特許第5857823号(P5857823)IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 沖電気工業株式会社の特許一覧

特許5857823制御装置及びプログラム、並びに、呼制御システム、並びに、通信システム
<>
  • 特許5857823-制御装置及びプログラム、並びに、呼制御システム、並びに、通信システム 図000002
  • 特許5857823-制御装置及びプログラム、並びに、呼制御システム、並びに、通信システム 図000003
  • 特許5857823-制御装置及びプログラム、並びに、呼制御システム、並びに、通信システム 図000004
  • 特許5857823-制御装置及びプログラム、並びに、呼制御システム、並びに、通信システム 図000005
  • 特許5857823-制御装置及びプログラム、並びに、呼制御システム、並びに、通信システム 図000006
  • 特許5857823-制御装置及びプログラム、並びに、呼制御システム、並びに、通信システム 図000007
  • 特許5857823-制御装置及びプログラム、並びに、呼制御システム、並びに、通信システム 図000008
  • 特許5857823-制御装置及びプログラム、並びに、呼制御システム、並びに、通信システム 図000009
  • 特許5857823-制御装置及びプログラム、並びに、呼制御システム、並びに、通信システム 図000010
  • 特許5857823-制御装置及びプログラム、並びに、呼制御システム、並びに、通信システム 図000011
  • 特許5857823-制御装置及びプログラム、並びに、呼制御システム、並びに、通信システム 図000012
  • 特許5857823-制御装置及びプログラム、並びに、呼制御システム、並びに、通信システム 図000013
  • 特許5857823-制御装置及びプログラム、並びに、呼制御システム、並びに、通信システム 図000014
  • 特許5857823-制御装置及びプログラム、並びに、呼制御システム、並びに、通信システム 図000015
  • 特許5857823-制御装置及びプログラム、並びに、呼制御システム、並びに、通信システム 図000016
  • 特許5857823-制御装置及びプログラム、並びに、呼制御システム、並びに、通信システム 図000017
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】5857823
(24)【登録日】2015年12月25日
(45)【発行日】2016年2月10日
(54)【発明の名称】制御装置及びプログラム、並びに、呼制御システム、並びに、通信システム
(51)【国際特許分類】
   H04M 3/00 20060101AFI20160128BHJP
【FI】
   H04M3/00 B
【請求項の数】8
【全頁数】19
(21)【出願番号】特願2012-61991(P2012-61991)
(22)【出願日】2012年3月19日
(65)【公開番号】特開2013-197814(P2013-197814A)
(43)【公開日】2013年9月30日
【審査請求日】2014年11月17日
(73)【特許権者】
【識別番号】000000295
【氏名又は名称】沖電気工業株式会社
(74)【代理人】
【識別番号】100180275
【弁理士】
【氏名又は名称】吉田 倫太郎
(74)【代理人】
【識別番号】100090620
【弁理士】
【氏名又は名称】工藤 宣幸
(74)【代理人】
【識別番号】100161861
【弁理士】
【氏名又は名称】若林 裕介
(72)【発明者】
【氏名】小林 稔和
【審査官】 須藤 竜也
(56)【参考文献】
【文献】 特開2007−134840(JP,A)
【文献】 特表2008−530846(JP,A)
【文献】 特開2011−234309(JP,A)
【文献】 特開2010−171714(JP,A)
【文献】 特開2006−270381(JP,A)
【文献】 特開2011−096161(JP,A)
【文献】 特開2005−354549(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
H04M 3/00
(57)【特許請求の範囲】
【請求項1】
複数の呼制御装置と協働して、通信装置に対して呼制御処理を提供する制御装置であって、
上記呼制御装置の動作を制御する動作制御手段と、
上記呼制御装置の動作状態を管理する動作状態管理手段と、
当該制御装置に到来した呼制御処理信号の処理を、いずれかの上記呼制御装置に振分ける振分手段とを有し、
上記動作制御手段は、当該制御装置に係るトラヒック量の測定結果に応じて、停止中の上記呼制御装置の起動を行い、
上記動作制御手段は、停止中の上記呼制御装置を起動させる際に、当該呼制御装置と、運転中の他の上記呼制御装置との間で、登録されている登録情報の内容を同期させる同期処理を行う
ことを特徴とする制御装置。
【請求項2】
上記通信装置から、当該通信装置に係る登録情報の登録を要求する登録要求信号が到来すると、上記呼制御装置のうち、少なくとも運転中の上記呼制御装置に、その登録要求信号を通知する登録要求信号処理手段をさらに有することを特徴とする請求項1に記載の制御装置。
【請求項3】
上記動作制御手段は、当該制御装置に係るトラヒック量の測定結果に応じて、一部の上記呼制御装置の停止を行うことを特徴とする請求項1又は2に記載の制御装置。
【請求項4】
上記動作制御手段は、上記呼制御装置を停止させる際に、当該呼制御装置が処理中の呼制御処理が終了するまで、当該呼制御装置を新規の呼制御処理を受付けない閉塞状態に制御することを特徴とする請求項3に記載の制御装置。
【請求項5】
上記動作制御手段は、停止中の上記呼制御装置を起動させる際に、当該呼制御装置について同期処理が完了するまで、当該呼制御装置を新規の呼制御処理を受付けない閉塞状態に制御することを特徴とする請求項に記載の制御装置。
【請求項6】
複数の呼制御装置と協働して、通信装置に対して呼制御処理を提供する制御装置に搭載されたコンピュータを、
上記呼制御装置の動作を制御する動作制御手段と、
上記呼制御装置の動作状態を管理する動作状態管理手段と、
当該制御装置に到来した呼制御処理信号の処理を、いずれかの上記呼制御装置に振分ける振分手段として機能させ、
上記動作制御手段は、当該制御装置に係るトラヒック量の測定結果に応じて、停止中の上記呼制御装置の起動を行い、
上記動作制御手段は、停止中の上記呼制御装置を起動させる際に、当該呼制御装置と、運転中の他の上記呼制御装置との間で、登録されている登録情報の内容を同期させる同期処理を行う
ことを特徴とする制御プログラム。
【請求項7】
通信装置に呼制御処理を提供する呼制御システムにおいて、
複数の呼制御装置と、上記呼制御装置と協働して上記通信装置に呼制御処理を提供する制御装置とを備え、
上記制御装置として請求項1〜のいずれかに記載の制御装置を適用したことを特徴とする呼制御システム。
【請求項8】
通信装置に呼制御処理を提供する通信システムにおいて、
上記通信装置に呼制御処理を提供する呼制御システムを1又は複数備え、
それぞれの上記呼制御システムとして、請求項に記載の呼制御システムを適用したことを特徴とする通信システム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、制御装置及びプログラム、並びに、呼制御システム、並びに、通信システムに関し、例えば、IMS(IP Multimedia Subsystem)システム上のCSCF(Call/Session Control Function)の制御に適用し得る。
【背景技術】
【0002】
近年、環境問題等により、消費電力の軽減が各種業界で検討及び導入が行われている。
【0003】
通信システムを構成する装置に関しても、利用者の少ない時間帯に関連機器を停止する等の手段が検討及び導入されている。
【0004】
例えば、従来の通信システムを構成する装置の省電力化を実現する技術としては、特許文献1の記載技術がある。特許文献1では、設定ポリシーに基づいて、トラヒック状況を踏まえ、装置に供給する電力量を制御することにより、省電力化を実現している。
【先行技術文献】
【特許文献】
【0005】
【特許文献1】特開2007−97126号公報
【特許文献2】特開2011−114423号公報
【特許文献3】特開2010−124740号公報
【特許文献4】特開2010−148023号公報
【非特許文献】
【0006】
【非特許文献1】ゴンザロ・カマリロ、ミゲール・A・ガルシア・マーチン著、澤田拓也他、鹿島拓也訳、「IMS標準テキスト NGNのコア技術」、2006年7月株式会社リックテレコム発行
【非特許文献2】3rd Generation Partnership Project(3GPP)編、「IP Multimedia Call Control Protocol based on Session Initiation Protocol (SIP) and Session Description Protocol(SDP).TS 24.229」、[Online]、INTERNET、[2012年3月7日検索],<URL: http://www.3gpp.org/ftp/Specs/archive/24_series/24.229/24229-810.zip>
【非特許文献3】3rd Generation Partnership Project(3GPP)編、「Signalling flows for the IP multimedia call control based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP).TS 24.228」、[Online]、INTERNET、[2012年3月7日検索],<URL: http://www.3gpp.org/ftp/Specs/archive/24_series/24.228/24228-5f0.zip>
【発明の概要】
【発明が解決しようとする課題】
【0007】
しかし、万人にサービスを提供することを前提にしている、通信事業者のネットワークにおいては、各種検討しているが、サービス利便性等の面でいくつか課題がある。特に、次世代の通信提供プラットフォームとなるIMSのアーキテクチャに適用した場合に関しては、既存の方式のみでは単純に対応できない。IMSは次世代ネットワーク(Next Generation Network;NGN)における中心的な技術であり、CSCFは、IMSにおいて極めて重要なノードで、SIP(Session Initiation Protocol)サーバとして、SIPメッセージの処理を行う。CSCFには機能により、P−CSCF(Proxy−CSCF)、I-CSCF(Interrogating−CSCF)、S−CSCF(Serving−CSCF)の3種類のいずれかに属する(非特許文献1参照)。
【0008】
そして、IMSアーキテクチャにおいて、呼制御の中核をなすS−CSCFは、端末(通信装置)からの初回位置登録(REGISTER)時に割り当てられる前提であり、単純にトラヒックの状況等で停止してしまうと、ユーザサービスに支障を来たす場合がある。
【0009】
そのため、省電力化を実現しつつ、安定的な呼制御処理を実現することができる制御装置及びプログラム、並びに、呼制御システム、並びに、通信システムが望まれている。
【課題を解決するための手段】
【0010】
第1の本発明は、複数の呼制御装置と協働して、通信装置に対して呼制御処理を提供する制御装置であって、(1)上記呼制御装置の動作を制御する動作制御手段と、(2)上記呼制御装置の動作状態を管理する動作状態管理手段と、(3)当該制御装置に到来した呼制御処理信号の処理を、いずれかの上記呼制御装置に振分ける振分手段とを有し、(4)上記動作制御手段は、当該制御装置に係るトラヒック量の測定結果に応じて、停止中の上記呼制御装置の起動を行い、(5)上記動作制御手段は、停止中の上記呼制御装置を起動させる際に、当該呼制御装置と、運転中の他の上記呼制御装置との間で、登録されている登録情報の内容を同期させる同期処理を行うことを特徴とする。
【0011】
第2の本発明の制御プログラムは、(1)複数の呼制御装置と協働して、通信装置に対して呼制御処理を提供する制御装置に搭載されたコンピュータを、(2)上記呼制御装置の動作を制御する動作制御手段と、(3)上記呼制御装置の動作状態を管理する動作状態管理手段と、(4)当該制御装置に到来した呼制御処理信号の処理を、いずれかの上記呼制御装置に振分ける振分手段として機能させ、(5)上記動作制御手段は、当該制御装置に係るトラヒック量の測定結果に応じて、停止中の上記呼制御装置の起動を行い、(6)上記動作制御手段は、停止中の上記呼制御装置を起動させる際に、当該呼制御装置と、運転中の他の上記呼制御装置との間で、登録されている登録情報の内容を同期させる同期処理を行うことを特徴とする。
【0012】
第3の本発明は、通信装置に呼制御処理を提供する呼制御システムにおいて、複数の呼制御装置と、上記呼制御装置と協働して上記通信装置に呼制御処理を提供する制御装置とを備え、上記制御装置として第1の本発明の御装置を適用したことを特徴とする呼制御システム。
【0013】
第4の本発明は、通信装置に呼制御処理を提供する通信システムにおいて、(1)上記通信装置に呼制御処理を提供する呼制御システムを1又は複数備え、(2)それぞれの上記呼制御システムとして、第2の本発明の呼制御システムを適用したことを特徴とする。
【発明の効果】
【0014】
本発明によれば、省電力化を実現しつつ、安定的な呼制御処理を実現する通信システムを提供することができる。
【図面の簡単な説明】
【0015】
図1】実施形態に係る通信システムの全体構成について示したブロック図である。
図2】実施形態に係るLB(制御装置)の機能的構成について示したブロック図である。
図3】実施形態に係るHSSの機能的構成について示したブロック図である。
図4】実施形態に係るトラヒック監視装置の機能的構成について示したブロック図である。
図5】実施形態に係るHSSで管理されるデータについて示した説明図である。
図6】実施形態に係るLBで管理されるデータについて示した説明図である。
図7】実施形態に係るトラヒック監視装置で管理されるデータについて示した説明図である。
図8】実施形態に係るS−CSCFグループで、全てのS−CSCFが運転中の状態で、REGISTER信号が供給された場合の動作について示したシーケンス図である。
図9】実施形態に係るLBでREGISTER信号が供給された場合の動作について示したフローチャートである。
図10】実施形態に係るS−CSCFグループで、サーバ停止が発生する場合の動作について示したシーケンス図である。
図11】実施形態に係るS−CSCFグループで、サーバ停止が発生する場合のLBの動作について示したフローチャートである。
図12】実施形態に係るS−CSCFグループで、一部のS−CSCFが停止状態で、REGISTER信号が供給された場合の動作について示したシーケンス図である。
図13】実施形態に係るS−CSCFグループで、発呼(INVITE信号)を受けた場合の動作について示したシーケンス図である。
図14】実施形態に係るLBで、発呼(INVITE信号)を受けた場合の動作について示したフローチャートである。
図15】実施形態に係るS−CSCFグループで、サーバ起動が発生する場合の動作について示したシーケンス図である。
図16】実施形態に係るS−CSCFグループで、サーバ起動が発生する場合のLBの動作について示したフローチャートである。
【発明を実施するための形態】
【0016】
(A)主たる実施形態
以下、本発明による制御装置及びプログラム、並びに、呼制御システム、並びに、通信システムの一実施形態を、図面を参照しながら詳述する。なお、この実施形態の呼制御システムはS−CSCFグループである。また、この実施形態の制御装置は、LB(Load Balancer)である。
【0017】
(A−1)実施形態の構成
図1は、この実施形態の通信システム1の全体構成を示すブロック図である。
【0018】
通信システム1は、アクセスネットワークNWを介して、ユーザが利用する端末90(図1では、90−1、90−2)に対してネットワークサービスを提供するシステムであり、P−CSCF10、I−CSCF20、N個の呼制御システムとしてのS−CSCFグループ30(30−1〜30−N)、HSS70(Home Subscriber Server)、及びトラヒック監視装置80を有している。なお、アクセスネットワークNWの構成や、アクセスネットワークNWに接続する端末90の数は限定されないものである。
【0019】
また、アクセスネットワークNWの種類は限定されないものであり、例えば、インターネット等のIPネットワークを適用することができる。
【0020】
それぞれのS−CSCFグループ30(30−1〜30−N)は、代表S−CSCF(制御装置)としてのLB40(30−1〜30−N)と、LB40の配下で動作する3台のS−CSCF60(60−11〜60−13、60−21〜60−23、…、60−N1〜60−N3)により構成されている。例えば、図1では、S−CSCFグループ30−1は、1台のLB40−1と、3台の60−11〜60−13により構成されている。また、同様に、S−CSCFグループ30−Nは、1台のLB40−Nと、3台の60−N1〜60−N3により構成されている。なお、通信システム1においてS−CSCFグループ30を配置する数や、S−CSCFグループ30を構成するS−CSCF60の数は限定されないものである。
【0021】
P−CSCF10は端末90と通信システム1が最初に接するポイントであり、SIPのリクエスト/レスポンスを適切な装置(I−CSCF20等)にフォワードする。
【0022】
I−CSCF20は主にユーザ(端末90)の位置情報(当該ユーザのURIが登録(RESTER)されているS−CSCFのアドレス)をHSS70から取得し、SIPリクエストを取得したアドレス(LB40のアドレス)へフォワードする。
【0023】
HSS70は、通信システム1内で、ユーザ情報やサーバ(S−CSCFグループ30)等に関する情報を管理するものであり、I−CSCF20からの要求に応じて、各S−CSCFグループ30(端末90)へのユーザの振り分け先の決定等の制御機能も担っている。
【0024】
トラヒック監視装置80は、通信システム1内のトラヒック量をリアルタイムで監視し、トラヒック量等に応じて、LB40経由でS−CSCF60の起動/停止を実行する。
【0025】
次に、HSS70の内部構成について、図3を用いて説明する。
【0026】
HSS70は、I−CSCF20又は配下のS−CSCF60との通信を行う。
【0027】
HSS70は、LB/S−CSCF割付情報管理部71、ユーザプロファイル管理部72、及びサービスプロファイル管理部73を有している。
【0028】
ユーザプロファイル管理部72は、ユーザのプロファイルを管理する機能を担っている
サービスプロファイル管理部73は、サービスプロファイルを管理する機能を担っている。
【0029】
LB/S−CSCF割付情報管理部71は、S−CSCFグループ30ごとに所属する装置に関する情報(以下、「グルーピング情報」と呼ぶ)も管理しているものとする。
【0030】
LB/S−CSCF割付情報管理部71は、例えば、図5のような形式で、グルーピング情報や、各S−CSCFグループ30に対して割り付けているユーザ数(割付ユーザ数)を管理している。
【0031】
なお、通信システム1では、図5等に示すように、各S−CSCFグループ30、各LB40、各S−CSCF60に対してIDを付与して管理する構成となっている。また、通信システム1では、図5に示すように、各S−CSCFグループ30(30−1〜30−N)のID(グループID)は、それぞれ1〜Nと表わすものとする。さらに、通信システム1では、図5に示すように、各LB40−1〜40−NのID(LB−ID)は、それぞれ1〜Nと表わすものとする。さらにまた、通信システム1では、図5に示すように、各S−CSCF60(60−11〜60−13、60−21〜60−23、…、60−N1〜60−N3)のID(S−CSCF−ID)は、11〜13、21〜23、…、N1〜N3)と表わすものとする。例えば、S−CSCFグループ30−1のグループIDは1、LB40−1のLB−IDは1、S−CSCF60−11のS−CSCF−IDは11となる。
【0032】
図5では、S−CSCFグループ30の単位(グループID単位)で、配下のLB−ID及び管理対象S−CSCF_IDが管理されている。また、図5では、グループIDごと(S−CSCFグループ30)ごとに、割り当てたユーザ数(割付ユーザ数)も管理されている。
【0033】
次に、各LB40の内部構成について図2を用いて説明する。なお、この実施形態では、全てのS−CSCFグループ30において、LB40は全て同じ構成であるものとして説明する。
【0034】
LB40は、配下のS−CSCF60と協働して、端末90に対してSIPのサービス(呼制御処理のサービス)を提供する。また、LB40は、配下の複数のS−CSCF60にINVITE信号等の信号処理を振り分ける負荷分散装置としても機能する。
【0035】
LB40は、REGISTER信号を受信した場合、配下の全ての運転中又は閉塞中のS−CSCF60にフォワードする。また、LB40は、セッション制御受信時(INVITE信号受信時)は、配下のS−CSCF60のうち、1台を選択してINVITE信号を信号フォワードする。そして、配下のS−CSCF60は、それぞれSIPのセッション制御機能やレジストラサーバとして動作する。上述の通り、通信システム1では、S−CSCFに関するサービスを提供する単位としてS−CSCFグループ30が存在し、それぞれのS−CSCFグループ30では、複数のS−CSCF(LB40及びS−CSCF60)が配置されている。すなわち、P−CSCF10から見た場合、各S−CSCFグループ30は1つのS−CSCFとして動作するものとして把握される。言い換えると、P−CSCF10が、各S−CSCFグループ30に対して意識するのは、代表S−CSCFであるLB40のみとなる。
【0036】
LB40は、信号制御部41、S−CSCF起動/停止部42、ルーチング情報処理部43、S−CSCF状態管理部44、REGISTER情報管理部45、S−CSCF管理情報記憶部46を有している。
【0037】
信号制御部41は、配下のS−CSCF60とSIP信号の送受信制御を行うものである。
【0038】
S−CSCF起動/停止部42は、トラヒック監視装置80からのS−CSCF起動/停止指示を受付、配下のS−CSCF60の起動/停止を制御するものである。
【0039】
ルーチング情報処理部43は、SIP信号のルーチング制御をするものである。
【0040】
REGISTER情報管理部45は、REGISTER情報を管理するものである。
【0041】
S−CSCF状態管理部44は、配下のS−CSCF60に関する情報を管理するものである。この実施形態のS−CSCF状態管理部44では、例として、図6のような形式で、配下のS−CSCF60に関する情報が管理されているものとする。
【0042】
S−CSCF状態管理部44では、図6に示すように、SIP−URI(端末90)ごとの、REGISTER情報(Contact情報、Path情報等)や、配下の各S−CSCF60への、当該SIP−URIに係るREGISTER情報の登録状況(最終REGISTER更新時間)などを管理している。また、S−CSCF状態管理部44では、配下の各S−CSCF60の運転状況(運転中、停止中又は閉塞中のいずれか)を管理している。
【0043】
例えば、図6では、「AAA」、「BBB」というSIP−URIに関する情報が登録されている。また、図6では、「AAA」、「BBB」に関するREGISTER情報について、最終RESGISTER更新時間が設定されているS−CSCF60−1、60−3には登録されていることを示している。一方、「AAA」、「BBB」に関するREGISTER情報について、最終RESGISTER更新時間が設定されていないS−CSCF60−2には登録されていないことを示している。
【0044】
LB40では、例えば、図6に示すようなS−CSCF状態管理部44の情報により、配下の各S−CSCF60へのREGISTER情報の登録状況を把握している。そして、LB40のS−CSCF起動/停止部42は、停止しているS−CSCF60が次に起動したときに、他のS−CSCF60と登録内容を同期させる処理を行う。具体的には、LB40は、図6に示すようなS−CSCF状態管理部44の情報(各SIP−URIに関する最終REGISTER更新時間等)を確認して、起動したS−CSCF60と他のS−CSCF60との差異を確認し、他のS−CSCF60と同期させるためのREGISTER信号を生成して起動したS−CSCF60に供給する。また、LB40のS−CSCF起動/停止部42は、起動したS−CSCF60について、他のS−CSCF60とREGISTER情報の同期がとれるまで、新たな呼制御(INVITE信号等の処理)を受付けない閉塞状態として制御する。
【0045】
次に、トラヒック監視装置80の内部構成について図4を用いて説明する。
【0046】
トラヒック監視装置80は、トラヒック状況監視部81、トラヒック状況分析部82、S−CSCF運転ポリシー情報管理部83、S−CSCFサーバ状態管理部84、及びS−CSCF起動/停止処理部85を有している。
【0047】
トラヒック状況監視部81は、通信システム1におけるトラヒック情報(アクセス状況)に関する情報を収集する機能を担っている。トラヒック状況監視部81は、各LB40−1〜30−Nと、I−CSCF20に流れる信号数(例えば、SIPメッセージ数)を、トラヒック情報として収集する。
【0048】
トラヒック状況分析部82は、トラヒック状況監視部81が収集したトラヒック情報を分析する機能を担っている。トラヒック状況分析部82は、トラヒック状況監視部81の収集した内容に基づいて、I−CSCF20及び各LB40に流れる単位時間当たりの信号数(例えば、SIPメッセージ数)を把握する。この実施形態では、トラヒック状況分析部82は、例として、1時間あたりに、I−CSCF20及び各LB40に流れるSIPメッセージ数を把握するものとする。
【0049】
S−CSCF運転ポリシー情報管理部83は、各S−CSCFグループ30のS−CSCF60の運転ポリシーを管理する機能を担っている。S−CSCF運転ポリシー情報管理部83では、S−CSCFグループ30ごとに、運転中のS−CSCF60を停止するポリシー(以下、「サーバ停止ポリシー」と呼ぶ)及び、運転中のS−CSCF60を停止するポリシー(以下、「サーバ起動ポリシー」と呼ぶ)を管理している。S−CSCF運転ポリシー情報管理部83が管理する運転ポリシーの内容詳細については後述する。
【0050】
S−CSCFサーバ状態管理部84は、各S−CSCFグループ30のS−CSCF60の運転状態を管理する機能を担っている。例えば、S−CSCFサーバ状態管理部84は、各LB40へ問合せを行って各S−CSCFグループ30のS−CSCF60の運転状態を把握するようにしても良い。
【0051】
S−CSCF起動/停止処理部85は、各S−CSCFグループ30のS−CSCF60に対して、起動/停止指示を行う機能を担っている。S−CSCF起動/停止処理部85は、S−CSCF運転ポリシー情報管理部83で管理されている運転ポリシーにしたがって、各LB40に配下のS−CSCF60に対する起動又は停止に関する制御指示を行う。
【0052】
次に、トラヒック監視装置80のS−CSCFサーバ状態管理部84で記憶される運転ポリシーの構成例について説明する。この実施形態のトラヒック監視装置80では、例として、図7のような形式で各S−CSCFグループ30の運転ポリシーを管理しているものとする。
【0053】
S−CSCF運転ポリシー情報管理部83では、S−CSCFグループ30(LB40)ごとに、現在のトラヒック量(トラヒック状況分析部82の分析結果)、サーバ停止ポリシー、サーバ停止ポリシーで適用する閾値(サーバ停止第1閾値、及び、サーバ停止第2閾値)、サーバ起動ポリシー、サーバ起動ポリシーで用いる閾値(サーバ起動第1閾値、及び、サーバ起動第2閾値)が管理されている。
【0054】
図7では、図示の都合上、S−CSCFグループ30−1(LB40−1)に係るサーバ停止ポリシーについてはPD1、サーバ起動ポリシーについてはPU1としている。そして、図7では、サーバ停止ポリシーPD1については図7(b)に示し、サーバ起動ポリシーPU1については図7(c)に示している。運転ポリシー(サーバ停止ポリシー、サーバ起動ポリシー)を記述するための言語や形式については限定されないものであるが、図7では、説明を簡易とするために自然言語を用いて図示している。実際には、例えば、図7に示すような内容を具現化する記述(プログラム言語を用いた記述)を行う必要がある。
【0055】
上述の通り、サーバ停止ポリシーを記述する形式や内容については限定されないものであるが、図7(b)に示すサーバ停止ポリシーPD1では、LB40−1のトラヒック量(1時間あたりのSIP信号処理数)が下がるほど、多くのサーバ(S−CSCF60)を停止させるポリシーとしている。図7(b)に示すサーバ停止ポリシーPD1(ポリシー番号1、2)では、2つのサーバ停止閾値TD1、TD2(TD1>TD2)を用いて、トラヒック量の下降に伴って段階的に多くのサーバ(S−CSCF60)を停止するポリシーとなっている。なお、用いるサーバ停止閾値の数は限定されないものである。
【0056】
ただし、図7(b)に示すサーバ停止ポリシーPD1(ポリシー番号3)では、時刻が9:00〜12:00の間は、トラヒック量に関係なくサーバ(S−CSCF60)を停止させないポリシーとなっている。
【0057】
上述の通り、サーバ起動ポリシーを記述する形式や内容については限定されないものであるが、図7(c)に示すサーバ起動ポリシーPU1では、LB40−1のトラヒック量(1時間あたりのSIP信号処理数)が上がるほど、多くのサーバ(S−CSCF60)を起動させるポリシーとしている。図7(c)に示すサーバ起動ポリシーPU1(ポリシー番号1、2)では、2つのサーバ起動閾値TU1、TU2(TU1<TU2)を用いて、トラヒック量の上昇に伴って段階的に多くのサーバ(S−CSCF60)を起動するポリシーとなっている。なお、用いるサーバ起動閾値の数は限定されないものである。ただし、図7(c)に示すサーバ起動ポリシーPU1(ポリシー番号3)では、時刻が9:00〜12:00の間は、トラヒック量に関係なく全てのサーバ(S−CSCF60)を起動させるポリシーとなっている。
【0058】
以上ように、S−CSCF運転ポリシー情報管理部83では、当該LB40のトラヒック量等を利用してS−CSCF60を起動/停止する条件を自由に設定することが可能である。そして、S−CSCF起動/停止処理部85は、S−CSCF運転ポリシー情報管理部83で定義された運転ポリシーに従って、各LB40に配下のS−CSCF60の停止又は起動を指示する。
【0059】
(A−2)実施形態の動作
次に、以上のような構成を有する実施形態の通信システム1の動作を説明する。
【0060】
以下では、説明を簡易とするために、S−CSCFグループ30−1〜30−Nのうち、S−CSCFグループ30−1に係る動作についてのみ説明するが、他のS−CSCFグループ30内の動作についても同様である。
【0061】
まず、端末90−1からREGISTER信号が送出された場合の通信システム1の動作について、図8図9を用いて説明する。なお、ここでは、初期状態として、S−CSCFグループ30−1内で、3つのS−CSCF60−11〜60−13の全てが運転中の状態であるものとする。
【0062】
図8は、端末90−1からREGISTER信号が送出された場合の通信システム1の動作について示したシーケンス図である。また、図9は、LB40−1が、REGISTER信号を受信する場合の動作について示したフローチャートである。
【0063】
まず、端末90−1から、送出されたREGISTER信号が、P−CSCF10を介して、I−CSCF20で受信されたものとする(S101)。
【0064】
そして、I−CSCF20は、HSS70に対して、当該REGISTER信号の処理をいずれのLB40にルーチングするか(振り分けるか)を問い合わせる(S102)。
【0065】
そして、ここでは、HSS70において当該REGISTER信号についての処理(端末90−1の登録先)が、LB40−1(S−CSCFグループ30−1)に振り付けられ、LB40−1のアクセス情報(アドレス情報)が、I−CSCF20に通知されたものとする(S103)。
【0066】
そして、I−CSCF20は、その通知に基づいてLB40−1に、REGISTER信号をフォワードする(S104)。
【0067】
そして、REGISTER信号を受信すると、LB40−1では、配下のS−CSCF60のうち、運転中のS−CSCF60に対して、受信したREGISTER信号を複製して供給する(S105)。なお、ステップS105の処理は、図9のステップS201〜S204の処理に該当する。ここでは、上述の通り、全てのS−CSCF60−11〜60−13が運転中であるので、LB40−1は、図9のステップS204の処理により、全てのS−CSCF60−11〜60−13に対してREGISTER信号を供給することになる。なお、LB40−1の配下で、停止中のS−CSC60があった場合には、LB40−1は、図9のステップS203の処理により、運転中又は閉塞中のS−CSC60に対してのみREGISTER信号を送信することになる。
【0068】
そして、LB40−1は、全てのS−CSCF60−11〜60−13から、REGISTER信号について正常に処理されたことを示す応答信号(OKのSIP信号)が返答されると、自身のS−CSCF管理情報記憶部46等の情報をそのREGISTER信号に基づいて更新(端末90−1に関する情報(行)を追加してREGISTER情報を設定)し、さらに、当該REGISTER信号に対するOKの応答信号(OKのSIPメッセージ)を生成して、端末90−1宛に返答する(S106、S107)。なお、ステップS106、S107の処理は、図9のステップS206〜S209の処理に該当する。
【0069】
ここでは、全てのS−CSCF60−11〜60−13からOKの応答信号が返答され、LB40−1は、図9のステップS208、S209の処理により、S−CSCF管理情報記憶部46の情報を更新すると共に、OKの応答信号(Service−Routeヘッダに自信のアドレスを設定したSIPメッセージ)を返答したものとする。
【0070】
なお、LB40−1に、配下のS−CSCF60のいずれかから、NGの応答信号(NGのSIPメッセージ)が供給された場合には、LB40−1は、図9のステップS207の処理により、NGの応答信号(Service−Routeヘッダに自身のアドレスを設定したSIPメッセージ)を生成して、端末90−1宛に送信することになる。
【0071】
次に、通信システム1において、S−CSCFグループ30−1のサーバ(S−CSCF60)停止が行われる場合の動作について図10図11を用いて説明する。図10は、トラヒック監視装置80において、サーバ停止ポリシーに基づいて、S−CSCFグループ30−1(LB40−1)のサーバ(S−CSCF60)停止を行うと判断された場合の通信システム1の動作について示したシーケンス図である。また、図11は、LB40−1が、トラヒック監視装置80からサーバ停止指示を受けた場合の動作について示したフローチャートである。
【0072】
なお、ここでは、初期状態として、S−CSCFグループ30−1内で、3つのS−CSCF60−11〜60−13の全てが動作している状態であるものとする。そして、トラヒック監視装置80のS−CSCFサーバ状態管理部84には、図7に示すサーバ停止ポリシーPD1が設定されているものとする。
【0073】
まず、上述の通り、S−CSCFグループ30−1内で、3つのS−CSCF60−11〜60−13の全てが動作している状態で、トラヒック監視装置80がLB40−1のトラヒック量を監視しているものとする(S301)。
【0074】
そして、トラヒック監視装置80において、LB40−1のトラヒック量が、サーバ停止第1閾値以下となったことが検知され(S302)、S−CSCF運転ポリシー情報管理部83に定義されたサーバ停止ポリシーに従って、LB40−1に対してサーバ停止指示が行われたものとする(S303)。
【0075】
そして、LB40−1では、トラヒック監視装置80からの通知に従って、S−CSCF60−11〜60−13から停止するものを1つ選択して、選択したS−CSCF60(ここでは、S−CSCF60−13であるものとする)に、サーバ閉塞指示を通知する(S304)。なお、LB40−1によるステップS304の処理は、図11のステップS401、S402の処理に該当する。
【0076】
そして、LB40−1は、閉塞指示をしたS−CSCF60−13において、実行中(制御中)の呼(セッション)が無くなるまで待機した後、S−CSCF60−13に対してサーバ停止指示を通知し、S−CSCF60−13の動作を停止させる(S305、S306)。なお、LB40−1によるステップS305の処理は、図11のステップS403〜S405の処理に該当する。
【0077】
このとき、S−CSCF60−13は、動作を停止するが、その後の起動指示に応じて起動する必要があるため、本明細書では、ネットワーク経由で指示信号を受信して起動することが可能な状態(スリープ状態)を「停止状態」と呼ぶものとする。これは、他のS−CSCF60が停止する場合でも同様である。
【0078】
次に、S−CSCFグループ30−1内で、1つのS−CSCF60−13が停止した状態で、端末90−1から送出されたREGISTER信号がLB40−1にフォワードされる場合の動作について、図12を用いて説明する。
【0079】
まず、ここでは、上述のステップS101〜S104と同様に、端末90−1から送出されたREGISTER信号がLB40−1にフォワードされたものとする(S501〜S504)。
【0080】
そして、REGISTER信号を受信すると、LB40−1は、配下のS−CSCF60のうち、運転中のS−CSCF60−11、60−12に対して、受信したREGISTER信号を複製して供給する(S505)。ここでは、上述の通り、全てのS−CSCF60−11、60−12のみが運転中(S−CSCF60−13が停止中)であるので、LB40−1は、図9のステップS203の処理により、S−CSCF60−11、60−12に対してREGISTER信号を供給することになる。
【0081】
そして、LB40−1は、REGISTER信号を供給したS−CSCF60−11、60−12から、REGISTER信号に対して正常に処理されたことを示す応答信号(OKのSIP信号)が返答されると、自身のS−CSCF管理情報記憶部46の情報をそのREGISTER信号に基づいて更新(端末90−1に関する情報(行)を追加してREGISTER情報を設定)し、さらに、当該REGISTER信号に対するOKの応答信号(OKのSIPメッセージ)を生成して、端末90−1宛に返答する(S506、S507)。
【0082】
次に、端末90−1から、INVITE信号が送出された場合の、通信システム1の動作について図13図14を用いて説明する。なお、S−CSCFグループ30−1内で、2つのS−CSCF60−11、60−12が動作状態(S−CSCF60−13は停止中)であるものとする。図13は、端末90−1から、端末90−1に発呼するためのINVITE信号が送出された場合の通信システム1の動作について示したシーケンス図である。また、図14は、LB40−1が、INVITE信号を受信する場合の動作について示したフローチャートである。
【0083】
まず、端末90−1から、送出されたINVITE信号がP−CSCF10で受信されたものとする。そして、P−CSCF10は、端末90−1のINVITE信号上のRouteヘッダに基づいて、LB40−1(S−CSCFグループ30−1)に、INVITE信号をフォワードするものとする(S601)。
【0084】
そして、LB40−1は、INVITE信号を受信すると(S602)、配下のS−CSCF60の運転状況を確認し、運転中のS−CSCF60の中からいずれかのS−CSCF60を選択してINVITE信号を送信する(S603)。なお、ステップS602、S603の処理は、図14のステップS701〜S704の処理に該当する。ここでは、LB40−1は、S−CSCF60−11を選択してINVITE信号を送信したものとする。
【0085】
そして、選択されたS−CSCF60−11は、受信した信号内容に基づいて以降の着信処理を開始し、実行する(S604)。なお、S−CSCF60−11によるS604以降の処理の詳細については図示していないが、例えば、従来のS−CSCFの処理を適用することができる。なお、ステップS603、S604の処理は、図14のステップS705、S706の処理に該当する。
【0086】
次に、通信システム1において、S−CSCFグループ30−1のサーバ(S−CSCF60)起動が行われる場合の動作について図15図16を用いて説明する。図15は、トラヒック監視装置80において、サーバ起動ポリシーに基づいて、S−CSCFグループ30−1(LB40−1)のサーバ(停止中のS−CSCF60)起動を行うと判断された場合の通信システム1の動作について示したシーケンス図である。また、図16は、LB40−1が、トラヒック監視装置80からサーバ起動指示を受けた場合の動作について示したフローチャートである。
【0087】
なお、ここでは、初期状態として、S−CSCFグループ30−1内で、1つのS−CSCF60−13が停止している状態であるものとする。そして、トラヒック監視装置80のS−CSCFサーバ状態管理部84には、図7に示すサーバ起動ポリシーPU1が設定されているものとする。
【0088】
まず、上述の通り、S−CSCFグループ30−1内で、1つのS−CSCF60−13が停止している状態で、トラヒック監視装置80がLB40−1のトラヒック量を監視しているものとする(S801)。
【0089】
そして、トラヒック監視装置80において、LB40−1のトラヒック量が、サーバ起動第2閾値以上となったことが検知され(S802)、S−CSCF運転ポリシー情報管理部83に定義されたサーバ起動ポリシーPU1に従って、LB40−1に対してサーバ起動指示が行われたものとする(S803)。
【0090】
そして、LB40−1では、トラヒック監視装置80からの通知に従って、唯一停止しているS−CSCF60−13を選択して、サーバ起動指示を通知する(S804)。なお、LB40−1によるステップS804の処理は、図16のステップS901、S902の処理に該当する。
【0091】
そして、起動指示が通知されたS−CSCF60−13では、停止状態(スリープ状態)から起動し(S805)、当初は閉塞状態に遷移する(S806)。
【0092】
そして、LB40−1は、S−CSCF60−13の動作状態を監視して、起動完了すると、S−CSCF管理情報記憶部46を参照して、SIP−URIごとに、最終REGISTER時刻と、REGISTER情報をチェックする。そして、LB40−1は、S−CSCF60−13に不足しているREGISTER情報(他のS−CSCF60−11、60−12と比較して不足しているREGISTER情報)があった場合、その情報をS−CSCF60−13に追加するためのREGISTER信号を順次生成して、S−CSCF60−13に送信する等の処理を行い、S−CSCF60−13と、他のS−CSCF60−11、60−12とのREGISTER情報の同期を取る(S807)。なお、LB40−1によるステップS805、S806の処理は、図16のステップS905〜S907の処理に該当する。
【0093】
そして、LB40−1は、REGISTER情報の同期処理が完了するとS−CSCF60−13に対して、閉塞解除を解除して、通常の運転中の状態に遷移する指示を通知し(S809)、S−CSCF60−13は閉塞状態を解除して運転中の状態に遷移する(S810)。なお、LB40−1によるステップS809の処理は、図16のステップS908の処理に該当する。
【0094】
(A−3)実施形態の効果
この実施形態によれば、以下のような効果を奏することができる。
【0095】
通信システム1では、複数のS−CSCF60をグルーピングしてS−CSCFグループ30(呼制御処理システム)を構成すること、および、トラヒック監視装置80との連携、必要情報を管理することで、トラヒック量等に応じたサーバ(S−CSCF60等)の効率的な運用を行うことができる。例えば、通信システム1では、トラヒックの少ない時間帯等はサーバの運転台数を減らしてサービスできる。また、通信システム1では、例えば、トラヒック上昇時等も柔軟にサーバ起動を行うことが可能となっており、サーバ停止による利便性の低下を防いでいる。すなわち、通信システム1では、トラヒック量等により柔軟に起動するサーバ数を制御できるので、省電力化を実現しつつ、安定的な呼制御処理を実現することができる。
【0096】
また、通信システム1及びS−CSCFグループ30の構成は、IMSの構成に準拠しており、連携するP−CSCF/I−CSCF等は特別な動作を意識する必要はなく、既存の事業者ネットワークに簡易に適用することが可能である。
【0097】
(B)他の実施形態
本発明は、上記の実施形態に限定されるものではなく、以下に例示するような変形実施形態も挙げることができる。
【0098】
(B−1)上記の実施形態では、通信システム1に複数のS−CSCFグループ30が配置される構成となっているが、1つのS−CSCFグループ30だけを配置するようにしても良い。その場合、LB40は、P−CSCF10やI−CSCF20を介さずに直接端末90と通信する構成としても良い。すなわち、LB40がSIPサービス(呼制御処理)を提供する通信装置(端末90)と通信する際の接続構成については、上記の実施形態の構成限定されないものである。
【0099】
(B−2)上記の実施形態では、トラヒック監視装置80が各S−CSCFグループ30に対する運転ポリシーを管理し、トラヒック量に応じてS−CSCF60の停止又は起動を指示する構成としている。しかし、通信システム1において、トラヒック量を監視する手段や、各S−CSCFグループ30に対する制御手段を実現する具体的構成については、上記の実施形態(トラヒック監視装置80を用いた構成)に限定されないものである。例えば、各LB40で、当該LB40に係る運転ポリシーの管理やトラヒック量の測定を行い、当該LB40の判断で配下のS−CSCF60に対する停止/起動の制御を行う構成としても良い。
【0100】
(B−3)上記の実施形態では、複数のサーバに分散して各種データ(例えば、運転ポリシーや各サーバの動作状況等)を管理する構成となっているが、一元的に別サーバ等で管理する構成としても良い。
【0101】
(B−5)上記の実施形態では、サーバ停止ポリシーに基づいてS−CSCF60を停止(スリープ状態)とするものとして説明したが、停止(スリープ状態)ではなく、より低消費電力で動作する動作モードであればその動作状態は限定されないものである。例えば、S−CSCF60のCPUを動作させる数や動作クロック数を下げることにより、低消費電力で動作させることができる。
【符号の説明】
【0102】
1…通信システム、NW…アクセスネットワーク、10…P−CSCF、20…I−CSCF、30、30−1〜30−N…S−CSCFグループ30、40、40−1〜40−N…LB、41…信号制御部、42…S−CSCF起動/停止部、43…ルーチング情報処理部、44…S−CSCF状態管理部、45…REGISTER情報管理部、46…S−CSCF管理情報記憶部、60、60−1〜60−3…S−CSCF60、70…HSS、71…LB/S−CSCF割付情報管理部、72…プロファイル管理部、73…サービスプロファイル管理部、80…トラヒック監視装置、81…トラヒック状況監視部、82…トラヒック状況分析部、83…S−CSCF運転ポリシー情報管理部、84…S−CSCFサーバ状態管理部、85…S−CSCF起動/停止処理部、90、90−1、90−2…端末。
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16