交換システムおよび交換システムの障害復旧方法
【課題】管理サーバに遠隔回線収容装置毎に状態・内部状態を持たせ、状態・内部状態と受信イベントにより、実行する処理を決定することで、複数の回線収容装置が障害から復旧した場合も、短時間で全ての遠隔回線収容装置の組込処理を完了する交換システムを提供する。
【解決手段】ネットワークを介して接続された管理サーバと遠隔回線収容装置を有する交換システムにおいて、管理サーバは、遠隔回線収容装置に接続された端末の呼制御を行う呼処理手段と、遠隔回線収容装置の状態を保持するデータベースと、遠隔回線収容装置から事象情報を受信し、データベースに保持された状態にしたがって遠隔回線収容装置へ命
令情報を送信する装置管理手段とを有する。
【解決手段】ネットワークを介して接続された管理サーバと遠隔回線収容装置を有する交換システムにおいて、管理サーバは、遠隔回線収容装置に接続された端末の呼制御を行う呼処理手段と、遠隔回線収容装置の状態を保持するデータベースと、遠隔回線収容装置から事象情報を受信し、データベースに保持された状態にしたがって遠隔回線収容装置へ命
令情報を送信する装置管理手段とを有する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、交換システムの障害復旧方法に関するものであり、特に、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）−Ｃｅｎｔｒｅｘシステムにおける、ＩＰ端末以外の端末（アナログ電話、アナログ多機能電話、ＰＨＳ（Ｐｅｒｓｏｎａｌ Ｈａｎｄｙｐｈｏｎｅ Ｓｙｓｔｅｍ）基地局など）、局線（アナログ局線、ＩＳＤＮ（Ｉｎｔｅｇｒａｔｅｄ Ｓｅｒｖｉｃｅｓ Ｄｉｇｉｔａｌ Ｎｅｔｗｏｒｋ）局線など）を収容する遠隔回線収容装置を有する交換システムに適用して好適なものである。
【背景技術】
【０００２】
従来、ＰＢＸ（Ｐｒｉｖａｔｅ Ｂｒａｎｃｈ ｅＸｃｈａｎｇｅ）装置では、回線収容装置は制御部と直接ケーブルにて結線されており、制御部１つに対する回線収容装置の数も最大で８程度と多くないため、回線収容装置の障害復旧時の組込み処理は、１装置毎にシーケンシャルに組み込まれる。そのため、複数の回線収容装置が障害から復旧した場合、全ての装置が組み込まれるまで時間がかかり、組込みできない装置がある場合は、組込みのタイムアウトまで待つことになるので、復旧にはさらに時間がかかっていた。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０００−３５８０９８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
従来拠点毎に設置していたＰＢＸを一ヶ所、１システムに集約して管理・運営するＩＰ−Ｃｅｎｔｒｅｘシステムにおいては、回線収容装置はＩＰネットワークによって遠隔地に収容されており、その収容数も大きくなる（〜２５５台）。そのため、ネットワーク障害、装置未実装といったことが原因で、回線収容装置が組み込み不可能となっている確率も従来のＰＢＸ装置に比べて高く、ネットワーク障害が発生した場合には、全回線収容装置が障害となる場合もある。ネットワーク障害が復旧したときには、全回線収容装置の復旧処理が動作するが、従来のＰＢＸ装置と同様な回線収容装置の組み込み方式では、全装置の復旧には多くの時間が必要となる。
【０００５】
本発明は、以上の点を鑑みて、管理サーバに遠隔回線収容装置毎に状態・内部状態を持たせ、状態・内部状態と受信イベントにより、実行する処理を決定することで、複数の遠隔回線収容装置を独立して、並列に組み込み処理をおこなうことができるものである。
【課題を解決するための手段】
【０００６】
かかる課題を解決するため、本発明は、ネットワークを介して接続された管理サーバと遠隔回線収容装置を有する交換システムの障害復旧方法において、ネットワーク障害が復旧した場合、遠隔回線収容装置から管理サーバに復旧事象が送信され、復旧情報を受信した管理サーバでは、状態を障害から組込中へ、内部状態を復旧事象受信へそれぞれ移行し、遠隔回線収容装置へリセット命令を送信し、リセット命令を受信した遠隔回線収容装置では、リセット処理を行い、管理サーバへリセット応答事象を送信し、リセット応答事象を受信した管理サーバでは、遠隔回線収容装置再開要求命令を送信し、状態を組込中に、内部状態を再開要求応答命令受信待ちにそれぞれ移行し、再開要求命令を受信した前記遠隔回線収容装置では、再開処理を実行し、管理サーバは再開要求応答命令を送信し、再開要求応答命令を受信した管理サーバでは、状態を正常に移行するものである。
【０００７】
また、本発明は、ネットワークを介して接続された管理サーバと遠隔回線収容装置を有する交換システムの障害復旧方法において、管理サーバでは受信した事象が復旧事象の場合は、状態が障害であれば状態を組込中に、内部状態をリセット応答事象待ちにそれぞれ変更し、リセット命令を遠隔回線収容装置に送信し、受信した事象がリセット応答事象の場合は、状態が組込中で内部状態がリセット応答事象待ちであれば状態を組込中に、内部状態を再開要求応答事象待ちにそれぞれ変更し、再開要求命令を遠隔回線収容装置に送信し、受信した事象が再開要求応答事象の場合は、状態が組込中で内部状態が再開要求応答事象待ちであれば状態を正常に変更し、管理サーバへ復旧を伝えるものである。
【発明の効果】
【０００８】
本発明によれば、管理サーバに遠隔回線収容装置毎に状態・内部状態を持たせ、状態・内部状態と受信イベントにより、実行する処理を決定することで、複数の回線収容装置が障害から復旧した場合も、短時間で全ての遠隔回線収容装置の組込処理を完了することができる。
【図面の簡単な説明】
【０００９】
【図１】実施形態の交換スシステムの構成を示すブロック図である。
【図２】実施形態の交換スシステムの管理サーバの詳細構成を示すブロック図である。
【図３】実施形態の交換システムの遠隔回線収容装置の障害からの復旧手順を示すシーケンス図である。
【図４】実施形態の交換システムの管理サーバのイベント受信時の処理手順を示すフローチャートである。
【図５】実施形態の交換システムの管理サーバ保持する状態の種別を示す表である。
【図６】実施形態の交換システムの管理サーバ保持する内部状態の種別を示す表である。
【発明を実施するための最良の形態】
【００１０】
以下、本発明による遠隔回線収容装置の障害復旧方法の実施形態を図面を参照しながら説明する。
【００１１】
（１）実施形態の構成
図1は本発明の第１の実施形態のネットワーク構成を示す図である。ＩＰ−Ｃｅｎｔｒｅｘシステムは、呼制御および端末制御を行うメインサーバ１０と、ＩＰネットワークを介して収容されるＩＰ電話端末(ハードフォン、ソフトフォン等)３２−１〜３２−ｎ（ｎは２以上の整数）、ＩＰ電話端末(ハードフォン、ソフトフォン等)４２−１〜４２−ｎ（ｎは２以上の整数）、図示しないＩＰ端末以外の端末（アナログ電話、アナログ多機能電話、ＰＨＳ基地局など）および図示しない局線（アナログ局線、ＩＳＤＮ局線）を収容する遠隔回線収容装置３１および４１を有している。
【００１２】
メインサーバ１０は、ＩＰ−Ｃｅｎｔｒｅｘセンタ１に設置され、ＩＰ電話端末３２−１〜３２−ｎおよび４２−１〜４２−ｎ、遠隔回線収容装置３１および４１は、拠点３および４にそれぞれ設置される。なお、本実施形態では拠点が２つ（拠点３、４）の例を示したが、拠点の数はこれに限るものではなく、複数（〜２５５）収容が可能である。
【００１３】
図２はメインサーバ１０の機能ブロック図である。メインサーバ１０は、呼処理機能１１０、装置管理機能１３０、データベース１２０等を有している。装置管理機能１３０は、遠隔回線収容装置からのイベントメッセージを受信するイベント受付部１３１、遠隔回線収容装置へオーダメッセージを送信するオーダ送信部１３２を有する。
【００１４】
データベース１２０は、個々の遠隔回線収容装置の状態テーブルを有する。状態の種類は図５に示す通り、「未登録」はデータ登録されていない状態、「正常」は正常に組み込まれている状態、「切離」はデータ登録されているが切り離されている状態、「障害」は障害中状態、「組込中」は障害または切離状態から復旧中の状態をそれぞれ示す。また、「組込中」状態にはさらに図６に示す通り内部状態があり、「復旧イベント受信」は復旧イベントを受信した状態、「リセット応答イベント受信待ち」はリセットオーダを受信してその応答待ちの状態、「再開要求応答イベント受信待ち」は再開要求オーダを受信してその応答待ちの状態をそれぞれ示す。
【００１５】
（２）実施形態の動作
以下、実施形態の遠隔回線収容装置の障害復旧方法の動作を、図３および図４を用いて説明する。
【００１６】
図３は、遠隔回線収容装置３１および４１の障害からの復旧シーケンスを示す。ネットワーク障害などの要因で遠隔回線収容装置３１および４１が障害となり、ネットワークの障害が復旧した場合、遠隔回線収容装置３１および４１から、ＴＣＰコネクションのオープンが行われ、メインサーバ１０の装置管理機能１３０へ復旧イベントが送信される。装置管理機能１３０では復旧イベントを受信すると、［状態：障害］状態から［状態：組込中、内部状態：復旧イベント受信］状態へと状態を移行し、遠隔回線収容装置３１および４１へリセットオーダを送信する。オーダを送信すると状態を［状態：組込中、内部状態
：リセット応答イベント受信待ち］へ移行する。遠隔回線収容装置３１および４１ではリセットオーダを受信するとリセット処理を実行し、メインサーバ１０へリセット応答イベントを送信する。メインサーバ１０でリセット応答イベントを受信すると、遠隔回線収容装置３１および４１へ再開要求オーダを送信し、状態を［状態：組込中、内部状態：再開要求応答イベント受信待ち］へ移行する。遠隔回線収容装置３１および４１では再開要求オーダを受信すると再開処理を実行し、メインサーバ１０へ再開要求応答イベントを送信する。メインサーバ１０で再開要求応答イベントを受信すると、状態を［状態：正常］へ
移行し、呼処理機能へ回復通知を送信し、組込み処理が完了となる。メインサーバ１０でのイベント受信時の処理は、受信したイベントの種類と、対応する遠隔回線収容装置３１および４１の状態・内部状態により決定される。状態・内部状態は個々の遠隔回線収容装置３１および４１それぞれに具備しているため、個々の遠隔回線収容装置への処理は独立して並列に行うことができる。
【００１７】
次に、図４を用いてイベント受信時の処理手順を説明する。
イベント待ちの状態（Ｓ１）からイベントを受信した場合（Ｓ３）、イベントの種別を判別する（Ｓ４）。イベント種別が「復旧イベント」の場合は、状態を判別し（Ｓ５）、状態が「障害」の場合は、状態を「組込中」とし、内部状態を「リセット応答イベント待ち」へ変更する（Ｓ８）。変更後はリセットオーダを送信する（Ｓ１１）。
【００１８】
イベント種別が「リセット応答イベント」の場合は、状態を判別し（Ｓ６）、状態が「組込中」で内部状態が「再開要求応答イベント待ち」の場合は、状態を「組込中」のままとし、内部状態を「再開要求応答イベント待ち」へ変更する（Ｓ９）。変更後は、再開要求オーダを送信する（Ｓ１２）。
【００１９】
イベントの種別が「再開要求応答イベント」の場合は、状態を判別し（Ｓ７）、状態が「組込中」で内部状態が「再開要求応答イベント待ち」の場合は、状態を「正常」に変更する（Ｓ１０）。変更後は、呼制御機能へ復旧する（Ｓ１３）。
【００２０】
（３）実施形態の効果
以上説明した実施形態によれば、管理サーバに遠隔回線収容装置毎に状態・内部状態を持たせ、状態・内部状態と受信イベントにより、実行する処理を決定することで、複数の遠隔回線収容装置を独立して、並列に組み込み処理を行うことができる。また、個々の遠隔回線収容装置の処理が独立しているため、1つの装置の処理によって他の装置が影響を受けることもない。そのため、ＩＰ−Ｃｅｎｔｒｅｘシステムのように多数の遠隔回線収容装置をＩＰネットワークを介して収容しているシステムとの親和性が良い。
【符号の説明】
【００２１】
１…ＩＰ−ｃｅｎｒｅｘセンタ、２…ＩＰネットワーク、３／４…拠点、１０…メイン
サーバ、３１、４１…遠隔回線収容装置、３２−１〜３２−ｎ／４２−１〜４２−ｎ…Ｉ
Ｐ電話端末。
【技術分野】
【０００１】
本発明は、交換システムの障害復旧方法に関するものであり、特に、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）−Ｃｅｎｔｒｅｘシステムにおける、ＩＰ端末以外の端末（アナログ電話、アナログ多機能電話、ＰＨＳ（Ｐｅｒｓｏｎａｌ Ｈａｎｄｙｐｈｏｎｅ Ｓｙｓｔｅｍ）基地局など）、局線（アナログ局線、ＩＳＤＮ（Ｉｎｔｅｇｒａｔｅｄ Ｓｅｒｖｉｃｅｓ Ｄｉｇｉｔａｌ Ｎｅｔｗｏｒｋ）局線など）を収容する遠隔回線収容装置を有する交換システムに適用して好適なものである。
【背景技術】
【０００２】
従来、ＰＢＸ（Ｐｒｉｖａｔｅ Ｂｒａｎｃｈ ｅＸｃｈａｎｇｅ）装置では、回線収容装置は制御部と直接ケーブルにて結線されており、制御部１つに対する回線収容装置の数も最大で８程度と多くないため、回線収容装置の障害復旧時の組込み処理は、１装置毎にシーケンシャルに組み込まれる。そのため、複数の回線収容装置が障害から復旧した場合、全ての装置が組み込まれるまで時間がかかり、組込みできない装置がある場合は、組込みのタイムアウトまで待つことになるので、復旧にはさらに時間がかかっていた。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０００−３５８０９８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
従来拠点毎に設置していたＰＢＸを一ヶ所、１システムに集約して管理・運営するＩＰ−Ｃｅｎｔｒｅｘシステムにおいては、回線収容装置はＩＰネットワークによって遠隔地に収容されており、その収容数も大きくなる（〜２５５台）。そのため、ネットワーク障害、装置未実装といったことが原因で、回線収容装置が組み込み不可能となっている確率も従来のＰＢＸ装置に比べて高く、ネットワーク障害が発生した場合には、全回線収容装置が障害となる場合もある。ネットワーク障害が復旧したときには、全回線収容装置の復旧処理が動作するが、従来のＰＢＸ装置と同様な回線収容装置の組み込み方式では、全装置の復旧には多くの時間が必要となる。
【０００５】
本発明は、以上の点を鑑みて、管理サーバに遠隔回線収容装置毎に状態・内部状態を持たせ、状態・内部状態と受信イベントにより、実行する処理を決定することで、複数の遠隔回線収容装置を独立して、並列に組み込み処理をおこなうことができるものである。
【課題を解決するための手段】
【０００６】
かかる課題を解決するため、本発明は、ネットワークを介して接続された管理サーバと遠隔回線収容装置を有する交換システムの障害復旧方法において、ネットワーク障害が復旧した場合、遠隔回線収容装置から管理サーバに復旧事象が送信され、復旧情報を受信した管理サーバでは、状態を障害から組込中へ、内部状態を復旧事象受信へそれぞれ移行し、遠隔回線収容装置へリセット命令を送信し、リセット命令を受信した遠隔回線収容装置では、リセット処理を行い、管理サーバへリセット応答事象を送信し、リセット応答事象を受信した管理サーバでは、遠隔回線収容装置再開要求命令を送信し、状態を組込中に、内部状態を再開要求応答命令受信待ちにそれぞれ移行し、再開要求命令を受信した前記遠隔回線収容装置では、再開処理を実行し、管理サーバは再開要求応答命令を送信し、再開要求応答命令を受信した管理サーバでは、状態を正常に移行するものである。
【０００７】
また、本発明は、ネットワークを介して接続された管理サーバと遠隔回線収容装置を有する交換システムの障害復旧方法において、管理サーバでは受信した事象が復旧事象の場合は、状態が障害であれば状態を組込中に、内部状態をリセット応答事象待ちにそれぞれ変更し、リセット命令を遠隔回線収容装置に送信し、受信した事象がリセット応答事象の場合は、状態が組込中で内部状態がリセット応答事象待ちであれば状態を組込中に、内部状態を再開要求応答事象待ちにそれぞれ変更し、再開要求命令を遠隔回線収容装置に送信し、受信した事象が再開要求応答事象の場合は、状態が組込中で内部状態が再開要求応答事象待ちであれば状態を正常に変更し、管理サーバへ復旧を伝えるものである。
【発明の効果】
【０００８】
本発明によれば、管理サーバに遠隔回線収容装置毎に状態・内部状態を持たせ、状態・内部状態と受信イベントにより、実行する処理を決定することで、複数の回線収容装置が障害から復旧した場合も、短時間で全ての遠隔回線収容装置の組込処理を完了することができる。
【図面の簡単な説明】
【０００９】
【図１】実施形態の交換スシステムの構成を示すブロック図である。
【図２】実施形態の交換スシステムの管理サーバの詳細構成を示すブロック図である。
【図３】実施形態の交換システムの遠隔回線収容装置の障害からの復旧手順を示すシーケンス図である。
【図４】実施形態の交換システムの管理サーバのイベント受信時の処理手順を示すフローチャートである。
【図５】実施形態の交換システムの管理サーバ保持する状態の種別を示す表である。
【図６】実施形態の交換システムの管理サーバ保持する内部状態の種別を示す表である。
【発明を実施するための最良の形態】
【００１０】
以下、本発明による遠隔回線収容装置の障害復旧方法の実施形態を図面を参照しながら説明する。
【００１１】
（１）実施形態の構成
図1は本発明の第１の実施形態のネットワーク構成を示す図である。ＩＰ−Ｃｅｎｔｒｅｘシステムは、呼制御および端末制御を行うメインサーバ１０と、ＩＰネットワークを介して収容されるＩＰ電話端末(ハードフォン、ソフトフォン等)３２−１〜３２−ｎ（ｎは２以上の整数）、ＩＰ電話端末(ハードフォン、ソフトフォン等)４２−１〜４２−ｎ（ｎは２以上の整数）、図示しないＩＰ端末以外の端末（アナログ電話、アナログ多機能電話、ＰＨＳ基地局など）および図示しない局線（アナログ局線、ＩＳＤＮ局線）を収容する遠隔回線収容装置３１および４１を有している。
【００１２】
メインサーバ１０は、ＩＰ−Ｃｅｎｔｒｅｘセンタ１に設置され、ＩＰ電話端末３２−１〜３２−ｎおよび４２−１〜４２−ｎ、遠隔回線収容装置３１および４１は、拠点３および４にそれぞれ設置される。なお、本実施形態では拠点が２つ（拠点３、４）の例を示したが、拠点の数はこれに限るものではなく、複数（〜２５５）収容が可能である。
【００１３】
図２はメインサーバ１０の機能ブロック図である。メインサーバ１０は、呼処理機能１１０、装置管理機能１３０、データベース１２０等を有している。装置管理機能１３０は、遠隔回線収容装置からのイベントメッセージを受信するイベント受付部１３１、遠隔回線収容装置へオーダメッセージを送信するオーダ送信部１３２を有する。
【００１４】
データベース１２０は、個々の遠隔回線収容装置の状態テーブルを有する。状態の種類は図５に示す通り、「未登録」はデータ登録されていない状態、「正常」は正常に組み込まれている状態、「切離」はデータ登録されているが切り離されている状態、「障害」は障害中状態、「組込中」は障害または切離状態から復旧中の状態をそれぞれ示す。また、「組込中」状態にはさらに図６に示す通り内部状態があり、「復旧イベント受信」は復旧イベントを受信した状態、「リセット応答イベント受信待ち」はリセットオーダを受信してその応答待ちの状態、「再開要求応答イベント受信待ち」は再開要求オーダを受信してその応答待ちの状態をそれぞれ示す。
【００１５】
（２）実施形態の動作
以下、実施形態の遠隔回線収容装置の障害復旧方法の動作を、図３および図４を用いて説明する。
【００１６】
図３は、遠隔回線収容装置３１および４１の障害からの復旧シーケンスを示す。ネットワーク障害などの要因で遠隔回線収容装置３１および４１が障害となり、ネットワークの障害が復旧した場合、遠隔回線収容装置３１および４１から、ＴＣＰコネクションのオープンが行われ、メインサーバ１０の装置管理機能１３０へ復旧イベントが送信される。装置管理機能１３０では復旧イベントを受信すると、［状態：障害］状態から［状態：組込中、内部状態：復旧イベント受信］状態へと状態を移行し、遠隔回線収容装置３１および４１へリセットオーダを送信する。オーダを送信すると状態を［状態：組込中、内部状態
：リセット応答イベント受信待ち］へ移行する。遠隔回線収容装置３１および４１ではリセットオーダを受信するとリセット処理を実行し、メインサーバ１０へリセット応答イベントを送信する。メインサーバ１０でリセット応答イベントを受信すると、遠隔回線収容装置３１および４１へ再開要求オーダを送信し、状態を［状態：組込中、内部状態：再開要求応答イベント受信待ち］へ移行する。遠隔回線収容装置３１および４１では再開要求オーダを受信すると再開処理を実行し、メインサーバ１０へ再開要求応答イベントを送信する。メインサーバ１０で再開要求応答イベントを受信すると、状態を［状態：正常］へ
移行し、呼処理機能へ回復通知を送信し、組込み処理が完了となる。メインサーバ１０でのイベント受信時の処理は、受信したイベントの種類と、対応する遠隔回線収容装置３１および４１の状態・内部状態により決定される。状態・内部状態は個々の遠隔回線収容装置３１および４１それぞれに具備しているため、個々の遠隔回線収容装置への処理は独立して並列に行うことができる。
【００１７】
次に、図４を用いてイベント受信時の処理手順を説明する。
イベント待ちの状態（Ｓ１）からイベントを受信した場合（Ｓ３）、イベントの種別を判別する（Ｓ４）。イベント種別が「復旧イベント」の場合は、状態を判別し（Ｓ５）、状態が「障害」の場合は、状態を「組込中」とし、内部状態を「リセット応答イベント待ち」へ変更する（Ｓ８）。変更後はリセットオーダを送信する（Ｓ１１）。
【００１８】
イベント種別が「リセット応答イベント」の場合は、状態を判別し（Ｓ６）、状態が「組込中」で内部状態が「再開要求応答イベント待ち」の場合は、状態を「組込中」のままとし、内部状態を「再開要求応答イベント待ち」へ変更する（Ｓ９）。変更後は、再開要求オーダを送信する（Ｓ１２）。
【００１９】
イベントの種別が「再開要求応答イベント」の場合は、状態を判別し（Ｓ７）、状態が「組込中」で内部状態が「再開要求応答イベント待ち」の場合は、状態を「正常」に変更する（Ｓ１０）。変更後は、呼制御機能へ復旧する（Ｓ１３）。
【００２０】
（３）実施形態の効果
以上説明した実施形態によれば、管理サーバに遠隔回線収容装置毎に状態・内部状態を持たせ、状態・内部状態と受信イベントにより、実行する処理を決定することで、複数の遠隔回線収容装置を独立して、並列に組み込み処理を行うことができる。また、個々の遠隔回線収容装置の処理が独立しているため、1つの装置の処理によって他の装置が影響を受けることもない。そのため、ＩＰ−Ｃｅｎｔｒｅｘシステムのように多数の遠隔回線収容装置をＩＰネットワークを介して収容しているシステムとの親和性が良い。
【符号の説明】
【００２１】
１…ＩＰ−ｃｅｎｒｅｘセンタ、２…ＩＰネットワーク、３／４…拠点、１０…メイン
サーバ、３１、４１…遠隔回線収容装置、３２−１〜３２−ｎ／４２−１〜４２−ｎ…Ｉ
Ｐ電話端末。
【特許請求の範囲】
【請求項１】
ネットワークを介して接続された管理サーバと遠隔回線収容装置を有する交換システムの障害復旧方法において、
ネットワーク障害が復旧した場合、前記遠隔回線収容装置から前記管理サーバに復旧事象が送信され、
前記復旧情報を受信した前記管理サーバでは、状態を障害から組込中へ、内部状態を復旧事象受信へそれぞれ移行し、前記遠隔回線収容装置へリセット命令を送信し、
前記リセット命令を受信した前記遠隔回線収容装置では、リセット処理を行い、前記管理サーバへリセット応答事象を送信し、
前記リセット応答事象を受信した前記管理サーバでは、前記遠隔回線収容装置再開要求命令を送信し、状態を組込中に、内部状態を再開要求応答命令受信待ちにそれぞれ移行し、
前記再開要求命令を受信した前記遠隔回線収容装置では、再開処理を実行し、前記管理サーバは前記再開要求応答命令を送信し、
前記再開要求応答命令を受信した前記管理サーバでは、状態を正常に移行することを特徴とする交換システムの障害復旧方法。
【請求項２】
ネットワークを介して接続された管理サーバと遠隔回線収容装置を有する交換システムの障害復旧方法において、
前記管理サーバでは、
受信した事象が復旧事象の場合は、状態が障害であれば状態を組込中に、内部状態をリセット応答事象待ちにそれぞれ変更し、リセット命令を前記遠隔回線収容装置に送信し、
受信した事象がリセット応答事象の場合は、状態が組込中で内部状態がリセット応答事象待ちであれば状態を組込中に、内部状態を再開要求応答事象待ちにそれぞれ変更し、再開要求命令を前記遠隔回線収容装置に送信し、
受信した事象が再開要求応答事象の場合は、状態が組込中で内部状態が再開要求応答事象待ちであれば状態を正常に変更し、前記管理サーバへ復旧を伝えることを特徴とする交換システムの障害復旧方法。
【請求項１】
ネットワークを介して接続された管理サーバと遠隔回線収容装置を有する交換システムの障害復旧方法において、
ネットワーク障害が復旧した場合、前記遠隔回線収容装置から前記管理サーバに復旧事象が送信され、
前記復旧情報を受信した前記管理サーバでは、状態を障害から組込中へ、内部状態を復旧事象受信へそれぞれ移行し、前記遠隔回線収容装置へリセット命令を送信し、
前記リセット命令を受信した前記遠隔回線収容装置では、リセット処理を行い、前記管理サーバへリセット応答事象を送信し、
前記リセット応答事象を受信した前記管理サーバでは、前記遠隔回線収容装置再開要求命令を送信し、状態を組込中に、内部状態を再開要求応答命令受信待ちにそれぞれ移行し、
前記再開要求命令を受信した前記遠隔回線収容装置では、再開処理を実行し、前記管理サーバは前記再開要求応答命令を送信し、
前記再開要求応答命令を受信した前記管理サーバでは、状態を正常に移行することを特徴とする交換システムの障害復旧方法。
【請求項２】
ネットワークを介して接続された管理サーバと遠隔回線収容装置を有する交換システムの障害復旧方法において、
前記管理サーバでは、
受信した事象が復旧事象の場合は、状態が障害であれば状態を組込中に、内部状態をリセット応答事象待ちにそれぞれ変更し、リセット命令を前記遠隔回線収容装置に送信し、
受信した事象がリセット応答事象の場合は、状態が組込中で内部状態がリセット応答事象待ちであれば状態を組込中に、内部状態を再開要求応答事象待ちにそれぞれ変更し、再開要求命令を前記遠隔回線収容装置に送信し、
受信した事象が再開要求応答事象の場合は、状態が組込中で内部状態が再開要求応答事象待ちであれば状態を正常に変更し、前記管理サーバへ復旧を伝えることを特徴とする交換システムの障害復旧方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図２】
【図３】
【図４】
【図５】
【図６】
【公開番号】特開２０１１−４５１２４（Ｐ２０１１−４５１２４Ａ）
【公開日】平成２３年３月３日（２０１１．３．３）
【国際特許分類】
【出願番号】特願２０１０−２３２０２１（Ｐ２０１０−２３２０２１）
【出願日】平成２２年１０月１４日（２０１０．１０．１４）
【分割の表示】特願２００５−２９８８２０（Ｐ２００５−２９８８２０）の分割
【原出願日】平成１７年１０月１３日（２００５．１０．１３）
【出願人】（００００００２９５）沖電気工業株式会社 (6,645)
【Ｆターム（参考）】
【公開日】平成２３年３月３日（２０１１．３．３）
【国際特許分類】
【出願日】平成２２年１０月１４日（２０１０．１０．１４）
【分割の表示】特願２００５−２９８８２０（Ｐ２００５−２９８８２０）の分割
【原出願日】平成１７年１０月１３日（２００５．１０．１３）
【出願人】（００００００２９５）沖電気工業株式会社 (6,645)
【Ｆターム（参考）】
[ Back to top ]