遠隔通信システムにおけるサービス影響の分析およびアラートの処理
サービス品質（ＱｏＳ）アラートの優先順位付け、およびサービスに対するこうしたアラートの影響の分析のためのシステムは、サービスが１つまたは複数のサービスコンポーネントおよびサブコンポーネントに分割されるサービスモデルを使用する。サービスの異なる相によって動かされるサービス依存関係モデルの作成は、サービス全体の１コンポーネントに過ぎない最下位のネットワークコンポーネントでのアラートが、サービス全体にどのように影響を与えるかを理解できるようになる上で重要である。アラートには「ハンドル」および重大度レベルが割り当てられる。ハンドルを含む各コンポーネントに対するコンポーネント状況インジケータを作成するために、アラートに適用される規則が定義される。各ＣＳＩがサービスモデル依存関係グラフのトップに向かって上方に伝搬されるにつれて、各ＣＳＩは事前に定義された規則に従って修正される。ＣＳＩがトップのサービスコンポーネントに伝搬される際に、サービス影響インデックスが作成される。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、遠隔通信システムにおけるアラームを含むアラート（ａｌｅｒｔ）のサービス品質の処理および分析に関する。より具体的に言えば、本発明は、無線遠隔通信システムにおけるアラートのサービス品質（ＱｏＳ）の優先順位付けおよびこうしたアラートの影響分析のための方法に関する。この方法は、アラート、特に最高優先順位のアラームの根本原因の分析も提供する。
【背景技術】
【０００２】
ＴＤＭＡ、ＣＤＭＡ、またはＧＳＭに基づくセルラシステム、あるいはＧＰＲＳに基づく２．５Ｇネットワークなどの遠隔通信システムにおいて、サービスプロバイダはこれまでにも増して高いサービス品質を提供するための競争にさらされている。多くの異なる遠隔通信サービス、特に多くの新しい無線サービスが登場するにつれて、サービス保証の問題はますます困難になりつつある。現在のネットワークオペレーションセンタ（ＮＯＣ）では、何百何千もの様々な形の様々なアラート、警告、およびアラームを受信することは珍しくない。トラブルシューティングおよび問題解決を担当するＮＯＣの職員は、通常、高度な訓練を受けたある特定の技術分野を専門とする技術者である。従来から、ＮＯＣグループは、アプリケーションおよび内部ＩＰネットワークを管理する情報技術（ＩＴ）組織とは別のものである。あるドメイン内で発生した問題は、通常、他のドメインからの影響を考慮して処理されることはない。特に、ＱｏＳ問題の優先順位付けまたは根本原因の分析に適した方法または手順はない。
【０００３】
現在のサービス管理は、隔離されたネットワーク管理システムおよび情報技術（ＩＴ）ベースの管理環境からなる。ネットワーク管理タスクは、大量の性能データの収集、週間または月間レポートの生成、および大量のイベントおよびアラームのログ記録からなる。主にデータは、いくつかの互いに素の要素管理システム（ＥＭＳ）によって、または場合によっては個々のネットワーク要素（ＮＥ）によって生成される。サービスおよびアプリケーションの領域では、サーバおよびＬＡＮ関係のアラームおよびイベントを監視およびログ記録する場合、Ｈｅｗｌｅｔｔ−Ｐａｃｋａｒｄ社のＯｐｅｎｖｉｅｗ、Ｃｏｍｐｕｔｅｒ Ａｓｓｏｃｉａｔｅｓ社のＵｎｉｃｅｎｔｅｒ、またはＩＢＭ社のＴｉｖｏｌｉなどの、従来のＩＴ管理プラットフォームが一般的である。しかしながら、これらのＩＴベースの管理プラットフォームと他のＥＭＳとの間には、何の相関関係もない。隔離されたそれぞれのドメインに対して、特定のドメイン（アプリケーション、コア、アクセス）を担当する職員によって、真のサービス管理が実行される。通常、異なるドメインは、異なる組織によって処理され、これらの組織は互いにほとんど対話することなく独立して運営される。サービス品質についての統合および相関された見解はなく、サービス保証または長期計画に対して一貫した努力が払われることはない。
【０００４】
２Ｇ、２．５、または３Ｇのセルラ技術、あるいは８０２．１１ ＷｉＦｉベースシステムなどの無線ＬＡＮ（ＷＬＡＮ）技術といった無線技術への依存度が高まるにつれて、サービスの問題はますます複雑さを増していく。ボトムアップサービス保証システムは、様々なネットワーク要素またはサブシステムからデータを収集することに焦点を置いており、顧客の満足を満たすように顧客が望む様々なサービスが実際に提供されているかどうかには焦点が置かれていない。
【０００５】
影響分析の全体的な目標は、ある事前に定義されたサービスレベル基準に対してサービス品質の低下を定量化することである。その後、こうした影響分析の結果を使用して、サービスおよびネットワークアラーム、サービスＱｏＳアラート、ならびにネットワーク性能しきい値超過（ｃｒｏｓｓｉｎｇ）アラートまたは問題のあるチケット生成に関した他の性能影響イベントの、優先順位付けをサポートすることができる。加えて、ネットワークおよびサービスリソース拡張の優先順位付けをサポートするため、またはマーケティングおよび契約目的でのサービスレベル合意の調整のために、この結果を使用することもできる。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
無線サービスが激増するにつれて、またそれぞれのライフサイクルが短くなるにつれて、適切な技術を備えたＮＯＣオペレータを訓練して様々なタイプのサービス関連ＱｏＳ問題を処理できるようにすることは、ますます困難になってきている。ＮＯＣ職員のＱｏＳアラームの優先順位付けを支援するためには、アラートに関する関連情報を収集および抽出し、顧客に対する影響、サービス品質、ならびにマーケティングおよびプランニングなどの他の基準に対してそれらを優先順位付けするためのツールがあることが望ましい。
【０００７】
サービスのそれぞれのコンポーネント（構成要素）について、関連付けられたキー性能インジケータ（ＫＰＩ）のセットがある。サービスモデルが４０のコンポーネントを有し、それぞれが３０のＫＰＩを有すると想定すると、サービスには合計で１２００のＫＰＩが存在することになる。同時に２０のサービスが活動状態にある場合、潜在的に２０，０００を超えるＫＰＩを扱う可能性がある。所与の時点でＫＰＩの１％がしきい値を超過し、所与の時点で２００を超えるＱｏＳアラートを生成すると想定してみる。ＫＰＩの量およびそれらのアラートに加えて、特定のＫＰＩに特有のアルゴリズムを作成することも困難である。したがって影響分析アルゴリズムは、スケーラビリティおよび複雑さの問題に同時に対処しなければならない。
【０００８】
さらに、何らかの定量的な影響インデックスに対して、ＱｏＳアラームの系統的な優先順位付けを可能にする方法およびシステムを有することが望ましい。
【０００９】
加えて、アラートの影響を優先順位付けおよび分析するためのサービスの依存関係モデルを使用するシステムおよび方法を有することが望ましい。
【００１０】
大規模ネットワークに関する影響分析を提供することが可能であり、スケーラビリティの問題に悩まされることのない、方法およびシステムを有することも望ましい。
【００１１】
最終的に、アラートの優先順位付けおよびサービス影響の分析システムによって識別された、サービス影響アラートの根本原因分析において、ネットワークオペレータを支援することのできる方法およびシステムを有することが望ましい。
【００１２】
本発明は、このような状況に鑑みてなされたもので、その目的とするところは、遠隔通信システムにおけるサービス影響の分析およびアラートの処理のための方法及びシステムを提供することにある。
【課題を解決するための手段】
【００１３】
本発明は、遠隔通信ネットワーク、特に無線ネットワークにおいて、アラームを優先順位付けするための方法およびシステムを提供する。ＱｏＳアラートまたはアラームが受信され、優先順位インデックスを生成するためにアルゴリズムが使用される。アラートとは、特定の物理コンポーネントの障害によって引き起こされるハード障害アラーム、および所定のしきい値を超過する１つまたは複数の性能または他のインジケータの結果として発行されるアラートの、両方を指す。優先順位付けは、ＱｏＳアラートによって影響を受けるサービス、各サービスが影響を受ける範囲、およびサービスの顧客への影響を識別する。
【００１４】
本発明の方法およびシステムは、影響を受けるサービスを識別すること、キー品質インジケータ、サービス影響インデックス（ＳＩＩ）、および低下の重大度（割込み合計、割込みの持続時間、性能低下、およびデータ転送正確度）に基づいてサービス品質影響を判定することにより、これらの問題に対処する。システムは、影響を受ける加入者数（特別顧客および正規顧客の割合）も判定する。システムおよび方法は、この情報を利用してそれらに重み付けするための規則セットを適用し、最終的な優先順位インデックスを作成する。
【００１５】
サービスモデルは最初に、サービスレベルおよびネットワークレベルのコンポーネントの依存関係を捕らえる、グラフ構造で構築される。このサービス依存関係モデルは、ＱｏＳキー性能インジケータ（ＫＰＩ）の相関関係に関する基本フレームワークを提供する。コンポーネント状況インジケータ（ＣＳＩ）を作成するために、各コンポーネントのうちのアラートが出されたＫＰＩに規則セットが適用される。ＣＳＩは、アラートの原因に関する情報を指定する１つまたは複数のハンドルを含む。ＣＳＩがサービスコンポーネントに向かって伝搬される際に、追加のＣＳＩ情報を使用して現在のＣＳＩが修正される。ＣＳＩは最終的に、サービス影響インデックス（ＳＩＩ）に関して影響を取り込む、重みセットにマッピングされることになる。その後ＳＩＩは、影響を受けたサービスの数、加入者の数、ＱｏＳクラス、およびアラートの持続時間を含む、他のパラメータで重み付けされる。最終的な優先順位付けは、各ＣＳＩに関して影響インデックス全体をソートすることによって達成される。ネットワークオペレータは、ＣＳＩのハンドルに含まれる情報を使用して根本原因を分析することが可能であり、これがアラートの原因となる問題の診断および矯正に役立つ。
【発明を実施するための最良の形態】
【００１６】
優先順位付けのシステムおよび方法を説明するために、第１に、サービスを記述するためのサービスモデルについて説明する。サービスとは、ネットワークオペレータによって彼らの顧客に販売される製品のことである。エンドツーエンドサービスとは、エンドユーザ顧客が体験する、完全なラウンドトリップの対話またはセッションのことである。
【００１７】
サービスは、サブサービスまたはドメインの組み合わせとみなすことができる。サービスは、様々なベアラサービスおよび情報サービス、ならびに顧客またはサービス特有のリンクを含むことができる。電子メール、ショートメッセージングサービス（ＳＭＳ）、またはマルチメディアメッセージングサービス（ＭＭＳ）などの格納（または送達）および転送サービスの場合、１つのラウンドトリップのエンドツーエンド対話の代わりに、送達および転送という２つの別々の対話が存在する。エンドツーエンドサービスを提供するために様々なサブサービスが対話可能である。階層化方式には、基礎となるネットワーク、ベアラサービス、１つまたは複数の情報サービス、ならびにサービス間およびサービス内ベアラが含まれる。
【００１８】
サービスモデルは、サービスインベントリに関する共通のリポジトリおよびリファレンス、サービスおよびサブサービス、ならびにそれらのコンポーネントを、オペレータに提供するために使用される。サービスモデルは、サービスレベル合意（ＳＬＡ）、キー性能インジケータ（ＫＰＩ）、キー品質インジケータ（ＫＱＩ）、および全体サービスインデックス（ＳＩ）を定義およびカスタマイズするための手段を提供する。
【００１９】
キー性能インジケータ（ＫＰＩ）は、無線ＧＳＭベースのセルラシステムで利用可能なタイムスロットの数などの、ネットワークコンポーネントからの下位パラメータである。
【００２０】
キー品質インジケータ（ＫＱＩ）は、たとえば、ある期間にわたって使用不可なＧＳＭシステムにおける基地局の割合などの、サービス品質を示すパラメータである。ＫＱＩは１つまたは複数のＫＰＩに基づくものである。
【００２１】
サービスインデックス（ＳＩ）は、サービスの全体性能を示すように全体のサービス品質を要約するものである。ＳＩ、ＫＱＩ、およびＫＰＩが、品質インジケータの階層を形成する。ＳＩは、ＫＱＩの重み付け合計によって算出される。
【００２２】
サービスモデルの基本構築ブロックがサービスコンポーネントである。サービスコンポーネントとは、サービス品質に影響を与える論理エンティティのことである。サービスのモデル化は、サービスの相（ｐｈａｓｅ）（たとえば、認証相またはデータ転送相）あるいはサービスのトポロジに基づく分解によって実行可能である。サービスは、顧客向き（ｃｕｓｔｏｍｅｒ−ｆａｃｉｎｇ）またはサービスおよびネットワークの層などの、いくつかのカテゴリに分解することができる。非周期多重接続有向グラフである依存関係グラフでは、コンポーネントは互いに関連付けられている。依存関係グラフにおいて、コンポーネントＡとＢの間の各有向縁部は、ＡとＢの間の依存関係を表す。Ａの性能はＢの性能に依存し、すなわちＢの性能はＡの性能に影響を与える。
【００２３】
顧客向きコンポーネントとは、サービス品質要件が内部および外部の両方で顧客とのサービスレベル合意（ＳＬＡ）の一部である、サービスコンポーネントである。各顧客向きコンポーネントは監視および保証可能であり、それぞれが関連付けられたＳＬＡを潜在的に有する。サービスの一例がＶＯＩＰであり、ここでは顧客向きコンポーネントは「呼び出しセットアップ」および「データ転送」である。この場合、呼び出しセットアップは、データ転送用と同じかまたは異なるサービスコンポーネントを使用することができる。顧客向きサービスコンポーネントは、サービスコンポーネントを顧客への転送／ベアラネットワークと組み合わせるものであり、たとえば電子メール／ＷＡＰ／ＧＰＲＳサービスは、ＷＡＰおよび電子メールサービスコンポーネント、ＤＮＳ、ＤＨＣＰ、および他のセットアップサービスコンポーネント、顧客へのＧＰＲＳベアラネットワーク、サービスベアラ間ネットワーク、ならびに、顧客ハンドセットまたは移動局上のＷＡＰおよび電子メールクライアントアプリケーションを組み合わせる。この組み合わせは、顧客向きコンポーネントとサポートしているサービスおよびネットワークコンポーネントとの間に依存関係を作成することによって実施される。言い換えれば、電子メール／ＷＡＰ／ＧＰＲＳサービスは、電子メールサービスコンポーネント、ＧＰＲＳベアラコンポーネント、ＤＨＣＰサービスコンポーネントなどに依存する。図１は、サービスモデル依存関係グラフの一例を示す。電子メールなどのサービスコンポーネント１００は、サービスの４つのサブコンポーネントである、ネットワーク接続１１０、アプリケーションコンポーネント１２０、認証コンポーネント１３０、およびＤＮＳコンポーネント１４０に直接依存する。ネットワーク接続１１０は、ＤＳＬまたはケーブルモデム接続などの、サービスユーザと電子メールサーバとの間の接続である。アプリケーションコンポーネント１２０は、サーバから電子メールを取り出すためのポストオフィスプロトコル３（ＰＯＰ３）アプリケーションである。アプリケーションコンポーネント１２０は、１つまたは複数のサーバクラスタ１５０ならびにそれらのそれぞれのホスト１５２および１５４に依存する。認証コンポーネント１３０は、ユーザ認証の責務を負うコンポーネントである。ＤＮＳコンポーネント１４０は、ホスト名をホストのＩＰアドレスにマッピングする責務を負うコンポーネントである。
【００２４】
１つまたは複数のＫＱＩ／ＫＰＩが、依存関係グラフ内の各コンポーネントに関連付けられる。たとえば図１では、認証コンポーネント１３０は、失敗した要求および平均応答時間に基づくＫＱＩ／ＫＰＩを有する。アプリケーションコンポーネント１２０は、セッションメッセージに基づくＫＱＩ／ＫＰＩ、すなわちクライアントセッション数および成功したトランザクションの数を有する。ＤＮＳコンポーネント１４０は可用性および応答時間に基づくＫＰＩを有する。サーバクラスタ１５０はロードバランスおよび稼働ホスト数に基づくＫＰＩを有する。ホスト１５２および１５４はＣＰＵ使用率およびメモリ使用率に基づくＫＰＩを有する。
【００２５】
すべてのサブサービスコンポーネントおよびネットワークベアラコンポーネントが顧客向きサービスの依存性グラフに含まれることを保証するために、サービスに関する完全な通信フローを展開しなければならない。このフローに関するすべてのコンポーネントおよびプロセスは、依存関係グラフ内に反映させることができる。
【００２６】
サービスコンポーネントは、顧客向きコンポーネントを直接サポートする論理コンポーネントである。たとえば、ＷＡＰを介した電子メールサービスは、ＧＰＲＳサービス、ＷＡＰアクセスサービス、ならびにＰＯＰ３およびＳＭＴＰの両方の電子メールサービスコンポーネントを必要とする。サービスコンポーネントは、特定のサービスタイプに特有のコンポーネントの集まりを表し、様々なアプリケーションコンポーネント、ならびにそれらアプリケーション間で任意の必要な通信をサポートするのに必要なネットワークを組み合わせる。たとえば電子メールサービスは、ＰＯＰ３サーバアプリケーションコンポーネント、ＰＯＰ３プロキシアプリケーションコンポーネント、ＳＭＴＰアプリケーションコンポーネント、およびこれらのアプリケーションクラスタを接続するためのＩＰ ＬＡＮに依存する。アプリケーションコンポーネントは、１つの特定なアプリケーションをサポートするために配置されたすべてのリソースを表し、１つまたは複数のサーバクラスタおよびクラスタ間での通信のための任意の必要なネットワークベアラサポートコンポーネントに依存する。たとえば、ＰＯＰ３サーバアプリケーションコンポーネントは、２つの別々のロードバランシングされたＰＯＰ３サーバクラスタを含むことができる。
【００２７】
サーバクラスタコンポーネントは、クライアントから見ると単一のサーバを表し、単一のサーバまたはロードバランシングされたクラスタのいずれかに対するバックエンドであることが可能である。サーバクラスタは、いくつかのソフトウェアおよびホストコンポーネント、ならびにクラスタ間通信に必要な任意の必須ネットワークベアラコンポーネントに依存する。図２は、ロードバランシングされたサーバクラスタのサービスモデルの一例を示す図である。図１とは対照的に、図２（ならびにその後の図）では、下位要素が上位要素に与える影響を示すために、矢印は最下位要素から上に向かっている。サーバクラスタ２００は、ロードバランサ２１０、複数のサーバ２２０および２３０、ならびにサーバと通信するためのＩＰ ＬＡＮ２４０という、４つのコンポーネントに依存する。図２では、インタフェース１〜６はロードバランサおよびサーバホスト上のＩＰ ＬＡＮインタフェースである。ロードバランサは２つのインタフェース１および４を有し、サーバはインタフェース２、５、および３、６を有する。これら以外に、インタフェース２および３のみがそれぞれインタフェース１および４に接続されると想定される。したがって、サーバ１の性能はインタフェース２および５の性能による影響を受け、サーバ２の性能はインタフェース３および６の性能による影響を受けるが、サーバクラスタの性能に影響を与えるのはインタフェース２および３の性能のみである。
【００２８】
各コンポーネントタイプについて説明し、ＱｏＳアラートのトリガおよび伝搬に関する規則を示す。サーバクラスタサービスコンポーネントは、クライアントから見た単一のエントリ点を表し、ここで単一のサーバ、またはロードバランシングされたサーバクラスタ内の複数のサーバのいずれかによって、クライアント要求を処理することができる。サーバクラスタの一例がＳＭＴＰサーバクラスタであり、これはＤＮＳラウンドロビン機構を使用して、いくつかのＳＭＴＰホスト間で着信するＳＭＴＰメッセージのバランスをとる。クラスタは、ロードバランシングソフトウェアを備えていない単一のホスト、またはロードバランシングソフトウェアを備えた複数のホストからなる。「ロードバランシング」という用語は、高水準のコンテキストで使用され、ソフトウェアを使用して複数のサーバ間で負荷のバランスをとるシステムのことを表すものであり、たとえば、ホストのオペレーティングシステムが複数のプロセッサ間でＣＰＵ負荷のバランスをとる、マルチプロセッサコンピュータホストを指すものではない。
【００２９】
サーバクラスタは、性能アラート、負荷関係性能アラート、可用度アラート、およびバランシング誤りアラートを有することができる。性能および負荷アラートは、ソフトウェアサブコンポーネントにおける低性能または高負荷によってトリガされる。バランシング誤りアラートは、子サーバソフトウェアコンポーネントのうちの１つまたは複数が、他の子コンポーネントとは大きく異なる負荷レベルを経験している場合に、トリガされる。
【００３０】
サーバクラスタコンポーネントはクラスタ全体を表し、マルチホストクラスタのロードバランシング機構と間違えられることはない。上記の例では、クラスタのＤＮＳロードバランシング機構は、サービスモデルの別のロードバランシングコンポーネントとしてモデル化されることになり、これが親サーバクラスタコンポーネントに影響を与える。
【００３１】
ネットワークベアラコンポーネントは、多種多彩な他のコンポーネントをサポートする移送関係のコンポーネントである。このコンポーネントは、全体ネットワークグループコンポーネント（いくつかのネットワークベアラコンポーネント間で共用される）、ならびに、特にベアラコンポーネントに影響を与えると思われる、特定のネットワークインタフェースおよびネットワークノードコンポーネントに依存する。たとえば、ホスト間の通信に共用ＩＰ ＬＡＮを使用するサーバクラスタを表すベアラコンポーネントは、ネットワークベアラコンポーネントに依存することになり、次にこれが（１）ＩＰ ＬＡＮネットワークグループコンポーネントおよび（２）個々のサーバホストインタフェースに依存することになる。次にＩＰ ＬＡＮは、ルータ、スイッチ、インタフェース、および他のネットワーク要素の集まりに依存することになり、このＬＡＮコンポーネントは、同じＬＡＮを共用する他のネットワークベアラコンポーネントに影響を与えることになる。図３は、ネットワークコンポーネントのサービスモデルの一例を示す図である。サービス対ネットワーク（Service-to-Network）３００は、サービス−ネットワークインタフェース３１０および全体ネットワーク３２０に依存する。全体ネットワーク３２０は、複数のサブネットワーク３３０および３４０に依存する。
【００３２】
マルチメディアメッセージングサービス（ＭＭＳ）は、本発明のモデル化方法の一例として提示されている。ＭＭＳは、人から人への移動メッセージングのためのエンドツーエンドの格納および転送サービスである。イメージ、オーディオ、ビデオ、データ、およびテキストを含む豊富なマルチメディアコンテンツを提供するが、それでもなお簡単に使えるように設計されている。ＭＭＳはショートメッセージングサービス（ＳＭＳ）に関する。しかしながら、ＭＭＳを使用した場合、ＳＭＳの場合のようにメッセージの最終送達はユーザに到達しない。むしろユーザは、メッセージの通知を受け、メッセージをダウンロードするオプションが与えられる。その結果、メッセージの送達は即時でない可能性がある。サービスは２段階である。第１に、一時記憶のために送信者（ＭＭ移動体）からＭＭＳＣにｍｍが送信され、その後、これがＭＭＳＣから、ＭＭ移動体、レガシー移動体、または電子メールクライアントである、宛先に送信される。
【００３３】
ＭＭＳは３つのサブサービスＭＭ−ＭＭ、ＭＭ−ＬＭ、およびＭＭ−電子メールに分割される。各サブサービスについて、セットアップおよびデータ転送という２つの相が定義される。これらの相は、顧客のサービス知覚に直接関係するために定義される。顧客の知覚は、下位サービスまたはネットワークコンポーネントアラートの結果として生じる影響から導出される、サービス影響インデックス（ＳＩＩ）（サービスインデックスとも呼ばれる）の形で測定される。
【００３４】
無線サービスは、移動体対移動体（ＭＭ−ＭＭ）、移動体対レガシー移動体（ＭＭ−ＬＭ）、電子メールベース、コンテンツ開始、およびプリペイドの、複数のサブサービスを含むことができる。移動体対移動体サブサービスが、本発明の一例として提示される。
【００３５】
移動体対移動体サブサービスは、１）セットアップ相コンポーネント、および２）データ転送相コンポーネントの、２相コンポーネントに分解することができる。この分解の理由は、サービスのこれら２つの相がユーザによって知覚された場合にまったく異なる品質要件を有するためである。相がどのように他のコンポーネントに依存するかを理解するためには、サービスの明確な定義がなければならない。副相（ｓｕｂ−ｐｈａｓｅ）１はハンドセット１（ＨＳ１）の認証である。副相２はＨＳ１ ＷＡＰ（無線アクセスプロトコル）の認証であり、副相３はＨＳ１ マルチメディアメッセージングサービス（ＭＭＳ）の認証である。副相４はＨＳ１からＭＭＳへのデータの転送である。副相５はハンドセット２（ＨＳ２）の通知／肯定応答である。副相６は送信するようにとのＨＳ２の要求である。副相７はＨＳ２の認証である。副相８はＨＳ２へのデータの送信であり、副相９はＨＳ１への通知である。
【００３６】
影響分析の場合、これらの副相はセットアップ相およびデータ転送相のコンポーネントにグループ化される。これらの相および関連するネットワークコンポーネントがそれぞれたどったパスに基づいて、サービス依存モデルが作成される。サービス定義を理解することによって、サービスモデルを構築するための体系的な方法が可能になる。前述のように、ＭＭＳは４つのサブサービス（プリペイドを可能な５番目とする）に分割される。これらのコンポーネントの依存関係は、図４に示されている。ＭＭＳサービス４００は、ＭＭ−ＭＭサブサービス４１０、ＭＭ−ＬＭサブサービス４２０、電子メールサブサービス４３０、およびサブサービスコンテンツ４４０を有する。この最初の３つのコンポーネントは、それぞれ、セットアップ相４５０およびデータ転送相４６０という２つの別々の相に分割することができる。これらの相は、顧客のサービス知覚に直接関係するために定義される。顧客の知覚は、下位サービスまたはネットワークコンポーネントアラートの結果として生じる影響から導出される、サービス影響インデックスの形で、または単にサービスインデックスと呼ばれる形で測定される。
【００３７】
図５は、ＭＭＳ汎用パケット無線サービス（ＧＰＲＳ）コンポーネント５００を示す。これには２つの「子」コンポーネントがある。１つは、ゲートウェイＧＰＲＳサービスノード（ＧＧＳＮ）のアクセスポイント名（ＡＰＮ）インタフェースコンポーネント５１０である。もう１つが全体ＧＰＲＳネットワークコンポーネント５２０であり、これはさらに、ＧＰＲＳコア５３０、インターネットプロトコル（ＩＰ）ワイドエリアネットワーク（ＷＡＮ）すなわちＩＰ ＷＡＮ ５４０、および無線アクセスネットワーク（ＲＡＮ）５５０という、３つのサブコンポーネントに分解される。このモデルでは、ＧＰＲＳネットワークの３つのコンポーネントは、ハンドセットとＭＭＳサービスとの間の接続に関する一般性能情報のみを提供し、仮想接続固有の情報は提供しないものと想定される。固有の性能情報は、インタフェース固有のコンポーネントからのものであると想定される。
【００３８】
図６〜９は、図５に示されたＧＰＲＳネットワークを含む、ＭＭＳサービスのサービス依存関係モデルを示す図である。このモデルは、前述の３つのカテゴリ、すなわちサービス、サーバ／クラスタ、およびネットワークのコンポーネントを使用する。図を簡略化するために、最下位のネットワークコンポーネントはＨＩ（ホストおよびインタフェース）のグループにまとめられる。さらに、ここでは単一のサーバのみが示されているが、この概念はサービスクラスタにも適用可能である。加えて、地理的に異なる場所にあるが、クラスタは形成していない（すなわち、負荷共有のない）サーバが存在する場合、それらのサーバは、異なるネットワークコンポーネントによってサポート可能であるため、異なるサービスコンポーネント（以下の図には示されていない）とみなされる。
【００３９】
４つのサブサービスに対応するサービスモデルが図６〜９に示されている。図６は、依存関係グラフ形式のＭＭ−ＭＭサービスモデル６００の基本コンポーネントを示す図である。ＭＭ−ＭＭサービス６１０のセットアップ部分は、ＳＭＳおよび信号方式システム７（ＳＳ７）ネットワーク６３０、認証サーバ（ＡｕＳ）６４０、無線アクセスプロトコル（ＷＡＰ）サーバ用認証６４２、リモート認証ダイヤルインユーザサービス（ＲＡＤＩＵＳ）サーバ６４４、メッセージングアプリケーションルータ／マルチメディアメッセージサービスセンタ（ＭＡＲ／ＭＭＳＣ）６４８（およびそのコンポーネントを介してＩＰ ＷＡＮ５４０へ）、ならびに加入者データ機能（ＳＤＦ）サーバ６５０に依存する。このコンテキストでは、ＳＭＳ性能それ自体が、サービス提供ＧＰＲＳサポートノード（ＳＧＳＮ）とショートメッセージサービスセンタ（ＳＭＳＣ）インタフェースの間の信号方式インタフェース６３１、ＳＭＳＣ−ＳＳ７インタフェース６３２、ＧＳＭ性能のＳＭＳ固有コンポーネント（ＧＳＭ−ＳＭＳ固有）６３３、ＳＭＳ−ＳＳ７ネットワークの全体性能６３４、およびＳＧＳＮ性能のＳＭＳ固有コンポーネント（ＳＧＳＮ ＳＭＳ−ｓ）６３５に依存する。ＳＭＳ−ＳＳ７ネットワーク６３０は、ＲＡＮ ５５０にも依存する。ＭＭ−ＭＭセットアップコンポーネント６１０およびＭＭ−ＭＭデータ転送コンポーネント６２０は、どちらも、ＩＰローカルエリアネットワーク（ＩＰ ＬＡＮ）の全体性能６５２、マルチメディアメッセージサービスセンタ（ＭＭＳＣ）ネットワーク６５４、ＷＡＰネットワーク６５６、ならびに図５に記載されたＧＰＲＳネットワーク５００に依存する。図６では、ＨＩは図２に示されたホストクラスタおよびインタフェースを表す。
【００４０】
図７は、依存関係グラフ形式のＭＭ−ＬＭサービスモデル７００の基本コンポーネントを示す図である。ＭＭ−ＬＭセットアップ相７１０およびＭＭ−ＬＭデータ転送相７２０に関するコンポーネントは、端末ゲートウェイサーバ（ＴＧＷ）７３０への追加のそれぞれの依存関係を除き、すべて図６と同じである。
【００４１】
図８は、依存関係グラフ形式のＭＭ電子メールサービスモデル８００の基本コンポーネントを示す図である。ＭＭ電子メールセットアップ相８１０およびＭＭ電子メールデータ転送相８２０に関するコンポーネントは、メッセージ転送エージェント（ＭＴＡ）８３０への追加のそれぞれの依存関係を除き、すべて図６と同じである。
【００４２】
図９は、依存関係グラフ形式のＭＭＳコンテンツサービス９００の基本コンポーネントを示す図である。ＭＭＳコンテンツサービス９００は、ＭＭＳコンテンツサービス相９１０およびＭＭＳコンテンツデータ転送相９２０に加えて、登録相９３０を含む。ＭＭＳコンテンツセットアップ相９１０に関するすべてのコンポーネントは、図６と同じである。ＭＭＳコンテンツデータ転送９２０に関するコンポーネントは、情報コンテンツサーバ（ＩＣＳ）サーバ９４０への追加の依存関係を除き、すべて図６と同じである。登録相９３０は、ＳＭＳ−ＳＳ７ ６４０、ＳＤＦ ６５０、およびＩＰ ＷＡＮ ５４０という前述の３つのコンポーネント、ならびにＩＣＳサーバ９４０に依存する。加えて登録相９３０は、対話型音声応答（ＩＶＲ）サーバ９３２、ＧＳＭサーバ９３４、およびＩＣＳ対ＳＤＦサーバＡＰＩ（ＩＣＳ−ＡＰＩ）９３６に依存する。
【００４３】
影響を受けるサービスの識別は、サービスがどのように実施されるかおよびサービスのコンポーネントに依存する。また、サービスコンポーネントのトポロジおよび構造にもかなり依存する。表面上は、サービスのサブコンポーネント（ルータまたはサーバなど）に関連付けられた任意のＱｏＳアラートが、その性能が低下しているルータまたはサーバを使用するサービスが影響を受けていることを示唆するというように、結論付けようとしている場合がある。実際には、分析がさらに大きく関わっている。不確実さは、主に、ＩＰネットワークの自己修復または障害隠蔽機能、およびサービスの実施に組み込まれた多くの耐障害性機構の結果である。
【００４４】
簡単な例を挙げると、ルータインタフェースの障害は、ルーティングアルゴリズムによって自動的に迂回することが可能であり、その後、ルータインタフェース障害はそれ自体を容量の中のほんのわずかとして表すことが可能であり、これはトラフィック負荷に応じてエンドサービスに影響を与える場合や与えない場合がある。サービスの影響に対するＱｏＳアラートの直接の関係の矛盾を示す他の例が、サーバのロードバランシングにある。このシナリオでは、それぞれがアプリケーションのコピーを実行中の複数のサーバ間で、アプリケーションがロードバランシングされる。サービスに対する要求は、ＤＮＳラウンドロビンまたはトラフィックベース割り振りなどの、あるロードバランシングアルゴリズムに従って、複数のサーバによって処理される。サーバの１つがハード障害を示す場合、そのサーバは使用不可となり、通常は重大なアラームである。しかしながら、他のサーバは依然として適切に機能しているため、（たとえばトラフィックベースの）ロードバランシングアルゴリズムに応じて、ここですべての要求を残りの健全なサーバに向けて送ることができる。このシナリオでは、負荷が軽い場合、ここでもサービスの影響が重大でない可能性がある。
【００４５】
ソフトウェアサービスコンポーネントは、単一のアプリケーションまたはコンピュータホスト上で実行中の１片のアプリケーションを表す。サービスモデルでは、ソフトウェアコンポーネントはハードウェアホストおよび１つまたはいくつかのインタフェースに依存し、サーバクラスタコンポーネントに影響を与える。サーバソフトウェアコンポーネントの一例が、ＳＭＴＰサーバアプリケーションプログラムである。ソフトウェアコンポーネントの他の例が、ソフトウェアベースのロードバランサアプリケーションである。
【００４６】
性能アラート、負荷関係性能アラート、および可用度アラートという、いくつかの異なるタイプのアラートが、ソフトウェアコンポーネントから送出される。性能および負荷アラートはＱｏＳ性能アラートであり、負荷関係ＫＰＩ（たとえば、ホストＣＰＵ負荷、インタフェース使用率、およびクライアントトランザクション回数など）のしきい値超過によってトリガされる。これらのＫＰＩが中央値しきい値を超過した場合、サービスモデル内の影響を受けるサービスコンポーネントに性能アラートが送出され、同時に発生するすべての関係ＫＰＩしきい値超過を１つにまとめて、伝搬されるアラートにこれらを含める。
【００４７】
ＩＰ ＬＡＮサービスコンポーネント６５２は、いくつかのサーバおよびクラスタにＩＰ接続を提供するために共通インフラストラクチャとして使用されるＩＰノードの集まりを表す。エンドツーエンド、プローブ、またはＥＭＳベースのデータを使用して、これらネットワークの性能が判定される。個々のノード／インタフェース使用率データを使用して、今後の性能／可用度問題を示すネットワーク使用率が判定される。他のコンポーネントタイプの場合と同様に、関係する同時ＫＰＩしきい値超過が報告され、単一のアラートとして伝搬される。
【００４８】
サービスモデルでは、サーバクラスタコンポーネントはＩＰ ＬＡＮコンポーネントに依存して、サーバとロードバランサとの間に接続を提供する。ＬＡＮの性能、使用率、および可用度が、親サーバクラスタに影響を与える。
【００４９】
図１０は、２つのサブコンポーネントＸおよびＹで構成されるコンポーネントＡに対する本発明の高水準アーキテクチャを示す。ＫＰＩアラートは、各ＫＰＩアラートを単独で分析するのではなく、Ｘ＿ＫＰＩ：｛ｘ１，ｘ２，．．．ｘｍ｝１０１０およびＹ＿ＫＰＩ：｛ｙ１，ｙ２，．．．ｙｎ｝１０２０などのコンポーネントごとのカテゴリにグループ化される。すべてのＫＰＩアラートは、第１にコンポーネントごとにグループ化される。あるコンポーネント内のＫＰＩアラートは、可用度および性能という２つの広範なカテゴリにさらにグループ化され、それぞれが規則エンジン１０３２および１０４２を使用するために、可用度インジケータ１０３４および１０４４ならびに性能インジケータ１０３６および１０４６を作成する。可用度および性能に加えて、たとえば使用率／負荷またはセキュリティなどの他の広範なカテゴリも実施できる可能性がある。規則エンジン１０３２および１０３４は、１つまたは複数の高水準プログラミング言語で作成された規則プログラムが実行可能な、汎用プロセッサである。
【００５０】
可用度カテゴリは、コンポーネントの可用度レベルのインジケーションである。３つのレベルが定義される。レベル３では、ハードウェア障害状態などの場合、コンポーネントは完全にダウンする。レベル２では、コンポーネントは部分的にダウン、すなわちコンポーネントの一部がダウンする。レベル１では、ある統計的なダウンタイム属性がしきい値を超え、すべてのキー性能インジケータは低い値を示すが、これはコンポーネントが依然として稼働（ｕｐ）しており、すべての性能測定値で非常に低い性能が示されていることを意味する。重大度に関しては、レベル３は最も重大であり、レベル１は最も重大でない。
【００５１】
性能カテゴリは、コンポーネントの全体性能のインジケーションである。３つのレベルが定義される。レベル１では、性能はわずかに低下している。レベル２では性能は低下し、レベル３では性能はかなり低下している。
【００５２】
加えて、アラートを識別するハンドルおよびアラートを記述するテキストのオプションフィールドが定義される。これらのハンドルは、技術者がアラートの原因により効率良く対処できることになる、特定のコンポーネントからのＫＰＩ情報である。
【００５３】
コンポーネントアラートグループは、ハンドルと共に、コンポーネント状況インジケータ（ＣＳＬ＿ａｌｅｒｔグループ）を形成する。その後、ＣＳＩインジケータ１０３８および１０４８は規則処理要素１０５２と組み合わされて、コンポーネントＡに関するＣＳＩインジケータ１０５４を展開し、コンポーネントＡはコンポーネントＸおよびＹに依存する。コンポーネントＸは、レベル２の重大度の問題によって現在ダウンしているため、ＣＳＩ可用度インジケータを転送する。コンポーネントＹは、現在使用可能であるが性能はかなり低下している、すなわちレベル＝３であるため、ＣＳＩ性能インジケータを転送する。コンポーネントＡは、コンポーネントｘおよびｙから受け取ったそれらに基づいて、可用度および性能のインジケータを転送する。ＣＳＩ＿ａｌｅｒｔグループの追加の例を以下に示す。
【００５４】
ＣＳＩ＿Ｐｅｒｆ：［ＭＭＳＣ＿Ｃｌｕｓｔｅｒ：Ｐ＝（レベル３）；ＰＨ＝０１０，０５９；“首尾良く送達されたメッセージの％＜９８％”］
ＣＳＩ＿Ａｖａｉｌ：［ＩＰ ＬＡＮ：Ａ＝（レベル２＝使用不可）；ハンドル＝１２、“ルータｘがダウン”］
ＣＳＩ＿ａｌｅｒｔグループが次の上位またはアップストリームレベルで親コンポーネントに伝搬する場合、親コンポーネントは２つのタスクを実行する。第１に、親コンポーネントは、そのダウンストリームにある「子」コンポーネントからのすべてのＣＳＩおよびそのレベルで処理された任意のアラートを考慮に入れて、それ自体に関する可用度インジケータおよび性能インジケータを割り当てる。第２に、親コンポーネントは、その子の可用度および性能の両方のＣＳＩの重要度レベルを修正するかどうかを判定する。
【００５５】
ＣＳＩの可用度および性能インジケータの判定に使用される規則は、ユーザによる変更が可能である。表１は、影響を与える規則の一例である。
【００５６】
【表１】
【００５７】
規則は静的または動的とすることができる。静的規則は経時的に変化しない。動的規則は、加入者数、ある時点でのサービスの値、または地理によって、経時的に変化する可能性がある。規則は一般に、一貫性を持たせるために中央のネットワークオペレータによって作成されるが、規則が作成されているコンポーネントについて最も詳しい者の専門知識を考慮に入れるものとする。これによって、影響の分析において、またアラートの処理においても、コンポーネントに関する技術的な専門知識を使用することができる。
【００５８】
各ＣＳＩグループには持続期間が割り当てられる。この持続期間は、含まれるすべてのハンドルの最大持続期間となるように定義される。たとえば、特定のＣＳＩ性能アラートグループが、ハンドルＨ１（持続期間１時間）、Ｈ２（持続期間３０分）、およびＨ３（持続期間２時間）を含むものと想定する。このグループ内で最大持続期間を有するハンドルはＨ３である。したがって、全体ＣＳＩ性能インジケータの持続期間は２時間である。個々のハンドルの持続期間は、ハンドルが現時点まで連続して活動状態であった時間の長さである。たとえば、システムが１５分間隔でパケット損失情報を集め、そのパケット損失測定値が過去２回のサンプリング間隔で性能アラートしきい値を超えた場合、パケット損失アラートハンドルの持続期間は３０分である。
【００５９】
図１１は、本発明に従ったサービス影響分析のための高水準流れ図である。ステップ１１１０で、複数のＣＳＩアラート（Ｘ１．．．Ｘｎ）が集められ、ＣＳＩアラートが性能または可用度に影響を与えるかどうかを判定する意思決定論理に転送される。ステップ１１２０で、ＣＳＩアラートが性能または可用度に影響を与える場合、影響規則の適用を通じてアラートがサービスに影響を与えるかどうかを判定する追加の意思決定論理に転送される。アラートがサービスに影響を与えない場合、ステップ１１４０でアラートインベントリデータベースに転送および格納される。アラートインベントリは、アラートのパターンなどを探すために後で分析することができる。アラートがサービスに影響を与える場合、ステップ１１３０で影響を受けるサービスを識別するために使用される。ステップ１１５０で、影響を受けるそれぞれのサービスについて、影響を受ける顧客の数、影響を受ける特別顧客の数、影響を受ける特別サービスの数、サービス影響インデックス（ＳＩＩ）の程度、およびアラートの持続期間、というパラメータのうちの１つまたは複数を推定することによって、影響を受けるサービス上の影響が判定される。ステップ１１６０で、ステップ１１５０で集められた情報に基づいてサービス影響インデックスを生成するために規則が適用され、複数のＳＩＩ（Ｉ（ｘ１）．．．Ｉ（ｘｎ））を生成し、その後ステップ１１７０で、影響の量に基づいて優先順位リストに優先順位付けされる。この優先順位リストを使用して、ネットワークオペレータはサービスに最大の影響を与える問題にどのアラートが関係しているかを即時に識別することができる。
【００６０】
本発明の代替実施形態では、中間規則を定義しないことによって実施を簡略化することができる。これは、下位レベルのコンポーネントについてアラート「ＣＳＩ＿Ａｖａｉｌ」および「ＣＳＩ＿Ｐｅｒｆ」がいったん定義されると、サービスモデルの中間コンポーネントによって修正されることがないことを意味する。
【００６１】
ＣＳＩアラートがサービスに影響を与えるものと判定されると、サービスの品質低下に関する影響を定量化しなければならない。サービス影響インデックス（ＳＩＩ）は、事前に定義されたＫＱＩセットの重み付け合計として定義することができる。図１２は、この判定のためのプロセス流れを示す図である。ステップ１２１０で、影響を受けるそれぞれのサービスのそれぞれのコンポーネントへのＫＱＩ影響が判定される。ステップ１２２０で、それぞれのコンポーネントへのＫＱＩ影響の合計が算出される。ステップ１２３０で、影響を受けるユーザの数、アラートの持続期間、特別サービスへの影響などの情報に基づいた重み付け要素を使用して、ＫＱＩ影響の合計に重み付けする。これらの重み付けおよび合計されたＫＱＩ影響が、その後、前述のように優先順位付け可能なサービス影響インデックスになる。
【００６２】
本発明の方法の主要な要素について以下に要約して記載する。サービスの異なる相によって動かされるサービス依存関係モデルの作成は、サービス全体の１コンポーネントに過ぎない最下位のネットワークコンポーネントでのアラートが、サービス全体にどのように影響を与えるかを理解できるようになる上で重要である。アラートには「ハンドル」および重大度レベルが割り当てられる。各コンポーネントに対するコンポーネント状況インジケータを作成するためにアラートに適用される規則が定義される。各ＣＳＩがサービスモデル依存関係グラフのトップに向かって上方に伝搬されるにつれて、各ＣＳＩは事前に定義された規則に従って修正される。
【００６３】
ＣＳＩがトップのサービスコンポーネントに伝搬される際に、サービス影響インデックスが作成される。影響を受けるそれぞれのサービスについて、アラートの持続期間、加入者の数、サービスの数、影響を受けるサービスのＱｏＳクラス、またはユーザによって定義される他の要素に従って、重み（乗数）が定義される。重みは、ＳＩＩを乗算して全体の影響インデックスを得るために使用され、このインデックスがソートされて優先順位リストが得られる。
【００６４】
優先順位付け用の主要な重みは以下の通りである。サービスインデックスは（セットアップおよびデータ転送からの）ＫＱＩの影響レベルから算出される。ＳＩは各サブサービスについて別々に算出しなければならず、結果をすべて加算してサービス影響インデックスが形成される。
【００６５】
加入者インデックスの数は、加入者数の重要性を表す数である。未処理の（ｏｕｔｓｔａｎｄｉｎｇ）アラートの持続期間は、サンプリング期間に関して定義される。問題が矯正されると、アラートは除去されると予測される。長い未処理のアラートには、アラートを新しくするより多くの重みが与えられる。１〜３のインデックスは持続期間の重みを表すために使用される。サービスの数はＣＳＩごとに識別され、合計影響は影響を受けるすべてのサービスに依存する。すべての重みが算出された後、特定のＣＳＩについての単一のインデックスが得られる。表２および３は、複数のサービスにわたる個々のサービス影響インデックスの重み付け合計に基づいた、合計影響インデックスの計算を示す。
【００６６】
【表２】
【００６７】
【表３】
【００６８】
前述の方法を拡張して、ネットワークオペレータがアラート優先順位付けおよびサービス影響分析中に生成された情報を根本原因分析のために使用できるようにすることが可能である。根本原因分析（ＲＣＡ）は、１つまたは複数のアラートの根本原因を識別する問題に対処する。この問題は、前述のサービス影響分析およびアラート優先順位付けの逆である。サービス影響分析およびアラーム優先順位付けでは、サービスモデル依存関係グラフの各レベルで生成されたＣＳＩが、次のレベルで追加のＣＳＩを作成するために使用され、トップレベルでサービス影響インデックスを生成するために使用される。障害のサービス影響およびサービスの低下が識別され、アラートが優先順位付けされると、ネットワークオペレータによる根本原因の診断およびサービスの復元によって、問題修復の問題に対処することができる。この方法はＲＣＡを支援し、追加の診断テストの必要性を最小限にする。パスに沿ってサービスモデル依存関係グラフ内を上方に、サービス影響分析およびそれに続くアラート優先順位付けをドリルダウンしていくこと、および１つまたは複数のＣＳＩに含まれるアラートに関連付けられたハンドルを参照することによって、ネットワークオペレータは、サービスモデル依存関係グラフの最も可能性の高い最下位層での、ネットワーク障害またはサービス低下の最も可能性の高い原因を識別することができる。
【００６９】
サービスモデル依存関係グラフのコンポーネントへのデータ入力は、（１）そのコンポーネントに関するアラートシステムからのアラート、（２）ダウンストリームの「子」コンポーネントからのＣＳＩ、および（３）プローブ、ＥＭＳ、またはＮＭＳ）などのデータ収集エージェントから収集された性能データからなる。前述のように、上記入力はすべて、各コンポーネントについて規則セットを使用して処理される。この規則は、そのレベルでのＣＳＩを発行するかどうかを判定し、これはその後アップストリームレベルまたは「親」コンポーネントによって使用可能である。規則エンジンがそのＣＳＩを発行すべきであると判定する場合は、ある規則に合致したためである。規則に合致しない場合、アラートは抑制され、これは検査を受けたアラートがサービス問題を引き起こさないことを意味する。このアラートのコンポーネントレベルのフィルタリングにより、さらにアップストリームでの不必要な処理がなくなる。したがって、コンポーネント内での規則の実行は、潜在的な性能問題のローカル診断である。規則実行の結果により、サービスおよびシステムレベルの根本原因診断に使用可能な、価値ある情報が提供される。ネットワークオペレータは、ＣＳＩのハンドルコンポーネントおよびハンドル伝搬を介して、この情報を根本原因分析に使用することができる。
【００７０】
図１３を参照すると、コンポーネント４−１ １３１０内の規則が満たされたために、コンポーネント４−１ １３１０のアラート１は、コンポーネント４−１で搬送されるＣＳＩ＿４−１（ｈ１）のハンドルｈ１になる。この時点で、以下の表４で説明するように、ＣＳＩ＿４−１に関する情報がＣＳＩテーブルに記録される。ＣＳＩテーブルは、ＣＳＩ ＩＤ、ハンドル、タイムスタンプ、および合致した規則を識別する。ＣＳＩ＿４−１は、性能データおよびＣＳＩ＿４−１を、コンポーネント３−１ １３４０へとアップストリームに伝搬し、ここでは異なる規則セットが、アラート２によって提供されるようなアラート情報を使用して、いずれかの規則が合致したかどうかを判定する。他の規則条件のうちの１つが満たされる場合、表４などのＣＳＩテーブルに格納された関連情報と共にＣＳＩ＿３−１が発行される。アラート２は、ＣＳＩ＿３−１内のハンドル２（ｈ２）となる。
【００７１】
コンポーネント４−２ １３２０、コンポーネント４−３ １３３０、コンポーネント３−３ １３６０、またはコンポーネント２−２ １３８０などのいくつかのコンポーネントでは、規則によってＣＳＩを伝搬させるアラートがない可能性がある。同様の規則処理は、規則およびアラート３に基づいてハンドルｈ３を伴うＣＳＩ＿３−２（ｈ３）が生成されるコンポーネント３−２ １３５０と、規則セットならびに「子」コンポーネント３−１および３−２からのＣＳＩに基づいてＣＳＩ＿２−１（ｈ１、ｈ２、ｈ３）が生成されるコンポーネント２−１ １３７０などの、他のコンポーネントでも発生する。ｈ１およびｈ２などのハンドルが新しいＣＳＩの生成と並行して伝搬される場合、逆のパスに関する情報がハンドルに追加されることになるため、ＣＳＩは以下のように表される。
【００７２】
ＣＳＩ＿２−１＝（．．．．．ｈ１（パス＝２−１、３−１、４−１）、ｈ２（パス＝２−１、３−１）、ｈ３（パス＝２−１、３−２）
ハンドルのパスＩＤはコンポーネントＩＤを与え、これと並行してハンドルが伝搬される。別のテーブルが、ハンドルおよびその対応するアラート、しきい値、違反回数などに関する情報を格納する。ハンドルテーブルは、他のドリルダウンアクションが所望される場合、ＣＳＩの性質に関する他の情報を提供する。コンポーネント２−１ １３７０からのＣＳＩを使用して、コンポーネント１−１ １３９０で、トップレベルＣＳＩおよびサービス影響分析を展開することができる。
【００７３】
【表４】
【００７４】
根本原因分析時に、トップレベルへと進むハンドルは、根本原因の分析に関するすべての関連する相関情報を容易に取り出すための情報を担持する。この情報は、多くの根本原因分析が含まれるため、ネットワークオペレータまたはトラブルシュータにとって特に有用である。
【００７５】
前述の方法は、一部の規則の適用およびＣＳＩアラートの生成を中央オフィスに実行させることにより、サービスレベル管理機能の一部としてネットワークオペレーションセンタで、サービスビューロとして、または配布物で、実施可能である。規則は、多くの異なるプログラミング言語で１つまたは複数のプロセッサを汎用コンピュータ上で実行するために実施可能である。オフィスまたはオフィスの近くに配置されたコンポーネントに関する規則を実行するネットワークオペレーションセンタおよび中央オフィスプロセッサは、異なるプログラミング言語で作成された異なる規則セットを実行することができる。重要な要素は、ＣＳＩのフォーマット、およびＣＳＩのフォーマットを介してダウンストリームプロセッサがアップストリームプロセッサと通信する機能である。また、アラートまたはＣＳＩのいずれかを、サービスモデル依存関係グラフのダウンストリームレベルからアップストリームレベルへと渡すためには、コンポーネント間に通信パスが必要であり、こうしたパスは直接物理接続、またはインターネットなどのネットワーク接続を介した仮想接続である。
【００７６】
前述の記述は、本発明を例示および説明するためにのみ提示したものである。本発明を網羅すること、または本発明を開示された任意の精密な形式に限定することは意図していない。上記の教示に鑑みて、多くの修正形態および変形形態が可能である。記載された明細書は、当業者が様々な応用例で、および企図された特定の用途に好適な様々な修正形態で、本発明を最も適切に使用できるように、本発明の原理およびその実際の応用例を最も良く説明するために選択および説明された。
【図面の簡単な説明】
【００７７】
【図１】サービスモデル依存関係グラフの一例を示す図である。
【図２】ロードバランシングされたサーバクラスタのサービスモデルの一例を示す図である。
【図３】ネットワークコンポーネントのサービスモデルの一例を示す図である。
【図４】ＭＭＳサービスに関する高水準サービスモデル依存関係グラフを示す図である。
【図５】ＭＭＳサービスのＭＭＳ汎用パケット無線サービス（ＧＰＲＳ）コンポーネントに関するサービスモデル依存関係グラフを示す図である。
【図６】ＭＭＳのＭＭ−ＭＭ部分を含む基本コンポーネントの依存関係グラフを示す図である。
【図７】ＭＭＳサービスのＭＭ−ＬＭ部分を含む基本コンポーネントの依存関係グラフを示す図である。
【図８】ＭＭＳサービスのＭＭ−Ｅメール部分を含む基本コンポーネントの依存関係グラフを示す図である。
【図９】ＭＭＳサービスのＭＭＳコンテンツ部分を含む基本コンポーネントの依存関係グラフを示す図である。
【図１０】本発明のアラート優先順位付けシステムの高水準アーキテクチャを示す図である。
【図１１】本発明のアラート優先順位付けおよびサービス影響分析方法のプロセス流れを示す図である。
【図１２】本発明のサービス影響分析方法のプロセス流れを示す図である。
【図１３】サービスモデル依存関係グラフにおける様々なコンポーネントレベルでのコンポーネント状況インジケータ（ＣＳＩ）の生成を介したハンドルの伝搬のグラフを示す図である。
【技術分野】
【０００１】
本発明は、遠隔通信システムにおけるアラームを含むアラート（ａｌｅｒｔ）のサービス品質の処理および分析に関する。より具体的に言えば、本発明は、無線遠隔通信システムにおけるアラートのサービス品質（ＱｏＳ）の優先順位付けおよびこうしたアラートの影響分析のための方法に関する。この方法は、アラート、特に最高優先順位のアラームの根本原因の分析も提供する。
【背景技術】
【０００２】
ＴＤＭＡ、ＣＤＭＡ、またはＧＳＭに基づくセルラシステム、あるいはＧＰＲＳに基づく２．５Ｇネットワークなどの遠隔通信システムにおいて、サービスプロバイダはこれまでにも増して高いサービス品質を提供するための競争にさらされている。多くの異なる遠隔通信サービス、特に多くの新しい無線サービスが登場するにつれて、サービス保証の問題はますます困難になりつつある。現在のネットワークオペレーションセンタ（ＮＯＣ）では、何百何千もの様々な形の様々なアラート、警告、およびアラームを受信することは珍しくない。トラブルシューティングおよび問題解決を担当するＮＯＣの職員は、通常、高度な訓練を受けたある特定の技術分野を専門とする技術者である。従来から、ＮＯＣグループは、アプリケーションおよび内部ＩＰネットワークを管理する情報技術（ＩＴ）組織とは別のものである。あるドメイン内で発生した問題は、通常、他のドメインからの影響を考慮して処理されることはない。特に、ＱｏＳ問題の優先順位付けまたは根本原因の分析に適した方法または手順はない。
【０００３】
現在のサービス管理は、隔離されたネットワーク管理システムおよび情報技術（ＩＴ）ベースの管理環境からなる。ネットワーク管理タスクは、大量の性能データの収集、週間または月間レポートの生成、および大量のイベントおよびアラームのログ記録からなる。主にデータは、いくつかの互いに素の要素管理システム（ＥＭＳ）によって、または場合によっては個々のネットワーク要素（ＮＥ）によって生成される。サービスおよびアプリケーションの領域では、サーバおよびＬＡＮ関係のアラームおよびイベントを監視およびログ記録する場合、Ｈｅｗｌｅｔｔ−Ｐａｃｋａｒｄ社のＯｐｅｎｖｉｅｗ、Ｃｏｍｐｕｔｅｒ Ａｓｓｏｃｉａｔｅｓ社のＵｎｉｃｅｎｔｅｒ、またはＩＢＭ社のＴｉｖｏｌｉなどの、従来のＩＴ管理プラットフォームが一般的である。しかしながら、これらのＩＴベースの管理プラットフォームと他のＥＭＳとの間には、何の相関関係もない。隔離されたそれぞれのドメインに対して、特定のドメイン（アプリケーション、コア、アクセス）を担当する職員によって、真のサービス管理が実行される。通常、異なるドメインは、異なる組織によって処理され、これらの組織は互いにほとんど対話することなく独立して運営される。サービス品質についての統合および相関された見解はなく、サービス保証または長期計画に対して一貫した努力が払われることはない。
【０００４】
２Ｇ、２．５、または３Ｇのセルラ技術、あるいは８０２．１１ ＷｉＦｉベースシステムなどの無線ＬＡＮ（ＷＬＡＮ）技術といった無線技術への依存度が高まるにつれて、サービスの問題はますます複雑さを増していく。ボトムアップサービス保証システムは、様々なネットワーク要素またはサブシステムからデータを収集することに焦点を置いており、顧客の満足を満たすように顧客が望む様々なサービスが実際に提供されているかどうかには焦点が置かれていない。
【０００５】
影響分析の全体的な目標は、ある事前に定義されたサービスレベル基準に対してサービス品質の低下を定量化することである。その後、こうした影響分析の結果を使用して、サービスおよびネットワークアラーム、サービスＱｏＳアラート、ならびにネットワーク性能しきい値超過（ｃｒｏｓｓｉｎｇ）アラートまたは問題のあるチケット生成に関した他の性能影響イベントの、優先順位付けをサポートすることができる。加えて、ネットワークおよびサービスリソース拡張の優先順位付けをサポートするため、またはマーケティングおよび契約目的でのサービスレベル合意の調整のために、この結果を使用することもできる。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
無線サービスが激増するにつれて、またそれぞれのライフサイクルが短くなるにつれて、適切な技術を備えたＮＯＣオペレータを訓練して様々なタイプのサービス関連ＱｏＳ問題を処理できるようにすることは、ますます困難になってきている。ＮＯＣ職員のＱｏＳアラームの優先順位付けを支援するためには、アラートに関する関連情報を収集および抽出し、顧客に対する影響、サービス品質、ならびにマーケティングおよびプランニングなどの他の基準に対してそれらを優先順位付けするためのツールがあることが望ましい。
【０００７】
サービスのそれぞれのコンポーネント（構成要素）について、関連付けられたキー性能インジケータ（ＫＰＩ）のセットがある。サービスモデルが４０のコンポーネントを有し、それぞれが３０のＫＰＩを有すると想定すると、サービスには合計で１２００のＫＰＩが存在することになる。同時に２０のサービスが活動状態にある場合、潜在的に２０，０００を超えるＫＰＩを扱う可能性がある。所与の時点でＫＰＩの１％がしきい値を超過し、所与の時点で２００を超えるＱｏＳアラートを生成すると想定してみる。ＫＰＩの量およびそれらのアラートに加えて、特定のＫＰＩに特有のアルゴリズムを作成することも困難である。したがって影響分析アルゴリズムは、スケーラビリティおよび複雑さの問題に同時に対処しなければならない。
【０００８】
さらに、何らかの定量的な影響インデックスに対して、ＱｏＳアラームの系統的な優先順位付けを可能にする方法およびシステムを有することが望ましい。
【０００９】
加えて、アラートの影響を優先順位付けおよび分析するためのサービスの依存関係モデルを使用するシステムおよび方法を有することが望ましい。
【００１０】
大規模ネットワークに関する影響分析を提供することが可能であり、スケーラビリティの問題に悩まされることのない、方法およびシステムを有することも望ましい。
【００１１】
最終的に、アラートの優先順位付けおよびサービス影響の分析システムによって識別された、サービス影響アラートの根本原因分析において、ネットワークオペレータを支援することのできる方法およびシステムを有することが望ましい。
【００１２】
本発明は、このような状況に鑑みてなされたもので、その目的とするところは、遠隔通信システムにおけるサービス影響の分析およびアラートの処理のための方法及びシステムを提供することにある。
【課題を解決するための手段】
【００１３】
本発明は、遠隔通信ネットワーク、特に無線ネットワークにおいて、アラームを優先順位付けするための方法およびシステムを提供する。ＱｏＳアラートまたはアラームが受信され、優先順位インデックスを生成するためにアルゴリズムが使用される。アラートとは、特定の物理コンポーネントの障害によって引き起こされるハード障害アラーム、および所定のしきい値を超過する１つまたは複数の性能または他のインジケータの結果として発行されるアラートの、両方を指す。優先順位付けは、ＱｏＳアラートによって影響を受けるサービス、各サービスが影響を受ける範囲、およびサービスの顧客への影響を識別する。
【００１４】
本発明の方法およびシステムは、影響を受けるサービスを識別すること、キー品質インジケータ、サービス影響インデックス（ＳＩＩ）、および低下の重大度（割込み合計、割込みの持続時間、性能低下、およびデータ転送正確度）に基づいてサービス品質影響を判定することにより、これらの問題に対処する。システムは、影響を受ける加入者数（特別顧客および正規顧客の割合）も判定する。システムおよび方法は、この情報を利用してそれらに重み付けするための規則セットを適用し、最終的な優先順位インデックスを作成する。
【００１５】
サービスモデルは最初に、サービスレベルおよびネットワークレベルのコンポーネントの依存関係を捕らえる、グラフ構造で構築される。このサービス依存関係モデルは、ＱｏＳキー性能インジケータ（ＫＰＩ）の相関関係に関する基本フレームワークを提供する。コンポーネント状況インジケータ（ＣＳＩ）を作成するために、各コンポーネントのうちのアラートが出されたＫＰＩに規則セットが適用される。ＣＳＩは、アラートの原因に関する情報を指定する１つまたは複数のハンドルを含む。ＣＳＩがサービスコンポーネントに向かって伝搬される際に、追加のＣＳＩ情報を使用して現在のＣＳＩが修正される。ＣＳＩは最終的に、サービス影響インデックス（ＳＩＩ）に関して影響を取り込む、重みセットにマッピングされることになる。その後ＳＩＩは、影響を受けたサービスの数、加入者の数、ＱｏＳクラス、およびアラートの持続時間を含む、他のパラメータで重み付けされる。最終的な優先順位付けは、各ＣＳＩに関して影響インデックス全体をソートすることによって達成される。ネットワークオペレータは、ＣＳＩのハンドルに含まれる情報を使用して根本原因を分析することが可能であり、これがアラートの原因となる問題の診断および矯正に役立つ。
【発明を実施するための最良の形態】
【００１６】
優先順位付けのシステムおよび方法を説明するために、第１に、サービスを記述するためのサービスモデルについて説明する。サービスとは、ネットワークオペレータによって彼らの顧客に販売される製品のことである。エンドツーエンドサービスとは、エンドユーザ顧客が体験する、完全なラウンドトリップの対話またはセッションのことである。
【００１７】
サービスは、サブサービスまたはドメインの組み合わせとみなすことができる。サービスは、様々なベアラサービスおよび情報サービス、ならびに顧客またはサービス特有のリンクを含むことができる。電子メール、ショートメッセージングサービス（ＳＭＳ）、またはマルチメディアメッセージングサービス（ＭＭＳ）などの格納（または送達）および転送サービスの場合、１つのラウンドトリップのエンドツーエンド対話の代わりに、送達および転送という２つの別々の対話が存在する。エンドツーエンドサービスを提供するために様々なサブサービスが対話可能である。階層化方式には、基礎となるネットワーク、ベアラサービス、１つまたは複数の情報サービス、ならびにサービス間およびサービス内ベアラが含まれる。
【００１８】
サービスモデルは、サービスインベントリに関する共通のリポジトリおよびリファレンス、サービスおよびサブサービス、ならびにそれらのコンポーネントを、オペレータに提供するために使用される。サービスモデルは、サービスレベル合意（ＳＬＡ）、キー性能インジケータ（ＫＰＩ）、キー品質インジケータ（ＫＱＩ）、および全体サービスインデックス（ＳＩ）を定義およびカスタマイズするための手段を提供する。
【００１９】
キー性能インジケータ（ＫＰＩ）は、無線ＧＳＭベースのセルラシステムで利用可能なタイムスロットの数などの、ネットワークコンポーネントからの下位パラメータである。
【００２０】
キー品質インジケータ（ＫＱＩ）は、たとえば、ある期間にわたって使用不可なＧＳＭシステムにおける基地局の割合などの、サービス品質を示すパラメータである。ＫＱＩは１つまたは複数のＫＰＩに基づくものである。
【００２１】
サービスインデックス（ＳＩ）は、サービスの全体性能を示すように全体のサービス品質を要約するものである。ＳＩ、ＫＱＩ、およびＫＰＩが、品質インジケータの階層を形成する。ＳＩは、ＫＱＩの重み付け合計によって算出される。
【００２２】
サービスモデルの基本構築ブロックがサービスコンポーネントである。サービスコンポーネントとは、サービス品質に影響を与える論理エンティティのことである。サービスのモデル化は、サービスの相（ｐｈａｓｅ）（たとえば、認証相またはデータ転送相）あるいはサービスのトポロジに基づく分解によって実行可能である。サービスは、顧客向き（ｃｕｓｔｏｍｅｒ−ｆａｃｉｎｇ）またはサービスおよびネットワークの層などの、いくつかのカテゴリに分解することができる。非周期多重接続有向グラフである依存関係グラフでは、コンポーネントは互いに関連付けられている。依存関係グラフにおいて、コンポーネントＡとＢの間の各有向縁部は、ＡとＢの間の依存関係を表す。Ａの性能はＢの性能に依存し、すなわちＢの性能はＡの性能に影響を与える。
【００２３】
顧客向きコンポーネントとは、サービス品質要件が内部および外部の両方で顧客とのサービスレベル合意（ＳＬＡ）の一部である、サービスコンポーネントである。各顧客向きコンポーネントは監視および保証可能であり、それぞれが関連付けられたＳＬＡを潜在的に有する。サービスの一例がＶＯＩＰであり、ここでは顧客向きコンポーネントは「呼び出しセットアップ」および「データ転送」である。この場合、呼び出しセットアップは、データ転送用と同じかまたは異なるサービスコンポーネントを使用することができる。顧客向きサービスコンポーネントは、サービスコンポーネントを顧客への転送／ベアラネットワークと組み合わせるものであり、たとえば電子メール／ＷＡＰ／ＧＰＲＳサービスは、ＷＡＰおよび電子メールサービスコンポーネント、ＤＮＳ、ＤＨＣＰ、および他のセットアップサービスコンポーネント、顧客へのＧＰＲＳベアラネットワーク、サービスベアラ間ネットワーク、ならびに、顧客ハンドセットまたは移動局上のＷＡＰおよび電子メールクライアントアプリケーションを組み合わせる。この組み合わせは、顧客向きコンポーネントとサポートしているサービスおよびネットワークコンポーネントとの間に依存関係を作成することによって実施される。言い換えれば、電子メール／ＷＡＰ／ＧＰＲＳサービスは、電子メールサービスコンポーネント、ＧＰＲＳベアラコンポーネント、ＤＨＣＰサービスコンポーネントなどに依存する。図１は、サービスモデル依存関係グラフの一例を示す。電子メールなどのサービスコンポーネント１００は、サービスの４つのサブコンポーネントである、ネットワーク接続１１０、アプリケーションコンポーネント１２０、認証コンポーネント１３０、およびＤＮＳコンポーネント１４０に直接依存する。ネットワーク接続１１０は、ＤＳＬまたはケーブルモデム接続などの、サービスユーザと電子メールサーバとの間の接続である。アプリケーションコンポーネント１２０は、サーバから電子メールを取り出すためのポストオフィスプロトコル３（ＰＯＰ３）アプリケーションである。アプリケーションコンポーネント１２０は、１つまたは複数のサーバクラスタ１５０ならびにそれらのそれぞれのホスト１５２および１５４に依存する。認証コンポーネント１３０は、ユーザ認証の責務を負うコンポーネントである。ＤＮＳコンポーネント１４０は、ホスト名をホストのＩＰアドレスにマッピングする責務を負うコンポーネントである。
【００２４】
１つまたは複数のＫＱＩ／ＫＰＩが、依存関係グラフ内の各コンポーネントに関連付けられる。たとえば図１では、認証コンポーネント１３０は、失敗した要求および平均応答時間に基づくＫＱＩ／ＫＰＩを有する。アプリケーションコンポーネント１２０は、セッションメッセージに基づくＫＱＩ／ＫＰＩ、すなわちクライアントセッション数および成功したトランザクションの数を有する。ＤＮＳコンポーネント１４０は可用性および応答時間に基づくＫＰＩを有する。サーバクラスタ１５０はロードバランスおよび稼働ホスト数に基づくＫＰＩを有する。ホスト１５２および１５４はＣＰＵ使用率およびメモリ使用率に基づくＫＰＩを有する。
【００２５】
すべてのサブサービスコンポーネントおよびネットワークベアラコンポーネントが顧客向きサービスの依存性グラフに含まれることを保証するために、サービスに関する完全な通信フローを展開しなければならない。このフローに関するすべてのコンポーネントおよびプロセスは、依存関係グラフ内に反映させることができる。
【００２６】
サービスコンポーネントは、顧客向きコンポーネントを直接サポートする論理コンポーネントである。たとえば、ＷＡＰを介した電子メールサービスは、ＧＰＲＳサービス、ＷＡＰアクセスサービス、ならびにＰＯＰ３およびＳＭＴＰの両方の電子メールサービスコンポーネントを必要とする。サービスコンポーネントは、特定のサービスタイプに特有のコンポーネントの集まりを表し、様々なアプリケーションコンポーネント、ならびにそれらアプリケーション間で任意の必要な通信をサポートするのに必要なネットワークを組み合わせる。たとえば電子メールサービスは、ＰＯＰ３サーバアプリケーションコンポーネント、ＰＯＰ３プロキシアプリケーションコンポーネント、ＳＭＴＰアプリケーションコンポーネント、およびこれらのアプリケーションクラスタを接続するためのＩＰ ＬＡＮに依存する。アプリケーションコンポーネントは、１つの特定なアプリケーションをサポートするために配置されたすべてのリソースを表し、１つまたは複数のサーバクラスタおよびクラスタ間での通信のための任意の必要なネットワークベアラサポートコンポーネントに依存する。たとえば、ＰＯＰ３サーバアプリケーションコンポーネントは、２つの別々のロードバランシングされたＰＯＰ３サーバクラスタを含むことができる。
【００２７】
サーバクラスタコンポーネントは、クライアントから見ると単一のサーバを表し、単一のサーバまたはロードバランシングされたクラスタのいずれかに対するバックエンドであることが可能である。サーバクラスタは、いくつかのソフトウェアおよびホストコンポーネント、ならびにクラスタ間通信に必要な任意の必須ネットワークベアラコンポーネントに依存する。図２は、ロードバランシングされたサーバクラスタのサービスモデルの一例を示す図である。図１とは対照的に、図２（ならびにその後の図）では、下位要素が上位要素に与える影響を示すために、矢印は最下位要素から上に向かっている。サーバクラスタ２００は、ロードバランサ２１０、複数のサーバ２２０および２３０、ならびにサーバと通信するためのＩＰ ＬＡＮ２４０という、４つのコンポーネントに依存する。図２では、インタフェース１〜６はロードバランサおよびサーバホスト上のＩＰ ＬＡＮインタフェースである。ロードバランサは２つのインタフェース１および４を有し、サーバはインタフェース２、５、および３、６を有する。これら以外に、インタフェース２および３のみがそれぞれインタフェース１および４に接続されると想定される。したがって、サーバ１の性能はインタフェース２および５の性能による影響を受け、サーバ２の性能はインタフェース３および６の性能による影響を受けるが、サーバクラスタの性能に影響を与えるのはインタフェース２および３の性能のみである。
【００２８】
各コンポーネントタイプについて説明し、ＱｏＳアラートのトリガおよび伝搬に関する規則を示す。サーバクラスタサービスコンポーネントは、クライアントから見た単一のエントリ点を表し、ここで単一のサーバ、またはロードバランシングされたサーバクラスタ内の複数のサーバのいずれかによって、クライアント要求を処理することができる。サーバクラスタの一例がＳＭＴＰサーバクラスタであり、これはＤＮＳラウンドロビン機構を使用して、いくつかのＳＭＴＰホスト間で着信するＳＭＴＰメッセージのバランスをとる。クラスタは、ロードバランシングソフトウェアを備えていない単一のホスト、またはロードバランシングソフトウェアを備えた複数のホストからなる。「ロードバランシング」という用語は、高水準のコンテキストで使用され、ソフトウェアを使用して複数のサーバ間で負荷のバランスをとるシステムのことを表すものであり、たとえば、ホストのオペレーティングシステムが複数のプロセッサ間でＣＰＵ負荷のバランスをとる、マルチプロセッサコンピュータホストを指すものではない。
【００２９】
サーバクラスタは、性能アラート、負荷関係性能アラート、可用度アラート、およびバランシング誤りアラートを有することができる。性能および負荷アラートは、ソフトウェアサブコンポーネントにおける低性能または高負荷によってトリガされる。バランシング誤りアラートは、子サーバソフトウェアコンポーネントのうちの１つまたは複数が、他の子コンポーネントとは大きく異なる負荷レベルを経験している場合に、トリガされる。
【００３０】
サーバクラスタコンポーネントはクラスタ全体を表し、マルチホストクラスタのロードバランシング機構と間違えられることはない。上記の例では、クラスタのＤＮＳロードバランシング機構は、サービスモデルの別のロードバランシングコンポーネントとしてモデル化されることになり、これが親サーバクラスタコンポーネントに影響を与える。
【００３１】
ネットワークベアラコンポーネントは、多種多彩な他のコンポーネントをサポートする移送関係のコンポーネントである。このコンポーネントは、全体ネットワークグループコンポーネント（いくつかのネットワークベアラコンポーネント間で共用される）、ならびに、特にベアラコンポーネントに影響を与えると思われる、特定のネットワークインタフェースおよびネットワークノードコンポーネントに依存する。たとえば、ホスト間の通信に共用ＩＰ ＬＡＮを使用するサーバクラスタを表すベアラコンポーネントは、ネットワークベアラコンポーネントに依存することになり、次にこれが（１）ＩＰ ＬＡＮネットワークグループコンポーネントおよび（２）個々のサーバホストインタフェースに依存することになる。次にＩＰ ＬＡＮは、ルータ、スイッチ、インタフェース、および他のネットワーク要素の集まりに依存することになり、このＬＡＮコンポーネントは、同じＬＡＮを共用する他のネットワークベアラコンポーネントに影響を与えることになる。図３は、ネットワークコンポーネントのサービスモデルの一例を示す図である。サービス対ネットワーク（Service-to-Network）３００は、サービス−ネットワークインタフェース３１０および全体ネットワーク３２０に依存する。全体ネットワーク３２０は、複数のサブネットワーク３３０および３４０に依存する。
【００３２】
マルチメディアメッセージングサービス（ＭＭＳ）は、本発明のモデル化方法の一例として提示されている。ＭＭＳは、人から人への移動メッセージングのためのエンドツーエンドの格納および転送サービスである。イメージ、オーディオ、ビデオ、データ、およびテキストを含む豊富なマルチメディアコンテンツを提供するが、それでもなお簡単に使えるように設計されている。ＭＭＳはショートメッセージングサービス（ＳＭＳ）に関する。しかしながら、ＭＭＳを使用した場合、ＳＭＳの場合のようにメッセージの最終送達はユーザに到達しない。むしろユーザは、メッセージの通知を受け、メッセージをダウンロードするオプションが与えられる。その結果、メッセージの送達は即時でない可能性がある。サービスは２段階である。第１に、一時記憶のために送信者（ＭＭ移動体）からＭＭＳＣにｍｍが送信され、その後、これがＭＭＳＣから、ＭＭ移動体、レガシー移動体、または電子メールクライアントである、宛先に送信される。
【００３３】
ＭＭＳは３つのサブサービスＭＭ−ＭＭ、ＭＭ−ＬＭ、およびＭＭ−電子メールに分割される。各サブサービスについて、セットアップおよびデータ転送という２つの相が定義される。これらの相は、顧客のサービス知覚に直接関係するために定義される。顧客の知覚は、下位サービスまたはネットワークコンポーネントアラートの結果として生じる影響から導出される、サービス影響インデックス（ＳＩＩ）（サービスインデックスとも呼ばれる）の形で測定される。
【００３４】
無線サービスは、移動体対移動体（ＭＭ−ＭＭ）、移動体対レガシー移動体（ＭＭ−ＬＭ）、電子メールベース、コンテンツ開始、およびプリペイドの、複数のサブサービスを含むことができる。移動体対移動体サブサービスが、本発明の一例として提示される。
【００３５】
移動体対移動体サブサービスは、１）セットアップ相コンポーネント、および２）データ転送相コンポーネントの、２相コンポーネントに分解することができる。この分解の理由は、サービスのこれら２つの相がユーザによって知覚された場合にまったく異なる品質要件を有するためである。相がどのように他のコンポーネントに依存するかを理解するためには、サービスの明確な定義がなければならない。副相（ｓｕｂ−ｐｈａｓｅ）１はハンドセット１（ＨＳ１）の認証である。副相２はＨＳ１ ＷＡＰ（無線アクセスプロトコル）の認証であり、副相３はＨＳ１ マルチメディアメッセージングサービス（ＭＭＳ）の認証である。副相４はＨＳ１からＭＭＳへのデータの転送である。副相５はハンドセット２（ＨＳ２）の通知／肯定応答である。副相６は送信するようにとのＨＳ２の要求である。副相７はＨＳ２の認証である。副相８はＨＳ２へのデータの送信であり、副相９はＨＳ１への通知である。
【００３６】
影響分析の場合、これらの副相はセットアップ相およびデータ転送相のコンポーネントにグループ化される。これらの相および関連するネットワークコンポーネントがそれぞれたどったパスに基づいて、サービス依存モデルが作成される。サービス定義を理解することによって、サービスモデルを構築するための体系的な方法が可能になる。前述のように、ＭＭＳは４つのサブサービス（プリペイドを可能な５番目とする）に分割される。これらのコンポーネントの依存関係は、図４に示されている。ＭＭＳサービス４００は、ＭＭ−ＭＭサブサービス４１０、ＭＭ−ＬＭサブサービス４２０、電子メールサブサービス４３０、およびサブサービスコンテンツ４４０を有する。この最初の３つのコンポーネントは、それぞれ、セットアップ相４５０およびデータ転送相４６０という２つの別々の相に分割することができる。これらの相は、顧客のサービス知覚に直接関係するために定義される。顧客の知覚は、下位サービスまたはネットワークコンポーネントアラートの結果として生じる影響から導出される、サービス影響インデックスの形で、または単にサービスインデックスと呼ばれる形で測定される。
【００３７】
図５は、ＭＭＳ汎用パケット無線サービス（ＧＰＲＳ）コンポーネント５００を示す。これには２つの「子」コンポーネントがある。１つは、ゲートウェイＧＰＲＳサービスノード（ＧＧＳＮ）のアクセスポイント名（ＡＰＮ）インタフェースコンポーネント５１０である。もう１つが全体ＧＰＲＳネットワークコンポーネント５２０であり、これはさらに、ＧＰＲＳコア５３０、インターネットプロトコル（ＩＰ）ワイドエリアネットワーク（ＷＡＮ）すなわちＩＰ ＷＡＮ ５４０、および無線アクセスネットワーク（ＲＡＮ）５５０という、３つのサブコンポーネントに分解される。このモデルでは、ＧＰＲＳネットワークの３つのコンポーネントは、ハンドセットとＭＭＳサービスとの間の接続に関する一般性能情報のみを提供し、仮想接続固有の情報は提供しないものと想定される。固有の性能情報は、インタフェース固有のコンポーネントからのものであると想定される。
【００３８】
図６〜９は、図５に示されたＧＰＲＳネットワークを含む、ＭＭＳサービスのサービス依存関係モデルを示す図である。このモデルは、前述の３つのカテゴリ、すなわちサービス、サーバ／クラスタ、およびネットワークのコンポーネントを使用する。図を簡略化するために、最下位のネットワークコンポーネントはＨＩ（ホストおよびインタフェース）のグループにまとめられる。さらに、ここでは単一のサーバのみが示されているが、この概念はサービスクラスタにも適用可能である。加えて、地理的に異なる場所にあるが、クラスタは形成していない（すなわち、負荷共有のない）サーバが存在する場合、それらのサーバは、異なるネットワークコンポーネントによってサポート可能であるため、異なるサービスコンポーネント（以下の図には示されていない）とみなされる。
【００３９】
４つのサブサービスに対応するサービスモデルが図６〜９に示されている。図６は、依存関係グラフ形式のＭＭ−ＭＭサービスモデル６００の基本コンポーネントを示す図である。ＭＭ−ＭＭサービス６１０のセットアップ部分は、ＳＭＳおよび信号方式システム７（ＳＳ７）ネットワーク６３０、認証サーバ（ＡｕＳ）６４０、無線アクセスプロトコル（ＷＡＰ）サーバ用認証６４２、リモート認証ダイヤルインユーザサービス（ＲＡＤＩＵＳ）サーバ６４４、メッセージングアプリケーションルータ／マルチメディアメッセージサービスセンタ（ＭＡＲ／ＭＭＳＣ）６４８（およびそのコンポーネントを介してＩＰ ＷＡＮ５４０へ）、ならびに加入者データ機能（ＳＤＦ）サーバ６５０に依存する。このコンテキストでは、ＳＭＳ性能それ自体が、サービス提供ＧＰＲＳサポートノード（ＳＧＳＮ）とショートメッセージサービスセンタ（ＳＭＳＣ）インタフェースの間の信号方式インタフェース６３１、ＳＭＳＣ−ＳＳ７インタフェース６３２、ＧＳＭ性能のＳＭＳ固有コンポーネント（ＧＳＭ−ＳＭＳ固有）６３３、ＳＭＳ−ＳＳ７ネットワークの全体性能６３４、およびＳＧＳＮ性能のＳＭＳ固有コンポーネント（ＳＧＳＮ ＳＭＳ−ｓ）６３５に依存する。ＳＭＳ−ＳＳ７ネットワーク６３０は、ＲＡＮ ５５０にも依存する。ＭＭ−ＭＭセットアップコンポーネント６１０およびＭＭ−ＭＭデータ転送コンポーネント６２０は、どちらも、ＩＰローカルエリアネットワーク（ＩＰ ＬＡＮ）の全体性能６５２、マルチメディアメッセージサービスセンタ（ＭＭＳＣ）ネットワーク６５４、ＷＡＰネットワーク６５６、ならびに図５に記載されたＧＰＲＳネットワーク５００に依存する。図６では、ＨＩは図２に示されたホストクラスタおよびインタフェースを表す。
【００４０】
図７は、依存関係グラフ形式のＭＭ−ＬＭサービスモデル７００の基本コンポーネントを示す図である。ＭＭ−ＬＭセットアップ相７１０およびＭＭ−ＬＭデータ転送相７２０に関するコンポーネントは、端末ゲートウェイサーバ（ＴＧＷ）７３０への追加のそれぞれの依存関係を除き、すべて図６と同じである。
【００４１】
図８は、依存関係グラフ形式のＭＭ電子メールサービスモデル８００の基本コンポーネントを示す図である。ＭＭ電子メールセットアップ相８１０およびＭＭ電子メールデータ転送相８２０に関するコンポーネントは、メッセージ転送エージェント（ＭＴＡ）８３０への追加のそれぞれの依存関係を除き、すべて図６と同じである。
【００４２】
図９は、依存関係グラフ形式のＭＭＳコンテンツサービス９００の基本コンポーネントを示す図である。ＭＭＳコンテンツサービス９００は、ＭＭＳコンテンツサービス相９１０およびＭＭＳコンテンツデータ転送相９２０に加えて、登録相９３０を含む。ＭＭＳコンテンツセットアップ相９１０に関するすべてのコンポーネントは、図６と同じである。ＭＭＳコンテンツデータ転送９２０に関するコンポーネントは、情報コンテンツサーバ（ＩＣＳ）サーバ９４０への追加の依存関係を除き、すべて図６と同じである。登録相９３０は、ＳＭＳ−ＳＳ７ ６４０、ＳＤＦ ６５０、およびＩＰ ＷＡＮ ５４０という前述の３つのコンポーネント、ならびにＩＣＳサーバ９４０に依存する。加えて登録相９３０は、対話型音声応答（ＩＶＲ）サーバ９３２、ＧＳＭサーバ９３４、およびＩＣＳ対ＳＤＦサーバＡＰＩ（ＩＣＳ−ＡＰＩ）９３６に依存する。
【００４３】
影響を受けるサービスの識別は、サービスがどのように実施されるかおよびサービスのコンポーネントに依存する。また、サービスコンポーネントのトポロジおよび構造にもかなり依存する。表面上は、サービスのサブコンポーネント（ルータまたはサーバなど）に関連付けられた任意のＱｏＳアラートが、その性能が低下しているルータまたはサーバを使用するサービスが影響を受けていることを示唆するというように、結論付けようとしている場合がある。実際には、分析がさらに大きく関わっている。不確実さは、主に、ＩＰネットワークの自己修復または障害隠蔽機能、およびサービスの実施に組み込まれた多くの耐障害性機構の結果である。
【００４４】
簡単な例を挙げると、ルータインタフェースの障害は、ルーティングアルゴリズムによって自動的に迂回することが可能であり、その後、ルータインタフェース障害はそれ自体を容量の中のほんのわずかとして表すことが可能であり、これはトラフィック負荷に応じてエンドサービスに影響を与える場合や与えない場合がある。サービスの影響に対するＱｏＳアラートの直接の関係の矛盾を示す他の例が、サーバのロードバランシングにある。このシナリオでは、それぞれがアプリケーションのコピーを実行中の複数のサーバ間で、アプリケーションがロードバランシングされる。サービスに対する要求は、ＤＮＳラウンドロビンまたはトラフィックベース割り振りなどの、あるロードバランシングアルゴリズムに従って、複数のサーバによって処理される。サーバの１つがハード障害を示す場合、そのサーバは使用不可となり、通常は重大なアラームである。しかしながら、他のサーバは依然として適切に機能しているため、（たとえばトラフィックベースの）ロードバランシングアルゴリズムに応じて、ここですべての要求を残りの健全なサーバに向けて送ることができる。このシナリオでは、負荷が軽い場合、ここでもサービスの影響が重大でない可能性がある。
【００４５】
ソフトウェアサービスコンポーネントは、単一のアプリケーションまたはコンピュータホスト上で実行中の１片のアプリケーションを表す。サービスモデルでは、ソフトウェアコンポーネントはハードウェアホストおよび１つまたはいくつかのインタフェースに依存し、サーバクラスタコンポーネントに影響を与える。サーバソフトウェアコンポーネントの一例が、ＳＭＴＰサーバアプリケーションプログラムである。ソフトウェアコンポーネントの他の例が、ソフトウェアベースのロードバランサアプリケーションである。
【００４６】
性能アラート、負荷関係性能アラート、および可用度アラートという、いくつかの異なるタイプのアラートが、ソフトウェアコンポーネントから送出される。性能および負荷アラートはＱｏＳ性能アラートであり、負荷関係ＫＰＩ（たとえば、ホストＣＰＵ負荷、インタフェース使用率、およびクライアントトランザクション回数など）のしきい値超過によってトリガされる。これらのＫＰＩが中央値しきい値を超過した場合、サービスモデル内の影響を受けるサービスコンポーネントに性能アラートが送出され、同時に発生するすべての関係ＫＰＩしきい値超過を１つにまとめて、伝搬されるアラートにこれらを含める。
【００４７】
ＩＰ ＬＡＮサービスコンポーネント６５２は、いくつかのサーバおよびクラスタにＩＰ接続を提供するために共通インフラストラクチャとして使用されるＩＰノードの集まりを表す。エンドツーエンド、プローブ、またはＥＭＳベースのデータを使用して、これらネットワークの性能が判定される。個々のノード／インタフェース使用率データを使用して、今後の性能／可用度問題を示すネットワーク使用率が判定される。他のコンポーネントタイプの場合と同様に、関係する同時ＫＰＩしきい値超過が報告され、単一のアラートとして伝搬される。
【００４８】
サービスモデルでは、サーバクラスタコンポーネントはＩＰ ＬＡＮコンポーネントに依存して、サーバとロードバランサとの間に接続を提供する。ＬＡＮの性能、使用率、および可用度が、親サーバクラスタに影響を与える。
【００４９】
図１０は、２つのサブコンポーネントＸおよびＹで構成されるコンポーネントＡに対する本発明の高水準アーキテクチャを示す。ＫＰＩアラートは、各ＫＰＩアラートを単独で分析するのではなく、Ｘ＿ＫＰＩ：｛ｘ１，ｘ２，．．．ｘｍ｝１０１０およびＹ＿ＫＰＩ：｛ｙ１，ｙ２，．．．ｙｎ｝１０２０などのコンポーネントごとのカテゴリにグループ化される。すべてのＫＰＩアラートは、第１にコンポーネントごとにグループ化される。あるコンポーネント内のＫＰＩアラートは、可用度および性能という２つの広範なカテゴリにさらにグループ化され、それぞれが規則エンジン１０３２および１０４２を使用するために、可用度インジケータ１０３４および１０４４ならびに性能インジケータ１０３６および１０４６を作成する。可用度および性能に加えて、たとえば使用率／負荷またはセキュリティなどの他の広範なカテゴリも実施できる可能性がある。規則エンジン１０３２および１０３４は、１つまたは複数の高水準プログラミング言語で作成された規則プログラムが実行可能な、汎用プロセッサである。
【００５０】
可用度カテゴリは、コンポーネントの可用度レベルのインジケーションである。３つのレベルが定義される。レベル３では、ハードウェア障害状態などの場合、コンポーネントは完全にダウンする。レベル２では、コンポーネントは部分的にダウン、すなわちコンポーネントの一部がダウンする。レベル１では、ある統計的なダウンタイム属性がしきい値を超え、すべてのキー性能インジケータは低い値を示すが、これはコンポーネントが依然として稼働（ｕｐ）しており、すべての性能測定値で非常に低い性能が示されていることを意味する。重大度に関しては、レベル３は最も重大であり、レベル１は最も重大でない。
【００５１】
性能カテゴリは、コンポーネントの全体性能のインジケーションである。３つのレベルが定義される。レベル１では、性能はわずかに低下している。レベル２では性能は低下し、レベル３では性能はかなり低下している。
【００５２】
加えて、アラートを識別するハンドルおよびアラートを記述するテキストのオプションフィールドが定義される。これらのハンドルは、技術者がアラートの原因により効率良く対処できることになる、特定のコンポーネントからのＫＰＩ情報である。
【００５３】
コンポーネントアラートグループは、ハンドルと共に、コンポーネント状況インジケータ（ＣＳＬ＿ａｌｅｒｔグループ）を形成する。その後、ＣＳＩインジケータ１０３８および１０４８は規則処理要素１０５２と組み合わされて、コンポーネントＡに関するＣＳＩインジケータ１０５４を展開し、コンポーネントＡはコンポーネントＸおよびＹに依存する。コンポーネントＸは、レベル２の重大度の問題によって現在ダウンしているため、ＣＳＩ可用度インジケータを転送する。コンポーネントＹは、現在使用可能であるが性能はかなり低下している、すなわちレベル＝３であるため、ＣＳＩ性能インジケータを転送する。コンポーネントＡは、コンポーネントｘおよびｙから受け取ったそれらに基づいて、可用度および性能のインジケータを転送する。ＣＳＩ＿ａｌｅｒｔグループの追加の例を以下に示す。
【００５４】
ＣＳＩ＿Ｐｅｒｆ：［ＭＭＳＣ＿Ｃｌｕｓｔｅｒ：Ｐ＝（レベル３）；ＰＨ＝０１０，０５９；“首尾良く送達されたメッセージの％＜９８％”］
ＣＳＩ＿Ａｖａｉｌ：［ＩＰ ＬＡＮ：Ａ＝（レベル２＝使用不可）；ハンドル＝１２、“ルータｘがダウン”］
ＣＳＩ＿ａｌｅｒｔグループが次の上位またはアップストリームレベルで親コンポーネントに伝搬する場合、親コンポーネントは２つのタスクを実行する。第１に、親コンポーネントは、そのダウンストリームにある「子」コンポーネントからのすべてのＣＳＩおよびそのレベルで処理された任意のアラートを考慮に入れて、それ自体に関する可用度インジケータおよび性能インジケータを割り当てる。第２に、親コンポーネントは、その子の可用度および性能の両方のＣＳＩの重要度レベルを修正するかどうかを判定する。
【００５５】
ＣＳＩの可用度および性能インジケータの判定に使用される規則は、ユーザによる変更が可能である。表１は、影響を与える規則の一例である。
【００５６】
【表１】
【００５７】
規則は静的または動的とすることができる。静的規則は経時的に変化しない。動的規則は、加入者数、ある時点でのサービスの値、または地理によって、経時的に変化する可能性がある。規則は一般に、一貫性を持たせるために中央のネットワークオペレータによって作成されるが、規則が作成されているコンポーネントについて最も詳しい者の専門知識を考慮に入れるものとする。これによって、影響の分析において、またアラートの処理においても、コンポーネントに関する技術的な専門知識を使用することができる。
【００５８】
各ＣＳＩグループには持続期間が割り当てられる。この持続期間は、含まれるすべてのハンドルの最大持続期間となるように定義される。たとえば、特定のＣＳＩ性能アラートグループが、ハンドルＨ１（持続期間１時間）、Ｈ２（持続期間３０分）、およびＨ３（持続期間２時間）を含むものと想定する。このグループ内で最大持続期間を有するハンドルはＨ３である。したがって、全体ＣＳＩ性能インジケータの持続期間は２時間である。個々のハンドルの持続期間は、ハンドルが現時点まで連続して活動状態であった時間の長さである。たとえば、システムが１５分間隔でパケット損失情報を集め、そのパケット損失測定値が過去２回のサンプリング間隔で性能アラートしきい値を超えた場合、パケット損失アラートハンドルの持続期間は３０分である。
【００５９】
図１１は、本発明に従ったサービス影響分析のための高水準流れ図である。ステップ１１１０で、複数のＣＳＩアラート（Ｘ１．．．Ｘｎ）が集められ、ＣＳＩアラートが性能または可用度に影響を与えるかどうかを判定する意思決定論理に転送される。ステップ１１２０で、ＣＳＩアラートが性能または可用度に影響を与える場合、影響規則の適用を通じてアラートがサービスに影響を与えるかどうかを判定する追加の意思決定論理に転送される。アラートがサービスに影響を与えない場合、ステップ１１４０でアラートインベントリデータベースに転送および格納される。アラートインベントリは、アラートのパターンなどを探すために後で分析することができる。アラートがサービスに影響を与える場合、ステップ１１３０で影響を受けるサービスを識別するために使用される。ステップ１１５０で、影響を受けるそれぞれのサービスについて、影響を受ける顧客の数、影響を受ける特別顧客の数、影響を受ける特別サービスの数、サービス影響インデックス（ＳＩＩ）の程度、およびアラートの持続期間、というパラメータのうちの１つまたは複数を推定することによって、影響を受けるサービス上の影響が判定される。ステップ１１６０で、ステップ１１５０で集められた情報に基づいてサービス影響インデックスを生成するために規則が適用され、複数のＳＩＩ（Ｉ（ｘ１）．．．Ｉ（ｘｎ））を生成し、その後ステップ１１７０で、影響の量に基づいて優先順位リストに優先順位付けされる。この優先順位リストを使用して、ネットワークオペレータはサービスに最大の影響を与える問題にどのアラートが関係しているかを即時に識別することができる。
【００６０】
本発明の代替実施形態では、中間規則を定義しないことによって実施を簡略化することができる。これは、下位レベルのコンポーネントについてアラート「ＣＳＩ＿Ａｖａｉｌ」および「ＣＳＩ＿Ｐｅｒｆ」がいったん定義されると、サービスモデルの中間コンポーネントによって修正されることがないことを意味する。
【００６１】
ＣＳＩアラートがサービスに影響を与えるものと判定されると、サービスの品質低下に関する影響を定量化しなければならない。サービス影響インデックス（ＳＩＩ）は、事前に定義されたＫＱＩセットの重み付け合計として定義することができる。図１２は、この判定のためのプロセス流れを示す図である。ステップ１２１０で、影響を受けるそれぞれのサービスのそれぞれのコンポーネントへのＫＱＩ影響が判定される。ステップ１２２０で、それぞれのコンポーネントへのＫＱＩ影響の合計が算出される。ステップ１２３０で、影響を受けるユーザの数、アラートの持続期間、特別サービスへの影響などの情報に基づいた重み付け要素を使用して、ＫＱＩ影響の合計に重み付けする。これらの重み付けおよび合計されたＫＱＩ影響が、その後、前述のように優先順位付け可能なサービス影響インデックスになる。
【００６２】
本発明の方法の主要な要素について以下に要約して記載する。サービスの異なる相によって動かされるサービス依存関係モデルの作成は、サービス全体の１コンポーネントに過ぎない最下位のネットワークコンポーネントでのアラートが、サービス全体にどのように影響を与えるかを理解できるようになる上で重要である。アラートには「ハンドル」および重大度レベルが割り当てられる。各コンポーネントに対するコンポーネント状況インジケータを作成するためにアラートに適用される規則が定義される。各ＣＳＩがサービスモデル依存関係グラフのトップに向かって上方に伝搬されるにつれて、各ＣＳＩは事前に定義された規則に従って修正される。
【００６３】
ＣＳＩがトップのサービスコンポーネントに伝搬される際に、サービス影響インデックスが作成される。影響を受けるそれぞれのサービスについて、アラートの持続期間、加入者の数、サービスの数、影響を受けるサービスのＱｏＳクラス、またはユーザによって定義される他の要素に従って、重み（乗数）が定義される。重みは、ＳＩＩを乗算して全体の影響インデックスを得るために使用され、このインデックスがソートされて優先順位リストが得られる。
【００６４】
優先順位付け用の主要な重みは以下の通りである。サービスインデックスは（セットアップおよびデータ転送からの）ＫＱＩの影響レベルから算出される。ＳＩは各サブサービスについて別々に算出しなければならず、結果をすべて加算してサービス影響インデックスが形成される。
【００６５】
加入者インデックスの数は、加入者数の重要性を表す数である。未処理の（ｏｕｔｓｔａｎｄｉｎｇ）アラートの持続期間は、サンプリング期間に関して定義される。問題が矯正されると、アラートは除去されると予測される。長い未処理のアラートには、アラートを新しくするより多くの重みが与えられる。１〜３のインデックスは持続期間の重みを表すために使用される。サービスの数はＣＳＩごとに識別され、合計影響は影響を受けるすべてのサービスに依存する。すべての重みが算出された後、特定のＣＳＩについての単一のインデックスが得られる。表２および３は、複数のサービスにわたる個々のサービス影響インデックスの重み付け合計に基づいた、合計影響インデックスの計算を示す。
【００６６】
【表２】
【００６７】
【表３】
【００６８】
前述の方法を拡張して、ネットワークオペレータがアラート優先順位付けおよびサービス影響分析中に生成された情報を根本原因分析のために使用できるようにすることが可能である。根本原因分析（ＲＣＡ）は、１つまたは複数のアラートの根本原因を識別する問題に対処する。この問題は、前述のサービス影響分析およびアラート優先順位付けの逆である。サービス影響分析およびアラーム優先順位付けでは、サービスモデル依存関係グラフの各レベルで生成されたＣＳＩが、次のレベルで追加のＣＳＩを作成するために使用され、トップレベルでサービス影響インデックスを生成するために使用される。障害のサービス影響およびサービスの低下が識別され、アラートが優先順位付けされると、ネットワークオペレータによる根本原因の診断およびサービスの復元によって、問題修復の問題に対処することができる。この方法はＲＣＡを支援し、追加の診断テストの必要性を最小限にする。パスに沿ってサービスモデル依存関係グラフ内を上方に、サービス影響分析およびそれに続くアラート優先順位付けをドリルダウンしていくこと、および１つまたは複数のＣＳＩに含まれるアラートに関連付けられたハンドルを参照することによって、ネットワークオペレータは、サービスモデル依存関係グラフの最も可能性の高い最下位層での、ネットワーク障害またはサービス低下の最も可能性の高い原因を識別することができる。
【００６９】
サービスモデル依存関係グラフのコンポーネントへのデータ入力は、（１）そのコンポーネントに関するアラートシステムからのアラート、（２）ダウンストリームの「子」コンポーネントからのＣＳＩ、および（３）プローブ、ＥＭＳ、またはＮＭＳ）などのデータ収集エージェントから収集された性能データからなる。前述のように、上記入力はすべて、各コンポーネントについて規則セットを使用して処理される。この規則は、そのレベルでのＣＳＩを発行するかどうかを判定し、これはその後アップストリームレベルまたは「親」コンポーネントによって使用可能である。規則エンジンがそのＣＳＩを発行すべきであると判定する場合は、ある規則に合致したためである。規則に合致しない場合、アラートは抑制され、これは検査を受けたアラートがサービス問題を引き起こさないことを意味する。このアラートのコンポーネントレベルのフィルタリングにより、さらにアップストリームでの不必要な処理がなくなる。したがって、コンポーネント内での規則の実行は、潜在的な性能問題のローカル診断である。規則実行の結果により、サービスおよびシステムレベルの根本原因診断に使用可能な、価値ある情報が提供される。ネットワークオペレータは、ＣＳＩのハンドルコンポーネントおよびハンドル伝搬を介して、この情報を根本原因分析に使用することができる。
【００７０】
図１３を参照すると、コンポーネント４−１ １３１０内の規則が満たされたために、コンポーネント４−１ １３１０のアラート１は、コンポーネント４−１で搬送されるＣＳＩ＿４−１（ｈ１）のハンドルｈ１になる。この時点で、以下の表４で説明するように、ＣＳＩ＿４−１に関する情報がＣＳＩテーブルに記録される。ＣＳＩテーブルは、ＣＳＩ ＩＤ、ハンドル、タイムスタンプ、および合致した規則を識別する。ＣＳＩ＿４−１は、性能データおよびＣＳＩ＿４−１を、コンポーネント３−１ １３４０へとアップストリームに伝搬し、ここでは異なる規則セットが、アラート２によって提供されるようなアラート情報を使用して、いずれかの規則が合致したかどうかを判定する。他の規則条件のうちの１つが満たされる場合、表４などのＣＳＩテーブルに格納された関連情報と共にＣＳＩ＿３−１が発行される。アラート２は、ＣＳＩ＿３−１内のハンドル２（ｈ２）となる。
【００７１】
コンポーネント４−２ １３２０、コンポーネント４−３ １３３０、コンポーネント３−３ １３６０、またはコンポーネント２−２ １３８０などのいくつかのコンポーネントでは、規則によってＣＳＩを伝搬させるアラートがない可能性がある。同様の規則処理は、規則およびアラート３に基づいてハンドルｈ３を伴うＣＳＩ＿３−２（ｈ３）が生成されるコンポーネント３−２ １３５０と、規則セットならびに「子」コンポーネント３−１および３−２からのＣＳＩに基づいてＣＳＩ＿２−１（ｈ１、ｈ２、ｈ３）が生成されるコンポーネント２−１ １３７０などの、他のコンポーネントでも発生する。ｈ１およびｈ２などのハンドルが新しいＣＳＩの生成と並行して伝搬される場合、逆のパスに関する情報がハンドルに追加されることになるため、ＣＳＩは以下のように表される。
【００７２】
ＣＳＩ＿２−１＝（．．．．．ｈ１（パス＝２−１、３−１、４−１）、ｈ２（パス＝２−１、３−１）、ｈ３（パス＝２−１、３−２）
ハンドルのパスＩＤはコンポーネントＩＤを与え、これと並行してハンドルが伝搬される。別のテーブルが、ハンドルおよびその対応するアラート、しきい値、違反回数などに関する情報を格納する。ハンドルテーブルは、他のドリルダウンアクションが所望される場合、ＣＳＩの性質に関する他の情報を提供する。コンポーネント２−１ １３７０からのＣＳＩを使用して、コンポーネント１−１ １３９０で、トップレベルＣＳＩおよびサービス影響分析を展開することができる。
【００７３】
【表４】
【００７４】
根本原因分析時に、トップレベルへと進むハンドルは、根本原因の分析に関するすべての関連する相関情報を容易に取り出すための情報を担持する。この情報は、多くの根本原因分析が含まれるため、ネットワークオペレータまたはトラブルシュータにとって特に有用である。
【００７５】
前述の方法は、一部の規則の適用およびＣＳＩアラートの生成を中央オフィスに実行させることにより、サービスレベル管理機能の一部としてネットワークオペレーションセンタで、サービスビューロとして、または配布物で、実施可能である。規則は、多くの異なるプログラミング言語で１つまたは複数のプロセッサを汎用コンピュータ上で実行するために実施可能である。オフィスまたはオフィスの近くに配置されたコンポーネントに関する規則を実行するネットワークオペレーションセンタおよび中央オフィスプロセッサは、異なるプログラミング言語で作成された異なる規則セットを実行することができる。重要な要素は、ＣＳＩのフォーマット、およびＣＳＩのフォーマットを介してダウンストリームプロセッサがアップストリームプロセッサと通信する機能である。また、アラートまたはＣＳＩのいずれかを、サービスモデル依存関係グラフのダウンストリームレベルからアップストリームレベルへと渡すためには、コンポーネント間に通信パスが必要であり、こうしたパスは直接物理接続、またはインターネットなどのネットワーク接続を介した仮想接続である。
【００７６】
前述の記述は、本発明を例示および説明するためにのみ提示したものである。本発明を網羅すること、または本発明を開示された任意の精密な形式に限定することは意図していない。上記の教示に鑑みて、多くの修正形態および変形形態が可能である。記載された明細書は、当業者が様々な応用例で、および企図された特定の用途に好適な様々な修正形態で、本発明を最も適切に使用できるように、本発明の原理およびその実際の応用例を最も良く説明するために選択および説明された。
【図面の簡単な説明】
【００７７】
【図１】サービスモデル依存関係グラフの一例を示す図である。
【図２】ロードバランシングされたサーバクラスタのサービスモデルの一例を示す図である。
【図３】ネットワークコンポーネントのサービスモデルの一例を示す図である。
【図４】ＭＭＳサービスに関する高水準サービスモデル依存関係グラフを示す図である。
【図５】ＭＭＳサービスのＭＭＳ汎用パケット無線サービス（ＧＰＲＳ）コンポーネントに関するサービスモデル依存関係グラフを示す図である。
【図６】ＭＭＳのＭＭ−ＭＭ部分を含む基本コンポーネントの依存関係グラフを示す図である。
【図７】ＭＭＳサービスのＭＭ−ＬＭ部分を含む基本コンポーネントの依存関係グラフを示す図である。
【図８】ＭＭＳサービスのＭＭ−Ｅメール部分を含む基本コンポーネントの依存関係グラフを示す図である。
【図９】ＭＭＳサービスのＭＭＳコンテンツ部分を含む基本コンポーネントの依存関係グラフを示す図である。
【図１０】本発明のアラート優先順位付けシステムの高水準アーキテクチャを示す図である。
【図１１】本発明のアラート優先順位付けおよびサービス影響分析方法のプロセス流れを示す図である。
【図１２】本発明のサービス影響分析方法のプロセス流れを示す図である。
【図１３】サービスモデル依存関係グラフにおける様々なコンポーネントレベルでのコンポーネント状況インジケータ（ＣＳＩ）の生成を介したハンドルの伝搬のグラフを示す図である。
【特許請求の範囲】
【請求項１】
アップストリームおよびダウンストリームのコンポーネントを示すネストされたレベルセットに複数のコンポーネントを有するサービスモデル依存関係グラフによって表される遠隔通信ネットワークにおいて、アラートを処理するための方法であって
コンポーネントに関する１つまたは複数のアラートを受信するステップと、
受信された各アラートに関して、前記アラートに関する情報を含むハンドルを生成するステップと、
ダウンストリームコンポーネントのコンポーネント状況インジケータを利用する事前に定義された規則のセットと、前記コンポーネントで受信されたアラートから生成された前記ハンドルからの情報とに基づいて、前記コンポーネントに関するコンポーネント状況インジケータを生成するステップと、
前記規則評価の結果と、前記規則評価に使用されるハンドルと、前記ダウンストリームコンポーネントの前記コンポーネント状況インジケータとを、前記コンポーネントに関する前記コンポーネント状況インジケータに関連付けるステップと
を備えることを特徴とするアラートを処理するための方法。
【請求項２】
前記コンポーネント状況インジケータに、前記サービスモデル依存関係グラフを介して各ハンドルが通るパスを関連付けるステップをさらに備えることを特徴とする請求項１に記載の方法。
【請求項３】
前記ハンドルは、アラートのタイプ、アラートの時間、およびアラートの持続期間に関する情報を含むことを特徴とする請求項１に記載の方法。
【請求項４】
前記サービスモデル依存関係グラフのトップレベルでサービス影響インデックスを生成するステップであって、前記サービス影響インデックスはサービスの品質に対するダウンストリームアラートの影響のインジケータである、生成するステップをさらに備えることを特徴とする請求項１に記載の方法。
【請求項５】
複数のサービスに関する前記サービス影響インデックスを合計することによって、合計影響インデックスを生成するステップをさらに備えることを特徴とする請求項４に記載の方法。
【請求項６】
前記合計影響インデックスは、所定の重み付け要素と掛け合わされた各サービスに関する前記サービス影響インデックスを合計することによって算出されることを特徴とする請求項５に記載の方法。
【請求項７】
サービス影響コンポーネント状況インジケータに関して根本原因分析を実行するステップをさらに備えることを特徴とする請求項２に記載の方法。
【請求項８】
サービス影響コンポーネント状況インジケータに関して根本原因分析を実行するステップは、
前記サービスモデル依存関係グラフを介して前記サービス影響ハンドルが通る前記パスを取り出すステップと、
前記サービス影響ハンドルが通る各コンポーネントで、前記コンポーネント状況インジケータに関連付けられた前記情報と、前記コンポーネントに関する前記関連付けられたハンドルとを取り出すステップと
を備えることを特徴とする請求項７に記載の方法。
【請求項９】
前記サービス影響インデックスに基づいて前記アラートの前記影響を優先順位付けするステップをさらに備えることを特徴とする請求項４に記載の方法。
【請求項１０】
前記合計影響インデックスに基づいて前記アラートの前記影響を優先順位付けするステップをさらに備えることを特徴とする請求項５に記載の方法。
【請求項１１】
１つまたは複数のコンポーネントに関するコンポーネント状況インジケータを生成するステップは、前記コンポーネントを収容する中央オフィス内で実行されることを特徴とする請求項１に記載の方法。
【請求項１２】
コンポーネント状況インジケータを生成するステップは、中央ネットワークオペレーションセンタ内で実行されることを特徴とする請求項１に記載の方法。
【請求項１３】
合計影響インデックスを生成し前記アラートの影響を優先順位付けするステップは、中央ネットワークオペレーションセンタ内で実行されることを特徴とする請求項１０に記載の方法。
【請求項１４】
サービスに影響を与えないアラートをアラートインベントリ内に格納するステップをさらに備えることを特徴とする請求項１に記載の方法。
【請求項１５】
アップストリームおよびダウンストリームのレベルセットに複数のコンポーネントを有するサービスモデル依存関係グラフとしてモデル化される遠隔通信ネットワークにおいてアラートを処理するためのシステムであって、
前記ネットワークのコンポーネントでアラートを受信するための手段と、
各アラートに応答して、前記アラートに関する情報を提供するハンドルを生成するための手段と、
１つまたは複数のダウンストリームコンポーネントのコンポーネント状況インジケータと、各コンポーネントに関するコンポーネント状況インジケータを生成するためにアラートに応答して生成される前記ハンドルとを利用する、規則エンジンと、
前記規則評価の結果と、前記規則評価に使用される前記ハンドルと、前記ダウンストリームコンポーネントの前記コンポーネント状況インジケータとを、各コンポーネントに関する前記コンポーネント状況インジケータに関連付けるための手段と
を備えたことを特徴とするシステム。
【請求項１６】
前記規則エンジンは前記コンポーネントに常駐することを特徴とする請求項１５に記載のシステム。
【請求項１７】
各コンポーネントと通信するネットワークオペレーションセンタをさらに備え、前記規則エンジンは、各コンポーネントに関する前記コンポーネント状況インジケータを生成するために前記規則評価を実行することを特徴とする請求項１５に記載のシステム。
【請求項１８】
前記ネットワークオペレーションセンタは、根本原因分析を実行するために前記ハンドル内の前記アラート情報を使用するための手段をさらに含むことを特徴とする請求項１７に記載のシステム。
【請求項１９】
前記ネットワークオペレーションセンタは、前記サービスモデル依存関係グラフのトップレベルに達するアラートのサービス品質影響を示すサービス影響インデックスを生成するための手段をさらに含むことを特徴とする請求項１７に記載のシステム。
【請求項２０】
前記ネットワークオペレーションセンタは、複数のサービスにわたって前記サービス品質への影響を示す合計影響インデックスを生成するための手段をさらに含むことを特徴とする請求項１９に記載のシステム。
【請求項１】
アップストリームおよびダウンストリームのコンポーネントを示すネストされたレベルセットに複数のコンポーネントを有するサービスモデル依存関係グラフによって表される遠隔通信ネットワークにおいて、アラートを処理するための方法であって
コンポーネントに関する１つまたは複数のアラートを受信するステップと、
受信された各アラートに関して、前記アラートに関する情報を含むハンドルを生成するステップと、
ダウンストリームコンポーネントのコンポーネント状況インジケータを利用する事前に定義された規則のセットと、前記コンポーネントで受信されたアラートから生成された前記ハンドルからの情報とに基づいて、前記コンポーネントに関するコンポーネント状況インジケータを生成するステップと、
前記規則評価の結果と、前記規則評価に使用されるハンドルと、前記ダウンストリームコンポーネントの前記コンポーネント状況インジケータとを、前記コンポーネントに関する前記コンポーネント状況インジケータに関連付けるステップと
を備えることを特徴とするアラートを処理するための方法。
【請求項２】
前記コンポーネント状況インジケータに、前記サービスモデル依存関係グラフを介して各ハンドルが通るパスを関連付けるステップをさらに備えることを特徴とする請求項１に記載の方法。
【請求項３】
前記ハンドルは、アラートのタイプ、アラートの時間、およびアラートの持続期間に関する情報を含むことを特徴とする請求項１に記載の方法。
【請求項４】
前記サービスモデル依存関係グラフのトップレベルでサービス影響インデックスを生成するステップであって、前記サービス影響インデックスはサービスの品質に対するダウンストリームアラートの影響のインジケータである、生成するステップをさらに備えることを特徴とする請求項１に記載の方法。
【請求項５】
複数のサービスに関する前記サービス影響インデックスを合計することによって、合計影響インデックスを生成するステップをさらに備えることを特徴とする請求項４に記載の方法。
【請求項６】
前記合計影響インデックスは、所定の重み付け要素と掛け合わされた各サービスに関する前記サービス影響インデックスを合計することによって算出されることを特徴とする請求項５に記載の方法。
【請求項７】
サービス影響コンポーネント状況インジケータに関して根本原因分析を実行するステップをさらに備えることを特徴とする請求項２に記載の方法。
【請求項８】
サービス影響コンポーネント状況インジケータに関して根本原因分析を実行するステップは、
前記サービスモデル依存関係グラフを介して前記サービス影響ハンドルが通る前記パスを取り出すステップと、
前記サービス影響ハンドルが通る各コンポーネントで、前記コンポーネント状況インジケータに関連付けられた前記情報と、前記コンポーネントに関する前記関連付けられたハンドルとを取り出すステップと
を備えることを特徴とする請求項７に記載の方法。
【請求項９】
前記サービス影響インデックスに基づいて前記アラートの前記影響を優先順位付けするステップをさらに備えることを特徴とする請求項４に記載の方法。
【請求項１０】
前記合計影響インデックスに基づいて前記アラートの前記影響を優先順位付けするステップをさらに備えることを特徴とする請求項５に記載の方法。
【請求項１１】
１つまたは複数のコンポーネントに関するコンポーネント状況インジケータを生成するステップは、前記コンポーネントを収容する中央オフィス内で実行されることを特徴とする請求項１に記載の方法。
【請求項１２】
コンポーネント状況インジケータを生成するステップは、中央ネットワークオペレーションセンタ内で実行されることを特徴とする請求項１に記載の方法。
【請求項１３】
合計影響インデックスを生成し前記アラートの影響を優先順位付けするステップは、中央ネットワークオペレーションセンタ内で実行されることを特徴とする請求項１０に記載の方法。
【請求項１４】
サービスに影響を与えないアラートをアラートインベントリ内に格納するステップをさらに備えることを特徴とする請求項１に記載の方法。
【請求項１５】
アップストリームおよびダウンストリームのレベルセットに複数のコンポーネントを有するサービスモデル依存関係グラフとしてモデル化される遠隔通信ネットワークにおいてアラートを処理するためのシステムであって、
前記ネットワークのコンポーネントでアラートを受信するための手段と、
各アラートに応答して、前記アラートに関する情報を提供するハンドルを生成するための手段と、
１つまたは複数のダウンストリームコンポーネントのコンポーネント状況インジケータと、各コンポーネントに関するコンポーネント状況インジケータを生成するためにアラートに応答して生成される前記ハンドルとを利用する、規則エンジンと、
前記規則評価の結果と、前記規則評価に使用される前記ハンドルと、前記ダウンストリームコンポーネントの前記コンポーネント状況インジケータとを、各コンポーネントに関する前記コンポーネント状況インジケータに関連付けるための手段と
を備えたことを特徴とするシステム。
【請求項１６】
前記規則エンジンは前記コンポーネントに常駐することを特徴とする請求項１５に記載のシステム。
【請求項１７】
各コンポーネントと通信するネットワークオペレーションセンタをさらに備え、前記規則エンジンは、各コンポーネントに関する前記コンポーネント状況インジケータを生成するために前記規則評価を実行することを特徴とする請求項１５に記載のシステム。
【請求項１８】
前記ネットワークオペレーションセンタは、根本原因分析を実行するために前記ハンドル内の前記アラート情報を使用するための手段をさらに含むことを特徴とする請求項１７に記載のシステム。
【請求項１９】
前記ネットワークオペレーションセンタは、前記サービスモデル依存関係グラフのトップレベルに達するアラートのサービス品質影響を示すサービス影響インデックスを生成するための手段をさらに含むことを特徴とする請求項１７に記載のシステム。
【請求項２０】
前記ネットワークオペレーションセンタは、複数のサービスにわたって前記サービス品質への影響を示す合計影響インデックスを生成するための手段をさらに含むことを特徴とする請求項１９に記載のシステム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【公表番号】特表２００７−５２２７７０（Ｐ２００７−５２２７７０Ａ）
【公表日】平成１９年８月９日（２００７．８．９）
【国際特許分類】
【出願番号】特願２００６−５５３２６７（Ｐ２００６−５５３２６７）
【出願日】平成１７年２月１１日（２００５．２．１１）
【国際出願番号】ＰＣＴ／ＵＳ２００５／００４３８５
【国際公開番号】ＷＯ２００５／０７９２９２
【国際公開日】平成１７年９月１日（２００５．９．１）
【出願人】（３９９０４７９２１）テルコーディア テクノロジーズ インコーポレイテッド (61)
【Ｆターム（参考）】
【公表日】平成１９年８月９日（２００７．８．９）
【国際特許分類】
【出願日】平成１７年２月１１日（２００５．２．１１）
【国際出願番号】ＰＣＴ／ＵＳ２００５／００４３８５
【国際公開番号】ＷＯ２００５／０７９２９２
【国際公開日】平成１７年９月１日（２００５．９．１）
【出願人】（３９９０４７９２１）テルコーディア テクノロジーズ インコーポレイテッド (61)
【Ｆターム（参考）】
[ Back to top ]