JP5857823B2 - 制御装置及びプログラム、並びに、呼制御システム、並びに、通信システム - Google Patents

Description

本発明は、制御装置及びプログラム、並びに、呼制御システム、並びに、通信システムに関し、例えば、ＩＭＳ（ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ）システム上のＣＳＣＦ（Ｃａｌｌ／Ｓｅｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ）の制御に適用し得る。

近年、環境問題等により、消費電力の軽減が各種業界で検討及び導入が行われている。

通信システムを構成する装置に関しても、利用者の少ない時間帯に関連機器を停止する等の手段が検討及び導入されている。

例えば、従来の通信システムを構成する装置の省電力化を実現する技術としては、特許文献１の記載技術がある。特許文献１では、設定ポリシーに基づいて、トラヒック状況を踏まえ、装置に供給する電力量を制御することにより、省電力化を実現している。

特開２００７−９７１２６号公報 特開２０１１−１１４４２３号公報 特開２０１０−１２４７４０号公報 特開２０１０−１４８０２３号公報

ゴンザロ・カマリロ、ミゲール・Ａ・ガルシア・マーチン著、澤田拓也他、鹿島拓也訳、「ＩＭＳ標準テキスト ＮＧＮのコア技術」、２００６年７月株式会社リックテレコム発行 ３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ（３ＧＰＰ）編、「ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｃａｌｌ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ ｂａｓｅｄ ｏｎ Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ （ＳＩＰ） ａｎｄ Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＳＤＰ）．ＴＳ ２４．２２９」、[Online]、INTERNET、[２０１２年３月７日検索]，＜ＵＲＬ： http://www.3gpp.org/ftp/Specs/archive/24_series/24.229/24229-810.zip＞ ３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ（３ＧＰＰ）編、「Ｓｉｇｎａｌｌｉｎｇ ｆｌｏｗｓ ｆｏｒ ｔｈｅ ＩＰ ｍｕｌｔｉｍｅｄｉａ ｃａｌｌ ｃｏｎｔｒｏｌ ｂａｓｅｄ ｏｎ Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ （ＳＩＰ） ａｎｄ Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ （ＳＤＰ）．ＴＳ ２４．２２８」、[Online]、INTERNET、[２０１２年３月７日検索]，＜ＵＲＬ： http://www.3gpp.org/ftp/Specs/archive/24_series/24.228/24228-5f0.zip＞

しかし、万人にサービスを提供することを前提にしている、通信事業者のネットワークにおいては、各種検討しているが、サービス利便性等の面でいくつか課題がある。特に、次世代の通信提供プラットフォームとなるＩＭＳのアーキテクチャに適用した場合に関しては、既存の方式のみでは単純に対応できない。ＩＭＳは次世代ネットワーク（Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ Ｎｅｔｗｏｒｋ；ＮＧＮ）における中心的な技術であり、ＣＳＣＦは、ＩＭＳにおいて極めて重要なノードで、ＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）サーバとして、ＳＩＰメッセージの処理を行う。ＣＳＣＦには機能により、Ｐ−ＣＳＣＦ（Ｐｒｏｘｙ−ＣＳＣＦ）、Ｉ-ＣＳＣＦ(Ｉｎｔｅｒｒｏｇａｔｉｎｇ−ＣＳＣＦ)、Ｓ−ＣＳＣＦ（Ｓｅｒｖｉｎｇ−ＣＳＣＦ）の３種類のいずれかに属する（非特許文献１参照）。

そして、ＩＭＳアーキテクチャにおいて、呼制御の中核をなすＳ−ＣＳＣＦは、端末（通信装置）からの初回位置登録（ＲＥＧＩＳＴＥＲ）時に割り当てられる前提であり、単純にトラヒックの状況等で停止してしまうと、ユーザサービスに支障を来たす場合がある。

そのため、省電力化を実現しつつ、安定的な呼制御処理を実現することができる制御装置及びプログラム、並びに、呼制御システム、並びに、通信システムが望まれている。

第１の本発明は、複数の呼制御装置と協働して、通信装置に対して呼制御処理を提供する制御装置であって、（１）上記呼制御装置の動作を制御する動作制御手段と、（２）上記呼制御装置の動作状態を管理する動作状態管理手段と、（３）当該制御装置に到来した呼制御処理信号の処理を、いずれかの上記呼制御装置に振分ける振分手段とを有し、（４）上記動作制御手段は、当該制御装置に係るトラヒック量の測定結果に応じて、停止中の上記呼制御装置の起動を行い、（５）上記動作制御手段は、停止中の上記呼制御装置を起動させる際に、当該呼制御装置と、運転中の他の上記呼制御装置との間で、登録されている登録情報の内容を同期させる同期処理を行うことを特徴とする。

第２の本発明の制御プログラムは、（１）複数の呼制御装置と協働して、通信装置に対して呼制御処理を提供する制御装置に搭載されたコンピュータを、（２）上記呼制御装置の動作を制御する動作制御手段と、（３）上記呼制御装置の動作状態を管理する動作状態管理手段と、（４）当該制御装置に到来した呼制御処理信号の処理を、いずれかの上記呼制御装置に振分ける振分手段として機能させ、（５）上記動作制御手段は、当該制御装置に係るトラヒック量の測定結果に応じて、停止中の上記呼制御装置の起動を行い、（６）上記動作制御手段は、停止中の上記呼制御装置を起動させる際に、当該呼制御装置と、運転中の他の上記呼制御装置との間で、登録されている登録情報の内容を同期させる同期処理を行うことを特徴とする。

第３の本発明は、通信装置に呼制御処理を提供する呼制御システムにおいて、複数の呼制御装置と、上記呼制御装置と協働して上記通信装置に呼制御処理を提供する制御装置とを備え、上記制御装置として第１の本発明の御装置を適用したことを特徴とする呼制御システム。

第４の本発明は、通信装置に呼制御処理を提供する通信システムにおいて、（１）上記通信装置に呼制御処理を提供する呼制御システムを１又は複数備え、（２）それぞれの上記呼制御システムとして、第２の本発明の呼制御システムを適用したことを特徴とする。

本発明によれば、省電力化を実現しつつ、安定的な呼制御処理を実現する通信システムを提供することができる。

実施形態に係る通信システムの全体構成について示したブロック図である。 実施形態に係るＬＢ（制御装置）の機能的構成について示したブロック図である。 実施形態に係るＨＳＳの機能的構成について示したブロック図である。 実施形態に係るトラヒック監視装置の機能的構成について示したブロック図である。 実施形態に係るＨＳＳで管理されるデータについて示した説明図である。 実施形態に係るＬＢで管理されるデータについて示した説明図である。 実施形態に係るトラヒック監視装置で管理されるデータについて示した説明図である。 実施形態に係るＳ−ＣＳＣＦグループで、全てのＳ−ＣＳＣＦが運転中の状態で、ＲＥＧＩＳＴＥＲ信号が供給された場合の動作について示したシーケンス図である。 実施形態に係るＬＢでＲＥＧＩＳＴＥＲ信号が供給された場合の動作について示したフローチャートである。 実施形態に係るＳ−ＣＳＣＦグループで、サーバ停止が発生する場合の動作について示したシーケンス図である。 実施形態に係るＳ−ＣＳＣＦグループで、サーバ停止が発生する場合のＬＢの動作について示したフローチャートである。 実施形態に係るＳ−ＣＳＣＦグループで、一部のＳ−ＣＳＣＦが停止状態で、ＲＥＧＩＳＴＥＲ信号が供給された場合の動作について示したシーケンス図である。 実施形態に係るＳ−ＣＳＣＦグループで、発呼（ＩＮＶＩＴＥ信号）を受けた場合の動作について示したシーケンス図である。 実施形態に係るＬＢで、発呼（ＩＮＶＩＴＥ信号）を受けた場合の動作について示したフローチャートである。 実施形態に係るＳ−ＣＳＣＦグループで、サーバ起動が発生する場合の動作について示したシーケンス図である。 実施形態に係るＳ−ＣＳＣＦグループで、サーバ起動が発生する場合のＬＢの動作について示したフローチャートである。

（Ａ）主たる実施形態
以下、本発明による制御装置及びプログラム、並びに、呼制御システム、並びに、通信システムの一実施形態を、図面を参照しながら詳述する。なお、この実施形態の呼制御システムはＳ−ＣＳＣＦグループである。また、この実施形態の制御装置は、ＬＢ（Ｌｏａｄ Ｂａｌａｎｃｅｒ）である。

（Ａ−１）実施形態の構成
図１は、この実施形態の通信システム１の全体構成を示すブロック図である。

通信システム１は、アクセスネットワークＮＷを介して、ユーザが利用する端末９０（図１では、９０−１、９０−２）に対してネットワークサービスを提供するシステムであり、Ｐ−ＣＳＣＦ１０、Ｉ−ＣＳＣＦ２０、Ｎ個の呼制御システムとしてのＳ−ＣＳＣＦグループ３０（３０−１〜３０−Ｎ）、ＨＳＳ７０（Ｈｏｍｅ Ｓｕｂｓｃｒｉｂｅｒ Ｓｅｒｖｅｒ）、及びトラヒック監視装置８０を有している。なお、アクセスネットワークＮＷの構成や、アクセスネットワークＮＷに接続する端末９０の数は限定されないものである。

また、アクセスネットワークＮＷの種類は限定されないものであり、例えば、インターネット等のＩＰネットワークを適用することができる。

それぞれのＳ−ＣＳＣＦグループ３０（３０−１〜３０−Ｎ）は、代表Ｓ−ＣＳＣＦ（制御装置）としてのＬＢ４０（３０−１〜３０−Ｎ）と、ＬＢ４０の配下で動作する３台のＳ−ＣＳＣＦ６０（６０−１１〜６０−１３、６０−２１〜６０−２３、…、６０−Ｎ１〜６０−Ｎ３）により構成されている。例えば、図１では、Ｓ−ＣＳＣＦグループ３０−１は、１台のＬＢ４０−１と、３台の６０−１１〜６０−１３により構成されている。また、同様に、Ｓ−ＣＳＣＦグループ３０−Ｎは、１台のＬＢ４０−Ｎと、３台の６０−Ｎ１〜６０−Ｎ３により構成されている。なお、通信システム１においてＳ−ＣＳＣＦグループ３０を配置する数や、Ｓ−ＣＳＣＦグループ３０を構成するＳ−ＣＳＣＦ６０の数は限定されないものである。

Ｐ−ＣＳＣＦ１０は端末９０と通信システム１が最初に接するポイントであり、ＳＩＰのリクエスト／レスポンスを適切な装置（Ｉ−ＣＳＣＦ２０等）にフォワードする。

Ｉ−ＣＳＣＦ２０は主にユーザ（端末９０）の位置情報（当該ユーザのＵＲＩが登録（ＲＥＳＴＥＲ）されているＳ−ＣＳＣＦのアドレス）をＨＳＳ７０から取得し、ＳＩＰリクエストを取得したアドレス（ＬＢ４０のアドレス）へフォワードする。

ＨＳＳ７０は、通信システム１内で、ユーザ情報やサーバ（Ｓ−ＣＳＣＦグループ３０）等に関する情報を管理するものであり、Ｉ−ＣＳＣＦ２０からの要求に応じて、各Ｓ−ＣＳＣＦグループ３０（端末９０）へのユーザの振り分け先の決定等の制御機能も担っている。

トラヒック監視装置８０は、通信システム１内のトラヒック量をリアルタイムで監視し、トラヒック量等に応じて、ＬＢ４０経由でＳ−ＣＳＣＦ６０の起動／停止を実行する。

次に、ＨＳＳ７０の内部構成について、図３を用いて説明する。

ＨＳＳ７０は、Ｉ−ＣＳＣＦ２０又は配下のＳ−ＣＳＣＦ６０との通信を行う。

ＨＳＳ７０は、ＬＢ／Ｓ−ＣＳＣＦ割付情報管理部７１、ユーザプロファイル管理部７２、及びサービスプロファイル管理部７３を有している。

ユーザプロファイル管理部７２は、ユーザのプロファイルを管理する機能を担っている
サービスプロファイル管理部７３は、サービスプロファイルを管理する機能を担っている。

ＬＢ／Ｓ−ＣＳＣＦ割付情報管理部７１は、Ｓ−ＣＳＣＦグループ３０ごとに所属する装置に関する情報（以下、「グルーピング情報」と呼ぶ）も管理しているものとする。

ＬＢ／Ｓ−ＣＳＣＦ割付情報管理部７１は、例えば、図５のような形式で、グルーピング情報や、各Ｓ−ＣＳＣＦグループ３０に対して割り付けているユーザ数（割付ユーザ数）を管理している。

なお、通信システム１では、図５等に示すように、各Ｓ−ＣＳＣＦグループ３０、各ＬＢ４０、各Ｓ−ＣＳＣＦ６０に対してＩＤを付与して管理する構成となっている。また、通信システム１では、図５に示すように、各Ｓ−ＣＳＣＦグループ３０（３０−１〜３０−Ｎ）のＩＤ（グループＩＤ）は、それぞれ１〜Ｎと表わすものとする。さらに、通信システム１では、図５に示すように、各ＬＢ４０−１〜４０−ＮのＩＤ（ＬＢ−ＩＤ）は、それぞれ１〜Ｎと表わすものとする。さらにまた、通信システム１では、図５に示すように、各Ｓ−ＣＳＣＦ６０（６０−１１〜６０−１３、６０−２１〜６０−２３、…、６０−Ｎ１〜６０−Ｎ３）のＩＤ（Ｓ−ＣＳＣＦ−ＩＤ）は、１１〜１３、２１〜２３、…、Ｎ１〜Ｎ３）と表わすものとする。例えば、Ｓ−ＣＳＣＦグループ３０−１のグループＩＤは１、ＬＢ４０−１のＬＢ−ＩＤは１、Ｓ−ＣＳＣＦ６０−１１のＳ−ＣＳＣＦ−ＩＤは１１となる。

図５では、Ｓ−ＣＳＣＦグループ３０の単位（グループＩＤ単位）で、配下のＬＢ−ＩＤ及び管理対象Ｓ−ＣＳＣＦ＿ＩＤが管理されている。また、図５では、グループＩＤごと（Ｓ−ＣＳＣＦグループ３０）ごとに、割り当てたユーザ数（割付ユーザ数）も管理されている。

次に、各ＬＢ４０の内部構成について図２を用いて説明する。なお、この実施形態では、全てのＳ−ＣＳＣＦグループ３０において、ＬＢ４０は全て同じ構成であるものとして説明する。

ＬＢ４０は、配下のＳ−ＣＳＣＦ６０と協働して、端末９０に対してＳＩＰのサービス（呼制御処理のサービス）を提供する。また、ＬＢ４０は、配下の複数のＳ−ＣＳＣＦ６０にＩＮＶＩＴＥ信号等の信号処理を振り分ける負荷分散装置としても機能する。

ＬＢ４０は、ＲＥＧＩＳＴＥＲ信号を受信した場合、配下の全ての運転中又は閉塞中のＳ−ＣＳＣＦ６０にフォワードする。また、ＬＢ４０は、セッション制御受信時（ＩＮＶＩＴＥ信号受信時）は、配下のＳ−ＣＳＣＦ６０のうち、１台を選択してＩＮＶＩＴＥ信号を信号フォワードする。そして、配下のＳ−ＣＳＣＦ６０は、それぞれＳＩＰのセッション制御機能やレジストラサーバとして動作する。上述の通り、通信システム１では、Ｓ−ＣＳＣＦに関するサービスを提供する単位としてＳ−ＣＳＣＦグループ３０が存在し、それぞれのＳ−ＣＳＣＦグループ３０では、複数のＳ−ＣＳＣＦ（ＬＢ４０及びＳ−ＣＳＣＦ６０）が配置されている。すなわち、Ｐ−ＣＳＣＦ１０から見た場合、各Ｓ−ＣＳＣＦグループ３０は１つのＳ−ＣＳＣＦとして動作するものとして把握される。言い換えると、Ｐ−ＣＳＣＦ１０が、各Ｓ−ＣＳＣＦグループ３０に対して意識するのは、代表Ｓ−ＣＳＣＦであるＬＢ４０のみとなる。

ＬＢ４０は、信号制御部４１、Ｓ−ＣＳＣＦ起動／停止部４２、ルーチング情報処理部４３、Ｓ−ＣＳＣＦ状態管理部４４、ＲＥＧＩＳＴＥＲ情報管理部４５、Ｓ−ＣＳＣＦ管理情報記憶部４６を有している。

信号制御部４１は、配下のＳ−ＣＳＣＦ６０とＳＩＰ信号の送受信制御を行うものである。

Ｓ−ＣＳＣＦ起動／停止部４２は、トラヒック監視装置８０からのＳ−ＣＳＣＦ起動／停止指示を受付、配下のＳ−ＣＳＣＦ６０の起動／停止を制御するものである。

ルーチング情報処理部４３は、ＳＩＰ信号のルーチング制御をするものである。

ＲＥＧＩＳＴＥＲ情報管理部４５は、ＲＥＧＩＳＴＥＲ情報を管理するものである。

Ｓ−ＣＳＣＦ状態管理部４４は、配下のＳ−ＣＳＣＦ６０に関する情報を管理するものである。この実施形態のＳ−ＣＳＣＦ状態管理部４４では、例として、図６のような形式で、配下のＳ−ＣＳＣＦ６０に関する情報が管理されているものとする。

Ｓ−ＣＳＣＦ状態管理部４４では、図６に示すように、ＳＩＰ−ＵＲＩ（端末９０）ごとの、ＲＥＧＩＳＴＥＲ情報（Ｃｏｎｔａｃｔ情報、Ｐａｔｈ情報等）や、配下の各Ｓ−ＣＳＣＦ６０への、当該ＳＩＰ−ＵＲＩに係るＲＥＧＩＳＴＥＲ情報の登録状況（最終ＲＥＧＩＳＴＥＲ更新時間）などを管理している。また、Ｓ−ＣＳＣＦ状態管理部４４では、配下の各Ｓ−ＣＳＣＦ６０の運転状況（運転中、停止中又は閉塞中のいずれか）を管理している。

例えば、図６では、「ＡＡＡ」、「ＢＢＢ」というＳＩＰ−ＵＲＩに関する情報が登録されている。また、図６では、「ＡＡＡ」、「ＢＢＢ」に関するＲＥＧＩＳＴＥＲ情報について、最終ＲＥＳＧＩＳＴＥＲ更新時間が設定されているＳ−ＣＳＣＦ６０−１、６０−３には登録されていることを示している。一方、「ＡＡＡ」、「ＢＢＢ」に関するＲＥＧＩＳＴＥＲ情報について、最終ＲＥＳＧＩＳＴＥＲ更新時間が設定されていないＳ−ＣＳＣＦ６０−２には登録されていないことを示している。

ＬＢ４０では、例えば、図６に示すようなＳ−ＣＳＣＦ状態管理部４４の情報により、配下の各Ｓ−ＣＳＣＦ６０へのＲＥＧＩＳＴＥＲ情報の登録状況を把握している。そして、ＬＢ４０のＳ−ＣＳＣＦ起動／停止部４２は、停止しているＳ−ＣＳＣＦ６０が次に起動したときに、他のＳ−ＣＳＣＦ６０と登録内容を同期させる処理を行う。具体的には、ＬＢ４０は、図６に示すようなＳ−ＣＳＣＦ状態管理部４４の情報（各ＳＩＰ−ＵＲＩに関する最終ＲＥＧＩＳＴＥＲ更新時間等）を確認して、起動したＳ−ＣＳＣＦ６０と他のＳ−ＣＳＣＦ６０との差異を確認し、他のＳ−ＣＳＣＦ６０と同期させるためのＲＥＧＩＳＴＥＲ信号を生成して起動したＳ−ＣＳＣＦ６０に供給する。また、ＬＢ４０のＳ−ＣＳＣＦ起動／停止部４２は、起動したＳ−ＣＳＣＦ６０について、他のＳ−ＣＳＣＦ６０とＲＥＧＩＳＴＥＲ情報の同期がとれるまで、新たな呼制御（ＩＮＶＩＴＥ信号等の処理）を受付けない閉塞状態として制御する。

次に、トラヒック監視装置８０の内部構成について図４を用いて説明する。

トラヒック監視装置８０は、トラヒック状況監視部８１、トラヒック状況分析部８２、Ｓ−ＣＳＣＦ運転ポリシー情報管理部８３、Ｓ−ＣＳＣＦサーバ状態管理部８４、及びＳ−ＣＳＣＦ起動／停止処理部８５を有している。

トラヒック状況監視部８１は、通信システム１におけるトラヒック情報（アクセス状況）に関する情報を収集する機能を担っている。トラヒック状況監視部８１は、各ＬＢ４０−１〜３０−Ｎと、Ｉ−ＣＳＣＦ２０に流れる信号数（例えば、ＳＩＰメッセージ数）を、トラヒック情報として収集する。

トラヒック状況分析部８２は、トラヒック状況監視部８１が収集したトラヒック情報を分析する機能を担っている。トラヒック状況分析部８２は、トラヒック状況監視部８１の収集した内容に基づいて、Ｉ−ＣＳＣＦ２０及び各ＬＢ４０に流れる単位時間当たりの信号数（例えば、ＳＩＰメッセージ数）を把握する。この実施形態では、トラヒック状況分析部８２は、例として、１時間あたりに、Ｉ−ＣＳＣＦ２０及び各ＬＢ４０に流れるＳＩＰメッセージ数を把握するものとする。

Ｓ−ＣＳＣＦ運転ポリシー情報管理部８３は、各Ｓ−ＣＳＣＦグループ３０のＳ−ＣＳＣＦ６０の運転ポリシーを管理する機能を担っている。Ｓ−ＣＳＣＦ運転ポリシー情報管理部８３では、Ｓ−ＣＳＣＦグループ３０ごとに、運転中のＳ−ＣＳＣＦ６０を停止するポリシー（以下、「サーバ停止ポリシー」と呼ぶ）及び、運転中のＳ−ＣＳＣＦ６０を停止するポリシー（以下、「サーバ起動ポリシー」と呼ぶ）を管理している。Ｓ−ＣＳＣＦ運転ポリシー情報管理部８３が管理する運転ポリシーの内容詳細については後述する。

Ｓ−ＣＳＣＦサーバ状態管理部８４は、各Ｓ−ＣＳＣＦグループ３０のＳ−ＣＳＣＦ６０の運転状態を管理する機能を担っている。例えば、Ｓ−ＣＳＣＦサーバ状態管理部８４は、各ＬＢ４０へ問合せを行って各Ｓ−ＣＳＣＦグループ３０のＳ−ＣＳＣＦ６０の運転状態を把握するようにしても良い。

Ｓ−ＣＳＣＦ起動／停止処理部８５は、各Ｓ−ＣＳＣＦグループ３０のＳ−ＣＳＣＦ６０に対して、起動／停止指示を行う機能を担っている。Ｓ−ＣＳＣＦ起動／停止処理部８５は、Ｓ−ＣＳＣＦ運転ポリシー情報管理部８３で管理されている運転ポリシーにしたがって、各ＬＢ４０に配下のＳ−ＣＳＣＦ６０に対する起動又は停止に関する制御指示を行う。

次に、トラヒック監視装置８０のＳ−ＣＳＣＦサーバ状態管理部８４で記憶される運転ポリシーの構成例について説明する。この実施形態のトラヒック監視装置８０では、例として、図７のような形式で各Ｓ−ＣＳＣＦグループ３０の運転ポリシーを管理しているものとする。

Ｓ−ＣＳＣＦ運転ポリシー情報管理部８３では、Ｓ−ＣＳＣＦグループ３０（ＬＢ４０）ごとに、現在のトラヒック量（トラヒック状況分析部８２の分析結果）、サーバ停止ポリシー、サーバ停止ポリシーで適用する閾値（サーバ停止第１閾値、及び、サーバ停止第２閾値）、サーバ起動ポリシー、サーバ起動ポリシーで用いる閾値（サーバ起動第１閾値、及び、サーバ起動第２閾値）が管理されている。

図７では、図示の都合上、Ｓ−ＣＳＣＦグループ３０−１（ＬＢ４０−１）に係るサーバ停止ポリシーについてはＰＤ１、サーバ起動ポリシーについてはＰＵ１としている。そして、図７では、サーバ停止ポリシーＰＤ１については図７（ｂ）に示し、サーバ起動ポリシーＰＵ１については図７（ｃ）に示している。運転ポリシー（サーバ停止ポリシー、サーバ起動ポリシー）を記述するための言語や形式については限定されないものであるが、図７では、説明を簡易とするために自然言語を用いて図示している。実際には、例えば、図７に示すような内容を具現化する記述（プログラム言語を用いた記述）を行う必要がある。

上述の通り、サーバ停止ポリシーを記述する形式や内容については限定されないものであるが、図７（ｂ）に示すサーバ停止ポリシーＰＤ１では、ＬＢ４０−１のトラヒック量（１時間あたりのＳＩＰ信号処理数）が下がるほど、多くのサーバ（Ｓ−ＣＳＣＦ６０）を停止させるポリシーとしている。図７（ｂ）に示すサーバ停止ポリシーＰＤ１（ポリシー番号１、２）では、２つのサーバ停止閾値ＴＤ１、ＴＤ２（ＴＤ１＞ＴＤ２）を用いて、トラヒック量の下降に伴って段階的に多くのサーバ（Ｓ−ＣＳＣＦ６０）を停止するポリシーとなっている。なお、用いるサーバ停止閾値の数は限定されないものである。

ただし、図７（ｂ）に示すサーバ停止ポリシーＰＤ１（ポリシー番号３）では、時刻が９：００〜１２：００の間は、トラヒック量に関係なくサーバ（Ｓ−ＣＳＣＦ６０）を停止させないポリシーとなっている。

上述の通り、サーバ起動ポリシーを記述する形式や内容については限定されないものであるが、図７（ｃ）に示すサーバ起動ポリシーＰＵ１では、ＬＢ４０−１のトラヒック量（１時間あたりのＳＩＰ信号処理数）が上がるほど、多くのサーバ（Ｓ−ＣＳＣＦ６０）を起動させるポリシーとしている。図７（ｃ）に示すサーバ起動ポリシーＰＵ１（ポリシー番号１、２）では、２つのサーバ起動閾値ＴＵ１、ＴＵ２（ＴＵ１＜ＴＵ２）を用いて、トラヒック量の上昇に伴って段階的に多くのサーバ（Ｓ−ＣＳＣＦ６０）を起動するポリシーとなっている。なお、用いるサーバ起動閾値の数は限定されないものである。ただし、図７（ｃ）に示すサーバ起動ポリシーＰＵ１（ポリシー番号３）では、時刻が９：００〜１２：００の間は、トラヒック量に関係なく全てのサーバ（Ｓ−ＣＳＣＦ６０）を起動させるポリシーとなっている。

以上ように、Ｓ−ＣＳＣＦ運転ポリシー情報管理部８３では、当該ＬＢ４０のトラヒック量等を利用してＳ−ＣＳＣＦ６０を起動／停止する条件を自由に設定することが可能である。そして、Ｓ−ＣＳＣＦ起動／停止処理部８５は、Ｓ−ＣＳＣＦ運転ポリシー情報管理部８３で定義された運転ポリシーに従って、各ＬＢ４０に配下のＳ−ＣＳＣＦ６０の停止又は起動を指示する。

（Ａ−２）実施形態の動作
次に、以上のような構成を有する実施形態の通信システム１の動作を説明する。

以下では、説明を簡易とするために、Ｓ−ＣＳＣＦグループ３０−１〜３０−Ｎのうち、Ｓ−ＣＳＣＦグループ３０−１に係る動作についてのみ説明するが、他のＳ−ＣＳＣＦグループ３０内の動作についても同様である。

まず、端末９０−１からＲＥＧＩＳＴＥＲ信号が送出された場合の通信システム１の動作について、図８、図９を用いて説明する。なお、ここでは、初期状態として、Ｓ−ＣＳＣＦグループ３０−１内で、３つのＳ−ＣＳＣＦ６０−１１〜６０−１３の全てが運転中の状態であるものとする。

図８は、端末９０−１からＲＥＧＩＳＴＥＲ信号が送出された場合の通信システム１の動作について示したシーケンス図である。また、図９は、ＬＢ４０−１が、ＲＥＧＩＳＴＥＲ信号を受信する場合の動作について示したフローチャートである。

まず、端末９０−１から、送出されたＲＥＧＩＳＴＥＲ信号が、Ｐ−ＣＳＣＦ１０を介して、Ｉ−ＣＳＣＦ２０で受信されたものとする（Ｓ１０１）。

そして、Ｉ−ＣＳＣＦ２０は、ＨＳＳ７０に対して、当該ＲＥＧＩＳＴＥＲ信号の処理をいずれのＬＢ４０にルーチングするか（振り分けるか）を問い合わせる（Ｓ１０２）。

そして、ここでは、ＨＳＳ７０において当該ＲＥＧＩＳＴＥＲ信号についての処理（端末９０−１の登録先）が、ＬＢ４０−１（Ｓ−ＣＳＣＦグループ３０−１）に振り付けられ、ＬＢ４０−１のアクセス情報（アドレス情報）が、Ｉ−ＣＳＣＦ２０に通知されたものとする（Ｓ１０３）。

そして、Ｉ−ＣＳＣＦ２０は、その通知に基づいてＬＢ４０−１に、ＲＥＧＩＳＴＥＲ信号をフォワードする（Ｓ１０４）。

そして、ＲＥＧＩＳＴＥＲ信号を受信すると、ＬＢ４０−１では、配下のＳ−ＣＳＣＦ６０のうち、運転中のＳ−ＣＳＣＦ６０に対して、受信したＲＥＧＩＳＴＥＲ信号を複製して供給する（Ｓ１０５）。なお、ステップＳ１０５の処理は、図９のステップＳ２０１〜Ｓ２０４の処理に該当する。ここでは、上述の通り、全てのＳ−ＣＳＣＦ６０−１１〜６０−１３が運転中であるので、ＬＢ４０−１は、図９のステップＳ２０４の処理により、全てのＳ−ＣＳＣＦ６０−１１〜６０−１３に対してＲＥＧＩＳＴＥＲ信号を供給することになる。なお、ＬＢ４０−１の配下で、停止中のＳ−ＣＳＣ６０があった場合には、ＬＢ４０−１は、図９のステップＳ２０３の処理により、運転中又は閉塞中のＳ−ＣＳＣ６０に対してのみＲＥＧＩＳＴＥＲ信号を送信することになる。

そして、ＬＢ４０−１は、全てのＳ−ＣＳＣＦ６０−１１〜６０−１３から、ＲＥＧＩＳＴＥＲ信号について正常に処理されたことを示す応答信号（ＯＫのＳＩＰ信号）が返答されると、自身のＳ−ＣＳＣＦ管理情報記憶部４６等の情報をそのＲＥＧＩＳＴＥＲ信号に基づいて更新（端末９０−１に関する情報（行）を追加してＲＥＧＩＳＴＥＲ情報を設定）し、さらに、当該ＲＥＧＩＳＴＥＲ信号に対するＯＫの応答信号（ＯＫのＳＩＰメッセージ）を生成して、端末９０−１宛に返答する（Ｓ１０６、Ｓ１０７）。なお、ステップＳ１０６、Ｓ１０７の処理は、図９のステップＳ２０６〜Ｓ２０９の処理に該当する。

ここでは、全てのＳ−ＣＳＣＦ６０−１１〜６０−１３からＯＫの応答信号が返答され、ＬＢ４０−１は、図９のステップＳ２０８、Ｓ２０９の処理により、Ｓ−ＣＳＣＦ管理情報記憶部４６の情報を更新すると共に、ＯＫの応答信号（Ｓｅｒｖｉｃｅ−Ｒｏｕｔｅヘッダに自信のアドレスを設定したＳＩＰメッセージ）を返答したものとする。

なお、ＬＢ４０−１に、配下のＳ−ＣＳＣＦ６０のいずれかから、ＮＧの応答信号（ＮＧのＳＩＰメッセージ）が供給された場合には、ＬＢ４０−１は、図９のステップＳ２０７の処理により、ＮＧの応答信号（Ｓｅｒｖｉｃｅ−Ｒｏｕｔｅヘッダに自身のアドレスを設定したＳＩＰメッセージ）を生成して、端末９０−１宛に送信することになる。

次に、通信システム１において、Ｓ−ＣＳＣＦグループ３０−１のサーバ（Ｓ−ＣＳＣＦ６０）停止が行われる場合の動作について図１０、図１１を用いて説明する。図１０は、トラヒック監視装置８０において、サーバ停止ポリシーに基づいて、Ｓ−ＣＳＣＦグループ３０−１（ＬＢ４０−１）のサーバ（Ｓ−ＣＳＣＦ６０）停止を行うと判断された場合の通信システム１の動作について示したシーケンス図である。また、図１１は、ＬＢ４０−１が、トラヒック監視装置８０からサーバ停止指示を受けた場合の動作について示したフローチャートである。

なお、ここでは、初期状態として、Ｓ−ＣＳＣＦグループ３０−１内で、３つのＳ−ＣＳＣＦ６０−１１〜６０−１３の全てが動作している状態であるものとする。そして、トラヒック監視装置８０のＳ−ＣＳＣＦサーバ状態管理部８４には、図７に示すサーバ停止ポリシーＰＤ１が設定されているものとする。

まず、上述の通り、Ｓ−ＣＳＣＦグループ３０−１内で、３つのＳ−ＣＳＣＦ６０−１１〜６０−１３の全てが動作している状態で、トラヒック監視装置８０がＬＢ４０−１のトラヒック量を監視しているものとする（Ｓ３０１）。

そして、トラヒック監視装置８０において、ＬＢ４０−１のトラヒック量が、サーバ停止第１閾値以下となったことが検知され（Ｓ３０２）、Ｓ−ＣＳＣＦ運転ポリシー情報管理部８３に定義されたサーバ停止ポリシーに従って、ＬＢ４０−１に対してサーバ停止指示が行われたものとする（Ｓ３０３）。

そして、ＬＢ４０−１では、トラヒック監視装置８０からの通知に従って、Ｓ−ＣＳＣＦ６０−１１〜６０−１３から停止するものを１つ選択して、選択したＳ−ＣＳＣＦ６０（ここでは、Ｓ−ＣＳＣＦ６０−１３であるものとする）に、サーバ閉塞指示を通知する（Ｓ３０４）。なお、ＬＢ４０−１によるステップＳ３０４の処理は、図１１のステップＳ４０１、Ｓ４０２の処理に該当する。

そして、ＬＢ４０−１は、閉塞指示をしたＳ−ＣＳＣＦ６０−１３において、実行中(制御中)の呼（セッション）が無くなるまで待機した後、Ｓ−ＣＳＣＦ６０−１３に対してサーバ停止指示を通知し、Ｓ−ＣＳＣＦ６０−１３の動作を停止させる（Ｓ３０５、Ｓ３０６）。なお、ＬＢ４０−１によるステップＳ３０５の処理は、図１１のステップＳ４０３〜Ｓ４０５の処理に該当する。

このとき、Ｓ−ＣＳＣＦ６０−１３は、動作を停止するが、その後の起動指示に応じて起動する必要があるため、本明細書では、ネットワーク経由で指示信号を受信して起動することが可能な状態（スリープ状態）を「停止状態」と呼ぶものとする。これは、他のＳ−ＣＳＣＦ６０が停止する場合でも同様である。

次に、Ｓ−ＣＳＣＦグループ３０−１内で、１つのＳ−ＣＳＣＦ６０−１３が停止した状態で、端末９０−１から送出されたＲＥＧＩＳＴＥＲ信号がＬＢ４０−１にフォワードされる場合の動作について、図１２を用いて説明する。

まず、ここでは、上述のステップＳ１０１〜Ｓ１０４と同様に、端末９０−１から送出されたＲＥＧＩＳＴＥＲ信号がＬＢ４０−１にフォワードされたものとする（Ｓ５０１〜Ｓ５０４）。

そして、ＲＥＧＩＳＴＥＲ信号を受信すると、ＬＢ４０−１は、配下のＳ−ＣＳＣＦ６０のうち、運転中のＳ−ＣＳＣＦ６０−１１、６０−１２に対して、受信したＲＥＧＩＳＴＥＲ信号を複製して供給する（Ｓ５０５）。ここでは、上述の通り、全てのＳ−ＣＳＣＦ６０−１１、６０−１２のみが運転中（Ｓ−ＣＳＣＦ６０−１３が停止中）であるので、ＬＢ４０−１は、図９のステップＳ２０３の処理により、Ｓ−ＣＳＣＦ６０−１１、６０−１２に対してＲＥＧＩＳＴＥＲ信号を供給することになる。

そして、ＬＢ４０−１は、ＲＥＧＩＳＴＥＲ信号を供給したＳ−ＣＳＣＦ６０−１１、６０−１２から、ＲＥＧＩＳＴＥＲ信号に対して正常に処理されたことを示す応答信号（ＯＫのＳＩＰ信号）が返答されると、自身のＳ−ＣＳＣＦ管理情報記憶部４６の情報をそのＲＥＧＩＳＴＥＲ信号に基づいて更新（端末９０−１に関する情報（行）を追加してＲＥＧＩＳＴＥＲ情報を設定）し、さらに、当該ＲＥＧＩＳＴＥＲ信号に対するＯＫの応答信号（ＯＫのＳＩＰメッセージ）を生成して、端末９０−１宛に返答する（Ｓ５０６、Ｓ５０７）。

次に、端末９０−１から、ＩＮＶＩＴＥ信号が送出された場合の、通信システム１の動作について図１３、図１４を用いて説明する。なお、Ｓ−ＣＳＣＦグループ３０−１内で、２つのＳ−ＣＳＣＦ６０−１１、６０−１２が動作状態（Ｓ−ＣＳＣＦ６０−１３は停止中）であるものとする。図１３は、端末９０−１から、端末９０−１に発呼するためのＩＮＶＩＴＥ信号が送出された場合の通信システム１の動作について示したシーケンス図である。また、図１４は、ＬＢ４０−１が、ＩＮＶＩＴＥ信号を受信する場合の動作について示したフローチャートである。

まず、端末９０−１から、送出されたＩＮＶＩＴＥ信号がＰ−ＣＳＣＦ１０で受信されたものとする。そして、Ｐ−ＣＳＣＦ１０は、端末９０−１のＩＮＶＩＴＥ信号上のＲｏｕｔｅヘッダに基づいて、ＬＢ４０−１（Ｓ−ＣＳＣＦグループ３０−１）に、ＩＮＶＩＴＥ信号をフォワードするものとする（Ｓ６０１）。

そして、ＬＢ４０−１は、ＩＮＶＩＴＥ信号を受信すると（Ｓ６０２）、配下のＳ−ＣＳＣＦ６０の運転状況を確認し、運転中のＳ−ＣＳＣＦ６０の中からいずれかのＳ−ＣＳＣＦ６０を選択してＩＮＶＩＴＥ信号を送信する（Ｓ６０３）。なお、ステップＳ６０２、Ｓ６０３の処理は、図１４のステップＳ７０１〜Ｓ７０４の処理に該当する。ここでは、ＬＢ４０−１は、Ｓ−ＣＳＣＦ６０−１１を選択してＩＮＶＩＴＥ信号を送信したものとする。

そして、選択されたＳ−ＣＳＣＦ６０−１１は、受信した信号内容に基づいて以降の着信処理を開始し、実行する（Ｓ６０４）。なお、Ｓ−ＣＳＣＦ６０−１１によるＳ６０４以降の処理の詳細については図示していないが、例えば、従来のＳ−ＣＳＣＦの処理を適用することができる。なお、ステップＳ６０３、Ｓ６０４の処理は、図１４のステップＳ７０５、Ｓ７０６の処理に該当する。

次に、通信システム１において、Ｓ−ＣＳＣＦグループ３０−１のサーバ（Ｓ−ＣＳＣＦ６０）起動が行われる場合の動作について図１５、図１６を用いて説明する。図１５は、トラヒック監視装置８０において、サーバ起動ポリシーに基づいて、Ｓ−ＣＳＣＦグループ３０−１（ＬＢ４０−１）のサーバ（停止中のＳ−ＣＳＣＦ６０）起動を行うと判断された場合の通信システム１の動作について示したシーケンス図である。また、図１６は、ＬＢ４０−１が、トラヒック監視装置８０からサーバ起動指示を受けた場合の動作について示したフローチャートである。

なお、ここでは、初期状態として、Ｓ−ＣＳＣＦグループ３０−１内で、１つのＳ−ＣＳＣＦ６０−１３が停止している状態であるものとする。そして、トラヒック監視装置８０のＳ−ＣＳＣＦサーバ状態管理部８４には、図７に示すサーバ起動ポリシーＰＵ１が設定されているものとする。

まず、上述の通り、Ｓ−ＣＳＣＦグループ３０−１内で、１つのＳ−ＣＳＣＦ６０−１３が停止している状態で、トラヒック監視装置８０がＬＢ４０−１のトラヒック量を監視しているものとする（Ｓ８０１）。

そして、トラヒック監視装置８０において、ＬＢ４０−１のトラヒック量が、サーバ起動第２閾値以上となったことが検知され（Ｓ８０２）、Ｓ−ＣＳＣＦ運転ポリシー情報管理部８３に定義されたサーバ起動ポリシーＰＵ１に従って、ＬＢ４０−１に対してサーバ起動指示が行われたものとする（Ｓ８０３）。

そして、ＬＢ４０−１では、トラヒック監視装置８０からの通知に従って、唯一停止しているＳ−ＣＳＣＦ６０−１３を選択して、サーバ起動指示を通知する（Ｓ８０４）。なお、ＬＢ４０−１によるステップＳ８０４の処理は、図１６のステップＳ９０１、Ｓ９０２の処理に該当する。

そして、起動指示が通知されたＳ−ＣＳＣＦ６０−１３では、停止状態（スリープ状態）から起動し（Ｓ８０５）、当初は閉塞状態に遷移する（Ｓ８０６）。

そして、ＬＢ４０−１は、Ｓ−ＣＳＣＦ６０−１３の動作状態を監視して、起動完了すると、Ｓ−ＣＳＣＦ管理情報記憶部４６を参照して、ＳＩＰ−ＵＲＩごとに、最終ＲＥＧＩＳＴＥＲ時刻と、ＲＥＧＩＳＴＥＲ情報をチェックする。そして、ＬＢ４０−１は、Ｓ−ＣＳＣＦ６０−１３に不足しているＲＥＧＩＳＴＥＲ情報（他のＳ−ＣＳＣＦ６０−１１、６０−１２と比較して不足しているＲＥＧＩＳＴＥＲ情報）があった場合、その情報をＳ−ＣＳＣＦ６０−１３に追加するためのＲＥＧＩＳＴＥＲ信号を順次生成して、Ｓ−ＣＳＣＦ６０−１３に送信する等の処理を行い、Ｓ−ＣＳＣＦ６０−１３と、他のＳ−ＣＳＣＦ６０−１１、６０−１２とのＲＥＧＩＳＴＥＲ情報の同期を取る（Ｓ８０７）。なお、ＬＢ４０−１によるステップＳ８０５、Ｓ８０６の処理は、図１６のステップＳ９０５〜Ｓ９０７の処理に該当する。

そして、ＬＢ４０−１は、ＲＥＧＩＳＴＥＲ情報の同期処理が完了するとＳ−ＣＳＣＦ６０−１３に対して、閉塞解除を解除して、通常の運転中の状態に遷移する指示を通知し（Ｓ８０９）、Ｓ−ＣＳＣＦ６０−１３は閉塞状態を解除して運転中の状態に遷移する（Ｓ８１０）。なお、ＬＢ４０−１によるステップＳ８０９の処理は、図１６のステップＳ９０８の処理に該当する。

（Ａ−３）実施形態の効果
この実施形態によれば、以下のような効果を奏することができる。

通信システム１では、複数のＳ−ＣＳＣＦ６０をグルーピングしてＳ−ＣＳＣＦグループ３０（呼制御処理システム）を構成すること、および、トラヒック監視装置８０との連携、必要情報を管理することで、トラヒック量等に応じたサーバ（Ｓ−ＣＳＣＦ６０等）の効率的な運用を行うことができる。例えば、通信システム１では、トラヒックの少ない時間帯等はサーバの運転台数を減らしてサービスできる。また、通信システム１では、例えば、トラヒック上昇時等も柔軟にサーバ起動を行うことが可能となっており、サーバ停止による利便性の低下を防いでいる。すなわち、通信システム１では、トラヒック量等により柔軟に起動するサーバ数を制御できるので、省電力化を実現しつつ、安定的な呼制御処理を実現することができる。

また、通信システム１及びＳ−ＣＳＣＦグループ３０の構成は、ＩＭＳの構成に準拠しており、連携するＰ−ＣＳＣＦ／Ｉ−ＣＳＣＦ等は特別な動作を意識する必要はなく、既存の事業者ネットワークに簡易に適用することが可能である。

（Ｂ）他の実施形態
本発明は、上記の実施形態に限定されるものではなく、以下に例示するような変形実施形態も挙げることができる。

（Ｂ−１）上記の実施形態では、通信システム１に複数のＳ−ＣＳＣＦグループ３０が配置される構成となっているが、１つのＳ−ＣＳＣＦグループ３０だけを配置するようにしても良い。その場合、ＬＢ４０は、Ｐ−ＣＳＣＦ１０やＩ−ＣＳＣＦ２０を介さずに直接端末９０と通信する構成としても良い。すなわち、ＬＢ４０がＳＩＰサービス（呼制御処理）を提供する通信装置（端末９０）と通信する際の接続構成については、上記の実施形態の構成限定されないものである。

（Ｂ−２）上記の実施形態では、トラヒック監視装置８０が各Ｓ−ＣＳＣＦグループ３０に対する運転ポリシーを管理し、トラヒック量に応じてＳ−ＣＳＣＦ６０の停止又は起動を指示する構成としている。しかし、通信システム１において、トラヒック量を監視する手段や、各Ｓ−ＣＳＣＦグループ３０に対する制御手段を実現する具体的構成については、上記の実施形態（トラヒック監視装置８０を用いた構成）に限定されないものである。例えば、各ＬＢ４０で、当該ＬＢ４０に係る運転ポリシーの管理やトラヒック量の測定を行い、当該ＬＢ４０の判断で配下のＳ−ＣＳＣＦ６０に対する停止／起動の制御を行う構成としても良い。

（Ｂ−３）上記の実施形態では、複数のサーバに分散して各種データ（例えば、運転ポリシーや各サーバの動作状況等）を管理する構成となっているが、一元的に別サーバ等で管理する構成としても良い。

（Ｂ−５）上記の実施形態では、サーバ停止ポリシーに基づいてＳ−ＣＳＣＦ６０を停止（スリープ状態）とするものとして説明したが、停止（スリープ状態）ではなく、より低消費電力で動作する動作モードであればその動作状態は限定されないものである。例えば、Ｓ−ＣＳＣＦ６０のＣＰＵを動作させる数や動作クロック数を下げることにより、低消費電力で動作させることができる。

１…通信システム、ＮＷ…アクセスネットワーク、１０…Ｐ−ＣＳＣＦ、２０…Ｉ−ＣＳＣＦ、３０、３０−１〜３０−Ｎ…Ｓ−ＣＳＣＦグループ３０、４０、４０−１〜４０−Ｎ…ＬＢ、４１…信号制御部、４２…Ｓ−ＣＳＣＦ起動／停止部、４３…ルーチング情報処理部、４４…Ｓ−ＣＳＣＦ状態管理部、４５…ＲＥＧＩＳＴＥＲ情報管理部、４６…Ｓ−ＣＳＣＦ管理情報記憶部、６０、６０−１〜６０−３…Ｓ−ＣＳＣＦ６０、７０…ＨＳＳ、７１…ＬＢ／Ｓ−ＣＳＣＦ割付情報管理部、７２…プロファイル管理部、７３…サービスプロファイル管理部、８０…トラヒック監視装置、８１…トラヒック状況監視部、８２…トラヒック状況分析部、８３…Ｓ−ＣＳＣＦ運転ポリシー情報管理部、８４…Ｓ−ＣＳＣＦサーバ状態管理部、８５…Ｓ−ＣＳＣＦ起動／停止処理部、９０、９０−１、９０−２…端末。

Claims (8)

1. 複数の呼制御装置と協働して、通信装置に対して呼制御処理を提供する制御装置であって、
   上記呼制御装置の動作を制御する動作制御手段と、
   上記呼制御装置の動作状態を管理する動作状態管理手段と、
   当該制御装置に到来した呼制御処理信号の処理を、いずれかの上記呼制御装置に振分ける振分手段とを有し、
   上記動作制御手段は、当該制御装置に係るトラヒック量の測定結果に応じて、停止中の上記呼制御装置の起動を行い、
   上記動作制御手段は、停止中の上記呼制御装置を起動させる際に、当該呼制御装置と、運転中の他の上記呼制御装置との間で、登録されている登録情報の内容を同期させる同期処理を行う
   ことを特徴とする制御装置。
2. 上記通信装置から、当該通信装置に係る登録情報の登録を要求する登録要求信号が到来すると、上記呼制御装置のうち、少なくとも運転中の上記呼制御装置に、その登録要求信号を通知する登録要求信号処理手段をさらに有することを特徴とする請求項１に記載の制御装置。
3. 上記動作制御手段は、当該制御装置に係るトラヒック量の測定結果に応じて、一部の上記呼制御装置の停止を行うことを特徴とする請求項１又は２に記載の制御装置。
4. 上記動作制御手段は、上記呼制御装置を停止させる際に、当該呼制御装置が処理中の呼制御処理が終了するまで、当該呼制御装置を新規の呼制御処理を受付けない閉塞状態に制御することを特徴とする請求項３に記載の制御装置。
5. 上記動作制御手段は、停止中の上記呼制御装置を起動させる際に、当該呼制御装置について同期処理が完了するまで、当該呼制御装置を新規の呼制御処理を受付けない閉塞状態に制御することを特徴とする請求項４に記載の制御装置。
6. 複数の呼制御装置と協働して、通信装置に対して呼制御処理を提供する制御装置に搭載されたコンピュータを、
   上記呼制御装置の動作を制御する動作制御手段と、
   上記呼制御装置の動作状態を管理する動作状態管理手段と、
   当該制御装置に到来した呼制御処理信号の処理を、いずれかの上記呼制御装置に振分ける振分手段として機能させ、
   上記動作制御手段は、当該制御装置に係るトラヒック量の測定結果に応じて、停止中の上記呼制御装置の起動を行い、
   上記動作制御手段は、停止中の上記呼制御装置を起動させる際に、当該呼制御装置と、運転中の他の上記呼制御装置との間で、登録されている登録情報の内容を同期させる同期処理を行う
   ことを特徴とする制御プログラム。
7. 通信装置に呼制御処理を提供する呼制御システムにおいて、
   複数の呼制御装置と、上記呼制御装置と協働して上記通信装置に呼制御処理を提供する制御装置とを備え、
   上記制御装置として請求項１〜５のいずれかに記載の制御装置を適用したことを特徴とする呼制御システム。
8. 通信装置に呼制御処理を提供する通信システムにおいて、
   上記通信装置に呼制御処理を提供する呼制御システムを１又は複数備え、
   それぞれの上記呼制御システムとして、請求項７に記載の呼制御システムを適用したことを特徴とする通信システム。

Images