WO2014002196A1

WO2014002196A1 - 通信制御装置、通信制御方法及び通信制御システム

Info

Publication number: WO2014002196A1
Application number: PCT/JP2012/066292
Authority: WO
Inventors: 英彦藤本
Original assignee: 富士通株式会社
Priority date: 2012-06-26
Filing date: 2012-06-26
Publication date: 2014-01-03
Also published as: CN104412571A; US20150103993A1; CN104412571B; JPWO2014002196A1; JP5954414B2

Abstract

　呼接続数管理部（１６）は、呼処理を行う各呼制御サーバの処理している呼の数を表す呼接続数を取得する。サーバ停止制御部（１５）は、呼制御サーバ毎の呼接続数を基に第一の呼制御サーバを選択し、第一の呼制御サーバに割り当てている呼処理を他の呼制御サーバに移行し、第一の呼制御サーバに割り当てている呼処理がなくなると第一の呼制御サーバを停止させる。振分制御部（１２）は、呼処理に関する処理要求を受け、処理要求に対応する呼処理を行っていた呼制御サーバがサーバ停止制御部（１５）により停止されている場合、サーバ停止制御部（１５）が前記処理要求に対応する呼処理を移行した先の前記他の呼制御サーバに前記処理要求を振分ける。

Description

通信制御装置、通信制御方法及び通信制御システム

　本発明は、通信制御装置、通信制御方法及び通信制御システムに関する。

　近年、通信サービスの分野において、ブロードバンド契約者の増加やサービスの多様化により、トラフィック量が増加しつつある。このような傾向から、通信分野で用いるサーバには、将来的なトラフィック量にも耐えうる性能が求められている。

　このように求められる性能を実現するにあたり、１台のサーバを大容量化していく方法では、対応できる性能に限界がある。また、最近では、スモールスタートからの段階的なトラフィック変動への設備有効活用や省電力化対策が求められている。このような状況の中で、従来のＡＣＴ／ＳＢＹ（Active/Standby）機能や２重化構造だけでは、サーバに求められる要件を満たせなくなってきている。そのため、複数台のサーバをベースとした通信制御システムを用いることで、システムの性能及び規模向上を実現することが提案されている。

　そうした中、クライアントからの単位時間あたりの処理要求数の最大値から算出したサーバ１台あたりの処理数を用いて、現在の要求を処理するのに必要なサーバ台数を求め、停止可能なサーバ又は起動すべきサーバがあるか否かを判定する従来技術がある（例えば、特許文献１参照）。

　また、複数のサーバの優先度にしたがい、優先度の高いサーバから閾値に達するまで要求を割り当てることで、サーバ稼働台数を増減させる従来技術がある（例えば、特許文献２参照）。

特開２０１１－０１５１９６号公報特開２０１１－０１３８７０号公報

　しかしながら、要求を処理するのに必要なサーバ台数を基にサーバを停止又は起動させる従来技術では、停止しようとしているサーバに対する継続処理要求を、サーバが全て処理し終わるまでは、サーバを停止することができない。そのため、効率的に省電力化することは困難である。特に、呼制御を行うサーバの場合、処理時間は利用者の利用状況によって変わるため、省電力化のための最適な制御ができないおそれがある。また、優先度にしたがって要求を割り当てる従来技術では、一時的に負荷が高くなり優先度の低いサーバに処理が割り当てられた場合、その後負荷が低くなっても割り当てられた処理が残っている優先度の低いサーバは、処理が終了するまで停止することができない。

　開示の技術は、上記に鑑みてなされたものであって、通信システムの消費電力を軽減する通信制御装置、通信制御方法及び通信制御システムを提供することを目的とする。

　本願の開示する通信制御装置、通信制御方法及び通信制御システムは、一つの態様において、呼接続数管理部は、呼処理を行う各呼制御サーバの処理している呼の数を表す呼接続数を取得する。サーバ停止制御部は、前記サーバ毎の呼接続数を基に前記呼制御サーバから第一の呼制御サーバを選択し、前記第一の呼制御サーバに割り当てている呼処理を他の呼制御サーバに移行し、前記第一の呼制御サーバに割り当てている呼処理がなくなると前記第一の呼制御サーバを停止させる。振分制御部は、呼処理に関する処理要求を受け、前記処理要求に対応する呼処理を行っていた呼制御サーバが前記サーバ停止制御部により停止されている場合、前記サーバ停止処理部が前記処理要求に対応する呼処理を移行した先の前記他の呼制御サーバに前記処理要求を振分ける。

　本願の開示する通信制御装置、通信制御方法及び通信制御システムの一つの態様によれば、通信システムの消費電力を軽減することができるという効果を奏する。

図１は、実施例に係る通信制御システムのブロック図である。図２は、呼情報の一例の図である。図３は、サーバ管理情報の一例の図である。図４は、呼接続情報リストの一例の図である。図５は、サーバ状態管理テーブルの一例の図である。図６は、呼処理の移動が発生する前の各呼制御サーバが管理する呼処理を表す図である。図７は、呼処理の移動が発生した後の各呼制御サーバが管理する呼処理を表す図である。図８は、呼処理を戻す前の各呼制御サーバが管理する呼処理を表す図である。図９は、呼処理を戻した後の各呼制御サーバが管理する呼処理を表す図である。図１０は、通信制御装置を２台のサーバで構成した場合の構成例の図である。図１１は、通信確立までの処理のシーケンス図である。図１２は、呼処理の移行の処理のシーケンス図である。図１３は、移行後の呼処理のシーケンス図である。図１４は、呼処理の戻し処理のシーケンス図である。図１５は、戻した後の呼処理のシーケンス図である。図１６は、停止対象サーバ及び移行先サーバの決定処理のフローチャートである。図１７は、移行前の呼接続情報リストの状態の一例を示す図である。図１８は、呼接続数昇順ソート結果の一例を示す図である。図１９は、停止対象サーバ及び移行先サーバの決定処理が行われたときの計算結果の一例を示す図である。図２０は、移行されていた呼処理を戻す呼制御サーバの決定処理のフローチャートである。図２１は、呼処理を戻す前の呼接続情報リストの状態の一例を示す図である。図２２は、呼処理を戻す呼制御サーバの決定処理が行われたときの計算結果の一例を示す図である。図２３は、サーバ管理情報の遷移を表す図である。図２４は、呼情報の遷移を表す図である。図２５は、サーバ状態管理テーブルの遷移を表す図である。図２６Ａは、従来技術を用いた場合における呼接続の状態の一例を示す図である。図２６Ｂは、本実施例に係る通信制御装置を用いた場合における呼接続数の状態の一例を示す図である。図２７Ａは、従来技術を用いた場合における呼接続の状態の他の例を示す図である。図２７Ｂは、本実施例に係る通信制御装置を用いた場合における呼接続数の状態の他の例を示す図である。図２８は、通信制御装置のハードウェア構成図である。

　以下に、本願の開示する通信制御装置、通信制御方法及び通信制御システムの実施例を図面に基づいて詳細に説明する。なお、以下の実施例により本願の開示する通信制御装置、通信制御方法及び通信制御システムが限定されるものではない。

　図１は、実施例に係る通信制御システムのブロック図である。本実施例に係る通信制御システムは、通信制御装置１及び呼制御サーバ２１～２２を有している。ここで、図１では、呼制御サーバ２１及び２２の２台のみを記載しているが、呼制御サーバは３台以上あってもよい。以下では各呼制御サーバを区別しない場合、「呼制御サーバ２０」と言う。通信制御装置１と呼制御サーバ２０とはネットワークで接続されている。

　また、発信側システム３１と着信側システム４１との組合せは、呼制御サーバ２１によりシステム間の呼処理が行われているシステムであることを表している。また、発信側システム３２と着信側システム４２との組合せは、呼制御サーバ２２によりシステム間の呼処理が行われているシステムであることを表している。図１では、呼処理を管理している呼制御サーバとの対応を表すため、呼制御サーバ２１及び２２と発信側システム３１、３２及び着信側システム４１、４２とのそれぞれが接続されているように表している。ただし、発信側システム３１、３２及び着信側システム４１、４２は、通信制御装置１と呼制御サーバ２１～２２とを接続しているネットワークに接続していても良い。以下の説明では、各発信側システムを区別しない場合には、「発信側システム３０」と言う。また、各着信側システムを区別しない場合には、「着信側システム４０」という。

　通信制御装置１は、記憶部１０、サーバ起動制御部１１、振分制御部１２、通信制御部１３、移行先サーバ管理部１４、サーバ停止制御部１５、呼接続数管理部１６、呼情報アクセス制御部１７及び呼番号管理部１８を有している。

　記憶部１０は、サーバ状態管理テーブル１０１、呼接続情報リスト１０２、サーバ管理情報１０３及び呼情報１０４のそれぞれのフォーマットを記憶している。

　図２は、呼情報の一例の図である。例えば、呼情報１０４は、図２に示すように、呼番号、呼状態、着番号、発番号、通話開始時刻及びその他情報のそれぞれが対応するように登録されているテーブルなどである。呼状態は、呼番号が割り当てられた呼が通話中か否かなどの呼の状態を示す情報である。着番号は、着信側の装置の電話番号を示す情報である。発番号は、発信側の装置の電話番号を示す情報である。通話開始時刻は、発信側の装置と着信側の装置との間で通話が開始された時刻を表す情報である。その他情報は、図２では、「ｅｔｃ」として表される情報であり、呼に付随する各種情報である。

　図３は、サーバ管理情報の一例の図である。例えば、サーバ管理情報１０３は、図３に示すように、呼番号、運転状態、呼生成サーバ及び移行先サーバのそれぞれが対応するように登録されているテーブルなどである。運転状態は、呼番号が割り当てられた呼の呼処理が、その呼を生成した呼制御サーバで管理されているか、その呼処理が呼生成サーバから他の呼制御サーバに移行され移行先の呼制御サーバで管理されているかを表す情報である。また、呼生成サーバは、呼番号が割り当てられた呼を生成した呼制御サーバの情報である。以下では、呼を生成した呼制御サーバを「呼生成サーバ」と言う場合がある。移行先サーバは、後述する呼生成サーバから他の呼制御サーバへ呼処理の移行が行われた場合の、呼処理を移行した先の呼制御サーバの情報である。以下では、呼処理を移行した先の呼制御サーバを「移行先サーバ」と言う場合がある。サーバ管理情報１０３では、呼に割り当てられていない呼番号に対応する運転状態は「空き」とされ、呼生成サーバ及び移行先サーバは「ＮＵＬＬ」とされている。

　図４は、呼接続情報リストの一例の図である。例えば、呼接続情報リスト１０２は、図４に示すように、サーバ番号、通常処理呼数、移行処理呼数及び移行元サーバのそれぞれが対応するように登録されているテーブルなどである。サーバ番号は、各呼制御サーバ２０の識別情報である。通常処理呼数は、対応するサーバ番号を有する呼制御サーバ２０が生成し管理している呼の個数である。移行処理個数は、対応するサーバ番号を有する呼制御サーバ２０に呼処理が移行された呼の移行元サーバ毎の個数である。呼生成サーバは、呼番号が割り当てられた呼を生成した呼制御サーバの識別情報である。移行先サーバは、対応するサーバ番号を有する呼制御サーバ２０に呼処理を移行した呼制御サーバ２０の識別情報である。呼接続情報リスト１０２は、後述する呼接続数管理部１６により生成される。

　図５は、サーバ状態管理テーブルの一例の図である。例えば、サーバ状態管理テーブル１０１は、図５に示すように、サーバ番号、アドレス、運転状態、移行先サーバアドレス及び新規イベント受付可否のそれぞれが対応するように登録されているテーブルなどである。サーバ番号は、各呼制御サーバ２０の識別情報である。運転状態は、対応するサーバ番号を有する呼制御サーバ２０が運転中か停止中かを表す情報である。移行先サーバアドレスは、対応するサーバ番号を有する呼制御サーバ２０が有していた呼処理が移行された呼制御サーバ２０のアドレスである。新規イベント受付可否は、対応するサーバ番号を有する呼制御サーバ２０が新規イベントを受け付けることができるか否かを表す情報である。

　通信制御部１３は、呼制御サーバ２０、発信側システム３０及び着信側システム４０からデータを受信し、受信したデータを処理する各部にデータを出力する。また、通信制御部１３は、各部から出力されたデータを受信し、呼制御サーバ２０、発信側システム３０及び着信側システム４０へデータを送信する。このように、通信制御装置１の各部は、実際には通信制御部１３を介して呼制御サーバ２０、発信側システム３０及び着信側システム４０とデータのやり取りを行うが、以下の説明では、便宜上、各部が呼制御サーバ２０とデータの授受を行っているように説明する場合がある。

　呼番号管理部１８は、発信側システム３０から呼設定の要求を受けた呼制御サーバ２０から呼番号取得要求を受ける。呼番号管理部１８は、呼情報１０４の呼状態を確認し、使用されていない呼番号を特定する。呼番号管理部１８は、呼制御サーバ２０からの呼番号取得要求に対して使用されていない呼番号を割り当てる。そして、呼番号管理部１８は、呼番号取得要求を送信してきた呼制御サーバ２０へ割り当てた呼番号を送信する。

　さらに、呼番号管理部１８は、割り当てた呼番号に対応するサーバ管理情報１０３の運転状態の欄に「通常」と登録する。また、呼番号管理部１８は、割り当てた呼番号に対応するサーバ管理情報１０３の呼生成サーバの欄にその呼番号を送信した呼制御サーバ２０の識別情報を登録する。

　呼情報アクセス制御部１７は、ある呼制御サーバ２０が管理している呼の情報は他の呼制御サーバ２０がアクセスできないようにするなどの排他制御機能を具備している。そして、呼情報アクセス制御部１７は、呼制御サーバ２０が呼番号に応じて個情報にアクセスし参照や更新などを行うための機能を提供する。

　例えば、通話を確立する場合、呼情報アクセス制御部１７は、呼番号管理部１８が割り当てた呼番号とその番号に対応する発番号や着番号などの情報を呼制御サーバ２０から受信する。そして、呼情報アクセス制御部１７は、受信した発番号、着番号などの情報を呼情報１０４に登録する。さらに、呼情報アクセス制御部１７は、受信した呼番号に対応する呼情報１０４の呼状態を発呼状態に変更する。その後、呼情報アクセス制御部１７は、呼制御サーバ２０から呼情報読出要求を受けると、呼情報１０４を読み出して呼制御サーバ２０へ送信する。また、呼情報アクセス制御部１７は、呼の状態が遷移した後に、呼制御サーバ２０から呼情報書込要求を受ける。そして、呼情報アクセス制御部１７は、呼の遷移状態を表すように呼情報１０４の呼状態を変更する。そして通話状態になると、呼情報アクセス制御部１７は、呼情報１０４の呼状態を「通話中」に変更する。

　また、通話を終了する場合も同様に、呼情報アクセス制御部１７は、呼制御サーバ２０から呼情報読出要求を受けると、呼情報１０４を読み出して呼制御サーバ２０へ送信する。また、呼情報アクセス制御部１７は、呼の状態が遷移した後に、呼制御サーバ２０から呼情報書込要求を受ける。そして、呼情報アクセス制御部１７は、呼の遷移状態を表すように呼情報１０４の呼状態を変更する。そして通話の切断が成功すると、呼情報アクセス制御部１７は、呼情報１０４における通話の切断が成功した呼の呼番号に対応する呼状態を「空き」に変更するとともに、その呼番号に対応する着番号、着番号、通話開始時間及びその他情報を呼情報１０４から削除する。

　呼接続数管理部１６は、後述するサーバ停止制御部１５から呼接続情報取得要求を受けると、サーバ管理情報１０３における運転状態が「通常」となっている呼処理を抽出し、各呼生成サーバ毎に集計する。そして、呼接続数管理部１６は、集計結果を呼接続情報リスト１０２における各呼制御サーバの通常処理呼数に登録する。また、呼接続数管理部１６は、サーバ管理情報１０３における運転状態が「移行」となっている呼処理を抽出し、移行先サーバ毎に且つ呼生成サーバ毎に集計する。そして、呼接続数管理部１６は、集計した各移行先サーバに対応する呼接続情報リスト１０２における呼制御サーバ２０を特定する。呼接続数管理部１６は、サーバ管理情報１０３において、特定した呼制御サーバ２０を移行先サーバとする呼生成サーバの識別情報を、呼接続情報リスト１０２の特定した呼制御サーバに対応する移行元サーバ番号の欄に登録する。さらに、呼接続数管理部１６は、登録した移行元サーバ番号に対応する移行処理呼数の欄に集計結果を登録する。

　サーバ停止制御部１５は、定期的に呼接続数管理部１６に対して呼接続情報取得要求を送信する。ここで、呼接続情報要求を送信する周期は、短ければサーバを停止の頻度を上げることができるので、より省電力化を図ることができるが、通信制御装置の負荷が高くなる。そこで、呼接続情報要求を送信する周期は、運用状況に合わせて決められることが好ましい。

　サーバ停止制御部１５は、呼接続数管理部１６が更新した呼接続情報リストを参照し、停止可能なサーバがあるか否かを判定する。ここで、サーバ停止制御部１５による、停止可能サーバの判定について、詳細に説明する。

　サーバ停止制御部１５は、サーバが停止可能か否かを判定するためのサーバ停止監視閾値を予め記憶している。例えば、サーバ停止監視閾値は、最大負荷量の２０％などとすることができる。そして、サーバ停止制御部１５は、呼接続情報リスト１０２から各呼制御サーバ２０が管理する通常処理呼数と移行処理呼数を取得する。そして、サーバ停止制御部１５は、呼制御サーバ２０毎に通常処理個数と移行処理個数とを合計し呼接続数を算出する。その後、サーバ停止制御部１５は、呼接続数の昇順に呼制御サーバ２０をソートする。そして、サーバ停止制御部１５は、昇順の最上位から最下位に向けて１つずつチェック対象サーバを選択し以下の処理を繰り返していく。サーバ停止制御部１５は、チェック対象サーバの次の順位の呼制御サーバ２０から最下位の呼制御サーバ２０までの間で、そのサーバが管理する呼接続数にチェック対象サーバの呼接続数を加算してもサーバ停止監視閾値を超えないサーバがあるか否かを判定する。サーバ停止制御部１５は、チェック対象サーバの呼接続数を加算してもサーバ停止監視閾値を超えないサーバがある場合、そのチェック対象サーバを停止対象サーバと判定する。この停止対象サーバが、「第一の呼制御サーバ」の一例にあたる。そして、サーバ停止制御部１５は、停止対象サーバの呼接続数を加算してもサーバ停止監視閾値を超えないサーバのうち順位が最も低い呼制御サーバ２０を移行先サーバとして決定する。そして、サーバ停止制御部１５は、呼処理を移行することにより各呼制御サーバ２０が管理することになった呼処理の数を計算結果として求める。サーバ停止制御部１５は、チェック対象サーバが次の呼制御サーバ２０に移った場合にもこの計算結果を保持していき、呼処理の移行が発生する都度更新していく。

　全ての呼制御サーバ２０に対する停止可能か否かのチェックが完了すると、サーバ停止制御部１５は、停止対象サーバの振分けの停止を振分制御部１２へ通知する。

　さらに、サーバ停止制御部１５は、サーバ管理情報１０３における停止対象サーバの運転状態の「停止中」への変更及び移行先サーバの登録を移行先サーバ管理部１４に通知する。

　移行先サーバ管理部１４からサーバ管理情報１０３の更新の完了通知を受けると、サーバ停止制御部１５は、停止対象サーバが管理していた呼の移行先サーバを振分制御部１２に通知し、サーバ状態管理テーブル１０１の更新を振分制御部１２に指示する。

　次に、サーバ停止制御部１５は、停止対象サーバである呼制御サーバ２０に停止命令を送信する。

　サーバ起動制御部１１は、定期的に呼接続数管理部１６に対して呼接続情報取得要求を送信する。ここで、呼接続情報要求を送信する周期は、短ければサーバの起動の頻度を上げることができ、サーバが高負荷になることを抑えることができるが、通信制御装置１の負荷が高くなる。そこで、呼接続情報要求を送信する周期は、運用状況に合わせて決められることが好ましい。

　サーバ起動制御部１１は、呼接続数管理部１６が更新した呼接続情報リスト１０２を参照し、停止中サーバがあるか否かを判定する。停止中サーバがある場合、サーバ起動制御部１１は、予め記憶しているサーバ起動監視閾値を超える負荷量を有する呼制御サーバ２０（以下、「高負荷サーバ」という場合がある。）があるか否かを判定する。ここで、サーバ起動監視閾値は、サーバ停止監視閾値よりも低い値を取る。例えば、サーバ停止監視閾値を最大負荷量の２０％とした場合、サーバ起動監視閾値は、最大負荷量の５０％などとすることができる。

　高負荷サーバがある場合、サーバ起動制御部１１は、高負荷サーバに移行されている呼処理を移行元サーバに戻すことを決定する。サーバ起動制御部１１は、サーバ管理情報の更新要求を移行先サーバ管理部１４へ通知する。

　移行先サーバ管理部１４からサーバ管理情報１０３の更新の完了通知を受けると、サーバ起動制御部１１は、呼処理を戻す移動元サーバである呼制御サーバ２０に起動命令を送信する。

　さらに、サーバ起動制御部１１は、高負荷サーバの情報をサーバ状態管理部に通知し、且つサーバ状態管理テーブル１０１の更新を振分制御部１２に指示する。

　さらに、サーバ起動制御部１１は、サーバ管理情報１０３における呼処理を戻す移行元サーバの運転状態の「通常」への変更及び移行先サーバを「ＮＵＬＬ」に戻すことを移行先サーバ管理部１４に指示する。

　移行先サーバ管理部１４は、サーバ管理情報１０３における停止対象サーバの運転状態の「停止中」への変更及び移行先サーバの登録の要求をサーバ停止制御部１５から受ける。そして、移行先サーバ管理部１４は、サーバ管理情報１０３における停止対象サーバの運転状態を「停止中」へ変更し、さらに停止対象サーバから呼が移行された移行先サーバの識別情報を登録する。その後、移行先サーバ管理部１４は、サーバ管理情報１０３の更新の完了通知をサーバ停止制御部１５へ出力する。

　また、移行先サーバ管理部１４は、サーバ管理情報１０３における呼処理を戻す移行元サーバの運転状態の「通常」への変更及び移行先サーバを「ＮＵＬＬ」に戻す要求をサーバ停止制御部１５から受ける。そして、移行先サーバ管理部１４は、サーバ管理情報１０３における呼処理を戻す移行元サーバの運転状態の「通常」へ変更し、さらに移行先サーバを「ＮＵＬＬ」に戻す。その後、移行先サーバ管理部１４は、サーバ管理情報１０３の更新の完了通知をサーバ起動制御部１１へ出力する。

　振分制御部１２は、呼設定の要求を発信側システム３０から受ける。そして、振分制御部１２は、呼制御サーバ２０の中から呼を設定するサーバを選択する。その後、振分制御部１２は、発信側システム３０の情報及び着信側システム４０の情報を選択した呼制御サーバ２０に通知し、選択した呼制御サーバ２０に呼設定を行う。

　振分制御部１２は、新規イベントの振り分け停止の指示をサーバ停止制御部１５から受ける。そして、振分制御部１２は、それ以降に要求された呼設定などのイベントを停止対象サーバに振分けないようにする。

　その後、振分制御部１２は、停止対象サーバが管理していた呼処理の移行先サーバの通知及びサーバ状態管理テーブル１０１の更新の指示をサーバ停止制御部１５から受ける。そして、振分制御部１２は、サーバ状態管理テーブル１０１の停止対象サーバの運転状態を「停止中」に変更する。さらに、振分制御部１２は、移行先サーバアドレスに停止対象サーバの呼処理の移行先サーバのアドレスを書込み、新規イベント受付可否を「不可」にする。

　また、振分制御部１２は、サーバ管理情報１０３における呼処理を戻す移行元サーバの運転状態の「通常」への変更及び移行先サーバを「ＮＵＬＬ」に戻す指示をサーバ起動制御部１１から受ける。そして、振分制御部１２は、サーバ状態管理テーブル１０１において、呼処理を戻す移行元サーバの運転状態を「運転中」に変更し、移行先サーバアドレスを「ＮＵＬＬ」に戻し、新規イベント受付可否を「可」にする。

　次に、呼制御サーバについて説明する。ここでは、呼制御サーバ２１を例に説明するが、呼制御サーバ２０は、いずれも同様の機能を有する。呼制御サーバ２１は、通信制御部２０１、呼処理部２０２及び電源制御部２０３を有する。

　通信制御部２０１は、通信制御装置１、発信側システム３０及び着信側システム４０との間の通信を制御する。

　呼処理部２０２は、通信制御装置１から設定された呼の処理を行う。例えば、呼処理部２０２は、通信制御装置１へ送る呼情報の生成や送信、発信側システム３０や着信側システム４０へ送信する信号の作成及び送信などを行う。呼処理部２０２は、発信側システム３０や着信側システム４０へ送信する信号を生成する場合、Ｖｉａヘッダ、Ｒｅｃｏｒｄ－Ｒｏｕｔｅヘッダは、通信制御装置１の振分制御部１２を経由するように編集する。

　電源制御部２０３は、通信制御装置１のサーバ停止制御部１５からの停止命令を受けて、呼制御サーバ２１の停止処理を開始し、その後、電源をＯＦＦにする。また、電源制御部２０３は、通信制御装置１のサーバ起動制御部１１からの起動命令を受けて、呼制御サーバ２１の電源をＯＮにし、起動処理を開始する。この電源制御部２０３が、「停止制御部」の一例にあたる。

　次に、図６～９を参照して、呼処理の移行処理及び移動した呼処理の戻し処理の概要を再度まとめて説明する。図６は、呼処理の移動が発生する前の各呼制御サーバが管理する呼処理を表す図である。また、図７は、呼処理の移動が発生した後の各呼制御サーバが管理する呼処理を表す図である。また、図８は、呼処理を戻す前の各呼制御サーバが管理する呼処理を表す図である。また、図９は、呼処理を戻した後の各呼制御サーバが管理する呼処理を表す図である。図６～９の縦軸はいずれも呼処理の数に対応する呼制御サーバにかかる負荷量を表しており、横軸は各呼制御サーバ２０を表している。以下の説明では、呼制御サーバ＃１～＃３という３台の呼制御サーバ２０がある場合で説明する。また、ここでは、説明の便宜上、上述したソートなどの呼処理を移行する呼制御サーバ２０の決定などの処理は省き、呼制御サーバ＃２及び＃３の呼処理を呼制御サーバ＃１へ移行する場合で説明する。

　サーバ停止制御部１５は、サーバが停止可能か否かを判定するための閾値として、例えば、図６に示すサーバ停止監視閾値３０２を予め記憶している。最大負荷量３０１は、呼制御サーバ２０にかけることができる負荷量の最大値を表す値である。サーバ停止監視閾値３０２は、最大負荷量３０１より低い値である。そして、図６の状態では、呼制御サーバ＃１は、呼処理Ａを管理しており、呼制御サーバ＃２は、呼処理Ｂを管理しており、呼制御サーバ＃３は、呼処理Ｃを管理している。

　そして、サーバ停止制御部１５は、呼制御サーバ＃２及び＃３が管理する呼処理を呼制御サーバ＃１へ移行した場合に呼制御サーバ＃１の負荷量がサーバ停止監視閾値３０２を超えるか否かを判定する。超えない場合には、呼制御サーバ＃２及び＃３の双方を停止対象サーバであると判定する。ここでは、図６の点線に示すように、呼制御サーバ＃１が管理している呼処理Ａに呼処理Ｂ及び呼処理Ｃを加えてもサーバ停止監視閾値３０２を超えない。そこで、サーバ停止制御部１５は、呼制御サーバ＃２及び＃３が管理する呼処理Ｂ及びＣを呼制御サーバ＃１に移動し、呼制御サーバ＃２及び＃３を停止することを決定する。

　そして、サーバ停止制御部１５は、呼制御サーバ＃２及び＃３が管理していた呼処理Ｂ及び呼処理Ｃを呼制御サーバ＃１へ移行する旨の通知及びサーバ状態管理テーブル１０１の更新の指示を振分制御部１２へ通知する。振分制御部１２は、サーバ停止制御部１５からの通知を受けて、サーバ状態管理テーブル１０１における、呼制御サーバ＃２及び＃３の運転状態を停止中にし、さらに、呼制御サーバ＃２及び＃３が管理していた呼処理Ｂ及び呼処理Ｃの移行先サーバアドレスに呼制御サーバ＃１のアドレスを書き込む。これにより、振分制御部１２は、これ以降の呼処理Ｂ及び呼処理Ｃにおける各処理をサーバ＃１に送信することになる。すなわち、図７に示すように、呼制御サーバ＃２及び＃３が管理していた呼処理Ｂ及び呼処理Ｃが呼制御サーバ＃１へ移行されたことになる。

　次に、図７の状態のときに、例えば、呼制御サーバ＃１に新しい呼が設定され、呼処理Ｄ及び呼処理Ｅが呼制御サーバ＃１により管理されるようになり、図８で表される状態になったとする。この場合、呼制御サーバ＃１の負荷量はサーバ起動監視閾値３０３以上となり、高負荷サーバとなる。そこで、サーバ起動制御部１１は、呼制御サーバ＃１に移行されている呼処理Ｂ及び呼処理Ｃを移行元サーバである呼制御サーバ＃２及び＃３へ戻すことを決定する。

　そして、サーバ起動制御部１１は、呼制御サーバ＃１が管理している呼処理Ｂ及び呼処理Ｃを呼制御サーバ＃２及び＃３へ戻す旨の通知及びサーバ状態管理テーブル１０１の更新の指示を振分制御部１２へ通知する。振分制御部１２は、サーバ起動制御部１１からの通知を受けて、サーバ状態管理テーブル１０１における、呼制御サーバ＃２及び＃３の運転状態を通常に戻し、さらに、呼制御サーバ＃２及び＃３に対応する移行先サーバアドレスを「ＮＵＬＬ」に戻す。これにより、振分制御部１２は、これ以降の呼処理Ｂにおける各処理をサーバ＃２に送信し、呼処理Ｃにおける各処理をサーバ＃３に送信することになる。すなわち、図９に示すように、呼制御サーバ＃２及び＃３に呼処理Ｂ及び呼処理Ｃが戻され、呼制御サーバ＃１の負荷量を減少させることができる。

　次に、図１０を参照して、通信制御装置１を振分サーバ１５１及びＤＢ（Data　Base）サーバ１５２に分けて構成した場合の通信システムについて説明する。図１０は、通信制御装置を２台のサーバで構成した場合の構成例の図である。

　振分サーバ１５１は、サーバ起動制御部１１、振分制御部１２、サーバ停止制御部１５及び通信制御部１９１を有している。また、振分サーバ１５１は、サーバ状態管理テーブル１０１、呼接続情報リスト１０２及びサーバ管理情報１０３を記憶する。振分サーバ１５１は、呼制御サーバ２０に対して呼処理を振分ける機能を有するサーバである。

　ＤＢサーバ１５２は、移行先サーバ管理部１４、呼接続数管理部１６、呼情報アクセス制御部１７、呼番号管理部１８及び通信制御部１９２を有している。また、ＤＢサーバ１５２は、呼情報１０４を記憶する。ＤＢサーバ１５２は、呼情報が登録されたデータベースを管理する機能を有するサーバである。

　そして、図１０において、図１と同じ符号を有する各部は同じ機能を有する。ただし、２台のサーバに分けたため、図１における通信制御部１３は、振分サーバ１５１の通信制御部１９１とＤＢサーバ１５２の通信制御部１９２に分けられている。

　このように、通信制御装置１は、図１０に示すように、２台のサーバに分けることもできるし、それ以上の台数のサーバに機能を分けることともできる。また、各機能の分け方は図１０の例に限らず、どちらのサーバがどの機能を有するかに特に制限はない。

　ここで、図１１を参照して、図１０の通信情報システムを例に、通信確立までの処理の流れについて説明する。図１１は、通信確立までの処理のシーケンス図である。

　発信側システム３０は、通話要求を行い、呼を設定するための呼設定要求であるＩＮＶＩＴＥを振分サーバ１５１へ送信する（ステップＳ１０１）。

　振分サーバ１５１は、ＩＮＶＩＴＥを発信側システム３０から受信する。そして、振分サーバ１５１の振分制御部１２は、呼を設定する呼制御サーバ２０を選択し、選択した呼制御サーバ２０へＩＮＶＩＴＥを送信する（ステップＳ１０２）。

　呼制御サーバ２０の呼処理部２０２は、ＩＮＶＩＴＥを振分サーバ１５１から受信する。そして、呼処理部２０２は、ＤＢサーバ１５２に呼番号取得要求を送信する（ステップＳ１０３）。

　ＤＢサーバ１５２は、呼番号取得要求を呼制御サーバ２０の呼処理部２０２から受信する。そして、ＤＢサーバ１５２の呼番号管理部１８は、呼情報１０４から使用されていない呼番号を取得する（ステップＳ１０４）。呼番号管理部１８は、取得した呼番号を発信側システム３０から設定要求のあった呼に割り当てる。さらに、呼番号管理部１８は、割り当てた呼番号に対応するサーバ管理情報１０３の各欄に情報を登録する（ステップＳ１０５）。さらに、呼番号管理部１８は、割り当てた呼番号を呼制御サーバ２０へ送信する（ステップＳ１０６）。

　呼制御サーバ２０の呼処理部２０２は、発信側システム３０から設定要求のあった呼に割り当てられた呼番号をＤＢサーバ１５２の呼番号管理部１８から受信する。そして、呼処理部２０２は、発信側システム３０からの設定要求を用いて割り当てられた呼番号に対応する呼情報を生成する（ステップＳ１０７）。そして、呼処理部２０２は、生成した呼情報をＤＢサーバ１５２へ送信する（ステップＳ１０８）。

　ＤＢサーバ１５２の呼情報アクセス制御部１７は、呼情報を呼制御サーバ２０の呼処理部２０２から受信する。そして、呼情報アクセス制御部１７は、受信した呼情報を呼情報１０４に登録する（ステップＳ１０９）。

　呼制御サーバ２０の呼処理部２０２は、ＩＮＶＩＴＥを着信側システム４０へ伝えるための信号を作成する（ステップＳ１１０）。この時、呼処理部２０２は、作成した信号のＶｉａヘッダ及びＲｅｃｏｒｄ－Ｒｏｕｔｅヘッダを、振分サーバ１５１を経由するように編集する。そして、呼処理部２０２は、作成した信号を用いてＩＮＶＩＴＥを着信側システム４０へ送信する（ステップＳ１１１）。

　着信側システム４０は、ＩＮＶＩＴＥを受信すると、受信した信号の各ヘッダを確認し、受信信号の応答先を特定する。そして、着信側システム４０は、ＩＮＶＩＴＥを受信したことを示す応答である１００　Ｔｒｙｉｎｇを振分サーバ１５１へ送信する（ステップＳ１１２）。

　振分サーバ１５１の振分制御部１２は、１００　Ｔｒｙｉｎｇを着信側システム４０から受信する。そして、振分制御部１２は、呼制御サーバ２０に１００Ｔｒｙｉｎｇを送信する（ステップＳ１１３）。

　呼制御サーバ２０の呼処理部２０２は、振分サーバ１５１の振分制御部１２から１００　Ｔｒｙｉｎｇを受信する。そして、呼処理部２０２は、呼情報読出要求をＤＢサーバ１５２へ送信する（ステップＳ１１４）。

　ＤＢサーバ１５２の呼情報アクセス制御部１７は、呼情報読出要求を呼制御サーバ２０の呼処理部２０２から受信する。そして、呼情報アクセス制御部１７は、呼情報１０４から呼情報読出要求に対応する呼の呼情報を呼情報１０４から読み出す（ステップＳ１１５）。そして、呼情報アクセス制御部１７は、読み出した呼情報を呼制御サーバ２０へ送信する（ステップＳ１１６）。

　呼制御サーバ２０の呼処理部２０２は、ＤＢサーバ１５２の呼情報アクセス制御部１７から呼情報を受信する。そして、呼処理部２０２は、１００　Ｔｒｙｉｎｇを取得した状態に呼情報に含まれる呼の状態の情報を遷移させる（ステップＳ１１７）。そして、呼処理部２０２は、変更した呼情報とともに呼情報書込要求をＤＢサーバ１５２へ送信する（ステップＳ１１８）。

　ＤＢサーバ１５２の呼情報アクセス制御部１７は、呼状態が変更された呼情報とともに呼制御サーバ２０の呼処理部２０２から呼情報書込要求を受ける。そして、呼情報アクセス制御部１７は、１００　Ｔｒｙｉｎｇを受信した状態に呼状態が変更された呼情報を呼情報１０４に書込み更新する（ステップＳ１１９）。

　呼制御サーバ２０の呼処理部２０２は、１００　Ｔｒｙｉｎｇを発信側システム３０へ伝えるための信号を作成する（ステップＳ１２０）。そして、呼処理部２０２は、作成した信号を用いて１００　Ｔｒｙｉｎｇを発信側システム３０へ送信する（ステップＳ１２１）。

　着信側システム４０は、着信側装置がＩＮＶＩＴＥを受け取り、ベルを鳴らすなどして呼び出しを行っていることを示す応答である１８０　Ｒｉｎｇｉｎｇを振分サーバ１５１へ送信する（ステップＳ１２２）。

　振分サーバ１５１の振分制御部１２は、１８０　Ｒｉｎｇｉｎｇを着信側システム４０から受信する。そして、振分制御部１２は、呼制御サーバ２０に１８０　Ｒｉｎｇｉｎｇを送信する（ステップＳ１２３）。

　呼制御サーバ２０の呼処理部２０２は、振分サーバ１５１の振分制御部１２から１８０　Ｒｉｎｇｉｎｇを受信する。そして、呼処理部２０２は、呼情報読出要求をＤＢサーバ１５２へ送信する（ステップＳ１２４）。

　ＤＢサーバ１５２の呼情報アクセス制御部１７は、呼情報読出要求を呼制御サーバ２０の呼処理部２０２から受信する。そして、呼情報アクセス制御部１７は、呼情報１０４から呼情報読出要求に対応する呼の呼情報を呼情報１０４から読み出す（ステップＳ１２５）。そして、呼情報アクセス制御部１７は、読み出した呼情報を呼制御サーバ２０へ送信する（ステップＳ１２６）。

　呼制御サーバ２０の呼処理部２０２は、ＤＢサーバ１５２の呼情報アクセス制御部１７から呼情報を受信する。そして、呼処理部２０２は、呼び出し中の状態に呼情報に含まれる呼の状態の情報を遷移させる（ステップＳ１２７）。そして、呼処理部２０２は、変更した呼情報とともに呼情報書込要求をＤＢサーバ１５２へ送信する（ステップＳ１２８）。

　ＤＢサーバ１５２の呼情報アクセス制御部１７は、呼状態が変更された呼情報とともに呼制御サーバ２０の呼処理部２０２から呼情報書込要求を受ける。そして、呼情報アクセス制御部１７は、呼び出し中の状態に呼状態が変更された呼情報を呼情報１０４に書込み更新する（ステップＳ１２９）。

　呼制御サーバ２０の呼処理部２０２は、１８０　Ｒｉｎｇｉｎｇを発信側システム３０へ伝えるための信号を作成する（ステップＳ１３０）。そして、呼処理部２０２は、作成した信号を用いて１８０　Ｒｉｎｇｉｎｇを発信側システム３０へ送信する（ステップＳ１３１）。

　その後、着信側装置において呼び出し応答があった場合、着信側システム４０は、ＩＮＶＩＴＥのリクエストが正常に処理された、すなわち、呼び出し成功を示す２００　ＯＫを振分サーバ１５１へ送信する（ステップＳ１３２）。

　振分サーバ１５１の振分制御部１２は、２００　ＯＫを着信側システム４０から受信する。そして、振分制御部１２は、呼制御サーバ２０に２００　ＯＫを送信する（ステップＳ１３３）。

　呼制御サーバ２０の呼処理部２０２は、振分サーバ１５１の振分制御部１２から２００　ＯＫを受信する。そして、呼処理部２０２は、呼情報読出要求をＤＢサーバ１５２へ送信する（ステップＳ１３４）。

　ＤＢサーバ１５２の呼情報アクセス制御部１７は、呼情報読出要求を呼制御サーバ２０の呼処理部２０２から受信する。そして、呼情報アクセス制御部１７は、呼情報１０４から呼情報読出要求に対応する呼の呼情報を呼情報１０４から読み出す（ステップＳ１３５）。そして、呼情報アクセス制御部１７は、読み出した呼情報を呼制御サーバ２０へ送信する（ステップＳ１３６）。

　呼制御サーバ２０の呼処理部２０２は、ＤＢサーバ１５２の呼情報アクセス制御部１７から呼情報を受信する。そして、呼処理部２０２は、呼情報に含まれる呼の状態の情報を呼び出し成功を表す状態に遷移させる（ステップＳ１３７）。そして、呼処理部２０２は、変更した呼情報とともに呼情報書込要求をＤＢサーバ１５２へ送信する（ステップＳ１３８）。

　ＤＢサーバ１５２の呼情報アクセス制御部１７は、呼状態が変更された呼情報とともに呼制御サーバ２０の呼処理部２０２から呼情報書込要求を受ける。そして、呼情報アクセス制御部１７は、呼び出し成功を表す状態に呼状態が変更された呼情報を呼情報１０４に書込み更新する（ステップＳ１３９）。

　呼制御サーバ２０の呼処理部２０２は、２００　ＯＫを発信側システム３０へ伝えるための信号を作成する（ステップＳ１４０）。そして、呼処理部２０２は、作成した信号を用いて２００　ＯＫを発信側システム３０へ送信する（ステップＳ１４１）。

　発信側システム３０は、２００　ＯＫを呼制御サーバ２０の呼処理部２０２から受信する。そして、２００　ＯＫのレスポンスを受け取ったことを示す確認応答であるＡＣＴを呼制御サーバ２０へ送信する（ステップＳ１４２）。

　呼制御サーバ２０の呼処理部２０２は、発信側システム３０から２００　ＯＫを受信する。そして、呼処理部２０２は、呼情報読出要求をＤＢサーバ１５２へ送信する（ステップＳ１４３）。

　ＤＢサーバ１５２の呼情報アクセス制御部１７は、呼情報読出要求を呼制御サーバ２０の呼処理部２０２から受信する。そして、呼情報アクセス制御部１７は、呼情報１０４から呼情報読出要求に対応する呼の呼情報を呼情報１０４から読み出す（ステップＳ１４４）。そして、呼情報アクセス制御部１７は、読み出した呼情報を呼制御サーバ２０へ送信する（ステップＳ１４５）。

　呼制御サーバ２０の呼処理部２０２は、ＤＢサーバ１５２の呼情報アクセス制御部１７から呼情報を受信する。そして、呼処理部２０２は、呼情報に含まれる呼の状態の情報を通話中を表す状態に遷移させる（ステップＳ１４６）。そして、呼処理部２０２は、変更した呼情報とともに呼情報書込要求をＤＢサーバ１５２へ送信する（ステップＳ１４７）。

　ＤＢサーバ１５２の呼情報アクセス制御部１７は、呼状態が変更された呼情報とともに呼制御サーバ２０の呼処理部２０２から呼情報書込要求を受ける。そして、呼情報アクセス制御部１７は、通話中を表す状態に呼状態が変更された呼情報を呼情報１０４に書込み更新する（ステップＳ１４８）。

　呼制御サーバ２０の呼処理部２０２は、ＡＣＴを着信側システム４０へ伝えるための信号を作成する（ステップＳ１４９）。そして、呼処理部２０２は、作成した信号を用いてＡＣＴを着信側システム４０へ送信する（ステップＳ１５０）。これにより、通信が確立し、発信側システム３０における発信側装置と着信側システム４０における着信側装置との間で通話が行われる（ステップＳ１５１）。

　次に、図１２を参照して、図１０の通信情報システムを例に、呼処理の移行の処理の流れについて説明する。図１２は、呼処理の移行の処理のシーケンス図である。ここでは、呼制御サーバ＃２が管理している呼処理を呼制御サーバ＃３へ移行する場合で説明する。

　振分サーバ１５１のサーバ停止制御部１５は、呼処理の移行を行う周期処理を開始する（ステップＳ２０１）。サーバ停止制御部１５は、呼接続情報取得要求をＤＢサーバ１５２へ送信する（ステップＳ２０２）。この時、サーバ停止制御部１５は、サーバ管理情報１０３をＤＢサーバ１５２へ送信する。

　ＤＢサーバ１５２の呼接続数管理部１６は、振分サーバ１５１のサーバ停止制御部１５から呼接続情報取得要求を受信する。そして、呼接続数管理部１６は、サーバ管理情報１０３から呼接続情報リスト１０２を作成する（ステップＳ２０３）。そして、呼接続数管理部１６は、作成した呼接続情報リスト１０２を振分サーバ１５１へ送信する（ステップＳ２０４）。

　振分サーバ１５１のサーバ停止制御部１５は、ＤＢサーバ１５２の呼接続数管理部１６から呼接続情報リスト１０２を受信する。そして、サーバ停止制御部１５は、呼接続数の昇順に呼制御サーバ２０のソートなどを行い、サーバ移行先の計算を行う（ステップＳ２０５）。サーバ停止制御部１５は、サーバ移行先の計算結果により停止対象サーバが有るか否かを判定する（ステップＳ２０６）。停止対象サーバが無い場合（ステップＳ２０６：否定）、サーバ停止制御部１５は、呼処理の移行の処理を終了する（ステップＳ２０７）。

　これに対して、停止対象サーバが有る場合（ステップＳ２０６：肯定）、サーバ停止制御部１５は、呼制御サーバ＃２への新規イベントの振分け停止を振分制御部１２に通知する。振分制御部１２は、呼制御サーバ＃２への新規イベントの振分けを停止する（ステップＳ２０８）。

　サーバ停止制御部１５は、停止対象サーバの中から１つを選択する（ステップＳ２０９）。そして、サーバ停止制御部１５は、サーバ管理情報１０３における選択した停止対象サーバの情報の更新要求をＤＢサーバ１５２へ送信する（ステップＳ２１０）。この時、サーバ停止制御部１５は、選択した停止対象サーバの情報及びその停止対象サーバが管理する呼処理を移行する移行先サーバの情報をＤＢサーバ１５２へ送信する。

　ＤＢサーバ１５２の移行先サーバ管理部１４は、振分サーバ１５１のサーバ停止制御部１５からサーバ管理情報１０３の更新要求を受信する。そして、移行先サーバ管理部１４は、指定された停止対象サーバの運転状態及び移行先サーバ番号を更新する（ステップＳ２１１）。次に、移行先サーバ管理部１４は、サーバ管理情報１０３の更新の完了通知を振分サーバ１５１へ通知する（ステップＳ２１２）。

　振分サーバ１５１のサーバ停止制御部１５は、ＤＢサーバ１５２の移行先サーバ管理部１４からサーバ管理情報１０３の更新の完了通知を受信する。そして、サーバ停止制御部１５は、選択した停止可能サーバの情報及びその停止可能サーバが管理していた呼処理の移行先サーバの情報とともに、サーバ状態管理テーブル１０１の更新の指示を振分制御部１２へ送信する。振分制御部１２は、サーバ状態管理テーブル１０１における指定された停止対象サーバの運転状態及び移行先サーバアドレスを更新する（ステップＳ２１３）。

　サーバ停止制御部１５は、停止対象サーバである呼制御サーバ＃２（ここでは呼制御サーバ＃２を例に説明する。）に対して電源ＯＦＦ要求を送信する（ステップＳ２１４）。

　呼制御サーバ＃２の電源制御部２０３は、振分サーバ１５１のサーバ停止制御部１５から電源ＯＦＦ要求を受信する。そして、電源制御部２０３は、サーバ停止処理を行う（ステップＳ２１５）。サーバ停止処理完了後、電源制御部２０３は、呼制御サーバ＃２の電源をＯＦＦする（ステップＳ２１６）。

　サーバ停止制御部１５は、停止対象サーバ全ての電源ＯＦＦが終わったか否かを判定する（ステップＳ２１７）。電源ＯＦＦをしていない停止対象サーバがある場合（ステップＳ２１７：否定）、サーバ停止制御部１５は、ステップＳ２０９へ戻る。

　これに対して、停止対象サーバ全ての電源ＯＦＦが終わっている場合（ステップＳ２１７：肯定）、サーバ停止制御部１５は、周期処理を終了する（ステップＳ２１８）。

　次に、図１３を参照して、図１０の通信情報システムを例に、移行後の呼処理の流れについて説明する。図１３は、移行後の呼処理のシーケンス図である。ここでは、呼制御サーバ＃２が管理している呼処理が呼制御サーバ＃３へ移行されている場合で説明する。

　発信側システム３０が、呼制御サーバ＃２が生成した呼に対する通話終了要求であるＢＹＥを振分サーバ１５１へ送信する（ステップＳ３０１）。

　振分サーバ１５１の振分制御部１２は、発信側システム３０からＢＹＥを受信する。振分制御部１２は、サーバ状態管理テーブル１０１を参照する（ステップＳ３０２）。振分制御部１２は、通話終了要求があった呼の呼番号が割り当てられた呼処理を管理している呼制御サーバ２０をサーバ状態管理テーブル１０１から取得する。ここでは、呼制御サーバ＃２が生成した呼の呼処理を呼制御サーバ＃３が管理しているので、振分制御部１２は、ＢＹＥの振分先として呼処理サーバ＃３を取得する。そして、振分制御部１２は、ＢＹＥを呼処理サーバ＃３へ振分ける（ステップＳ３０３）。振分制御部１２は、ＢＹＥを呼制御サーバ＃３へ送信する（ステップＳ３０４）。

　呼制御サーバ＃３の呼処理部２０２は、振分サーバ１５１の振分制御部１２からＢＹＥを受信する。そして、呼処理部２０２は、呼情報読出要求をＤＢサーバ１５２へ送信する（ステップＳ３０５）。

　ＤＢサーバ１５２の呼情報アクセス制御部１７は、呼情報読出要求を呼制御サーバ＃３の呼処理部２０２から受信する。そして、呼情報アクセス制御部１７は、呼情報１０４から呼情報読出要求に対応する呼の呼情報を呼情報１０４から読み出す（ステップＳ３０６）。そして、呼情報アクセス制御部１７は、読み出した呼情報を呼制御サーバ＃３へ送信する（ステップＳ３０７）。

　呼制御サーバ＃３の呼処理部２０２は、ＤＢサーバ１５２の呼情報アクセス制御部１７から呼情報を受信する。そして、呼処理部２０２は、呼情報に含まれる呼の状態の情報を通話終了の状態に遷移させる（ステップＳ３０８）。そして、呼処理部２０２は、変更した呼情報とともに呼情報書込要求をＤＢサーバ１５２へ送信する（ステップＳ３０９）。

　ＤＢサーバ１５２の呼情報アクセス制御部１７は、呼状態が変更された呼情報とともに呼制御サーバ２０の呼処理部２０２から呼情報書込要求を受ける。そして、呼情報アクセス制御部１７は、通話終了の状態に呼状態が変更された呼情報を呼情報１０４に書込み更新する（ステップＳ３１０）。

　呼制御サーバ＃３の呼処理部２０２は、ＢＹＥを着信側システム４０へ伝えるための信号を作成する（ステップＳ３１１）。そして、呼処理部２０２は、作成した信号を用いてＢＹＥを着信側システム４０へ送信する（ステップＳ３１２）。

　着信側システム４０は、呼制御サーバ＃３の呼処理部２０２からＢＹＥを受信する。そして、着信側システム４０は、切断成功を表す信号である２００　ＯＫを振分サーバ１５１へ送信する（ステップＳ３１３）。

　振分サーバ１５１の振分制御部１２は、２００　ＯＫを着信側システム４０から受信する。振分制御部１２は、サーバ状態管理テーブル１０１を参照する（ステップＳ３１４）。そして、振分制御部１２は、通話が終了した呼の呼番号が割り当てられた呼処理を管理している呼制御サーバ２０をサーバ状態管理テーブル１０１から取得する。ここでは、呼制御サーバ＃２が生成した呼の呼処理を呼制御サーバ＃３が管理しているので、振分制御部１２は、２００　ＯＫの振分先として呼処理サーバ＃３を取得する。そして、振分制御部１２は、２００　ＯＫを呼処理サーバ＃３へ振分ける（ステップＳ３１５）。次に、振分制御部１２は、呼制御サーバ＃３に２００　ＯＫを送信する（ステップＳ３１６）。

　呼制御サーバ＃３の呼処理部２０２は、振分サーバ１５１の振分制御部１２から２００　ＯＫを受信する。そして、呼処理部２０２は、呼情報読出要求をＤＢサーバ１５２へ送信する（ステップＳ３１７）。

　ＤＢサーバ１５２の呼情報アクセス制御部１７は、呼情報読出要求を呼制御サーバ＃３の呼処理部２０２から受信する。そして、呼情報アクセス制御部１７は、呼情報１０４から呼情報読出要求に対応する呼の呼情報を呼情報１０４から読み出す（ステップＳ３１８）。そして、呼情報アクセス制御部１７は、読み出した呼情報を呼制御サーバ２０へ送信する（ステップＳ３１９）。

　呼制御サーバ＃３の呼処理部２０２は、ＤＢサーバ１５２の呼情報アクセス制御部１７から呼情報を受信する。そして、呼処理部２０２は、呼情報に含まれる呼の状態の情報を通話終了の状態に遷移させる（ステップＳ３２０）。そして、呼処理部２０２は、変更した呼情報とともに呼情報書込要求をＤＢサーバ１５２へ送信する（ステップＳ３２１）。

　ＤＢサーバ１５２の呼情報アクセス制御部１７は、呼状態が変更された呼情報とともに呼制御サーバ２０の呼処理部２０２から呼情報書込要求を受ける。そして、アクセス制御部１７は、通話終了の状態に呼状態が変更された呼情報を呼情報１０４に書込み更新する（ステップＳ３２２）。

　呼制御サーバ＃３の呼処理部２０２は、２００　ＯＫを発信側システム３０へ伝えるための信号を作成する（ステップＳ３２３）。そして、呼処理部２０２は、作成した信号を用いて２００　ＯＫを発信側システム３０へ送信し、切断成功を通知する（ステップＳ３２４）。

　次に、図１４を参照して、図１０の通信情報システムを例に、呼処理の戻し処理の流れについて説明する。図１４は、呼処理の戻し処理のシーケンス図である。ここでは、呼制御サーバ＃３に移行された呼処理を呼制御サーバ＃２へ戻す場合で説明する。

　振分サーバ１５１のサーバ起動制御部１１は、呼処理の移行を行う周期処理を開始する（ステップＳ４０１）。サーバ起動制御部１１は、呼接続情報取得要求をＤＢサーバ１５２へ送信する（ステップＳ４０２）。この時、サーバ起動制御部１１は、サーバ管理情報１０３をＤＢサーバ１５２へ送信する。

　ＤＢサーバ１５２の呼接続数管理部１６は、振分サーバ１５１のサーバ起動制御部１１から呼接続情報取得要求を受信する。そして、呼接続数管理部１６は、サーバ管理情報１０３から呼接続情報リスト１０２を作成する（ステップＳ４０３）。そして、呼接続数管理部１６は、作成した呼接続情報リスト１０２を振分サーバ１５１へ送信する（ステップＳ４０４）。

　振分サーバ１５１のサーバ起動制御部１１は、ＤＢサーバ１５２の呼接続数管理部１６から呼接続情報リスト１０２を受信する。そして、サーバ起動制御部１１は、停止している呼制御サーバ２０がある場合、稼動している呼制御サーバ２０の負荷量を計算する（ステップＳ４０５）。サーバ起動制御部１１は、負荷量の計算結果により高負荷サーバが有るか否かを判定する（ステップＳ４０６）。高負荷サーバが無い場合（ステップＳ４０６：否定）、サーバ起動制御部１１は、呼処理の戻し処理を終了する（ステップＳ４０７）。

　これに対して、高負荷サーバが有る場合（ステップＳ４０６：肯定）、サーバ起動制御部１１は、高負荷サーバの中から一つを選択する（ステップＳ４０８）。そして、サーバ起動制御部１１は、サーバ管理情報１０３における選択した高負荷サーバ及びその高負荷サーバが管理している呼処理を戻す移行元サーバの情報の更新要求をＤＢサーバ１５２へ送信する（ステップＳ４０９）。この時、サーバ起動制御部１１は、高負荷サーバが管理している呼処理を戻す移行元サーバの情報をＤＢサーバ１５２へ送信する。

　ＤＢサーバ１５２の移行先サーバ管理部１４は、振分サーバ１５１のサーバ起動制御部１１からサーバ管理情報１０３の更新要求を受信する。そして、移行先サーバ管理部１４は、指定された呼処理を戻す移行元サーバの運転状態を通常に戻し、さらに移行先サーバ番号を「ＮＵＬＬ」に変更してサーバ管理情報１０３を更新する（ステップＳ４１０）。次に、移行先サーバ管理部１４は、サーバ管理情報１０３の更新の完了通知を振分サーバ１５１へ通知する（ステップＳ４１１）。

　振分サーバ１５１のサーバ起動制御部１１は、ＤＢサーバ１５２の移行先サーバ管理部１４からサーバ管理情報１０３の更新の完了通知を受信する。そして、サーバ起動制御部１１は、呼処理を戻す呼制御サーバ＃２（ここでは呼制御サーバ＃２を例に説明する。）に対して電源ＯＮ要求を送信する（ステップＳ４１２）。

　呼制御サーバ＃２の電源制御部２０３は、振分サーバ１５１のサーバ起動制御部１１から電源ＯＮ要求を受信する。そして、電源制御部２０３は、サーバの電源をＯＮする（ステップＳ４１３）。次に、電源制御部２０３は、サーバ起動処理を行う（ステップＳ４１４）。

　振分サーバ１５１のサーバ起動制御部１１は、選択した高負荷サーバの情報及びその高負荷サーバが管理する呼処理を戻す移行元サーバの情報とともに、サーバ状態管理テーブル１０１の更新の指示を振分制御部１２へ送信する。振分制御部１２は、サーバ状態管理テーブル１０１における指定された高負荷サーバが管理する呼処理を戻す移行元サーバの運転状態を通常に戻し、移行先サーバアドレスを「ＮＵＬＬ」にもどして更新する（ステップＳ４１５）。

　振分サーバ１５１のサーバ起動制御部１１は、停止対象サーバ全ての電源ＯＮが終わったか否かを判定する（ステップＳ４１６）。電源ＯＦＦをしていない停止対象サーバがある場合（ステップＳ４１６：否定）サーバ停止制御部１５は、ステップＳ４０８へ戻る。

　これに対して、停止対象サーバ全ての電源ＯＮが終わっている場合（ステップＳ４１６：肯定）、サーバ起動制御部１１は、周期処理を終了する（ステップＳ４１７）。

　次に、図１５を参照して、図１０の通信情報システムを例に、戻した後の呼処理の流れについて説明する。図１５は、戻した後の呼処理のシーケンス図である。ここでは、呼制御サーバ＃３が管理していた呼処理が呼制御サーバ＃２へ戻された場合で説明する。

　発信側システム３０が、呼制御サーバ＃２が生成した呼に対する通話終了要求であるＢＹＥを振分サーバ１５１へ送信する（ステップＳ５０１）。

　振分サーバ１５１の振分制御部１２は、発信側システム３０からＢＹＥを受信する。振分制御部１２は、サーバ状態管理テーブル１０１を参照する（ステップＳ５０２）。振分制御部１２は、通話終了要求があった呼の呼番号が割り当てられた呼処理を管理している呼制御サーバ２０をサーバ状態管理テーブル１０１から取得する。ここでは、呼制御サーバ＃３が管理していた呼処理が呼制御サーバ＃２に戻されているので、振分制御部１２は、ＢＹＥの振分先として呼処理サーバ＃２を取得する。そして、振分制御部１２は、ＢＹＥを呼処理サーバ＃２へ振分ける（ステップＳ５０３）。振分制御部１２は、ＢＹＥを呼制御サーバ＃２へ送信する（ステップＳ５０４）。

　呼制御サーバ＃２の呼処理部２０２は、振分サーバ１５１の振分制御部１２からＢＹＥを受信する。そして、呼処理部２０２は、呼情報読出要求をＤＢサーバ１５２へ送信する（ステップＳ５０５）。

　ＤＢサーバ１５２の呼情報アクセス制御部１７は、呼情報読出要求を呼制御サーバ＃２の呼処理部２０２から受信する。そして、呼情報アクセス制御部１７は、呼情報１０４から呼情報読出要求に対応する呼の呼情報を呼情報１０４から読み出す（ステップＳ５０６）。そして、呼情報アクセス制御部１７は、読み出した呼情報を呼制御サーバ＃２へ送信する（ステップＳ５０７）。

　呼制御サーバ＃２の呼処理部２０２は、ＤＢサーバ１５２の呼情報アクセス制御部１７から呼情報を受信する。そして、呼処理部２０２は、呼情報に含まれる呼の状態の情報を通話終了の状態に遷移させる（ステップＳ５０８）。そして、呼処理部２０２は、変更した呼情報とともに呼情報書込要求をＤＢサーバ１５２へ送信する（ステップＳ５０９）。

　ＤＢサーバ１５２の呼情報アクセス制御部１７は、呼状態が変更された呼情報とともに呼制御サーバ２０の呼処理部２０２から呼情報書込要求を受ける。そして、呼情報アクセス制御部１７は、通話終了の状態に呼状態が変更された呼情報を呼情報１０４に書込み更新する（ステップＳ５１０）。

　呼制御サーバ＃２の呼処理部２０２は、ＢＹＥを着信側システム４０へ伝えるための信号を作成する（ステップＳ５１１）。そして、呼処理部２０２は、作成した信号を用いてＢＹＥを着信側システム４０へ送信する（ステップＳ５１２）。

　着信側システム４０は、呼制御サーバ＃２の呼処理部２０２からＢＹＥを受信する。そして、着信側システム４０は、切断成功を表す信号である２００　ＯＫを振分サーバ１５１へ送信する（ステップＳ５１３）。

　振分サーバ１５１の振分制御部１２は、２００　ＯＫを着信側システム４０から受信する。振分制御部１２は、サーバ状態管理テーブル１０１を参照する（ステップＳ５１４）。そして、振分制御部１２は、通話が終了した呼の呼番号が割り当てられた呼処理を管理している呼制御サーバ２０をサーバ状態管理テーブル１０１から取得する。ここでは、呼制御サーバ＃３が管理していた呼処理が呼制御サーバ＃２に戻されているので、振分制御部１２は、２００　ＯＫの振分先として呼処理サーバ＃２を取得する。そして、振分制御部１２は、２００　ＯＫを呼処理サーバ＃２へ振分ける（ステップＳ５１５）。次に、振分制御部１２は、呼制御サーバ＃２に２００　ＯＫを送信する（ステップＳ５１６）。

　呼制御サーバ＃２の呼処理部２０２は、振分サーバ１５１の振分制御部１２から２００　ＯＫを受信する。そして、呼処理部２０２は、呼情報読出要求をＤＢサーバ１５２へ送信する（ステップＳ５１７）。

　ＤＢサーバ１５２の呼情報アクセス制御部１７は、呼情報読出要求を呼制御サーバ＃２の呼処理部２０２から受信する。そして、呼情報アクセス制御部１７は、呼情報１０４から呼情報読出要求に対応する呼の呼情報を呼情報１０４から読み出す（ステップＳ５１８）。そして、呼情報アクセス制御部１７は、読み出した呼情報を呼制御サーバ＃２へ送信する（ステップＳ５１９）。

　呼制御サーバ＃２の呼処理部２０２は、ＤＢサーバ１５２の呼情報アクセス制御部１７から呼情報を受信する。そして、呼処理部２０２は、呼情報に含まれる呼の状態の情報を通話終了の状態に遷移させる（ステップＳ５２０）。そして、呼処理部２０２は、変更した呼情報とともに呼情報書込要求をＤＢサーバ１５２へ送信する（ステップＳ５２１）。

　ＤＢサーバ１５２の呼情報アクセス制御部１７は、呼状態が変更された呼情報とともに呼制御サーバ２０の呼処理部２０２から呼情報書込要求を受ける。そして、呼情報アクセス制御部１７は、通話終了の状態に呼状態が変更された呼情報を呼情報１０４に書込み更新する（ステップＳ５２２）。

　呼制御サーバ２０の呼処理部２０２は、２００　ＯＫを発信側システム３０へ伝えるための信号を生成する（ステップＳ５２３）。そして、呼処理部２０２は、生成した信号を用いて２００　ＯＫを発信側システム３０へ送信し、切断成功を通知する（ステップＳ５２４）。

　次に、図１６～１９を参照して、停止対象サーバ及び移行先サーバの決定処理の流れ、並びに、その処理における各種情報の変化について説明する。図１６は、停止対象サーバ及び移行先サーバの決定処理のフローチャートである。また、図１７は、移行前の呼接続情報リストの状態の一例を示す図である。また、図１８は、呼接続数昇順ソート結果の一例を示す図である。また、図１９は、停止対象サーバ及び移行先サーバの決定処理が行われたときの計算結果の一例を示す図である。この場合、呼処理の移行がいずれの呼制御サーバ２０においても未だ行われていない場合で説明する。ここでは、サーバ番号１～５の呼制御サーバ２０がある場合を例に説明する。以下では、サーバ番号１～５の呼制御サーバ２０を、それぞれ呼制御サーバ＃１～５と表す。

　サーバ停止制御部１５は、停止対象サーバの決定処理を開始すると、呼接続情報リスト１０２の取得要求を呼接続数管理部１６へ通知し、呼接続情報リスト１０２を呼接続数管理部１６から取得する（ステップＳ６０１）。この場合、未だ呼処理の移行が行われていないため、サーバ停止制御部１５は、図１７のテーブル４０１で示されるような呼接続情報リスト１０２を取得する。テーブル４０１では、移行処理呼数がどの呼制御サーバ２０においても０であり、且つ移行元サーバの全て「ＮＵＬＬ」となっている。

　次に、サーバ停止制御部１５は、取得した呼接続情報リスト１０２から各呼制御サーバ２０の通常処理呼数と移行処理呼数とを抽出し、呼制御サーバ２０毎に通常処理呼数と移行処理呼数とを加算し呼接続数を算出する（ステップＳ６０２）。

　次に、サーバ停止制御部１５は、各呼制御サーバ２０を呼接続数の昇順にソートする（ステップＳ６０３）。この場合、未だいずれの呼制御サーバ２０も移行されてきた呼処理を有していないので、図１７のテーブル４０１の通常処理個数が各呼制御サーバ２０の呼接続数となる。そこで、この場合の各呼制御サーバ２０を呼接続数でソートすると、図１８のテーブル４０２で示される呼接続数昇順ソート結果が得られる。この場合、サーバ番号２、５、４、３、１の順にソートされている。

　次に、サーバ停止制御部１５は、停止対象サーバとなるか否かのチェックが未チェックの呼制御サーバ２０のうちソート順位が最上位のサーバを選択する（ステップＳ６０４）。ここでは、サーバ停止制御部１５は、まず呼制御サーバ＃２を選択し、呼制御サーバ＃２のチェックが終わると次に呼制御サーバ＃５を選択してチェックを行うという処理を呼制御サーバ＃１まで繰り返す。

　そして、サーバ停止制御部１５は、選択した呼制御サーバ２０の呼処理を移行した場合の負荷量がサーバ停止監視閾値を下回り、呼処理を移行することが可能なサーバが、選択している呼制御サーバ２０より下の順位に有るか否かを判定する（ステップＳ６０５）。

　そして、サーバ停止制御部１５は、選択した呼制御サーバ２０の呼処理を移行することが可能なサーバの中で、ソート順が最も低い呼制御サーバ２０を移行先サーバとして選択する（ステップＳ６０６）。

　そして、サーバ停止制御部１５は、停止対象サーバが管理する呼処理を０とし、さらに、移行先サーバへ停止対象サーバが管理する呼処理を移行した場合の結果を図１９に示すような計算結果として記憶して更新する（ステップＳ６０７）。

　そして、サーバ停止制御部１５は、全ての呼制御サーバ２０のチェックが完了したか否かを判定する（ステップＳ６０８）。チェックを終えていない呼制御サーバ２０がある場合（ステップＳ６０８：否定）、サーバ停止制御部１５は、ステップＳ６０４へ戻る。これに対して、チェックが全て終わっている場合（ステップＳ６０８：肯定）、サーバ停止制御部１５は、計算結果を確定する（ステップＳ６０９）。

　例えば、図１８のようにソートした場合で説明する。ここでは、サーバ停止監視閾値は呼接続数が５００の場合の負荷量とする。まず、サーバ停止制御部１５は、呼制御サーバ＃２をチェック対象として選択する。呼制御サーバ＃２の呼接続数は２００であり、この呼処理を移行しても呼接続数が５００を超えない呼制御サーバ２０は、呼接続サーバ＃５、＃４又は＃３である。そこで、サーバ停止制御部１５は、呼制御サーバ＃２の呼処理を移行することが可能なサーバがあると判定する。そして、サーバ停止制御部１５は移行可能なサーバの中から、ソート順が最も低い呼制御サーバ＃３を呼制御サーバ＃２が管理する呼処理の移行先サーバとして選択する。次に、サーバ停止制御部１５は、呼制御サーバ＃２が管理する呼処理を０とし、呼制御サーバ＃２が管理する呼処理を呼制御サーバ＃３へ移行する内容で計算結果を更新する。具体的には、サーバ停止制御部１５は、図１９のテーブル４０１に示す、呼制御サーバ＃２の通常処理呼数を表す欄４３１を０とする。さらに、呼制御サーバ＃２の移行先サーバ番号の欄４３２にサーバ番号３を登録する。また、サーバ停止制御部１５は、呼制御サーバ＃３の移行処理呼数を表す欄４３３に呼制御サーバ＃２が管理していた呼処理の数である２００を登録する。さらに、サーバ停止制御部１５は、呼制御サーバ＃３へ移行した呼処理の移行元サーバを表す欄４３４にサーバ番号２を登録する。

　さらに、呼制御サーバ＃２の呼処理を呼制御サーバ＃３へ移行するとした後に、図１８のテーブル４０２における次順位のサーバである呼制御サーバ＃５をチェックする場合を説明する。この場合、呼制御サーバ＃５の通常処理呼数は２１０である。そして、呼制御サーバ＃３には既に呼制御サーバ＃２の管理していた呼処理の移行が決定されているので、呼制御サーバ＃３の呼接続数は４３０となっている。そのため、呼制御サーバ＃５の呼処理を移行しても呼接続数が５００を超えない呼制御サーバ２０は、呼接続サーバ＃４である。そこで、サーバ停止制御部１５は、呼制御サーバ＃５の呼処理を移行することが可能なサーバがあり、それは呼接続サーバ＃４であると判定する。次に、サーバ停止制御部１５は、呼制御サーバ＃５が管理する呼処理を０とし、呼制御サーバ＃５が管理する呼処理を呼制御サーバ＃４へ移行する内容で計算結果を更新する。具体的には、サーバ停止制御部１５は、図１７のテーブル４０１に示す、呼制御サーバ＃５の通常処理呼数を表す欄４３５を０とする。さらに、呼制御サーバ＃５の移行先サーバ番号の欄４３６にサーバ番号４を登録する。また、サーバ停止制御部１５は、呼制御サーバ＃４の移行処理呼数を表す欄４３７に呼制御サーバ＃５が管理していた呼処理の数である２１０を登録する。さらに、サーバ停止制御部１５は、呼制御サーバ＃４へ移行した呼処理の移行元サーバを表す欄４３８にサーバ番号５を登録する。

　これ以外には、停止対象サーバがないので、この場合、サーバ停止制御部１５は、図１９のテーブル４０３の状態を最終的な計算結果とする。

　図２０～２２を参照して、移行されていた呼処理を戻す呼制御サーバ２０の決定処理の流れ、並びに、その処理における各種情報の変化について説明する。図２０は、移行されていた呼処理を戻す呼制御サーバの決定処理のフローチャートである。また、図２１は、呼処理を戻す前の呼接続情報リストの状態の一例を示す図である。また、図２２は、呼処理を戻す呼制御サーバの決定処理が行われたときの計算結果の一例を示す図である。この場合、図１７～１９を用いて説明した呼処理の移行が行われた状態から開始する場合で説明する。

　サーバ起動制御部１１は、呼処理を戻す呼制御サーバ２０の決定処理を開始すると、呼接続情報リスト１０２の取得要求を呼接続数管理部１６へ通知する。そして、サーバ起動制御部１１は、呼接続管理部１６により生成された呼接続情報リスト１０２を取得する（ステップＳ７０１）。この場合、サーバ起動制御部１１は、図１９で示される計算結果が反映された呼接続情報リスト１０２、すなわち、図２１のテーブル４０４で示されるような呼接続情報リスト１０２を取得する。テーブル４０４では、呼制御サーバ＃２の通常処理呼数を示す欄４４１が０である。また、テーブル４０４では、呼制御サーバ＃３の移行処理呼数示す欄４４２が２３０であり、移行元サーバの欄４４３にサーバ番号２が登録されている。さらに、テーブル４０４では、呼制御サーバ＃５の通常処理呼数を示す欄４４４が０である。また、テーブル４０４では、呼制御サーバ＃４の移行処理呼数示す欄４４５が２１０であり、移行元サーバの欄４４６にサーバ番号５が登録されている。

　次に、サーバ起動制御部１１は、呼接続情報リスト１０２から、停止中の呼制御サーバ２０が有るか否かを判定する（ステップＳ７０２）。停止中サーバがなければ（ステップＳ７０２：否定）、サーバ起動制御部１１は、処理を終了する。これに対して、停止中のサーバが有る場合（ステップＳ７０２：肯定）、サーバ起動制御部１１は、起動中の呼制御サーバ２０の中から呼処理を戻すか否かのチェックの対象として未選択の呼制御サーバ２０を選択する（ステップＳ７０３）。

　そして、サーバ起動制御部１１は、選択した呼制御サーバ２０の負荷量がサーバ起動監視閾値以上か否かを判定する（ステップＳ７０４）。選択した呼制御サーバ２０の負荷量がサーバ起動監視閾値より低い場合（ステップＳ７０４：否定）、サーバ起動制御部１１は、ステップＳ７０７へ進む。

　これに対して、選択した呼制御サーバ２０の負荷量がサーバ起動監視閾値以上の場合（ステップＳ７０４：肯定）、サーバ起動制御部１１は、選択した呼制御サーバ２０へ移行されている呼処理を移行元のサーバへ戻すことを決定する（ステップＳ７０５）。

　そして、サーバ起動制御部１１は、選択した呼制御サーバ２０へ移行されていた呼処理を移行元サーバへ戻した場合の結果を図２２に示すような計算結果として記憶して更新する（ステップＳ７０６）。

　そして、サーバ起動制御部１１は、全ての呼制御サーバ２０のチェックが完了したか否かを判定する（ステップＳ７０７）。チェックを終えていない呼制御サーバ２０がある場合（ステップＳ７０７：否定）、サーバ起動制御部１１は、ステップＳ７０３へ戻る。これに対して、チェックが全て終わっている場合（ステップＳ７０７：肯定）、サーバ起動制御部１１は、計算結果を確定する（ステップＳ７０８）。

　例えば、サーバ起動監視閾値が管理する呼処理数が７００の時の負荷量の場合で説明する。図２１では、呼制御サーバ＃３の接続個数は通常処理呼数と移行処理個数を合わせて８３０であり、呼制御サーバ＃４の接続個数は８１０である。この場合、呼制御サーバ＃３及び＃４のいずれも、負荷量がサーバ起動監視閾値を超えている。そこで、サーバ起動制御部１１は、呼制御サーバ＃３及び＃４のいずれにおいても、呼処理を移行元サーバへ戻すことを決定する。そして、サーバ起動制御部１１は、図２２のテーブル４０５に示すような計算結果を求める。すなわち、サーバ起動制御部１１は、呼制御サーバ＃３から移行先サーバへ戻す処理も戻し処理呼数を示す欄４５１に２３０を登録し、呼処理を戻す呼制御サーバ２０を表す戻し先サーバ番号の欄４５２にサーバ番号２を登録する。また、サーバ起動制御部１１は、呼制御サーバ＃４から移行先サーバへ戻す処理も戻し処理呼数を示す欄４５３に２１０を登録し、呼処理を戻す呼制御サーバ２０を表す戻し先サーバ番号の欄４５４にサーバ番号５を登録する。

　さらに、呼処理の移行から呼処理を戻すという一連の処理におけるサーバ管理情報１０３、呼情報１０４及びサーバ状態管理テーブル１０１の遷移について、図２３～２５を参照して説明する。図２３は、サーバ管理情報の遷移を表す図である。図２４は、呼情報の遷移を表す図である。図２５は、サーバ状態管理テーブルの遷移を表す図である。ここでは、サーバ番号２を有する呼制御サーバ２０である呼制御サーバ＃２の呼処理がサーバ番号３を有する呼制御サーバ２０である呼制御サーバ＃３へ移行される場合について説明する。

　サーバ管理情報１０３は、いずれの呼制御サーバ２０にも呼処理が割り当てられていない状態では、図２３のテーブル１３１のような状態となる。そして、呼処理が割り当てられると、テーブル１３２のように、各呼の呼番号に対応する運転状態が「通常」に変わり、その呼の呼処理を管理している呼制御サーバが登録される。この場合、未だ呼処理の移行は発生していないので、移行先サーバはいずれも「ＮＵＬＬ」となっている。

　そして、呼制御サーバ＃２から呼制御サーバ＃３へ呼処理が移行されると、サーバ管理情報１０３は、テーブル１３３のような状態となる。すなわち、呼制御サーバ＃２が管理していた呼処理の呼番号に対応する運転状態は「移行中」となる。また、呼制御サーバ＃２が管理していた呼処理の呼番号に対応する移行先サーバには、サーバ番号３が登録される。

　その後、移行していた呼処理を移行元サーバへ戻す処理が行われた場合、サーバ管理情報１０３は、移行されていた呼処理の呼番号に対応する運転状態及び移行先サーバの欄は元に戻されテーブル１３４のようになる。テーブル１３４とテーブル１３２は同じであり、移行前の状態にサーバ管理情報１０３が戻っていることが分かる。

　呼情報１０４は、いずれの呼制御サーバ２０にも呼処理が割り当てられていない状態では、図２４のテーブル１４１のような状態となる。そして、呼処理が割り当てられ通話が開始されると、テーブル１４２のように、各呼の呼番号に対応する呼状態が「通話中」に変わり、その呼の着番号、発番号及び通話開始時刻が登録される。その後、移行が発生した状態の呼情報１０４は、テーブル１４３であり、呼処理の戻し処理が発生した状態の呼情報１０４は、テーブル１４４である。このように、呼情報は、移行や呼処理の戻し処理が発生しても、書き換わらない。

　サーバ状態管理テーブル１０１は、移行が発生する前の状態では、テーブル１１１のように、各呼制御サーバ２０の運転状態は「通常」であり、移行先サーバアドレスは「ＮＵＬＬ」となっており、新規イベントはいずれの呼制御サーバ２０も「可」となっている。

　そして、呼制御サーバ＃２から呼制御サーバ＃３へ呼処理が移行され、呼制御サーバ＃２が停止すると、サーバ状態管理テーブル１０１は、テーブル１１２のような状態となる。すなわち、サーバ状態管理テーブル１０１の呼制御サーバ＃２の運転状態は「停止中」となる。また、サーバ状態管理テーブル１０１の呼制御サーバ＃２が管理していた呼処理の呼番号に対応する移行先サーバには、呼制御サーバ＃３のアドレスが登録される。さらに、呼制御サーバ＃２は停止しているので、サーバ状態管理テーブル１０１の新規イベント受付可否は「不可」となる。

　その後、移行していた呼処理を移行元サーバへ戻す処理が行われた場合、サーバ状態管理テーブル１０１は、停止されていた呼制御サーバ＃２の状態が元に戻されテーブル１１３のようになる。テーブル１１３とテーブル１１１は同じであり、移行前の状態にサーバ状態管理テーブル１０１が戻っていることが分かる。

　ここで、図２６Ａ、Ｂ及び図２７Ａ、Ｂを参照して、本実施例に係る通信制御装置による消費電力の軽減の一例について説明する。図２６Ａは、従来技術を用いた場合における呼接続の状態の一例を示す図である。図２６Ｂは、本実施例に係る通信制御装置を用いた場合における呼接続数の状態の一例を示す図である。また、図２７Ａは、従来技術を用いた場合における呼接続の状態の他の例を示す図である。図２７Ｂは、本実施例に係る通信制御装置を用いた場合における呼接続数の状態の他の例を示す図である。

　図２６Ａ、Ｂ及び図２７Ａ、Ｂのいずれも、呼制御サーバ２０が５台稼動している場合である。そして、図２６Ａ、Ｂは、５台のうち４台の呼制御サーバ２０が停止できた場合の比較である。また、図２７Ａ、Ｂは、５台のうち２台の呼制御サーバ２０が停止できた場合の比較である。図２６Ａ、Ｂ及び図２７Ａ、Ｂのいずれも、横軸で１日の時間の経過を表している。

　図２６Ａに示すように、従来技術の場合、全体的に呼接続数が減っても呼制御サーバ２０は停止することなく、全ての呼制御サーバ２０が１日中動き続ける。これに対して、図２６Ｂに示すように、本実施例に係る通信制御装置１を用いた場合、呼処理が減ると、タイミング５０１で移行が開始され１台の呼制御サーバ２０に全ての呼処理が集約され、他の呼制御サーバ２０は停止する。その後、呼処理が増えると、タイミング５０２で停止していた呼制御サーバ２０が起動され、５台の呼制御サーバ２０に呼処理が割り当てられる。このように、１時～６時の間は４台の呼制御サーバ２０を停止することができる。これにより、図２６Ａの場合と比較して図２６Ｂの場合は、消費電力を約２０％削減することができる。

　また、図２７Ａの場合も図２６Ａと同様に、従来技術では、全体的に呼接続数が減っても呼制御サーバ２０は停止することなく、全ての呼制御サーバ２０が１日中動き続ける。これに対して、図２７Ｂに示すように、本実施例に係る通信制御装置１を用いた場合、呼処理が減ると、タイミング５０３で移行が開始され、２台の呼制御サーバの呼処理が他の２台の呼制御サーバ２０に移行される。そして、管理する呼処理が無くなった２台の呼制御サーバ２０は停止する。その後、呼処理が増えると、タイミング５０４で停止していた２台の呼制御サーバ２０が起動され、５台の呼制御サーバ２０に呼処理が割り当てられる。このように、１時～６時の間は２台の呼制御サーバ２０を停止することができる。これにより、図２７Ａの場合と比較して図２７Ｂの場合は、消費電力を約１０％削減することができる。

　以上に説明したように、本実施例に係る通信制御装置は、ある呼制御サーバが管理する呼処理を他の呼制御サーバに移行しても所定の負荷量を超えない場合に、ある呼制御サーバの呼処理を移行したのち停止する。これにより、稼動するサーバを減らすことができ、通信システムの省エネ化を図ることができる。この点、呼処理は呼設定から通信切断までが一連の処理であり、利用状況によって処理時間がまちまちとなる。そのため、管理している呼処理が完了し、管理する呼処理がなくなってから呼制御サーバを停止していては、いつ停止できるかわからず最適な省電力のための制御を行うことが困難である。その点、本実施例に係る通信制御装置は、呼設定から通信切断までの間である呼処理の処理中に、呼処理を他のサーバに移動することができる。そのため、本実施例に係る通信制御装置によれば、適切なタイミングで呼制御サーバが管理する呼処理をなくすことができ、呼制御サーバの電源を適切なタイミングで落とすことができる。

　また、本実施例に係る通信制御装置は、呼処理を移行して停止している呼制御サーバがある場合に、稼動している呼制御サーバの負荷が所定の値を超えた場合、停止している呼制御サーバを起動し呼処理を戻す。これにより、呼制御サーバが高負荷となる状態を回避することができ、通信システムの安定的な運転が可能となる。

（ハードウェア構成）
　図２８は、通信制御装置のハードウェア構成図である。本実施例に係る通信制御装置１は、ＣＰＵ（Central　Processing　Unit）９０１、メモリ９０２、ネットワークカード９０３及びハードディスク９０４を有している。

　メモリ９０２、ネットワークカード９０３及びハードディスク９０４は、ＣＰＵ９０１とバスで接続されている。

　ネットワークカード９０３及びＣＰＵ９０１は、例えば、図１に示した通信制御部１３の機能を実現する。

　ハードディスク９０４は、例えば、図１に示した記憶部１０の機能を実現する。

　ＣＰＵ９０１、メモリ９０２及びハードディスク９０４は、図１に示した、サーバ起動制御部１１、振分制御部１２、移行先サーバ管理部１４、サーバ停止制御部１５、呼接続管理部１６、呼情報アクセス制御部１７及び呼番号管理部１８などの機能を実現する。具体的には、ハードディスク９０４は、図１に示したサーバ起動制御部１１、振分制御部１２、移行先サーバ管理部１４、サーバ停止制御部１５、呼接続管理部１６、呼情報アクセス制御部１７及び呼番号管理部１８などによる処理を実現する各種プログラムを記憶している。そして、プロセッサ９０１は、ハードディスク９０４に記憶されている各種プログラムを読み出してメモリ９０２上に展開し、上述の各機能を実現するプロセスを生成する。

　また、図１０に示した振分サーバ１５１及びＤＢサーバ１５２も図２８で示されるハードウェア構成を有している。この場合、振分サーバ１５１の、ＣＰＵ９０１及びネットワークカード９０３により、図１０に示す通信制御部１９１の機能が実現される。また、振分サーバ１５１のハードディスク９０４に、図１０に示す、サーバ状態管理テーブル１０１、呼情報接続リスト１０２及びサーバ管理情報１０３などが記憶される。そして、振分サーバ１５１のＣＰＵ９０１、メモリ９０２及びハードディスク９０４により、図１０に示す、サーバ起動制御部１１、振分制御部１２及びサーバ停止制御部１５などの機能が実現される。また、ＤＢサーバ１５２の、ＣＰＵ９０１及びネットワークカード９０３により、図１０に示す通信制御部１９２の機能が実現される。また、ＤＢサーバ１５２のハードディスク９０４に、図１０に示す呼情報１０４などが記憶される。そして、ＤＢサーバ１５２のＣＰＵ９０１、メモリ９０２及びハードディスク９０４により、図１０に示す移行先サーバ管理部１４、呼接続数管理部１６、呼情報アクセス制御部１７及び呼番号管理部１８などの機能が実現される。

　また、図２８では、通信制御装置１のハードウェア構成を図示したが、呼制御サーバ２０も同様のハードウェア構成を有している。そこで、図２８を呼制御サーバ２０のハードウェアに対応させて呼制御サーバ２０の各ハードウェアについて説明する。呼制御サーバ２０のＣＰＵ９０１及びネットワークカード９０４により、図１に示す通信制御部２０１の機能が実現される。また、呼制御サーバ２０のＣＰＵ９０１、メモリ９０２及びハードディスク９０４により、図１に示す呼処理部２０２及び電源制御部２０３などの機能が実現される。

　１　通信制御装置
　１０　記憶部
　１１　サーバ起動制御部
　１２　振分制御部
　１３　通信制御部
　１４　移行先サーバ管理部
　１５　サーバ停止制御部
　１６　呼接続数管理部
　１７　呼情報アクセス制御部
　１８　呼番号管理部
　２０、２１、２２　呼制御サーバ
　３０、３１、３２　発信側システム
　４０、４１、４２　着信側システム
　１０１　サーバ状態管理テーブル
　１０２　呼接続情報リスト
　１０３　サーバ管理情報
　１０４　呼情報
　２０１　通信制御部
　２０２　呼処理部
　２０３　電源制御部

Claims

　呼処理を行う各呼制御サーバの処理している呼の数を表す呼接続数を取得する呼接続数管理部と、
　前記呼制御サーバ毎の呼接続数を基に前記呼制御サーバから第一の呼制御サーバを選択し、前記第一の呼制御サーバに割り当てている呼処理を他の呼制御サーバに移行し、前記第一の呼制御サーバに割り当てている呼処理がなくなると前記第一の呼制御サーバを停止させるサーバ停止制御部と、
　呼処理に関する処理要求を受け、前記処理要求に対応する呼処理を行っていた呼制御サーバが前記サーバ停止制御部により停止されている場合、前記サーバ停止制御部が前記処理要求に対応する呼処理を移行した先の前記他の呼制御サーバに前記処理要求を振分ける振分制御部と
　を備えたことを特徴とする通信制御装置。
　前記サーバ停止制御部は、サーバ停止閾値を予め記憶しており、前記呼制御サーバ毎の呼接続数を基に第一の呼制御サーバを選択し、前記第一の呼制御サーバに割り当てた呼処理を他の呼制御サーバに移行した場合の当該他の呼制御サーバの負荷が前記サーバ停止閾値以下であれば、前記第一の呼制御サーバに割り当てた呼処理を当該他の呼制御サーバに移行し、前記第一の呼制御サーバに割り当てた呼処理がなくなると前記第一の呼制御サーバを停止することを特徴とする請求項１に記載の通信制御装置。
　サーバ起動閾値を予め記憶しており、各前記呼制御サーバのいずれかの負荷が前記サーバ起動閾値を超えた場合、停止している呼制御サーバを起動させるサーバ起動制御部をさらに備えたことを特徴とする請求項１に記載の通信制御装置。
　前記サーバ起動制御部は、負荷が前記サーバ起動閾値を超えた呼制御サーバに対して割り当てている呼処理のいずれかを、起動した呼制御サーバへ移行することを特徴とする請求項３に記載の通信制御装置。
　前記サーバ制御起動部は、負荷が前記サーバ起動閾値を超えた呼制御サーバに割り当てた呼処理の中に起動した呼制御サーバから移行された移行呼処理がある場合、前記移行呼処理の移行元である起動した呼制御サーバへ前記移行呼処理を戻すことを特徴とする請求項４に記載の通信制御装置。
　呼処理を行う各呼制御サーバの処理している呼の数を表す呼接続数を取得し、
　前記呼制御サーバ毎の呼接続数を基に前記呼制御サーバから第一の呼制御サーバを選択し、前記第一の呼制御サーバに割り当てている呼処理を他の呼制御サーバに移行し、
　前記第一の呼制御サーバに割り当てている呼処理がなくなると前記第一の呼制御サーバを停止させ、
　呼処理に関する処理要求を受け、前記処理要求に対応する呼処理を行っていた呼制御サーバが前記サーバ停止制御部により停止されている場合、前記処理要求に対応する呼処理を移行した先の前記他の呼制御サーバに前記処理要求を振分ける
　ことを特徴とする通信制御方法。
　呼制御サーバと通信制御装置とを有する通信制御システムであって、
　前記呼制御サーバは、
　呼の処理を行う呼処理部と、
　自装置を停止させる停止制御部とを備え、
　前記通信制御装置は、
　各前記呼制御サーバの処理している呼の数を表す呼接続数を取得する呼接続数管理部と、
　前記呼制御サーバ毎の呼接続数を基に、前記呼制御サーバから第一の呼制御サーバを選択し、前記第一の呼制御サーバに割り当てている呼処理を他の呼制御サーバに移行し、前記第一の呼制御サーバに割り当てている呼処理がなくなると前記第一の呼制御サーバの前記停止制御部に対して停止を指示するサーバ停止制御部と、
　呼処理に関する処理要求を受け、前記処理要求に対応する呼処理を行っていた呼制御サーバが停止している場合、前記サーバ停止処理部が前記処理要求に対応する呼処理を移行した先の前記他の呼制御サーバに前記処理要求を振分ける振分制御部
　を備えたことを特徴とする通信制御システム。