(57)【特許請求の範囲】
【請求項１】
通信装置に対する移動ウインドウ内で発生した呼数を監視し、その障害の発生数が第１の所定の数を超えたときに異常レポート発行を行うステップと、
前記の異常レポート発行が行われた後、通信装置内で発生した障害の数を固定の呼数を有する再評価ウインドウ内で監視し、もし、前記再評価ウインドウ内で障害数が第２の所定の数を超えたときには、障害の反復報告を行うステップとを含むことを特徴とする通信装置の障害報告方法。
【請求項２】
通信装置に対する移動ウインドウ内で発生した呼数を監視し、その障害の発生数が第１の所定の数を超えたときに異常レポート発行を行う手段と、
前記の異常レポート発行が行われた後、通信装置内で発生した障害の数を固定の呼数を有する再評価ウインドウ内で監視し、もし、前記再評価ウインドウ内で障害数が第２の所定の数を超えたときには、障害の反復報告を行う手段と
を含むことを特徴とする通信装置の障害報告システム。
【発明の詳細な説明】
技術分野
本発明は、一般に、通信ネットワークを監視するシステムに関する。特に、呼量の閾値処理に基づいて異常を発生する中央局交換監視システムに関する。
背景技術
従来の中央局交換システムは、典型的には自己監視機能を備えており、それによって異常の、好ましくない障害が認識され、障害点として記録される。異常レポート（以下、「レポート」を「報告」ともいう）を作成するためにその様な障害のタイムベース閾値処理が一般的に知られている。
障害の閾値処理は、伝統的には所定の時間間隔で障害の発生を観察することによって行われる。例えば、30分の設定時間内に特定の障害が少なくとも25回発生したとすると、その特定の障害に関する異常レポートが生成される。
発明の開示
発明が解決しようとする課題
タイムベース閾値処理は、中央交換機における呼量の変化量下における障害の深刻さを正確に反映していないという点において不十分である。言い換えれば、比較的呼量が大きい時には、ある数までの障害の発生は認められるかもしれないが、呼量が小さいときには、同数の障害発生によって重大な問題を示すおそれがある。時間ベースの異常発生は、この様な異なる呼量の差を区別することはできない。特定の時間間隔内で異常発生が閾値に到達する限り、常に異常レポートが発生されるが、異なる呼量の差を区別することは保証されない。従って、異常を発生するための他の技術として電話局呼量に基づいた閾値処理を実行するシステムを有することが望ましい。
課題を解決するための手段
本発明の目的は、新たに改良された呼量ベースの中央局交換機の監視システムを提供することにある。従って、本発明の第１の側面においては、通信装置の障害報告方法において、通信装置に対する移動ウインドウ内で発生した呼数を監視し、その障害の発生数が第１の所定の数を超えたときに異常レポート発行を行うステップと、前記の異常レポート発行が行われた後、通信装置内で発生した障害の数を固定の呼数を有する再評価ウインドウ内で監視し、もし、前記再評価ウインドウ内で障害数が第２の所定の数を超えたときには、障害の反復報告を行うステップとを含むことを特徴とする。
本発明の第２の側面においては、通信装置の障害報告システムにおいて、通信装置に対する移動ウインドウ内で発生した呼数を監視し、その障害の発生数が第１の所定の数を超えたときに異常レポート発行を行う手段と、前記の異常レポート発行が行われた後、通信装置内で発生した障害の数を固定の呼数を有する再評価ウインドウ内で監視し、もし、前記再評価ウインドウ内で障害数が第２の所定の数を超えたときには、障害の反復報告を行う手段とを含むことを特徴とする。
発明を実施するための最良の形態
図１に示すように、中央局交換機10とエキスパート・システム（ES）12はリンク14を介して結合される。ES12はまたローカル・エリア・ネットワーク（LAN）やワイド・エリア・ネットワーク（WAN）のようなネットワーク16に接続され、そのネットワーク16に複数のワークステーション18が接続される。
交換機10は、従来の動作測定記録（OM）20と障害記録（ログ）22を備えている。OM20は、ペグが種々の障害をカウントしたときに、交換機10によって作り出される。上記のペグは物理的にはデータ・レジスタであり、障害が発生するたびに歩進される。交換機呼量に関する障害は、例えば、着信呼数や発信呼数などである。障害記録22は交換機が作成し、種々の障害を識別するものである。その内のいくつかは交換機10の動作不良に関係する。ノーザンテレコムのDMSスーパー・ノードは交換機10の一例であり、OM20や障害記録22を作成可能で、インタフェースも含み、そのインタフェースによって、このデータはそのインタフェースに接続されたES12などの付属装置から検索できる。
ES12はルール・ベースの処理プラットフォームで、交換機10のOM20と障害記録22を用いて、異常発生のため呼量ベースの閾値処理を行う。ES12の機能には、OM転送ユニット24、障害記録転送ユニット26・異常発生器28、異常送出ユニット30などが含まれる。OM転送ユニット24と記録薄転送ユニット26は、リンク14を介して、それぞれOM20、障害記録22を検索し、その検索データは、異常発生器に入力される。異常発生器28は、交換機10から得られるあるタイプの障害を監視するアプリケーションであり、呼量ベースの閾値処理ルールをそこに加える。例えば、所定の限度の特定の障害が、ある呼量（たとえば、1,000呼につき５呼）に達したとすると、異常発生器28は異常レポートを生成する。呼量の判断は、交換機10が処理した呼数に関連するOM20のペグカウントを監視することによって行われる。
異常発生器28は、定期的な周期で、OM転送ユニット24と障害転送ユニット26を介して、交換機10に問い合わせを行い、呼量ペグカウントをOM20および障害記録22から収集する。特定タイプの障害は、それぞれの各タイプの障害の発生と呼量限界と共に監視され、ES12に保持されたデータベースと比較確認される。異常送出ユニット30は、作成された異常レポートを、ネットワーク16を介して、たとえば、ワークステーション18の１つに出力する。回線保守担当者はそのワークステーション18を監視し、適切な処置をとる。ノーザンテレコム社製スーパーノード・データ・マネジャ（SDM）はハードウエアー・プラットフォームの一例であり、適切にプ障害ラミングされ、エキスパート・システム12用に供給される。
図１と図２を用いて、ES12による呼量ベース異常発生システムの動作ステップを次に述べる。ステップ100の監視状態において、ES12はスイッチ障害と、OMを監視する。ステップ102において障害を受信すると、ES12は、ステップ104で、データベースをチェックし、このタイプの障害を扱ったかどうか調べる。答えが「NO」の場合、ステップ100の監視状態に戻る。ステップ104での答えが「YES」の場合、ES12は、ステップ106において、既存の障害タイプと受信した障害タイプとがマッチするものがあるかについてデータベースを検索し、今受信した障害のタイプが始めて受信されたものか否かを調べる。答えが「YES」の場合、合致するタイプの障害が存在しないため、ステップ108において、新しいタイプの障害を作成し、障害が発生したときの呼数を記録する。
各障害には、各々独自の障害識別子が割り当てられる。一方、ステップ106の答えが「NO」の場合、ステップ110において、今回の発生による呼量を記録することによって既存の障害数を１だけ歩進する。同じ障害タイプの障害を受けるたびに、ステップ112において、ES12は、直近に受けたｎ呼数（たとえば、呼数10000）をチェックし、現在の呼量数からｎを引き、それにより移動ウインドウの呼量（所定の呼数）を決める。もし、ウインドウ内の障害数が閾値（所定の呼数）を超えていた場合は、ES12は、ステップ114において異常レポートを行い、監視状態100に戻る。一方、ステップ112において答が「NO」であった場合、ES12は、障害監視ステップ100に直接行き、次の障害監視を続ける。異常レポートはネットワーク16を介して、たとえば、ワークステーション18の保守要員に送られる。
ステップ114における異常レポート発行に続き、再評価ウインドウが開始され、障害が発生したときの呼数（第２の所定の呼数）に固定される。ES12は、タイマを起動すると共に、さらにｎ個の呼の発生を待ち、ｎ個の呼が発生するか、タイマがタイムアウトになると、ステップ116で、再評価ウインドウは終了する。ES12は、その後、ステップ118で、最後のレポート以降に同じタイプの障害が到着しているか否かを調べる。もし、それ以上の障害が受信されなければ、それ以上の障害を追跡する必要はないので、ES12は、ステップ120で障害を消去してもよい。しかし、その障害に関する特別の障害識別子は再使用できない。
幾つかの障害を受信したとしても、その数値が閾値ｎを超さなければ、ステップ122において再評価ウインドウはリセットされ、ES12は、再び呼移動ウインドウを用いて、新たに呼量数（ｎ）のカウントを始め、ステップ124において、最後にレポートを受けた後に発生した障害数が閾値（第２の所定の数）を超すか否かを調べる。
もし最後のｎ呼量の値が閾値（第２の所定の数）を超した場合、ステップ126において、同じ障害識別子を反復して通知し、ステップ100の監視状態に戻る。ステップ124において、その値がゼロより大きいが「閾値（第２の所定の呼数）」を超していない場合、ES12は、いかなる動作も行わず、ステップ100において障害の監視を継続する。ES12は、ネットワーク16を介して、ステップ126で生成した障害反復通知をワークステーション18の１つに送る。ステップ122において、もし、ES12によってリセットされた再評価ウインドウが時間切れになると、同じステップがステップ116によって開始される。
ステップ128において、ES12は、OM20に関連する呼量を監視し、ステップ130において、リアルタイムで呼数を計算する。この数字はステップ112と116で使用される。
図３は、図１中に示し図２に説明されているES12の呼量ベース異常発生動作の典型例を示す図である。障害をＹで表し、特定の障害の閾値を10呼区間のウインドウ中で３回と仮定する。横線200は、10呼区間の移動ウインドウを表し、縦線202は、障害Ｙの発生を表す。横線204は、以前に発生した異常レポート後に固定された10呼区間のウインドウを表す。
最初の異常レポートは14番目の呼（すなわち、呼量の14番目の呼）において出される。第３回目の障害は13番目の呼で発生しているため、最初の呼カウント３における障害Ｙの発生は最初の異常レポートの発生には関係しない。言い換えれば、200−Ｉにおいては、２つの障害Ｙのみが10呼区間の移動ウインドウ内で発生しているのみである。異常記録は呼カウント14の第４番目の障害Ｙにおいて発行される。というのは、３つの記録（すなわち、それぞれカウント6,13,14における障害2,3,4）が、200−IIに示されるように、５番目の呼と14番目の呼の間に発生しているからである。
最初の異常レポートが発行された後、次の４タイプの内いずれかが発生する可能性がある。204−Ｉに示すように、障害が、障害Ｙとその後10呼区間内に発生しない場合は、障害はクリアされる。204−IIでは、次の10呼区間にさらに３つの（又はそれ以上の）障害Ｙが発生し、その場合には、同じ障害の発生を示す反復レポートが発行される。204−IIIでは、１回（または２回、しかし３回は含まず）のみ障害Ｙが発生した場合は、10呼区間の移動ウインドウ（204−IV）内で障害Ｙが発生するか否かをさらに監視する。204−IVは、204−IIIの続きであり、呼量ベースのウインドウにさらに２つの障害が現れた場合を示す。この場合、同じ障害の反復レポートが発行される。
この発明の分野の当業者であれば、本発明の精神および意図から離れることなく種々の修正や変更を本発明に加えることができる。例えば、呼量ベースの異常発生システムは、外部の追加プラットフォームに収容することなく、中央局交換機内に容易に組み込むことができる。また、他の表示や信号を発生することによって、障害を自動的に処理でき、または異常レポートを生成できる。従って、実施の形態において特に限定されていない場合でも、上述のシステムの実施の形態に限定されるものではない。
【図面の簡単な説明】
本発明は、添付の図面を参照し、次の呼量ベースの異常発生システムの記述から理解できる
図１は、呼量ベース・異常発生システムを示すブロック図である。
図２は、図2Aと図2Bから構成され、システム動作のフローチャートを示す図である。
図３は、呼量ベースの異常発生の例を示す呼量・チャートを示す図である。
【図１】
0003581934.tif 000002
【図２】
0003581934.tif 000003
【図２Ａ】
0003581934.tif 000004
【図２Ｂ】
0003581934.tif 000005
【図３】
0003581934.tif 000006