JP2004104173A

JP2004104173A - Operation system, alarm monitoring apparatus, and alarm monitoring method

Info

Publication number: JP2004104173A
Application number: JP2002259249A
Authority: JP
Inventors: Takeshi Makino; 牧野　雄至; Kazuhide Takahashi; 高橋　和秀; Nobuhiro Tanigawa; 谷川　延広
Original assignee: NTT Docomo Inc
Current assignee: NTT Docomo Inc
Priority date: 2002-09-04
Filing date: 2002-09-04
Publication date: 2004-04-02

Abstract

<P>PROBLEM TO BE SOLVED: To provide an operation system capable of extending the number of accommodated NEs while realizing real time alarm processing. <P>SOLUTION: The operation system for managing a plurality of and many kinds of network elements (NEs) configuring a communication network includes: databases distributingly provided for storing alarms notified by the network elements; and an alarm content type distributed storage means for sharing and storing the alarms to the distributed databases. <P>COPYRIGHT: (C)2004,JPO

Description

【０００１】
【発明の属する技術分野】
本発明は、複数、かつ多種類のネットワークエレメント（交換機、伝送装置）の保守を支援するオペレーションシステムに関する。
【０００２】
【従来の技術】
通信ネットワークを構成する無線系装置、交換機、伝送装置等のネットワークエレメント（以下、ＮＥという）は、一般に、オペレーションシステムによる設備監視がなされている。
【０００３】
従来のオペレーションシステムは、各ＮＥからの警報を収集・集約して種々の処理を行なうサーバ（本サーバは、警報集約サーバあるいはＮＥ集約サーバと呼ばれるが本例では、ＮＥ集約サーバを用いる）を設け、本ＮＥ集約サーバを介して各ＮＥからの警報を操作卓等のディスプレイに表示させるようにしている（例えば、非特許文献１参照）。これにより、保守者は、全てのＮＥからの警報の発生状況を把握することが可能となっている。
【０００４】
ＮＥ集約サーバは、各ＮＥからの警報（自律メッセージを含む）を受信すると、所定の処理を施して当該警報を保守端末に表示させて保守者に通知するが、ＮＥ集約サーバには、同時刻に複数のＮＥから複数の警報が通知され、警報内容（例：警報レベル）も保守者によっていくつかに分類されている。以下に、警報レベルの種類を示す。
（警報レベルの種類）
▲１▼緊急性が非常に高く迅速なアクションを必要とするレベルの警報（以下、最緊急メッセージという）
▲２▼緊急性が高く一次切り分けなどの一次措置を実施する必要があるレベルの警報（以下、緊急メッセージという）
▲３▼緊急性は高くなく、リアルタイム措置が必要ないレベルの警報（以下、エラーメッセージという）
▲４▼予防保全的な観点で、リアルタイム監視の必要がないレベルの警報（以下、通常メッセージという）
図９は、従来のオペレーションシステムにおけるＮＥからの警報処理を概略的に示す図である。同図に示すオペレーションシステムでは、前述したＮＥ集約サーバ１００による警報処理が行なわれる。以下、ＮＥ集約サーバ１００にて行なわれる従来の警報処理について説明する。尚、ここでは、ＮＥ集約サーバ１００に複数のＮＥ（ＮＥ＃１〜ＮＥ＃ｎ）が収容されていると仮定する。
【０００５】
複数のＮＥ、すなわちＮＥ＃１〜ＮＥ＃ｎから発せられた警報は、まず、ＮＥインターフェース（ＮＥ　Ｉ／Ｆ）１０１で受信される。ＮＥインターフェース１０１は、複数のＮＥから受信した警報を受信した順番で警報受信部１０２（警報受信プロセスとも呼ばれる）に通知する。ここで「プロセス」とは実行されているプログラムのことをいう。警報受信部１０２は、ＮＥ数分備えられ、各ＮＥからの警報は該当する警報受信部でそれぞれ受信された後、ジャーナルデータベース登録部１０３（ジャーナルデータベース登録プロセスとも呼ばれる）及び保守端末通信部１０４（保守端末通信プロセスとも呼ばれる）へと通知される。ジャーナルデータベース登録部１０３は、ＮＥグループ（一定のＮＥ数の集合が１ＮＥグループ）分備えられ、そのＮＥグループに属するＮＥからの警報を受信した警報受信部から出力された警報が、該当ＮＥグループのジャーナルデータベース登録部において受信される。ジャーナルデータベース登録部１０３は、受信した警報を受信した順に従ってジャーナル履歴データベース（ＤＢ）１０５に書き込む。また、警報受信機部１０２から出力された警報は、保守端末通信部１０４（保守端末通信プロセスとも呼ばれる）にも出力され、保守端末通信部１０４において該当の保守端末２００に対する警報のリアルタイム通知がなされる。尚、上記警報受信部１０２、ジャーナルデータベース登録部１０３、及び保守端末通信部１０４は、前述したようにＮＥ集約サーバ上のＯＳによって管理されるプロセス（ＯＳによってはタスクともいう）であり、プロセス間通信により情報の授受が行なわれる。また、警報受信部１０２及びジャーナルデータベース登録部１０３は、システム起動時に常時動作している常駐型のプロセスとなっている。
【０００６】
上記のように各ＮＥからの警報は、ジャーナル履歴ＤＢ１０５に蓄積されるが、従来は、同一のデータベースに全ＮＥからの警報が蓄積される。図１０及び図１１は、従来のオペレーションシステムにおいてＮＥからの警報を同一のジャーナル履歴ＤＢに蓄積させる例を示した概略図である。図１０と図１１の違いは、ジャーナルデータベース登録部が一つか複数かの違いで動作は前述した図９と同様である。すなわち、図１０を例にとれば、ぞれぞれの警報受信部１１４〜１１６で受信された各ＮＥからの警報が一つのジャーナルデータベース登録部１１７にて順次受信される。ジャーナルデータベース登録部１１７は、警報を受信した順にジャーナル履歴ＤＢ１１８へ書き込む。一方、図１１の場合は、ジャーナルデータベース登録部１２１、１２２が複数（ここでは、ｎ個）備えられ、ｎ個のジャーナルデータベース登録部１２１、１２２が同時に起動する。それぞれのジャーナルデータベース登録部１２１、１２２は該当する警報受信部１１４〜１１６からの警報を受信した時点で、順次、ジャーナル履歴ＤＢ１１８への警報の書き込みを行なう。
【０００７】
また、従来のオペレーションシステムにおいて、頻繁に上がってくる自律警報通知を監視プロセスで即監視画面に表示させるか否かを判断することで、自律警報通知のリアルタイム受信を可能とするものもある（例えば、特許文献１参照）。
【０００８】
【特許文献１】
特開平１１−１２２３２６
【非特許文献１】
立川敬二監修「Ｗ−ＣＤＭＡ移動通信方式」丸善出版、２００１年６月２５日、ｐ．３０６。
【０００９】
【発明が解決しようとする課題】
しかしながら、上述した従来のオペレーションシステムは、下記記載の問題点を有している。
【００１０】
例えば、図９において、ＮＥ集約サーバ１００におけるジャーナル履歴ＤＢ１０５への警報の蓄積処理については、現実的にはレベルの低い警報が全体の９割を超えるにもかかわらず、各ＮＥから通知された全ての警報について、警報レベルに関係なく同一の処理が行なわれる。すなわち、レベルの低い警報が瞬間的に大量に集中して発生するにもかかわらず、同一の蓄積処理が行なわれるので、ジャーナル履歴ＤＢ１０５への警報の書き込み時においてＩ／Ｏ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ：入出力）処理遅延が発生し、警報の蓄積処理待ちキューが滞留する。この結果、メモリ不足に陥り、システムの処理性能が劣化するため、リアルタイムな警報処理が困難となり、システムの運用性に大きなダメージを与えていた。
【００１１】
また、メモリ不足の発生、すなわちシステムリソース不足により、ＮＥ集約サーバ１００における収容可能ＮＥ数が制約されてしまい、ＮＥの収容数を増加させるには、ＮＥ集約サーバ１００を増設しなければならない。しかし、その場合、ハードウェアコストの増大を招いてしまう。
【００１２】
また、レベルの高い警報については、一定期間ジャーナル履歴ＤＢ１０５への蓄積が必要となるが、全体の警報のうち、レベルの低い警報が大半を占めるため、ジャーナル履歴ＤＢ１０５の容量としては、レベルの低い警報の情報量も含めたデータベース容量が必要となる。すなわち、レベルの低い警報のデータ量がデータベース容量の相当を占めてしまうため、収容可能なＮＥ数が制約されてしまう。また、警報の保守者への通知については、全ての警報について通知がなされるので、レベルの高い警報がレベルの低い警報に埋もれてしまう可能性が高くなり、ＮＥ重大故障時の警報の見落としによるサービス品質の低下という悪影響を及ぼす恐れがある。
【００１３】
さらに、図１０及び図１１に示したように、各ＮＥからの警報の蓄積処理が同一のジャーナル履歴ＤＢ１１８に対して行なわれるので、ジャーナルデータベース登録部を複数設けて、同時に起動して蓄積処理するような場合であっても、低レベル警報の輻輳によりジャーナルデータベース登録部におけるキュー溜りによるメモリ不足の発生により、リアルタイムな警報処理ができなくなる。
【００１４】
本発明は、上記のような問題点に鑑みてなされたもので、その課題とするところは、リアルタイムな警報処理を実現しつつ、収容ＮＥ数を拡大させることが可能なオペレーションシステムを提供することである。
【００１５】
【課題を解決するための手段】
上記課題を解決するため、本発明は、警報内容により、ネットワークエレメントからの警報を蓄積するデータベースを分散させて格納することを特徴とする。具体的には、請求項１に記載されるように、通信ネットワークを構成する複数、かつ多種類のネットワークエレメント（ＮＥ）を管理するオペレーションシステムにおいて、前記ネットワークエレメントから通知される警報を蓄積するデータベースを分割して設け、前記警報で表される警報内容に応じて、該警報を前記分割したデータベースに振り分けて蓄積させる警報内容型分散蓄積手段を備えたことを特徴としている。
【００１６】
また、本発明の請求項２は、前記オペレーションシステムにおいて、前記データベースは、前記警報内容から特定される警報レベルに基づいて分割されることを特徴としている。
【００１７】
また、本発明の請求項３は、前記オペレーションシステムにおいて、前記警報内容と警報番号とを対応付けたテーブルと、前記ネットワークエレメントからの警報の通知があった際に、前記テーブルに基づき、その警報の重要度を警報レベルの高低として判断する警報レベル判断手段とを備え、前記警報内容型分散蓄積手段は、前記警報レベル判断手段での判断結果に基づいて、前記通知があった警報を前記分割したデータベースのいずれに振り分けて蓄積させることを特徴としている。
【００１８】
また、本発明の請求項４は、前記オペレーションシステムにおいて、前記警報レベル判断手段は、前記テーブルの参照により、前記ネットワークエレメントから通知された警報の警報内容が警報番号のある警報内容であるとの参照結果が得られれば、その警報内容を低レベル警報と判断し、そうでなければ、その警報内容を高レベル警報として判断することを特徴としている。
【００１９】
また、本発明の請求項５は、前記オペレーションシステムにおいて、前記警報レベル判断手段は、前記テーブルの参照により、前記ネットワークエレメントから通知された警報の警報内容が低レベル警報であると判断した場合、その警報をバッファに蓄積するバッファ蓄積手段を備え、前記警報内容型分散蓄積手段は、前記バッファ蓄積手段に蓄積されている警報を所定のタイミングで前記分割したデータベースのうちの低レベル警報を蓄積するデータベースに蓄積させる低レベル警報登録手段を備えたことを特徴としている。
【００２０】
また、本発明の請求項６は、前記オペレーションシステムにおいて、前記警報内容型分散蓄積手段は、前記警報レベル判断手段にて、前記ネットワークエレメントから通知された警報の警報内容が高レベル警報であると判断された場合、その警報の警報内容を所定の端末装置に出力して表示させる高レベル警報表示手段を備えたことを特徴としている。
【００２１】
また、本発明の請求項７は、前記オペレーションシステムにおいて、前記警報内容型分散蓄積手段は、前記警報レベル判断手段にて、前記ネットワークエレメントから通知された警報の警報内容が高レベル警報であると判断された場合に、その警報を所定のタイミングで前記分割したデータベースのうちの高レベル警報を蓄積するデータベースに蓄積させる高レベル警報登録手段を備えたことを特徴としている。
【００２２】
また、本発明の請求項８は、前記オペレーションシステムにおいて、前記警報内容型分散蓄積手段は、前記バッファ手段に蓄積されている同レベルの警報件数が所定件数に達したとき、若しくは所定時間経過したかどうかを判定する低レベル警報蓄積タイミング判定手段を備え、前記警報蓄積タイミング判定手段により、前記バッファ手段に蓄積されている同レベルの警報件数が所定件数に達した、若しくは所定時間が経過したと判定されたときに、前記バッファ蓄積手段に蓄積されている警報を前記分割したデータベースのうちの低レベル警報を蓄積するデータベースに蓄積させることを特徴としている。
【００２３】
また、本発明は、ネットワークエレメント毎に警報を蓄積するデータベースを分散させて格納することを特徴とする。具体的には、請求項１６に記載されるように、通信ネットワークを構成する複数、かつ多種類のネットワークエレメント（ＮＥ）を管理するオペレーションシステムにおいて、前記ネットワークエレメントから通知される警報を蓄積するデータベースの格納領域をパーティション毎にｎ分割するデータベース分割手段と、前記ｎ分割されたデータベースに収容されるネットワークエレメントを該ｎ分割されたデータベースに蓄積されているデータ量に応じて該ｎ分割されたデータベースのいずれのデータベースに収容すべきかを判定するネットワークエレメント収容データベース判定手段とを備えたことを特徴としている。
【００２４】
また、本発明の請求項１７は、前記オペレーションシステムにおいて、前記パーティション毎にｎ分割されたデータベースにグループ番号を割り付け、各グループ番号毎のデータベースに収容されるネットワークエレメント数を管理するネットワークエレメントグループ番号管理手段を備え、前記ネットワークエレメント収容データベース判定手段は、前記ネットワークエレメントグループ番号管理手段より、各グループ番号毎のデータベースに収容されるネットワークエレメント数を取得するグループ別ネットワークエレメント収容数取得手段と、その取得した各グループ番号毎のデータベースに収容されるネットワークエレメント数のうち、収容ネットワークエレメント数が最小となるグループ番号のデータベースを該当ネットワークエレメントの警報を格納するデータベースとして割り振るグループ別データベース割り振り手段とを備えたことを特徴としている。
【００２５】
また、本発明の請求項１８は、前記オペレーションシステムにおいて、前記グループ別データベース割り振り手段は、収容ネットワークエレメント数が最小となるグループ番号のデータベースが複数あった場合に、最若番のグループ番号のデータベースを前記新規ネットワークエレメントから通知される警報の蓄積先として割り振ることを特徴としている。
【００２６】
上記のように本発明の構成によれば、ネットワークエレメント毎の警報レベルにより蓄積するデータベースを分散し、警報の蓄積処理を複数同時に起動させるようにしたため、単一時間当たりのデータベースアクセス回数が増加する。これにより、単一時間当たりの登録・更新処理で大量の警報を同時に登録・更新することができるようになり、従来のようなデータベース書き込み時のＩ／Ｏ処理遅延でのキュー溜りによるメモリ不足が回避され、リアルタイムな警報処理が実現される。
【００２７】
また、ＮＥ毎に警報を蓄積するデータベースをパーティション毎にｎ分割し、ｎ分割されたデータベースに収容されている収容ＮＥ件数に応じて各ＮＥの警報の蓄積先データベースを決定するので、警報処理の負荷分散が可能となり、ＮＥからの警報が特定のデータベースに集中してしまうといった従来の問題を回避できるようになる。これにより、単位時間当たりのデータベースアクセス回数が増加し、データベース書き込み時のＩ／Ｏ処理遅延でのキュー溜りによるメモリ不足が回避でき、リアルタイムな警報処理が可能となる。
【００２８】
さらに、上記により、システム上の処理性能が向上するので、ハードウェアコストの増加を招くことなくＮＥ収容数の拡大が可能となる。
【００２９】
【発明の実施の形態】
以下、本発明の実施の形態を図面に基づいて説明する。
【００３０】
（実施の形態１）
図１は、本発明の実施の形態１に係るオペレーションシステムの構成を概略的に示す図である。図１において、このオペレーションシステムは、ＮＥ集約サーバ１００と保守端末２００から構成される。ＮＥ集約サーバ１００は、各ＮＥ（ＮＥ＃１〜＃ｎ）１０から通知される警報を受信するＮＥインターフェース１２１（ＮＥ毎に具備）、警報受信部１２２、警報ジャーナルデータベース登録部１２３、保守端末通信部１２４、特定警報定義テーブル１２５、特定警報配信部１３１、特定ジャーナルデータベース登録部１３２、特定警報登録プロセス管理テーブル１３３、タイマー監視部１３４を備え、かつ、各ＮＥ１０から通知される警報を蓄積するデータベースが備えられる。このデータベースは、従来の１つのジャーナル履歴ＤＢから、警報の内容により、特定ジャーナル履歴ＤＢ１３５（例：警報レベルの低い警報の履歴（ジャーナル）を蓄積）と警報ジャーナル履歴ＤＢ１２６（例：警報レベルの高い警報の履歴を蓄積）の２つのデータベースに分割される。
【００３１】
上記のように構成されたオペレーションシステムにおいて、以下、同図及び図２のフローチャートを参照しながら本発明の動作について説明する。図２は、ＮＥ集約サーバ１００での警報処理の手順を示すフローチャートである。本例では、説明を平易にするために、ｎ番目のＮＥ（＝ＮＥ＃ｎ）から警報が発生られた場合を仮定し、以下、説明を進める。
【００３２】
図２において、ＮＥ＃ｎから発せられた警報がＮＥインターフェース１２１で受信（Ｓ１）されると、ＮＥインターフェース１２１は、特定警報定義テーブル１２５を参照し（Ｓ２）、ＮＥ＃ｎから発せられた警報が警報番号の定義されている警報か否かを判定（Ｓ３）する。この特定警報定義テーブル１２５は、例えば、図３に示すように、「警報番号」と「警報種類が」記載され、本例では、警報番号の記載されている警報を低レベル警報（同図（ａ））、警報番号の記載されていない警報を高レベル警報（同図（ｂ））とする。
【００３３】
図２に戻って、上記判定（Ｓ３）で、警報番号の定義されている警報であるとの判定結果を得た場合（Ｓ３でＹＥＳ）、該当警報をＮＥ＃ｎが属するグループの特定警報配信部１３１に配信（Ｓ４）する。特定警報配信部１３１は、ＮＥインターフェース１２１から配信された警報を取得し、その警報を該当の特定ジャーナルデータベース登録部１３２に配信（Ｓ５）する。特定ジャーナルデータベース登録部１３２は、特定警報配信部１３１から取得した警報をバッファに保管するとともに、特定警報登録プロセス管理テーブル１３３に書き込む（Ｓ６）。その後、特定警報登録プロセス管理テーブル１３３に書き込んだ警報の件数が一定件数（本例では、２００件）に達した、若しくはタイマー監視部１３４から一定時間（本例では、３００秒）が経過したとの通知を受けたとき（Ｓ７でＹＥＳ）に、上記バッファから当該警報を取り出して特定ジャーナル履歴ＤＢ１３５に書き込む（Ｓ８）。
【００３４】
一方、上記判定（Ｓ７）において、特定警報登録プロセス管理テーブル１３３に書き込んだ警報の件数が一定件数（本例では、２００件）に達していない、若しくはタイマー監視部１３４から一定時間（本例では、３００秒）が経過していないとの通知を受けた場合（Ｓ７でＮＯ）、最初の処理に戻ってＮＥからの警報受信待ち状態となる。
【００３５】
また、上記判定（Ｓ３）で、ＮＥ＃ｎから発せられた警報が警報番号の定義されていない警報であるとの判定結果を得た場合（Ｓ３でＮＯ）、該当警報は警報受信部１２２に配信（Ｓ９）される。警報受信部１２２で取得された警報は、その後、警報ジャーナルデータベース登録部１２３及び保守端末通信部１２４へと配信（Ｓ１０、Ｓ１１）される。警報ジャーナルデータベース登録部１２３は、警報受信部から配信された警報を警報単位で警報ジャーナル履歴ＤＢ１２６への登録処理を行ない（Ｓ１２）、一定時間（例：１６秒、任意に設定可）の通知を受けることにより、警報ジャーナル履歴ＤＢ１２６の更新を行なう（Ｓ１２）。また、保守端末通信部１２４は、警報受信部から１２２配信された警報を該当の保守端末２００に通知し（Ｓ１３）、画面上に警報内容を表示させる。
【００３６】
上記のように本実施例では、ＮＥの警報内容（レベル）により、蓄積先となるデータベースが異なる。これにより、保守者は警報レベル毎の格納期間（データベースの容量）を設計することができる。例えば、レベルの高い警報については、従来どおりの格納期間とし、レベルの低い警報については、短期間（データベース容量を削減）とすることにより、１ＮＥ当たりの必要なデータベース容量を削減することができる。図４は、本発明におけるデータベース分割方式のデータベースと従来方式のデータベースにおいて必要なデータ量を比較した図である。尚、両者の比較に際して、以下の条件を前提条件とする。
【００３７】
（前提条件）
１．特定警報定義テーブルに定義されていない警報が１ＮＥ当たり１時間に１０件発生したと仮定
２．特定警報定義テーブルに定義されている警報が１ＮＥ当たり１時間に１０００件発生したと仮定
３．一定期間格納が必要な警報は１月とし、それ以外は１週間（７日）と仮定
４．１警報１レコードと仮定
上記条件下で従来方式と本発明のデータ分散方式によるデータベース容量の比較結果を以下に示す。
【００３８】
（従来方式：ジャーナル履歴ＤＢ）
１０件×２４時間×３１日＝７４４０レコード
１０００件×２４時間×３１日＝７４４０００レコード
データベース容量：７４４０＋７４４０００＝７５１４４０レコード
（本発明のデータベース分散方式：警報ジャーナル履歴ＤＢと特定ジャーナル履歴ＤＢに分割）
▲１▼警報ジャーナル履歴ＤＢ
１０件×２４時間×３１日＝７４４０レコード
▲２▼特定ジャーナル履歴ＤＢ
１０００件×２４時間×７日＝１６８０００レコード
▲１▼と▲２▼のデータベース容量の合計：１７５４４０レコード
このように従来方式のジャーナル履歴ＤＢでは、保守者は警報レベル毎の格納期間を設計することができないため、全警報について一定期間（ここでは、１月分）蓄積される。しかし、本発明のデータベース分散方式では、保守者は警報レベル毎に格納期間を設計することができるため、レベルの高い警報については、１月分、レベルの低い警報については７日分とデータベースに蓄積される警報のデータ量を警報内容に応じて増減させることが可能となる。これにより、１ＮＥ当たりの必要なデータベース容量を削減することができる。
【００３９】
また、上記例では、特定警報定義テーブル１２５の参照により、警報レベルを判別し、判別結果に応じて、警報のデータベースへの蓄積を分散させる形態を示したが、本発明はこのような実施の形態に限定されるものではない。例えば、ＮＥ＃ｎから発せられる警報の種別に応じて異なるデータベースに分散蓄積させるような形態であってもよい。この場合、警報種別毎の発生頻度の統計をとり、統計結果から得られる発生頻度の多少に基づいて、警報を異なるデータベースに分散させて蓄積させればよい。
【００４０】
以上、説明してきたように、本実施例によれば、ＮＥ毎の警報レベルにより蓄積するデータベースを分散し、データベースへの蓄積処理を複数同時に起動するようにしたため、単一時間当たりのデータベースアクセス回数が増加する。これにより、単一時間当たりの登録・更新処理で大量の警報を同時に登録・更新することができるようになり、従来のようなデータベース書き込み時のＩ／Ｏ処理遅延でのキュー溜りによるメモリ不足を回避することができ、リアルタイムな警報処理が可能となる。
【００４１】
また、上記により、ＮＥ集約サーバ１００の処理性能が向上するので、ハードウェアコストの増加を招くことなくＮＥ収容数の拡大が可能となる。
【００４２】
さらに、警報レベルの高い警報のみを保守者に通知するため、従来のような警報レベルの高い警報が警報レベルの低い警報に埋もれてしまうといった問題を回避することができ、保守者にとって容易、かつ確実な警報確認が可能となる。また、レベルの低い警報については、保守者からの要求により、特定ジャーナル履歴ＤＢ１３５の検索による確認が可能である。また、特定ジャーナル履歴ＤＢ１３５に蓄積する警報については、保守者により警報ランクまたは、警報番号を登録することにより、ＮＥ集約サーバ１００運用中に特定警報の追加、変更が可能である。
【００４３】
（実施の形態２）
図５は、本発明の実施の形態２に係るオペレーションシステムの構成を概略的に示す図である。図５において、このオペレーションシステムは、ＮＥ集約サーバ１００と保守端末（図示省略）から構成される。ＮＥ集約サーバ１００は、各ＮＥ（本例では、ＮＥ＃ａ、ＮＥ＃α、ＮＥ＃β、ＮＥ＃γ）１１〜１４から通知される警報を受信するＮＥインターフェース（ＮＥ毎に具備）１４１〜１４４、警報受信部１４５〜１４８、ジャーナルデータベース登録部１５０〜１５１を備え、かつ、各ＮＥ１１〜１４から通知される警報を蓄積するデータベースが備えられる。このデータベースは、従来の１つのジャーナル履歴ＤＢから、ｎ分割（本例では、ｎ＝７とし、分割されたデータベースの番号はパーティション番号ともいう）されたジャーナル履歴ＤＢ＃Ａ１６０〜＃Ｇ１６１である。
【００４４】
図５において、各ＮＥ＃ａ１１〜ＮＥ＃γ１４から通知される警報は、該当のＮＥインターフェース１４１〜１４４を介して警報受信部１４５〜１４８で取得される。例えば、ＮＥ＃ａ１１から発せられた警報は、ＮＥインターフェース１４１を介して警報受信部１４５で取得された後、ジャーナルデータベース登録部１５０に配信される。このジャーナルデータベース登録部１５０は、警報受信部１４５〜１４６から送られてきた警報を受付ける。ジャーナルデータベース登録部１５０は、上記のようにして取得したＮＥ＃ａ１１からの警報をジャーナル履歴ＤＢ＃Ａ１６０に書き込む登録処理を行なう。ジャーナルデータベース登録部１５０、１５１とジャーナル履歴ＤＢ１６０、１６１とは対応関係にあり、システム運用時には７つあるジャーナルデータベース登録部１５０、１５１が同時に起動してジャーナル履歴ＤＢ１６０、１６１へのデータ登録処理を行なう。
【００４５】
このように各ＮＥ１１〜１４からの警報は、７つに分割されたジャーナル履歴ＤＢ＃Ａ〜＃Ｇのうち該当のデータベースに登録・更新処理される。ここで、新規ＮＥの追加収容が必要になった場合、新規ＮＥからの警報は、ジャーナル履歴ＤＢ＃Ａ１６０〜＃Ｇ１６１のうちのいずれかに登録されるが、本実施例では、各ジャーナル履歴ＤＢ＃Ａ１６０〜＃Ｇ１６１に収容されるＮＥ数に応じて新規ＮＥの収容先となるデータベースが決定される。具体的には、以下のようにして新規ＮＥの収容先データベースが決定される。
【００４６】
図６は、新規ＮＥに対するパーティション番号を動的に分散配置する方法を説明するための機能ブロック図、図７は、新規ＮＥに対するパーティション番号を動的に分散配置する処理手順を示したフローチャートである。本例では、システム運用中に追加される新規ＮＥに対してパーティション番号を動的に分散配置する場合を想定する。
【００４７】
図６において、ＮＥ集約サーバ１００内には、図５に示した警報受信部１４５〜１４８等の機能ブロックの他に、保守端末２００から送られてくる局データを受信する局データ受信手段１７０、局データ受信手段にて受信された局データをメモリ上に展開させるためのメモリ１７１、ＮＥグループ番号毎の収容ＮＥ件数が管理されるＮＥグループ番号管理データベース１７２、メモリ上にあるデータとＮＥグループ番号管理データベース１７２に管理されているＮＥグループ番号毎の収容ＮＥ件数から該当のＮＥの警報をどのデータベース（ジャーナル履歴ＤＢ＃Ａ１６０〜＃Ｇ１６１）に分散させるかを判定する制御手段（例：ＣＰＵ等）１７３を備える。
【００４８】
次に、図７のフローチャートを説明する。尚、同図を説明するにあたり、図６の機能ブロック図を参照する。
【００４９】
図７において、ＮＥ集約サーバ１００に新規に収容ＮＥが追加された場合、保守端末２００を通じて、新規ＮＥの局データ（ＮＥの装置構成、装置番号、接続先、加入者情報等を規定した情報）が投入される。保守端末２００により投入された局データは、局データ受信手段１７０で受信された後、メモリ１７１上に展開される。制御手段（例：ＣＰＵ等）１７３は、メモリ１７１上に上記情報が展開されたことを認識すると、ＮＥグループ番号管理データベース（ＤＢ）１７２（図８（ａ）参照）を検索（Ｓ２１）し、グループ番号毎に収容ＮＥ件数を求める（Ｓ２２）。このＮＥグループ番号管理ＤＢ１７２には、グループ番号毎（本例では、データベースを７分割しているので、グループ番号は「１」〜「７」はパーティション番号に対応する）に、収容されているＮＥの装置番号（Ｓ／Ｎ：ｓｅｒｉａｌ　Ｎｕｍｂｅｒ）の情報が記録されている。ここでは、説明を平易にするために、各グループ番号の収容ＮＥ件数を次のように仮定する（図８（ａ）のかっこ内の数値）。
【００５０】
グループ番号１　１０件
グループ番号２　２０件
グループ番号３　２５件
グループ番号４　３３件
グループ番号５　１０件
グループ番号６　２３件
グループ番号７　１７件
制御手段１７３は、ＮＥグループ番号管理ＤＢ１７２を参照して、各グループ番号毎の収容ＮＥ件数を取得（Ｓ２２）すると、収容ＮＥ件数が最小となるグループ番号を検索し（Ｓ２３）、最小グループ番号が複数あるかどうかを判定（Ｓ２４）する。制御手段は１７３、この判定（Ｓ２４）で「複数グループあり」と判定した場合（Ｓ２４で複数グループあり）、グループ番号の最若番のグループ番号を当該新規ＮＥの収容先として割り振る（Ｓ２５）。本例の場合、図８の（ａ）に示すように、収容ＮＥ件数の最小グループが、グループ番号１、グループ番号５と複数あるため、これらのうちの最若番グループ、つまり、グループ番号１が当該新規ＮＥの収容先として割り振られる。制御手段１７３は、上記のようにしてグループ番号を割り振った後、当該新規ＮＥの装置番号（例：装置番号＝２２００）を割り振られたグループ番号に登録（Ｓ２７）する（図８の（ｂ）の下線部参照）。制御手段１７３は、当該新規ＮＥの装置番号を割り振ったグループ番号に登録した後、ＮＥグループ番号管理ＤＢ１７２の内容を最新のものとしてメモリ１７１上に展開する。以後、新規ＮＥからの警報は、ジャーナル履歴ＤＢ＃Ａ１６０に蓄積される。
【００５１】
一方、上記判定（Ｓ２４）で、「１グループのみ」と判定されたとき（Ｓ２４で１グループのみ）は、制御手段１７３は該当のグループ番号を当該新規ＮＥの収容先として割り振り（Ｓ２６）、これ以降は、上記と同様の処理（Ｓ２７〜Ｓ２８）が行なわれる。
【００５２】
このように、本実施例によれば、収容するＮＥをパーティション毎のデータベースに均等に割り付けるので、収容ＮＥを追加収容する場合であっても、収容ＮＥ件数の少ないデータベースから順に割り振られていくので、警報処理の負荷分散が可能となる。これにより、ＮＥからの警報が特定のデータベースに集中してしまうといった従来の問題を回避できるようになり、ＮＥ集約サーバ全体での単位時間当たりのデータベースアクセス回数を増加する。その結果、データベース書き込み時のＩ／Ｏ処理遅延でのキュー溜りによるメモリ不足が回避され、リアルタイムな警報処理が可能となる。
【００５３】
また、上記により、ＮＥ集約サーバ１００の処理性能が向上するので、ハードウェアコストの増加を招くことなくＮＥ収容数の拡大が可能となる。
【００５４】
上記実施の形態１において、図２に示す処理全体が警報内容型分散蓄積手段に対応し、ステップＳ２の処理で参照される特定警報定義テーブル１２５がテーブル（請求項３記載のテーブルをいう）に対応し、ステップＳ３での処理が警報レベル判断手段に対応する。また、ステップＳ６での処理がバッファ蓄積手段に対応し、ステップＳ８での処理が低レベル警報登録手段に対応し、ステップＳ１２での処理が高レベル警報登録手段に対応する。また、ステップＳ１３での処理が高レベル警報表示手段に対応し、ステップＳ７での処理が警報蓄積タイミング判定手段に対応する。
【００５５】
上記実施の形態２において、保守端末（実施の形態２では図示省略）での操作によりデータベースを任意の数に分割させる機能がデータベース分割手段に対応し、図７に示すステップＳ２４での処理がネットワークエレメント収容データベース判定手段に対応する。また、図６に示すＮＥグループ番号管理データベース１７２のデータベース機能がネットワークエレメントグループ番号管理手段に対応する。また、図７に示すステップＳ２２での処理がグループ別ネットワークエレメント収容数取得手段に対応し、ステップＳ２５又はステップＳ２６の処理がグループ別データベース割り振り手段に対応する。
【００５６】
また、上記実施の形態１及び実施の形態２において、ＮＥ集約サーバ１００の機能が警報監視装置に対応する。
【００５７】
【発明の効果】
以上、説明したように、本願発明によれば、ネットワークエレメント毎の警報レベルにより蓄積するデータベースを分散し、警報の蓄積処理を複数同時に起動させるようにしたため、従来のようなデータベース書き込み時のＩ／Ｏ処理遅延でのキュー溜りによるメモリ不足が回避され、リアルタイムな警報処理が実現される。
【００５８】
また、ＮＥ毎に警報を蓄積するデータベースをパーティション毎にｎ分割し、ｎ分割されたデータベースに収容されている収容ＮＥ件数に応じて各ＮＥの警報の蓄積先データベースを決定するので、警報処理の負荷分散が可能となり、ＮＥからの警報が特定のデータベースに集中してしまうといった従来の問題を回避できるようになる。そのため、上記同様、データベース書き込み時のＩ／Ｏ処理遅延でのキュー溜りによるメモリ不足が回避でき、リアルタイムな警報処理が可能となる。
【００５９】
さらに、上記により、システム上の処理性能が向上するので、ハードウェアコストの増加を招くことなくＮＥ収容数の拡大が可能となる。
【図面の簡単な説明】
【図１】本発明の実施の形態１に係るオペレーションシステムの構成を概略的に示す図である。
【図２】ＮＥ集約サーバ１００での警報処理の手順を示すフローチャートである。
【図３】特定警報定義テーブルの一例を示す図である。
【図４】本発明におけるデータベース分割方式のデータベースと従来方式のデータベースにおいて必要なデータ量を比較した図である。
【図５】本発明の実施の形態２に係るオペレーションシステムの構成を概略的に示す図である。
【図６】新規ＮＥに対するパーティション番号を動的に分散配置する方法を説明するための機能ブロック図である。
【図７】新規ＮＥに対するパーティション番号を動的に分散配置する処理手順を示したフローチャートである。
【図８】ＮＥグループ番号管理データベースの一例を示す図である。
【図９】従来のオペレーションシステムにおけるＮＥからの警報処理を概略的に示す図である。
【図１０】従来のオペレーションシステムにおいてＮＥからの警報を同一のジャーナル履歴ＤＢに蓄積させる例を示した概略図（その１）である。
【図１１】従来のオペレーションシステムにおいてＮＥからの警報を同一のジャーナル履歴ＤＢに蓄積させる例を示した概略図（その２）である。
【符号の説明】
１０　ネットワークエレメント（ＮＥ）＃１〜＃ｎ
１１　ネットワークエレメント（ＮＥ）＃ａ
１２　ネットワークエレメント（ＮＥ）＃α
１３　ネットワークエレメント（ＮＥ）＃β
１４　ネットワークエレメント（ＮＥ）＃γ
１００　ＮＥ集約サーバ
１０２、１１４〜１１６、１２２、１４５〜１４８　警報受信部
１０３、１０４、１１７、１２１、１２２、１５０、１５１　ジャーナルデータベース登録部
１０５、１１８　ジャーナル履歴データベース（ＤＢ）
１１１〜１１３、１２１、１４１〜１４４　ＮＥインターフェース
１２３　警報ジャーナルデータベース登録部
１２４　保守端末通信部
１２５　特定警報定義テーブル
１２６　警報ジャーナル履歴データベース（ＤＢ）
１３１　特定警報配信部
１３２　特定ジャーナルデータベース登録部
１３３　特定警報登録プロセス管理テーブル
１３４　タイマー監視部
１３５　特定ジャーナル履歴データベース（ＤＢ）
１６０、１６１　ジャーナル履歴データベース（ＤＢ）＃Ａ〜＃Ｇ
１７０　局データ受信手段
１７１　メモリ
１７２　ＮＥグループ番号管理データベース（ＤＢ）
２００　保守端末[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to an operation system that supports maintenance of a plurality of and various types of network elements (switches, transmission devices).
[0002]
[Prior art]
Network elements (hereinafter referred to as NEs) such as wireless devices, exchanges, and transmission devices constituting a communication network are generally monitored by an operation system.
[0003]
The conventional operation system is provided with a server that collects and aggregates alarms from each NE and performs various processes (this server is called an alarm aggregation server or an NE aggregation server, but in this example, an NE aggregation server is used). An alert from each NE is displayed on a display such as a console through the NE aggregation server (for example, see Non-Patent Document 1). As a result, the maintenance person can grasp the state of occurrence of alarms from all NEs.
[0004]
When the NE aggregation server receives an alarm (including an autonomous message) from each NE, the NE aggregation server performs a predetermined process, displays the alarm on a maintenance terminal, and notifies the maintenance person of the alarm. A plurality of alarms are notified from a plurality of NEs, and the contents of the alarms (eg, alarm levels) are also classified into some by the maintenance person. The following shows the types of alarm levels.
(Type of alarm level)
(1) An alert that is extremely urgent and requires a quick action (hereinafter referred to as the most urgent message)
(2) Warnings that are urgent and require primary measures such as primary separation (hereinafter referred to as emergency messages)
(3) An alert that is not urgent and does not require real-time measures (hereinafter referred to as an error message)
(4) From the point of view of preventive maintenance, a level of alarm that does not require real-time monitoring (hereinafter referred to as a normal message)
FIG. 9 is a diagram schematically showing a warning process from a NE in a conventional operation system. In the operation system shown in the figure, the alarm processing is performed by the NE aggregation server 100 described above. Hereinafter, a conventional alarm process performed by the NE aggregation server 100 will be described. Here, it is assumed that a plurality of NEs (NE # 1 to NE # n) are accommodated in the NE aggregation server 100.
[0005]
Alarms issued from a plurality of NEs, ie, NE # 1 to NE # n, are first received by the NE interface (NE I / F) 101. The NE interface 101 notifies the alarm receiving unit 102 (also called an alarm receiving process) in the order in which the alarms received from the plurality of NEs are received. Here, the “process” refers to a program being executed. The alarm receiving units 102 are provided for the number of NEs. After the alarms from each NE are received by the corresponding alarm receiving unit, the journal database registration unit 103 (also called a journal database registration process) and the maintenance terminal communication unit 104 ( (Also called a maintenance terminal communication process). The journal database registration unit 103 is provided with NE groups (a set of a certain number of NEs is one NE group), and outputs an alarm output from an alarm receiving unit that has received an alarm from an NE belonging to the NE group. It is received at the journal database registration unit. The journal database registration unit 103 writes the received alerts to the journal history database (DB) 105 in the order in which they were received. The alarm output from the alarm receiver unit 102 is also output to the maintenance terminal communication unit 104 (also called a maintenance terminal communication process), and the maintenance terminal communication unit 104 notifies the maintenance terminal 200 of the alarm in real time. You. The alarm receiving unit 102, the journal database registration unit 103, and the maintenance terminal communication unit 104 are processes (also called tasks depending on the OS) managed by the OS on the NE aggregation server as described above. Information is exchanged by communication. Further, the alarm receiving unit 102 and the journal database registering unit 103 are resident processes that are constantly operating when the system is started.
[0006]
As described above, alerts from each NE are stored in the journal history DB 105, but conventionally, alerts from all NEs are stored in the same database. FIGS. 10 and 11 are schematic diagrams showing an example in which a warning from an NE is stored in the same journal history DB in a conventional operation system. The difference between FIG. 10 and FIG. 11 is that the operation is the same as that of FIG. That is, in the example of FIG. 10, the alerts from the respective NEs received by the respective alert receiving units 114 to 116 are sequentially received by one journal database registration unit 117. The journal database registration unit 117 writes in the journal history DB 118 in the order in which the alarms are received. On the other hand, in the case of FIG. 11, a plurality (here, n) of journal database registration units 121 and 122 are provided, and the n journal database registration units 121 and 122 are activated simultaneously. Each of the journal database registration units 121 and 122 sequentially writes an alarm in the journal history DB 118 when receiving an alarm from the corresponding alarm receiving unit 114 to 116.
[0007]
Also, in some conventional operation systems, real-time reception of an autonomous alarm notification is made possible by determining whether or not a frequently occurring autonomous alarm notification is immediately displayed on a monitoring screen in a monitoring process (for example, And Patent Document 1).
[0008]
[Patent Document 1]
JP-A-11-122326
[Non-patent document 1]
"W-CDMA mobile communication system" supervised by Keiji Tachikawa, Maruzen Publishing, June 25, 2001, p. 306.
[0009]
[Problems to be solved by the invention]
However, the conventional operation system described above has the following problems.
[0010]
For example, in FIG. 9, regarding the processing of accumulating alarms in the journal history DB 105 in the NE aggregation server 100, in spite of the fact that low-level alarms account for more than 90% of the total, all of the information notified from each NE The same processing is performed for the alarms of irrespective of the alarm level. That is, despite the fact that low-level alarms are instantaneously concentrated in large quantities, the same accumulation process is performed. Therefore, when writing an alarm to the journal history DB 105, I / O (Input / Output: input) is performed. Output) Processing delay occurs, and the alarm accumulation processing queue stays. As a result, a memory shortage occurs, and the processing performance of the system deteriorates, so that real-time alarm processing becomes difficult, and the operability of the system is seriously damaged.
[0011]
In addition, the number of NEs that can be accommodated in the NE aggregation server 100 is restricted due to the occurrence of a memory shortage, that is, a lack of system resources. In order to increase the number of NEs that can be accommodated, the number of NE aggregation servers 100 must be increased. However, in that case, the hardware cost increases.
[0012]
Also, high-level alerts need to be accumulated in the journal history DB 105 for a certain period of time, but low-level alerts occupy the majority of all alerts, so the journal history DB 105 has a low level of capacity. The database capacity including the information amount of the alarm is required. In other words, the data amount of the low-level alarm occupies a considerable amount of the database capacity, so that the number of NEs that can be accommodated is restricted. In addition, as for the notification of the alarm to the maintenance person, since all the alarms are notified, there is a high possibility that a high-level alarm is buried in a low-level alarm. There is a possibility that the quality of service will be adversely affected.
[0013]
Further, as shown in FIG. 10 and FIG. 11, since the processing of accumulating alarms from each NE is performed on the same journal history DB 118, a plurality of journal database registration units are provided, and are activated simultaneously to perform the accumulation processing. Even in such a case, real-time alarm processing cannot be performed due to congestion of low-level alarms and a shortage of memory due to queue accumulation in the journal database registration unit.
[0014]
The present invention has been made in view of the above-described problems, and an object thereof is to provide an operation system that can increase the number of accommodated NEs while realizing a real-time alarm process. It is.
[0015]
[Means for Solving the Problems]
In order to solve the above problem, the present invention is characterized in that a database for accumulating alarms from network elements is stored in a distributed manner according to alarm contents. Specifically, as described in claim 1, in an operation system for managing a plurality of and various types of network elements (NEs) constituting a communication network, a database for storing alarms notified from the network elements Is provided in a divided manner, and according to the contents of the alarm represented by the alarm, an alarm content type distributed storage means for distributing and storing the alarm in the divided database is provided.
[0016]
According to a second aspect of the present invention, in the operation system, the database is divided based on an alarm level specified from the alarm content.
[0017]
Further, in the operation system, the operation system may include a table in which the contents of the alarm are associated with the alarm number, and an alarm based on the table when an alarm is notified from the network element. Alarm level judging means for judging the importance of the alarm level as a high or low alarm level, wherein the alarm content type decentralized accumulation means divides the notified alarm based on the judgment result by the alarm level judging means. It is characterized in that the data is sorted and stored in any of the databases.
[0018]
According to a fourth aspect of the present invention, in the operation system, the alarm level judging means determines that the alarm content of the alarm notified from the network element is an alarm content having an alarm number by referring to the table. If the reference result is obtained, the content of the alarm is determined as a low-level alarm, and if not, the content of the alarm is determined as a high-level alarm.
[0019]
According to a fifth aspect of the present invention, in the operation system, when the alarm level determination unit determines that the alarm content of the alarm notified from the network element is a low level alarm by referring to the table, Buffer storage means for storing the alarm in a buffer, wherein the alarm content type distributed storage means stores the low-level alarm in the database obtained by dividing the alarm stored in the buffer storage means at a predetermined timing. It is characterized by having low-level alarm registration means for storing in a database.
[0020]
According to a sixth aspect of the present invention, in the operation system, the alarm content type decentralized storage means determines that the alarm content of the alarm notified from the network element by the alarm level determination means is a high-level alarm. When the judgment is made, high-level alarm display means for outputting the content of the alarm to a predetermined terminal device for display is provided.
[0021]
According to a seventh aspect of the present invention, in the operation system, the alarm content type decentralized storage means determines that the alarm content of the alarm notified from the network element by the alarm level determination means is a high-level alarm. When the judgment is made, a high-level alarm registering means is provided for storing the alarm at a predetermined timing in a database storing the high-level alarm among the divided databases.
[0022]
In the operating system, the alarm content type distributed accumulating means may be configured such that when the number of alarms of the same level stored in the buffer means reaches a predetermined number or when a predetermined time has elapsed. Low-level alarm accumulation timing determining means for determining whether the number of alarms of the same level accumulated in the buffer means has reached a predetermined number or a predetermined time has elapsed. When it is determined, the alarm stored in the buffer storage unit is stored in a database of the divided databases that stores a low-level alarm.
[0023]
Further, the present invention is characterized in that a database for accumulating alarms for each network element is distributed and stored. Specifically, in an operation system for managing a plurality of and various types of network elements (NEs) constituting a communication network, a database for storing alarms notified from the network elements, as described in claim 16. Database dividing means for dividing the storage area into n for each partition, and dividing the network elements accommodated in the n-divided database into n-based databases according to the amount of data stored in the n-divided database. And a network element accommodation database determining means for determining which database should be accommodated.
[0024]
Further, according to the present invention, in the operating system, a network element group number for allocating a group number to the database divided into n for each partition and managing the number of network elements accommodated in the database for each group number A network element accommodation number acquiring means for acquiring the number of network elements accommodated in a database for each group number from the network element group number managing means, the network element accommodation database determining means comprising: Of the number of network elements accommodated in the acquired database for each group number, the database of the group number with the smallest number of accommodated network elements is assigned to the corresponding network element. It is characterized in that a group-specific database allocation means for allocating a database that stores the alarm instrument.
[0025]
Further, according to the present invention, in the operation system, the group-by-group database allocating means may be configured such that, when there are a plurality of group number databases having the minimum number of accommodated network elements, Is assigned as a storage destination of an alarm notified from the new network element.
[0026]
As described above, according to the configuration of the present invention, the database to be accumulated is distributed according to the alarm level for each network element, and a plurality of alarm accumulation processes are started simultaneously, so that the number of database accesses per single time increases. . As a result, a large number of alarms can be registered and updated at the same time in the registration and update processing per single time. Avoided, real-time alarm processing is realized.
[0027]
Further, the database for storing alarms for each NE is divided into n parts for each partition, and the database for storing the alarms of each NE is determined according to the number of accommodated NEs accommodated in the n-divided database. The load can be distributed, and the conventional problem that the alarm from the NE concentrates on a specific database can be avoided. As a result, the number of database accesses per unit time increases, memory shortage due to queue accumulation due to I / O processing delay during database writing can be avoided, and real-time alarm processing can be performed.
[0028]
Further, the processing performance on the system is improved by the above, so that the number of NEs accommodated can be increased without increasing the hardware cost.
[0029]
BEST MODE FOR CARRYING OUT THE INVENTION
Hereinafter, embodiments of the present invention will be described with reference to the drawings.
[0030]
(Embodiment 1)
FIG. 1 is a diagram schematically showing a configuration of an operation system according to Embodiment 1 of the present invention. In FIG. 1, this operation system includes an NE aggregation server 100 and a maintenance terminal 200. The NE aggregation server 100 includes an NE interface 121 (provided for each NE) that receives an alert notified from each NE (NE # 1 to #n) 10, an alert receiving unit 122, an alert journal database registration unit 123, and a maintenance terminal communication. A database that includes a unit 124, a specific alarm definition table 125, a specific alarm distribution unit 131, a specific journal database registration unit 132, a specific alarm registration process management table 133, and a timer monitoring unit 134, and stores alarms notified from each NE 10. Is provided. This database includes a specific journal history DB 135 (e.g., accumulates an alarm history (journal) with a low alarm level) and an alarm journal history DB 126 (e.g., a high alarm level) according to the contents of an alarm from one conventional journal history DB. Alarm history).
[0031]
In the operation system configured as described above, the operation of the present invention will be described below with reference to the flowchart of FIG. 2 and FIG. FIG. 2 is a flowchart illustrating a procedure of an alarm process in the NE aggregation server 100. In this example, for the sake of simplicity, it is assumed that an alarm is issued from the n-th NE (= NE # n), and the description will proceed below.
[0032]
In FIG. 2, when an alert issued from NE # n is received by the NE interface 121 (S1), the NE interface 121 refers to the specific alert definition table 125 (S2), and issues an alert issued from NE # n. It is determined whether or not is an alarm for which an alarm number is defined (S3). In the specific alarm definition table 125, for example, as shown in FIG. 3, "alarm number" and "alarm type" are described. In this example, the alarm in which the alarm number is described is a low-level alarm (see FIG. a)), an alarm without an alarm number is defined as a high-level alarm (FIG. 9B).
[0033]
Returning to FIG. 2, in the above determination (S3), if a determination result that the alarm number is a defined alarm is obtained (YES in S3), the corresponding alarm is distributed to a specific alarm of the group to which NE # n belongs. It is distributed to the unit 131 (S4). The specific alarm distribution unit 131 acquires the alarm distributed from the NE interface 121, and distributes the alarm to the specific journal database registration unit 132 (S5). The specific journal database registration unit 132 stores the alarm acquired from the specific alarm distribution unit 131 in a buffer and writes it in the specific alarm registration process management table 133 (S6). Thereafter, the number of alarms written in the specific alarm registration process management table 133 reaches a certain number (200 in this example) or a certain time (300 seconds in this example) has passed from the timer monitoring unit 134. Is received (YES in S7), the alarm is taken out from the buffer and written in the specific journal history DB 135 (S8).
[0034]
On the other hand, in the determination (S7), the number of alarms written in the specific alarm registration process management table 133 does not reach a certain number (200 in this example) or a certain time (in this example) from the timer monitoring unit 134. , 300 seconds) has not passed (NO in S7), the process returns to the initial process, and waits for receiving an alarm from the NE.
[0035]
Further, in the above determination (S3), when the determination result that the alarm issued from NE # n is an alarm for which an alarm number is not defined is obtained (NO in S3), the corresponding alarm is sent to the alarm receiving unit 122. Distribution (S9). The alert acquired by the alert receiving unit 122 is then distributed to the alert journal database registration unit 123 and the maintenance terminal communication unit 124 (S10, S11). The alarm journal database registration unit 123 registers the alarm distributed from the alarm reception unit in the alarm journal history DB 126 in alarm units (S12), and sends a notification of a fixed time (eg, 16 seconds, arbitrarily settable). Upon receiving the information, the alarm journal history DB 126 is updated (S12). Further, the maintenance terminal communication unit 124 notifies the maintenance terminal 200 of the alarm distributed from the alarm reception unit 122 (S13), and displays the content of the alarm on the screen.
[0036]
As described above, in this embodiment, the database as the storage destination differs depending on the content (level) of the NE alarm. Thereby, the maintenance person can design the storage period (database capacity) for each alarm level. For example, the required storage capacity per NE can be reduced by setting the high-level alarm to the same storage period as the conventional one and the low-level alarm to the short period (reducing the database capacity). FIG. 4 is a diagram comparing the data amount required in the database of the present invention with the database division system and the data amount of the conventional system. The following conditions are preconditions for comparison between the two.
[0037]
(Precondition)
1. Assume that 10 alarms per hour per NE not defined in the specific alarm definition table
2. It is assumed that 1000 alarms are generated per hour per NE defined in the specific alarm definition table
3. It is assumed that the alarm that needs to be stored for a certain period is January, and the other is one week (7 days)
4.1 Assuming one alarm record
The results of comparison of the database capacity between the conventional system and the data distribution system of the present invention under the above conditions are shown below.
[0038]
(Conventional method: Journal history DB)
10 records x 24 hours x 31 days = 7440 records
1000 records x 24 hours x 31 days = 744000 records
Database capacity: 7440 + 744000 = 751,440 records
(Database distribution method of the present invention: divided into alarm journal history DB and specific journal history DB)
(1) Alert journal history DB
10 records x 24 hours x 31 days = 7440 records
(2) Specific journal history DB
1000 records x 24 hours x 7 days = 168,000 records
Total database capacity of (1) and (2): 175440 records
As described above, in the conventional journal history DB, since the maintenance person cannot design a storage period for each alarm level, all alarms are accumulated for a certain period (here, one month). However, in the database distribution method of the present invention, the maintenance person can design a storage period for each alarm level, so that a high-level alarm is stored in the database for one month, and a low-level alarm is stored for seven days in the database. It is possible to increase or decrease the data amount of the stored alarm according to the contents of the alarm. As a result, the required database capacity per NE can be reduced.
[0039]
In the above example, the alarm level is determined by referring to the specific alarm definition table 125, and the accumulation of alarms in the database is dispersed according to the determination result. It is not limited to the form. For example, a form in which the data is distributed and stored in different databases according to the types of alarms issued from NE # n may be used. In this case, statistics of the frequency of occurrence for each alarm type may be obtained, and the alarms may be distributed and accumulated in different databases based on the frequency of occurrence obtained from the statistical result.
[0040]
As described above, according to the present embodiment, the database to be accumulated is distributed according to the alarm level of each NE, and a plurality of accumulation processes in the database are started at the same time. Increase. As a result, a large number of alarms can be registered / updated simultaneously in the registration / update processing per unit time, and the memory shortage due to the queue accumulation due to the I / O processing delay at the time of database writing as in the related art can be prevented. This can be avoided and real-time alarm processing can be performed.
[0041]
Further, since the processing performance of the NE aggregation server 100 is improved by the above, the number of NEs accommodated can be increased without increasing the hardware cost.
[0042]
Further, since only the high alarm level alarm is notified to the maintenance person, it is possible to avoid the problem that the conventional high alarm level alarm is buried in the low alarm level alarm, which is easy for the maintenance person, and Reliable alarm confirmation becomes possible. The low-level alarm can be confirmed by searching the specific journal history DB 135 in response to a request from a maintenance person. As for the alarms stored in the specific journal history DB 135, the alarm can be added or changed during the operation of the NE aggregation server 100 by registering the alarm rank or the alarm number by the maintenance person.
[0043]
(Embodiment 2)
FIG. 5 is a diagram schematically showing a configuration of an operation system according to Embodiment 2 of the present invention. In FIG. 5, this operation system includes an NE aggregation server 100 and a maintenance terminal (not shown). The NE aggregation server 100 includes NE interfaces (provided for each NE) 141 to receive alarms notified from the NEs (in this example, NE # a, NE # α, NE # β, NE # γ) 11 to 14. 144, alarm receiving units 145 to 148, journal database registering units 150 to 151, and a database for storing alarms notified from the NEs 11 to 14. This database is a journal history DB # A160 to # G161 that is divided into n (in this example, n = 7, and the number of the divided database is also referred to as a partition number) from one conventional journal history DB.
[0044]
In FIG. 5, the alarm notified from each of the NEs # a11 to NE # γ14 is acquired by the alarm receiving units 145 to 148 via the corresponding NE interfaces 141 to 144. For example, an alarm issued from NE # a11 is acquired by the alarm receiving unit 145 via the NE interface 141, and is then distributed to the journal database registration unit 150. The journal database registration unit 150 receives the warning sent from the warning receiving units 145 to 146. The journal database registration unit 150 performs a registration process of writing the alarm from the NE # a11 acquired as described above to the journal history DB # A160. The journal database registration units 150 and 151 and the journal history DBs 160 and 161 have a correspondence relationship, and during system operation, the seven journal database registration units 150 and 151 are activated simultaneously to perform data registration processing to the journal history DBs 160 and 161. .
[0045]
As described above, the alarms from the NEs 11 to 14 are registered and updated in the corresponding database among the seven journal history DBs #A to #G. Here, when additional accommodation of a new NE is required, an alarm from the new NE is registered in one of the journal history DBs # A160 to # G161. The database as the accommodation destination of the new NE is determined according to the number of NEs accommodated in # A160 to # G161. Specifically, the new NE accommodation destination database is determined as follows.
[0046]
FIG. 6 is a functional block diagram for explaining a method of dynamically distributing partition numbers for new NEs, and FIG. 7 is a flowchart showing a processing procedure for dynamically distributing partition numbers for new NEs. . In this example, it is assumed that partition numbers are dynamically distributed to new NEs added during system operation.
[0047]
6, the NE aggregation server 100 includes, in addition to the functional blocks such as the alarm receiving units 145 to 148 shown in FIG. 5, a station data receiving unit 170 for receiving station data transmitted from the maintenance terminal 200, A memory 171 for expanding the station data received by the station data receiving means on the memory, an NE group number management database 172 for managing the number of NEs accommodated for each NE group number, data on the memory and the NE group number A control unit (eg, CPU, etc.) that determines which database (journal history DB # A160 to # G161) to distribute the alarm of the NE from the number of NEs accommodated for each NE group number managed in the management database 172. 173 is provided.
[0048]
Next, the flowchart of FIG. 7 will be described. In describing the figure, a functional block diagram of FIG. 6 will be referred to.
[0049]
In FIG. 7, when a newly accommodated NE is added to the NE aggregation server 100, station data of the new NE (information defining the NE device configuration, device number, connection destination, subscriber information, etc.) via the maintenance terminal 200. Is input. The station data input by the maintenance terminal 200 is received by the station data receiving unit 170 and then expanded on the memory 171. When recognizing that the information has been developed on the memory 171, the control means (eg, CPU or the like) 173 searches the NE group number management database (DB) 172 (see FIG. 8A) (S 21). The number of NEs accommodated is obtained for each group number (S22). The NE group number management DB 172 stores NEs stored for each group number (in this example, since the database is divided into seven, the group numbers “1” to “7” correspond to partition numbers). Of the device number (S / N: serial number) of the device. Here, in order to simplify the explanation, the number of NEs accommodated in each group number is assumed as follows (numerical values in parentheses in FIG. 8A).
[0050]
Group number 1 10
Group number 2 20
Group number 3 25
Group number 4 33
Group number 5 10
Group number 6 23
Group number 7 17
When the control unit 173 refers to the NE group number management DB 172 and obtains the number of accommodated NEs for each group number (S22), the control unit 173 searches for a group number that minimizes the number of accommodated NEs (S23). It is determined whether there is more than one (S24). If the control means 173 determines that “there is a plurality of groups” in the determination (S24) (there is a plurality of groups in S24), the control means assigns the lowest group number of the group number as the accommodation destination of the new NE (S25). In the case of the present example, as shown in FIG. 8A, since there are a plurality of groups having the minimum number of accommodated NEs, ie, the group number 1 and the group number 5, the youngest group among them, that is, the group number 1 Is allocated as the accommodation destination of the new NE. After allocating the group number as described above, the control unit 173 registers the device number (eg, device number = 2200) of the new NE in the allocated group number (S27) ((b) of FIG. 8). Underline). After registering the new NE device number in the assigned group number, the control means 173 develops the contents of the NE group number management DB 172 on the memory 171 as the latest one. Thereafter, the alarm from the new NE is stored in the journal history DB # A160.
[0051]
On the other hand, when it is determined in the above determination (S24) that "only one group" is present (only one group in S24), the control means 173 allocates the corresponding group number as the accommodation destination of the new NE (S26). Thereafter, the same processing as described above (S27 to S28) is performed.
[0052]
As described above, according to the present embodiment, the NEs to be accommodated are evenly allocated to the database for each partition. Therefore, even if the NEs to be accommodated are additionally accommodated, the NEs are assigned in order from the database with the smallest number of accommodated NEs. Thus, the load of the alarm processing can be distributed. This makes it possible to avoid the conventional problem that alerts from the NE are concentrated on a specific database, and increases the number of database accesses per unit time in the entire NE aggregation server. As a result, memory shortage due to queue accumulation due to I / O processing delay at the time of database writing is avoided, and real-time alarm processing becomes possible.
[0053]
Further, since the processing performance of the NE aggregation server 100 is improved by the above, the number of NEs accommodated can be increased without increasing the hardware cost.
[0054]
In the first embodiment, the entire process shown in FIG. 2 corresponds to the alarm content type decentralized accumulation means, and the specific alarm definition table 125 referred to in the process of step S2 is a table (referred to as the table in claim 3). Correspondingly, the processing in step S3 corresponds to the alarm level determining means. Further, the processing in step S6 corresponds to the buffer storage means, the processing in step S8 corresponds to the low-level alarm registration means, and the processing in step S12 corresponds to the high-level alarm registration means. Further, the processing in step S13 corresponds to high-level alarm display means, and the processing in step S7 corresponds to alarm accumulation timing determination means.
[0055]
In the second embodiment, the function of dividing the database into an arbitrary number by the operation of the maintenance terminal (not shown in the second embodiment) corresponds to the database dividing means, and the processing in step S24 shown in FIG. Corresponds to element accommodation database determination means. The database function of the NE group number management database 172 shown in FIG. 6 corresponds to a network element group number management unit. Further, the processing in step S22 shown in FIG. 7 corresponds to a group-by-group network element accommodation number acquiring unit, and the processing in step S25 or step S26 corresponds to a group-by-group database allocating unit.
[0056]
In the first and second embodiments, the function of the NE aggregation server 100 corresponds to the alarm monitoring device.
[0057]
【The invention's effect】
As described above, according to the present invention, the database to be accumulated is distributed according to the alarm level of each network element, and a plurality of alarm accumulation processes are started simultaneously. Insufficient memory due to queue accumulation due to O processing delay is avoided, and real-time alarm processing is realized.
[0058]
Further, the database for storing alarms for each NE is divided into n parts for each partition, and the database for storing the alarms of each NE is determined according to the number of accommodated NEs accommodated in the n-divided database. The load can be distributed, and the conventional problem that the alarm from the NE concentrates on a specific database can be avoided. Therefore, as described above, it is possible to avoid a memory shortage due to queue accumulation due to an I / O processing delay at the time of database writing, and real-time alarm processing can be performed.
[0059]
Further, the processing performance on the system is improved by the above, so that the number of NEs accommodated can be increased without increasing the hardware cost.
[Brief description of the drawings]
FIG. 1 is a diagram schematically showing a configuration of an operation system according to a first embodiment of the present invention.
FIG. 2 is a flowchart illustrating a procedure of a warning process in the NE aggregation server 100.
FIG. 3 is a diagram showing an example of a specific alarm definition table.
FIG. 4 is a diagram comparing a data amount required in a database of a database division system according to the present invention and a data amount required in a database of a conventional system.
FIG. 5 is a diagram schematically showing a configuration of an operation system according to a second embodiment of the present invention.
FIG. 6 is a functional block diagram for explaining a method of dynamically distributing and allocating partition numbers for new NEs.
FIG. 7 is a flowchart illustrating a processing procedure for dynamically distributing and allocating partition numbers for new NEs.
FIG. 8 is a diagram illustrating an example of an NE group number management database.
FIG. 9 is a diagram schematically showing a warning process from an NE in a conventional operation system.
FIG. 10 is a schematic diagram (part 1) showing an example in which a warning from an NE is stored in the same journal history DB in a conventional operation system.
FIG. 11 is a schematic diagram (part 2) showing an example in which an alarm from an NE is stored in the same journal history DB in a conventional operation system.
[Explanation of symbols]
10 Network elements (NE) # 1 to #n
11 Network element (NE) #a
12 Network element (NE) # α
13 Network element (NE) # β
14 Network Element (NE) # γ
100 NE aggregation server
102, 114 to 116, 122, 145 to 148 Alarm receiving unit
103, 104, 117, 121, 122, 150, 151 Journal database registration unit
105, 118 Journal history database (DB)
111-113, 121, 141-144 NE interface
123 Alert Journal Database Registration Unit
124 maintenance terminal communication unit
125 Specific alarm definition table
126 Alert Journal History Database (DB)
131 Specific alarm distribution unit
132 Specific Journal Database Registration Section
133 Specific alarm registration process management table
134 Timer monitoring unit
135 Specific journal history database (DB)
160, 161 Journal history database (DB) #A to #G
170 station data receiving means
171 memory
172 NE Group Number Management Database (DB)
200 maintenance terminal

Claims

In an operation system for managing a plurality of and various types of network elements (NEs) constituting a communication network,
A database for storing alarms notified from the network element is provided separately,
An operation system, comprising: an alarm content type distributed storage unit that distributes and stores the alarm in the divided database according to the alarm content represented by the alarm.

The operation system according to claim 1,
The operation system according to claim 1, wherein the database is divided based on an alarm level specified from the alarm content.

The operation system according to claim 1 or 2,
A table associating the alarm content with the alarm number,
When there is a notification of an alarm from the network element, based on the table, comprises an alarm level determining means for determining the importance of the alarm as high or low of the alarm level,
The operation system according to claim 1, wherein the alarm content type distributed accumulating means distributes and accumulates the notified alarm to any of the divided databases based on the judgment result of the alarm level judging means.

The operation system according to claim 3,
The alarm level determining means, by referring to the table, if a reference result indicating that the alarm content of the alarm notified from the network element is an alarm content having an alarm number is obtained, the alarm content is referred to as a low-level alarm. An operation system for determining, and if not, determining the content of the alarm as a high-level alarm.

The operation system according to claim 3 or 4,
The alarm level determination unit, by referring to the table, when it is determined that the alarm content of the alarm notified from the network element is a low-level alarm, a buffer storage unit that stores the alarm in a buffer,
The alarm content type distributed accumulating means includes low-level alarm registering means for accumulating, at a predetermined timing, an alarm accumulated in the buffer accumulating means in a database that accumulates low-level alarms among the divided databases. An operation system characterized by the following.

The operation system according to claim 3 or 4,
The alarm content type distributed storage means, when the alarm level determination means determines that the alarm content of the alarm notified from the network element is a high-level alarm, the alarm content of the alarm is determined by a predetermined terminal device. An operation system comprising a high-level alarm display means for outputting to an external device for display.

The operation system according to claim 6,
The alarm content type decentralized storage unit, when the alarm level determination unit determines that the alarm content of the alarm notified from the network element is a high-level alarm, splits the alarm at a predetermined timing. An operation system comprising: a high-level alarm registration unit for storing a high-level alarm in a database that stores high-level alarms among the selected databases.

The operation system according to claim 5,
The alarm content type distributed accumulation means, when the number of alarms of the same level accumulated in the buffer means has reached a predetermined number, or comprises a low-level alarm accumulation timing determination means for determining whether a predetermined time has elapsed,
When the alarm accumulation timing determination means determines that the number of alarms of the same level stored in the buffer means has reached a predetermined number or that a predetermined time has elapsed, the alarm storage timing is stored in the buffer storage means. An operation system for storing alarms in a database that stores low-level alarms among the divided databases.

An alarm monitoring device used in an operation system for managing a plurality of and various types of network elements (NEs) constituting a communication network,
A database for storing alarms notified from the network element is provided separately,
An alarm monitoring device, comprising: alarm content type distributed accumulation means for distributing and accumulating the alarm in the divided database according to the alarm content represented by the alarm.

In an alarm monitoring method for monitoring alarms from a plurality and various types of network elements (NEs) constituting a communication network,
Dividing the database storing the alarms notified from the network element based on the alarm level specified from the content of the alarm,
When an alarm is notified from the network element, referring to a predetermined table to determine the level of the alarm level indicating the importance of the alarm,
An alarm monitoring method, characterized in that an alarm notified from the network element is sorted and stored in the divided database based on the determination result.

The alarm monitoring method according to claim 10,
The alarm monitoring method is characterized in that the table is created by associating the contents of the alarm with an alarm number.

The alarm monitoring method according to claim 10 or 11,
When an alarm is notified from the network element, refer to the table,
If the content of the notified alarm is an alarm content having an alarm number, the alarm is determined to be a low-level alarm; otherwise, the alarm is determined to be a high-level alarm. .

The alarm monitoring method according to claim 12,
When the content of the alarm notified from the network element is determined to be a high-level alarm by referring to the table, the alarm is stored in a database that stores the high-level alarm among the divided databases at a predetermined timing. Accumulating, if not, buffering the alarm, and accumulating the alarm stored in the buffer when a predetermined condition is satisfied in a database of the divided databases that stores low-level alarms. An alarm monitoring method characterized in that:

The alarm monitoring method according to claim 13,
The alarm monitoring method according to claim 1, wherein the predetermined condition is either when the number of alarms of the same level stored in the buffer reaches a predetermined number or when a predetermined time has elapsed.

The alarm monitoring method according to claim 13,
When the content of the alarm notified from the network element is determined to be a high-level alarm by referring to the table, the alarm is output to a predetermined terminal device to be displayed.

In an operation system for managing a plurality of and various types of network elements (NEs) constituting a communication network,
Database dividing means for dividing a storage area of a database for storing alarms notified from the network element by n for each partition;
A network element accommodation database that determines which of the n-divided databases should accommodate the network elements accommodated in the n-divided database according to the amount of data stored in the n-divided database An operation system, comprising: a determination unit.

The operation system according to claim 16,
Assigning a group number to the database divided into n for each partition,
Network element group number management means for managing the number of network elements accommodated in the database for each group number;
The network element accommodation database determination unit, from the network element group number management unit, a group-by-group network element accommodation number acquisition unit that acquires the number of network elements accommodated in the database for each group number,
A group-by-group database allocating means for allocating a database of a group number having the smallest number of accommodated network elements among the acquired number of network elements accommodated in the database for each group number as a database for storing alarms of the corresponding network elements; An operation system comprising:

The operation system according to claim 17,
The group-by-group database allocating means allocates the database with the lowest group number as the storage destination of the alarm notified from the new network element when there are a plurality of databases with the group numbers that minimize the number of accommodated network elements. An operation system, characterized in that:

An alarm monitoring device used in an operation system for managing a plurality of and various types of network elements (NEs) constituting a communication network,
Database dividing means for dividing a storage area of a database for storing alarms notified from the network element by n for each partition;
A network element accommodation database that determines which of the n-divided databases should accommodate the network elements accommodated in the n-divided database according to the amount of data stored in the n-divided database An alarm monitoring device comprising: a determination unit.