(57)【特許請求の範囲】
【請求項１】
発信端末からの呼接続要求に伴い送信される呼接続要求信号を受信して、当該呼接続要求信号を加入者情報取得部に転送し、当該加入者情報取得部から転送される前記呼接続要求信号を受信した後、前記呼接続要求信号に応じた呼接続処理を行う呼制御サーバであって、
受信した前記呼接続要求信号の送信元装置が前記加入者情報取得部であるか否かを判別する送信元装置判別部と、
受信した呼接続要求信号のうち、前記加入者情報取得部を除く装置から送信された呼接続要求信号である規制対象信号の受信数に基づき規制判断を行う規制判断部と、
当該規制判断部で規制が必要と判断されるとき、前記規制対象信号を規制する信号規制部と、を備えることを特徴とする呼制御サーバ。
【請求項２】
前記呼接続要求信号は、当該呼接続要求信号の送信元装置を特定する送信元識別情報を含み、
前記送信元装置判別部は、受信した呼接続要求信号に含まれる前記送信元識別情報に基づき当該呼接続要求信号の送信元装置が前記加入者情報取得部であるか否かを判別することを特徴とする請求項１記載の呼制御サーバ。
【請求項３】
前記送信元装置判別部は、受信した呼接続要求信号に含まれる前記送信元識別情報に基づき当該呼接続要求信号それぞれの送信元装置を判別して、送信元装置が前記加入者情報取得部を除く装置であると判別される呼接続要求信号を規制対象信号とし、
前記規制判断部は、前記規制対象信号の受信数をその送信元装置毎に計数し、送信元装置毎の規制対象信号の受信数と、送信元装置毎に設定した規定値とを比較することにより、前記規制対象信号の規制判断を行うことを特徴とする請求項２記載の呼制御サーバ。
【請求項４】
前記呼接続要求信号は、当該呼接続要求信号を特定する信号識別情報を含み、
前記送信元装置判別部は、受信した呼接続要求信号に含まれる前記信号識別情報が登録される記憶部と、
前記呼接続要求信号を受信したとき、当該呼接続要求信号に含まれる前記信号識別情報が前記記憶部に未登録であるか否かを判断する登録状況判断部と、
当該登録状況判断部により、受信した呼接続要求信号に含まれる信号識別情報が前記記憶部に未登録であると判断されるとき、受信した呼接続要求信号を前記規制対象信号であると判断する規制対象信号特定部と、を備えることを特徴とする請求項２記載の呼制御サーバ。
【請求項５】
発信端末からの呼接続要求に伴い送信される呼接続要求信号を受信して、当該呼接続要求信号を加入者情報取得部に転送し、当該加入者情報取得部から転送される前記呼接続要求信号を受信した後、前記呼接続要求に応じた呼接続処理を行う呼制御サーバにおける規制方法であって、
受信した呼接続要求信号のうち、呼接続要求信号の送信元装置が前記加入者情報取得部を除く装置である呼接続要求信号を規制対象信号とし、
当該規制対象信号の受信数に基づき規制が必要と判断されるとき、前記規制対象信号を規制することを特徴とする呼制御サーバの規制方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は呼制御を行う呼制御サーバおよび呼制御サーバの規制方法に関する。
【背景技術】
【０００２】
従来、携帯電話通信網などを提供する通信事業者は、費用対効果の観点から配備する設備数を決定している。具体的には、通常トラヒックの処理に要する必要最低限の設備を配備している。
そのため、災害発生時、チケット予約開始時、コンサート等の野外イベントによる一時的なバーストトラヒックについては、設備の許容量をオーバーする可能性がある。
このようにバーストトラヒックをうけた際の過負荷によるネットワークのダウンを防ぐため、規制機能が必要となる。
【０００３】
このような規制機能として、以下のような方法が提案されている。
すなわち、呼接続処理を行うＳＩＰサーバとしてのＣＳＣＦ（Call Session Control Function）サーバ（以後、ＣＳＣＦという。）などの呼制御サーバと移動端末との間に介挿されるＰＤＧ(Packet Data Gateway)などの通信制御装置において、基準値以上の通信量が発生したと判断されるときに、呼制御サーバに対して新たな呼制御を規制するよう規制指示を送信することで、呼制御サーバの過負荷を抑制するようにしたものがある（例えば、特許文献１参照。）。
【０００４】
また、呼制御サーバ自身において規制する方法として、図８に示すように、呼制御サーバとしての発信端末側のＣＳＣＦと対向している、例えばＧＷ（GateWay）、または呼制御先のＣＳＣＦからのバーストトラヒックの流入自体が生じないようにするサーバ間規制と、バーストトラヒックが自サーバに流入してしまった場合に自サーバを守る自サーバ規制とがある。
【０００５】
このうち、自サーバ規制の方法として、呼制御サーバでは、セッション開始を要求するＩＮＶＩＴＥ信号の数をカウントし、単位時間あたりに受信したＩＮＶＩＴＥ信号の数が所定数を超えたときに、受信したＩＮＶＩＴＥ信号に対する処理を中止することで、自サーバが過負荷となることを回避する方法などがとられている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００７−２８８２４３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
ところで、上述のように、ＩＮＶＩＴＥ信号の数を計測することで過負荷を検出するようにした方法においては、呼制御サーバでは、送信元の機器に関係なく、単に受信したＩＮＶＩＴＥ信号をカウントしている。
ここで、ＩＭＳ網に属する携帯端末間での呼接続では、図９（ａ）に示すように、発信端末１から呼接続要求が行われたとき、発信端末１からのＩＮＶＩＴＥ信号は発側のＧＷ（発）２を介して、発側のＣＳＣＦ（発）３に転送され、ＣＳＣＦ（発）３からＣＳ−ＡＳ（Call Session Application Server）（発）４に転送される。そして、ＣＳ−ＡＳ（発）４がＨＳＳ（Home Subscriber Server）５を参照し、所定の情報を取得するなどの処理を行った後、取得した情報などを含むＩＮＶＩＴＥ信号が、ＣＳ−ＡＳ（発）４からＣＳＣＦ（発）３に転送される。さらに、ＣＳＣＦ（発）３から着信端末１１を管理する着側のＣＳＣＦ（着）１３に転送され、ＣＳ−ＡＳ（着）１４に転送され、ＣＳ−ＡＳ（着）がＨＳＳ１５を参照し、所定の情報を取得するなどの処理を行った後、取得した情報などを含むＩＮＶＩＴＥ信号を、ＣＳＣＦ（着）１３およびＧＷ（着）１２を介して着信端末１１に転送するようになっている。
【０００８】
そのため、前述のように、ＣＳＣＦ（例えばＣＳＣＦ（発）３）において、受信したＩＮＶＩＴＥ信号の数を計測するようにした場合、例えば、発信端末１からの接続要求に伴って送信されるＩＮＶＩＴＥ信号は、ＧＷ（発）２からと、ＣＳ−ＡＳ（発）４からとの２回、ＣＳＣＦ（発）３で受信されることになる。
つまり、発信端末１からの一度の呼接続要求に伴い、ＣＳＣＦ（発）３は、ＧＷ（発）２からＩＮＶＩＴＥ信号を受信したタイミングおよびＣＳ−ＡＳ（発）４からＩＮＶＩＴＥ信号を受信したタイミングで、規制判断を行うことになる。
【０００９】
そのため、ＣＳＣＦ（発）３において、ＩＮＶＩＴＥ信号をＧＷ（発）２から受信した時点で、ＩＮＶＩＴＥ信号の数が規定値以上であると判断されなかったとしても、ＣＳ−ＡＳ（発）４から受信した時点で、ＩＮＶＩＴＥ信号の数が規定値以上と判断された場合には、この時点で、発信端末１からの呼接続要求を終了することになる。
なお、図９において、矢印は、ＩＮＶＩＴＥ信号の流れを表し、「○」は、規制判断を行うタイミングを表す。
【００１０】
このように、ＣＳＣＦ（発）３がＣＳ−ＡＳ（発）４からＩＮＶＩＴＥ信号を受信した時点で、このＩＮＶＩＴＥ信号に対して規制が行われた場合、ＣＳＣＦ（発）３がＧＷ（発）２からのＩＮＶＩＴＥ信号を受信した時点から、ＣＳＣＦ（発）３がＣＳ−ＡＳ（発）４からＩＮＶＩＴＥ信号を受信するまでの間に、各装置で行われた処理が無駄になってしまう。つまり、ＣＳＣＦ（発）３での過負荷防止のために規制を行っているにも関わらず、ＣＳＣＦ（発）３では、ＣＰＵ使用率を有効にコントロールすることができないという問題がある。
【００１１】
また、このように、ＩＮＶＩＴＥ信号の規制ポイントが複数あると、規制率よりも疎通率が悪くなるという問題もある。
このような問題は、着側のＣＳＣＦ（着）１３でも同様であって、着側のＣＳＣＦ（着）１３では、発側のＣＳＣＦ（着）３からＩＮＶＩＴＥ信号を受信したタイミングおよびＣＳ−ＡＳ（着）１４からＩＮＶＩＴＥ信号を受信したタイミングでＩＮＶＩＴＥ信号の規制判断を行うため、ＣＳ−ＡＳ（着）１４からＩＮＶＩＴＥ信号を受信した時点で、ＩＮＶＩＴＥ信号に規制を行った場合には、この呼接続処理に関するそれまでの各装置での処理が無駄になる。
【００１２】
また、図９（ｂ）に示すように、他の通信網に属する発信端末とＩＭＳ網に属する着信端末との間で呼接続を行う場合にも同様であって、他の通信網から呼接続要求が行われると、この呼接続要求に伴うＩＮＶＩＴＥ信号はＭＧＷ（Media GateWay）２６からＣＳＣＦ（着）２３を経てＣＳ−ＡＳ（着）２４に転送され、ＣＳ−ＡＳ（着）２４がＨＳＳ２５を参照し所定の情報などを取得した後、ＩＮＶＩＴＥ信号をＣＳＣＦ（着）２３、ＧＷ（着）２２を経て着信端末２１に転送している。そのため、ＣＳＣＦ（着）２３では、ＩＮＶＩＴＥ信号をＭＧＷ２６から受信した時点およびＣＳ−ＡＳ（着）２４から受信した時点のＩＮＶＩＥ信号の規制判断を行うため、ＣＳ−ＡＳ（着）２４からＩＮＶＩＴＥ信号を受信した時点でＩＮＶＩＴＥ信号の規制を行った場合には、この呼接続処理に関するそれまでの各装置での処理が無駄になる。
そこで、この発明は、上記従来の未解決の問題に着目してなされたものであり、無駄な処理を行うことなく適切なタイミングで規制を行うことの可能な呼制御サーバおよび呼制御サーバの規制方法を提供することを目的としている。
【課題を解決するための手段】
【００１３】
本発明の一態様にかかる呼制御サーバは、発信端末からの呼接続要求に伴い送信される呼接続要求信号を受信して、当該呼接続要求信号を加入者情報取得部に転送し、当該加入者情報取得部から転送される前記呼接続要求信号を受信した後、前記呼接続要求信号に応じた呼接続処理を行う呼制御サーバであって、受信した前記呼接続要求信号の送信元装置が前記加入者情報取得部であるか否かを判別する送信元装置判別部と、受信した呼接続要求信号のうち、前記加入者情報取得部を除く装置から送信された呼接続要求信号である規制対象信号の受信数に基づき規制判断を行う規制判断部と、当該規制判断部で規制が必要と判断されるとき、前記規制対象信号を規制する信号規制部と、を備えることを特徴としている。
【００１４】
ここで、呼制御サーバでは、受信した呼接続要求信号を加入者情報取得部に転送した後、加入者情報取得部から転送されるこの呼接続要求信号を再度受信するため、加入者情報取得部から呼接続要求信号を受信した段階でこの呼接続要求信号を規制した場合、呼制御サーバが呼接続要求信号を加入者情報取得部に転送した時点から、加入者情報取得部から転送される呼接続要求信号を受信するまでの処理が無駄になる。
【００１５】
しかしながら、呼制御サーバを、上述のように、加入者情報取得部を除く装置から受信した呼接続要求信号を規制対象信号とする構成としたため、呼制御サーバにおいて無駄な処理を行うことを回避しつつ、効率よく呼制御サーバの規制を行うことができる。
また、本発明の一態様にかかる呼制御サーバは、前記呼接続要求信号は、当該呼接続要求信号の送信元装置を特定する送信元識別情報を含み、前記送信元装置判別部は、受信した呼接続要求信号に含まれる前記送信元識別情報に基づき当該呼接続要求信号の送信元装置が前記加入者情報取得部であるか否かを判別することを特徴としている。
【００１６】
呼制御サーバをこのような構成とすることにより、呼接続要求信号に含まれる送信元識別情報を参照することによって、受信した呼接続要求信号の送信元装置を加入者情報取得部であるか否かを容易に判別することができる。
また、本発明の一態様にかかる呼制御サーバは、前記送信元装置判別部は、受信した呼接続要求信号に含まれる前記送信元識別情報に基づき当該呼接続要求信号それぞれの送信元装置を判別して、送信元装置が前記加入者情報取得部を除く装置であると判別される呼接続要求信号を規制対象信号とし、前記規制判断部は、前記規制対象信号の受信数をその送信元装置毎に計数し、送信元装置毎の規制対象信号の受信数と、送信元装置毎に設定した規定値とを比較することにより、前記規制対象信号の規制判断を行うことを特徴としている。
【００１７】
呼制御サーバをこのような構成とすることによって、呼接続要求信号に含まれる送信元識別情報から、受信した呼接続要求信号の送信元装置を容易に判別することができる。また、送信元装置が加入者情報取得部を除く装置であると判別される呼接続要求信号を規制対象信号とし、送信元装置毎の規制対象信号の受信数と、送信元装置毎に設定した規定値とを比較することにより、規制判断を行うため、規制の必要の有無を容易に判断することができる。
【００１８】
また、本発明の一態様にかかる呼制御サーバは、前記呼接続要求信号は、当該呼接続要求信号を特定する信号識別情報を含み、前記送信元装置判別部は、受信した呼接続要求信号に含まれる前記信号識別情報が登録される記憶部と、前記呼接続要求信号を受信したとき、当該呼接続要求信号に含まれる前記信号識別情報が前記記憶部に未登録であるか否かを判断する登録状況判断部と、当該登録状況判断部により、受信した呼接続要求信号に含まれる信号識別情報が前記記憶部に未登録であると判断されるとき、受信した呼接続要求信号を前記規制対象信号であると判断する規制対象信号特定部と、を備えることを特徴としている。
【００１９】
呼制御サーバをこのような構成とすることによって、呼制御サーバでは、受信した呼接続要求信号を加入者情報取得部に転送した後、加入者情報取得部から転送されるこの呼接続要求信号を再度受信し、同じ信号識別情報を有する呼接続要求信号を２回受信するため、呼接続要求信号に含まれる信号識別情報が記憶部に登録されていれば、この呼接続要求信号の送信元装置は加入者情報取得部であるとみなすことができ、未登録であればこの呼接続要求信号の送信元装置は加入者情報取得部を除く装置であるとみなすことができ、規制対象信号を容易に特定することができる。
【００２０】
さらに、本発明の一態様にかかる呼制御サーバにおける規制方法は、発信端末からの呼接続要求に伴い送信される呼接続要求信号を受信して、当該呼接続要求信号を加入者情報取得部に転送し、当該加入者情報取得部から転送される前記呼接続要求信号を受信した後、前記呼接続要求に応じた呼接続処理を行う呼制御サーバにおける規制方法であって、受信した呼接続要求信号のうち、呼接続要求信号の送信元装置が前記加入者情報取得部を除く装置である呼接続要求信号を規制対象信号とし、当該規制対象信号の受信数に基づき規制が必要と判断されるとき、前記規制対象信号を規制することを特徴としている。
【００２１】
ここで、呼制御サーバでは、受信した呼接続要求信号を加入者情報取得部に転送した後、加入者情報取得部から転送されるこの呼接続要求信号を再度受信するため、加入者情報取得部から呼接続要求信号を受信した段階でこの呼接続要求信号を規制した場合、呼制御サーバが呼接続要求信号を加入者情報取得部に転送した時点から、加入者情報取得部から転送される呼接続要求信号を受信するまでの処理が無駄になる。
しかしながら、上述のように、受信した呼接続要求信号のうち、加入者情報取得部を除く装置から受信した呼接続要求信号を規制対象信号とするため、呼制御サーバにおいて無駄な処理を行うことを回避しつつ、効率よく呼制御サーバの規制を行うことができる。
【発明の効果】
【００２２】
本発明によれば、呼制御サーバでは、受信した呼接続要求信号を加入者情報取得部に転送した後、加入者情報取得部から転送されるこの呼接続要求信号を再度受信するが、呼接続要求信号の送信元装置が、前記加入者情報取得部を除く装置である呼接続要求信号を規制対象信号とし、この規制対象信号の受信数に基づき規制が必要かを判断し規制対象信号を規制するため、呼制御サーバにおいて無駄な処理を行うことを回避しつつ、効率よく呼制御サーバの規制を行うことができる。
【図面の簡単な説明】
【００２３】
【図１】本発明を適用した通信システムの一例を示す概略構成図である。
【図２】第１の実施形態における規制処理の処理手順の一例を示すフローチャートである。
【図３】規制方法を説明するための説明図である。
【図４】第１の実施形態の動作説明に供する説明図である。
【図５】第１の実施形態の動作説明に供する説明図である。
【図６】第２の実施形態における通信システムの一例を示す概略構成図である。
【図７】第２の実施形態における規制処理の処理手順の一例を示すフローチャートである。
【図８】従来のＣＳＣＦサーバの規制方法を説明するための説明図である。
【図９】従来のＣＳＣＦサーバの規制方法を説明するための説明図である。
【発明を実施するための形態】
【００２４】
以下、本発明の実施の形態を、図面を参照して説明する。なお、以下の説明において参照する各図では、他の図と同等部分は同一符号によって示されている。
なお、一般的な電話接続処理およびその構成については説明を省略する。
（第１実施形態）
まず、本発明の第１の実施形態を説明する。
【００２５】
（全体構成）
図１は、第１の実施の形態における呼制御サーバを適用したＣＳＣＦを含むＩＭＳ（IP Multimedia Subsystem）網を備えた通信システムの構成を示す図である。ＩＭＳ網は、ＩＰ（Internet Protocol）上において音声ならびにマルチメディアサービスを取り扱う通信網である。
通信システムは、発信端末と着信端末との間の呼の制御（確立や切断など）を実行するネットワークシステムであり、移動体通信に関する移動通信システムの一部である。
図１（ａ）はともにＩＭＳ網に属する発信端末１と着信端末１１との間で呼接続を行う場合のＩＮＶＩＴＥ信号の流れを表し、図１（ｂ）は、ＩＭＳ網に属する発信端末（図示せず）とＩＭＳ網に属する着信端末２１との間で呼接続を行う場合のＩＮＶＩＴＥ信号の流れを表す。
【００２６】
ＩＭＳ網に属する携帯端末間で呼接続を行う場合には、図１（ａ）に示すように、発信端末１からの呼接続要求に伴い送信されるＩＮＶＩＴＥ信号は、発信端末１から、発側のＧＷ（発）２、発側のＣＳＣＦ（発）３、発側のＣＳ−ＡＳ（発）４に転送され、ＣＳ−ＡＳ（発）４でＨＳＳ５を参照し、ＩＮＶＩＴＥ信号に対して所定の情報を付加するなどの処理が行われた後、ＣＳ−ＡＳ（発）４からＣＳＣＦ（発）３を介して、着信端末１１を管理するＣＳＣＦ（着）１３に送信される。
着側のＣＳＣＦ（着）１３は、受信したＩＮＶＩＴＥ信号を、ＣＳ−ＡＳ（着）１４に送信し、ＣＳ−ＡＳ（着）１４でＩＮＶＩＴＥ信号に対して所定の情報を付加するなどの処理が行われた後、ＣＳＣＦ（着）１３からＧＷ（着）１２を介して着信端末１１に送信される。
【００２７】
ここで、発側のＣＳＣＦ（発）３は、発信端末１と着信端末１１とを通信接続するために呼制御を実行する呼制御装置である。ＣＳＣＦ（発）３は、着信端末の加入者識別子や着信端末の携帯電話番号などを含むＩＮＶＩＴＥ信号を、発側のＧＷ（発）２を介して発信端末１から受信し、これをＣＳ−ＡＳ（発）４に転送する。また、ＣＳＣＦ（発）３は、ＣＳ−ＡＳ（発）４から受信した、着信端末１１と通信可能な着側のＣＳＣＦ（着）１３やＣＳ−ＡＳ（着）１４のアドレス情報などを含むＩＮＶＩＴＥ信号を取得し、これに基づき、着信端末１１と通信可能なＣＳＣＦ（着）１３宛にＩＮＶＩＴＥ信号を送信する。
【００２８】
着側のＣＳＣＦ（着）１３は、発側のＣＳＣＦ（発）３からＩＮＶＩＴＥ信号を受信すると、ＣＳ−ＡＳ（着）１４に送信し、ＣＳ−ＡＳ（着）１４においてＨＳＳ１５を参照し、所定の情報を付加するなどの処理が行われたＩＮＶＩＴＥ信号をＣＳ−ＡＳ（着）１４から受信し、ＧＷ（着）１２を介して着信端末１１に転送する。
また、ＣＳＣＦ３、１３は、ＩＮＶＩＴＥ信号に基づき規制処理を行い、受信したＩＮＶＩＴＥ信号の送信元の装置に応じてＩＮＶＩＴＥ信号を規制し、ＩＮＶＩＴＥ信号の規制を行ったことを表す「規制遭遇Causeエラー」を、ＩＮＶＩＴＥ信号の送信元の装置に送信する。
【００２９】
また、ＣＳＣＦ３は、ＣＳＣＦ１３から「規制遭遇Causeエラー」を受信したときには、音源ＭＲＦＣ／Ｐ（Media Resource Function Controller／Processor）６から、「回線が混み合っておりつながりにくいため切断する」旨の音声ガイダンス情報を取得し、ＧＷ（発）２を介して発信端末１に通知する。なお、ＣＳＣＦ（発）３においてＩＮＶＩＴＥ信号に対する規制を行った場合にも、音声ガイダンスを発信端末１に通知する構成とすることも可能である。
【００３０】
ＣＳ−ＡＳ４、１４は、それぞれ対応するＣＳＣＦ３、１３から受信したＩＮＶＩＴＥ信号に基づき、それぞれ対応するＨＳＳ５、１５を参照し、ＨＳＳ５、１５から、着信端末１１を管理するＣＳＣＦ（着）１３やＣＳ−ＡＳ（着）１４のアドレス情報など、所定の情報を取得し、必要に応じて、取得した情報を受信したＩＮＶＩＴＥ信号に付加し、これを対応するＣＳＣＦに送信する。
【００３１】
ＨＳＳ５、１５は、携帯端末の加入者識別子と、この携帯端末の呼制御を実行するＣＳＣＦ３、１３やＣＳ−ＡＳ４、１４のアドレス情報などとが関連付けられた加入者情報を記憶するデータベースサーバである。加入者識別子は、携帯端末の加入者を示す識別情報であり、ＣＳＣＦ３、１３やＣＳ−ＡＳ４、１４のアドレス情報は、その携帯端末が在圏するエリアに対応づけられ、当該携帯端末と現在通信可能である、ＣＳＣＦ３、１３やＣＳ−ＡＳ４、１４を示す装置識別情報である。これらＣＳＣＦ３、１３やＣＳ−ＡＳ４、１４などのアドレス情報は、携帯端末があるエリアから他のエリアに移動する度に、その携帯端末が在圏エリアを示す位置情報に基づいて更新される。なお、ＨＳＳ５、１５には、上述の加入者情報の他にも、呼制御を実行するための各種情報が含まれている。
【００３２】
一方、他の通信網に属する携帯端末とＩＭＳ網に属する携帯端末との間で呼接続を行う場合には、図１（ｂ）に示すように、他の通信網に属する発信端末（図示せず）からの呼接続要求はＭＧＷ２６で受信され、この呼接続要求に対応するＩＮＶＩＴＥ信号は、ＭＧＷ２６から、ＣＳＣＦ（着）２３を経てＣＳ−ＡＳ（着）２４に転送され、ＣＳ−ＡＳ（着）２４でＨＳＳ２５を参照して所定の情報を付加するなどの処理が行われた後、ＣＳ−ＣＦ（着）２３、ＧＷ（着）２２を経て、着信端末２１に送信される。
【００３３】
ここで、着側のＣＳＣＦ（着）２３は、ＭＧＷ２６からＩＮＶＩＴＥ信号を受信すると、このＩＮＶＩＴＥ信号をＣＳ−ＡＳ（着）２４に送信し、ＣＳ−ＡＳ（着）２４において所定の情報を付加するなどの処理が行われたＩＮＶＩＴＥ信号をＣＳ−ＡＳ（着）２４から受信し、ＧＷ（着）２２を介して着信端末２１に転送する。
また、ＣＳＣＦ（着）２３は、ＩＮＶＩＴＥ信号に基づき規制処理を行い、受信したＩＮＶＩＴＥ信号の送信元の装置に応じて、ＩＮＶＩＴＥ信号を規制する。
【００３４】
なお、ＣＳＣＦ３、ＣＳＣＦ１３、ＣＳＣＦ２３は、同一の機能構成を有し、同一のＩＭＳ網に属する携帯端末間で呼接続を行うとき、発側のＣＳＣＦとして動作する場合には前記発側のＣＳＣＦ（発）３と同様に動作し、着側のＣＳＣＦとして動作するときには前記着側のＣＳＣＦ（着）１３と同様に動作し、他の通信網に属する発信端末とＩＭＳ網に属する受信端末との間で呼接続を行うときには前記着側のＣＳＣＦ（着）２３と同様に動作する。
同様に、ＣＳ−ＡＳ４、１４、２４は同一の機能構成を有し、ＨＳＳ５、１５、２５も同一の機能構成を有する。
【００３５】
次に、ＣＳＣＦ（３、１３、２３）において実行される規制処理を説明する。
図２は、規制処理の処理手順の一例を示すフローチャートである。
図２に示すように、ＣＳＣＦは、ＩＮＶＩＴＥ信号を受信すると、受信したＩＮＶＩＴＥ信号の送信元の装置を判定する（ステップＳ１）。
この送信元装置の判定は、ＩＮＶＩＴＥ信号に基づき行う。
ここで、ＩＮＶＩＴＥ信号は、当該ＩＮＶＩＴＥ信号の送信元を特定する情報を格納するｖｉａヘッダを含んでいる。そして、ＧＷ、ＣＳＣＦ、ＣＳ−ＡＳ、ＭＧＷでは、ＩＮＶＩＴＥ信号を送信する際に、自装置を特定するための識別情報をｖｉａヘッダに付加して送信する。このとき、ＧＷ、ＣＳＣＦ、ＭＧＷでは、ＩＮＶＩＴＥ信号のｖｉａヘッダに、自装置を特定するための識別情報を順次付加するが、ＣＳ−ＡＳでは、ｖｉａヘッダに既に格納されている送信元装置を特定するための識別情報を、自ＣＳ−ＡＳを特定する識別情報に書き換えるようになっている。
【００３６】
ＣＳＣＦでは、ＩＮＶＩＴＥ信号のｖｉａヘッダを参照することにより、送信元装置を判定する。そして、送信元装置がＣＳ−ＡＳである場合には、このＩＮＶＩＴＥ信号は規制対象信号ではないとして、ＩＮＶＩＴＥ信号の規制は行わず、ステップＳ２に移行し、ＣＳ−ＡＳから受信したＩＮＶＩＴＥ信号に対する呼接続処理を継続する。
一方、送信元装置が、ＣＳ−ＡＳを除く他の装置である場合には、このＩＮＶＩＴＥ信号は規制対象信号であるとして、ＣＳＣＦでは、このＩＮＶＩＴＥ信号を規制する。
【００３７】
すなわち、送信元装置がＧＷであるときには、ステップＳ１からステップＳ４に移行し、単位時間あたりにＧＷから受信するＩＮＶＩＴＥ数を計測するためのカウンタを、「１」だけインクリメントし、ＩＮＶＩＴＥ受信数をカウントアップする。ここでＧＷからのＩＮＶＩＴＥ受信数を「Ａ」とする。
次いで、ステップＳ５に移行し、ＩＮＶＩＴＥ受信数Ａが、予め設定した規定値「ａ」以下であるかを判断する。そして、ａ≧ＡであるときにはステップＳ１０に移行し、ＩＮＶＩＴＥ信号の規制は行わず、ＧＷから受信したＩＮＶＩＴＥ信号に対する呼制御処理を継続する。
【００３８】
一方、ａ＜ＡであるときにはステップＳ６に移行し、ＩＮＶＩＴＥ信号の規制を行う。すなわち、単位時間あたりのＩＮＶＩＴＥ受信数Ａが規定値ａを上回るため、ＣＳＣＦが過負荷状態となる可能性があり規制が必要と判断しＩＮＶＩＴＥ信号の規制を行う。
具体的には、このＩＮＶＩＴＥ信号に対する呼制御処理を中止し、規制遭遇呼であることを表すエラー応答を送信元の装置に返信する。例えば、エラー応答（ＳＩＰ  ５０３）として、「規制遭遇Causeエラー」を設定し、これを送信元の装置すなわちＧＷ（発）に送信する。なお、ＣＳＣＦにおいて、「混み合っているためつながりにくい」旨の音声ガイダンスを発信端末に通知するための音声ガイダンス情報を、音源ＭＲＦＣ／Ｐ６から取得し、ＩＮＶＩＴＥ信号の送信元の装置、すなわちＧＷ（発）を介して発信端末１に送信するようにしてもよい。
【００３９】
また、ステップＳ１の処理で、送信元装置が、他のＣＳＣＦであると判断される場合には、ＩＮＶＩＴＥ信号を受信したＣＳＣＦ（つまり着側のＣＳＣＦ）では、ステップＳ１からステップＳ１１に移行し、単位時間あたりに他のＣＳＣＦから受信するＩＮＶＩＴＥ数を計測するためのカウンタを、「１」だけインクリメントし、ＩＮＶＩＴＥ受信数をカウントアップする。ここで他のＣＳＣＦからのＩＮＶＩＴＥ受信数を「Ｂ」とする。
【００４０】
次いで、ステップＳ１２に移行し、ＩＮＶＩＴＥ受信数Ｂが、予め設定した規定値「ｂ」以下であるかを判断する。そして、ｂ≧ＢであるときにはステップＳ１０に移行し、ＩＮＶＩＴＥ信号の規制は行わず、他のＣＳＣＦから受信したＩＮＶＩＴＥ信号に対する呼制御処理を継続する。
一方、ｂ＜Ｂであるときには、着側のＣＳＣＦ（着）１３は、ステップＳ１３に移行し、ステップＳ６での処理と同様の手順でＩＮＶＩＴＥ信号の規制を行い、エラー応答（ＳＩＰ  ５０３）として、「規制遭遇Causeエラー」を、ＩＮＶＩＴＥ信号の送信元の装置である発側のＣＳＣＦ（発）３に送信する。「規制遭遇Causeエラー」を通知された発側のＣＳＣＦ（発）３では、音源ＭＲＦＣ／Ｐ６から音声ガイダンス情報を取得し、「混み合っているためつながりにくい」旨の音声ガイダンスを、発信端末に送信する。
【００４１】
また、ステップＳ１の処理で、送信元装置がＭＧＷであると判断される場合には、ＣＳＣＦでは、ステップＳ１からステップＳ１５に移行し、単位時間あたりにＭＧＷから受信するＩＮＶＩＴＥ数を計測するためのカウンタを、「１」だけインクリメントし、ＩＮＶＩＴＥ受信数をカウントアップする。ここでＭＧＷからのＩＮＶＩＴＥ受信数を「Ｃ」とする。
【００４２】
次いで、ステップＳ１６に移行し、ＩＮＶＩＴＥ受信数Ｃが、予め設定した規定値「ｃ」以下であるかを判断する。そして、ｃ≧ＣであるときにはステップＳ１０に移行し、ＩＮＶＩＴＥ信号の規制は行わず、ＭＧＷから受信したＩＮＶＩＴＥ信号に対する呼制御処理を継続する。
一方、ｃ＜ＣであるときにはステップＳ１７に移行し、ステップＳ６での処理と同様の手順でＩＮＶＩＴＥ信号の規制を行う。
【００４３】
なお、この場合、他の通信網が、音声ガイダンス情報を受付可能な通信網である場合には、他の通信網側において、ＭＧＷ２６からエラー応答（ＳＩＰ  ５０３）として「規制遭遇Causeエラー」を受信したときには、他の通信網を構成する図示しない音源ＭＲＦＣ／Ｐなどから音声ガイダンス情報を取得し、これを発信端末に送信する構成とすることで、他の通信網においても発信端末に音声ガイダンスにより通知するようにしてもよい。
【００４４】
また、ステップＳ１の処理で、送信元装置が、「その他の装置」であると判断される場合には、ＣＳＣＦでは、ステップＳ１からステップＳ２１に移行し、単位時間あたりに「その他の装置」から受信するＩＮＶＩＴＥ数を計測するためのカウンタを、「１」だけインクリメントし、ＩＮＶＩＴＥ受信数をカウントアップする。ここで「その他の装置」からのＩＮＶＩＴＥ受信数を「Ｄ」とする。なお、ここでいう「その他の装置」とは、例えば、ＣＳＣＦに直接接続される、携帯端末などのことをいう。
【００４５】
次いで、ステップＳ２２に移行し、ＩＮＶＩＴＥ受信数Ｄが、予め設定した規定値「ｄ」以下であるかを判断する。そして、ｄ≧ＤであるときにはステップＳ１０に移行し、ＩＮＶＩＴＥ信号の規制は行わず、「その他の装置」から受信したＩＮＶＩＴＥ信号に対する呼制御処理を継続する。一方、ｄ＜ＤであるときにはステップＳ２３に移行し、ステップＳ６での処理と同様の手順でＩＮＶＩＴＥ信号の規制を行う。
【００４６】
なお、この場合も、ＣＳＣＦにおいて、「混み合っているためつながりにくい」旨の音声ガイダンスを発信端末に通知するための音声ガイダンス情報を、音源ＭＲＦＣ／Ｐ６から取得し、ＩＮＶＩＴＥ信号の送信元の装置、すなわちＧＷ（発）を介して発信端末１に送信するようにしてもよい。
前記規制を行うか否かを判断するための規定値ａ〜ｄは、それぞれ送信元の装置毎に設定される。例えば、ＣＳＣＦにおいて、各装置からのＩＮＶＩＴＥ信号に対して処理を行う各処理部での処理性能や、ＣＳＣＦ全体の処理性能などに応じて決定される、各装置から１秒あたりに受付可能なＩＮＶＩＴＥ信号の数に設定される。また、ＩＮＶＩＴＥ受信数Ａ〜Ｄは、単位時間（例えば１秒）毎に零にクリアされる。
【００４７】
その結果、図３に示すように、単位時間あたりのＩＮＶＩＴＥ受信数が規定値以下である場合には、このＩＮＶＩＴＥ信号に対する呼接続処理は継続される。一方、単位時間あたりのＩＮＶＩＴＥ受信数が規定値を上回るときには、この規定値を上回る状態で受信したＩＮＶＩＴＥ信号（図３のハッチング部分に相当）については呼接続処理が中止される。これによって、ＣＳＣＦが過負荷となることを回避するようになっている。
【００４８】
次に、上記第１の実施形態の動作を、図４を伴って説明する。
前記図１（ａ）に示すように、ともにＩＭＳ網に属する発信端末１と着信端末１１との間で呼接続を行う場合には、発信端末１からセッション開始を表すＩＮＶＩＴＥ信号が送信されると、このＩＮＶＩＴＥ信号は、ＧＷ（発）２を介してＣＳＣＦ（発）３に送信される。図４（ａ）中に示すように、この時点で、ＩＮＶＩＴＥ信号（〔ＳＩＰ  ＩＮＶＩＴＥ〕）のｖｉａヘッダには、送信元装置として例えば、「Ｖｉａ：ＧＷ  ＩＰａｄｄ」が設定される。
【００４９】
ＣＳＣＦ（発）３では、ＩＮＶＩＴＥ信号を受信したことから図２に示す規制処理が行われる。この場合、ＩＮＶＩＴＥ信号の送信元装置は、ＧＷ（発）２であるため、図２のステップＳ１からステップＳ４に移行し、ＩＮＶＩＴＥ受信数Ａがインクリメントされる。このとき、比較的回線が混雑しておらず、ＩＮＶＩＴＥ受信数Ａが規定値ａ以下であれば呼接続処理が継続され、ＣＳＣＦ（発）３では、ＩＮＶＩＴＥ信号をＣＳ−ＡＳ（発）４に転送し、ＣＳ−ＡＳ（発）４においてＨＳＳ５を参照することなどにより所定の情報が付加されたＩＮＶＩＴＥ信号をＣＳ−ＡＳ（発）４から受信する。
【００５０】
このとき、ＣＳＣＦ（発）３からＣＳ−ＡＳ（発）４へのＩＮＶＩＴＥ信号のｖｉａヘッダには、送信元装置として例えば、「Ｖｉａ：ＣＳＣＦ（発）  ＩＰａｄｄ、Ｖｉａ：ＧＷ（発）  ＩＰａｄｄ」と設定され、ＣＳ−ＡＳ（発）４からＣＳＣＦ（発）３へのＩＮＶＩＴＥ信号のｖｉａヘッダには、送信元装置として例えば、「Ｖｉａ：ＣＳ−ＡＳ（発）  ＩＰａｄｄ」と設定される。
【００５１】
そして、ＣＳＣＦ（発）３では、ＣＳ−ＡＳ（発）４からＩＮＶＩＴＥ信号を受信した時点で、再度図２に示す規制処理が行われ、ＩＮＶＩＴＥ信号の送信元装置は、ＣＳ−ＡＳ（発）４であるため、図２のステップＳ１からステップＳ２に移行し、呼接続処理が継続され、ＣＳＣＦ（発）４はＩＮＶＩＴＥ信号を着側のＣＳＣＦ（着）１３に送信する。
【００５２】
ＣＳＣＦ（着）１３では、ＣＳＣＦ（発）３からＩＮＶＩＴＥ信号を受信したことから、図２に示す規制処理を実行し、図２のステップＳ１からステップＳ１１に移行し、「他のＣＳＣＦ」からのＩＮＶＩＴＥ受信数Ｂをインクリメントし、ＩＮＶＩＴＥ受信数Ｂが規定値ｂ以下であれば呼接続処理が継続され、すなわちＩＮＶＩＴＥ信号がＣＳ−ＡＳ（着）１４に転送され、ＣＳ−ＡＳ（着）１４では、ＨＳＳ１５から取得した所定情報を付加するなどした後、ＩＮＶＩＴＥ信号をＣＳＣＦ（着）１４に送信する。
ＣＳＣＦ（着）１４では、ＩＮＶＩＴＥ信号を受信した時点で、図２に示す規制処理を実行するが、送信元装置はＣＳ−ＡＳ（着）１４であるため呼接続処理を継続し、ＧＷ（着）１２を介して着信端末１１にＩＮＶＩＴＥ信号を送信する。
【００５３】
なお、このとき、ＣＳＣＦ（発）３からＣＳＣＦ（着）１３へのＩＮＶＩＴＥ信号のｖｉａヘッダには、送信元装置として例えば、「Ｖｉａ：ＣＳＣＦ（発）  ＩＰａｄｄ、Ｖｉａ：ＣＳ−ＡＳ（発）  ＩＰａｄｄ」と設定される。ＣＳＣＦ（着）１３からＣＳ−ＡＳ（着）１４へのＩＮＶＩＴＥ信号のｖｉａヘッダには、送信元装置として例えば、「Ｖｉａ：ＣＳＣＦ（着）  ＩＰａｄｄ、Ｖｉａ：ＣＳＣＦ（発）  ＩＰａｄｄ、Ｖｉａ：ＣＳ−ＡＳ（発）  ＩＰａｄｄ」と設定される。ＣＳ−ＡＳ（着）１４からＣＳＣＦ（着）１３へのＩＮＶＩＴＥ信号のｖｉａヘッダには、送信元装置として例えば、「Ｖｉａ：ＣＳ−ＡＳ（着）  ＩＰａｄｄ」と設定される。ＣＳＣＦ（着）１３からＧＷ（着）１２へのＩＮＶＩＴＥ信号のｖｉａヘッダには、送信元装置として例えば、「Ｖｉａ：ＣＳＣＦ（着）  ＩＰａｄｄ、Ｖｉａ：ＣＳ−ＡＳ（着）  ＩＰａｄｄ」と設定される。
【００５４】
以上により、通信回線が比較的混雑していないときには、規制されることなく呼接続処理が行われる。
一方、通信回線が比較的混雑している場合には、ＣＳＣＦ（発）３がＧＷ（発）２からＩＮＶＩＴＥ信号を受信した段階、または、ＣＳＣＦ（着）１３がＣＳＣＦ（発）３からＩＮＶＩＴＥ信号を受信した段階で、ＩＮＶＩＴＥ受信数Ａ、またはＩＮＶＩＴＥ受信数Ｂが、それぞれの規定値ａまたはｂを上回っているときに規制され、このＩＮＶＩＴＥ信号を破棄するなどによりこのＩＮＶＩＴＥ信号に対する呼接続処理が中止される。
【００５５】
そして、ＧＷ（発）２からＩＮＶＩＴＥ信号をＣＳＣＦ（発）３で受信した段階で規制する場合には、図４（ａ）に破線矢印で示すように「規制遭遇Causeエラー」が、ＧＷ（発）２を介して発信端末１に送信される。
また、ＣＳＣＦ（着）１３がＣＳＣＦ（発）３からＩＮＶＩＴＥ信号を受信した段階で規制する場合には、図５（ａ）に破線矢印で示すように、ＣＳＣＦ（着）１３から「規制遭遇Causeエラー」がＣＳＣＦ（発）３に送信され、さらにＣＳ−ＡＳ（発）４に転送され、ＨＳＳ５を参照して所定の情報が付加されるなどの処理が行われた後、「規制遭遇Causeエラー」は、ＣＳ−ＡＳ（発）４からＣＳＣＦ（発）３に転送される。これをうけて、ＣＳＣＦ（発）３により、音源ＭＲＦＣ／Ｐ６から音声ガイダンス情報が読み出され、「混み合っているためつながりにくい」旨のガイダンスが発信端末１に通知される。これにより、発信端末１のユーザは、回線混雑のため、呼接続を行うことができなかったことを認識することができる。
【００５６】
ここで、過負荷防止のために規制を行うためには、呼制御を確立するためのＩＮＶＩＴＥ信号を受信するタイミングで規制するか否かの判断を行うことが好ましい。
仮に、例えばＣＳＣＦ（発）３が、ＣＳ−ＡＳ（発）からＩＮＶＩＴＥ信号を受信した段階で規制する構成とした場合、ＣＳＣＦ（発）３が、ＣＳ−ＡＳ（発）４からＩＮＶＩＴＥ信号を受信した時点では、ＣＳＣＦ（発）３およびＣＳ−ＡＳ（発）４では、発信端末１からのＩＮＶＩＴＥ信号に対する処理、すなわち、ＩＮＶＩＴＥ信号をＣＳＣＦ（発）３からＣＳ−ＡＳ（発）４に転送し、ＩＮＶＩＴＥ信号をＣＳ−ＡＳ（発）４からＣＳＣＦ（発）３に転送する処理を既に行っているため、ＣＳＣＦ（発）３が、ＣＳ−ＡＳ（発）４からＩＮＶＩＴＥ信号を受信した時点でＩＮＶＩＴＥ信号に対する規制を行うことは、このＩＮＶＩＴＥ信号に対してこれまで行った処理が無駄になってしまい、すなわち、ＣＳＣＦ（発）３では無駄な処理を行うことになる。
【００５７】
しかしながら、上述のように第１実施形態におけるＣＳＣＦ（発）３では、図２の規制処理に示すように、ＩＮＶＩＴＥ信号の送信元装置を特定し、ＧＷ（発）２からのＩＮＶＩＴＥ信号は規制対象信号として規制し、ＣＳ−ＡＳ（発）４からのＩＮＶＩＴＥ信号は規制対象信号ではないとして、規制しないようにしているため、ＩＮＶＩＴＥ信号を規制することに伴って、ＣＳＣＦ（発）３が無駄な処理を行うことを回避することができる。
同様に、ＣＳＣＦ（着）１３では、ＣＳＣＦ（発）３からのＩＮＶＩＴＥ信号を規制し、ＣＳ−ＡＳ（着）１４からのＩＮＶＩＴＥ信号は規制しないようにしているため、ＩＮＶＩＴＥ信号を規制することに伴って、ＣＳＣＦ（着）１３が無駄な処理を行うことを回避することができる。
【００５８】
また、例えば、前記図１（ｂ）に示すように、他の通信網に属する発信端末１とＩＭＳ網に属する着信端末１１との間で呼接続を行う場合には、図４（ｂ）に示すように、他の通信網に属する発信端末から呼接続要求が行われると、ＩＮＶＩＴＥ信号がＭＧＷ２６からＣＳＣＦ（着）２３を経てＣＳ−ＡＳ（着）２４に転送され、ＨＳＳ２５を参照することなどにより所定の情報が付加されたＩＮＶＩＴＥ信号がＣＳ−ＡＳ（着）２４からＣＳＣＦ（着）２３、ＧＷ（着）２２を経て、着信端末２１に送信される。
【００５９】
なお、ＭＧＷ２６からＩＮＶＩＴＥ信号を受信したＣＳＣＦ（着）２３が、着信端末と通信可能なＣＳＣＦではない場合には、ＣＳ−ＡＳ（着）２４を介してＨＳＳ２５から取得したアドレス情報など基づき着信端末と通信可能なＣＳＣＦ（着）にＩＮＶＩＴＥ信号を送信し、着信端末と通信可能なＣＳＣＦ（着）からＧＷ（着）を介して着信端末にＩＮＶＩＴＥ信号を送信する。
【００６０】
このとき、ＣＳＣＦ（着）２３が着信端末２１と通信可能なＣＳＣＦ（着）であるとすると、ＣＳＣＦ（着）２３では、ＭＧＷ２６からＩＮＶＩＴＥ信号を受信した時点およびＣＳ−ＡＳ（着）２４からＩＮＶＩＴＥ信号を受信した時点で、図２に示す規制処理を実行する。このときの、ＭＧＷ２６からＣＳＣＦ（着）２３へのＩＮＶＩＴＥ信号のｖｉａヘッダには、図４（ｂ）中に示すように、送信元装置として例えば、「Ｖｉａ：ＭＧＷ  ＩＰａｄｄ」と設定される。ＣＳＣＦ（着）２３からＣＳ−ＡＳ（着）２４へのＩＮＶＩＴＥ信号のｖｉａヘッダには、送信元装置として例えば、「Ｖｉａ：ＣＳＣＦ（着）  ＩＰａｄｄ、Ｖｉａ：ＭＧＷ  ＩＰａｄｄ」と設定される。ＣＳ−ＡＳ（着）２４からＣＳＣＦ（着）２３へのＩＮＶＩＴＥ信号のｖｉａヘッダには、送信元装置として例えば、「Ｖｉａ：ＣＳ−ＡＳ（着）  ＩＰａｄｄ」と設定される。ＣＳＣＦ（着）２４からＧＷ（着）２２へのＩＮＶＩＴＥ信号のｖｉａヘッダには、送信元装置として例えば、「Ｖｉａ：ＣＳＣＦ（着）  ＩＰａｄｄ、Ｖｉａ：ＣＳ−ＡＳ（着）  ＩＰａｄｄ」と設定される。
【００６１】
ここで、比較的通信回線が混雑していなければ、ＭＧＷ２６からＩＮＶＩＴＥ信号を受信した時点でのＩＮＶＩＴＥ受信数Ｃは規定値ｃ以下となり、また、ＣＳ−ＡＳ（着）２４からのＩＮＶＩＴＥ信号に対して規制は行わないから、ＣＳＣＦ（着）２３では呼制御を継続する。比較的通信回線が混雑している場合などには、ＣＳ−ＡＳ（着）２４からのＩＮＶＩＴＥ信号に対しては規制を行わないが、ＭＧＷ２６からＩＮＶＩＴＥ信号を受信した時点でのＩＮＶＩＴＥ受信数Ｃが規定値を超えると、この時点でＩＮＶＩＴＥ信号の規制が行われ、図５（ｂ）に破線矢印で示すように、ＣＳＣＦ（着）２３から「規制遭遇Causeエラー」がＭＧＷ２６を介して他の通信網に送信される。
【００６２】
したがって、ＭＧＷ２６からのＩＮＶＩＴＥ信号に対する処理を、ＣＳＣＦ（着）２３およびＣＳ−ＡＳ（着）２４において行う前の段階で規制を行うことができ、また、ＣＳ−ＡＳ（着）２４からのＩＮＶＩＴＥ信号に対しては規制を行わないため、ＭＧＷ２６からのＩＮＶＩＴＥ信号に対する処理を、ＣＳＣＦ（着）２３およびＣＳ−ＡＳ（着）２４において既に行った後の時点でこのＩＮＶＩＴＥ信号を規制することはない。このため、このＩＮＶＩＴＥ信号に対してＣＳＣＦ（着）２３およびＣＳ−ＡＳ（着）２４において行った処理が無駄になることはない。
【００６３】
このように、第１の実施形態においては、ＣＳＣＦに入力されるＩＮＶＩＴＥ信号の送信元装置がＣＳ−ＡＳである場合には規制を行わず、送信元装置がＣＳ−ＡＳではない場合に規制を行うようにしているため、ＩＮＶＩＴＥ信号に対する処理が、ＣＳＣＦおよびＣＳ−ＡＳにおいて既に行われた後のＩＮＶＩＴＥ信号を規制することはない。したがって、ＩＮＶＩＴＥ信号に対してＣＳＣＦおよびＣＳ−ＡＳにおいて、既に行われた処理が無駄になることはなく、ＩＮＶＩＴＥ信号の規制を効率よく行うことができ、結果的に、ＣＳＣＦを効率よく作動させることができる。
【００６４】
いいかえれば、ＩＮＶＩＴＥ信号の規制の目的は、ＣＳＣＦの処理負荷を軽減することであるため、ＩＮＶＩＴＥ信号に対する処理が、ＣＳＣＦおよびＣＳ−ＡＳにおいて既に行われた時点でＩＮＶＩＴＥ信号を規制することは、ＣＳＣＦの処理負荷の軽減効果は少なく、却って無駄な処理を行うことになり効率が悪い。しかしながら、上述のように、ＣＳ−ＡＳからＣＳＣＦに入力されるＩＮＶＩＴＥ信号を除く他の装置からＩＮＶＩＴＥ信号を受信した時点で規制を行うため、ＣＳＣＦが無駄な処理を行うことを回避し、ＣＳＣＦの処理負荷の軽減を効果的に行うことができる。
【００６５】
また、ＩＮＶＩＴＥ信号の送信元の装置の判断は、ＩＮＶＩＴＥ信号のｖｉａヘッダに格納された送信元情報に基づき行っており、この送信元情報は、３ＧＰＰ（Third Generation Partner Project）規格により、通常ｖｉａヘッダに格納されるように決められている情報である。したがって、送信元情報を新たにＩＮＶＩＴＥ信号に付加するなどの変更を伴うことなく容易に実現することができる。
【００６６】
なお、上記第１の実施の形態においては、図２に示す規制処理において、ＩＮＶＩＴＥ信号の送信元装置が、ＣＳ−ＡＳ、ＧＷ、ＣＳＣＦ、ＭＧＮ、「その他の装置」のいずれであるかを特定し、ＣＳ−ＡＳを除く装置からのＩＮＶＩＴＥ信号の場合には、それぞれ個別にＩＮＶＩＴＥ受信数をカウントする場合について説明したが、これに限るものではない。
【００６７】
例えば、送信元装置がＣＳ−ＡＳであるかそれ以外の装置であるかを判断し、ＣＳ−ＡＳ以外の装置からのＩＮＶＩＴＥ信号についてはまとめてＩＮＶＩＴＥ受信数としてカウントアップする構成としてもよい。
また、ＩＮＶＩＴＥ信号の送信元の装置が、ＧＷ、ＣＳＣＦ、ＭＧＮ、「その他の装置」の場合に、これら装置毎にＩＮＶＩＴＥ受信数をカウントする場合について説明したが、これに限るものではない。例えば、「その他の装置」についてもこの「その他の装置」に含まれる装置ごとにＩＮＶＩＴＥ受信数をカウントする構成としてもよい。
【００６８】
或いは、前述のＩＮＶＩＴＥ信号の送信元の装置のうち、複数の装置をまとめてＩＮＶＩＴＥ受信数をカウントする構成としてもよい。
例えば、ＣＳＣＦにおいて、ＧＷからのＩＮＶＩＴＥ信号を処理する処理部とＭＧＷからのＩＮＶＩＴＥ信号を処理する処理部とが共通であり、ＧＷからのＩＮＶＩＴＥ信号とＭＧＮからのＩＮＶＩＴＥ信号とのそれぞれに対する、共通の処理部での処理負荷や、これらＩＮＶＩＴＥ信号に対する処理で使用するソフトおよびハードリソースなどが完全に同一である場合などには、ＧＷからのＩＮＶＩＴＥ信号とＭＧＷからのＩＮＶＩＴＥ信号とをまとめて、これらのＩＮＶＩＴＥ受信数をカウントする構成としてもよい。
【００６９】
このように１つにまとめることによって集約効果により、ＧＷからのＩＮＶＩＴＥ信号およびＭＧＷからのＩＮＶＩＴＥ信号を処理する共通の処理部では、ＩＮＶＩＴＥ数の規定値ａとＩＮＶＩＴＥ数の規定値ｃとの和「ａ＋ｃ」相当までＩＮＶＩＴＥ信号を受け付けることができる。
したがって、例えば、ＧＷからのＩＮＶＩＴＥ受信数Ａがその規定値ａを上回る場合であっても、「ａ＋ｃ」を下回るときには、ＧＷからのＩＮＶＩＴＥ受信数Ａを受け付けることができ、ＭＧＷからのＩＮＶＩＴＥ受信数Ｃが零である場合には、「ａ＋ｃ」まで受け付けることができる。また、集約効果により規制判定処理が少なくなるため、処理負荷軽減を図ることができる。
【００７０】
なお、このように集約した場合、ＣＳＣＦではＧＷからのＩＮＶＩＴＥ信号と、ＭＧＷからのＩＮＶＩＴＥ信号とを区別なくカウントするため、ＣＳＣＦがＩＮＶＩＴＥ信号を受信するタイミングによっては、これらＧＷからのＩＮＶＩＴＥ信号とＭＧＷからのＩＮＶＩＴＥ信号との間で、ＣＳＣＦが受け付けるＩＮＶＩＴＥ信号数に偏りが生じる可能性がある。したがって、この点を考慮して、いずれの装置からのＩＮＶＩＴＥ信号どうしを集約するかを決定することが好ましい。
【００７１】
次に、本発明の第２の実施形態を説明する。
この第２の実施形態は、上記第１の実施の形態において、ＣＳＣＦでの規制方法が異なること以外は同一であるので、同一部の詳細な説明は省略する。
この第２の実施形態では、発信端末で呼接続要求時に送信するＩＮＶＩＴＥ信号に、当該呼接続要求を、他の呼接続要求と区別するための識別情報である「ｃａｌｌ−ＩＤ」を付加して送信する。この呼接続要求に関与する各装置では、この呼接続要求に伴う「ＩＮＶＩＴＥ信号」を受信した時点から呼接続処理が終了する「ＢＹＥ信号」を受信するまでの間にこの呼接続要求に伴って授受される各種信号について、この「ｃａｌｌ−ＩＤ」を含んだ状態で授受するようになっている。また、ＣＳＣＦは、図６（ａ）および（ｂ）に示すように、複数の「ｃａｌｌ−ＩＤ」を記憶するためのテーブルＴを備えている。ＣＳＣＦでは、このテーブルＴに、ＩＮＶＩＴＥ信号から抽出した「ｃａｌｌ−ＩＤ」を登録し、登録した時点から予め設定した単位時間が経過した時点で「ｃａｌｌ−ＩＤ」をテーブルから削除するようになっている。前記単位時間は、ＣＳＣＦが、一の呼接続処理に伴うＩＮＶＩＴＥ信号を初めて受信した時点、すなわち、ある「ｃａｌｌ−ＩＤ」を有するＩＮＶＩＴＥ信号をＣＳＣＦが初めて受信した時点から、この「ｃａｌｌ−ＩＤ」を有するＩＮＶＩＴＥ信号をＣＳ−ＡＳから受信するのに十分な時間に設定される。
【００７２】
図７は、第２の実施形態において、ＣＳＣＦで実行される規制処理の処理手順の一例を示すフローチャートである。
この第２の実施の形態における規制処理は、図７に示すように、ＩＮＶＩＴＥ信号を受信すると、ＣＳＣＦでは、まず、ステップＳ３１で、受信したＩＮＶＩＴＥ信号に含まれる「ｃａｌｌ−ＩＤ」を抽出し、この「ｃａｌｌ−ＩＤ」が、自ＣＳＣＦのテーブルＴに記憶されているかを判断する。そして、抽出した「ｃａｌｌ−ＩＤ」がテーブルＴに記憶されていなければ、このＩＮＶＩＴＥ信号は規制対象信号であると判断し、ステップＳ３２に移行して抽出した「ｃａｌｌ−ＩＤ」をテーブルＴに追加記憶する。次いでステップＳ３３に移行し、ＩＮＶＩＴＥ受信数Ｇをインクリメントする。次いで、ステップＳ３４に移行し、ＩＮＶＩＴＥ受信数Ｇが予め設定した規定値「ｇ」以下であるかを判断する。すなわち、上記第１の実施形態と同様に、図３に示すように、ある単位時間において、単位時間あたりのＩＮＶＩＴＥ受信数Ｇが規定値ｇを上回るとき、以後、この単位時間において受信したＩＮＶＩＴＥ信号は規制遭遇呼としてこのＩＮＶＩＴＥ信号を規制する。
【００７３】
そして、ｇ≧Ｇである場合には、回線が混み合っていないと判断して、ステップＳ３５に移行し、呼接続処理を継続する。一方、ｇ＜Ｇである場合には、回線が混み合っていると判断し、ステップＳ３６に移行し、ＩＮＶＩＴＥ信号の規制を行う。すなわち、上記第１の実施の形態と同様に、このＩＮＶＩＴＥ信号に対する呼制御処理は行わず、規制遭遇呼であることを表すエラー応答を送信元の装置に返信する。例えば、エラー応答（ＳＩＰ  ５０３）として、「規制遭遇Causeエラー」を設定し、これを送信元の装置に返信する。
【００７４】
前記規制を行うか否かを判断するための規定値ｇは、単位時間（例えば１秒）あたりのＣＳＣＦで受付可能なＩＮＶＩＴＥ数に設定される。また、ＩＮＶＩＴＥ受信数Ｇは、単位時間（例えば１秒）毎に零にクリアされる。
一方、前記ステップＳ３１で、受信したＩＮＶＩＴＥ信号から抽出した「ｃａｌｌ−ＩＤ」が、テーブルＴに記憶されているときには、このＩＮＶＩＴＥ信号は規制対象信号であると判断し、ステップＳ３７に移行し、呼接続処理を継続する。
【００７５】
次に、上記第２の実施形態の動作を説明する。
図６（ａ）に示すように、ともにＩＭＳ網に属する発信端末１と着信端末１１との間で呼接続を行う場合、発信端末１では、セッション開始を表すＩＮＶＩＴＥ信号を送信する際に、この呼接続処理を識別する「ｃａｌｌ−ＩＤ」をＩＮＶＩＴＥ信号に付加して送信する。ＩＮＶＩＴＥ信号は、ＧＷ（発）２を介してＣＳＣＦ（発）３に転送される。
【００７６】
ＣＳＣＦ（発）３では、ＩＮＶＩＴＥ信号を受信したことから図７に示す規制処理を行う。この時点では、ＩＮＶＩＴＥ信号に含まれる「ｃａｌｌ−ＩＤ」は、テーブルＴに登録されていないことから、ステップＳ３１からステップＳ３２に移行し、抽出した「ｃａｌｌ−ＩＤ」をテーブルＴに追加し、ＩＮＶＩＴＥ受信数Ｇをインクリメントする。
このとき、回線が混み合っており、単位時間あたりのＩＮＶＩＴＥ受信数Ｇが規定値ｇ以上であるときには、ステップＳ３４からステップＳ３６に移行し、この時点でＩＮＶＩＴＥ信号の規制が行われる。このため、ＩＮＶＩＴＥ信号は、発側のＣＳＣＦ（発）３からＣＳ−ＡＳ（発）４に転送されない。
【００７７】
一方、回線が混み合っておらず、単位時間あたりのＩＮＶＩＴＥ受信数Ｇが規定値ｇ以下であるときには、ステップＳ３４からステップＳ３５に移行し、呼接続処理が継続される。すなわち、このＩＮＶＩＴＥ信号は、ＣＳＣＦ（発）３からＣＳ−ＡＳ（発）４に転送され、ＨＳＳ５から取得した情報を付加するなどの処理が行われた後、ＣＳ−ＡＳ（発）４からＣＳＣＦ（発）３に転送される。
【００７８】
ＣＳＣＦ（発）３は、ＩＮＶＩＴＥ信号を受信したことから図７の規制処理を行い、この場合、受信したＩＮＶＩＴＥ信号に含まれる「ｃａｌｌ−ＩＤ」は、先にテーブルＴに登録されているため、ステップＳ３１からステップＳ３７に移行し、このＩＮＶＩＴＥ信号に対する呼接続処理を継続する。すなわち、ＩＮＶＩＴＥ信号を着側のＣＳＣＦ（着）１３に転送する。
【００７９】
着側のＣＳＣＦ（着）１３は、ＩＮＶＩＴＥ信号を受信したことから、図７に示す規制処理を実行するが、このＩＮＶＩＴＥ信号に含まれる「ｃａｌｌ−ＩＤ」は、この時点では、テーブルＴに登録されていないから、ステップＳ３１からステップＳ３２、Ｓ３３を経てステップＳ３４に移行し、回線が混雑していなければステップＳ３５に移行し、呼接続処理を継続する。
【００８０】
そして、ＣＳＣＦ（着）１３がＣＳ−ＡＳ（着）１４からＩＮＶＩＴＥ信号を受信した時点で、再度図７に示す規制処理が行われるが、この時点ではこのＩＮＶＩＴＥ信号に含まれる「ｃａｌｌ−ＩＤ」は、テーブルＴに登録されているため、ステップＳ３１からステップＳ３７に移行し、このＩＮＶＩＴＥ信号に対する呼接続処理が継続され、着信端末１１との呼接続処理が継続される。
【００８１】
一方、回線が混み合っており、着側のＣＳＣＦ（着）１３において、単位時間あたりのＩＮＶＩＴＥ受信数Ｇが規定値ｇを上回るときには、ステップＳ３４からステップＳ３６に移行し、ＩＮＶＩＴＥ信号の規制が行われ、ＩＮＶＩＴＥ信号の送信元の装置である発側のＣＳＣＦ（発）３に対し、エラー応答（ＳＩＰ  ５０３）として、「規制遭遇Causeエラー」が送信される。
このため、この「ｃａｌｌ−ＩＤ」で識別される呼接続処理は、ＩＮＶＩＴＥ信号が、着側のＣＳＣＦ（着）１３に転送された時点で終了する。また、この「規制遭遇Causeエラー」を受信した発側のＣＳＣＦ（発）３では、音源ＭＲＦＣ／Ｐ６から音声ガイダンス情報を取得し、これを発信端末１に通知する。
【００８２】
このように、発側のＣＳＣＦ（発）３および着側のＣＳＣＦ（着）１３ともに、ＩＮＶＩＴＥ信号に対するＡＳ−ＣＳでの処理が行われた後の段階では、このＩＮＶＩＴＥ信号に対する規制は行わず、ＩＮＶＩＴＥ信号をＡＳ−ＣＳを除く装置から受信した時点でのみＩＮＶＩＴＥ信号に対する規制を行う構成としたため、ＣＳＣＦおよびＡＳ−ＣＳにおいてＩＮＶＩＴＥ信号に対する処理が行われた後の段階で、このＩＮＶＩＴＥ信号を規制することを回避することができ、すなわち、ＣＳＣＦおよびＡＳ−ＣＳでのＩＮＶＩＴＥ信号に対する処理が無駄になることを回避し、ＣＳＣＦの負荷軽減を効率よく行うことができる。
【００８３】
また、例えば、図６（ｂ）に示すように、他の通信網に属する発信端末とＩＭＳ通信網に属する着信端末２１との間で呼接続を行う場合には、他の通信網に所属する発信端末から呼接続要求が行われると、ＭＧＷ２６からＩＮＶＩＴＥ信号がＣＳＣＦ（着）２３を介してＣＳ−ＡＳ（着）２４に転送され、ＣＳＣＦ（着）２３は、ＣＳ−ＡＳ（着）２４から転送されるＩＮＶＩＴＥ信号から着信端末２４と通信可能なＣＳＣＦのアドレスなどのアドレス情報を取得し、ＣＳＣＦ（着）２３が着信端末２１と通信可能なＣＳＣＦ（着）である場合には、ＧＷ（着）２２を介して着信端末２１にＩＮＶＩＴＥ信号を送信する。なお、着信端末２１と通信可能なＣＳＣＦ（着）２３ではない場合には、ＩＮＶＩＴＥ信号によってＨＳＳ２５から取得したアドレス情報に基づき着信端末２１と通信可能なＣＳＣＦ（着）２３にＩＮＶＩＴＥ信号を送信し、着信端末２１と通信可能なＣＳＣＦ（着）からＧＷ（着）を介して着信端末にＩＮＶＩＴＥ信号を送信する。
【００８４】
このとき、ＣＳＣＦ（着）２３が着信端末２１と通信可能なＣＳＣＦであるものとすると、ＣＳＣＦ（着）２３では、ＭＧＷ２６からＩＮＶＩＴＥ信号を受信した時点およびＣＳ−ＡＳ（着）２４からＩＮＶＩＴＥ信号を受信した時点で、図７に示す規制処理を実行する。
つまり、ＭＧＷ２６からＩＮＶＩＴＥ信号を受信した時点で、ＩＮＶＩＴＥ信号に含まれる「ｃａｌｌ−ＩＤ」をテーブルＴに登録してＩＮＶＩＴＥ信号の規制を行うかを判断し（ステップＳ３１〜Ｓ３４）、ＩＮＶＩＴＥ信号を規制しないときには、ＩＮＶＩＴＥ信号をＣＳ−ＡＳ（着）２４に転送し、ＣＳ−ＡＳ（着）２４からＩＮＶＩＴＥ信号を受信した時点で「ｃａｌｌ−ＩＤ」がテーブルＴに登録されているため、ステップＳ３１からステップＳ３７に移行し、ＩＮＶＩＴＥ信号の規制は行わない。
【００８５】
一方、回線が混み合っている場合には、ＭＧＷ２６からＣＳＣＦ（着）２３がＩＮＶＩＴＥ信号を受信した時点で、ＩＮＶＩＴＥ受信数Ｇが規定値ｇよりも大きいときにＩＮＶＩＴＥ信号の規制が行われ、「規制遭遇Causeエラー」がＩＮＶＩＴＥ信号の送信元の装置であるＭＧＷ２６を介して他の通信網に送信される。そして、他の通信網側では、必要に応じて「回線が混み合っておりつながりにくいため切断する」旨の音声ガイダンス情報を、音源ＭＲＦＣ／Ｐ（図示せず）から取得し、これを発信端末（図示せず）に送信する。
【００８６】
したがって、ＩＮＶＩＴＥ信号に対する、ＣＳＣＦ（着）２３およびＣＳ−ＡＳ（着）２４での処理が行われる前の時点で規制を行うことができる。
このように、第２の実施形態においても、ＣＳＣＦでは、ＣＳ−ＡＳからＩＮＶＩＴＥ信号を受信したときにはＩＮＶＩＴＥ信号の規制は行わず、ＣＳ−ＡＳを除く装置からＩＮＶＩＴＥ信号を受信したときにのみ規制を行うため、ＩＮＶＩＴＥ信号に対するＣＳＣＦおよびＡＳ−ＣＳでの処理が行われる前の段階で、このＩＮＶＩＴＥ信号を規制することができる。したがって、この第２の実施形態においても上記第１の実施形態と同等の作用効果を得ることができる。
【００８７】
ここで、上記実施形態において、ＩＮＶＩＴＥ信号が呼接続要求信号に対応し、ＣＳ−ＡＳが加入者情報取得部に対応し、ＣＳＣＦサーバが呼制御サーバに対応している。
また、第１の実施形態において、図２のステップＳ１の処理が送信元装置判別部に対応し、ステップＳ４、Ｓ５、ステップＳ１１、Ｓ１２、ステップＳ１５、Ｓ１６、ステップＳ２１、Ｓ２２の処理が規制判断部に対応し、ステップＳ６、Ｓ１３、Ｓ１７、Ｓ２３の処理が信号規制部に対応し、ｖｉａヘッダに含まれる送信元装置を特定するための識別情報が送信元識別情報に対応している。
【００８８】
また、第２の実施形態において、図７のステップＳ３１、Ｓ３２の処理が送信元装置判別部に対応し、ステップＳ３３、Ｓ３４の処理が規制判断部に対応し、ステップＳ３６の処理が信号規制部に対応している。また、「ｃａｌｌ−ＩＤ」が信号識別情報に対応し、テーブルＴが記憶部に対応し、図７のステップＳ３１の処理が登録状況判断部に対応し、ステップＳ３１およびステップＳ３２の処理が規制対象信号特定部に対応している。
【符号の説明】
【００８９】
１  発信端末
２、１２、２２  ＧＷ
３、１３、２３  ＣＳＣＦ
４、１４、２４  ＣＳ−ＡＳ
５、１５、２５  ＨＳＳ
６  音源ＭＲＦＣ／Ｐ
２６  ＭＧＷ
【図１】
0005784522.tif 000002
【図２】
0005784522.tif 000003
【図３】
0005784522.tif 000004
【図４】
0005784522.tif 000005
【図５】
0005784522.tif 000006
【図６】
0005784522.tif 000007
【図７】
0005784522.tif 000008
【図８】
0005784522.tif 000009
【図９】
0005784522.tif 000010