JP2017050673A - 負荷分散装置，負荷分散システム，及び負荷分散装置の信号振分方法 - Google Patents

Abstract

【課題】或る宛先向けの信号の輻輳の影響を抑える。【解決手段】負荷分散装置は、複数の信号処理部のいずれかに発呼信号を振り分ける振分部と、或る宛先向けの発呼信号について、振分先の信号処理部での処理不可を示す情報の受信回数が所定範囲に達した場合に、前記或る宛先向けの発呼信号の振分先を、前記複数の信号処理部中の特定の信号処理部とする制御部と、を含む。【選択図】図１６

Description

本発明は、負荷分散装置，負荷分散システム，及び負荷分散装置の信号振分方法に関する。

コンサートチケットの予約や、テレビショッピングにおける商品購入などの企画に対する電話申込みのために、特定の着信先電話番号（着番）宛の信号がバースト的に発生し、輻輳が発生する（電話が繋がりにくくなる）ことがある。このような輻輳は、「企画型輻輳」と呼ばれる。

一方、電話交換網には、生起した呼の信号（発呼信号）を処理する装置（呼処理装置と呼ぶ）が複数台予め用意され、信号を複数の呼処理装置に振り分ける負荷分散装置が設けられている。負荷分散装置は、企画によってバースト的に発生した特定の着番宛の信号（「バースト呼の信号」と称する）を、例えばラウンドロビン方式で均等に各呼処理装置に振り分ける。振分によって、特定の呼処理装置へ負荷が偏り、当該呼処理装置が信号処理不能状態となることが回避される。

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

しかしながら、振分処理によって各呼処理装置へ均等に生起した呼の信号が振り分けられても、各呼処理装置での呼処理の状況によっては、呼処理装置がリソース不足で信号処理不能状態となる場合が起こり得る。この場合、呼処理装置は、振り分けられた信号を処理できない旨を負荷分散装置に通知する。すると、負荷分散装置は、当該信号を所定の迂回ルールに従って異なる呼処理装置（迂回先）へ振り分ける迂回処理を行う。

ところが、負荷分散装置は、振分処理に加えて迂回処理を行うので、負荷が上昇し、電話交換網、すなわちネットワーク（ＮＷ）全体に輻輳が拡大する。このようなバースト呼の信号による輻輳の影響を受けて、バースト呼以外の呼（「一般呼」と称する）の完了率が低下するおそれがあった。ここに、生起した呼が相手側に接続され、通信を開始することを「完了」といい、完了呼数の生起呼数に対する割合を完了率という。

本発明は、特定の宛先向けの信号による輻輳の影響を抑えることが可能な技術を提供することを目的とする。

本発明の一側面は、負荷分散装置である。この負荷分散装置は、複数の信号処理部のいずれかに発呼信号を振り分ける振分部と、或る宛先向けの発呼信号について、振分先の信号処理部での処理不可を示す情報の受信回数が所定範囲に達した場合に、前記或る宛先向けの発呼信号の振分先を、前記複数の信号処理部中の特定の信号処理部とする制御部と、を含む。

本発明によれば、特定の宛先向けの信号による輻輳の影響を抑えることができる。

実施形態に係る負荷分散システムが適用されたネットワークシステムの構成例を示す図である。 図２は、ゲートウェイ（ＧＷ）で企画型輻輳が生じた場合の問題点を説明する図である。 図３は、バースト呼用の呼処理リソースを模式的に示す。 図４は、実施形態のロードバランサの動作例を説明する図である。 図５は、実施形態のロードバランサの動作例を説明する図である。 図６は、実施形態のロードバランサの動作例を説明する図である。 図７は、実施形態のバースト呼用の呼処理サーバにおけるバースト呼の処理専用のリソースの増加（追加）を説明する図である。 図８は、実施形態のバースト呼用の呼処理サーバにおけるバースト呼の処理専用のリソースの減少（一部解放）を説明する図である。 図９は、実刑体のロードバランサとして動作可能な情報処理装置のハードウェア構成礼を示す図である。 図１０は、ロードバランサの機能を模式的に示すブロック図である。 図１１は、呼処理サーバの機能を模式的に示すブロック図である。 図１２は、実施形態の動作例を示すシーケンス図である。 図１３は、実施形態の動作例を示すシーケンス図である。 図１４は、バースト呼に対する発信規制が実施されている場合における動作例を示すシーケンス図である。 図１５は、バースト呼に対する発信規制が実施されている場合における動作例を示すシーケンス図である。 図１６は、ロードバランサの処理例を示すフローチャートである。 図１７は、ロードバランサから信号を受信した場合における呼処理サーバの処理例を示すフローチャートである。 図１８は、或る着信先の電話番号（“012-345-6789”）の振分先をバースト呼用の呼処理サーバへ切り換えた後に、当該着信先の電話番号向けの発呼の信号が受信された場合におけるロードバランサの処理例を示すフローチャートである。 図１９は、ロードバランサが発信規制中に規制対象の電話番号への発呼の信号を受信した場合における処理例を示すフローチャートである。 図２０は、呼処理リソース量の変更指示をロードバランサから受信した呼処理サーバにおける処理例を示すフローチャートである。

以下、図面を参照して実施形態について説明する。実施形態の構成は例示であり、実施形態の構成に限定されない。図１は、実施形態に係る負荷分散システムが適用されたネットワークシステムの構成例を示す図である。図１の例では、ネットワークシステムは、第１網１と、第２網２とを含む。第１網１は、複数の通信ノード５と、各通信ノード５と接続されたゲートウェイ（ＧＷ）３とを含む。第２網２は、複数の通信ノード６と、各通信ノードと接続されたゲートウェイ（ＧＷ）４とを含む。ＧＷ３とＧＷ４とが接続されることによって、第１網１と第２網２とが接続されている。

以下の説明では、第１網１及び第２網２のそれぞれは電話網であり、通信ノード５，通信ノード６が電話端末である例について説明する。但し、第１網１及び第２網２は、データ通信網であっても良い。また、第１網１は、ＩＰ（Internet Protocol）電話網である
。一方、第２網２は、ＩＰ電話網であっても、ＰＳＴＮ網であっても良い。

ＧＷ３は、電話交換網として機能する。図１に示すように、ＧＷ３は、負荷分散サーバ（以下「ロードバランサ」と称する）７と、複数の呼処理サーバ８とを有する。ロードバランサ７は、「負荷分散装置」の一例であり、複数の呼処理サーバ８は、「複数の信号処理部」の一例である。

ロードバランサ７は、各通信ノード５で生起された、特定の通信ノード６の電話番号を着信先番号とする発呼の信号（発呼信号ともいう）を受信する。ロードバランサ７は、所定の振分ルールに従って、受信された発呼信号を複数の呼処理サーバ８のいずれかに振り分ける。図１の例では、３つの呼処理サーバ８（呼処理サーバ＃１，＃２，＃３）が例示されている。但し、呼処理サーバ８の数は適宜設定可能である。ロードバランサ７は、例えば、ラウンドロビン方式によって、呼処理サーバ＃１→呼処理サーバ＃２→呼処理サーバ＃３→呼処理サーバ＃１・・・の順で順繰りに信号を各呼処理サーバ８に振り分ける。

呼処理サーバ８は、振り分けられた信号に基づき所定の処理を行う。例えば、振り分けられた信号をＧＷ４（第２網２）へ伝送するためのプロトコル変換、或いはフォーマット変換を行う。変換によって得られた信号は、呼処理サーバ８から出力され、ＧＷ４へ送信される。ＧＷ４では、受信信号に対する所定の処理（プロトコル変換など）を行う。図１に模式的に示すように、各呼処理サーバ８からの信号出力により、最終的に、着信先である第２網２の通信ノード６に対し、発呼を知らせる信号が着信（着呼）する。

第１網１のキャリア（通信事業者）は、呼の疎通確保を目的として、ネットワークリソースの有効活用（負荷分散、迂回制御等）に努めている。例えば、ロードバランサ７は、ラウンドロビン方式で、第１網１から第２網２へ向けられた複数の発呼信号を複数の呼処理サーバに振り分ける（分配）する。

図２は、ＧＷ３で企画型輻輳が生じた場合の問題点を説明する図である。チケット予約、商品販売などの企画（イベント）に対する電話申込みにより、第１網１において、特定の着信電話番号（着番：図２では、“012-345-6789”）へ向けた不特定多数の発信者からの発呼がバースト的に発生したと仮定する。この場合、発呼信号が、ロードバランサ７に集中する。企画型輻輳の要因となる呼を「バースト呼」と呼ぶ。

ロードバランサ７は、ラウンドロビン方式で、バースト呼の信号を複数の呼処理サーバ８（呼処理サーバ＃１，呼処理サーバ＃２，呼処理サーバ＃３）へ振り分けを行う。ところが、発呼信号の量によっては、各呼処理サーバ８の信号処理のリソース（回線リソース）の使用率が上昇し、リソース不足となる。この場合、振分先の呼処理サーバ８は、処理不可を示す情報をロードバランサ７に送信する。ロードバランサ７は、処理不可を示す情報を受信すると、迂回処理を行う。迂回処理は、或る呼処理サーバ８へ振り分けた信号を、迂回路に該当する他の呼処理サーバ８へ振り分ける処理である。

迂回処理が頻発すると、ロードバランサ７は、振分処理と迂回処理とを並列に実行するようになるので負荷が上昇し、ロードバランサ７が処理のボトルネックとなる可能性がある。ロードバランサ７がボトルネックになると、輻輳の範囲がＮＷ全体（ロードバランサ７及び全ての呼処理サーバ８）に及ぶおそれがある。また、ロードバランサ７にて、バースト呼以外の呼（一般呼：図２の例では、着番“012-345-9999”，“012-345-8888”）の信号を受け付けることができなくなる。これによって、一般呼の完了率が低下するおそれがあった。

企画型輻輳は、キャリアが事前に企画の発生時刻を把握している場合には、処理リソースの前もっての拡大や、ロードバランサ７における振分ルールを企画の発生時刻に合わせて変更することによって対応することができる。しかし、キャリアが全ての企画を把握す
ることは困難である。

実施形態では、企画型輻輳の要因となる呼のような、或る着番向けにバースト的に発生した呼の信号の振分先を切り換えて、当該呼の信号の輻輳が影響する範囲の拡大を抑え、一般呼の完了率低下を回避可能とするロードバランサ７について説明する。

実施形態では、ロードバランサ７において、迂回処理の対象となる呼の着番を記憶する。企画型輻輳の要因となる呼、すなわち、特定の時刻に予約や販売などが開始される企画によって生じる、或る電話番号を着信先とする呼（以下、「企画呼」と称する）の信号は、大量且つバースト的に発生することが少なくない。

企画呼が大量且つバースト的に発生する場合には、企画呼の信号は、ロードバランサ７において、高い確率で迂回処理の対象となると考えられる。このため、迂回処理の対象となった呼の信号の着番を記憶、解析することで、企画呼の信号を検出することができる。

また、実施形態では、ロードバランサ７において、記憶した着番と同じ番号を着信先とする信号の振分先を、所定条件下で、特定の呼処理サーバ８に切り換える。これによって、企画呼の信号による輻輳の影響の拡大を抑止し、一般呼の完了率を高める。

実施形態では、特定の呼処理サーバ８（信号処理部の一例）について、バースト呼用の呼処理リソース（信号の処理用のリソースの一例）が予め確保される。図３は、バースト呼用の呼処理リソースを模式的に示す。実施形態では、呼処理サーバ＃１〜＃３のうち、呼処理サーバ＃３にバースト呼専用の呼処理リソースが確保される。

図３において、呼処理リソースは、マトリクスで模式的に表され、呼処理リソースの一部がバースト呼専用の呼処理リソースとして使用される。残りの呼処理リソースは、バースト呼以外の呼（一般呼）用の呼処理リソースとして使用される。

実施形態において、ロードバランサ７は、接続不可を示す応答処理の受信回数が所定範囲に達した着番宛の呼を、「バースト呼」として検出する。具体的に説明すると、不特定多数のユーザが、第２網２の或る通信ノード６（電話番号：Ａ）に対する発呼を行う。すると、各発呼の信号を受信するロードバランサ７は、例えば、ラウンドロビン方式によって、各発呼の信号を、複数の呼処理サーバ８（呼処理サーバ＃１〜＃３）に振り分ける。

ラウンドロビンは、初期の（第１の）振分ルール（振分方法）の一例である。但し、初期の振分方法として、ラウンドロビン以外の振分方法が使用されても良い。ロードバランサ７は、各呼処理サーバ８の負荷を分散するために、所定の振分ルールに従って少なくとも２つの呼処理サーバ８へ発呼の信号を振り分けるようになっていれば良い。

各呼処理サーバ８は、受信した信号の呼処理、例えば、着信先の電話番号“Ａ”に対する接続処理（「信号処理」の一例）を行う。このとき、各呼処理サーバ８は、接続を行うことができない場合には、着信先の電話番号“Ａ”と、接続不可の要因とを含む応答信号を、ロードバランサ７に送信（通知）する。接続不可要因としては、接続用のリソースの不足と、ビジー状態（接続処理（信号処理）を受け付けられない状態）とがある。

ロードバランサ７は、呼処理サーバ８へ振り分ける信号の着番毎に、呼処理サーバ８における信号の処理、すなわち、呼の接続状況を管理する。以下の表１は、ロードバランサ７にて管理される、接続不可カウンタテーブル（以下、カウンタテーブルという）のデータ構造例を示す。

表１に示すように、カウンタテーブルは、第１のカウンタ（カウンタＡ），第２のカウンタ（カウンタＢ），第３のカウンタ（カウンタＣ−１），及び第４のカウンタ（カウンタＣ−２）の各カウンタ値を記憶する。

カウンタＡは、初期の振分方法（ラウンドロビン）で振り分けられた、着番の信号の振分先の呼処理サーバ８から、リソース不足を要因とする接続不可の応答信号の受信回数（通知回数）を計数する。カウンタＢは、ラウンドロビンで振り分けられた、着番の信号の振分先の呼処理サーバ８から、ビジー状態を要因とする接続不可の応答信号の受信回数（通知回数）を計数する。

カウンタＣ−１は、バースト呼用の呼処理サーバ８（呼処理サーバ＃３）から受信される、リソース不足を要因とする接続不可の応答信号の受信回数（通知回数）を計数する。カウンタＣ−２は、バースト呼用の呼処理サーバ８（呼処理サーバ＃３）から受信される、ビジー状態を要因とする接続不可の応答信号の受信回数（通知回数）を計数する。

カウンタテーブルへのレコード（エントリ）の登録は、例えば、以下によって行われる。すなわち、ロードバランサ７は、受信された信号の宛先（着番）を当該信号の参照によって特定する。特定した着番のレコードがカウンタテーブルに登録されていなければ、当該レコードを登録する。なお、レコードの登録は、呼処理サーバ８から、着番及びエラー情報（接続不可を示す情報を含む）が受信された場合に実行されるようにしても良い。この場合、カウンタテーブルに登録されるレコード数を減らすことができると考えられる。なお、カウンタテーブルに登録されたレコードは、例えば、呼の切断を契機に削除される。

図４は、実施形態のロードバランサの動作例を示す図である。或る着番（例：“012-345-6789”）宛の信号を、初期の振分方法（ラウンドロビン）によって呼処理サーバ８（呼処理サーバ＃１，＃２，＃３）へ振り分ける。電話番号“012-345-6789”は、企画における着信先として指定された番号であり、当該電話番号への発呼は、不特定多数の者からバースト的に生起された企画呼（バースト呼）であると仮定する。

このとき、例えば、呼処理サーバ＃１は、リソース不足によって、企画呼（着番“012-345-6789”）の信号の呼処理（接続処理）ができない場合には、以下の処理を行う。すなわち、呼処理サーバ＃１は、エラー情報（接続不可の要因（リソース不足）を示す情報を含む）と着番とを含む応答信号をロードバランサ７へ送信する。ロードバランサ７は、応答信号を受信すると、応答信号中の着番に対応するレコード（エントリ）を、接続不可カウンタテーブルから特定し、当該レコードにおけるカウンタＡの値をインクリメント（１を加算）する。

このとき、カウンタＡの値が、ロードバランサ７にて予め保持されているカウンタＡの値に対する閾値（閾値Ａとする）を超える場合（閾値を超える範囲に達した）には、ロードバランサ７は、以下の判定を行う。すなわち、ロードバランサ７は、カウンタＡの値が閾値Ａを超過した着番の信号が、バースト呼の信号であると判定する。この場合、ロード
バランサ７は、当該着番の信号についての振分先を、ラウンドロビンで決定される振分先でなく、特定の呼処理サーバ８である呼処理サーバ＃３に切り換える（変更する）。なお、上記した振分先の切り替えタイミングにおいて、接続不可カウンタテーブルにおけるカウンタＡ及びカウンタＢの値がリセットされる。

振分方法の変更（切り換え）によって、バースト呼の信号が、特定の呼処理サーバ＃３に振り分けられ、呼処理サーバ＃１及び呼処理サーバ＃２には振り分けられなくなる。このように、バースト呼の信号が振り分けられない呼処理サーバ＃１及び＃２には、バースト呼の影響が及ばない。このため、呼処理サーバ＃１及び＃２では、バースト呼以外の呼（一般呼）の処理がバースト呼の影響が抑えられた状態で行われる。よって、バースト呼の影響による一般呼の完了率の低下を抑えることができる。

一方、呼処理サーバ＃３では、バースト呼専用のリソースを用いてバースト呼の信号に対する呼処理を行うことができる。よって、バースト呼について、或る程度の完了率を確保することができる。

図５は、実施形態のロードバランサの動作例を示す図である。或る着番（例：“012-345-6789”）宛の信号が、図４の例と同様に、呼処理サーバ＃１で、処理不可（接続不可）と判定されたと仮定する。但し、接続不可の要因が、リソース不足でなく、ビジー状態である。

ロードバランサ７は、エラー情報（接続不可の要因（ビジー）を示す情報を含む）と着番とを含む応答信号を受信する。すると、ロードバランサ７は、応答信号中の着番に対応する、接続不可カウンタテーブル（表１）のレコードにおけるカウンタＢの値をインクリメントする（１を加算する）。

このとき、カウンタＢの値が、ロードバランサ７にて予め保持されている閾値（閾値Ｂ）を超過する場合には、ロードバランサ７は、所定期間、当該着番に対する呼を、所定の規制率で疎通させる発信規制（「接続規制」の一例）を実行する。所定期間は、例えば、ロードバランサ７が有するタイマＡで計時することができる。規制率は、以下の表２に示すような、発信規制の管理テーブルにて管理することができる。

ロードバランサ７は、カウンタＢが閾値Ｂを超過する場合には、発信規制フラグを“ＯＮ”に設定し、予め設定された発信規制率（例えば“４０％”）で発信規制を行う。すなわち、ロードバランサ７は、ロードバランサ７で受信される着番“012-345-6789”の信号のうち、４０％は疎通させる（振分を行う）が、残りの６０％の信号は受け付けない。但し、発信規制率の値は適宜設定可能である。なお、カウンタＢが閾値Ｂを超過する（発信規制を開始する）タイミングで、カウンタＡ及びカウンタＢの値は初期化（リセット）することができる。

発信規制の開始を契機に、当該着番（例：“012-345-6789”）向けの信号は、バースト呼用の呼処理サーバ＃３へ振り分けられる。図６は、実施形態のロードバランサの動作例
を示す図である。

上記した或る着番（例：“012-345-6789”）への発信規制中に、ロードバランサ７が呼処理サーバ＃３からリソース不足を要因とする接続不可の応答信号を受信した場合には、ロードバランサ７は、以下の処理を行う。すなわち、ロードバランサ７は、着番に対応するカウンタＣ−１のインクリメントを行う。一方、ロードバランサ７は、ビジー状態を要因とする接続不可の応答信号を受信した場合には、着番に対応するカウンタＣ−２をインクリメントする。

ロードバランサ７は、カウンタＣの値、すなわち、カウンタＣ−１の値とカウンタＣ−２の値との合計値が予め用意された閾値Ｃを超過する場合には、当該着番宛の呼について、タイマＡで定義された時間、所定の規制率で発信規制を行う。但し、発信規制率は可変とする。発信規制の管理は発信規制管理テーブル（表2参照）の発信規制フラグによって
管理を行なう。また、このタイミングでカウンタＣ−１及びカウンタＣ−２の各値の初期化を行う。

ロードバランサ７は、タイマＡで設定した一定時間が満了した場合には、対応するカウンタＣ−１，及びカウンタＣ−２の値に応じて、以下の処理を実行する。

第１に、カウンタＣ−１の値が閾値Ｃ−１を超過する場合には、ロードバランサ７は、バースト呼用の呼処理サーバ＃３に対し、バースト呼用の呼処理リソースの追加を指示する。図７に示すように、呼処理サーバ＃３は、バースト呼専用の呼処理リソースを増加させる。増加量は、適宜設定可能である。その後、ロードバランサ７は、バースト呼についての振分方法を、初期方法（ラウンドロビン）に戻す。

第２に、カウンタＣ−１の値が、第２閾値Ｃ−１’を下回っている（第２閾値Ｃ−１’を下回る範囲に低下した場合）には、ロードバランサ７は、バースト呼用の呼処理サーバ＃３に対し、バースト呼用の呼処理リソースの一部解放を指示する。図８に示すように、呼処理サーバ＃３は、バースト呼専用の呼処理リソースの一部を解放する。解放量は適宜設定可能である。解放されたリソースは、一般呼の信号の処理に使用可能である。その後、ロードバランサ７は、バースト呼についての振分先（振分方法）を、元のラウンドロビンに戻す。

第３に、カウンタＣ−２の値が、閾値Ｃ−２を超える（閾値Ｃ−２を超える範囲に達する）場合には、ロードバランサ７は、バースト呼に対する発信規制を強化（厳しく）し、振分方法を元に戻す。例えば、発信規制が、「現状の規制率＋１０％」のような厳しい規制率に設定し直される。但し、どの程度厳しくするかは適宜設定可能である。

第４に、カウンタＣ−２の値が、第２閾値Ｃ−２’を下回っている（第２閾値Ｃ−２’を下回る範囲に低下した場合）には、ロードバランサ７は、バースト呼に対する発信規制を緩和し、振分方法を元に戻す。例えば、発信規制が、「現状の規制率−１０％」に緩和される。但し、どの程度緩和するかは適宜設定可能である。

以下の表３に、実施形態１で用いるパラメータ（カウンタ値），閾値，タイマＡの設定値を示す。

図９は、実施形態に係るロードバランサ７，呼処理サーバ８として使用可能な情報処理装置３０のハードウェア構成例を示す。図９には、単一の情報処理装置（コンピュータ）の構成を示すが、ロードバランサ７及び複数の呼処理サーバ８（すなわち、ＧＷ３）は、複数のプロセッサを備えるコンピュータ、或いは、複数台のコンピュータによって形成されても良い。

図９において、情報処理装置３０は、バスを介して相互に接続されたＣＰＵ３１，主記憶装置３２，補助記憶装置３３，入力装置３５，出力装置３６，及び通信インタフェース（通信ＩＦ）３４を含む。

主記憶装置３２は、ＣＰＵ３１の作業領域，プログラムやデータの記憶領域，通信データのバッファ領域として使用される。主記憶装置３２は、例えば、Random Access Memory（ＲＡＭ），或いはＲＡＭとRead Only Memory（ＲＯＭ）との組み合わせで形成される。

補助記憶装置３３は、ＣＰＵ３１によって実行されるプログラム，及びプログラムの実行に際して使用されるデータを記憶する。補助記憶装置３３は、例えば、ハードディスクドライブ（ＨＤＤ），Solid State Drive（ＳＳＤ），フラッシュメモリ，Electrically Erasable Programmable Read-Only Memory（ＥＥＰＲＯＭ）などである。

入力装置３５は、情報処理装置３０に情報やデータを入力するために使用される。入力装置３５は、例えば、ボタン、キー、マウスなどのポインティングデバイス，タッチパネルなどを含む。

出力装置３６は、情報やデータを出力する。出力装置３６は、例えばディスプレイ装置である。通信ＩＦ３４は、ネットワークを介して他の情報処理装置と接続される。これにより、ロードバランサ７として動作する情報処理装置は、呼処理サーバ８として動作する情報処理装置と通信することができる。通信ＩＦ３４は、例えばネットワークインタフェースカード（ＮＩＣ）である。

ＣＰＵ３１は、主記憶装置３２又は補助記憶装置３３に記憶されたプログラムを主記憶装置３２にロードして実行する。主記憶装置３２又は補助記憶装置３３に記憶されたプロ
グラムは、オペレーティングシステムや、情報処理装置３０をロードバランサ７や呼処理サーバとして動作させるアプリケーションプログラムを含む。ＣＰＵ３１のプログラムの実行によって、情報処理装置３０は、ロードバランサ７，或いは、呼処理サーバ８として動作することができる。

なお、ＣＰＵ３１で実行される処理は、複数のＣＰＵ（プロセッサ）によって実行されても良い。ＣＰＵ３１で実行される処理の少なくとも一部は、Digital Signal Processor（ＤＳＰ）によって実行されても良い。また、ＣＰＵ３１で実行される処理の少なくとも一部は、Field Programmable Gate Array（ＦＰＧＡ）のようなプログラマブルロジック
デバイス（ＰＬＤ）や集積回路（ＩＣ，ＬＳＩ，Application Specific Integrated Circuit（ＡＳＩＣ）など）のような半導体デバイスで実行されても良い。

なお、ＣＰＵ３１は、「プロセッサ」,「振分部」,「制御部」,「規制制御部」,「指示部」の一例であり、通信ＩＦ３４は、「振分部」，「通信部」の一例である。主記憶装置３２及び補助記憶装置３３のそれぞれは、「記憶部」，「記憶装置」，「メモリ」，「記憶媒体」の一例である。

図１０は、ロードバランサ７の機能を模式的に示すブロック図である。図９に示した情報処理装置３０は、ＣＰＵ３１がプログラムを実行することによって、制御部７０Ａと、管理部７０Ｂとを含むロードバランサ７として動作する。制御部７０Ａは、信号受信部７１と、発信規制制御部７２と、信号振分部７３とを含む。管理部７０Ｂは、タイマ管理部７４と、カウンタ管理部７５とを含む。

信号受信部７１は、通信ＩＦ３４を介してロードバランサ７の外部（例えば、呼処理サーバ８）からの信号を受信する処理を行う。信号受信部７１は、エラー内容判定部７１ａを有している。エラー内容判定部７１ａは、信号受信部７１で受信した応答信号に含まれるエラー情報を抽出し、判定する。エラー情報は、上述した接続不可の要因を示す情報であり、リソース不足であったり、ビジー状態であったりする。

発信規制制御部７２は、特定の電話番号（バースト呼と判定された着番）に対する発信規制の実施、発信規制率の管理（変更や切り替え）を行う。信号振分部７３は、信号送信部７３ａと振分先制御部７３ｂとを含んでいる。

信号送信部７３ａは、通信ＩＦ３４を介してロードバランサ７から外部の装置（例えば、呼処理サーバ８）に対して信号を送信する処理を行う。振分先制御部７３ｂは、カウンタ値及び閾値を用いた判定を行い、振分ルールの変更（切り換え）を行う。信号送信部７３ａは、振分方法（振分ルール）に従った振分先の呼処理サーバ８へ信号を送信する。

カウンタ管理部７５は、カウンタテーブル７５ａと、カウンタ閾値７５ｂとを管理する。カウンタテーブル７５ａは、上述した接続不可カウンタテーブル（表１）であり、表１や表３に示した各カウンタの値を記憶する。カウンタ閾値７５ｂは、表３に示した各閾値である。このように、カウンタ管理部７５は、ロードバランサ７で使用する各カウンタ情報及び閾値を管理している。なお、各閾値は保守者にて変更可能である。カウンタ管理部７５は、各カウンタ値の加算（インクリメント）を、信号受信部７１で受信されたエラー情報の内容に応じて行う。

タイマ管理部７４は、タイマ７４ａを有する。タイマ７４ａは、上述した“タイマＡ”であり、表３に示したような、発信規制の時間（一定時間）を計時する。タイマ管理部７４は、発信規制制御部７２からのタイマ設定要求に応じてタイマ７４ａの計時を開始させる。また、タイマ７４ａの満了を、発信規制制御部７２に知らせる。

信号受信部７１及び信号送信部７３ａは、例えば、通信ＩＦ３４を用いて形成される。エラー内容判定部７１ａ，発信規制制御部７２，振分先制御部７３ｂ，カウンタ管理部７５，タイマ管理部７４は、ＣＰＵ３１がプログラムを実行することによって得られるＣＰＵ３１の機能である。カウンタテーブル７５ａ，カウンタ閾値７５ｂ，タイマ７４ａは、例えば主記憶装置３２及び補助記憶装置３３の少なくとも一方に記憶される。

図１１は、呼処理サーバ８の機能を模式的に示すブロック図である。図９に示した情報処理装置３０は、ＣＰＵ３１がプログラムを実行することによって、信号受信部８１と、呼処理部８２と、信号送信部８３と、呼処理リソース管理部８４とを含む呼処理サーバ８として動作する。

信号受信部８１は、ロードバランサ７から送信された信号を受信する。呼処理部８２は、信号受信部８１で受信された信号に対する呼処理（接続処理）を行う。信号送信部８３は、呼処理部８２での呼処理の結果として得られた信号を他網（第２網２）へ送信する。

呼処理リソース管理部８４は、図３にマトリクスで示したような呼処理リソース（回線リソースなど）を管理する。バースト呼の振分先として使用される特定の呼処理サーバ８の呼処理リソース管理部８４は、バースト呼専用の呼処理リソースの管理も行う。呼処理リソース管理部８４は、ロードバランサ７からの指示（制御信号）に従って、バースト呼専用の呼処理リソースの量を変更（調整）する。

図１２は、実施形態の動作例を示すシーケンス図である。発呼端末である通信ノード５から、或る電話番号（例えば“012-345-6789”）宛に送信された発呼信号（図１２＜１＞）は、ロードバランサ７の信受信部７１で受信され、信号振分部７３に渡される（図１２＜２＞）。

信号振分部７３は、初期の振分方法（ラウンドロビン）に従って、信号を、例えば受信順で、順繰りに振分先の呼処理サーバ８（呼処理サーバ＃１〜＃３）へ送信する。図１２の例では、信号は、呼処理サーバ＃１へ送信される（図１２＜３＞）。

信号の振分先の呼処理サーバ８がリソース不足で信号に対する呼処理ができない（処理不可）の場合には、図１２[１]の処理が行われる。すなわち、呼処理サーバ８は、エラー情報（リソース不足を示す情報を含む）及び着番を含む応答信号をロードバランサ７へ送信する（図１２＜４＞）。応答信号は信号受信部７１で受信される。

エラー情報及び着番は、カウンタ管理部７５に通知され（図１２＜５＞）、カウンタ管理部７５は、カウンタテーブル７５ａ（表１）中の対応するレコードのカウンタＡをインクリメントする。

カウンタＡの値が閾値Ａを超えた場合には、カウンタ管理部７５は、信号振分部７３に対して、バースト呼（特定の着番への呼）の信号は、特定の（バースト呼用の）呼処理サーバ８である呼処理サーバ＃３へ振り分けることを指示する（図１２＜６＞）。信号振分部７３は、指示に従い、バースト呼の振分先を、呼処理サーバ＃１〜＃３のうち呼処理サーバ＃３のみに切り換える。

なお、信号の振分先の呼処理サーバ８（例えば、呼処理サーバ＃１）において、信号を処理できない要因がない場合には、呼処理部８２が信号の処理を行う。そして、呼処理部８２からの出力信号（例えば、着信先の通信ノード６の呼び出し信号）が、信号送信部８３から第２網２へ送信される（図１２＜７＞）。

図１３は、実施形態の動作例を示すシーケンス図である。発呼端末である通信ノード５から、或る電話番号（例えば“012-345-6789”）宛に送信された発呼信号（図１３＜１＞）は、ロードバランサ７の信号受信部７１で受信され、信号振分部７３に渡される（図１３＜２＞）。

信号振分部７３は、初期の振分方法（ラウンドロビン）に従って、信号を、例えば受信順で、順繰りに振分先の呼処理サーバ８（呼処理サーバ＃１〜＃３）へ送信する。図１３の例では、信号は、呼処理サーバ＃１へ送信される（図１３＜３＞）。

信号の振分先の呼処理サーバ８がビジー状態で信号に対する呼処理ができない（処理不可）の場合には、図１３[１]の処理が行われる。すなわち、呼処理サーバ８は、エラー情報（ビジー状態を示す情報を含む）及び着番を含む応答信号をロードバランサ７へ送信する（図１３＜４＞）。応答信号は信号受信部７１で受信される。

エラー情報及び着番は、カウンタ管理部７５に通知され（図１３＜５＞）、カウンタ管理部７５は、カウンタテーブル７５ａ（表１）中の対応するレコードのカウンタＢをインクリメントする。

カウンタＢの値が閾値Ｂを超えた場合には、カウンタ管理部７５は、タイマ管理部７４に対して、タイマＡの設定を指示する（図１３＜６＞）。タイマ管理部７４は、タイマＡの計時を開始する。

カウンタ管理部７５は、発信規制制御部７２に対して、バースト呼（特定の着番への呼）に対する発信規制の実施を指示する（図１３＜７＞）。発信規制制御部７２は、カウンタ管理部７５からの指示に基づき、タイマＡの時間における特定の着番への呼の受け付けが発信規制率（表２）となるように、特定の着番の呼の信号の受け付けを規制する。

なお、信号の振分先の呼処理サーバ８（例えば、呼処理サーバ＃１）において、信号を処理できない要因がない場合には、図１２＜７＞と同様の動作が行われる。そして、呼処理部８２からの出力信号（例えば、着信先の通信ノード６の呼び出し信号）が、信号送信部８３から第２網２へ送信される（図１３＜８＞）。

図１４及び図１５は、カウンタＢの値が閾値Ｂを超えて、バースト呼に対する発信規制が実施されている場合における動作例を示すシーケンス図である。ロードバランサ７の信号受信部７１で受信したバースト呼（図１４＜１＞）は、信号振分部７３に渡される（図１４＜２＞）信号振分部７３において、バースト呼用の呼処理サーバ８に振り分けられる（図１４＜３＞）。

ロードバランサ７において、信号の振分先の呼処理サーバ８からエラー情報及び着番を含む応答信号が信号受信部７１で受信される（図１４＜４＞）。この場合、エラー情報及び着番は、カウンタ管理部７５に通知される（図１４＜５＞）。カウンタ管理部７５は、エラーがリソース不足を要因とする場合には、カウンタテーブル７５ａ（表１）中の対応するレコードのカウンタＣ−１をインクリメントする。

ロードバランサ７において、信号の振分先の呼処理サーバ８からエラー情報及び着番を含む応答信号が信号受信部７１で受信される（図１４＜６＞）。この場合、エラー情報及び着番は、カウンタ管理部７５に通知される（図１４＜７＞）。カウンタ管理部７５は、エラーがビジー状態を要因とする場合には、カウンタテーブル７５ａ（表１）中の対応するレコードのカウンタＣ−２をインクリメントする。

図１５において、タイマＡが満了すると、タイマ管理部７４からカウンタ管理部７５へ、タイマＡの満了が通知される（図１５＜１＞）。このとき、カウンタＣ−１の値が閾値Ｃ−１を超えている場合には、カウンタ管理部７５は、バースト呼の処理専用のリソースの追加の指示を出力する。指示（指示を含む制御信号）は、ロードバランサ７から呼処理サーバ＃３へ送信される（図１５＜２＞）。呼処理サーバ＃３の呼処理リソース管理部８４は、指示に従い、バースト呼専用の呼処理リソースの量を増加させる（図７参照）。

これに対し、カウンタＣ−１の値が閾値Ｃ−１’を下回っている場合には、カウンタ管理部７５は、バースト呼の処理専用のリソースの一部解放の指示を出力する。指示（指示を含む制御信号）は、ロードバランサ７から呼処理サーバ＃３へ送信される（図１５＜３＞）。呼処理サーバ＃３の呼処理リソース管理部８４は、指示に従い、バースト呼専用の呼処理リソースの一部を解放する（図８参照）。これによって、バースト呼専用の処理リソースの量が減少する。

タイマＡの満了時にカウンタＣ−１の値が閾値Ｃ−１を超えている場合には、カウンタ管理部７５は、バースト呼の処理専用のリソースの追加の指示を出力する。指示（指示を含む制御信号）は、ロードバランサ７から呼処理サーバ＃３へ送信される（図１５＜２＞）。呼処理サーバ＃３の呼処理リソース管理部８４は、指示に従い、バースト呼専用の呼処理リソースの量を増加させる（図７参照）。

タイマＡの満了時にカウンタＣ−１の値が閾値Ｃ−１’を下回っている場合には、カウンタ管理部７５は、バースト呼の処理専用のリソースの一部解放（減少）の指示を出力する。指示（指示を含む制御信号）は、ロードバランサ７から呼処理サーバ＃３へ送信される（図１５＜３＞）。呼処理サーバ＃３の呼処理リソース管理部８４は、指示に従い、バースト呼専用の呼処理リソースの一部を解放する（図８参照）。これによって、バースト呼専用の処理リソースの量が減少する。

タイマＡの満了時にカウンタＣ−２の値が閾値Ｃ−２を超えている場合には、カウンタ管理部７５は、発信規制制御部７２に対し、対応する着番の呼に対する規制率の上昇（規制率の厳格化）を指示する（図１５＜４＞）。発信規制制御部７２は、規制率を、例えば、「現状の規制率＋１０％」に変更（厳格化）する。規制率は、保守者によって適宜変更可能である。

タイマＡの満了時にカウンタＣ−２の値が閾値Ｃ−２’を下回っている場合には、カウンタ管理部７５は、発信規制制御部７２に対し、対応する着番の呼に対する規制率の低下（規制率の緩和）を指示する（図１５＜５＞）。発信規制制御部７２は、指示に従い、規制率を、例えば、「現状の規制率−１０％」に変更（緩和）する。但し、規制率は、保守者によって適宜変更可能である。

図１６は、ロードバランサ７における処理例、例えば、ロードバランサ７として動作する情報処理装置３０のＣＰＵ３１による処理例を示すフローチャートである。図１６の処理は、ロードバランサ７にて発呼の信号が受信されることを契機に開始される。

図１６の０１では、ＣＰＵ３１は、発呼の信号に対するレコードを主記憶装置３２及び補助記憶装置３３の少なくとも一方に記憶されたカウンタテーブル７５ａ（表１）に設定する。その後、信号の振分先をラウンドロビン方式で決定する。信号は、決定された振分先の呼処理サーバ８へ送信される。

０２では、ＣＰＵ３１は、ロードバランサ７が接続不可（エラー情報）を受信したか否
かを判定する。エラー情報が受信されていない場合には（０２，Ｎｏ）、図１６の処理が終了する。この場合、例えば、呼処理を通じて通話回線が確立され、通話がなされる。エラー情報が受信された場合には（０２，Ｙｅｓ）、処理が０３に進む。

０３では、ＣＰＵ３１は、エラー情報中の接続不可要因を判定する。要因がリソース不足であれば、処理が０４に進む。これに対し、要因がビジー状態であれば、処理が０９に進む。

０４では、ＣＰＵ３１は、カウンタテーブル７５ａの対応するレコード中のカウンタＡの値をインクリメントする。０５では、ＣＰＵ３１は、カウンタＡの値が閾値Ａを超過している（超過する範囲に達している）か否かを判定する。カウンタＡの値が閾値Ａを超過していない場合には（０５，Ｎｏ）、図１６の処理が終了する。この場合、例えば、呼の切断処理がなされる。カウンタＡの値が閾値Ａを超過している場合（０５，Ｙｅｓ）には、処理が０６に進む。

０６では、ＣＰＵ３１は、着番の呼をバースト呼と判定する。０７では、ＣＰＵ３１は、バースト呼を呼処理サーバ＃３へ振り分けるように振分方法の設定変更（切り換え）を行う。０８では、ＣＰＵ３１は、対応するレコード中のカウンタＡを初期化し、図１６の処理を終了する。

０９では、ＣＰＵ３１は、カウンタテーブル７５ａの対応するレコード中のカウンタＢの値をインクリメントする。１０では、ＣＰＵ３１は、カウンタＢの値が閾値Ｂを超過している（超過する範囲に達している）か否かを判定する。カウンタＢの値が閾値Ｂを超過していない場合には（１０，Ｎｏ）、図１６の処理が終了する。この場合、例えば、呼の切断処理がなされる。カウンタＢの値が閾値Ｂを超過している場合には（１０，Ｙｅｓ）、処理が１１に進む。

１１では、ＣＰＵ３１は、着番の呼をバースト呼と判定する。１２では、ＣＰＵ３１は、タイマＡの設定を行い、発信規制率の初期値で発信を規制する時間の計時を開始する。１３では、ＣＰＵ３１は、バースト呼の発信規制を行う。すなわち、発信規制率となるように、当該着番宛の信号の受信を拒否するか、受信された当該着番宛の信号の一部についての受信又は振分を禁止する。１４では、ＣＰＵ３１は、カウンタＡを初期化し、図１６の処理を終了する。

図１７は、ロードバランサ７から信号を受信した場合における呼処理サーバ８の処理例を示すフローチャートである。図１７の処理は、例えば、呼処理サーバ８として動作する情報処理装置３０のＣＰＵ３１によって実行される。

１５では、ＣＰＵ３１は、ロードバランサ７から受信された信号の呼処理を行うためのリソースが確保可能か否かを判定する。リソースが確保可能な場合には（１５，Ｙｅｓ）、処理が１６に進む。リソースが確保できない場合には（１５，Ｎｏ）、処理が１８に進む。

１６では、ＣＰＵ３１は、信号に対する処理（呼処理）がビジー状態か否かを判定する。ビジー状態であれば（１６，Ｙｅｓ）、処理が１７に進む。ビジー状態でなければ（１６，Ｎｏ）、図１７の処理が終了する。この場合、信号に対する呼処理が行われ、発着信間で呼が確立される。

１７では、ＣＰＵ３１は、着番とエラー情報（ビジー状態を示す情報を含む）とを生成し、これらを含む応答信号がロードバランサ７に送信される。１８では、ＣＰＵ３１は、
着番とエラー情報（リソース不足を示す情報を含む）とを生成し、これらを含む応答信号がロードバランサ７に送信される。応答信号が送信されると、図１７の処理が終了する。

図１８は、或る着番（“012-345-6789”）の振分先を呼処理サーバ＃３へ切り換えた後に、当該着番向け（当該着番宛）の発呼の信号が受信された場合におけるロードバランサ７の処理例を示すフローチャートである。図１８の処理は、例えば、ロードバランサ７として動作する情報処理装置３０のＣＰＵ３１によって実行される。

００１では、ＣＰＵ３１は、或る着番の信号を呼処理サーバ＃３へ送信する処理を行う。００２では、ＣＰＵ３１は、ロードバランサ７がエラー情報（接続不可）を受信したか否かを判定する。エラー情報が受信された場合には（００２，Ｙｅｓ）、処理が００３へ進む。エラー情報が受信されない場合には（００２,Ｎｏ）、図１８の処理が終了する。
この場合、呼処理サーバ＃３での呼処理を経て、発着信間の呼が確立される。

００３では、ＣＰＵ３１は、エラー情報中の接続不可の要因を解析する。要因がリソース不足であれば、処理が００４に進む。要因がビジー状態であれば、処理が００５に進む。００４では、ＣＰＵ３１は、カウンタテーブル７５ａの対応するレコード中のカウンタＣ−１の値をインクリメントする。００５では、ＣＰＵ３１は、カウンタテーブル７５ａの対応するレコード中のカウンタＣ−２の値をインクリメントする。

００６では、ＣＰＵ３１は、カウンタＣ−１の値とカウンタＣ−２の値との合計値が閾値Ｃを超過している（超過する範囲に達している）か否かを判定する。合計値が閾値Ｃを超過していない場合には（００６，Ｎｏ）、図１８の処理が終了する。この場合、例えば、呼の切断処理がなされる。合計値が閾値Ｃを超過している場合には（００６，Ｙｅｓ）、処理が００７に進む。

００７では、ＣＰＵ３１は、タイマＡの設定を行い、発信規制率の初期値で発信を規制する時間の計時を開始する。００８では、ＣＰＵ３１は、当該着番の呼の発信規制を行う。すなわち、発信規制率となるように、受信された着番宛の信号の一部についての受信を拒絶する。或いは、受信された当該着番宛の信号の一部を振り分けることなく廃棄する。００９では、ＣＰＵ３１は、カウンタＣ−１及びＣ−２を初期化し、図１８の処理を終了する。

図１９は、ロードバランサ７が発信規制中に規制対象の電話番号への発呼の信号を受信した場合における処理例を示すフローチャートである。当該処理は、例えば、ロードバランサ７として動作する情報処理装置３０のＣＰＵ３１によって実行される。

２１において、ＣＰＵ３１は、発信規制に基づき、信号を透過させるか否かを判定する。信号を透過させない場合には（２１，Ｎｏ）、図１９の処理が終了する。この場合、信号は廃棄又は遮断され、着番へ接続できない旨の案内（トーキー）が発信元の通信ノード５（発信端末）へ送られる。信号を透過させる場合には（２１，Ｙｅｓ）、処理が２２に進む。

２２では、ＣＰＵ３１は、信号を呼処理サーバ＃３へ送信する処理を行う。２３では、ＣＰＵ３１は、ロードバランサ７がエラー情報（接続不可）を受信したか否かを判定する。エラー情報が受信された場合には（２３，Ｙｅｓ）、処理が２４へ進む。エラー情報が受信されない場合には、図１９の処理が終了する。この場合、信号に基づく呼処理が行われ、発着信間で呼が確立される。

２４では、ＣＰＵ３１は、エラー情報中の接続不可の要因を解析する。要因がリソース
不足であれば、処理が２５に進む。要因がビジー状態であれば、処理が２６に進む。２５では、ＣＰＵ３１は、カウンタテーブル７５ａの対応するレコード中のカウンタＣ−１の値をインクリメントする。２６では、ＣＰＵ３１は、カウンタテーブル７５ａの対応するレコード中のカウンタＣ−２の値をインクリメントする。

２７では、ＣＰＵ３１は、タイマＡが満了したか否かを判定する。タイマＡが満了していない場合には（２７，Ｎｏ）、図１９の処理が終了する。タイマＡが満了している場合には（２７，Ｙｅｓ）、処理が２８に進む。

２８では、ＣＰＵ３１は、カウンタ値の確認を行う。このとき、カウンタＣ−１の値が閾値Ｃ−１を上回る場合には、処理が２９へ進む。カウンタＣ−１の値が閾値Ｃ−１’を下回る場合には、処理が３０へ進む。カウンタＣ−２の値が閾値Ｃ−２を上回る場合には、処理が３１へ進む。カウンタＣ−２の値が閾値Ｃ−２’を下回る場合には、処理が３２へ進む。

２９では、ＣＰＵ３１は、呼処理サーバ＃３のバースト呼用のリソースの追加を決定し、呼処理サーバ＃３にその旨の指示を送る。３０では、ＣＰＵ３１は、呼処理サーバ＃３のバースト呼用のリソースの一部解放を決定し、呼処理サーバ＃３にその旨の指示を送る。３１では、ＣＰＵ３１は、バースト呼に対する発信規制率の厳格化、例えば「現状の規制率＋１０％」に発信規制率を設定し直す。３２では、ＣＰＵ３１は、バースト呼に対する発信規制率の緩和、例えば「現状の規制率−１０％」に発信規制率を設定し直す。２９〜３２の処理が終了すると、図１９の処理が終了する。

図２０は、呼処理リソース量の変更指示をロードバランサ７から受信した呼処理サーバ８における処理例を示すフローチャートである。図２０の処理は、例えば、バースト呼専用の呼処理リソースを有する呼処理サーバ８として動作する情報処理装置３０のＣＰＵ３１によって行われる。図２０の処理は、例えば、変更指示の受信を契機に開始される。

５１において、ＣＰＵ３１は、変更指示がリソースの追加を示すかリソースの解放を示すかを判定する。変更指示がリソースの追加を示す場合には、処理が５２に進み、リソースの解放を示す場合には、処理が５３に進む。

５２では、ＣＰＵ３１は、例えば、一般呼用の呼処理リソースの５％を、バースト呼用の呼処理リソースに割り当て変更する。これによって、バースト呼用の呼処理リソース量が増加する。５２の処理が終了すると、図２０の処理が終了する。

５３では、ＣＰＵ３１は、例えば、バースト呼用の呼処理リソースの５％を、一般呼用の呼処理リソースに割り当て変更する。これによって、バースト呼用の呼処理リソースの一部が解放され、バースト呼用の呼処理リソース量が減少する。５３の処理が終了すると、図２０の処理が終了する。

実施形態において、複数の呼処理サーバ８（呼処理サーバ＃１〜＃３）は、「複数の信号処理部」の一例であり、ロードバランサ７は、「複数の信号処理部に信号を振り分ける負荷分散装置」の一例である。ロードバランサ７は、「振分部」の一例である信号送信部７３ａ（ＣＰＵ３１）と、「制御部」の一例である振分先制御部７３ｂ（ＣＰＵ３１）とを有する。

振分先制御部７３ｂ（ＣＰＵ３１）は、或る着番の信号（「或る宛先向けの発呼信号」の一例）について、カウンタＡの値が閾値Ａを超過した（「振分先の信号処理部での処理不可を示す情報の受信回数が所定範囲に達した」の一例）場合に、以下の処理を行う。カ
ウンタＡの値は、呼処理（信号処理）のリソース不足を要因とする接続不可を示す情報の受信を契機にインクリメントされる。すなわち、リソース不足を要因とする接続不可を示情報は、「前記或る宛先向けの発呼信号の処理用のリソース不足が処理不可の要因であることを示す情報」の一例である。

カウンタＡの値が閾値Ａを超過した場合に、振分先制御部７３ｂ（ＣＰＵ３１）は、或る着番の信号の振分先を、呼処理サーバ＃１〜＃３のうちの呼処理サーバ＃３（「複数の信号処理部中の特定の信号処理部」の一例）とする（切り換える）。

これによって、或る着番向けの信号（例えば、企画呼の信号）の輻輳の影響が及ぶ範囲が、呼処理サーバ＃３に抑えられる。すなわち、呼処理サーバ＃１及び＃２には、或る着番向けの信号が振り分けられなくなるので、輻輳の影響が及ばない。或る着番向けの信号（バースト呼の信号）以外の一般呼の信号については、例えば、ラウンドロビンによって呼処理サーバ＃１〜＃３へ振り分けられる。一般呼の呼処理が、輻輳の影響が及ばない呼処理サーバ＃１及び＃２で行われることによって、一般呼の完了率の低下を抑えることができる。

実施形態のロードバランサ７は、或る着番向けの信号の振分先を、バースト呼の信号（「振分先の信号処理部での処理不可を示す情報の受信回数が所定範囲に達した信号」の一例）の処理専用のリソースを確保した呼処理サーバ＃３（特定の信号処理部）とする。これによって、バースト呼の信号についても、或る程度の完了率を確保することが可能となる。

また、実施形態では、ロードバランサ７は、規制制御部の一例である発信規制制御部７２（ＣＰＵ３１）を含む。発信規制制御部７２は、或る着番向けの信号（「或る宛先向けの発呼信号」の一例）について、或る場合に、或る着番向けの信号の振分を所定の規制率で規制する。

或る場合は、例えば、カウンタＢの値が閾値Ｂを超過した場合（「振分先の信号処理部での受付不可を示す情報の受信回数が所定範囲に達した場合」の一例）である。ビジー状態を要因とする接続不可を示す情報は、「振分先の信号処理部での受付不可を示す情報」の一例である。或る着番向けの信号に対する規制の実施によって、ビジー状態を早期に解消し、一般呼の信号に対する呼処理が行われるようにする。これによって、一般呼の完了率の低下を抑えることができる。

また、実施形態における発信規制制御部７２は、呼処理サーバ＃３へ送信される或る着番の信号（「前記特定の信号処理部に振り分けられた前記或る宛先向けの信号」の一例）について、以下の処理を行う。すなわち、発信規制制御部７２は、呼処理サーバ＃３での接続不可を示す情報の受信回数（カウンタＣ１の値とカウンタＣ２の値との合計値）が閾値Ｃを超過する場合に、或る着番向けの信号に対する発信規制を行う。これによって、呼処理サーバ＃３で、或る着番向けの信号の呼処理が円滑に実行されるようにすることができる。

また、実施形態におけるロードバランサ７は、「指示部」の一例であるカウンタ管理部７５（ＣＰＵ３１）を含む。カウンタ管理部７５は、呼処理サーバ＃３へ振り分けられる或る着番向けの信号（バースト呼の信号）に対する発信規制の開始から所定時間経過後（すなわち、タイマＡの満了後）において、以下の場合に以下の処理を行う。

以下の場合とは、例えば、リソース不足を要因とする接続不可を示す情報の受信回数（すなわち、カウンタＣ−１の値）が閾値Ｃ−１を超えている場合である。当該場合は、「
リソース不足を要因とする、前記特定の信号処理部での前記或る宛先向けの信号の処理不可を示す情報の受信回数が所定範囲に達している場合」の一例である。

以下の処理とは、呼処理サーバ＃３に対し、或る着番向けの信号（バースト呼の信号）の処理用のリソースの追加を指示すること（「特定の信号処理部に対し、前記或る宛先向けの信号の処理用のリソースの追加を指示する」の一例である）。これによって、呼処理サーバ＃３におけるバースト呼用のリソースを増加し、バースト呼に対する処理を促進させることができる。

また、実施形態において、「指示部」の一例であるカウンタ管理部７５は、タイマＡの満了後において、以下の場合に以下の処理を行う。以下の場合とは、リソース不足を要因とする接続不可を示す情報の受信回数（すなわち、カウンタＣ−１の値）が閾値Ｃ−１’を下回っている場合である。

当該場合は、「リソース不足を要因とする、前記特定の信号処理部での前記或る宛先向けの信号の処理不可を示す情報の受信回数が所定範囲に収まっている場合」の一例である。以下の処理とは、呼処理サーバ＃３に対し、バースト呼の信号の処理用のリソースの減少（一部解放）を指示する（「特定の信号処理部に対し、前記或る宛先向けの信号の処理用のリソースの減少を指示する」の一例）ことである。これによって、バースト呼用のリソースが一般呼に割り当てられるようにして、一般呼の完了率低下を抑えることができる。

また、実施形態において、「規制制御部」の一例である発信規制制御部７２（ＣＰＵ３１）は、タイマＡの満了後（前記特定の信号処理部に振り分けられる前記或る宛先向けの発呼信号についての振分の規制開始から所定時間経過後）において、以下の場合に以下を行う。

以下の場合とは、呼処理サーバ＃３でのビジー状態を要因とする接続不可を示す情報の受信回数、すなわちカウンタＣ−２の値が閾値Ｃ−２を超過している場合である。当該場合は、「特定の信号処理部での前記或る宛先向けの発呼信号の受付不可を示す情報の受信回数が所定範囲に達している場合」の一例である。このような場合に、発信規制制御部７２は、或る着番向けの信号に対する発信規制率を、例えば１０％増加させて厳格化する（「前記或る宛先向けの発呼信号に対する規制率を厳格化する」の一例）。これによって、呼処理サーバ＃３において、バースト呼の信号による影響が、呼処理サーバ＃３で行われる一般呼の処理に及ぶのを抑えることができる。

また、実施形態において、「規制制御部」の一例である発信規制制御部７２（ＣＰＵ３１）は、タイマＡの満了後（前記特定の信号処理部に振り分けられる前記或る宛先向けの発呼信号についての振分の規制開始から所定時間経過後）において、以下の場合に以下を行う。

以下の場合とは、呼処理サーバ＃３でのビジー状態を要因とする接続不可を示す情報の受信回数、すなわちカウンタＣ−２の値が閾値Ｃ−２’を超過している場合である。当該場合は、「特定の信号処理部での前記或る宛先向けの発呼信号の受付不可を示す情報の受信回数が所定範囲に収まっている場合」の一例である。このような場合に、発信規制制御部７２は、或る着番向けの信号に対する発信規制率を、例えば１０％低下させて緩和する（「前記或る宛先向けの発呼信号に対する規制率を緩和する」の一例）。これによって、呼処理サーバ＃３において、一般呼に影響が少ない（低下している）と考えられる場合に、バースト呼の信号の規制を緩和して、バースト呼の完了率を向上させることができる。

また、負荷分散サーバ（ロードバランサ）７及び複数の呼処理サーバ８を含むＧＷ３は、「負荷分散システム」の一例である。但し、実施形態の構成は、信号を振り分けるロードバランサと、振分先となる複数の信号処理部（信号処理装置）とを備える装置乃至システムに広く適用可能である。すなわち、信号の振分先で実行される処理は、呼処理以外の信号処理であっても良い。この場合でも、或る宛先向けの発呼信号がバースト的に発生した場合において、当該信号の輻輳の範囲が拡大するのを抑え、或る宛先以外の宛先へ向けた信号の処理が、或る宛先向けの発呼信号が振り分けられない信号処理部にて適正に行われるようにすることができる。以上説明した実施形態の構成は、適宜組み合わせることができる。

３・・・ゲートウェイ
７・・・負荷分散サーバ（ロードバランサ）
８・・・呼処理サーバ（信号処理部）
３０・・・情報処理装置（コンピュータ）
３１・・・ＣＰＵ
３２・・・主記憶装置
３３・・・補助記憶装置
３４・・・通信インタフェース
７２・・・発信規制制御部
７３ａ・・・信号送信部
７３ｂ・・・振分先制御部
７５・・・カウンタ管理部

Claims (11)

1. 複数の信号処理部のいずれかに発呼信号を振り分ける振分部と、
   或る宛先向けの発呼信号について、振分先の信号処理部での処理不可を示す情報の受信回数が所定範囲に達した場合に、前記或る宛先向けの発呼信号の振分先を、前記複数の信号処理部中の特定の信号処理部とする制御部と、
   を含む負荷分散装置。
2. 前記制御部は、前記或る宛先向けの発呼信号の振分先を、振分先の信号処理部での処理不可を示す情報の受信回数が所定範囲に達した信号の処理専用のリソースを確保した前記特定の信号処理部とする
   請求項１に記載の負荷分散装置。
3. 前記振分先の信号処理部での処理不可を示す情報は、前記或る宛先向けの発呼信号の処理用のリソース不足が処理不可の要因であることを示す情報を含む
   請求項１又は２に記載の負荷分散装置。
4. 前記或る宛先向けの発呼信号について、振分先の信号処理部での受付不可を示す情報の受信回数が所定範囲に達した場合に、前記或る宛先向けの発呼信号に対する振分を所定の規制率で規制する規制制御部をさらに含む
   請求項１又は２に記載の負荷分散装置。
5. 前記特定の信号処理部に振り分けられた前記或る宛先向けの発呼信号について、振分先の信号処理部での処理不可を示す情報の受信回数が所定範囲に達した場合に、前記或る宛先向けの発呼信号に対する振分を所定の規制率で規制する規制制御部をさらに含む
   請求項１又は２に記載の負荷分散装置。
6. 前記特定の信号処理部に振り分けられる前記或る宛先向けの発呼信号についての振分の規制開始から所定時間経過後において、リソース不足を要因とする、前記特定の信号処理部での前記或る宛先向けの発呼信号の処理不可を示す情報の受信回数が所定範囲に達している場合に、前記特定の信号処理部に対し、前記或る宛先向けの発呼信号の処理用のリソースの追加を指示する指示部をさらに含む
   請求項５に記載の負荷分散装置。
7. 前記特定の信号処理部に振り分けられる前記或る宛先向けの発呼信号についての振分の規制開始から所定時間経過後において、リソース不足を要因とする、前記特定の信号処理部での前記或る宛先向けの発呼信号の処理不可を示す情報の受信回数が所定範囲に収まっている場合に、前記特定の信号処理部に対し、前記或る宛先向けの発呼信号の処理用のリソースの減少を指示する指示部をさらに含む
   請求項５又は６に記載の負荷分散装置。
8. 前記規制制御部は、前記特定の信号処理部に振り分けられる前記或る宛先向けの発呼信号についての振分の規制開始から所定時間経過後において、前記特定の信号処理部での前記或る宛先向けの発呼信号の受付不可を示す情報の受信回数が所定範囲に達している場合に、前記或る宛先向けの発呼信号に対する規制率を厳格化する
   請求項５から７の何れか１項に記載の負荷分散装置。
9. 前記規制制御部は、前記特定の信号処理部に振り分けられる前記或る宛先向けの発呼信号についての振分の規制開始から所定時間経過後において、前記特定の信号処理部での前記或る宛先向けの発呼信号の受付不可を示す情報の受信回数が所定範囲に収まっている場
   合に、前記或る宛先向けの発呼信号に対する規制率を緩和する
   請求項５から８の何れか１項に記載の負荷分散装置。
10. 複数の信号処理部と、
    前記複数の信号処理部のいずれかへ発呼信号を振り分ける負荷分散装置とを含み、
    前記負荷分散装置は、
    或る宛先向けの発呼信号について、振分先の信号処理部での処理不可を示す情報の受信回数が所定範囲に達した場合に、前記或る宛先向けの発呼信号の振分先を、前記複数の信号処理部中の特定の信号処理部とする制御部を含む、
    負荷分散システム。
11. 負荷分散装置が、
    複数の信号処理部のいずれかへ発呼信号を振り分け、
    或る宛先向けの発呼信号について、振分先の信号処理部での処理不可を示す情報の受信回数が所定範囲に達した場合に、前記或る宛先向けの発呼信号の振分先を、前記複数の信号処理部中の特定の信号処理部とする
    ことを含む、負荷分散装置の信号振分方法。

Images