知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-01-16
(45)【発行日】2024-01-24
(54)【発明の名称】サーバシステムおよびプロセスの冗長化方法
(51)【国際特許分類】
G06F 11/20 20060101AFI20240117BHJP
G06F 11/07 20060101ALI20240117BHJP
H04L 45/28 20220101ALI20240117BHJP
【ＦＩ】
G06F11/20 623
G06F11/07 140A
G06F11/07 157
G06F11/07 196
H04L45/28
【請求項の数】
10
(21)【出願番号】P 2019048649
(22)【出願日】2019-03-15
(65)【公開番号】P2020149580
(43)【公開日】2020-09-17
【審査請求日】2021-12-17
(73)【特許権者】
【識別番号】000100746
【氏名又は名称】アイコム株式会社
(74)【代理人】
【識別番号】100095407
【弁理士】
【氏名又は名称】木村 満
(74)【代理人】
【識別番号】100131152
【弁理士】
【氏名又は名称】八島 耕司
(74)【代理人】
【識別番号】100174573
【弁理士】
【氏名又は名称】大坂 知美
(74)【代理人】
【識別番号】100173462
【弁理士】
【氏名又は名称】宮本 一浩
(72)【発明者】
【氏名】中野 晃
(72)【発明者】
【氏名】宮越 克明
【審査官】坂東 博司
(56)【参考文献】
【文献】特開２００６－１７２０５０（ＪＰ，Ａ）
【文献】特開２０１７－０２７１１０（ＪＰ，Ａ）
【文献】特開２０１０－０８６１３７（ＪＰ，Ａ）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｆ １１／２０
Ｈ０４Ｌ ４５／２８
Ｇ０６Ｆ １１／０７
(57)【特許請求の範囲】
【請求項1】
通信ネットワーク上に設置された第１サーバおよび第２サーバを備えたシステムであって、前記第１サーバは複数のプロセスを実行し、前記第２サーバは、前記第１サーバで実行される複数のプロセスの少なくとも一部のプロセスを並行して実行し、
前記第１サーバおよび前記第２サーバで並行して実行されているプロセスのうち、一方のプロセスが、実際にサービスを提供する稼働モードで動作し、前記一方のプロセスに対応する他方のプロセスが、前記稼働モードの前記一方のプロセスがダウンしたとき、該ダウンしたプロセスに代わって稼働モードとなる待機モードで動作し、
稼働モードのプロセスである稼働プロセスは、待機モードのプロセスである待機プロセスに対して、自身が正常に動作していることを通知するメッセージである動作通知を定期的に送信し、
前記待機プロセスは、前記稼働プロセスから定期的に動作通知を受信している間、待機モードを継続し、
前記待機プロセスは、前記稼働プロセスから動作通知を受信しなくなると、自身の動作モードを待機モードから稼働モードに切り換えて、前記サービスの提供を開始するとともに、前記一方のプロセスがある一方のサーバにおけるダウンしない稼働モードのプロセスは、前記稼働モードで続けて動作し、
前記第１サーバで実行されるプロセスは、プロセス単位で冗長化の有無が設定される
サーバシステム。
【請求項2】
前記通信ネットワークは、第１ネットワークおよび第２ネットワークを有し、前記第１サーバは、前記第１ネットワーク上に設けられ、前記第２サーバは、前記第２ネットワーク上に設けられ、
前記第１サーバと第２サーバとは、前記通信ネットワークとは別の通信線で接続されている
請求項１に記載のサーバシステム。
【請求項3】
前記通信ネットワーク上に、各プロセスの動作状況を記憶する管理テーブルを備えた管理サーバをさらに設け、各プロセスは、前記管理サーバに対して、定期的に前記動作通知を送信し、
各プロセスは、自身の動作モードが待機モードから稼働モードに切り換わったとき、その旨を通知するメッセージであるモード切換通知を前記管理サーバに送信し、
前記管理サーバは、前記動作通知および前記モード切換通知によって取得した各プロセスの動作状況を前記管理テーブルに記憶し、
前記複数のプロセスのうちの所定の第１プロセスおよび第２プロセスは相互にプロセス間通信を実行し、且つ、前記第２プロセスは、前記第１サーバおよび前記第２サーバで並行して実行されており、
前記第１プロセスは、前記管理サーバに各プロセスの動作状況を問い合わせ、
前記管理サーバは、前記問い合わせに応じて前記各プロセスの動作状況を、前記第１プロセスに対して送信し、
前記第１プロセスは、受信した各プロセスの動作状況に基づいて、前記並行して実行されている第２プロセスのうち、稼働モードで動作しているプロセスを決定して、該稼働している第２プロセスを前記プロセス間通信の通信相手とする
請求項１に記載のサーバシステム。
【請求項4】
前記通信ネットワークは、異なるセグメントの第１ネットワークおよび第２ネットワークを有し、前記第１サーバは前記第１ネットワーク上に設けられ、前記第２サーバは前記第２ネットワーク上に設けられ、
前記管理サーバは、前記第１ネットワーク上に設けられた第１管理サーバ、および、前記第２ネットワーク上に設けられた第２管理サーバを有し、
前記第１サーバ、第１管理サーバと、第２サーバ、第２管理サーバとの間は、前記ネットワークとは別の通信線で接続されており、
各プロセスは、前記動作通知およびモード切換通知を、前記第１管理サーバおよび第２管理サーバの両方に送信し、
前記第１プロセスは、自身と同じ側のネットワーク上にある管理サーバに各プロセスの動作状況を問い合わせる
請求項３に記載のサーバシステム。
【請求項5】
前記第１サーバおよび第２サーバで実行されるプロセスは、複数の通信端末から送信された音声信号を中継する呼制御プロセスであり、
前記複数の通信端末は、前記第１ネットワーク、第２ネットワークのいずれかを介して前記第１サーバまたは第２サーバにアクセスする、
請求項２または請求項４に記載のサーバシステム。
【請求項6】
前記第１サーバおよび第２サーバはそれぞれ、複数のパーテーションに分割され、各パーテーションでそれぞれ別のプロセスを実行する、
請求項５に記載のサーバシステム。
【請求項7】
前記別の通信線は、ＶＰＮで構成され、
前記第１サーバおよび第２サーバで実行されるプロセスは、複数の通信端末から送信された音声信号を中継する呼制御プロセスと、稼働モードにある呼制御プロセス同士を接続する接続プロセスとを含み、
稼働モードにある前記接続プロセスが、前記第１サーバと前記第２サーバの一方に位置する場合に、前記第１サーバと前記第２サーバの他方に位置する稼働モードにある前記呼制御プロセスに、前記ＶＰＮを介して、接続する、
請求項５または６に記載のサーバシステム。
【請求項8】
稼働モードにある前記呼制御プロセスは、該呼制御プロセスが、前記第１サーバに位置する場合に、前記ＶＰＮを介して、前記第２ネットワークに接続された通信端末に接続され、該呼制御プロセスが、前記第２サーバに位置する場合に、前記ＶＰＮを介して、前記第１ネットワークに接続された通信端末に接続され、
前記ＶＰＮがダウンした場合、前記第１サーバと前記第２サーバそれぞれに位置する呼制御プロセスと接続プロセスは、それぞれ稼働モードとなり、前記第１ネットワークに接続された通信端末間の通信と、前記第２ネットワークに接続された通信端末間の通信とをそれぞれ可能とする、
請求項７に記載のサーバシステム。
【請求項9】
通信ネットワーク上に設置された第１サーバが、複数のプロセスを実行し、前記通信ネットワーク上に設置された第２サーバが、前記第１サーバで実行される複数のプロセスの少なくとも一部のプロセスを並行して実行し、
前記第１サーバおよび前記第２サーバで並行して実行されているプロセスのうち、一方のプロセスが、実際にサービスを提供する稼働モードで動作し、他方のプロセスが、前記稼働モードのプロセスがダウンしたとき、該ダウンしたプロセスに代わって稼働モードとなる待機モードで動作し、
稼働モードのプロセスである稼働プロセスは、待機モードのプロセスである待機プロセスに対して、自身が正常に動作していることを通知するメッセージである動作通知を定期的に送信し、
前記待機プロセスは、前記稼働プロセスから定期的に動作通知を受信している間、待機モードを継続し、
前記待機プロセスは、前記稼働プロセスから動作通知を受信しなくなると、自身の動作モードを待機モードから稼働モードに切り換えて、前記サービスの提供を開始し、
前記第１サーバで実行されるプロセスは、プロセス単位で冗長化の有無が設定される
プロセスの冗長化方法。
【請求項10】
各プロセスは、前記通信ネットワーク上に設けられた管理サーバに対して、定期的に前記動作通知を送信し、各プロセスは、自身の動作モードが待機モードから稼働モードに切り換わったとき、その旨を通知するメッセージであるモード切換通知を前記管理サーバに送信し、
前記管理サーバは、前記動作通知および前記モード切換通知によって取得した各プロセスの動作状況を管理テーブルに記憶し、
前記第１サーバおよび前記第２サーバで並行して実行されているプロセスである第２プロセスとのプロセス間通信を実行する第１プロセスが、前記管理サーバに各プロセスの動作状況を問い合わせ、取得した各プロセスの動作状況に基づいて、前記並行して実行されている第２プロセスのうち、稼働モードで動作しているプロセスを決定して、該稼働している第２プロセスを前記プロセス間通信の通信相手とする
請求項９に記載のプロセスの冗長化方法。
【発明の詳細な説明】
【技術分野】
【0001】
この発明は、サーバシステムの冗長化に関する。
【背景技術】
【0002】
稼働（active）サーバと待機（standby）サーバを設置し、稼働サーバと待機サーバとの間で同期をとることでサーバシステムを冗長化することは従来より知られている。このような冗長構成のサーバシステムを構成する場合、ＶＲＲＰなどのプロトコルを用いて仮想ＩＰで通信することが考えられる（特許文献１参照）。
【先行技術文献】
【特許文献】
【0003】
【文献】特開２０１３－０７７９８３号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
しかし、ＶＲＲＰを用いるためには、同一ネットワークセグメント上に稼働サーバ、待機サーバの両方を設置する必要があり、また、この形態で冗長化されたサーバシステムは、サーバで複数のプロセスが実行されている場合、一部のプロセスに障害が発生した場合でも、全てのプロセスを稼働サーバから待機サーバへ切り換える必要があった。
【0005】
また、ＶＲＲＰでは、稼働サーバは、自身が正常に動作していることを通知するため、待機サーバに向けて一定時間毎にアドバタイズメントを送信するが、逆方向すなわち、待機サーバから稼働サーバに向けてのアドバタイズメントは送信されないため、稼働サーバが、システム内の他のサーバの状態を知ることができなかった。
【0006】
この発明の目的は、プロセス単位でサーバを冗長化でき、プロセス間通信を行う場合等に、プロセスが他のプロセスの動作状況を容易に知ることができるようにすることにある。
【課題を解決するための手段】
【0007】
本発明は、通信ネットワーク上に設置された第１サーバおよび第２サーバを備えている。第１サーバは複数のプロセスを実行し、第２サーバは、第１サーバで実行される複数のプロセスの少なくとも一部のプロセスを並行して実行する。第１サーバおよび第２サーバで並行して実行されているプロセスのうち、一方のプロセスが、実際にサービスを提供する稼働モードで動作し（稼働プロセス）、一方のプロセスに対応する他方のプロセスが、稼働モードの一方のプロセスがダウンしたとき、これに代わって稼働モードとなる待機モードで動作する（待機プロセス）。稼働プロセスは、自身が正常に動作していることを通知するメッセージである動作通知を、定期的に待機プロセスに送信する。待機プロセスは、稼働プロセスから定期的に動作通知を受信している間待機モードを継続するが、稼働プロセスから動作通知を受信しなくなると、自身の動作モードを待機モードから稼働モードに切り換えて、このプロセスのサービスの提供を開始するとともに、一方のプロセスがある一方のサーバにおけるダウンしない稼働モードのプロセスは、稼働モードで続けて動作する。第１サーバで実行されるプロセスは、プロセス単位で冗長化の有無が設定される。
【0008】
この発明では、第１サーバ、第２サーバでプロセスが並行して実行され、一方が稼働プロセス、他方が待機プロセスとされる。一部のプロセスが障害でダウンした場合に、サーバ全体を切り換えるのでなく、その障害が発生したプロセスの単位で切り換える。これにより、冗長構成の切り換え処理が簡略化されるとともに、第１、第２サーバの双方で一部のプロセスがダウンしていても、相手方のサーバでそのプロセスが正常に稼働していればシステム全体として動作可能であるため、より堅牢性が増す。
【0009】
通信ネットワークとして、例えばそれぞれ別の携帯電話キャリアのネットワークである第１ネットワーク、第２ネットワークを用い、第１サーバを第１ネットワーク上に設け、第２サーバを第２ネットワーク上に設けてもよい。この場合、第１サーバと第２サーバとは、専用線によるＶＰＮなどで接続される。このように、第１サーバおよび第２サーバを別々のネットワーク上に設置することで、ネットワーク障害に対して強いシステムを構成することが可能になる。
【0010】
通信ネットワーク上に、各プロセスの動作状況を記憶する管理テーブルを備えた管理サーバをさらに設けてもよい。第１、第２サーバで実行される各プロセスは、管理サーバに対して定期的に動作通知を送信する。また、プロセスの動作モードが待機モードから稼働モードに切り換わったとき、そのプロセスはモード切換通知を管理サーバに送信する。管理サーバは、動作通知およびモード切換通知によって取得した各プロセスの動作状況を管理テーブルに記憶する。
【0011】
プロセスが、この管理テーブルの内容、すなわち、各プロセスの動作状況を参照することで、自身に通知が送られてこなくても、他のプロセスの動作状況を知ることができ、プロセス単位で稼働／待機（メイン／サブ）が切り換わっても、それに追従してプロセス間通信を維持することができる。
【0012】
例えば、第１プロセスが、第１サーバおよび第２サーバで並行して実行されているプロセス（第２プロセス）とプロセス間通信を実行する場合に、管理サーバに各プロセスの動作状況を問い合わせ、取得した各プロセスの動作状況に基づいて、２つのサーバで並行して実行されている第２プロセスのうち、稼働モードで動作しているプロセスを決定し、この稼働している第２プロセスをプロセス間通信の通信相手とする。
【0013】
通信ネットワークとして、例えばそれぞれ別の携帯電話キャリアのネットワークである第１ネットワーク、第２ネットワークを用い、第１サーバおよび第１管理サーバを第１ネットワーク上に設け、第２サーバおよび第２管理サーバを第２ネットワーク上に設けてもよい。この場合、第１サーバシステム（第１サーバ、第１管理サーバ）と第１サーバシステム（第２サーバ、第２管理サーバ）とは、専用線によるＶＰＮなどで接続される。
【0014】
第１、第２サーバで実行される各プロセスは、第１管理サーバ、第２管理サーバの両方に対して動作通知およびモード切換通知を送信する。これにより、管理サーバの冗長化が可能になる。プロセスは、自身と同じ側のネットワーク上にある管理サーバに各プロセスの動作状況を問い合わせればよい。
【0015】
第１サーバおよび第２サーバで実行されるプロセスは、複数の通信端末から送信された音声信号を中継する呼制御プロセスであってよい。複数の通信端末のうち、第１ネットワークのＳＩＭがセットされた通信端末は、第１ネットワークを介してサーバにアクセスする。第２ネットワークのＳＩＭがセットされた通信端末は、第２ネットワークを介してサーバにアクセスする。第１ネットワークから第２サーバにアクセスする場合は、サーバ間をつなぐＶＰＮを介する。
【発明の効果】
【0016】
この発明によれば、第１および第２サーバで複数のプロセスを実行する場合に、プロセス単位で冗長構成を構築することができ、サーバ（プロセス）切り換えの容易化およびより高い堅牢化を実現することができる。
【図面の簡単な説明】
【0017】
【発明を実施するための形態】
【0018】
図１は、この発明の実施形態である音声通信システム１の構成を示す図である。音声通信システム１は、複数（この実施形態では２つ）のサーバシステム２（２－１,２－２）および複数の通信端末４を有している。サーバシステム２と通信端末４とは、複数（この実施形態では２つ）のＬＴＥネットワーク３（３－１,３－２）で相互に接続されている。２つのＬＴＥネットワーク３－１，３－２は、それぞれ異なる通信キャリア（携帯電話会社）が提供する通信ネットワークである。
【0019】
ＬＴＥネットワーク３－１（第１キャリア）上にクラウドサーバとしてサーバシステム２－１が設置され、ＬＴＥネットワーク３－２（第２キャリア）上にクラウドサーバとしてサーバシステム２－２が設置される。サーバシステム２－１、２－２間は通信キャリア３よって提供される専用回線を用いたＶＰＮ６で接続されている。
【0020】
通信端末４のうち、ＬＴＥネットワーク３－１を介してサーバシステム２にアクセスする通信端末は、第１キャリアのＳＩＭカードを装着しており、ＬＴＥネットワーク３－２を介してサーバシステム２にアクセスする通信端末は、第２キャリアのＳＩＭカードを装着している。
【0021】
サーバシステム２－１は、呼制御サーバ２１－１、プロビジョニングサーバ２２－１および管理サーバ２０－１を有している。また、サーバシステム２－２も同様に、呼制御サーバ２１－２、プロビジョニングサーバ２２－２および管理サーバ２０－２を有している。呼制御サーバ２１－１、プロビジョニングサーバ２２－１、管理サーバ２０－１およびＬＴＥネットワーク３－１は、ＬＡＮ（ローカル・エリア・ネットワーク）５－１で相互に接続されている。また、呼制御サーバ２１－２、プロビジョニングサーバ２２－２、管理サーバ２０－２およびＬＴＥネットワーク３－２は、ＬＡＮ５－２で相互に接続されている。ＬＡＮ５－１およびＬＡＮ５－２は、ＶＰＮ６で相互に接続されている。
【0022】
したがって、サーバシステム２－１とサーバシステム２－２は、それぞれ異なる通信キャリアのクラウド上にあり、地理的に離れた場所に設置することが可能であるため、障害に強い堅牢な音声通信システムを構築することができる。また、サーバシステム２－１とサーバシステム２－２とは、専用線のＶＰＮ６で接続されているため、同一のネットワーク上にある場合と同様に、以下に説明するような柔軟なプロセスの冗長化が可能である。
【0023】
通常動作時は、サーバシステム２－１の呼制御サーバ２１－１およびプロビジョニングサーバ２２－１がメインサーバとして、通信端末４に対するプロビジョニングおよび呼制御を実行する。サーバシステム２－２の呼制御サーバ２１－２およびプロビジョニングサーバ２２－２は、メインサーバのダウンに備えたサブサーバとしてスタンバイしている。なお、メイン／サブの切り換えは、ハードウェア単位ではなく、内部で起動される複数のプロセス（仮想サーバ：図４参照）単位で行われる。
【0024】
管理サーバ２０（２０－１、２０－２）は、サーバシステム２－１、２－２の呼制御サーバ２１－１、２１－２およびプロビジョニングサーバ２２－１、２２－２で実行される各プロセスの動作状況を管理し、要求に応じてサーバや通信端末４にその情報を提供する。このため、管理サーバ２０は、図９に示すような管理テーブルを備えている。
【0025】
ある通信端末４（発呼端末）が他の通信端末４（着呼端末）と通信する場合、発呼端末が、着呼端末の識別情報を制御情報として含む音声信号を呼制御サーバ２１に送信する。呼制御サーバ２１は、この音声信号をＬＴＥネットワーク３を介して着呼端末に転送する。これによって、ＳＩＰ手順などの事前の呼出手続なしで（一般の無線トランシーバのような操作で）、ネットワークを介した発呼端末－着呼端末間の音声通信が可能になる。この通信方式は、国際公開ＷＯ２０１５／０６８６６３号パンフレットに詳細に記載されている。
【0026】
図２は、管理サーバ２０（２０－１，２０－２）、呼制御サーバ２１（２１－１、２１－２）、および、プロビジョニングサーバ２２（２２－１、２２－２）のブロック図である。サーバは、制御部３０、記憶部３１およびネットワーク通信部３２を有している。記憶部３１は、たとえばハードディスクやＲＡＭなどで構成される。管理サーバ２０の場合、記憶部３１には、図９に示すような管理テーブルが記憶される。呼制御サーバ２１の場合、記憶部３１には、図７に示すようなステータステーブルが設けられる。ネットワーク通信部３２は、ＬＡＮ５およびＬＴＥネットワーク３を介して通信端末４や他のサーバと通信する。制御部３０は、各サーバの動作を制御する。
【0027】
図３は、通信端末４のブロック図である。通信端末４は、図１に示したように、ハンディトランシーバの外観を有しているが、機能的にはＬＴＥネットワーク３を介して音声信号を送受信する無線ネットワーク機器である。装置の動作を制御する制御部４０はマイクロプロセッサで構成される。制御部４０は、各種のデータが記憶される記憶部４１を有している。記憶部４１は、プロビジョニングデータ記憶エリア４１Ａを有し、このプロビジョニングデータ記憶エリア４１Ａには、図１２に示すようなプロビジョニングデータが記憶される。制御部４０には、操作部４２、表示部４３、オーディオ回路４４、ＬＴＥ通信部４５およびカードスロット４６が接続されている。操作部４２は、ＰＴＴスイッチ２２０などのキースイッチを含み、ユーザの操作を受け付けてその操作信号を制御部４０に入力する。表示部４３は液晶ディスプレイを含む。液晶ディスプレイには、ユーザの操作によって選択された通信相手の識別番号や着信した通信相手の識別番号などが表示される。
【0028】
オーディオ回路４４は、マイク２４０およびスピーカ２４１を有している。制御部４０は、受信した音声信号をデコードしてオーディオ回路４４に入力する。オーディオ回路は、このデコードされたオーディオ信号をアナログ信号に変換してスピーカ２４１から出力する。オーディオ回路４４は、また、マイク２４０から入力された音声信号をデジタル信号に変換して制御部４０に入力する。制御部４０は、このデジタルオーディオ信号を音声パケット化してＬＴＥ通信部４５に入力する。ＬＴＥ通信部４５は、ＬＴＥ通信方式で無線通信を行う回路を有し、制御部４０から入力されたパケットをＬＴＥネットワーク３に向けて送信するとともに、ＬＴＥネットワーク３から受信したパケットを制御部４０に入力する。なお、オーディオ回路４４にはイヤホンコネクタ２４２が設けられている。イヤホンコネクタ２４２にイヤホンマイク（不図示）が接続されると、通信端末４本体に設けられているマイク２４０およびスピーカ２４１は機能を停止し、イヤホンマイクのマイクおよびスピーカ（イヤホン）が有効になる。カードスロット４６には、端末識別情報が記憶されたＩＣカード（ＳＩＭカード）４７がセットされる。ＬＴＥネットワーク３－１で使用される通信端末４には第１キャリアのＳＩＭカード４７がセットされ、ＬＴＥネットワーク３－２で使用される通信端末４には第２キャリアのＳＩＭカード４７がセットされる。このＳＩＭカード４７に記憶されている端末識別情報（ＩＣＣＩＤ）が各通信端末４の識別情報として用いられる。
【0029】
以上の構成の通信端末４において、ユーザがＰＴＴスイッチ２２０を押しながらマイク２４０に向けて音声を入力すると、通信端末４は、この音声信号を、予め設定された着呼端末の識別情報が書き込まれた音声パケットに編集し、この音声パケットをＬＴＥネットワーク３を介して呼制御サーバ２１に送信する。
【0030】
図４、図５は、呼制御サーバ２１、プロビジョニングサーバ２２の冗長化構成を示す図である。図４は、呼制御サーバ２１，プロビジョニングサーバ２２による二重化と呼制御サーバ２１の制御部３０におけるパーテーション構成を示す図、図５は、呼制御サーバ２１で実行される各プロセスの機能を示す図である。呼制御サーバ２１は、複数のクライアントに対して独立した通信サービスを提供できるように、相互に独立した複数のプロセス（仮想サーバ）を実行する。図４に示すように、呼制御サーバ２１は、６のパーテーションに分割され、各パーテーションでそれぞれ別のプロセスを実行する。プロビジョニングサーバ２２は、複数のクライアントに対して共通であるが、各クライアントの通信端末４の固有識別番号に基づいて、それぞれ別のプロビジョニング処理を実行する。
【0031】
呼制御サーバ２１－１の各パーテーションで実行されるプロセスは、図５に示すように、クライアントＡ，Ｂ，Ｃの音声通信を制御するための呼制御プロセスＡ，Ｂ，Ｃである。また、呼制御サーバ２１－２の各パーテーションで実行されるプロセスは、図５に示すように、クライアントＡ，Ｂの音声通信を制御するための呼制御プロセスＡ，Ｂである。すなわち、クライアントＡ，Ｂの呼制御プロセスＡ，Ｂは冗長化されているが、クライアントＣの呼制御プロセスＣは冗長化されていない。
【0032】
呼制御プロセスＡは、クライアントＡの通信端末４相互間の音声通信を中継するプロセスである。呼制御プロセスＣは、クライアントＣの通信端末４相互間の音声通信を中継するプロセスである。なお、一つの呼制御プロセスは、所定の台数（例えば１００台）までの通信端末４を収容することができる。なお、「通信端末４を収容する」とは、通信端末４を登録して、その通信端末４に対して音声通信の中継やプロビジョニングデータの送信を行うことである。所定台数以上の通信端末４を収容する場合には、呼制御プロセスを複数実行してそれぞれの呼制御プロセスに１００台以内の通信端末４を収容し、各呼制御プロセスを拠点間接続プロセスでつないで、各呼制御プロセスに収容されている通信端末４相互間の音声通信を可能にする。クライアントＢは、所有する（収容すべき）通信端末４の台数が多い（１００台を超える）ため、２つの呼制御プロセスＢ１、Ｂ２が実行され、さらに、拠点間接続プロセスＢｒが実行されて呼制御プロセスＢ１、Ｂ２をつないでいる。これにより、クライアントＢに属する全ての通信端末４相互間の音声通信が実現される。
【0033】
このように、クライアントＡ，Ｂの呼制御プロセスＡ，Ｂは冗長化されているが、クライアントＣの呼制御プロセスＣは冗長化されていない。冗長化されたハードウェアである呼制御サーバ２１の内部で実行される呼制御プロセスは、プロセス単位で冗長化の有無を設定することができる。ハードウェア資源やプロセスの重要度などに基づいて、各プロセスの冗長化の有無を決定すればよい。
【0034】
プロビジョニングサーバ２２は、通信端末４に図１２に示すようなプロビジョニングデータを送信するためのサーバである。通信端末４は、電源オン時にプロビジョニングサーバ２２にアクセスし、図１２に示すプロビジョニングデータを受信する。通信端末４は、受信したプロビジョニングデータで自身の動作をセットアップし、その通信端末４を保有するクライアントの呼制御プロセスにアクセスできるようになる。プロビジョニングについては、国際公開ＷＯ２０１７／０８６４１６号パンフレットに詳細に記載されている。
【0035】
なお、呼制御サーバ２１－１およびプロビジョニングサーバ２２－１と呼制御サーバ２１－２およびプロビジョニングサーバ２２－２が、必ずしも同じ性能のものである必要はなく、設定可能なパーテーションの数も同数である必要はない。
【0036】
冗長化され呼制御サーバ２１－１、呼制御サーバ２１－２の両方で実行されている呼制御プロセスＡ，Ｂのうち、呼制御サーバ２１－１で実行されているプロセスが、稼働（active）プロセスとして通信端末４相互間の音声通信を中継する呼制御処理を実際に行い、呼制御サーバ２１－２で実行されている各プロセスは、待機（standby）プロセスとして、対応する稼働プロセス（呼制御サーバ２１－１で実行されている同じプロセス）がダウンした場合に交替するべく待機している。各プロセスの動作モード（稼働プロセス／待機プロセス）は、管理サーバ２０の管理テーブル（図９参照）に記憶される。
【0037】
なお、プロビジョニングサーバ２２－１、プロビジョニングサーバ２２－２は、両方とも稼働（active）モードに設定され、通信端末４からのプロビジョニング要求に応答する。
【0038】
図５は、全てのプロセスが正常に実行されているとき（通常運用）の各呼制御プロセスと通信端末４との接続関係を示している。各クライアントが所持する通信端末４には、以下の種類がある。通信キャリア１のＳＩＭがセットされ、ＬＴＥネットワーク３－１を介してサーバシステム２にアクセスする通信端末４、および、通信キャリア２のＳＩＭがセットされ、ＬＴＥネットワーク３－２を介してサーバシステム２にアクセスする通信端末４がある。通常運用時は、メインサーバである呼制御サーバ２１－１の呼制御プロセスＡ，Ｂ１，Ｂ２，Ｃが稼働して、実際に呼制御処理を行っているため、通信端末４は全て呼制御サーバ２１－１のプロセスに接続される。呼制御サーバ２１－１はＬＴＥネットワーク３－１側に接続されているため、ＬＴＥネットワーク３－２に接続される通信端末４は、ＬＴＥネットワーク３－２からＶＰＮ６を経由して呼制御サーバ２１－１にアクセスする。なお、通信キャリア１のＳＩＭおよび通信キャリア２のＳＩＭの両方がセットされ、ＬＴＥネットワーク３－１、ＬＴＥネットワーク３－２のどうちらを介してでもサーバシステム２にアクセス可能な（マルチキャリア）通信端末４を設けてもよい。
【0039】
通常運用中に呼制御サーバ２１－１のいずれかのプロセスがダウンした場合、ダウンしたプロセスが、図６（Ｂ），図６（Ｃ）に示すような形態で、呼制御サーバ２１－２の待機プロセスに切り換えられる。図６では、クライアントＢの呼制御プロセスＢ（呼制御プロセスＢ１，Ｂ２および拠点間接続プロセスＢｒ）における稼働プロセスから待機プロセスへの切り換えについて説明する。
【0040】
図６（Ａ）はクライアントＢの各プロセスが正常に実行されている場合の各プロセスおよび通信端末４の接続形態を示している。この接続形態は、図５に示したものと同じである。ここでは、呼制御プロセスＢ１－１，Ｂ２－１および拠点間接続プロセスＢｒ－１が稼働しており、通信端末４は、呼制御プロセスＢ１－１，Ｂ２－１にアクセスする。詳細には、通信端末４－１は、ＬＴＥネットワーク３－１を介して呼制御プロセスＢ１－１にアクセスし、通信端末４－３は、ＬＴＥネットワーク３－２およびＶＰＮ６を介して呼制御プロセスＢ１－１にアクセスする。通信端末４－２は、ＬＴＥネットワーク３－１を介して呼制御プロセスＢ２－１にアクセスし、通信端末４－４は、ＬＴＥネットワーク３－２およびＶＰＮ６を介して呼制御プロセスＢ２－１にアクセスする。
【0041】
図６（Ｂ）は、呼制御プロセスＢ２－１がダウンした場合の接続形態を示している。稼働プロセスであった呼制御プロセスＢ２－１がダウンしたため、対応する待機プロセスである呼制御プロセスＢ２－２が稼働プロセスとなる。そうすると、通信端末４－２、４－４は、呼制御プロセスＢ２－１から呼制御プロセスＢ２－２にアクセス先を変更する。詳細には、通信端末４－２は、ＬＴＥネットワーク３－１およびＶＰＮ６を介して呼制御プロセスＢ２－２にアクセスし、通信端末４－４は、ＬＴＥネットワーク３－２を介して呼制御プロセスＢ２－２にアクセスする。また、拠点間接続プロセスＢｒ－１は、メインの呼制御プロセスＢ１－１とサブの呼制御プロセスＢ２－２とを接続するよう接続拠点を切り換える。
【0042】
図６（Ｃ）は、拠点間接続プロセスＢｒ－１がダウンした場合の接続形態を示している。稼働プロセスであった拠点間接続プロセスＢｒ－１がダウンしたため、待機プロセスである拠点間接続プロセスＢｒ－２が稼働プロセスとなる。呼制御サーバ２１－１の呼制御プロセスＢ１－１、Ｂ２－１が正常に稼働しているため、拠点間接続プロセスＢｒ－２は、ＶＰＮ６を介して、呼制御サーバ２１－１の呼制御プロセスＢ１－１およびＢ２－１を接続する。なお、通常動作時と同様に呼制御プロセスＢ１－１およびＢ２－１は正常に稼働しているため、通信端末４－１～４のアクセス先に変更はない。
【0043】
このように、ハードウェアの呼制御サーバ２１－１、２１－２で複数のプロセス（仮想サーバ）が稼働しており、そのいずれかがダウンした場合、プロセス単位で呼制御サーバ２１－１のプロセスから呼制御サーバ２１－２のプロセスに切り換えられる。
【0044】
各プロセス（パーテーション）は、自身が実行しているプロセスおよび対応する相手プロセスの状態を記憶するため、記憶部３１に図７に示すようなステータステーブルを有している。ステータステーブルは、自身が実行しているプロセスの名称、動作設定、動作モード（稼働モード（active）／待機モード（standby））、および、自身の動作通知有効期限、稼働中システムの動作通知有効期限の記憶エリアを有している。動作設定の欄には、メインプロセス（main）／サブプロセス（sub）／単独プロセス（alone）のいずれかの設定情報が記憶される。呼制御サーバ２１－１および呼制御サーバ２１－２で、同じプロセスが実行される場合、そのうちの一方（一般的にはメインサーバである呼制御サーバ２１－１で実行されるプロセス）がメインプロセスに設定され、他方（一般的にはサブサーバである呼制御サーバ２１－２で実行されるプロセス）がサブプロセスに設定される。両プロセスが正常に動作しているときは、メインプロセスが実際の処理を実行する稼働モードになり、サブプロセスが待機モードになる。メインプロセスがダウンした場合、サブプロセスが稼働モードになる。動作モードの欄には、このプロセスの動作モードが稼働モード（active）であるか、待機モード（stadby）であるかが記憶される。
【0045】
また、呼制御プロセスＣは、呼制御サーバ２１－１のみで実行されているため、動作設定の欄には、単独プロセス（alone）が記憶される。
【0046】
なお、各プロセスが管理サーバ２０および対応する待機プロセスに送信する動作通知は、自身が実行しているプロセスの名称、動作設定、動作モード、および、この動作通知の有効期限を含んでいる。
【0047】
図７（Ａ）は、メインプロセスのステータステーブルの記憶内容の例を示す図である。この例では、このプロセス（パーテーション）は、呼制御プロセスＢ２－１を実行しており、動作設定はメイン、動作モードは稼働モードである。動作通知有効期限は、自身が管理サーバ２０および相手のサブプロセスに対して送った動作通知の有効期限が記憶される。動作通知は、自身が管理サーバ２０および待機プロセスに対して、自身が正常に動作していることを通知するメッセージである。待機プロセスおよび管理サーバ２０は、この動作通知の有効期限が経過する前に新たな有効期限の動作通知が送られてくることで稼働プロセスが正常に動作していることを確認する。稼働プロセス動作通知有効期限は、自身が待機中の場合に、対応する稼働プロセスから受信した動作通知の有効期限が記憶される。図７（Ａ）は、稼働プロセスのステータステーブルであるため、稼働プロセスから受信する稼働プロセス動作通知有効期限は空欄である。
【0048】
図７（Ｂ）は、サブプロセスのステータステーブルの記憶内容の例を示す図である。この例では、このプロセス（パーテーション）は、呼制御プロセスＢ２－２を実行しており、動作設定はサブプロセス、動作モードは待機モードである。動作通知有効期限は、自身が管理サーバ２０に対して送った動作通知の有効期限が記憶される。稼働システム動作通知有効期限には、対応する稼働プロセス（呼制御プロセスＢ２－１）から送られてきた動作通知の有効期限が記憶される。有効期限が経過する前に新たな有効期限の動作通知が送られてくると、その新たな有効期限でテーブルを更新し、待機モードを継続する。
【0049】
この有効期限を過ぎても稼働プロセスから動作通知が送られて来ない場合、同図右欄に示すように、このサブプロセスは、稼働プロセスであるメインプロセスがダウンしていると判断し、自身の動作モードを稼働モードに切り換えて、通信端末４の音声通信の中継を開始する。
【0050】
図８は呼制御サーバ２１で実行される呼制御プロセスの動作を示すフローチャートである。図８（Ａ）は、稼働プロセスの動作通知処理を示している。稼働プロセスは、定期的（たとえば１分毎）に、両側の管理サーバ２０－１、２０－２に対して動作通知を送信するとともに（Ｓ１１）、対応する待機プロセスに対しても動作通知を送信する（Ｓ１２）。送信した動作通知の有効期限は、次の送信予定時刻よりも長く設定されている。この有効期限で、自身のステータステーブルの動作通知の有効期限を更新する（Ｓ１３）。
【0051】
図８（Ｂ）は、稼働プロセスおよび待機プロセスが実行する動作状況確認処理を示している。この処理も定期的に実行される。稼働プロセスには、他のプロセスと接続があるものがある。他のプロセスとの接続とは、図５、図６に示したように、呼制御プロセスＢ１と拠点間接続プロセスＢｒ、呼制御プロセスＢ２と拠点間プロセスＢｒがそれぞれ接続され音声信号等の送受信を行う形態である。自身のプロセスがこのような形態で他のプロセスで接続されている場合、他のプロセスの動作状況に合わせて接続先を切り換える等の処理が行われる。プロセスは、所定の時間ごとに管理サーバ２０に各プロセスの動作状況を問い合わせる（Ｓ１６）。この問い合わせに応答して管理サーバ２０から各プロセスの動作状況が返信されてくると（Ｓ１７）、接続先のプロセスがダウンして待機プロセスが稼働プロセスに切り換わっているなど、接続先の動作状況に変更があるかを判断する（Ｓ１８）。接続先の動作状況に変更があった場合には（Ｓ１８でＹＥＳ）、現在の動作状況に合わせて接続先を切り換えて（Ｓ１９）、処理を終了する。他のプロセスと接続がない場合、または、接続先の変更がない場合（Ｓ１８でＮＯ）には、そのまま処理を終了する。
【0052】
例えば、図６（Ｂ）のように、呼制御プロセスＢ２－１がダウンした場合、拠点間接続プロセスＢｒ－１は、管理サーバ２０－１に動作状況を問い合わせたときに、呼制御プロセスＢ２－１がダウンしていること、および、その待機プロセスであった呼制御プロセスＢ２－２が稼働を開始していることを知る。そこで、呼制御プロセスＢ２－２に対するプロセス間通信を開始することにより、呼制御プロセスＢの稼働を維持する。
【0053】
図８（Ｂ）における管理サーバ２０への問い合わせは、同じ側の管理サーバ２０、すなわち、このプロセスが実行されている呼制御サーバ２１と同じサーバシステム２－１、２－２内に設置されている管理サーバ２０に対して行うが、この管理サーバ２０が応答しなかった場合は、反対側の管理サーバ２０（このプロセスが実行されている呼制御サーバ２１と異なるサーバシステム２－１、２－２内に設置されている管理サーバ２０）に再度問い合わせる。
【0054】
また、管理サーバ２０への問い合わせは、一定時間毎に行ってもよいが、プロセス間通信の変更や待機プロセスの動作モードの切り換え（図８（Ｄ）参照）が発生するごとに管理サーバ２０に対して各プロセスの動作状況（通信相手）を問い合わせるようにしてもよい。
【0055】
図８（Ｃ）は、待機プロセスの動作通知処理を示している。待機プロセスは、定期的（たとえば１分毎）に、両側の管理サーバ２０－１、２０－２に対して動作通知を送信する（Ｓ２１）。送信した動作通知の有効期限は、次の送信予定時刻よりも長く設定されている。この有効期限で、自身のステータステーブルの動作通知の有効期限を更新する（Ｓ２２）。
【0056】
図８（Ｄ）は、待機プロセスの動作状況確認処理を示している。この処理も定期的に実行される。待機プロセスは、ステータステーブルを参照して稼働プロセスの動作通知が有効であるかを判断する（Ｓ２４）。稼働プロセスからの動作通知の有効期限が切れている場合（Ｓ２４でＮＯ）、稼働プロセスはダウンしていると判断し、図８（Ｂ）の処理で取得していた各プロセスの動作状況に合わせて接続先等を設定して、ダウンした稼働プロセス（メインプロセス）に代わって自身を稼働プロセスとして動作を開始する（Ｓ２５）。同時にステータステーブルの動作モードを稼働モード（active）に書き換える（Ｓ２６）。例えば、図６（Ｃ）のように、拠点間接続プロセスＢｒ－１がダウンした場合、拠点間接続プロセスＢｒ－２が、稼働している呼制御プロセスＢ１－１、Ｂ２－１とプロセス間通信を行う稼働を開始する。
【0057】
稼働プロセスとして動作を開始したのち、管理サーバ２０に対して、動作モードを変更した旨を通知する（Ｓ２７）。この動作モード変更通知は、動作通知を兼ねている。一方、Ｓ２４において、稼働プロセスが正常に動作している場合、すなわち、動作通知の有効期限が切れていない場合は（Ｓ２４でＹＥＳ）、Ｓ２４で動作を終了する。
【0058】
図９は、管理サーバ２０に設定される管理テーブルの例を示す図である。図９には、管理テーブルのうち、呼制御サーバ２１－１、２１－２のプロセスに関する部分のみ記載する。プロビジョニングサーバ２２－１、２２－２の各プロセスについても同様のテーブルが設けられている。
【0059】
管理テーブルには、メインサーバである（第一）呼制御サーバ２１－１、および、サブサーバである（第二）呼制御サーバ２１－２で実行される全てのプロセスの情報が記憶されている。管理テーブルには、プロセスごとに、動作通知有効期限、動作設定、動作モードが記憶される。動作通知有効期限の欄には、プロセスから送られてきた動作通知に記載されていた有効期限が記憶される。管理サーバ２０が、この有効期限以内にプロセスから新たな動作通知を受信した場合、この有効期限は、その新たな動作通知に記載されている有効期限に更新される。動作設定の欄には、メインプロセス（メイン）／サブプロセス（サブ）のいずれかの設定情報が記憶される。動作モードの欄には、稼働モード（active）／待機モード（stadby）のいずれかが記憶される。
【0060】
各プロセスから、動作通知有効期限内に新たな動作通知が送られてこなかった場合には、そのプロセスがダウンしている（動作通知を送信する機能が失われている）として、動作モードをダウンに書き換える。正常に動作しているプロセスから定期的に全プロセスの動作状況の問い合わせがあるため、この問い合わせに応答して、正常に稼働しているプロセス、正常に待機しているプロセス、および、ダウンしているプロセス等の情報を返信する。各プロセスは、この動作状況に応じて接続先の切り換えなどを行う。また、管理サーバ２０は、稼働プロセスのダウンに対応して稼働を開始したプロセスから、稼働を開始した旨の通知を受信した場合、管理テーブルのこのプロセスの動作モードを稼働モードに書き換える。
【0061】
なお、管理テーブルに、プロセス間通信を行うプロセス（例えば呼制御プロセスＢ１－１、Ｂ１－２、Ｂｒ－１など）について、通信相手である接続先プロセスを記憶するエリアを設けてもよい。
【0062】
図１０は管理サーバ２０の動作を表すフローチャートである。図１０（Ａ）は、有効期限更新動作を示すフローチャートである。いずれかのプロセスから動作通知を受信すると（Ｓ３１）、管理テーブルのそのプロセスの動作通知有効期限を更新する（Ｓ３２）。なお、プロセスが起動し、初めて動作通知を送信した場合、管理サーバ２０は、このプロセスを管理テーブルに登録して動作通知有効期限を書き込む。
【0063】
図１０（Ｂ）は、プロセスから稼働開始通知を受信した場合の動作を示すフローチャートである。待機プロセスから（ダウンした稼働プロセスに代わって）稼働を開始した旨の通知を受信すると（Ｓ３５：図８（Ｄ）のＳ２７参照）、管理テーブルのそのプロセスの動作モードを稼働モード（active）に変更する（Ｓ３６）。この稼働開始通知は動作通知を兼ねているので、このプロセスの動作通知有効期限を更新する（Ｓ３７）。そして、稼働プロセスが変更になった旨をシステム管理者の端末（パーソナルコンピュータ）に対してメール等でアラートを送信する（Ｓ３８）。
【0064】
図１０（Ｃ）は、テーブルメンテナンス動作を示すフローチャートである。定期的にテーブル上の全てのプロセスについて以下の処理を実行する。プロセスの動作通知の有効期限を読み出す（Ｓ４１）。そしてこの有効期限を現在時刻と比較し、有効期限切れになっている場合には（Ｓ４２でＹＥＳ）、動作モードをダウンに書き換えて（Ｓ４４）、次のプロセスのメンテンスに進む。なお、Ｓ４４において、ダウン状態が継続していて既に動作モードがダウンに書き換えられている場合でも、動作モードのダウンへの書き換えが行われるが、既にダウンモードの場合は書き換えないようにしてもよい。
【0065】
動作通知の有効期限が切れていなければ（Ｓ４２でＮＯ）、現在の動作モードがダウンであるかを判断する（Ｓ４５）。動作モードがダウンである場合には（Ｓ４５でＹＥＳ）、動作モードを待機モード（standby）に書き換えたのち（Ｓ４６）、次のプロセスのメンテナンスに進む。動作通知の有効期限が切れておらず（Ｓ４２でＮＯ）且つ動作モードがダウンでない場合には（Ｓ４５でＮＯ）、このプロセスに対する処理を終了して、次のプロセスのメンテナンスに進む。
【0066】
Ｓ４６に示すように、一度ダウンしたプロセスが復旧した場合、現在稼働中のプロセスのダウンに備えた待機プロセスとして動作する。なお、予め動作設定がメインプロセスとされているプロセスが復旧した場合には、そのとき稼働している対応するサブプロセスを待機モードに変更させて、メインプロセスを稼働プロセスに復帰させてもよい。
【0067】
図１１（Ａ）、（Ｂ）に、クライアントＢの呼制御プロセスが、図６（Ｂ）の状態になった場合、図６（Ｃ）の状態になった場合の管理テーブルの記憶内容を示す図である。この図では、各プロセスの動作モードの欄のみを表示している。図６（Ｂ）の状態では、呼制御プロセスＢ２－１がダウンし、これに代えて呼制御プロセスＢ２－２が稼働しているため、図１１（Ａ）に示す管理テーブルにおいても、呼制御プロセスＢ２－１の動作モードがダウン（down）に書き換えられ、これに代えて呼制御プロセスＢ２－２の動作モードが稼働モード（active）になっている。
【0068】
また、図６（Ｃ）の状態では、呼制御サーバ２１－１の拠点間接続プロセスＢｒ－１がダウンし、これに代えて呼制御サーバ２１－２の拠点間接続プロセスＢｒ－２が稼働しているため、図１１（Ｂ）に示す管理テーブルにおいても、拠点間接続プロセスＢｒ－１の動作モードがダウン（down）に書き換えられ、これに代えて拠点間接続プロセスＢｒ－２の動作モードが稼働モード（active）になっている。
【0069】
このように、各プロセスの動作モードの変更に対応して管理テーブルを更新し、他のプロセスや通信端末４からの問い合わせに対しては、このテーブルの内容を送信する。これにより、プロセスが他のプロセスの状態を知ることができるようになり、プロセス間通信の接続先を変更することや、通信端末４が、アクセスする呼制御プロセスを変更することが容易になる。
【0070】
なお、管理サーバ２０は、ウェブサーバとしても機能する。管理テーブルの内容やその更新履歴等をＬＡＮ５またはＬＴＥネットワーク３経由で管理者のパーソナルコンピュータに映すことができる。
【0071】
図１０（Ｄ）は、プロセスからの問い合わせに対応する処理を示すフローチャートである。プロセスから動作状況の問い合わせがあると（Ｓ５０：図８（Ｂ）のＳ１６、図８（Ｄ）のＳ２５参照）、問い合わせのあったプロセスに対して、各プロセスの動作状況（管理テーブルの内容）を送信する（Ｓ５１）。これにより、プロセスは他のプロセスの動作状況を知ることができる。
【0072】
図１０（Ｅ）は、通信端末４からの問い合わせに対応する処理を示すフローチャートである。通信端末４から稼働中の呼制御プロセスの問い合わせがあると（Ｓ５４）、その通信端末４が所属するクライアントの呼制御プロセスのうち稼働している側の呼制御プロセスを通知する（Ｓ５５）。これにより、稼働していた呼制御プロセスがダウンして稼働中呼制御プロセスが切り換わった場合、通信端末４がその切り換わった呼制御プロセスにアクセスすることが可能になる。
【0073】
図１２は、通信端末４のメモリに記憶されるプロビジョニングデータの一例を示す図である。プロビジョニングデータは、メインプロビジョニングサーバアドレス、サブプロビジョニングサーバアドレス、メイン呼制御サーバアドレス、サブ呼制御サーバアドレス、および、各種設定情報を含んでいる。
【0074】
メインプロビジョニングサーバアドレスは、プロビジョニングサーバ２２－１のＩＰアドレスおよびポート番号を含んでいる。サブプロビジョニングサーバアドレスは、プロビジョニングサーバ２２－２のＩＰアドレスおよびポート番号を含んでいる。これらのアドレスは、プロビジョニングサーバ２２から与えられてもよく、事前に通信端末４に記憶されていてもよい。
【0075】
メイン呼制御サーバアドレスは、呼制御サーバ２１－１のＩＰアドレス、および、この通信端末４が所属するクライアントのプロセスのポート番号を含んでいる。サブ呼制御サーバアドレスは、プロビジョニングサーバ２１－２のＩＰアドレス、および、この通信端末４が所属するクライアントのプロセスのポート番号を含んでいる。メインプロビジョニングサーバアドレス／サブプロビジョニングサーバアドレス、および、メイン呼制御サーバアドレス／サブ呼制御サーバアドレスには、どのアドレスのプロセスが稼働中であるかを示す稼働中フラグが設けられている。デフォルトでは、メインプロビジョニングサーバアドレスおよびメイン呼制御サーバアドレスの稼働中フラグがセットされる。
【0076】
各種設定情報は、たとえば、通信端末４の呼出ＩＤ、通知音設定（着信時の通知音の選択情報）、イヤホン設定（イヤホンマイクが接続された場合にフル・デュプレックス通信を行うか否かの設定情報）、アドレス帳（呼出可能な通信端末４の呼出ＩＤリスト）、音量設定（通話音の音量設定情報）などである。
【0077】
図１３は、通信端末４の動作を示すフローチャートである。図１３（Ａ）は、プロビジョニング動作を示すフローチャートである。この動作は通信端末４の電源オン時などに実行される。通信端末４の制御部４０が、メインサーバであるプロビジョニングサーバ２２－１にアクセスして、プロビジョニングデータの送信を要求する（Ｓ６１）。一定時間以内にプロビジョニングサーバ２２－１から応答があった場合には（Ｓ６２でＹＥＳ）、このサーバからプロビジョニングデータを受信して（Ｓ６５）、プロビジョニングを実行する（Ｓ６６）。もし、一定時間以内にプロビジョニングサーバ２２－１から応答がなかった場合には（Ｓ６２でＮＯ）、サブサーバであるプロビジョニングサーバ２２－２にアクセスして、プロビジョニングデータの送信を要求し（Ｓ６３）、稼働中フラグをサブプロビジョニングサーバ２２－２側に切り換える（Ｓ６４）。そして、サブプロビジョニングサーバ２２－２からプロビジョニングデータを受信する（Ｓ６５）。もし、２つのプロビジョニングサーバ２２－１、２２－２が同時にダウンした場合、通信端末４は、以前に取得したプロビジョニングデータを用いて接続を試みるようにすればよい。
【0078】
図１３（Ｂ）は、通信端末４の音声通信時の動作を示すフローチャートである。ＰＴＴボタン２２０が押されるとこの動作が開始される。通信端末４の制御部４０が、メインの呼制御サーバ２１－１のこの通信端末４に割り当てられた呼制御プロセス（仮想サーバ）に音声信号を送信する（Ｓ７１）。一定時間以内に呼制御サーバ２１－１のプロセスから応答があった場合には（Ｓ７２でＹＥＳ）、音声通信を開始する。もし、一定時間以内に呼制御サーバ２１－１のプロセスから応答がなかった場合には（Ｓ７２でＮＯ）、通信不可である旨の表示を行う等して動作を停止する。この通信ダウンの状態は、それまで稼働していた呼制御プロセスがダウンしたのち、図１３（Ｃ）の稼働プロセス確認前に通信が開始された場合に発生し得る状態である。
【0079】
図１３（Ｃ）は、通信端末４が、稼働している呼制御プロセスを問い合わせる動作を示すフローチャートである。この処理は定期的に行われるが、図１３（Ｂ）のＳ７２で稼働中としていた呼制御プロセスから応答がなかったときに臨時に実行されるようにしてもよい。通信端末４の制御部４０は、管理サーバ２０に、この通信端末４を収容している稼働中の呼制御プロセスを問い合わせる（Ｓ７３）。これに応答して管理サーバから稼働プロセスの情報が送られてくるので、これを受信し（Ｓ７４：図１０（Ｅ）Ｓ５５参照）、稼働プロセスに切り換えられたかを判断する（Ｓ７５）。切り換えられた場合は（Ｓ７５でＹＥＳ）、呼制御サーバの稼働中フラグを稼働プロセス側（サブ呼制御サーバ側）に切り換える（Ｓ７６）。これ以後、通信端末４は、音声通信が発生した場合は、稼働プロセスに切り換わった呼制御プロセスに対してアクセスするようになる。
【0080】
なお、通信端末４は、運用開始時および定期的に、さらにはエリア移動などの機会ごとに、稼働モードの呼制御サーバ２０に対して、登録を要求するメッセージ（レジストメッセージ）を送信する。稼働モードの呼制御サーバ２０は、このメッセージを受信することにより、運用中の通信端末を把握し、この通信端末４を端末テーブルに登録することができる。通信端末４は、このレジストメッセージを稼働モードとされる呼制御サーバ２０－１／２に送信しても応答がない場合、この呼制御サーバ２０－１／２はダウンしているとして、反対側の呼制御サーバ２０－２／１に、改めてレジストメッセージを送信する。
【0081】
図１０、図１３に示すフローチャートでは、通信端末４は、定期的に管理サーバ２１に対して、稼働モードの呼制御プロセスを問い合わせているが、上記のレジストメッセージに対する応答の有無によって稼働モードの呼制御プロセスがどちらであるかを解決してもよい。
【0082】
また、待機モードで動作している呼制御プロセスが、通信端末からレジストメッセージを受信した場合、レジストメッセージの送信先を反対側の（稼働モードの）呼制御プロセスに切り換えて再送信すべき旨の応答を通信端末に返信するようにしてもよい。
【0083】
レジストメッセージに対する応答の有無で稼働モードの呼制御サーバ２０を判断するようにすれば、通信端末４の台数が多い場合でも、管理サーバ２１に対する問い合わせが頻発することがなくなり、管理サーバ２１の負荷を軽減することができる。ただし、一般的にレジストの間隔は、図１３（Ｃ）等に示した問い合わせの間隔よりも長いため、通信端末４が稼働モードの呼制御プロセスの交代を知るまでの時間が長くなる。
【0084】
以上は、呼制御サーバ２１－１、２１－２のプロセスがダウンした場合の呼制御動作の切り換えについて説明した。プロセスがダウンしていない場合でも、サーバシステム２－１とサーバシステム２－２とをつなぐＶＰＮ６がダウンする場合がある。図１４、図１５を参照して、ＶＰＮ６がダウンした場合の縮退動作について説明する。
【0085】
図１４は、クライアントＢの呼制御プロセスにおいて、ＶＰＮ６がダウンした場合のプロセス間の接続形態を示している。管理サーバ２０－１、２０－２、呼制御サーバ２１－１、２１－２、プロビジョニングサーバ２２－１、２２－２は正常に動作しており、呼制御プロセスＢ１－１、Ｂ２－１、Ｂ１－２、Ｂ２－２、および、拠点間接続プロセスＢｒ－１、Ｂｒ－２もそれぞれ正常に動作しているものとする。
【0086】
ＶＰＮ６がダウンすると、サーバシステム２－１、２－２間の通信が不可能になる。この場合でも、サーバシステム２－１の管理サーバ２０－１、呼制御サーバ２１－１、プロビジョニングサーバ２２－１は正常に動作しているため、ＬＴＥネットワーク３－１を介してサーバシステム２－１にアクセスする通信端末４（４－１、４－２）に対して呼制御プロセスＢなどのサービスを継続することが可能である。
【0087】
一方、サーバシステム２－２においても、管理サーバ２０－２、呼制御サーバ２１－２、プロビジョニングサーバ２２－２は正常に動作おり、且つ、サーバシステム２－１の各プロセスからの動作通知が届かなくなるため、管理サーバ２０－２および呼制御サーバ２１－２、プロビジョニングサーバ２２－２の各プロセスは、サーバシステム２－１側の各プロセスが全てダウンしたと判断し、呼制御サーバ２１－２、プロビジョニングサーバ２２－２の各プロセスは、待機モードから稼働モードに切り換わってクライアントＢに対する呼制御プロセスを稼働させる。そして、呼制御サーバ２１－２で立ち上げられた呼制御プロセスは、ＬＴＥネットワーク３－２を介してサーバシステム２にアクセスする通信端末４（４－３、４－４）に対してサービスを提供する。
【0088】
このように、ＶＰＮ６がダウンすると、ＬＴＥネットワーク３－１、３－２をつなぐ通信は不可能になるが、各ＬＴＥネットワーク３－１、３－２で呼制御プロセスＢが稼働モードとなり、それぞれの範囲でサービスを提供できるようになる。
【0089】
このとき、サーバシステム２－１内の管理サーバ２０－１の管理テーブルは、図１５（Ａ）に示すように、呼制御サーバ２１－１の各プロセスが全て稼働モード（active）になっており、呼制御サーバ２１－２の各プロセスの動作モードが全てダウン（down）になっている。一方、サーバシステム２－２内の管理サーバ２０－２の管理テーブルは、図１５（Ｂ）に示すように、呼制御サーバ２１－１の各プロセスの動作モードが全てダウン（down）になっており、呼制御サーバ２１－２の各プロセスが全て稼働モード（active）になっている。なお、呼制御プロセスＣは、冗長化されておらず、呼制御サーバ２１－１のみで実行されるため、ＶＰＮ６がダウンした場合、（図５の例には記載していないが、）ＬＴＥネットワーク３－２のエリアにクライアントＣの通信端末４があった場合には、この通信端末４は通信することができなくなる。
【0090】
この縮退動作は、ＶＰＮ６のダウンによって相手側プロセスからの動作通知が途絶えたことに対応する動作として、図８に示した呼制御サーバ２１－１、２１－２の各プロセスの動作、および、図１０に示した管理サーバ２０－１、２０－２の動作によって実現可能である。
【0091】
この実施形態では、呼制御サーバ２１－１をメインサーバ、呼制御サーバ２１－２をサブサーバとして、呼制御サーバ２１－１で実行される各プロセスをメインとして動作設定しているが、メインとして動作設定されるプロセスを呼制御サーバ２１－１、２１－２に分散させてもよい。
【0092】
以上の実施形態では、サーバシステム２、ネットワーク３がそれぞれ２つずつ設けられている構成について説明したが、第３、第４、・・・のサーバシステム、ネットワークを有する構成であってもよい。そのようにすることにより、さらなる冗長化が可能になる。
【0093】
以上のように、この実施形態によれば、障害を起こしてダウンしたプロセスがあっても、それのためにサーバ全体を交代させる必要がないため、他のプロセスに対する影響を最小限にすることができる。また、専用の管理サーバ２０を設置して各プロセスの動作状況を管理および問い合わせに答えることができるようにしたことにより、プロセスに障害が発生してもその障害を他のプロセスが知り、プロセス間の通信先を切り換えるなどの対応が可能になり、プロセス間通信を維持することができるようになる。
【符号の説明】
【0094】
１ 音声通信システム
２（２－１、２－２） サーバシステム
２０（２０－１、２０－２） 管理サーバ
２１（２１－１、２１－２） 呼制御サーバ
２２（２２－１、２２－２） プロビジョニングサーバ
３（３－１、３－２） ＬＴＥネットワーク
４（４－１～４） 通信端末
２（２－１、２－２） サーバシステム
２０（２０－１、２０－２） 管理サーバ
２１（２１－１、２１－２） 呼制御サーバ
２２（２２－１、２２－２） プロビジョニングサーバ
３（３－１、３－２） ＬＴＥネットワーク
４（４－１～４） 通信端末
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】