JP5820337B2 - 輻輳制御システム - Google Patents

Description

本発明は、災害等の発生により、電話網が輻輳した時に通信規制を行う輻輳制御システムに関する。

地震等の大規模災害の発生時には、被災地住民への安否確認等のための着信呼や、被災地住民同士の連絡や被災地から非被災地への安否連絡、救助要請のための発信呼が被災地の呼制御サーバに集中し、ネットワークが輻輳状態になることが考えられる。輻輳状態が悪化すると電話の発着信の通信サービスが利用できなくなり、安否や救助連絡等が行えずに被害が拡大するケースがある。そのため、現在のネットワークでは、呼制御サーバは、輻輳悪化を回避するために輻輳制御機能を備えている。

例えば、輻輳した呼制御サーバへの着信呼を制限するために、輻輳した呼制御サーバ以外の呼制御サーバが、輻輳した呼制御サーバへ向かう呼数密度を一定以下に抑えてから送信する呼数密度制御がある。この呼数密度制御を利用することで、輻輳した呼制御サーバへ届く呼数（着信呼）を抑えることが可能であり、輻輳の悪化を抑えることができる。

また、輻輳した呼制御サーバに送信される発信呼を制限するための輻輳制御方法としては、呼制御サーバの負荷状況を常に確認し、呼制御サーバのＣＰＵ利用率等によって、加入者優先度に応じた発信規制を行う方法がある。

例えば、ＩＰ（Internet Protocol）電話用制御サーバとして用いられるＳＩＰ（Session Initiation Protocol）サーバにおいて、加入者優先度を、最優先、優先、一般の三種類に分け、ＳＩＰサーバのＣＰＵ使用率に応じて、一次規制、二次規制、三次規制の三段階で発信規制を実行する（特許文献１参照）。例えば、図１５に示すように、ＣＰＵ使用率の所定値からの超過の度合とその超過した時間に基づき、一次規制では、一般加入者の一般呼（緊急呼は除く）の一部の発信を規制する。二次規制では、一般加入者の一般呼の発信はすべて規制し、かつ、緊急呼の一部を規制する。三次規制では、一般加入者の緊急呼も含んだすべての発信を規制する。このような加入者優先度による発信規制を実行することで、輻輳の悪化を抑えつつも優先加入者の通信の確保が可能となる。ただし、優先加入者（警察、消防、病院等）の通信を優先するため、二次規制以降では、優先度の低い一般加入者からのすべての発信は規制されてしまう。

また、一般的に加入者は通信不可に出会った場合、再発信（リダイヤル）を繰り返す。リダイヤル信号がすべて輻輳した呼制御サーバに届くと、その呼制御サーバの処理が大きく増え、輻輳の悪化が加速していくことが考えられる。リダイヤルによる輻輳の悪化を防ぐためにの方法としては、特許文献２に記載されたような、輻輳状態の時に、発信予約処理を実行することによって、端末からの無駄な再発信要求の繰り返しを防ぎ、輻輳した通信網に負荷をかけない方法等がある。

特開２０１１−２３９２１５号公報 特開２００１−２５１４２４号公報

しかしながら、現状の輻輳制御では、一般加入者の端末からのすべての発信呼に対して、発信不可のレスポンスを行うため、端末を通信不可にしたとしても、輻輳した呼制御サーバは、端末からの発信要求に対して接続不可応答を送信する処理を繰り返している。さらに、通信が繋がらない場合、利用ユーザの端末によって繰り返し行われるリダイヤル信号がすべて輻輳した呼制御サーバに届くため、通信網に対する無駄な負荷が多くかかり、輻輳状態を悪化させる一因となっている。

これに対し、特許文献２に記載の技術は、端末からの輻輳時のリダイヤルを抑止する技術ではあるが、端末側に複雑な発信予約制御機能を具備させる必要がある。また、機能を具備していない端末からのリダイヤルを抑止することはできない。さらに、端末が発信予約をする際や発信予約確認をする際に、ユーザインタフェース機能も必要となる。

また、従来の着信側の輻輳制御では、呼数密度制御等の規制により輻輳した呼制御サーバの処理を抑えることはできるが、着信制御は輻輳した呼制御サーバの網内のみで行われている。しかしながら、通信キャリアや網の種類の多様化により、他網からの着信呼が輻輳した呼制御サーバに与える影響も大きくなり、他網からの着信が輻輳の悪化を招いていることも問題となっている。

一方、特許文献１に記載の加入者優先度による輻輳制御では、被災地住民であり優先度の低いユーザは、輻輳時にまったく通信が行えなくなる場合が発生する。そのため、大規模災害等の緊急時には、多くのユーザが連絡をとることができずに、安否情報等を外部に知らせることが難しいという問題がある。

さらに、従来の輻輳制御解除のタイミングは、呼制御サーバのＣＰＵ使用率を検知して輻輳状態か否かを判定し決定していることが多く、通信規制によりＣＰＵ使用率が一次的に下がったとしても、実際にどの程度の量の呼が輻輳した呼制御サーバに向かっているかを考慮しないため、輻輳制御解除後に再び輻輳状態になるケースもある。そのため、輻輳解除後の再輻輳の可能性を低減することも問題となる。

このような背景に鑑みて本発明がなされたのであり、本発明は、災害発生時において、呼制御サーバへの発信要求の増大による輻輳状態の悪化を抑制することができる、輻輳制御システムを提供することを課題とする。

前記した課題を解決するため、請求項１に記載の発明は、災害発生時に呼制御サーバに発生した輻輳状態を解消するための制御を行う輻輳制御システムであって、前記輻輳制御システムが、端末装置を収容し呼接続処理を実行する複数の前記呼制御サーバと、他の通信網との接続を行う他網接続ゲートウェイと、前記呼制御サーバおよび前記他網接続ゲートウェイから呼処理の状態を示す状態情報を収集する網状態検知サーバと、前記呼制御サーバおよび前記他網接続ゲートウェイに対し輻輳制御を指示する配信サーバとから構成され、前記呼制御サーバが、自身の呼処理の状態を検知し、輻輳状態であると判定した場合に、輻輳発生通知を前記網状態検知サーバに送信する状態検知部と、前記輻輳状態であるときに、前記端末装置からルーティングサーバを介して発信要求を受信した場合に、前記端末装置に対し、前記発信要求を発信不可にすることを指示する発信不可信号を送信する発信不可信号通知部と、前記発信要求を受信したことを示す発信要求通知を前記配信サーバに送信する発信要求通知部と、前記配信サーバから、前記輻輳状態のときでも前記発信要求を発信可とすることを示す優先度変更情報を受信した場合に、その優先度変更情報に示される前記端末装置からの前記発信要求を優先呼と判定し呼接続処理を実行させる優先呼判定部と、を備え、前記網状態検知サーバが、前記輻輳発生通知を受信すると、前記呼制御サーバおよび前記他網接続ゲートウェイから前記状態情報を取得して集約し、網状態情報として前記配信サーバに送信する状態情報収集部を備え、前記配信サーバが、前記発信要求通知を受信すると、前記網状態情報に基づき、前記端末装置が前記発信要求を発信可能とする時間帯である発信可能時間帯を含む発信可能条件情報を生成する発信可能条件情報生成部と、前記発信可能時間帯の開始時刻のときに、前記呼制御サーバに前記優先度変更情報を送信する優先度変更情報送信部と、前記発信可能時間帯の開始時刻のときに、前記端末装置に、前記発信要求を発信可能にすることを指示する発信可信号を送信する発信可信号送信部と、を備え、前記端末装置が、前記発信要求を送信する発信要求部と、前記発信不可信号を受信した場合に前記発信要求部からの前記発信要求を発信不可に設定し、前記発信可信号を受信した場合に前記発信要求部からの前記発信要求を発信可能に設定する発信可／不可設定部と、を備えることを特徴とする輻輳制御システムとした。

このようにすることで、端末装置から輻輳時に発信要求を送信することができなくなる。よって、輻輳状態にある呼制御サーバがリダイヤル等による多数の発信要求を処理する必要がなくなるため、輻輳状態の悪化を抑制することができる。
また、発信要求を行った端末装置ごとに通話可能時間帯を設定することで、端末装置ごとに均等に通信権限を付与することができ、輻輳時の安定的な通信の提供が可能となる。

請求項２に記載の発明は、前記輻輳制御システムにおいて、前記端末装置が、前記発信可／不可設定部を備えていない場合に、前記配信サーバが、前記端末装置からの発信要求に対して設定した前記発信可能時間帯以外の時間に、再度当該端末装置からの発信要求を受信したことを示す発信要求通知を受信した場合、当該発信要求を違反呼とみなし、前記ルーティングサーバに対し、当該端末装置からの発信要求の閉塞指示を送信する違反呼判定部をさらに備え、前記ルーティングサーバが、前記配信サーバから前記閉塞指示を受信すると、当該端末からの発信要求を閉塞する閉塞処理部を備えることを特徴とする請求項１に記載の輻輳制御システムとした。

このようにすることで、端末装置に発信可／不可制御部が備わっていない場合であっても、ルーティングサーバの閉塞処理部が、発信可能時間帯以外の時間に送信された発信要求を閉塞するため、輻輳状態にある呼制御サーバに当該発信要求を届かないようにすることができる。したがって、呼制御サーバの輻輳状態の悪化を防ぐことができる。

請求項３に記載の発明は、前記輻輳制御システムが、さらに、Ｗｅｂサーバまたはメールサーバを備え、前記配信サーバの発信可能条件情報生成部が、前記生成した発信可能条件情報を前記Ｗｅｂサーバまたは前記メールサーバに送信し、前記Ｗｅｂサーバにより前記発信可能条件情報を前記端末装置の利用者に閲覧させ、または、前記メールサーバにより前記発信可能条件情報を前記端末装置の利用者が設定したアドレスに送信させることを特徴とする請求項１または請求項２に記載の輻輳制御システムとした。

これにより、端末装置の利用ユーザは、その端末装置が発信可能な時間帯（発信可能時間帯）を知ることができ、不要なリダイヤルを行うことなく、確実に通信手段を確保することができる。

請求項４に記載の発明は、前記配信サーバの発信可能条件情報生成部が、前記発信可能条件情報を、前記網状態情報に基づき、前記他網接続ゲートウェイの網状態を示す情報を含めて生成することを特徴とする請求項３に記載の輻輳制御システムとした。

これにより、端末装置の利用ユーザは、他の通信網（インターネット、携帯電話、ＰＳＴＮ、ＩＰ電話等）の網状態を示す情報、例えば、通信量の増加度合等を把握することができる。よって、端末装置が発信不可の場合であっても、利用ユーザに、他の通信網による通信サービスの利用を促すことができ、自網の呼制御サーバの輻輳状態の悪化を防ぐことができる。

請求項５に記載の発明は、前記網状態検知サーバの前記状態情報収集部が、所定の時間間隔で前記呼制御サーバおよび前記他網接続ゲートウェイから前記状態情報を取得して、前記網状態情報として前記配信サーバに送信しており、前記配信サーバが、前記網状態情報に含まれる前記呼制御サーバの処理呼数と前記他網接続ゲートウェイの処理呼数とを合計した最大値が、前記輻輳状態にある呼制御サーバの処理呼数の限界数以下である場合に、輻輳状態が解消したと判定する輻輳解除処理部を、さらに備えることを特徴とする請求項１乃至請求項４のいずれか１項に記載の輻輳制御システムとした。

これにより、他の通信網から他網接続ゲートウェイを介して輻輳状態にある呼制御サーバへ向かう発信要求の呼数を考慮した上で、輻輳解除の判定を行うことができる。したがって、輻輳解除後の再輻輳のリスクを低減することができる。

本発明によれば、災害発生時において、呼制御サーバへの発信要求の増大による輻輳状態の悪化を抑制する、輻輳制御システムを提供することができる。

本実施形態に係る輻輳制御システム（第１例）の全体構成と、処理の概要を説明するための図である。 本実施形態に係る輻輳制御システム（第２例）の全体構成と、処理の概要を説明するための図である。 本実施形態に係る呼制御サーバの構成例を示す機能ブロック図である。 本実施形態に係る網状態検知サーバの構成例を示す機能ブロック図である。 本実施形態に係る他網接続ゲートウェイの構成例を示す機能ブロック図である。 本実施形態に係る配信サーバの構成例を示す機能ブロック図である。 本実施形態に係る発信可能時間帯設定部が行う発信可能時間帯設定処理の第１例を説明するための図である。 本実施形態に係る発信可能時間帯設定部が行う発信可能時間帯設定処理の第２例を説明するための図である。 本実施形態に係るルーティングサーバの構成例を示す機能ブロック図である。 本実施形態に係る端末の構成例を示す機能ブロック図である。 本実施形態に係る輻輳制御方法の処理の流れ（第１例）を示すシーケンス図である。 本実施形態に係る輻輳制御方法の処理の流れ（第２例）を示すシーケンス図である。 本実施形態に係る輻輳制御システムにおける配信サーバによる輻輳制御の解除処理を説明するための図である。 本実施形態に係る端末の処理の流れを示すフローチャートである。 従来の加入者優先度に基づく発信規制を説明するための図である。

次に、本発明を実施するための形態（以下、「本実施形態」という）における輻輳制御システム１等について説明する。

まず、本実施形態に係る輻輳制御システム１の概要について説明する。
図１および図２は、本実施形態に係る輻輳制御システム１の全体構成と、処理の概要を説明するための図である。図１は、端末（端末装置）６０が、後記する発信可／不可制御部６３を備えている場合の処理と全体構成を示す。また、図２は、端末（端末装置）６０が、発信可／不可制御部６３を備えていない場合の処理と全体構成を示す。

＜システム構成＞
本実施形態に係る輻輳制御システム１は、図１に示すように、通信網（電話網）を構築する複数の呼制御サーバ１０と、網状態検知サーバ２０と、他網接続ゲートウェイ３０と、配信サーバ４０と、ルーティングサーバ５０と、端末（端末装置）６０と、Ｗｅｂサーバ７０またはメールサーバ７５と、を含んで構成される。

呼制御サーバ１０は、通信を行う際の呼制御や、自身以外の呼制御サーバ１０が輻輳した場合に、接続する呼を制限する呼数密度制御を行う。また、呼制御サーバ１０は、自身が輻輳状態にある場合に、ルーティングサーバ５０を介して端末６０から発信要求を受信すると、その端末６０に対し、発信不可信号を送信する。なお、以下、呼制御サーバ１０が輻輳状態にあるときと、輻輳状態ではないときを区別する場合、輻輳した呼制御サーバ１０を呼制御サーバ１０ａと表記し、輻輳した呼制御サーバ１０ａ以外の他の呼制御サーバ１０を呼制御サーバ１０ｂと表記する。

他網接続ゲートウェイ３０は、インターネットや携帯電話、ＰＳＴＮ（Public Switched Telephone Networks）、ＩＰ電話等の他の通信網それぞれとの間での通信を接続する。また、呼制御サーバ１０が輻輳した場合に、他網接続ゲートウェイ３０は、輻輳した呼制御サーバ１０ａに向かう呼に対して呼数密度制御を行う。

網状態検知サーバ２０は、各呼制御サーバ１０の呼処理の状態（呼数密度等）を示す状態情報と、複数の他網接続ゲートウェイ３０それぞれから呼処理の状態を示す状態情報とを収集し、収集した状態情報を網状態情報として配信サーバ４０に送信する。

配信サーバ４０は、輻輳した呼制御サーバ１０ａ以外の各呼制御サーバ１０ｂおよび他網接続ゲートウェイ３０に対し、網状態情報に基づき計算した呼数密度に関する呼数密度制御指示情報を送信する。また、配信サーバ４０は、呼制御サーバ１０ａに対し発信要求を送信した端末６０について、その端末６０の発信要求機能（後記する「発信要求部６２」）を利用可能とする時間帯（後記する「発信可能時間帯」）と、他網の網状態を示す情報とを含む発信可能条件情報を生成し、Ｗｅｂサーバ７０やメールサーバ７５に送信する。

ルーティングサーバ５０は、端末６０からの発信要求を呼制御サーバ１０に送信する。また、このルーティングサーバ５０は、端末６０が発信可／不可制御部６３を備えていない場合（図２参照）に、輻輳制御（通信規制）中にその端末６０から発信要求を再度受信すると、次回以降の発信要求を閉塞する。

端末６０は、呼制御サーバ１０を介して通話を実行する電話機であり、本実施形態においては、輻輳した呼制御サーバ１０に収容されている端末６０とする。また、この端末６０は、発信要求を呼制御サーバ１０に向けて送信することができる状態、つまり、発信要求機能（「発信要求部６２」）を利用可能な状態（発信可）と、発信要求を呼制御サーバ１０に向けて送信することができない状態、つまり、発信要求機能（「発信要求部６２」）を利用できない状態（発信不可）と、のいずれかに自身の端末６０を設定する発信可／不可制御部６３を備える端末６０と、この発信可／不可制御部６３を備えていない端末６０の場合がある。

＜処理概要＞
次に、図１を参照して、端末６０が発信可／不可制御部６３を備える場合の輻輳制御システム１が行う処理の概要について説明する。なお、輻輳した呼制御サーバ１０ａに収容される端末６０を端末６０ａと表記し、さらに、発信可／不可制御部６３を備える端末６０ａを、端末６０ａ_１と表記して説明する。

まず、地震等の大規模災害の発生により、被災地に設置された呼制御サーバ１０に輻輳が発生したものとする。次に、輻輳が発生した呼制御サーバ１０ａは、網状態検知サーバ２０に輻輳が発生したことを示す輻輳発生通知を送信する。網状態検知サーバ２０は、輻輳が発生した呼制御サーバ１０ａから輻輳発生通知を受信したことを契機に、輻輳が発生した呼制御サーバ１０ａ以外の呼制御サーバ１０ｂから状態情報を取得し（ステップＳ１）、他網接続ゲートウェイ３０それぞれからも状態情報を取得する（ステップＳ２）。そして、網状態検知サーバ２０は、取得した状態情報を集約して網状態情報を生成し配信サーバ４０に送信する（ステップＳ３）。

配信サーバ４０は、網状態情報に基づき、輻輳制御（通信規制）するために必要な呼数密度を計算し、呼数密度制御指示情報を、輻輳した呼制御サーバ１０ａ以外の呼制御サーバ１０ｂと、各他網接続ゲートウェイ３０とに送信し（ステップＳ４）、輻輳制御システム１としての呼数密度制御による通信規制を実行する。

ここで、輻輳した呼制御サーバ１０ａが収容する端末６０ａ_１から、発信要求が送信されると（ステップＳ５）、輻輳状態である呼制御サーバ１０ａは、発信要求を受信したことを示す発信要求通知を配信サーバ４０に送信した上で（ステップＳ６）、発信不可信号をその端末６０ａ_１に送信する（ステップＳ７）。発信不可信号を受信した端末６０ａ_１は、発信可／不可制御部６３の機能により、ユーザが端末６０ａ_１を操作したとしても、発信要求を送信できない状態となる（発信不可）。

一方、発信要求通知を受信した配信サーバ４０は、網状態情報に基づき、発信要求を送信した端末６０ａ_１の発信可能時間帯を設定し、その設定した発信可能時間帯と他網の網状態を示す情報とを含めた発信可能条件情報を生成して、Ｗｅｂサーバ７０またはメールサーバ７５に送信する（ステップＳ８）。メールサーバ７５は、発信可能条件情報を受信すると、端末６０ａ_１のユーザが予め登録したアドレスにその発信可能条件情報を送信する。また、ユーザは、予め取得したＵＲＬ（Uniform Resource Locator）にアクセスすることにより、Ｗｅｂサーバ７０において、発信可能条件情報を閲覧しその情報を取得する（ステップＳ９）。

配信サーバ４０は、発信可能条件情報に示される発信可能時間帯の開始時刻になると、輻輳した呼制御サーバ１０に対し優先度変更信号を送信し、端末６０ａ_１に対し発信可信号を送信することにより（ステップＳ１０）、その端末６０ａ_１に対する通信規制を解除する。これにより、端末６０ａ_１は、発信要求を送信し、着信先との間で通話を実行することができる。

このようにすることで、端末６０ａ_１から輻輳時にリダイヤルを実行することができなくなり、輻輳した呼制御サーバ１０ａの輻輳状態が長期に継続する状況を防ぎ、速やかに輻輳を復旧することができる。
また、発信要求を行った端末６０ａ_１ごとに通話可能時間帯を設定することで、一般加入者の端末６０ａ_１に均等に通信権限を付与することができ、輻輳時の安定的な通信の提供が可能となる。

続いて、図２を参照して、端末６０ａが発信可／不可制御部６３を備えていない場合の輻輳制御システム１が行う処理の概要について説明する。
図１に示した構成と、図２に示した構成との違いは、端末６０が発信可／不可制御部６３を備えていないことと、ルーティングサーバ５０が、閉塞処理部５２を備えていることである。なお、輻輳した呼制御サーバ１０ａに収容される端末６０ａにおいて、発信可／不可制御部６３を備えていない端末６０ａを、端末６０ａ_２と表記して説明する。また、ステップＳ１〜Ｓ９の処理は、端末６０ａ_２が自身を発信不可に設定できないことを除き同じであるため説明を省略する。

図２に示すように、端末６０ａ_２は、ステップＳ７において、輻輳した呼制御サーバ１０ａから発信不可信号を受信するが、この端末６０ａ_２は、発信可／不可制御部６３を備えていないため、ユーザの操作により、再度発信要求が呼制御サーバ１０ａに送信される（ステップＳ１１）。呼制御サーバ１０ａは、発信要求を受信すると、配信サーバ４０に対し発信要求通知を送信する。配信サーバ４０は、発信可能条件情報において発信可能時間帯を設定済みの端末６０ａ_２を登録しており、登録済みの端末６０ａ_２の発信要求については、リダイヤルされた違反呼であるとして、呼制御サーバ１０ａに対して閉塞指示を送信する。閉塞指示を受信した呼制御サーバ１０ａは、その閉塞指示をルーティングサーバ５０に送信し、所定の時間その端末６０ａ_２からの発信要求を閉塞する処理を行う（ステップＳ１２）。

このようにすることで、輻輳した呼制御サーバ１０ａに収容される端末６０ａが発信可／不可制御部６３を備えていない端末６０ａ_２であっても、端末６０ａ_２からの発信要求がルーティングサーバ５０により閉塞される。よって、端末６０ａ_２からの発信要求が輻輳した呼制御サーバ１０ａには届かないため、輻輳した呼制御サーバ１０ａの輻輳状態の悪化を防ぐことができる。

次に、本実施形態に係る輻輳制御システム１を構成する各装置の具体的な構成について説明する。

≪呼制御サーバ≫
図３は、本実施形態に係る呼制御サーバ１０の構成例を示す機能ブロック図である。
呼制御サーバ１０は、通信を接続するための呼制御を行う。また、自身以外の呼制御サーバ１０が輻輳した場合に、接続する呼を制限する呼数密度制御を行う。そして、呼制御サーバ１０自身が輻輳状態にある場合に、輻輳した呼制御サーバ１０ａは、ルーティングサーバ５０を介して端末６０ａから発信要求を受信すると、その端末６０ａに対し、発信不可信号を送信する。
この呼制御サーバ１０は、制御部１１と、入出力部１２と、メモリ部１３と、記憶部１４とを備える。

制御部１１は、呼接続処理や、輻輳制御等の処理の全般を司り、呼接続処理部１１１と、状態検知部１１２と、呼数密度制御部１１３と、優先呼判定部１１４と、発信要求通知部１１５と、発信不可信号通知部１１６と、優先度変更部１１７と、閉塞要求部１１８と、閉塞解除部１１９とを含んで構成される。

呼接続処理部１１１は、端末６０ａからルーティングサーバ５０を介して発信要求を受信すると、他の呼制御サーバ１０ｂとの間で、呼接続のための制御を行う。

状態検知部１１２は、呼制御サーバ１０の呼処理の状態、例えば、ＣＰＵ使用率、処理呼数（トラヒックデータ）の情報等を監視し、所定の閾値を超えた場合に、輻輳状態になったと判定し、輻輳が発生したことを示す輻輳発生通知を、網状態検知サーバ２０に送信する。
また、状態検知部１１２は、網状態検知サーバ２０から、状態情報送信指示を受信したことを契機として、自身の呼制御サーバ１０ｂが呼数密度制御を行っている場合に、所定の時間間隔で、ＣＰＵ使用率や処理呼数（あふれ呼を含む）等の情報である状態情報を検知し、網状態検知サーバ２０に送信する。そして、状態検知部１１２は、配信サーバ４０から輻輳解除通知を受信すると、状態情報の送信を終了する。

呼数密度制御部１１３は、配信サーバ４０から呼数密度制御指示情報を受信すると、その呼数密度制御指示情報に付された呼数密度に基づき、呼数密度制御を実行する。

優先呼判定部１１４は、端末６０ａからルーティングサーバ５０を介して、発信要求を呼接続処理部１１１が受信すると、その発信要求に付された着信先の識別情報（電話番号等）を抽出し、その発信要求が、警察、消防等への緊急呼であるかを判定する。そして、優先呼判定部１１４は、緊急呼であると判定した場合、通信規制中であっても呼接続処理部１１１により呼処理を実行させる。
また、優先呼判定部１１４は、受信した発信要求が、配信サーバ４０から受信した優先度変更情報に基づき所定時間（変更時間）優先度が変更され、発信可となった端末６０ａからの発信要求であるか否かを判定する。そして、優先呼判定部１１４は、所定時間通信可となった端末６０ａからの発信要求である場合に、呼接続処理部１１１により、呼処理を実行させる。

発信要求通知部１１５は、端末６０ａからルーティングサーバ５０を介して、発信要求を呼接続処理部１１１が受信すると、発信要求を受信したことを示す発信要求通知を、その発信要求に付された端末６０ａの識別情報（電話番号等）とともに、配信サーバ４０に送信する。

発信不可信号通知部１１６は、状態検知部１１２が、自身の呼制御サーバ１０が輻輳状態になったと判定した後に、端末６０ａからルーティングサーバ５０を介して、発信要求を受信した場合に、その配信要求を送信した端末６０ａに対し、呼制御サーバ１０ａが輻輳状態であり通信規制しているため、発信不可であることを示す発信不可信号を通知する。

優先度変更部１１７は、発信不可とした端末６０ａについて、配信サーバ４０が設定した発信可能時間帯の開始時刻に、配信サーバ４０からその端末６０ａを発信可能であることを示す優先度変更情報を受信すると、その端末６０ａを、発信可とする。なお、優先度変更情報には、変更時間が付されており、優先度変更部１１７は、端末６０ａについて発信可に設定した後、この変更時間が終了すると、その端末６０ａを再び発信不可に設定する。
なお、この優先度変更部１１７は、例えば、記憶部１４内の後記する加入者情報１４０に記憶された端末６０ａの識別情報（電話番号等）に対応付けて、当該端末が発信可、発信不可のいずれに設定されるかを登録する。

閉塞要求部１１８は、配信サーバ４０から、発信可／不可制御部６３を備えていない端末６０ａ_２についての閉塞指示を受信した場合に、その端末６０ａ_２に接続されるルーティングサーバ５０に対し、その閉塞指示を送信し、発信要求を閉塞させる。

閉塞解除部１１９は、配信サーバ４０から、発信可／不可制御部６３を備えていない端末６０ａ_２についての閉塞解除指示を受信した場合に、その端末６０ａ_２に接続されるルーティングサーバ５０に対し、その閉塞解除指示を送信し、発信要求の閉塞を解除させる。

入出力部１２は、他の装置との間で情報の送受信を行うための通信インタフェースと、キーボード等の入力装置や、モニタ等の出力装置との間で情報の送受信を行うための入出力インタフェースとから構成される。

メモリ部１３は、ＲＡＭ（Random Access Memory）等の一次記憶装置からなり、制御部１１によるデータ処理に必要な情報を一次的に記憶する。

記憶部１４は、ハードディスクやフラッシュメモリ等の記憶装置からなり、加入者情報１４０等を記憶している。
この加入者情報１４０には、呼制御サーバ１０自身が収容する端末６０の識別情報が記憶され、その識別情報に対応付けて、輻輳時において、発信要求を呼接続処理するか否かの発信可、発信不可に関する情報が登録される。

なお、この呼制御サーバ１０をプログラム実行処理により実現する場合、記憶部１４には、呼制御サーバ１０の制御部１１の機能を実現するためのプログラムが格納される。そして、制御部１１は、記憶部１４に記憶されたプログラムを、不図示のＣＰＵ（Central Processing Unit）が、ＲＡＭ等に展開し実行することで実現される。

≪網状態検知サーバ≫
図４は、本実施形態に係る網状態検知サーバ２０の構成例を示す機能ブロック図である。なお、図４においては、制御部、入出力部、メモリ部、記憶部の図示を省略し、網状態検知サーバ２０の主要な機能を示す制御部内の状態情報収集部２１と輻輳解除指示部２２とを記載している。

状態情報収集部２１は、輻輳発生通知を輻輳が発生した呼制御サーバ１０ａから受信すると、輻輳が発生した呼制御サーバ１０ａ以外の呼制御サーバ１０ｂおよび他網接続ゲートウェイ３０に対し、状態情報送信指示を送信し、呼制御サーバ１０ｂ、他網接続ゲートウェイ３０それぞれから状態情報を取得する。そして、状態情報収集部２１は、その取得した状態情報を集約し網状態情報として配信サーバ４０に送信する。
そして、状態情報収集部２１は、輻輳発生通知を受信したことを契機として、呼制御サーバ１０ｂおよび他網接続ゲートウェイ３０から、所定の時間間隔で状態情報を収集し、網状態情報として配信サーバ４０に送信する。

輻輳解除指示部２２は、配信サーバ４０から輻輳解除通知を受信すると、網状態情報の配信サーバ４０への送信を終了する。そして、輻輳解除指示部２２は、他網接続ゲートウェイ３０に対して、呼数密度制御の終了と状態情報の網状態検知サーバ２０への送信の終了とを示す輻輳解除指示情報を送信する。

≪他網接続ゲートウェイ≫
図５は、本実施形態に係る他網接続ゲートウェイ３０の構成例を示す機能ブロック図である。なお、図５においては、制御部、入出力部、メモリ部、記憶部の図示を省略し、他網接続ゲートウェイ３０の主要な機能を示す制御部内の呼接続制御部３１と、網状態検知部３２と、呼数密度制御部３３とを記載している。

呼接続制御部３１は、他網から受信した発信要求を自網内のプロトコルに変換等することにより、他網からの呼を自網内に送信する処理を行う。

網状態検知部３２は、網状態検知サーバ２０から状態情報送信指示を受信すると、処理呼数（あふれ呼を含む）等の情報を収集し、状態情報として網状態検知サーバ２０に送信する。また、網状態検知部３２は、状態情報送信指示を受信した後において、所定の時間間隔で状態情報を収集し、網状態検知サーバ２０に送信する。
また、網状態検知部３２は、網状態検知サーバ２０から輻輳解除指示情報を受信すると、状態情報の送信を終了する。

呼数密度制御部３３は、配信サーバ４０から呼数密度制御指示情報を受信すると、その呼数密度制御指示情報に付された呼数密度に基づき、呼数密度制御を実行する。
また、呼数密度制御部３３は、網状態検知サーバ２０から輻輳解除指示情報を受信すると、呼数密度制御を終了する。

≪配信サーバ≫
図６は、本実施形態に係る配信サーバ４０の構成例を示す機能ブロック図である。
配信サーバ４０は、網状態情報に基づき、輻輳した呼制御サーバ１０ａ以外の各呼制御サーバ１０ｂおよび各他網接続ゲートウェイ３０に対し、呼数密度制御の実行を指示する呼数密度制御指示情報を送信する。
また、配信サーバ４０は、輻輳した呼制御サーバ１０ａに対し発信要求を送信した端末６０ａについて、その端末６０ａを発信可能とする時間帯（発信可能時間帯）と、他網の網状態を示す情報とを含む発信可能条件情報を生成し、Ｗｅｂサーバ７０やメールサーバ７５に送信する。そして、配信サーバ４０は、発信可能時間帯の開始時刻になると、その端末６０ａを発信可とすることを示す優先度変更情報を、発信可とする時間（変更時間）とともに、輻輳した呼制御サーバ１０ａに送信する。
さらに、配信サーバ４０は、網状態検知サーバ２０から所定の時間間隔で網状態情報を取得し、所定の条件を満たした場合に、輻輳した呼制御サーバ１０が輻輳状態でなくなったと判定し、輻輳解除通知を、輻輳した呼制御サーバ１０ａ、輻輳した呼制御サーバ１０ａ以外の呼制御サーバ１０ｂおよび網状態検知サーバ２０に送信する。
この配信サーバ４０は、制御部４１と、入出力部４２と、メモリ部４３と、記憶部４４とを備える。

制御部４１は、呼数密度制御指示情報の送信や、発信可能条件情報の生成等の処理の全般を司り、呼数密度計算部４１１と、発信可能条件情報生成部４１２と、優先度変更情報送信部４１４と、発信可信号送信部４１５と、違反呼判定部４１６と、輻輳解除処理部４１７とを含んで構成される。

呼数密度計算部４１１は、網状態情報を網状態検知サーバ２０から受信すると、その網状態情報に基づき、輻輳した呼制御サーバ１０ａ以外の呼制御サーバ１０ｂおよび他網接続ゲートウェイ３０が制御する呼数密度を計算し、呼数密度制御指示情報として、各呼制御サーバ１０ｂおよび他網接続ゲートウェイ３０に送信する。

呼数密度計算部４１１は、例えば、呼数密度制御指示を次のように決定する。
呼数密度計算部４１１は、網内の呼制御サーバ１０ｂから輻輳した呼制御サーバ１０ａへの着信呼数と、他網接続ゲートウェイ３０から輻輳した呼制御サーバ１０ａへの着信呼数との合計である全着信呼数を網状態情報に基づき計算し、輻輳した呼制御サーバ１０ａが呼損なく呼処理を行える着信呼の呼数密度の限界数を超えないように削減すべき着信呼数の割合を決定する。
具体的には、呼数密度計算部４１１は、輻輳した呼制御サーバ１０ａに対する全着信呼の呼数密度を「Ｃ」、その輻輳した呼制御サーバ１０ａの着信呼の呼数密度の限界数を「Ｐ」、ある他網接続ゲートウェイ３０からの呼数密度を「ｋ」とした場合、全着信呼数の呼数密度「Ｃ」を限界数「Ｐ」以下に制御する必要があるため、当該他網接続ゲートウェイ３０に対して呼数密度制御で指示する呼数密度は、ｋ*（Ｐ／Ｃ）となる。
このようにして、呼数密度計算部４１１は、輻輳した呼制御サーバ１０ａ以外の呼制御サーバ１０ｂおよび他網接続ゲートウェイ３０それぞれが制御する呼数密度を計算し、呼数密度制御指示情報として送信する。

発信可能条件情報生成部４１２は、発信可能時間帯設定部４１３を備え、発信可能時間帯設定部４１３が設定した端末６０ａが発信要求を発信可能な時間帯（発信可能時間帯）と、他網接続ゲートウェイ３０から取得した他網の網状態を示す情報とを含めた発信可能条件情報を生成し、Ｗｅｂサーバ７０またはメールサーバ７５に送信する。
また、発信可能条件情報生成部４１２は、生成した発信可能条件情報を、発信要求を送信した端末６０ａの識別情報（電話番号等）に対応付けて、記憶部４４の発信可能条件情報ＤＢ（DataBase）４４０に記憶する。

発信可能時間帯設定部４１３は、輻輳した呼制御サーバ１０ａから発信要求通知を受信し、発信要求を送信した各端末６０ａに対して発信可能時間帯を、例えば、以下のように設定する。

図７は、本実施形態に係る発信可能時間帯設定部４１３が行う発信可能時間帯設定処理の第１例を説明するための図である。
発信可能時間帯設定部４１３は、所定の時間間隔で設定された時間帯において発信可能な端末数の上限を、例えば、輻輳した呼制御サーバ１０ａの着信呼の呼数密度の限界数やＣＰＵ使用率等に基づき決定する。そして、発信可能時間帯設定部４１３は、配信サーバ４０が発信要求通知を受信した先着順に、発信可能時間帯を割り当てる。

図７に示す例では、５分間隔ごとに、１０００個を上限として、先着順に発信要求通知を割り当てた例を示している。例えば、発信可能時間帯設定部４１３は、配信サーバ４０が１２３４番目に受信した発信要求通知を送信した端末６０ａについて、１５：０５〜１５：１０の間に発信可能時間帯を割り当てる。

図８は、本実施形態に係る発信可能時間帯設定部４１３が行う発信可能時間帯設定処理の第２例を説明するための図である。
発信可能時間帯設定部４１３は、発信要求通知に付された端末６０ａの識別情報（電話番号や契約番号等）の下一桁の値等に基づき通話可能時間帯を決定する。

図８に示す例では、５分間隔ごとに、電話番号の下一桁を振り分けて、受信した発信要求通知に付された端末６０ａの電話番号の下一桁に基づき通話可能時間帯を決定する。例えば、発信可能時間帯設定部４１３は、受信した発信要求通知に付された端末６０ａの電話番号が「03-1111-1114」であった場合は、１５：１５〜１５：２０の間に発信可能時間帯を割り当てる。

また、発信可能条件情報生成部４１２は、他網の網状態を示す情報として、以下の情報を含めた発信可能条件情報を生成する。
例えば、発信可能条件情報生成部４１２は、他網接続ゲートウェイ３０から輻輳した呼制御サーバ１０ａに向けての平常時の呼量（トラヒック）の平均値等を予めまたは状態情報とともに取得し、その平常時の呼量の平均値と、輻輳発生後に他網から輻輳した呼制御サーバ１０ａに向けて発信要求がなされた呼量との割合（通信量の増加度合）を、他網接続ゲートウェイ３０それぞれについて計算する。そして、発信可能条件情報生成部４１２は、他網接続ゲートウェイ３０それぞれの呼量の割合（増加度合）を他網の網状態を示す情報とする。この他網の網状態を示す情報をユーザに提供することにより、着信先への接続の可能性が高い他の通信手段をユーザが選択することができる。

図６に戻り、優先度変更情報送信部４１４は、発信要求を送信した端末６０ａについて、配信サーバ４０の発信可能時間帯設定部４１３が設定した発信可能時間帯の開始時刻になった時に、その端末６０ａを発信可とすることを示す優先度変更情報を、輻輳した呼制御サーバ１０ａに対し、その発信可とする所定の時間（変更時間）を付して送信する。

発信可信号送信部４１５は、発信要求を送信した端末６０ａについて、配信サーバ４０の発信可能時間帯設定部４１３が設定した発信可能時間帯の開始時刻になった時に、その端末６０ａに対し、発信可信号を送信する。なお、発信可／不可制御部６３を備える端末６０ａ_１は、発信可／不可制御部６３の制御により発信不可となっていた場合、この発信可信号を受信することにより、発信要求機能（端末６０ａ_１の「発信要求部６２」）を利用可能な状態（発信可）とすることにより、発信要求を送信することが可能となる。

違反呼判定部４１６は、入出力部４２を介して、発信要求通知を受信すると、その発信要求通知に付された識別情報（電話番号等）に基づき、記憶部４４内の発信可能条件情報ＤＢ４４０を検索する。違反呼判定部４１６は、その識別情報が発信可能条件情報ＤＢ４４０に記憶されており、その発信可能条件で設定された発信可能時間帯以外であった場合に、その発信要求を違反呼と判定する。そして、違反呼判定部４１６は、その発信要求（違反呼）を送信した端末６０ａを閉塞するため、輻輳した呼制御サーバ１０ａに対し閉塞指示を送信する。

輻輳解除処理部４１７は、網状態検知サーバ２０から所定の時間間隔で受信する網状態情報等に基づき、輻輳した呼制御サーバ１０ａに対する輻輳制御（通信規制）を解除すべきか否かを判定する。そして、輻輳解除処理部４１７は、輻輳制御（通信規制）を解除すべきと判定すると、輻輳解除通知を、輻輳した呼制御サーバ１０ａ、輻輳した呼制御サーバ１０ａ以外の呼制御サーバ１０ｂおよび他網接続ゲートウェイ３０に対して送信する。
また、輻輳解除処理部４１７は、輻輳制御（通信規制）を解除すべきと判定した場合に、ルーティングサーバ５０を介して、端末６０ａに向けて、発信可信号を送信する。

この輻輳解除処理部４１７は、例えば、以下の手法により輻輳制御（通信規制）を解除すべきと判定する。
輻輳解除処理部４１７は、網状態検知サーバ２０から所定の時間間隔で送信される網状態情報に基づき、輻輳した呼制御サーバ１０ａ以外の呼制御サーバ１０ｂおよび他網接続ゲートウェイ３０から輻輳した呼制御サーバ１０ａに向かう全着信呼数（あふれ呼を含む）を計算する。また、輻輳解除処理部４１７は、配信サーバ４０が受信する発信要求通知の受信数を計測する。さらに、輻輳解除処理部４１７は、輻輳した呼制御サーバ１０ａが収容する端末６０ａ_２と接続するルーティングサーバ５０から閉塞により通信規制した発信要求の呼数を取得する。輻輳解除処理部４１７は、これらの情報を統合して輻輳した呼制御サーバ１０ａの呼数密度の最大値を推定し、その値が当該呼制御サーバ１０ａの呼数密度の限界数以下になった場合に、輻輳制御（通信規制）を解除すべきと判定する。

入出力部４２は、他の装置との間で情報の送受信を行うための通信インタフェースと、キーボード等の入力装置や、モニタ等の出力装置との間で情報の送受信を行うための入出力インタフェースとから構成される。

メモリ部４３は、ＲＡＭ等の一次記憶装置からなり、制御部４１によるデータ処理に必要な情報を一次的に記憶している。

記憶部４４は、ハードディスクやフラッシュメモリ等の記憶装置からなり、前記した発信可能条件情報ＤＢ４４０や各呼制御サーバ１０が処理可能な呼数密度の限界数（不図示）等を記憶している。

なお、この配信サーバ４０をプログラム実行処理により実現する場合、記憶部４４には、配信サーバ４０の制御部４１の機能を実現するためのプログラムが格納される。そして、制御部４１は、記憶部４４に記憶されたプログラムを、不図示のＣＰＵが、ＲＡＭ等に展開し実行することで実現される。

また、この配信サーバ４０は、発信要求通知の受信、発信可能条件情報の生成や通知、優先度変更情報や発信可信号の送信等を行うため、輻輳時の負荷が大きくなることが考えられる。しかし、配信サーバ４０は、呼処理を行うわけではないため、実時間処理に対する要求は厳しくない。よって、配信サーバ４０が輻輳状態にならないように、端末６０ａからの発信要求をキュー蓄積し逐次処理を行ったり、複数台での分散処理を行ったりすること等により、配信サーバ４０が輻輳状態にならないように回避することができる。

≪ルーティングサーバ≫
図９は、本実施形態に係るルーティングサーバ５０の構成例を示す機能ブロック図である。図９においては、制御部、入出力部、メモリ部、記憶部の図示を省略し、ルーティングサーバ５０の主要な機能を示す制御部内のルーティング処理部５１と閉塞処理部５２とを記載している。

ルーティング処理部５１は、自身と接続する端末６０から、発信要求等の情報を受信すると、端末６０を収容する呼制御サーバ１０にその情報を出力する。また、ルーティング処理部５１は、呼制御サーバ１０から受信した情報を、端末６０に送信する。

閉塞処理部５２は、輻輳した呼制御サーバ１０ａから閉塞指示を受信した場合に、その閉塞指示に含まれる端末６０ａの識別情報に基づき、その端末６０ａからの発信要求を閉塞する。なお、この閉塞処理部５２による閉塞は、配信サーバ４０から閉塞解除指示を受信するまでの所定時間続けられる。
また、閉塞処理部５２は、配信サーバ４０から発信可信号を受信した場合に、その発信可信号を端末６０ａに送信する。このとき、閉塞処理部５２が、発信可／不可制御部６３を備えない端末６０ａ_２からの発信要求を閉塞しているときには、その閉塞を解除する。
なお、このルーティングサーバ５０は、例えば、ルータに閉塞処理部５２の機能を備えた装置として実現される。

≪端末≫
図１０は、本実施形態に係る端末（端末装置）６０の構成例を示す機能ブロック図である。図１０においては、制御部、入出力部、メモリ部、記憶部の図示を省略し、端末６０の主要な機能を示す制御部内の発着信制御部６１と発信要求部６２と発信可／不可制御部６３と緊急呼判定部６４とを記載している。なお、この端末６０は、例えば、電話機である。

発着信制御部６１は、発信要求部６２を備え、着信先の端末６０との間での通信を制御する。発信要求部６２は、不図示の入出力部を介して入力された着信先となる端末６０の識別情報（電話番号）と端末６０自身の識別情報（電話番号）とを付した発信要求等の情報を、ルーティングサーバ５０を介して呼制御サーバ１０に送信する。

発信可／不可制御部６３は、輻輳した呼制御サーバ１０から発信不可信号を受信すると、入出力部を介して着信先の識別情報（電話番号）が入力された場合であっても、発信要求部６２の利用を不可とすることにより、端末６０ａ_１を発信不可の状態にする。
また、発信可／不可制御部６３は、ルーティングサーバ５０を介して配信サーバ４０から発信可信号を受信すると、発信不可の状態を解除、つまり、発信要求部６２を利用可能とし、端末６０ａ_１を発信可の状態にする。

緊急呼判定部６４は、入出力部を介して入力された着信先の識別情報（電話番号）が、警察、消防等への緊急呼であるかを判定する。そして、緊急呼判定部６４は、緊急呼であると判定した場合、発信可／不可制御部６３により発信要求を送信できない発信不可の状態であっても、発着信制御部６１（発信要求部６２）により、発信要求の送信を実行させる。

≪Ｗｅｂサーバ≫
≪メールサーバ≫
本実施形態に係る輻輳制御システム１において、配信サーバ４０が生成した発信可能条件情報をユーザに通知する手段として、Ｗｅｂサーバ７０またはメールサーバ７５を用いる。端末６０ａのユーザは、予め緊急時の発信可能条件情報を閲覧するＷｅｂサイトのＵＲＬが通知されているか、メールアドレスを登録しているものとし、ユーザへの発信可能条件情報の通知を、Ｗｅｂサイトや電子メールを介して行う。このようにすることにより、端末６０ａにユーザインタフェース機能を必ずしも備える必要をなくし、発信可能条件情報の確認手段をユーザが選択できるものとする。

＜輻輳制御方法＞
次に、本実施形態に係る輻輳制御システム１における、輻輳制御方法の処理の流れについて説明する。
図１１は、本実施形態に係る輻輳制御方法の処理の流れ（第１例）を示すシーケンス図である。ここでは、輻輳した呼制御サーバ１０ａに収容される端末６０ａが、発信可／不可制御部６３を備える端末６０ａ_１の場合の処理について説明する。

まず、地震等の大規模災害の発生により、被災地に設置された呼制御サーバ１０の状態検知部１１２（図３参照）が、ＣＰＵ使用率等に基づき、輻輳が発生したことを検知する。そして、輻輳が発生した呼制御サーバ１０ａの状態検知部１１２が、輻輳が発生したことを示す輻輳発生通知を、網状態検知サーバ２０に送信する（ステップＳ２０）。

次に、網状態検知サーバ２０は、輻輳発生通知を受信すると、状態情報収集部２１（図４参照）が、輻輳した呼制御サーバ１０ａ以外の呼制御サーバ１０ｂおよび他網接続ゲートウェイ３０に対して、状態情報送信指示を送信する（ステップＳ２１，Ｓ２２）。

状態情報送信指示を受信した呼制御サーバ１０ｂは、状態検知部１１２が取得した処理呼数（あふれ呼を含む）等の状態情報を、網状態検知サーバ２０の送信する（ステップＳ２３）。また、状態情報送信指示を受信した他網接続ゲートウェイ３０は、網状態検知部３２（図５参照）が取得した処理呼数（あふれ呼を含む）等の状態情報を、網状態検知サーバ２０に送信する（ステップＳ２４）。

続いて、輻輳した呼制御サーバ１０ａ以外の呼制御サーバ１０ｂおよび他網接続ゲートウェイ３０から状態情報を取得した網状態検知サーバ２０の状態情報収集部２１（図４参照）は、取得した状態情報を集約して網状態情報を生成し、配信サーバ４０に送信する（ステップＳ２５）。

配信サーバ４０の呼数密度計算部４１１（図６参照）は、網状態情報を受信すると、輻輳した呼制御サーバ１０ａ以外の呼制御サーバ１０ｂおよび他網接続ゲートウェイ３０が制御する呼数密度を計算し（ステップＳ２６）、呼数密度制御指示情報として、呼制御サーバ１０ｂおよび他網接続ゲートウェイ３０に送信する（ステップＳ２７，Ｓ２８）。そして、輻輳した呼制御サーバ１０ａ以外の呼制御サーバ１０ｂおよび他網接続ゲートウェイ３０において、呼数密度制御が実行される。

ここで、輻輳した呼制御サーバ１０ａに収容される端末６０ａで、かつ、発信可／不可制御部６３を備える端末６０ａ_１から発信要求がされると（ステップＳ３０）、ルーティングサーバ５０を介して、その発信要求を、輻輳した呼制御サーバ１０ａが受信する（ステップＳ３１）。

呼制御サーバ１０ａの発信要求通知部１１５（図３参照）は、端末６０ａから発信要求を受信したことを示す発信要求通知を、配信サーバ４０に送信する（ステップＳ３２）。また、呼制御サーバ１０ａの発信不可信号通知部１１６（図３参照）は、呼制御サーバ１０ａが輻輳状態であることから、端末６０ａ_１に対し、発信不可信号を送信する（ステップＳ３３，Ｓ３４）。端末６０ａ_１は、発信不可信号を受信すると、発信可／不可制御部６３（図１０参照）が、端末６０ａ_１自身を、発信要求を送信することができない発信不可の状態に設定する。

一方、発信要求通知を受信した配信サーバ４０は、発信可能条件情報生成部４１２（図６参照）が、端末６０ａ_１の発信可能時間帯と、他網の網状態を示す情報とを含めた発信可能条件情報を生成し（ステップＳ３５）、生成した発信可能条件情報を、記憶部４４の発信可能条件情報ＤＢ４４０に記憶した上で、Ｗｅｂサーバ７０またはメールサーバ７５に送信する（ステップＳ３６）。そして、ユーザが予め通知されていたＷｅｂサイトのＵＲＬの情報を確認したり、発信可能条件情報をメールサーバ７５から送信されることにより（ステップＳ３７）、ユーザは、端末６０ａ_１での発信可能時間帯と他網の網状態を知ることができる。

次に、配信サーバ４０の優先度変更情報送信部４１４（図６参照）は、端末６０ａ_１に設定した発信可能時間帯の開始時刻になると、その端末６０ａ_１を発信可とすることを示す優先度変更情報を、輻輳した呼制御サーバ１０ａに対し、その発信可とする時間（変更時間）を付して送信する（ステップＳ４０）。
また、配信サーバ４０の発信可信号送信部４１５（図６参照）は、端末６０ａ_１に設定した発信可能時間帯の開始時刻になると、ルーティングサーバ５０を介して端末６０ａ_１に、発信可信号を送信する（ステップＳ４１，Ｓ４２）。端末６０ａ_１は、発信可信号を受信すると、発信可／不可制御部６３（図１０参照）が、端末６０ａ_１自身を、発信要求を送信することができる発信可の状態に設定する。

そして、発信可能時間帯に、その端末６０ａ_１が発信要求を送信すると（ステップＳ４３，Ｓ４４）、呼制御サーバ１０ａの優先呼判定部１１４（図３参照）が、その端末６０ａ_１からの発信要求を優先して接続すべきであると判定し、呼接続を実行する旨を示す制御信号（ＯＫ）を、その端末６０ａ_１に送信する（ステップＳ４５，Ｓ４６）。これにより、端末６０ａ_１と着信先との間での通話が行われる（ステップＳ４７）。

なお、呼制御サーバ１０ａは、配信サーバ４０から受信した優先度変更情報に付された変更時間が終了すると、その端末６０ａ_１からの発信要求を発信不可に変更する。これにより、発信可能時間帯の終了後に、その端末６０ａ_１から再度発信要求があった場合には、前記したステップＳ３０〜Ｓ３７の処理と同様に、端末６０ａ_１に対し、呼制御サーバ１０ａから発信不可信号が送信され、ユーザは、Ｗｅｂサーバ７０またはメールサーバ７５に基づき、発信可能条件情報を取得する。

図１２は、本実施形態に係る輻輳制御方法の処理の流れ（第２例）を示すシーケンス図である。ここでは、輻輳した呼制御サーバ１０ａに収容される端末６０が、発信可／不可制御部６３（図１０参照）を備えない端末６０ａ_２の場合の処理について説明する。なお、図１１に示した処理を同じ処理については、同一のステップ番号を付し、説明を省略する。また、図１２には示していないが、呼制御サーバ１０ａに輻輳が発生した以降の図１１のステップＳ２０〜Ｓ２８の処理はすでに実行され、呼制御サーバ１０および他網接続ゲートウェイ３０において輻輳制御が行われているものとする。

まず、端末６０ａ_２が発信要求を呼制御サーバ１０ａに送信すると、図１１のステップＳ３０〜Ｓ３７と同様の処理が行われ、端末６０ａ_２は、発信不可信号を受信する（ステップＳ３４）。しかし、端末６０ａ_２は、発信可／不可制御部６３（図１０参照）を備えていないため、発信不可の設定とはならない。

この状態で、再び、端末６０ａ_２から発信要求が呼制御サーバ１０ａに向けて送信されると（ステップＳ５０，Ｓ５１）、呼制御サーバ１０ａの発信要求通知部１１５（図３参照）は、端末６０ａ_２から発信要求を受信したことを示す発信要求通知を、配信サーバ４０に送信する（ステップＳ５２）。

配信サーバ４０の違反呼判定部４１６（図６参照）は、発信要求通知を受信すると、その発信要求通知に付された識別情報（電話番号等）に基づき、発信可能条件情報ＤＢ４４０を検索し、その識別情報（電話番号等）が発信可能条件情報ＤＢ４４０に記憶されており、設定された発信可能時間帯以外であった場合に、その発信要求を違反呼と判定する（ステップＳ５３）。
そして、違反呼判定部４１６は、呼制御サーバ１０ａを介してルーティングサーバ５０に対し閉塞指示を送信する（ステップＳ５４，Ｓ５５）。閉塞指示を受信すると、ルーティングサーバ５０の閉塞処理部５２（図９参照）は、その閉塞指示に含まれる端末６０ａ_２の識別情報（電話番号等）に基づき、その端末６０ａ_２からの発信要求を閉塞する。

このルーティングサーバ５０が閉塞処理を実行している間に、端末６０ａ_２から発信要求が送信されても（ステップＳ５６）、ルーティングサーバ５０において、発信要求を閉塞しているため、その発信要求は、呼制御サーバ１０ａには送信されず、通信不可となる。

配信サーバ４０の閉塞処理部５２は、ルーティングサーバ５０に向けて、閉塞指示を送信してから、所定時間が経過すると、呼制御サーバ１０ａを介してルーティングサーバ５０に対し閉塞解除指示を送信する（ステップＳ５７，Ｓ５８）。閉塞解除指示を受信したルーティングサーバ５０は、その端末６０ａ_２の閉塞を解除する。

なお、この状態で、端末６０ａ_２が発信要求を送信すると、前記したステップＳ３０〜Ｓ３７までの処理と同様のステップＳ６０〜Ｓ６７までの処理が行われ、配信サーバ４０により、再度、発信可能条件情報を生成等が行われる。

図１３は、本実施形態に係る輻輳制御システム１における配信サーバ４０による輻輳制御の解除処理を説明するための図である。
図１３において、図１１に示した処理を同じ処理については、同一のステップ番号を付し、説明を省略する。

呼制御サーバ１０ａに輻輳が発生すると、輻輳制御システム１は、図１１に示したステップＳ２０〜Ｓ２５と同様の処理を行い、網状態検知サーバ２０が、状態情報送信指示を送信することにより、呼制御サーバ１０ｂおよび他網接続ゲートウェイ３０から状態情報を取得し、網状態情報として配信サーバ４０に送信する。

輻輳した呼制御サーバ１０ａ以外の呼制御サーバ１０ｂおよび他網接続ゲートウェイ３０は、状態情報送信指示を受信すると、所定の時間間隔毎に、処理呼数（あふれ呼を含む）等の状態情報を網状態検知サーバ２０に送信する（ステップＳ７０，Ｓ７１）。そして、網状態検知サーバ２０の状態情報収集部２１（図４参照）は、取得した状態情報を集約した網状態情報を所定の時間間隔で、配信サーバ４０に送信する（ステップＳ７２）。

配信サーバ４０の輻輳解除処理部４１７（図６参照）は、所定の時間間隔で網状態情報を取得すると、その網状態情報等に基づき、輻輳した呼制御サーバ１０ａに対する輻輳制御（通信規制）を解除すべきか否かを判定する。例えば、輻輳解除処理部４１７は、輻輳した呼制御サーバ１０ａの呼数密度の最大値を推定し、その値が当該呼制御サーバ１０ａの呼数密度の限界数以下になった場合に、輻輳制御（通信規制）を解除すべきと判定する（ステップＳ７３）。そして、輻輳解除処理部４１７は、輻輳した呼制御サーバ１０ａ、輻輳した呼制御サーバ１０ａ以外の呼制御サーバ１０ｂおよび網状態検知サーバ２０に対して輻輳解除通知を送信する（ステップＳ７４，Ｓ７５，Ｓ７６）。

輻輳した呼制御サーバ１０ａは、輻輳解除通知を受信すると、自身が輻輳状態ではなくなったと判定し、それ以降に端末６０ａから発信要求を受信した場合、発信要求通知部１１５（図３参照）による配信サーバ４０への発信要求通知の送信を終了する。また、発信不可信号通知部１１６（図３参照）は、同じく端末６０ａから発信要求を受信した場合の配信不可信号の端末６０ａに向けての送信を終了する。
輻輳した呼制御サーバ１０ａ以外の呼制御サーバ１０ｂは、輻輳解除通知を受信すると、状態検知部１１２（図３参照）が、網状態検知サーバ２０に向けた所定の時間間隔での状態情報の送信を終了する。そして、呼制御サーバ１０ｂの呼数密度制御部１１３（図３参照）は、輻輳解除通知を受信すると、呼数密度制御を終了する。
網状態検知サーバ２０の状態情報収集部２１（図４参照）は、輻輳解除通知を受信すると、網状態情報の配信サーバ４０への送信を終了する。また、輻輳解除指示部２２（図４参照）は、配信サーバ４０から輻輳解除通知を受信すると、他網接続ゲートウェイ３０に対して、呼数密度制御の終了と状態情報の網状態検知サーバ２０への送信の終了とを示す輻輳解除指示情報を送信する（ステップＳ７７）。そして、輻輳解除指示情報を受信した他網接続ゲートウェイ３０は、呼数密度制御を終了し、状態情報の送信を終了する。

また、配信サーバ４０の輻輳解除処理部４１７（図６参照）は、輻輳制御（通信規制）を解除すべきと判定すると、ルーティングサーバ５０を介して端末６０ａに発信可信号を送信する（ステップＳ７８，Ｓ７９）。発信可信号を受信した、発信可／不可制御部６３（図１０参照）を備える端末６０ａ_１は、発信可／不可制御部６３の制御により、端末６０ａ_１自身を、発信要求を送信することができる発信可の状態に設定する。

＜発信可／不可制御部６３を備える端末の処理＞
次に、発信可／不可制御部６３（図１０参照）を備える端末６０ａ_１の処理の流れについて説明する。
図１４は、本実施形態に係る端末６０ａ_１の処理の流れを示すフローチャートである。

まず、発信要求に付される着信先の識別情報（電話番号等）が、入出力部（不図示）を介して端末６０ａ_１に入力される（ステップＳ１０１）。

次に、端末６０ａ_１の緊急呼判定部６４（図１０参照）は、入力された着信先の識別情報（電話番号等）が、警察、消防等への緊急呼であるかを判定する（ステップＳ１０２）。緊急呼であると判定された場合は（ステップＳ１０２→Ｙｅｓ）、発信要求部６２（図１０参照）の制御により、呼制御サーバ１０ａに向けて発信要求を送信し（ステップＳ１０７）、着信先との間で呼接続を行い通話が実行される（ステップＳ１０８）。一方、ステップＳ１０２において、緊急呼ではないと判定された場合は（ステップＳ１０２→Ｎｏ）、次のステップＳ１０３に進む。

ステップＳ１０３において、発信可／不可制御部６３は、端末６０ａ_１が発信可の状態であるか否かを判定する。ここで、端末６０ａ_１が発信不可の状態であれば（ステップＳ１０３→Ｎｏ）、処理を終了する。一方、端末６０ａ_１が発信可の状態であれば（ステップＳ１０３→Ｙｅｓ）、発信要求部６２の制御により、呼制御サーバ１０ａに向けて発信要求を送信する（ステップＳ１０４）。

次に、端末６０ａ_１は、発信要求に対して発信不可信号が返ってくるか否かを判定する（ステップＳ１０５）。ここで、発信不可信号が返ってきた場合（ステップＳ１０５→Ｙｅｓ）、発信可／不可制御部６３は、端末６０ａ_１の状態を発信不可に設定し（ステップＳ１０６）、処理を終える。一方、発信不可信号が返ってこなかった場合は（ステップＳ１０５→Ｎｏ）、着信先との間で呼接続を行い通話が実行され（ステップＳ１０８）、処理を終える。

以上説明したように、本実施形態に係る輻輳制御システム１および端末（端末装置）６０によれば、次に示す効果を得ることができる。

（１）輻輳制御システム１において、端末６０ａ（端末６０ａ_１）が発信可／不可制御部６３を備えることにより、発信要求部６２の利用を不可にし、端末６０ａ_１からの輻輳時のリダイヤルを実行できなくする。これにより、輻輳した呼制御サーバ１０ａの輻輳状態が長期に継続するのを防ぎ、速やかに輻輳を復旧することができる。
また、端末６０ａ（端末６０ａ_２）が発信可／不可制御部６３を備えない場合でも、ルーティングサーバ５０が閉塞処理部５２を備えることにより、輻輳時に端末６０ａ_２がリダイヤルしたときに、発信要求を輻輳した呼制御サーバ１０ａに届かないように閉塞することができる。よって、速やかに輻輳を復旧させることができる。

（２）呼数密度制御の適用範囲を他網（他網接続ゲートウェイ３０）まで広げることで、輻輳した呼制御サーバ１０ａに届く着信呼の数を減らすことができ、輻輳の悪化を抑えることができる。

（３）端末６０ａごとに通話可能時間帯を設定することで、輻輳時においても一般加入者の各端末６０ａに対して均等に通信の権限を付与することが可能となり、輻輳時の安定的な通信手段の提供が可能となる。

（４）通話可能時間帯の通知と同時に、他網の網状態を示す情報を提示することにより、端末６０ａの利用ユーザが、他の通信網（インターネット、携帯電話、ＰＳＴＮ、ＩＰ電話等）の利用状況（通信量の増加度合等）を把握することができる。よって、ユーザが利用する通信手段の分散が期待されるため、呼制御サーバ１０ａの輻輳の悪化を防ぐと同時に、端末６０ａの利用ユーザにとっては、輻輳した電話網が通信不可の場合でも、他の通信サービスを選択し利用できる可能性が向上する。

（５）本輻輳制御システム１において、発信可能条件情報を通知する手段として、Ｗｅｂサーバ７０、メールサーバ７５等の複数の手段を備えるものとすれば、各端末６０ａの利用ユーザが発信可能条件情報を受け取れなくなるリスクを低減することができる。

（６）配信サーバ４０が、自網内の呼制御サーバ１０ｂから輻輳した呼制御サーバ１０ａへの着信呼数と、他網接続ゲートウェイ３０を介する他網からの輻輳した呼制御サーバ１０ａへの着信呼数とを、呼数密度制御によるあふれ呼も含めて把握し、輻輳解除の判定を行うことによって、輻輳解除後の再輻輳のリスクを低減することができる。

１ 輻輳制御システム
１０ 呼制御サーバ
１１，４１ 制御部
１２，４２ 入出力部
１３，４３ メモリ部
１４，４４ 記憶部
２０ 網状態検知サーバ
２１ 状態情報収集部
２２ 輻輳解除指示部
３０ 他網接続ゲートウェイ
３１ 呼接続制御部
３２ 網状態検知部
３３ 呼数密度制御部
４０ 配信サーバ
５０ ルーティングサーバ
５１ ルーティング処理部
５２ 閉塞処理部
６０ 端末（端末装置）
６１ 発着信制御部
６２ 発信要求部
６３ 発信可／不可制御部
６４ 緊急呼判定部
７０ Ｗｅｂサーバ
７５ メールサーバ
１１１ 呼接続処理部
１１２ 状態検知部
１１３ 呼数密度制御部
１１４ 優先呼判定部
１１５ 発信要求通知部
１１６ 発信不可信号通知部
１１７ 優先度変更部
１１８ 閉塞要求部
１１９ 閉塞解除部
１４０ 加入者情報
４１１ 呼数密度計算部
４１２ 発信可能条件情報生成部
４１３ 発信可能時間帯設定部
４１４ 優先度変更情報送信部
４１５ 発信可信号送信部
４１６ 違反呼判定部
４１７ 輻輳解除処理部
４４０ 発信可能条件情報ＤＢ

Claims (5)

1. 呼制御サーバに発生した輻輳状態を解消するための制御を行う輻輳制御システムであって、
   前記輻輳制御システムは、端末装置を収容し呼接続処理を実行する複数の前記呼制御サーバと、他の通信網との接続を行う他網接続ゲートウェイと、前記呼制御サーバおよび前記他網接続ゲートウェイから呼処理の状態を示す状態情報を収集する網状態検知サーバと、前記呼制御サーバおよび前記他網接続ゲートウェイに対し輻輳制御を指示する配信サーバとから構成され、
   前記呼制御サーバは、
   自身の呼処理の状態を検知し、輻輳状態であると判定した場合に、輻輳発生通知を前記網状態検知サーバに送信する状態検知部と、
   前記輻輳状態であるときに、前記端末装置からルーティングサーバを介して発信要求を受信した場合に、前記端末装置に対し、前記発信要求を発信不可にすることを指示する発信不可信号を送信する発信不可信号通知部と、
   前記発信要求を受信したことを示す発信要求通知を前記配信サーバに送信する発信要求通知部と、
   前記配信サーバから、前記輻輳状態のときでも前記発信要求を発信可とすることを示す優先度変更情報を受信した場合に、その優先度変更情報に示される前記端末装置からの前記発信要求を優先呼と判定し呼接続処理を実行させる優先呼判定部と、を備え、
   前記網状態検知サーバは、
   前記輻輳発生通知を受信すると、前記呼制御サーバおよび前記他網接続ゲートウェイから前記状態情報を取得して集約し、網状態情報として前記配信サーバに送信する状態情報収集部を備え、
   前記配信サーバは、
   前記発信要求通知を受信すると、前記網状態情報に基づき、前記端末装置が前記発信要求を発信可能とする時間帯である発信可能時間帯を含む発信可能条件情報を生成する発信可能条件情報生成部と、
   前記発信可能時間帯の開始時刻のときに、前記呼制御サーバに前記優先度変更情報を送信する優先度変更情報送信部と、
   前記発信可能時間帯の開始時刻のときに、前記端末装置に、前記発信要求を発信可能にすることを指示する発信可信号を送信する発信可信号送信部と、を備え、
   前記端末装置は、
   前記発信要求を送信する発信要求部と、
   前記発信不可信号を受信した場合に前記発信要求部からの前記発信要求を発信不可に設定し、前記発信可信号を受信した場合に前記発信要求部からの前記発信要求を発信可能に設定する発信可／不可設定部と、を備える
   ことを特徴とする輻輳制御システム。
2. 前記輻輳制御システムにおいて、前記端末装置が、前記発信可／不可設定部を備えていない場合に、
   前記配信サーバは、
   前記端末装置からの発信要求に対して設定した前記発信可能時間帯以外の時間に、再度当該端末装置からの発信要求を受信したことを示す発信要求通知を受信した場合、当該発信要求を違反呼とみなし、前記ルーティングサーバに対し、当該端末装置からの発信要求の閉塞指示を送信する違反呼判定部をさらに備え、
   前記ルーティングサーバは、
   前記配信サーバから前記閉塞指示を受信すると、当該端末からの発信要求を閉塞する閉塞処理部を備えること
   を特徴とする請求項１に記載の輻輳制御システム。
3. 前記輻輳制御システムは、さらに、Ｗｅｂサーバまたはメールサーバを備え、
   前記配信サーバの発信可能条件情報生成部は、
   前記生成した発信可能条件情報を前記Ｗｅｂサーバまたは前記メールサーバに送信し、前記Ｗｅｂサーバにより前記発信可能条件情報を前記端末装置の利用者に閲覧させ、または、前記メールサーバにより前記発信可能条件情報を前記端末装置の利用者が設定したアドレスに送信させること
   を特徴とする請求項１または請求項２に記載の輻輳制御システム。
4. 前記配信サーバの発信可能条件情報生成部は、前記発信可能条件情報を、前記網状態情報に基づき、前記他網接続ゲートウェイの網状態を示す情報を含めて生成すること
   を特徴とする請求項３に記載の輻輳制御システム。
5. 前記網状態検知サーバの前記状態情報収集部は、所定の時間間隔で前記呼制御サーバおよび前記他網接続ゲートウェイから前記状態情報を取得して、前記網状態情報として前記配信サーバに送信しており、
   前記配信サーバは、前記網状態情報に含まれる前記呼制御サーバの処理呼数と前記他網接続ゲートウェイの処理呼数とを合計した最大値が、前記輻輳状態にある呼制御サーバの処理呼数の限界数以下である場合に、輻輳状態が解消したと判定する輻輳解除処理部を、さらに備えること
   を特徴とする請求項１乃至請求項４のいずれか１項に記載の輻輳制御システム。

Images