図面 (/)

技術 輻輳制御装置、輻輳制御方法、およびそのプログラム

出願人 日本電信電話株式会社
発明者 遠藤大己堀米英明可児島建
出願日 2011年5月10日 (9年6ヶ月経過) 出願番号 2011-105469
公開日 2012年12月6日 (7年11ヶ月経過) 公開番号 2012-238968
状態 特許登録済
技術分野 電話通信サービス 広域データ交換
主要キーワード 負荷閾値 送信停止指示 局番情報 輻輳発生通知 展開ステップ 規制エリア 規制制御 輻輳要因
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2012年12月6日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (8)

課題

輻輳発生時に迅速な制御の開始および網リソースの最大活用を可能とする輻輳制御を実行する。

解決手段

輻輳制御装置10は、まず、輻輳が発生したときの初動時に、輻輳セッション制御装置が収容する局番前方一致の局番(短桁)を規制対象とする制御指示制御を発呼規制セッション制御装置に送信する(ステップS302)。次に、輻輳制御装置10は、発呼規制セッション制御装置から受信したトラヒック状況情報に基づいて、輻輳要因となる要因局番を抽出する(ステップS305)。そして、輻輳制御装置10は、その抽出した要因局番の下位の桁を番号展開し(ステップS306)、その番号展開した局番を規制対象とする制御指示を含む制御指示情報を発呼規制セッション制御装置に送信して、発呼規制セッション制御装置の規制制御を実行する。

概要

背景

IP(Internet Protocol)電話網では、その網のノードにおいて輻輳発生が検出されたとき、その輻輳要因となる呼の網への流入を、網の入口のノードで規制する制御が行われる。網のノードとして、例えば、IP電話網を実現するためにコンピュータ電話のそれぞれの機能を統合するためのCTI(Computer Telephony Integration)技術を用いたCTI−GW(ゲートウェイ)、または、発信元着信先との間のセッションSIP(Session Initiation Protocol)のINVITEリクエスト接続要求;呼に該当)を用いて確立するソフトスイッチ(以降、セッション制御装置とも称す。)が用いられている。

特許文献1では、ある端末Aに呼が集中して、CTI−GWまたはソフトスイッチにおいて輻輳が発生したとき、CTI−GWまたはソフトスイッチは、端末Aの識別情報IPアドレスまたは電話番号)を含む輻輳情報輻輳制御管理装置(本発明の輻輳制御装置に相当)に送信する。輻輳制御管理装置は、輻輳を解消するために、端末Aに対する単位時間当りの呼の接続数である呼数密度を決定し、その呼数密度を含む接続制御指示信号を生成し、網の入口となるソフトスイッチに送信する。接続制御指示信号を受信したソフトスイッチは、呼数密度に基づいて端末Aに対する呼の接続数を制御し、輻輳を解消する。

概要

輻輳発生時に迅速な制御の開始および網リソースの最大活用を可能とする輻輳制御を実行する。輻輳制御装置10は、まず、輻輳が発生したときの初動時に、輻輳セッション制御装置が収容する局番前方一致の局番(短桁)を規制対象とする制御指示制御を発呼規制セッション制御装置に送信する(ステップS302)。次に、輻輳制御装置10は、発呼規制セッション制御装置から受信したトラヒック状況情報に基づいて、輻輳要因となる要因局番を抽出する(ステップS305)。そして、輻輳制御装置10は、その抽出した要因局番の下位の桁を番号展開し(ステップS306)、その番号展開した局番を規制対象とする制御指示を含む制御指示情報を発呼規制セッション制御装置に送信して、発呼規制セッション制御装置の規制制御を実行する。

目的

本発明は、輻輳発生時に迅速な制御の開始および網リソースの最大活用を可能とする輻輳制御を実行することを課題とする

効果

実績

技術文献被引用数
1件
牽制数
0件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

IP(Internet Protocol)電話網ノードであるセッション制御装置通信可能に接続され、輻輳状態となった第1のセッション制御装置に向かう呼を規制対象とする制御指示を示す制御指示情報を、前記呼を端末から受け付ける第2のセッション制御装置に送信して、輻輳制御を実行する輻輳制御装置であって、前記第1のセッション制御装置が収容している前記呼の局番と所定の閾値とを記憶している記憶部と、前記記憶部から取得した前記第1のセッション制御装置が収容している前記局番同士の前方一致のN桁の局番を規制対象とする制御指示を示す制御指示情報を生成する制御指示情報生成部と、前記第2のセッション制御装置に当該制御指示情報を送信する制御指示部と、当該制御指示情報を受信した前記第2のセッション制御装置から、所定期間の前記規制対象のトラヒック量を取得する演算部と、前記トラヒック量と前記閾値とを比較して、前記トラヒック量が前記閾値を超える場合その局番を輻輳要因要因局番であると判定して規制対象とし、前記トラヒック量が前記閾値以下である場合その局番は前記要因局番でないと判定して規制対象から除き、前記要因局番であると判定した局番に対して、その要因局番の下位の桁を番号展開し、その番号展開したN+1桁の局番を規制対象とする制御指示を含む制御指示情報を新たに生成する番号展開部と、前記局番の桁数を表すNをN+1の値に更新して、前記制御指示情報生成部、前記制御指示部、前記演算部、および前記番号展開部の処理を順に繰り返し実行する制御情報決定部と、を備えることを特徴とする輻輳制御装置。

請求項2

前記制御指示情報生成部は、(A)前記桁数Nの局番の桁数が所定の閾値を超える場合、(B)前記桁数Nの局番の数が所定の閾値を超える場合、のいずれかまたは双方を示す所定の条件に到達したか否かを判定し、前記所定の条件に到達したと判定した場合、前記繰り返し処理を終了することを特徴とする請求項1に記載の輻輳制御装置。

請求項3

前記輻輳制御装置において、さらに前記制御指示情報生成部は、前記要因局番でないと判定した局番を、前記規制対象とは異なる監視対象として含めて前記制御指示情報を生成し、前記演算部は、当該制御指示情報を送信した前記第2のセッション制御装置から、当該要因局番でないと判定した局番のトラヒック量を取得し、前記番号展開部は、当該トラヒック量と前記閾値とを比較して、その要因局番でないと判定した局番が要因局番か否かを判定することを特徴とする請求項1または請求項2に記載の輻輳制御装置。

請求項4

前記規制対象のトラヒック量は、(1)規制対象の局番を接続先とする発信呼数、(2)Initial−INVITEリクエストの総発生数、(3)規制制御遭遇した呼数、(4)規制対象トラヒックの中で着側の前記端末から応答信号を受信した完了呼数、のいずれかまたは複数の組み合わせについて前記所定期間内で測定した値であることを特徴とする請求項1ないし請求項3のいずれか一項に記載の輻輳制御装置。

請求項5

IP電話網のノードであるセッション制御装置と通信可能に接続され、輻輳状態となった第1のセッション制御装置に向かう呼を規制対象とする制御指示を示す制御指示情報を、前記呼を端末から受け付ける第2のセッション制御装置に送信して、輻輳制御を実行する輻輳制御装置における輻輳制御方法であって、前記輻輳制御装置は、前記第1のセッション制御装置が収容している前記呼の局番と所定の閾値とを記憶している記憶部を備え、前記記憶部から取得した前記第1のセッション制御装置が収容している前記局番同士の前方一致のN桁の局番を規制対象とする制御指示を示す制御指示情報を生成する制御指示情報生成ステップと、前記第2のセッション制御装置に当該制御指示情報を送信する制御指示ステップと、当該制御指示情報を受信した前記第2のセッション制御装置から、所定期間の前記規制対象の局番のトラヒック量を取得する演算ステップと、前記トラヒック量と前記閾値とを比較して、前記トラヒック量が前記閾値を超える場合その局番を輻輳要因の要因局番であると判定して規制対象とし、前記トラヒック量が前記閾値以下である場合その局番は前記要因局番でないと判定して規制対象から除き、前記要因局番であると判定した局番に対して、その要因局番の下位の桁を番号展開し、その番号展開したN+1桁の局番を規制対象とする制御指示を含む制御指示情報を新たに生成する番号展開ステップと、前記局番の桁数を表すNをN+1の値に更新して、前記制御指示情報生成ステップ、前記制御指示ステップ、前記演算ステップ、および前記番号展開ステップの処理を順に繰り返し実行する制御情報決定ステップと、を実行することを特徴とする輻輳制御方法。

請求項6

前記輻輳制御装置は、前記制御指示情報生成ステップにおいて、(A)前記桁数Nの局番の桁数が所定の閾値を超える場合、(B)前記桁数Nの局番の数が所定の閾値を超える場合、のいずれかまたは双方を示す所定の条件に到達したか否かを判定し、前記所定の条件に到達したと判定した場合、前記繰り返し処理を終了することを特徴とする請求項5に記載の輻輳制御方法。

請求項7

請求項5または請求項6に記載の輻輳制御方法を、コンピュータである前記輻輳制御装置に実行させるためのプログラム

技術分野

0001

本発明は、網を介して通信サービスを行うためのC−plane(制御プレーン)における輻輳制御に関する。

背景技術

0002

IP(Internet Protocol)電話網では、その網のノードにおいて輻輳発生が検出されたとき、その輻輳要因となる呼の網への流入を、網の入口のノードで規制する制御が行われる。網のノードとして、例えば、IP電話網を実現するためにコンピュータ電話のそれぞれの機能を統合するためのCTI(Computer Telephony Integration)技術を用いたCTI−GW(ゲートウェイ)、または、発信元着信先との間のセッションSIP(Session Initiation Protocol)のINVITEリクエスト接続要求;呼に該当)を用いて確立するソフトスイッチ(以降、セッション制御装置とも称す。)が用いられている。

0003

特許文献1では、ある端末Aに呼が集中して、CTI−GWまたはソフトスイッチにおいて輻輳が発生したとき、CTI−GWまたはソフトスイッチは、端末Aの識別情報IPアドレスまたは電話番号)を含む輻輳情報を輻輳制御管理装置(本発明の輻輳制御装置に相当)に送信する。輻輳制御管理装置は、輻輳を解消するために、端末Aに対する単位時間当りの呼の接続数である呼数密度を決定し、その呼数密度を含む接続制御指示信号を生成し、網の入口となるソフトスイッチに送信する。接続制御指示信号を受信したソフトスイッチは、呼数密度に基づいて端末Aに対する呼の接続数を制御し、輻輳を解消する。

先行技術

0004

特許第3715604号(段落0056〜0059参照)

発明が解決しようとする課題

0005

ところで、輻輳制御の対処方針として、優先度の高い指標として迅速な制御の開始が挙げられ、次に準じて優先度の高い指標として網リソースの最大活用が挙げられる。この対処方針は、初動時には輻輳元のセッション制御装置がダウンしてしまうことを防ぐために、まず輻輳の状態を解消し、次に、初動によって規制を掛け過ぎた場合には徐々に網リソースを有効に活用できるようにするという考え方である。
特許文献1では、輻輳要因となる端末Aの識別情報が特定されたことを前提として輻輳制御が行われている。しかし、一般的には、輻輳発生が検出された直後には、輻輳要因となる要因局番が特定されていない場合が多い。そこで、輻輳元のセッション制御装置に収容されているすべての局番に対して輻輳制御を開始することになるが、その局番が多数存在する場合には、その多数の局番に対応する制御指示を生成することに時間がかかるため、初動として迅速に制御を行うことができないという問題がある。さらに、局番が多数存在する場合に迅速な制御の開始を実現するために、制御指示を手分けして行う多人数のリソースを確保し、その多人数の作業に対応するための高性能な輻輳制御管理装置のリソースを備えておくのでは非経済的になるという問題もある。また、初動として迅速に制御を行った上で、輻輳要因の要因局番をどのようにして特定し、網リソースを最大活用できるようにするかという点についての検討例はほとんど見られない。

0006

そこで、本発明は、輻輳発生時に迅速な制御の開始および網リソースの最大活用を可能とする輻輳制御を実行することを課題とする。

課題を解決するための手段

0007

本発明は、IP電話網のノードであるセッション制御装置と通信可能に接続され、輻輳状態となった第1のセッション制御装置に向かう呼を規制対象とする制御指示を示す制御指示情報を、前記呼を端末から受け付ける第2のセッション制御装置に送信して、輻輳制御を実行する輻輳制御装置であって、前記第1のセッション制御装置が収容している前記呼の局番と所定の閾値とを記憶している記憶部と、前記記憶部から取得した前記第1のセッション制御装置が収容している前記局番同士の前方一致のN桁の局番を規制対象とする制御指示を示す制御指示情報を生成する制御指示情報生成部と、前記第2のセッション制御装置に当該制御指示情報を送信する制御指示部と、当該制御指示情報を受信した前記第2のセッション制御装置から、所定期間の前記規制対象のトラヒック量を取得する演算部と、前記トラヒック量と前記閾値とを比較して、前記トラヒック量が前記閾値を超える場合その局番を輻輳要因の要因局番であると判定して規制対象とし、前記トラヒック量が前記閾値以下である場合その局番は前記要因局番でないと判定して規制対象から除く或いはN桁による制御を継続し、前記要因局番であると判定した局番に対して、その要因局番の下位の桁を番号展開し、その番号展開したN+1桁の局番を規制対象とする制御指示を含む制御指示情報を新たに生成する番号展開部と、前記局番の桁数を表すNをN+1の値に更新して、前記制御指示情報生成部、前記制御指示部、前記演算部、および前記番号展開部の処理を順に繰り返し実行する制御情報決定部と、を備えることを特徴とする。

0008

また、本発明は、IP電話網のノードであるセッション制御装置と通信可能に接続され、輻輳状態となった第1のセッション制御装置に向かう呼を規制対象とする制御指示を示す制御指示情報を、前記呼を端末から受け付ける第2のセッション制御装置に送信して、輻輳制御を実行する輻輳制御装置における輻輳制御方法であって、前記輻輳制御装置が、前記第1のセッション制御装置が収容している前記呼の局番と所定の閾値とを記憶している記憶部を備え、前記記憶部から取得した前記第1のセッション制御装置が収容している前記局番同士の前方一致のN桁の局番を規制対象とする制御指示を示す制御指示情報を生成する制御指示情報生成ステップと、前記第2のセッション制御装置に当該制御指示情報を送信する制御指示ステップと、当該制御指示情報を受信した前記第2のセッション制御装置から、所定期間の前記規制対象の局番のトラヒック量を取得する演算ステップと、前記トラヒック量と前記閾値とを比較して、前記トラヒック量が前記閾値を超える場合その局番を輻輳要因の要因局番であると判定して規制対象とし、前記トラヒック量が前記閾値以下である場合その局番は前記要因局番でないと判定して規制対象から除く或いはN桁による制御を継続し、前記要因局番であると判定した局番に対して、その要因局番の下位の桁を番号展開し、その番号展開したN+1桁の局番を規制対象とする制御指示を含む制御指示情報を新たに生成する番号展開ステップと、前記局番の桁数を表すNをN+1の値に更新して、前記制御指示情報生成ステップ、前記制御指示ステップ、前記演算ステップ、および前記番号展開ステップの処理を順に繰り返し実行する制御情報決定ステップと、を実行することを特徴とする。

0009

このような構成によれば、輻輳制御装置は、輻輳状態となった第1のセッション制御装置(以降、輻輳セッション制御装置と称す。)に収容されている局番について前方一致のN桁の数を規制対象とすることによって、そのN桁の局番一つによって、広範囲の規制を掛けることが可能なため、輻輳発生時に迅速な制御の開始を可能とする。次に、輻輳制御装置は、取得したトラヒック量に基づいて、輻輳要因の要因局番であると判定された局番の下位の桁を番号展開して、その番号展開した局番について、さらに要因局番か否かを判定しつつ、要因局番を絞っていくことによって、網リソースの最大活用を可能とする輻輳制御を実行することができる。

0010

また、本発明における前記制御指示情報生成部または前記制御指示情報生成ステップは、(A)前記桁数Nの局番の桁数が所定の閾値を超える場合、(B)前記桁数Nの局番の数が所定の閾値を超える場合、のいずれかまたは双方を示す所定の条件に到達したか否かを判定し、前記所定の条件に到達したと判定した場合、前記繰り返し処理を終了することを特徴とする。

0011

このような構成によれば、輻輳制御装置は、規制対象として制御指示に含める局番の数が多過ぎも少な過ぎもしない適度な数となり、人的リソースや輻輳制御管理装置のリソースが非経済的になることを防ぎつつ、網リソースの最大活用を実現することができる。

0012

また、本発明では、前記輻輳制御装置において、さらに、前記制御指示情報生成部が、前記要因局番でないと判定した局番を、前記規制対象とは異なる監視対象として含めて前記制御指示情報を生成し、前記演算部が、当該制御指示情報を送信した前記第2のセッション制御装置から、当該要因局番でないと判定した局番のトラヒック量を取得し、前記番号展開部が、当該トラヒック量と前記閾値とを比較して、その要因局番でないと判定した局番が要因局番か否かを判定することを特徴とする。

0013

このような構成によれば、輻輳制御装置は、要因局番でないと判定した局番については、規制対象から外して、番号展開は行わずに監視対象としてトラヒック量を収集する。このトラヒック量を収集する理由は、トラヒック量の急な再上昇に迅速に対応できるようにするためである。したがって、輻輳制御装置は、輻輳セッション制御装置の輻輳状況を解消しつつ、網リソースの最大活用を可能とすることができる。

0014

また、本発明では、前記規制対象のトラヒック量が、(1)規制対象の局番を接続先とする発信呼数、(2)Initial−INVITEリクエストの総発生数、(3)規制制御遭遇した呼数、(4)規制対象トラヒックの中で着側の前記端末から応答信号を受信した完了呼数、のいずれかまたは複数の組み合わせについて前記所定期間内で測定した値であることを特徴とする。

0015

このような構成によれば、輻輳制御装置は、トラヒック量として、輻輳セッション制御装置の輻輳状態に直接的または間接的に関係するパラータの値を取得する。したがって、輻輳制御装置は、測定したトラヒック量に基づいて、輻輳セッション制御装置の輻輳状況を解消しつつ、網リソースの最大活用に役立てることができる。

0016

また、本発明は、前記輻輳制御方法を、コンピュータとしての輻輳制御装置に実行させるためのプログラムとした。このようなプログラムをインストールされたコンピュータは、このプログラムに基づいた機能を実現することができる。

発明の効果

0017

本発明によれば、輻輳発生時に迅速な制御の開始および網リソースの最大活用を可能とする輻輳制御を実行することができる。

図面の簡単な説明

0018

本実施形態の輻輳制御システムにおける動作例の概要を示す図であり、(a)は初動時を表しており、(b)は要因局番絞込み時を表している。
本実施形態の輻輳制御システムを構成する各装置の機能例を示す図である。
記憶部に記憶されている情報の一例を示す図であり、(a)は収容局番情報を表しており、(b)は要因局番を表している。
本実施形態の輻輳制御システムにおける各装置の動作シーケンス例を示す図である。
本実施形態における輻輳制御装置の処理フロー例を示す図である。
比較例の輻輳制御システムにおける動作例を示す図である。
総務省がWebページ掲載している市外局番の一覧を示す図である。

実施例

0019

本発明を実施するための形態(以降、「本実施形態」と称す。)について、適宜図面を参照しながら詳細に説明する。なお、各図において共通する箇所には同一の符号を付し、重複した説明を省略する。

0020

(比較例の輻輳制御システム)
はじめに、比較例として、従来の輻輳制御システム1aにおける動作例について、図6を用いて説明する。

0021

IP電話網のC−planeでは、図6に示すように、複数のセッション制御装置20(20A,20B,20C)がノードとして配置されて、ノード同士は通信可能になっている。セッション制御装置20は、端末30(例えば、電話機等)から接続要求(一点鎖線;例えば、SIPのINVITEリクエスト)を受け付けて、発信元と着信先とのセッションを確立する。なお、図6では、セッション制御装置20は、3台しか記載していないが、3台に限らなくとも良い。

0022

図6では、セッション制御装置20Cは、処理すべき接続要求が増大してリソースが圧迫されて輻輳発生の状態になったことを表している。以降の説明では、輻輳状態になったセッション制御装置20を輻輳セッション制御装置と称する。

0023

また、輻輳制御装置10aは、各セッション制御装置20と通信可能に接続され、輻輳セッション制御装置から輻輳発生を検出したことを示す輻輳発生通知(輻輳状況情報)を受信し(破線矢印)、輻輳セッション制御装置が収容する局番について接続要求の受け付けを呼数密度によって規制(制限)する制御指示を生成し、その制御指示を含む制御指示情報を発側のセッション制御装置20A,20Bに送信する(破線矢印)。なお、以降の説明では、発側のセッション制御装置20A,20Bを、発呼規制セッション制御装置と称す。発呼規制セッション制御装置は、受信した制御指示情報に含まれる呼数密度に基づいて呼の接続数を制御する。

0024

具体的には、輻輳セッション制御装置に収容されている収容局番が0ABC10〜0ABC39であった場合には、輻輳制御装置10aは、そのすべての局番に対して、接続要求の受け付けを規制する制御指示を含む制御指示情報を、発呼規制セッション制御装置に送信する。この場合、すべての局番に対応する制御指示を生成することに時間がかかるため、迅速に制御を行う必要のある初動として好ましくない。

0025

なお、輻輳制御装置10aは、輻輳発生通知を受信して以降、周期的に輻輳セッション制御装置から輻輳状況を含む輻輳状況情報を受信して、その輻輳状況情報に基づいて輻輳セッション制御装置の輻輳状態を監視(判定)する。輻輳状況とは、例えば、CPU(Central Processing Unit)使用率等の処理負荷に関する情報である。そして、輻輳制御装置10aは、例えば、処理負荷が予め設定してある負荷閾値(処理負荷に関する閾値)以上の場合、輻輳状態にあると判定する。輻輳制御装置10aは、輻輳状態であると判定している間、周期的に制御指示情報を送信するとともに、発呼規制セッション制御装置からトラヒック状況情報(例えば、局番ごとのトラヒック量に関する情報)を受信する(点線矢印)。輻輳制御装置10aは、予め輻輳制御装置10aにインプットされた輻輳セッション制御装置にて接続要求の受け付けが可能な最大容量、或いは人為的な指定により呼数密度を決定し、その決定した呼数密度を受信したトラヒック状況情報に基づいて発呼規制セッション制御装置毎に配分し、その配分した呼数密度を含む制御指示を制御指示情報として発呼規制セッション制御装置に送信する。なお、輻輳制御装置10aは、輻輳状態が沈静化したと判定した場合には、輻輳状況情報の送信停止通知を輻輳セッション制御装置に送信する。

0026

(本実施形態の輻輳制御システムの概要)
前記したように、比較例の輻輳制御システム1aでは、輻輳セッション制御装置が収容する局番が多数存在する場合には、迅速な制御の開始を満足することは難しい。そこで、輻輳発生時に迅速な制御の開始および網リソースの最大活用を可能とする輻輳制御を行える、本実施形態の輻輳制御システム1における動作例の概要について、図1(a)(b)を用いて説明する。なお、図1(a)(b)は、説明に必要な輻輳制御装置10およびセッション制御装置20(20A,20B,20C)のみを記載し、特に説明に必要でない図6に記載したような、端末30、他網、C−planeの記載を省略している。また、図1では、セッション制御装置20は、3台しか記載していないが、3台に限らなくとも良い。また、図1(a)(b)に示すセッション制御装置20は、IP電話網のノードであって相互に通信可能になっており、輻輳制御装置10とも通信可能になっている。

0027

図1(a)に示す輻輳発生後の初動時には、輻輳制御装置10は、輻輳セッション制御装置(第1のセッション制御装置)から輻輳発生通知(輻輳状況情報)を受信して、輻輳セッション制御装置によって収容されている局番の前方一致の上位桁図1では0ABCの4桁)の局番を規制対象とする制御指示および呼数密度を含む制御指示情報を、発呼規制セッション制御装置(第2のセッション制御装置)に送信する(破線矢印)。したがって、輻輳制御装置10は、一つの局番による制御指示を含む制御指示情報を送信することによって、輻輳発生通知を受信後直ちに、広範囲の局番を対象とした規制を実施することが可能となる。そして、輻輳制御装置10は、制御指示情報に含まれる局番に関するトラヒック状況情報を、発呼規制セッション制御装置から受信する(点線矢印)。

0028

なお、初動時に規制対象とする局番の桁数は、前方一致の上位桁数とは言っても、地域性を考慮することが好ましい。この理由は、図7に局番の一例を示すように、総務省が管理している電話番号計画では、例えば、先頭の0を含めた局番が3桁〜4桁であれば、適度に広範囲な規制エリアを設定可能である。一般的に、地震津波等の自然災害イベント等の企画は、適度に広範囲なエリアに集中するので、初動時には、規制対象とする局番を3桁〜4桁とすることは有効と考えられる。また、局番を2桁にしてしまうと、エリアが広くなり過ぎて、網リソースを有効に活用できない。また、初動時の規制対象とする局番の桁数を大きくすると、制御指示に設定する局番の数が多くなるため、前記したように、高性能の装置や多人数のリソースを確保しなければならなくなって非経済的になる。

0029

次に、図1(a)に示す初動時から時間が経過した後の、図1(b)に示す要因局番絞込み時の動作について説明する。図1(b)は、要因局番が0ABC1に絞られた時点を表している。

0030

図1(a)から図1(b)に至る時間の経過において、図示はしていないが、輻輳制御装置10は、局番0ABCの下位の桁を番号展開して、局番0ABC1,0ABC2,0ABC3に関する制御指示情報を発呼規制セッション制御装置に送信し、発呼規制セッション制御装置から局番0ABC1,0ABC2,0ABC3に関するトラヒック量に関するトラヒック状況情報を受信する。
そして、輻輳制御装置10は、発呼規制セッション制御装置から受信したトラヒック状況情報から取得される局番0ABC1,0ABC2,0ABC3ごとのトラヒック量に基づいて、輻輳要因となる要因局番を絞り込んでいく。具体的には、輻輳制御装置10は、トラヒック量がトラヒック閾値(トラヒック量に関する閾値であって、請求項に記載の閾値)を超える場合には要因局番であると判定し、トラヒック量がトラヒック閾値以下であれば要因局番ではないと判定する。その結果、要因局番が0ABC1と判定されたものとする。
なお、輻輳制御装置10は、要因局番でないと判定した局番については、規制対象から外して、番号展開は行わずに監視対象としてトラヒック量を収集する。このトラヒック量を収集する理由は、トラヒック量の急な再上昇に迅速に対応できるようにするためである。また、トラヒック量が前記のトラヒック閾値よりさらに小さい所定の閾値未満の場合には、監視対象から外しても構わない。

0031

そして、図1(b)で表されるように、輻輳制御装置10が、要因局番を0ABC1と判定した状態になる。
輻輳制御装置10は、輻輳発生通知を受信した後、輻輳セッション制御装置から、CPU負荷等の輻輳状況を含む輻輳状況情報を周期的に受信している。
輻輳制御装置10は、局番0ABC1の下位の桁を番号展開(0ABC10〜0ABC19)して、それらの番号展開した局番に関する制御指示を含む制御指示情報を発呼規制セッション制御装置に送信する(破線矢印)。次に、輻輳制御装置10は、発呼規制セッション制御装置から局番0ABC10〜0ABC19に関するトラヒック量を含むトラヒック状況情報を受信する(点線矢印)。そして、輻輳制御装置10は、トラヒック量がトラヒック閾値を超える場合には要因局番であると判定し、トラヒック量がトラヒック閾値以下であれば要因局番ではないと判定し、要因局番を絞り込んでいく。この要因局番の絞込みは、後記する所定の条件に到達するまで実行される。

0032

(輻輳制御装置およびセッション制御装置の機能)
次に、輻輳制御装置10の機能例およびセッション制御装置20の機能例について、図2を用いて説明する(適宜、図1参照)。ただし、図2は、本発明の説明に必要な機能のみを記載し、データ入力のための入力手段、ネットワークを介するデータ送受信のための通信手段、メッセージ等をディスプレイに表示する出力手段、および接続要求を受け付ける呼数密度等の演算に係る各手段については記載を省略している。

0033

図2に示すように、輻輳制御装置10は、制御情報決定部11、記憶部15、および制御指示部16を備える。制御情報決定部11は、さらに、演算部12、番号展開部13、および制御指示情報生成部14を備える。輻輳制御装置10は、図示しないCPUおよびメインメモリによって構成される処理部とアプリケーションプログラム等を記憶する記憶部15とを備える。処理部は、記憶部15に記憶されているアプリケーションプログラムをメインメモリに展開して、制御情報決定部11、演算部12、番号展開部13、制御指示情報生成部14、および制御指示部16を具現化する。

0034

制御情報決定部11は、番号展開を進めていくために、制御指示情報生成部14、制御指示部16、演算部12、および番号展開部13の処理を順に繰り返す制御を実行する。また、制御情報決定部11は、演算部12、番号展開部13、制御指示情報生成部14、記憶部15、および制御指示部16間の連携動作制御を司る。

0035

演算部12は、輻輳セッション制御装置から受信した輻輳状況情報に基づいて、輻輳セッション制御装置の輻輳状態を監視(判定)するとともに、発呼規制セッション制御装置から受信したトラヒック状況情報から局番ごとのトラヒック量を取得する。

0036

番号展開部13は、演算部12から取得した局番ごとのトラヒック量に基づいて、規制対象の局番(要因局番)を抽出する。また、番号展開部13は、要因局番の下位の桁を番号展開する処理を実行する。なお、番号展開部13の処理の詳細は、後記する。

0037

制御指示情報生成部14は、番号展開部13によって番号展開された局番が所定の条件に到達したか否かを判定するとともに、所定の条件に到達する前に番号展開された局番について、制御指示情報を生成する。ここで、所定の条件とは、(A)規制対象となる局番の桁数が所定の閾値(例えば、市町村単位の局番の桁数)を超える場合、(B)制御指示を行う局番の数が局番数に関する所定の閾値を超える場合、(C)輻輳状態が解消した場合、のいずれかまたは複数の組み合わせである。なお、制御指示情報生成部14の処理の詳細は、後記する。

0038

記憶部15は、前記したアプリケーションプログラムや各セッション制御装置20が収容している局番情報(収容局番情報)や種々の閾値を記憶している。また、記憶部15は、番号展開部13によって抽出された要因局番を記憶している。ここで、収容局番情報や要因局番についての具体例を、図3を用いて説明する。
図3(a)は、収容局番情報を表しており、セッション制御装置20のIDと、そのセッション制御装置20が収容している局番の情報(収容局番情報)と、初動時の局番とを記憶している。また、図3(b)は、要因局番と判定された局番が記憶されている状態を表している。

0039

図2に戻って、制御指示部16は、制御指示情報生成部14が生成した制御指示情報を、発呼規制セッション制御装置(セッション制御装置20A,20B)に送信する。

0040

また、輻輳セッション制御装置(セッション制御装置20C)は、少なくとも、発呼規制要求部21、リソース監視部22、および接続要求処理部24を備える。

0041

発呼規制要求部21は、リソース監視部22において輻輳発生と判定した場合、輻輳発生通知(輻輳状況情報)を輻輳制御装置10に送信する。また、発呼規制要求部21は、リソース監視部22において測定した処理負荷の大きさ(例えば、CPU使用率)に関する輻輳状況情報を、所定の周期で、輻輳制御装置10に送信する。

0042

リソース監視部22は、処理負荷の大きさを表す一例として、CPU使用率を所定の周期で測定するCPU使用率測定部23を備えている。そして、リソース監視部22は、測定したCPU使用率を負荷閾値と比較し、CPU使用率が負荷閾値以上のときに、輻輳発生と判定する。

0043

接続要求処理部24は、端末30(図1参照)から接続要求を受け付けて、その接続要求の着信先に接続する制御を行う。

0044

発呼規制セッション制御装置(セッション制御装置20A,20B)は、少なくとも、発呼規制部25および接続要求処理部24を備える。なお、発呼規制セッション制御装置は、図示しないCPUおよびメインメモリによって構成される処理部とアプリケーションプログラム等を記憶する記憶部とを含んで構成される。処理部は、記憶部に記憶されているアプリケーションプログラムをメインメモリに展開して、発呼規制部25および接続要求処理部24を具現化する。

0045

発呼規制部25は、輻輳制御装置10から受信した制御指示情報に基づいて、輻輳セッション制御装置に向かう呼を規制する指示を、接続要求処理部24に通知する。
接続要求処理部24は、発呼規制部25から通知された指示に基づいて、端末30(図1参照)から受け付けた接続要求の呼の着信先への接続を制御する。

0046

次に、本実施形態の輻輳制御システム1を構成する各装置の動作シーケンス例について、図4を用いて説明する(適宜、図1,2参照)。なお、輻輳セッション制御装置が収容している局番は、図1と同様に、0ABC10〜0ABC39であるものとして説明するが、これに限らなくても良い。

0047

まず、ステップS300では、セッション制御装置20C(輻輳セッション制御装置)において、リソース監視部22が、輻輳発生と判定する。そして、発呼規制要求部21が輻輳発生通知(輻輳状況情報)を輻輳制御装置10に送信する。
ステップS301では、輻輳制御装置10の演算部12が、輻輳発生通知(輻輳状況情報)を取得する。

0048

ステップS302では、制御指示情報生成部14が、輻輳セッション制御装置に収容されている局番の前方一致の局番である上位の短桁(0ABC)を規制対象とする制御指示を含む制御指示情報を生成し、その制御指示情報を制御指示部16を介して、セッション制御装置20A,20B(発呼規制セッション制御装置)に送信する。なお、輻輳制御装置10が輻輳発生通知を受信した直後のステップS302に限って、前方一致の局番(図3(a)の初動時の局番)は、網管制者によって設定されるものとする。また、ステップS302における処理は、図1(a)に示す初動時の処理に相当する。

0049

ステップS303では、発呼規制セッション制御装置は、制御指示情報に格納されている規制対象の局番(0ABC)に関するトラヒック量を測定する。なお、このトラヒック量の測定は、所定期間内のトラヒックについて行われる。また、トラヒック量の測定対象パラメータは、例えば、(1)規制対象の局番を接続先とする発信呼数、(2)Initial−INVITEリクエストの総発生数(規制対象の局番に限らずINVITEリクエストの発生した総数)、(3)規制制御に遭遇した呼数、(4)規制対象トラヒックの中で着側の端末30から応答信号を受信した完了呼数、のいずれかまたは複数の組み合わせである。発呼規制セッション制御装置は、測定したトラヒック量をトラヒック状況情報として、輻輳制御装置10に送信する。

0050

ステップS304では、演算部12は、発呼規制セッション制御装置から、規制対象の局番(0ABC)のトラヒック量に関するトラヒック状況情報を受信する。

0051

ステップS305では、番号展開部13は、規制対象の局番0ABCのトラヒック量とトラヒック閾値とを比較し、要因局番を抽出する。具体的には、番号展開部13は、ある局番のトラヒック量がトラヒック閾値を超える場合、その局番が要因局番であると判定し、ある局番のトラヒック量がトラヒック閾値以下である場合、その局番が要因局番でないと判定する。要因局番であると判定された局番は、記憶部15に記憶される。ただし、輻輳発生通知を受信した後で最初に実行される要因局番の抽出処理では、一般的に、局番0ABCが要因局番であると判定される。

0052

ステップS306では、番号展開部13は、記憶部15から要因局番であると判定された局番を取得し、その局番の下位の桁を番号展開する。具体的には、要因局番0ABCを番号展開することによって、番号展開した局番は、0ABC*=0ABC1,0ABC2,0ABC3となる。
ステップS307では、制御指示情報生成部14は、番号展開した局番(0ABC*)に関する制御指示情報を生成し、制御指示部16を介して、その制御指示情報を発呼規制セッション制御装置に送信する。

0053

ステップS308では、発呼規制セッション制御装置は、ステップS303の処理と同様に、制御指示情報に格納されている規制対象の局番(0ABC*)に関するトラヒック量を測定する。発呼規制セッション制御装置は、測定したトラヒック量をトラヒック状況情報として、輻輳制御装置10に送信する。

0054

ステップS309では、演算部12は、ステップS304の処理と同様に、発呼規制セッション制御装置から、規制対象の局番(0ABC*)のトラヒック量に関するトラヒック状況情報を受信する。

0055

ステップS310では、番号展開部13は、ステップS305の処理と同様に、規制対象の局番ごとにトラヒック量とトラヒック閾値とを比較し、要因局番を抽出する。具体的には、番号展開部13は、当該トラヒック量がトラヒック閾値を超える場合、その局番が要因局番であると判定し、当該トラヒック量がトラヒック閾値以下である場合、その局番が要因局番でないと判定する。要因局番であると判定された局番は、記憶部15に記憶される。例えば、要因局番であると判定された局番が、0ABC1であったとする。

0056

ステップS311では、番号展開部13は、記憶部15に記憶された要因局番であると判定された局番0ABC1を取得し、その局番の下位の桁を番号展開する。具体的には、番号展開した局番は、0ABC1*=0ABC10,0ABC11,0ABC12,0ABC13,0ABC14,0ABC15,0ABC16,0ABC17,0ABC18,0ABC19となる。

0057

ステップS312〜S314では、局番情報0ABC1*に対して、ステップS307〜S309と同様の処理が実行される。
なお、輻輳セッション制御装置は、輻輳発生を検出した後、周期的に輻輳状況情報を輻輳制御装置10へ送信しており、輻輳制御装置10は受信した輻輳状況情報に基づいて、輻輳セッション制御装置の輻輳状況を判定している。なお、輻輳制御装置10の演算部12は、輻輳セッション制御装置が輻輳の状態でないと判定した場合、輻輳状況情報の送信を停止することを示す送信停止指示を輻輳セッション制御装置に送信する。
そして、ステップS312以降の処理においては、ステップS307〜S311と同様の処理が、展開した局番が所定の条件に到達するまで繰り返し実行される。

0058

(輻輳制御装置の処理フロー)
次に、輻輳制御装置10の処理フロー例について、図5を用いて説明する(適宜、図1〜3参照)。
ステップS401では、演算部12は、輻輳セッション制御装置から輻輳状況情報(輻輳発生通知)を受信し、輻輳状態か否かを判定する。
輻輳状態であると判定した場合(ステップS401でYes)、処理はステップS402へ進む。また、輻輳状態でないと判定した場合(ステップS401でNo)、処理はステップS410へ進み、ステップS410の処理後に終了する。

0059

ステップS402では、制御指示部16が桁数Nの局番を規制対象とする制御指示を含む制御指示情報を発呼規制セッション制御装置に送信する(図4のステップS302,S307,S312に対応)。ただし、桁数Nの局番は、図1(a)に示す初動時には、網管制者によって設定される。

0060

ステップS403では、演算部12は、規制対象の局番のトラヒック量に関するトラヒック状況情報を受信する(図4のステップS304,S309,S314に対応)。そして、演算部12は、トラヒック状況情報から局番のトラヒック量を取得する。

0061

ステップS404では、番号展開部13は、トラヒック状況情報(トラヒック量)に基づいて、要因局番を抽出する(図4のステップS305,S310に対応)。具体的には、番号展開部13は、演算部12によって取得された規制対象の局番ごとにトラヒック量とトラヒック閾値とを比較し、トラヒック量がトラヒック閾値を超える場合、その局番を要因局番であると判定し、トラヒック量がトラヒック閾値以下である場合その局番は要因局番でないと判定する。要因局番であると判定された局番は、記憶部15に記憶される。

0062

ステップS405では、番号展開部13は、要因局番があるかないかを判定する。
要因局番があると判定した場合(ステップS405でYes)、処理はステップS406へ進む。また、要因局番がないと判定した場合(ステップS405でNo)、処理はステップS401へ戻る。

0063

ステップS406では、番号展開部13は、桁数Nの要因局番の下位の桁を追加し、新たな桁数N+1の局番を生成する(図4のステップS306,S311に対応)。

0064

ステップS407では、制御指示情報生成部14は、新たな桁数N+1の局番が、所定の条件に到達したか否かを判定する。なお、所定の条件とは、(A)規制対象となる局番の桁数が所定の閾値(例えば、市町村単位の局番の桁数)を超える場合、(B)制御指示を行う局番の数が局番数に関する所定の閾値を超える場合、(C)輻輳状態が解消した場合、のいずれかまたは複数の組み合わせである。
所定の条件に到達したと判定した場合(ステップS407でYes)、処理はステップS401へ戻る。また、所定の条件に到達していないと判定した場合(ステップS407でNo)、処理はステップS408へ進む。

0065

ステップS408では、制御指示情報生成部14は、局番の桁数を表すNをN+1の値に更新する。

0066

ステップS409では、制御指示情報生成部14は、桁数Nの局番を規制対象とする制御指示を含む制御指示情報を生成する。

0067

ステップS410では、演算部12が輻輳セッション制御装置に輻輳状況情報の送信を停止することを示す送信停止指示を送信する。

0068

以上、本実施形態で説明した輻輳制御装置10は、まず、輻輳が発生したときの初動時に、輻輳セッション制御装置が収容する局番同士の前方一致の局番(短桁)を用いて、発呼規制セッション制御装置に対して規制制御を実行する。このことによって、輻輳発生時に迅速な制御の開始を実現することができる。次に、輻輳制御装置10は、発呼規制セッション制御装置から受信したトラヒック状況情報に基づいて、要因局番を抽出する。そして、輻輳制御装置10は、その抽出した要因局番の下位の桁を番号展開し、その番号展開した局番を規制対象とする制御指示を含む制御指示情報を生成し、発呼規制セッション制御装置に送信して、発呼規制セッション制御装置の規制制御を実行する。このように、要因番号を抽出するために番号展開を繰り返し実行して、規制対象となる局番が所定の条件に到達するまで要因局番を絞り込んでいくことによって、網リソースの最大活用を可能とする輻輳制御を実現することができる。

0069

なお、本実施形態では、トラヒック量とトラヒック閾値とを比較(絶対比較)するように説明したが、これに限られず、局番をトラヒック量が大きい順に並べたとき、相対比較として、大きい方から順に上位に入る局番を番号展開する対象として選択しても構わない。
また、局番をトラヒック量が大きい順に並べたとき、相対比較として、小さい方から順に下位に入る局番を監視対象から外しても構わない。

0070

また、本実施形態では、要因局番でないと判定された局番については、規制対象から外し、番号展開は行わすに監視対象としてトラヒック量を収集することを説明した。この監視対象とする処理の具体例について以下に説明する。まず、図5のステップS409において、制御指示情報生成部14が、要因局番でないと判定した局番を監視対象とする制御指示を含む制御指示情報を生成する。次に、ステップS402〜S403において、演算部12が、当該制御指示情報を発呼規制セッション制御装置に送信し、当該発呼規制セッション制御装置から、その要因局番でないと判定した局番のトラヒック量を取得する。そして、ステップS404において、番号展開部13が、当該トラヒック量とトラヒック閾値とを比較して、その要因局番でないと判定した局番が要因局番か否かを判定すれば良い。

0071

また、本実施形態では、要因局番として、1つの局番が抽出された場合について説明したが、複数の要因局番が抽出された場合には、それぞれの要因局番に対して、それぞれ番号展開しては要因局番を抽出する処理を繰り返して実行する。ただし、複数の要因局番が抽出された場合には、制御指示の数の増加が早くなるため、制御指示の総数に上限値を設け、その上限値以上の場合には番号展開を行わないようにすることが好ましい。

0072

また、本実施形態では、セッション制御装置としてソフトスイッチの場合で説明したが、当該ソフトスイッチの機能をハードウェアによって実現したスイッチであっても構わない。

0073

また、本実施形態において説明した、輻輳制御装置10は、一般的なコンピュータに、前記した各処理のプログラムを実行させることで実現することができる。このプログラムは、通信回線を介して提供することが可能であり、CD−ROM(Compact Disc-Read Only Memory)等の記録媒体に書き込んで配布することも可能である。

0074

1,1a輻輳制御システム
10,10a輻輳制御装置
11制御情報決定部
12演算部
13番号展開部
14制御指示情報生成部
15 記憶部
16制御指示部
20(20A,20B,20C)セッション制御装置
21発呼規制要求部
22リソース監視部
23CPU使用率測定部
24接続要求処理部
25 発呼規制部
30 端末

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ