自動障害修復のための通信ネットワーク管理システム
本発明は、ネットワーク要素Ｎ１、Ｎ２、Ｎ３、Ｎ４によって供給される情報Ａから診断Ｄを判定することができる診断モジュールＭＤを含む通信ネットワークＮの管理のためのシステムＮＭＳであって、前記診断がネットワーク内の障害を識別するシステムに関する。管理システムはまた、少なくとも前記診断から１つまたは複数の修正行為を判定し、障害を修正するために修正行為に対応する１つまたは複数のコマンドＣを１つまたは複数のネットワーク要素に送信することが意図された修復モジュールＭＲも含む。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は通信ネットワークに関し、限定されるわけではないが、特にはパケット志向の通信ネットワークに適用可能である。本発明は、より詳細には通信ネットワークの管理に関する。
【背景技術】
【０００２】
ネットワーク管理システム（ＮＭＳ）は、ネットワーク機器からの警報を収集し、特にはコリレーション方法を使用してこれらの警報の要約を作成し、この要約またはこれらの警報をオペレータに対して表示して、この機器のうちの１つまたは複数のアイテムに障害がある場合にオペレータが修正行為を実行できるようにするために、通信ネットワークに関連付けられることができることが知られている。「障害」の概念は、ハードウェアまたはソフトウェアの機能異常のうちのあらゆる種類のものを表す非常に広い意味で理解されなければならない。したがって、ネットワーク要素の誤った構成は障害であるとみなされることが可能であり（ソフトウェア）、同様に、テーブルをルーティングするＩＰルータにおけるエラー、または偶然閉じられてしまったポートも、障害であるとみなされることが可能である。
【０００３】
ネットワーク管理システムは、ネットワーク機器を構成するために使用されることも可能である。オペレータはマンマシンインタフェースを使用して新しいパラメータを入力することができ、ネットワーク管理システムはこれらの新しいパラメータを機器に適用する。このようにして、オペレータは警報の表示に対する反応の中で、ネットワーク障害を修正することができる。
【０００４】
そのような集中化された分析は、通信システムの中の多くの要素から大量のデータおよび警報を収集することに依存している。これらの要素はＩＰ（インターネットプロトコル）通信ネットワークのフレームワークにおけるルータなどの機器であってよいが、いわゆるＮＧＮ（次世代ネットワーク）における音声および光学スイッチ、ＰＡＢＸ（構内交換機）およびメディアゲートウェイ等に関連するものであることも可能である。ネットワーク要素はまた、例えばカードなど、そうした機器の一部を形成してもよい。
【０００５】
ネットワークの要素の間の多くの相互作用のために、単一の障害が非常に多くの数の警報を生成する可能性がある。したがって、機器のアイテム中のカード上の障害は、このカード上のポートの１つに接続された他の機器中のすべてのカードからの警報と、障害が起こった機器のカードによる警報とを生成することもある。
【０００６】
したがってオペレータにとっては、多数の生成された警報の中でどれが本当の障害であるのかを判定することは困難なので、行われるべき修正行為を判定することはさらに困難である。
【０００７】
最もありそうな原因を判定するために、この多数の警報を使用する診断システムによって、進歩がなされた。
【０００８】
これらの診断システムは例えば、Ｉｌｏｇ社によって売り出されているＩｌｏｇＲｕｌｅｓ（商標）製品に基づく規則などの、規則の組に基づいている。これらの診断システムはまた、ニューラルネットワーク、ベイシアンネットワーク、エキスパートシステム、または特には人工知能などのその他の技術に基づいていてもよい。
【０００９】
言及に値するいくつかの製品は、Ａｇｉｌｅｎｔ社の「Ｆａｕｌｔ Ｄｅｔｅｃｔｉｖｅ ｆｏｒ Ｄａｔａ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ（ＦＤＤＣ）」、Ｈｅｗｌｅｔｔ−Ｐａｃｋａｒｄの「Ｎｅｔｗｏｒｋ Ｎｏｄｅ Ｍａｎａｇｅｒ」および「Ｎｅｔｗｏｒｋ Ｎｏｄｅ Ｍａｎａｇｅｒ Ｅｘｔｅｎｄｅｄ Ｔｏｐｏｌｏｇｙ」製品、ならびにＣｉｓｃｏ社の「Ｏｕｔｐｕｔ Ｉｎｔｅｒｐｒｅｔｅｒ」および「Ｔｒｏｕｂｌｅｓｈｏｏｔｉｎｇ Ａｓｓｉｓｔａｎｔ（ＴＡＣ）」製品である。
【００１０】
それでもやはり、オペレータは行われるべき修正行為を判定し、その行為を起こすために、これらのツールを用いて各障害に対して処置を施さなければならない。その後、オペレータはネットワーク管理システムを使用してネットワークを再構成するか、または機器のアイテムのうちの１つまたは複数に手動で接続し、適切なＣＬＩ（コマンド行インタフェース）コマンドを送信する必要がある。
【００１１】
この作業は現状技術の診断システムによって補助されるが、依然として難しいものであり、したがって費用がかかり、エラーを起こしやすい。
【００１２】
実際、再構成と機器フェーズへの手動接続とは時間がかかり、退屈なものである。これらの作業はＣＬＩコマンドのパラメータの中で間違いを起こしやすいので、別のネットワーク障害を引き起こしやすい。
【００１３】
オペレータは最適な行為を求める場合、ネットワークの性能情報およびその他のパラメータを考慮に入れなければならないので、修正行為のフェーズを判定することはオペレータにとって実に難しいことである。
【００１４】
これらの作業は、増加したネットワークの複雑性、利用可能な機器タイプの数およびそれらの複雑性のために、さらに一層難しく、費用がかかるようになる。
【００１５】
診断の判定によって通信ネットワーク機器の構成を自動化する解決法が利用可能である。そのような解決法は、例えばインテリジェントエージェントおよびマルチエージェント技術の実用アプリケーションについての国際会議紀要において１９９６年４月２２日に発表されたＭｅｒｃｅｄｅｓ Ｇａｒｉｊｏ、Ａｎｄｒｅｓ Ｃａｎｃｅｒ、Ｊｕｌｉｏ Ｊ．Ｓａｎｃｈｅｚの「Ａ Ｍｕｌｔｉａｇｅｎｔ Ｓｙｓｔｅｍ ｆｏｒ Ｃｏｏｐｅｒａｔｉｖｅ Ｎｅｔｗｏｒｋ−Ｆａｕｌｔ Ｍａｎａｇｅｍｅｎｔ」で説明されており、北京で開催されたＩＥＥＥ国際会議「システム、人間およびサイバネティクス」で１９９６年１０月に発表されたＪｉａｎｎ−Ｌｉａｎｇ Ｃｈｅｎ、Ｐｅｉ−Ｈｗａ Ｈｕａｎｇの「Ａ Ｆｕｚｚｙ Ｅｘｐｅｒｔ Ｓｙｓｔｅｍ ｆｏｒ Ｎｅｔｗｏｒｋ Ｆａｕｌｔ Ｍａｎａｇｅｍｅｎｔ」でも説明されている。
【００１６】
しかしながらこれらのシステムは、検出された問題点を修正行為が実際に修正したことを確認するいかなる方法も含んでいない。さらに、これらのシステムを用いることで、これらの修正行為が状況を悪化させていないということが確信されることは不可能である。これらの文献の中で、この問題は言及さえされていない。
【発明の開示】
【発明が解決しようとする課題】
【００１７】
本発明の目的は、検出された問題が修正されることを保証するか、または少なくとも遠距離通信ネットワークの全般的な状況が改善されることを保証しながら、管理された通信ネットワークにおいて障害の修正を自動化することである。
【課題を解決するための手段】
【００１８】
このことを達成するために、本発明の第１の目的は、通信ネットワークの中の要素によって提供される情報を利用して診断を判定することができる診断モジュールを含む通信ネットワークの管理のためのシステムである。この診断は、通信ネットワーク内の障害を識別する。この管理システムは、
−診断モジュールから受信された診断に基づいて、１つまたは複数の修正行為を判定し、
−障害を修正するために、修正行為に対応する１つまたは複数のコマンドを通信ネットワークの中の１つまたは複数の要素に送信し、
−診断モジュールによる新たな診断の判定を開始するために、診断要求を診断モジュールに送信するように設計された修復モジュールもまた含むことを特徴とする。
【００１９】
本発明の実施形態によって、管理システムは以下の特徴を１つずつ、または組み合わせて有してもよい。
−イテレーションカウンタ（ｉｔｅｒａｔｉｏｎ ｃｏｕｎｔｅｒ）は新たな診断が開始される度に増やされ、管理システムはイテレーションカウンタが所定の閾値に達するとき、診断および修復モジュールを停止する。
−コマンドは、一般言語で公式化されたコマンドを、通信ネットワーク中の異なる機器に特有のコマンド言語を伴う特有のコマンドコンプライアント（ｃｏｍｐｌｉａｎｔ）に変換することができる仲介モジュールを通じて送信される。
−修復モジュールは、障害を修正するために修正行為が十分に判定されることが不可能な場合に、通信ネットワークの動作においてこの障害の影響を取り除くか、または制限するために、トラフィック最適化モジュールと通信するように配置される。
−診断モジュールは、診断を判定するためにベイシアンネットワークを使用する。
−診断は少なくとも障害の説明、障害の位置を含み、場合によっては診断に関連した起こりうる事態の予想を含む。
−診断モジュールは、診断を含むＳＮＭＰプロトコルを備えたメッセージコンプライアントを修復モジュールに送信する。
−修復モジュールは修復規則のベースを有する。
−規則はイテレーションカウンタに依存してもよい。
−修復モジュールは、各イテレーションで判定された診断履歴と修正行為履歴とを有し、診断が、閾値が到達されるときに所与のイテレーションの間のものと同様に適切ではない場合、通信ネットワークをこの所与のイテレーションの間の状態に戻すことができる。
【００２０】
本発明の第２の目的は、通信ネットワークの要素によって提供される情報に基づき診断を判定するための第１ステップを含む通信ネットワークの管理のための方法である。この方法は、診断が障害を識別する場合、障害を修正するために、少なくとも診断に基づいて１つまたは複数の修正行為を判定し、通信ネットワークの１つまたは複数の要素に、これまたはこれらの修正行為に対応する１つまたは複数のコマンド（Ｃ）を送信する第２ステップも含み、処理サイクルを形成するために、第２ステップの終了時に第１ステップが自動的に開始されることを特徴とする。
【００２１】
本発明の実施形態によって、管理方法は以下の特徴を１つずつか、または組み合わせて含んでもよい。
−イテレーションカウンタは新たな診断が起こされる度に増やされ、このイテレーションカウンタが所定の閾値に達するとき、処理サイクルは中断される。
−コマンドは、一般言語で公式化されたコマンドを、通信ネットワーク中の異なる機器に特有のコマンド言語を伴う特有のコマンドコンプライアントに変換することができる仲介モジュールを通じて送信される。
−コマンドは、障害を十分に修正するために修正行為が判定されることが不可能な場合、通信ネットワークの動作においてこの障害の影響を取り除くか、または制限するために、トラフィック最適化モジュールに送信されてもよい。
−第１ステップは、診断を判定するためにベイシアンネットワークを使用する。
−診断は少なくとも障害の説明、障害の位置を含み、場合によっては診断に関連して起こりうる事態の予想を含む。
−各イテレーションで判定された診断履歴および修正行為履歴が構築され、診断が、閾値が到達されるときにこの前のイテレーションの間のものと同様に適切ではない場合、この前のイテレーションの間の通信ネットワークの状態が回復される。
【００２２】
したがって本発明により、修復モジュールは障害の影響を制限するために、および特には通信ネットワーク上のＳＬＡ（サービスレベル契約）設定へのそれらの影響を制限するために、通信障害を自動的に修復すること、および／または修正行為を行うことが可能であるか、またはオペレータによる動作確認の後で、これらの修復を半自動化することが可能である。
【００２３】
修正の後、診断モジュールは、この修復が新たな障害を生成していないことを保証するため、およびもし障害を生成していれば、それらを順次修正するために、新たな診断を行うことを求められる。したがって、診断された障害を修復することに集中しなければならない処理サイクルが実施されてもよい。
【００２４】
閾値は極端に長い修復ループを防ぐために、ループ内のイテレーションの数に対して固定されてもよい。
【００２５】
本発明ならびにその特徴および利点は、添付の図面を参照して以下の説明を読んだ後により明らかとなろう。
【００２６】
これらの添付の図面は、本発明を制限することなく、本発明の説明を完全なものにするだけではなく、一部の場合では本発明を定義することにも寄与する。
【発明を実施するための最良の形態】
【００２７】
本発明によって、ネットワーク管理システムは２つの主要なモジュールを含み、すなわち第１に診断モジュールＭＤと第２に修復モジュールＭＲとを含む。
【００２８】
診断モジュールへの入力は、カスタマの苦情ＣＣと、ネットワークからの情報Ａとから構成される。カスタマの苦情は、ネットワーク性能の低下、またはネットワークで使用されるサービスの低下によって誘発されてもよい。そうした苦情を受信すると、診断システムＭＤは、この苦情につながる技術的な原因を判定するために、診断検索を起動することができる。次いで、診断システムＭＤはネットワーク要素からの情報出力を利用することができる。
【００２９】
診断検索はまた、通信ネットワーク中の個々の要素（すなわち、存在するカスタマの苦情とは関係なく）からの情報出力によって起動されてもよい。
【００３０】
ネットワーク要素からの情報出力は、２つの主要な種類のものであってよい。
・警報、すなわちネットワーク要素によってネットワーク管理システムに送信される非同期の通知。要素によって異常が検出される場合、測定された値が所定の閾値に達する場合、またはより一般的には、その構成のための任意の種類のイベントが、オカレンスが警報を起動すべきであるというものである場合、これらの警報が送信される。したがって、これらの警報は、ソフトウェア、ハードウェアのどちらでも障害を示してもよい。
・警報は、ネットワーク管理システムＮＭＳに通知されていないが、ＮＭＳが管理情報ベース（ＭＩＢ）の中で見つけ出さなければならない構成または性能のデータに関連していてもよい。
・警報は、能動性テスト、能動性測定または受動性測定、および特にはエンドツーエンドの測定を設定するために必要とされてもよい。
【００３１】
特に警報の受信において、診断モジュールＭＤはこれらの警報が障害か、または起こりうる障害を表しているということを判定してもよい。次いで診断モジュールは、そのような判定の後に診断の判定、すなわち障害の検索を起動する。
【００３２】
上述のように、障害が起こった場合、障害のあったネットワーク要素からだけではなく、「隣接する」ネットワーク要素からも発せられた警報を誘発してもよい。診断の判定は、複数のネットワーク要素から発せられたこの１組の警報に基づき、障害のあったネットワーク要素を識別すること（トラブルシューティング）と、障害の種類（障害名）を識別することから構成される。一般に、診断は確定的であることは不可能であり、その後診断モジュールＭＤは最も見込みのある診断Ｄを提供し、それに確率値を関連付ける。診断モジュールＭＤはまた、各々が確率値に関連付けられ、各々が通信ネットワークＮ内の障害を識別する複数の診断のリストも提供することができる。
【００３３】
診断モジュールは、現状技術で知られているモジュールであってもよい。上述のようにニューラルネットワーク、エキスパートシステム、規則ベースのシステム等の様々な技術が使用されてもよい。上述の商品は使用されてもよい。
【００３４】
診断モジュールＭＤは、好ましくは２つの基準を遵守する。
・診断モジュールＭＤは「予防的（ｐｒｏａｃｔｉｖｅ）」でなければならず、すなわち診断検索は通信ネットワークからの警報Ａの受信以外によって起動されてもよい。特に、診断モジュールＭＤは、カスタマの苦情ＣＣか、または修復モジュールＭＲによって送信される診断要求（ＣＤ）のいずれかであってもよい外部のイベントによってこの検索を起動することが可能でなければならず、このことは後に説明される。
・診断モジュールＭＤは最も見込みのある診断を提供することが可能でなければならず、可能な場合には、それについての確率を添付することができなければならない。
【００３５】
この診断モジュールは好ましくはベイシアンネットワークを使用し、これはＡｌｃａｔｅｌ社によって製作された「５５３０−Ｎｅｔｗｏｒｋ Ａｎａｌｉｚｅｒ」に類似している。したがって、このモジュールの実装の動作は、「５５３０」製品の技術文書の中で説明されている。ベイシアンネットワークの技術、および診断の判定のためのその応用は、例えばＦ．Ｊｅｎｓｅｎによる著書「Ａｎ ｉｎｔｒｏｄｕｃｔｉｏｎ ｔｏ Ｂａｙｅｓｉａｎ Ｎｅｔｗｏｒｋｓ」、ＵＣＬ Ｐｒｅｓｓ、１９９６、または２００４年３月の第３回ネットワーキングについての国際会議でのＧｅｒａｒｄ Ｄｅｌｅｇｕｅ、Ｓｔｅｐｈａｎｅ Ｂｅｔｇｅ−Ｂｒｅｚｅｔｚ、Ｅｍｍａｎｕｅｌ Ｍａｒｉｌｌｙ ａｎｄ Ｏｌｉｖｉｅｒ Ｍａｒｔｉｎｏｔによる論文「ＩＰ ＶＰＮ Ｎｅｔｗｏｒｋ Ｄｉａｇｎｏｓｉｓ：Ｔｅｃｈｎｏｌｏｇｉｅｓ ａｎｄ Ｐｅｒｓｐｅｃｔｉｖｅｓ」の中で説明されている。
【００３６】
ベイシアンネットワークの原理は、証明および背景情報のさらなる要素を考慮に入れて仮定を精錬するための規則を定義する確率の理論を使用するので、したがって、仮定が真である確率の程度を表す数字につながる。
【００３７】
したがってベイシアンダイアグラムは、確率、および例えば他のものよりも時間を多く必要とするテストを定義するために使用されるコストに関連して行われるすべてのテスト行為を定義する。
【００３８】
図３は、極めて簡略化されたベイシアンダイアグラムの例を示す。この図は、「損失パケット」エンティティが複数のその他のエンティティ、「高ＣＰＵ利用」率、「インターフェースインステータス」（インタフェース入力ステータス）、「インタフェースアウトステータス」（インタフェース出力ステータス）に依存していることを示す。
【００３９】
したがって、このモデルによって、システムは最初に一連の原因を表し、それによってテストが実行されるべきものを示し、次に各々の見込みのある診断に対して確率値を算定し、最も見込みのある診断を判定することができる。
【００４０】
実際には、ベイシアンダイアグラムは明らかにもっと複雑であり、複数の階層レベルを含んでいるかもしれない。さらに、ネットワーク要素を形作るために、多くのダイアグラムが必要である。
【００４１】
診断Ｄは一旦判定されると、１つまたは複数のメッセージの形態で修復モジュールＭＲに送信される。例えば、これらのメッセージは、バージョン１のためのＲＦＣ１１５７およびバージョン２のためのＲＦＣ１５９２の中でＩＥＴＦ（インターネット技術特別調査委員会）によって定義されるＳＮＭＰ（シンプルネットワーク管理プロトコル）プロトコルを伴うコンプライアントであってもよい。
【００４２】
診断Ｄは単一のＳＮＭＰメッセージ（または「トラップ」）か、または複数のメッセージであってもよい。複数のメッセージが使用される場合、修復モジュールＭＲが同一の診断Ｄに関連するものを簡単に判定できるように、複数のメッセージは明確に識別されなければならない。１つの実施形態によって、第１メッセージは診断についての一般的な情報を含む一方で、次に続くメッセージは詳細な情報を含む。例えば、診断がＬＳＰ（ラベルスイッチングポイント）に関連している場合、第１メッセージはＬＳＰそのものについての診断情報を含んでよい一方で、その後のメッセージはＬＳＰが通過する機器（またはルータ）についての情報を含む。
【００４３】
この判定は、後に説明されるチケットを使用して行われてよく、すなわち同一の診断Ｄを運搬するすべてのＳＮＭＰメッセージは同一のチケットを有することになる。
【００４４】
しかしながらその他の実施形態が可能であり、特に２つのモジュールは、ＯＭＧ（オープン管理グループ）によって定義されたようなＣＯＲＢＡ（共通オブジェクトリクエストブローカアーキテクチャ）型のソフトウェアバスか、またはＭｉｃｒｏｓｏｆｔ社によるＣＯＭ／ＤＣＯＭを通じて通信してもよい。
【００４５】
このメッセージＤは、好ましくは以下の情報を含む。
・診断された障害のタイトル。例えば「インタフェースのダウン」「ＢＧＰ（ボーダゲートウェイプロトコル）構成の不良」等。
・障害の位置、すなわち関連するネットワーク要素、カード、インタフェース、仮想プライベートネットワーク（ＶＰＮ）等の識別子。
・確立された診断が考慮されなければならない信頼度を判定する確率値。
・チケット、すなわち所与の問題に対する正しい診断のための検索セッションを識別する数。上述のように、同一の診断が複数のメッセージによって運搬される場合、これらのメッセージの各々は、特に情報量が非常に多いことから同一のチケットを有することになる。
・所与のチケットに対する診断検索のオカレンスの数を識別するイテレーション数。複数のイテレーションが問題への解決法に達することを必要としてもよいように、問題は診断モジュールＭＤと修復モジュールＭＲとの間でループを作ることができることが後に明らかにされる。
【００４６】
以下の表は、ＳＮＭＰプロトコルに基づく実装の場合の「ＳＮＭＰトラップ」の例を示す。
【表１】
【００４７】
これらのＯＩＤファイル（ＳＮＭＰオブジェクト識別子）は、Ａｌｃａｔｅｌ識別子に対応する左の部分（１．３．６．１．４．１．６３７．）、アプリケーション（すなわち診断モジュールＭＤ）に対応する次の部分（４．）、および「ＳＮＭＰトラップ」中のフィールドに特有の属性に対応する最後の部分の３つの部分から構成されている。
【００４８】
診断Ｄを含むメッセージを受信すると、修復モジュールＤは１つまたは複数の修正行為を判定しようとする。
【００４９】
図２は修復モジュールＭＲの１つの可能な機能構造を示す。この構造は機能的なものなので、異なる実施形態が可能である。この実施形態によって、修復モジュールＭＲは主モジュールＭＰ、マンマシンインタフェースＩＨＭ、データベースＢおよび構成モジュールＭＣを含む。
【００５０】
診断Ｄは主モジュールＭＰによって受信され、その目的は修正行為を判定し、これらの修正行為に対応したコマンドを仲介モジュールＭＥＤに送信するか、または図示されていないネットワーク要素に直接送信することである。
【００５１】
したがって、判定は診断Ｄ、および診断Ｄに含まれている先に明らかにされた情報から行われる。しかしながら判定は、以下のようなその他の情報に依存するものであってもよい。
−内部論理、すなわち少なくとも１つの診断に基づいて修正行為を判定するための方針の特定の言語での公式定義。この内部論理はデータベースＢの中に記憶される。
−特にＩＨＭインタフェースおよび構成モジュールＭＣを使用してユーザによって判定され、データベースＢの中に（または場合によっては他の独立のデータベースの中に）記憶されるパラメータ。
−特に主モジュールＭＰによる提案に応じて、診断の生成の間にＩＨＭインタフェースを通じてユーザによって送信される情報。
【００５２】
本発明の１つの好ましい実施形態によって、内部論理は１組の規則の形態で公式に定義される。
【００５３】
これらの規則は、診断モジュールＭＤから受信されてもよい診断Ｄを修正行為に関連させるために使用される。これらの規則は、構成モジュールＭＣおよびＩＨＭインタフェースを通じてベースＢに入力されてもよい。
【００５４】
これらの規則は典型的には以下の形式すなわち、
ＩＦ ｐｒｅｍｉｓｅｓ ＴＨＥＮ ａｃｔｉｏｎｓ
で表現されてよく、ここでの「ｐｒｅｍｉｓｅｓ」は、行為が起動されるために満たされなければならない条件のリストである。このリストは、（ＡＮＤ論理オペレータによって）共同で互いに関連付けられているか、または（ＯＲ論理オペレータによって）分離的に互いに関連付けられた複数の条件を含んでもよい。
【００５５】
例えば、そのような規則は以下のように記述されてもよい。
○Ｉｆ（Ｒｏｕｔｅｒ＝Ａｌｃａｔｅｌ／１９２．１２８．１２．５２、Ｉｎｔｅｒｆａｃｅ＝ＦａｓｔＥｔｈｅｒｎｅｔ１／０）＆＆（（Ｉｔｅｒａｔｉｏｎ＝１）＜３）＆＆（Ｆａｉｌｕｒｅ＝ＩＮＴＥＲＦＡＣＥ＿ＤＯＷＮ）Ｔｈｅｎ（Ｅｘｅｃｕｔｅ Ｃｏｒｒｅｃｔｉｖｅ Ａｃｔｉｏｎ２）．
○Ｉｆ（Ｒｏｕｔｅｒ＝Ａｌｃａｔｅｌ／１９２．１２８．１２．５２、Ｉｎｔｅｒｆａｃｅ＝ＦａｓｔＥｔｈｅｒｎｅｔ１／０）＆＆（（Ｉｔｅｒａｔｉｏｎ＝１）＜３）＆＆（Ｆａｉｌｕｒｅ＝ＢＧＰ＿ＭＩＳＣＯＮＦＩＧＵＲＡＴＩＯＮ）Ｔｈｅｎ（Ｅｘｅｃｕｔｅ Ｃｏｒｒｅｃｔｉｖｅ Ａｃｔｉｏｎ３）．
○（Ｃｏｒｒｅｃｔｉｖｅ Ａｃｔｉｏｎ２）＝Ｐｕｔ（Ｒｏｕｔｅｒ＝Ｃｉｓｃｏ／１９２．１２８．１２．５２、Ｉｎｔｅｒｆａｃｅ＝ＦａｓｔＥｔｈｅｒｎｅｔ１／０）Ｉｎｔｅｒｆａｃｅ Ｕｐ．
○（Ｃｏｒｒｅｃｔｉｖｅ Ａｃｔｉｏｎ３）＝Ｃｏｎｆｉｇｕｒｅ（Ｒｏｕｔｅｒ＝Ａｌｃａｔｅｌ／１９２．１２８．１２．５２、 Ｉｎｔｅｒｆａｃｅ＝ＦａｓｔＥｔｈｅｒｎｅｔ１／０）Ｗｉｔｈ ＢＧＰ＿Ｃｏｎｆｉｇｕｒａｔｉｏｎ＿Ｓｃｒｉｐｔ＿１
【００５６】
修正行為が直接に、場合によっては仲介モジュールＭＥＤを通じて、通信ネットワークの要素に送信されることが可能であるのかどうか、またはそれらの有効性をオペレータが確認しなければならないのかどうかを明示するために、指標はこれらの規則の公式定義に関連しているか、またはパラメータの中でこれらの規則に関連していてもよい。オペレータが有効性を確認しなければならない場合、修正行為はスクリーン上に表示されるために、マンマシンインタフェースＩＨＭに送信される。これらの指標はマンマシンインタフェースＩＨＭを通じてオペレータにアクセスすることができる構成モジュールＭＣを使用して、ベースＢの中に記憶されてもよい。
【００５７】
これらの修正行為の他に、特に診断モジュールＭＤによって送信された診断Ｄに関する情報など、オペレータの決断を助けるためのその他の情報が表示されてもよい。
【００５８】
次にオペレータは、修復モジュールＭＲがコマンドＣをネットワーク要素に送信する前に、修復モジュールからの提案の有効性を確認することができる。
【００５９】
複数の修正行為が可能な状況では、ＩＨＭインタフェースはそれらをスクリーン上に表示することが可能であり、続いてユーザは最も適切と思われるものは何でも選択することができる。次いで、修復モジュールＭＲはオペレータによって選択された修正行為に対応するコマンドＣを、通信ネットワーク中の要素に送信する。
【００６０】
規則に基づいた好ましい実施形態以外の実施形態もまた可能である。
【００６１】
例えば、ベイシアンネットワークまたはニューラルネットワークが使用されることが可能である。ニューラルネットワークを使用することの利点はその学習能力、および不確かな状況の中で機能する能力である。例えば、ニューラルネットワークは、たとえ一定量の情報が失われている場合であっても、最も見込みのある修正行為を最も起こりうる障害に適用することができてもよい。しかしながらその問題点は、本願出願時に、通信ネットワークのオペレータがそうした技術を理解することの難しさである。
【００６２】
上述のように、コマンドＣは仲介モジュールＭＥＤを通じて通信ネットワークＮ中の要素に送信されてもよい。この仲介モジュールの目的は、修復モジュールＭＲによって一般言語で公式化されたコマンドＣを、通信ネットワーク中の様々な機器に特有のコマンド言語を伴う特有のコマンドＣ１、Ｃ２のコンプライアントに変換することである。
【００６３】
ゆえに図１の機器Ｎ１とＮ２とは、この通信ネットワークＮを不図示の別のネットワークに接続するために、例えばＩＰルータとメディアゲートウェイなどの異なる種類の機器であってもよい。機器はまた、同様の種類であるが異なる供給業者によって作られた機器であってもよい。いずれの場合でも、それらを構成するために使用されるコマンドは、その機器によって理解されるコマンド言語に適したものでなければならない。したがって、単一の一般コマンドＣ（例えば「インタフェースをオープンしなさい」等）は２種類の機器Ｎ１とＮ２とのための異なった特有のコマンドにつながり、これらの特有のコマンドの各々は機器に特有の言語、特にそれらのＣＬＩ（コマンドラインインタフェース）インタフェースに準拠している。
【００６４】
この仲介モジュールＭＥＤを製作するために、異なる製品および技術が使用されてもよい。
【００６５】
特に、方針規則に基づく管理構造（「方針に基づく管理」のためのＰＢＭ）が使用されてもよい。そのような構造は、例えば特許出願ＥＰ１３３５５２４号「Ｄｅｐｌｏｙｍｅｎｔ ｏｆ ｒｕｌｅｓ ｂｙ ａ ｓｅｒｖｉｃｅ ｍａｎａｇｅｍｅｎｔ ｄｅｖｉｃｅ ａｓ ａ ｆｕｎｃｔｉｏｎ ｏｆ ｉｎｆｏｒｍａｔｉｏｎ ｏｎ ｎｅｔｗｏｒｋ ｅｑｕｉｐｍｅｎｔ」、および特許出願ＥＰ１３８７５２６号「Ｒｕｌｅ−ｂａｓｅｄ ｎｅｔｗｏｒｋ ｍａｎａｇｅｍｅｎｔ ｓｙｓｔｅｍ ｃｏｍｐｒｉｓｉｎｇ ａｎ ｉｎｆｅｒｅｎｃｅ ｍｏｔｏｒ」で説明されている。
【００６６】
したがって、修正行為の判定によって、本発明による修復モジュールＭＲは通信ネットワークの修復を自動化することができ、またはオペレータの行為が求められる場合には半自動化することができる。
【００６７】
しかしながら、通信ネットワークの複雑な点は、修正行為の影響を完全に制御することは実質的に不可能であるということである。第１に（例えば診断が間違っていたため、または同じく修正行為が完全には適切ではなかったために）修復は問題を解決するのに効果的ではないことが判明する場合があり、第２に障害の実際の修復が新たな障害を生み出し得るという可能性もある。例えば第１の障害を修復する中で、以前は隔離されていたネットワーク要素へのトラフィックの伝達が可能にされ、そうなることで、これらのネットワーク要素の中で障害が識別されるかもしれない。
【００６８】
したがって出願人は、通信ネットワークへの不適当または望ましくない影響を最小化するというさらなる技術的問題を考慮した。このために、通信ネットワーク中の要素へのコマンドＣの送信の後、診断モジュールが新たな診断を判定できるように、診断要求ＣＤは診断モジュールＭＤに送信される。
【００６９】
この診断要求ＣＤは、この新たな診断（および任意のその後の診断）が同じチケットによって判定されたセッション内の第１診断に関連付けられるように、チケットの値を含んでもよい。
【００７０】
この診断モジュールＭＤへのループバックによって、診断モジュールは障害の修正を確認し、新たな障害が起こり得るかどうかを検出することができる。次いで、診断モジュールは修復モジュールＭＲその他を通じて、新たな修復作業を起動することができる。したがって、本発明のこの好ましい実施形態は、管理された通信ネットワーク上で行われる行為を制御するためのループを作るために使用されることが可能である。
【００７１】
しかしながらこの実施形態は、無限ループを作り出すというさらなる問題を生じさせるかもしれず、すなわち各修復は新たな障害を循環的に生み出すことになる。
【００７２】
これらの無限ループを防ぐために、イテレーションカウンタが使用されることが可能である。例えば、このイテレーションカウンタは新たな診断が起こされる度に増やされる。このイテレーションカウンタが所与の事前に定義された閾値に達するとき、ループは停止され、システムはＩＨＭインタフェースを通じてオペレータに解決法が見つからなかったことを通知することができる。
【００７３】
同様に当業者のために、カウンタはこの閾値で初期化され、新たな診断が起こされる度に減らされてもよい。そのときの停止基準は、このイテレーションカウンタが０を通過することである。
【００７４】
本発明の１つの実施形態によって、このイテレーションカウンタは修復モジュールの内部論理に影響を及ぼすことができる。例えば、この内部論理が１組の規則の形態で実施されるという状況では、これらの規則はイテレーションカウンタの値に依存してもよい。
【００７５】
オペレータは自分が定める制約の機能として、これらの従属関係を設定することができる。例えば、オペレータは重要ではないＬＳＰ上で（特に、後に説明されるように、結果として生じるコストがトラフィック最適化モジュールを起動するコストよりも低いために）、高いイテレーション閾値と関連することができる。大きなペナルティを伴うＬＳＡの存在する非常に重要なＬＳＰのために、イテレーション閾値は非常に低いものであることが可能であり、オペレータの主な目的は、トラフィック最適化モジュールが起動されなければならない場合でも、サービスを維持することである。
【００７６】
最終的に、診断が通信ネットワーク上で所与の時点の問題よりもより深刻な問題に関連する場合、このネットワーク構成に戻すためにバックトラッキング機構が使用されることが可能である。修復モジュールはこの目的のために、修正行為および／または送信されたコマンドおよび受信された診断の履歴を含む。閾値が到達されたときの新たな診断が、前のイテレーションの間のものよりも悪い場合、次いで修復モジュールはこのイテレーションに対応する状態にネットワークを戻すために、この履歴を使用することができる。次いで必要なものは、この前の状況を回復するために逆コマンドを送信することがすべてである。
【００７７】
障害が真に解決されない場合、この実施形態はネットワークの状態を改善するための妥協案を可能にする。
【００７８】
そのようなバックトラッキングの後、問題が解決されなかったこととネットワークの状況とをオペレータに通知するために、マンマシンインタフェースＩＨＭを通じてオペレータにメッセージが送信される。
【００７９】
その他の実施形態によって、診断モジュールが問題を解決できない場合、トラフィックエンジニアリングＴＥ最適化モジュールが使用されてもよい。このトラフィック最適化モジュールの目的は、真に問題を解決するのではなく、問題を回避するためにトラフィックを向け直すことである。ゆえに、問題がルータ内で解決されることが不可能な場合（例えばハードウェアの問題）、ＴＥモジュールは他のルータ上のルーティングテーブル、このルータを通過するＬＳＰなどを変更して、このルータにこれ以上トラフィックが送信されないようにすることができる。ゆえに、ネットワーク動作は問題となっている機器が動作不能のままであっても、完全に動作可能となってもよい。
【００８０】
要約すると、障害を識別する診断は、障害が修復されるか、または障害は修復されずオペレータに知らされるか、または障害は修復されないがトラフィック最適化ツールが起動されるか、または修復モジュールＭＲがバックトラッキング機能を使用してネットワークを「より」悪くない状態にしてオペレータに通知するかの４つの結論のうちの１つを有することができる。
【００８１】
図３は、本発明による方法におけるステップの実施を概略的に示す。
【００８２】
第１の「Ｄｉａｇ」ステップは、診断の判定を起動することから構成されている。このステップは、特に通信ネットワーク内の警報またはカスタマの苦情の受信後に起動される。
【００８３】
次いで、システムは診断が障害を識別するかどうかを判定する（枠「Ｐ？」）。障害がなければ方法は停止する（枠「Ｆ１」）。
【００８４】
障害がある場合、方法はいくつかの停止基準を判定することから構成される（「停止？」）。目的は、イテレーションの数が所定の閾値に到達したかどうか、または診断が、前のイテレーションの間に予め作成されていた診断に対応しているかどうかを判定することである。これらの停止基準が満たされる場合、システムは停止する（枠「Ｆ２」）。
【００８５】
停止基準が満たされない場合、方法は修正行為を判定することと、これらの修正行為に関連するコマンドを通信ネットワークに送信することから構成される「Ｒｅｐ」ステップを使用する。
【００８６】
本発明の１つの好ましい実施形態で、続いて新たな「Ｄｉａｇ」診断ステップが起動され、その後方法は上述の異なるステップおよびテストを通過する。
【００８７】
次いで方法は、「Ｐ？」テストの間の障害の解決、または「停止？」テストの間の停止基準の充足によって終了されることが可能な処理サイクルを形成する。
【００８８】
本発明および異なるステップの連鎖は、以下の３つの特定の例を読んだ後により明らかとなろう。
【００８９】
これらの例の各々で、診断モジュールは通信ネットワークからの警報の受信、またはカスタマの苦情によって動作に入る。
【００９０】
第１の例で、カスタマの苦情ＣＣ、または通信ネットワークから受信された警報Ａは、このネットワーク内の問題を示している。第１の診断は、ルータＹのインタフェースＸがダウンしていることを明らかにする。診断モジュールＭＤは、チケット値およびイテレーション値１とともに、この診断を修復モジュールに送信する。
【００９１】
次いで、修復モジュールＭＲはこの診断に関連した修正行為を判定する。この実施例の中で、修正行為はインタフェースＸをサービス（「アップ」）に戻すことである。この修正行為に関連する一般コマンドは、ルータＹに特有の言語での適切なコマンドを判定する仲介モジュールＭＥＤに送信される。
【００９２】
修復モジュールＭＲは診断要求ＣＤを診断モジュールＭＤに送信し、同じチケット値を特定する。
【００９３】
診断モジュールＭＤは通信ネットワークの診断を繰り返し、ルータＹのインタフェースＸが現在アップしており、ネットワークが通常に動作していることを判定する。次いで診断モジュールＭＤは、ネットワークが通常に動作していることを通知するために、診断Ｄを修復モジュールに送信することができる。次いで問題は解決されたので、修復モジュールＭＲはいかなる行為も起動することはなく、本発明による方法は終了する。
【００９４】
第２の例で、診断モジュールはまた、ルータＹのインタフェースＸがダウンしていることを判定する。第１の例と同様に、診断Ｄはチケットとともに修復モジュールに送信され、修復モジュールＭＲは修正行為を判定する。この修正行為に関連する一般コマンドは、このコマンドをルータＹの特定の言語を伴うコマンドコンプライアントに変換する仲介モジュールＭＥＤに送信される。
【００９５】
修復モジュールＭＲは、同じチケットとともに、診断要求ＣＤを診断モジュールＭＤに送信する。診断モジュールＭＤは新たな診断判定を開始する。新たな診断Ｄは、ルータＹのインタフェースＸが依然としてダウンしていることを判定する。この診断Ｄは、同じチケット値、および２に等しいイテレーション値とともに、修復モジュールＭＲに送信される。
【００９６】
修復モジュールＭＲは、イテレーションは２に等しいが、問題は同じままであるということを認めてもよい。次いで修復モジュールＭＲは、トラフィック最適化モジュールＴＥ（トラフィックエンジニアリング）にコマンドを送信することを決定してもよい。
【００９７】
次いで、このトラフィックエンジニアリングモジュールＴＥは、通信ネットワークの中の既存の経路を変更して、それらがルータＹのインタフェースＸを回避するようにすることが可能である。このように、問題となっているインタフェースがダウンしていても、通信ネットワークは通常通りに動作することが可能である。
【００９８】
第３の例で、診断モジュールＭＤはまた、ルータＹのインタフェースＸがダウンしていることを判定する。診断Ｄはチケット数および１に等しいイテレーション値とともに、修復モジュールに送信される。
【００９９】
上述のように、修復モジュールは、インタフェースＸがサービス（「アップ」）になるように、一般コマンドが、それをルータＹに特有の言語を伴うコマンドコンプライアントに変換する仲介モジュールＭＥＤに送信されることを判定する。
【０１００】
修復モジュールＭＲは、同じチケット数とともに、診断要求ＣＤを診断モジュールＭＤに送信する。
【０１０１】
次いで、診断モジュールは新たな診断判定を起動し、例えばＢＧＰ（ボーダゲートウェイプロトコル）の構成不良などの新たな問題が見つけ出される。この診断Ｄは、２に等しいイテレーション数、および同じチケット値とともに、修理モジュールに送信される。
【０１０２】
次いで修復モジュールＭＲは、この場合ＢＧＰプロトコルを再構成することであってもよい適切な修正行為を判定する。次いで一般コマンドは、このコマンドを特定のコマンドに変換する仲介モジュールＭＥＤに送信される。
【０１０３】
再び修復モジュールＭＲは診断モジュールＭＤに診断要求ＣＤを送信し、同じチケット数を特定する。新たな診断Ｄは、ルータＹの同じインタフェースＸがダウンしていることを示す。この診断Ｄは３に等しいイテレーション値、および依然として同じチケット値とともに、修復モジュールＭＲに送信される。
【０１０４】
修復モジュールは、イテレーション値が３に等しく、診断がイテレーションが１のときと同じであることを認めてもよい。次いで修復モジュールは、問題が解決できないことを判定し、この不可能性および診断についての情報を表すメッセージを表示するマンマシンインタフェースＩＨＭにコマンドを送信することができる。
【０１０５】
これらの実施例は本発明の異なる動作方式を示しており、特には、例えばオペレータに通知する、トラフィック最適化モジュールを起動する、修復コマンドを起動する等のために、規則ベースＢを構成することによって、本発明による修復モジュールＭＲを違った風に動作させることができるということを示している。
【図面の簡単な説明】
【０１０６】
【図１】本発明による管理システムを概略的に示す図である。
【図２】本発明の１つの実施形態による修復モジュールの内部構造を示す図である。
【図３】本発明による方法のステップの連鎖を示す図である。
【技術分野】
【０００１】
本発明は通信ネットワークに関し、限定されるわけではないが、特にはパケット志向の通信ネットワークに適用可能である。本発明は、より詳細には通信ネットワークの管理に関する。
【背景技術】
【０００２】
ネットワーク管理システム（ＮＭＳ）は、ネットワーク機器からの警報を収集し、特にはコリレーション方法を使用してこれらの警報の要約を作成し、この要約またはこれらの警報をオペレータに対して表示して、この機器のうちの１つまたは複数のアイテムに障害がある場合にオペレータが修正行為を実行できるようにするために、通信ネットワークに関連付けられることができることが知られている。「障害」の概念は、ハードウェアまたはソフトウェアの機能異常のうちのあらゆる種類のものを表す非常に広い意味で理解されなければならない。したがって、ネットワーク要素の誤った構成は障害であるとみなされることが可能であり（ソフトウェア）、同様に、テーブルをルーティングするＩＰルータにおけるエラー、または偶然閉じられてしまったポートも、障害であるとみなされることが可能である。
【０００３】
ネットワーク管理システムは、ネットワーク機器を構成するために使用されることも可能である。オペレータはマンマシンインタフェースを使用して新しいパラメータを入力することができ、ネットワーク管理システムはこれらの新しいパラメータを機器に適用する。このようにして、オペレータは警報の表示に対する反応の中で、ネットワーク障害を修正することができる。
【０００４】
そのような集中化された分析は、通信システムの中の多くの要素から大量のデータおよび警報を収集することに依存している。これらの要素はＩＰ（インターネットプロトコル）通信ネットワークのフレームワークにおけるルータなどの機器であってよいが、いわゆるＮＧＮ（次世代ネットワーク）における音声および光学スイッチ、ＰＡＢＸ（構内交換機）およびメディアゲートウェイ等に関連するものであることも可能である。ネットワーク要素はまた、例えばカードなど、そうした機器の一部を形成してもよい。
【０００５】
ネットワークの要素の間の多くの相互作用のために、単一の障害が非常に多くの数の警報を生成する可能性がある。したがって、機器のアイテム中のカード上の障害は、このカード上のポートの１つに接続された他の機器中のすべてのカードからの警報と、障害が起こった機器のカードによる警報とを生成することもある。
【０００６】
したがってオペレータにとっては、多数の生成された警報の中でどれが本当の障害であるのかを判定することは困難なので、行われるべき修正行為を判定することはさらに困難である。
【０００７】
最もありそうな原因を判定するために、この多数の警報を使用する診断システムによって、進歩がなされた。
【０００８】
これらの診断システムは例えば、Ｉｌｏｇ社によって売り出されているＩｌｏｇＲｕｌｅｓ（商標）製品に基づく規則などの、規則の組に基づいている。これらの診断システムはまた、ニューラルネットワーク、ベイシアンネットワーク、エキスパートシステム、または特には人工知能などのその他の技術に基づいていてもよい。
【０００９】
言及に値するいくつかの製品は、Ａｇｉｌｅｎｔ社の「Ｆａｕｌｔ Ｄｅｔｅｃｔｉｖｅ ｆｏｒ Ｄａｔａ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ（ＦＤＤＣ）」、Ｈｅｗｌｅｔｔ−Ｐａｃｋａｒｄの「Ｎｅｔｗｏｒｋ Ｎｏｄｅ Ｍａｎａｇｅｒ」および「Ｎｅｔｗｏｒｋ Ｎｏｄｅ Ｍａｎａｇｅｒ Ｅｘｔｅｎｄｅｄ Ｔｏｐｏｌｏｇｙ」製品、ならびにＣｉｓｃｏ社の「Ｏｕｔｐｕｔ Ｉｎｔｅｒｐｒｅｔｅｒ」および「Ｔｒｏｕｂｌｅｓｈｏｏｔｉｎｇ Ａｓｓｉｓｔａｎｔ（ＴＡＣ）」製品である。
【００１０】
それでもやはり、オペレータは行われるべき修正行為を判定し、その行為を起こすために、これらのツールを用いて各障害に対して処置を施さなければならない。その後、オペレータはネットワーク管理システムを使用してネットワークを再構成するか、または機器のアイテムのうちの１つまたは複数に手動で接続し、適切なＣＬＩ（コマンド行インタフェース）コマンドを送信する必要がある。
【００１１】
この作業は現状技術の診断システムによって補助されるが、依然として難しいものであり、したがって費用がかかり、エラーを起こしやすい。
【００１２】
実際、再構成と機器フェーズへの手動接続とは時間がかかり、退屈なものである。これらの作業はＣＬＩコマンドのパラメータの中で間違いを起こしやすいので、別のネットワーク障害を引き起こしやすい。
【００１３】
オペレータは最適な行為を求める場合、ネットワークの性能情報およびその他のパラメータを考慮に入れなければならないので、修正行為のフェーズを判定することはオペレータにとって実に難しいことである。
【００１４】
これらの作業は、増加したネットワークの複雑性、利用可能な機器タイプの数およびそれらの複雑性のために、さらに一層難しく、費用がかかるようになる。
【００１５】
診断の判定によって通信ネットワーク機器の構成を自動化する解決法が利用可能である。そのような解決法は、例えばインテリジェントエージェントおよびマルチエージェント技術の実用アプリケーションについての国際会議紀要において１９９６年４月２２日に発表されたＭｅｒｃｅｄｅｓ Ｇａｒｉｊｏ、Ａｎｄｒｅｓ Ｃａｎｃｅｒ、Ｊｕｌｉｏ Ｊ．Ｓａｎｃｈｅｚの「Ａ Ｍｕｌｔｉａｇｅｎｔ Ｓｙｓｔｅｍ ｆｏｒ Ｃｏｏｐｅｒａｔｉｖｅ Ｎｅｔｗｏｒｋ−Ｆａｕｌｔ Ｍａｎａｇｅｍｅｎｔ」で説明されており、北京で開催されたＩＥＥＥ国際会議「システム、人間およびサイバネティクス」で１９９６年１０月に発表されたＪｉａｎｎ−Ｌｉａｎｇ Ｃｈｅｎ、Ｐｅｉ−Ｈｗａ Ｈｕａｎｇの「Ａ Ｆｕｚｚｙ Ｅｘｐｅｒｔ Ｓｙｓｔｅｍ ｆｏｒ Ｎｅｔｗｏｒｋ Ｆａｕｌｔ Ｍａｎａｇｅｍｅｎｔ」でも説明されている。
【００１６】
しかしながらこれらのシステムは、検出された問題点を修正行為が実際に修正したことを確認するいかなる方法も含んでいない。さらに、これらのシステムを用いることで、これらの修正行為が状況を悪化させていないということが確信されることは不可能である。これらの文献の中で、この問題は言及さえされていない。
【発明の開示】
【発明が解決しようとする課題】
【００１７】
本発明の目的は、検出された問題が修正されることを保証するか、または少なくとも遠距離通信ネットワークの全般的な状況が改善されることを保証しながら、管理された通信ネットワークにおいて障害の修正を自動化することである。
【課題を解決するための手段】
【００１８】
このことを達成するために、本発明の第１の目的は、通信ネットワークの中の要素によって提供される情報を利用して診断を判定することができる診断モジュールを含む通信ネットワークの管理のためのシステムである。この診断は、通信ネットワーク内の障害を識別する。この管理システムは、
−診断モジュールから受信された診断に基づいて、１つまたは複数の修正行為を判定し、
−障害を修正するために、修正行為に対応する１つまたは複数のコマンドを通信ネットワークの中の１つまたは複数の要素に送信し、
−診断モジュールによる新たな診断の判定を開始するために、診断要求を診断モジュールに送信するように設計された修復モジュールもまた含むことを特徴とする。
【００１９】
本発明の実施形態によって、管理システムは以下の特徴を１つずつ、または組み合わせて有してもよい。
−イテレーションカウンタ（ｉｔｅｒａｔｉｏｎ ｃｏｕｎｔｅｒ）は新たな診断が開始される度に増やされ、管理システムはイテレーションカウンタが所定の閾値に達するとき、診断および修復モジュールを停止する。
−コマンドは、一般言語で公式化されたコマンドを、通信ネットワーク中の異なる機器に特有のコマンド言語を伴う特有のコマンドコンプライアント（ｃｏｍｐｌｉａｎｔ）に変換することができる仲介モジュールを通じて送信される。
−修復モジュールは、障害を修正するために修正行為が十分に判定されることが不可能な場合に、通信ネットワークの動作においてこの障害の影響を取り除くか、または制限するために、トラフィック最適化モジュールと通信するように配置される。
−診断モジュールは、診断を判定するためにベイシアンネットワークを使用する。
−診断は少なくとも障害の説明、障害の位置を含み、場合によっては診断に関連した起こりうる事態の予想を含む。
−診断モジュールは、診断を含むＳＮＭＰプロトコルを備えたメッセージコンプライアントを修復モジュールに送信する。
−修復モジュールは修復規則のベースを有する。
−規則はイテレーションカウンタに依存してもよい。
−修復モジュールは、各イテレーションで判定された診断履歴と修正行為履歴とを有し、診断が、閾値が到達されるときに所与のイテレーションの間のものと同様に適切ではない場合、通信ネットワークをこの所与のイテレーションの間の状態に戻すことができる。
【００２０】
本発明の第２の目的は、通信ネットワークの要素によって提供される情報に基づき診断を判定するための第１ステップを含む通信ネットワークの管理のための方法である。この方法は、診断が障害を識別する場合、障害を修正するために、少なくとも診断に基づいて１つまたは複数の修正行為を判定し、通信ネットワークの１つまたは複数の要素に、これまたはこれらの修正行為に対応する１つまたは複数のコマンド（Ｃ）を送信する第２ステップも含み、処理サイクルを形成するために、第２ステップの終了時に第１ステップが自動的に開始されることを特徴とする。
【００２１】
本発明の実施形態によって、管理方法は以下の特徴を１つずつか、または組み合わせて含んでもよい。
−イテレーションカウンタは新たな診断が起こされる度に増やされ、このイテレーションカウンタが所定の閾値に達するとき、処理サイクルは中断される。
−コマンドは、一般言語で公式化されたコマンドを、通信ネットワーク中の異なる機器に特有のコマンド言語を伴う特有のコマンドコンプライアントに変換することができる仲介モジュールを通じて送信される。
−コマンドは、障害を十分に修正するために修正行為が判定されることが不可能な場合、通信ネットワークの動作においてこの障害の影響を取り除くか、または制限するために、トラフィック最適化モジュールに送信されてもよい。
−第１ステップは、診断を判定するためにベイシアンネットワークを使用する。
−診断は少なくとも障害の説明、障害の位置を含み、場合によっては診断に関連して起こりうる事態の予想を含む。
−各イテレーションで判定された診断履歴および修正行為履歴が構築され、診断が、閾値が到達されるときにこの前のイテレーションの間のものと同様に適切ではない場合、この前のイテレーションの間の通信ネットワークの状態が回復される。
【００２２】
したがって本発明により、修復モジュールは障害の影響を制限するために、および特には通信ネットワーク上のＳＬＡ（サービスレベル契約）設定へのそれらの影響を制限するために、通信障害を自動的に修復すること、および／または修正行為を行うことが可能であるか、またはオペレータによる動作確認の後で、これらの修復を半自動化することが可能である。
【００２３】
修正の後、診断モジュールは、この修復が新たな障害を生成していないことを保証するため、およびもし障害を生成していれば、それらを順次修正するために、新たな診断を行うことを求められる。したがって、診断された障害を修復することに集中しなければならない処理サイクルが実施されてもよい。
【００２４】
閾値は極端に長い修復ループを防ぐために、ループ内のイテレーションの数に対して固定されてもよい。
【００２５】
本発明ならびにその特徴および利点は、添付の図面を参照して以下の説明を読んだ後により明らかとなろう。
【００２６】
これらの添付の図面は、本発明を制限することなく、本発明の説明を完全なものにするだけではなく、一部の場合では本発明を定義することにも寄与する。
【発明を実施するための最良の形態】
【００２７】
本発明によって、ネットワーク管理システムは２つの主要なモジュールを含み、すなわち第１に診断モジュールＭＤと第２に修復モジュールＭＲとを含む。
【００２８】
診断モジュールへの入力は、カスタマの苦情ＣＣと、ネットワークからの情報Ａとから構成される。カスタマの苦情は、ネットワーク性能の低下、またはネットワークで使用されるサービスの低下によって誘発されてもよい。そうした苦情を受信すると、診断システムＭＤは、この苦情につながる技術的な原因を判定するために、診断検索を起動することができる。次いで、診断システムＭＤはネットワーク要素からの情報出力を利用することができる。
【００２９】
診断検索はまた、通信ネットワーク中の個々の要素（すなわち、存在するカスタマの苦情とは関係なく）からの情報出力によって起動されてもよい。
【００３０】
ネットワーク要素からの情報出力は、２つの主要な種類のものであってよい。
・警報、すなわちネットワーク要素によってネットワーク管理システムに送信される非同期の通知。要素によって異常が検出される場合、測定された値が所定の閾値に達する場合、またはより一般的には、その構成のための任意の種類のイベントが、オカレンスが警報を起動すべきであるというものである場合、これらの警報が送信される。したがって、これらの警報は、ソフトウェア、ハードウェアのどちらでも障害を示してもよい。
・警報は、ネットワーク管理システムＮＭＳに通知されていないが、ＮＭＳが管理情報ベース（ＭＩＢ）の中で見つけ出さなければならない構成または性能のデータに関連していてもよい。
・警報は、能動性テスト、能動性測定または受動性測定、および特にはエンドツーエンドの測定を設定するために必要とされてもよい。
【００３１】
特に警報の受信において、診断モジュールＭＤはこれらの警報が障害か、または起こりうる障害を表しているということを判定してもよい。次いで診断モジュールは、そのような判定の後に診断の判定、すなわち障害の検索を起動する。
【００３２】
上述のように、障害が起こった場合、障害のあったネットワーク要素からだけではなく、「隣接する」ネットワーク要素からも発せられた警報を誘発してもよい。診断の判定は、複数のネットワーク要素から発せられたこの１組の警報に基づき、障害のあったネットワーク要素を識別すること（トラブルシューティング）と、障害の種類（障害名）を識別することから構成される。一般に、診断は確定的であることは不可能であり、その後診断モジュールＭＤは最も見込みのある診断Ｄを提供し、それに確率値を関連付ける。診断モジュールＭＤはまた、各々が確率値に関連付けられ、各々が通信ネットワークＮ内の障害を識別する複数の診断のリストも提供することができる。
【００３３】
診断モジュールは、現状技術で知られているモジュールであってもよい。上述のようにニューラルネットワーク、エキスパートシステム、規則ベースのシステム等の様々な技術が使用されてもよい。上述の商品は使用されてもよい。
【００３４】
診断モジュールＭＤは、好ましくは２つの基準を遵守する。
・診断モジュールＭＤは「予防的（ｐｒｏａｃｔｉｖｅ）」でなければならず、すなわち診断検索は通信ネットワークからの警報Ａの受信以外によって起動されてもよい。特に、診断モジュールＭＤは、カスタマの苦情ＣＣか、または修復モジュールＭＲによって送信される診断要求（ＣＤ）のいずれかであってもよい外部のイベントによってこの検索を起動することが可能でなければならず、このことは後に説明される。
・診断モジュールＭＤは最も見込みのある診断を提供することが可能でなければならず、可能な場合には、それについての確率を添付することができなければならない。
【００３５】
この診断モジュールは好ましくはベイシアンネットワークを使用し、これはＡｌｃａｔｅｌ社によって製作された「５５３０−Ｎｅｔｗｏｒｋ Ａｎａｌｉｚｅｒ」に類似している。したがって、このモジュールの実装の動作は、「５５３０」製品の技術文書の中で説明されている。ベイシアンネットワークの技術、および診断の判定のためのその応用は、例えばＦ．Ｊｅｎｓｅｎによる著書「Ａｎ ｉｎｔｒｏｄｕｃｔｉｏｎ ｔｏ Ｂａｙｅｓｉａｎ Ｎｅｔｗｏｒｋｓ」、ＵＣＬ Ｐｒｅｓｓ、１９９６、または２００４年３月の第３回ネットワーキングについての国際会議でのＧｅｒａｒｄ Ｄｅｌｅｇｕｅ、Ｓｔｅｐｈａｎｅ Ｂｅｔｇｅ−Ｂｒｅｚｅｔｚ、Ｅｍｍａｎｕｅｌ Ｍａｒｉｌｌｙ ａｎｄ Ｏｌｉｖｉｅｒ Ｍａｒｔｉｎｏｔによる論文「ＩＰ ＶＰＮ Ｎｅｔｗｏｒｋ Ｄｉａｇｎｏｓｉｓ：Ｔｅｃｈｎｏｌｏｇｉｅｓ ａｎｄ Ｐｅｒｓｐｅｃｔｉｖｅｓ」の中で説明されている。
【００３６】
ベイシアンネットワークの原理は、証明および背景情報のさらなる要素を考慮に入れて仮定を精錬するための規則を定義する確率の理論を使用するので、したがって、仮定が真である確率の程度を表す数字につながる。
【００３７】
したがってベイシアンダイアグラムは、確率、および例えば他のものよりも時間を多く必要とするテストを定義するために使用されるコストに関連して行われるすべてのテスト行為を定義する。
【００３８】
図３は、極めて簡略化されたベイシアンダイアグラムの例を示す。この図は、「損失パケット」エンティティが複数のその他のエンティティ、「高ＣＰＵ利用」率、「インターフェースインステータス」（インタフェース入力ステータス）、「インタフェースアウトステータス」（インタフェース出力ステータス）に依存していることを示す。
【００３９】
したがって、このモデルによって、システムは最初に一連の原因を表し、それによってテストが実行されるべきものを示し、次に各々の見込みのある診断に対して確率値を算定し、最も見込みのある診断を判定することができる。
【００４０】
実際には、ベイシアンダイアグラムは明らかにもっと複雑であり、複数の階層レベルを含んでいるかもしれない。さらに、ネットワーク要素を形作るために、多くのダイアグラムが必要である。
【００４１】
診断Ｄは一旦判定されると、１つまたは複数のメッセージの形態で修復モジュールＭＲに送信される。例えば、これらのメッセージは、バージョン１のためのＲＦＣ１１５７およびバージョン２のためのＲＦＣ１５９２の中でＩＥＴＦ（インターネット技術特別調査委員会）によって定義されるＳＮＭＰ（シンプルネットワーク管理プロトコル）プロトコルを伴うコンプライアントであってもよい。
【００４２】
診断Ｄは単一のＳＮＭＰメッセージ（または「トラップ」）か、または複数のメッセージであってもよい。複数のメッセージが使用される場合、修復モジュールＭＲが同一の診断Ｄに関連するものを簡単に判定できるように、複数のメッセージは明確に識別されなければならない。１つの実施形態によって、第１メッセージは診断についての一般的な情報を含む一方で、次に続くメッセージは詳細な情報を含む。例えば、診断がＬＳＰ（ラベルスイッチングポイント）に関連している場合、第１メッセージはＬＳＰそのものについての診断情報を含んでよい一方で、その後のメッセージはＬＳＰが通過する機器（またはルータ）についての情報を含む。
【００４３】
この判定は、後に説明されるチケットを使用して行われてよく、すなわち同一の診断Ｄを運搬するすべてのＳＮＭＰメッセージは同一のチケットを有することになる。
【００４４】
しかしながらその他の実施形態が可能であり、特に２つのモジュールは、ＯＭＧ（オープン管理グループ）によって定義されたようなＣＯＲＢＡ（共通オブジェクトリクエストブローカアーキテクチャ）型のソフトウェアバスか、またはＭｉｃｒｏｓｏｆｔ社によるＣＯＭ／ＤＣＯＭを通じて通信してもよい。
【００４５】
このメッセージＤは、好ましくは以下の情報を含む。
・診断された障害のタイトル。例えば「インタフェースのダウン」「ＢＧＰ（ボーダゲートウェイプロトコル）構成の不良」等。
・障害の位置、すなわち関連するネットワーク要素、カード、インタフェース、仮想プライベートネットワーク（ＶＰＮ）等の識別子。
・確立された診断が考慮されなければならない信頼度を判定する確率値。
・チケット、すなわち所与の問題に対する正しい診断のための検索セッションを識別する数。上述のように、同一の診断が複数のメッセージによって運搬される場合、これらのメッセージの各々は、特に情報量が非常に多いことから同一のチケットを有することになる。
・所与のチケットに対する診断検索のオカレンスの数を識別するイテレーション数。複数のイテレーションが問題への解決法に達することを必要としてもよいように、問題は診断モジュールＭＤと修復モジュールＭＲとの間でループを作ることができることが後に明らかにされる。
【００４６】
以下の表は、ＳＮＭＰプロトコルに基づく実装の場合の「ＳＮＭＰトラップ」の例を示す。
【表１】
【００４７】
これらのＯＩＤファイル（ＳＮＭＰオブジェクト識別子）は、Ａｌｃａｔｅｌ識別子に対応する左の部分（１．３．６．１．４．１．６３７．）、アプリケーション（すなわち診断モジュールＭＤ）に対応する次の部分（４．）、および「ＳＮＭＰトラップ」中のフィールドに特有の属性に対応する最後の部分の３つの部分から構成されている。
【００４８】
診断Ｄを含むメッセージを受信すると、修復モジュールＤは１つまたは複数の修正行為を判定しようとする。
【００４９】
図２は修復モジュールＭＲの１つの可能な機能構造を示す。この構造は機能的なものなので、異なる実施形態が可能である。この実施形態によって、修復モジュールＭＲは主モジュールＭＰ、マンマシンインタフェースＩＨＭ、データベースＢおよび構成モジュールＭＣを含む。
【００５０】
診断Ｄは主モジュールＭＰによって受信され、その目的は修正行為を判定し、これらの修正行為に対応したコマンドを仲介モジュールＭＥＤに送信するか、または図示されていないネットワーク要素に直接送信することである。
【００５１】
したがって、判定は診断Ｄ、および診断Ｄに含まれている先に明らかにされた情報から行われる。しかしながら判定は、以下のようなその他の情報に依存するものであってもよい。
−内部論理、すなわち少なくとも１つの診断に基づいて修正行為を判定するための方針の特定の言語での公式定義。この内部論理はデータベースＢの中に記憶される。
−特にＩＨＭインタフェースおよび構成モジュールＭＣを使用してユーザによって判定され、データベースＢの中に（または場合によっては他の独立のデータベースの中に）記憶されるパラメータ。
−特に主モジュールＭＰによる提案に応じて、診断の生成の間にＩＨＭインタフェースを通じてユーザによって送信される情報。
【００５２】
本発明の１つの好ましい実施形態によって、内部論理は１組の規則の形態で公式に定義される。
【００５３】
これらの規則は、診断モジュールＭＤから受信されてもよい診断Ｄを修正行為に関連させるために使用される。これらの規則は、構成モジュールＭＣおよびＩＨＭインタフェースを通じてベースＢに入力されてもよい。
【００５４】
これらの規則は典型的には以下の形式すなわち、
ＩＦ ｐｒｅｍｉｓｅｓ ＴＨＥＮ ａｃｔｉｏｎｓ
で表現されてよく、ここでの「ｐｒｅｍｉｓｅｓ」は、行為が起動されるために満たされなければならない条件のリストである。このリストは、（ＡＮＤ論理オペレータによって）共同で互いに関連付けられているか、または（ＯＲ論理オペレータによって）分離的に互いに関連付けられた複数の条件を含んでもよい。
【００５５】
例えば、そのような規則は以下のように記述されてもよい。
○Ｉｆ（Ｒｏｕｔｅｒ＝Ａｌｃａｔｅｌ／１９２．１２８．１２．５２、Ｉｎｔｅｒｆａｃｅ＝ＦａｓｔＥｔｈｅｒｎｅｔ１／０）＆＆（（Ｉｔｅｒａｔｉｏｎ＝１）＜３）＆＆（Ｆａｉｌｕｒｅ＝ＩＮＴＥＲＦＡＣＥ＿ＤＯＷＮ）Ｔｈｅｎ（Ｅｘｅｃｕｔｅ Ｃｏｒｒｅｃｔｉｖｅ Ａｃｔｉｏｎ２）．
○Ｉｆ（Ｒｏｕｔｅｒ＝Ａｌｃａｔｅｌ／１９２．１２８．１２．５２、Ｉｎｔｅｒｆａｃｅ＝ＦａｓｔＥｔｈｅｒｎｅｔ１／０）＆＆（（Ｉｔｅｒａｔｉｏｎ＝１）＜３）＆＆（Ｆａｉｌｕｒｅ＝ＢＧＰ＿ＭＩＳＣＯＮＦＩＧＵＲＡＴＩＯＮ）Ｔｈｅｎ（Ｅｘｅｃｕｔｅ Ｃｏｒｒｅｃｔｉｖｅ Ａｃｔｉｏｎ３）．
○（Ｃｏｒｒｅｃｔｉｖｅ Ａｃｔｉｏｎ２）＝Ｐｕｔ（Ｒｏｕｔｅｒ＝Ｃｉｓｃｏ／１９２．１２８．１２．５２、Ｉｎｔｅｒｆａｃｅ＝ＦａｓｔＥｔｈｅｒｎｅｔ１／０）Ｉｎｔｅｒｆａｃｅ Ｕｐ．
○（Ｃｏｒｒｅｃｔｉｖｅ Ａｃｔｉｏｎ３）＝Ｃｏｎｆｉｇｕｒｅ（Ｒｏｕｔｅｒ＝Ａｌｃａｔｅｌ／１９２．１２８．１２．５２、 Ｉｎｔｅｒｆａｃｅ＝ＦａｓｔＥｔｈｅｒｎｅｔ１／０）Ｗｉｔｈ ＢＧＰ＿Ｃｏｎｆｉｇｕｒａｔｉｏｎ＿Ｓｃｒｉｐｔ＿１
【００５６】
修正行為が直接に、場合によっては仲介モジュールＭＥＤを通じて、通信ネットワークの要素に送信されることが可能であるのかどうか、またはそれらの有効性をオペレータが確認しなければならないのかどうかを明示するために、指標はこれらの規則の公式定義に関連しているか、またはパラメータの中でこれらの規則に関連していてもよい。オペレータが有効性を確認しなければならない場合、修正行為はスクリーン上に表示されるために、マンマシンインタフェースＩＨＭに送信される。これらの指標はマンマシンインタフェースＩＨＭを通じてオペレータにアクセスすることができる構成モジュールＭＣを使用して、ベースＢの中に記憶されてもよい。
【００５７】
これらの修正行為の他に、特に診断モジュールＭＤによって送信された診断Ｄに関する情報など、オペレータの決断を助けるためのその他の情報が表示されてもよい。
【００５８】
次にオペレータは、修復モジュールＭＲがコマンドＣをネットワーク要素に送信する前に、修復モジュールからの提案の有効性を確認することができる。
【００５９】
複数の修正行為が可能な状況では、ＩＨＭインタフェースはそれらをスクリーン上に表示することが可能であり、続いてユーザは最も適切と思われるものは何でも選択することができる。次いで、修復モジュールＭＲはオペレータによって選択された修正行為に対応するコマンドＣを、通信ネットワーク中の要素に送信する。
【００６０】
規則に基づいた好ましい実施形態以外の実施形態もまた可能である。
【００６１】
例えば、ベイシアンネットワークまたはニューラルネットワークが使用されることが可能である。ニューラルネットワークを使用することの利点はその学習能力、および不確かな状況の中で機能する能力である。例えば、ニューラルネットワークは、たとえ一定量の情報が失われている場合であっても、最も見込みのある修正行為を最も起こりうる障害に適用することができてもよい。しかしながらその問題点は、本願出願時に、通信ネットワークのオペレータがそうした技術を理解することの難しさである。
【００６２】
上述のように、コマンドＣは仲介モジュールＭＥＤを通じて通信ネットワークＮ中の要素に送信されてもよい。この仲介モジュールの目的は、修復モジュールＭＲによって一般言語で公式化されたコマンドＣを、通信ネットワーク中の様々な機器に特有のコマンド言語を伴う特有のコマンドＣ１、Ｃ２のコンプライアントに変換することである。
【００６３】
ゆえに図１の機器Ｎ１とＮ２とは、この通信ネットワークＮを不図示の別のネットワークに接続するために、例えばＩＰルータとメディアゲートウェイなどの異なる種類の機器であってもよい。機器はまた、同様の種類であるが異なる供給業者によって作られた機器であってもよい。いずれの場合でも、それらを構成するために使用されるコマンドは、その機器によって理解されるコマンド言語に適したものでなければならない。したがって、単一の一般コマンドＣ（例えば「インタフェースをオープンしなさい」等）は２種類の機器Ｎ１とＮ２とのための異なった特有のコマンドにつながり、これらの特有のコマンドの各々は機器に特有の言語、特にそれらのＣＬＩ（コマンドラインインタフェース）インタフェースに準拠している。
【００６４】
この仲介モジュールＭＥＤを製作するために、異なる製品および技術が使用されてもよい。
【００６５】
特に、方針規則に基づく管理構造（「方針に基づく管理」のためのＰＢＭ）が使用されてもよい。そのような構造は、例えば特許出願ＥＰ１３３５５２４号「Ｄｅｐｌｏｙｍｅｎｔ ｏｆ ｒｕｌｅｓ ｂｙ ａ ｓｅｒｖｉｃｅ ｍａｎａｇｅｍｅｎｔ ｄｅｖｉｃｅ ａｓ ａ ｆｕｎｃｔｉｏｎ ｏｆ ｉｎｆｏｒｍａｔｉｏｎ ｏｎ ｎｅｔｗｏｒｋ ｅｑｕｉｐｍｅｎｔ」、および特許出願ＥＰ１３８７５２６号「Ｒｕｌｅ−ｂａｓｅｄ ｎｅｔｗｏｒｋ ｍａｎａｇｅｍｅｎｔ ｓｙｓｔｅｍ ｃｏｍｐｒｉｓｉｎｇ ａｎ ｉｎｆｅｒｅｎｃｅ ｍｏｔｏｒ」で説明されている。
【００６６】
したがって、修正行為の判定によって、本発明による修復モジュールＭＲは通信ネットワークの修復を自動化することができ、またはオペレータの行為が求められる場合には半自動化することができる。
【００６７】
しかしながら、通信ネットワークの複雑な点は、修正行為の影響を完全に制御することは実質的に不可能であるということである。第１に（例えば診断が間違っていたため、または同じく修正行為が完全には適切ではなかったために）修復は問題を解決するのに効果的ではないことが判明する場合があり、第２に障害の実際の修復が新たな障害を生み出し得るという可能性もある。例えば第１の障害を修復する中で、以前は隔離されていたネットワーク要素へのトラフィックの伝達が可能にされ、そうなることで、これらのネットワーク要素の中で障害が識別されるかもしれない。
【００６８】
したがって出願人は、通信ネットワークへの不適当または望ましくない影響を最小化するというさらなる技術的問題を考慮した。このために、通信ネットワーク中の要素へのコマンドＣの送信の後、診断モジュールが新たな診断を判定できるように、診断要求ＣＤは診断モジュールＭＤに送信される。
【００６９】
この診断要求ＣＤは、この新たな診断（および任意のその後の診断）が同じチケットによって判定されたセッション内の第１診断に関連付けられるように、チケットの値を含んでもよい。
【００７０】
この診断モジュールＭＤへのループバックによって、診断モジュールは障害の修正を確認し、新たな障害が起こり得るかどうかを検出することができる。次いで、診断モジュールは修復モジュールＭＲその他を通じて、新たな修復作業を起動することができる。したがって、本発明のこの好ましい実施形態は、管理された通信ネットワーク上で行われる行為を制御するためのループを作るために使用されることが可能である。
【００７１】
しかしながらこの実施形態は、無限ループを作り出すというさらなる問題を生じさせるかもしれず、すなわち各修復は新たな障害を循環的に生み出すことになる。
【００７２】
これらの無限ループを防ぐために、イテレーションカウンタが使用されることが可能である。例えば、このイテレーションカウンタは新たな診断が起こされる度に増やされる。このイテレーションカウンタが所与の事前に定義された閾値に達するとき、ループは停止され、システムはＩＨＭインタフェースを通じてオペレータに解決法が見つからなかったことを通知することができる。
【００７３】
同様に当業者のために、カウンタはこの閾値で初期化され、新たな診断が起こされる度に減らされてもよい。そのときの停止基準は、このイテレーションカウンタが０を通過することである。
【００７４】
本発明の１つの実施形態によって、このイテレーションカウンタは修復モジュールの内部論理に影響を及ぼすことができる。例えば、この内部論理が１組の規則の形態で実施されるという状況では、これらの規則はイテレーションカウンタの値に依存してもよい。
【００７５】
オペレータは自分が定める制約の機能として、これらの従属関係を設定することができる。例えば、オペレータは重要ではないＬＳＰ上で（特に、後に説明されるように、結果として生じるコストがトラフィック最適化モジュールを起動するコストよりも低いために）、高いイテレーション閾値と関連することができる。大きなペナルティを伴うＬＳＡの存在する非常に重要なＬＳＰのために、イテレーション閾値は非常に低いものであることが可能であり、オペレータの主な目的は、トラフィック最適化モジュールが起動されなければならない場合でも、サービスを維持することである。
【００７６】
最終的に、診断が通信ネットワーク上で所与の時点の問題よりもより深刻な問題に関連する場合、このネットワーク構成に戻すためにバックトラッキング機構が使用されることが可能である。修復モジュールはこの目的のために、修正行為および／または送信されたコマンドおよび受信された診断の履歴を含む。閾値が到達されたときの新たな診断が、前のイテレーションの間のものよりも悪い場合、次いで修復モジュールはこのイテレーションに対応する状態にネットワークを戻すために、この履歴を使用することができる。次いで必要なものは、この前の状況を回復するために逆コマンドを送信することがすべてである。
【００７７】
障害が真に解決されない場合、この実施形態はネットワークの状態を改善するための妥協案を可能にする。
【００７８】
そのようなバックトラッキングの後、問題が解決されなかったこととネットワークの状況とをオペレータに通知するために、マンマシンインタフェースＩＨＭを通じてオペレータにメッセージが送信される。
【００７９】
その他の実施形態によって、診断モジュールが問題を解決できない場合、トラフィックエンジニアリングＴＥ最適化モジュールが使用されてもよい。このトラフィック最適化モジュールの目的は、真に問題を解決するのではなく、問題を回避するためにトラフィックを向け直すことである。ゆえに、問題がルータ内で解決されることが不可能な場合（例えばハードウェアの問題）、ＴＥモジュールは他のルータ上のルーティングテーブル、このルータを通過するＬＳＰなどを変更して、このルータにこれ以上トラフィックが送信されないようにすることができる。ゆえに、ネットワーク動作は問題となっている機器が動作不能のままであっても、完全に動作可能となってもよい。
【００８０】
要約すると、障害を識別する診断は、障害が修復されるか、または障害は修復されずオペレータに知らされるか、または障害は修復されないがトラフィック最適化ツールが起動されるか、または修復モジュールＭＲがバックトラッキング機能を使用してネットワークを「より」悪くない状態にしてオペレータに通知するかの４つの結論のうちの１つを有することができる。
【００８１】
図３は、本発明による方法におけるステップの実施を概略的に示す。
【００８２】
第１の「Ｄｉａｇ」ステップは、診断の判定を起動することから構成されている。このステップは、特に通信ネットワーク内の警報またはカスタマの苦情の受信後に起動される。
【００８３】
次いで、システムは診断が障害を識別するかどうかを判定する（枠「Ｐ？」）。障害がなければ方法は停止する（枠「Ｆ１」）。
【００８４】
障害がある場合、方法はいくつかの停止基準を判定することから構成される（「停止？」）。目的は、イテレーションの数が所定の閾値に到達したかどうか、または診断が、前のイテレーションの間に予め作成されていた診断に対応しているかどうかを判定することである。これらの停止基準が満たされる場合、システムは停止する（枠「Ｆ２」）。
【００８５】
停止基準が満たされない場合、方法は修正行為を判定することと、これらの修正行為に関連するコマンドを通信ネットワークに送信することから構成される「Ｒｅｐ」ステップを使用する。
【００８６】
本発明の１つの好ましい実施形態で、続いて新たな「Ｄｉａｇ」診断ステップが起動され、その後方法は上述の異なるステップおよびテストを通過する。
【００８７】
次いで方法は、「Ｐ？」テストの間の障害の解決、または「停止？」テストの間の停止基準の充足によって終了されることが可能な処理サイクルを形成する。
【００８８】
本発明および異なるステップの連鎖は、以下の３つの特定の例を読んだ後により明らかとなろう。
【００８９】
これらの例の各々で、診断モジュールは通信ネットワークからの警報の受信、またはカスタマの苦情によって動作に入る。
【００９０】
第１の例で、カスタマの苦情ＣＣ、または通信ネットワークから受信された警報Ａは、このネットワーク内の問題を示している。第１の診断は、ルータＹのインタフェースＸがダウンしていることを明らかにする。診断モジュールＭＤは、チケット値およびイテレーション値１とともに、この診断を修復モジュールに送信する。
【００９１】
次いで、修復モジュールＭＲはこの診断に関連した修正行為を判定する。この実施例の中で、修正行為はインタフェースＸをサービス（「アップ」）に戻すことである。この修正行為に関連する一般コマンドは、ルータＹに特有の言語での適切なコマンドを判定する仲介モジュールＭＥＤに送信される。
【００９２】
修復モジュールＭＲは診断要求ＣＤを診断モジュールＭＤに送信し、同じチケット値を特定する。
【００９３】
診断モジュールＭＤは通信ネットワークの診断を繰り返し、ルータＹのインタフェースＸが現在アップしており、ネットワークが通常に動作していることを判定する。次いで診断モジュールＭＤは、ネットワークが通常に動作していることを通知するために、診断Ｄを修復モジュールに送信することができる。次いで問題は解決されたので、修復モジュールＭＲはいかなる行為も起動することはなく、本発明による方法は終了する。
【００９４】
第２の例で、診断モジュールはまた、ルータＹのインタフェースＸがダウンしていることを判定する。第１の例と同様に、診断Ｄはチケットとともに修復モジュールに送信され、修復モジュールＭＲは修正行為を判定する。この修正行為に関連する一般コマンドは、このコマンドをルータＹの特定の言語を伴うコマンドコンプライアントに変換する仲介モジュールＭＥＤに送信される。
【００９５】
修復モジュールＭＲは、同じチケットとともに、診断要求ＣＤを診断モジュールＭＤに送信する。診断モジュールＭＤは新たな診断判定を開始する。新たな診断Ｄは、ルータＹのインタフェースＸが依然としてダウンしていることを判定する。この診断Ｄは、同じチケット値、および２に等しいイテレーション値とともに、修復モジュールＭＲに送信される。
【００９６】
修復モジュールＭＲは、イテレーションは２に等しいが、問題は同じままであるということを認めてもよい。次いで修復モジュールＭＲは、トラフィック最適化モジュールＴＥ（トラフィックエンジニアリング）にコマンドを送信することを決定してもよい。
【００９７】
次いで、このトラフィックエンジニアリングモジュールＴＥは、通信ネットワークの中の既存の経路を変更して、それらがルータＹのインタフェースＸを回避するようにすることが可能である。このように、問題となっているインタフェースがダウンしていても、通信ネットワークは通常通りに動作することが可能である。
【００９８】
第３の例で、診断モジュールＭＤはまた、ルータＹのインタフェースＸがダウンしていることを判定する。診断Ｄはチケット数および１に等しいイテレーション値とともに、修復モジュールに送信される。
【００９９】
上述のように、修復モジュールは、インタフェースＸがサービス（「アップ」）になるように、一般コマンドが、それをルータＹに特有の言語を伴うコマンドコンプライアントに変換する仲介モジュールＭＥＤに送信されることを判定する。
【０１００】
修復モジュールＭＲは、同じチケット数とともに、診断要求ＣＤを診断モジュールＭＤに送信する。
【０１０１】
次いで、診断モジュールは新たな診断判定を起動し、例えばＢＧＰ（ボーダゲートウェイプロトコル）の構成不良などの新たな問題が見つけ出される。この診断Ｄは、２に等しいイテレーション数、および同じチケット値とともに、修理モジュールに送信される。
【０１０２】
次いで修復モジュールＭＲは、この場合ＢＧＰプロトコルを再構成することであってもよい適切な修正行為を判定する。次いで一般コマンドは、このコマンドを特定のコマンドに変換する仲介モジュールＭＥＤに送信される。
【０１０３】
再び修復モジュールＭＲは診断モジュールＭＤに診断要求ＣＤを送信し、同じチケット数を特定する。新たな診断Ｄは、ルータＹの同じインタフェースＸがダウンしていることを示す。この診断Ｄは３に等しいイテレーション値、および依然として同じチケット値とともに、修復モジュールＭＲに送信される。
【０１０４】
修復モジュールは、イテレーション値が３に等しく、診断がイテレーションが１のときと同じであることを認めてもよい。次いで修復モジュールは、問題が解決できないことを判定し、この不可能性および診断についての情報を表すメッセージを表示するマンマシンインタフェースＩＨＭにコマンドを送信することができる。
【０１０５】
これらの実施例は本発明の異なる動作方式を示しており、特には、例えばオペレータに通知する、トラフィック最適化モジュールを起動する、修復コマンドを起動する等のために、規則ベースＢを構成することによって、本発明による修復モジュールＭＲを違った風に動作させることができるということを示している。
【図面の簡単な説明】
【０１０６】
【図１】本発明による管理システムを概略的に示す図である。
【図２】本発明の１つの実施形態による修復モジュールの内部構造を示す図である。
【図３】本発明による方法のステップの連鎖を示す図である。
【特許請求の範囲】
【請求項１】
通信ネットワーク（Ｎ）の要素（Ｎ１、Ｎ２、Ｎ３、Ｎ４）によって提供される情報（Ａ）に基づき診断（Ｄ）を判定することができる診断モジュール（ＭＤ）を含む前記通信ネットワークのための管理システム（ＮＭＳ）であって、前記診断が前記通信ネットワーク内の障害を識別し、前記システムが、前記診断モジュール（ＭＤ）から受信された少なくとも前記診断に基づき１つまたは複数の修正行為を判定し、前記障害を修正するために前記修正行為に対応する１つまたは複数のコマンド（Ｃ）を前記通信ネットワークの１つまたは複数の要素に送信し、前記診断モジュールによる新たな診断の判定を起動するために診断要求（ＣＤ）を診断モジュール（ＭＤ）に送信するように設計された修復モジュール（ＭＲ）も含むことを特徴とする、管理システム。
【請求項２】
イテレーションカウンタが新たな診断が起動される度に増やされ、前記イテレーションカウンタが所定の閾値に到達する場合、前記管理システムが診断モジュールと修復モジュールとを停止する、請求項１に記載の管理システム。
【請求項３】
コマンドが、一般言語で公式化された前記コマンドを、前記通信ネットワーク中の異なる機器に特有のコマンド言語を伴う特有のコマンド（Ｃ１、Ｃ２）コンプライアントに変換することができる仲介モジュール（ＭＥＤ）を通じて送信される、請求項１または２のいずれか一項に記載の管理システム。
【請求項４】
修復モジュール（ＭＲ）が、各イテレーションで判定された診断履歴と修正行為履歴とを有し、診断が、前記閾値が到達されるときに所与のイテレーションの間のものと同様に適切ではない場合、通信ネットワークを前記所与のイテレーションの間の状態に戻すことができる、請求項２または３の一項に記載の管理システム。
【請求項５】
前記修復モジュールが、前記障害を修正するために修正行為が十分に判定されることが不可能な場合に、前記通信ネットワークの動作において前記障害の影響を取り除くか、または制限するために、トラフィック最適化モジュール（ＴＥ）と通信するようにも設計される、請求項１から４のいずれか一項に記載の管理システム。
【請求項６】
前記診断モジュール（ＭＤ）が、前記診断を判定するためにベイシアンネットワークを使用する、請求項１から５のいずれか一項に記載の管理システム。
【請求項７】
前記診断（Ｄ）が少なくとも前記障害の説明、前記障害の位置を含み、場合によっては前記診断に関連して起こりうる事態の予想を含む、請求項１から６のいずれか一項に記載の管理システム。
【請求項８】
前記診断モジュールが、ＳＮＭＰプロトコルを伴うメッセージコンプライアントを使用して、前記診断を前記修復モジュールに通信する、請求項１から７のいずれか一項に記載の管理システム。
【請求項９】
前記修復モジュールが修復規則ベースを有する、請求項１から８の一項に記載の管理システム。
【請求項１０】
前記規則が前記イテレーションカウンタに依存してもよい、請求項９および２に記載の管理システム。
【請求項１１】
通信ネットワーク（Ｎ）の要素（Ｎ１、Ｎ２、Ｎ３、Ｎ４）によって提供される情報（Ａ）に基づき診断（Ｄ）を判定するための第１ステップを含む前記通信ネットワークの管理方法であって、前記診断が障害を識別する場合、少なくとも前記診断に基づいて１つまたは複数の修正行為を判定し、前記障害を修正するためにこの（これらの）修正行為に対応する１つまたは複数のコマンド（Ｃ）を前記通信ネットワークの１つまたは複数の要素に送信するための第２ステップも含むことと、処理サイクルを形成するために、前記第１ステップが前記第２ステップの終了時に自動的に起動されることとを特徴とする、管理方法。
【請求項１２】
イテレーションカウンタが新たな診断が起動される度に増やされ、前記イテレーションカウンタが所定の閾値に到達する場合、前記処理サイクルが停止する、請求項１１に記載の方法。
【請求項１３】
各イテレーションで判定された診断履歴と修正行為履歴とが形成され、通信ネットワークは、診断が、前記閾値が到達されるときに以前のイテレーションの間のものと同様に適切ではない場合、以前のイテレーションの間の状態に戻される、請求項１２に記載の方法。
【請求項１４】
コマンドが、一般言語で公式化された前記コマンドを、前記通信ネットワーク中の異なる機器に特有のコマンド言語を伴う特有のコマンドコンプライアントに変換することができる仲介モジュール（ＭＥＤ）を通じて送信される、請求項１１から１３の一項に記載の方法。
【請求項１５】
コマンドが、前記障害を修正するために修正行為が十分に判定されることが不可能な場合、前記通信ネットワークの動作において前記障害の影響を取り除くか、または制限するために、トラフィック最適化モジュール（ＴＥ）に送信されてもよい、請求項１１から１４の一項に記載の方法。
【請求項１６】
前記第１ステップは前記診断を判定するためにベイシアンネットワークを使用する請求項１１から１５の一項に記載の方法。
【請求項１７】
前記診断（Ｄ）が少なくとも前記障害の説明、前記障害の位置を含み、場合によっては前記診断に関連する起こりうる事態の予想を含む、請求項１１から１６の一項に記載の方法。
【請求項１】
通信ネットワーク（Ｎ）の要素（Ｎ１、Ｎ２、Ｎ３、Ｎ４）によって提供される情報（Ａ）に基づき診断（Ｄ）を判定することができる診断モジュール（ＭＤ）を含む前記通信ネットワークのための管理システム（ＮＭＳ）であって、前記診断が前記通信ネットワーク内の障害を識別し、前記システムが、前記診断モジュール（ＭＤ）から受信された少なくとも前記診断に基づき１つまたは複数の修正行為を判定し、前記障害を修正するために前記修正行為に対応する１つまたは複数のコマンド（Ｃ）を前記通信ネットワークの１つまたは複数の要素に送信し、前記診断モジュールによる新たな診断の判定を起動するために診断要求（ＣＤ）を診断モジュール（ＭＤ）に送信するように設計された修復モジュール（ＭＲ）も含むことを特徴とする、管理システム。
【請求項２】
イテレーションカウンタが新たな診断が起動される度に増やされ、前記イテレーションカウンタが所定の閾値に到達する場合、前記管理システムが診断モジュールと修復モジュールとを停止する、請求項１に記載の管理システム。
【請求項３】
コマンドが、一般言語で公式化された前記コマンドを、前記通信ネットワーク中の異なる機器に特有のコマンド言語を伴う特有のコマンド（Ｃ１、Ｃ２）コンプライアントに変換することができる仲介モジュール（ＭＥＤ）を通じて送信される、請求項１または２のいずれか一項に記載の管理システム。
【請求項４】
修復モジュール（ＭＲ）が、各イテレーションで判定された診断履歴と修正行為履歴とを有し、診断が、前記閾値が到達されるときに所与のイテレーションの間のものと同様に適切ではない場合、通信ネットワークを前記所与のイテレーションの間の状態に戻すことができる、請求項２または３の一項に記載の管理システム。
【請求項５】
前記修復モジュールが、前記障害を修正するために修正行為が十分に判定されることが不可能な場合に、前記通信ネットワークの動作において前記障害の影響を取り除くか、または制限するために、トラフィック最適化モジュール（ＴＥ）と通信するようにも設計される、請求項１から４のいずれか一項に記載の管理システム。
【請求項６】
前記診断モジュール（ＭＤ）が、前記診断を判定するためにベイシアンネットワークを使用する、請求項１から５のいずれか一項に記載の管理システム。
【請求項７】
前記診断（Ｄ）が少なくとも前記障害の説明、前記障害の位置を含み、場合によっては前記診断に関連して起こりうる事態の予想を含む、請求項１から６のいずれか一項に記載の管理システム。
【請求項８】
前記診断モジュールが、ＳＮＭＰプロトコルを伴うメッセージコンプライアントを使用して、前記診断を前記修復モジュールに通信する、請求項１から７のいずれか一項に記載の管理システム。
【請求項９】
前記修復モジュールが修復規則ベースを有する、請求項１から８の一項に記載の管理システム。
【請求項１０】
前記規則が前記イテレーションカウンタに依存してもよい、請求項９および２に記載の管理システム。
【請求項１１】
通信ネットワーク（Ｎ）の要素（Ｎ１、Ｎ２、Ｎ３、Ｎ４）によって提供される情報（Ａ）に基づき診断（Ｄ）を判定するための第１ステップを含む前記通信ネットワークの管理方法であって、前記診断が障害を識別する場合、少なくとも前記診断に基づいて１つまたは複数の修正行為を判定し、前記障害を修正するためにこの（これらの）修正行為に対応する１つまたは複数のコマンド（Ｃ）を前記通信ネットワークの１つまたは複数の要素に送信するための第２ステップも含むことと、処理サイクルを形成するために、前記第１ステップが前記第２ステップの終了時に自動的に起動されることとを特徴とする、管理方法。
【請求項１２】
イテレーションカウンタが新たな診断が起動される度に増やされ、前記イテレーションカウンタが所定の閾値に到達する場合、前記処理サイクルが停止する、請求項１１に記載の方法。
【請求項１３】
各イテレーションで判定された診断履歴と修正行為履歴とが形成され、通信ネットワークは、診断が、前記閾値が到達されるときに以前のイテレーションの間のものと同様に適切ではない場合、以前のイテレーションの間の状態に戻される、請求項１２に記載の方法。
【請求項１４】
コマンドが、一般言語で公式化された前記コマンドを、前記通信ネットワーク中の異なる機器に特有のコマンド言語を伴う特有のコマンドコンプライアントに変換することができる仲介モジュール（ＭＥＤ）を通じて送信される、請求項１１から１３の一項に記載の方法。
【請求項１５】
コマンドが、前記障害を修正するために修正行為が十分に判定されることが不可能な場合、前記通信ネットワークの動作において前記障害の影響を取り除くか、または制限するために、トラフィック最適化モジュール（ＴＥ）に送信されてもよい、請求項１１から１４の一項に記載の方法。
【請求項１６】
前記第１ステップは前記診断を判定するためにベイシアンネットワークを使用する請求項１１から１５の一項に記載の方法。
【請求項１７】
前記診断（Ｄ）が少なくとも前記障害の説明、前記障害の位置を含み、場合によっては前記診断に関連する起こりうる事態の予想を含む、請求項１１から１６の一項に記載の方法。
【図１】
【図２】
【図３】
【図２】
【図３】
【公表番号】特表２００８−５０８７６０（Ｐ２００８−５０８７６０Ａ）
【公表日】平成２０年３月２１日（２００８．３．２１）
【国際特許分類】
【出願番号】特願２００７−５２３１２６（Ｐ２００７−５２３１２６）
【出願日】平成１７年７月１日（２００５．７．１）
【国際出願番号】ＰＣＴ／ＦＲ２００５／０５０５３０
【国際公開番号】ＷＯ２００６／０２１７０２
【国際公開日】平成１８年３月２日（２００６．３．２）
【出願人】（５０６４１７２８９）
【Ｆターム（参考）】
【公表日】平成２０年３月２１日（２００８．３．２１）
【国際特許分類】
【出願日】平成１７年７月１日（２００５．７．１）
【国際出願番号】ＰＣＴ／ＦＲ２００５／０５０５３０
【国際公開番号】ＷＯ２００６／０２１７０２
【国際公開日】平成１８年３月２日（２００６．３．２）
【出願人】（５０６４１７２８９）
【Ｆターム（参考）】
[ Back to top ]