JPH11510663A - ネットワーク解析システム - Google Patents

Abstract

(57)【要約】 電信ネットワーク設備によって発生されるパラメータデータを獲得するネットワーク解析システム。パラメータデータはネットワークの動作パラメータを表わすシステムは上記パラメータデータに適用されるテスト手順から症状データを生成するため、パラメータデータを処理する。発生し得たトラブルを表わすトラブルデータが、症状データと症状データとトラブルの間の関係を表わす関係データに基づいて生成される。ある症状とあるトラブルの間の関係は、トラブルによって惹起されるシステムの尤度を表わす。システムは上記トラブルデータに基づいて確かに発生したトラブルを表わす発生データをも生成する。

Description

【発明の詳細な説明】 ネットワーク解析システム 技術分野 本発明はネットワーク解析システムとその方法とに関する。 背景技術 遠隔通信システムでは、装置の状態と運用及び遠隔通信システムのその他の面 に莫大なデータを供給する優れた電子スイッチ装置を用いている。特に携帯遠隔 通信システムは、携帯遠隔通信ステーションの移動と使用状態に応じて多用な動 作条件に曝されている。携帯システムの動作条件には予測できない要素があり、 そのために検出する必要のある種々の異なったトラブルが発生することがある。 携帯遠隔通信システムの装置、特に、このシステムで用いているベースステーシ ョンは大量のデータを発生しており、これらのデータからトラブルを判定するこ とができる。従って、トラブル判定に適したデータにアクセスして、そのデータ を解析することでトラブルを検出できるように、遠隔通信ネットワークをモニタ ーできるのであれば、それほど好ましいことはない。 発明の開示 本発明は、 遠隔通信ネットワークの装置が発生するものであって、当該ネットワークの動 作パラメータを表すパラメータデータを得る手段と、 前記パラメータデータを処理して、当該パラメータデータに適用した試験方法 から症状データを発生する手段と、 発生したものと考えられるトラブルを表すトラブルデータを、前記症状データ と、当該症状データと前記トラブルとの関係を表す関係データとに基づいて発生 する手段とからなるネットワーク解析システムを提供している。 前記トラブルデータとしては、前記トラブルが発生する可能性を表しているも のであるのが望ましい。 また、前記システムにグラフィッカルユーザインターフェースを設ければ、前 記関係データを得ることができると共に、調整することもできて望ましい。 更に、発生したものと考えられるトラブルを表す発生データを前記トラブルデ ータに基づいて発生する手段を前記システムに設けることも望ましい。 前記発生データ発生手段は所定のルールを前記トラブルデータに適用して前記 発生データを発生するようになっているのが望ましい。また、この発生データ発 生手段は、所定の関係を有する複数の前記装置に対応したトラブルデータを比較 して前記発生データを発生するようになっているのが望ましい。前記関係によっ ては、発生データ発生手段は、前記複数の装置の内の一つのためのトラブルデー タを考慮対象から除外することができる。 本発明は、遠隔通信ネットワークの装置が発生するものであって、当該ネット ワークの動作パラメータを表すパラメータデータを得る手段と、 前記パラメータデータを処理して発生したものと考えられるトラブルを表すト ラブルデータを発生する手段と、 発生したものと考えられるトラブルを表す発生データを前記トラブルデータに 基づいて発生する手段とからなるネットワーク解析システムをも提供している。 更に、本発明は、遠隔通信ネットワークの装置が発生するものであって、当該 ネットワークの動作パラメータを表すパラメータデータを得るステップと、 前記パラメータデータを処理して、当該パラメータデータに適用した試験方法 から症状データを発生するステップと、 発生したものと考えられるトラブルを表すトラブルデータを、前記症状データ と、当該症状データと前記トラブルとの関係を表す関係データとに基づいて発生 するステップとからなるネットワーク解析方法をも提供している。 遠隔通信ネットワークの装置が発生するものであって、当該ネットワークの動 作パラメータを表すパラメータデータを得るステップと、 前記パラメータデータを処理して発生したものと考えられるトラブルを表すト ラブルデータを発生するステップと、 発生したものと考えられるトラブルを表す発生データを前記トラブルデータに 基づいて発生するステップとからなるネットワーク解析方法をも、本発明は提供 している。 図面の簡単な説明 以後、下記の添付図面を参照しながら、本発明の好ましい実施の携帯を詳述す る。 図１は、ネットワーク解析システムの好ましい実施の形態のブロック図。 図２は、システムのデータ記憶部における運用インジケータの記憶部を示す概 略図。 図３は、システムのメインメニューの図。 図４は、システムの診断推測ネットワークのブロック図。 図５は、システムの決定テーブル表示の図。 図６は、システムの別の決定テーブル表示の図。 図７は、図１のシステムの診断推奨エキスパートシステムのブロック図。 図８は、図７の診断推奨エキスパートシステムのフローチャート。 発明を実施するための最良の形態 図１に示したネットワーク解析システム２はコンピュータを基礎においたシス テムであって、データ記憶システム４と、診断推測ネットワーク（ＤＩＮ）６と 、診断推奨エキスパートシステム（ＤＲＥＳ）８と、Ｘ−ウィンドウズ準拠 ユ ーザインターフェースとからなる。ユニックスの下で稼働するサン・マイクロシ ステムズ社のSpare Station 5の如くのコンピュータワークステーションにおい てソフトを実行するものとして説明するが、解析システム２は、特定のハードウ ェア環境を用いて、又は、ソフトウェアにおいて、或いは、両方用いることによ り実行することができる。システム２のソフトウェアはＣ＋＋言語で書かれてお り、ＤＲＥＳ８については、コードはＣ言語に翻訳するＯＰＳ５ルール言語で書 かれている。 ネットワーク運用データは、携帯遠隔通信ネットワークのベースステーション の如くのネットワーク１０の装置から自動的に発生されて、データ収集システム １２により自動的に収集され、その後、データ記憶システム４に供給される。デ ータ収集システム１２は、解析システム２とネットワーク１０の装置とインター フェースするソフトウェアパッケージである共通アプリケーションプラットフォ ーム（ＣＡＰ）から得られるものであっても良い。ＣＡＰは、装置でのデータ収 集と後処理プログラムの実行をスケジュールするが、解析システム２のモジュー ルの実行をスケジュールするのに利用することもできる。このＣＡＰには、装置 からネットワークデータに自動的にアクセスして、それを解析システム２の記憶 システム４にロードするように実行される命令を含んでいる。携帯遠隔通信ネッ トワークの場合では、収集される運用データには、以下の三種のデータが含まれ ている。 ネットワークの環境を記述するために携帯電話交換局により発生されるＣＴＳ （セルトラヒック統計）データ（例えば、セル、音声チャンネル、制御チャンネ ル、セル間関係）、 信号強度、所定測定期間、通常４〜８時間に亙る信号対ノイズ比などの如くの 交換局の無線運用についての概括統計(summary statistics)をあらわす、携帯電 話交換局により発生されるＲＥＳ（無線環境統計）データ、 所定測定期間に亙るネットワークでの無線干渉の統計を表す、携帯電話交換に より発生されるＲＤＲ（無線妨害記録）データ。 データ記憶システム４はネットワーク運用データのためのデータベースを構築 している一方で、そのデータとネットワーク環境の記述にアクセスする道具をも なしている。ネットワークデータは、電話交換局、携帯セルラーネットワーク、 ベースステーションないし通信チャンネルの如くのネットワークオブジェクトに 対応する種々の異なったネットワーク運用インジケータを表している。携帯遠隔 通信ネットワークについて解析システム２が処理できるネットワーク運用インジ ケータのリストについては、第１５頁から第２０頁にかけて掲載してある。各ネ ットワークオブジェクトごとのデータは階層形式で記憶されており、ネットワー クオブジェクトのための各運用インジケータごとのデータが図２に示したように マトリックス関係で記憶されている。各ネットワークオブジェクト１４につき、 運用データの列１６は、たくさんの運用インジケータについて一日間で収集した デ ータを表しており、他方、その行１８にはオブジェクト１４の一つの運用インジ ケータについて収集されたデータの年代順の履歴が含まれている。解析システム ２のユーザインターフェースで図３に示したメインメニュー２０が得られ、この メニュー２０をみながらインターフェース２０上の下記の命令ボタンを選択する ことにより、データへアクセスするツールが得られる。 １．「データ追放」２０、このボタンでデータが選択的に削除できる。 ２．「データブラウザ」２４、このボタンで収集したネットワークデータが表示 されると共に、異なったネットワークオブジェクトに亙ってスクロールでき、更 には、どれかのオブジェクトのどれかの運用インジケータについてデータを望み の時間に亙ってグラフィッカルに、ネットワークデータの制御制約に関する情報 と発生した特別事象と共にプロットできるようになる。 ３．「制御制約のリセット」２６、このボタンでネットワーク運用インジケータ の制御制約をリセットできる。インジケータの制御制約は、当該インジケータに 予想されるランダム変化についての上限と下限（ＵＣＬとＬＣＬ）を定めている 。選択した事象が発生する時期を判定したり、ＤＩＮ６が使用する症状を同定す るのに、この制約が利用できる。制御制約リセット手順で、新制約と旧制約とを 統計比較して、ネットワークオブジェクトとその運用インジケータについてリセ ットする必要のある制御制約を特定するレポートを生成することにより、制御制 約がチェックされるようにすることができる。 ４．「事象ログ」２８、このボタンで、ＤＩＮ６又はＤＲＥＳ８によりトラブル と認知されうるネットワークオブジェクトの既知の妨害についてのログが作成さ れる。 データが一旦収集されてデータ記憶システム４に記憶されると、「ＤＩＮ実行 」命令ボタン３０を選択することでデータをＤＩＮ６に供給できる。 ＤＩＮ６は、孤立しているセルないし交換局の如くのネットワークオブジェク トを解析することにより遠隔通信ネットワークでの問題の予備診断を行うプログ ラムである。図４に示したようにＤＩＮ６はネットワークオブジェクトのネット ワーク運用インジケータの変化を検出する推測エンジン３２を利用しており、各 オブジェクトごとの決定テーブル３４を用いて、その推測エンジン３２が生成す るＤＩＮレポート３６における変化の原因を提示するようになっている。ＤＩＮ レポート３６には、特定のデータについてネットワークオブジェクトのネットワ ーク運用データに決定テーブルを適用して得られた結果が含まれている。このレ ポート３６は未フォーマットデータファイルに保存されるが、この未フォーマッ トデータファイルは、「ＤＩＮレポートのブラウザ」ボタン３８により選択され るＤＩＮブラウザモジュール３７を用いて所望通り検査、フォーマットされるよ うになっており、これでフォーマットされたＤＩＮレポート４０が得られる。 ＤＩＮ６は、大量のネットワーク運用データをモニターして、当該データによ り指摘されたあり得るトラブルを速やかに診断する。これは、トラブル診断に用 いられている理由付けの複雑さを制限することにより達成できる。それぞれのト ラブルは、ネットワークオブジェクトごとの運用データから判断される症状のパ ターンにより特徴づけられている。それぞれのパターンは、トラブルとその症状 との関係の基づく数式で表されている。これにより、後述のように決定テーブル ３４に表されている、遠隔通信のエキスパートにより確立される、トラブルに至 る症状の決定ネットワークが得られる。このことは、決定ネットワークを構築す るのにトレーニングアルゴリズムを用い、トレーニング例の集合に基づいてネッ トワークにおける重みとしてトラブル症状関係をそれとなく解読するニューラル ネットワーク法とは対比をなしている。 決定テーブル３４は、図５に示したようにユーザインターフェースにグラフィ ッカルに表示されるもので、ＤＩＮ６２よりモニターされた症状４２のリストと 、ＤＩＮ６２より推測されるトラブル４４のリストと、トラブル４４と症状４２ との関係４６の集合に関する情報を保持している。トラブル４４は決定テーブル ３４の列に割り当てられ、症状はその決定テーブル３４の行に割り当てられてい る。トラブル４４と症状４２との関係は、当該トラブル４４の列と当該症状４２ の行との交差において特定されている。このテーブル３４は、ネットワークオブ ジェクトにあり得る問題、即ち、症状４２をモニターすると共に、これらの問題 、即ち、トラブル４４の考えられる原因を提示するためにＤＩＮ６により利用さ れる。 症状４２は、「１０％超過のトラヒックオーバーフロー」の如くのネットワー ク運用インジケータにテストを適用した結果である。症状は、特定のデータｉに おけるインジケータｘ_iの値を抽出し、症状のテストをその値に適用することに より、当該データｉでのネットワークオブジェクトについて判定される。インジ ケータ値が特定のデータに得られない場合では、症状値は未知のものとなり、そ うでなければ症状値は真か偽かということになる。 運用インジケータには幾つかの異なったテストを適用することができ、これら のテストは通常、四つのメインタイプ、即ち、閾テスト、差テスト、移動平均テ スト、制御制約テスト、の内の一つである。例えば、下記のテストの一つを症状 に選択できる。 ｘ_i＜｛閾値｝ ｘ_i＜＝｛閾値｝ ｘ_i＝｛閾値｝ ｘ_i＞｛閾値｝ ｘ_i＞＝｛閾値｝ 100*（ｘ_i−ｘ_i-1）／ｘ_i-1＞｛閾値｝ -100*（ｘ_i−ｘ_i-1）／ｘ_i-1＞｛閾値｝ ｘ_i＞平均（ｘ_i-1）＋｛ｎ｝*std−dev（ｘ_i-1） ｘ_i＜平均（ｘ_i-1）−｛ｎ｝*std-dev（ｘ_i-1） ｘ_i＞制御上限 ｘ_i＜制御下限 ｘ_i制御制約外（上方又は下方） ｘ_i制御制約内（上方又は下方） トラブル４４とは、例えば「トランシーバートラブル」の如く症状４２の考え られる原因である。それぞれのネットワークオブジェクトは、それ自体のトラブ ルの集合を有していて、そのトラブルは決定テーブル３４への組み込みに選択で きるようになっている。ＤＩＮ６は、トラブルに関係のある各症状の状態に基づ いてネットワークオブジェクトごとの各トラブルの可能性をランク付けする。 それぞれの症状は複数のトラブルにより現れることもあり、同様にそれぞれの トラブルも複数の症状をもたらすこともある。トラブルのアクティブな症状が多 ければ多いほど、トラブルがあり得る可能性が大きい。ＤＩＮ６は、トラブルに 関係のある症状の値を見つけることで各トラブルの証拠を蓄積する。症状４２が トラブル４４に至る関係については、陽性(positive)、陰性(negative)、必要(n ecessary)、禁忌(prohibited)、無効(null)の四種がある。 ユーザインターフェースに白抜き円に黒点のあるものとして示した陽性関係５ ０は、症状がアクティブ（即ち、真）であれば、トラブルが考えられる原因であ ることを意味する。また、図６において二重円で示した陰性関係５０は、症状が アクティブであれば、トラブルが原因とは考えられないことを意味する。黒円で 表されている必要関係５４は、トラブルがアクティブと見なされるためには症状 がアクティブでなければならないことを意味する。白円で表された禁忌関係５６ は、症状がアクティブであれば、トラブルにより起こされたものではないことを 意味している。また、小さい黒点で表された無効関係５８は、症状でトラブルが 同定されていないことを意味する。陽性関係はトラブルとトリガーするのに利用 でき、陰性関係はトラブルをフィルターするのに利用できる。 トラブルがアクティブになる可能性は、それが関係する症状の状態を見つめる ことにより判定できる。トラブルがアクティブであるためには、その必要症状の 全てがアクティブであると同時に、禁忌症状が全てアクティブでないようでなけ ればならない。それが症状に対して必要関係を持たないのであれば、トラブルが アクティブであるためには少なくとも一つの陽性症状がアクティブでなければな らない。ＤＩＮ６は、アクティブな陽性症状の数が０より大きく、非アクティブ な必要症状がなく、また、禁忌症状もアクティブでない場合にトラブルをアクテ ィブと判定する。すると、ＤＩＮ６は下記の重み付けのトラブル可能性を生成す る。 非アクティブな必要症状があるか、アクティブな禁忌症状があるか、又は、 アクティブな陽性症状がない場合では、０、 未知の症状値ないし陰性症状がない場合では、アクティブな陽性症状の数、 アクティブな陽性症状の数をアクティブな症状と非アクティブな症状と未知 症状値の半数との合計で割った数。 トラブルがアクティブであれば、可能性重み付けに基づいてランク付けが行わ れる。 ＞＝０.６６ 非常にあり得る ＞＝０.３３＆＜０.６６ あり得る ＞０＆＜０.３３ 考えられる ０ あり得ない 下記のネットワーク運用インジケータのあるネットワークオブジェクトごとに 図６に示した決定テーブル３４を用いれば、 ＤＩＮ６が、トラブルｆ１とｆ２とは非常にあり得ること、ｆ３とｆ４とはあり 得ないとの結果を生成する。この結果は、最初の三つの症状６０が真であり、最 後の二つの症状６２が偽であることから起こるのである。ｆ１についてのこの可 能性ランク付けは１.０（非常にあり得る）であり、ｆ２については０.６７（非 常にあり得る）、ｆ３とｆ４については０（あり得ない）となっている。 「ＤＩＮエディター」命令ボタン６２を選択すると、各ネットワークオブジェ クトごとに所望通りに決定テーブル３４を編集できるようにするＤＩＮエディッ トモジュール６４が起動する。ＤＩＮエディット６４は、ユーザーをしてテーブ ル３４におけるエレメントにポインターを移動させるグラフィックユーザーイン ターフェースを備えていて、ユーザーの望み通りにテーブルが表示されるように ポインター装置を選択する。例えば、症状／トラブル交点にポインターを合わせ てクリックすると、症状／トラブル関係４６が特定される。先ず、黒点のある白 抜き円が現れ、ユーザーが再びクリックすると、その円はベタ黒円になる。もう 一度クリックすると白抜き円になり、更にもう一度クリックすると二重円になる 。最後にクリックすると黒点になって、無効関係を表すようになる。異なった関 係４６を介して移動させると円になる。トラブルラベル４４、ネットワーク運用 インジケータラベル６４、テストラベル６６のどれかにクリックを入れると、ユ ーザーに対してポップアップウィンドウがあらわれて、この中から幾つかの異な ったトラブル、インジケータ、又は、テストが選択できるようになる。すると、 決定テーブル３４がネットワークのオブジェクトに割り当てられる。デフォルト の決定テーブル３４も、「デフォルトＤＩＮテーブル設定」ボタン７０を選択す ることによりデフォルトＤＩＮテーブル設定手順を利用して設定することができ る。ＤＩＮレポート３６、４９からは、解析したオブジェクトの詳細、利用した 決定テーブル、利用した運用データの種類が分かる。このデータは通常、データ 或いはデータファイル名を参照することで特定される。症状は、それらのステー タス（アクティブ、非アクティブ、又は、未知）により、また、トラブルはそれ らのステータス（非常にあり得る、あり得る、考えられる、あり得ない）とトラ ブルの証拠の摘要とでそれぞれ説明されることになる。 図７に示したようにＤＲＥＳ８はルール準拠エキスパートシステム７０を含ん でおり、このエキスパートシステム７０は、ネットワークオブジェクトに関する データ記憶システム４から獲得したデータと生のＤＩＮレポート７２とを利用し て、考えられるトラブルのリストを同定トラブルのリストにする生のレポート７ ２を生成する。このＤＲＥＳ８にはＤＲＥＳブラウザモジュール７２も含まれて いて、このモジュール７４は「ＤＲＥＳブラウザレポート」ボタン７６を選択す ることにより起動されて、生のＤＲＥＳレポート７２が表示されると共に、ユー ザー定義フォーマット化ＤＲＥＳレポート７８に再フォーマットされるようにな る。エキスパートシステム７０は、メインメニュー２０から「ＤＲＥＳ起動」ボ タン８０を選択することで起動される。 ＤＲＥＳエキスパートシステム７０は、一度にその日のネットワーク運用デー タを利用してネットワークオブジェクトを解析することで、詳細レベルのトラブ ル診断を出す。先ず、ＤＲＥＳ８は図８に示した初期手順９０の時にＤＩＮ４か ら問題ネットワークオブジェクトに関する全てのデータにアクセスする。すると 、ＤＲＥＳ８が調査手順９２を開始して、ＤＩＮ６が同定した各オブジェクトに ついて潜在的トラブルを有するものとしてトラブルを調査する。この調査手順９ ２では、後処理プログラムを用いて先ずネットワークオブジェクトに関する外部 情報にアクセスすることにより、ＤＩＮ６が特定した特定のトラブルを追認する 。後処理プログラムは、運用データについての強化レポートを生成するために交 換局からでた運用データにアクセスするためのプログラムである。携帯セルラー ネットワークの場合では、下記のトラブルについての証拠を更に収集するために 、１チャンネル高、１チャンネル低、音声チャンネル（ＶＣ）アップリンクイン ターフェレンス、ＶＣトラブル、二チャンネル毎低とかなどの種々のトラブルを 判定するために情報にアクセスする：ＶＣ送信機（ＴＸ）パワーの低下、ベース でのＴＸパスのトラブル、ＶＣトランシーバーのトラブル、ＶＣトランシーバー のトラブル、ＶＣアップリンクの干渉、交換局に対するＰＣＭリンクの損失、ト ランシーバーのクリック、パワーレベル（ＰＬ）値の不正、ＶＣＴＸパワーの低 下。 調査手順９２では、関連ネットワークオブジェクトに関する情報にアクセスす ると共に、当該情報をチェックしている。携帯セルラーネットワークの場合では 、各ベース局には、ある程度近隣セルとオーバーラップする一つかそれ以上のセ ルがある。ベース局が呼の切換えのためにネットワークの電話交換局に接続され 、局のセルが、搬送周波数を共有するセルクラスターとして知られるグループを 形成する。エヌセル(ncell)とは、現在のセルがもう一つのセルに対して強制的 に呼を中断すると、ハンドオフを受信するのに使える隣接セルを意味する。ディ セル(dcell)とは、処理不能な呼びかけをセルが受信したときで、局ないし交換 局としてはそれらの呼を一つか又はそれ以上の近くのセルに仕向ける必要のある 、現在のセルに対してすぐ近くのセルを意味する。ノーセル(nocell)とは、現在 のセルに対して異なった交換局にあるncellを意味する。下記の表は、調査手順 ９２で得られるncell／dcell／nocell情報とトラブルを示している。例えば、Ｄ ＩＮ６が、交換局に対するＰＣＭリンクの損失があり得ると指摘すると、ＤＲＥ Ｓ８が、ncell／dcell証拠が入力データについての意義テスト(significance te st) としてプリセット閾値（TRAFOV/DROPHO＞1%とVCDESF/INSTXQ＞2%）よりも高いか どうかをチェックする。ネットワーク運用インジケータに用いた英数略語の説明 については、第１５頁から第２０頁にかけて掲載してある。 外部情報と関連オブジェクト情報にアクセスした後、ＤＲＥＳ８は調査手順９ ２を利用して、三つの異なったルールグループ、即ち、未確認問題、オブジェク ト内追テスト、一般対特定のルールグループを用いて詳細なネットワークオブジ ェクト解析を行う。携帯セルラーネットワークの場合での未確認問題グループの 一例は下記の通りである。 「交換局に対するＰＣＭリンクの損失」のトラブル又は「ベース局ハードウェ アのトラブル」にたいして間接的な証拠がある場合、この証拠が同一ベース局内 のセルからでたものかどうかをチェックして、そうでなければ除去する。 「交換局に対するＰＣＭりんくの損失」のトラブル、「ＣＣ冗長スイッチのト ラブル」、又は「ＳＳ受信局低のトラブル」を裏付ける間接証拠がない場合では 、 このトラブルを除去する。そして、 「相互交換ハンドオフデータが不正確」のトラブルがあり、セルがボーダーセ ルでない場合、このトラブルを除去する。 携帯遠隔通信セルの場合でのネットワークオブジェクト内の追テストの一例は 下記の通り。 「Ｒｘアンテナトラブル」がある場合では、HOFF1とHOFF0とが約５０％かどう かをチェックし、そうであれば追加証拠としてそれを追加する。 「ＳＳ受信局低」のトラブルがあれば、HOFF0がHOFFIよりも大きいかどうかを チェックし、そうであれば追加証拠としてそれを追加する。 「相互交換ハンドオフデータが不正確」のトラブルがあれば、証拠を除去でき なければ、DRVCCが１０よりも小さいかどうかをチェックする。 「特殊事象高トラヒック」や「セル容量問題」、「ＶＣトランシーバーの損失 」などのトラブルがあれば、証拠を除去できなければ、TRAFOVが５％よりも大き いかどうかをチェックする。 「Ｒｘアンテナトラブル」と「誤指向Ｒｘアンテナ」のトラブルが同一セルに 指摘されれば、「誤指向Ｒｘアンテナ」を除去する。 一般対特殊ルールは下記のフォーマットを有している。即ち、「Ｘ」のトラブ ルがあり、「Ｙ」のトラブルもあって、そのトラブルに「Ｚ」があらわれていな い場合、「Ｙ」トラブルを除去する。例えば、「ＶＣトランシーバーの損失」の トラブルがあり、「ＶＣトランシーバーのトラブル」もあり、_G.BS25が高いと か、_G.VC190が高いとかの証拠がない場合では、「ＶＣトランシーバーのトラブ ル」を除去する。 すると、ＤＲＥＳ８が、ルールのグループにアクセスして関連ネットワークオ ブジェクトを比較する比較手順９４を実行する。ルールのグループが一つのトラ ブルの間接証拠が別のトラブルの直接証拠であるかどうかをチェックする。例え ば、セルＢから何らかの間接証拠Ｘを有するセルＡがあり、セルＢにおいてはそ の証拠が唯一つだけの証拠であれば、セルＢからのこの証拠Ｘに係わるトラブル を除去する。例えば、セルＡに、セルＢからの高TRAFOVの間接証拠と共に「ＰＣ Ｍリンクの損失」のトラブルがあり、セルＢにおいて唯一つの証拠として高TRAF OVのトラブルがある場合、これらのトラブルを除去する。その後、除外手順９６ を用いて、運用インジケータがオーバーレイセル、又は、小さいセルやセルの範 囲を拡大するための低ノイズ増幅器を利用により発生するトラブルで、以上では あるが有効なネットワーク条件であるトラブルとして解釈されかねないネットワ ークのアスペクトに運用インジケータが関しているかどうかをチェックするルー ルグループを利用することで偽の陽性(false positives)が排除される。例えば 、セルが高DROPH0、高VCDESF、高_G.VCI90、高REGATTを有しているのであれば、 セルはトラブルでない低ノイズ増幅器を使っているかもしれない。 ＤＲＥＳ８の最終手順１００では、モジュールを起動して残りのトラブルを処 理するための推奨を検索し、生のＤＲＥＳレポート７２をファイルに書き出す。 モジュールは、残りのトラブルとそれらに関係のあるネットワークオブジェクト に関する情報と証拠とを全て収集する。生成されたＤＲＥＳレポート７２には、 ネットワークオブジェクトに割り当てられたトラブルの発生回数を含む摘要レポ ートと、ＤＲＥＳ８が同定したトラブルと持続トラブルを挙げた詳細レポートと が含まれている。ＤＲＥＳブラウザ手順７４には、ユーザーが、指定されたネッ トワークオブジェクトについて持続しているものと定義づけられている症状を含 む持続ファイル１０２を生成、もしくは、修正できるようにする持続モジュール を選択する意見が含まれている。ユーザーは、持続症状がアクティブであるとき に適用すべきテストを、症状について試したり、オーバーライドするために関連 付けすることができる。トラブルの全ての症状が持続していて、関連付けられた テストがどれもうまく行かなかった場合、トラブルは持続しているものと定義づ けられて、ＤＲＥＳレポート７２の最後の持続トラブルの部に入れられる。ユー ザーは、症状についての持続テストが最早適用できないものとしてデータを設定 することができる。 ＤＲＥＳ８について前記したルールは、トラブルデータを解析するために必要 なルールの種類を表したものであり、ここにルールベースの全体の構成を説明し た。これらのルールの形と詳細については、解析すべきネットワークの技術と実 行方法に殆ど全て依存する。ネットワークと、解析に必要なそれらの運用と方法 とは、用いる技術、設計基準、地域風土などに依存するから、ＤＲＥＳ解析ルー ルは、関係のあるネットワークの特定の詳細について構築すべきであり、詳細な ネットワークの知識なしで範囲を定めることはできない。 移動ネットワーク運用インジケータ REGATT 登録企図 TOTACC 全呼アクセス MSORG MS発信トラヒック（％） MSTERM MS着信トラヒック（％） DRVCC 音声チャネル輻そうによる指向リトライ（％） PAGE1 第１頁に対する応答（％） （最早使われない） TRAFOV トラヒックオーバーフロー（％） VCSZE VC起動 TOTLOC ロケーティングの総数 LOHOFA ハンドオフ企図当たりのロケーティング数 HOFAIL 失敗ハンドオフ（％） HOFF0 ハンドオフアウトの総数 HOFONP 非主要セルに対するハンドオフ（％） HOFAILO 失敗／不成功・ハンドオフアウト（％） HOFFI ハンドオフインの総数 HOFINP 非主要セルとしてのハンドオフイン（％） HOFAILI 失敗／不成功ハンドオフイン（％） VCDESF ＶＣ指定失敗（％） DROPHO ハンドオフでのドロップアウト（％） INSTXQ 不十分なＴＸ品質によるドロップアウト（％） CALLDO 呼ドロップアウト（％） HINSTX 取扱われた不十分ＴＸドロップアウト（％） （最早使われない） CPROGDO 呼中のドロップアウト（％） DRUPR 未知の頁応答による指向リトライ UPRREJ 未知頁応答拒否割合 HORATIO HOFFSI/HOFFSO HOFFITOT 総不成功HOイン HOFFOTOT 総不成功HOアウト A<SSACC アクセス<SSAC VCSZCII VC把握拒絶C/Iイン VCSCIO VC把握拒絶C/Iアウト ACCMULT 多重アクセス ACCALL 総アクセス(SSACC以下のものを含む) SATFOUT SATフェイルアウト SATFIN SATフェイルイン R<SSREG 登録<SSREG _ML.1 デブロックCHM上での能動化ローカル制御 _ML.10 実行されたローカル制御からの復帰 _ML.70 高すぎるPMUアラームSWR _ML.182 不法な局クラスマーク _ML.208 測定された要求屋外線 _ML.220 ハンドオフでの失敗VCスタート _ML.221 ハンドオフでの失敗VCスタート _ML.222 ディスクの低送信品質 _ML.223 SAT認証失敗 _ML.224 100VCスタート失敗 _ML.225 ハンドオフスタート失敗 _ML.226 65％VCスタート失敗 _ML.254 26VBAT<25.4V _ML.257 Rx-ボード+12V範囲外電圧 _ML.261 AIO-ユニット+5V範囲外参照 _ML.263 CCダイバーシチエラーのためのA-チャネル _ML.264 CCダイバーシチエラーのためのB-チャネル _ML.266 L0L1範囲外 _ML.267 VCダイバーシチエラーのためのA-チャネル _ML.268 VCダイバーシチエラーのためのB-チャネル _ML.307 モデムハードウエア／ソフトウエア失敗 _ML.314 検出されたFGTX合成ロック失敗 _ML.322 PMUアンテナから高すぎるSWR検出 _ML.323 A-チャネルでの多重カップラ失敗 _ML.324 B-チャネルでの多重カップラ失敗 _ML.325 A,Bチャネルでの多重カップラ失敗 _ML.338 僅かな出力電力規制ループ失敗 _ML.341 PAユニット出力規制失敗 _ML.343 検出されたPAユニット失敗 _ML.346 PAユニット出力規制失敗（高すぎるPALEVEL） _ML.347 PAユニット出力規制失敗（低すぎるPALEVEL） _ML.348 PAユニット出力規制失敗（高すぎる出力電力） _ML.349 PAユニット出力規制失敗（出力電力１dBダウン） _ML.350 PAユニット出力の高すぎるSWR _ML.351 ２つのPAユニット温度検出器のいずれか一つの故障 _ML.352 ２６Ｖ規制ボード故障 _ML.353 PAユニットの温度過剰検出 _ML.356 AIOハードウエア失敗 _ML.359 FGRXユニット合成ロック失敗 _ML.361 モデムハードウエア／ソフトウエア失敗 _ML.364 S/W Exec.キューほぼ満杯 _ML.377 接続CHM内の基準発振器警告 _G.%<ACC SSACC以下の補償されないアクセスレベルの％ _G.%OCC ブロックされない音声チャネルの専有％ _G.BLK セル内のブロックされた装置の数 _G.BNC10 ビジィ状態のすべてのチャネルで受信された補償されない信号強度の 10％ _G.BNC50 ビジィ状態の全てのチャネルで受信された補償されない信号強度の 50％ _G.BNC90 ビジィ状態の全てのチャネルで受信された補償されない信号強度の 90％ _G.BS15 15ｄＢ以下のノイズに対するビジィSat _G.BS20 20ｄＢ以下のノイズに対するビジィSat _G.BS25 25ｄＢ以下のノイズに対するビジィSat _G.BS30 30ｄＢ以下のノイズに対するビジィSat _G.CCAI10 アイドルであったときにアクセスする制御チャネルで受信された10％ 平均信号強度 _G.CCAI50 アイドルであったときにアクセスする制御チャネルで受信された50％ 平均信号強度 _G.CCAI90 アイドルであったときにアクセスする制御チャネルで受信された90％ 平均信号強度 _G.C/I10 10ｄＢ以下の干渉測定に対するキャリア％ _G.C/I15 15ｄＢ以下の干渉測定に対するキャリア％ _G.C/I18 18ｄＢ以下の干渉測定に対するキャリア％ _G.C/I20 20ｄＢ以下の干渉測定に対するキャリア％ _G.C./I25 25ｄＢ以下の干渉測定に対するキャリア％ _G_NACCS 真のアクセス数 _G.VCI10 アイドル状態のチャネルで受信された補償されない信号強度の10％ _G.VCI50 アイドル状態のチャネルで受信された補償されない信号強度の50％ _G.VCI90 アイドル状態のチャネルで受信された補償されない信号強度の90％ CUSTACCF カストマが認識したアクセス失敗（％） CPROGDO 呼中のドロップアウト（％） NETCONG ネットワーク輻そう（％） SERVLOS サービス損失 （使用されない） TOTACC 総呼アクセス TOTDHO ハンドオフを含む総ドロップアウト TOTDROP ハンドオフを除く総ドロップアウト TRAFOV トラヒックオーバーフロー（％） ACCUPR 未知の負応答によるアクセス （使用されない） DROPHO＼U ハンドオフでのドロップアウト（％） DRSUC 指向リトライ成功応答（％） INSTXQ 不十分なＴＸ品質によるドロップアウト（％） PAGEI 第１頁に対する応答 PAGECON 負輻そう PAGESUC 成功ページ STAFAIL SAT失敗 UNCREG 未確認登録 UNSUCHO 不成功ハンドオフ UPRDR 指向リトライに導かないUPR （使用されない） VCDESDR VC指定失敗（指向リトライ）（％） VCDESF VC指定失敗（全部）（％） VCSZE 音声チャネル起動 DO>5 セルの数DO>5％ R<SSREG 登録企図<SSREG ACCALL 含まれる全てのアクセス<SSACC A<SSACC アクセス<SSACC ACCMULT 多重アクセス VCSZUHO HOにおける不成功VC起動 VCSZCI 拒絶されたVC起動−低C/I _G.BS10 10ｄＢレベルでのノイズ挙動に対する総SAT％ _G.BS15 15ｄＢレベルでのノイズ挙動に対する総SAT％ _G.BS20 20ｄＢレベルでのノイズ挙動に対する総SAT％ _G.BS25 25ｄＢレベルでのノイズ挙動に対する総SAT％ _G.BS30 30ｄＢレベルでのノイズ挙動に対する総SAT％ _G.CI10 10ｄＢについての干渉挙動に対する総SAT％ _G.CI15 15ｄＢについての干渉挙動に対する総SAT％ _G.CI18 18ｄＢについての干渉挙動に対する総SAT％ _G.CI20 20ｄＢについての干渉挙動に対する総SAT％ _G.CI25 25ｄＢについての干渉挙動に対する総SAT％ _G.RSS10 対象となる全てのセルの全てのチャネルにおける全てのチャネルにつ いて10信号強度％ _G.RSS50 対象となる全てのセルの全てのチャネルにおける全てのチャネルにつ いて50信号強度％ _G.RSS90 対象となる全てのセルの全てのチャネルにおける全てのチャネルにつ いて90信号強度％

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，Ｌ Ｕ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ， ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＫＥ，ＬＳ，ＭＷ，ＳＤ，Ｓ Ｚ，ＵＧ)，ＵＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ ，ＲＵ，ＴＪ，ＴＭ)，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＵ， ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＥ，Ｈ Ｕ，ＩＬ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ， ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，Ｒ Ｏ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＴＪ，ＴＭ ，ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＳ，ＵＺ，ＶＮ (72)発明者 フラワー，マイケル・コリン オーストラリア3130ビクトリア州 ブラッ クバーン、ジ・アベニュー７番 (72)発明者 センジェン，キャサリン・ライ オーストラリア3070ビクトリア州 ノース コート、ジャクソン・ストリート５番

Claims (1)

1. 【特許請求の範囲】 １．ネットワーク解析システムは以下のものを含む： 電信ネットワーク設備によって発生されるパラメータデータを得る手段、上記 パラメータデータは上記ネットワークの動作パラメータを表わす、 上記パラメータデータを処理して上記パラメータデータに加えられるテスト操 作から症状データを生成する手段、および 上記症状データに基づいて起こり得るトラブルを表わすトラブルデータおよび 上記症状データと上記トラブルの間の関係を表わす関係データを生成する手段。 ２．上記関係データは、上記症状データに対応する症状と上記トラブルの間の関 係を表わすとともに、上記症状の一つと上記トラブルの一つの間の関係はトラブ ルによって惹起される症状の尤度を表わす、請求項１に記載のネットワーク解析 システム。 ３．上記関係は、肯定、否定、必要、禁忌もしくは中立である請求項２に記載の ネットワーク解析システム。 ４．上記トラブルデータは、当該トラブルについての症状データがアクティブ陽 性症状の数が０より多く、非アクティブな必要症状が存在せず、アクティブな禁 忌症状も存在しないことを示す時に起こり得るトラブルを指示する、請求項３に 記載のネットワーク解析システム。 ５．上記関係データを樹立するとともに調整するためのグラフィカルユーザイン ターフェースを更に含む、請求項４記載のネットワーク解析システム。 ６．上記設備についての関係データは、ネットワーク対象決定テーブル内に備え られている、請求項５に記載のネットワーク解析システム。 ７．上記トラブルデータは更に発生したトラブルの尤度を表わす、請求項１から ６のいずれか１つに記載のネットワーク解析システム。 ８．上記トラブルデータに基づいて、発生した確率の高いトラブルを表わす発生 データを生成する手段を含む、請求項１に記載のネットワーク解析システム。 ９．ネットワーク解析システムは、以下のものを含む： 電信ネットワーク設備によって生成されるパラメータデータを得る手段、 上記データは上記ネットワークの動作パラメータを表わす、発生し得たトラブ ルを表わすトラブルデータを生成するために上記パラメータデータを処理する手 段、および 上記トラブルデータを基づいて発生した確率の高いトラブルを表わす発生デー タを生成する手段。 １０．上記発生データは上記設備について上記トラブルデータに対して所定のル ールを適用することによって生成される請求項８または９に記載のネットワーク 解析システム。 １１．所定の関係を有する複数の設備のトラブルデータが、上記発生データを発 生するために比較される、請求項１０に記載のネットワーク解析システム。 １２．上記複数の設備の一つについてのトラブルデータは、高い確率で発生する トラブルを表さないように決められており、上記発生データを生成するのに使用 されない、請求項１１記載のネットワーク解析システム。 １３．上記発生データは、上記パラメータデータの更なる処理に基づいて生成さ れる、請求項１２記載のネットワーク解析システム。 １４．ネットワーク解析方法は、以下のものを含む： 電信ネットワークの設備によって生成されるパラメータデータを獲得する、上 記パラメータデータは上記ネットワークの動作パラメータを表わす、 上記パラメータデータに適用されるテスト手順から症状データを生成するため に上記パラメータデータを処理する、および 上記症状データに基づいて起こり得たトラブルを表わすトラブルデータと、上 記症状データと上記トラブルの間の関係を表わす関係データとを生成する。 １５．上記関係データは上記症状データに対応する症状と上記トラブルとの間の 関係を表わすとともに、上記症状の一つと上記トラブルの一つの間の関係がトラ ブルによって生成される症状の尤度を表わす請求項１４記載のネットワーク解析 方法。 １６．上記関係は、陽性、陰性、必要、禁忌または中立である、請求項１５記載 のネットワーク解析方法。 １７．上記トラブルデータは、上記トラブルについての症状データがアクティブ 肯定症状の数が０より多く、非アクティブな必要症状、およびアクティブな禁忌 症状がないことを示しているときに起こり得たトラブルを示す、請求項１６記載 のネットワーク解析システム。 １８．上記関係データを樹立するとともに調整するためのグラフィカルユーザイ ンターフェースを更に備える、請求項１７記載のネットワーク解析方法。 １９．上記設備についての関係データは、ネットワーク対象決定テーブル内に備 えられている、請求項１８記載のネットワーク解析方法。 ２０．上記トラブルデータは、発生したトラブルの尤度を表わす、請求項１４か ら１９のいずれか一つに記載のネットワーク解析方法。 ２１．上記トラブルデータに基づいて、発生した確率の高いトラブルを表わす発 生データを生成することを含む、請求項１４に記載のネットワーク解析方法。 ２２．ネットワーク解析方法は以下のものを含む： 電信ネットワーク設備によって生成されるパラメータデータを獲得する、上記 データは上記ネットワークの動作パラメータを表わす、 上記パラメータデータを処理して起こり得たトラブルを表わすトラブルデータ を生成する、および 上記トラブルデータに基づいて、発生した確率の高いトラブルを表わす発生デ ータを生成する。 ２３．上記発生データは、上記設備について上記トラブルデータに対し、所定の ルールを適用することによって発生される、請求項２１または２２に記載のネッ トワーク解析方法。 ２４．所定の関係を有する複数の設備のトラブルデータが上記発生データを生成 されるために比較される、請求項２３記載のネットワーク解析方法。 ２５．上記複数の設備の一つについてのトラブルデータは、確かに発生したトラ ブルを表さないように決定されており、上記発生データを生成するのに使用され ない、請求項２４記載のネットワーク解析方法。 ２６．上記発生データは、上記パラメータデータの更なる処理に基づいて生成さ れる請求項２５に記載のネットワーク解析方法。