(57)【要約】【課題】新規規制アルゴリズムを規制アルゴリズム起動中に入れ替えても即座にその新規アルゴリズムにて動作できるようにする。【解決手段】従来１つしか存在しなかったシナリオマネージャを、輻輳の検出から最初の規制制御を発動するまでの初期発動処理用と、その後のネットワークの監視を行いながら適切な規制量にて輻輳直前のところでネットワークトラヒックを安定させることを特定の解除条件を満たすまで継続的に行うフィードバック制御処理用と、の２つのシナリオマネージャに分割する。そして、それらをそれぞれ別々の契機にて起動することにより、発動最中にアルゴリズムを変更した場合でも、その変更後のアルゴリズムによって即時に動作させることができる。【選択図】      図１
2005020194.tif 000002
【特許請求の範囲】
【請求項１】
個別に変更が可能な複数のシナリオフラグメントそれぞれに対応する処理を順次実行することにより、トラヒックについて輻輳制御を行うトラヒックコントロール装置であって、前記複数のシナリオフラグメントのうち、輻輳規制発動開始に関するシナリオフラグメントに対応する処理を実行する初期発動シナリオマネージャと、前記複数のシナリオフラグメントのうち、前記初期発動シナリオマネージャによって実行される処理開始後に繰返し行われる輻輳規制に関するシナリオフラグメントに対応する処理を実行するフィードバック制御シナリオマネージャと、を含み、前記初期発動シナリオマネージャ及び前記フィードバック制御シナリオマネージャによって実行されるシナリオフラグメント全体によって輻輳制御を行うことを特徴とするトラヒックコントロール装置。
【請求項２】
前記初期発動シナリオマネージャは、輻輳の検出から最初の規制制御を発動するまでの初期発動処理を行うことを特徴とする請求項１記載のトラヒックコントロール装置。
【請求項３】
前記初期発動シナリオマネージャによって実行される処理開始後、一定時間内のトラヒック量が予め定められた閾値を超えないように繰返し制御するフィードバック制御を行うことを特徴とする請求項２記載のトラヒックコントロール装置。
【請求項４】
請求項１乃至３のいずれか１項のトラヒックコントロール装置と、輻輳発生の検出に応答して前記初期発動シナリオマネージャに処理実行を指示する手段と、一定時間経過毎に前記フィードバック制御シナリオマネージャに処理実行を指示する手段とを含むことを特徴とするトラヒックコントロールシステム。
【請求項５】
個別に変更が可能な複数のシナリオフラグメントそれぞれに対応する処理を順次実行することにより、トラヒックについて輻輳制御を行うトラヒックコントロール方法であって、前記複数のシナリオフラグメントのうち、輻輳規制発動開始に関するシナリオフラグメントに対応する処理を実行する初期発動ステップと、前記複数のシナリオフラグメントのうち、前記初期発動ステップにおいて実行される処理開始後に繰返し行われる輻輳規制に関するシナリオフラグメントに対応する処理を実行するフィードバック制御ステップとを含み、前記初期発動ステップ及び前記フィードバック制御ステップにおいて実行される処理全体によって輻輳制御を行うことを特徴とするトラヒックコントロール方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明はトラヒックコントロール装置、トラヒックコントロールシステム、トラヒックコントロール方法に関し、特に個別に変更が可能な複数のシナリオフラグメントそれぞれに対応する処理を順次実行することにより、トラヒックについて輻輳制御を行うトラヒックコントロール装置、トラヒックコントロールシステム、トラヒックコントロール方法に関する。
【０００２】
【従来の技術】
これまでのトラヒックコントロール装置では、輻輳及び輻輳予兆検出、輻輳要因特定、及び規制発動後のフィードバックに必要となるトラヒックの収集項目や規制アルゴリズムはトラヒックコントロール装置自体のアプリケーションへの作りこみであり、それらの情報を変更する際にはアプリケーションの変更が必要となる。また、規制アルゴリズムをシナリオ化（部品化）し、動的にアルゴリズムを入れ替えられるシステムも存在するが、それらのシステムにてアルゴリズム起動中（規制制御中）にそのアルゴリズムを入れ替えた場合、そのシナリオが一旦終了（輻輳の沈静後）するまでは旧アルゴリズムにて動作し、新規アルゴリズムが有効となる時は、新たにアルゴリズムが起動（新規輻輳発生）した時以降である。このようなシステムは、例えば、本願出願人による特願２００２−４３８３９号の明細書及び図面に記載されている。
【０００３】
図５は、上記明細書及び図面に記載されているトラヒックコントロール装置の構成を説明するためのブロック図である。同図に示されているように本装置は、ＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）７Ｃと、ミドルウェア７Ｂと、アプリケーションプログラム（以下、ＡＰと称することがある）群７Ａと、を含んで構成されている。
【０００４】
ＯＳ７Ｃには、例えばＳｏｌａｒｉｓ８を使用する。
ミドルウェア７Ｂは、例えば、システム故障監視と、ＤＢ等化プロセスと、ＳＴＬ（Ｓｔａｎｄｅｒｄ  Ｔｅｍｐｌａｔｅ  Ｌｉｂｒａｒｙ）と、ＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）と、ＮＴＰ（Ｎｅｔｗｏｒｋ  Ｔｉｍｅ  Ｐｒｏｔｏｃｏｌ）と、Ｓｙｓｔｅｍ  Ｗａｌｋｅｒ（登録商標）（システム統合運用管理ソフト群）と、ＯＲＡＣＬＥ８ｉ（登録商標）と、を含んで構成されている。
【０００５】
ＡＰ群７Ａには、業務ＡＰ群、システム管理、運用データ管理の他、シナリオを管理するエンジン（以下、シナリオマネージャと称す）が固定的に組み込まれている。
また、トラヒックコントロール装置にインストールされるＡＰ群７Ａの上位層７Ｄには、後述するシナリオフラグメント２，シナリオ定義ファイル３、及び、閾値定義ファイル４のシナリオマネージャによって使用される各種ファイルが含まれる。
【０００６】
ここでは、同一のトラヒックコントロール装置に、シナリオマネージャ、シナリオフラグメント２、シナリオ定義ファイル３、閾値定義ファイル４が含まれているが、シナリオフラグメント２、シナリオ定義ファイル３、及び、閾値定義ファイル４をネットワーク上の他の装置、例えばネットワークエレメント（以下、ＮＥと称す）、あるいは、分散処理を行う他のトラヒックコントロール装置に含めるように構成してもよい。
【０００７】
図６は、上記明細書及び図面に記載されているトラヒックコントロール装置によって実現される動的アルゴリズム変更機能の概要を説明する図である。同図に示されているように、シナリオ定義ファイル３と、シナリオマネージャ１と、シナリオフラグメント２とによって、本機能が実現される。
シナリオ定義ファイル３は、後述する各処理ブロック７にどのシナリオフラグメント２を使用するのかを指定するためのテキスト定義ファイルである。すなわち、シナリオ定義ファイル３にて定義した処理が、そのシナリオ定義ファイル３に対応する輻輳モデルに対して行われる処理となる。図６に示されているシナリオ定義ファイル３には、処理の流れが「１Ｃ→２Ｂ→３Ｂ」と定義されている。これは、図中の処理ブロック（１）においてはシナリオフラグメント２（１−Ｃ）を使用して処理１Ｃを、処理ブロック（２）においてはシナリオフラグメント２（２−Ｂ）を使用して処理２Ｂを、処理ブロック（３）においてはシナリオフラグメント２（３−Ｂ）を使用して処理３Ｂの処理を行うことを定義している。このシナリオ定義ファイル３は、基本的に輻輳モデル毎に存在し、複数存在する。
【０００８】
シナリオマネージャ１は、シナリオの定義に基づいて、規制制御を実現するためのプロセスである。ここで、シナリオとは、トラヒックコントロールのアルゴリズムを定義するものである。また、アルゴリズムは、規制ロジック、トラヒック収集項目、トラヒックコントロールのための閾値、及び、それらと輻輳モデルの対応等を含めて、トラヒックコントロールを行う方法である。トラヒックコントロールのアルゴリズムを定義するものであれば、その形式を限定するものではない。本例においては、シナリオ定義ファイル３と、閾値定義ファイル４と、制御情報インスタンス５と、に基づいて、シナリオフラグメント２と通信して規制制御を実現する。このシナリオマネージャ１は、複数の処理ブロックに分割されており、処理ブロック毎にシナリオ定義ファイル３にて定義されたシナリオフラグメントを呼び出す。
【０００９】
シナリオフラグメント２は、シナリオマネージャ１内の処理ブロック毎に必要とするトラヒックコントロールのロジックを定義する。本例において、シナリオフラグメント２は、実行ファイルとして構成されている。ただし、特にフォーマットや言語を特定する必要はなく、シナリオマネージャ１にて何を実行すればよいのかが認識できればよい。シナリオマネージャ１内の各処理ブロックにて呼ばれ、１プロセスを起動する。図６には、一点鎖線Ｘ内に、シナリオフラグメント２の集合が示されている。同図において、処理ブロック（１）には、それぞれ異なる処理、処理１Ａ、処理１Ｂ、処理１Ｃを定義するシナリオフラグメント２が、同様に、処理ブロック（２）には、それぞれ処理２Ａ、処理２Ｂ、処理２Ｃ、処理ブロック（３）には、それぞれ処理３Ａ、処理３Ｂ、処理３Ｃを定義するシナリオフラグメント２が対応している。
【００１０】
運用上においては、シナリオマネージャ１は、シナリオ定義ファイル３にて定義された各処理ブロックに対応するシナリオフラグメント２の管理番号（図６の例においては、１Ａ、２Ａ、…）を参照することによって、呼び出し動作可能となる。すなわち、アルゴリズムを追加・変更する場合には、追加すべきシナリオフラグメント２を追加し、あるいは、変更すべきシナリオフラグメント２を変更したシナリオフラグメント２と入れ替える。更に、シナリオ定義ファイル３に追加・変更したシナリオフラグメント２についての定義を追加する。これにより、アルゴリズムを変更することができる。このため、アルゴリズムの変更に伴ってアプリケーションプログラムの変更を行う必要がない。アプリケーションプログラム自体に、規制ロジック、トラヒック収集項目、及び、それらと輻輳モデルの対応を作り込んだ場合には、一部のアルゴリズムの変更であっても、関連する全てのモジュールについて変更しなければならない。さらに、運用するためには、その変更の全てにつき、試験を行わなければならない。
【００１１】
一方、シナリオフラグメント２の入れ替えでは、その新たなシナリオフラグメント２の部分だけを試験すればよい。更に、登録済みのシナリオフラグメント２の組合せの変更だけで済むような輻輳モデルの追加であれば、シナリオ定義ファイル３の追加だけで事足りることになる。加えて、上述のようにシナリオフラグメント２を入れ替える代わりに、追加する。例えば、変更後のシナリオフラグメント２を追加し、変更後のシナリオフラグメント２のみを定義するシナリオ定義ファイル３を追加する。これにより、トラヒックコントロール装置を停止することなく、変更を反映させることができる。ゆえに、本体装置にインストールされるアプリケーションプログラムの改版（変更後のアプリケーションプログラムの再インストール）のように、装置の停止による長期間の輻輳の無監視状態を招くことなく、ファイルの更新をアプリケーションプログラムとなるシナリオマネージャが認識するまでのわずかの間に変更に対応することができる。
【００１２】
制御情報インスタンス５は、輻輳したＮＥを制御するための情報（各種トラヒック、計算した負荷量、規制量）をセットするファイルである。シナリオフラグメント２同士で交換するための情報を保持するものである。例えば、制御情報インスタンス５は、シナリオフラグメント２において行った演算の結果を、他のシナリオフラグメント２において使用する等の場合に使用する。すなわち、演算を行ったシナリオフラグメント２において制御情報インスタンス５へ演算結果を出力し、他のシナリオフラグメント２に制御情報インスタンス５を渡すことにより、受け取ったシナリオフラグメント２において演算結果を使用することができる。
【００１３】
つまり、シナリオフラグメント２同士の間での情報共有や受け渡しのために、制御情報インスタンス５というデータ構造体を用意する。本例においては、図６に示されているように、制御情報インスタンス５は、ＣＯＲＢＡ通信（ｃｏｍｍｏｎ  ｏｂｊｅｃｔ  ｒｅｑｕｅｓｔ  ｂｒｏｋｅｒ  ａｒｃｈｉｔｅｃｔｕｒｅ）によって処理を行うシナリオフラグメント２に引き渡され、シナリオフラグメント２における処理中に情報が書込まれる。処理が終わると、新たな情報が書込まれた制御情報インスタンス５は、再びシナリオマネージャ１に引き渡される。
【００１４】
この制御情報インスタンス５の型は、シナリオマネージャ、全てのシナリオフラグメントにおいて共通に使用するため、同一型である必要がある。また、いかなるシナリオフラグメントでも共有できるユニークな構造体を事前に用意する必要があるため、考え得る全ての情報が書き込める構造体でなくてはならない。
図７には、制御情報インスタンスの構造体例が示されている。同図には、構造体のメンバとなるデータ項目が列挙されている。このうち、「予備領域」は、制御情報インスタンスの型はユニークである必要があるため、事前に予測しきれない情報もあることを想定し、追加される情報に割り当て可能な領域として確保するものである。これにより、情報の追加に対して柔軟に対応することができる。
【００１５】
閾値定義ファイル４は、各トラヒックの閾値や対象とするネットワークを安定させるための目標となる値等を定義する。輻輳及び輻輳予兆の発生を検出するために、監視しているトラヒック項目毎に輻輳及び輻輳予兆発生と判断する値や、規制制御を実施しトラヒックを安定させる際の目標となるトラヒックの値等である。
【００１６】
この閾値定義ファイルは、シナリオフラグメント２内においてその使用が定義される各種閾値の実データが格納されている。すなわち、シナリオフラグメント２に定義される処理の実行において、必要となる各種閾値の値は、閾値定義ファイルを参照することにより得ることができる。閾値定義ファイル４は、単一で存在し、シナリオフラグメントの様に頻繁に追加することは前提とされていない。ただし、値を変更する必要が発生することも考慮し、閾値定義ファイルをサーバ実行環境ファイルとして管理する。
【００１７】
このように、各種閾値等の実データをアプリケーションプログラム自体に組み込むことなく、閾値定義ファイルとして構成することにより、対象とするネットワークの性能が向上した場合等に迅速な対応が可能である。すなわち、ネットワークを安定させるために目標とする負荷値や各トラヒック項目の閾値の変更を、本体アプリケーンョンプログラム自体に手を加えることなく、閾値定義ファイル内の該当パラメータの数値を変更することによって、本体装置を新たな情報にて動作させることが可能である。また、閾値を変更することなく、シナリオフラグメントに定義する処理のみを変更するような場合に、閾値の値が不要に変更される事態を防ぐことができる。
【００１８】
以上のように、シナリオとシナリオマネージャによってトラヒックコントロールを行うことにより、対象とするネットワークに変更等があった際等、本体アプリケーションプログラム自体に手を加えることなく、シナリオフラグメントの入れ替えにて新たな規制ロジックを迅速に本体装置に認識させることができる。
また、対象とするネットワークの性能が向上した際等、ネットワークを安定させるために目標とする負荷値や各トラヒック項目の閾値の変更を、本体アプリケーションプログラム自体に手を加えることなくシナリオのパラメータ（数値）を変更することによって本体装置に認識させることができる。
【００１９】
さらに、シナリオフラグメントの追加という形態にて、アルゴリズムの変更を実現することにより、本体装置を停止させることなく動的に変更することができる。
なお、特許文献１には、ファームウェアファイル更新をシナリオ化し、通信機器が実際の更新動作を自律で行うようにすることで、更新を簡単に行う技術が記載されている。
【００２０】
【特許文献１】
特開平７−２４８９１３号公報（段落［００３９］）
【００２１】
【発明が解決しようとする課題】
上述した従来の技術では、規制アルゴリズム（シナリオ）起動中に入れ替えた規制アルゴリズムが有効となるのは、一旦その旧アルゴリズムが終了した後になるという問題があった。
また、特許文献１は更新を簡単に行う技術にすぎず、上記と同様な問題がある。
本発明は上述した従来技術の欠点を解決するためになされたものであり、その目的は新規規制アルゴリズムを規制アルゴリズム起動中に入れ替えても即座にその新規アルゴリズムにて動作することのできるトラヒックコントロール装置、トラヒックコントロールシステム、トラヒックコントロール方法を提供することである。
【００２２】
【課題を解決するための手段】
本発明の請求項１によるトラヒックコントロール装置は、個別に変更が可能な複数のシナリオフラグメントそれぞれに対応する処理を順次実行することにより、トラヒックについて輻輳制御を行うトラヒックコントロール装置であって、前記複数のシナリオフラグメントのうち、輻輳規制発動開始に関するシナリオフラグメントに対応する処理を実行する初期発動シナリオマネージャ（後述する図１中の初期発動シナリオマネージャ２００に対応）と、前記複数のシナリオフラグメントのうち、前記初期発動シナリオマネージャによって実行される処理開始後に繰返し行われる輻輳規制に関するシナリオフラグメントに対応する処理を実行するフィードバック制御シナリオマネージャ（後述する図２中のフィードバック制御シナリオマネージャ３００に対応）と、を含み、前記初期発動シナリオマネージャ及び前記フィードバック制御シナリオマネージャによって実行されるシナリオフラグメント全体によって輻輳制御を行うことを特徴とする。このような構成を採用することにより、輻輳制御アルゴリズムが起動中であっても、シナリオフラグメントを追加・削除・変更すると、即時に新規なアルゴリズムで輻輳制御を行うことができる。
【００２３】
本発明の請求項２によるトラヒックコントロール装置は、請求項１において、前記初期発動シナリオマネージャは、輻輳の検出から最初の規制制御を発動するまでの初期発動処理を行うことを特徴とする。これにより、輻輳発生に応答して初期発動処理を行うことができる。
本発明の請求項３によるトラヒックコントロール装置は、請求項２において、前記初期発動シナリオマネージャによって実行される処理開始後、一定時間内のトラヒック量が予め定められた閾値を超えないように繰返し制御するフィードバック制御を行うことを特徴とする。これにより、初期発動処理後、一定時間毎に、輻輳制御のためのフィードバック制御を行うことができる。
【００２４】
本発明の請求項４によるトラヒックコントロールシステムは、請求項１乃至３のいずれか１項のトラヒックコントロール装置と、輻輳発生の検出に応答して前記初期発動シナリオマネージャに処理実行を指示する手段（後述する図１中のプロセス７に対応）と、一定時間経過毎に前記フィードバック制御シナリオマネージャに処理実行を指示する手段（後述する図２中のプロセス７に対応）とを含むことを特徴とする。このように構成することにより、輻輳発生に応答して初期発動処理を実行でき、かつ、その処理後には輻輳制御のためのフィードバック制御を行うことができる。
【００２５】
本発明の請求項５によるトラヒックコントロール方法は、個別に変更が可能な複数のシナリオフラグメントそれぞれに対応する処理を順次実行することにより、トラヒックについて輻輳制御を行うトラヒックコントロール方法であって、前記複数のシナリオフラグメントのうち、輻輳規制発動開始に関するシナリオフラグメントに対応する処理を実行する初期発動ステップと、前記複数のシナリオフラグメントのうち、前記初期発動ステップにおいて実行される処理開始後に繰返し行われる輻輳規制に関するシナリオフラグメントに対応する処理を実行するフィードバック制御ステップとを含み、前記初期発動ステップ及び前記フィードバック制御ステップにおいて実行される処理全体によって輻輳制御を行うことを特徴とする。このような構成を採用することにより、輻輳制御アルゴリズムが起動中であっても、シナリオフラグメントを追加・削除・変更すると、即時に新規なアルゴリズムで輻輳制御を行うことができる。
【００２６】
要するに本発明によるトラヒックコントロール装置は、特定のネットワークの輻輳を監視しトラヒックを安定させることを目標とする装置であり、更に、ネットワークを安定させるために使用するアルゴリズムをその装置自体のアプリケーションプログラムに手を加えることなく、変更することが可能なシナリオ機能を具備した装置において、従来１つしか存在しなかったシナリオマネージャを、輻輳の検出から最初の規制制御を発動するまでの処理（以下、初期発動と称す）と、その後のネットワークの監視を行いながら適切な規制量にて輻輳直前のところでネットワークトラヒックを安定させることを特定の解除条件を満たすまで継続的に行う処理（以下、フィードバック制御と称す）と、の２つのシナリオマネージャに分割し、それぞれ別々の契機にて起動することにより、発動最中にアルゴリズムを変更した場合でも、その変更後のアルゴリズムによって即時に動作させることができる。
【００２７】
そして、輻輳事象に対して１回初期発動が起動した後、その輻輳が沈静化するまでフィードバック制御が繰返し、起動されることとなる。この一連の動きによって１つの規制アルゴリズムが完成する。それぞれのシナリオマネージャの起動契機は別々の条件であり、更に、フィードバック制御は、繰返し起動契機を受け動作するため、その契機の度にシナリオ定義ファイルを参照することが可能となる。よって、参照したシナリオ定義ファイルの内容がこの一連の流れの途中で変更されても実行上問題は起きない。そして、規制アルゴリズム起動中に書き換えた場合、その新規アルゴリズムにて即時に動作できる。
【００２８】
ただし、フィードバック制御が実際に処理を開始するには、特定のＮＥのトラヒック値が予め設定した閾値を超え、かつそのＮＥを対象に初期発動が起動したことが条件となる。その初期発動が行われたかどうかの情報や各フラグメントのアウトプットで他のシナリオフラグメントが必要とするデータを受け渡すファイル（以下、制御情報インスタンスと称す）も実装上必要となる。
【００２９】
【発明の実施の形態】
次に、図面を参照して本発明の実施の形態について説明する。なお、以下の説明において参照する各図においては、他の図と同等部分に同一符号が付されている。
（トラヒックコントロール装置）
本実施形態においては、初期発動用のシナリオマネージャ（以下、初期発動シナリオマネージャと称する）と、フィードバック制御用のシナリオマネージャと（以下、フィードバック制御シナリオマネージャと称する）を設けている。初期発動シナリオマネージャは、輻輳規制発動開始に関するシナリオフラグメントに対応する処理を実行するシナリオマネージャである。初期発動シナリオマネージャは、一連の規制処理を発動させるための初期発動処理を行う。
【００３０】
フィードバック制御シナリオマネージャは、初期発動シナリオマネージャによって実行される処理開始後に繰返し行われる輻輳規制に関するシナリオフラグメントに対応する処理を実行するシナリオマネージャである。フィードバック制御シナリオマネージャは、一定時間内のトラヒック量が予め定められた閾値を超えないように制御するフィードバック制御処理を行う。
【００３１】
このように、１つのシナリオマネージャによって輻輳制御を行うのではなく、初期発動シナリオマネージャとフィードバックシナリオマネージャとに分割されたシナリオマネージャを用いることにより、規制アルゴリズム起動中にシナリオフラグメントを書換えた場合、その新規アルゴリズムにて即時に動作できる。
本例では、初期発動シナリオマネージャの起動契機となるイベントを輻輳通知とする。また、フィードバック制御シナリオマネージャの起動契機となるイベントをトラヒック凍結通知とする。
【００３２】
図１には、初期発動シナリオマネージャ２００を用いた初期発動処理の流れが示されている。また、図２には、フィードバック制御シナリオマネージャ３００を用いたフィードバック制御処理の流れが示されている。以下、これらの図を参照して、初期発動処理、フィードバック制御処理、について説明する。
（初期発動処理）
図１において、同図中の輻輳通知２０は、監視対象となっているネットワークを構築するＮＥから通知されてくる信号である。この輻輳通知２０は、ＮＥが予め定めた閾値を超えたトラヒックを、周辺ＮＥから受信した際に送出される。初期発動シナリオマネージャ２００は、輻輳通知２０を受信したことに応答して起動される。
【００３３】
図１中の「イベント受付２１」、「シナリオ判定２２」、「制御情報インスタンス初期設定２３」、「シナリオフラグメントＡ」、「シナリオフラグメントＢ」、「シナリオフラグメントＣ」、「シナリオフラグメントＤ」、「シナリオフラグメントＥ」、「シナリオフラグメントＦ」、「シナリオフラグメントＧ」は、図６中の一点鎖線Ｘ内のシナリオフラグメントに対応しており、これらが初期発動シナリオマネージャによって処理される。
【００３４】
初期発動シナリオマネージャ２００は、アプリケーション内のプロセス７から輻輳通知２０を受信すると「イベント受付２１」というフラグメントによって起動される。その後、輻輳要因が判断される。この判断によって輻輳要因が特定されると、「シナリオ判定２２」というフラグメントによって適切なシナリオ定義ファイルが判定される。そして、そのシナリオ定義ファイルに示されたシナリオフラグメントが順次起動されていく。シナリオフラグメント起動の際には、「制御情報インスタンス初期設定２３」というフラグメントによって新規の制御情報インスタンスが作成され、初期発動完了時にその旨が書込まれる。
【００３５】
本例では、その後、同図中のシナリオフラグメントＡ、シナリオフラグメントＢ、シナリオフラグメントＣ、シナリオフラグメントＤ、シナリオフラグメントＥ、シナリオフラグメントＦ、シナリオフラグメントＧ、が順次起動される。
（フィードバック制御処理）
図２において、同図中のトラヒック凍結通知３０は、監視対象となっている全ＮＥから一定時間毎に収集しているトラヒックデータの集計が終わったことを知らせる信号である。例えば、トラヒックデータを毎分収集している場合、このトラヒック凍結通知３０は、アプリケーション内のプロセス７から毎分通知されることになる。フィードバック制御シナリオマネージャ３００は、トラヒック凍結通知３０を受信したことに応答して起動される。
【００３６】
図２中の「イベント受付３１」、「シナリオ判定３２」、「制御情報インスタンス初期設定３３」、「シナリオフラグメントＨ」、「シナリオフラグメントＩ」、「シナリオフラグメントＪ」、「シナリオフラグメントＫ」、「シナリオフラグメントＬ」、「シナリオフラグメントＭ」、「シナリオフラグメントＮ」は、図６中の一点鎖線Ｘ内のシナリオフラグメントに対応しており、これらがフィードバック制御シナリオマネージャによって処理される。
【００３７】
フィードバック制御シナリオマネージャ３００は、アプリケーション内のプロセスからトラヒック凍結通知３０を毎分受信し、その度に制御情報インスタンスを参照し、該当ＮＥに対して既に初期発動が実行されたかを確認し完了していれば、「イベント受付３１」というフラグメントによって起動される。起動後は、初期発動シナリオマネージャの場合と同様に、「シナリオ判定３２」というフラグメントによってシナリオ定義ファイルを参照し、実行すべきフラグメントを認識し、指定のフラグメントを順次実行していく。シナリオフラグメント起動の際には、「制御情報インスタンス初期設定３３」というフラグメントによって新規の制御情報インスタンスが作成され、初期発動完了時にその旨が書込まれる。
【００３８】
本例では、その後、同図中のシナリオフラグメントＨ、シナリオフラグメントＩ、シナリオフラグメントＪ、シナリオフラグメントＫ、シナリオフラグメントＬ、シナリオフラグメントＭ、シナリオフラグメントＮ、が順次起動される。
すなわち、アプリケーション内のプロセスからトラヒック凍結通知３０が送出されることにより、イベント受付３１が行われる。これにより、シナリオ判定３２、制御情報インスタンス初期設定３３等、以後の処理が順に行われる。
【００３９】
ところで、どのようなタイミングにおいても、アルゴリズム変更は、新規となるシナリオフラグメントを追加し、シナリオ定義ファイルを変更することによって実現される。よって、規制アルゴリズム起動時に、そのアルゴリズムを変更しても、実行中アルゴリズムの次周期には新規アルゴリズムにて動作することとなる。本例の場合、フィードバック制御シナリオマネージャ３００は、トラヒック凍結通知３０を毎分受信しているので、最大でも１分で次のフィードバック制御が起動されることになる。
【００４０】
（初期発動処理の例）
次に、初期発動シナリオマネージャによる初期発動処理の例について図３を参照して説明する。最初に、輻輳通知を受信したか判断する（ステップＳ４０１）。輻輳通知を受信した場合、輻輳要因を判断する（ステップＳ４０１→Ｓ４０２）。次に、シナリオ定義ファイルを検索し（ステップＳ４０３）、シナリオ定義ファイルを参照する（ステップＳ４０４）。これにより、シナリオフラグメントを認識し（ステップＳ４０５）、そのシナリオフラグメントを実行する（ステップＳ４０６）。
ここで、処理が終了かどうか判断する（ステップＳ４０７）。処理が終了でない場合、ステップＳ４０４に戻って処理は継続される（ステップＳ４０７→Ｓ４０４…）。処理が終了の場合、最後に制御情報インスタンスを作成し、初期発動が完了した旨を書込む（ステップＳ４０７→Ｓ４０８）。
【００４１】
（フィードバック制御処理の例）
次に、フィードバック制御シナリオマネージャによるフィードバック制御処理の例について図４を参照して説明する。
凍結通知を受信したか判断する（ステップＳ５０１）。凍結通知を受信した場合、制御情報インスタンスを参照し（ステップＳ５０２）、初期発動が実行されているか判断する（ステップＳ５０３）。すなわち、図３中のステップ４０８において、初期発動が完了した旨の制御情報インスタンスが作成されている場合に限り、以降の処理が行われる。
【００４２】
図３に示されている初期発動処理の場合と同様に、シナリオ定義ファイルを参照する（ステップＳ５０４）。これにより、シナリオフラグメントを認識し（ステップＳ５０５）、そのシナリオフラグメントを実行する（ステップＳ５０６）。
ここで、処理が終了かどうか判断し（ステップＳ５０７）、処理は終了となる。一方、処理が終了でない場合、ステップＳ５０４に戻って処理は継続される（ステップＳ５０７→Ｓ５０４…）。
【００４３】
（トラヒックコントロールシステム）
以上の説明によれば、以下のようなトラヒックコントロールシステムが実現されていることになる。すなわち、初期発動及びフィードバック制御のそれぞれのために別々に用意されたシナリオマネージャと、初期発動シナリオマネージャに処理実行を指示する手段（図１中のプロセス７に対応）と、一定時間経過毎に前記フィードバック制御シナリオマネージャに処理実行を指示する手段（図２中のプロセス７に対応）とを含むトラヒックコントロールシステムが実現されている。このように構成することにより、輻輳発生に応答して初期発動処理を実行でき、かつ、その処理後には輻輳制御のためのフィードバック制御を行うことができる。
【００４４】
（トラヒックコントロール方法）
以上の説明によれば、以下のようなトラヒックコントロール方法が実現されていることになる。すなわち、個別に変更が可能な複数のシナリオフラグメントそれぞれに対応する処理を順次実行することにより、トラヒックについて輻輳制御を行うトラヒックコントロール方法であり、上記複数のシナリオフラグメントのうち、輻輳規制発動開始に関するシナリオフラグメントに対応する処理を実行する初期発動ステップと、上記複数のシナリオフラグメントのうち、上記初期発動ステップにおいて実行される処理開始後に繰返し行われる輻輳規制に関するシナリオフラグメントに対応する処理を実行するフィードバック制御ステップとを含み、上記初期発動ステップ及び上記フィードバック制御ステップにおいて実行される処理全体によって輻輳制御を行うトラヒックコントロール方法が実現されている。このような構成を採用することにより、輻輳制御アルゴリズムが起動中であっても、シナリオフラグメントを追加・削除・変更すると、即時に新規なアルゴリズムで輻輳制御を行うことができる。
【００４５】
（まとめ）
以上説明したように、本発明においては、シナリオ機能を具備したトラヒックコントロール装置を前提とし、その核となる規制アルゴリズムの入れ替えをそのアルゴリズムが起動中でも行うことができるものであり、更に、アルゴリズム起動中の変更でも、その新規アルゴリズムにて即時に動作することができる。
このため、アルゴリズムを変更したい時、本機能により規制制御がかかっているＮＥがあるか（アルゴリズム実行中かどうか）を確認する必要がなくなる。この調査稼動削減効果は、対象としているＮＥの数が多ければ多いほど、大きくなる。
また、シナリオフラグメントのコーディング等に誤り（バグ）があり、規制制御が永久ループ状態に陥り、終了できなくなった際にも、修正したフラグメントを追加し、入れ替えることにより、強制的にアルゴリズムの起動を停止しなくても救済することができる。
【００４６】
【発明の効果】
以上説明したように本発明は、従来１つしか存在しなかったシナリオマネージャを、輻輳の検出から最初の規制制御を発動するまでの初期発動処理用と、その後のネットワークの監視を行いながら適切な規制量にて輻輳直前のところでネットワークトラヒックを安定させることを特定の解除条件を満たすまで継続的に行うフィードバック制御処理用と、の２つのシナリオマネージャに分割し、それぞれ別々の契機にて起動することにより、発動最中にアルゴリズムを変更した場合でも、その変更後のアルゴリズムによって即時に動作させることができるという効果がある。
【図面の簡単な説明】
【図１】本発明によるトラヒックコントロール装置における、初期発動シナリオマネージャを用いた初期発動処理の流れを示す図である。
【図２】本発明によるトラヒックコントロール装置における、フィードバック制御シナリオマネージャを用いたフィードバック制御処理の流れを示す図である。
【図３】初期発動シナリオマネージャによる初期発動処理の例を示すフローチャートである。
【図４】フィードバック制御シナリオマネージャによるフィードバック制御処理の例を示すフローチャートである。
【図５】本願出願人による他の出願の明細書及び図面に記載されているトラヒックコントロール装置の構成を説明するためのブロック図である。
【図６】本願出願人による他の出願の明細書及び図面に記載されているトラヒックコントロール装置によって実現される動的アルゴリズム変更機能の概要を説明する図である。
【図７】制御情報インスタンスの構造体例を示す図である。
【符号の説明】
１  シナリオマネージャ
２  シナリオフラグメント
３  シナリオ定義ファイル
４  閾値定義ファイル
５  制御情報インスタンス
７Ａ  ＡＰ群
７Ｂ  ミドルウェア
７Ｃ  ＯＳ
７Ｄ  上位層
２０  輻輳通知
２１  イベント受付
２２  シナリオ判定
２３  制御情報インスタンス初期設定
３０  トラヒック凍結通知
３１  イベント受付
３２  シナリオ判定
３３  制御情報インスタンス初期設定
２００  初期発動シナリオマネージャ
３００  フィードバック制御シナリオマネージャ
Ａ〜Ｎ  シナリオフラグメント
【図１】
2005020194.tif 000003
【図２】
2005020194.tif 000004
【図３】
2005020194.tif 000005
【図４】
2005020194.tif 000006
【図５】
2005020194.tif 000007
【図６】
2005020194.tif 000008
【図７】
2005020194.tif 000009