(57)【特許請求の範囲】
【請求項１】
物理的リソースに係るトラヒック規制を行う物理的リソース系トラヒック規制制御部と、呼の発生を検出する呼検出部と、前記呼検出部によって検出された呼に対応するトラヒック量を既定の呼種別毎に算定する呼種別トラヒック量算定部と、前記呼種別トラヒック量算定部で算定された呼種別のトラヒック量を該トラヒック量に対応する呼種別論理的リソース消費量に換算する呼種別論理的リソース消費量換算部と、前記呼種別論理的リソース消費量換算部で算定される呼種別論理的リソース消費量に関する規制の基準値を保持する呼種別論理的リソース消費量規制基準値保持部と、前記呼種別論理的リソース消費量規制基準値保持部に保持された当該基準値に基づいて前記呼種別論理的リソース消費量換算部で換算された呼種別論理的リソース消費量が既定の規制値に該当するか否かを判定する呼種別トラヒック規制要否判定部と、前記呼種別トラヒック規制要否判定部で規制値に該当すると判定されたトラヒックに関する規制を前記物理的リソース系トラヒック規制制御部によるトラヒック規制とは非排他的に且つ呼種別に実行する呼種別トラヒック規制制御部と、
を備えていることを特徴とするネットワークエンティティ。
【請求項２】
当該ネットワークエンティティがＬＴＥにおけるＣＳＣＦとして構成され、前記呼種別トラヒック規制制御部は、前記ＣＳＣＦにおける呼セッションの制御を担う呼セッション制御部において各別の呼種に応じた規制を行うように構成されていることを特徴とする請求項１に記載のネットワークエンティティ。
【請求項３】
ネットワーク上に設けられたコンピュータが、該ネットワークないしネットワークエンティティの注目点におけるトラヒック量を既定の呼種別毎に算定し、該算定された呼種別のトラヒック量を該トラヒック量に対応する呼種別の論理的リソース消費量に換算し、該換算による呼種別の論理的リソース消費量が既定の規制値との対照においてトラヒック規制を要するか否かを呼種別に判定し、規制を要すると判定されたトラヒックに関する規制を前記論理的リソースとは別異の物理的リソースに係るトラヒック規制である物理的リソース系トラヒック規制とは非排他的に実行することを特徴とするネットワークエンティティ保護方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、自己をバーストトラヒックから保護する機能を備えたネットワークエンティティ、および、ネットワークエンティティ保護方法に関する。
【背景技術】
【０００２】
一般に、音声呼（通常の電話での通話等の通信を行うための発信や着信）をサポートするために、ネットワークは物理的リソースおよび論理的リソースを割り当てる。ここに、物理的リソースとは、無線基地局におけるＲＦトランシーバおよび基地局コントローラ内のデジタル信号プロセッサ、その他、該当するノードにおける信号処理回路等の所謂ハードウェアに該当するリソースである。また、論理的リソースとは、種々のネットワークエンティティ間で呼データおよび制御情報を運ぶネットワークトランスポートチャネル、その他、ノードにおける特定のソフトウェアに依拠して発動する既定の機能等に該当するリソースである。
【０００３】
そして、有限の物理的リソースで生じるバーストトラヒックに起因する通信品質の低下を抑制しようとする技術が従来より種々提案されている。
例えば、バーストトラヒック発生時における通信品質の劣化を回避するため、無線リソース（物理的リソース）の使用状況に応じて、優先度に応じて予め設定した複数の呼受付閾値を、当該呼に係る呼受付閾値と比較し、該比較結果に基づいて当該呼に対する新規の呼受付を規制することが提案されている（例えば、特許文献１参照）。
【０００４】
特許文献１所載の技術では、より具体的には、リソース使用状況について測定値を取得するとともに、その測定値と呼受付閾値との大小を比較して新規の呼受付の許可または拒否を判断することによって、新規の呼受付の規制を効率的に実現することができるとされている。そして、呼受付の制御に用いられるリソースについては、例えば、通信に用いられる接続方式が、ＦＤＭＡ方式またはＴＤＭＡ方式であり、監視対象とされるリソースは、チャネル数、または無線機数の少なくとも１つであることが一つの特徴であるとされている。
【０００５】
また、従来の技術を詳細に解析し、より具体的な解決策を提案した特許文献も存在する（例えば、特許文献２参照）。
この特許文献２所載の技術は、発信呼、着信呼、呼設定後のデータ通信などの各種のトラヒックの処理時に、ＣＰＵリソースやメモリリソース（物理的リソース）が、該当ノードへの大量のトラヒック流入によって許容リソース使用率を超えて輻輳状態となり、ネットワーク全体のトラヒック処理能力が極端に低下する問題に対処する技術であるとされている。
【０００６】
そして、従来においても、輻輳状態を回避するために、ＴＣＳコントローラ（トラヒックコントロールシステム）が各通信装置の輻輳状態を監視し、輻輳状態を検知すると、当該通信装置に対する他の通信装置からのトラヒック量の流入量を規制する技術が存在したが、特許文献２の技術によって、このＴＣＳコントローラの更なる改善が図られることが開示されている。
【０００７】
即ち、従来のＴＣＳコントローラにおいても、通信装置で処理可能な目標トラヒック量（総量）を現実のトラヒック量が超過したことが検知すると、その通信装置の種別に応じ予め設定した目標トラヒック量以下となるようなトラヒック流入規制の実行をもって輻輳状態からの回避を図っていた。しかしながら、この目標トラヒック量を予め最適値に設定することは現実には非常に難しく、熟練した保守者が、通信装置毎の性能等を認識した上で個々に目標トラヒック量を設定する必要がある。ところが、この設定作業には規制制御の有効性確認、及び通信装置のバージョンアップや設定値誤りに対する修正作業などの処理が要求される。従って、管理が煩雑であるばかりか、設定を誤った場合には、有効な規制制御が困難であるといった現場での具体的技術課題に対処する技術である旨開示されている。
【０００８】
特許文献２の技術では、以上を踏まえ、通信ネットワークを構成する複数の通信装置のいずれかが輻輳状態になった場合に、その輻輳状態の通信装置に流入するトラヒック量を、目標トラヒック量に応じた量に規制制御して上記輻輳状態を回避する輻輳制御方法において、輻輳状態の通信装置のトラヒック負荷に基づき、輻輳中に上記目標トラヒック量を算出するものであるとされている。
【０００９】
一方、上述のようなトラヒックの制御は、３Ｇ（３rd Generation Partnership Projects）のシステムに限られず、ＬＴＥ（Long Term Evolution）のシステムにおいても同様に必要である。
図４は、ＬＴＥのシステムにおけるネットワークエンティティ間のトラヒックについて説明するための概念図である。この図では、トラヒックは細線の矢線で表されている。
【００１０】
図４において、左側の系において、不図示の端末装置からゲートウェイ４１０に到達したトラヒックは、ルーティングを担うノードであるＣＳＣＦ（Call Session Control Function）４２０、および、交換機能を担うノードであるＣＳ−ＡＳ（Circuit Switched Application Server）４３０を通して、ユーザプロパティ情報を保有するＨＳＳ（Home Subscriber Server）４4０に送信先の問い合わせが行われる。
【００１１】
そして、該問い合わせへの応答に従って、ＣＳ−ＡＳ４３０、ＣＳＣＦ４２０を経て、図にて右側の系におけるＣＳＣＦ４２０ａ→ＣＳ−ＡＳ４３０ａ→ＨＳＳ４4０ａ→ＣＳ−ＡＳ４３０ａ→ＣＳＣＦ４２０ａのルートで、ゲートウェイ４１０ａから外部の相手方の端末装置ないしサーバに接続される。
この場合、ＣＳＣＦ４２０では、従来の技術によって、通例の如く、接続されている外部のサーバ（ノード）からのバーストトラヒックの流入を抑止するように、当該外部のサーバ（ノード）においてＣＳＣＦ４２０へ送るトラヒックに関する規制が実行される。
【００１２】
また、ＣＳＣＦ４２０内においても、特許文献１、或いは、特許文献２所載の技術におけるように、自己（ＣＳＣＦ４２０）へのバーストトラヒックの流入規制も実行され得る。
発明者は、上述のようなバーストトラヒックの規制とその効果等について種々考察を加えた。次に、これらの考察について、以下に、図面を参照して説明する。
【００１３】
図５は、サーバ（例えば、図４におけるＣＳＣＦ４２０等のネットワークエンティティ）に故障や通信品質の低下等の機能不全が発生する要因を２つの種別に区分して考察した結果を表す図である。尚、図５の全体によって表された例は、後述するように、種々考察の結果想到したトラヒックの規制に関する一つの理想像であり、従来の通信システムに対する分析結果を表すものではない。
【００１４】
図５（ａ）は、上記機能不全の発生要因となる事象を２つの種別に区分して考察した場合における、トラヒック（バーストトラヒック）に課すべき規制に係る注目因子、および、規制の基準を表す図である。
また、図５（ｂ）は、図５（ａ）における機能不全の発生要因を２つの種別に区分して、それぞれに課すべき規制の条件を可視化した図である。
図５（ａ）および図５（ｂ）における考察では、機能不全の発生要因を物理的リソースと論理的リソースとに区分している。
【００１５】
既述のとおり、物理的リソースとは、無線基地局におけるＲＦトランシーバおよび基地局コントローラ内のデジタル信号プロセッサ、その他、該当するノードにおける信号処理回路（ＣＰＵ）等である。また、論理的リソースとは、種々のネットワークエンティティ間で呼データおよび制御情報を運ぶネットワークトランスポートチャネル、その他、該当するノードにおける特定のソフトウェアに依拠して発動する既定の機能等である。
【００１６】
図５（ａ）を参照して理解される通り、この考察は、ネットワークエンティティの機能不全の発生要因を物理的リソースと論理的リソースとに区分し、該区分による発生要因毎にトラヒック（バーストトラヒック）の規制の形態を考えようとするものである。
そして、図５（ａ）の例では、当該ネットワークエンティティにおける機能不全の発生要因が物理的リソースである場合には、トラヒック規制を考えるに際して上記機能不全発生に係る注目因子を、ハードウェアのリソース（即ち、物理的リソース）の使用率としている。
【００１７】
物理的リソースは、その稼働状況を計測値として評価し管理するには馴染み易い。例えば、トラヒック量の計測は、電話に関するものでは呼から、データ通信に関するものではメッセージやトランザクションからそれぞれ計測することができる。このため、従来のバーストトラヒックの規制は、押しなべて、この物理的リソースに係る稼働状況を計測し管理するものであった。
また、ハードウェアのリソースの使用率は、例えば、該当するノードに適用されたサーバコンピュータの仕様上の能力に対する使用率として定義し得る。この場合には、トラヒック規制の基準として、動作保証されている ハードウェアリソース（上記の例では、サーバコンピュータのＣＰＵ）の使用率が適用され得る。
【００１８】
一方、ネットワークエンティティの機能不全の発生要因として論理的リソースを考える場合には、この論理的リソースに該当する事象が数百種類に上るため、各別に評価することが困難である。発明者は、この状況に鑑み種々検討の結果、トラヒック規制を考えるに際しての当該ネットワークエンティティにおける機能不全発生に係る注目因子として、単位時間当りの受付け呼数を用いることが妥当であると推定するに到った。上述のように、トラヒック規制を考えるに際しての当該ネットワークエンティティにおける機能不全発生に係る注目因子を単位時間当りの受付け呼数とする場合、トラヒック規制の基準としては、通常のトラヒック（例えば、既定期間の常態でのトラヒック数）とすることが概ね妥当であると考えられる。
【００１９】
図５（ａ）を参照して説明した物理的リソースに関する規制、および、論理的リソースに関する規制の双方を充足する状態が、図５（ｂ）に表された許容領域Ｚ５１であり、この領域に該当する状態では規制の発動を要しない。
また、物理的リソースに関する規制、および、論理的リソースに関する規制の何れかでも規制に抵触する状態が図５（ｂ）に表された非許容領域Ｚ５２であり、この領域に該当する状態のときに規制の発動を要することになる。
【００２０】
図６は、図５の考え方における更なる課題について説明するための図である。
図５を参照して説明したバーストトラヒックの規制に係る考察では、リソースを物理的リソースと共に論理的リソースをも併せ勘案する一方、呼の種別については別段の配慮をしないで所謂総量規制を行うことを条件とするという前提であった。これに対し、図６を参照して説明するケースでは、呼の種別毎のトラヒックの動静に係る視点で考察を加えたものである。
【００２１】
図６（ａ）は呼の種別（以下、呼種という）Ａ、Ｂ、Ｃ、Ｄ毎に、トラヒック量、従って、これに対応するリソースの状況に着目した考察の結果を表している。
図６（ａ）における右側の「規制値未満」と表記された状況は、リソースの稼働が規制の基準値未満である場合を表している。即ち、呼種Ａ、呼種Ｂ、呼種Ｃ、および、呼種Ｄは、個々において、何れも呼種別の規制値未満であって、当然に、それらの総和も規制の基準値未満である。従って、呼種別および総量の何れの点でも規制発動に到らない状態である。
【００２２】
図６（ａ）における左側の「バーストトラヒック発生時」と表記されたケースはバーストトラヒック規制に該当する状況を表している。呼種Ｃおよび呼種Ｄが何れも呼種別の規制の基準値未満であり、一方、呼種Ａおよび呼種Ｂについては図中ＡｅおよびＢｅと表記の程度だけ呼種別の規制値を上回っており、これらについて規制を発動することが必要になる。この場合、呼種別のリソース占有率ではウェイトの高い呼種Ｃが規制値を大幅に下回っているため、全呼種Ａ〜Ｄのトラヒック量の総和は、マージンＭＧを残して規制の基準値（対応するリソースの使用率）を下回っている。
【００２３】
図６（ａ）を参照して説明した呼種別のバーストトラヒック規制は、既述の特許文献における提案例のように、従来、物理的リソースに関するものであった。これは、従来における通信システムでは、物理的リソースの稼働率と論理的リソースの稼働率とが常時対を成すが如くに相関が深いため、計測し管理するに馴染み易い物理的リソースに注目してバーストトラヒックの規制を行えば、該当ノード（該当するサーバ、ないし、その他のネットワークエンティティ）の保護や通信品質の維持等の目的を達成するには十分であったからである。
【００２４】
しかしながら、発明者等は、通信システムの将来像について種々検討を加える途上で、既述の従来の技術思想のように、物理的リソースの稼働率と論理的リソースの稼働率とが常時対を成すが如くに相関が深いものであるとの前提に立脚して技術的解決手段を講じるのみでは通信システム内で現実に生じるであろう現象とは最早乖離してしまう状況が出現することを予見するに到った。
【００２５】
即ち、物理的リソースに該当するコンピュータやその他の電子デバイスの著しい性能向上に伴って、同一のハードウェア上で実行される多種多様に亘る論理的リソースに該当する各種処理の不均衡に起因して、該当するネットワークエンティティが機能を全うできなくなる事態を予防する技術の必要を予見した。
図６（ｂ）は、従来の如く物理的リソースに関してバーストトラヒックに規制をかける場合の問題点について説明するための図である。
【００２６】
既述の図５（ｂ）の例では、物理的リソースと論理的リソースとの双方の何れか一方でも基準値を超過した場合（領域Ｚ５２に該当する場合）にはバーストトラヒックに規制をかけるものであったが、図６（ｂ）では、論理的リソースについてのみ規制をかけている。
即ち、図６（ｂ）における領域Ｚ６１は物理的リソースおよび論理的リソースの双方に係る各基準値未満の領域である許容領域であり、図５（ｂ）における領域Ｚ５１に対応する。従って、この領域Ｚ６１では規制の発動を要しない。
【００２７】
一方、物理的リソースの基準値を超過している領域Ｚ６２では、従来の如く、バーストトラヒックに規制がかけられる。他方、論理的リソースの基準値を超過する領域Ｚ６３は、図５（ｂ）の例における領域Ｚ５２の一部に該当する領域であり、理想的には規制が必要とされるが、既述の従来の通信システムでは規制されることがない。従って、この領域Ｚ６３に該当する状況下では、該当するネットワークエンティティが機能不全を生じる虞がある。
【先行技術文献】
【特許文献】
【００２８】
【特許文献１】特開２００２−２２３２３９号公報
【特許文献２】特開２００３−３０９５９９号公報
【発明の概要】
【発明が解決しようとする課題】
【００２９】
本発明は、通信システムの運用に係る将来の動向を上述のような種々の考察から予見した発明者が、新たな技術課題の認識のもとに、この技術課題を解決すべくなされたものである。
即ち、バーストトラヒックに起因する故障や通信品質低下等の機能不全の発生を確実に予防することができるネットワークエンティティ、および、ネットワークエンティティ保護方法を実現することをその目的とする。
【課題を解決するための手段】
【００３０】
上記課題を解決するために、ここに、次のような技術を提案する。
（１）物理的リソースに係るトラヒック規制を行う物理的リソース系トラヒック規制制御部と、呼の発生を検出する呼検出部と、前記呼検出部によって検出された呼に対応するトラヒック量を既定の呼種別毎に算定する呼種別トラヒック量算定部と、前記呼種別トラヒック量算定部で算定された呼種別のトラヒック量を該トラヒック量に対応する呼種別論理的リソース消費量に換算する呼種別論理的リソース消費量換算部と、前記呼種別論理的リソース消費量換算部で算定される呼種別論理的リソース消費量に関する規制の基準値を保持する呼種別論理的リソース消費量規制基準値保持部と、前記呼種別論理的リソース消費量規制基準値保持部に保持された当該基準値に基づいて前記呼種別論理的リソース消費量換算部で換算された呼種別論理的リソース消費量が既定の規制値に該当するか否かを判定する呼種別トラヒック規制要否判定部と、前記呼種別トラヒック規制要否判定部で規制値に該当すると判定されたトラヒックに関する規制を前記物理的リソース系トラヒック規制制御部によるトラヒック規制とは非排他的に且つ呼種別に実行する呼種別トラヒック規制制御部と、
を備えていることを特徴とするネットワークエンティティ。
【００３１】
上記（１）のネットワークエンティティでは、呼検出部が検出した呼について、呼種別トラヒック量算定部で呼種別のトラヒック量が算定され、更に、該呼種別のトラヒック量が呼種別論理的リソース消費量換算部で呼種別論理的リソース消費量に換算される。そして、該換算された呼種別論理的リソース消費量が、呼種別トラヒック規制要否判定部において、呼種別論理的リソース消費量規制基準値保持部に保持された当該基準値との対照により既定の規制値に該当するか否かが判定される。この判定結果が規制値に該当する旨である場合には、呼種別トラヒック規制制御部において、上記規制値に該当すると判定されたトラヒックに関する規制を実行する。この場合の論理的リソースに係るトラヒックの規制が実行される際にしては、物理的リソース系トラヒック規制制御部によるトラヒック規制とは非排他的に且つ呼種別に実行される。
【００３２】
（２）当該ネットワークエンティティがＬＴＥにおけるＣＳＣＦとして構成され、前記呼種別トラヒック規制制御部は、前記ＣＳＣＦにおける呼セッションの制御を担う呼セッション制御部において各別の呼種に応じた規制を行うように構成されていることを特徴とする（１）のネットワークエンティティ。
上記（２）のネットワークエンティティでは、（１）のネットワークエンティティにおいて特に、当該ネットワークエンティティがＬＴＥにおけるＣＳＣＦとして構成され、前記呼種別トラヒック規制制御部は、前記ＣＳＣＦにおける呼セッションの制御を担う呼セッション制御部において各別の呼種に応じた規制を行うように構成されているため、ＣＳＣＦでの呼セッション制御動作の一環として呼種別の論理的リソースに係るトラヒック規制が物理的リソースに係るトラヒック規制とは非排他的に実行される。
【００３３】
（３）ネットワーク上に設けられたコンピュータが、該ネットワークないしネットワークエンティティの注目点におけるトラヒック量を既定の呼種別毎に算定し、該算定された呼種別のトラヒック量を該トラヒック量に対応する呼種別の論理的リソース消費量に換算し、該換算による呼種別の論理的リソース消費量が既定の規制値との対照においてトラヒック規制を要するか否かを呼種別に判定し、規制を要すると判定されたトラヒックに関する規制を前記論理的リソースとは別異の物理的リソースに係るトラヒック規制である物理的リソース系トラヒック規制とは非排他的に実行することを特徴とするネットワークエンティティ保護方法。
【００３４】
上記（３）のネットワークエンティティ保護方法では、呼種別の論理的リソースの消費量が既定の規制値を超過する場合には、論理的リソースに係る該当する呼種のトラヒックに関する規制を実行する。この規制の実行に際しては、前記論理的リソースとは別異の物理的リソースに係るトラヒック規制である物理的リソース系トラヒック規制とは非排他的に実行する。
【発明の効果】
【００３５】
バーストトラヒックに起因する故障や通信品質低下等の機能不全の発生を確実に予防することができるネットワークエンティティ、および、ネットワークエンティティ保護方法を実現することができる。
【図面の簡単な説明】
【００３６】
【図１】本発明の実施の形態としてのネットワークエンティティの構成を表す機能ブロック図である。
【図２】図１のネットワークエンティティの動作を表すフローチャートである。
【図３】図１のネットワークエンティティの作用を説明するための図である。
【図４】ＬＴＥのシステムにおけるネットワークエンティティ間のトラヒックについて説明するための概念図である。
【図５】サーバ（ネットワークエンティティ）に機能不全が発生する要因を２つの種別に区分して考察した結果を表す図である。
【図６】図５の考え方における更なる課題について説明するための図である。
【発明を実施するための形態】
【００３７】
以下に、図面を参照して本発明の実施の形態について詳述することにより、本発明を明らかにする。
（ネットワークエンティティの構成）
図１は、本発明の実施の形態としてのネットワークエンティティの構成を表す機能ブロック図である。
図１におけるネットワークエンティティはＬＴＥ（Long Term Evolution）のシステム
におけるＣＳＣＦ（Call Session Control Function）１００として構成されている。
ＣＳＣＦ１００は、呼検出部１１１、呼種別トラヒック量算定部１１２、呼種別論理的リソース消費量換算部１１３、呼種別トラヒック規制要否判定部１１４、記憶部１２０、および、呼セッション制御部１３０を含んで構成されている。
【００３８】
また、記憶部１２０には、物理的リソース系トラヒック規制制御用データ保持部１２１、呼種別論理的リソース消費量換算用データ保持部１２２、呼種別トラヒック規制値保持部１２３が設定されている。
更に、呼セッション制御部１３０は、ＣＳＣＦ１００における中核的機能である呼セッション制御を実行するための機能部であり、物理的リソース系トラヒック規制制御部１３１、および、呼種別トラヒック規制制御部１３２を備えている。
【００３９】
ＣＳＣＦ１００における呼検出部１１１は、呼の発生を検出する。また、呼種別トラヒック量算定部１１２は、呼検出部１１１によって検出された呼に対応するトラヒック量を既定の呼種毎に算定する。ここに、既定の呼種とは、例えば、発信呼、着信呼、位置登録呼、…、等々であるが、これらは、信号の種別に着目して区分すれば、発信要求信号、着信要求信号、位置登録信号、サービス要求信号、背景呼要求信号、…、等々である。
【００４０】
また、呼種別論理的リソース消費量換算部１１３は、呼種別トラヒック量算定部１１２で算定された呼種別のトラヒック量を該トラヒック量に対応する呼種別の論理的リソース消費量に換算する。この換算においては、記憶部１２０の呼種別論理的リソース消費量換算用データ保持部１２２に保持された呼種別論理的リソース消費量換算用データに依拠してこの換算に係る処理が実行される。
【００４１】
呼種別トラヒック規制要否判定部１１４は、既定の基準値との対照により、呼種別論理的リソース消費量換算部１１３で換算された呼種別論理的リソース消費量が既定の規制値に該当するか否かを判定する。この判定における既定の規制値は、記憶部１２０における呼種別トラヒック規制値保持部１２３に保持されており、上述の判定に係る処理は、該保持された呼種別トラヒック規制値との対照を行う形態で実行される。
【００４２】
呼種別トラヒック規制要否判定部１１４における判定結果が規制値に該当する旨である場合には、呼セッション制御部１３０の呼種別トラヒック規制制御部１３２において、上記規制値に該当すると判定されたトラヒックに関する規制を実行する。
呼セッション制御部１３０の、物理的リソース系トラヒック規制制御部１３１は、物理的リソースに係るバーストトラヒックを規制するための、それ自体は上掲の文献所載のような一般的な構成を有するものである。
【００４３】
そして、図１の実施の形態においては、呼セッション制御部１３０の呼種別トラヒック規制制御部１３２における、上述のようなトラヒックに関する規制は、物理的リソース系トラヒック規制制御部１３１によるトラヒックの規制とは非排他的に実行される。
従って、図６を参照して既述のような、物理的リソースに関するトラヒックの規制だけでは規制が発動されない論理的リソースに係る基準値超過状態、即ち、図６（ｂ）における領域Ｚ６３に該当する状態に対して有効に規制を発動することができる。
【００４４】
次に、フローチャートを参照して図１のネットワークエンティティ（ＣＳＣＦ）１００の動作について説明する。
図２は、図１のネットワークエンティティの動作を表すフローチャートである。
呼検出部１１１が呼の発生を待機し（Ｓ２０１、Ｓ２０２：Ｎｏ）、呼の発生が検出されると（Ｓ２０２：Ｙｅｓ）、呼種別トラヒック量算定部１１２でＣＳＣＦ１００への呼種別のトラヒック流入量が算定される（Ｓ２０３）。
【００４５】
次いで、呼種別論理的リソース消費量換算部１１３において、ステップＳ２０３で算定された呼種別のトラヒック流入量が、呼種別の論理的リソース消費量への換算処理によって算定される（Ｓ２０４）。ステップＳ２０４における換算処理は、記憶部１２０の呼種別論理的リソース消費量換算用データ保持部に保持された呼種別論理的リソース消費量換算用データを利用して実行される。
【００４６】
次いで、呼種別トラヒック規制要否判定部１１４において、ステップＳ２０４で算定された呼種別の論理的リソース消費量が規定の基準値と対照されて、それら呼種別の論理的リソースに係るトラヒックに対する規制の要否が判定される（Ｓ２０５、Ｓ２０６）。
上記の判定が規制を要する旨であるときには（Ｓ２０６：Ｙｅｓ）、呼セッション制御部１３０の呼種別トラヒック規制制御部１３２において、該当する呼種別にトラヒックの規制制御が実行される（Ｓ２０７）。
【００４７】
ステップＳ２０７における呼種別のトラヒック規制制御は、呼セッション制御部１３０の物理的リソース系トラヒック規制制御部１３１による物理的リソースに係るトラヒックの規制とは、非排他的に実行される。
このため、図６（ｂ）における領域Ｚ６３に該当する状態についても、規制が発動することになり、ネットワークエンティティ（ＣＳＣＦ）１００におけるバーストトラヒックからの保護が十全に行われる。
一方、上記の判定が規制を要しない旨であるときには（Ｓ２０６：Ｎｏ）、呼種別トラヒック規制制御部１３２における呼種別のトラヒック規制制御を行わずにリターンする。
【００４８】
図３は、図１のネットワークエンティティ（ＣＳＣＦ）の作用を従来の問題点との対比において説明するための図である。
図３（ａ）は、既述の図６（ａ）に相応する図であり、呼種Ａ、Ｂ、Ｃ、Ｄ毎に、トラヒック量、従って、これに対応するリソースの状況に着目した考察の結果を表している。
図３（ａ）における「規制値未満」と表記された状況は、リソースの稼働が規制の基準値未満である場合を表している。即ち、呼種Ａ、呼種Ｂ、呼種Ｃ、および、呼種Ｄは、個々において、何れも呼種別の規制値未満であって、当然に、それらの総和も規制の基準値未満である。従って、呼種別および総量の何れの点でも規制発動に到らない状態である。
【００４９】
図３（ａ）における左側の「バーストトラヒック発生時」と表記されたケースはバーストトラヒック規制に該当する状況を表している。呼種Ｃおよび呼種Ｄが何れも呼種別の規制の基準値未満であり、一方、呼種Ａおよび呼種Ｂについては図中ＡｅおよびＢｅと表記の程度だけ呼種別の規制値を上回っており、これらの呼種について規制を発動することが必要になる。しかしながら、呼種別のリソース占有率ではウェイトの高い呼種Ｃが規制値を大幅に下回っている状況であるため、全呼種Ａ〜Ｄのトラヒック量の総和は、マージンＭＧを残して規制の基準値（対応するリソースの使用率）を下回っている。従って、「総量規制」のみである限りは、バーストトラヒックに対し規制は発動しない。
【００５０】
図３（ｂ）は、本発明におけるような呼種別の規制を行う場合を表している。図示の場合では、呼種Ａ〜Ｄについて各別の規制値（基準値）を設定している。
このため、バーストトラヒック発生時に、呼種Ａおよび呼種Ｂについて、それらが各別の基準値Ｕａ、Ｕｂ未満であるときにはリソースの枯渇なく通信が持続され得るため、規制がかからない。そして、それら呼種Ａおよび呼種Ｂが各別の基準値Ｕａ、Ｕｂを、それぞれＳａ、Ｓｂ超過した場合には、規制がかかり、リソースの枯渇に起因する通信品質の低下や、ネットワークエンティティにおける機能不全の発生が効果的に回避される。
【符号の説明】
【００５１】
１００……………………ネットワークエンティティ（ＣＳＣＦ）
１１１……………………呼検出部
１１２……………………呼種別トラヒック量算定部
１１３……………………呼種別論理的リソース消費量換算部
１１４……………………呼種別トラヒック規制要否判定部
１２０……………………記憶部
１２１……………………物理的リソース系トラヒック規制制御用データ保持部
１２２……………………呼種別論理的リソース消費量換算用データ保持部
１２３……………………呼種別トラヒック規制値保持部
１３０……………………呼セッション制御部
１３１……………………物理的リソース系トラヒック規制制御部
１３２……………………呼種別トラヒック規制制御部
【図１】
0005281667.tif 000002
【図２】
0005281667.tif 000003
【図３】
0005281667.tif 000004
【図４】
0005281667.tif 000005
【図５】
0005281667.tif 000006
【図６】
0005281667.tif 000007