(57)【要約】【課題】サーバシステムを通信経路の障害に対して堅牢にする。【解決手段】それぞれ異なる通信事業者の第１ネットワーク３−１、第２ネットワーク３−２上に、第１サーバシステム２−１、第２サーバシステム２−２を設置する。これら第１、第２サーバシステムは、専用線６で互いに接続される。第１ネットワークに障害が発生しても、第２ネットワーク経由の通信を維持することができ、第２ネットワークに障害が発生しても第１ネットワーク経由の通信を維持することができる。また、専用線に障害が発生した場合には、第１、第２ネットワーク内でそれぞれ縮退モードで動作することができる。【選択図】図１６
2020150498.tif 000002
【特許請求の範囲】
【請求項１】
第１ネットワーク上に第１サーバシステムが設置され、
前記第１ネットワークから分離された第２ネットワーク上に第２サーバシステムが設置され、
前記第１サーバシステムおよび第２サーバシステムは、前記ネットワークとは別の通信線で互いに接続されており、
前記第１サーバシステムは第１呼制御サーバを備え、前記第２サーバシステムは第２呼制御サーバを備え、
前記第１呼制御サーバおよび第２呼制御サーバは、前記第１、第２ネットワークに接続される複数の通信端末間の音声通信を制御する呼制御プロセスを並行して実行し、
前記通信端末の音声通信の信号は、前記第１、第２ネットワークおよび前記通信線を経由して転送される
音声通信システム。
【請求項２】
前記第１ネットワークおよび第２ネットワークは、それぞれ異なる通信事業者による閉域ネットワークである請求項１に記載の音声通信システム。
【請求項３】
前記通信端末として、第１ネットワークに接続可能な第１通信端末、および、第２ネットワークに接続可能な第２通信端末が設けられ、
前記第１通信端末は、前記第１ネットワークを介して前記第１呼制御サーバにアクセス可能であるとともに、前記第１ネットワークおよび前記通信線を介して前記第２呼制御サーバにアクセス可能であり、
前記第２通信端末は、前記第２ネットワークを介して前記第２呼制御サーバにアクセス可能であるとともに、前記第２ネットワークおよび前記通信線を介して前記第１呼制御サーバにアクセス可能であり、
前記呼制御プロセスを並行して実行する第１呼制御サーバおよび前記第２呼制御サーバのうち、一方の呼制御サーバが、実際に音声通信を制御する稼働モードで動作し、他方の呼制御サーバが、前記稼働モードの呼制御サーバが正常に動作しないとき、該正常に動作しない呼制御サーバに代わって稼働モードとなる待機モードで動作し、
前記稼働モードの呼制御サーバである稼働サーバは、前記待機モードの呼制御サーバである待機サーバに対して、自身が正常に動作していることを通知するメッセージである動作通知を、前記通信線を介して定期的に送信し、前記待機サーバは、前記動作通知を定期的に受信している間、前記待機モードを維持し、
前記通信端末は、前記稼働モードの呼制御サーバにアクセスして、他の通信端末と音声通信を行う、
請求項１または請求項２に記載の音声通信システム。
【請求項４】
前記通信線の障害により、前記第１、第２サーバシステム間の通信が不可能となった場合、
前記稼働サーバは、稼働モードを維持し、
前記待機サーバは、自身の動作モードを稼働モードに切り換えて、音声通信の制御を開始し、
前記稼働サーバ側のネットワークに接続される通信端末は、前記稼働サーバにアクセスして、該稼働サーバにアクセスする他の通信端末と音声通信を行い、
前記待機サーバ側のネットワークに接続される通信端末は、稼働モードになった前記待機サーバにアクセスして、該稼働モードになった待機サーバにアクセスする他の通信端末と音声通信を行う
請求項３に記載の音声通信システム。
【請求項５】
前記第１サーバシステムは、第１、第２呼制御サーバの動作状況を記憶する管理テーブルを有する第１管理サーバをさらに備え、前記第２サーバシステムは、第１、第２呼制御サーバの動作状況を記憶する管理テーブルを有する第２管理サーバをさらに備え、
第１呼制御サーバおよび第２呼制御サーバは、前記第１管理サーバおよび第２管理サーバに対して、定期的に前記動作通知を送信し、
前記第１または第２呼制御サーバは、自身の動作モードを待機モードから稼働モードに切り換えたとき、その旨を通知するメッセージであるモード切換通知を前記第１管理サーバおよび第２管理サーバに送信し、
前記第１管理サーバおよび前記第２管理サーバは、前記動作通知および前記モード切換通知によって取得した各呼制御サーバの動作状況を前記管理テーブルに記憶し、
前記通信端末は、自身が接続するネットワーク上にある管理サーバに、第１呼制御サーバ、第２呼制御サーバのいずれが稼働サーバであるかの問い合わせを行い、回答された呼制御サーバにアクセスする
請求項１乃至請求項５に記載の音声通信システム。
【請求項６】
第１ネットワーク上に設置された第１呼制御サーバ、および、第２ネットワーク上に設置された第２呼制御サーバを有し、前記第１呼制御サーバ、第２呼制御サーバ間が前記ネットワークと異なる通信線で接続された音声通信システムにおいて、
前記通信線を介した通信が可能な通常時、前記第１サーバを、実際に呼制御サービスを提供する稼働モードで動作させ、前記第２サーバを、前記稼働モードの第１サーバがダウンしたとき、該第１サーバに代わって稼働モードとなる待機モードで動作させ、
前記通信線がダウンした障害時、前記第２呼制御サーバを、前記第１呼制御サーバとともに稼働モードで動作させる
呼制御サーバの冗長化方法。
【請求項７】
前記稼働モードの第１呼制御サーバは、前記待機モードの第２呼制御サーバに対して、自身が正常に動作していることを通知するメッセージである動作通知を定期的に送信し、
前記第２呼制御サーバは、前記第１呼制御サーバから前記動作通知を定期的に受信している間、待機モードを継続し、前記第１呼制御サーバから動作通知を受信しなくなると、自身の動作モードを待機モードから稼働モードに切り換える
請求項６に記載の呼制御サーバの冗長化方法。
【請求項８】
第１ネットワークに接続可能な第１通信端末、および、第２ネットワークに接続可能な第２通信端末を設け、
前記通常時は、前記第１通信端末は、前記第１ネットワークを介して前記稼働モードの第１呼制御サーバにアクセスし、前記第２通信端末は、前記第２ネットワークおよび前記通信線を介して前記稼働モードの第１呼制御サーバにアクセスし、
前記障害時は、前記第１通信端末は、前記第１ネットワークを介して前記稼働モードの第１呼制御サーバにアクセスし、前記第２通信端末は、前記第２ネットワークを介して前記稼働モードの第２サーバにアクセスする
請求項６または請求項７に記載の呼制御サーバの冗長化方法。
【請求項９】
前記第１ネットワーク上に第１管理サーバを設置し、前記第２ネットワーク上に第２管理サーバを設置し、
前記第１呼制御サーバおよび前記第２呼制御サーバに、前記第１および第２管理サーバに対して、定期的に前記動作通知を送信させるとともに、自身の動作モードが待機モードから稼働モードに切り換わったとき、その旨を通知するメッセージであるモード切換通知を前記第１および第２管理サーバに送信させ、
前記第１および第２通信端末は、自身が接続可能なネットワーク上にある管理サーバに、第１呼制御サーバ、第２呼制御サーバのいずれが稼働サーバであるかの問い合わせを行い、回答された呼制御サーバにアクセスする
請求項６乃至請求項８のいずれかに記載の呼制御サーバの冗長化方法。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、ネットワークを経由して行われる音声通信を制御する音声通信システムに関し、特にそのサーバシステムの冗長化に関する。
【背景技術】
【０００２】
サーバシステムを冗長化するにあたり、サーバや通信経路を多重化し、１つを稼働（active）、他方を待機（standby）とした環境を構築することは一般的である。このような冗長化されたシステムをクラウド上に設置することも可能である（特許文献１参照）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１５−１５３２５９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかし、単一の通信事業者が提供するサービスの場合、通信経路全体に障害が発生した場合などには、稼働側から待機側への切り換えが期待できない可能性があり、堅牢性に不安が残る。
【０００５】
この発明の目的は、サーバシステムを一部サーバの障害や通信経路の障害に対して堅牢な音声通信システムおよび呼制御サーバの冗長化方法を提供することにある。
【課題を解決するための手段】
【０００６】
本発明の音声通信システムは、第１ネットワーク上に設置された第１サーバシステム、および、第１ネットワークから分離された第２ネットワーク上に設置された第２サーバシステムを有する。これら第１、第２サーバシステムは、ネットワークとは別の通信線で互いに接続されている。第１サーバシステムは第１呼制御サーバを備え、前記第２サーバシステムは第２呼制御サーバを備えている。第１呼制御サーバおよび第２呼制御サーバは、第１および第２ネットワークに接続される複数の通信端末間の音声通信を制御する呼制御プロセスを並行して実行する。通信端末の音声通信の信号は、第１、第２ネットワークおよび通信線を経由して通信端末間を転送される。なお、第１および第２ネットワークは、それぞれ異なる通信事業者による閉域ネットワークであってもよい。
【０００７】
本発明の呼制御サーバの冗長化方法は、第１ネットワーク上に設置された第１呼制御サーバ、および、第２ネットワーク上に設置された第２呼制御サーバを有し、第１呼制御サーバ、第２呼制御サーバ間が前記ネットワークと異なる通信線で接続された音声通信システムにおいて、各サーバに以下の動作を行わせる。通信線を介した通信が可能な通常時に、第１サーバを、実際に呼制御サービスを提供する稼働モードで動作させ、第２サーバを、稼働モードの第１サーバがダウンしたとき、該第１サーバに代わって稼働モードとなる待機モードで動作させる。通信線がダウンした障害時、第２呼制御サーバを、第１呼制御サーバとともに稼働モードで動作させる。
【０００８】
異なるネットワーク上にサーバシステムを設置し、それらをＶＰＮなどの通信線（専用線）で接続することで、サーバを冗長化した。これにより、一方のネットワークが全面的に障害に陥った場合でも、通信機能を確保することができる。
【０００９】
通信端末は、第１ネットワークに接続可能な第１通信端末、および、第２ネットワークに接続可能な第２通信端末があり、第１通信端末は、第１ネットワークを介して第１呼制御サーバにアクセス可能であるとともに、第１ネットワークおよび通信線を介して第２呼制御サーバにアクセス可能である。第２通信端末は、第２ネットワークを介して第２呼制御サーバにアクセス可能であるとともに、第２ネットワークおよび通信線を介して第１呼制御サーバにアクセス可能である。呼制御プロセスを並行して実行する第１呼制御サーバおよび第２呼制御サーバのうち、一方の呼制御サーバが、実際に音声通信を制御する稼働モードで動作し（稼働サーバ）、他方の呼制御サーバが、稼働モードの呼制御サーバが正常に動作しないとき、該正常に動作しない呼制御サーバに代わって稼働モードとなる待機モードで動作する（待機サーバ）。稼働サーバは、待機モードの呼制御サーバである待機サーバに対して、自身が正常に動作していることを通知するメッセージである動作通知を、通信線を介して定期的に送信する。待機サーバは、動作通知を定期的に受信している間、待機モードを維持する。通信端末は、稼働モードの呼制御サーバにアクセスして他の通信端末と音声通信を行う。
【００１０】
異なるネットワーク上にサーバシステムを設置した場合でも、通信線を介して音声信号の交換が可能であるため、一方のサーバシステムの呼制御サーバを稼働サーバとし、他方のサーバシステムの呼制御サーバを待機サーバとして冗長構成とすることが可能である。
【００１１】
通信線の障害により、第１、第２サーバシステム間の通信が不可能となった場合、稼働サーバは、稼働モードを維持し、待機サーバは、自身の動作モードを稼働モードに切り換えて、音声通信の制御を開始する。すなわち、両方とも稼働モード（active）となる。稼働サーバ側のネットワークに接続される通信端末は、稼働サーバにアクセスして、同じ稼働サーバにアクセスする他の通信端末と音声通信を行う。一方、待機サーバ側のネットワークに接続される通信端末は、稼働モードになった待機サーバにアクセスして、この稼働モードになった待機サーバにアクセスする他の通信端末と音声通信を行う。
【００１２】
サーバシステム間を接続する通信線に障害が起きた場合に、第１呼制御サーバ、第２呼制御サーバの両方を稼働モード（active）で動作させることで、第１ネットワーク内、および、第２ネットワーク内での通信は維持することができる。
【００１３】
第１サーバシステムは第１管理サーバをさらに備え、第２サーバシステムは第２管理サーバをさらに備える。第１管理サーバ、第２管理サーバは、ともに、第１、第２呼制御サーバの動作状況を記憶する管理テーブルを有する。第１呼制御サーバおよび第２呼制御サーバは、第１管理サーバおよび第２管理サーバに対して、定期的に動作通知を送信する。また、第１呼制御サーバおよび第２呼制御サーバは、自身の動作モードを待機モードから稼働モードに切り換えたとき、その旨を通知するメッセージであるモード切換通知を第１管理サーバおよび第２管理サーバに送信する。第１管理サーバおよび第２管理サーバは、動作通知およびモード切換通知によって取得した各呼制御サーバの動作状況、すなわち、どの呼制御サーバが稼働モードであるかを含む状況を管理テーブルに記憶する。通信端末は、自身が接続するネットワーク上にある管理サーバに、第１呼制御サーバ、第２呼制御サーバのいずれが稼働サーバであるかの問い合わせを行い、回答された呼制御サーバにアクセスする。
【００１４】
管理サーバを設置することで、通信端末が稼働サーバを探しやすくなる。また、両方のサーバシステムに管理サーバを設置することで、通信線が遮断された場合でも、両ネットワークに接続する通信端末がそれぞれの側の管理サーバに問い合わせることが可能になる。
【発明の効果】
【００１５】
本発明によれば、第１、第２サーバシステムをそれぞれ異なる第１、第２ネットワーク上に設置したことにより、サーバの障害や通信経路の障害に対して堅牢にすることができる。
【図面の簡単な説明】
【００１６】
【図１】図１は、この発明の実施形態である音声通信システムの構成図である。
【図２】図２は、音声通信システムのサーバのブロック図である。
【図３】図３は、通信端末のブロック図である。
【図４】図４は、呼制御サーバ、プロビジョニングサーバのパーテーションおよび各パーテーションで実行されるプロセス（仮想サーバ）を示す図である。
【図５】図５は、全てのプロセスが正常に動作している場合の各プロセスおよび通信端末の接続形態を示す図である。
【図６】図６は、一部のプロセスがダウンした場合の各プロセスおよび通信端末の接続形態を示す図である。
【図７】図７は、各プロセスに設けられるステータステーブルを示す図である。
【図８】図８は、呼制御サーバの動作を示すフローチャートである。
【図９】図９は、管理サーバに設けられる管理テーブルを示す図である。
【図１０】図１０は、管理サーバの動作を示すフローチャートである。
【図１１】図１１は、一部のプロセスがダウンした場合の管理テーブルの記憶内容を示す図である。
【図１２】図１２は、通信端末に設定されるプロビジョニングデータの例を示す図である。
【図１３】図１３は、通信端末の動作を示すフローチャートである。
【図１４】図１４は、サーバシステム間をつなぐＶＰＮがダウンした場合の呼制御プロセスと端末装置との接続形態を示す図である。
【図１５】図１５は、サーバシステム間をつなぐＶＰＮがダウンした場合の管理テーブルの記憶内容を示す図である。
【図１６】図１６は、２つのＬＴＥネットワークのうち、一方がダウンした場合の動作形態を示す図である。
【発明を実施するための形態】
【００１７】
図１は、この発明の実施形態である音声通信システム１の構成を示す図である。音声通信システム１は、複数（この実施形態では２つ）のサーバシステム２（２−１,２−２）および複数の通信端末４を有している。サーバシステム２と通信端末４とは、複数（この実施形態では２つ）のＬＴＥネットワーク３（３−１,３−２）で相互に接続されている。２つのＬＴＥネットワーク３−１，３−２は、それぞれ異なる通信キャリア（通信事業者、例えば携帯電話会社）が提供する通信ネットワークであり、インターネットなどに直接接続しない閉域ネットワークである。
【００１８】
第１ＬＴＥネットワーク３−１上にクラウドサーバとしてサーバシステム２−１が設置され、第２ＬＴＥネットワーク３−２上にクラウドサーバとしてサーバシステム２−２が設置される。サーバシステム２−１、２−２間は通信キャリア３よって提供される専用回線を用いたＶＰＮ６で接続されている。
【００１９】
通信端末４のうち、第１ＬＴＥネットワーク３−１を介してサーバシステム２にアクセスする通信端末は、第１キャリアのＳＩＭカードを装着しており、第２ＬＴＥネットワーク３−２を介してサーバシステム２にアクセスする通信端末は、第２キャリアのＳＩＭカードを装着している。
【００２０】
サーバシステム２−１は、呼制御サーバ２１−１、プロビジョニングサーバ２２−１および管理サーバ２０−１を有している。また、サーバシステム２−２も同様に、呼制御サーバ２１−２、プロビジョニングサーバ２２−２および管理サーバ２０−２を有している。呼制御サーバ２１−１、プロビジョニングサーバ２２−１、管理サーバ２０−１および第１ＬＴＥネットワーク３−１は、ＬＡＮ（ローカル・エリア・ネットワーク）５−１で相互に接続されている。また、呼制御サーバ２１−２、プロビジョニングサーバ２２−２、管理サーバ２０−２および第２ＬＴＥネットワーク３−２は、ＬＡＮ５−２で相互に接続されている。ＬＡＮ５−１およびＬＡＮ５−２は、ＶＰＮ６で相互に接続されている。
【００２１】
したがって、サーバシステム２−１とサーバシステム２−２は、それぞれ異なる通信キャリアのクラウド上にあり、地理的に離れた場所に設置することが可能であるため、障害に強い堅牢な音声通信システムを構築することができる。また、サーバシステム２−１とサーバシステム２−２とは、専用線のＶＰＮ６で接続されているため、同一のネットワーク上にある場合と同様に、以下に説明するような柔軟なプロセスの冗長化が可能である。
【００２２】
通常動作時は、サーバシステム２−１の呼制御サーバ２１−１およびプロビジョニングサーバ２２−１がメインサーバとして、通信端末４に対するプロビジョニングおよび呼制御を実行する。サーバシステム２−２の呼制御サーバ２１−２およびプロビジョニングサーバ２２−２は、メインサーバのダウンに備えたサブサーバとしてスタンバイしている。
【００２３】
この実施形態では、呼制御サーバ２１−１、２１−２が、それぞれ複数のプロセスを並行して実行する場合について説明するが、呼制御サーバ２１−１、２１−２は、それぞれ１つの呼制御プロセスを実行するものであってもよい。呼制御サーバ２１−１、２１−２が、それぞれ複数のプロセスを並行して実行する場合、メイン／サブの切り換えは、ハードウェア単位ではなく、内部で起動される複数のプロセス（仮想サーバ：図４参照）単位で行われる。
【００２４】
管理サーバ２０（２０−１、２０−２）は、サーバシステム２−１、２−２の呼制御サーバ２１−１、２１−２およびプロビジョニングサーバ２２−１、２２−２で実行される各プロセスの動作状況を管理し、要求に応じてサーバや通信端末４にその情報を提供する。このため、管理サーバ２０は、図９に示すような管理テーブルを備えている。
【００２５】
ある通信端末４（発呼端末）が他の通信端末４（着呼端末）と通信する場合、発呼端末が、着呼端末の識別情報を制御情報として含む音声信号を呼制御サーバ２１に送信する。呼制御サーバ２１は、この音声信号をＬＴＥネットワーク３を介して着呼端末に転送する。これによって、ＳＩＰ手順などの事前の呼出手続なしで（一般の無線トランシーバのような操作で）、ネットワークを介した発呼端末−着呼端末間の音声通信が可能になる。この通信方式は、国際公開ＷＯ２０１５／０６８６６３号パンフレットに詳細に記載されている。
【００２６】
図２は、管理サーバ２０（２０−１，２０−２）、呼制御サーバ２１（２１−１、２１−２）、および、プロビジョニングサーバ２２（２２−１、２２−２）のブロック図である。サーバは、制御部３０、記憶部３１およびネットワーク通信部３２を有している。記憶部３１は、たとえばハードディスクやＲＡＭなどで構成される。管理サーバ２０の場合、記憶部３１には、図９に示すような管理テーブルが記憶される。呼制御サーバ２１の場合、記憶部３１には、図７に示すようなステータステーブルが設けられる。ネットワーク通信部３２は、ＬＡＮ５およびＬＴＥネットワーク３を介して通信端末４や他のサーバと通信する。制御部３０は、各サーバの動作を制御する。
【００２７】
図３は、通信端末４のブロック図である。通信端末４は、図１に示したように、ハンディトランシーバの外観を有しているが、機能的にはＬＴＥネットワーク３を介して音声信号を送受信する無線ネットワーク機器である。装置の動作を制御する制御部４０はマイクロプロセッサで構成される。制御部４０は、各種のデータが記憶される記憶部４１を有している。記憶部４１は、プロビジョニングデータ記憶エリア４１Ａを有し、このプロビジョニングデータ記憶エリア４１Ａには、図１２に示すようなプロビジョニングデータが記憶される。制御部４０には、操作部４２、表示部４３、オーディオ回路４４、ＬＴＥ通信部４５およびカードスロット４６が接続されている。操作部４２は、ＰＴＴスイッチ２２０などのキースイッチを含み、ユーザの操作を受け付けてその操作信号を制御部４０に入力する。表示部４３は液晶ディスプレイを含む。液晶ディスプレイには、ユーザの操作によって選択された通信相手の識別番号や着信した通信相手の識別番号などが表示される。
【００２８】
オーディオ回路４４は、マイク２４０およびスピーカ２４１を有している。制御部４０は、受信した音声信号をデコードしてオーディオ回路４４に入力する。オーディオ回路は、このデコードされたオーディオ信号をアナログ信号に変換してスピーカ２４１から出力する。オーディオ回路４４は、また、マイク２４０から入力された音声信号をデジタル信号に変換して制御部４０に入力する。制御部４０は、このデジタルオーディオ信号を音声パケット化してＬＴＥ通信部４５に入力する。ＬＴＥ通信部４５は、ＬＴＥ通信方式で無線通信を行う回路を有し、制御部４０から入力されたパケットをＬＴＥネットワーク３に向けて送信するとともに、ＬＴＥネットワーク３から受信したパケットを制御部４０に入力する。なお、オーディオ回路４４にはイヤホンコネクタ２４２が設けられている。イヤホンコネクタ２４２にイヤホンマイク（不図示）が接続されると、通信端末４本体に設けられているマイク２４０およびスピーカ２４１は機能を停止し、イヤホンマイクのマイクおよびスピーカ（イヤホン）が有効になる。カードスロット４６には、端末識別情報が記憶されたＩＣカード（ＳＩＭカード）４７がセットされる。第１ＬＴＥネットワーク３−１で使用される通信端末４には第１キャリアのＳＩＭカード４７がセットされ、第２ＬＴＥネットワーク３−２で使用される通信端末４には第２キャリアのＳＩＭカード４７がセットされる。このＳＩＭカード４７に記憶されている端末識別情報（ＩＣＣＩＤ）が各通信端末４の識別情報として用いられる。
【００２９】
以上の構成の通信端末４において、ユーザがＰＴＴスイッチ２２０を押しながらマイク２４０に向けて音声を入力すると、通信端末４は、この音声信号を、予め設定された着呼端末の識別情報が書き込まれた音声パケットに編集し、この音声パケットをＬＴＥネットワーク３を介して呼制御サーバ２１に送信する。
【００３０】
図４、図５は、呼制御サーバ２１、プロビジョニングサーバ２２の冗長化構成を示す図である。図４は、呼制御サーバ２１，プロビジョニングサーバ２２による二重化と呼制御サーバ２１の制御部３０におけるパーテーション構成を示す図、図５は、呼制御サーバ２１で実行される各プロセスの機能を示す図である。呼制御サーバ２１は、複数のクライアントに対して独立した通信サービスを提供できるように、相互に独立した複数のプロセス（仮想サーバ）を実行する。図４に示すように、呼制御サーバ２１は、６のパーテーションに分割され、各パーテーションでそれぞれ別のプロセスを実行する。プロビジョニングサーバ２２は、複数のクライアントに対して共通であるが、各クライアントの通信端末４の固有識別番号に基づいて、それぞれ別のプロビジョニング処理を実行する。
【００３１】
呼制御サーバ２１−１の各パーテーションで実行されるプロセスは、図５に示すように、クライアントＡ，Ｂ，Ｃの音声通信を制御するための呼制御プロセスＡ，Ｂ，Ｃである。また、呼制御サーバ２１−２の各パーテーションで実行されるプロセスは、図５に示すように、クライアントＡ，Ｂの音声通信を制御するための呼制御プロセスＡ，Ｂである。すなわち、クライアントＡ，Ｂの呼制御プロセスＡ，Ｂは冗長化されているが、クライアントＣの呼制御プロセスＣは冗長化されていない。
【００３２】
呼制御プロセスＡは、クライアントＡの通信端末４相互間の音声通信を中継するプロセスである。呼制御プロセスＣは、クライアントＣの通信端末４相互間の音声通信を中継するプロセスである。なお、一つの呼制御プロセスは、所定の台数（例えば１００台）までの通信端末４を収容することができる。なお、「通信端末４を収容する」とは、通信端末４を登録して、その通信端末４に対して音声通信の中継やプロビジョニングデータの送信を行うことである。所定台数以上の通信端末４を収容する場合には、呼制御プロセスを複数実行してそれぞれの呼制御プロセスに１００台以内の通信端末４を収容し、各呼制御プロセスを拠点間接続プロセスでつないで、各呼制御プロセスに収容されている通信端末４相互間の音声通信を可能にする。クライアントＢは、所有する（収容すべき）通信端末４の台数が多い（１００台を超える）ため、２つの呼制御プロセスＢ１、Ｂ２が実行され、さらに、拠点間接続プロセスＢｒが実行されて呼制御プロセスＢ１、Ｂ２をつないでいる。これにより、クライアントＢに属する全ての通信端末４相互間の音声通信が実現される。
【００３３】
このように、クライアントＡ，Ｂの呼制御プロセスＡ，Ｂは冗長化されているが、クライアントＣの呼制御プロセスＣは冗長化されていない。冗長化されたハードウェアである呼制御サーバ２１の内部で実行される呼制御プロセスは、プロセス単位で冗長化の有無を設定することができる。ハードウェア資源やプロセスの重要度などに基づいて、各プロセスの冗長化の有無を決定すればよい。
【００３４】
プロビジョニングサーバ２２は、通信端末４に図１２に示すようなプロビジョニングデータを送信するためのサーバである。通信端末４は、電源オン時にプロビジョニングサーバ２２にアクセスし、図１２に示すプロビジョニングデータを受信する。通信端末４は、受信したプロビジョニングデータで自身の動作をセットアップし、その通信端末４を保有するクライアントの呼制御プロセスにアクセスできるようになる。プロビジョニングについては、国際公開ＷＯ２０１７／０８６４１６号パンフレットに詳細に記載されている。
【００３５】
なお、呼制御サーバ２１−１およびプロビジョニングサーバ２２−１と呼制御サーバ２１−２およびプロビジョニングサーバ２２−２が、必ずしも同じ性能のものである必要はなく、設定可能なパーテーションの数も同数である必要はない。
【００３６】
冗長化され呼制御サーバ２１−１、呼制御サーバ２１−２の両方で実行されている呼制御プロセスＡ，Ｂのうち、呼制御サーバ２１−１で実行されているプロセスが、稼働（active）プロセスとして通信端末４相互間の音声通信を中継する呼制御処理を実際に行い、呼制御サーバ２１−２で実行されている各プロセスは、待機（standby）プロセスとして、対応する稼働プロセス（呼制御サーバ２１−１で実行されている同じプロセス）がダウンした場合に交替するべく待機している。各プロセスの動作モード（稼働プロセス／待機プロセス）は、管理サーバ２０の管理テーブル（図９参照）に記憶される。
【００３７】
なお、プロビジョニングサーバ２２−１、プロビジョニングサーバ２２−２は、両方とも稼働（active）モードに設定され、通信端末４からのプロビジョニング要求に応答する。
【００３８】
図５は、全てのプロセスが正常に実行されているとき（通常運用）の各呼制御プロセスと通信端末４との接続関係を示している。各クライアントが所持する通信端末４には、以下の種類がある。通信キャリア１のＳＩＭがセットされ、第１ＬＴＥネットワーク３−１を介してサーバシステム２にアクセスする通信端末４、および、通信キャリア２のＳＩＭがセットされ、第２ＬＴＥネットワーク３−２を介してサーバシステム２にアクセスする通信端末４がある。通常運用時は、メインサーバである呼制御サーバ２１−１の呼制御プロセスＡ，Ｂ１，Ｂ２，Ｃが稼働して、実際に呼制御処理を行っているため、通信端末４は全て呼制御サーバ２１−１のプロセスに接続される。呼制御サーバ２１−１は第１ＬＴＥネットワーク３−１側に接続されているため、第２ＬＴＥネットワーク３−２に接続される通信端末４は、第２ＬＴＥネットワーク３−２からＶＰＮ６を経由して呼制御サーバ２１−１にアクセスする。なお、通信キャリア１のＳＩＭおよび通信キャリア２のＳＩＭの両方がセットされ、第１ＬＴＥネットワーク３−１、第２ＬＴＥネットワーク３−２のどうちらを介してでもサーバシステム２にアクセス可能な（マルチ・キャリア）通信端末４を設けてもよい。
【００３９】
通常運用中に呼制御サーバ２１−１のいずれかのプロセスがダウンした場合、ダウンしたプロセスが、図６（Ｂ），図６（Ｃ）に示すような形態で、呼制御サーバ２１−２の待機プロセスに切り換えられる。図６では、クライアントＢの呼制御プロセスＢ（呼制御プロセスＢ１，Ｂ２および拠点間接続プロセスＢｒ）における稼働プロセスから待機プロセスへの切り換えについて説明する。
【００４０】
図６（Ａ）はクライアントＢの各プロセスが正常に実行されている場合の各プロセスおよび通信端末４の接続形態を示している。この接続形態は、図５に示したものと同じである。ここでは、呼制御プロセスＢ１−１，Ｂ２−１および拠点間接続プロセスＢｒ−１が稼働しており、通信端末４は、呼制御プロセスＢ１−１，Ｂ２−１にアクセスする。詳細には、通信端末４−１は、第１ＬＴＥネットワーク３−１を介して呼制御プロセスＢ１−１にアクセスし、通信端末４−３は、第２ＬＴＥネットワーク３−２およびＶＰＮ６を介して呼制御プロセスＢ１−１にアクセスする。通信端末４−２は、第１ＬＴＥネットワーク３−１を介して呼制御プロセスＢ２−１にアクセスし、通信端末４−４は、第２ＬＴＥネットワーク３−２およびＶＰＮ６を介して呼制御プロセスＢ２−１にアクセスする。
【００４１】
図６（Ｂ）は、呼制御プロセスＢ２−１がダウンした場合の接続形態を示している。稼働プロセスであった呼制御プロセスＢ２−１がダウンしたため、対応する待機プロセスである呼制御プロセスＢ２−２が稼働プロセスとなる。そうすると、通信端末４−２、４−４は、呼制御プロセスＢ２−１から呼制御プロセスＢ２−２にアクセス先を変更する。詳細には、通信端末４−２は、第１ＬＴＥネットワーク３−１およびＶＰＮ６を介して呼制御プロセスＢ２−２にアクセスし、通信端末４−４は、第２ＬＴＥネットワーク３−２を介して呼制御プロセスＢ２−２にアクセスする。また、拠点間接続プロセスＢｒ−１は、メインの呼制御プロセスＢ１−１とサブの呼制御プロセスＢ２−２とを接続するよう接続拠点を切り換える。
【００４２】
図６（Ｃ）は、拠点間接続プロセスＢｒ−１がダウンした場合の接続形態を示している。稼働プロセスであった拠点間接続プロセスＢｒ−１がダウンしたため、待機プロセスである拠点間接続プロセスＢｒ−２が稼働プロセスとなる。呼制御サーバ２１−１の呼制御プロセスＢ１−１、Ｂ２−１が正常に稼働しているため、拠点間接続プロセスＢｒ−２は、ＶＰＮ６を介して、呼制御サーバ２１−１の呼制御プロセスＢ１−１およびＢ２−１を接続する。なお、通常動作時と同様に呼制御プロセスＢ１−１およびＢ２−１は正常に稼働しているため、通信端末４−１〜４のアクセス先に変更はない。
【００４３】
このように、ハードウェアの呼制御サーバ２１−１、２１−２で複数のプロセス（仮想サーバ）が稼働しており、そのいずれかがダウンした場合、プロセス単位で呼制御サーバ２１−１のプロセスから呼制御サーバ２１−２のプロセスに切り換えられる。
【００４４】
各プロセス（パーテーション）は、自身が実行しているプロセスおよび対応する相手プロセスの状態を記憶するため、記憶部３１に図７に示すようなステータステーブルを有している。ステータステーブルは、自身が実行しているプロセスの名称、動作設定、動作モード（稼働モード（active）／待機モード（standby））、および、自身の動作通知有効期限、稼働中システムの動作通知有効期限の記憶エリアを有している。動作設定の欄には、メインプロセス（main）／サブプロセス（sub）／単独プロセス（alone）のいずれかの設定情報が記憶される。呼制御サーバ２１−１および呼制御サーバ２１−２で、同じプロセスが実行される場合、そのうちの一方（一般的にはメインサーバである呼制御サーバ２１−１で実行されるプロセス）がメインプロセスに設定され、他方（一般的にはサブサーバである呼制御サーバ２１−２で実行されるプロセス）がサブプロセスに設定される。両プロセスが正常に動作しているときは、メインプロセスが実際の処理を実行する稼働モードになり、サブプロセスが待機モードになる。メインプロセスがダウンした場合、サブプロセスが稼働モードになる。動作モードの欄には、このプロセスの動作モードが稼働モード（active）であるか、待機モード（stadby）であるかが記憶される。
【００４５】
また、呼制御プロセスＣは、呼制御サーバ２１−１のみで実行されているため、動作設定の欄には、単独プロセス（alone）が記憶される。
【００４６】
なお、各プロセスが管理サーバ２０および対応する待機プロセスに送信する動作通知は、自身が実行しているプロセスの名称、動作設定、動作モード、および、この動作通知の有効期限を含んでいる。
【００４７】
図７（Ａ）は、メインプロセスのステータステーブルの記憶内容の例を示す図である。この例では、このプロセス（パーテーション）は、呼制御プロセスＢ２−１を実行しており、動作設定はメイン、動作モードは稼働モードである。動作通知有効期限は、自身が管理サーバ２０および相手のサブプロセスに対して送った動作通知の有効期限が記憶される。動作通知は、自身が管理サーバ２０および待機プロセスに対して、自身が正常に動作していることを通知するメッセージである。待機プロセスおよび管理サーバ２０は、この動作通知の有効期限が経過する前に新たな有効期限の動作通知が送られてくることで稼働プロセスが正常に動作していることを確認する。稼働プロセス動作通知有効期限は、自身が待機中の場合に、対応する稼働プロセスから受信した動作通知の有効期限が記憶される。図７（Ａ）は、稼働プロセスのステータステーブルであるため、稼働プロセスから受信する稼働プロセス動作通知有効期限は空欄である。
【００４８】
図７（Ｂ）は、サブプロセスのステータステーブルの記憶内容の例を示す図である。この例では、このプロセス（パーテーション）は、呼制御プロセスＢ２−２を実行しており、動作設定はサブプロセス、動作モードは待機モードである。動作通知有効期限は、自身が管理サーバ２０に対して送った動作通知の有効期限が記憶される。稼働システム動作通知有効期限には、対応する稼働プロセス（呼制御プロセスＢ２−１）から送られてきた動作通知の有効期限が記憶される。有効期限が経過する前に新たな有効期限の動作通知が送られてくると、その新たな有効期限でテーブルを更新し、待機モードを継続する。
【００４９】
この有効期限を過ぎても稼働プロセスから動作通知が送られて来ない場合、同図右欄に示すように、このサブプロセスは、稼働プロセスであるメインプロセスがダウンしていると判断し、自身の動作モードを稼働モードに切り換えて、通信端末４の音声通信の中継を開始する。
【００５０】
図８は呼制御サーバ２１で実行される呼制御プロセスの動作を示すフローチャートである。図８（Ａ）は、稼働プロセスの動作通知処理を示している。稼働プロセスは、定期的（たとえば１分毎）に、両側の管理サーバ２０−１、２０−２に対して動作通知を送信するとともに（Ｓ１１）、対応する待機プロセスに対しても動作通知を送信する（Ｓ１２）。送信した動作通知の有効期限は、次の送信予定時刻よりも長く設定されている。この有効期限で、自身のステータステーブルの動作通知の有効期限を更新する（Ｓ１３）。
【００５１】
図８（Ｂ）は、稼働プロセスおよび待機プロセスが実行する動作状況確認処理を示している。この処理も定期的に実行される。稼働プロセスには、他のプロセスと接続があるものがある。他のプロセスとの接続とは、図５、図６に示したように、呼制御プロセスＢ１と拠点間接続プロセスＢｒ、呼制御プロセスＢ２と拠点間プロセスＢｒがそれぞれ接続され音声信号等の送受信を行う形態である。自身のプロセスがこのような形態で他のプロセスで接続されている場合、他のプロセスの動作状況に合わせて接続先を切り換える等の処理が行われる。プロセスは、所定の時間ごとに管理サーバ２０に各プロセスの動作状況を問い合わせる（Ｓ１６）。この問い合わせに応答して管理サーバ２０から各プロセスの動作状況が返信されてくると（Ｓ１７）、接続先のプロセスがダウンして待機プロセスが稼働プロセスに切り換わっているなど、接続先の動作状況に変更があるかを判断する（Ｓ１８）。接続先の動作状況に変更があった場合には（Ｓ１８でＹＥＳ）、現在の動作状況に合わせて接続先を切り換えて（Ｓ１９）、処理を終了する。他のプロセスと接続がない場合、または、接続先の変更がない場合（Ｓ１８でＮＯ）には、そのまま処理を終了する。
【００５２】
例えば、図６（Ｂ）のように、呼制御プロセスＢ２−１がダウンした場合、拠点間接続プロセスＢｒ−１は、管理サーバ２０−１に動作状況を問い合わせたときに、呼制御プロセスＢ２−１がダウンしていること、および、その待機プロセスであった呼制御プロセスＢ２−２が稼働を開始していることを知る。そこで、呼制御プロセスＢ２−２に対するプロセス間通信を開始することにより、呼制御プロセスＢの稼働を維持する。
【００５３】
図８（Ｂ）における管理サーバ２０への問い合わせは、同じ側の管理サーバ２０、すなわち、このプロセスが実行されている呼制御サーバ２１と同じサーバシステム２−１、２−２内に設置されている管理サーバ２０に対して行うが、この管理サーバ２０が応答しなかった場合は、反対側の管理サーバ２０（このプロセスが実行されている呼制御サーバ２１と異なるサーバシステム２−１、２−２内に設置されている管理サーバ２０）に再度問い合わせる。
【００５４】
また、管理サーバ２０への問い合わせは、一定時間毎に行ってもよいが、プロセス間通信の変更や待機プロセスの動作モードの切り換え（図８（Ｄ）参照）が発生するごとに管理サーバ２０に対して各プロセスの動作状況（通信相手）を問い合わせるようにしてもよい。
【００５５】
図８（Ｃ）は、待機プロセスの動作通知処理を示している。待機プロセスは、定期的（たとえば１分毎）に、両側の管理サーバ２０−１、２０−２に対して動作通知を送信する（Ｓ２１）。送信した動作通知の有効期限は、次の送信予定時刻よりも長く設定されている。この有効期限で、自身のステータステーブルの動作通知の有効期限を更新する（Ｓ２２）。
【００５６】
図８（Ｄ）は、待機プロセスの動作状況確認処理を示している。この処理も定期的に実行される。待機プロセスは、ステータステーブルを参照して稼働プロセスの動作通知が有効であるかを判断する（Ｓ２４）。稼働プロセスからの動作通知の有効期限が切れている場合（Ｓ２４でＮＯ）、稼働プロセスはダウンしていると判断し、図８（Ｂ）の処理で取得していた各プロセスの動作状況に合わせて接続先等を設定して、ダウンした稼働プロセス（メインプロセス）に代わって自身を稼働プロセスとして動作を開始する（Ｓ２５）。同時にステータステーブルの動作モードを稼働モード（active）に書き換える（Ｓ２６）。例えば、図６（Ｃ）のように、拠点間接続プロセスＢｒ−１がダウンした場合、拠点間接続プロセスＢｒ−２が、稼働している呼制御プロセスＢ１−１、Ｂ２−１とプロセス間通信を行う稼働を開始する。
【００５７】
稼働プロセスとして動作を開始したのち、管理サーバ２０に対して、動作モードを変更した旨を通知する（Ｓ２７）。この動作モード変更通知は、動作通知を兼ねている。一方、Ｓ２４において、稼働プロセスが正常に動作している場合、すなわち、動作通知の有効期限が切れていない場合は（Ｓ２４でＹＥＳ）、Ｓ２４で動作を終了する。
【００５８】
図９は、管理サーバ２０に設定される管理テーブルの例を示す図である。図９には、管理テーブルのうち、呼制御サーバ２１−１、２１−２のプロセスに関する部分のみ記載する。プロビジョニングサーバ２２−１、２２−２の各プロセスについても同様のテーブルが設けられている。
【００５９】
管理テーブルには、メインサーバである（第一）呼制御サーバ２１−１、および、サブサーバである（第二）呼制御サーバ２１−２で実行される全てのプロセスの情報が記憶されている。管理テーブルには、プロセスごとに、動作通知有効期限、動作設定、動作モードが記憶される。動作通知有効期限の欄には、プロセスから送られてきた動作通知に記載されていた有効期限が記憶される。管理サーバ２０が、この有効期限以内にプロセスから新たな動作通知を受信した場合、この有効期限は、その新たな動作通知に記載されている有効期限に更新される。動作設定の欄には、メインプロセス（メイン）／サブプロセス（サブ）のいずれかの設定情報が記憶される。動作モードの欄には、稼働モード（active）／待機モード（stadby）のいずれかが記憶される。
【００６０】
各プロセスから、動作通知有効期限内に新たな動作通知が送られてこなかった場合には、そのプロセスがダウンしている（動作通知を送信する機能が失われている）として、動作モードをダウンに書き換える。正常に動作しているプロセスから定期的に全プロセスの動作状況の問い合わせがあるため、この問い合わせに応答して、正常に稼働しているプロセス、正常に待機しているプロセス、および、ダウンしているプロセス等の情報を返信する。各プロセスは、この動作状況に応じて接続先の切り換えなどを行う。また、管理サーバ２０は、稼働プロセスのダウンに対応して稼働を開始したプロセスから、稼働を開始した旨の通知を受信した場合、管理テーブルのこのプロセスの動作モードを稼働モードに書き換える。
【００６１】
なお、管理テーブルに、プロセス間通信を行うプロセス（例えば呼制御プロセスＢ１−１、Ｂ１−２、Ｂｒ−１など）について、通信相手である接続先プロセスを記憶するエリアを設けてもよい。
【００６２】
図１０は管理サーバ２０の動作を表すフローチャートである。図１０（Ａ）は、有効期限更新動作を示すフローチャートである。いずれかのプロセスから動作通知を受信すると（Ｓ３１）、管理テーブルのそのプロセスの動作通知有効期限を更新する（Ｓ３２）。なお、プロセスが起動し、初めて動作通知を送信した場合、管理サーバ２０は、このプロセスを管理テーブルに登録して動作通知有効期限を書き込む。
【００６３】
図１０（Ｂ）は、プロセスから稼働開始通知を受信した場合の動作を示すフローチャートである。待機プロセスから（ダウンした稼働プロセスに代わって）稼働を開始した旨の通知を受信すると（Ｓ３５：図８（Ｄ）のＳ２７参照）、管理テーブルのそのプロセスの動作モードを稼働モード（active）に変更する（Ｓ３６）。この稼働開始通知は動作通知を兼ねているので、このプロセスの動作通知有効期限を更新する（Ｓ３７）。そして、稼働プロセスが変更になった旨をシステム管理者の端末（パーソナルコンピュータ）に対してメール等でアラートを送信する（Ｓ３８）。
【００６４】
図１０（Ｃ）は、テーブルメンテナンス動作を示すフローチャートである。定期的にテーブル上の全てのプロセスについて以下の処理を実行する。プロセスの動作通知の有効期限を読み出す（Ｓ４１）。そしてこの有効期限を現在時刻と比較し、有効期限切れになっている場合には（Ｓ４２でＹＥＳ）、動作モードをダウンに書き換えて（Ｓ４４）、次のプロセスのメンテンスに進む。なお、Ｓ４４において、ダウン状態が継続していて既に動作モードがダウンに書き換えられている場合でも、動作モードのダウンへの書き換えが行われるが、既にダウンモードの場合は書き換えないようにしてもよい。
【００６５】
動作通知の有効期限が切れていなければ（Ｓ４２でＮＯ）、現在の動作モードがダウンであるかを判断する（Ｓ４５）。動作モードがダウンである場合には（Ｓ４５でＹＥＳ）、動作モードを待機モード（standby）に書き換えたのち（Ｓ４６）、次のプロセスのメンテナンスに進む。動作通知の有効期限が切れておらず（Ｓ４２でＮＯ）且つ動作モードがダウンでない場合には（Ｓ４５でＮＯ）、このプロセスに対する処理を終了して、次のプロセスのメンテナンスに進む。
【００６６】
Ｓ４６に示すように、一度ダウンしたプロセスが復旧した場合、現在稼働中のプロセスのダウンに備えた待機プロセスとして動作する。なお、予め動作設定がメインプロセスとされているプロセスが復旧した場合には、そのとき稼働している対応するサブプロセスを待機モードに変更させて、メインプロセスを稼働プロセスに復帰させてもよい。
【００６７】
図１１（Ａ）、（Ｂ）に、クライアントＢの呼制御プロセスが、図６（Ｂ）の状態になった場合、図６（Ｃ）の状態になった場合の管理テーブルの記憶内容を示す図である。この図では、各プロセスの動作モードの欄のみを表示している。図６（Ｂ）の状態では、呼制御プロセスＢ２−１がダウンし、これに代えて呼制御プロセスＢ２−２が稼働しているため、図１１（Ａ）に示す管理テーブルにおいても、呼制御プロセスＢ２−１の動作モードがダウン（down）に書き換えられ、これに代えて呼制御プロセスＢ２−２の動作モードが稼働モード（active）になっている。
【００６８】
また、図６（Ｃ）の状態では、呼制御サーバ２１−１の拠点間接続プロセスＢｒ−１がダウンし、これに代えて呼制御サーバ２１−２の拠点間接続プロセスＢｒ−２が稼働しているため、図１１（Ｂ）に示す管理テーブルにおいても、拠点間接続プロセスＢｒ−１の動作モードがダウン（down）に書き換えられ、これに代えて拠点間接続プロセスＢｒ−２の動作モードが稼働モード（active）になっている。
【００６９】
このように、各プロセスの動作モードの変更に対応して管理テーブルを更新し、他のプロセスや通信端末４からの問い合わせに対しては、このテーブルの内容を送信する。これにより、プロセスが他のプロセスの状態を知ることができるようになり、プロセス間通信の接続先を変更することや、通信端末４が、アクセスする呼制御プロセスを変更することが容易になる。
【００７０】
なお、管理サーバ２０は、ウェブサーバとしても機能する。管理テーブルの内容やその更新履歴等をＬＡＮ５またはＬＴＥネットワーク３経由で管理者のパーソナルコンピュータに映すことができる。
【００７１】
図１０（Ｄ）は、プロセスからの問い合わせに対応する処理を示すフローチャートである。プロセスから動作状況の問い合わせがあると（Ｓ５０：図８（Ｂ）のＳ１６、図８（Ｄ）のＳ２５参照）、問い合わせのあったプロセスに対して、各プロセスの動作状況（管理テーブルの内容）を送信する（Ｓ５１）。これにより、プロセスは他のプロセスの動作状況を知ることができる。
【００７２】
図１０（Ｅ）は、通信端末４からの問い合わせに対応する処理を示すフローチャートである。通信端末４から稼働中の呼制御プロセスの問い合わせがあると（Ｓ５４）、その通信端末４が所属するクライアントの呼制御プロセスのうち稼働している側の呼制御プロセスを通知する（Ｓ５５）。これにより、稼働していた呼制御プロセスがダウンして稼働中呼制御プロセスが切り換わった場合、通信端末４がその切り換わった呼制御プロセスにアクセスすることが可能になる。
【００７３】
図１２は、通信端末４のメモリに記憶されるプロビジョニングデータの一例を示す図である。プロビジョニングデータは、メインプロビジョニングサーバアドレス、サブプロビジョニングサーバアドレス、メイン呼制御サーバアドレス、サブ呼制御サーバアドレス、および、各種設定情報を含んでいる。
【００７４】
メインプロビジョニングサーバアドレスは、プロビジョニングサーバ２２−１のＩＰアドレスおよびポート番号を含んでいる。サブプロビジョニングサーバアドレスは、プロビジョニングサーバ２２−２のＩＰアドレスおよびポート番号を含んでいる。これらのアドレスは、プロビジョニングサーバ２２から与えられてもよく、事前に通信端末４に記憶されていてもよい。
【００７５】
メイン呼制御サーバアドレスは、呼制御サーバ２１−１のＩＰアドレス、および、この通信端末４が所属するクライアントのプロセスのポート番号を含んでいる。サブ呼制御サーバアドレスは、プロビジョニングサーバ２１−２のＩＰアドレス、および、この通信端末４が所属するクライアントのプロセスのポート番号を含んでいる。メインプロビジョニングサーバアドレス／サブプロビジョニングサーバアドレス、および、メイン呼制御サーバアドレス／サブ呼制御サーバアドレスには、どのアドレスのプロセスが稼働中であるかを示す稼働中フラグが設けられている。デフォルトでは、メインプロビジョニングサーバアドレスおよびメイン呼制御サーバアドレスの稼働中フラグがセットされる。
【００７６】
各種設定情報は、たとえば、通信端末４の呼出ＩＤ、通知音設定（着信時の通知音の選択情報）、イヤホン設定（イヤホンマイクが接続された場合にフル・デュプレックス通信を行うか否かの設定情報）、アドレス帳（呼出可能な通信端末４の呼出ＩＤリスト）、音量設定（通話音の音量設定情報）などである。
【００７７】
図１３は、通信端末４の動作を示すフローチャートである。図１３（Ａ）は、プロビジョニング動作を示すフローチャートである。この動作は通信端末４の電源オン時などに実行される。通信端末４の制御部４０が、メインサーバであるプロビジョニングサーバ２２−１にアクセスして、プロビジョニングデータの送信を要求する（Ｓ６１）。一定時間以内にプロビジョニングサーバ２２−１から応答があった場合には（Ｓ６２でＹＥＳ）、このサーバからプロビジョニングデータを受信して（Ｓ６５）、プロビジョニングを実行する（Ｓ６６）。もし、一定時間以内にプロビジョニングサーバ２２−１から応答がなかった場合には（Ｓ６２でＮＯ）、サブサーバであるプロビジョニングサーバ２２−２にアクセスして、プロビジョニングデータの送信を要求し（Ｓ６３）、稼働中フラグをサブプロビジョニングサーバ２２−２側に切り換える（Ｓ６４）。そして、サブプロビジョニングサーバ２２−２からプロビジョニングデータを受信する（Ｓ６５）。もし、２つのプロビジョニングサーバ２２−１、２２−２が同時にダウンした場合、通信端末４は、以前に取得したプロビジョニングデータを用いて接続を試みるようにすればよい。
【００７８】
図１３（Ｂ）は、通信端末４の音声通信時の動作を示すフローチャートである。ＰＴＴボタン２２０が押されるとこの動作が開始される。通信端末４の制御部４０が、メインの呼制御サーバ２１−１のこの通信端末４に割り当てられた呼制御プロセス（仮想サーバ）に音声信号を送信する（Ｓ７１）。一定時間以内に呼制御サーバ２１−１のプロセスから応答があった場合には（Ｓ７２でＹＥＳ）、音声通信を開始する。もし、一定時間以内に呼制御サーバ２１−１のプロセスから応答がなかった場合には（Ｓ７２でＮＯ）、通信不可である旨の表示を行う等して動作を停止する。この通信ダウンの状態は、それまで稼働していた呼制御プロセスがダウンしたのち、図１３（Ｃ）の稼働プロセス確認前に通信が開始された場合に発生し得る状態である。
【００７９】
図１３（Ｃ）は、通信端末４が、稼働している呼制御プロセスを問い合わせる動作を示すフローチャートである。この処理は定期的に行われるが、図１３（Ｂ）のＳ７２で稼働中としていた呼制御プロセスから応答がなかったときに臨時に実行されるようにしてもよい。通信端末４の制御部４０は、管理サーバ２０に、この通信端末４を収容している稼働中の呼制御プロセスを問い合わせる（Ｓ７３）。これに応答して管理サーバから稼働プロセスの情報が送られてくるので、これを受信し（Ｓ７４：図１０（Ｅ）Ｓ５５参照）、稼働プロセスに切り換えられたかを判断する（Ｓ７５）。切り換えられた場合は（Ｓ７５でＹＥＳ）、呼制御サーバの稼働中フラグを稼働プロセス側（サブ呼制御サーバ側）に切り換える（Ｓ７６）。これ以後、通信端末４は、音声通信が発生した場合は、稼働プロセスに切り換わった呼制御プロセスに対してアクセスするようになる。
【００８０】
なお、通信端末４は、運用開始時および定期的に、さらにはエリア移動などの機会ごとに、稼働モードの呼制御サーバ２０に対して、登録を要求するメッセージ（レジストメッセージ）を送信する。稼働モードの呼制御サーバ２０は、このメッセージを受信することにより、運用中の通信端末を把握し、この通信端末４を端末テーブルに登録することができる。通信端末４は、このレジストメッセージを稼働モードとされる呼制御サーバ２０−１／２に送信しても応答がない場合、この呼制御サーバ２０−１／２はダウンしているとして、反対側の呼制御サーバ２０−２／１に、改めてレジストメッセージを送信する。
【００８１】
図１０、図１３に示すフローチャートでは、通信端末４は、定期的に管理サーバ２１に対して、稼働モードの呼制御プロセスを問い合わせているが、上記のレジストメッセージに対する応答の有無によって稼働モードの呼制御プロセスがどちらであるかを解決してもよい。
【００８２】
また、待機モードで動作している呼制御プロセスが、通信端末からレジストメッセージを受信した場合、レジストメッセージの送信先を反対側の（稼働モードの）呼制御プロセスに切り換えて再送信すべき旨の応答を通信端末に返信するようにしてもよい。
【００８３】
レジストメッセージに対する応答の有無で稼働モードの呼制御サーバ２０を判断するようにすれば、通信端末４の台数が多い場合でも、管理サーバ２１に対する問い合わせが頻発することがなくなり、管理サーバ２１の負荷を軽減することができる。ただし、一般的にレジストの間隔は、図１３（Ｃ）等に示した問い合わせの間隔よりも長いため、通信端末４が稼働モードの呼制御プロセスの交代を知るまでの時間が長くなる。
【００８４】
以上は、呼制御サーバ２１−１、２１−２のプロセスがダウンした場合の呼制御動作の切り換えについて説明した。プロセスがダウンしていない場合でも、サーバシステム２−１とサーバシステム２−２とをつなぐＶＰＮ６がダウンする場合がある。図１４、図１５を参照して、ＶＰＮ６がダウンした場合の縮退動作について説明する。
【００８５】
図１４は、クライアントＢの呼制御プロセスにおいて、ＶＰＮ６がダウンした場合のプロセス間の接続形態を示している。管理サーバ２０−１、２０−２、呼制御サーバ２１−１、２１−２、プロビジョニングサーバ２２−１、２２−２は正常に動作しており、呼制御プロセスＢ１−１、Ｂ２−１、Ｂ１−２、Ｂ２−２、および、拠点間接続プロセスＢｒ−１、Ｂｒ−２もそれぞれ正常に動作しているものとする。
【００８６】
ＶＰＮ６がダウンすると、サーバシステム２−１、２−２間の通信が不可能になる。この場合でも、サーバシステム２−１の管理サーバ２０−１、呼制御サーバ２１−１、プロビジョニングサーバ２２−１は正常に動作しているため、第１ＬＴＥネットワーク３−１を介してサーバシステム２−１にアクセスする通信端末４（４−１、４−２）に対して呼制御プロセスＢなどのサービスを継続することが可能である。
【００８７】
一方、サーバシステム２−２においても、管理サーバ２０−２、呼制御サーバ２１−２、プロビジョニングサーバ２２−２は正常に動作おり、且つ、サーバシステム２−１の各プロセスからの動作通知が届かなくなるため、管理サーバ２０−２および呼制御サーバ２１−２、プロビジョニングサーバ２２−２の各プロセスは、サーバシステム２−１側の各プロセスが全てダウンしたと判断し、呼制御サーバ２１−２、プロビジョニングサーバ２２−２の各プロセスは、待機モードから稼働モードに切り換わってクライアントＢに対する呼制御プロセスを稼働させる。そして、呼制御サーバ２１−２で立ち上げられた呼制御プロセスは、第２ＬＴＥネットワーク３−２を介してサーバシステム２にアクセスする通信端末４（４−３、４−４）に対してサービスを提供する。
【００８８】
このように、ＶＰＮ６がダウンすると、第１ＬＴＥネットワーク３−１、３−２をつなぐ通信は不可能になるが、第１、第２ＬＴＥネットワーク３−１、３−２で呼制御プロセスＢが稼働モードとなり、それぞれの範囲でサービスを提供できるようになる。
【００８９】
このとき、サーバシステム２−１内の管理サーバ２０−１の管理テーブルは、図１５（Ａ）に示すように、呼制御サーバ２１−１の各プロセスが全て稼働モード（active）になっており、呼制御サーバ２１−２の各プロセスの動作モードが全てダウン（down）になっている。一方、サーバシステム２−２内の管理サーバ２０−２の管理テーブルは、図１５（Ｂ）に示すように、呼制御サーバ２１−１の各プロセスの動作モードが全てダウン（down）になっており、呼制御サーバ２１−２の各プロセスが全て稼働モード（active）になっている。なお、呼制御プロセスＣは、冗長化されておらず、呼制御サーバ２１−１のみで実行されるため、ＶＰＮ６がダウンした場合、（図５の例には記載していないが、）第２ＬＴＥネットワーク３−２のエリアにクライアントＣの通信端末４があった場合には、この通信端末４は通信することができなくなる。
【００９０】
この縮退動作は、ＶＰＮ６のダウンによって相手側プロセスからの動作通知が途絶えたことに対応する動作として、図８に示した呼制御サーバ２１−１、２１−２の各プロセスの動作、および、図１０に示した管理サーバ２０−１、２０−２の動作によって実現可能である。
【００９１】
図１６は、ＬＴＥネットワーク３（３−１、３−２）のうち、一方のサービスがダウンした場合の動作形態を示す図である。図１６（Ａ）は、第１ＬＴＥネットワーク３−１がダウンした場合の動作形態を示している。第１ＬＴＥネットワーク３−１がダウンしているため、この第１ＬＴＥネットワーク３−１に接続する通信端末４−１、４−２は通信不可である。しかしながら、サーバシステム２−１上で稼働している稼働プロセス（稼働サーバ）である呼制御プロセスＢ１−１、Ｂ１−２は、ＶＰＮ６を介して第２ＬＴＥネットワーク３−２に接続されているため、第２ＬＴＥネットワーク３−２に接続される通信端末４−３、４−４がこの呼制御プロセスＢ１−１、Ｂ２−１にアクセスして通信が可能であり、一方のネットワーク３−２のみを用いた通信維持される。
【００９２】
また、図１６（Ｂ）は、第２ＬＴＥネットワーク３−２がダウンした場合の動作形態を示している。第２ＬＴＥネットワーク３−１がダウンしているため、第２ＬＴＥネットワーク３−２に接続する通信端末４−３、４−４は通信不可である。しかしながら、稼働プロセス（稼働サーバ）である呼制御プロセスＢ１−１、Ｂ１−２は、第１ＬＴＥネットワーク３−１上に設置されているため、第１ＬＴＥネットワーク３−１に接続される通信端末４−１、４−２がこの呼制御プロセスＢ１−１、Ｂ２−１にアクセスして通信が可能であり、一方のネットワーク３−１のみを用いた通信維持される。
【００９３】
なお、第１ＬＴＥネットワーク３−１、第２ＬＴＥネットワーク３−２の両方のＳＩＭが装着されたマルチ・キャリア（デュアル・キャリア）通信端末であれば、障害が発生していない方のＬＴＥネットワークに接続して通信を行うことが可能である。
【００９４】
この実施形態では、呼制御サーバ２１−１をメインサーバ、呼制御サーバ２１−２をサブサーバとして、呼制御サーバ２１−１で実行される各プロセスをメインとして動作設定しているが、メインとして動作設定されるプロセスを呼制御サーバ２１−１、２１−２に分散させてもよい。
【００９５】
以上の実施形態では、サーバシステム２、ネットワーク３がそれぞれ２つずつ設けられている構成について説明したが、第３、第４、・・・のサーバシステム、ネットワークを有する構成であってもよい。そのようにすることにより、さらなる冗長化が可能になる。
【符号の説明】
【００９６】
１  音声通信システム
２（２−１、２−２）  サーバシステム
２０（２０−１、２０−２）  管理サーバ
２１（２１−１、２１−２）  呼制御サーバ
２２（２２−１、２２−２）  プロビジョニングサーバ
３（３−１、３−２）  ＬＴＥネットワーク
４（４−１〜４）  通信端末
【図１】
2020150498.tif 000003
【図２】
2020150498.tif 000004
【図３】
2020150498.tif 000005
【図４】
2020150498.tif 000006
【図５】
2020150498.tif 000007
【図６】
2020150498.tif 000008
【図７】
2020150498.tif 000009
【図８】
2020150498.tif 000010
【図９】
2020150498.tif 000011
【図１０】
2020150498.tif 000012
【図１１】
2020150498.tif 000013
【図１２】
2020150498.tif 000014
【図１３】
2020150498.tif 000015
【図１４】
2020150498.tif 000016
【図１５】
2020150498.tif 000017
【図１６】
2020150498.tif 000018