(57)【要約】【課題】他網からの接続数を抑制し、自網内の呼処理装置の負荷を低減する。【解決手段】ＥＮＵＭサーバ３０は、自網内の各呼処理装置から、着信先番号が付された呼についてのトラヒック情報を収集し、その着信先番号ごとに単位時間当たりの呼量を集計して呼量集計情報３３１として記憶するとともに、他網から受信したＥＮＵＭクエリに付された着信先番号を抽出し、呼量集計情報３３１を参照して、当該着信先番号の呼量が所定の閾値を超えている場合に、当該着信先番号の呼が輻輳状態であると判定する輻輳検知部３２２と、輻輳状態であると判定された着信先番号が付されたＥＮＵＭクエリに対し、所定の規制処理に基づき、当該ＥＮＵＭクエリを規制対象にするか否かを決定する規制処理部３２３と、規制対象に決定されたＥＮＵＭクエリについて、接続不可であることを示すＥＮＵＭアンサを生成し、他網に返信する信号応答部３２５と、を備える。【選択図】図２
2020127158.tif 000002
【特許請求の範囲】
【請求項１】
発信端末を収容する他網からのＥＮＵＭクエリを受信し、当該ＥＮＵＭクエリに付された自網が管理する着信端末の着信先番号に対応する接続先情報を、前記他網に返信するＥＮＵＭサーバであって、
前記他網からのＥＮＵＭクエリを受信する信号受信部と、
前記自網内の各呼処理装置から、前記着信先番号が付された呼についてのトラヒック情報を収集し、前記着信先番号ごとに単位時間当たりの呼量を集計して呼量集計情報として記憶部に記憶するとともに、受信した前記ＥＮＵＭクエリに付された着信先番号を抽出し、前記呼量集計情報を参照して、当該着信先番号の前記呼量が所定の閾値を超えている場合に、当該着信先番号の呼が輻輳状態であると判定する輻輳検知部と、
前記輻輳状態であると判定された着信先番号が付されたＥＮＵＭクエリに対し、所定の規制処理に基づき、当該ＥＮＵＭクエリを規制対象にするか否かを決定する規制処理部と、
前記規制対象に決定されたＥＮＵＭクエリについて、接続不可であることを示すＥＮＵＭアンサを生成し、前記他網に返信する信号応答部と、
を備えることを特徴とするＥＮＵＭサーバ。
【請求項２】
発信端末を収容する他網からのＥＮＵＭクエリを受信し、当該ＥＮＵＭクエリに付された自網が管理する着信端末の着信先番号に対応する接続先情報を、前記他網に返信するＥＮＵＭサーバの輻輳制御方法であって、
前記ＥＮＵＭサーバは、
前記自網内の各呼処理装置から、前記着信先番号が付された呼についてのトラヒック情報を収集し、前記着信先番号ごとに単位時間当たりの呼量を集計して呼量集計情報として記憶手段に記憶するステップと、
前記他網からのＥＮＵＭクエリを受信するステップと、
受信した前記ＥＮＵＭクエリに付された着信先番号を抽出し、前記呼量集計情報を参照して、当該着信先番号の前記呼量が所定の閾値を超えている場合に、当該着信先番号の呼が輻輳状態であると判定するステップと、
前記輻輳状態であると判定された着信先番号が付されたＥＮＵＭクエリに対し、所定の規制処理に基づき、当該ＥＮＵＭクエリを規制対象にするか否かを決定するステップと、
前記規制対象に決定されたＥＮＵＭクエリについて、接続不可であることを示すＥＮＵＭアンサを生成し、前記他網に返信するステップと、
を実行することを特徴とする輻輳制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＩＰ（Internet Protocol）電話等の電話番号を、ＵＲＩ（Uniform Resource Identifiers）に対応付けて名前解決を行うＥＮＵＭ（E.164 Number Mapping）の技術分野であり、ＥＮＵＭサーバおよび輻輳制御方法に関する。
【背景技術】
【０００２】
従来、ＩＰ網において、通信事業者網内の装置（呼制御サーバ等）が、電話番号とＵＲＩ（Uniform Resource Identifier）との対応付けを行う仕組みとしてＥＮＵＭシステムが提案されている。このＥＮＵＭシステムでは、通信事業者のネットワーク内に設置された呼制御サーバ（ＳＩＰ（Session Initiation Protocol）サーバ）が、接続先となる端末（ＩＰ電話等）の電話番号についての接続先情報（ＩＰアドレスや、ドメイン名等）をＥＮＵＭサーバに問い合わせて、その接続先情報に基づいてルーティングを行う。なお、ＥＮＵＭシステムでは、呼制御サーバが、ＥＮＵＭプロトコルに準拠したＥＮＵＭクエリ（ＥＮＵＭ信号）を生成し、接続先情報（ＩＰアドレスや、ドメイン名等）を問い合わせる。
【０００３】
具体的には、図６に示すように、ＥＮＵＭシステム９００では、端末１から自網（発信側の通信事業者網：発事業者網）のＳＩＰサーバ２が、接続要求（ＳＩＰ信号）を受け付け（ステップＳ６１）、ＥＮＵＭクエリ（ＥＮＵＭ信号）を生成して、着信先情報に対応する接続先情報の要求をＥＮＵＭサーバ３に送信する（ステップＳ６２）。ＥＮＵＭサーバ３は、その着信先情報で示される着信先の番号が自網（発事業者網）で管理する電話番号である場合には、自身の接続先情報ＤＢ（DataBase）から、その着信先情報に対応する接続先情報を取得してＥＮＵＭアンサ（ＥＮＵＭ信号）を生成し、自網のＳＩＰサーバ２に返信して（ステップＳ６３）、自網の着信先端末と呼接続を行う（ステップＳ６４）。
【０００４】
一方、図７は、着信先情報で示される着信先の番号が他網（着信側の通信事業者網：着事業者網）で管理する電話番号である場合を示す図である。
この場合に、ＥＮＵＭシステム９００では、端末１から自網（発事業者網）のＳＩＰサーバ２が、接続要求（ＳＩＰ信号）を受け付け（ステップＳ７１）、ＥＮＵＭクエリ（ＥＮＵＭ信号）を生成して、着信先情報に対応する接続先情報の要求をＥＮＵＭサーバ３に送信する（ステップＳ７２）。発事業者網のＥＮＵＭサーバ３は、着信先情報で示される着信先の番号が他網（着信側の通信事業者網：着事業者網）で管理する電話番号である場合には、その電話番号を管理する着事業者網のＥＮＵＭサーバ３に、ＥＮＵＭクエリを送信する（ステップＳ７３）。他網のＥＮＵＭサーバ３は、自身の接続先情報ＤＢ（DataBase）から、その着信先情報に対応する接続先情報を取得してＥＮＵＭアンサ（ＥＮＵＭ信号）を生成し、発事業者網のＥＮＵＭサーバ３に返信する（ステップＳ７４）。発事業者網のＥＮＵＭサーバ３は、取得したＥＮＵＭアンサを、自網のＳＩＰサーバ２に返信する（ステップＳ７５）。発事業者網のＳＩＰサーバ２は、取得した接続先情報が自網ではなく、他網であるため、他網（着事業者網）のＳＩＰサーバ２に接続要求を送信することにより着事業者網の着信先端末１と呼接続を行う（ステップＳ７６）。
【０００５】
このＥＮＵＭサーバは、通信事業者網内に設定される複数の呼制御サーバ等からアクセスを受け付ける、さらに、１つの呼制御サーバが収容する端末（ＩＰ電話等）の台数も多いため、全体として膨大な端末からのアクセスを受け付けることとなる。
ＥＮＵＭクエリでの問い合わせは、イベント等のチケット販売時や、大規模災害の発生時に、特定の番号や特定の地域への発呼が大量に発生した場合に輻輳状態となる。そして、ＥＮＵＭサーバにおいて、呼制御サーバからの問い合わせに対する応答時間が長くなったり、最悪の場合応答できなくなったりして、端末間の接続遅延の増加や接続障害が発生する。なお、イベント等のチケット販売により輻輳が発生することを企画型輻輳という。
【０００６】
企画型輻輳等により特定の着信先番号に呼が集中すると、その番号へのトラフィック量が一時的に増大し、その他の番号への呼が繋がりにくくなる等の影響がある。そのため、特定の番号を対象とした輻輳制御が行われている。
【０００７】
図８は、着信先情報で示される着信先番号が他網（着事業者網）で管理する電話番号である場合における、従来の輻輳制御を説明するための図である。
図８では、図７で示した例と同様に、発事業者網側のＥＮＵＭサーバ３が、ＥＮＵＭクエリを自網のＳＩＰサーバ２から受け付け、着信先情報で示される着信先番号が他網（着事業者網）で管理する電話番号である場合に、その電話番号を管理する着事業者網のＥＮＵＭサーバ３に要求を行い接続先情報を取得する。そして、発事業者網側のＥＮＵＭサーバ３は、接続先情報を付したＥＮＵＭアンサを、自網のＳＩＰサーバ２に送信する。発事業者網のＳＩＰサーバ２は、取得した接続先情報が自網ではなく、他網であるため、ゲートウェイ機能を備えるＮＮＩ−ＳＢＣ（Network Network Interface - Session Border Controller）４を介して、着事業者網に接続要求（ＳＩＰ信号）を送信する。発事業者網からのＳＩＰ信号を受信した着事業者網側のＮＮＩ−ＳＢＣ４は、ＣＳＣＦ（Call Session Control Function）５やＡＳ（Application Server）６等の呼処理装置に送信することにより呼接続を行う。なお、着事業者網側のＣＳＣＦ５およびＡＳ６は、発事業者側のＳＩＰサーバ２と同様に、ＳＩＰの通信プロトコルを利用したＳＩＰサーバである。着事業者網においては、企画型輻輳等の際に、他網（発事業者網）から自網（着事業者網）が管理する番号に大量のＳＩＰ信号が到達する。この場合、着事業者側の網全体のトラフィックを監視するトラフィック監視装置７が輻輳を検出し、呼を中継する装置やセッション制御する装置等の呼処理装置それぞれに対して、規制を指示している。
従来技術では、ＳＩＰ信号に対する輻輳制御が前提であり、他網（発事業者網）と接続する装置（ＮＮＩ−ＳＢＣ４等）に対しては多数のＳＩＰ信号が到達することとなり、処理負荷が増大してしまう。
【０００８】
一方、ＥＮＵＭサーバを用いた輻輳制御方式としては、ＥＮＵＭ自身の輻輳を回避するための機能や、特定の条件の呼を専用のＥＮＵＭサーバへ振り分ける機能などがある。特許文献１に記載の発明では、特定の番号への問合せが集中した場合に、その番号に対する問合せを特定のＥＮＵＭサーバへ振り分け、その他の呼への影響を低減させている。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開２０１８−１３３７５９号公報
【発明の概要】
【発明が解決しようとする課題】
【００１０】
しかしながら、上記したＥＮＵＭサーバを用いた輻輳制御方式では、ＥＮＵＭサーバそのものの負荷は低減できるものの網全体としての輻輳を回避できるものではなかった。また、図８に示したような従来の網全体の輻輳制御方式では、他網（発事業者網）から大量のＳＩＰ信号を、ＮＮＩ−ＳＢＣ４等の網内装置（呼処理装置）が受け取ってトラフィック量が増大してから、トラフィック監視装置７による輻輳制御が行われるため、自網（着事業者網）への接続数を抑制することはできなかった。よって、特に他網と接続する装置の負荷の増大を抑えることができなかった。
【００１１】
このような背景に鑑みて本発明がなされたのであり、本発明は、他網からの接続数を抑制し、自網内の呼処理装置の負荷を低減することができる、ＥＮＵＭサーバおよび輻輳制御方法を提供することを課題とする。
【課題を解決するための手段】
【００１２】
前記した課題を解決するため、請求項１に記載の発明は、発信端末を収容する他網からのＥＮＵＭクエリを受信し、当該ＥＮＵＭクエリに付された自網が管理する着信端末の着信先番号に対応する接続先情報を、前記他網に返信するＥＮＵＭサーバであって、前記他網からのＥＮＵＭクエリを受信する信号受信部と、前記自網内の各呼処理装置から、前記着信先番号が付された呼についてのトラヒック情報を収集し、前記着信先番号ごとに単位時間当たりの呼量を集計して呼量集計情報として記憶部に記憶するとともに、受信した前記ＥＮＵＭクエリに付された着信先番号を抽出し、前記呼量集計情報を参照して、当該着信先番号の前記呼量が所定の閾値を超えている場合に、当該着信先番号の呼が輻輳状態であると判定する輻輳検知部と、前記輻輳状態であると判定された着信先番号が付されたＥＮＵＭクエリに対し、所定の規制処理に基づき、当該ＥＮＵＭクエリを規制対象にするか否かを決定する規制処理部と、前記規制対象に決定されたＥＮＵＭクエリについて、接続不可であることを示すＥＮＵＭアンサを生成し、前記他網に返信する信号応答部と、を備えることを特徴とするＥＮＵＭサーバとした。
【００１３】
また、請求項３に記載の発明は、発信端末を収容する他網からのＥＮＵＭクエリを受信し、当該ＥＮＵＭクエリに付された自網が管理する着信端末の着信先番号に対応する接続先情報を、前記他網に返信するＥＮＵＭサーバの輻輳制御方法であって、前記ＥＮＵＭサーバが、前記自網内の各呼処理装置から、前記着信先番号が付された呼についてのトラヒック情報を収集し、前記着信先番号ごとに単位時間当たりの呼量を集計して呼量集計情報として記憶手段に記憶するステップと、前記他網からのＥＮＵＭクエリを受信するステップと、受信した前記ＥＮＵＭクエリに付された着信先番号を抽出し、前記呼量集計情報を参照して、当該着信先番号の前記呼量が所定の閾値を超えている場合に、当該着信先番号の呼が輻輳状態であると判定するステップと、前記輻輳状態であると判定された着信先番号が付されたＥＮＵＭクエリに対し、所定の規制処理に基づき、当該ＥＮＵＭクエリを規制対象にするか否かを決定するステップと、前記規制対象に決定されたＥＮＵＭクエリについて、接続不可であることを示すＥＮＵＭアンサを生成し、前記他網に返信するステップと、を実行することを特徴とする輻輳制御方法とした。
【００１４】
このようにすることで、ＥＮＵＭサーバは、輻輳状態にある着信先番号が付されたＥＮＵＭクエリについて規制処理を実行し、他網に対し接続不可であることを示すＥＮＵＭアンサを返信することができる。よって、他網（発信側）から自網（着信側）への接続数を抑制し、自網内の呼処理装置への負荷を軽減することができる。
【発明の効果】
【００１５】
本発明によれば、他網からの接続数を抑制し、自網内の呼処理装置の負荷を低減する、ＥＮＵＭサーバおよび輻輳制御方法を提供することができる。
【図面の簡単な説明】
【００１６】
【図１】本実施形態に係るＥＮＵＭサーバを含む輻輳制御システムの全体構成と処理概要を説明するための図である。
【図２】本実施形態に係るＥＮＵＭサーバの構成例を示す機能ブロック図である。
【図３】本実施形態に係る呼量集計情報のデータ構成例を示す図である。
【図４】本実施形態に係る接続先情報ＤＢのデータ構成例を示す図である。
【図５】本実施形態に係るＥＮＵＭサーバの処理の流れを示すフローチャートである。
【図６】従来のＥＮＵＭシステムの問い合わせ処理の流れ（自網宛て）を説明するための図である。
【図７】従来のＥＮＵＭシステムの問い合わせ処理の流れ（他網宛て）を説明するための図である。
【図８】従来の網全体のトラフィックの監視による輻輳制御を説明するための図である。
【発明を実施するための形態】
【００１７】
次に、本発明を実施するための形態（以下、本実施形態と称する。）における、ＥＮＵＭサーバ３０等について説明する。
まず、本実施形態に係るＥＮＵＭサーバ３０を含む輻輳制御システム１００について説明する。
【００１８】
図１は、本実施形態に係るＥＮＵＭサーバ３０を含む輻輳制御システム１００の全体構成と処理概要を説明するための図である。
図１で示した輻輳制御システム１００と、図８で示したシステムとの違いは、本実施形態の輻輳制御システム１００では、図８のシステムのように、着事業者網において、各呼処理装置を監視して規制制御を行うトラフィック監視装置７を設けていない。その代わり、ＥＮＵＭサーバ３０が網内の各呼処理装置のトラフィックを監視する。なお、呼処理装置は、例えば、ＮＮＩ−ＳＢＣ４、ＣＳＣＦ５、ＡＳ６等の網内装置である。また、ＣＳＣＦ５は、呼セッション制御機能を備え、発事業者網側で説明したＳＩＰサーバ２と同様の処理を着事業者網において実現する装置である。
ＥＮＵＭサーバ３０は、自網内の各呼処理装置から、着信先番号（特定番号）への発呼に関するトラフィック情報を収集する。そして、ＥＮＵＭサーバ３０は、収集した特定番号についての輻輳を検知した場合、他網（発事業者網）のＥＮＵＭサーバ３０から要求のあった、その着信先番号（特定番号）に関するＥＮＵＭクエリに対して、接続不可であることを示すＥＮＵＭアンサを返信する。接続不可であることを示すＥＮＵＭアンサを受け取った他網（発事業者網）のＳＩＰサーバ２は、着事業者網への接続先情報を得ることができず、接続要求（ＳＩＰ信号）を他網へ送信することはできない。
【００１９】
このように、ＥＮＵＭサーバ３０において、網全体のトラフィックを監視し、特定番号に対する輻輳を検出した場合に規制を行うことにより、他網（発事業者網）から自網（着事業者網）へのＳＩＰ信号の接続数を抑制することができる。よって、従来技術に比べ、規制した呼数分のＳＩＰ信号が削減でき、自網（着事業者網）内の呼処理装置への負担を軽減することができる。
【００２０】
＜ＥＮＵＭサーバ＞
次に、本実施形態に係るＥＮＵＭサーバ３０について説明する。
図２は、本実施形態に係るＥＮＵＭサーバ３０の構成例を示す機能ブロック図である。
ＥＮＵＭサーバ３０は、自網のＳＩＰサーバ２や、他網のＥＮＵＭサーバ３０からＥＮＵＭクエリによる問い合わせを受けた際に、着信先情報に対応する接続先情報を、接続先情報ＤＢ３３０を参照して抽出し、ＥＮＵＭアンサとして返信する。また、ＥＮＵＭサーバ３０は、他網（発事業者網）からのＥＮＵＭクエリによる問い合わせに対して、自網（着事業者網）においてそのＥＮＵＭクエリで示される着信先番号（特定番号）の呼において輻輳が発生していると判断した場合には、接続不可であることを示すＥＮＵＭアンサを返信する。
このＥＮＵＭサーバ３０は、入出力部３１と、制御部３２と、記憶部３３とを備える。
【００２１】
入出力部３１は、他の装置等との間の情報の入出力を行う。例えば、入出力部３１は、自網のＳＩＰサーバ２や他網のＥＮＵＭサーバ３０等との間で情報の送受信を行う。この入出力部３１は、通信回線を介して情報の送受信を行う通信インタフェースと、不図示のキーボード等の入力装置やモニタ等の出力装置との間で情報の入出力を行う入出力インタフェースとから構成される。
【００２２】
記憶部３３（記憶手段）は、ハードディスクやフラッシュメモリ、ＲＡＭ等により構成される。
この記憶部３３には、後記する呼量集計情報３３１（図３参照）および接続先情報ＤＢ３３０（図４参照）が記憶されるとともに、制御部３２の各機能を実行させるためのプログラムや、制御部３２の処理に必要な情報が一時的に記憶される。
なお、記憶部３３には、呼接続の規制に関する情報が記憶される。呼接続の規制に関する情報は、規制を開始する閾値の情報（詳細は後記）、規制を実行する際に許容するクエリ数（／秒）（例えば、50クエリ／秒）や、規制割合（例えば、「１／２」）等である。
【００２３】
制御部３２は、ＥＮＵＭサーバ３０が実行する処理の全般を司り、信号受信部３２１と、輻輳検知部３２２と、規制処理部３２３と、接続先情報検索部３２４と、信号応答部３２５とを含んで構成される。なお、この制御部３２は、例えば、このＥＮＵＭサーバ３０の記憶部３３に格納されたプログラムをＣＰＵがＲＡＭに展開し実行することにより実現される。
【００２４】
信号受信部３２１は、他網のＥＮＵＭサーバ３０および自網のＳＩＰサーバ２（ＣＳＣＦ５等）からＥＮＵＭクエリを受信する。そして、信号受信部３２１は、他網のＥＮＵＭサーバ３０から受信したＥＮＵＭクエリを、輻輳検知部３２２に出力する。また、信号受信部３２１は、自網のＳＩＰサーバ２から受信したＥＮＵＭクエリを、接続先情報検索部３２４に出力する。
【００２５】
輻輳検知部３２２は、網内の各呼処理装置（ＮＮＩ−ＳＢＣ４、ＣＳＣＦ５、ＡＳ６等）から、着信先番号（特定番号）が付された呼についてのトラフィック情報を収集して、単位時間当たりの呼量を集計し、記憶部３３内の呼量集計情報３３１として記憶する。
【００２６】
図３は、本実施形態に係る呼量集計情報３３１のデータ構成例を示す図である。
呼量集計情報３３１には、着信先番号（特定番号）ごとに、集計した単位時間あたりの呼量が格納される。
例えば、着信先番号（Ｅ．１６４番号）が「81312345555」についての呼量が「100（／秒）」として格納される。
【００２７】
輻輳検知部３２２は、所定の閾値（例えば、500／秒）を超えた着信先番号の呼を、輻輳状態であると判定する。図３においては、着信先番号が「81312347777」の呼について、呼量が「1000（／秒）」であることから、所定の閾値を超えており、輻輳状態であると判定する。
輻輳検知部３２２は、信号受信部３２１からＥＮＵＭクエリを受信すると、そのＥＮＵＭクエリに付された着信先番号（特定番号）を抽出し、呼量集計情報３３１を参照して、その着信先番号の呼が輻輳状態か否かを判定する。そして、輻輳検知部３２２は、輻輳状態であると判定した場合には、その着信先番号が付されたＥＮＵＭクエリを、規制処理部３２３に出力する。一方、輻輳検知部３２２は、輻輳状態でないと判定した場合には、そのＥＮＵＭクエリを、接続先情報検索部３２４に出力する。
【００２８】
規制処理部３２３は、輻輳状態であると判定された着信先番号が付されたＥＮＵＭクエリについて、所定の規制処理を実行する。例えば、規制処理部３２３は、単位時間当たりに許容するクエリ数（例えば、50クエリ／秒）を超えるＥＮＵＭクエリを規制対象のＥＮＵＭクエリに決定したり、規制割合（例えば、「１／２」）に応じて当該着信先番号が付されたＥＮＵＭクエリを規制対象のＥＮＵＭクエリに決定したりする。
そして、規制処理部３２３は、規制対象に決定したＥＮＵＭクエリについては、信号応答部３２５に出力する。また、規制処理部３２３は、規制対象としなかったＥＮＵＭクエリについては、接続先情報検索部３２４に出力する。
【００２９】
接続先情報検索部３２４は、ＥＮＵＭクエリを取得すると、そのクエリに付された着信先情報を抽出する。そして、接続先情報検索部３２４は、記憶部３３内の接続先情報ＤＢ３３０（図４）を参照し、その着信先情報に対応する接続先情報を検索する。接続先情報検索部３２４は、接続先情報ＤＢ３３０を検索した結果得られた接続先情報を抽出し、信号応答部３２５に処理の指示を出力する。
【００３０】
図４は、本実施形態に係る接続先情報ＤＢ３３０のデータ構成例を示す図である。
図４に示すように、接続先情報ＤＢ３３０には、着信先情報に対応付けて、接続先情報が記憶される。具体的には、着信先情報には、例えば、着信先番号（着信先の端末１の電話番号）に基づき、Ｅ．１６４番号をＥＮＵＭプロトコルのドメイン形式に変換した情報（例えば、「5.5.5.5.4.3.2.1.8.e164enum.net」）が記憶される。この着信先情報に対応付けた接続先情報には、例えば、着信先の端末１のＥ．１６４番号と、接続先の通信事業者のドメイン名（例えば、「carrier_a.ne.jp」）とを含むＵＲＩが記憶される。
【００３１】
信号応答部３２５は、接続先情報検索部３２４が接続先情報を抽出したＥＮＵＭクエリについて、その抽出した接続先情報を含むＥＮＵＭアンサを生成し、当該ＥＮＵＭクエリの送信元である、他網のＥＮＵＭサーバ３０や自網のＳＩＰサーバ２に返信する。
一方、信号応答部３２５は、規制処理部３２３が規制対象に決定したＥＮＵＭクエリについて、接続不可であることを示すＥＮＵＭアンサを生成し、他網のＥＮＵＭサーバ３０に返信する。
【００３２】
信号応答部３２５は、接続不可であることを示すＥＮＵＭアンサとして、例えば、ＥＮＵＭ標準の規格「ＪＪ−９０．３１」（「キャリアＥＮＵＭの相互接続共通インタフェース」第4.0版、2018年8月29日、一般社団法人情報通信技術委員会）で定められたアンサに関する「ＲＣＯＤＥフィールド」の設定値を、「５」（拒否）に設定したＥＮＵＭアンサを生成する。なお、設定値「５」は、事業者ポリシでＥＮＵＭアンサを返送しない場合を意味する。ただし、接続不可であることを示すＥＮＵＭアンサの設定例は、上記に限定されない。
また、信号応答部３２５は、ＥＮＵＭアンサに設定するＴＴＬ（Time To Live）を、ＥＮＵＭ標準の規格で推奨される値（60秒）よりも小さいする値にすることが望ましい。このＴＴＬの値は例えば「０」でもよく、キャッシュ生存時間を短くする（若しくは無くす）ことにより、着事業者網のＥＮＵＭサーバ３０が輻輳状態と判定した着信先番号が付されたＥＮＵＭクエリについて、キャッシュ生存時間を待たずに規制することが可能となる。
【００３３】
このように、本実施形態に係るＥＮＵＭサーバ３０によれば、輻輳状態にある着信先番号（特定番号）が付されたＥＮＵＭクエリについては規制処理を実行し、他網（発事業者網）のＥＮＵＭサーバ３０に対し接続不可のＥＮＵＭアンサを返信する。よって、他網（発事業者網）から自網（着事業者網）への接続数を抑制し、自網（着事業者網）内の呼処理装置への負荷を軽減することができる。
【００３４】
≪ＥＮＵＭサーバの処理≫
次に、本実施形態に係るＥＮＵＭサーバ３０の処理の流れを説明する。
図５は、本実施形態に係るＥＮＵＭサーバ３０の処理の流れを示すフローチャートである。なお、ここでは、自網（着事業者網）のＥＮＵＭサーバ３０が、他網（発事業者網）のＥＮＵＭサーバ３０からのＥＮＵＭクエリを受信するものとして説明する。
【００３５】
まず、ＥＮＵＭサーバ３０の輻輳検知部３２２は、自網内の各呼処理装置から、着信先番号（特定番号）が付された呼についてのトラフィック情報を収集し、単位時間当たりの呼量を集計して、記憶部３３内の呼量集計情報３３１に記憶する（ステップＳ１０）。なお、輻輳検知部３２２によるトラフィック情報の収集処理は、所定の時間間隔毎に行われ、現時点の最新の状態が格納される。
【００３６】
次に、ＥＮＵＭサーバ３０（信号受信部３２１）は、他網（発事業者網）のＥＮＵＭサーバ３０からＥＮＵＭクエリ（接続要求）を受信する（ステップＳ１１）。そして、信号受信部３２１は、受信したＥＮＵＭクエリを輻輳検知部３２２に出力する。
【００３７】
輻輳検知部３２２は、受け取ったＥＮＵＭクエリに付された着信先番号（特定番号）を抽出し、その着信先番号に対応する呼が輻輳状態か否かを判定する（ステップＳ１２）。輻輳検知部３２２は、呼量集計情報３３１（図３）を参照し、所定の閾値を超えたか否かにより、その着信先番号宛ての呼が輻輳状態であるか否かを判定する。
【００３８】
そして、輻輳検知部３２２が、その着信先番号に対応する呼が輻輳状態でないと判定した場合には（ステップＳ１２→Ｎｏ）、そのＥＮＵＭクエリに対する処理は、ステップＳ１４へ進む。
一方、輻輳検知部３２２が、輻輳状態であると判定した場合には（ステップＳ１２→Ｙｅｓ）、次のステップＳ１３に進む。
【００３９】
ステップＳ１３において、規制処理部３２３は、そのＥＮＵＭクエリについて、所定の規制処理を実行するか否かを決定する。つまり、規制処理部３２３は、規制対象となるＥＮＵＭクエリか否かを決定する。
ここで、規制処理部３２３は、例えば、単位時間当たりに許容するクエリ数を超えるＥＮＵＭクエリを規制対象のＥＮＵＭクエリに決定したり、また、規制割合に基づき当該着信先番号が付されたＥＮＵＭクエリを規制対象のＥＮＵＭクエリに決定する。
規制処理部３２３は、規制対象となるＥＮＵＭクエリでない決定した場合には（ステップＳ１３→Ｎｏ）、当該ＥＮＵＭクエリを、接続先情報検索部３２４に出力し、ステップＳ１４に進む。一方、規制処理部３２３は、規制対象となるＥＮＵＭクエリであると決定した場合には、当該クエリを、信号応答部３２５に出力し、ステップＳ１６に進む。
【００４０】
ステップＳ１４において、接続先情報検索部３２４は、そのＥＮＵＭクエリを取得すると、当該クエリに付された着信先情報を抽出する。そして、接続先情報検索部３２４は、記憶部３３内の接続先情報ＤＢ３３０（図４）を参照し、その着信先情報に対応する接続先情報を検索する。接続先情報検索部３２４は、接続先情報ＤＢ３３０を検索した結果得られた接続先情報を抽出し、信号応答部３２５に処理の指示を出力する。
【００４１】
信号応答部３２５は、接続先情報検索部３２４が接続先情報を抽出したＥＮＵＭクエリについて、その抽出した接続先情報を含むＥＮＵＭアンサを生成し、当該ＥＮＵＭクエリの送信元である、他網のＥＮＵＭサーバ３０に返信し（ステップＳ１５）、処理を終える。
【００４２】
一方、規制処理部３２３が、規制対象となるＥＮＵＭクエリであると決定した場合には（ステップＳ１３→Ｙｅｓ）、接続不可であることを示すＥＮＵＭアンサを生成して、他網のＥＮＵＭサーバ３０に返信し（ステップＳ１６）、処理を終える。
【００４３】
このようにすることで、本実施形態に係るＥＮＵＭサーバ３０および輻輳制御方法によれば、ＥＮＵＭサーバ３０が、網全体のトラフィックを監視し、着信先番号（特定番号）についての輻輳状態を検出した場合に、その着信先番号が付されたＥＮＵＭクエリについて規制を行うことにより、他網（発事業者網）から自網（着事業者網）への接続数を抑制することができる。よって、従来技術と比べ、規制した呼数分のＳＩＰ信号が削減でき、自網（着事業者網）内の呼処理装置への負担を軽減することができる。
【符号の説明】
【００４４】
１      端末
２      ＳＩＰサーバ
４      ＮＮＩ−ＳＢＣ
５      ＣＳＣＦ
６      ＡＳ
３０    ＥＮＵＭサーバ
３１    入出力部
３２    制御部
３３    記憶部（記憶手段）
３２１  信号受信部
３２２  輻輳検知部
３２３  規制処理部
３２４  接続先情報検索部
３２５  信号応答部
３３０  接続先情報ＤＢ
３３１  呼量集計情報
【図１】
2020127158.tif 000003
【図２】
2020127158.tif 000004
【図３】
2020127158.tif 000005
【図４】
2020127158.tif 000006
【図５】
2020127158.tif 000007
【図６】
2020127158.tif 000008
【図７】
2020127158.tif 000009
【図８】
2020127158.tif 000010