JP6168628B1 - 障害解析装置、障害解析システム、障害解析方法、及び障害解析用プログラム - Google Patents

Abstract

【課題】音声通話に支障の出る可能性のあるネットワーク障害の発生を容易に検知し、迅速に障害から回復するための障害解析装置を提供する。【解決手段】ＲＴＰパケットを生成するＲＴＰパケット生成手段と、前記ＲＴＰパケットにＤＴＭＦ信号を付加し、障害検知信号とするＤＴＭＦ信号付加手段と、前記障害検知信号を他障害解析装置に送信する送信手段と、他障害解析装置から返信されてきた前記障害検知信号を受信する受信手段と、前記受信手段が受信した前記障害検知信号に含まれるＤＴＭＦ信号に基づき、当該障害解析装置内の問題モジュールを検出する問題検出手段と、前記問題検出手段によって検出された前記問題モジュールをリブートするリブート手段とを備える。【選択図】図４

Description

本発明は、障害解析装置、障害解析システム、障害解析方法、及び障害解析用プログラムに関し、特に、通信ネットワークで用いられる障害解析装置、障害解析システム、障害解析方法、及び障害解析用プログラムに関する。

ネットワーク機器は、その機能の性質上、さまざまなネットワーク環境に置かれ、多種多様な機器との通信を行う。そのため、ひとたび障害が発生すると、原因の切り分けに膨大な時間がかかり、かかる費用も甚大である。

また、障害が発生したとき、どのような通信が行われていたか知りたくても、ネットワークプロトコルアナライザは通常設置されていないため、現場からの情報をもとに再現試験を行い、問題を再現させて原因を究明するしかないのが、多くの場合の現状である。しかし、再現試験を行うにしても不確かな情報をもとに、考えられる試験をするほかない場合が多かった。

したがって多くの場合、手当り次第の試験にならざるを得ず、現象の再現だけでも膨大な工数が必要となる。さらに、ネットワーク機器は金融系、交通系などミッションクリティカルが要求される業務で使用されることも多く、障害が発生した場合、速やかに復旧することが求められる。しかし、多くの場合、障害が発生したことさえシステムは検知できないため、障害が発生したままの状態で運用をつづけ、業務に甚大な影響を与えてしまい、金銭的にも信用的にも大きな打撃となっていた。

例として、図１を示す。図１のゲートウェイ（Ｇａｔｅｗａｙ）装置１０−１及び１０−２は、電話機端末を収容し、上位装置２０の制御に従ってＩＰと電話機端末プロトコルとの変換を行う装置である。

例えば端末３０−１がオフフックし、相手先である端末３０−２の電話番号を押下したとき、それらの情報はＩＰパケットの制御信号として上位装置２０に送られ、上位装置２０はその番号に該当する電話機を収容しているゲートウェイ装置１０−２に対して端末３０−２の鳴動を指示するＩＰ制御パケットを送出する。ゲートウェイ装置１０−２はその制御信号を受信し、電話機を実際に鳴動させる。その端末３０−２がオフフックすると、その信号が上位装置２０に送られ、それを受けて上位装置２０から各ゲートウェイ間で通話を行うよう指示が行われる。ゲートウェイ装置１０−１は、その指示に従い、各ゲートウェイ間で通話のためのネゴシエーションを行い、完了後、相互にＲＴＰによる音声パケットをやり取りして通話を行う。

これらの制御パケットや音声パケットは、さまざまなネットワーク機器を経由するためパケットの遅延や揺らぎ等も起きやすく、それらを想定していないタイミングで処理することにより、ゲートウェイ装置が不具合を引き起こすことも多い。

これに関し、特許文献１は、センター側から端末側に送信したＲＴＰパケットと、このＲＴＰパケットに応じて、端末側からセンター側に送信されたＤＴＭＦパケットとの対応関係を判定する発明を開示している。

また、特許文献２は、サーバ、ネットワークＡ、ルータ、ネットワークＢ、端末の順に接続されているシステムにおいて、ネットワークＡでＲＴＰパケットが消失した場合、消失パケットのシーケンス番号を有すると共に、欠落に関する情報を記述したＲＴＰパケットをルータが挿入することにより、ネットワークＡとネットワークＢの何れにおいて障害が発生しているかを判定する発明を開示している。

特開２００４−１６６０４９号公報 特開２００９−０４４３００号公報

しかし、特許文献１に係る発明は、上記のようにあくまでＲＴＰパケットとＤＴＭＦパケットとの対応関係を判定する発明であって、障害を検出するものではなかった。また、特許文献２に係る発明においては、例えばルータにおいて障害が発生したために、欠落に関する情報を記述したＲＴＰパケットを挿入できなかった場合、ルータとネットワークＢとのいずれにおいて障害が発生しているのか、原因を切り分けることができなかった。

従って、ＶｏＩＰ技術を用いてＩＰネットワーク上で音声通話を行うＩＰ電話システムにおいて、ネットワーク障害が発生し音声通話に支障が出た場合、これらの発明を用いても、障害解析・原因究明・障害除去には膨大な労力が必要であった。

そこで本発明においては、音声通話に支障の出る可能性のあるネットワーク障害の発生を容易に検知し、迅速に障害から回復するための障害解析装置を提供することを目的とする。

本発明の第１の観点によれば、障害解析装置であって、ＲＴＰパケットを生成するＲＴＰパケット生成手段と、前記ＲＴＰパケットにＤＴＭＦ信号を付加し、障害検知信号とするＤＴＭＦ信号付加手段と、前記障害検知信号を他障害解析装置に送信する送信手段と、他障害解析装置から返信されてきた前記障害検知信号を受信する受信手段と、前記受信手段が受信した前記障害検知信号に含まれるＤＴＭＦ信号に基づき、当該障害解析装置内の問題モジュールを検出する問題検出手段と、前記問題検出手段によって検出された前記問題モジュールをリブートするリブート手段とを備え、前記受信手段が、更に、他障害解析装置又は当該障害解析装置の上位装置から制御信号を受信し、前記問題検出手段が、前記受信手段が受信した前記制御信号に基づき、前記問題モジュールを検出することを特徴とする障害解析装置が提供される。

本発明の第２の観点によれば、障害解析方法であって、ＲＴＰパケットを生成するＲＴＰパケット生成ステップと、前記ＲＴＰパケットにＤＴＭＦ信号を付加し、障害検知信号とするＤＴＭＦ信号付加ステップと、前記障害検知信号を他障害解析装置に送信する送信ステップと、他障害解析装置から返信されてきた前記障害検知信号を受信する受信ステップと、受信した前記障害検知信号に含まれるＤＴＭＦ信号に基づき、自障害解析装置内の問題モジュールを検出する問題検出ステップと、前記問題検出ステップにおいて検出された前記問題モジュールをリブートするリブートステップとを有し、前記受信ステップが、更に、他障害解析装置又は当該障害解析装置の上位装置から制御信号を受信し、前記問題検出ステップが、前記受信ステップが受信した前記制御信号に基づき、前記問題モジュールを検出することを特徴とする障害解析方法が提供される。

本発明の第３の観点によれば、障害解析装置としてコンピュータを機能させるための障害解析用プログラムであって、コンピュータを、ＲＴＰパケットを生成するＲＴＰパケット生成手段と、前記ＲＴＰパケットにＤＴＭＦ信号を付加し、障害検知信号とするＤＴＭＦ信号付加手段と、前記障害検知信号を他障害解析装置に送信する送信手段と、他障害解析装置から返信されてきた前記障害検知信号を受信する受信手段と、前記受信手段が受信した前記障害検知信号に含まれるＤＴＭＦ信号に基づき、当該障害解析装置内の問題モジュールを検出する問題検出手段と、前記問題検出手段によって検出された前記問題モジュールをリブートするリブート手段として機能させ、前記受信手段が、更に、他障害解析装置又は当該障害解析装置の上位装置から制御信号を受信し、前記問題検出手段が、前記受信手段が受信した前記制御信号に基づき、前記問題モジュールを検出することを特徴とする障害解析用プログラムが提供される。

本発明によれば、容易な障害発生の検知と障害からの自律復旧により、運用環境下での障害による影響を最小限にとどめることが可能となる。

ゲートウェイ装置とそれらに接続する上位装置とで構成されるシステムの従来例を示す図である。 本発明の実施形態に係る障害検知の仕組みを示す概念図である。 本発明の実施形態に係る障害検知の手法を示すフロー図である。 本発明の実施形態に係る障害解析装置の構成を示す構成図である。 本発明の実施形態に係る障害解析装置の動作を示すフロー図である。 本発明の実施形態に係る障害解析装置が実施する外部信号記録の概念図である。 本発明の実施形態に係る障害解析装置が実施する内部状態記録の概念図である。 本発明の実施形態に係る障害解析システムの構成を示す構成図である。 本発明の実施形態に係る障害解析システムのデータを用いた再現試験方法を示す図である。 本発明の実施形態に係る障害解析システムの動作例を示す図である。

（障害解析装置による障害検知及び障害からの回復）
図２に障害を検知する仕組みに関する概念図を示す。

ゲートウェイ装置と上位装置、又はゲートウェイ装置間でやり取りされる制御情報を有するパケットは、図２に示す通り、先頭にヘッダ情報として順序番号（Ｎｏ．ｘｘ）、ＣｈｅｃｋＳｕｍ、送信時間（Ｔｉｍｅ）の情報をもっており、ヘッダ情報の次に実制御情報であるＤａｔａを持つ。

ゲートウェイ装置は、これらの情報をもとにネットワークの状態を診断する。例えば、順序番号が抜けた場合はパケットのロスが発生したと判断し、ＣｈｅｃｋＳｕｍが間違っている場合はネットワークにノイズなどの異常が起きていると判断する。

次に音声信号であるＲＴＰパケットについてであるが、こちらは音声信号であるため、揺らぎやパケットロスがないことが保証されておらず、上述の方法でエラーを検知することが難しい。そのため、ＲＴＰパケットにＤＴＭＦ信号を音声として付加することで、品質チェックの手段としてＤＴＭＦ信号を利用する方法を考える。すなわち、他装置との間でＲＴＰ信号をやり取りする際、別のチャネルでもう一経路余分にＲＴＰ信号をやり取りするパスを開いておき、そこでＤＴＭＦ音を含んだＲＴＰパケットを送出し、エラー検出の手段として用いる。

図３は、その手法を示す図である。

まず、ゲートウェイ装置１００−１とゲートウェイ装置１００−２との間に音声品質チェック用の通話パスを開く。図３の通り、ゲートウェイ装置１００−１からＤＴＭＦ音声をＲＴＰ信号に乗せ、番号１から９まで連続に送信し、それを繰り返す。

受け手であるゲートウェイ装置１００−２はその信号をＤＴＭＦ信号として認識し、認識した通りに同様にゲートウェイ装置１００−１に対してＤＴＭＦ信号を返信する。ここで、ゲートウェイ装置１００−１からゲートウェイ装置１００−２にＲＴＰを送る経路で音声品質に異常が生じた場合、ＤＴＭＦ信号はゆがみ、あるいは欠損し、ゲートウェイ装置１００−２はＤＴＭＦ信号を正しく認識しない。そのため、連続に来るはずの番号が欠損したと認識するので、音声品質に影響があったと判断できる。

また、ゲートウェイ装置１００−１としては、ゲートウェイ装置１００−２の送信するＤＴＭＦ信号がやはり欠損するため、同様に問題があったことを認識できる。

そして、問題を検出したタイミングで直ちに当該問題モジュール（例えば音声通話で問題を検出した場合はＲＴＰ送出を行うＶｏＩＰ制御パッケージ）の初期化を行い、迅速にエラー状態から回復できる。

これにより、障害発生時間を最小限に抑えることが可能となる。

図４は、上記の手法を用いる、第一の実施形態である障害解析装置（ゲートウェイ装置）１００の構成を示す図である。また、図５は、図４に示される各構成要素の挙動の順序を説明するフローチャートである。

図４に示されるように、障害解析装置１００は、ＲＴＰパケット生成部１１０、ＤＴＭＦ信号付加部１２０、送信部１３０、受信部１４０、問題検出部１５０、リブート部１６０、外部信号記録部１７０、内部状態記録部１８０、及びこれらを制御する制御部１９０を含む。なお、外部信号記録部１７０及び内部状態記録部１８０は、主要部であるＲＴＰパケット生成部１１０、ＤＴＭＦ信号付加部１２０、送信部１３０、受信部１４０、問題検出部１５０、リブート部１６０、制御部１９０と別体としてもよい。あるいは、上記の主要部を含む障害解析装置１００自体と別体としてもよい。各構成要素の機能については、以下に図５を用いて示す、障害検知及び回復方法に係る説明内で述べる。

図５は、障害解析装置１００が実施する障害検知及び回復方法のフローを示すフローチャートである。

最初にＲＴＰパケット生成部１１０が、ＲＴＰパケットを生成する（ＳＴＥＰ１００１）。

次に、ＤＴＭＦ信号付加部１２０が、ＳＴＥＰ１００１において生成されたＲＴＰパケットにＤＴＭＦ信号を付加し、障害検知信号とする（ＳＴＥＰ１００２）。この際、上述のように、ＤＴＭＦ音声を番号１から９まで連続に付加し、それを繰り返す。

次に、送信部１３０が、ＳＴＥＰ１００２において生成された障害検知信号を他障害解析装置に送信する（ＳＴＥＰ１００３）。

次に、受信部１４０が、他障害解析装置から返信されてきた障害検知信号を受信する（ＳＴＥＰ１００４）。

次に、問題検出部１５０が、受信した障害検知信号に含まれるＤＴＭＦ信号を基に問題を検出する（ＳＴＥＰ１００５）。この際、ＤＴＭＦ信号を波形として検出することにより、その波形の揺らぎ、途切れ等もそのまま検出することが可能である。これにより、単なるＤＴＭＦ信号の受信有無ではなく、ＤＴＭＦ信号の品質も確認する。

次に、リブート部１６０が、ＳＴＥＰ１００５において検出された問題を有するモジュールを初期化し、再起動する（ＳＴＥＰ１００６）。

なお、上記の説明では、受信部１４０が受信した障害検知信号に含まれるＤＴＭＦ信号を基に問題を検出するとしたが、受信部１４０が受信した制御信号を基に問題を検出してもよい。この際、仮に問題のあるモジュールを特定できなかった場合は、外部信号記録部１７０及び内部状態記録部１８０が障害解析装置１００と別体である場合は、障害解析装置１００自体を初期化し、再起動してもよい。あるいは、外部信号記録部１７０及び内部状態記録部１８０が、障害解析装置１００に含まれるものの、障害解析装置１００の主要部である、図４内の点線部、すなわち、ＲＴＰパケット生成部１１０、ＤＴＭＦ信号付加部１２０、送信部１３０、受信部１４０、問題検出部１５０、リブート部１６０、制御部１９０と別体である場合は、主要部のみをリブートしてもよい。

また、上記のＳＴＥＰ１００５でＤＴＭＦ信号の品質をチェックする際は、揺らぎの大きなＤＴＭＦ信号を受信側内部ＤＳＰにてＤＴＭＦとして認識しないといった調整をしてもよい。

なお、障害解析装置１００が有する外部信号記録部１７０、及び内部状態記録部１８０等の機能については、後述する。

（障害解析装置による障害情報の記録）
次に、障害情報の記録に関して説明する。

ゲートウェイ装置は、外部からの入力であるパケットの信号をもとに動作し、それ以外の信号によって動作が変化することは基本的にない。そのため、パケットは障害解析のために最も重要な情報であるが、全てのパケットデータを保存することは、そのデータ量が膨大であるためできない。

そのため、前述の手段によって障害を検知した時点の近辺に受信したパケットのみを、外部信号記録部１７０により記録する。

図６に外部信号記録部１７０の概念図を示す。ゲートウェイ装置は、外部信号記録部１７０により、外部からのパケットをリングバッファ形式で保存し、古いものは上書きして常に保存する。障害を検知したとき、その前後数パケットのデータのみが記録される。こうすることで、障害が発生した時点、及びその近傍の時点でのパケットデータのみを記録でき、保存領域を圧迫しない。これによって障害が発生した時点の外部信号が明らかになり、障害を起こすに至ったトリガーとなる信号を特定できる。

一方、障害の発生は必ずしも外部信号のみによって決まるものではない。ゲートウェイ装置としての状態が、ある特定の状態（ステータス）の時にのみ、特定の外部信号を受けることにより、装置として想定しない動作となり、障害を引き起こすことも多い。

そのため、障害を引き起こしたときの装置の内部状態を記録することも重要となってくる。

これについて、図７を用いて説明する。

今日の一般的なデジタルコンピュータのアーキテクチャはノイマン型コンピュータであり、メインメモリにプログラムとデータを記憶し、ＣＰＵがプログラムカウンタによって実行中のプログラムのアドレスを記憶しながら順番にプログラムを実行していく方式となっている。そのため、メインメモリと、ＣＰＵ上のプログラムカウンタ（各種レジスタも含む）は、デジタルコンピュータの状態すべてを表す。したがって、これを保存し、同じアーキテクチャを持つデジタルコンピュータにロードすれば、保存した時点の状態をプログラムの実行状態含め、すべて再現できることになる。

したがって、デジタルコンピュータであるゲートウェイ装置の動作は、内部状態と外的信号によって一意に決定されるため、外部信号記録部１７０及び内部状態記録部１８０を用いて、障害発生を検知した段階でのプログラムカウンタ含むメモリおよび外部信号を保存することで、問題が起こるであろう状態をすべて保存できる。

そして、このデータを再生することで、別のゲートウェイ装置で何度でも問題を発生させることが可能となる。

一般的に問題の再現条件の究明は、問題解析にかかる時間の大半を占めていると言っても過言ではない状況であり、上述の仕組みにより１００％問題を再現させることができれば、問題解析のスピードは飛躍的に向上する。

上記のように本発明に係る障害解析装置は、問題モジュールを特定したら、当該問題モジュールをとりあえずリブートし、その後、以下に示す障害解析システムが上記の外部信号及び内部記録のデータを用いて、具体的な障害の解析を行うものである。これにより、ユーザに障害を障害として認識させる以前の段階で、問題モジュールをリブートすることが可能となる。

（障害解析システムの概要）
図８は、上記のゲートウェイ装置でもある上記の障害解析装置１００−１及び１００−２を備える障害解析システム５００の概要を示す図である。

障害解析システム５００は、図２に示されるシステムと同様に、互いに接続されたゲートウェイ装置（障害解析装置）１００−１及び１００−２と上位装置２００を含む。更に障害解析システム５００は、これらゲートウェイ装置（障害解析装置）１００−１及び１００−２と上位装置２００とに接続するＰＣ端末１５０を含む。

このゲートウェイ装置（障害解析装置）１００−１及び１００−２としては、電話機端末を収容するゲートウェイ装置を考える。

また、図２を用いて説明したように、ゲートウェイ装置１００−１及び１００−２と上位装置２００との間、及びゲートウェイ装置１００−１及び１００−２同士は、エラー検出可能な信号で通信を行っており、また図３で示した仕組みにより、通話異常や動作遅延などが発生した場合に、直ちに問題を検出することができる。

問題を検出した場合、前述の手順に従い直ちにゲートウェイ装置のメモリ状態を退避し、外部信号の保存を行う。情報の退避が完了したら直ちに当該問題モジュールの部分的再起動を行い、自律的に障害復旧を行う。

障害通知については、図８に示す経路で行われる。

障害が発生したという情報は、ゲートウェイ装置１００−１から上位装置２００に通知され、上位装置２００は音声ネットワークを保守する保守担当者のＰＣ端末４００に対して、メールなどで通知を行う。メールで障害発生を検知した保守担当者は障害発生を即座に認識し、外部からゲートウェイ装置１００−１にアクセスする。これにより、ゲートウェイ装置１００−１に保存してある外部信号とメモリ状態（内部状態）を即座に入手できる。

取得したデータは、保守担当者から技術担当者に渡され、技術担当者はラボなどで、当該ラボに存在するゲートウェイ装置に対して、取得したデータのロードを行う。この時、ゲートウェイ装置の状態は、図６で示した外部信号と図７で示した内部情報とにより一意に決定されるのでネットワーク環境なども特に現地に合わせる必要はなく、上位装置、端末等も必要ない。つまり、図９に示すようにゲートウェイ装置１０００とＰＣ端末１５００さえあれば、ゲートウェイ装置１０００の内部状態として、障害が発生した現地と全く同じ状態をつくることができ、再現試験を極めて簡単に行うことができる。さらに、この状態でゲートウェイ装置１０００にＩＣＥなどの解析機器（デバッガツール）１１００を接続することで、ゲートウェイ装置１０００内部の解析が容易になり、直ちに問題の特定に至ることも困難ではない。

図８における構成例では、上位装置２００から外部ネットワークを経由して保守担当者のＰＣ端末４００に直接メールを送信し、リアルタイムな障害通知を可能にしている。また、保守担当者は、メール経由で障害発生したゲートウェイ装置１００−１のＩＰアドレス情報も取得できるため、同じく外部からゲートウェイ装置１００−１に直接アクセスでき、必要な情報を吸い上げることが出来る。そして、保守担当者が必要だと判断したときには、技術担当者にメールで連絡し、吸い上げた情報を技術担当者に送信することができる。

また、上位装置２００からの通知をトリガーに、ゲートウェイ装置１００−１へのアクセスおよび情報収集を自動的に行うことも可能である。これによって、保守担当者が注視しなくても自動的にＰＣ端末１５０に必要な情報は保存されていき、定期的なメンテナンスにてエラーの発生有無をチェックすることも可能である。

（障害解析システムの使用方法概要）
図８及び図９で示した実施例に関して、実際の障害解析の流れについて説明する。

障害を検知したとき、ゲートウェイ装置１００−１は外部信号及び内部のメモリ状態（内部状態）を全て保存し、上位装置２００に障害が発生したことを通知する。

ゲートウェイ装置１００−１は、上記の外部信号の情報及び内部状態の情報を含む必要な情報を、各々、外部記憶装置等の外部信号記録部１７０及び内部状態記録部１８０に保存後、問題箇所の部分的なリブートもしくは装置自体のリブートによりプログラムの異常状態等を速やかに復旧させる。このとき、障害解析に必要な情報はすべて外部記憶装置に保存されており、装置のリブートによって情報が消えることはない。

上位装置２００は、ゲートウェイ装置１００−１から障害通知を受信したとき、あらかじめ設定された保守者のメールアドレス等を用いて、保守者が使用するＰＣ端末４００に対し、障害が発生した旨とゲートウェイ装置１００−１のＩＰアドレスを通知する。保守者は、障害が発生したゲートウェイ装置１００−１のＩＰアドレスを知ることができるので、そのゲートウェイ装置１００−１にアクセスでき、必要なデータを取得することが可能となる。

ゲートウェイ装置１００−１の不具合である可能性がある場合、保守担当者は開発担当者に取得したデータを渡し、解析を依頼する。取得データは、開発担当者から、ラボにあるゲートウェイ装置１０００にロードされ、不具合発生時点のゲートウェイ装置１００−１の状態を再現することが可能となる。

（障害解析システムの動作例）
実際の障害内容については多種多様であるが、例として、上位装置２００からゲートウェイ装置１００−１に対して想定外の指示を与えた場合を示す。

ゲートウェイ装置１００−１が設計考慮漏れ等により、上位装置２００から想定外のパラメータ等を含む指示を受信した場合、ゲートウェイ装置１００−１はパラメータエラーとなり、正常に通話動作を行うことができない。

図１０に例を示す。

上位装置２００がゲートウェイ装置１００−１に対し通話指示を行った時、ゲートウェイ装置１００−１は他のゲートウェイ装置１００−２と通話ネゴシエーションを行い、その後ＲＴＰのやり取りを行って通話を行うが、プログラムのエラーにより、ＲＴＰパケットを送出することができない状態となったとする。

この時、前述のＤＴＭＦ信号のやり取りによって通話障害が検出される。

図６で示した仕組みにより、障害発生時点及びその近傍の時点の外部信号は全て記録されている。これにより、障害が検出されたのは「３．ＲＴＰパケット」においてであるが、通話開始のトリガーとなる「１．通話指示」も記録されている。

ゲートウェイ装置１００−１の内部状態も各々の外部信号に対して対となるよう記録されており、各々の信号を処理する直前の内部状態がメモリに保存されている。すなわち、この状態のメモリをゲートウェイ装置１０００にロードすれば、その信号を処理する直前のゲートウェイ装置１００−１の状態を再生可能となり、外部信号を与えてそのままプログラムを走らせれば、その信号を処理したときのプログラムのトレースを行うことができる。もし、現地にて障害発生のトリガーとなった信号と内部状態の組み合わせを特定できれば、プログラム上問題となる箇所（バグ）に到達する。

この例における問題は、上位装置からの想定外の指示によるゲートウェイ装置１００−１の動作不良であるので、ゲートウェイ装置１０００において、「１．通話指示処理時」の内部状態の下で、「１．通話指示（上位装置）」なる外部信号の入力を与えたとき、プログラム上想定していない処理に流れ、ＲＴＰの送出が正常に行えない状態が再現する。

この時、ＩＣＥなどのデバッガツールを備えた環境であれば、プログラムのステップ実行が可能であるのでどのようなルートを通って異常処理に流れるか容易に特定可能である。

以上の仕組みにより、問題の再現および、現象の特定は極めて簡単に行うことができる。

上記の実施形態により、ＤＴＭＦ信号が正しく受信できない場合、通話音声の遅延、ゆらぎ、途切れ等に繋がるＩＰネットワーク障害が発生していると判断され、解析に必要なデータの取得を開始することが可能となる。ＤＴＭＦ信号の送信回路や受信回路は、従来電話装置には搭載されているため、安価に発明を実施することが可能である。

また、従来行われているキープアライブ信号の通信やＰＩＮＧパケットによる障害発生の検出方法だと、ＩＰパケットが通らないようなネットワーク障害や相手機器が動作不能になっていることは検知できたとしても、パケットは通っているものの、遅延や、音声信号のゆらぎ、途切れ等、音声通話に支障が出る、ネットワーク障害までを検知することはできなかった。この点、本実施形態によれば、パケットは通っているもののネットワーク障害が発生していることを検知することが可能である。

更に、ソフトウェア開発において非常に大きな割合を占める保守工数を大幅に削減することが可能である。

ひいては、障害となっている現象の確実かつ迅速な再現、その原因の迅速な特定と修正の適用、並びに、障害からの速やかな回復が可能である。具体的には、ネットワーク機器内部に障害記録、解析機能を内蔵することにより、障害解析をやりやすくするとともに、障害からの自律復旧機能を備えることにより、運用環境下での影響を最小限にとどめることが可能となる。

（その他の実施例）
実用上の制約として、図７で示した内部状態すべてを記録することは、外部記録装置の制約等により難しい場合もある。その場合は、必要最小限のメモリにとどめることで記憶容量を圧縮する。きっかけとなる外部信号と、最低限必要なメモリだけでも知ることができれば、開発者にとっては非常に大きなヒントとなり、原因の究明に大きく寄与すると考えられる。

以上、上記各実施例を参照して本発明を説明したが、本発明は上記各実施例に限定されるものではない。本発明の構成や詳細には、本発明の範囲内で当業者が理解し得る様々な変更をすることができる。

なお、上記障害解析装置及び障害解析システムの各部分は、ハードウェア、ソフトウェアのいずれか又はこれらの組み合わせにより実現することができる。また、上記の障害解析装置又は障害解析システムにより行われる障害解析方法も、ハードウェア、ソフトウェアのいずれか又はこれらの組み合わせにより実現することができる。ここで、ソフトウェアによって実現されるとは、コンピュータがプログラムを読み込んで実行すること、又は、ハードウェアがプログラムに相当するマイクロコードに従って動作することにより実現されることを意味する。

プログラムは、様々なタイプの非一時的なコンピュータ可読媒体（non-transitory computer readable medium）を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（tangible storage medium）を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えば、フレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば、光磁気ディスク）、ＣＤ−ＲＯＭ（Read Only Memory）、ＣＤ−Ｒ、ＣＤ−Ｒ／Ｗ、半導体メモリ（例えば、マスクＲＯＭ、ＰＲＯＭ（Programmable ROM）、ＥＰＲＯＭ（Erasable PROM）、フラッシュＲＯＭ、ＲＡＭ（random access memory））を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体（transitory computer readable medium）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。

上記の実施形態の一部または全部は、以下の付記のようにも記載されるが、以下には限られない。
（付記１）
障害解析装置であって、
ＲＴＰパケットを生成するＲＴＰパケット生成手段と、
前記ＲＴＰパケットにＤＴＭＦ信号を付加し、障害検知信号とするＤＴＭＦ信号付加手段と、
前記障害検知信号を他障害解析装置に送信する送信手段と、
他障害解析装置から返信されてきた前記障害検知信号を受信する受信手段と、
前記受信手段が受信した前記障害検知信号に含まれるＤＴＭＦ信号に基づき、当該障害解析装置内の問題モジュールを検出する問題検出手段と、
前記問題検出手段によって検出された前記問題モジュールをリブートするリブート手段とを備えることを特徴とする障害解析装置。
（付記２）
付記１に記載の障害解析装置であって、
前記ＤＴＭＦ信号付加手段は、前記ＲＴＰパケットに対して複数種類のＤＴＭＦ信号を順番に付加し、前記問題検出手段は、前記受信手段が受信した前記障害検知信号に含まれるＤＴＭＦ信号が、付加された順番通りに前記障害検知信号に含まれるか否かに基づき、前記問題モジュールを検出することを特徴とする障害解析装置。
（付記３）
付記１又は２に記載の障害解析装置であって、
前記受信手段が、更に、他障害解析装置又は当該障害解析装置の上位装置から制御信号を受信し、
前記問題検出手段が、前記受信手段が受信した前記制御信号に基づき、前記問題モジュールを検出することを特徴とする障害解析装置。
（付記４）
付記１乃至３のいずれか１に記載の障害解析装置であって、
前記問題検出手段が、前記問題モジュールを特定できなかった際は、前記リブート手段が、当該障害解析装置自体をリブートすることを特徴とする障害解析装置。
（付記５）
付記３又は４に記載の障害解析装置であって、
前記受信手段が更に音声信号を受信し、
前記受信手段が受信した前記音声信号及び前記制御信号を含む外部信号のうち、前記問題モジュールにおける問題が発生した時点及びその前後所定個数分のパケットに対応する外部信号を記録する外部信号記録手段を更に備えることを特徴とする障害解析装置。
（付記６）
付記５に記載の障害解析装置であって、
前記受信手段が前記外部信号を受信した時点での当該障害解析装置の内部状態を記録する内部状態記録手段を更に備えることを特徴とする障害解析装置。
（付記７）
障害解析システムであって、
互いに接続された複数の付記１乃至６のいずれか１に記載の障害解析装置と、
前記複数の障害解析装置を制御する上位装置とを備えることを特徴とする障害解析システム。
（付記８）
付記７に記載の障害解析システムであって、
前記上位装置及び前記複数の障害解析装置に接続された外部端末を更に備え、
前記複数の障害解析装置のうち何れかの障害解析装置において、前記問題モジュール内の問題が発生した際、前記上位端末は前記外部端末に対して、前記問題の発生と前記問題が発生した障害解析装置のＩＰアドレスとを通知することを特徴とする障害解析システム。
（付記９）
互いに接続された複数の付記６に記載の障害解析装置と、
前記複数の障害解析装置を制御する上位装置とを備える障害解析システムであって、
前記外部端末が、前記問題が発生した障害解析装置が記憶する前記外部信号と前記内部状態とを、前記問題が発生した障害解析装置から受信することを特徴とする障害解析システム。
（付記１０）
付記９に記載の障害解析システムであって、
前記外部端末は、前記上位端末からの前記問題の発生と前記ＩＰアドレスとの通知をトリガーとして、前記問題が発生した障害解析装置が記憶する前記外部信号と前記内部状態とを自動的に受信することを特徴とする障害解析システム。
（付記１１）
障害解析方法であって、
ＲＴＰパケットを生成するＲＴＰパケット生成ステップと、
前記ＲＴＰパケットにＤＴＭＦ信号を付加し、障害検知信号とするＤＴＭＦ信号付加ステップと、
前記障害検知信号を他障害解析装置に送信する送信ステップと、
他障害解析装置から返信されてきた前記障害検知信号を受信する受信ステップと、
受信した前記障害検知信号に含まれるＤＴＭＦ信号に基づき、自障害解析装置内の問題モジュールを検出する問題検出ステップと、
前記問題検出ステップにおいて検出された前記問題モジュールをリブートするリブートステップとを有することを特徴とする障害解析方法。
（付記１２）
障害解析装置としてコンピュータを機能させるための障害解析用プログラムであって、
コンピュータを、
ＲＴＰパケットを生成するＲＴＰパケット生成手段と、
前記ＲＴＰ信号にＤＴＭＦ信号を付加し、障害検知信号とするＤＴＭＦ信号付加手段と、
前記障害検知信号を他障害解析装置に送信する送信手段と、
他障害解析装置から返信されてきた前記障害検知信号を受信する受信手段と、
前記受信部が受信した前記障害検知信号に含まれるＤＴＭＦ信号に基づき、当該障害解析装置内の問題モジュールを検出する問題検出手段と、
前記問題検出手段によって検出された前記問題モジュールをリブートするリブート手段として機能させるための障害解析用プログラム。

本発明は、通信ネットワークの分野で用いることが可能である。とりわけ、通話端末を収容する通信ネットワークの分野で用いることが好適である。

１０−１ １０−２ ゲートウェイ装置
２０ 上位装置
３０−１ ３０−２ 端末
１００ １００−１ １００−２ 障害解析装置（ゲートウェイ装置）
１１０ ＲＴＰパケット生成部
１２０ ＤＴＭＦ信号付加部
１３０ 送信部
１４０ 受信部
１５０ 問題検出部
１６０ リブート部
１７０ 外部信号記録部
１８０ 内部状態記録部
１９０ 制御部
２００ 上位装置
３００−１ ３００−２ 端末
４００ ＰＣ端末
５００ 障害解析システム
１０００ ゲートウェイ装置
１１００ デバッガツール
１４００ ＰＣ端末

Claims (9)

1. 障害解析装置であって、
   ＲＴＰパケットを生成するＲＴＰパケット生成手段と、
   前記ＲＴＰパケットにＤＴＭＦ信号を付加し、障害検知信号とするＤＴＭＦ信号付加手段と、
   前記障害検知信号を他障害解析装置に送信する送信手段と、
   他障害解析装置から返信されてきた前記障害検知信号を受信する受信手段と、
   前記受信手段が受信した前記障害検知信号に含まれるＤＴＭＦ信号に基づき、当該障害解析装置内の問題モジュールを検出する問題検出手段と、
   前記問題検出手段によって検出された前記問題モジュールをリブートするリブート手段と
   を備え、
   前記受信手段が、更に、他障害解析装置又は当該障害解析装置の上位装置から制御信号を受信し、
   前記問題検出手段が、前記受信手段が受信した前記制御信号に基づき、前記問題モジュールを検出する
   ことを特徴とする障害解析装置。
2. 請求項１に記載の障害解析装置であって、
   前記ＤＴＭＦ信号付加手段は、前記ＲＴＰパケットに対して複数種類のＤＴＭＦ信号を順番に付加し、
   前記問題検出手段は、前記受信手段が受信した前記障害検知信号に含まれるＤＴＭＦ信号が、付加された順番通りに前記障害検知信号に含まれるか否かに基づき、前記問題モジュールを検出する
   ことを特徴とする障害解析装置。
3. 請求項１又は２に記載の障害解析装置であって、
   前記問題検出手段が、前記問題モジュールを特定できなかった際は、前記リブート手段が、当該障害解析装置自体をリブートする
   ことを特徴とする障害解析装置。
4. 請求項２又は３に記載の障害解析装置であって、
   前記受信手段が更に音声信号を受信し、前記受信手段が受信した前記音声信号及び前記制御信号を含む外部信号のうち、前記問題モジュールにおける問題が発生した時点及びその前後の所定個数分のパケットに対応する外部信号を記録する外部信号記録手段を更に備える
   ことを特徴とする障害解析装置。
5. 請求項４に記載の障害解析装置であって、
   前記受信手段が前記外部信号を受信した時点での当該障害解析装置の内部状態を記録する内部状態記録手段
   を更に備える
   ことを特徴とする障害解析装置。
6. 障害解析システムであって、
   互いに接続された複数の請求項１乃至５のいずれか１項に記載の障害解析装置と、
   前記複数の障害解析装置を制御する上位装置と
   を備えることを特徴とする障害解析システム。
7. 請求項６に記載の障害解析システムであって、
   前記上位装置及び前記複数の障害解析装置に接続された外部端末を更に備え、
   前記複数の障害解析装置のうち何れかの障害解析装置において、前記問題モジュール内の問題が発生した際、前記上位装置は前記外部端末に対して、前記問題の発生と前記問題が発生した障害解析装置のＩＰアドレスとを通知する
   ことを特徴とする障害解析システム。
8. 障害解析方法であって、
   ＲＴＰパケットを生成するＲＴＰパケット生成ステップと、
   前記ＲＴＰパケットにＤＴＭＦ信号を付加し、障害検知信号とするＤＴＭＦ信号付加ステップと、
   前記障害検知信号を他障害解析装置に送信する送信ステップと、
   他障害解析装置から返信されてきた前記障害検知信号を受信する受信ステップと、
   受信した前記障害検知信号に含まれるＤＴＭＦ信号に基づき、自障害解析装置内の問題モジュールを検出する問題検出ステップと、
   前記問題検出ステップにおいて検出された前記問題モジュールをリブートするリブートステップと
   を有し、
   前記受信ステップが、更に、他障害解析装置又は当該障害解析装置の上位装置から制御信号を受信し、
   前記問題検出ステップが、前記受信ステップが受信した前記制御信号に基づき、前記問題モジュールを検出する
   ことを特徴とする障害解析方法。
9. 障害解析装置としてコンピュータを機能させるための障害解析用プログラムであって、
   コンピュータを、
   ＲＴＰパケットを生成するＲＴＰパケット生成手段と、
   前記ＲＴＰパケットにＤＴＭＦ信号を付加し、障害検知信号とするＤＴＭＦ信号付加手段と、
   前記障害検知信号を他障害解析装置に送信する送信手段と、
   他障害解析装置から返信されてきた前記障害検知信号を受信する受信手段と、
   前記受信手段が受信した前記障害検知信号に含まれるＤＴＭＦ信号に基づき、当該障害解析装置内の問題モジュールを検出する問題検出手段と、
   前記問題検出手段によって検出された前記問題モジュールをリブートするリブート手段として機能させ、
   前記受信手段が、更に、他障害解析装置又は当該障害解析装置の上位装置から制御信号を受信し、
   前記問題検出手段が、前記受信手段が受信した前記制御信号に基づき、前記問題モジュールを検出する
   ことを特徴とする障害解析用プログラム。

Images