JP2015159517A - トラヒック制御装置、トラヒック制御方法、及びトラヒック制御プログラム - Google Patents

Abstract

【課題】負荷に応じてソフトスイッチのリソース量が動的に変化する通信ネットワークにおいて、輻輳の発生タイミングを適切に判断するとともに、利用可能なリソース量の変動に追従して適切な制御総量を決定し、さらに決定された制御総量を好適に配分する。【解決手段】トラヒック制御装置１は、リソース情報をリソース管理装置２から取得するリソース情報取得部１１と、対地別トラヒック情報を取得する対地別トラヒック情報取得部１２と、輻輳地域を特定し、取得したリソース情報と対地別トラヒック情報とを用いて、輻輳地域の制御総量を決定する制御総量決定部１３と、決定された制御総量を稼働中のセッション制御装置に配分してセッション制御装置４Ｓに発呼規制を指示する制御指示部１４と、を備え、制御総量決定部１３は、輻輳地域の端末への接続要求のみを行う前記セッション制御装置を決定し、決定された前記セッション制御装置に前記制御総量を配分する。【選択図】図１

Description

本発明は、網を介して通信サービスを提供するためのＣ−ｐｌａｎｅ（制御プレーン）における輻輳制御の技術に関する。

従来の輻輳制御の技術として、特許文献１には、公衆電話網において着信集中等により疎通が困難となった交換機や地域を対地とする発信呼の制御方法として、輻輳が発生している当該対地へ疎通させる総呼数（制御総量）を発信側の各交換機に配分した上で、各交換機で配分された値（制御量）を越える発信呼数分を接続しない規制遭遇の技術が開示されている。

また、特許文献２及び特許文献３には、ＩＰ（Internet Protocol）網を介して電話通信を行なうためのＩＰ電話システムにおいて、多数の呼の集中によりＣ−ｐｌａｎｅのソフトスイッチの機能停止の可能性を生じる輻輳が発生した場合、その検出方法として呼数を監視してそれが所定の呼数よりも多ければ輻輳であると判定する技術、及び、その制御方法として単位時間当たりの呼の接続許容数である呼数密度に基づいて呼の接続数を制御する技術が開示されている。なお、さらにＳＩＰ（Session Initiation Protocol）におけるＩＮＶＩＴＥ信号を呼数密度に基づいて制御する技術も開示されている。

また、特許文献４には、輻輳を検出した交換機が規制情報を共通線信号方式等の応答信号、切断信号等のバックワ−ド信号に相乗する等の方法で発側交換機に規制情報を通知し、発側交換機がこの規制情報の指示により規制制御を開始したのち、輻輳交換機は輻輳状況により規制量を変更し、または発側交換機で得られる情報に基づいて発側交換機が規制量を変更するというように、規制制御を発側と着側の両交換機のフィ−ドバック制御により自動的に行う技術が開示されている。

また、特許文献５には、中継網における対地間トラヒック量を測定し、測定結果が所要の接続品質目標を満たさない対地を検出した際に、当該対地に関連した発側通信装置を決定するトラヒック制御法の技術が開示されている。

一方、近年の仮想化技術の進歩などにより、セッション制御を行うソフトスイッチのリソースが動的に管理された通信ネットワーク（例えば、特許文献６参照）が普及しつつある。

セッション制御を行うソフトスイッチのリソースが動的に管理される新たな通信ネットワークにおいては、局所的なボトルネック箇所が論理的に存在しない。また、通信ネットワークにおいてセッション制御に使用される論理的なリソースの量がリアルタイムに変化していくことから、従来の輻輳制御における制御総量算出法を適用することはできない。その一方で、このような新たな通信ネットワークにおいても、輻輳制御の基本的考え方である“網リソースの最大活用”は不変的な要件と想定され、呼の疎通率の最大化を図ることが求められる。

しかしながら、負荷に応じてソフトスイッチのリソース量が動的に変化する新たな通信ネットワークにおいては、ソフトスイッチ単位で輻輳の発生を検知する従来技術では、輻輳の発生タイミングを適切に判断できない恐れがある。かかる事情に鑑み、非特許文献１には、利用可能なリソース量の変動に追従して適切な制御総量を決定する手法が開示されている。

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

高橋謙輔、他３名、「動的リソース管理されたＮＷにおける制御総量算出手法の一検討」、電子情報通信学会、２０１３年電子情報通信学会通信ソサイエティ大会 通信講演論文集２、平成２５年９月、ｐ．３９９

非特許文献１に記載の発明において、決定された制御総量を配分する際には、発信呼数の比率によって制御総量を各セッション制御装置に配分することが考えられている。しかし、かかる手法では、呼が全てのセッション制御装置に配分され、各セッション制御装置が輻輳輻輳地域の加入者端末への接続要求及びとそれ以外の接続要求を行うため、前周期の情報に基づいて前記制御総量を配分したとしても、各セッション制御装置へのトラヒック量が変化する可能性が高く、前記制御総量を好適に配分することができず、網リソースの最大活用を行うことができない恐れがある。

本発明は、前記の事情に鑑みてなされたものであり、負荷に応じてソフトスイッチのリソース量が動的に変化する通信ネットワークにおいて、輻輳の発生タイミングを適切に判断するとともに、利用可能なリソース量の変動に追従して適切な制御総量を決定し、さらに決定された制御総量を好適に配分することが可能なトラヒック制御装置、トラヒック制御方法、及びトラヒック制御プログラムを提供することを目的とする。

前記の目的を達成するために、本発明は、通信ネットワークに接続された端末に対して、各種通信サービスを提供するために必要なリソースである複数のコンピュータと、前記複数のコンピュータのそれぞれを、端末からの接続要求を受け付けて端末間の接続処理を行うセッション制御装置と、端末間の接続処理以外の処理を行う非セッション制御装置とのいずれかとして稼働させる、またはリソースプールに待機させることにより、サービス負荷の変動に応じてリソースを割り当てるリソース管理装置と、前記通信ネットワークの特定地域にて輻輳が発生したときに、前記セッション制御装置に対して、当該特定地域の端末への接続要求の受付数を制限する指示を送信するトラヒック制御装置とを備える通信制御システムの前記トラヒック制御装置であって、稼働している前記セッション制御装置の台数及び前記非セッション制御装置の台数を含むリソース情報を、前記リソース管理装置から取得するとともに、前記リソースプールのリソースが不足する状態になったときに輻輳制御処理を開始させるリソース情報取得部と、前記セッション制御装置の着信地域別の発信呼数及び着信呼数を集計した情報を含む対地別トラヒック情報を取得する対地別トラヒック情報取得部と、前記対地別トラヒック情報から直近の着信地域別の発信呼数が所定の基準を超えている輻輳地域を特定し、取得した前記リソース情報と取得した前記対地別トラヒック情報とを用いて、特定した前記輻輳地域の端末への接続要求の総受付数の上限となる制御総量を決定し、決定した前記制御総量を稼働中の前記セッション制御装置に配分して接続要求の受付数の上限となる発呼規制値を決定する制御総量決定部と、決定された前記発呼規制値を含む発呼規制指示情報を、前記セッション制御装置に送信する制御指示部と、を備え、前記制御総量決定部は、稼働中の前記セッション制御装置に割り当てられたリソース及び前記制御総量に基づいて、前記輻輳地域の端末への接続要求のみを行う前記セッション制御装置を決定し、決定された前記セッション制御装置に前記制御総量を配分するものとした。

こうすることにより、負荷に応じて動的にコンピュータリソースが割り当てられる通信制御システムによって運用される通信ネットワークにおいて輻輳が発生した場合に、リソースの利用状況に応じて最大の制御総量を確保することができ、輻輳地域への着信呼数を最大化することができる。また、輻輳制御においてリソースを動的管理して配分するとともに、輻輳制御を行うセッション制御装置を集約することができ、網リソースを好適に活用することができる。

また、本発明は、前記のトラヒック制御装置において、前記輻輳制御処理を開始した場合は、所定時間毎に、前記リソース情報取得部が直近の前記リソース情報を取得し、前記対地別トラヒック情報取得部が直近の前記対地別トラヒック情報を取得し、前記制御総量決定部は、取得した直近の前記リソース情報に含まれる前記稼働している前記セッション制御装置の台数に、装置１台当たりの最大処理可能呼数を乗じた値から、取得した直近の前記対地別トラヒック情報から得られる前記輻輳地域以外の端末間の総発着信呼数を減じた値を、前記制御総量として決定するものとした。

こうすることにより、輻輳地域の端末宛の接続要求の処理に対して利用可能な最大限のリソースが割り当てられるので、輻輳地域への着信呼数を最大化することができる。

また、本発明は、前記のトラヒック制御装置において、前記リソース情報取得部は、取得した前記リソース情報を記憶手段に記憶させ、前記輻輳制御処理の開始時には、前記制御総量決定部は、取得した前記対地別トラヒック情報から得られる前記輻輳地域への直近の着信呼数を前記制御総量として決定するとともに、その値を前記記憶手段に記憶させ、以降は所定時間毎に、前記リソース情報取得部が直近の前記リソース情報を取得し、前記制御総量決定部は、取得した直近の前記リソース情報に含まれる前記稼働している前記セッション制御装置の台数と、前記記憶手段に記憶しておいた前回のセッション制御装置の台数とから、前記セッション制御装置に割り当てられているリソースの割当率の増減率を示すリソース増減率を算出し、算出した前記リソース増減率の値に、前記記憶手段に記憶しておいた前回の制御総量の値を乗じた値を、今回の前記制御総量として決定するものとした。

こうすることにより、輻輳地域に対する初期の制御総量を、輻輳が発生する直前の当該地域宛への着信呼数に設定し、以降は実際のトラヒック変動への追従制御によるリソース割当率の増減に比例するように制御総量を変化させる。したがって、実トラヒックの変動への追従性が高く、かつリソース状態の変化に適合した制御が可能となる。

また、本発明は、前記のトラヒック制御装置において、前記リソース情報取得部は、前記リソース管理装置から前記リソース情報を取得できないと判定した場合に、前記対地別トラヒック情報取得部が、前記対地別トラヒック情報を取得し、前記制御総量決定部が、前記対地別トラヒック情報から直近の着信地域別の発信呼数が所定の基準を超えている輻輳地域を特定することで輻輳の発生の有無を検知する輻輳監視処理を開始させ、前記制御総量決定部は、前記輻輳監視処理によって輻輳の発生を検知した場合には、前記対地別トラヒック情報から得られる前記輻輳地域への直近の着信呼数を前記制御総量として決定するものとした。

こうすることにより、リソース管理装置によるリソース制御が適切に機能しなくなった場合においても、トラヒック制御装置が輻輳の発生を検知して輻輳が発生する直前の輻輳地域への着信呼数を確保する発呼規制を発動するので、その時点で稼働しているセッション制御装置のリソースを活用した輻輳制御を実現することができる。

また、本発明は、通信ネットワークに接続された端末に対して、各種通信サービスを提供するために必要なリソースである複数のコンピュータと、前記複数のコンピュータのそれぞれを、端末からの接続要求を受け付けて端末間の接続処理を行うセッション制御装置と、端末間の接続処理以外の処理を行う非セッション制御装置とのいずれかとして稼働させる、またはリソースプールに待機させることにより、サービス負荷の変動に応じてリソースを割り当てるリソース管理装置と、前記通信ネットワークの特定地域にて輻輳が発生したときに、前記セッション制御装置に対して、当該特定地域の端末への接続要求の受付数を制限する指示を送信するトラヒック制御装置とを備える通信制御システムの前記トラヒック制御装置のトラヒック制御方法であって、稼働している前記セッション制御装置の台数及び前記非セッション制御装置の台数を含むリソース情報を、前記リソース管理装置から取得するとともに、前記リソースプールのリソースが不足する状態になったときに輻
輳制御処理を開始させるステップと、前記セッション制御装置の着信地域別の発信呼数及び着信呼数を集計した情報を含む対地別トラヒック情報を取得するステップと、前記対地別トラヒック情報から直近の着信地域別の発信呼数が所定の基準を超えている輻輳地域を特定し、取得した前記リソース情報と取得した前記対地別トラヒック情報とを用いて、特定した前記輻輳地域の端末への接続要求の総受付数の上限となる制御総量を決定し、決定した前記制御総量を稼働中の前記セッション制御装置に配分して接続要求の受付数の上限となる発呼規制値を決定するステップと、決定された前記発呼規制値を含む発呼規制指示情報を、前記セッション制御装置に送信するステップと、を含み、決定した前記制御総量を稼働中の前記セッション制御措置に配分する際に、前記制御総量決定部は、稼働中の前記セッション制御装置に割り当てられたリソース及び前記制御総量に基づいて、前記輻輳地域の端末への接続要求のみを行う前記セッション制御装置を決定し、決定された前記セッション制御装置に前記制御総量を配分するものとした。

こうすることにより、負荷に応じて動的にコンピュータリソースが割り当てられる通信制御システムによって運用される通信ネットワークにおいて輻輳が発生した場合に、リソースの利用状況に応じて最大の制御総量を確保することができ、輻輳地域への着信呼数を最大化することができる。また、輻輳制御においてリソースを動的管理して配分するとともに、輻輳制御を行うセッション制御装置を集約することができ、網リソースを好適に活用することができる。

また、本発明のトラヒック制御プログラムは、コンピュータを前記のトラヒック制御装置として機能させるためのものとした。

こうすることにより、コンピュータを前記のトラヒック制御装置として機能させることができる。

本発明によれば、負荷に応じてソフトスイッチのリソース量が動的に変化する通信ネットワークにおいて、輻輳の発生タイミングを適切に判断するとともに、利用可能なリソース量の変動に追従して適切な制御総量を決定し、さらに決定された制御総量を好適に配分することが可能なトラヒック制御装置、トラヒック制御方法、及びトラヒック制御プログラムを提供することができる。

本発明の実施形態に係る通信制御システムの構成例を示す図である。 本発明の実施形態に係る通信制御システムを構成する各装置の構成例を示す図である。 リソース管理装置から取得されるリソース情報の構成及びデータ例である。 トラヒック監視装置から取得される対地別トラヒック情報の構成及びデータ例である。 リソース管理装置によって輻輳が検知されるまでのリソース情報の推移例である。 発呼規制を行うための第一の制御方法の処理を示すフローチャートである。 発呼規制前の通信制御システムを示す図である。 発呼規制後の通信制御システムを示す図である。 発呼規制を行うための第二の制御方法の処理を示すフローチャートである。 第二の制御方法による制御総量の推移例である。 発呼規制を行うための第三の制御方法の処理を示すフローチャートである。

以下、本発明を実施するための形態（以下、「実施形態」という。）を、適宜図面を参照して詳細に説明する。

図１は、本発明の実施形態に係る通信制御システムの構成例を示す図である。図１に示すように、ＩＰネットワーク８には、トラヒック制御装置１、リソース管理装置２、トラヒック監視装置３、リソースプール４０、セッション制御装置群４０Ｓ、非セッション制御装置群４０Ｎ、ロードバランサー５、及びロケーションサーバ６が配備されている。

リソース管理装置２は、ＩＰネットワーク８との接続インタフェースを備える複数の汎用コンピュータ４から構成されるリソースを管理し、それぞれの汎用コンピュータ４を、セッション制御装置４Ｓとして用いるか、非セッション制御装置４Ｎとして用いるか、予備リソースとしてリソースプール４０に留保しておくかを決定する。また、リソース管理装置２は、リソースプール４０の予備リソースが不足する場合（枯渇した場合または枯渇に近い状況が発生した場合）に、トラヒック制御装置１に対して輻輳の発生を通知する。

なお、それぞれの汎用コンピュータ４を、セッション制御装置４Ｓまたは非セッション制御装置４Ｎとして用いてもよいし、１台の汎用コンピュータ４のリソースをセッション制御装置４Ｓと非セッション制御装置４Ｎとに配分することにより両者を共存させるものとしてもよい。また、処理性能が異なる複数種類の汎用コンピュータ４によってリソースを構成してもよい。

ＩＰネットワーク８に接続されている加入者端末７からの接続要求（例えば、ＳＩＰのＩＮＶＩＴＥリクエスト）は、ロードバランサー５に送信され、ロードバランサー５は、当該接続要求を受け付けて、当該接続要求をセッション制御装置群４０Ｓに含まれているいずれかのセッション制御装置４Ｓに転送する。このとき、ロードバランサー５は、例えば、ラウンドロビン方式やハッシング方式などを用いることにより、すべてのセッション制御装置４ＳのＣＰＵ（Central Processing Unit）利用率が平準化されるように接続要求を振り分ける。

ロードバランサー５から転送された接続要求を受け付けたセッション制御装置４Ｓは、ロケーションサーバ６から着信先の加入者端末７のＩＰアドレスを取得して、発信元の加入者端末７と着信先の加入者端末７との間のセッションを確立する。

また、加入者端末７からの非セッション系のサービス要求（例えば、ＷＥＢサイトの閲覧要求）は、ロードバランサー５に送信され、ロードバランサー５は、当該サービス要求を受け付けて、当該サービス要求を非セッション制御装置群４０Ｎに含まれているいずれかの非セッション制御装置４Ｎに転送する。このとき、ロードバランサー５は、例えば、ラウンドロビン方式やハッシング方式などを用いることにより、非セッション制御装置４ＮのＣＰＵ利用率が平準化されるようにサービス要求を振り分ける。

ロードバランサー５から転送されたサービス要求を受け付けた非セッション制御装置４Ｎは、要求元の加入者端末７に対して要求された非セッション系のサービスを提供する。

トラヒック監視装置３は、それぞれのセッション制御装置４Ｓが処理した接続要求の数（発信呼数）及び接続数（着信呼数）を着信地域別にカウントすることにより、直近の発信呼数、着信呼数、及び最繁時の発信呼数を着信地域別に集計する。

また、制御センタ等に配備されるトラヒック制御装置１は、リソース管理装置２から輻輳の発生を通知されると、輻輳制御処理を開始し、輻輳地域への接続要求を受け付ける回数の上限となる制御総量（全セッション制御装置４Ｓが受け付ける接続要求数の合計値）を、そのときのリソースの利用状況及びトラヒック状況に応じて算出する。そして、トラヒック制御装置１は、その制御総量に基づいて各セッション制御装置４Ｓに接続要求の受付数の上限となる発呼規制値を含んで発呼規制を指示する制御指示情報（発呼規制指示情報）を生成し、その制御指示情報を各セッション制御装置４Ｓに送信する。この制御指示情報を受信したセッション制御装置４Ｓは、輻輳地域宛の接続数（着信呼数）が指示された発呼規制値以下となるように、発呼規制（規制遭遇）を行う。

また、トラヒック制御装置１は、発呼規制の発動中に輻輳地域宛の発信呼数が減少して、リソースプール４０の不足状況（枯渇または枯渇に近い状況）が解消した時点で、各セッション制御装置４Ｓに対して発呼規制の解除の指示情報を送信する。この指示情報を受信したセッション制御装置４Ｓは、輻輳地域宛の発呼規制を解除する。

次に、図１の通信制御システムを構成する主な装置の構成について図２を用いて説明する（適宜、図１参照）。ただし、図２には、各装置の主要な機能のみを記載し、データ入力のための入力手段、ネットワークを介してデータを送受信するための通信手段、メッセージ等を表示するための出力手段、及び各種情報を記憶するための記憶手段の記載を省略している。

図２は、本発明の実施形態に係る通信制御システムを構成する主な装置の構成例を示す図である。図２に示すように、トラヒック制御装置１は、リソース情報取得部１１、対地別トラヒック情報取得部１２、制御総量決定部１３、及び制御指示部１４を備える。これらは、トラヒック制御装置１が備える不図示のＣＰＵが、記憶手段に記憶された所定の制御プログラム（トラヒック制御プログラム）を実行することによって具現化される。

リソース情報取得部１１は、リソース管理装置２から、リソースの割当て状況を示すリソース情報（詳細は図３を用いて後記する。）を取得する。また、リソース情報取得部１１は、リソース管理装置２から輻輳の発生を通知された場合には、輻輳制御処理を開始させ、リソース管理装置２との交信が途絶えた場合は、輻輳監視処理を開始させる。対地別トラヒック情報取得部１２は、トラヒック監視装置３から着信地域別のトラヒック情報（以下、「対地別トラヒック情報」と呼ぶ。詳細は図４を用いて後記する。）を取得する。

制御総量決定部１３は、例えば、リソース管理装置２から輻輳の発生を通知されたとき、所定の算出方法にしたがって、セッション制御装置４Ｓ全体、つまりセッション制御装置群４０Ｓが受付可能な輻輳地域への制御総量を決定する。具体的な制御総量の算出方法については、図６〜図１０を用いて後記する。制御指示部１４は、制御総量決定部１３が決定した制御総量に基づいて、各セッション制御装置４Ｓに発呼規制値を含んで発呼規制を指示する制御指示情報（発呼規制指示情報）を送信し、また輻輳が解消したときには各セッション制御装置４Ｓに発呼規制の解除の指示情報を送信する。

リソース管理装置２は、リソース制御部２１、リソース監視部２２、及び輻輳検知部２３を備える。これらは、リソース管理装置２が備える不図示のＣＰＵが、記憶手段に記憶された所定の制御プログラムを実行することによって具現化される。

リソース制御部２１は、セッション制御装置群４０Ｓや非セッション制御装置群４０Ｎに割り当てたリソースが不足している場合は、リソースプール４０から待機中の汎用コンピュータ４を払い出して、セッション制御装置４Ｓや非セッション制御装置４Ｎとして稼働させる。他方、リソース制御部２１は、セッション制御装置群４０Ｓや非セッション制御装置群４０Ｎに割り当てたリソースが余剰となっている場合は、セッション制御装置４Ｓや非セッション制御装置４Ｎとして稼働しているコンピュータの稼働を停止し、それらをリソースプール４０に引き戻して待機させる。また、リソース制御部２１は、リソースの割当て状況を示すリソース情報（詳細は図３を用いて後記する。）を生成してトラヒック制御装置１に送信する。

リソース監視部２２は、セッション制御装置４Ｓ及び非セッション制御装置４Ｎとして稼働している各コンピュータのＣＰＵ利用率の情報を収集することにより、セッション制御装置群４０Ｓ及び非セッション制御装置群４０ＮのＣＰＵ利用率を算出する。また、輻輳検知部２３は、リソースプール４０のリソースの不足（枯渇または枯渇に近い状況の発生）を検知した場合に、トラヒック制御装置１に対して輻輳の発生を通知する（詳細は図５を用いて後記する）。

トラヒック監視装置３は、各セッション制御装置４Ｓから着信地域別の接続要求の数（発信呼数）及び接続数（着信呼数）を受信して対地別トラヒック情報（図４参照）を生成する対地別トラヒック情報集計部３１を備える。

セッション制御装置群４０Ｓを構成する各セッション制御装置４Ｓは、接続要求処理部４１、発呼規制部４２、ＣＰＵ利用率測定部４３、及び発着信呼数情報収集部４４を備える。これらは、セッション制御装置４Ｓが備える不図示のＣＰＵが、記憶手段に記憶された所定の制御プログラムを実行することによって具現化される。

接続要求処理部４１は、ロードバランサー５から転送される発信元の加入者端末７（図１参照）からの接続要求を受け付けて、その着信先として指定された加入者端末７と発信元の加入者端末７との間のセッションを確立する制御を行う。また、接続要求処理部４１は、発呼規制部４２から通知された発呼規制値を満たすように、加入者端末７から輻輳地域への接続要求を受け付けて接続処理を行う数を制限する。

発呼規制部４２は、トラヒック制御装置１から受信した制御指示情報（発呼規制指示情報）にしたがって、輻輳地域への接続要求を規制するための発呼規制値を、接続要求処理部４１に通知する。ＣＰＵ利用率測定部４３は、自装置のＣＰＵ利用率（処理負荷）を測定し、測定結果を記憶手段（不図示）に記憶するとともに、リソース管理装置２からの要求にしたがって、記憶したＣＰＵ利用率をリソース管理装置２に送信する。発着信呼数情報収集部４４は、着信地域別の接続要求の数（発信呼数）及び接続数（着信呼数）を測定し、測定結果を記憶手段（不図示）に記憶するとともに、トラヒック監視装置３からの要求にしたがって、記憶した着信地域別の発信呼数及び着信呼数をトラヒック監視装置３に送信する。

図３は、リソース管理装置２から取得されるリソース情報の構成及びデータ例である。図３に示すように、リソース情報９１は、セッション制御装置台数（以下、適宜「ＳＣ数」と略記する。）、セッション制御装置全体のＣＰＵ利用率（以下、適宜「ＳＣ利用率」と略記する。）、非セッション制御装置台数（以下、適宜「ＮＳＣ数」と略記する。）、非セッション制御装置全体のＣＰＵ利用率（以下、適宜「ＮＳＣ利用率」と略記する。）、及びプール台数から構成されている。図３のデータ例は、合計１０台の処理性能が等しい汎用コンピュータ４がリソースとして配備されており、そのうちの３台ずつがそれぞれセッション制御装置４Ｓ及び非セッション制御装置４Ｎとして稼働し、残る４台がリソースプール４０にプールされていること、並びに、セッション制御装置４Ｓ全体のＣＰＵ利用率が６５％で非セッション制御装置４Ｎ全体のＣＰＵ利用率が７５％であることを表している。なお、処理性能が異なる複数種類の汎用コンピュータ４によってリソースが構成される場合には、処理性能に応じた重みを乗じて換算された装置台数及びＣＰＵ利用率を用いて、これらの値が算出されるものとする。

図４は、トラヒック監視装置３から取得される対地別トラヒック情報の構成及びデータ例である。図４に示すように、対地別トラヒック情報９２は、着信地域、発信呼数、着信呼数、及び最繁時発信呼数からなるデータの組が、着信地域の数だけ繰り返されて構成されている。ここで、着信地域とは、対地別の発信規制を行うときの単位として通信事業者によって設定される地域である。発信呼数とは、当該地域の加入者宛に発信された直近の１分当たりの呼数である。着信呼数とは、そのうち実際に接続処理により着信した呼数である。最繁時発信呼数とは、当該地域の加入者宛に発信された平常時の最繁時間帯における１分当たりの呼数である。図４のデータ例は、地域Ａの加入者宛の直近の発信呼数が２５（呼／分）、着信呼数が２４（呼／分）、最繁時発信呼数が６０（呼／分）であり、地域Ｂの加入者宛の直近の発信呼数が４０（呼／分）、着信呼数が３８（呼／分）、最繁時発信呼数が９５（呼／分）であることを表している。

続いて、図１に示した通信制御システムにおいて輻輳が発生した場合の動作例について、図５〜図１０を用いて説明する。なお、ここでは、動作の説明を単純化するために、合計１０台の処理性能が等しい汎用コンピュータ４がリソースとして配備されており、初期状態ではそのうち３台ずつがそれぞれセッション制御装置４Ｓ及び非セッション制御装置４Ｎとして稼働しているものと仮定する。また、リソース管理装置２は、リソースプール４０に残っている最後の汎用コンピュータ４を払い出す直前で、リソース不足により輻輳の発生を検知するものとする。

図５は、時刻Ｔ１における初期状態から時刻Ｔ７においてリソース管理装置２が輻輳を検知するまでのリソース情報９１の推移を示した例である。なお、リソース管理装置２がセッション制御装置４Ｓまたは非セッション制御装置４Ｎを追加稼働させるためのＣＰＵ利用率の閾値は９０％であるものとする。したがって、リソース管理装置２は、図５中の太枠で囲まれたそれぞれの数値について、装置の追加稼働が必要であると判定する。

時刻Ｔ１では、初期の平常運転が行われており、ＳＣ数（セッション制御装置台数）が３台でＳＣ利用率（セッション制御装置全体のＣＰＵ利用率）が６５％、ＮＳＣ数（非セッション制御装置台数）が３台でＮＳＣ利用率（非セッション制御装置全体のＣＰＵ利用率）が７５％、プール台数が４台となっている。

時刻Ｔ２では、発呼量増加に伴ってＳＣ利用率が９０％に増加したため、リソース管理装置２は、セッション制御装置（ＳＣ）４Ｓの追加稼働が必要であると判定し、リソースプール４０から汎用コンピュータ４を１台払い出してＳＣ４Ｓとして稼働させる。それにより、次の時刻Ｔ３におけるＳＣ数は４台となり、プール台数は３台となる。

時刻Ｔ３では、非セッション系のサービス負荷の増加に伴ってＮＳＣ利用率が９０％に増加したため、リソース管理装置２は、非セッション制御装置（ＮＳＣ）４Ｎの追加稼働が必要であると判定し、リソースプール４０から汎用コンピュータ４を１台払い出してＮＳＣ４Ｎとして稼働させる。それにより、次の時刻Ｔ４におけるＮＳＣ数は４台となり、プール台数は２台となる。

時刻Ｔ４では、ＮＳＣ４Ｎの追加稼働に伴ってＮＳＣ利用率が６５％に減少し、ＳＣ数とＮＳＣ数とが共に４台、プール台数が２台で平常運転が行われている。

時刻Ｔ５では、発呼量の急増に伴ってＳＣ利用率が９５％に増加したため、リソース管理装置２は、ＳＣ４Ｓの追加稼働が必要であると判定する。このとき、ＮＳＣ利用率が６０％と低くなっていることから、リソース管理装置２は、ＮＳＣ４Ｎとして稼働している４台のうちの１台を転用してＳＣ４Ｓとして稼働させる。それにより、次の時刻Ｔ６におけるＳＣ数は５台となり、ＮＳＣ数は３台となる。

時刻Ｔ６では、ＮＳＣ４Ｎを転用してＳＣ４Ｓを追加稼働させたのにも関わらず、ＳＣ利用率が９５％と依然として高くなっているため、リソース管理装置２は、ＳＣ４Ｓの追加稼働が必要であると判定し、リソースプール４０から汎用コンピュータ４を１台払い出してＳＣ４Ｓとして稼働させる。それにより、次の時刻Ｔ７におけるＳＣ数は６台、ＮＳＣ数は３台となり、プール台数は１台となる。

時刻Ｔ７では、ＳＣ４Ｓを追加稼働させたのにも関わらず、ＳＣ利用率が９０％と依然として高くなっていることから、リソース管理装置２は、ＳＣ４Ｓの追加稼働が必要であると判定する。リソースプール４０から最後の１台を払い出してしまうとリソースプール４０のプール台数が０台となってリソースが枯渇するので、リソース管理装置２は、この時点で輻輳の発生を検知し、トラヒック制御装置１に対して輻輳が発生した旨を通知する。この場合、リソース管理装置２は、リソースプール４０から最後の１台を払い出す前に輻輳の発生を検知するので、実際には最後の１台の払い出しは行われない。

続いて、輻輳の発生の通知を受けたトラヒック制御装置１は、輻輳を解消するために輻輳地域への着信呼数を制限する発呼規制制御を行う。以下、輻輳を解消するための２つの制御方法について説明する。

＜第一の制御方法＞
図６は、発呼規制を行うための第一の制御方法の処理を示すフローチャートである。

トラヒック制御装置１のリソース情報取得部１１は、ステップＳ１０１にてリソース管理装置２から輻輳を検知した旨が通知されるのを待ち（ステップＳ１０１でＮｏ）、輻輳を検知した旨が通知されると（ステップＳ１０１でＹｅｓ）ステップＳ１０２に処理を進めて輻輳制御処理を開始させる。

ステップＳ１０２にて、対地別トラヒック情報取得部１２は、トラヒック監視装置３から対地別トラヒック情報９２（図４参照）を取得し、次のステップＳ１０３にて、制御総量決定部１３は、取得した対地別トラヒック情報９２に含まれる着信地域毎の直近の発信呼数と最繁時発信呼数とを所定の基準で比較することにより、輻輳地域を特定する。例えば、直近の発信呼数が最繁時発信呼数の２倍以上になっている地域を輻輳地域として抽出する。このとき通常は１つ以上の輻輳地域が抽出されるが、多数の着信地域で２倍未満のトラヒック増加があった場合には、１つも輻輳地域が抽出されないこともあり得る。その場合は、着信地域全体を輻輳地域として特定する。

次に、ステップＳ１０４にて、リソース情報取得部１１は、リソース管理装置２からリソース情報９１（図３参照）を取得し、次のステップＳ１０５にて、制御総量決定部１３は、（式１）により、取得したリソース情報９１に含まれるセッション制御装置台数と、ステップＳ１０２にて取得した対地別トラヒック情報９２とを用いて、制御総量の値を算出する。

制御総量＝セッション制御装置台数×最大処理可能呼数
−直近の輻輳地域以外の総発着信呼数 ・・・ （式１）

ここで、最大処理可能呼数とは、１台のセッション制御装置４Ｓが接続要求を処理可能な１分あたりの最大数であり、ステップＳ１０５では、輻輳地域以外の加入者間の接続要求を処理するためのリソースを除いた全てのリソースが輻輳地域の加入者宛の接続要求の処理に割り当てられるものとして、制御総量が算出される。

次に、ステップＳ１０６にて、制御総量決定部１３は、稼働中のセッション制御装置４Ｓに割り当てられたリソース及び制御総量に基づいて、輻輳地域の加入者端末７への接続要求のみを行うセッション制御装置４Ｓを決定し、決定されたセッション制御装置４Ｓに制御総量を配分することによって、それぞれのセッション制御装置４Ｓに指示する発呼規制値を決定する。

詳細には、制御総量決定部１３は、算出した制御総量を含む問い合わせ信号をリソース管理装置２へ送信する。
リソース管理装置２は、問い合わせ信号を受信すると、受信した問い合わせ信号に含まれる制御総量に合致するリソース（セッション制御装置４Ｓが発呼可能な最大値）を有するセッション制御装置４Ｓを選択し、選択されたセッション制御装置４Ｓ及び当該セッション制御装置４Ｓのリソースを回答信号として制御総量算出部１３へ送信する。
例えば、制御総量が１０００である場合には、リソース管理装置２は、複数のセッション制御装置４Ｓから、リソースの合計が１０００以上で最小となるセッション制御装置４Ｓの組み合わせを選択することができる。
制御総量決定部１３は、回答信号を受信すると、回答信号に含まれるセッション制御装置４Ｓを、輻輳地域の加入者端末７への接続要求のみを行うセッション制御装置４Ｓとして決定するとともに、決定されたセッション制御装置のリソースに応じて制御総量を配分することによって、それぞれのセッション制御装置４Ｓに指示する発呼規制値を決定する。

次に、ステップＳ１０７にて、制御指示部１４は、算出した発呼規制値を各セッション制御装置４Ｓに対して指示する制御指示情報（発呼規制指示情報）を送信したのち、所定時間待機する。

かかる動作によると、例えば、図７に示すように、地域Ａの加入者端末７への着信呼で輻輳が発生している場合において、トラヒック制御装置１は、図８に示すように、２つのセッション制御装置４Ｓに対して輻輳地域の加入者端末７への接続要求のみを行わせることとなる。

なお、制御総量を配分する前（図７参照）において右の２つのセッション制御装置４Ｓが行っていた接続要求（輻輳地域の加入者端末７への接続要求を除く）を、制御総量を配分した後（図８参照）において左の２つのセッション制御装置４Ｓに配分する手法としては、例えば、入江、他４名、「スケールアウト型セッション制御サーバにおける動的構成変更に関する一検討」、電子情報通信学会、信学技報 ＮＳ２０１０−２３６、平成２３年３月、ｐ．４０７−４１０ に記載されている手法等、公知の手法が採用可能である。

次に、ステップＳ１０８にて、対地別トラヒック情報取得部１２は、トラヒック監視装置３から直近の対地別トラヒック情報９２を取得し、ステップＳ１０９にて、リソース情報取得部１１は、リソース管理装置２から直近のリソース情報９１を取得する。

次に、ステップＳ１１０にて、制御総量決定部１３は、取得した直近の対地別トラヒック情報９２または直近のリソース情報９１を用いて輻輳が解消したか否かを判定し、輻輳が解消していない場合は（ステップＳ１１０でＮｏ）ステップＳ１０５に処理を戻して前記の処理を繰り返す。一方、輻輳が解消した場合は（ステップＳ１１０でＹｅｓ）ステップＳ１１１に処理を進める。このとき、輻輳が解消したか否かの判定は、全ての着信地域宛の発信呼数が最繁時発信呼数以下になったか否かを判定することで行ってもよいし、リソースプール４０のプール台数の比率が、例えば全リソース台数の２０％以上になったか否かを判定することにより行ってもよい。

ステップＳ１１１では、制御指示部１４が、各セッション制御装置４Ｓに対して発呼規制の解除指示を送信したのち、一連の処理を終了する。

以上説明した第一の制御方法によれば、輻輳制御においてリソースを動的管理して配分するとともに、輻輳制御を行うセッション制御装置４Ｓを集約することができ、網リソースを好適に活用することができる。
また、輻輳地域の加入者宛の接続要求の処理に対して利用可能な最大限のリソースが割り当てられるので、輻輳が発生している場合における輻輳地域の加入者宛の呼の接続数を最大化することができる。

＜第二の制御方法＞
図９は、発呼規制を行うための第二の制御方法の処理を示すフローチャートである。

ステップＳ２０１からステップＳ２０４までの処理は、ステップＳ２０４にて取得したリソース情報９１を、記憶手段に記憶させておく点を除いて、前記した第一の制御方法のステップＳ１０１からステップＳ１０４までの処理と同じである。

次に、ステップＳ２０５にて、制御総量決定部１３は、（式２）により、ステップＳ２０２にて取得した対地別トラヒック情報９２を用いて制御総量の値を算出する。なお、ここで算出した制御総量の値は、記憶手段に記憶させておく。

制御総量＝直近の輻輳地域への着信呼数 ・・・ （式２）

このステップＳ２０５では、直近の輻輳地域の加入者宛の着信呼数が、最初の制御総量に設定される。

次に、ステップＳ２０６にて、制御総量決定部１３は、前記のステップＳ１０６と同様の手法により、それぞれのセッション制御装置４Ｓに指示する発呼規制値を決定する。

次に、ステップＳ２０７にて、制御指示部１４は、算出した発呼規制値を各セッション制御装置４Ｓに対して指示する制御指示情報（発呼規制指示情報）を送信したのち、所定時間待機する。次に、ステップＳ２０８にて、リソース情報取得部１１は、リソース管理装置２から直近のリソース情報９１を取得する。なお、ここで取得したリソース情報９１は、記憶手段に記憶させておく。

次に、ステップＳ２０９にて、制御総量決定部１３は、直近のリソース情報９１を用いて輻輳が解消したか否かを判定し、輻輳が解消していない場合は（ステップＳ２０９でＮｏ）ステップＳ２１０に処理を進め、輻輳が解消した場合は（ステップＳ２０９でＹｅｓ）ステップＳ２１１に処理を進める。このとき、輻輳が解消したか否かの判定は、リソースプール４０のプール台数の比率が、例えば全リソース台数の２０％以上になったか否かを判定することにより行う。

ステップＳ２１０では、制御総量決定部１３は、（式３）により、記憶手段に記憶しておいた前回の制御総量及び前回のリソース情報９１と今回取得したリソース情報９１とを用いて制御総量の値を算出する。

制御総量＝前回の制御総量×セッション制御装置への今回リソース割当率
／セッション制御装置への前回リソース割当率 ・・・ （式３）

このステップＳ２１０では、前回の制御総量にセッション制御装置へのリソース割当率の変化の割合（リソース増減率）を乗じた値が、新たな今回の制御総量として算出される（詳細は図９を用いて後記する。）。そののち、制御総量決定部１３は、ステップＳ２０６に処理を戻して前記の処理を繰り返す。

ステップＳ２１１では、制御指示部１４が、各セッション制御装置４Ｓに対して発呼規制の解除指示を送信したのち、一連の処理を終了する。

ここで、第二の制御方法による制御総量の推移について図１０を用いて説明する。図１０は、第二の制御方法による制御総量の推移例である。なお、ここでは、時刻ｔにおいて輻輳の発生が検知された結果、初期の制御総量がＣに設定されたものとする。また、制御総量の再計算はΔｔ毎に行われ、空きリソース率が１０％以上となるように、セッション制御装置４Ｓ全体へのリソース割当率（ＳＣリソース割当率）を変化させ、非セッション制御装置４Ｎ全体へのリソース割当率（ＮＳＣリソース割当率）は制御対象外であるものと仮定する。

まず、時刻ｔにて、輻輳の発生が検知され、初期の制御総量がＣに決定される。このとき、ＳＣリソース割当率は６０％、ＮＳＣリソース割当率は３０％、空きリソース率は１０％となっている。

時刻ｔ＋Δｔでは、非セッション系のサービスに対する負荷が増大した結果、ＮＳＣリソース割当率が３５％に増加し、空きリソース率が５％まで減少した。そのため、リソース管理装置２は、空きリソース率を１０％に高めるため、ＳＣリソース割当率を５５％に減少させる。これに伴い、制御総量はＣ×５５／６０に再設定される。

時刻ｔ＋２Δｔでは、非セッション系のサービスに対する負荷が減少した結果、ＮＳＣリソース割当率が３０％に減少し、空きリソース率が１５％まで増加した。そのため、リソース管理装置２は、空きリソース率が１０％となるように、ＳＣリソース割当率を６０％に増加させる。これに伴い、制御総量は（Ｃ×５５／６０）×６０／５５＝Ｃに再設定される。

時刻ｔ＋３Δｔでは、ＮＳＣリソース割当率が３０％のままであったため、ＳＣリソース割当率が６０％に、空きリソース率が１０％にそれぞれ維持され、制御総量はＣのままである。

時刻ｔ＋４Δｔでは、非セッション系のサービスに対する負荷が再び増大した結果、ＮＳＣリソース割当率が３５％に増加したが、輻輳地域宛の発信呼数が減少して、リソース管理装置２の制御によりＳＣリソース割当率が５０％に減少し、空きリソース率が１５％まで増加した。これに伴い、制御総量はＣ×５０／６０に再設定される。

時刻ｔ＋５Δｔでは、ＮＳＣリソース割当率は３５％のままであったが、輻輳地域宛の発信呼数がさらに減少して、リソース管理装置２の制御によりＳＣリソース割当率が４５％にまで減少した結果、空きリソース率が発呼規制の解除基準となる２０％にまで復帰した。これに伴い、発呼規制の解除が行われて一連の制御が終了する。

以上説明した第二の制御方法によれば、輻輳地域に対する初期の制御総量は、輻輳が発生する直前の当該地域宛の発信呼数に設定され、以降は実際のトラヒック変動への追従制御によるリソース割当率の増減に比例するように制御総量を変化させる。したがって、実トラヒックの変動への追従性が高く、かつリソース状態の変化に適合した制御が可能となる。

続いて、リソース管理装置２の障害あるいはネットワーク障害などによって、トラヒック制御装置１とリソース管理装置２との交信が途絶えた場合において、輻輳の発生を検知してそれを解消するための第三の制御方法について説明する。

＜第三の制御方法＞
図１１は、トラヒック制御装置１が輻輳の発生を検知して発呼規制を行うための第三の制御方法の処理を示すフローチャートである。

トラヒック制御装置１のリソース情報取得部１１は、ステップＳ３０１にてリソース管理装置２との交信が可能か否かを判定し、交信が可能であれば（ステップＳ３０１でＹｅｓ）処理を終了する。一方、リソース管理装置２との交信が可能でなければ（ステップＳ３０１でＮｏ）ステップＳ３０２に処理を進めて輻輳監視処理を開始させる。

ステップＳ３０２では、トラヒック制御装置１は、その時点で稼働しているセッション制御装置群４０Ｓの情報を取得する。ここで取得する情報には、稼働中の全てのセッション制御装置４Ｓと個別に通信するためのアドレス情報が含まれ、これによりトラヒック制御装置１は稼働中のセッション制御装置４Ｓの台数を把握する。これらの情報は、ロードバランサー５またはトラヒック監視装置３から取得してもよいし、全てのセッション制御装置４Ｓに情報の取得を要求する同報通知信号を送信して、個別に情報を取得するようにしてもよい。

次に、ステップＳ３０３にて、対地別トラヒック情報取得部１２は、トラヒック監視装置３から対地別トラヒック情報９２（図４参照）を取得し、次のステップＳ３０４にて、制御総量決定部１３は、図６のステップＳ１０３において説明したように、取得した対地別トラヒック情報９２を用いて輻輳地域を特定する。なお、輻輳が発生していない場合には、輻輳地域なしと判定する。

次に、ステップＳ３０５にて、制御総量決定部１３は、輻輳地域が特定されたか否かによって輻輳が発生しているか否かを判定し、輻輳が発生していなければ（ステップＳ３０５でＮｏ）ステップＳ３０１に処理を戻して前記の処理を繰り返す。一方、輻輳が発生していれば（ステップＳ３０５でＹｅｓ）ステップＳ３０６に処理を進める。

次に、ステップＳ３０６にて、制御総量決定部１３は、前記の（式２）により、ステップＳ３０３にて取得した対地別トラヒック情報９２を用いて制御総量の値を算出する。このステップＳ３０３では、直近の輻輳地域の加入者宛の着信呼数が、制御総量に設定される。

次に、ステップＳ３０７にて、制御総量決定部１３は、前記のステップＳ１０６と同様の手法により、それぞれのセッション制御装置４Ｓに指示する発呼規制値を算出する。

次に、ステップＳ３０８にて、制御指示部１４は、算出した発呼規制値を各セッション制御装置４Ｓに対して指示する制御指示情報（発呼規制指示情報）を送信したのち、所定時間待機する。次に、ステップＳ３０９にて、対地別トラヒック情報取得部１２は、トラヒック監視装置３から直近の対地別トラヒック情報９２を取得する。

次に、ステップＳ３１０にて、制御総量決定部１３は、取得した直近の対地別トラヒック情報９２を用いて輻輳が解消したか否かを判定し、輻輳が解消していない場合は（ステップＳ３１０でＮｏ）ステップＳ３１１に処理を進め、所定時間待機したのちにステップＳ３０９に処理を戻して前記の処理を繰り返す。一方、輻輳が解消した場合は（ステップＳ３１０でＹｅｓ）ステップＳ３１２に処理を進める。このとき、輻輳が解消したか否かの判定は、全ての着信地域宛の発信呼数が最繁時発信呼数以下になったか否かを判定することで行う。

ステップＳ３１２では、制御指示部１４が、各セッション制御装置４Ｓに対して発呼規制の解除指示を送信したのちにステップＳ３０１に処理を戻して前記の処理を繰り返す。

以上説明した第三の制御方法によれば、リソース管理装置２によるリソース制御が適切に機能しなくなった場合においても、トラヒック制御装置１とトラヒック監視装置３とが連携して、輻輳の発生を検知するとともに、輻輳が発生する直前の輻輳地域への着信呼数を確保する発呼規制を発動することにより、その時点で稼働しているセッション制御装置４Ｓのリソースを活用した輻輳制御を実現することができる。

また、以上説明した第一から第三の制御方法の処理を行うトラヒック制御プログラムを、通信インタフェースを備えたコンピュータに実行させることによって、トラヒック制御装置１を実現することができる。このトラヒック制御プログラムは通信回線を介して提供することも可能であるし、ＣＤ−ＲＯＭ（Compact Disc-Read Only Memory）等の記録媒体に書き込んで配布することも可能である。

以上にて本発明の実施形態の説明を終えるが、本発明の実施の態様はこれに限られるものではなく、本発明の趣旨を逸脱しない範囲において各種変形が可能である。例えば、ステップＳ１０４，Ｓ２０４，Ｓ３０２において、トラヒック制御装置１がリソース管理装置２から送信された、前記した回答信号に対応する信号を受信し、ステップＳ１０６，Ｓ２０６，Ｓ３０７において、かかる信号に基づいて発呼規制値を決定する構成であってもよい。

１ トラヒック制御装置
１１ リソース情報取得部
１２ 対地別トラヒック情報取得部
１３ 制御総量決定部
１４ 制御指示部
２ リソース管理装置
２１ リソース制御部
２２ リソース監視部
２３ 輻輳検知部
３ トラヒック監視装置
３１ 対地別トラヒック情報集計部
４ 汎用コンピュータ（制御装置）
４１ 接続要求処理部
４２ 発呼規制部
４３ ＣＰＵ利用率測定部
４４ 発着信呼数情報収集部
４Ｓ セッション制御装置
４Ｎ 非セッション制御装置
４０Ｓ セッション制御装置群
４０Ｎ 非セッション制御装置群
５ ロードバランサー
６ ロケーションサーバ
７ 加入者端末（端末）
８ ＩＰネットワーク
９１ リソース情報
９２ 対地別トラヒック情報

Claims (6)

1. 通信ネットワークに接続された端末に対して、各種通信サービスを提供するために必要なリソースである複数のコンピュータと、
   前記複数のコンピュータのそれぞれを、端末からの接続要求を受け付けて端末間の接続処理を行うセッション制御装置と、端末間の接続処理以外の処理を行う非セッション制御装置とのいずれかとして稼働させる、またはリソースプールに待機させることにより、サービス負荷の変動に応じてリソースを割り当てるリソース管理装置と、
   前記通信ネットワークの特定地域にて輻輳が発生したときに、前記セッション制御装置に対して、当該特定地域の端末への接続要求の受付数を制限する指示を送信するトラヒック制御装置と、
   を備える通信制御システムの前記トラヒック制御装置であって、
   稼働している前記セッション制御装置の台数及び前記非セッション制御装置の台数を含むリソース情報を、前記リソース管理装置から取得するとともに、前記リソースプールのリソースが不足する状態になったときに輻輳制御処理を開始させるリソース情報取得部と、
   前記セッション制御装置の着信地域別の発信呼数及び着信呼数を集計した情報を含む対地別トラヒック情報を取得する対地別トラヒック情報取得部と、
   前記対地別トラヒック情報から直近の着信地域別の発信呼数が所定の基準を超えている輻輳地域を特定し、取得した前記リソース情報と取得した前記対地別トラヒック情報とを用いて、特定した前記輻輳地域の端末への接続要求の総受付数の上限となる制御総量を決定し、決定した前記制御総量を稼働中の前記セッション制御装置に配分して接続要求の受付数の上限となる発呼規制値を決定する制御総量決定部と、
   決定された前記発呼規制値を含む発呼規制指示情報を、前記セッション制御装置に送信する制御指示部と、
   を備え、
   前記制御総量決定部は、稼働中の前記セッション制御装置に割り当てられたリソース及び前記制御総量に基づいて、前記輻輳地域の端末への接続要求のみを行う前記セッション制御装置を決定し、決定された前記セッション制御装置に前記制御総量を配分する
   ことを特徴とするトラヒック制御装置。
2. 請求項１に記載のトラヒック制御装置において、
   前記輻輳制御処理を開始した場合は、所定時間毎に、
   前記リソース情報取得部が直近の前記リソース情報を取得し、
   前記対地別トラヒック情報取得部が直近の前記対地別トラヒック情報を取得し、
   前記制御総量決定部は、取得した直近の前記リソース情報に含まれる前記稼働している前記セッション制御装置の台数に、装置１台当たりの最大処理可能呼数を乗じた値から、取得した直近の前記対地別トラヒック情報から得られる前記輻輳地域以外の端末間の総発着信呼数を減じた値を、前記制御総量として決定する
   ことを特徴とするトラヒック制御装置。
3. 請求項１に記載のトラヒック制御装置において、
   前記リソース情報取得部は、取得した前記リソース情報を記憶手段に記憶させ、
   前記輻輳制御処理の開始時には、
   前記制御総量決定部は、取得した前記対地別トラヒック情報から得られる前記輻輳地域への直近の着信呼数を前記制御総量として決定するとともに、その値を前記記憶手段に記憶させ、
   以降は所定時間毎に、
   前記リソース情報取得部が直近の前記リソース情報を取得し、
   前記制御総量決定部は、取得した直近の前記リソース情報に含まれる前記稼働している前記セッション制御装置の台数と、前記記憶手段に記憶しておいた前回のセッション制御装置の台数とから、前記セッション制御装置に割り当てられているリソースの割当率の増減率を示すリソース増減率を算出し、算出した前記リソース増減率の値に、前記記憶手段に記憶しておいた前回の制御総量の値を乗じた値を、今回の前記制御総量として決定する
   ことを特徴とするトラヒック制御装置。
4. 請求項１に記載のトラヒック制御装置において、
   前記リソース情報取得部は、前記リソース管理装置から前記リソース情報を取得できないと判定した場合に、前記対地別トラヒック情報取得部が、前記対地別トラヒック情報を取得し、前記制御総量決定部が、前記対地別トラヒック情報から直近の着信地域別の発信呼数が所定の基準を超えている輻輳地域を特定することで輻輳の発生の有無を検知する輻輳監視処理を開始させ、
   前記制御総量決定部は、前記輻輳監視処理によって輻輳の発生を検知した場合には、前記対地別トラヒック情報から得られる前記輻輳地域への直近の着信呼数を前記制御総量として決定する
   ことを特徴とするトラヒック制御装置。
5. 通信ネットワークに接続された端末に対して、各種通信サービスを提供するために必要なリソースである複数のコンピュータと、
   前記複数のコンピュータのそれぞれを、端末からの接続要求を受け付けて端末間の接続処理を行うセッション制御装置と、端末間の接続処理以外の処理を行う非セッション制御装置とのいずれかとして稼働させる、またはリソースプールに待機させることにより、サービス負荷の変動に応じてリソースを割り当てるリソース管理装置と、
   前記通信ネットワークの特定地域にて輻輳が発生したときに、前記セッション制御装置に対して、当該特定地域の端末への接続要求の受付数を制限する指示を送信するトラヒック制御装置と、
   を備える通信制御システムの前記トラヒック制御装置のトラヒック制御方法であって、
   稼働している前記セッション制御装置の台数及び前記非セッション制御装置の台数を含むリソース情報を、前記リソース管理装置から取得するとともに、前記リソースプールのリソースが不足する状態になったときに輻輳制御処理を開始させるステップと、
   前記セッション制御装置の着信地域別の発信呼数及び着信呼数を集計した情報を含む対地別トラヒック情報を取得するステップと、
   前記対地別トラヒック情報から直近の着信地域別の発信呼数が所定の基準を超えている輻輳地域を特定し、取得した前記リソース情報と取得した前記対地別トラヒック情報とを用いて、特定した前記輻輳地域の端末への接続要求の総受付数の上限となる制御総量を決定し、決定した前記制御総量を稼働中の前記セッション制御装置に配分して接続要求の受付数の上限となる発呼規制値を決定するステップと、
   決定された前記発呼規制値を含む発呼規制指示情報を、前記セッション制御装置に送信するステップと、
   を含み、
   決定した前記制御総量を稼働中の前記セッション制御措置に配分する際に、前記制御総量決定部は、稼働中の前記セッション制御装置に割り当てられたリソース及び前記制御総量に基づいて、前記輻輳地域の端末への接続要求のみを行う前記セッション制御装置を決定し、決定された前記セッション制御装置に前記制御総量を配分する
   ことを特徴とするトラヒック制御方法。
6. コンピュータを、請求項１から請求項４のいずれか一項に記載のトラヒック制御装置として機能させるためのトラヒック制御プログラム。

Images