JP2014072685A

JP2014072685A - 呼制御システム

Info

Publication number: JP2014072685A
Application number: JP2012216972A
Authority: JP
Inventors: Tadasuke Nozoe; 忠佑野副; Nobuyuki Uta; 信行宇多
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2012-09-28
Filing date: 2012-09-28
Publication date: 2014-04-21
Anticipated expiration: 2032-09-28
Also published as: JP5766164B2

Abstract

【課題】ＡＳ（アプリケーションサーバ）で発生した輻輳を柔軟に制御すること。
【解決手段】ＳＩＰリクエスト信号に対してサービスを提供するＡＳ３が、ＳＩＰリクエスト信号に設定されたｉＦＣ識別子を用いてＳＩＰリクエスト信号に係るトラヒックデータをサービス毎に収集し、自機に輻輳が発生した場合に当該トラヒックデータを制御センタ５に送信し、その制御センタ５は、トラヒックの量又はサービスの重要度に応じてサービス毎の規制方針を定めた規制シナリオを予め記憶しておき、トラヒックデータを受信した場合、その規制シナリオを用いてサービスに対する規制方針を決定し、その決定されたサービス毎の規制方針での規制をＳ−ＣＳＣＦ１に指示する。
【選択図】図１

Description

本発明は、ＩＭＳネットワーク上に設置されたＡＳ（アプリケーションサーバ）の輻輳制御技術に関する。

ＩＭＳ（IP Multimedia Subsystem）ネットワークでは、Ｓ−ＣＳＣＦ（Serving Call State Control Function）がｉＦＣ（initial filter criteria）との比較結果に基づいてＳＩＰリクエスト信号をＡＳ（Application server）に転送することにより、電話端末が所望するサービスを提供している（非特許文献１参照）。

例えば、図９に示すように、Ｓ−ＣＳＣＦ１は、ＳＩＰリクエスト信号に含まれるヘッダ情報内のＲ−ＵＲＩ値が「０１２０」から始まる場合にサービスＡを提供可能なＡＳ（＃１）３ａに転送することを定義したｉＦＣ１と、Ｒ−ＵＲＩ値が「＃」から始まる場合にサービスＢを提供可能なＡＳ（＃２）３ｂに転送することを定義したｉＦＣ２とを保持しておく。

そして、Ｓ−ＣＳＣＦ１は、電話端末（＃１）７ａから「０１２０ｘｘｘｘｘｘ」（ｘは数字）のＩＮＶＩＴＥ信号を受信すると、比較優先度の高いｉＦＣ１と比較し、ここでは当該ｉＦＣ１の条件に合致するため、そのＩＮＶＩＴＥ信号をＡＳ（＃１）３ａに転送する。

また、他の電話端末（＃２）７ｂから「＃ｘｘｘｘ」のＩＮＶＩＴＥ信号を受信した場合も同様にｉＦＣ１と比較するが、そのｉＦＣ１の条件に合致しないため、次に比較優先度の高いｉＦＣ２と比較する。ここで、そのｉＦＣ２の条件には合致することから、そのＩＮＶＩＴＥ信号をＡＳ（＃２）３ｂに転送する。

一方、ＡＳ３におけるサービスの提供方法については、１台のＡＳ３内に複数のサービスプログラムを実装することにより、１つのＡＳ３で複数のサービスを提供することも可能である。

例えば、図１０に示すように、サービスＡとサービスＢをそれぞれ提供可能なサービスＡ処理部とサービスＢ処理部を１つのＡＳ（＃３）３ｃで実行するようにし、更に、Ｓ−ＣＳＣＦ１によっていずれのサービスが起動されたかを判定する起動サービス判定部をそれら各サービス処理部の前段で動作させるようにする。

また、ｉＦＣ１を、Ｒ−ＵＲＩ値が「０１２０」から始まる場合にＡＳ（＃３）３ｃに転送するように定義し、ｉＦＣ２を、Ｒ−ＵＲＩ値が「＃」から始まる場合にＡＳ（＃３）３ｃに転送するように定義する。

このような構成の場合、Ｓ−ＣＳＣＦ１は、受信したＩＮＶＩＴＥ信号が「０１２０ｘｘｘｘｘｘ」又は「＃ｘｘｘｘ」のいずれの場合であってもＡＳ（＃３）３ｃに転送し、更に当該ＡＳ（＃３）３ｃにおいて該当のサービス処理部を起動する。

そして、ＡＳ（＃３）３ｃの起動サービス判定部は、ＳＩＰリクエスト信号に含まれるヘッダ情報内のＲ−ＵＲＩ値に基づいてＳ−ＣＳＣＦ１によって起動されたサービス処理部を判定し、受信したＳＩＰリクエスト信号を当該サービス処理部に転送する。

このように従来の呼制御システムは、主にＳ−ＣＳＣＦ１及びＡＳ３によって構成されている。しかし、ＡＳ３内の特定のサービス処理で一時的にトラヒックが急増する場合があるため、その輻輳を制御する輻輳制御機能を設ける必要がある。

ここで、ＩＭＳネットワークのようなＩＰベースのネットワークにおける輻輳制御技術としては、ＰＳＴＮ（Public Switched Telephone Networks）と同様に、呼制御システムを管理等制御する制御センタからの呼数密度規制指示が有用である（非特許文献２参照）。

ここでいう呼数密度規制とは、輻輳が発生しているＡＳ３への単位時間当たりのＳＩＰリクエスト信号の送信量（Ｓ−ＣＳＣＦ１からの転送量）を一定値以下に抑制する規制方法であり、そのＡＳ３の輻輳を迅速に収束させることができる。

ここで、図１１を参照しながら、従来の呼数密度規制方法について説明する。ＡＳ３は、（１）ＣＰＵ使用率やメモリ使用量等が閾値を超過すると自機で輻輳が発生したと判定し、（２）輻輳の発生を示す輻輳発生信号とこれまでに記録したＳＩＰリクエスト信号に関するトラヒックデータを制御センタに送信する。

その後、制御センタ５は、（３）受信したトラヒックデータを用いて、上記ＡＳ３で輻輳が発生しないように処理可能なＳＩＰリクエスト信号数を推定し、各Ｓ−ＣＳＣＦ１での単位時間当たりの転送可能ＳＩＰリクエスト信号数を算出する（各Ｓ−ＣＳＣＦ１への配分計算）。

そして、（４）算出された転送可能ＳＩＰリクエスト信号数を各Ｓ−ＣＳＣＦ１にそれぞれ通知して呼数密度規制を指示すると、各Ｓ−ＣＳＣＦ１は、（５）上記ＡＳ３向けの単位時間当たりのＳＩＰリクエスト信号の転送数を転送可能ＳＩＰリクエスト信号数以下に制限する。

これ以降、輻輳発生中、ＡＳ３は、定期的にトラヒックデータを制御センタ５に通知し、制御センタ５は、通知されたトラヒックデータに基づいて転送可能ＳＩＰリクエスト信号数等を再計算して各Ｓ−ＣＳＣＦ１にそれぞれ再通知する。各Ｓ−ＣＳＣＦ１は、再通知された転送可能ＳＩＰリクエスト信号数に基づいてＡＳ３に転送する単位時間当たりのＳＩＰリクエスト数を制限する。

「3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; IP Multimedia (IM) session handling; IM call model; Stage 2 (Release 11)」、3GPP TS 23.218 V11．3.0（2012-06）可児島、外２名、「ＩＰ電話網における輻輳制御方法の評価」、電子情報通信学会、2007年7月5日、p.49-53

しかしながら、ＡＳで発生した輻輳の収束を目的としているため、そのＡＳに対する全てのＳＩＰリクエスト信号が規制対象となってしまい、輻輳制御を柔軟に実施できないという問題があった。

具体的には、ＡＳ向けのＳＩＰリクエスト信号に対する呼数密度規制となるため、輻輳発生の要因となったサービス以外のサービスに対するＳＩＰリクエスト信号も規制されることから、例えば、輻輳が発生したサービスＡに対してのみ規制し、輻輳が発生していないサービスＢに対しては規制しないように、各サービスに対する呼の集中状況に応じた輻輳制御を行うことができない（図１２参照）。

また、同様の理由により、サービスの重要度に関わらず全てのＳＩＰリクエスト信号が規制されることから、例えば、サービスの重要度の高いサービスＡを継続させて当該サービスＡが処理可能なＳＩＰリクエスト信号数を増加し、サービス重要度の低いサービスＢのみを規制するように、サービス重要度に応じた輻輳制御を行うことができない（図１３参照）。

本発明は、上記事情を鑑みてなされたものであり、ＡＳで発生した輻輳を柔軟に制御することを課題とする。

請求項１記載の呼制御システムは、ＳＩＰ信号を制御する呼制御サーバと、前記ＳＩＰ信号に対してサービスを提供するアプリケーションサーバと、前記アプリケーションサーバを管理する管理サーバと、を備えた呼制御システムにおいて、前記アプリケーションサーバは、ＳＩＰ信号に設定されたサービス識別子を用いて前記ＳＩＰ信号に係るトラヒックデータをサービス毎に収集するトラヒックデータ収集手段と、自機に輻輳が発生した場合、前記トラヒックデータを前記管理サーバに送信するトラヒックデータ送信手段と、を有し、前記管理サーバは、トラヒックの量又はサービスの重要度に応じてサービス毎の規制方針を定めた規制シナリオを記憶しておくデータ記憶手段と、前記トラヒックデータを受信した場合、前記データ記憶手段から読み出した前記規制シナリオを用いて前記収集されたサービスに対する規制方針を決定する規制方針決定手段と、前記決定されたサービス毎の規制方針での規制を前記呼制御サーバに指示する規制指示手段と、を有し、前記呼制御サーバは、電話端末から受信したＳＩＰ信号のヘッダ情報から所望されるサービスのサービス識別子を当該ＳＩＰ信号に設定するサービス識別子設定手段と、前記指示された規制方針に沿って前記アプリケーションサーバに転送するＳＩＰ信号をサービス毎に規制するＳＩＰ信号規制手段と、を有することを特徴とする。

本発明によれば、ＳＩＰ信号に対してサービスを提供するアプリケーションサーバが、ＳＩＰ信号に設定されたサービス識別子を用いてＳＩＰ信号に係るトラヒックデータをサービス毎に収集し、自機に輻輳が発生した場合に当該トラヒックデータを管理サーバに送信し、その管理サーバは、トラヒックの量又はサービスの重要度に応じてサービス毎の規制方針を定めた規制シナリオを予め記憶しておき、トラヒックデータを受信した場合、その規制シナリオを用いてサービスに対する規制方針を決定し、その決定されたサービス毎の規制方針での規制を呼制御サーバに指示するため、呼制御サーバからアプリケーションサーバに転送されるＳＩＰ信号をサービス毎に規制できることから、アプリケーションサーバで発生した輻輳を柔軟に制御することができる。

本発明によれば、ＡＳで発生した輻輳を柔軟に制御することができる。

呼制御システムの全体構成及び各構成要素の機能ブロック構成を示す図である。トラヒックデータの構成例を示す図である。サービス重要度表の例を示す図である。呼数密度規制の動作を示すシーケンス図である。規制シナリオの例を示す図である。呼制御システムの具体的な動作例を示す図である。規制シナリオの例を示す図である。呼制御システムの具体的な動作例を示す図である。従来の呼制御システムの動作例を示す図である。従来の呼制御システムの動作例を示す図である。従来の呼数密度規制の動作概要を示す図である。従来の呼制御システムにおける課題説明時の参照図である。従来の呼制御システムにおける課題説明時の参照図である。

従来の呼数密度規制方法は、輻輳の原因となったサービスを意識することなく全てのＳＩＰリクエスト信号を一律に規制するため、輻輳の原因となっていないサービスに対するＳＩＰリクエスト信号も規制の対象とされてしまう。そこで、本発明では、サービスを意識して規制することにより、運用ポリシに応じた柔軟な輻輳制御を実現する。

以下、本発明を実施する一実施の形態について図面を用いて説明する。但し、本発明は多くの異なる様態で実施することが可能であり、本実施の形態の記載内容に限定して解釈すべきではない。

〔呼制御システムの機能について〕
本実施の形態に係る呼制御システムの全体構成及び各構成要素の機能ブロック構成を図１に示す。この呼制御システムは、電話端末７から送信されたＳＩＰリクエスト信号（ＳＩＰ信号）をＳ−ＣＳＣＦ（Serving Call State Control Function）で制御する呼制御サーバ１（以下、単にＳ−ＣＳＣＦ１という）と、ＳＩＰリクエスト信号に対してサービスを提供するＡＳ（Application server（アプリケーションサーバ））３と、ＡＳ３を制御センタで管理・制御する管理サーバ５（以下、制御センタ５という）と、で主に構成される。

Ｓ−ＣＳＣＦ１，ＡＳ３，制御センタ５は、インターネットやＬＡＮ等の通信ネットワークを通じて相互に通信可能であり、メモリやＣＰＵ等を有するコンピュータにより実現される。以下、それら各装置の機能について説明する。

（Ｓ−ＣＳＣＦの機能について）
最初に、Ｓ−ＣＳＣＦ１の機能について説明する。Ｓ−ＣＳＣＦ１は、リクエスト信号送受信部１１と、ｉＦＣ判定部１２と、規制情報送受信部１３と、呼数密度規制部１４と、データ記憶部１５とで主に構成される。

リクエスト信号送受信部１１は、電話端末７又はＡＳ３から受信したＳＩＰリクエスト信号をｉＦＣ判定部１２に送信する機能を有している。また、呼数密度規制部１４から受信したＳＩＰリクエスト信号をＡＳ３に転送する機能を有している。

ｉＦＣ判定部１２は、リクエスト信号送受信部１１から送信されたＳＩＰリクエスト信号を受信して、そのヘッダ情報内のＲ−ＵＲＩ値と各ｉＦＣ（ｉＦＣ１〜ｉＦＣｎ）の設定条件とをｉＦＣの比較優先度順に比較し、合致するｉＦＣのｉＦＣ識別子（サービス識別子に相当）をヘッダ情報内に設定して呼数密度規制部１４に転送する機能を有している。

尚、ｉＦＣとは、ＳＩＰリクエスト信号に含まれるヘッダ情報内のＲ−ＵＲＩ値に基づきＳＩＰリクエスト信号の転送先を定義した転送先定義情報である。ＡＳ３で提供するサービス毎に用意されており、合致したｉＦＣに対応するサービス処理部がＳ−ＣＳＣＦ１によって起動されることから、サービス起動条件情報とも称される。

規制情報送受信部１３は、制御センタ５から通知された規制情報を受信して、その内容に基づいて規制開始又は規制終了を呼数密度規制部１４に指示する機能を有している。また、呼数密度規制部１４から送信された規制結果を受信して、制御センタ５に送信する機能を有している。

呼数密度規制部１４は、規制情報送受信部１３により規制開始が指示された場合、ｉＦＣ判定部１２から転送されたＳＩＰリクエスト信号のヘッダ情報（Ｒ−ＵＲＩ値又はｉＦＣ識別子）から、Ｓ−ＣＳＣＦ１によってどのｉＦＣでＡＳ３のサービス処理部が起動されたかを判定し、規制開始指示に指定されているサービス向けのｉＦＣであれば当該ＳＩＰリクエスト信号に対して呼数密度規制を実行する機能を有している。尚、規制中は、その規制結果を定期的に規制情報送受信部１３に通知する機能を有している。

また、呼数密度規制部１４は、規制開始の指示で指定されていないサービス向けのｉＦＣでサービス処理部が起動されていた場合、呼数密度規制を実施することなく、転送されたＳＩＰリクエスト信号をリクエスト信号送受信部１１に送信する機能を有している。同様に、規制情報送受信部１３から規制開始の指示を受けてない場合には、何らの処理を行うことなく、転送されたＳＩＰリクエスト信号をリクエスト信号送受信部１１に送信する機能を有している。

データ記憶部１５は、ｉＦＣ判定部１２によって用いられるｉＦＣデータや、Ｓ−ＣＳＣＦ１が処理動作中に生成等した各種データを読み出し可能に記憶しておく機能を有している。

（ＡＳの機能について）
次に、ＡＳ３の機能について説明する。ＡＳ３は、リクエスト信号送受信部３１と、起動サービス判定部３２と、サービス処理部３３と、トラヒックデータ収集部３４と、輻輳検出部３５と、輻輳通知部３６と、データ記憶部３７とで主に構成される。

リクエスト信号送受信部３１は、Ｓ−ＣＳＣＦ１から転送されたＳＩＰリクエスト信号を起動サービス判定部３２に送信する機能を有している。また、サービス処理部３３から受信したＳＩＰリクエスト信号をＳ−ＣＳＣＦ１に送信する機能を有している。

起動サービス判定部３２は、リクエスト信号送受信部３１からＳＩＰリクエスト信号を受信して、そのヘッダ情報（Ｒ−ＵＲＩ値又はｉＦＣ識別子）からサービス処理部がどのｉＦＣで起動されたかを判定し、そのＳＩＰリクエスト信号を該当のサービス処理部に送信する機能を有している。

サービス処理部３３は、異なるサービスＡ〜Ｚをそれぞれ提供可能な複数のサービスＡ処理部〜サービスＺ処理部により構成され、起動サービス判定部３２から受信したＳＩＰリクエスト信号について所定のサービス処理を行い、その処理結果のＳＩＰリクエスト信号をリクエスト信号送受信部３１に送信する機能を有している。

トラヒックデータ収集部３４は、起動サービス判定部３２とサービス処理部３３との間で送受信されるＳＩＰリクエスト信号内のｉＦＣ識別子に基づいて、完了リクエスト数、不完了リクエスト数、エラーコード返却数等をサービス毎にカウントし、ＳＩＰリクエスト信号に係るサービス毎のトラヒックデータ（図２参照）としてデータ記憶部３７に記録しておく機能を有している。

輻輳検出部３５は、ＣＰＵ使用率やメモリ使用率、トラヒックデータ等を基に輻輳が発生したか否かを判定し、輻輳の発生と判定した場合に、これまでに更新されたトラヒックデータをデータ記憶部３７から取得して、輻輳が発生した旨を示す輻輳発生信号と共に輻輳通知部３６に送信する機能を有している。

輻輳通知部３６は、輻輳検出部３５から受信した輻輳発生信号とトラヒックデータを制御センタ５に送信する機能を有している。

データ記憶部３７は、トラヒックデータ収集部３４で計算されたトラヒックデータやＡＳ３が処理動作中に生成等した各種データを読み出し可能に記憶しておく機能を有している。

（制御センタの機能について）
次に、制御センタ５の機能について説明する。制御センタ５は、輻輳通知受信部５１と、規制判定部５２と、規制情報送受信部５３と、データ記憶部５４とで主に構成される。

輻輳通知受信部５１は、ＡＳ３から輻輳発生信号とトラヒックデータを受信した際に、規制判定部５２に転送する機能を有している。

規制判定部５２は、輻輳通知受信部５１から受信したトラヒックデータと、規制情報送受信部５３から受信したＳ−ＣＳＣＦ１による規制結果と、各サービスの重要度を定めたサービス重要度表（図３参照）と、トラヒック量やサービス重要度等に応じてサービス毎の規制方針を定めた規制シナリオ（後述）とに基づいて、規制対象とすべきサービスを判定し、更に各サービスに対する各Ｓ−ＣＳＣＦ１からの単位時間当たりの転送可能ＳＩＰリクエスト信号数を決定して、規制情報送受信部５３に通知する機能（規制方針決定機能）を有している。

規制情報送受信部５３は、規制判定部５２から通知された配分結果に基づく規制情報を各Ｓ−ＣＳＣＦ１にそれぞれ送信することにより、各Ｓ−ＣＳＣＦ１に対して規制指示を実施する機能を有している。また、各Ｓ−ＣＳＣＦ１から受信した各規制結果を規制判定部５２に通知する機能を有している。

データ記憶部５４は、サービス重要度表や規制シナリオの各種データや制御センタ５が処理動作中に生成等した各種データを読み出し可能に記憶しておく機能を有している。

〔呼制御システムの動作について〕
次に、図４を参照しながら、呼制御システムで行う呼数密度規制方法について説明する。まず、電話端末７からＳＩＰリクエスト信号を受信すると、Ｓ−ＣＳＣＦ１は、データ記憶部１５から各ｉＦＣデータを読み出して当該ＳＩＰリクエスト信号に含まれるヘッダ情報内のＲ−ＵＲＩ値と比較し、各ｉＦＣで定義された設定条件に合致するか否かを判定する（ステップＳ１０１）。

次に、Ｓ−ＣＳＣＦ１は、ステップＳ１０１の判定の結果、合致したｉＦＣのｉＦＣ識別子をＳＩＰリクエスト信号のヘッダ情報内に設定してＡＳ３に送信すると共に、その合致したｉＦＣに対応するサービス処理部（サービス処理部３３内で該当するサービス処理部）を起動する（ステップＳ１０２）。

次に、ＡＳ３は、受信したＳＩＰリクエスト信号に含まれるヘッダ情報内のＲ−ＵＲＩ値又はｉＦＣ識別子を参照して起動されたサービス処理部を判定し、そのサービス処理部にＳＩＰリクエスト信号を送信し、そのＳＩＰリクエスト信号に係るトラヒック量をｉＦＣ識別子毎にカウントすることにより、サービス毎のトラヒックデータを計算する（ステップＳ１０３）。

その後、ＡＳ３は、ＣＰＵ使用率等が閾値を超過する等により輻輳が発生したことを検知すると（ステップＳ１０４）、これまでに集計されたトラヒックデータ及び輻輳発生信号を制御センタ５に送信する（ステップＳ１０５）。

次に、制御センタ５は、輻輳発生信号の受信により送信元のＡＳ３で輻輳が発生したことを認識すると、サービス重要度表及び規制シナリオをデータ記憶部５４から取得し、輻輳発生信号と同時に受信したトラヒックデータを更に用いて、輻輳が発生したＡＳ３で規制対象とすべきサービスを判定し、各サービスに対する各Ｓ−ＣＳＣＦ１からの単位時間当りの転送可能ＳＩＰリクエスト信号数を計算する（ステップＳ１０６）。

次に、制御センタ５は、ステップＳ１０６の判定結果及び計算結果に基づいて各Ｓ−ＣＳＣＦ１に規制情報（規制対象サービス名、規制対象サービスに対する各Ｓ−ＣＳＣＦ１からの転送可能ＳＩＰリクエスト信号数、規制開始指示又は規制終了指示）をそれぞれ送信し（ステップＳ１０７）、規制指示を受けたＳ−ＣＳＣＦ１は、その規制情報に基づき規制を開始する（ステップＳ１０８）。

その後、そのＳ−ＣＳＣＦ１は、新たなＳＩＰリクエスト信号を受信した際に、起動するサービスが規制対象であるか否かを判定し、規制対象のサービスであれば転送可能ＳＩＰリクエスト信号数を超えないように呼数密度規制を実行し、規制対象のサービスでなければそのままＳＩＰリクエスト信号をＡＳ３に送信する（ステップＳ１０９）。

〔動作例１〕
引き続き、呼制御システムの具体的な動作例について説明する。規制シナリオの定義によっては様々な運用ポリシを規定できるが、ここでは、「リクエストが集中しているサービスのみを規制する（輻輳原因サービスの優先的規制）」という運用ポリシの規制シナリオを用いた場合について説明する。

（規制シナリオ例）
まず、動作例を説明する前に、図５を参照しながら、この規制シナリオを用いて行う制御センタ５（規制判定部５２）の動作について説明する。但し、本動作説明において、ＡＳ３は、１つ又は２つのサービスを提供可能とする。

まず、輻輳が発生したＡＳ３から受信したトラヒックデータを参照し、そのＡＳ３で提供しているサービスの数を確認する（ステップＳ２０１）。提供サービス数が１つの場合には、これまでの規制実施状況から当該ＡＳ３に対する現在の規制状況を確認する（ステップＳ２０２）。

ステップＳ２０２での確認の結果、上記１つのサービスに対して何ら規制されていない場合には、そのサービスに対して規制を開始し（ステップＳ２０３）、既に規制されている場合には、そのサービスに対する各Ｓ−ＣＳＣＦ１からの転送可能ＳＩＰリクエスト信号数を再計算する（ステップＳ２０４）。

一方、ステップＳ２０１での確認の結果、提供サービス数が２つの場合にも、上記ＡＳ３に対する現在の規制状況を確認し（ステップＳ２０５）、それら２つのサービスに対して何ら規制されていない場合には、トラヒックデータを参照してトラヒック（例えば、図２に示した総呼数）が多いサービスを規制する（ステップＳ２０６）。

それに対し、１つのサービスに対して既に規制されている場合には、トラヒックデータを参照してリクエスト数（例えば、図２に示した総呼数）が多いサービスを確認し（ステップＳ２０７）、そのサービスが現在未規制のサービスの場合には、規制済のサービスの規制を解除すると共に、未規制のサービスを規制する（ステップＳ２０８）。

一方、リクエスト数が多いサービスが規制済サービスの場合には、ステップＳ２０４と同様に、各サービスに対する各Ｓ−ＣＳＣＦ１からの転送可能ＳＩＰリクエスト信号数を再計算する（ステップＳ２０９）。

（呼制御システムの動作例）
次に、図６を参照しながら、動作例１について説明する。但し、本動作説明において、ＡＳ３のサービスＡ処理部は着信課金サービスを提供し、サービスＢ処理部は＃ダイヤルサービスを提供可能とする。

また、ｉＦＣ１には、Ｒ−ＵＲＩ値が「０１２０」から始まるならＡＳ３にＳＩＰリクエスト信号を転送し、ｉＦＣ２には、Ｒ−ＵＲＩ値が「＃」から始まるならＡＳ３にＳＩＰリクエスト信号を転送することが定義されているとする。尚、ｉＦＣの比較優先度はｉＦＣ１の方がｉＦＣ２よりも高いとする。

まず、電話端末７で「０１２０ｘｘｘｘｘｘ」（ｘは数字）がダイヤルされると、その電話端末７からＳ−ＣＳＣＦ１に向けてＲ−ＵＲＩ値に「０１２０ｘｘｘｘｘｘ」が設定されたＩＮＶＩＴＥ信号が送信される（ステップＳ３０１）。

次に、そのＩＮＶＩＴＥ信号を受信したＳ−ＣＳＣＦ１は、最初に比較優先度の高いｉＦＣ１を用いてＩＮＶＩＴＥ信号と比較処理を行う（ステップＳ３０２）。ここでは、受信したＩＮＶＩＴＥ信号のＲ−ＵＲＩ値に「０１２０」が含まれてることから、ｉＦＣ１の条件に合致するため、ｉＦＣ１を起動した旨を示すｉＦＣ識別子をＩＮＶＩＴＥ信号内に設定してＡＳ３に転送すると共に、そのｉＦＣ１に対応するサービスＡ処理部を起動する（ステップＳ３０３）。

次に、そのＩＮＶＩＴＥ信号を受信したＡＳ３は、そのＩＮＶＩＴＥ信号の内部に設定されているｉＦＣ識別子からサービスＡ処理部が起動されたと判断し、サービスＡに係る着信課金処理を行う（ステップＳ３０４）。

また、ＡＳ３は、その着信課金処理と併せて、着信課金向けのトラヒックデータをカウントする（ステップＳ３０５）。トラヒックデータは、図２に示したように、例えば、「総呼数（一定期間に受け付けたＩＮＶＩＴＥ信号数の合計）」、「完了呼数（一定期間に総呼数のうち発信元の電話端末に「２００ＯＫ」を送信した呼数）」、「不完了呼数（一定期間に総呼数のうち完了呼とならなかった呼数）」、「最大同時接続数（一定期間内で発生した最大の同時接続数）」のような項目から構成される。

一方、他の電話端末７（同一の電話端末７でも可）で「＃ｘｘｘｘ」（ｘは数字）がダイヤルされると、その電話端末７からＳ−ＣＳＣＦ１に向けてＲ−ＵＲＩ値に「＃ｘｘｘｘ」が設定されたＩＮＶＩＴＥ信号が送信される（ステップＳ３０６）。

そして、ＩＮＶＩＴＥ信号を受信したＳ−ＣＳＣＦ１は、同様に最初にｉＦＣ１を用いてＩＮＶＩＴＥ信号との比較処理を行うが、そのｉＦＣ１の条件に合致しないため、次に比較優先度の高いｉＦＣ２と比較評価処理を実行する（ステップＳ３０７）。ここで、受信したＩＮＶＩＴＥ信号のＲ−ＵＲＩ値が「＃」から始まりｉＦＣ２の条件に合致するため、ｉＦＣ２を起動した旨のｉＦＣ識別子をＩＮＶＩＴＥ信号内に設定した上でＡＳ３に転送すると共に、そのｉＦＣ２に対応するサービスＢ処理部を起動する（ステップＳ３０８）。

次に、そのＩＮＶＩＴＥ信号を受信したＡＳ３は、そのＩＮＶＩＴＥ信号の内部に設定されているｉＦＣ識別子からサービスＢ処理部が起動されたと判断し、サービスＢに係る＃ダイヤル処理を行うと共に（ステップＳ３０９）、＃ダイヤル向けのトラヒックデータをカウントする（ステップＳ３１０）。

ここまでの動作により、着信課金と＃ダイヤルとの２つのサービスに関するトラヒックデータが収集されることになる。

ここで、ある着信課金番号「０１２０ｙｙｙｙｙｙ」（ｙは数字）にリクエストが集中し、ＡＳ３のＣＰＵ使用率が上昇して、予め設定していた閾値（例えば、８０％）を一定時間超過したとする。

その場合、ＡＳ３は、輻輳が発生していると判断し、輻輳が発生した旨の輻輳発生信号とサービス毎のトラヒックデータとを併せて制御センタ５に通知する（ステップＳ３１１）。

制御センタ５は、輻輳発生信号を受信すると、それに併せて受信したトラヒックデータと、サービス重要度及び規制シナリオとに基づいて、サービス毎の規制要否、Ｓ−ＣＳＣＦ１への配分を決定する（ステップＳ３１２）。

例えば、以下のようなトラヒックデータの場合、制御センタ５は、着信課金サービスにリクエストが集中し、更に総呼数に対する不完了呼数の割合が高いことから、着信課金サービスが輻輳発生の原因と判断し、着信課金サービスのみを規制対象と判断する。

（着信課金サービス）
・総呼数：２００，０００呼／時
・完了呼数：１５０，０００呼／時
・不完了呼数：５０，０００呼／時
・最大同時接続数：１０，０００呼
（＃ダイヤルサービス）
・総呼数：５，０００呼／時
・完了呼数：４，８００呼／時
・不完了呼数：２００呼／時
・最大同時接続数：３００呼
また、制御センタ５は、各Ｓ−ＣＳＣＦ１に対して、着信課金サービス向けの単位時間当たりの転送可能ＳＩＰリクエスト信号数（例えば、５００呼／分）を決定し、各Ｓ−ＣＳＣＦ１への規制指示を実行する（ステップＳ３１３）。

その規制指示を受信したＳ−ＣＳＣＦ１は、ｉＦＣ１に合致したＩＮＶＩＴＥ信号をＡＳ３に送信する際には、上記決定された単位時間当たりの転送可能ＳＩＰリクエスト信号数内に収まるかどうかを判断する（ステップＳ３１４）。

例えば、５００呼／分の規制指示を受けている場合は、ｉＦＣ１に合致したＩＮＶＩＴＥ信号は１分内に５００個のリクエストしか転送せず、それ以上のｉＦＣ１に合致するＩＮＶＩＴＥ信号を電話端末７から受信した場合は、その電話端末７に対して規制中のエラー応答を返却する。一方、ｉＦＣ２に合致したＩＮＶＩＴＥ信号については規制指示を受けていないため、規制することなく全てＡＳ３に転送する。

以上が輻輳発生時の動作である。その後、各Ｓ−ＣＳＣＦ１から着信課金向けのＩＮＶＩＴＥ信号が規制されるため、ＡＳ３のＣＰＵ使用率は、ＩＮＶＩＴＥ信号の受信量低下に伴い低下することになる。

その後、ＣＰＵ使用率が閾値を一定時間下回った場合には、輻輳状態が解除された旨を制御センタ５に通知する。尚、ＣＰＵ使用率が閾値を下回らない場合は、輻輳が継続している旨と最新のトラヒックデータを制御センタ５に通知する。

制御センタ５は、規制解除通知を受信すると、Ｓ−ＣＳＣＦ１に対して規制解除の指示を送信する。一方、輻輳継続通知を受けた場合は、最新のトラヒックデータから各Ｓ−ＣＳＣＦ１に対する規制値を再計算し、Ｓ−ＣＳＣＦ１に規制指示を送信する。

Ｓ−ＣＳＣＦ１は、規制解除指示を受信した場合、規制を解除する。また、再度規制指示を受けた場合は、最新の規制値に基づいて規制を継続する。

〔動作例２〕
次に、２つ目の動作例について説明する。ここでは、「重要度が低いサービスを規制し、重要度が高いサービスを継続する」という運用ポリシの規制シナリオを用いた場合について説明する。

（規制シナリオ例）
先と同様に、まず、図７を参照しながら、この規制シナリオを用いて行う制御センタ５の動作について説明する。但し、本動作説明において、ＡＳ３は、１つ又は２つのサービスを提供可能とする。また、規制基準となるサービス重要度を８とする。

まず、輻輳が発生したＡＳ３から受信したトラヒックデータを参照し、そのＡＳ３で提供しているサービスの数を確認する（ステップＳ４０１）。提供サービス数が１つの場合には、これまでの規制実施状況から当該ＡＳ３に対する現在の規制状況を確認する（ステップＳ４０２）。

ステップＳ４０２での確認の結果、上記１つのサービスに対して何ら規制されていない場合には、そのサービスに対して規制を開始し（ステップＳ４０３）、既に規制されている場合には、そのサービスに対する各Ｓ−ＣＳＣＦ１からの転送可能ＳＩＰリクエスト信号数を再計算する（ステップＳ４０４）。

一方、ステップＳ４０１での確認の結果、提供サービス数が２つの場合には、サービス重要度表を更に参照して重要度が８以上のサービスが含まれているか否かを確認する（ステップＳ４０５）。

ステップＳ４０５での確認の結果、重要度が８以上のサービスが含まれていない場合には、上記ＡＳ３に対する現在の規制状況を確認し（ステップＳ４０６）、それら２つのサービスに対して何ら規制されていない場合には、重要度の低いサービスを規制する（ステップＳ４０７）。また、一方のサービスのみ規制されている場合には、規制されていない他方のサービスも規制し（ステップＳ４０８）、いずれのサービスも規制されている場合には、ステップＳ４０４と同様に、各サービスに対する各Ｓ−ＣＳＣＦ１からの転送可能ＳＩＰリクエスト信号数を再計算する（ステップＳ４０９）。

一方、ステップＳ４０５での確認の結果、重要度が８以上のサービスが含まれている場合にも、上記ＡＳ３に対する現在の規制状況を確認し（ステップＳ４１０）、それら２つのサービスに対して何ら規制されていない場合には、重要度が８未満のサービスを規制し（ステップＳ４１１）、重要度が８未満のサービスのみ規制されている場合には、ステップＳ４０９と同様の処理を実行する（ステップＳ４１２）。

（呼制御システムの動作例）
次に、図８を参照しながら、動作例２について説明する。但し、本動作説明において、ＡＳ３のサービスＡ処理部は広域内線サービスを提供し、サービスＢ処理部は着信課金サービスを提供可能とする。

また、ｉＦＣ１には、Ｒ−ＵＲＩ値が内線番号帯であり、且つ、発信してきた電話端末７が広域内線サービスの契約端末ならＡＳ３にＳＩＰリクエスト信号を転送し、ｉＦＣ２には、Ｒ−ＵＲＩ値が「０１２０」から始まるならＡＳ３にＳＩＰリクエスト信号を転送することが定義されているとする。尚、ｉＦＣの比較優先度はｉＦＣ１の方がｉＦＣ２よりも高いとする。

輻輳が発生するまでの動作はステップＳ３０１〜ステップＳ３１０と同様であるため、その間の説明は省略する。

その後、着信課金サービス及び広域内線サービスに同程度の割合でＳＩＰリクエスト信号が大量に発生し、ＡＳ３のＣＰＵ使用率が閾値（例えば、８０％）を一定時間超過したとする。例えば、諸元３０万ＢＨＣＡに対し、着信課金サービスに１６万ＢＨＣＡ（Busy Hour Call Attempts）、広域内線サービスに１４万ＢＨＣＡの呼が発生したとする。

その場合、ＡＳ３は輻輳が発生していると判断し、輻輳が発生した旨の輻輳発生信号とサービス毎のトラヒックデータとを併せて制御センタ５に通知する（ステップＳ５０１）。

制御センタ５は、輻輳発生信号を受信すると、それに併せて受信したトラヒックデータと、サービス重要度及び規制シナリオとに基づいて、サービス毎の規制要否、Ｓ−ＣＳＣＦ１への配分を決定する（ステップＳ５０２）。

例えば、トラヒックデータから両サービスとも同程度のトラヒックが発生しているが、サービス重要度は着信課金サービスの方が高いことから、着信課金サービスの処理を継続するために、サービス重要度の低い広域内線サービスを規制対象と判断する。

また、制御センタ５は、各Ｓ−ＣＳＣＦ１に対して、広域内線サービス向けの単位時間当たりの転送可能ＳＩＰリクエスト信号数（例えば、５００呼／分）を決定し、各Ｓ−ＣＳＣＦ１への規制指示を実行する（ステップＳ５０３）。

その規制指示を受信したＳ−ＣＳＣＦ１は、ｉＦＣ１に合致したＩＮＶＩＴＥ信号をＡＳ３に送信する際には、上記決定された単位時間当たりの転送可能ＳＩＰリクエスト信号数内に収まるかどうかを判断する（ステップＳ５０４）。

以上が輻輳発生時の動作である。その後、Ｓ−ＣＳＣＦ１から着信課金向けのＩＮＶＩＴＥ信号が規制されるため、ＡＳ３のＣＰＵ使用率は、ＩＮＶＩＴＥ信号の受信量低下に伴い低下することになる。

以上より、本実施の形態によれば、ＡＳ３が、ＳＩＰリクエスト信号に設定されたｉＦＣ識別子を用いてＳＩＰリクエスト信号に係るトラヒックデータをサービス毎に収集し、自機に輻輳が発生した場合に当該トラヒックデータを制御センタ５に送信し、その制御センタ５は、トラヒックの量又はサービスの重要度に応じてサービス毎の規制方針を定めた規制シナリオを予め記憶しておき、トラヒックデータを受信した場合、その規制シナリオを用いてサービスに対する規制方針を決定し、その決定されたサービス毎の規制方針での規制をＳ−ＣＳＣＦ１に指示するので、Ｓ−ＣＳＣＦ１からＡＳ３に転送されるＳＩＰリクエスト信号をサービス毎に規制できることから、ＡＳ３で発生した輻輳を柔軟に制御することができる。

１…Ｓ−ＣＳＣＦ（呼制御サーバ）
１１…リクエスト信号送受信部
１２…ｉＦＣ判定部（サービス識別子設定手段）
１３…規制情報送受信部
１４…呼数密度規制部（ＳＩＰ信号規制手段）
１５…データ記憶部
３…ＡＳ（アプリケーションサーバ）
３１…リクエスト信号送受信部
３２…起動サービス判定部
３３…サービス処理部
３４…トラヒックデータ収集部（トラヒックデータ収集手段）
３５…輻輳検出部
３６…輻輳通知部（トラヒックデータ送信手段）
３７…データ記憶部
５…制御センタ（管理サーバ）
５１…輻輳通知受信部
５２…規制判定部（規制方針決定手段）
５３…規制情報送受信部（規制指示手段）
５４…データ記憶部（データ記憶手段）
７…電話端末
Ｓ１０１〜Ｓ１０９、Ｓ２０１〜Ｓ２０９、Ｓ３０１〜Ｓ３１４、Ｓ４０１〜Ｓ４１２、Ｓ５０１〜Ｓ５０４…ステップ

Claims

ＳＩＰ信号を制御する呼制御サーバと、前記ＳＩＰ信号に対してサービスを提供するアプリケーションサーバと、前記アプリケーションサーバを管理する管理サーバと、を備えた呼制御システムにおいて、
前記アプリケーションサーバは、
ＳＩＰ信号に設定されたサービス識別子を用いて前記ＳＩＰ信号に係るトラヒックデータをサービス毎に収集するトラヒックデータ収集手段と、
自機に輻輳が発生した場合、前記トラヒックデータを前記管理サーバに送信するトラヒックデータ送信手段と、を有し、
前記管理サーバは、
トラヒックの量又はサービスの重要度に応じてサービス毎の規制方針を定めた規制シナリオを記憶しておくデータ記憶手段と、
前記トラヒックデータを受信した場合、前記データ記憶手段から読み出した前記規制シナリオを用いて前記収集されたサービスに対する規制方針を決定する規制方針決定手段と、
前記決定されたサービス毎の規制方針での規制を前記呼制御サーバに指示する規制指示手段と、を有し、
前記呼制御サーバは、
電話端末から受信したＳＩＰ信号のヘッダ情報から所望されるサービスのサービス識別子を当該ＳＩＰ信号に設定するサービス識別子設定手段と、
前記指示された規制方針に沿って前記アプリケーションサーバに転送するＳＩＰ信号をサービス毎に規制するＳＩＰ信号規制手段と、
を有することを特徴とする呼制御システム。