(57)【要約】【課題】他社網における障害発生時に、障害の原因を特定する。【解決手段】他社網の障害を検知する障害検知装置１であって、最大転送数を含むリクエストを前記他社網に送信することで、他社網の階層の深さを示す階層数を検出する階層検出部１１と、他社網の障害を検知した場合、他社網に前記リクエストを送信することで、前記他社網の障害箇所の階層を特定する障害箇所特定部１３と、障害箇所の階層が他社網の階層数より小さい階層の場合、他社網の網コア装置の障害と判定する判定部１４と、を備える。【選択図】図１
2019149752.tif 000002
【特許請求の範囲】
【請求項１】
他社網の障害を検知する障害検知装置であって、
最大転送数を含むリクエストを前記他社網に送信することで、前記他社網の階層の深さを示す階層数を検出する階層検出部と、
前記他社網の障害を検知した場合、前記他社網に前記リクエストを送信することで、前記他社網の障害箇所の階層を特定する障害箇所特定部と、
前記障害箇所の階層が前記他社網の階層数より小さい階層の場合、前記他社網の網コア装置の障害と判定する判定部と、を備えること
を特徴とする障害検知装置。
【請求項２】
請求項１記載の障害検知装置であって、
前記階層検出部は、前記リクエストの最大転送数を、０から１ずつ増加させて前記他社網に送信し、前記他社網から成功応答を受信したときの前記最大転送数に１加算した値を、前記他社網の階層の深さを示す階層数と特定すること
を特徴とする障害検知装置。
【請求項３】
請求項１または２記載の障害検知装置であって、
INVITEリクエストを前記他社網に送信する際にタイマを起動し、前記INVITEリクエストに対する暫定レスポンスを受信することなく、前記タイマがタイムアウトになった場合、前記他社網の障害を検知する障害検知部を、備えること
を特徴とする障害検知装置。
【請求項４】
請求項１から３のいずれか１項に記載の障害検知装置であって、
前記判定部は、記他社網の網コア装置の障害と判別した場合、前記他社網の現用のインタフェースサーバとは別のインタフェースサーバに前記リクエストを送信し、前記別のインタフェースサーバを介した経路での他社網の疎通確認後に、前記別のインタフェースサーバへ切り替えること
を特徴とする障害検知装置。
【請求項５】
障害検知装置が行う、他社網の障害を検知する障害検知方法であって、
最大転送数を含むリクエストを前記他社網に送信することで、前記他社網の階層の深さを示す階層数を検出する階層検出ステップと、
前記他社網の障害を検知した場合、前記他社網に前記リクエストを送信することで、前記他社網の障害箇所の階層を特定する障害箇所特定ステップと、
前記障害箇所の階層が前記他社網の階層数より小さい階層の場合、前記他社網の網コア装置の障害と判定する判定ステップと、を行うこと
を特徴とする障害検知方法。
【請求項６】
請求項５記載の障害検知方法であって、
前記階層検出ステップは、前記リクエストの最大転送数を、０から１ずつ増加させて前記他社網に送信し、前記他社網から成功応答を受信したときの前記最大転送数に１加算した値を、前記他社網の階層の深さを示す階層数と特定すること
を特徴とする障害検知方法。
【請求項７】
請求項５または６記載の障害検知方法であって、
INVITEリクエストを前記他社網に送信する際にタイマを起動し、前記INVITEリクエストに対する暫定レスポンスを受信することなく、前記タイマがタイムアウトになった場合、前記他社網の障害を検知する障害検知ステップを、行うこと
を特徴とする障害検知方法。
【請求項８】
請求項１から４のいずれか１項に記載の障害検知装置として、コンピュータを機能させること、を特徴とする障害検知プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、他社網の障害を検知する障害検知装置、障害検知方法、および障害検知プログラムに関する。
【背景技術】
【０００２】
近年、各通信事業者（キャリア）間のIP相互接続に向け、相互接続性確認試験を実施しており、SIP信号条件、POI（Point Of Interface）構成等のルール作りを進めている（非特許文献１〜３）。今後は、IP相互接続におけるネットワーク障害時のアクションについての検討が予定されている。
【先行技術文献】
【非特許文献】
【０００３】
【非特許文献１】TTC, JJ-90.30, "IMS事業者網間の相互接続共通インタフェース"
【非特許文献２】3GPP, TS 29.165, "Inter-IMS Network to Network Interface (NNI)“
【非特許文献３】IETF, RFC3261,“SIP: Session Initiation Protocol”
【発明の概要】
【発明が解決しようとする課題】
【０００４】
自社網と他社網とのPOI境界に設置されるNNI-GW（Network to Network Interface - Gateway）では、他社網内の障害を検知することが困難であり、また、通信事業者間での障害伝達の標準化がなされていない。
【０００５】
自社網の自社NNI-GWが、複数POIで他社網と接続されている場合、POIの切り替えを行うことで、他社網の障害を迅速に回避できる可能性がある。ただし、他社網の障害の原因が、他社網自体ではなく、ユーザ端末側にある可能性もある。
【０００６】
障害の原因がユーザ端末側にある場合、障害の影響する範囲は限定的であり、また、POIを切り替えても障害復旧の効果はない。一方、障害の原因が他社網自体の場合は、障害の影響範囲（り障範囲）が大きく、POIの切り替えを行うことで、障害を回避できる可能性がある。そのため、他社網の障害の原因を特定する必要がある。
【０００７】
現在、他社網で障害発生時に、自社NNI-GWは、500（Server Internal Error）レスポンスを他社網から受信するが、当該500レスポンスでは、障害の原因を特定することができない。
【０００８】
また、他社網から障害の内容を伝達してもらう方法が考えられる。しかしながら、この場合、「エラーコード＋ワーニングコード」の組み合わせを標準化する必要があり、全ての通信事業者がこのような標準化を自社網で実装する必要があるため、現実的ではない。
【０００９】
本発明は、上記事情に鑑みてなされたものであり、本発明の目的は、他社網における障害発生時に、障害の原因を特定することにある。
【課題を解決するための手段】
【００１０】
上記目的を達成するため、本発明は、他社網の障害を検知する障害検知装置であって、最大転送数を含むリクエストを前記他社網に送信することで、前記他社網の階層の深さを示す階層数を検出する階層検出部と、前記他社網の障害を検知した場合、前記他社網に前記リクエストを送信することで、前記他社網の障害箇所の階層を特定する障害箇所特定部と、前記障害箇所の階層が前記他社網の階層数より小さい階層の場合、前記他社網の網コア装置の障害と判定する判定部と、を備える。
【００１１】
本発明は、障害検知装置が行う、他社網の障害を検知する障害検知方法であって、最大転送数を含むリクエストを前記他社網に送信することで、前記他社網の階層の深さを示す階層数を検出する階層検出ステップと、前記他社網の障害を検知した場合、前記他社網に前記リクエストを送信することで、前記他社網の障害箇所の階層を特定する障害箇所特定ステップと、前記障害箇所の階層が前記他社網の階層数より小さい階層の場合、前記他社網の網コア装置の障害と判定する判定ステップと、を行う。
【００１２】
本発明は、上記障害検知装置として、コンピュータを機能させること、を特徴とする障害検知プログラムである。
【発明の効果】
【００１３】
本発明によれば、他社網における障害発生時に、障害の原因を特定することができる。
【図面の簡単な説明】
【００１４】
【図１】本発明の実施形態に係る通信システムの全体構成を示す図である。
【図２】自社NNI-GWの構成を示す機能ブロック図である。
【図３】平常時における、他社網の階層数を検出するシーケンス図である。
【図４】障害時における、他社網の障害箇所を特定するシーケンス図である。
【発明を実施するための形態】
【００１５】
以下、本発明の実施の形態について、図面を参照して説明する。
【００１６】
図１は、本発明の実施形態に係る通信システムの全体を示すシステム構成図である。図示する通信システムは、異なる通信事業者間でIP相互接続が行われるシステムである。
【００１７】
本実施形態の通信システムでは、自社である通信事業者Ａの自社網と、他社である通信事業者Ｂの他者網とが、複数のPOI（Point Of Interface：相互接続点）９を介して接続されている。自社網および他社網は、IP網である。また、他者網にはユーザ端末８が接続されている。
【００１８】
図示する自社網は、自社NNI-GW１と、自社SIPサーバ２と、DNSサーバ３とを含む。自社NNI-GW１は、他社網とのPOI境界に設置されるゲートウェイである。自社NNI-GW１は、自社網と他社網とを相互に接続するために、データ形式、通信方式などを変換する。また、本実施形態の自社NNI-GW１は、他社網の障害を検知する。自社SIPサーバ２は、発信および着信などの呼処理（呼制御）を行う。
【００１９】
DNS（Domain Name System）サーバ３は、他社網に配置された他社NNI-GW５の名前解決を行う。ここでは、DNSサーバは、自社NNI-GW１からの要求に応じて、他社網に配置された全ての他社NNI-GW５のリストを自社NNI-GW１に送信する。図１では、他社網には３つの他社NNI-GW５が配置されているため、リストには３つの他社NNI-GW５に関する情報が設定されている。
【００２０】
図示する他者網は、２つのPOI９を介して自社網（自社NNI-GW１）と接続され、複数の他社NNI-GW５と、複数の他社SIPサーバ６Ａ、６Ｂと、他社HGW（Home GateWay）７とを備える。現在のIP相互接続仕様の標準化（通信事業者の調整）において、複数のPOI９を介して２つの網を相互に接続すること、および、１つのPOI９に複数の他社NNI-GW５を接続することが検討されている。ここでは、第１のPOI９には、２つの他社NNI-GW５が接続され、第２のPOI９には、１つの他社NNI-GW５が接続されている。
【００２１】
他社NNI-GW５は、自社網とのPOI境界に設置されるゲートウェイである。他社NNI-GW５は、２つの網を相互に接続するために、データ形式、通信方式などを変換する。他社SIPサーバ６は、発信および着信などの呼処理を行う。なお、他社NNI-GW５および他社SIPサーバ６は、他社網のコア網装置である。
【００２２】
他社HGW７は、ユーザ端末８を他社網に接続するためのユーザ側装置である。他社HGW７にはユーザ端末８が接続される。ユーザ端末８は、電話機能を有する端末であって、例えばSIP端末などを用いることができる。なお、図１では、１つの他社HGW７および１つのユーザ端末８を記載しているが、他社網は複数の他社HGW７を備え、他社網には複数のユーザ端末８が接続されているものとする。
【００２３】
図示する他社網は、一例として、左から順に他社NNI-GW５、２つの他社SIPサーバ６、および他社HGW７の４階層の網であるが、これに限定されるものではない。
【００２４】
また、図１に示す通信システムでは、NNI-GW１、５は、SIPサーバ２、６とは独立した装置であるが、SIPサーバ２、６がNNI-GW１、５の機能を備えることとしてもよい。
【００２５】
図２は、本実施形態の自社NNI-GW１（障害検知装置）の構成を示す機能ブロック図である。図示する自社NNI-GW１は、階層検出部１１と、障害検知部１２と、障害箇所特定部１３と、判定部１４と、相互接続部１５と、記憶部１６とを備える。
【００２６】
階層検出部１１は、最大転送数を含むOPTIONSリクエストを他社網に送信することで、他社網の階層の深さを示す階層数を検出する。具体的には、階層検出部１１は、リクエストの最大転送数を、０から１ずつ増加させて他社網に送信し、他社網から成功応答を受信したときの最大転送数に１加算した値を、他社網の階層の深さを示す階層数と特定する。
【００２７】
障害検知部１２は、INVITEリクエストを他社網に送信する際にタイマを起動し、INVITEリクエストに対する18xレスポンス（暫定レスポンス）を受信することなく、タイマがタイムアウトになった場合、他社網の障害を検知する。また、障害検知部１２は、他社NNI-GW５から500エラーレスポンス（Server Internal Error）を受信した場合、他社網の障害を検知する。
【００２８】
障害箇所特定部１３は、他社網の障害を検知した場合、他社網にOPTIONSリクエストを送信することで、他社網の障害箇所の階層を特定する。
【００２９】
判定部１４は、障害箇所の階層が他社網の階層数より小さい階層の場合、他社網の網コア装置（他社NNI-GW５、他社SIPサーバ６）に起因する障害と判定し、障害箇所の階層が他社網の階層数と等しい場合、ユーザ側装置（他社HGW７）またはユーザ端末８に起因する障害であると判定する。また、判定部１４は、他社網の網コア装置に起因する障害と判別した場合、他社網の現用の他社NNI-GW５とは別の他社NNI-GW５にOPTIONSリクエストを送信し、別の他社NNI-GW５を介した経路での他社網の疎通確認後に、別の他社NNI-GW５の経路へ切り替える。
【００３０】
相互接続部１５は、他社網とデータを送受信するために、データ形式、通信方式などを変換する。記憶部１６には、階層検出部１１が検出した他社網の階層数などが記憶される。
【００３１】
上記説明した自社NNI-GW１には、例えば、CPU（Central Processing Unit、プロセッサ）と、メモリと、ストレージ（HDD：Hard Disk Drive、SSD：Solid State Drive）と、通信装置と、入力装置と、出力装置とを備える汎用的なコンピュータシステムを用いることができる。このコンピュータシステムにおいて、CPUがメモリ上にロードされた自社NNI-GW１用のプログラムを実行することにより、自社NNI-GW１の各機能が実現される。また、自社NNI-GW１用のプログラムは、HDD、SSD、USBメモリ、CD-ROM、DVD-ROM、MOなどのコンピュータ読取り可能な記録媒体に記憶することも、ネットワークを介して配信することもできる。
【００３２】
次に、本実施形態の通信システムにおける動作を説明する。
【００３３】
図３は、平常時における通信システムの動作を示すシーケンス図である。平常時において、自社NNI-GW１は、OPTIONSリクエストを他社網に送信することで、他社網の階層の深さを示す階層数を検出する。
【００３４】
具体的には、自社NNI-GW１の階層検出部１１は、サンプリング的にOPTIONSリクエストを他社網に送信する。その際、階層検出部１１は、OPTIONSリクエストの最大転送数を示すMax-Forwardヘッダ（以下、「MF」という。）の値を、０から１ずつ増加（インクリメント）させながら送信する。なお、OPTIONSリクエストの宛先（Request-URI）は、他社網の電話番号体系の任意の電話番号とする。
【００３５】
図示する例では、階層検出部１１は、MF値に０を設定したOPTIONSリクエストを、他社網の他社NNI-GW５に送信する（Ｓ１１）。図１に示すように、他社網に複数の他社NNI-GW５が存在する場合、階層検出部１１は、任意のPOIの任意の他社NNI-GW５にOPTIONSリクエストを送信する。
【００３６】
OPTIONSリクエストを受信した他社NNI-GW５は、MF値を１減算しようとするが、受信したOPTIONSリクエストのMF値は０であるため、483エラーレスポンス（エラー応答）を自社NNI-GW１に送信する（Ｓ１２）。483エラーは、最大ホップ数を超えた場合に送信される。
【００３７】
そして、階層検出部１１は、MF値に１を設定したOPTIONSリクエストを、他社網の他社NNI-GW５に送信する（Ｓ１３）。他社NNI-GW５は、OPTIONSリクエストのMF値を１減算し、MF値０のOPTIONSリクエストを次の転送先の他社SIPサーバ６Ａに送信する（Ｓ１４）。他社SIPサーバ６Ａは、受信したOPTIONSリクエストのMF値は０であるため、483エラーレスポンスを、他社NNI-GW５を介して自社NNI-GW１に送信する（Ｓ１５）。
【００３８】
そして、階層検出部１１は、MF値に２を設定したOPTIONSリクエストを、他社網の他社NNI-GW５に送信する（Ｓ１６）。他社NNI-GW５は、OPTIONSリクエストのMF値を１減算し、MF値１のOPTIONSリクエストを次の転送先の他社SIPサーバ６Ａに送信する（Ｓ１７）。他社ＳＩＰサーバ６Ａは、OPTIONSリクエストのMF値を１減算し、MF値０のOPTIONSリクエストを次の転送先の他社SIPサーバ６Ｂに送信する（Ｓ１８）。他社ＳＩＰサーバ６Ｂは、受信したOPTIONSリクエストのMF値は０であるため、483エラーレスポンスを、他社NNI-GW５等を介して自社NNI-GW１に送信する（Ｓ１９）。
【００３９】
そして、階層検出部１１は、MF値に３を設定したOPTIONSリクエストを、他社網の他社NNI-GW５に送信する（Ｓ２０）。他社NNI-GW５は、OPTIONSリクエストのMF値を１減算し、MF値２のOPTIONSリクエストを次の転送先の他社SIPサーバ６Ａに送信する（Ｓ２１）。他社ＳＩＰサーバ６Ａは、OPTIONSリクエストのMF値を１減算し、MF値を１のOPTIONSリクエストを次の転送先の他社SIPサーバ６Ｂに送信する（Ｓ２２）。他社ＳＩＰサーバ６Ｂは、OPTIONSリクエストのMF値を１減算し、MF値０のOPTIONSリクエストを次の転送先の他社HGW７に送信する（Ｓ２３）。他社HGW７は、受信したOPTIONSリクエストが自分の宛先であるため、200 OKレスポンス（成功応答）を、他社NNI-GW５等を介して自社NNI-GW１に送信する（Ｓ２４）。
【００４０】
自社NNI-GW１の階層検出部１１は、200 OKレスポンスを受信したときのOPTIONSリクエストのMF値に１加算した値が、他社網の階層の深さを示す階層数であると検出（学習）する（Ｓ２５）。そして、階層検出部１１は、検出した階層数を記憶部１６に記憶する。図３に示す例では、階層の浅い順に、他社NNI-GW５は１階層目、他社SIPサーバ６Ａが２階層目、他社SIPサーバ６Ｂが３階層目、他社HGW７が４階層目となる。
【００４１】
なお、複数の通信事業者の他社網とIP相互接続を行う場合、自社NNI-GW１は、通信事業者毎に、図３に示す動作により他社網の階層の深さを検出し、階層数を記憶部１６に記憶する。
【００４２】
また、本実施形態では、OPTIONSリクエストを用いて他社網の階層の深さを検出するが、これに限定されるものでなく、MFを含むメッセージであればOPTIONSリクエスト以外のメッセージであってもよい。
【００４３】
図４は、障害時における通信システムの動作を示すシーケンス図である。ここでは、自社SIPサーバ２が送信したINVITEリクエスト（セッション確立要求）がエラーとなる場合を例に説明する。
【００４４】
自社SIPサーバ２は、INVITEリクエストを自社NNI-GW１に送信する（Ｓ３１）。自社NNI-GW１の相互接続部１５は、受信したINVITEリクエストを他社網の他社NNI-GW５に送信するとともに（Ｓ３２）、100 tryingレスポンス（試行中応答）を自社SIPサーバ２に送信する（Ｓ３３）。
【００４５】
また、自社NNI-GW１の故障検知部は、Ｓ３２でINVITEリクエストを他社NNI-GW５に送信すると同時に、18x受信タイマを起動し、タイムアウトを監視する。18x受信タイマは、18xレスポンス（例えば180 Ringing、181 Call is being forwardedなど）の受信を監視するためのタイマである。なお、18x受信タイマのタイマ値は、他社網の障害検知を迅速に行うために比較的短い値とする。
【００４６】
他社NNI-GW５は、INVITEリクエストを次の階層の他社SIPサーバ６Ａに送信するとともに（Ｓ３４）、100 tryingレスポンスを自社NNI-GW１に送信する（Ｓ３５）。そして、他社SIPサーバ６Ａは、INVITEリクエストを次の階層の他社SIPサーバ６Ｂに送信するとともに（Ｓ３６）、100 tryingレスポンスを他社NNI-GW５に送信する（Ｓ３７）。
【００４７】
ここで、他社SIPサーバ６Ｂに障害が発生している場合、他社SIPサーバ６Ｂは、INVITEリクエストを受信することができず、あるいは、INVITEリクエストを受信しても当該リクエストを処理することができない。これにより、自社NNI-GW１は、正常時においては他社HGW７から送信される18xレスポンスを、Ｓ３２で起動した18x受信タイマが満了する前に受信することができない。すなわち、18xレスポンスを受信する前に、Ｓ３４で起動した18x受信タイマがタイムアウトとなる。これにより、障害検知部１２は、他社網で障害が発生したことを検知する（Ｓ３８）。
【００４８】
あるいは、他社SIPサーバ６Ｂに障害が発生している場合、隣接する他社SIPサーバ６Ａは、他社SIPサーバ６Ｂの障害を検知して、503エラーレスポンス（Service Unavailable）を隣接する他社NNI-GW５に送信する（Ｓ４１）。他社NNI-GW５は、503エラーレスポンスを受信すると、500エラーレスポンス（Server Internal Error）にインタワークして、隣接する自社NNI-GW１に送信する（Ｓ４２）。これにより、自社NNI-GW１の障害検知部１２は、他社網で障害が発生したと検知する（Ｓ４３）。
【００４９】
本実施形態では、自社NNI-GW１の障害検知部１２は、Ｓ３８の18x受信タイマのタイムアウト、または、Ｓ４３の500エラーレスポンスの受信により、他社網での障害を検知する。
【００５０】
障害検知部１２が他社網の障害を検知すると、自社NNI-GW１の障害箇所特定部１３は、他社網の障害箇所を特定する。具体的には、障害箇所特定部１３は、図３で説明したように、OPTIONSリクエストに含まれる最大転送数を示すMF値を、０から１ずつ増加させながら送信して、SIPトレースルートを実施し、障害箇所を特定する。また、障害箇所特定部１３は、OPTIONSリクエストの宛先（Request-URI）に、INVITEリクエスト（Ｓ３１、Ｓ３２等）で指定された電話番号を設定する。
【００５１】
正常な他社網の各装置は、MF値が０になると483エラーレスポンスを送信する。そこで、障害箇所特定部１３は、OPTIONSリクエストを送信すると同時に483受信タイマを起動し、当該タイマのタイムアウトを監視する。障害箇所特定部１３は、483受信タイマが満了する前に483エラーレスポンスを受信することができない場合、すなわち、483エラーレスポンスを受信する前に483受信タイマがタイムアウトとなった場合、他社網の故障箇所が自分より何番目の階層か（何ホップ先か）を特定する。
【００５２】
図示する例では、障害箇所特定部１３は、MF値に０を設定したOPTIONSリクエストを、他社網の他社NNI-GW５に送信するとともに、483受信タイマを起動する（Ｓ５１）。他社NNI-GW５は、受信したOPTIONSリクエストのMF値は０であるため、483エラーレスポンスを自社NNI-GW１に送信する（Ｓ５２）。
【００５３】
そして、階層検出部１１は、MF値に１を設定したOPTIONSリクエストを、他社NNI-GW５に送信するとともに、483受信タイマを起動する（Ｓ５３）。他社NNI-GW５は、OPTIONSリクエストのMF値を１減算し、MF値０のOPTIONSリクエストを他社SIPサーバ６Ａに送信する（Ｓ５４）。他社SIPサーバ６Ａは、受信したOPTIONSリクエストのMF値は０であるため、483エラーレスポンスを自社NNI-GW１に送信する（Ｓ５５）。
【００５４】
そして、階層検出部１１は、MF値に２を設定したOPTIONSリクエストを、他社網の他社NNI-GW５に送信するとともに、483受信タイマを起動する（Ｓ５６）。他社NNI-GW５は、OPTIONSリクエストのMF値を１減算し、MF値１のOPTIONSリクエストを他社SIPサーバ６Ａに送信する（Ｓ５７）。他社SIPサーバ６Ａは、OPTIONSリクエストのMF値を１減算し、MF値０のOPTIONSリクエストを他社SIPサーバ６Ｂに送信する（Ｓ５８）。
【００５５】
ここで、他社ＳＩＰサーバ６Ｂで障害が発生しているため、他社SIPサーバ６Ｂは、MF値０のOPTIONSリクエストに対する483エラーレスポンスを送信することができない。これにより、障害箇所特定部１３は、483エラーレスポンスをＳ５６で起動した483受信タイマが満了する前に受信することができず、483受信タイマがタイムアウトとなる。
【００５６】
これにより、障害箇所特定部１３は、他社網における故障箇所を特定する。すなわち、障害箇所特定部１３は、483受信タイマがタイムアウトとなったときのOPTIONSリクエストのMF値に１加算した値の階層（ホップ先）が、障害が発生した箇所であると特定する（Ｓ５９）。
【００５７】
図４に示す例では、障害箇所特定部１３は、483受信タイマがタイムアウトとなったときのOPTIONSリクエストのMF値２に１加算した３階層目（他社SIPサーバ６Ｂ）が、障害箇所であると特定する。
【００５８】
そして、自社NNI-GW１の判定部１４は、他社網の網コア装置に起因する障害であるのか、あるいは、ユーザ側装置またはユーザ端末８に起因する障害であるのか判定する。
【００５９】
具体的には、判定部１４は、障害箇所特定部１３が特定した障害箇所の階層が、階層検出部１１が検出した他社網の階層数より小さい階層（浅い階層、自社NNI-GW1に近い階層）の場合は、他社網の網コア装置（他社NNI-GW５、他社SIPサーバ６Ａ、６Ｂ）に起因する障害と判定する。
【００６０】
一方、判定部１４は、特定した障害箇所の階層が他社網の階層数と等しい場合、ユーザ側装置（他社HGW7）またはユーザ端末８に起因する障害であると判定する（Ｓ５９）。ユーザ側装置またはユーザ端末８に起因する障害と判定した場合、判定部１４は、障害の影響が限定的であり、また、現用の他社NNI-GW５とは別の他社NNI-GW５に切り替えても当該障害を回避することは難しいと判断する。このため、判定部１４は、障害回避に関する処理は行わない。
【００６１】
他社網の網コア装置の障害と判定した場合、判定部１４は、障害の影響が大きく、現用の他社NNI-GW５を他の他社NNI-GW５に切り替えた場合、障害を回避できる可能性があると判断する。そのため、判定部１４は、障害箇所が特定された他社SIPサーバ６Ｂの経路に繋がる現用の他社NNI-GW５とは別の他社NNI-GWを経由したSIP信号の到達可能性を検査する。すなわち、別の他社NNI-GW５の経路での疎通確認に応じて、他社網の切替先の他社NNI-GW５（経路）を洗い出す。
【００６２】
具体的には、判定部１４は、DNSサーバ３にアクセスし、他社網の全ての他社NNI-GW５に関する情報（例えば、URIなどのアドレス、識別情報など）が設定されたNNI-GWリストを取得する。そして、判定部１４は、障害が検知された経路（系）である、現用の他社NNI-GW５以外の他の他社NNI-GWにOPTIONSリクエストを送信する。このとき、判定部１４は、図３と同様に、OPTIONSリクエストに含まれる最大転送数を示すMF値を、０から１ずつ増加させながら、他の他社NNI-GWにOPTIONSリクエストを送信する。また、判定部１４は、OPTIONSリクエストの宛先（Request-URI）に、INVITEリクエスト（Ｓ３１、Ｓ３２等）で指定された電話番号を設定する。なお、他の他社NNI-GW５には、図１に示すように、同じPOIの他の他社NNI-GW５と、異なるPOIの他の他社NNI-GW５とが含まれる。
【００６３】
そして、判定部１４は、いずれかの他の他社NNI-GW５の経路でOPTIONSリクエストに対する200 OKレスポンスを受信すると、他社NNI-GW５の切替で障害が回避できるケースであると判定し、当該他の他社NNI-GW５への経路切替を実施する。なお、経路切替には、同じPOIの他の他社NNI-GW５への経路切替と、異なるPOIの他の他社NNI-GW５への経路切替とがある。
【００６４】
これにより、本実施形態では、他社網の網コア装置の障害と判定した場合に、切替先の経路を洗い出し、障害を回避することができる。また、本実施形態では、経路を切り替え前に、事前に、経路を切り替えることで障害が回避できるかを、OPTIONSリクエストを送信して疎通確認することで検証する。これにより、障害が回避できる場合にのみ、経路を切り替え、経路を切り替えても効果がない（障害が回避できない）場合に、経路を切り替えてしまう無駄な処理を回避することができる。
【００６５】
以上説明した本実施形態では、最大転送数を含むリクエストを前記他社網に送信することで、前記他社網の階層の深さを示す階層数を検出し、前記他社網の障害を検知した場合、前記他社網に前記リクエストを送信することで、前記他社網の障害箇所の階層を特定し、前記障害箇所の階層が前記他社網の階層数より小さい階層の場合、前記他社網の網コア装置の障害と判定する。
【００６６】
これにより、本実施形態では、他社網で障害が発生した場合、障害の影響範囲を大きいもので、障害を回避できる可能性があるケースか、あるいは、ユーザ端末障害などの障害の影響が限定的なもので、障害を回避できる可能性がないケースかを把握（区別）することができる。
【００６７】
また、本願発明は、INVITEリクエストを他社網に送信する際に18x受信タイマを起動し、INVITEリクエストに対する暫定レスポンスを受信することなく、18x受信タイマがタイムアウトになった場合、他社網の障害を検知する。これにより、本実施形態では、18x受信タイマのタイマ値を短くすることで、他社網で発生した障害を迅速に検知することができる。
【００６８】
従来、他社網の障害を検知するには、他社NNI-GW５とのTCPコネクションが切断されるか、INVITEタイムアウト（SIP  Timer B:32秒）を待つしかない。しかしながら、他社NNI-GW５とTCPコネクションを張らない場合は、障害を検知することができない。また、隣接する他社NNI-GW５の先の装置で障害が発生している場合であっても、隣接する他社NNI-GW５からはINVITEリクエストに対する100tryingレスポンスが返答されるため、障害を検知することができない。また、隣接する他社NNI-GW５の先の装置での障害を検知するには、INVITEタイム満了（SIP  Timer C:180秒）が考えらえるが、この場合、他社網での障害の検知が長時間化してしまい、その間に多数の呼損が生じる。
【００６９】
これに対し、本実施形態では、NVITEリクエストを他社網に送信する際に、18x受信タイマを起動することで、他社網における障害検知が長期間化することを回避することができる。なお、18x受信タイマのタイマ値は、迅速な障害検知ができるように比較的、短い時間を設定する。
【００７０】
また、本実施形態では、自社NNI-GW１の実装のみで実現できるため、他社網の装置の実装状況に依存せず、能動的に他社網の障害の原因を検知することができる。また、自社NNI-GW１内の実装であるため、開発が容易で、かつ、オペレータが介在することなく、他の他社NNI-GW５に切り替えることで障害を回避することができる。
【００７１】
なお、本発明は上記実施形態に限定されるものではなく、その要旨の範囲内で数々の変形が可能である。
【符号の説明】
【００７２】
１  ：自社NNI-GW
１１：階層検出部 
１２：障害検知部
１３：障害箇所特定部
１４：判定部
１５：相互接続部
１６：記憶部
２  ：自社SIPサーバ
３  ：DNSサーバ
５  ：他社NNI-GW
６  ：他社SIPサーバ
７  ：他社HGW
８  ：ユーザ端末
【図１】
2019149752.tif 000003
【図２】
2019149752.tif 000004
【図３】
2019149752.tif 000005
【図４】
2019149752.tif 000006