(57)【要約】【課題】監視のためのハードウェアとIPアドレスの数を削減する。【解決手段】監視対象装置を監視する制御装置は、アクティブ状態の第１の制御部と、監視対象装置を死活監視する、スタンバイ状態の第１の死活監視部とを含む運用系サーバ、スタンバイ状態の第２の制御部と、監視対象装置を死活監視する、アクティブ状態の第２の死活監視部とを含む待機系サーバ、及び、監視対象装置と第１通信ネットワークを介して接続し、各サーバと第２通信ネットワークを介して接続し、第２の死活監視部からの監視対象装置に向けたパケットの、第２通信ネットワークにおける第２の送信元アドレスを第１通信ネットワークにおける第１の送信元アドレスに変換して監視対象装置に送信し、監視対象装置からの、応答パケットの送信先アドレスを第２の送信元アドレスに変換して待機系サーバに送信するパケット振り分け装置とを有する。【選択図】図１
2011010187.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーションを実行する監視対象の装置、並びに、
アクティブ状態の第１の制御部と、前記装置をアプリケーションレベルで死活監視する、スタンバイ状態の第１の死活監視部とを含む第１のサーバ、
スタンバイ状態の第２の制御部と、前記装置をアプリケーションレベルで死活監視する、アクティブ状態の第２の死活監視部とを含む第２のサーバ、及び、
前記装置と第１の通信ネットワークを介して接続し、
前記第１のサーバ及び前記第２のサーバと第２の通信ネットワークを介して接続し、前記第２のサーバの前記第２の死活監視部からの前記装置に向けた第１のパケットの、前記第２の通信ネットワークにおける第２の送信元アドレスを前記第１の通信ネットワークにおける第１の送信元アドレスに変換して前記装置に送信し、前記装置からの、前記第１のパケットに対応する応答パケットの送信先アドレスを前記第２の送信元アドレスに変換して前記第２のサーバに送信するパケット振り分け装置とを有する制御装置を設けたことを特徴とする通信ネットワークシステム。
【請求項２】
前記パケット振り分け装置は、前記第１のパケットの受信に応答して、前記第２の送信元アドレスを格納するIDテーブルを有し、
前記第１の通信ネットワークを介して受信する、前記応答パケットを含む第２のパケットの送信先アドレスが、前記第２の送信元アドレスとして前記IDテーブルに格納されているか否かに応じて、前記第２のパケットを前記第１のサーバ及び前記第２のサーバとのいずれか一方に選択的に送信することを特徴とする請求項１記載の通信ネットワークシステム。
【請求項３】
前記第１のサーバの前記第１の制御部のアクティブ状態からスタンバイ状態への遷移に応答して、
前記第２のサーバは、前記第２の制御部をスタンバイ状態からアクティブ状態へ遷移させ、前記第２の死活監視部をアクティブ状態からスタンバイ状態へ遷移させ、
前記第１のサーバは、前記第１の死活監視部をスタンバイ状態からアクティブ状態へ遷移させることを特徴とする請求項２記載の通信ネットワークシステム。
【請求項４】
前記第２のサーバは、前記第２の死活監視部をアクティブ状態からスタンバイ状態への遷移に伴い、前記第２の死活監視部が前記装置をアプリケーションレベルで死活監視した結果である監視データを前記第１のサーバへ転送することを特徴とする請求項３記載の通信ネットワークシステム。
【請求項５】
前記第１の死活監視部及び前記第２の死活監視部の状態遷移に伴い、前記IDテーブルに格納されている前記第２の送信元アドレスを、前記第１のサーバの前記第２の通信ネットワークにおけるアドレスに更新することを特徴とする請求項４記載の通信ネットワークシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信システムネットワークに関し、さらに詳しくは冗長化された装置により、上位プロトコルを用いてアプリケーションの死活監視を行う通信ネットワークシステムに関する。
【背景技術】
【０００２】
常時サービスを提供するシステムにおいては、高い信頼性が求められており、さまざまな保守装置が存在する。保守装置の一種である死活監視装置とは、通信システムネットワーク内において、常時稼働する各装置の動作状況を監視する装置である。基本的動作は、監視対象に信号を送り、その応答を受け取ることで、監視対象の死活を確認する、というものである。また、何らかの異常（監視対象がダウンしている、ネットワーク障害で信号が届かない等）があり、応答を受け取れなかい場合には、システム保守者に通知する。
【０００３】
IPネットワークに接続された機器の死活監視を行うために、Ping応答が活用される(例えば特許文献1参照)。
【０００４】
Ping応答はInternet Control Message Protocol（ICMP）において使用されるエコー要求及びエコー応答を利用したIPネットワークにおける疎通確認方法に用いられる。Ping応答を用いる利点としては、汎用性の高さが挙げられる。IPネットワークで構成されたシステム内では、ほとんどの装置はOSIモデルで言うネットワーク層のプロトコルICMPに対応しているため、監視対象に特別な設定をすることなく、Ping応答により、装置を監視でき、ネットワーク疎通の確認もできる。
【０００５】
また、常時サービスを提供するシステムにおいて信頼性を向上させるために、システム内の重要な装置を冗長構成にすることも、頻繁に行われる手段である（例えば特許文献２）。非同期冗長構成を有する装置は、運用系サーバと待機系サーバが1台：1台の冗長構成（1+1冗長構成）、またはN台：1台の冗長構成（N+1冗長構成）を対象とし、運用系サーバは主機能がActive状態（ACT）にあるサーバを指し、待機系サーバは主機能がStandby状態(SBY)にあるサーバを指す。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開2007-336221号公報
【特許文献２】特開平8-186619号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
近年ではアプリケーションレベルまでの監視が可能な、死活監視が求められている。しかしながら、Ping応答による死活監視では、装置の稼働状況は確認できても、その装置上のアプリケーションの稼働状況を確認できない。
【０００８】
アプリケーションレベルでの死活監視には、Ping応答のような汎用的な方法を使用できないため、システムの使用するアプリケーションごとに、死活監視用のアプリケーションを構築する必要がある。結果として、死活監視専用の装置を、システム内に設置することがしばしばありうる。
【０００９】
また、非同期の冗長構成化された装置においては、運用系サーバに障害が発生しない限り、待機系サーバは使用されず、ハードウェアリソースを効果的に活用できていないという問題点があった。
【００１０】
本発明は、前記のような問題点を解消するためになされたものであって、冗長構成化された装置の機能を損なうことなく、ハードウェアリソース及び外部IPアドレスの数の削減を図ることができる通信ネットワークシステムを得ることを目的とする。
【課題を解決するための手段】
【００１１】
本発明の通信ネットワークシステムは、アプリケーションを実行する監視対象装置、並びに、アクティブ状態の第１の制御部と、監視対象装置をアプリケーションレベルで死活監視する、スタンバイ状態の第１の死活監視部とを含む第１のサーバ（運用系サーバ）、スタンバイ状態の第２の制御部と、監視対象装置をアプリケーションレベルで死活監視する、アクティブ状態の第２の死活監視部とを含む第２のサーバ(待機系サーバ)、及び、監視対象装置と第１の通信ネットワークを介して接続し、第１のサーバ及び第２のサーバと第２の通信ネットワークを介して接続し、第２のサーバの第２の死活監視部からの監視対象装置に向けた第１のパケットの、第２の通信ネットワークにおける第２の送信元アドレスを第１の通信ネットワークにおける第１の送信元アドレスに変換して監視対象装置に送信し、監視対象装置からの、第１のパケットに対応する応答パケットの送信先アドレスを第２の送信元アドレスに変換して第２のサーバに送信するパケット振り分け装置とを有する制御装置を設ける。
【００１２】
本発明の望ましい他の態様は、パケット振り分け装置は、第１のパケットの受信に応答して、第２の送信元アドレスを格納するIDテーブルを有し、第１の通信ネットワークを介して受信する、応答パケットを含む第２のパケットの送信先アドレスが、第２の送信元アドレスとしてIDテーブルに格納されているか否かに応じて、第２のパケットを第１のサーバ及び第２のサーバとのいずれか一方に選択的に送信する。
【００１３】
本発明の望ましいさらに他の態様は、第１のサーバの第１の制御部のアクティブ状態からスタンバイ状態への遷移に応答して、第２のサーバは、第２の制御部をスタンバイ状態からアクティブ状態へ遷移させ、第２の死活監視部をアクティブ状態からスタンバイ状態へ遷移させ、第１のサーバは、第１の死活監視部をスタンバイ状態からアクティブ状態へ遷移させる。
【発明の効果】
【００１４】
本発明によれば、死活監視を待機系サーバに実行させることにより、従来専用の死活監視装置として用いたコンピュータが不要になる。また、死活監視装置に付与されていたIPアドレスを、待機系サーバのIPアドレスと共用することで、用いるIPアドレスの数を削減できる。
【図面の簡単な説明】
【００１５】
【図１】通信ネットワークシステムの1例である。
【図２】基地局制御装置の構成例である。
【図３】パケット振り分け装置の構成例である。
【図４】運用系サーバの構成例である。
【図５】待機系サーバの構成例である。
【図６】課金・認証サーバの構成例である。
【図７】ホームエージェントの構成例である。
【図８】保守センタの構成例である。
【図９】死活監視するシーケンス図である。
【図１０】死活監視において応答メッセージを受信しない場合のシーケンス図である。
【図１１】監視テーブルの構成例である。
【図１２】IDテーブルの構成例である。
【図１３】パケット振り分け処理のフローチャートである。
【図１４】冗長切り替え動作のシーケンス図である。
【図１５】冗長切り替えに伴う、メッセージの処理シーケンス図である。
【発明を実施するための形態】
【００１６】
図１は、通信ネットワークシステムの1例である。通信ネットワークシステムは、無線基地局20、基地局制御装置30、課金・認証サーバ40、コア網70に接続するホームエージェント50、及び基地局20と基地局制御装置30を保守する保守センタ60を有する。
【００１７】
基地局20は、無線送信電力に応じた無線通信エリア（セル）を形成し、無線通信エリア内に位置した無線端末10と無線で通信する。
【００１８】
認証・課金サーバ40は、基地局制御装置30に接続され、無線端末10がコア網70との通信を確立する際に、基地局制御装置30を介して無線端末10の認証を行う。
【００１９】
ホームエージェント50は、たとえばインターネットや公衆通信網などのコア網70に接続され、無線端末10からの送信パケットをコア網70に中継するとともに、コア網70から受信した無線端末10宛てのパケットを、基地局制御装置30及び基地局20を介して無線端末10に中継する。
【００２０】
保守センタ60は、基地局20および基地局制御装置30に接続され、基地局20および基地局制御装置30の保守・管理を行う。
【００２１】
ここでは図面を簡単化するため、基地局20と基地局制御装置30が1台づつ配置されているが、複数の基地局制御装置30が存在し、またそれぞれの基地局制御装置30は複数の基地局20を制御できる。同様に複数の課金・認証サーバ40及びホームエージェント50が存在しうる。
【００２２】
図２は、基地局制御装置30の構成例である。基地局制御装置30は、運用系サーバ31と待機系サーバ32とパケット振り分け装置33とを有する。
【００２３】
図３は、パケット振り分け装置33の構成例である。パケット振り分け装置33は、プロセッサ330、基地局20との通信インタフェース１（331）、運用系サーバ31との通信インタフェース２（332）、待機系サーバ32との通信インタフェース３（333）、課金・認証サーバ40及びホームエージェント50との通信インタフェース４（334）、保守センタ60との通信インタフェース５（335）、及びメモリ336を有し、これらはバスで接続される。メモリ336上には、パケット転送処理部337、メッセージバッファ338、及びIDテーブル600が配置される。
【００２４】
図４運用系サーバ31の構成例である。運用系サーバ31は、プロセッサ310、パケット振り分け装置33との通信インタフェース311、HDD312、及びメモリ313を有し、これらはバスで接続される。メモリ313には、呼制御部314、待機系サーバ32を監視する死活監視部315、障害監視部316、および監視テーブル500Aが配置される。
【００２５】
図５は、待機系サーバ32の構成例である。待機系サーバ32は、運用系サーバ31と例えば1+1冗長を構成する場合、メモリ上に配置される処理部を除いて同じブロック構成図となる。本実施形態は、N台の運用系サーバ31と1台の待機系サーバ32によりN+1冗長を構成する場合にも適用可能である。
【００２６】
待機系サーバ32は、プロセッサ320、パケット振り分け装置32との通信インタフェース321、HDD322、メモリ323を有し、これらはバスで接続される。メモリ323には、呼制御部324、運用系サーバ31を監視する死活監視部325、障害監視部326、および監視テーブル500Bが配置される。
【００２７】
図６は、課金・認証サーバ40の構成例である。課金・認証サーバ40は、基地局制御装置30との通信インタフェース41、メモリ42、プロセッサ44、およびHDD45を有し、これらはバスで接続される。メモリ42上には、課金・認証部43の処理プログラムが配置される。、
図７は、ホームエージェント50の構成例である。ホームエージェント50は、基地局制御装置30との通信インタフェース１（51）、メモリ52、コア網70との通信インタフェース２（54）、プロセッサ55、及びHDD56を有し、これらはバスで接続される。メモリ52には、ホームエージェント50のアプリケーションの処理プログラムが配置される。ここでは、この処理プログラムを主処理53と呼ぶ。
【００２８】
図８は、保守センタ60の構成例である。基地局20と基地局制御装置30との通信インタフェース61、メモリ62、プロセッサ64、HDD65、及び入出力装置67とを有し、これらはバスで接続される。
【００２９】
図９は、待機系サーバ32の死活監視部325が、ホームエージェント50内の主処理53をアプリケーションレベルで死活監視(アプリケーションの実行を死活監視)するシーケンス図である。死活監視部325は、上位プロトコルMIPv4（Mobile Internet Protocol v4）を用いる。
【００３０】
この死活監視シーケンスで待機系サーバ32が用いる監視テーブル500Bを説明する。図１１に、監視テーブル500の構成例を示す。待機系サーバ32の監視テーブル500Bと運用系サーバ31の監視テーブル500Aは、同じ構成である。監視テーブル500Bは、監視対象の種別である監視種別501、監視対象を識別する番号502、監視対象の状態503、および監視対象のIPアドレスの欄を有し、監視種別501、番号502、監視対象のIPアドレス504の欄には、各々所定のデータを予め登録しておく。運用系サーバ31の監視テーブル500Aは、運用系サーバ31が運用状態である場合には使用せず、運用系サーバ31が待機状態に、待機系サーバ32が運用状態に切り替わった後に使用する。
【００３１】
死活監視部325は、ホームエージェント50のIPアドレス（通信インタフェース１（51）のIPアドレス）に対してMIPv4仕様のRegistration Requestメッセージを送信する（SQ01）。Registration Requestメッセージには、送信元IPアドレスとして待機系サーバ32の内部IPアドレス（通信インタフェース321のIPアドレス）、送信先IPアドレスとしてホームエージェント50のIPアドレス、Identificationの１例としてタイムスタンプが含まれる。
【００３２】
待機系サーバ32の死活監視部325からのRegistration Requestメッセージ(パケット)は、パケット振り分け装置33を経由する。言い換えると、Registration Requestメッセージは、パケット振り分け装置33によって宛先を振り分けて中継される。図12は、パケット振り分け装置33が、メッセージや応答のパケットを中継する際に用いるIDテーブル600の構成例である。IDテーブル600は、通信プロトコル601、Identification602、通信インタフェース603、送信元のIPアドレスである内部IPアドレス604、パケット振り分け装置33のIPアドレスである外部IPアドレス605の各欄を有する。
【００３３】
待機系サーバ32の死活監視部325からRegistration Requestメッセージを受信したパケット振り分け装置33は、受信した通信インタフェースを識別する。待機系サーバ32と接続する通信インタフェース３（333）であるので、受信したRegistration Requestメッセージを解析し、IDテーブル600の通信プロトコル600、Identification601、通信インタフェース603、および送信元の内部IPアドレス604の各欄に、解析結果を新たなレコードとして登録する。続いて、Registration Requestメッセージの送信元IPアドレスを、パケット振り分け装置33の通信インタフェース４（334）の外部IPアドレスに書き変えて（SQ02）、ホームエージェント50に向けて転送する（SQ03）。
【００３４】
ホームエージェント50の主処理53は、受信したRegistration Requestメッセージを解析し、Registration Replyメッセージ(パケット)を生成する（SQ04）。パケット振り分け装置32に、生成したRegistration Replyメッセージを送信する（SQ05）。Registration Replyメッセージには、送信先IPアドレスとしてパケット振り分け装置33の通信インタフェース４（334）の外部IPアドレス、送信元IPアドレスとしてホームエージェント50の外部IPアドレス（通信インタフェース１（51）のIPアドレス）、MIPv4仕様のIdentificationとしてRegistration RequestメッセージのIdentificationと同じ値が含まれる。
【００３５】
パケット振り分け装置32は、受信したRegistration Replyメッセージを解析し、Registration Replyメッセージを受信したプロトコルとRegistration Replyメッセージに含まれるIdentificationをキーとしてIDテーブル600を検索する（SQ06）。Identificationが一致するレコードがあれば、Registration Replyの送信先IPアドレスを、検索したレコードの内部IPアドレス604の値に書き変えて、検索したレコードの通信インタフェース603に示される通信インタフェースからRegistration Replyメッセージを転送する（SQ07）。IDテーブル600の検索したレコードを削除する。ここでは、Registration Replyメッセージは、送信先IPアドレスを待機系サーバ32の通信インタフェース321のIPアドレスとし、通信インタフェース３（333）を介して、Registration Requestメッセージを送信した待機系サーバ32の死活監視部325に転送される。
【００３６】
パケット振り分け装置33からRegistration Replyメッセージを受信した死活監視部325は、Registration Requestメッセージの送信先としたホームエージェント50が正常に動作していると判断し、監視テーブル500Bの監視対象の状態503に「正常」を格納する（SQ08）。
【００３７】
図１０は、待機系サーバ32の死活監視部325が、Registration Requestメッセージを送信してから所定時間内に、対応するRegistration Replyメッセージ(応答メッセージ)を受信しない場合の簡略化したシーケンス図である。
【００３８】
死活監視部325が、Registration Requestメッセージを送信して（SQ01、SQ03：図９のSQ01〜SQ03に相当）から所定時間(タイムアウト時間)Ｔ内に、対応するRegistration Replyメッセージを受信しない場合はタイムアウトし、Registration Requestメッセージの再送を行う（SQ13、SQ14）。予め定めた回数の再送を繰り返しても、Registration Replyメッセージを受信しない場合、監視対象としてRegistration Requestメッセージを送信したホームエージェント50又はその主処理53が正常に動作していないと判断し、監視テーブル500Bの当該監視対象の状態503に「異常」を格納する（SQ15）。待機系サーバ32の死活監視部325は、パケット振り分け装置33を経由して、保守センタ60に向けてTRAP（SNMPv2）メッセージを送信し（SQ16、SQ17）、保守センタ60にホームエージェント50が正常に動作していないことを通知する。
【００３９】
図１３は、パケット振り分け装置33がRegistration Requestメッセージのようなメッセージを受信したときのパケット振り分け処理700を示すフローチャートである。
【００４０】
パケット振り分け装置33はメッセージを受信すると（ステップ701）、メッセージの送信元が、メッセージを受信した通信インタフェースの種別に基づいて、内部（運用系サーバ31及び待機系サーバ32）か、それとも外部（基地局20、認証・課金サーバ40、ホームエージェント50及び保守センタ60）かを判定する（ステップ702）。内部/外部は、基地局制御装置30の内部/外部を示す。
【００４１】
メッセージの送信元が内部の場合、メッセージの送信先IPアドレスは内部IPアドレスか、それとも外部IPアドレスかを判定する（ステップ703）。内部IPアドレス/外部IPアドレスは、基地局制御装置30の内部/外部に対応する通信に用いるIPアドレスである。
【００４２】
メッセージの送信先IPアドレスが外部IPアドレスである場合には、送信元IPアドレスが待機系サーバ32の内部IPアドレスかどうかを判定する（ステップ704）。
【００４３】
待機系サーバ32の内部IPアドレスからのメッセージが、内部から外部へと送出される場合、IDテーブル600に、受信したメッセージのプロトコル種別、Identification、通信インタフェース、送信元の内部IPアドレス、送信先の外部IPアドレスを登録する（ステップ705）。
【００４４】
送信元の内部IPアドレスを、パケット振り分け装置33の、メッセージを送出する通信インタフェースの外部IPアドレスに書き変え（ステップ706）、メッセージを送信する（ステップ707）。
【００４５】
ステップ704において、運用系サーバ31から外部へメッセージを送出する場合（送信元IPアドレスが待機系サーバ32の内部IPアドレスではない場合）、IDテーブル600への情報の登録は行わず、送信元IPアドレスを外部IPアドレスに書き変えて（ステップ706）、メッセージを送信する（ステップ707）。
【００４６】
ステップ703において、送信先が内部の場合、内部から内部へのメッセージのため、送信先・送信元の元IPアドレスを書き変えずに、メッセージを転送する。
【００４７】
ステップ702において、送信元が外部の場合、プロトコル種別に基づいてメッセージを解析し、プロトコル種別に対応させてIdentificationを抽出する。プロトコル種別及びIdentificationの組み合わせをキーにして、IDテーブル600のレコードを検索し、該当するレコードが登録されているかを判定する（ステップ708）
登録されている場合は、そのメッセージは待機系サーバ32の死活監視部325から外部へ送出されたメッセージに対するリプライメッセージ（応答）であると判定できるため、IDテーブル600の該当データに登録された、待機系サーバ31Bを示す内部IPアドレス604に、メッセージの送信先IPアドレスを書き変える（ステップ709）。IDテーブル600の該当レコードを削除し（ステップ710）、メッセージを送信する（ステップ707）。
【００４８】
ステップ708において、受信したメッセージのIdentificationがIDテーブル600に登録されていない場合、受信したメッセージは待機系サーバ32の死活監視部325からのメッセージに対する応答ではないと判定され、送信先IPアドレスを、呼制御部314が動作している運用系サーバ31を示す内部IPアドレスに書き換え（ステップ711）、メッセージを送信する（ステップ707）。
【００４９】
図１４は、冗長切り替え動作のシーケンス図である。冗長切り替えとは、運用系サーバ31を待機系に、待機系サーバ32を運用系に切り替えることである。ただし、冗長切り替えに伴って、運用系サーバ31の死活監視部315はスタンバイ状態(SBY)からアクティブ状態（ACT）に、待機系サーバ32の死活監視部325はアクティブ状態（ACT）からスタンバイ状態(SBY)に切り替わる。
【００５０】
ここでは、1例として運用系サーバ31の障害監視部316が障害を検出した場合の冗長切り替えについて説明する。障害を検知した障害監視部316は、運用系サーバ31の呼制御部314及びパケット振り分け装置33に切り替え要求を送信する（SQ20、SQ30）。切り替え要求を受信したパケット振り分け装置33は、待機系サーバ32の死活監視部325に向けて切り替え要求を転送し、切り替えが完了するまでの間に受信する、切り替えに関係のないメッセージを、メッセージバッファ338に蓄積する（SQ31）。
【００５１】
切り替え要求を受信した呼制御部314は、運用系サーバ31の呼制御部314が持つ、運用に必要な呼制御データを待機系サーバ32の呼制御部324へ転送し(SQ21)、ACTからSBYへ遷移する（SQ22）。さらに、パケット振り分け装置33を経由して待機系サーバ32の呼制御部324に切り替え要求を送信する（SQ23、SQ24）。切り替え要求を受信した呼制御部324は、SBYからACTへ遷移する（SQ25）。ACTとなった呼制御部324は、切り替え完了通知をパケット振り分け装置33に送信し（SQ26）、パケット振り分け装置33はその切り替え完了通知を呼制御部314へ転送する（SQ27）。
【００５２】
一方、切り替え要求を受信した待機系サーバ32の死活監視部325は、監視テーブル500Bへデータ転送要求を送信し(SQ32)、監視テーブル500Bの監視情報を、監視テーブル500Aへ転送する(SQ33)。死活監視部325は、データ転送完了通知を監視テーブル500Bから受け取り(SQ34)、ACTからSBYへ遷移する(SQ35)。あたかも監視テーブル500Bがデータ転送を実行するように説明したが、実際には監視テーブル500Bのデータの転送やデータ転送完了を通知する処理プログラムが用意される。死活監視部325は、パケット振り分け装置33を経由して運用系サーバ31の死活監視部315に状態遷移完了通知を送信する（SQ36、SQ37）。状態遷移完了通知を受信した運用系サーバ31の死活監視部315は、SBYからACTへ遷移する（SQ38）。ACTとなった死活監視部315は、切り替え完了通知をパケット振り分け装置33に送信し（SQ39）、パケット振り分け装置33はその切り替え完了通知を死活監視部325へ転送する（SQ40）。
【００５３】
呼制御部324及び死活監視部315の両方から切り替え完了通知を受信したパケット振り分け装置33は、IDテーブル600に存在する各レコードの通信インタフェース603に格納されている通信インターフェイス２（332）と通信インターフェイス３（333）とを入れ替え、この入れ換えに対応する内部IPアドレスも入れ替える（SQ50）。IDテーブル600の更新後、障害監視部316に、切り替え完了通知を送信する（SQ51）。冗長切り替え終了後、切り替え動作中にメッセージバッファ338に蓄積していたメッセージを処理する。
【００５４】
図１５は、冗長切り替えに伴う、メッセージの処理シーケンスの１例を示す図である。
【００５５】
冗長切り替え前に、死活監視部325からRegistration Requestメッセージ801が、パケット振り分け装置33を介して、ホームエージェント50に向けて送信される。Registration Requestメッセージ801には、Identificationが100、送信先IPがホームエージェント50のIPアドレス、送信元IPアドレスが待機系サーバ32の内部IPアドレスxx.xx.xx.xxが保持されている。
【００５６】
パケット振り分け装置33において、図１３のパケット振り分け処理により、図１５のIDテーブル600Aのように、Registration Requestメッセージの情報が格納され、ホームエージェント50にRegistration Requestメッセージ802が送信される。
【００５７】
ここで、基地局制御装置30において冗長切り替え803が発生し、図１４に示す処理が実行された場合、IDテーブル600AからIDテーブル600Bのように情報が更新される。すなわち、通信インタフェース603Aの「３」が通信インタフェース603Bの「２」に、内部アドレス604Aのxx.xx.xx.xxが内部アドレス604Bのaa.aa.aa.aaに更新される。冗長切り替え中に受信された、ホームエージェント50からのRegistration Reply804はメッセージバッファ338に保持されており、冗長切り替え後に処理される。
【００５８】
冗長切り替え後、パケット振り分け装置32が、パケット振り分け処理を行い、Registration Reply805の送信先IPアドレスはzz.zz.zz.zzからaa.aa.aa.aaに書き変えられ、死活監視部315へ送信される。死活監視部315は、冗長切り替えの際に死活監視部325からの監視データ500Bの情報を、自身の監視データ500Aに格納しているため、Registration Replyを処理し、ホームエージェント50の状態を「正常」と判断する。
【００５９】
本実施形態によれば、死活監視を待機系サーバに実行させることにより、従来専用の死活監視装置として用いたコンピュータが不要になる。また、死活監視装置に付与されていたIPアドレスを、待機系サーバのIPアドレスと共用することで、用いるIPアドレスの数を削減できる。また、運用系サーバと待機系サーバとの冗長構成の監視を基地局制御装置の内部ネットワークで行うため、外部ネットワーク上の死活監視パケットを抑制できる。
【符号の説明】
【００６０】
１０：無線端末、２０：無線基地局、３０：基地局制御装置、３１:運用系サーバ、３２:待機系サーバ、３３：パケット振り分け装置、４０：課金・認証サーバ、５０：ホームエージェント、６０：保守センタ、７０：コア網、５００：監視テーブル、６００：ＩＤテーブル。
【図１】
2011010187.tif 000003
【図２】
2011010187.tif 000004
【図３】
2011010187.tif 000005
【図４】
2011010187.tif 000006
【図５】
2011010187.tif 000007
【図６】
2011010187.tif 000008
【図７】
2011010187.tif 000009
【図８】
2011010187.tif 000010
【図９】
2011010187.tif 000011
【図１０】
2011010187.tif 000012
【図１１】
2011010187.tif 000013
【図１２】
2011010187.tif 000014
【図１３】
2011010187.tif 000015
【図１４】
2011010187.tif 000016
【図１５】
2011010187.tif 000017