JP2011250250A - 障害検出装置、方法及びプログラム - Google Patents

Abstract

【課題】音声通信の音声品質を劣化させている通信網上の箇所を特定する技術を提供する。
【解決手段】第１ユーザ端末と第２ユーザ端末との間の音声通信を実現する通信網で利用される障害検出装置は、通信網を流れる呼制御パケット及び音声パケットを通信網上の複数箇所からそれぞれ取り出す取得手段と、当該複数個所の各々から取り出された呼制御パケット及び音声パケットに基づいて、複数箇所の各々における第１ユーザ端末から第２ユーザ端末方向の音声品質情報及び第２ユーザ端末から第１ユーザ端末方向の音声品質情報を含む呼情報を、各呼についてそれぞれ管理する管理手段と、この管理手段により管理される呼情報に応じて音声通信の音声品質を劣化させる障害箇所を特定する特定手段と、を備える。
【選択図】図１

Description

本発明は、ネットワーク上の障害検出技術に関する。

現在、インターネット等のＩＰ（Internet Protocol）ネットワークを用いて音声通信
を行う技術が実用化されている。このような音声通信では、通話情報は、ＩＰをサポートする交換機（以降、ＩＰ交換機と表記する）により交換制御され、呼制御等のためのシグナリング情報及び音声通話データとして各種制御サーバを経由して伝達される。なお、シグナリング情報はＣプレーン情報とも呼ばれ、音声通話データはＵプレーン情報とも呼ばれる。Ｃプレーン情報は例えばＳＩＰ（Session Initiation Protocol）パケットにより
ＩＰネットワーク上を伝送される。Ｕプレーン情報はＲＴＰ（Real-time Transport Protocol）パケットによりＩＰネットワーク上を伝送される。

このようなＩＰネットワークを用いた音声通信システムでは、発信者からの呼は、その発信者が収容される電話網に接続されるＩＰ交換機に送られる。最終的には、その呼がそのＩＰ交換機からＩＰネットワークを経由して着信者が収容される電話網に接続される他のＩＰ交換機へ送られることにより、発信者と着信者との間の音声通話が実現される。発信者及び着信者が収容される電話網には、例えば、ＰＳＴＮ（Public Switched Telephone Networks）等の既存電話網やＰＤＣ（Personal Digital Cellular）等のような携帯電
話網が存在する。

このような音声通信システムではサービス品質を保つために監視手段が実装される。この監視手段は、例えば、ＩＰ交換機を経由する音声情報パケットをキャプチャすることにより通話品質を測定することにより、通話の劣化発生状況に応じて障害が発生していると想定されるＩＰ交換機を特定する。また、監視手段が、各ＩＰ交換機から定期的にＣＰＵ（Central Processing Unit）負荷状況や故障の発生状況をそれぞれ収集し、この収集さ
れた情報から障害が発生していると想定されるＩＰ交換機を特定する手法も存在する。

特開２０００−１３３７４号公報

しかしながら、上述のような従来の音声通信システムの監視手法では以下のような問題がある。音声情報パケットをキャプチャする手法では、障害が発生していると想定されるＩＰ交換機が特定されたとしても、その障害発生の要因まで特定することはできない。保守者が、各通話についての監視結果で障害が生じていると想定されるＩＰ交換機の情報を各通話についてそれぞれ集計することにより、劣化要因を或る程度推定することは可能かもしれない。しかしながら、監視対象となり得る通話数は、例えば、１分間に１００万通話のように膨大であるため、保守者による手動での劣化箇所の特定は実質不可能である。

また、監視手段による収集手法では、必要な情報を収集するための処理負荷、及び、ネットワーク負荷が余計に掛かってしまう。この収集周期を長くすると、品質劣化の検出が遅れてしまう。また、この手法では、ＩＰ交換機等のような装置自体の情報を収集しているに過ぎないため、実際の音声通話サービスの品質を判定することはできない。更に、サイレント故障等のような装置自体で検知できない劣化は検出することができない。

本発明の一態様に係る課題は、このような問題点に鑑み、音声通信の音声品質を劣化させている通信網上の箇所を特定する技術を提供することにある。

本発明の各態様では、上述した課題を解決するために、それぞれ以下の構成を採用する。

第１の態様は、第１ユーザ端末と第２ユーザ端末との間の音声通信を実現する通信網で利用される障害検出装置に関する。第１の態様に係る障害検出装置は、通信網を流れる呼制御パケット及び音声パケットを通信網上の複数箇所からそれぞれ取り出す取得手段と、当該複数個所の各々から取り出された呼制御パケット及び音声パケットに基づいて、複数箇所の各々における第１ユーザ端末から第２ユーザ端末方向の音声品質及び第２ユーザ端末から第１ユーザ端末方向の音声品質を含む呼情報を、各呼についてそれぞれ管理する管理手段と、この管理手段により管理される呼情報に応じて音声通信の音声品質を劣化させる障害箇所を特定する特定手段と、を備える。

なお、本発明の別態様としては、上記態様の各構成要素を実現する障害検出方法であってもよいし、障害検出プログラムであってもよいし、このようなプログラムを記録したコンピュータが読み取り可能な記憶媒体であってもよい。

上記各態様によれば、音声通信の音声品質を劣化させている通信網上の箇所を特定する技術を提供することができる。

音声通信システムの概略構成例を示す図。 本実施例の障害検出システムのハードウェア構成例を示す図。 プローブ装置１０、コレクタ装置２０及びマネージャ装置３０における各処理部の構成例を示す図。 呼管理テーブルの例を示す図。 本実施例における障害検出システムの動作シーケンスを示す図。 障害箇所特定処理を示すフローチャート。 音声品質情報と特定される障害箇所との関係を示す表。 呼管理テーブルの変形例を示す図。 変形例として障害検出装置の詳細構成を示す図。 変形例の障害検出システムの詳細構成を示す図。 優先度テーブル２７の例を示す図。

以下、一実施形態としての障害検出システムについて具体例（以降、実施例と表記する）を挙げ説明する。以下、実施例の障害検出システムが、ＩＰネットワークを用いて音声通信を行う音声通信システムに適用される場合を例に挙げ説明する。この例では、通信プロトコルとしてＩＰを例に挙げるが、本実施形態はこのような通信プロトコルを限定するものではない。以下に挙げた実施例はそれぞれ例示であり、本実施形態は以下の実施例の構成に限定されない。

［システム構成］
実施例の障害検出システムが適用される音声通信システムのシステム構成について図１を用いて説明する。図１は、音声通信システムの概略構成例を示す図である。音声通信シ
ステムは、ローカル網１、ＩＰ交換機２、ルータ３、ＩＰ網５等を含み、ローカル網１を介して接続されるユーザ端末に音声通信サービスを提供する。

ローカル網１は、発信者となるユーザ端末（以降、発信者端末と表記する）や着信者となるユーザ端末（以降、着信者端末と表記する）が存在する各エリアに設置されたネットワークである。ローカル網１は、例えば、ＰＳＴＮ等の既存電話網、ＰＤＣ等のような携帯電話網、ＩＰ電話等が接続されるＬＡＮ（Local Area Network）等である。図１は、発信者端末が存在するエリアに存在するローカル網１（Ｔ）と、着信者端末が存在するエリアに存在するローカル網１（Ｒ）とを区別して表記する。しかしながら、本実施形態は、発信者端末及び着信者端末が収容されるローカル網１を制限するものではない。ここで、発信者とは、音声通信を開始した、即ち、発呼したユーザを意味し、着信者とは、当該発信者から発せられた音声通信を受け入れた、即ち、着呼したユーザを意味する。

ＩＰ網５は、インターネット等のような各ローカル網１を接続し得るネットワークである。

ＩＰ交換機２は、各ローカル網１及びＩＰ網５にそれぞれ接続され、各ローカル網１とＩＰ網５との間の中継機である。ＩＰ交換機２は、発信者端末からの呼をローカル網１を経由して受信し、この呼を必要に応じて呼制御パケット及び音声パケットに変換し、呼制御パケット及び音声パケットをＩＰ網５側へ転送する。逆に、ＩＰ交換機２は、呼制御パケット及び音声パケットをＩＰ網５を経由して受信すると、この呼制御パケット及び音声パケットを必要に応じて呼信号に変換し、この呼信号をローカル網１側へ送出する。なお、ローカル網１がＩＰ網である場合には、ＩＰ交換機２は、呼制御パケット及び音声パケットの変換処理を実行しなくてもよい。

ＩＰ交換機２は、例えば、図１に示すように、各種処理をそれぞれ実行する複数のブレードが装着されるブレードサーバとして実現される。複数のブレードには、接続されるローカル網１とのインタフェース処理を実行するブレード、ローカル網１のプロトコルをＩＰに変換する処理を実行するブレード、呼制御を行うブレード、ＩＰ網５とのインタフェース処理を実行するブレード等を含む。なお、本実施形態では、ＩＰ交換機２は、各ローカル網１とＩＰ網５との間の中継機として動作する装置であればよく、ＩＰ交換機２自体の具体的処理を限定するものではない。

各ＩＰ交換機２から送出された音声通信パケットは、ルータ３を経由してＩＰ網５に伝送され、ＩＰ網５からルータ３を経由して他のＩＰ交換機３へ送られる。図１では、ＩＰ網５のエッジに設置されたルータはエッジルータ３（Ｔ２）及び３（Ｒ２）と表記され、その他のルータは中継ルータ３（Ｔ１）及び３（Ｒ１）と表記されている。

上述のように、本実施例では、ローカル網１及びＩＰ交換機２を発信者側と着信者側とに区別して示すが、これは説明の便宜のためである。

［装置構成］
本実施例の障害検出システムは、このような音声通信システム内の障害を検出し、かつ、その障害箇所を特定する。図２は、本実施例の障害検出システムのハードウェア構成例を示す図である。本実施例の障害検出システムは、プローブ装置１０、コレクタ装置２０、マネージャ装置３０等を含む。

プローブ装置１０は、音声通信システム内に流れるパケットを所定箇所でキャプチャすることにより当該パケットの情報を取り出す。プローブ装置１０は、発信者端末と着信者端末との間の各呼について、ＩＰ網５を介して発信者端末側（発側とも表記する）と着信
者端末側（着側とも表記する）との少なくとも２つの箇所からパケットを取り出す。本実施例では、ＩＰ網５が監視対象網とされ、ＩＰ交換機２が監視対象装置とされる。ここで、呼とは、発信者端末及び着信者端末間における発呼から切断までの一連の通信を示す。

プローブ装置１０は、図２に示すようなネットワークタップ等と呼ばれる信号分岐装置（以降、単にタップと表記する）７を用いることによりパケット情報を取り出す。なお、本実施形態は、パケットを対象ネットワークから取り出す手法を限定するものではなく、ルータのミラーポートから取り出すようにしてもよい。本実施形態は、ネットワークに影響を与えることなくパケット情報を取り出し得る手法であればいずれの手法が利用されてもよい。

本実施例では、監視対象装置としてのＩＰ交換機２（Ｔ）及び２（Ｒ）をＩＰ網５へ接続するための各通信線に各タップ７がそれぞれ設置され、プローブ装置１０は、各タップ７により取り出されたパケットをそれぞれ受信する。図２における複数の監視対象装置２（Ｔ）は、例えば、ＩＰ交換機２（Ｔ）におけるＩＰ網５と接続するための通信線を収容する複数のブレードを示す。なお、本実施形態は、このタップ７の数を制限するものではなく、監視の仕様に応じて、パケット情報を取り出す所定箇所は任意の数及び位置で設定されればよい。本実施例では、送信者端末が接続されるローカル網１（Ｔ）に接続されるＩＰ交換機２（Ｔ）から送出されるパケットを取り出すプローブ装置を１０（Ｔ）と表記する。同様に、受信者端末が接続されるローカル網１（Ｒ）に接続されるＩＰ交換機２（Ｒ）から送出されるパケットを取り出すプローブ装置を１０（Ｒ）と表記する。

プローブ装置１０は、パケット情報を取り出す通信線の数等に応じて所定台数、設けられる。例えば、１つのＩＰ交換機２に対して１つのプローブ装置１０が利用される。本実施形態は、このプローブ装置１０の数を限定するものではない。プローブ装置１０は、各々取り出されたパケットから音声通信パケットを抽出し、この音声通信パケットをコレクタ装置２０へ送る。

コレクタ装置２０は、プローブ装置１０から音声通信パケットを受信し、この音声通信パケットを解析することにより音声通信情報を呼情報を取得し、取得された呼情報を管理する。コレクタ装置２０は、管理される呼情報に基づいて音声通信システム内に発生したと想定される障害を検出し、かつ、この障害の箇所を特定する。

マネージャ装置３０は、コレクタ装置２０で検出及び特定された障害情報を音声通信システムの管理者や保守者等へ提供するためのユーザインタフェースを実現する。

なお、本実施例では、障害検出システムが、図２に示すように、プローブ装置１０、コレクタ装置２０、マネージャ装置３０を含むが、本実施形態はこのようなハードウェア構成に限定するものではなく１台のハードウェアとして実現されてもよいし、２台以上の複数のハードウェアとして実現されてもよい。

〔詳細構成〕
以下、プローブ装置１０、コレクタ装置２０及びマネージャ装置３０における各処理部の構成例について説明する。図３は、プローブ装置１０、コレクタ装置２０及びマネージャ装置３０における各処理部の構成例を示す図である。図３に示す各処理部は、ソフトウェアの構成要素又はハードウェアの構成要素、若しくはこれらの組み合わせとしてそれぞれ実現される（［その他］の項参照）。

プローブ装置１０は、受信部１１、抽出部１５等を含む。

受信部１１は、各タップ７に接続される通信線を収容するための各通信ポートを有する。受信部１１は、各通信ポートに接続される各通信線からＩＰパケットをそれぞれ受信する。受信部１１は、受信されたＩＰパケットを抽出部１５へ送る。

抽出部１５は、受信部１１から送られたＩＰパケットのうち音声通信パケットを抽出する。例えば、抽出部１５は、呼制御パケットとしてのＳＩＰパケット及び音声パケットとしてのＲＴＰパケットを抽出する。本実施形態は音声通信プロトコルをＳＩＰ及びＲＴＰに限定するものではないが、以下では、呼制御プロトコルとしてＳＩＰを例に挙げ、音声伝送プロトコルとしてＲＴＰを例に挙げ説明する。

抽出部１５は、ポート番号を用いることによりＳＩＰパケットを抽出する。抽出部１５は、更に、抽出されたＳＩＰパケットの中から呼情報を抽出するために必要なＳＩＰパケットを抽出する。具体的には、例えば、呼開始を示すＩＮＶＩＴＥメッセージ、そのＩＮＶＩＴＥメッセージに対する受信者側からの応答である２００ＯＫメッセージ、呼終了を示すＢＹＥメッセージを示すＳＩＰパケットが抽出される。抽出部１５は、抽出されたこれらのＳＩＰパケットをコレクタ装置２０へ送る。

このとき、抽出部１５は、ＩＮＶＩＴＥメッセージ及び２００ＯＫメッセージから発信者端末のＩＰアドレス及びポート番号、受信者端末のＩＰアドレス及びポート番号を取得し、保持する。抽出部１５は、保持された発信者端末及び受信者端末のＩＰアドレス及びポート番号の各セットを送信元ＩＰアドレス、送信元ポート番号、送信先ＩＰアドレス及び送信先ポート番号に設定されたパケットを抽出する。この抽出により、ＲＴＰパケットが抽出される。抽出部１５は、抽出されたＲＴＰパケットをコレクタ装置２０へ送る。

このように、プローブ装置１０は、複数の呼に関する呼制御パケット及び音声パケットを処理する。抽出部１５からコレクタ装置２０へ送られるＳＩＰパケット及びＲＴＰパケットは、複数の呼を示す場合がある。

コレクタ装置２０は、解析部２１、呼管理テーブル２３、障害特定部２５等を含む。

解析部２１は、プローブ装置１０（Ｔ）及び１０（Ｒ）から送られるＳＩＰパケット及びＲＴＰパケットを受信し、受信されたＳＩＰパケット及びＲＴＰパケットを解析することにより呼情報を取得する。解析部２１は、取得された呼情報を呼管理テーブル２３に格納する。

図４は、呼管理テーブルの例を示す図である。呼管理テーブル２３は、各呼についてそれぞれ呼情報を格納する。呼管理テーブルは、ＣＡＬＬ−ＩＤフィールド、発番号フィールド、発信者ＩＰフィールド、発信者ポート番号フィールド、着番号フィールド、着信者ＩＰフィールド、着信者ポート番号フィールド、第１方向発側音声品質情報フィールド、第１方向着側音声品質情報フィールド、第２方向発側音声品質情報フィールド、第２方向着側音声品質情報フィールドを持つ。

ＣＡＬＬ−ＩＤフィールドには、呼の識別番号が格納される。呼の識別番号としては、例えば、ＳＩＰパケットのＩＮＶＩＴＥメッセージ及び２００ＯＫメッセージのＣＡＬＬ−ＩＤヘッダの値が利用される。発番号フィールドには、発信者の識別番号が格納される。発信者の識別番号としては、例えば、ＳＩＰパケットのＩＮＶＩＴＥメッセージのＦＲＯＭヘッダに設定されるデータが設定される。発信者ＩＰフィールドには、発信者のＩＰアドレスが格納される。発信者のＩＰアドレスは、例えば、ＳＩＰパケットのＩＮＶＩＴＥメッセージ及び２００ＯＫメッセージのボディ部から取得される。発信者ポート番号フィールドには、ＲＴＰパケットで利用される発信者のポート番号が格納される。発信者の
ポート番号は、例えば、ＳＩＰパケットのＩＮＶＩＴＥメッセージ及び２００ＯＫメッセージのボディ部から取得される。

着番号フィールドには、着信者の識別番号が格納される。着信者の識別番号としては、例えば、ＳＩＰパケットのＩＮＶＩＴＥメッセージのＴＯヘッダに設定されるデータが設定される。着信者ＩＰフィールドには、着信者のＩＰアドレスが格納される。着信者のＩＰアドレスは、例えば、ＳＩＰパケットのＩＮＶＩＴＥメッセージ及び２００ＯＫメッセージのボディ部から取得される。着信者ポート番号フィールドには、ＲＴＰパケットで利用される着信者のポート番号が格納される。着信者のポート番号は、例えば、ＳＩＰパケットのＩＮＶＩＴＥメッセージ及び２００ＯＫメッセージのボディ部から取得される。

第１方向発側音声品質情報フィールドには、発信者端末が接続されるローカル網１（Ｔ）側のプローブ装置１０（Ｔ）により取り出される、発信者から着信者に対して発せされた音声データの品質を示す情報が格納される。第１方向着側音声品質情報フィールドには、着信者端末が接続されるローカル網１（Ｒ）側のプローブ装置１０（Ｒ）により取り出される、発信者から着信者に対して発せられた音声データの品質を示す情報が格納される。第２方向発側音声品質情報フィールドには、発信者端末が接続されるローカル網１（Ｔ）側のプローブ装置１０（Ｔ）により取り出される、着信者から発信者に対して発せられた音声データの品質を示す情報が格納される。第２方向着側音声品質情報フィールドには、着信者端末が接続されるローカル網１（Ｒ）側のプローブ装置１０（Ｒ）により取り出される、着信者から発信者に対して発せられた音声データの品質を示す情報が格納される。

このように、着信者端末が接続されるローカル網１（Ｒ）側のプローブ装置１０（Ｒ）により取り出されたデータを着側のデータと表記する場合がある。同様に、発信者端末が接続されるローカル網１（Ｔ）側のプローブ装置１０（Ｔ）により取り出されたデータを発側のデータと表記することもある。更に、発信者端末から着信者端末への方向を第１方向と表記し、着信者端末から発信者端末への方向を第２方向と表記することもある。

音声通信では、ＳＩＰパケットを用いたシグナリングにより発信者端末と着信者端末との間で呼が確立された後、ＲＴＰパケットにより音声データが伝送される。そこで、解析部２１は、同じＣＡＬＬ−ＩＤが設定されたＩＮＶＩＴＥメッセージ及び２００ＯＫメッセージをそれぞれ受けると、新たな呼が発生したとみなし、呼管理テーブル２３に新たなレコードを追加する。ＲＴＰパケットを受けると、解析部２１は、そのＲＴＰパケットに設定されている送信元及び送信先のＩＰアドレス及びポート番号により呼管理テーブル２３に格納されるそのＲＴＰパケットに対応する呼を示すレコードを特定する。

解析部２１は、そのＲＴＰパケットから周知の所定手法によりそのＲＴＰパケットに含まれる音声データの音声品質を解析する。周知の所定手法には、例えば、ＩＴＵ−Ｔ Ｇ.１０７及びＧ．１１３で規定される手法が利用される。本実施形態はこの音声品質解析
手法を限定するものではないため、周知の手法が利用されればよい。解析部２１は、音声品質解析結果を、第１方向発側音声品質情報フィールド、第１方向着側音声品質情報フィールド、第２方向発側音声品質情報フィールド、又は、第２方向着側音声品質情報フィールドに格納する。解析部２１は、そのＲＴＰパケットの転送元であるプローブ装置１０により、そのＲＴＰパケットの取り出された箇所が発側か、着側かを判断する。また、解析部２１は、そのＲＴＰパケットに設定されている送信元ＩＰアドレス及び送信先ＩＰアドレスに基づいて、そのＲＴＰパケットが第１方向の音声データを含むか、第２方向の音声データを含むかを判断する。

障害特定部２５は、任意のタイミングで、呼管理テーブル２３を参照することにより、
音声品質が劣化していること（障害）を検知し、その障害が発生している箇所を特定する。具体的には、障害特定部２５は、呼管理テーブル２３に格納される第１方向発側音声品質情報、第１方向着側音声品質情報、第２方向発側音声品質情報及び第２方向着側音声品質情報に基づいて、障害の検知及び障害箇所の特定を行う。障害特定部２５のこの障害箇所特定手法については動作例の項において説明する。障害特定部２５は、特定された障害箇所の情報をマネージャ装置３０へ送る。

マネージャ装置３０は、障害通知部３１等を含む。障害通知部３１は、１つ以上のコレクタ装置２０から送られる障害箇所情報を取得し、この取得された障害箇所情報を本音声通信システムの保守者、管理者等のユーザ（以降、保守ユーザと表記する）に提供する。例えば、マネージャ装置３０がＷＥＢサーバ機能を有している場合には、障害通知部３１は、この障害箇所を示すＷＥＢページを生成するようにしてもよい。この場合には、保守ユーザは、ＷＥＢブラウザを用いてマネージャ装置３０にアクセスすることによりその障害箇所を示す画面を参照することができる。

〔動作例〕
以下、本実施例における障害検出システムの動作例について説明する。

図５は、本実施例における障害検出システムの動作シーケンスを示す図である。本実施例の障害検出システムでは、図２に示すように、プローブ装置１０（Ｔ）が監視対象装置としてのＩＰ交換機２（Ｔ）のＩＰ網５側への通信線にタップ７を介して接続されている。また、プローブ装置１０（Ｒ）が監視対象装置としてのＩＰ交換機２（Ｒ）のＩＰ網５側への通信線にタップ７を介して接続されている。これにより、プローブ装置１０（Ｔ）及び１０（Ｒ）は、ＩＰ交換機２（Ｔ）に接続されるローカル網１（Ｔ）内の発信者端末とＩＰ交換機２（Ｒ）に接続されるローカル網１（Ｒ）内の着信者端末との間で伝送されるパケットを逐次受ける。ＩＰ交換機２（Ｔ）及びＩＰ交換機２（Ｒ）の間で送受されるパケットは、正常であれば、プローブ装置１０（Ｔ）及び１０（Ｒ）においてそれぞれ取り出される。以降、各プローブ装置１０（Ｔ）及び１０（Ｒ）をプローブ装置１０と総称して説明する。

プローブ装置１０の受信部１１は、タップ７により取り出されたＩＰパケットを受信する。受信されたＩＰパケットは抽出部１５に逐次送られる。

抽出部１５は、受信部１１から送られたＩＰパケットのうち音声通信パケットとしてＳＩＰパケット及びＲＴＰパケットを抽出する。音声通信では、ＳＩＰパケットを用いたシグナリングにより発信者端末と着信者端末との間で呼が確立された後、ＲＴＰパケットにより音声データが伝送される。よって、図５に示すように、１つの呼において、まず、ＳＩＰパケットが抽出される（Ｓ５０）。抽出部１５は、ＩＰパケットのＴＣＰヘッダ又はＵＤＰヘッダに設定されているポート番号が所定の番号である場合に、そのＩＰパケットをＳＩＰパケットと判定する。抽出部１５は、抽出されたＳＩＰパケットをコレクタ装置２０へ送る。

プローブ装置１０に接続されるコレクタ装置２０では、解析部２１がＳＩＰパケットを受信する。解析部２１は、ＳＩＰパケットを解析することにより、このＳＩＰパケットから呼情報を取得する（Ｓ５１）。解析部２１は、具体的には、ＳＩＰパケットのリクエスト行又はステータス行に設定されるテキストデータに基づいて、そのＳＩＰパケットがＩＮＶＩＴＥメッセージ、２００ＯＫメッセージ、ＢＹＥメッセージのいずれを示すか判定する。解析部２１は、同じＣＡＬＬ−ＩＤが設定されたＩＮＶＩＴＥメッセージ及び２００ＯＫメッセージをそれぞれ受けると、新たな呼が発生したと判定する。解析部２１は、新たな呼が発生したと判定すると、ＩＮＶＩＴＥメッセージ及び２００ＯＫメッセージか
らＣＡＬＬ−ＩＤ、発信者及び着信者の識別番号、発信者及び着信者のＩＰアドレス及びポート番号を抽出する。一方で、解析部２１は、ＢＹＥメッセージを受けた場合には、呼が解放されたと判定する。解析部２１は、呼が解放されたと判定すると、ＢＹＥメッセージからＣＡＬＬ−ＩＤを抽出する。

解析部２１は、このように抽出された呼情報に基づいて、呼管理テーブル２３を更新する（Ｓ５２）。具体的には、解析部２１は、新たな呼が発生したと判定した場合に抽出された情報を、ＣＡＬＬ−ＩＤフィールド、発番号フィールド、発信者ＩＰフィールド、発信者ポート番号フィールド、着番号フィールド、着信者ＩＰフィールド、着信者ポート番号フィールドに設定した新たなレコードを呼管理テーブル２３に格納する（Ｓ５２）。一方、解析部２１は、呼が解放されたと判定した場合に抽出されたＣＡＬＬ−ＩＤと同一の値がＣＡＬＬ−ＩＤフィールドに格納されているレコードを呼管理テーブル２３から削除する。

音声通信のメッセージシーケンス上、次に、ＲＴＰパケットが受信部１１で受信され、抽出部１５へ送られる。抽出部１５は、ＳＩＰパケット抽出時に同じＣＡＬＬ−ＩＤが設定されたＩＮＶＩＴＥメッセージ及び２００ＯＫメッセージを受信した際に、それらメッセージから発信者端末のＩＰアドレス及びポート番号、受信者端末のＩＰアドレス及びポート番号を取得し、保持する。抽出部１５は、保持された発信者端末及び受信者端末のＩＰアドレス及びポート番号の各セットを送信元ＩＰアドレス、送信元ポート番号、送信先ＩＰアドレス及び送信先ポート番号に設定されたパケットを抽出する。この抽出により、ＲＴＰパケットが抽出される（Ｓ５３）。抽出部１５は、抽出されたＲＴＰパケットをコレクタ装置２０へ送る。

プローブ装置１０に接続されるコレクタ装置２０では、解析部２１がＲＴＰパケットを受信する。解析部２１は、この受信されたＲＴＰパケットに関する情報を用いることにより、そのＲＴＰパケットで伝送される音声の品質を解析する（Ｓ５４）。

解析部２１は、そのＲＴＰパケットのＵＤＰヘッダに格納される送信先及び送信元のＩＰアドレス及びポート番号が、発信者端末及び着信者端末のＩＰアドレス及びポート番号に設定されているレコードを呼管理テーブル２３から抽出する（Ｓ５５）。具体的には、ＵＤＰヘッダに格納される送信先のセット（送信先ＩＰアドレス及び送信先ポート番号）が呼管理テーブル２３の発信者のセット（発信者ＩＰアドレス及び発信者ポート番号）又は着信者のセット（着信者ＩＰアドレス及び着信者ポート番号）に設定されているレコードが特定される。更に、この特定されたレコードのうち、ＵＤＰヘッダに格納される送信元のセット（送信元ＩＰアドレス及び送信元ポート番号）が呼管理テーブル２３の発信者のセット又は着信者のセットに設定されているレコードが特定される。

このように、ＩＰアドレス及びポート番号の各セットに基づいて、解析部２１は、呼管理テーブル２３におけるＳＩＰパケットにより設定された各呼の情報とＲＴＰパケットとを関連付ける。これは、ＲＴＰパケットにはＣＡＬＬ−ＩＤが設定されていないからである。

解析部２１は、上述のように特定されたレコードの第１方向発側音声品質情報フィールド、第１方向着側音声品質情報フィールド、第２方向発側音声品質情報フィールド、第２方向着側音声品質情報フィールドに上述のように解析された音声品質情報を設定する（Ｓ５６）。ここで、解析部２１は、解析された音声品質情報が第１方向及び第２方向のいずれのものであるかについては、対象のＲＴＰパケットの伝送方向により決める。具体的には、ＲＴＰパケットの送信先のセットが特定されたレコードの着信者のセットと一致し、ＲＴＰパケットの送信元のセットが特定されたレコードの発信者のセットと一致する場合
には、そのＲＴＰパケットは第１方向に伝送されたものとして決められる。逆に、ＲＴＰパケットの送信先のセットが特定されたレコードの発信者のセットと一致し、ＲＴＰパケットの送信元のセットが特定されたレコードの着信者のセットと一致する場合には、そのＲＴＰパケットは第２方向に伝送されたものとして決められる。また、解析部２１は、解析された音声品質情報が発側及び着側のいずれかのものであるかについては、そのＲＴＰパケットの転送元のプローブ装置１０により判定される。例えば、プローブ装置１０（Ｔ）で受信されたＲＴＰパケットは発側を示し、プローブ装置１０（Ｒ）で受信されたＲＴＰパケットは着側を示す。

コレクタ装置２０の障害特定部２５は、任意のタイミングで呼管理テーブル２３の各レコードを分析する（Ｓ５７）。障害特定部２５は、この分析により、後述するように、音声品質の劣化を生じさせている障害の検出とその障害箇所の特定を行う（Ｓ５８）。障害特定部２５は、特定された障害箇所の情報をマネージャ装置３０へ送る。

マネージャ装置３０の障害通知部３１は、コレクタ装置２０から送られる障害箇所情報を取得し、この取得された障害箇所情報を本音声通信システムの保守ユーザに通知する（Ｓ５９）。

以下、障害特定部２５による障害箇所特定処理について図６及び７を用いて説明する。

図６は、障害箇所特定処理を示すフローチャートである。障害特定部２５は、呼管理テーブル２３の各レコードを順次読み出し（Ｓ６０）、読み出されたレコードについてそれぞれ以下のような処理を行う。なお、呼管理テーブル２３の各レコードは、上述したように各呼に対応する。

障害特定部２５は、呼管理テーブル２３の各レコードについての、第１方向の発側、第１方向の着側、第２方向の発側、第２方向の着側の４つの音声品質情報をそれぞれ解析することにより、各音声品質情報が正常を示すか異常を示すかを判断する（Ｓ６１）。例えば、障害特定部２５は、所定の閾値と各音声品質値とを比較することによりその判断を行う。

障害特定部２５は、４つの音声品質情報について正常か異常かを判定すると、その判定結果に応じて、その呼(レコード)が示す伝送状態を図７に示す６つのケースのいずれか１つに特定する（Ｓ６２、Ｓ６３、Ｓ６４、Ｓ６５、Ｓ６６、Ｓ６７）。図７は、音声品質情報と特定される障害箇所との関係を示す表である。

具体的には、障害特定部２５は、全ての音声品質情報が正常である場合には、その呼の伝送状態はケース１であると判断する（Ｓ６２；ＹＥＳ）。障害特定部２５は、ケース１の場合には、障害なしと判定する（Ｓ７１）。

障害特定部２５は、第１方向発側及び第１方向着側の音声品質情報がそれぞれ異常であり、その他の音声品質情報が正常である場合には、その呼の伝送状態はケース２であると判断する（Ｓ６３；ＹＥＳ）。障害特定部２５は、ケース２の場合には、発側の監視対象装置２（Ｔ）即ちＩＰ交換機２（Ｔ）を障害箇所として特定する（Ｓ７２）。これは、発信者端末から送信された音声データが、ＲＴＰパケットとしてＩＰ交換機２（Ｔ）からＩＰ網５方向へ送出され、プローブ装置１０（Ｔ）により取り出された時点で既に異常（品質劣化）状態となっているからである。その音声データは、品質が劣化した状態でＩＰ網５を経由してＩＰ交換機２（Ｒ）へ伝送されるため、第１方向着側即ちプローブ装置１０（Ｒ）で取り出された時点でも異常状態と判定される。一方で、着信者端末から発信者端末へ送信された音声データは、他の箇所に障害がないため、ＩＰ交換機２（Ｔ）で処理さ
れるまで異常状態とならない。これにより、ケース２の場合には、障害箇所は、発側の監視対象装置２（Ｔ）即ちＩＰ交換機２（Ｔ）に特定することができる。

障害特定部２５は、第２方向発側及び第２方向着側の音声品質情報がそれぞれ異常であり、その他の音声品質情報が正常である場合には、その呼の伝送状態はケース３であると判断する（Ｓ６４；ＹＥＳ）。障害特定部２５は、ケース３の場合には、着側の監視対象装置２（Ｒ）即ちＩＰ交換機２（Ｒ）を障害箇所として特定する（Ｓ７３）。これは、着信者端末から送信された音声データが、ＲＴＰパケットとしてＩＰ交換機２（Ｒ）からＩＰ網５方向へ送出され、プローブ装置１０（Ｒ）により取り出された時点で既に異常状態となっているからである。この場合、その音声データは、第１方向発側即ちプローブ装置１０（Ｔ）で取り出された時点でも異常状態と判定される。一方で、発信者端末から着信者端末へ送信された音声データは、他の箇所に障害がないため、ＩＰ交換機２（Ｒ）で処理されるまで異常状態とならない。これにより、ケース３の場合には、障害箇所は、着側の監視対象装置２（Ｒ）即ちＩＰ交換機２（Ｒ）に特定することができる。

障害特定部２５は、第１方向着側の音声品質情報のみが異常であり、その他の音声品質情報が正常である場合には、その呼の伝送状態はケース４であると判断する（Ｓ６５；ＹＥＳ）。障害特定部２５は、ケース４の場合には、監視対象網即ちＩＰ網５の第１方向を障害箇所として特定する（Ｓ７４）。これは、発信者端末から送信された音声データが発側のプローブ装置１０（Ｔ）により取り出された時点では正常状態であり、着側の監視対象装置２（Ｒ）の手前で取り出された時点で異常状態となっているからである。一方で、着信者端末から発信者端末へ送信された音声データは、その方向ではＩＰ網５には障害がないため、いずれの箇所でも正常状態となっている。これにより、ケース４の場合には、障害箇所は、ＩＰ網５の第１方向即ち発信者端末から着信者端末方向に特定することができる。

障害特定部２５は、第２方向発側の音声品質情報のみが異常であり、その他の音声品質情報が正常である場合には、その呼の伝送状態はケース５であると判断する（Ｓ６６；ＹＥＳ）。障害特定部２５は、ケース５の場合には、ＩＰ網５の第２方向を障害箇所として特定する（Ｓ７５）。これは、着信者端末から送信された音声データが着側のプローブ装置１０（Ｒ）からＩＰ網５側に送出された時点で取り出された場合には正常状態であり、発側の監視対象装置２（Ｔ）の手前で取り出された時点で異常状態となっているからである。一方で、発信者端末から着信者端末へ送信された音声データは、その方向ではＩＰ網５には障害がないため、いずれの箇所でも正常状態となっている。これにより、ケース５の場合には、障害箇所は、ＩＰ網５の第２方向即ち着信者端末から発信者端末方向に特定することができる。

障害特定部２５は、第１方向着側及び第２方向発側の音声品質情報がそれぞれ異常であり、その他の音声品質情報が正常である場合には、その呼の伝送状態はケース６であると判断する（Ｓ６７；ＹＥＳ）。障害特定部２５は、ケース６の場合には、ＩＰ網５の両方向を障害箇所として特定する（Ｓ７６）。ケース６は、ケース４とケース５とを組み合わせたケースであるため、このように特定することができる。

〈実施例の作用及び効果〉
上述したように、本実施例では、監視対象のＩＰ網５と監視対象の各ＩＰ交換機２との間の各所定箇所からタップ７によりそれぞれパケットが取り出される。各プローブ装置１０では、このように取り出されたパケットから、呼制御パケットや音声パケットのような音声通信パケットが抽出される。各プローブ装置１０で抽出された音声通信パケットはそれぞれコレクタ装置２０に送られ、コレクタ装置２０により解析される。

コレクタ装置２０では、ＳＩＰパケットのような呼制御パケットから各呼についての呼情報が取得され、呼管理テーブル２３に格納される。また、ＲＴＰパケットのような音声パケットからその音声パケットに含まれる音声データの品質が判定される。音声パケットにより判定された音声品質情報は、その音声パケットの送信元情報（ＩＰアドレス及びポート番号）及び送信先情報（ＩＰアドレス及びポート番号）により、呼制御パケットから取り出された各呼についての呼情報に関連付けられ、呼管理テーブル２３に格納される。

音声品質判定では、同一音声パケットにつき、発側で取り出された音声パケットに含まれる音声データの品質（発側音声品質）及び着側で取り出された音声パケットに含まれる音声データの品質（着側音声品質）がそれぞれ判定される。加えて、各呼につき、発信者から着信者への方向（第１方向）の音声パケットに含まれる音声データの品質（第１方向音声品質）及び着信者から発信者への方向（第２方向）の音声パケットに含まれる音声データの品質（第２方向音声品質）がそれぞれ判定される。

コレクタ装置２０の障害特定部２５では、各呼の各方向について、発側及び着側の各音声品質情報の状態（正常か異常か）がそれぞれ判定され、音声品質の劣化が生じていることが検出され、かつ、その発生箇所が特定される。障害箇所は、発側の監視対象装置（ＩＰ交換機２（Ｔ））、着側の監視対象装置（ＩＰ交換機２（Ｒ））、監視対象網（ＩＰ網５）のいずれか１つに特定される。更に、監視対象網については、その音声品質の劣化が生じている通信方向が特定される。

結果、マネージャ装置３０により、音声品質の劣化が生じていること（障害発生）、音声品質の劣化を生じさせている箇所（障害箇所）が保守ユーザに通知される。

従って、本実施例の障害検出システムによれば、音声通信システム内の障害発生を検出することができることに加え、その障害箇所を適切に特定することができる。これにより、保守ユーザは、障害対処を迅速に実施することができる。また、本実施例の障害検出システムによる障害箇所特定は、自動で実行されるため、膨大な通話数を対象としても実行することが可能である。更に、この障害箇所特定処理は、タップ７等により取り出されたパケットを用いて行われるため、音声通信システム内を流れるトラフィックに何ら影響を与えず、かつ、音声通信システム内のネットワーク装置に負荷を与えるものでもない。更に、監視対象となるネットワーク装置自身では検知できない障害についても品質劣化の検知が可能である。

［変形例］
上述の実施例では、コレクタ装置２０が呼管理テーブル２３を有し、各呼についてその呼管理テーブル２３の１つのレコードで管理していたが、ＲＴＰパケット及びＳＩＰパケットの転送元であるプローブ装置１０毎にレコードを生成するようにしてもよい。

図８は、呼管理テーブルの変形例を示す図である。この変形例の呼管理テーブル２３には、呼情報と共に、ＲＴＰパケット及びＳＩＰパケットの転送元であるプローブ装置１０のＩＰアドレスが格納される。また、プローブ装置１０毎に、第１方向及び第２方向の各音声品質情報が格納される。この場合、障害特定部２５は、障害特定処理をする際に、呼管理テーブル２３のＣＡＬＬ−ＩＤが等しいレコードを同一呼のレコードとして抽出する。障害特定部２５は、転送元のプローブ装置１０のアドレスによりそのレコードの音声品質情報が発側の情報か着側の情報かを決めるようにすればよい。更に、各プローブ装置１０のＩＰアドレスと発側か着側かを示す情報とが対応付けられたテーブルがコレクタ装置２０で保持されるようにすればよい。

また、上述の実施例では、コレクタ装置２０の障害特定部２５が、呼管理テーブル２３
の音声品質情報が正常か異常かを判断していたが、解析部２１が音声品質情報として正常か異常かを呼管理テーブル２３に格納するようにしてもよい。

また、上述の実施例では、プローブ装置１０からコレクタ装置２０へは音声通信パケットが渡されていたが、プローブ装置１０で音声品質情報の解析（評価）を行い、この解析結果がプローブ装置１０からコレクタ装置２０へ送られるようにしてもよい。このようにすれば、プローブ装置１０とコレクタ装置２０との間の受け渡しデータ量を削減することができる。

また、上述の実施例では、障害検出システムが、図２に示すように、プローブ装置１０、コレクタ装置２０、マネージャ装置３０を有していたが、その障害検出システムは１台の障害検出装置として実現されるようにしてもよい。図９は、変形例として障害検出装置の詳細構成を示す図である。この場合には、障害検出装置の受信部１１が各タップ７により取り出されたパケットをそれぞれ受信する。

また、上述の実施例では、監視対象が、発側監視対象装置としてのＩＰ交換機２（Ｔ）、着側監視対象装置としてのＩＰ交換機２（Ｒ）、監視対象網としてのＩＰ網５であったが、更に監視対象を増やしてもよい。その場合には、監視対象を介して両側の通信線からパケットを取り出すようにし、その各パケットの呼が示す音声品質情報を判定するようにすればよい。

また、コレクタ装置２０の障害特定部２５は、呼管理テーブル２３の各レコードに優先度を付し、優先度の高いレコードを優先的に障害特定処理の対象とするようにしてもよい。言い換えれば、各呼について障害特定処理優先度がそれぞれ付されるようにしてもよい。

図１０は、変形例の障害検出システムの詳細構成を示す図である。図１１は、優先度テーブル２７の例を示す図である。変形例の障害検出システムでは、コレクタ装置２０が更に優先度テーブル２７を有する。優先度テーブル２７には、呼管理テーブル２３の着番号と優先度との対応関係が格納される。図１１に示すように、警察機関に提供される緊急通報用電話番号のような特定番号には高い優先度が付される。障害特定部２５は、各呼を示すレコードをその着番号に対応する優先度の順に並び替え、その優先度の高いレコードから優先的に障害特定処理を実行する。このようにすれば、特定番号向けの通話についての障害箇所を優先的に判断することができる。

［その他］
〈ハードウェアの構成要素（Component）及びソフトウェアの構成要素（Component）について〉
ハードウェアの構成要素とは、ハードウェア回路であり、例えば、フィールド・プログラマブル・ゲートアレイ（ＦＰＧＡ）、特定用途向け集積回路（ＡＳＩＣ）、ゲートアレイ、論理ゲートの組み合わせ、信号処理回路、アナログ回路等がある。

ソフトウェアの構成要素とは、ソフトウェアとして上記処理を実現する部品（断片）であり、そのソフトウェアを実現する言語、開発環境等を限定する概念ではない。ソフトウェアの構成要素としては、例えば、タスク、プロセス、スレッド、ドライバ、ファームウェア、データベース、テーブル、関数、プロシジャ、サブルーチン、プログラムコードの所定の部分、データ構造、配列、変数、パラメータ等がある。これらソフトウェアの構成要素は、コンピュータ内において、１又は複数のメモリ上で実現されるか、或いは、１又は複数のメモリ上のデータが１又は複数のプロセッサ（例えば、ＣＰＵ（Central Processing Unit）、ＤＳＰ（Digital Signal Processor）等）で実行されることにより実現さ
れる。

なお、上述の各実施形態は、上記各処理部の実現手法を限定するものではない。上記各処理部は、上記ハードウェアの構成要素又はソフトウェアの構成要素若しくはこれらの組み合わせとして、本技術分野の通常の技術者において実現可能な手法により構成されていればよい。

１ ローカル網
２、２（Ｔ）、２（Ｒ） ＩＰ交換機
５ ＩＰ網
７ タップ
１０ プローブ装置
１１ 受信部
１５ 抽出部
２０ コレクタ装置
２１ 解析部
２３ 呼管理テーブル
２５ 障害特定部
２７ 優先度テーブル
３０ マネージャ装置
３１ 障害通知部

Claims (7)

1. 第１ユーザ端末と第２ユーザ端末との間の音声通信を実現する通信網で利用される障害検出装置において、
   前記通信網を流れる呼制御パケット及び音声パケットを前記通信網上の複数箇所からそれぞれ取り出す取得手段と、
   前記複数個所の各々から取り出された呼制御パケット及び音声パケットに基づいて、前記複数箇所の各々における第１ユーザ端末から第２ユーザ端末方向の音声品質情報及び第２ユーザ端末から第１ユーザ端末方向の音声品質情報を含む呼情報を、各呼についてそれぞれ管理する管理手段と、
   前記管理手段により管理される呼情報に応じて音声通信の音声品質を劣化させる障害箇所を特定する特定手段と
   を備えることを特徴とする障害検出装置。
2. 前記管理手段は、前記呼制御パケットに含まれる発信者側情報及び着信者側情報を各呼についての呼情報として格納部に格納し、該格納部に格納される発信者側情報及び着信者側情報と前記音声パケットに設定されている送信先情報及び送信元情報とに基づいて該音声パケットに対応する呼を特定し、該音声パケットに応じて判定される音声品質を該特定された呼についての呼情報として該格納部に格納する、
   ことを特徴とする請求項１に記載の障害検出装置。
3. 前記特定手段は、同一方向の音声品質の劣化判定が前記複数個所のうちの第１箇所と第２箇所のそれぞれにおいて異なる場合に、該第１箇所と該第２箇所との間を障害箇所として特定し、同一方向の音声品質が該第１箇所及び該第２箇所の両方で劣化していると判定した場合には、該第１箇所から前記第１ユーザ端末側、又は、該第２箇所から前記第２ユーザ端末側を障害箇所として特定する、
   ことを特徴とする請求項１又は２に記載の障害検出装置。
4. 前記管理手段は、前記呼制御パケットに含まれる呼識別情報を更に各呼についての呼情報としてそれぞれ前記格納部に格納し、前記複数箇所のうちの第１箇所から取得された呼制御パケット及び音声パケットに基づいて管理される呼情報と該第１箇所とは異なる第２箇所から取得された呼制御パケット及び音声パケットに基づいて管理される呼情報とを該呼識別情報を用いて関連付ける、
   ことを特徴とする請求項２又は３に記載の障害検出装置。
5. 前記管理手段は、前記呼情報に、前記呼制御パケットに含まれる着信電話番号を含め、
   前記特定手段は、各電話番号についてそれぞれ優先度が格納される優先度格納部から、前記管理手段により管理される各呼情報に含まれる着信電話番号に対応する優先度を取得し、該取得された優先度の高い呼を優先的に障害箇所特定処理の対象とする、
   ことを特徴とする請求項１から４のいずれか１項に記載の障害検出装置。
6. 第１ユーザ端末と第２ユーザ端末との間の音声通信を実現する通信網において実行される障害検出方法において、
   前記通信網を流れる呼制御パケット及び音声パケットを前記通信網上の複数箇所からそれぞれ取り出し、
   前記複数個所の各々から取り出された呼制御パケット及び音声パケットに基づいて、前記複数箇所の各々における第１ユーザ端末から第２ユーザ端末方向の音声品質情報及び第２ユーザ端末から第１ユーザ端末方向の音声品質情報を含む呼情報を、各呼についてそれぞれ管理し、
   前記管理される呼情報に応じて音声通信の音声品質を劣化させる障害箇所を特定する、
   ことを含む障害検出方法。
7. 第１ユーザ端末と第２ユーザ端末との間の音声通信を実現する通信網に設置されるコンピュータで実行される障害検出プログラムにおいて、
   前記通信網を流れる呼制御パケット及び音声パケットを前記通信網上の複数箇所からそれぞれ取り出し、
   前記複数個所の各々から取り出された呼制御パケット及び音声パケットに基づいて、前記複数箇所の各々における第１ユーザ端末から第２ユーザ端末方向の音声品質情報及び第２ユーザ端末から第１ユーザ端末方向の音声品質情報を含む呼情報を、各呼についてそれぞれ管理し、
   前記管理される呼情報に応じて音声通信の音声品質を劣化させる障害箇所を特定する、
   ことを含む障害検出プログラム。

Images