特許 6985606 障害検知装置、障害検知方法、および障害検知プログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6985606

(24)【登録日】2021年11月30日

(45)【発行日】2021年12月22日

(54)【発明の名称】障害検知装置、障害検知方法、および障害検知プログラム

(51)【国際特許分類】

   H04L 12/70 20130101AFI20211213BHJP

   H04M 3/00 20060101ALI20211213BHJP

【ＦＩ】

   H04L12/70 100Z

   H04M3/00 E

【請求項の数】7

【全頁数】12

(21)【出願番号】特願2018-34459(P2018-34459)

(22)【出願日】2018年2月28日

(65)【公開番号】特開2019-149752(P2019-149752A)

(43)【公開日】2019年9月5日

【審査請求日】2019年12月16日

(73)【特許権者】

【識別番号】000004226

【氏名又は名称】日本電信電話株式会社

(74)【代理人】

【識別番号】100083806

【弁理士】

【氏名又は名称】三好 秀和

(74)【代理人】

【識別番号】100129230

【弁理士】

【氏名又は名称】工藤 理恵

(72)【発明者】

【氏名】山本 高大

(72)【発明者】

【氏名】谷田 康司

【審査官】 今川 悟

(56)【参考文献】

【文献】 国際公開第２００５／０７６５５０（ＷＯ，Ａ１）

【文献】 特開２０１１−１４６９２０（ＪＰ，Ａ）

【文献】 山本 高大 Kodai YAMAMOTO，ＮＴＮＩ−ＧＷにおける他社網障害検知方法に関する一考察，電子情報通信学会２０１７年総合大会講演論文集 通信２ PROCEEDINGS OF THE 2017 IEICE GENERAL CONFERENCE，日本，2017年03月07日，152

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｌ １２／７０

Ｈ０４Ｍ ３／００

(57)【特許請求の範囲】

【請求項1】

他社網の障害を検知する障害検知装置であって、
最大転送数を含むリクエストを前記他社網に送信することで、前記他社網の階層の深さを示す階層数を検出する階層検出部と、
前記他社網の障害を検知した場合、前記他社網に前記リクエストを送信することで、前記他社網の障害箇所の階層を特定する障害箇所特定部と、
前記障害箇所の階層が前記他社網の階層数より小さい階層の場合、前記他社網の網コア装置の障害と判定する判定部と、を備え、
前記判定部は、前記他社網の網コア装置の障害と判別した場合、前記他社網の現用のインタフェースサーバとは別のインタフェースサーバに前記リクエストを送信し、ＯＫレスポンスを受信することで前記別のインタフェースサーバを介した経路での他社網の疎通が確認できた後に、前記別のインタフェースサーバへ切り替えること
を特徴とする障害検知装置。

【請求項2】

請求項１に記載の障害検知装置であって、
前記判定部は、前記障害箇所の階層が前記他社網の階層数と等しい場合、前記他社網のユーザ側装置またはユーザ端末の障害と判定し、前記別のインタフェースサーバへ切り替えを行わないこと
を特徴とする障害検知装置。

【請求項3】

請求項１または２に記載の障害検知装置であって、
前記障害箇所特定部は、前記リクエストの最大転送数を、０から１ずつ増加させて前記他社網に送信し、受信タイマがタイムアウトになったときの前記最大転送数に１加算した値を、前記他社網の障害箇所の階層として特定すること
を特徴とする障害検知装置。

【請求項4】

請求項１から３のいずれか１項に記載の障害検知装置であって、
前記階層検出部は、前記リクエストの最大転送数を、０から１ずつ増加させて前記他社網に送信し、前記他社網から成功応答を受信したときの前記最大転送数に１加算した値を、前記他社網の階層の深さを示す階層数と特定すること
を特徴とする障害検知装置。

【請求項5】

請求項１から４のいずれか１項に記載の障害検知装置であって、
INVITEリクエストを前記他社網に送信する際にタイマを起動し、前記INVITEリクエストに対する暫定レスポンスを受信することなく、前記タイマがタイムアウトになった場合、前記他社網の障害を検知する障害検知部を、備えること
を特徴とする障害検知装置。

【請求項6】

障害検知装置が行う、他社網の障害を検知する障害検知方法であって、
最大転送数を含むリクエストを前記他社網に送信することで、前記他社網の階層の深さを示す階層数を検出する階層検出ステップと、
前記他社網の障害を検知した場合、前記他社網に前記リクエストを送信することで、前記他社網の障害箇所の階層を特定する障害箇所特定ステップと、
前記障害箇所の階層が前記他社網の階層数より小さい階層の場合、前記他社網の網コア装置の障害と判定する判定ステップと、
前記他社網の網コア装置の障害と判別した場合、前記他社網の現用のインタフェースサーバとは別のインタフェースサーバに前記リクエストを送信し、ＯＫレスポンスを受信することで前記別のインタフェースサーバを介した経路での他社網の疎通が確認できた後に、前記別のインタフェースサーバへ切り替える切り替えステップと、を行うこと
を特徴とする障害検知方法。

【請求項7】

請求項１から５のいずれか１項に記載の障害検知装置として、コンピュータを機能させること、を特徴とする障害検知プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、他社網の障害を検知する障害検知装置、障害検知方法、および障害検知プログラムに関する。

【背景技術】

【0002】

近年、各通信事業者（キャリア）間のIP相互接続に向け、相互接続性確認試験を実施しており、SIP信号条件、POI（Point Of Interface）構成等のルール作りを進めている（非特許文献１〜３）。今後は、IP相互接続におけるネットワーク障害時のアクションについての検討が予定されている。

【先行技術文献】

【非特許文献】

【0003】

【非特許文献1】TTC, JJ-90.30, "IMS事業者網間の相互接続共通インタフェース"

【非特許文献2】3GPP, TS 29.165, "Inter-IMS Network to Network Interface (NNI)“

【非特許文献3】IETF, RFC3261,“SIP: Session Initiation Protocol”

【発明の概要】

【発明が解決しようとする課題】

【0004】

自社網と他社網とのPOI境界に設置されるNNI-GW（Network to Network Interface - Gateway）では、他社網内の障害を検知することが困難であり、また、通信事業者間での障害伝達の標準化がなされていない。

【0005】

自社網の自社NNI-GWが、複数POIで他社網と接続されている場合、POIの切り替えを行うことで、他社網の障害を迅速に回避できる可能性がある。ただし、他社網の障害の原因が、他社網自体ではなく、ユーザ端末側にある可能性もある。

【0006】

障害の原因がユーザ端末側にある場合、障害の影響する範囲は限定的であり、また、POIを切り替えても障害復旧の効果はない。一方、障害の原因が他社網自体の場合は、障害の影響範囲（り障範囲）が大きく、POIの切り替えを行うことで、障害を回避できる可能性がある。そのため、他社網の障害の原因を特定する必要がある。

【0007】

現在、他社網で障害発生時に、自社NNI-GWは、500（Server Internal Error）レスポンスを他社網から受信するが、当該500レスポンスでは、障害の原因を特定することができない。

【0008】

また、他社網から障害の内容を伝達してもらう方法が考えられる。しかしながら、この場合、「エラーコード＋ワーニングコード」の組み合わせを標準化する必要があり、全ての通信事業者がこのような標準化を自社網で実装する必要があるため、現実的ではない。

【0009】

本発明は、上記事情に鑑みてなされたものであり、本発明の目的は、他社網における障害発生時に、障害の原因を特定することにある。

【課題を解決するための手段】

【0010】

上記目的を達成するため、本発明は、他社網の障害を検知する障害検知装置であって、最大転送数を含むリクエストを前記他社網に送信することで、前記他社網の階層の深さを示す階層数を検出する階層検出部と、前記他社網の障害を検知した場合、前記他社網に前記リクエストを送信することで、前記他社網の障害箇所の階層を特定する障害箇所特定部と、前記障害箇所の階層が前記他社網の階層数より小さい階層の場合、前記他社網の網コア装置の障害と判定する判定部と、を備える。

【0011】

本発明は、障害検知装置が行う、他社網の障害を検知する障害検知方法であって、最大転送数を含むリクエストを前記他社網に送信することで、前記他社網の階層の深さを示す階層数を検出する階層検出ステップと、前記他社網の障害を検知した場合、前記他社網に前記リクエストを送信することで、前記他社網の障害箇所の階層を特定する障害箇所特定ステップと、前記障害箇所の階層が前記他社網の階層数より小さい階層の場合、前記他社網の網コア装置の障害と判定する判定ステップと、を行う。

【0012】

本発明は、上記障害検知装置として、コンピュータを機能させること、を特徴とする障害検知プログラムである。

【発明の効果】

【0013】

本発明によれば、他社網における障害発生時に、障害の原因を特定することができる。

【図面の簡単な説明】

【0014】

【図1】本発明の実施形態に係る通信システムの全体構成を示す図である。

【図2】自社NNI-GWの構成を示す機能ブロック図である。

【図3】平常時における、他社網の階層数を検出するシーケンス図である。

【図4】障害時における、他社網の障害箇所を特定するシーケンス図である。

【発明を実施するための形態】

【0015】

以下、本発明の実施の形態について、図面を参照して説明する。

【0016】

図１は、本発明の実施形態に係る通信システムの全体を示すシステム構成図である。図示する通信システムは、異なる通信事業者間でIP相互接続が行われるシステムである。

【0017】

本実施形態の通信システムでは、自社である通信事業者Ａの自社網と、他社である通信事業者Ｂの他者網とが、複数のPOI（Point Of Interface：相互接続点）９を介して接続されている。自社網および他社網は、IP網である。また、他者網にはユーザ端末８が接続されている。

【0018】

図示する自社網は、自社NNI-GW１と、自社SIPサーバ２と、DNSサーバ３とを含む。自社NNI-GW１は、他社網とのPOI境界に設置されるゲートウェイである。自社NNI-GW１は、自社網と他社網とを相互に接続するために、データ形式、通信方式などを変換する。また、本実施形態の自社NNI-GW１は、他社網の障害を検知する。自社SIPサーバ２は、発信および着信などの呼処理（呼制御）を行う。

【0019】

DNS（Domain Name System）サーバ３は、他社網に配置された他社NNI-GW５の名前解決を行う。ここでは、DNSサーバは、自社NNI-GW１からの要求に応じて、他社網に配置された全ての他社NNI-GW５のリストを自社NNI-GW１に送信する。図１では、他社網には３つの他社NNI-GW５が配置されているため、リストには３つの他社NNI-GW５に関する情報が設定されている。

【0020】

図示する他者網は、２つのPOI９を介して自社網（自社NNI-GW１）と接続され、複数の他社NNI-GW５と、複数の他社SIPサーバ６Ａ、６Ｂと、他社HGW（Home GateWay）７とを備える。現在のIP相互接続仕様の標準化（通信事業者の調整）において、複数のPOI９を介して２つの網を相互に接続すること、および、１つのPOI９に複数の他社NNI-GW５を接続することが検討されている。ここでは、第１のPOI９には、２つの他社NNI-GW５が接続され、第２のPOI９には、１つの他社NNI-GW５が接続されている。

【0021】

他社NNI-GW５は、自社網とのPOI境界に設置されるゲートウェイである。他社NNI-GW５は、２つの網を相互に接続するために、データ形式、通信方式などを変換する。他社SIPサーバ６は、発信および着信などの呼処理を行う。なお、他社NNI-GW５および他社SIPサーバ６は、他社網のコア網装置である。

【0022】

他社HGW７は、ユーザ端末８を他社網に接続するためのユーザ側装置である。他社HGW７にはユーザ端末８が接続される。ユーザ端末８は、電話機能を有する端末であって、例えばSIP端末などを用いることができる。なお、図１では、１つの他社HGW７および１つのユーザ端末８を記載しているが、他社網は複数の他社HGW７を備え、他社網には複数のユーザ端末８が接続されているものとする。

【0023】

図示する他社網は、一例として、左から順に他社NNI-GW５、２つの他社SIPサーバ６、および他社HGW７の４階層の網であるが、これに限定されるものではない。

【0024】

また、図１に示す通信システムでは、NNI-GW１、５は、SIPサーバ２、６とは独立した装置であるが、SIPサーバ２、６がNNI-GW１、５の機能を備えることとしてもよい。

【0025】

図２は、本実施形態の自社NNI-GW１（障害検知装置）の構成を示す機能ブロック図である。図示する自社NNI-GW１は、階層検出部１１と、障害検知部１２と、障害箇所特定部１３と、判定部１４と、相互接続部１５と、記憶部１６とを備える。

【0026】

階層検出部１１は、最大転送数を含むOPTIONSリクエストを他社網に送信することで、他社網の階層の深さを示す階層数を検出する。具体的には、階層検出部１１は、リクエストの最大転送数を、０から１ずつ増加させて他社網に送信し、他社網から成功応答を受信したときの最大転送数に１加算した値を、他社網の階層の深さを示す階層数と特定する。

【0027】

障害検知部１２は、INVITEリクエストを他社網に送信する際にタイマを起動し、INVITEリクエストに対する18xレスポンス（暫定レスポンス）を受信することなく、タイマがタイムアウトになった場合、他社網の障害を検知する。また、障害検知部１２は、他社NNI-GW５から500エラーレスポンス（Server Internal Error）を受信した場合、他社網の障害を検知する。

【0028】

障害箇所特定部１３は、他社網の障害を検知した場合、他社網にOPTIONSリクエストを送信することで、他社網の障害箇所の階層を特定する。

【0029】

判定部１４は、障害箇所の階層が他社網の階層数より小さい階層の場合、他社網の網コア装置（他社NNI-GW５、他社SIPサーバ６）に起因する障害と判定し、障害箇所の階層が他社網の階層数と等しい場合、ユーザ側装置（他社HGW７）またはユーザ端末８に起因する障害であると判定する。また、判定部１４は、他社網の網コア装置に起因する障害と判別した場合、他社網の現用の他社NNI-GW５とは別の他社NNI-GW５にOPTIONSリクエストを送信し、別の他社NNI-GW５を介した経路での他社網の疎通確認後に、別の他社NNI-GW５の経路へ切り替える。

【0030】

相互接続部１５は、他社網とデータを送受信するために、データ形式、通信方式などを変換する。記憶部１６には、階層検出部１１が検出した他社網の階層数などが記憶される。

【0031】

上記説明した自社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などのコンピュータ読取り可能な記録媒体に記憶することも、ネットワークを介して配信することもできる。

【0032】

次に、本実施形態の通信システムにおける動作を説明する。

【0033】

図３は、平常時における通信システムの動作を示すシーケンス図である。平常時において、自社NNI-GW１は、OPTIONSリクエストを他社網に送信することで、他社網の階層の深さを示す階層数を検出する。

【0034】

具体的には、自社NNI-GW１の階層検出部１１は、サンプリング的にOPTIONSリクエストを他社網に送信する。その際、階層検出部１１は、OPTIONSリクエストの最大転送数を示すMax-Forwardヘッダ（以下、「MF」という。）の値を、０から１ずつ増加（インクリメント）させながら送信する。なお、OPTIONSリクエストの宛先（Request-URI）は、他社網の電話番号体系の任意の電話番号とする。

【0035】

図示する例では、階層検出部１１は、MF値に０を設定したOPTIONSリクエストを、他社網の他社NNI-GW５に送信する（Ｓ１１）。図１に示すように、他社網に複数の他社NNI-GW５が存在する場合、階層検出部１１は、任意のPOIの任意の他社NNI-GW５にOPTIONSリクエストを送信する。

【0036】

OPTIONSリクエストを受信した他社NNI-GW５は、MF値を１減算しようとするが、受信したOPTIONSリクエストのMF値は０であるため、483エラーレスポンス（エラー応答）を自社NNI-GW１に送信する（Ｓ１２）。483エラーは、最大ホップ数を超えた場合に送信される。

【0037】

そして、階層検出部１１は、MF値に１を設定したOPTIONSリクエストを、他社網の他社NNI-GW５に送信する（Ｓ１３）。他社NNI-GW５は、OPTIONSリクエストのMF値を１減算し、MF値０のOPTIONSリクエストを次の転送先の他社SIPサーバ６Ａに送信する（Ｓ１４）。他社SIPサーバ６Ａは、受信したOPTIONSリクエストのMF値は０であるため、483エラーレスポンスを、他社NNI-GW５を介して自社NNI-GW１に送信する（Ｓ１５）。

【0038】

そして、階層検出部１１は、MF値に２を設定したOPTIONSリクエストを、他社網の他社NNI-GW５に送信する（Ｓ１６）。他社NNI-GW５は、OPTIONSリクエストのMF値を１減算し、MF値１のOPTIONSリクエストを次の転送先の他社SIPサーバ６Ａに送信する（Ｓ１７）。他社ＳＩＰサーバ６Ａは、OPTIONSリクエストのMF値を１減算し、MF値０のOPTIONSリクエストを次の転送先の他社SIPサーバ６Ｂに送信する（Ｓ１８）。他社ＳＩＰサーバ６Ｂは、受信したOPTIONSリクエストのMF値は０であるため、483エラーレスポンスを、他社NNI-GW５等を介して自社NNI-GW１に送信する（Ｓ１９）。

【0039】

そして、階層検出部１１は、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１に送信する（Ｓ２４）。

【0040】

自社NNI-GW１の階層検出部１１は、200 OKレスポンスを受信したときのOPTIONSリクエストのMF値に１加算した値が、他社網の階層の深さを示す階層数であると検出（学習）する（Ｓ２５）。そして、階層検出部１１は、検出した階層数を記憶部１６に記憶する。図３に示す例では、階層の浅い順に、他社NNI-GW５は１階層目、他社SIPサーバ６Ａが２階層目、他社SIPサーバ６Ｂが３階層目、他社HGW７が４階層目となる。

【0041】

なお、複数の通信事業者の他社網とIP相互接続を行う場合、自社NNI-GW１は、通信事業者毎に、図３に示す動作により他社網の階層の深さを検出し、階層数を記憶部１６に記憶する。

【0042】

また、本実施形態では、OPTIONSリクエストを用いて他社網の階層の深さを検出するが、これに限定されるものでなく、MFを含むメッセージであればOPTIONSリクエスト以外のメッセージであってもよい。

【0043】

図４は、障害時における通信システムの動作を示すシーケンス図である。ここでは、自社SIPサーバ２が送信したINVITEリクエスト（セッション確立要求）がエラーとなる場合を例に説明する。

【0044】

自社SIPサーバ２は、INVITEリクエストを自社NNI-GW１に送信する（Ｓ３１）。自社NNI-GW１の相互接続部１５は、受信したINVITEリクエストを他社網の他社NNI-GW５に送信するとともに（Ｓ３２）、100 tryingレスポンス（試行中応答）を自社SIPサーバ２に送信する（Ｓ３３）。

【0045】

また、自社NNI-GW１の故障検知部は、Ｓ３２でINVITEリクエストを他社NNI-GW５に送信すると同時に、18x受信タイマを起動し、タイムアウトを監視する。18x受信タイマは、18xレスポンス（例えば180 Ringing、181 Call is being forwardedなど）の受信を監視するためのタイマである。なお、18x受信タイマのタイマ値は、他社網の障害検知を迅速に行うために比較的短い値とする。

【0046】

他社NNI-GW５は、INVITEリクエストを次の階層の他社SIPサーバ６Ａに送信するとともに（Ｓ３４）、100 tryingレスポンスを自社NNI-GW１に送信する（Ｓ３５）。そして、他社SIPサーバ６Ａは、INVITEリクエストを次の階層の他社SIPサーバ６Ｂに送信するとともに（Ｓ３６）、100 tryingレスポンスを他社NNI-GW５に送信する（Ｓ３７）。

【0047】

ここで、他社SIPサーバ６Ｂに障害が発生している場合、他社SIPサーバ６Ｂは、INVITEリクエストを受信することができず、あるいは、INVITEリクエストを受信しても当該リクエストを処理することができない。これにより、自社NNI-GW１は、正常時においては他社HGW７から送信される18xレスポンスを、Ｓ３２で起動した18x受信タイマが満了する前に受信することができない。すなわち、18xレスポンスを受信する前に、Ｓ３４で起動した18x受信タイマがタイムアウトとなる。これにより、障害検知部１２は、他社網で障害が発生したことを検知する（Ｓ３８）。

【0048】

あるいは、他社SIPサーバ６Ｂに障害が発生している場合、隣接する他社SIPサーバ６Ａは、他社SIPサーバ６Ｂの障害を検知して、503エラーレスポンス（Service Unavailable）を隣接する他社NNI-GW５に送信する（Ｓ４１）。他社NNI-GW５は、503エラーレスポンスを受信すると、500エラーレスポンス（Server Internal Error）にインタワークして、隣接する自社NNI-GW１に送信する（Ｓ４２）。これにより、自社NNI-GW１の障害検知部１２は、他社網で障害が発生したと検知する（Ｓ４３）。

【0049】

本実施形態では、自社NNI-GW１の障害検知部１２は、Ｓ３８の18x受信タイマのタイムアウト、または、Ｓ４３の500エラーレスポンスの受信により、他社網での障害を検知する。

【0050】

障害検知部１２が他社網の障害を検知すると、自社NNI-GW１の障害箇所特定部１３は、他社網の障害箇所を特定する。具体的には、障害箇所特定部１３は、図３で説明したように、OPTIONSリクエストに含まれる最大転送数を示すMF値を、０から１ずつ増加させながら送信して、SIPトレースルートを実施し、障害箇所を特定する。また、障害箇所特定部１３は、OPTIONSリクエストの宛先（Request-URI）に、INVITEリクエスト（Ｓ３１、Ｓ３２等）で指定された電話番号を設定する。

【0051】

正常な他社網の各装置は、MF値が０になると483エラーレスポンスを送信する。そこで、障害箇所特定部１３は、OPTIONSリクエストを送信すると同時に483受信タイマを起動し、当該タイマのタイムアウトを監視する。障害箇所特定部１３は、483受信タイマが満了する前に483エラーレスポンスを受信することができない場合、すなわち、483エラーレスポンスを受信する前に483受信タイマがタイムアウトとなった場合、他社網の故障箇所が自分より何番目の階層か（何ホップ先か）を特定する。

【0052】

図示する例では、障害箇所特定部１３は、MF値に０を設定したOPTIONSリクエストを、他社網の他社NNI-GW５に送信するとともに、483受信タイマを起動する（Ｓ５１）。他社NNI-GW５は、受信したOPTIONSリクエストのMF値は０であるため、483エラーレスポンスを自社NNI-GW１に送信する（Ｓ５２）。

【0053】

そして、階層検出部１１は、MF値に１を設定したOPTIONSリクエストを、他社NNI-GW５に送信するとともに、483受信タイマを起動する（Ｓ５３）。他社NNI-GW５は、OPTIONSリクエストのMF値を１減算し、MF値０のOPTIONSリクエストを他社SIPサーバ６Ａに送信する（Ｓ５４）。他社SIPサーバ６Ａは、受信したOPTIONSリクエストのMF値は０であるため、483エラーレスポンスを自社NNI-GW１に送信する（Ｓ５５）。

【0054】

そして、階層検出部１１は、MF値に２を設定したOPTIONSリクエストを、他社網の他社NNI-GW５に送信するとともに、483受信タイマを起動する（Ｓ５６）。他社NNI-GW５は、OPTIONSリクエストのMF値を１減算し、MF値１のOPTIONSリクエストを他社SIPサーバ６Ａに送信する（Ｓ５７）。他社SIPサーバ６Ａは、OPTIONSリクエストのMF値を１減算し、MF値０のOPTIONSリクエストを他社SIPサーバ６Ｂに送信する（Ｓ５８）。

【0055】

ここで、他社ＳＩＰサーバ６Ｂで障害が発生しているため、他社SIPサーバ６Ｂは、MF値０のOPTIONSリクエストに対する483エラーレスポンスを送信することができない。これにより、障害箇所特定部１３は、483エラーレスポンスをＳ５６で起動した483受信タイマが満了する前に受信することができず、483受信タイマがタイムアウトとなる。

【0056】

これにより、障害箇所特定部１３は、他社網における故障箇所を特定する。すなわち、障害箇所特定部１３は、483受信タイマがタイムアウトとなったときのOPTIONSリクエストのMF値に１加算した値の階層（ホップ先）が、障害が発生した箇所であると特定する（Ｓ５９）。

【0057】

図４に示す例では、障害箇所特定部１３は、483受信タイマがタイムアウトとなったときのOPTIONSリクエストのMF値２に１加算した３階層目（他社SIPサーバ６Ｂ）が、障害箇所であると特定する。

【0058】

そして、自社NNI-GW１の判定部１４は、他社網の網コア装置に起因する障害であるのか、あるいは、ユーザ側装置またはユーザ端末８に起因する障害であるのか判定する。

【0059】

具体的には、判定部１４は、障害箇所特定部１３が特定した障害箇所の階層が、階層検出部１１が検出した他社網の階層数より小さい階層（浅い階層、自社NNI-GW1に近い階層）の場合は、他社網の網コア装置（他社NNI-GW５、他社SIPサーバ６Ａ、６Ｂ）に起因する障害と判定する。

【0060】

一方、判定部１４は、特定した障害箇所の階層が他社網の階層数と等しい場合、ユーザ側装置（他社HGW7）またはユーザ端末８に起因する障害であると判定する（Ｓ５９）。ユーザ側装置またはユーザ端末８に起因する障害と判定した場合、判定部１４は、障害の影響が限定的であり、また、現用の他社NNI-GW５とは別の他社NNI-GW５に切り替えても当該障害を回避することは難しいと判断する。このため、判定部１４は、障害回避に関する処理は行わない。

【0061】

他社網の網コア装置の障害と判定した場合、判定部１４は、障害の影響が大きく、現用の他社NNI-GW５を他の他社NNI-GW５に切り替えた場合、障害を回避できる可能性があると判断する。そのため、判定部１４は、障害箇所が特定された他社SIPサーバ６Ｂの経路に繋がる現用の他社NNI-GW５とは別の他社NNI-GWを経由したSIP信号の到達可能性を検査する。すなわち、別の他社NNI-GW５の経路での疎通確認に応じて、他社網の切替先の他社NNI-GW５（経路）を洗い出す。

【0062】

具体的には、判定部１４は、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５とが含まれる。

【0063】

そして、判定部１４は、いずれかの他の他社NNI-GW５の経路でOPTIONSリクエストに対する200 OKレスポンスを受信すると、他社NNI-GW５の切替で障害が回避できるケースであると判定し、当該他の他社NNI-GW５への経路切替を実施する。なお、経路切替には、同じPOIの他の他社NNI-GW５への経路切替と、異なるPOIの他の他社NNI-GW５への経路切替とがある。

【0064】

これにより、本実施形態では、他社網の網コア装置の障害と判定した場合に、切替先の経路を洗い出し、障害を回避することができる。また、本実施形態では、経路を切り替え前に、事前に、経路を切り替えることで障害が回避できるかを、OPTIONSリクエストを送信して疎通確認することで検証する。これにより、障害が回避できる場合にのみ、経路を切り替え、経路を切り替えても効果がない（障害が回避できない）場合に、経路を切り替えてしまう無駄な処理を回避することができる。

【0065】

以上説明した本実施形態では、最大転送数を含むリクエストを前記他社網に送信することで、前記他社網の階層の深さを示す階層数を検出し、前記他社網の障害を検知した場合、前記他社網に前記リクエストを送信することで、前記他社網の障害箇所の階層を特定し、前記障害箇所の階層が前記他社網の階層数より小さい階層の場合、前記他社網の網コア装置の障害と判定する。

【0066】

これにより、本実施形態では、他社網で障害が発生した場合、障害の影響範囲を大きいもので、障害を回避できる可能性があるケースか、あるいは、ユーザ端末障害などの障害の影響が限定的なもので、障害を回避できる可能性がないケースかを把握（区別）することができる。

【0067】

また、本願発明は、INVITEリクエストを他社網に送信する際に18x受信タイマを起動し、INVITEリクエストに対する暫定レスポンスを受信することなく、18x受信タイマがタイムアウトになった場合、他社網の障害を検知する。これにより、本実施形態では、18x受信タイマのタイマ値を短くすることで、他社網で発生した障害を迅速に検知することができる。

【0068】

従来、他社網の障害を検知するには、他社NNI-GW５とのTCPコネクションが切断されるか、INVITEタイムアウト（SIP Timer B:32秒）を待つしかない。しかしながら、他社NNI-GW５とTCPコネクションを張らない場合は、障害を検知することができない。また、隣接する他社NNI-GW５の先の装置で障害が発生している場合であっても、隣接する他社NNI-GW５からはINVITEリクエストに対する100tryingレスポンスが返答されるため、障害を検知することができない。また、隣接する他社NNI-GW５の先の装置での障害を検知するには、INVITEタイム満了（SIP Timer C:180秒）が考えらえるが、この場合、他社網での障害の検知が長時間化してしまい、その間に多数の呼損が生じる。

【0069】

これに対し、本実施形態では、NVITEリクエストを他社網に送信する際に、18x受信タイマを起動することで、他社網における障害検知が長期間化することを回避することができる。なお、18x受信タイマのタイマ値は、迅速な障害検知ができるように比較的、短い時間を設定する。

【0070】

また、本実施形態では、自社NNI-GW１の実装のみで実現できるため、他社網の装置の実装状況に依存せず、能動的に他社網の障害の原因を検知することができる。また、自社NNI-GW１内の実装であるため、開発が容易で、かつ、オペレータが介在することなく、他の他社NNI-GW５に切り替えることで障害を回避することができる。

【0071】

なお、本発明は上記実施形態に限定されるものではなく、その要旨の範囲内で数々の変形が可能である。

【符号の説明】

【0072】

１ ：自社NNI-GW
１１：階層検出部
１２：障害検知部
１３：障害箇所特定部
１４：判定部
１５：相互接続部
１６：記憶部
２ ：自社SIPサーバ
３ ：DNSサーバ
５ ：他社NNI-GW
６ ：他社SIPサーバ
７ ：他社HGW
８ ：ユーザ端末

【図1】

【図2】

【図3】

【図4】