(57)【要約】【課題】冗長化構成をとるセッション制御装置が輻輳した場合に、その制御総量を適正に算出する。【解決手段】ネットワークを構成するセッション制御装置が輻輳した場合、および、特定加入者に対して輻輳が発生した場合において、輻輳セッション制御装置の処理容量を変数ｙに代入し（ステップＳ６０３）、輻輳セッション制御装置と冗長関係にある他のセッション制御装置をすべて抽出し、それらの処理容量の合計値を、変数ｚに代入し（ステップＳ６０４）、両者を合計する（ステップＳ６０５）。その合計値を、発側のセッション制御装置において接続要求を規制するために用いる制御総量として決定する（ステップＳ６０６）。【選択図】図６
2012039344.tif 000002
【特許請求の範囲】
【請求項１】
端末からの接続要求を受け付けて接続処理を行うセッション制御装置に対して、前記セッション制御装置の輻輳発生時に、端末からの接続要求の受け付けを制限する指示を出すトラヒック制御装置であって、
前記接続要求に基づく接続処理を分担して行う前記セッション制御装置同士を関連付けることを示す冗長関係と、前記セッション制御装置の前記接続要求に対する処理容量とを記憶している記憶部と、
前記セッション制御装置から輻輳を検出したことを示す輻輳情報を受信して、前記記憶部から当該セッション制御装置の処理容量と、当該セッション制御装置と冗長関係にある他の前記セッション制御装置の処理容量とを取得し、その取得した前記処理容量を加算して、その合計値を制御総量として決定する制御総量決定部と、
前記制御総量決定部によって決定された前記制御総量に基づいて、前記端末からの接続要求を受け付ける前記セッション制御装置に、当該接続要求の受け付けを制限する制御指示情報を送信する制御指示部と
を備えることを特徴とするトラヒック制御装置。
【請求項２】
端末からの接続要求を受け付けて接続処理を行うセッション制御装置に対して、前記セッション制御装置の輻輳発生時に、端末からの接続要求の受け付けを制限する指示を出すトラヒック制御装置であって、
特定加入者の加入者契約リソースを分けて収容し、前記接続要求に基づく接続処理を分担して行う前記セッション制御装置同士を関連付けることを示す冗長関係を記憶している記憶部と、
前記セッション制御装置において、前記特定加入者単位で測定された接続要求数が予め当該セッション制御装置が記憶している当該特定加入者の前記加入者契約リソースを超えると判定された場合に、当該セッション制御装置から送信される、当該特定加入者の加入者契約リソースを含む輻輳情報を受信して、当該特定加入者の加入者契約リソースを取得し、当該セッション制御装置と冗長関係にある他の前記セッション制御装置からそのセッション制御装置の前記加入者契約リソースを取得し、その取得した前記加入者契約リソースを加算して、その合計値を制御総量として決定する制御総量決定部と、
前記制御総量決定部によって決定された前記制御総量に基づいて、前記端末から前記特定加入者への接続要求を受け付ける前記セッション制御装置に、当該接続要求の受け付けを制限する制御指示情報を送信する制御指示部と
を備えることを特徴とするトラヒック制御装置。
【請求項３】
前記端末からの接続要求を受け付けて接続処理を行うセッション制御装置から前記冗長関係にある前記セッション制御装置に向かう方路ごとに、当該冗長関係にある前記セッション制御装置の処理容量に応じて、接続要求を受け付ける割合を決定する方路別接続比率決定部をさらに備え、
前記方路別接続比率決定部によって決定された前記接続要求を受け付ける割合を前記制御指示情報に含める
ことを特徴とする請求項１に記載のトラヒック制御装置。
【請求項４】
端末からの接続要求を受け付けて接続処理を行うセッション制御装置に対して、前記セッション制御装置の輻輳発生時に、端末からの接続要求の受け付けを制限する指示を出すトラヒック制御装置において用いられるトラヒック制御方法であって、
前記トラヒック制御装置は、
前記接続要求に基づく接続処理を分担して行う前記セッション制御装置同士を関連付けることを示す冗長関係と、前記セッション制御装置の前記接続要求に対する処理容量とを記憶している記憶部を備え、
前記セッション制御装置から輻輳を検出したことを示す輻輳情報を受信して、前記記憶部から当該セッション制御装置の処理容量と、当該セッション制御装置と冗長関係にある他の前記セッション制御装置の処理容量とを取得し、その取得した前記処理容量を加算して、その合計値を制御総量として決定する制御総量決定ステップと、
前記制御総量決定ステップによって決定された前記制御総量に基づいて、前記端末からの接続要求を受け付ける前記セッション制御装置に、当該接続要求の受け付けを制限する制御指示情報を送信する制御指示ステップと
を実行することを特徴とするトラヒック制御方法。
【請求項５】
請求項４に記載のトラヒック制御方法を、コンピュータである前記トラヒック制御装置に実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークのノード輻輳時および特定加入者への接続要求の輻輳時において、処理可能な制御総量を、ノードの冗長化構成を考慮して決定する技術に関する。
【背景技術】
【０００２】
特許文献１には、ネットワーク内の、あるノードが過負荷状態となった場合（この状態をノード輻輳と称す。）、トラヒック制御装置（文献では、トラヒック制御システム）が、輻輳ノードから輻輳情報を受信して、その輻輳ノードに対する他のノードからの呼設定処理要求数（接続要求数）の合計を、その輻輳ノードの呼処理容量となるように規制することが、開示されている。
【０００３】
また、特許文献２には、特定加入者への着信が過負荷となった場合、交換ノードの輻輳の発生を防止するため、当該加入者を着信先とする呼を発側のノードで規制することが記載されている(段落００１０参照）。具体的には、特定加入者への処理要求数（接続要求数）が当該特定加入者の加入者契約リソース（処理容量）よりあふれることで呼損が多発した場合（この状態を特定加入者輻輳と称し、当該特定加入者を輻輳加入者と称す。）、トラヒック制御装置（文献では、輻輳制御オペレーションシステム）は、同時接続数や捕捉あふれ数を含む輻輳情報を受信する。そして、トラヒック制御装置は、受信した輻輳情報に基づいて、輻輳加入者に向かう接続要求数の合計が輻輳加入者用の処理容量に見合うように、各ノードに指定する接続要求数を算出し、各ノードは指定された接続要求数に基づき、全ノードから当該特定加入者への接続要求数を規制する（段落００５０，００６０参照)。
【０００４】
なお、ＩＰ（Internet Protocol）ネットワークにおいても、特許文献１，２に記載の技術を適用することが可能である。例えば、発信元と着信先との間のセッションをＳＩＰ（Session Initiation Protocol）のＩＮＶＩＴＥリクエスト（接続要求：呼に該当）を用いて確立するセッション制御装置は、特許文献１，２に記載のノードに相当し、過負荷状態となった場合に、輻輳状態となる。この状態をセッション制御装置輻輳と称す。そこで、ＩＰネットワークにおいても、トラヒック制御装置は、各セッション制御装置に指定する接続要求数を算出し、全セッション制御装置からの接続要求数を規制することが考えられる。なお、各セッション制御装置に指定する接続要求数の合計値を制御総量と称す。例えば、単位時間あたりの値、つまり呼数密度の値として指定する。
また、特定加入者輻輳においても、セッション制御装置輻輳の場合と同様に、トラヒック制御装置は、各セッション制御装置に指定する接続要求数を算出し、全セッション制御装置からの接続要求数を規制することが考えられる。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開平７−０４６３１４号公報
【特許文献２】特開平７−２１２４７９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ところで、ＩＰネットワークでは、ネットワークを高信頼化構成にするために、同一サービスの提供を行う複数のセッション制御装置をネットワーク上に災害罹災を避けるように分散配置することや、同一加入者の加入者契約リソースを複数のセッション制御装置に分けて収容を行うことが考えられる。このような冗長関係にある複数のセッション制御装置を並行に運用して、それらのセッション制御装置に発信側から均等に接続させる（ラウンドロビンを用いる）場合、当該セッション制御装置のうちのいずれかで輻輳事象が発生すると、冗長関係にある他のセッション制御装置でも同様の輻輳事象が発生する。この現象は、セッション制御装置輻輳の場合だけでなく、特定加入者輻輳の場合においても同様に発生する。
【０００７】
しかしながら、この高信頼化構成にされた複数のセッション制御装置で同時に発生する輻輳に対して、トラヒック制御の制御総量を何に応じて決定するべきかが未検討となっている。例えば、特許文献１，２に記載の技術は、１台のセッション制御装置について制御総量を算出してしまうので、複数のセッション制御装置間の冗長関係を加味して制御総量を決定できないという問題がある。つまり、特許文献１，２に記載の技術では、セッション制御装置の処理能力を十分に活かしきれない。
【０００８】
そこで、本発明は、冗長化構成をとるセッション制御装置が輻輳した場合に、その制御総量を適正に算出することを課題とする。
【課題を解決するための手段】
【０００９】
本発明は、端末からの接続要求を受け付けて接続処理を行うセッション制御装置に対して、前記セッション制御装置の輻輳発生時に、端末からの接続要求の受け付けを制限する指示を出すトラヒック制御装置であって、前記接続要求に基づく接続処理を分担して行う前記セッション制御装置同士を関連付けることを示す冗長関係と、前記セッション制御装置の前記接続要求に対する処理容量とを記憶している記憶部と、前記セッション制御装置から輻輳を検出したことを示す輻輳情報を受信して、前記記憶部から当該セッション制御装置の処理容量と、当該セッション制御装置と冗長関係にある他の前記セッション制御装置の処理容量とを取得し、その取得した前記処理容量を加算して、その合計値を制御総量として決定する制御総量決定部と、前記制御総量決定部によって決定された前記制御総量に基づいて、前記端末からの接続要求を受け付ける前記セッション制御装置に、当該接続要求の受け付けを制限する制御指示情報を送信する制御指示部とを備えることを特徴とする。
【００１０】
また、本発明は、端末からの接続要求を受け付けて接続処理を行うセッション制御装置に対して、前記セッション制御装置の輻輳発生時に、端末からの接続要求の受け付けを制限する指示を出すトラヒック制御装置において用いられるトラヒック制御方法であって、前記トラヒック制御装置が、前記接続要求に基づく接続処理を分担して行う前記セッション制御装置同士を関連付けることを示す冗長関係と、前記セッション制御装置の前記接続要求に対する処理容量とを記憶している記憶部を備え、前記セッション制御装置から輻輳を検出したことを示す輻輳情報を受信して、前記記憶部から当該セッション制御装置の処理容量と、当該セッション制御装置と冗長関係にある他の前記セッション制御装置の処理容量とを取得し、その取得した前記処理容量を加算して、その合計値を制御総量として決定する制御総量決定ステップと、前記制御総量決定ステップによって決定された前記制御総量に基づいて、前記端末からの接続要求を受け付ける前記セッション制御装置に、当該接続要求の受け付けを制限する制御指示情報を送信する制御指示ステップとを実行することを特徴とする。
【００１１】
このような構成によれば、トラヒック制御装置は、輻輳を検出したセッション制御装置（以降、輻輳セッション制御装置と称す。）の処理容量と、当該輻輳セッション制御装置と冗長関係にある他のセッション制御装置の処理容量とを加算して、その合計値を制御総量として決定することができる。すなわち、トラヒック制御装置は、冗長化構成をとるセッション制御装置が輻輳した場合に、その制御総量を適正に算出することができる。したがって、冗長化構成されたセッション制御装置全体の処理容量を十分に活用可能な指示を出すことができる。
【００１２】
また、本発明は、端末からの接続要求を受け付けて接続処理を行うセッション制御装置に対して、前記セッション制御装置の輻輳発生時に、端末からの接続要求の受け付けを制限する指示を出すトラヒック制御装置であって、特定加入者の加入者契約リソースを分けて収容し、前記接続要求に基づく接続処理を分担して行う前記セッション制御装置同士を関連付けることを示す冗長関係を記憶している記憶部と、前記セッション制御装置において、前記特定加入者単位で測定された接続要求数が予め当該セッション制御装置が記憶している当該特定加入者の前記加入者契約リソースを超えると判定された場合に、当該セッション制御装置から送信される、当該特定加入者の加入者契約リソースを含む輻輳情報を受信して、当該特定加入者の加入者契約リソースを取得し、当該セッション制御装置と冗長関係にある他の前記セッション制御装置からそのセッション制御装置の前記加入者契約リソースを取得し、その取得した前記加入者契約リソースを加算して、その合計値を制御総量として決定する制御総量決定部と、前記制御総量決定部によって決定された前記制御総量に基づいて、前記端末から前記特定加入者への接続要求を受け付ける前記セッション制御装置に、当該接続要求の受け付けを制限する制御指示情報を送信する制御指示部とを備えることを特徴とする。
【００１３】
このような構成によれば、トラヒック制御装置は、特定加入者について輻輳を検出したセッション制御装置（輻輳セッション制御装置）の加入者契約リソースと、当該輻輳セッション制御装置と冗長関係にある他のセッション制御装置の加入者契約リソースとを加算して、その合計値を制御総量として決定することができる。すなわち、トラヒック制御装置は、特定加入者を分けて収容を行っている冗長化されたセッション制御装置が輻輳した場合に、その制御総量を適正に算出することができる。したがって、冗長化構成されたセッション制御装置全体の処理容量を十分に活用可能な指示を出すことができる。
【００１４】
また、本発明は、前記端末からの接続要求を受け付けて接続処理を行うセッション制御装置から前記冗長関係にある前記セッション制御装置に向かう方路ごとに、当該冗長関係にある前記セッション制御装置の処理容量に応じて、接続要求を受け付ける割合を決定する方路別接続比率決定部をさらに備え、前記方路別接続比率決定部によって決定された前記接続要求を受け付ける割合を前記制御指示情報に含めることを特徴とする。
【００１５】
このような構成によれば、トラヒック制御装置は、冗長化構成された複数のセッション制御装置の処理容量が等しくない場合においても、接続規制後に制御通過した呼について方路ごとの接続割合に基づいて方路別に接続することができるので、処理容量を十分に活用可能な指示を出すことができる。
【００１６】
また、本発明は、トラヒック制御方法を、コンピュータとしてのトラヒック制御装置に実行させるためのプログラムとした。このようなプログラムをインストールされたコンピュータは、このプログラムに基づいた機能を実現することができる。
【発明の効果】
【００１７】
本発明によれば、冗長化構成をとるセッション制御装置が輻輳した場合に、その制御総量を適正に算出することができる。
【図面の簡単な説明】
【００１８】
【図１】第１実施形態におけるネットワーク構成例を示す図である。
【図２】第１実施形態におけるネットワークを構成する各装置の構成例を示す図であり、（ａ）はトラヒック制御装置を表し、（ｂ）はセッション制御装置を表す。
【図３】冗長化構成情報の一例を示す図である。
【図４】第１実施形態におけるネットワークを構成する各装置の機能例を示す図である。
【図５】第１実施形態におけるネットワークを構成する各装置の動作例を示す図である。
【図６】第１実施形態におけるトラヒック制御装置における制御総量算出フローの一例を示す図である。
【図７】第２実施形態における輻輳加入者契約リソース情報の一例を示す図である。
【図８】第２実施形態におけるネットワークを構成する各装置の動作例を示す図である。
【図９】第２実施形態におけるトラヒック制御装置における制御総量算出フローの一例を示す図である。
【図１０】第３実施形態におけるネットワークを構成する各装置の構成例を示す図であり、（ａ）はトラヒック制御装置を表し、（ｂ）はセッション制御装置を表す。
【図１１】第３実施形態におけるネットワークを構成する各装置の機能例を示す図である。
【図１２】第３実施形態におけるネットワークを構成する各装置の動作例を示す図である。
【発明を実施するための形態】
【００１９】
発明を実施するための形態（以降、「実施形態」と称す。）について、適宜図面を参照しながら詳細に説明する。なお、第１実施形態では、セッション制御装置輻輳の場合について説明し、第２実施形態では、特定加入者輻輳の場合について説明する。ここで、セッション制御装置輻輳とは、セッション制御装置が過負荷となって輻輳した状態のことである。特定加入者輻輳とは、特定加入者への接続要求数が当該特定加入者の加入者契約リソース（処理容量）よりあふれることで呼損が多発した状態のことである。ただし、第１および第２実施形態は、端末からの接続要求を受け付ける発側のセッション制御装置（発呼規制セッション制御装置）から、冗長化構成となる各セッション制御装置に向けてのルート（以降、方路と称す。）への接続を、ラウンドロビンによって均等な割合で実施することを前提としている。そこで、第３実施形態では、方路ごとに接続される割合が不均等な場合について説明する。
【００２０】
（第１実施形態）
第１実施形態におけるネットワーク構成について、その概要を図１を用いて説明する。
図１に示すように、ＩＰネットワーク３０では、複数のセッション制御装置２０（２０ａ，２０ｂ，２０ｃ，２０ｄ，２０ｅ）がノードとして配置されて、相互に情報が送受信される（実線）。セッション制御装置２０は、端末５０から接続要求（一点鎖線；例えば、ＳＩＰのＩＮＶＩＴＥリクエスト）を受け付けて、発信元と着信先とのセッションを確立する。
各セッション制御装置２０ｃ，２０ｄ，２０ｅは、ラウンドロビン（処理要求を順番に割り振ること）によって冗長化構成となっている。つまり、各セッション制御装置２０ｃ，２０ｄ，２０ｅは、接続処理を分担して行う。図１では、各セッション制御装置２０ｃ，２０ｄ，２０ｅは、処理すべき接続要求が増大してリソースが圧迫されて輻輳発生の状態になったことを表している。したがって、以降の説明では、輻輳発生の状態になった各セッション制御装置２０ｃ，２０ｄ，２０ｅを輻輳セッション制御装置と称する。
【００２１】
また、トラヒック制御装置１０は、各セッション制御装置２０との間で通信可能に接続され（破線）、輻輳セッション制御装置（セッション制御装置２０ｃ，２０ｄ，２０ｅ）から輻輳を検出したことを示す輻輳情報を受信し、制御総量（各セッション制御装置２０に指定する接続要求数の合計値）を算出し、その制御総量に基づいて接続要求の受け付けを規制（制限）する指示情報を生成し、その指示情報を制御指示情報として発側のセッション制御装置２０ａ，２０ｂに送信する。
なお、図１では、セッション制御装置２０は、５台しか記載していないが、５台に限らない。また、冗長化構成となる各セッション制御装置２０ｃ，２０ｄ，２０ｅは１組だけを記載しているが、２組以上であっても構わない。また、冗長化構成となるセッション制御装置２０の台数は、図１では３台として記載しているが、３台に限らない。
【００２２】
次に、トラヒック制御装置１０の構成およびセッション制御装置２０の構成について、それぞれ図２（ａ）および（ｂ）を用いて説明する（適宜、図１参照）。ただし、図２は、第１実施形態における主要な機能のみを記載し、データ入力のための入力手段、ネットワークを介するデータ送受信のための通信手段、およびメッセージ等をディスプレイに表示する出力手段については記載を省略している。
【００２３】
図２（ａ）に示すように、トラヒック制御装置１０は、制御総量決定部１１および制御指示部１７を備える。制御総量決定部１１は、さらに、演算部１２、冗長化構成判定部１３、および輻輳加入者リソース判定部１５を備える。トラヒック制御装置１０は、図示しないＣＰＵ（Central Processing Unit）およびメインメモリによって構成される処理部とアプリケーションプログラム等を記憶する記憶部とで構成される。処理部は、記憶部に記憶されているアプリケーションプログラムをメインメモリに展開して、制御総量決定部１１、演算部１２、冗長化構成判定部１３、輻輳加入者リソース判定部１５および制御指示部１７、を具現化する。また、冗長化構成情報１４および輻輳加入者契約リソース情報１６は、前記した記憶部に記憶される。なお、第１実施形態では用いない輻輳加入者リソース判定部１５および輻輳加入者契約リソース情報１６については、破線で表示し、後記する第２実施形態において説明する。
【００２４】
制御総量決定部１１は、例えば、輻輳セッション制御装置から輻輳情報を受信したとき、セッション制御装置２０全体が処理可能な制御総量を決定する。具体的には、冗長化構成判定部１３は、予め冗長化構成情報１４（図３参照）を参照して、輻輳情報を送信してきた輻輳セッション制御装置と冗長関係にある各セッション制御装置２０を抽出し、それらの処理容量を読み出す。次に、演算部１２は、冗長化構成判定部１３によって読み出された処理容量の合算値と、輻輳情報を送信してきた輻輳セッション制御装置の処理容量とを加算して、合計値を算出する。そして、制御総量決定部１１は、演算部１２によって算出された合算値を制御総量として決定する。
【００２５】
制御指示部１７は、制御総量決定部１１において決定した制御総量に基づいて、発呼規制セッション制御装置に制御指示情報を送信する。
【００２６】
また、図２（ｂ）に示すように、セッション制御装置２０は、発呼規制要求部２１、リソース監視部２２、ＣＰＵ使用率測定部２３、特定加入者接続数測定部２４、加入者契約リソース情報２５、接続要求処理部２６、および発呼規制部２７を備える。なお、セッション制御装置２０は、図示しないＣＰＵおよびメインメモリによって構成される処理部とアプリケーションプログラム等を記憶する記憶部とを含んで構成される。処理部は、記憶部に記憶されているアプリケーションプログラムをメインメモリに展開して、発呼規制要求部２１、リソース監視部２２、ＣＰＵ使用率測定部２３、特定加入者接続数測定部２４、接続要求処理部２６、および発呼規制部２７を具現化する。また、記憶部は、加入者契約リソース情報２５および各測定部２３，２４によって測定された結果等を記憶している。
【００２７】
発呼規制要求部２１は、リソース監視部２２において輻輳発生と判定された場合、輻輳情報をトラヒック制御装置１０に送信する。
リソース監視部２２は、ＣＰＵ使用率測定部２３および特定加入者接続数測定部２４を備えている。ＣＰＵ使用率測定部２３は、ＣＰＵ使用率（処理負荷）を測定し、測定結果を記憶部に記憶する。なお、第１実施形態では用いない特定加入者接続数測定部２４および加入者契約リソース情報２５については、破線で表示し、後記する第２実施形態において説明する。そして、リソース監視部２２は、測定したＣＰＵ使用率を、予め設定された処理負荷の閾値と比較し、ＣＰＵ使用率が閾値を超えたときに、輻輳発生と判定する。
【００２８】
発呼規制部２７は、トラヒック制御装置１０から受信した制御指示情報に基づいて、各輻輳セッション制御装置に向かう接続要求を規制する規制指示を、接続要求処理部２６に通知する。
接続要求処理部２６は、端末５０から接続要求を受け付けて、その接続要求の目的の着信先に接続する制御を行う。また、接続要求処理部２６は、発呼規制部２７から通知された規制指示に基づいて、端末５０からの接続要求を規制する。
【００２９】
ここで、冗長化構成情報１４の一例について、図３を用いて説明する。
図３に示すように、冗長化構成情報１４は、少なくとも、セッション制御装置の識別記号、処理容量、および冗長関係にあるセッション制御装置の識別記号を関連付けて記憶している。
セッション制御装置の識別記号は、セッション制御装置２０を識別する記号である。
処理容量は、セッション制御装置２０で処理可能な、所定の単位時間あたりの接続要求数である。この処理容量は、例えば、セッション制御装置２０から輻輳情報に含めて通知される値であっても、予め設定されている値であっても構わない。
冗長関係にあるセッション制御装置の識別記号は、冗長関係にある他のセッション制御装置２０を識別する記号である。
【００３０】
次に、トラヒック制御装置１０の機能およびセッション制御装置２０の機能について、図４を用いて説明する（適宜、図１参照）。なお、各装置１０，２０間を接続する線は、情報の送受信を表している。
【００３１】
図４に示す各輻輳セッション制御装置（セッション制御装置２０ｃ，２０ｄ，２０ｅ）は、処理すべき接続要求数が増大して輻輳状態となった、図１に示したセッション制御装置２０ｃ，２０ｄ，２０ｅを表している。
各輻輳セッション制御装置（セッション制御装置２０ｃ，２０ｄ，２０ｅ）は、いずれも同様の機能を備えているので、セッション制御装置２０ｃが輻輳状態となった場合を代表例として、説明する。
【００３２】
輻輳セッション制御装置（セッション制御装置２０ｃ）の接続要求処理部２６は、端末５０から接続要求を受け付けて、その接続要求の目的の着信先に接続する制御を行う。
輻輳セッション制御装置（セッション制御装置２０ｃ）のリソース監視部２２は、ＣＰＵ使用率測定部２３を備えている。ＣＰＵ使用率測定部２３は、ＣＰＵ使用率（処理負荷）を測定し、測定結果を記憶部に記憶する。そして、リソース監視部２２は、測定したＣＰＵ使用率を、予め設定された処理負荷の閾値と比較し、ＣＰＵ使用率が閾値を超えたときに、輻輳発生と判定する。
輻輳セッション制御装置（セッション制御装置２０ｃ）の発呼規制要求部２１は、リソース監視部２２において輻輳発生と判定された場合、輻輳情報をトラヒック制御装置１０に送信する。
【００３３】
発呼規制セッション制御装置は、輻輳発生にともなって接続要求を規制する、例えば、図１に示す発側のセッション制御装置２０ａを示している。
発呼規制セッション制御装置（セッション制御装置２０ａ）の発呼規制部２７は、トラヒック制御装置１０から受信した制御指示情報に基づいて、各輻輳セッション制御装置（セッション制御装置２０ｃ，２０ｄ，２０ｅ）に向かう接続要求を規制する規制指示を、接続要求処理部２６に通知する。
発呼規制セッション制御装置（セッション制御装置２０ａ）の接続要求処理部２６は、発呼規制部２７から通知された規制指示に基づいて、端末５０からの接続要求の受け付けを規制する。
【００３４】
トラヒック制御装置１０の制御総量決定部１１は、輻輳セッション制御装置（例えば、セッション制御装置２０ｃ）から輻輳情報を受信したとき、セッション制御装置２０全体が処理可能な制御総量を決定する。具体的には、冗長化構成判定部１３は、予め冗長化構成情報１４（図３参照）を参照して、輻輳情報を送信してきた輻輳セッション制御装置（セッション制御装置２０ｃ）と冗長関係にある各セッション制御装置２０ｄ，２０ｅを抽出し、それらの処理容量を読み出す。次に、演算部１２は、冗長化構成判定部１３によって読み出された処理容量の合算値と、輻輳情報を送信してきた輻輳セッション制御装置（セッション制御装置２０ｃ）の処理容量とを加算して、合計値を算出する。そして、制御総量決定部１１は、演算部１２によって算出された合算値を制御総量として決定する。
制御指示部１７は、制御総量決定部１１において決定した制御総量に基づいて、発呼規制セッション制御装置（セッション制御装置２０ａ）に制御指示情報を送信する。
【００３５】
次に、ＩＰネットワークを構成する各装置の動作例について、図５を用いて説明する（適宜、図４参照）。
まず、ステップＳ４１では、端末５０から接続要求を受信する各セッション制御装置２０ｃ，２０ｄ，２０ｅのリソース監視部２２が、輻輳発生と判定（輻輳を検出）する。そして、各セッション制御装置２０ｃ，２０ｄ，２０ｅそれぞれの発呼規制要求部２１が、輻輳情報をトラヒック制御装置１０に送信する。ステップＳ４２では、トラヒック制御装置１０の制御総量決定部１１が、例えば、輻輳情報を送信してきた輻輳セッション制御装置（セッション制御装置２０ｃ）の処理容量を取得し、当該処理容量に、当該輻輳セッション制御装置（セッション制御装置２０ｃ）と冗長関係にあるセッション制御装置２０ｄ，２０ｅの処理容量の合算値を加算して、その加算値を制御総量として決定する。ステップＳ４３では、トラヒック制御装置１０の制御指示部１７が、当該制御総量に基づいて、各発呼規制セッション制御装置となるセッション制御装置２０ａ，２０ｂに、制御指示情報を送信する。
【００３６】
次に、図６を用いて、トラヒック制御装置１０における制御総量算出フローの一例について説明する（適宜、図４、図５参照）。なお、図６では、セッション制御装置２０ｃが輻輳状態となったケースで説明する。
ステップＳ６０１では、制御総量決定部１１は、輻輳情報を受信したか否か（輻輳が発生したか否か）を判定する。そして、輻輳情報を受信したと判定した場合、制御総量決定部１１は、輻輳が発生したと判定する（ステップＳ６０１でＹｅｓ）。なお、輻輳が発生していないと判定した場合（ステップＳ６０１でＮｏ）、処理は、ステップＳ６０１へ戻る。
輻輳が発生したと判定した場合（ステップＳ６０１でＹｅｓ）、ステップＳ６０２では、演算部１２は、変数ｙ，ｚに初期値として、それぞれ「０」を代入する。
ステップＳ６０３では、演算部１２は、輻輳セッション制御装置（セッション制御装置２０ｃ）の処理容量を取得し、その処理容量を変数ｙに代入する。
【００３７】
ステップＳ６０４では、冗長化構成判定部１３は、冗長化構成情報１４を参照して、輻輳セッション制御装置（セッション制御装置２０ｃ）と冗長関係にある他のセッション制御装置２０ｄ，２０ｅをすべて抽出し、それらの処理容量を取得する。次に、演算部１２は、冗長化構成判定部１３によって取得された処理容量の合算し、変数ｚに代入する。
ステップＳ６０５では、演算部１２は、変数ｙと変数ｚとを加算し、その結果を変数ｙとする。
ステップＳ６０６では、制御総量決定部１１は、ステップＳ６０５において算出した変数ｙの値を、制御総量として決定する。そして、処理は、ステップＳ６０１へ戻る。
なお、図６に示した処理フローはあくまでも一例であり、決定される制御総量が同じであれば、ステップの順序は異なっていても構わない。
【００３８】
以上、第１実施形態で説明したトラヒック制御装置１０は、冗長化構成となっているセッション制御装置を冗長化構成情報１４に記憶しているので、冗長化構成をとるセッション制御装置のいずれかが輻輳を検出した場合に、その制御総量を適正に算出することができる。したがって、冗長化構成されたセッション制御装置全体の処理容量を十分に活用可能な指示を出すことができる。
【００３９】
（第２実施形態）
第２実施形態では、特定加入者の加入者契約リソース（予め加入者単位で設定されている接続要求数）が冗長化構成された複数のセッション制御装置に設定されている場合において、特定加入者輻輳が発生したときの制御総量を決定するケースについて説明する。加入者契約リソースの冗長化構成とは、複数のセッション制御装置に、加入者契約リソースを分けて収容を行うことを意味する。なお、以降の説明では、特定加入者輻輳となった特定加入者を輻輳加入者と称す。
【００４０】
まず、特定加入者輻輳の発生に対処する、トラヒック制御装置１０の構成およびセッション制御装置２０の構成について、図２を用いて説明する。ここでは、第１実施形態において説明を省略した、特定加入者接続数測定部２４、加入者契約リソース情報２５、輻輳加入者リソース判定部１５、および輻輳加入者契約リソース情報１６について説明する。
【００４１】
特定加入者接続数測定部２４は、加入者単位で接続数を測定し、測定結果を記憶部に記憶する。また、加入者契約リソース情報２５は、加入者単位で予め契約に基づいて設定されている契約回線数であり、冗長化されたセッション制御装置２０間に配分された加入者契約リソースを格納している。そして、リソース監視部２２は、特定加入者ごとに、測定された接続数と加入者契約リソース情報２５の加入者契約リソースとを比較してリソースの空き状態を監視し、加入者契約リソースを超える接続要求の集中等により呼損が発生した場合に輻輳発生と判定する。そして、発呼規制要求部２１は、加入者契約リソースを含む輻輳情報を、トラヒック制御装置１０に送信する。
【００４２】
トラヒック制御装置１０の輻輳加入者リソース判定部１５は、輻輳情報が特定加入者輻輳によるものであった場合に、輻輳セッション制御装置と冗長関係にある他のセッション制御装置２０の中で、輻輳加入者の加入者契約リソースを受信していないセッション制御装置２０から、当該輻輳加入者の加入者契約リソースを取得し、輻輳加入者契約リソース情報１６に記憶する。そして、演算部１２は、輻輳加入者リソース判定部１５によって輻輳加入者契約リソース情報１６に記憶された輻輳加入者の加入者契約リソース（処理容量）を合算して、合算値を算出する。そして、制御総量決定部１１は、演算部１２によって算出された合算値を制御総量として決定する。なお、制御指示部１７は、制御総量決定部１１において決定した制御総量に基づいて、各発呼規制セッション制御装置（セッション制御装置２０）に制御指示情報を送信する。
【００４３】
ここで、輻輳加入者契約リソース情報１６の一例について、図７を用いて説明する。
図７に示すように、輻輳加入者契約リソース情報１６は、少なくとも、セッション制御装置の識別記号、加入者契約リソース（処理容量）、および冗長関係にあるセッション制御装置の識別記号を関連付けて記憶している。具体的には、例えば、図７の１行目の記載では、セッション制御装置２０ｃはセッション制御装置２０ｄ，２０ｅと冗長関係にあり、加入者契約リソースがＸｃであることを示している。また、２行目の記載は、セッション制御装置２０ｄはセッション制御装置２０ｃ，２０ｅと冗長関係にあり、加入者契約リソースがＸｄであることを示している。また、３行目の記載は、セッション制御装置２０ｅはセッション制御装置２０ｃ，２０ｄと冗長関係にあり、加入者契約リソースがＸｅであることを示している。なお、輻輳加入者契約リソース情報１６は、同一加入者ごとに作成される。
セッション制御装置の識別記号は、セッション制御装置２０を識別する記号である。
加入者契約リソース（処理容量）は、当該セッション制御装置２０から輻輳加入者リソース判定部１５によって取得された輻輳加入者の加入者契約リソースである。
冗長関係にあるセッション制御装置の識別記号は、当該セッション制御装置２０と冗長関係にある他のセッション制御装置２０を識別する記号である。
【００４４】
次に、特定加入者輻輳が発生した場合の、ＩＰネットワーク３０を構成する各装置の動作例について、図８を用いて説明する（適宜、図２、図４参照）。
まず、ステップＳ７１では、複数のセッション制御装置２０ｃ，２０ｄ，２０ｅは、それぞれ接続要求に対して、自身のリソース監視部２２が、加入者単位でリソースの空き状況を監視している。そして、図８に示す例では、セッション制御装置２０ｄ，２０ｅのリソース監視部２２は、それぞれの加入者契約リソースを超える接続要求の集中等により呼損が発生した場合に輻輳発生と判定し、輻輳を検出する。ただし、複数のセッション制御装置２０ｃ，２０ｄ，２０ｅの各々で加入者の加入者契約リソースは同容量であることを前提としている。
【００４５】
ステップＳ７２では、輻輳を検出した各セッション制御装置（輻輳セッション制御装置）２０ｄ，２０ｅは、当該輻輳加入者の加入者契約リソースを含む輻輳情報を、トラヒック制御装置１０に送信する。
ステップＳ７３では、トラヒック制御装置１０の輻輳加入者リソーソ判定部１５は、輻輳セッション制御装置（セッション制御装置２０ｄ，２０ｅ）と冗長関係にある他の複数セッション制御装置２０（図８では、セッション制御装置２０ｃ）を抽出する。
ステップＳ７４では、輻輳加入者リソース判定部１５は、抽出した冗長関係にある他のセッション制御装置２０の中で、当該輻輳加入者の加入者契約リソースを通知していないセッション制御装置２０（図８では、セッション制御装置２０ｃ）に対して、当該輻輳加入者の加入者契約リソースを要求する指示を示す通知指示を送信する。
【００４６】
ステップＳ７５では、通知指示を受信したセッション制御装置２０（図８では、セッション制御装置２０ｃ）は、加入者契約リソースを、トラヒック制御装置１０に送信する。
ステップＳ７６では、制御総量決定部１１は、冗長関係にある各セッション制御装置２０ｃ，２０ｄ，２０ｅにおける当該特定加入者の加入者契約リソースを合算し、その合計値を制御総量として決定する。
ステップＳ７７では、制御指示部１７は、当該制御総量に基づいて、端末５０から特定加入者への接続要求を受け付ける各発呼規制セッション制御装置（図８では、セッション制御装置２０ａ，２０ｂ）に、当該接続要求の受け付けを規制する制御指示情報を送信する。そして、各発呼規制セッション制御装置（図８では、セッション制御装置２０ａ，２０ｂ）は、受信した制御指示情報に基づいて、接続規制を実施する。
【００４７】
次に、図９を用いて、トラヒック制御装置１０における制御総量算出フローの一例について説明する（適宜、図４、図８参照）。なお、図９では、図８を例として、各セッション制御装置２０ｄ，２０ｅが輻輳状態となったケースで説明する。
ステップＳ９０１では、制御総量決定部１１は、輻輳情報を受信したか否か（輻輳が発生したか否か）を判定する。具体的には、制御総量決定部１１は、各輻輳セッション制御装置（セッション制御装置２０ｄ，２０ｅ）から輻輳情報を受信したか否かを判定している。そして、輻輳情報を受信したと判定した場合、制御総量決定部１１は、輻輳が発生したと判定する（ステップＳ９０１でＹｅｓ）。なお、輻輳が発生していないと判定した場合（ステップＳ９０１でＮｏ）、処理は、ステップＳ９０１へ戻る。
輻輳が発生したと判定した場合（ステップＳ９０１でＹｅｓ）、ステップＳ９０２では、演算部１２は、変数ｙ，ｚに初期値として、それぞれ「０」を代入する。
ステップＳ９０３では、演算部１２は、各輻輳セッション制御装置（セッション制御装置２０ｄ，２０ｅ）から受信した輻輳情報に含まれる輻輳加入者の加入者契約リソース（処理容量）を加算して、変数ｙに代入する。
【００４８】
ステップＳ９０４では、輻輳加入者リソース判定部１５は、輻輳加入者契約リソース情報１６を参照して、各輻輳セッション制御装置（セッション制御装置２０ｄ，２０ｅ）と冗長関係にある他のセッション制御装置２０をすべて抽出し（図８では、セッション制御装置２０ｃ）、それらの加入者契約リソース（処理容量）を取得する。次に、演算部１２は、輻輳加入者リソース判定部１５によって取得された加入者契約リソース（処理容量）を合算し、変数ｚに代入する。
ステップＳ９０５では、演算部１２は、変数ｙと変数ｚとを加算し、その結果を変数ｙとする。
ステップＳ９０６では、制御総量決定部１１は、ステップＳ９０５において算出した変数ｙの値を、制御総量として決定する。そして、処理は、ステップＳ９０１へ戻る。
なお、図９に示した処理フローはあくまでも一例であり、決定される制御総量が同じであれば、ステップの順序は異なっていても構わない。
【００４９】
以上、第２実施形態で説明したトラヒック制御装置１０は、特定加入者輻輳に関して、冗長化構成となっているセッション制御装置２０を輻輳加入者契約リソース情報１６に記憶しているので、冗長化構成をとるセッション制御装置２０のいずれかが輻輳を検出した場合に、特定加入者輻輳に対応する制御総量を適正に算出することができる。したがって、冗長化構成されたセッション制御装置全体の処理容量を十分に活用可能な指示を出すことができる。
【００５０】
（第３実施形態）
第２実施形態では、特定加入者の加入者契約リソースが冗長化構成された複数のセッション制御装置２０において等容量に設定されている場合について示したが、この第３実施形態では、セッション制御装置２０ごとに異なる容量に設定されているケースについて説明する。
【００５１】
第３実施形態のトラヒック制御装置１０ａの構成およびセッション制御装置２０の構成について、図１０を用いて説明する。なお、図２に示した第１および第２実施形態と同様の構成については、同じ符号を付し、説明を省略する。
トラヒック制御装置１０ａの制御指示部１７は、方路別に接続させる接続比率を決定する方路別接続比率決定部１８を備える。なお、方路とは、端末５０からの接続要求を受け付けたセッション制御装置２０から、冗長化構成となる各セッション制御装置２０に向けてのルートを表す。また、セッション制御装置２０の接続要求処理部２６は、方路別接続比率決定部１８において決定された接続比率を制御指示部１７から受信して、図示しない記憶部に方路別接続比率情報２８として記憶している。
【００５２】
次に、トラヒック制御装置１０ａの機能およびセッション制御装置２０の機能について、図１１を用いて説明する。なお、図４と同じ構成については、同じ符号を付し、説明を省略する。
【００５３】
発呼規制セッション制御装置（セッション制御装置２０ａ）の接続要求処理部２６は、制御指示部１７から受信する制御指示情報に含まれる、方路別接続比率決定部１８において決定された接続比率を、方路別接続比率情報２８に記憶している。そして、発呼規制セッション制御装置（セッション制御装置２０ａ）の発呼規制部２７は、トラヒック制御装置１０ａから受信した制御指示情報に含まれる制御総量に基づいて、接続要求を規制する規制指示を、自身の接続要求処理部２６に通知する。次に、発呼規制セッション制御装置（セッション制御装置２０ａ）の接続要求処理部２６は、自身の発呼規制部２７から通知された規制指示に基づいて接続規制を実施し、制御通過した呼を方路別接続比率情報２８に基づいて方路別に接続する。
【００５４】
次に、第３実施形態におけるＩＰネットワークを構成する各装置の動作例について、図１２を用いて説明する（適宜、図１１参照）。なお、ステップＳ９１〜Ｓ９６は、図８に示すステップＳ７１〜Ｓ７６と同様であるので、説明を省略し、ステップＳ９７について説明する。
ステップＳ９７では、トラヒック制御装置１０ａの制御指示部１７は、方路別接続比率決定部１８によって算出された方路別の接続比率と、公知（例えば、特開平７−２１２４７９号の段落００６０参照）の総量制御方式に基づいた指示内容とを含めた制御指示情報を生成する。
方路別の接続比率は、各々の冗長化された各セッション制御装置２０ｃ，２０ｄ，２０ｅにおける当該輻輳加入者の加入者契約リソースの容量に応じて決められる。例えば、方路別の接続比率は、各々の冗長化された各セッション制御装置２０ｃ，２０ｄ，２０ｅにおける当該輻輳加入者の加入者契約リソースの容量に比例して決められても良い。図１２に示すように、例えば、特定加入者に対して、セッション制御装置２０ｃの加入者契約リソースの（処理可能な）呼が２０呼、セッション制御装置２０ｄの加入者契約リソースの（処理可能な）呼が１０呼、セッション制御装置２０ｅの加入者契約リソースの（処理可能な）呼が１０呼、であったとする。この場合、方路別の接続比率は、２：１：１と算出される。
【００５５】
そして、各発呼規制セッション制御装置（セッション制御装置２０ａ，２０ｂ）は、受信した制御指示情報に含まれる制御総量に基づいて接続規制を実施し、かつ制御通過した呼について方路別接続比率に基づいて方路別に接続する。例えば、図１２に示すように、各セッション制御装置２０ａ，２０ｂは、制御通過した呼について、各セッション制御装置２０ｃ，２０ｄ，２０ｅに向かう方路ごとに、それぞれ１０呼、５呼、５呼まで接続可能とする。
【００５６】
以上、第３実施形態で説明したトラヒック制御装置１０ａは、特定加入者輻輳に関して、第２実施形態と同様の機能を備えているので、特定加入者輻輳に対応する制御総量を適正に算出することができる。また、特定加入者の加入者契約リソースが冗長化構成された複数のセッション制御装置２０において異なる容量に設定されている場合であっても、接続規制を実施し、かつ制御通過した呼について方路別接続比率に基づいて方路別に接続可能となるので、処理容量を十分に活用することができる。
【００５７】
なお、セッション制御装置輻輳においても、冗長化構成された複数のセッション制御装置２０の処理容量が等しくないケースは、第３実施形態と同様に、方路別接続比率を各セッション制御装置２０ｃ，２０ｄ，２０ｅの処理容量の比率に置き換えることで対処可能である。
【００５８】
また、第１実施形態、第２実施形態、および第３実施形態において説明した、各トラヒック制御装置１０、１０ａは、一般的なコンピュータに、前記した各処理のプログラムを実行させることで実現することができる。このプログラムは、通信回線を介して提供することが可能であるし、ＣＤ−ＲＯＭ（Compact Disc-Read Only Memory）等の記録媒体に書き込んで配布することも可能である。
【符号の説明】
【００５９】
１０，１０ａ  トラヒック制御装置
１１    制御総量決定部
１２    演算部
１３    冗長化構成判定部
１４    冗長化構成情報
１５    輻輳加入者リソース判定部
１６    輻輳加入者契約リソース情報
１７    制御指示部
１８    方路別接続比率決定部
２０（２０ａ，２０ｂ，２０ｃ，２０ｄ，２０ｅ）    セッション制御装置
２１    発呼規制要求部
２２    リソース監視部
２３    ＣＰＵ使用率測定部
２４    特定加入者接続数測定部
２５    加入者契約リソース情報
２６    接続要求処理部
２７    発呼規制部
２８    方路別接続比率情報
３０    ＩＰネットワーク
５０    端末
【図１】
2012039344.tif 000003
【図２】
2012039344.tif 000004
【図３】
2012039344.tif 000005
【図４】
2012039344.tif 000006
【図５】
2012039344.tif 000007
【図６】
2012039344.tif 000008
【図７】
2012039344.tif 000009
【図８】
2012039344.tif 000010
【図９】
2012039344.tif 000011
【図１０】
2012039344.tif 000012
【図１１】
2012039344.tif 000013
【図１２】
2012039344.tif 000014