説明

呼処理並列化システムおよび呼処理並列化方法

【課題】呼処理シーケンスの並列処理化によって、呼処理の時間を短縮する。
【解決手段】呼処理並列化システム1では、端末20Aから発呼されたINVITEリクエストは、P−CSCF11Aを経由して信号振分装置12で受信される。信号振分装置12は、受信したINVITEリクエストを複製して、発側CSCF10Aおよび着側CSCF10Bにそれぞれ送信する。発側CSCF10Aおよび着側CSCF10Bは、受信したINVITEリクエストに対して、それぞれ並列処理を実行し、並列処理の完了後に、INVITEリクエストを発側着側処理完了確認装置13に送信する。そして、発側着側処理完了確認装置13は、発側CSCF10Aおよび着側CSCF10BのそれぞれからINVITEリクエストを受信した場合、P−CSCF11Bを介して着側の端末20Bに向けてINVITEリクエストを送信する。

【発明の詳細な説明】
【技術分野】
【0001】
本発明は、セッション制御サーバにおける呼処理の並列化技術に関する。
【背景技術】
【0002】
近年、次世代ネットワーク(NGN;Next Generation Network)(非特許文献1)では、アクセス網に依存せずに種々のマルチメディアサービスを提供するプラットフォームとして、IMS(IP Multimedia Subsystem)(非特許文献2)を導入する検討が進められている。IMSでは、2以上のクライアント端末間でセッションを確立するプロトコルとしてSIP(Session Initiation Protocol)(非特許文献3)が用いられる。そして、IMSにおいて、呼処理制御を実行するセッション制御サーバは、CSCF(Call State Control Function)と呼ばれる。なお、このCSCFは、設備維持コストの低減を目的として、従来の交換機のような専用ハードウェアではなく、汎用サーバによって実現されることが一般的となっている。
【0003】
前記したCSCFにおける呼処理フローは、受け付けた呼に対する一連の処理を処理目的別に分けたブロック(処理ブロック)を、逐次的に実行していくものである。
【先行技術文献】
【非特許文献】
【0004】
【非特許文献1】J.Rosenberg,et.al,“SIP: Session Initiation Protocol”,RFC3261,IETF,2002.6
【非特許文献2】原広明、“第17回 IMS(IP multimedia subsystem)(前編) ユビキタス・サービスを実現”、[online]、平成19年9月18日、[平成22年7月27日検索]、インターネット<URL :http://itpro.nikkeibp.co.jp/article/COLUMN/20070903/281033/?ST=network>
【非特許文献3】ITU-T Recommendation Y.2012,“Functional requirements and architecture of the NGN”,2006
【発明の概要】
【発明が解決しようとする課題】
【0005】
既存のCSCFにおける呼処理では、逐次処理を行っていたため、処理ブロック間に依存関係がない箇所であっても逐次的な処理が実行されていた。したがって、全体の呼処理に時間がかかるという問題があった。
そこで、本発明は、呼処理の時間を短縮する技術を提供することを課題とする。
【課題を解決するための手段】
【0006】
本発明は、発呼情報を受信して、前記発呼情報に基づいて発信元と接続先とを接続するための呼処理を実行し、前記接続先に当該発呼情報を伝達する呼処理並列化システムであって、前記発呼情報を受信し、その発呼情報に格納されている接続先の情報を抽出し、前記接続先と前記発呼情報の転送先となる発側呼処理制御部を識別する識別情報および着側呼処理制御部を識別する識別情報とを関連付けて記憶している転送先情報を参照して、前記発呼情報の転送先となる前記発側呼処理制御部および前記着側呼処理制御部を決定し、当該発呼情報を、その発呼情報の転送先として決定した前記発側呼処理制御部および前記着側呼処理制御部に転送する信号転送部と、前記信号転送部から受信した前記発呼情報から発信元を抽出し、前記発信元と前記呼処理に用いる情報とを関連付けて記憶している加入者情報を参照して、当該発信元に対応する前記呼処理に用いる情報を取得し、当該呼処理に用いる情報に基づいて前記発信元に対応する前記呼処理を実行し、前記呼処理完了後に当該発呼情報を発側着側処理完了確認部に送信する前記発側呼処理制御部と、前記信号転送部から受信した前記発呼情報から接続先を抽出し、前記接続先と前記呼処理に用いる情報とを関連付けて記憶している前記加入者情報を参照して、当該接続先に対応する前記呼処理に用いる情報を取得し、当該呼処理に用いる情報に基づいて前記接続先に対応する前記呼処理を実行し、前記呼処理完了後に当該発呼情報を発側着側処理完了確認部に送信する前記発側呼処理制御部と、前記発側呼処理制御部および前記着側呼処理制御部の双方から受信した前記発呼情報を比較して、受信した双方の前記発呼情報に格納されている情報が同じと判定した場合、当該発呼情報を前記接続先へ送信する前記発側着側処理完了確認部とを備えることを特徴とする。
【0007】
本発明は、発呼情報を受信して、前記発呼情報に基づいて発信元と接続先とを接続するための呼処理を実行し、前記接続先に当該発呼情報を伝達する呼処理並列化システムにおいて用いられる呼処理並列化方法であって、前記呼処理並列化システムが、信号転送部、発側呼処理制御部、着側呼処理制御部、および発側着側処理完了確認部を備え、前記信号転送部が、前記発呼情報を受信し、その発呼情報に格納されている接続先の情報を抽出し、前記接続先と前記発呼情報の転送先となる発側呼処理制御部を識別する識別情報および着側呼処理制御部を識別する識別情報とを関連付けて記憶している転送先情報を参照して、前記発呼情報の転送先となる前記発側呼処理制御部および前記着側呼処理制御部を決定し、当該発呼情報を、その発呼情報の転送先として決定した前記発側呼処理制御部および前記着側呼処理制御部に転送し、前記発側呼処理制御部が、前記信号転送部から受信した前記発呼情報から発信元を抽出し、前記発信元と前記呼処理に用いる情報とを関連付けて記憶している加入者情報を参照して、当該発信元に対応する前記呼処理に用いる情報を取得し、当該呼処理に用いる情報に基づいて前記発信元に対応する前記呼処理を実行し、前記呼処理完了後に当該発呼情報を発側着側処理完了確認部に送信し、前記着側呼処理制御部が、前記信号転送部から受信した前記発呼情報から接続先を抽出し、前記接続先と前記呼処理に用いる情報とを関連付けて記憶している前記加入者情報を参照して、当該接続先に対応する前記呼処理に用いる情報を取得し、当該呼処理に用いる情報に基づいて前記接続先に対応する前記呼処理を実行し、前記呼処理完了後に当該発呼情報を発側着側処理完了確認部に送信し、前記発側着側処理完了確認部が、前記発側呼処理制御部および前記着側呼処理制御部の双方から受信した前記発呼情報を比較して、受信した双方の前記発呼情報に格納されている情報が同じと判定した場合、当該発呼情報を前記接続先へ送信することを特徴とする。
【0008】
このような構成によれば、呼処理並列化システムの信号転送部は、受信した発呼情報を、発側呼処理制御部および着側呼処理制御部に送信する。発側呼処理制御部および着側呼処理制御部は、それぞれ、発信元および接続先について呼処理を並列に実行し、処理が完了した場合、発呼情報を発側着側処理完了確認部に送信する。そして、発側着側処理完了確認部が、発側呼処理制御部および着側呼処理制御部の双方から、同じ発呼情報を受信したと判定した場合、当該発呼情報を前記接続先へ送信する。したがって、従来の呼処理では、発側呼処理制御部の呼処理を終えてから着側呼処理制御部の呼処理を逐次的に行っていたのに対して、本発明では、発側呼処理制御部および着側呼処理制御部の呼処理を並列処理化することができ、そのため、呼処理の時間を短縮することができる。
【0009】
本発明は、前記発側呼処理制御部および前記着側呼処理制御部が、受信した前記発呼情報のメッセージを分割したメッセージ片に記述されている文字列を構文解析を用いて識別子として抽出し、前記識別子と前記呼処理の一連の処理を処理目的別に分けた処理ブロックとを関連付けて記憶している処理ブロック対応情報を参照して、前記抽出した識別子を含む前記メッセージ片を、当該識別子に関連付けられている並列処理部の前記処理ブロックに引き渡す処理振分部と、処理の順番に依存関係のある前記処理ブロックについては逐次処理を実行し、依存関係のない前記処理ブロック間では並列処理を実行し、その処理が正常に完了した場合に、前記逐次処理の最後の処理ブロックおよび前記並列処理される依存関係のない処理ブロックから前記引き渡されたメッセージ片を並列処理確認部へ出力する前記並列処理部と、前記逐次処理の最後の処理ブロックおよび前記並列処理される依存関係のない処理ブロックから前記メッセージ片を受信した場合、前記並列処理が正常に完了したと判断し、前記受信したメッセージ片を組み立て直して、前記処理振分部が受信したのと同じ発呼情報を生成し、前記発側着側処理完了確認部へ当該発呼情報を送信する並列処理確認部とを備えることを特徴とする。
【0010】
本発明は、前記発側呼処理制御部および前記着側呼処理制御部が、受信した前記発呼情報のメッセージを分割したメッセージ片に記述されている文字列を構文解析を用いて識別子として抽出し、前記識別子と前記呼処理の一連の処理を処理目的別に分けた処理ブロックとを関連付けて記憶している処理ブロック対応情報を参照して、前記抽出した識別子を含む前記メッセージ片を、当該識別子に関連付けられている並列処理ステップの前記処理ブロックに引き渡す処理振分ステップと、処理の順番に依存関係のある前記処理ブロックについては逐次処理を実行し、依存関係のない前記処理ブロック間では並列処理を実行し、その処理が正常に完了した場合に、前記逐次処理の最後の処理ブロックおよび前記並列処理される依存関係のない処理ブロックから前記引き渡されたメッセージ片を並列処理確認ステップへ出力する前記並列処理ステップと、前記逐次処理の最後の処理ブロックおよび前記並列処理される依存関係のない処理ブロックから前記メッセージ片を受信した場合、前記並列処理が正常に完了したと判断し、前記受信したメッセージ片を組み立て直して、前記処理振分ステップが受信したのと同じ発呼情報を生成し、前記発側着側処理完了確認ステップへ当該発呼情報を送信する前記並列処理確認ステップとを実行することを特徴とする。
【0011】
このような構成によれば、発側呼処理制御部および着側呼処理制御部の処理振分部は、受信した発呼情報のメッセージ片に記述されている文字列を構文解析を用いて識別子を抽出し、抽出した識別子を含むメッセージ片を、当該識別子に関連付けられている処理ブロックに引き渡す。そして、並列処理部の処理ブロックは、依存関係のある処理ブロックについては逐次処理を実行し、依存関係のない処理ブロック間では並列処理を実行し、処理が正常に完了した場合に、メッセージ片を並列処理確認部へ出力する。並列処理確認部は、並列処理部の処理ブロックからメッセージ片を受信して、並列処理が正常に完了したと判断し、受信したメッセージ片を組み立て直して、処理振分部が受信したのと同じ発呼情報を生成し、発側着側処理完了確認装置へ当該発呼情報を送信する。したがって、従来の呼処理では、発側呼処理制御部および着側呼処理制御部の各内部での呼処理を逐次的に行っていたのに対して、本発明では、発側呼処理制御部および着側呼処理制御部の呼処理を並列処理化することができ、呼処理の時間を短縮することができる。
【発明の効果】
【0012】
本発明によれば、呼処理の時間を短縮する技術を提供することができる。
【図面の簡単な説明】
【0013】
【図1】本実施形態における呼処理並列化システムの構成例を示す図である。
【図2】呼処理並列化システムにおける信号転送装置の構成例を示す図である。
【図3】呼処理並列化システムにおける発側着側処理完了確認装置の構成例を示す図である。
【図4】本実施形態における発側CSCFおよび着側CSCFの構成例を示す図である。
【図5】本実施形態における発側CSCFの呼処理の流れを示す図である。
【図6】本実施形態における着側CSCFの呼処理の流れを示す図である。
【図7】比較例における既存のIMSにおける呼の経路の構成例を示す図である。
【図8】比較例における発側CSCFの逐次呼処理の例を示す図である。
【図9】比較例における着側CSCFの逐次呼処理の例を示す図である。
【発明を実施するための形態】
【0014】
本発明を実施するための形態(以降、「本実施形態」と称す。)について、適宜図面を参照しながら詳細に説明する。はじめに、比較例として、IMSをベースとした、呼処理を実行するセッション制御サーバ(S−CSCF)における逐次呼処理の概要について説明する。
【0015】
(比較例)
まず、図7には、既存のIMSにおける、呼の経路の構成例を示す。ただし、呼処理(発信元と接続先とを通信可能に接続するための呼の処理)に必要な加入者情報等を管理するHSS(Home Subscriber Server)や各種サービスを提供するアプリケーションサーバは、図示を省略している。加入者情報は、例えば、加入者に設定された電話番号、IPアドレス、享受するサービス種別等の加入者プロファイルを格納している。
図7に示すように、IMSは、P−CSCF(Proxy Call Session Control Function)11(11A,11B)およびS−CSCF(Serving Call Session Control Function)40(40A,40B)によって構成される。便宜上、PC(Personal Computer)等の端末20Aから発呼を受け付けるネットワーク(例えば、IP(Internet Protocol)ネットワーク)を発側ネットワーク30と呼び、着信先の端末20Bに呼を伝達するネットワーク(例えば、IPネットワーク)を着側ネットワーク31と呼ぶ。発側ネットワーク30および着側ネットワーク31には、それぞれP−CSCF11およびS−CSCF40が配置される。
【0016】
P−CSCF11は、端末20との間で送受信するSIP信号の仲介を行う。S−CSCF40は、HSS(不図示)から取得した加入者情報に基づいて、呼処理を行う。以降の説明では、便宜的に、発側ネットワーク30に配置されているS−CSCFを発側CSCF40Aと呼び、着側ネットワーク31に配置されているS−CSCFを着側CSCF40Bと呼ぶ。
【0017】
図7では、端末20Aから発呼されたSIP信号(INVITEリクエスト)は、P−CSCF11Aを経由して発側CSCF40Aで呼処理が行われ、着側CSCF40Bに処理のリクエスト(INVITEリクエスト)を送信する。着側CSCF40Bは、発側CSCF40Aからリクエストを受信すると、着信先についての呼処理を実行し、P−CSCF11Bを経由して着信先の端末20Bに対してSIP信号(INVITEリクエスト)を送信する。
【0018】
次に、既存の発側CSCF40Aおよび着側CSCF40Bにおける、呼処理の大まかな流れ(ただし、順序関係を限定するものではない)について、それぞれ図8および図9を用いて説明する(適宜、図7参照)。なお、図8,9に示す、加入者情報DB(Data Base)、加入者端末単位カウント情報DB、および番号翻訳用データDBは、IMSモデルにおけるHSS(不図示)に記憶してもよい。ただし、記憶場所を限定するのもではない。
【0019】
図8には、発側CSCF40Aにおける逐次呼処理の流れを、処理ブロックの連続で表している。処理ブロックは、受け付けた呼に対する呼処理の一連の処理を処理目的別に分けたときにできるブロックであって、処理ブロックごとに実行可能なようにプログラム化されているものとする。
まず、図8に示すように、発側CSCF40Aは、端末20AからP−CSCF11Aを経由して、INVITEリクエスト(発呼情報)を受信する。
機種分析の処理ブロックでは、受信したINVITEリクエストから、発信元の加入者情報(発信元アドレス、発信元電話番号等)を取得する。そして、取得した加入者情報を、加入者情報DBに登録済みの情報と比較して、サービスに加入している正規ユーザであるか否かを認証する。
信号分析の処理ブロックでは、INVITEリクエストのヘッダ情報を分析し、ヘッダのエラーチェックを行う。
発加入者情報収集の処理ブロックでは、INVITEリクエストに格納されていた発信元の加入者情報を用いて、加入者情報DBを参照し、発加入者(発信元の加入者)が他に契約しているサービスがある場合には、そのサービス情報を取得する。なお、発加入者情報収集の処理ブロックは、信号分析の処理ブロックの実行後に実行されなければならないという関係にある。このような関係を依存関係があるという。
【0020】
次に、発加入者リソースチェックの処理ブロックでは、加入者端末単位カウント情報DBを参照して、空きセッション、チャネルリソースがあるかをチェックし、その加入者端末単位カウント情報DBを更新する。
番号分析の処理ブロックでは、番号翻訳用データDBを参照して、Request-URI(Uniform Resource Identifier)の番号を分析する。
帯域予約の処理ブロックでは、呼接続のための帯域を帯域予約サーバに予約し、着側CSCFにINVITEリクエストを送信する。この帯域予約の処理ブロックは、機種分析の処理ブロックの実行後に実行されなければならないという依存関係にある。
なお、機種分析の処理ブロックの実行前に、現在の処理状態を管理するコールデータに対して、処理状態の生成または取得を実行する。そして、帯域予約の処理ブロックの実行後に、コールデータに対して現在の処理状態について更新する。
【0021】
図9には、着側CSCF40Bにおける逐次呼処理の流れを、処理ブロックの連続で表している。
まず、着側CSCF40Bは、発側CSCF40Aから、INVITEリクエスト(発呼情報)を受信する。
そして、着側CSCF40Bは、発側CSCF40Aと同様に、コールデータに対して処理状態の生成および取得を行う。
着加入者情報収集の処理ブロックでは、加入者情報DBを参照して、着加入者(接続先の加入者)の加入者情報を取得する。
着サービス分析の処理ブロックでは、取得した加入者情報に基づいて、加入者端末単位カウント情報DBを参照して、端末データ情報を取得し、着加入者が他に契約している着サービスがないかを分析する。
【0022】
着リソースチェックの処理ブロックでは、加入者端末単位カウント情報DBを参照して、着側のリソース情報をチェックするとともに、その加入者端末単位カウント情報DBを更新する。
帯域予約の処理ブロックでは、着側の帯域を帯域予約サーバに予約する。なお、着加入者情報収集の処理ブロック、着サービス分析の処理ブロック、着リソースチェックの処理ブロック、および帯域予約の処理ブロックは、依存関係にある。
発番号インタワークの処理ブロックでは、IPアドレス等のインタワークを行う。
そして、着側CSCF40Bは、帯域予約の処理ブロックの実行後に、コールデータに対して現在の処理状態について更新し、着側端末20Bに対してINVITEリクエストを送信する。
【0023】
以上説明したように、比較例では、発側CSCF40Aおよび着側CSCF40Bともに、処理ブロック間に依存関係がない箇所も逐次的に処理している。そのため、比較例における呼処理に費やされる時間には、短縮可能な処理時間が含まれていると考えられる。
【0024】
(本実施形態における呼処理並列化システム)
次に、比較例で示した逐次的呼処理に対して、並列処理で実行する発側CSCF10Aおよび着側CSCF10Bを備える、呼処理並列化システムの構成例について、図1を用いて説明する。図1の構成が比較例(図7)の構成と異なる点は、信号転送装置12および発側着側処理確認装置13が新たに設けられ、発側CSCF10Aおよび着側CSCF10Bが処理ブロックの並列処理を実行することである。なお、図1において、図7と同じ構成については、同じ符号を付し、説明を省略する。また、図1には、発側CSCF10Aおよび着側CSCF10Bを1台ずつしか記載していないが、それぞれ2台以上であっても構わない。
【0025】
図1に示すように、呼処理並列化システム1は、発側CSCF10A、着側CSCF10B、信号転送装置12、および発側着側処理完了確認装置13によって構成される。
端末20Aから発呼されたINVITEリクエスト(発呼情報)は、P−CSCF11Aを経由して信号転送装置12で受信される。信号転送装置12は、受信したINVITEリクエストを複製して、発側CSCF10Aおよび着側CSCF10Bにそれぞれ送信する。発側CSCF10Aおよび着側CSCF10Bは、受信したINVITEリクエストに対して、それぞれ並列処理(後記)を実行し、並列処理の完了後に、INVITEリクエストを発側着側処理完了確認装置13に送信する。そして、発側着側処理完了確認装置13は、発側CSCF10Aおよび着側CSCF10BのそれぞれからINVITEリクエストを受信した場合、P−CSCF11Bを介して着側の端末20Bに向けてINVITEリクエストを送信する。
すなわち、呼処理並列化システム1は、発側CSCF10Aと着側CSCF10Bとの並列処理と、それぞれの発側CSCF10Aおよび着側CSCF10B内での並列処理とを実現することができる。
【0026】
(信号転送装置)
信号転送装置12の構成例について、図2を用いて説明する。図2に示すように、信号転送装置12は、処理部121、記憶部122、および通信部123を備える。処理部121は、図示しないCPUおよびメインメモリによって構成され、アプリケーションプログラム等を記憶する記憶部122に記憶されているアプリケーションプログラムをメインメモリに展開して、転送先決定部1211を具現化する。また、記憶部122は、転送先情報1221を記憶している。通信部123は、通信用インタフェースであり、SIP信号を送受信する。
【0027】
転送先情報1221は、INVITEリクエストに格納されている接続先情報(接続先の情報)と、そのINVITEリクエストの転送先の情報(発側CSCF10Aを識別する識別情報および着側CSCF10Bを識別する識別情報)とを関連付けて記憶している。
転送先決定部1211は、通信部123を介して受信したINVITEリクエスト(発呼情報)に格納されている接続先の情報を抽出し、転送先情報1221を参照し、当該接続先の情報に関連付けられた転送先の発側CSCF10Aおよび着側CSCF10Bを決定する。そして、転送先決定部1211は、受信したINVITEリクエストを複製して、決定した転送先に送信する。
【0028】
(発側着側処理完了確認装置)
発側着側処理完了確認装置13の構成例について、図3を用いて説明する。図3に示すように、発側着側処理完了確認装置13は、処理部131、記憶部132、および通信部133を備える。処理部131は、図示しないCPUおよびメインメモリによって構成され、アプリケーションプログラム等を記憶する記憶部132に記憶されているアプリケーションプログラムをメインメモリに展開して、発着処理確認部1311を具現化する。通信部133は、通信用インタフェースであり、SIP信号を送受信する。
【0029】
発着処理確認部1311は、通信部133を介して、発側CSCF10Aおよび着側CSCF10BからそれぞれINVITEリクエストを受信する。次に、発着処理確認部1311は、受信した双方のINVITEリクエストを比較し、それらのINVITEリクエストに格納されている情報が同じか否かを判定する。そして、発着処理確認部1311は、同じと判定した場合、発側CSCF10Aおよび着側CSCF10Bのそれぞれの処理完了と判断して、着側の端末20Bに対してINVITEリクエストを送信する。
【0030】
(発側CSCFおよび着側CSCF)
発側CSCF10Aおよび着側CSCF10Bの構成例について、図4を用いて説明する。なお、発側CSCF10Aと着側CSCF10Bとは、同じ構成を備えている。そこで、発側CSCF10Aの場合を代表させて説明する。
図4に示すように、発側CSCF10Aは、処理部101、記憶部102、および通信部103を備える。処理部101は、図示しないCPUおよびメインメモリによって構成され、アプリケーションプログラム等を記憶する記憶部102に記憶されているアプリケーションプログラムをメインメモリに展開して、処理振分部14、並列処理部15、および並列処理確認部16を具現化する。また、記憶部102は、処理ブロック対応情報1021を記憶している。通信部103は、通信用インタフェースであり、SIP信号を送受信する。
【0031】
処理ブロック対応情報1021は、INVITEリクエストのメッセージ内部に記述されている文字列等を識別子として、その識別子と、その識別子が示す処理を実行する処理ブロックを識別する処理ブロック識別情報とを関連付けて記憶している。例えば、識別子は、処理ブロックの処理に入力される情報となる文字列である。なお、処理ブロック識別情報は、処理ブロックのプログラムが格納されているメモリアドレスであっても構わない。
処理振分部14は、通信部103を介して受信したINVITEリクエストに格納されているメッセージを分割したメッセージ片に記述されている文字列を構文解析を用いて識別子として抽出する。次に、処理振分部14は、抽出した識別子を用いて、処理ブロック対応情報1021を参照して、その抽出した識別子を含むメッセージ片を、当該識別子に関連付けられている処理ブロックに引き渡す。
並列処理部15は、処理の順番に依存関係のある処理ブロックについては逐次処理を実行し、依存関係のない処理ブロック間では並列処理を実行する。そして、逐次処理の最後の処理ブロックおよび並列処理される依存関係のない処理ブロックは、自身の処理を完了した場合、入力されたメッセージ片を並列処理確認部16へ出力する。
並列処理確認部16は、並列処理部15からメッセージ片を受信した場合、並列処理が正常に完了したと判断し、受信したメッセージ片を組み立て直して、処理振分部14が受信したのと同様のINVITEリクエストを生成する。そして、並列処理確認部16は、通信部103を介して、発側着側処理完了確認装置13へ、INVITEリクエストを送信する。
【0032】
次に、本実施形態における発側CSCF10Aの呼処理の流れについて、図5を用いて説明する。
ステップS1では、処理振分部14が、受信したINVITEリクエストに格納されているメッセージを分割したメッセージ片に記述されている文字列を構文解析を用いて識別子として抽出し、その抽出した識別子を含むメッセージ片を、当該識別子に関連付けられている処理ブロックに引き渡す。
ステップS2では、並列処理部15が、処理振分部14からメッセージ片を取得して、そのメッセージ片を入力とする処理ブロックを起動し、処理を実行する。なお、並列処理部15は、依存関係のある機種分析および帯域予約と、依存関係のある信号分析および発加入者情報収集と、発加入者リソースチェックと、番号分析とを並列に実行する。また、帯域予約、発加入者情報収集、発加入者リソースチェック、および番号分析の各ブロックは、処理が正常に完了した場合に、入力されたメッセージ片を並列処理確認部16へ出力する。なお、当該メッセージ片に処理完了を示す処理完了情報を付加して出力してもよい。
【0033】
そして、ステップS3では、並列処理確認部16が、並列処理部15から、メッセージ片をすべて受信した場合に、並列処理が正常に完了したと判断する。なお、メッセージ片に処理完了情報が付加されている場合には、処理完了情報をすべて受信したときに、並列処理が正常に完了したと判断する。そして、並列処理確認部16は、受信したメッセージ片を組み立て直して、処理振分部14が受信したのと同様のINVITEリクエストを生成して、発側着側処理完了確認装置13へ当該INVITEリクエストを送信する。
【0034】
なお、図5に示す、加入者情報DB、加入者端末単位カウント情報DB、および番号翻訳用データDBは、図4の記憶部102に記憶してあっても、発側CSCF10Aに接続される外部のHDD(Hard Disc Drive)やデータベースサーバ等に記憶してあっても構わない。また、各処理ブロックは、いずれかのDBの情報に対して読み出し(参照)を行う場合、参照する情報にロックをかけずに参照し、更新が発生する書き込み時のみロックをかけて実行する楽観的ロックの手法を用いる。このことで、同じ情報へのアクセス競合のための参照待ち合わせを防止できることになるので、処理時間の短縮化が見込める。また、楽観的ロックの手法を用いることで、将来、新しい処理ブロックの追加が発生した場合であっても、処理ブロックの処理の順番の組み換えに対して、その組み換えに対応したロックの順番の見直しを行う必要が少なくなる。なお、更新発生時のロックについては、情報を更新するためにDBへアクセスする際に、キャッシュを用いて、キャッシュに記憶されている情報と更新情報との相違を判定し、相違があった場合にのみ更新処理を行う等の手法をとっても良い。
【0035】
なお、図5には記載していないが、コールデータに対して、処理部101は、ステップS2の並列処理の処理開始前に処理状態の生成および取得を行い、ステップS3の並列処理確認において、並列処理が正常に完了したことを確認した後に、現在の処理状態を更新する。
【0036】
次に、本実施形態における着側CSCF10Bの呼処理の流れについて、図6を用いて説明する。
ステップS4では、処理振分部14が、受信したINVITEリクエストに格納されているメッセージを分割したメッセージ片に記述されている文字列を構文解析を用いて識別子として抽出し、その抽出した識別子を含むメッセージ片を、当該識別子に関連付けられている処理ブロックに引き渡す。
ステップS5では、並列処理部15が、処理振分部14からメッセージ片を取得して、そのメッセージ片を入力とする処理ブロックを起動し、処理を実行する。なお、並列処理部15は、依存関係のある着加入者情報収集、着サービス分析、着リソースチェック、および帯域予約と、発番号インタワークとを並列に実行する。また、帯域予約および発番号インタワークの各ブロックは、処理が正常に完了した場合に、入力されたメッセージ片を並列処理確認部16へ出力する。なお、当該メッセージ片に処理完了を示す処理完了情報を付加して出力してもよい。
【0037】
そして、ステップS6では、並列処理確認部16が、並列処理部15から、メッセージ片をすべて受信した場合に、並列処理が正常に完了したと判断する。なお、メッセージ片に処理完了情報が付加されている場合には、処理完了情報をすべて受信した場合に、並列処理が正常に完了したと判断する。そして、並列処理確認部16は、受信したメッセージ片を組み立て直して、処理振分部14が受信したのと同様のINVITEリクエストを生成して、発側着側処理完了確認装置13へ当該INVITEリクエストを送信する。
【0038】
なお、図6に示す、加入者情報DBおよび加入者端末単位カウント情報DBは、図4の記憶部102に記憶してあっても、発側CSCF10Aおよび着側CSCF10Bに接続される外部のHDDやデータベースサーバ等に記憶してあっても構わない。また、各処理ブロックは、いずれかのDBの情報に対して読み出し(参照)を行う場合、楽観的ロックの手法を用いる。また、更新発生時のロックについては、情報を更新するためにDBへアクセスする際に、キャッシュを用いて、キャッシュに記憶されている情報と更新情報との相違を判定し、相違があった場合にのみ更新処理を行う等の手法をとっても良い。
【0039】
なお、図6には記載していないが、コールデータに対して、処理部101は、ステップS5の並列処理の処理開始前に処理状態の生成および取得を行い、ステップS6の並列処理確認において、並列処理が正常に完了したことを確認した後に、現在の処理状態を更新する。
【0040】
以上、本実施形態で説明した呼処理並列化システム1は、発側CSCF10A、着側CSCF10B、信号転送装置12、および発側着側処理完了確認装置13によって構成される。信号転送装置12は、端末20Aから受信したINVITEリクエストを複製して、発側CSCF10Aおよび着側CSCF10Bにそれぞれ送信する。発側CSCF10Aおよび着側CSCF10Bは、受信したINVITEリクエストに対して、それぞれ並列処理を実行し、並列処理の完了後に、INVITEリクエストを発側着側処理完了確認装置13に送信する。そして、発側着側処理完了確認装置13は、発側CSCF10Aおよび着側CSCF10BのそれぞれからINVITEリクエストを受信した場合、P−CSCF11Bを介して着側の端末20Bに向けてINVITEリクエストを送信する。
すなわち、呼処理並列化システム1は、発側CSCF10Aと着側CSCF10Bとの並列処理と、それぞれの発側CSCF10Aおよび着側CSCF10B内での並列処理とを実現することができる。
このような構成を備えているため、呼処理並列化システム1は、呼処理シーケンスの並列化処理によって、呼処理の時間を短縮することが可能となる。
【0041】
また、本実施形態では、SIPのINVITEリクエストを用いた場合を例として説明したが、これに限られることはなく、他のプロトコルを用いた呼処理の場合にも適用可能である。
【符号の説明】
【0042】
1 呼処理並列化システム
10A 発側CSCF(発側呼処理制御部)
10B 着側CSCF(着側呼処理制御部)
12 信号転送装置(信号転送部)
13 発側着側処理完了確認装置(発側着側処理完了確認部)
14 処理振分部
15 並列処理部
16 並列処理確認部
20 端末
101,121,131 処理部
102,122,132 記憶部
1021 処理ブロック識別情報
1211 転送先決定部
1221 転送先情報
1311 発着処理確認部

【特許請求の範囲】
【請求項1】
発呼情報を受信して、前記発呼情報に基づいて発信元と接続先とを接続するための呼処理を実行し、前記接続先に当該発呼情報を伝達する呼処理並列化システムであって、
前記発呼情報を受信し、その発呼情報に格納されている接続先の情報を抽出し、前記接続先と前記発呼情報の転送先となる発側呼処理制御部を識別する識別情報および着側呼処理制御部を識別する識別情報とを関連付けて記憶している転送先情報を参照して、前記発呼情報の転送先となる前記発側呼処理制御部および前記着側呼処理制御部を決定し、当該発呼情報を、その発呼情報の転送先として決定した前記発側呼処理制御部および前記着側呼処理制御部に転送する信号転送部と、
前記信号転送部から受信した前記発呼情報から発信元を抽出し、前記発信元と前記呼処理に用いる情報とを関連付けて記憶している加入者情報を参照して、当該発信元に対応する前記呼処理に用いる情報を取得し、当該呼処理に用いる情報に基づいて前記発信元に対応する前記呼処理を実行し、前記呼処理完了後に当該発呼情報を発側着側処理完了確認部に送信する前記発側呼処理制御部と、
前記信号転送部から受信した前記発呼情報から接続先を抽出し、前記接続先と前記呼処理に用いる情報とを関連付けて記憶している前記加入者情報を参照して、当該接続先に対応する前記呼処理に用いる情報を取得し、当該呼処理に用いる情報に基づいて前記接続先に対応する前記呼処理を実行し、前記呼処理完了後に当該発呼情報を発側着側処理完了確認部に送信する前記発側呼処理制御部と、
前記発側呼処理制御部および前記着側呼処理制御部の双方から受信した前記発呼情報を比較して、受信した双方の前記発呼情報に格納されている情報が同じと判定した場合、当該発呼情報を前記接続先へ送信する前記発側着側処理完了確認部と
を備えることを特徴とする呼処理並列化システム。
【請求項2】
前記発側呼処理制御部および前記着側呼処理制御部は、
受信した前記発呼情報のメッセージを分割したメッセージ片に記述されている文字列を構文解析を用いて識別子として抽出し、前記識別子と前記呼処理の一連の処理を処理目的別に分けた処理ブロックとを関連付けて記憶している処理ブロック対応情報を参照して、前記抽出した識別子を含む前記メッセージ片を、当該識別子に関連付けられている並列処理部の前記処理ブロックに引き渡す処理振分部と、
処理の順番に依存関係のある前記処理ブロックについては逐次処理を実行し、依存関係のない前記処理ブロック間では並列処理を実行し、その処理が正常に完了した場合に、前記逐次処理の最後の処理ブロックおよび前記並列処理される依存関係のない処理ブロックから前記引き渡されたメッセージ片を並列処理確認部へ出力する前記並列処理部と、
前記逐次処理の最後の処理ブロックおよび前記並列処理される依存関係のない処理ブロックから前記メッセージ片を受信した場合、前記並列処理が正常に完了したと判断し、前記受信したメッセージ片を組み立て直して、前記処理振分部が受信したのと同じ発呼情報を生成し、前記発側着側処理完了確認部へ当該発呼情報を送信する並列処理確認部と
を備えることを特徴とする請求項1に記載の呼処理並列化システム。
【請求項3】
発呼情報を受信して、前記発呼情報に基づいて発信元と接続先とを接続するための呼処理を実行し、前記接続先に当該発呼情報を伝達する呼処理並列化システムにおいて用いられる呼処理並列化方法であって、
前記呼処理並列化システムは、
信号転送部、発側呼処理制御部、着側呼処理制御部、および発側着側処理完了確認部を備え、
前記信号転送部は、前記発呼情報を受信し、その発呼情報に格納されている接続先の情報を抽出し、前記接続先と前記発呼情報の転送先となる発側呼処理制御部を識別する識別情報および着側呼処理制御部を識別する識別情報とを関連付けて記憶している転送先情報を参照して、前記発呼情報の転送先となる前記発側呼処理制御部および前記着側呼処理制御部を決定し、当該発呼情報を、その発呼情報の転送先として決定した前記発側呼処理制御部および前記着側呼処理制御部に転送し、
前記発側呼処理制御部は、前記信号転送部から受信した前記発呼情報から発信元を抽出し、前記発信元と前記呼処理に用いる情報とを関連付けて記憶している加入者情報を参照して、当該発信元に対応する前記呼処理に用いる情報を取得し、当該呼処理に用いる情報に基づいて前記発信元に対応する前記呼処理を実行し、前記呼処理完了後に当該発呼情報を発側着側処理完了確認部に送信し、
前記着側呼処理制御部は、前記信号転送部から受信した前記発呼情報から接続先を抽出し、前記接続先と前記呼処理に用いる情報とを関連付けて記憶している前記加入者情報を参照して、当該接続先に対応する前記呼処理に用いる情報を取得し、当該呼処理に用いる情報に基づいて前記接続先に対応する前記呼処理を実行し、前記呼処理完了後に当該発呼情報を発側着側処理完了確認部に送信し、
前記発側着側処理完了確認部は、前記発側呼処理制御部および前記着側呼処理制御部の双方から受信した前記発呼情報を比較して、受信した双方の前記発呼情報に格納されている情報が同じと判定した場合、当該発呼情報を前記接続先へ送信する
ことを特徴とする呼処理並列化方法。
【請求項4】
前記発側呼処理制御部および前記着側呼処理制御部は、
受信した前記発呼情報のメッセージを分割したメッセージ片に記述されている文字列を構文解析を用いて識別子として抽出し、前記識別子と前記呼処理の一連の処理を処理目的別に分けた処理ブロックとを関連付けて記憶している処理ブロック対応情報を参照して、前記抽出した識別子を含む前記メッセージ片を、当該識別子に関連付けられている並列処理ステップの前記処理ブロックに引き渡す処理振分ステップと、
処理の順番に依存関係のある前記処理ブロックについては逐次処理を実行し、依存関係のない前記処理ブロック間では並列処理を実行し、その処理が正常に完了した場合に、前記逐次処理の最後の処理ブロックおよび前記並列処理される依存関係のない処理ブロックから前記引き渡されたメッセージ片を並列処理確認ステップへ出力する前記並列処理ステップと、
前記逐次処理の最後の処理ブロックおよび前記並列処理される依存関係のない処理ブロックから前記メッセージ片を受信した場合、前記並列処理が正常に完了したと判断し、前記受信したメッセージ片を組み立て直して、前記処理振分ステップが受信したのと同じ発呼情報を生成し、前記発側着側処理完了確認ステップへ当該発呼情報を送信する前記並列処理確認ステップと
を実行することを特徴とする請求項3に記載の呼処理並列化方法。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate

【図8】
image rotate

【図9】
image rotate


【公開番号】特開2012−39533(P2012−39533A)
【公開日】平成24年2月23日(2012.2.23)
【国際特許分類】
【出願番号】特願2010−179960(P2010−179960)
【出願日】平成22年8月11日(2010.8.11)
【出願人】(000004226)日本電信電話株式会社 (13,992)
【Fターム(参考)】