以下、図面と共に本発明に係る移動体通信システム、呼処理ノード及び通信制御方法の実施形態について詳細に説明する。なお、図面の説明においては同一要素には同一符号を付し、重複する説明を省略する。
図1に本実施形態に係る移動体通信システム1の構成を示す。移動体通信システム1は、移動通信端末(移動機)50に移動体通信の機能を提供するシステムである。移動通信端末50は、ユーザにより用いられて移動体通信システム(移動体通信網)に無線通信によって接続して移動体通信を行う装置である。具体的には、移動通信端末50は、携帯電話機等に相当する。移動通信端末50は、例えば、移動体通信システム1を介して対向ノード60との間で呼接続を確立して通信を行う。対向ノード60は、例えば、別の移動通信端末や移動通信端末50に様々なサービスを提供するサーバ装置、あるいは他の通信網に接続するための装置(例えば、GGSN(Gateway GPRS Support Node))等に相当する。移動通信端末50は、移動通信端末50のユーザが移動体通信システム1の通信事業者と契約することによって移動体通信を行うことが可能になる。なお、移動通信端末50は、従来の移動通信端末と同様のものでよい。
図1に示すように、移動体通信システム1は、呼処理管理用データベース10と、複数の呼処理サーバ20と、オープンフローネットワーク30と、ネットワークマネージャ40とを含んで構成されている。なお、これらの構成10,20,30,40は、移動体通信システム1(移動体通信網)のコアネットワークを構成するものである。
呼処理管理用データベース10は、呼処理に必要なデータを保持するデータベースである。呼処理管理用データベース10は、このデータを、例えば、移動通信端末50を特定する情報に対応付けて、移動通信端末50毎に保持する。呼処理に必要なデータとしては、具体的には呼処理の状態を示すステート情報や移動通信端末50に係る加入者プロファイルを保持する。ステート情報としては、移動通信端末50の在圏エリアや、移動通信端末50が通信中であるか待受中であるかの情報(静的ステート情報)である。この情報は、後述するように呼処理サーバ20によって読み出されると共に更新(書き込み)される。呼処理管理用データベース10は、更に本実施形態に係る動的ステート情報を保持する。動的ステート情報は、静的ステート情報と合わせてより詳細に後述する。
また、加入者プロファイルのデータとしては、移動通信端末50の電話番号、認証情報、契約速度等の情報がある。これらの情報は、移動通信端末50のユーザが移動体通信システム1の通信事業者と契約した時に呼処理管理用データベース10に加入者プロファイルとして新たに記憶(生成)される。これらの情報は、呼処理サーバ20によって読み出されるが呼処理サーバ20による更新(書き込み)はなされない。なお、移動通信端末50毎に記憶されるデータには、このように読み出し(Read)と書き込み(Write)の両方が発生する項目と読み出し(Read)のみ発生する項目とがある。呼処理管理用データベース10において、これらの項目のレコードを分けて管理することで、Writeの同期待ちでReadが遅延することを防止するように工夫することができる。
呼処理管理用データベース10は、複数の呼処理サーバ20それぞれと接続されており、呼処理サーバ20によって、呼処理管理用データベース10が保持するデータの参照や登録、更新が行われる。呼処理管理用データベース10は、データベースとして任意の構成をとることができるが、呼処理に必要なデータを保持することを考慮して、図1に示すように、複数のサーバ装置で実現される分散データベースとし、SPOF(Single Point of Failure)が無いように構成することが望ましい。
ここで呼処理とは、移動体通信システム1を介して移動通信端末50と対向ノード60との呼接続に係る処理である。例えば、移動通信端末50と対向ノード60との間の呼接続(通信セッション接続とも呼ばれる)を確立する処理、あるいは切断する処理等である。また、移動体通信システム1に在圏するための処理、即ち、位置登録の処理も本実施形態における呼処理に含むこととしてもよい。
呼処理サーバ20は、移動体通信システム1において呼処理を行う呼処理ノードである。呼処理サーバ20は、図1に示すようにオープンフローネットワーク30を介して、移動通信端末50及び対向ノード60と接続されており、移動通信端末50からの要求等に応じて呼処理を行う。呼処理サーバ20は、図2に示すようにHW(ハードウェア)層、OS(オペレーティングシステム)層及びAPL(アプリケーション)層の機能によって実現される。また、後述の障害時やスケールアウト時の処理を容易にするため、仮想サーバとして実装してもよい。
図2に示すように、APL層では、呼情報、一時的な情報、プログラムがメモリ上に記憶される。呼情報は、呼処理に必要なデータであり、呼の状態遷移を保持するステート情報や加入者プロファイルである。ステート情報には、静的なステート情報(静的ステート情報)と動的なステート情報(動的ステート情報)とが含まれる。静的ステート情報は、例えば、待受中、発信中、通信中等の移動通信端末50の通信状態(呼状態)を示す情報である。動的ステート情報は、実行中の呼処理に係る情報であり、例えば、最終更新日時や呼処理を行っている呼処理サーバ20を特定する情報である更新ノードID(例えば、呼処理サーバ20の一つであるP−CSCFのIPアドレス)である。
呼情報は、呼処理管理用データベース10から情報を取得する等して、呼処理の際のみに保持される。なお、呼情報は、呼処理後にも、キャッシュとして処理の効率化のために呼処理サーバ20において保持されていてもよいが、呼処理サーバ20は呼情報についての責任は持たない。一時的な情報は、呼処理(信号シーケンス)の途中で用いられる一時的な情報(位置登録、発信等のシーケンス途中の情報)である。例えば、待受中から通信中へ変わる過渡的な状態で用いられるテンポラリ情報である。この一時的な情報は、後述するように呼処理サーバ20間で送受信される。プログラムは、呼処理サーバ20の機能を実現するための実行コードそのもの(実行バイナリの情報)である。
移動体通信システム1には、複数の呼処理サーバ20が含まれる。図1に示すように、災害により何れかの呼処理サーバ20が故障する場合等を考慮して、複数の拠点(データセンタ等の場所)2を設け、それぞれの拠点2に1つ以上の呼処理サーバ20を設けるようにすることが望ましい。呼処理サーバ20は、望ましくはサーバ装置に仮想マシン技術を利用して、仮想化された仮想サーバとして実現される。なお、本実施形態では、呼処理ノードは仮想マシンとして説明するが、個々のサーバ装置による仮想マシンでない呼処理サーバとして実現されてもよい。呼処理サーバ20は、従来の移動体通信システムでは例えば、SGSN(Serving GPRS Support Node)やCSCF(Call SessionControl Function)、AS(Application Server)等のノードに相当する。
あるいは、IMS(IP Multimedia Subsystem)では、図3に示すように、呼処理サーバ20は、P−CSCF(Proxy- Call Session Control Function)、CSN(CallSession control Node)及びASN(Application Serving Node)である。移動体通信システム1に含まれるP−GW(Packet Data Network Gateway)から呼処理に係る信号がP−CSCFに入力され、図3に示すように呼処理がP−CSCF、CSN及びASNにおいて順次、行われる。本実施形態では、呼処理サーバ20として、P−CSCF、CSN及びASNを例に説明する。なお、本実施形態に係るP−CSCF、CSN及びASNは、既存のP−CSCF、CSN及びASNの機能に加えて、後述する本実施形態に係る機能を有する。
オープンフローネットワーク30は、呼処理サーバ20、移動通信端末50及び対向ノード60とそれぞれ接続されており、それらの装置の間の通信路を構成するフロー制御ネットワークである。なお、通常、オープンフローネットワーク30と移動通信端末50とは、基地局(BTS)や無線制御装置(RNC)を介して接続されている。オープンフローネットワーク30は、互いに接続されているオープンフロースイッチである複数のノード31によって構成されている。ノード31は、通常オープンフローネットワークのオープンフロースイッチとして用いられる装置に相当する。後述するように、オープンフローネットワーク30は、ネットワークマネージャ40のオープンフローコントローラからの制御を受けて情報の送受信を行う。具体的には、オープンフローネットワーク30の各ノード31が、自身が受信した情報をどのノードに送信するかを示すフローエントリを、ネットワークマネージャ40から受信して当該フローエントリに従った情報の送受信を行う。本説明では、オープンフローネットワークとして説明を行うが、SDN(Softwarer difined network)と呼ばれる、同様のフロー制御とその制御に従ってフロー転送処理を行うネットワークでもよい。
ネットワークマネージャ40は、オープンフローネットワーク30における情報の送受信を制御する制御ノードである。制御は、例えば、ネットワークマネージャ40が備える、負荷分散制御を行うオープンフローコントローラによって行われる。具体的にどのような制御を行うかについては後述する。ネットワークマネージャ40は、呼処理サーバ20のそれぞれと接続されており、情報の送受信を行うことができる。
引き続いて、ネットワークマネージャ40及び呼処理サーバ20の本実施形態に係る機能についてより詳細に説明する。図1に示すようにネットワークマネージャ40は、ノード状態把握部41と、制御部42とを備えて構成される。また、呼処理サーバを仮想化して仮想マシンによって構成されることとした場合、ネットワークマネージャ40は、仮想化された呼処理サーバ(仮想呼処理サーバ)の制御を行う仮想マシン制御部(図示せず)を、更に備えることとしてもよい。この制御によって、具体的には、仮想呼処理サーバのプロビジョニングが行われる。
ノード状態把握部41は、複数の呼処理サーバ20の状態を把握するノード状態把握手段である。まず、ノード状態把握部41は、どの呼処理サーバ20があるかを把握する。これは例えば、呼処理サーバ20が、スケールアウト等のために新たに設置された場合に呼処理サーバ20から新たに設置された旨の情報を受信することによって行われる。また、ノード状態把握部41は、呼処理サーバ20の状態として、それぞれのサーバの負荷や、故障が発生していないか否かの情報を把握する。これらの情報は、例えば、定期的なノード状態把握部41からの問い合わせによって、あるいは、ノード状態把握部41からの自発的な送信によって、呼処理サーバ20からの情報を受信することによってノード状態把握部41で把握される。ノード状態把握部41は、把握した各呼処理サーバ20の状態を示す情報を制御部42に出力する。
制御部42は、ノード状態把握部41によって把握された複数の各呼処理サーバ20の状態に基づいて、移動通信端末50から呼処理の要求を処理する呼処理サーバ20を決定して(割り当てして)決定した呼処理サーバ20によって当該呼処理の要求が処理されるように制御する制御手段である。具体的には、制御部42は、決定した呼処理サーバ20によって当該呼処理の要求が処理されるようにオープンフローネットワーク30を設定する。
制御部42は、各呼処理サーバ20の状態に基づいて、呼処理を制御する呼処理サーバ20を決定する。例えば、故障している呼処理サーバ20や一定の閾値以上の処理負荷がかかっている呼処理サーバ20が、呼処理を処理する呼処理サーバ20とならないように呼処理を処理する呼処理サーバ20を決定する。また、呼処理サーバ20間で、処理負荷がなるべく均一になるように呼処理を処理する呼処理サーバ20を決定することとしてもよい。なお、呼処理を行う呼処理サーバ20は、移動通信端末50に応じて決定されてもよい。どのように呼処理を処理する呼処理サーバ20を決定するかの基準(実施シナリオ)については、例えば、移動体通信システム1の通信事業者が予め制御部42に記憶させておく。
制御部42は、移動通信端末50からの呼処理の要求が決定した呼処理サーバ20に送信されるようにフローエントリを生成して、生成したフローエントリをオープンフローネットワーク30の各ノード31に送信する。
呼処理を処理する呼処理サーバ20の決定、及びフローエントリの生成は、例えば、一定期間毎(例えば、特定の時刻毎)や、呼処理サーバ20の状態が変更した場合(例えば、呼処理サーバ20が故障や処理輻輳、保守作業等で停止する場合)等に行われることとすればよい。
なお、オープンフローネットワーク30は、呼処理サーバ20間にも設けられており、呼処理サーバ間(例えば、P−CSCFとCSNとの間やCSNとASNとの間)における信号の送信先の制御も上述したように行う。
仮想マシン制御部は、呼処理サーバを仮想化した場合に、ノード状態把握部41によって把握された複数の各呼処理サーバ20の状態に基づいて、当該仮想化を制御する仮想化制御手段である。これは例えば、呼処理サーバ20を、各呼処理サーバ20の状態に応じてスケールアウト等のために増設したい場合に、仮想マシン制御部がHypervisorに指示を送ることによって、仮想呼処理サーバ20を新たにプロビジョニングさせる等の制御である。これによって、呼処理サーバ20の状態に応じて、適切な仮想化を行うことができる。より具体的には、仮想マシン制御部による仮想マシンのプロビジョニングを統合制御することで(処理を同調させることで)、以下に説明するように更に適切なスケールアウト処理や、障害時処理が可能となる。
呼処理サーバ20は、呼処理要求受付部21と、登録部22と、取得部23と、呼処理部24と、呼処理結果格納部25とを備えて構成される。
呼処理要求受付部21は、ネットワークマネージャ40の制御を受けてオープンフローネットワーク30から自ノード20に送信された、呼処理の要求を受け付ける(受信する)呼処理要求受付手段である。呼処理の要求は、発信要求(呼接続確立の要求)や位置登録要求である。呼処理要求受付部21は、受信した呼処理の要求を登録部22、取得部23及び呼処理部24に出力する。
登録部22は、呼処理要求受付部21から呼処理の要求が入力されると、呼処理の要求に係る移動通信端末50に対する呼処理を実行中の呼処理サーバ20として自ノードを呼処理管理用データベース10に登録する登録手段である。
図3に示すように、呼処理管理用データベース10は、移動通信端末50を特定する情報であるユーザ識別子に対応付けて、呼処理サーバ20の種類毎の呼処理の状態を示す情報(Key−Valueストア(KVS))を保持する。呼処理サーバ20の種類とは、P−CSCF、CSN及びASN等の種類である。呼処理の状態を示す情報とは、静的ステート情報と動的ステート情報である。これらの情報を参照することによって、当該移動通信端末50に関してその種類の呼処理サーバ20の何れかにおいて呼処理が実行中であるか否かを判断することができる。呼処理が実行中でない状態は、例えば、図3に示す“状態1”、“状態2”等の状態である。呼処理が実行中である(呼状態が遷移中である)状態は、例えば、図3に示す「状態遷移中」等の状態)である。なお、図3に示す凡例は、以降の図でも同様である。
動的ステート情報には、当該移動通信端末50に関して呼処理を実行している呼処理サーバ20を特定する情報である更新ノードID(例えば、呼処理サーバ20のIPアドレス)が含まれる。図3に示すユーザ識別子が“C”である移動通信端末50の情報の例では、ASNに係る呼処理の状態(ASN状態)は“状態1(例えば、待受状態)”、CSNに係る呼処理の状態(ASN状態)は“状態1”、P−CSCFに係る呼処理の状態(P−CSCF状態)は“状態遷移中”である。また、P−CSCF状態を示す情報には、呼処理を実行している呼処理サーバ20の更新ノードIDとして、P−CSCF1bのノードIDが含まれている。
登録部22は、呼処理要求受付部21から呼処理の要求が入力されると、当該要求から要求元の移動通信端末50を特定する。例えば、呼処理の要求が、ユーザ識別子が“C”である移動通信端末50から対抗ノードへの発信要求(ユーザCからユーザXへの発信要求)であった場合には、登録部22は、ユーザ識別子が“C”である移動通信端末50を、呼処理の要求元の移動通信端末50として特定する。登録部22は、特定したユーザ識別子と自ノードのノードIDとを含めた動的ステート情報更新要求を呼処理管理用データベース10に送信する。呼処理管理用データベース10は、動的ステート情報更新要求を受信して、受信した動的ステート情報更新要求に基づいて、ユーザ識別子に対応付けられた呼処理の状態を示す情報を、ユーザ識別子をキーとして更新(登録)する。この登録によって、当該移動通信端末50の状態が、呼処理が実行中であるという状態(状態遷移中)となる。
取得部23は、呼処理要求受付部21によって受け付けられた呼処理の要求に係る移動通信端末50の情報を呼処理管理用データベース10から取得する取得手段である。取得部23は、呼処理の要求に含まれる、当該呼処理の要求元である移動通信端末50を特定する情報を抽出して、当該移動通信端末50に係る情報を送信するように呼処理管理用データベース10に対して要求する。ここで要求する情報は、図2に示す呼情報であり、具体的には上述したように電話番号、認証情報、契約速度、在圏エリア、通信中/待受中の情報である。なお、自ノード20において移動通信端末50に係る呼処理を行っており、自ノード20に有効な呼情報のキャッシュが残っている場合には、キャッシュの最終更新時刻が、呼処理管理用データベース10の最終更新時刻より古くなければ、取得部23による取得が行われなくてもよい。取得部23は、呼処理管理用データベース10から取得した情報を呼処理部24に出力する。
また、取得部23は、自ノードと同じ種類で自ノード以外の別の呼処理サーバ20が、呼処理の要求元である移動通信端末50に対する呼処理を実行中である場合には、当該別の呼処理サーバ20から呼処理のための情報を取得して、呼処理を引き継いで実行する。呼処理管理用データベース10に呼処理の要求元である移動通信端末50のユーザ識別子に対応付けられて保持された、自ノードと同じ種類の呼処理の状態を示す情報が、自ノード以外の別の呼処理サーバ20において呼処理が実行中であることを示すものであった場合、取得部23は、当該別の呼処理サーバ20を特定する情報である更新ノードIDを取得する。
この取得は、例えば、取得部23によって、呼処理管理用データベース10に格納された、呼処理の要求元である移動通信端末50が状態遷移中であるという情報(フラグ)が参照されておこなわれる。あるいは、登録部22による呼処理管理用データベース10への自ノードの登録の際に、自ノード以外の別の呼処理サーバ20が呼処理の要求に係る移動通信端末50に対する呼処理を実行中の呼処理サーバ20として登録されていた場合、呼処理管理用データベース10がその別の呼処理サーバ20のサーバの更新ノードIDを送信することによって行われてもよい。
取得部23は、当該別の呼処理サーバ20から呼処理の要求に係る移動通信端末50の情報を取得する。この情報の取得は、当該別の呼処理サーバ20に移動通信端末50の情報の同期を要求することによって行われる。ここで取得される情報は、呼処理(信号シーケンス)の途中で用いられる一時的な情報(位置登録、発信等のシーケンス途中の情報)であり、呼処理管理用データベース10には登録されない情報である。
なお、別の呼処理サーバ20から情報を取得して呼処理を引き継ぐ場合、別の呼処理サーバ20から取得した情報だけで呼処理を継続できる場合には、呼処理管理用データベース10から必ずしも情報を取得する必要はない。取得部23は、別の呼処理サーバ20から取得した情報を呼処理部24に出力する。
なお、呼処理の途中で呼処理を実行する呼処理サーバ20が変更するのは、呼処理サーバ20の増設、減設、あるいはその他の原因によって、呼処理が実行されている間にオープンフローネットワーク30によって信号の経路の変更が行われてしまうためである。本実施形態の構成は、このように呼処理が実行されている間にオープンフローネットワーク30によって信号の経路の変更が行われた場合であっても、変更前の呼処理サーバ20で取得された情報を再送制御による処理救済等で改めて取得せずに呼処理を継続できるようにするためのものである。
呼処理部24は、取得部23によって取得された情報を用いて当該要求に係る呼処理を行う呼処理手段である。具体的には、呼接続の確立や切断、あるいは位置登録の処理(在圏エリアの登録又は更新の処理)を行う。別の呼処理サーバ20から呼処理のための情報を取得した場合には、呼処理部24は、当該別の呼処理サーバ20が行っていた呼処理を引き継いだ処理を行う。呼処理部24は、呼処理の結果の情報を呼処理結果格納部25に出力する。
呼処理結果格納部25は、呼処理部24によって行われた呼処理の結果の情報を呼処理管理用データベース10に格納する呼処理結果格納手段である。具体的には、呼処理結果格納部25は、呼処理によって更新された、移動通信端末50の在圏エリアや、移動通信端末50が通信中であるか待受中であるかの情報である。これらの情報は、当該移動通信端末50に係る次の呼処理に必要な情報である。呼処理結果格納部25による呼処理管理用データベース10への情報の格納は、呼情報(ステート情報)に変更が生じた場合のみに行われることとしてもよい。呼処理結果格納部25による呼処理管理用データベース10への情報の格納が行われた場合、最終更新時刻を現在時刻にアップデートする。
呼処理結果格納部25は、呼処理部24によって行われた呼処理が終了したら当該呼処理の要求に係る移動通信端末50に対する呼処理を実行中の呼処理サーバ20としての呼処理管理用データベース10に対する登録を終了させる。呼処理結果格納部25は、呼処理管理用データベース10に自ノードにおける呼処理が終了して、当該移動通信端末50における自ノードの種類の呼処理の状態を状態遷移中から何れの呼処理サーバ20においても呼処理が実行中でない状態に移行した旨を通知する。なお、この通知は、呼処理の結果の格納と合わせて行われてもよい。呼処理管理用データベース10は、この通知を受け取り、通知に基づき当該移動通信端末50における情報を更新する。以上が、ネットワークマネージャ40及び呼処理サーバ20の本実施形態に係る機能である。
図4に本実施形態に係る呼処理管理用データベース10、呼処理サーバ20、オープンフローネットワーク30のノード31及びネットワークマネージャ40を構成するサーバ装置のハードウェア構成を示す。図4に示すように当該サーバ装置は、CPU101、主記憶装置であるRAM(Random Access Memory)102及びROM(Read OnlyMemory)103、通信を行うための通信モジュール104、並びにハードディスク等の補助記憶装置105等のハードウェアを備えるコンピュータを含むものとして構成される。これらの構成要素がプログラム等により動作することにより、上述した各ノード10,20,31,40の機能が発揮される。以上が、移動体通信システム1の構成である。
引き続いて、図5及び図9のシーケンス図、図6〜図8及び図10〜図12の図を用いて、本実施形態に係る移動体通信システム1で実行される処理である通信制御方法を説明する。まず、図5のシーケンス図及び図6〜図8を用いて、ユーザ識別子が“C”である移動通信端末50から別の端末への発信等の呼処理の要求があり、その呼処理の途中で呼処理サーバ20が増設されてスケールアウトされた場合の処理について説明する。本処理では、CSNが増設される例について説明する。また、図3に示すように呼処理サーバとして、P−CSCF、CSN及びASNが設けられている例について説明する。
呼処理サーバ(P−CSCF1、CSN1、ASN1)20は、それぞれユーザ識別子が“A”、“B”、“C”及び“D”である移動通信端末50(以降、それぞれユーザA,B,C,Dと呼ぶ)を収容している。本実施形態においては、ユーザを収容しているとは、当該ユーザに係る呼処理の信号がオープンフローネットワーク30によって、それぞれの呼処理サーバ20に振り分けられて処理することを言う。但し、呼処理の信号は、ユーザに応じて特定の呼処理サーバ20に振り分けられる必要はなく、信号の中継時点でオープンフローネットワーク30によってフローエントリに基づいて振り分け先が判断されてもよい。
P−CSCF1aはユーザA,Bを、P−CSCF1bはユーザC,Dを、CSN1aはユーザA,B,C,Dを、ASN1aはユーザA,Bを、ASN1bはユーザC,Dをそれぞれ収容している。本処理の初期状態では、図6(a)に示すように、何れのユーザの呼処理の状態も、呼処理が実行中でない状態である、例えば、待受状態である“状態1”となっている。上記のように本処理では、ユーザCに着目する。図5のシーケンス図には、呼処理管理用データベース10で保持されるユーザCの情報(図3に示す情報と同様の情報)を示す。
移動体通信システム1では、ネットワークマネージャ40のノード状態把握部41によって、各呼処理サーバ20の状態の把握が行われている。各呼処理サーバ20の状態を示す情報は、ノード状態把握部41から制御部42に出力される。続いて、制御部42によって、各呼処理サーバ20の状態を示す情報に基づいて呼処理を行う呼処理サーバ20が決定されて、決定された呼処理サーバ20に呼処理の要求が送信されるようにフローエントリが生成されている。生成されたフローエントリは、オープンフローネットワーク30の各ノード31に送信されている。オープンフローネットワーク30の各ノード31では、当該フローエントリが受信されて、当該フローエントリに基づいてフロー(呼処理の要求等の信号)の送信が行われる。なお、図5においては、オープンフローネットワーク30の図示を省略する。
本処理では、まず、ユーザCから移動体通信システム1(移動体通信網)に対して発信要求が行われる。発信要求は、別の端末(例えば、ユーザX)と通信を行うための呼接続の要求である。当該発信要求に係る信号(発信信号)は、P−GWに受信される。
続いて、発信信号は、P-GWからP−CSCF1に対して送信される。送信された発信信号は、オープンフローネットワーク30の所定のノード31(P-GWと接続されているノード31)によって受信される。当該ノード31によって、フローエントリに基づいて、要求先(送信先)のP−CSCF1(P−CSCF1b)が決定される。続いて、当該ノード31からP−CSCF1bに発信信号が送信される(S01、制御ステップ)。
発信信号が送信されたP−CSCF1bでは、呼処理要求受付部21によって発信信号が受信される(S01、呼処理要求受付ステップ)。呼処理要求受付部21によって受け付けられた発信要求の情報は、登録部22、取得部23及び呼処理部24に出力される。P−CSCF1bでは、登録部22によって、当該発信信号に基づいて動的ステート情報更新要求が呼処理管理用データベース10に送信される(S02、登録ステップ)。動的ステート情報更新要求は、当該発信信号に係る呼処理の要求元のユーザCに対する呼処理を実行中のP−CSCFとして自ノードを呼処理管理用データベース10に登録する信号である。動的ステート情報更新要求は、ユーザCのユーザ識別子とP−CSCF1bのノードIDとが含まれる。なお、動的ステート情報の更新や参照(KVSの更新、参照)は、呼処理サーバ20に移動通信端末50の情報のキャッシュがある場合でも行われる(以下についても同様である)。
なお、P−CSCF1bでは、呼処理に必要なユーザCのデータ、即ち、呼処理の状態を示すステート情報やユーザCに係る加入者プロファイルを含む呼情報を保持していない。
そこで、P−CSCF1bでは、動的ステート情報更新要求の送信と合わせて、取得部23から呼処理管理用データベース10に対して、発信要求を行ったユーザCに係る呼情報を要求する呼情報取得要求が行われる(S02、取得ステップ)。動的ステート情報更新要求と呼情報取得要求とは同一の信号によって行われてもよいし、別々の信号によって行われてもよい。
呼処理管理用データベース10では、動的ステート情報更新要求及び呼情報取得要求が受信される。呼処理管理用データベース10では、図6(b)に示すように、動的ステート情報更新要求に基づいて、管理されているユーザCに係るP−CSCFの呼状態が“状態1”から“状態遷移中”にされる。また、ユーザCに対する呼処理を実行中のP−CSCFとしてP−CSCF1bが登録される。ユーザCの呼状態(ステート情報)が更新されると呼処理管理用データベース10からP−CSCF1bに更新完了通知が送信される(S03)。
また、呼処理管理用データベース10では、呼情報取得要求に基づいて、ユーザCに係る呼情報が読み出されて、呼処理管理用データベース10からP−CSCF1bに呼情報取得応答として送信される(S03)。更新完了通知と呼情報取得応答とは同一の信号によって行われてもよいし、別々の信号によって行われてもよい。
P−CSCF1bでは、取得部23によって呼情報が受信される(S03、取得ステップ)。ここで取得される呼情報は、待受中である旨の情報を含む呼情報である。これにより、P−CSCF1bは、呼処理の状態を示すステート情報やユーザCに係る加入者プロファイルを含む呼情報を保持した状態となる。受信された呼情報は、取得部23から呼処理部24に出力される。
続いて、呼処理部24によって、取得部23によって取得された呼情報に基づいて、発信要求に係る呼処理が実行される(S04、呼処理ステップ)。ここでの呼処理は呼接続を確立するための発信処理であり、他のサーバとの間で呼接続を確立する発信シーケンスに沿って処理が行われる。呼処理中の情報は、上述した一時的な情報として保持されている。
続いて、当該呼処理の一つとして、発信信号が、呼処理部24からCSN1に対して送信される。送信された発信信号は、オープンフローネットワーク30の所定のノード31(P−CSCF1bと接続されているノード31)によって受信される。当該ノード31によって、フローエントリに基づいて、要求先(送信先)のCSN1(CSN1a)が決定される。続いて、当該ノード31からCSN1aに発信信号が送信される(S05、制御ステップ)。
発信信号が送信されたCSN1aでは、呼処理要求受付部21によって発信信号が受信される(S05、呼処理要求受付ステップ)。呼処理要求受付部21によって受け付けられた発信要求の情報は、登録部22、取得部23及び呼処理部24に出力される。CSN1aでは、登録部22によって、当該発信信号に基づいて動的ステート情報更新要求が呼処理管理用データベース10に送信される(S06、登録ステップ)。動的ステート情報更新要求は、当該発信信号に係る呼処理の要求元のユーザCに対する呼処理を実行中のCSNとして自ノードを呼処理管理用データベース10に登録する信号である。動的ステート情報更新要求は、ユーザCのユーザ識別子とCSN1aのノードIDとが含まれる。
なお、CSN1aでは、呼処理に必要なユーザCのデータ、即ち、呼処理の状態を示すステート情報やユーザCに係る加入者プロファイルを含む呼情報を保持していない。
そこで、CSN1aでは、動的ステート情報更新要求の送信と合わせて、取得部23から呼処理管理用データベース10に対して、発信要求を行ったユーザCに係る呼情報を要求する呼情報取得要求が行われる(S06、取得ステップ)。動的ステート情報更新要求と呼情報取得要求とは同一の信号によって行われてもよいし、別々の信号によって行われてもよい。
呼処理管理用データベース10では、動的ステート情報更新要求及び呼情報取得要求が受信される。呼処理管理用データベース10では、図6(c)に示すように、動的ステート情報更新要求に基づいて、管理されているユーザCに係るCSNの呼状態が“状態1”から“状態遷移中”にされる。また、ユーザCに対する呼処理を実行中のCSNとしてCSN1aが登録される。ユーザCの呼状態(ステート情報)が更新されると呼処理管理用データベース10からCSN1aに更新完了通知が送信される(S07)。
また、呼処理管理用データベース10では、呼情報取得要求に基づいて、ユーザCに係る呼情報が読み出されて、呼処理管理用データベース10からCSN1aに呼情報取得応答として送信される(S07)。更新完了通知と呼情報取得応答とは同一の信号によって行われてもよいし、別々の信号によって行われてもよい。
CSN1aでは、取得部23によって呼情報が受信される(S07、取得ステップ)。ここで取得される呼情報は、待受中である旨の情報を含む呼情報である。これにより、CSN1aは、呼処理の状態を示すステート情報やユーザCに係る加入者プロファイルを含む呼情報を保持した状態となる。受信された呼情報は、取得部23から呼処理部24に出力される。
続いて、呼処理部24によって、取得部23によって取得された呼情報に基づいて、発信要求に係る呼処理が実行される(S08、呼処理ステップ)。ここでの呼処理は呼接続を確立するための発信処理であり、他のサーバとの間で呼接続を確立する発信シーケンスに沿って処理が行われる。呼処理中の情報は、上述した一時的な情報として保持されている。
続いて、当該呼処理の一つとして、発信信号が、呼処理部24からASN1に対して送信される。送信された発信信号は、オープンフローネットワーク30の所定のノード31(CSN1aと接続されているノード31)によって受信される。当該ノード31によって、フローエントリに基づいて、要求先(送信先)のASN1(ASN1b)が決定される。続いて、当該ノード31からASN1bに発信信号が送信される(S09、制御ステップ)。
発信信号が送信されたASN1bでは、呼処理要求受付部21によって発信信号が受信される(S09、呼処理要求受付ステップ)。呼処理要求受付部21によって受け付けられた発信要求の情報は、登録部22、取得部23及び呼処理部24に出力される。ASN1bでは、登録部22によって、当該発信信号に基づいて動的ステート情報更新要求が呼処理管理用データベース10に送信される(S10、登録ステップ)。動的ステート情報更新要求は、当該発信信号に係る呼処理の要求元のユーザCに対する呼処理を実行中のASNとして自ノードを呼処理管理用データベース10に登録する信号である。動的ステート情報更新要求は、ユーザCのユーザ識別子とASN1bのノードIDとが含まれる。
なお、ASN1bでは、呼処理に必要なユーザCのデータ、即ち、呼処理の状態を示すステート情報やユーザCに係る加入者プロファイルを含む呼情報を保持していない。
そこで、ASN1bでは、動的ステート情報更新要求の送信と合わせて、取得部23から呼処理管理用データベース10に対して、発信要求を行ったユーザCに係る呼情報を要求する呼情報取得要求が行われる(S10、取得ステップ)。動的ステート情報更新要求と呼情報取得要求とは同一の信号によって行われてもよいし、別々の信号によって行われてもよい。
呼処理管理用データベース10では、動的ステート情報更新要求及び呼情報取得要求が受信される。呼処理管理用データベース10では、図6(d)に示すように、動的ステート情報更新要求に基づいて、管理されているユーザCに係るASNの呼状態が“状態1”から“状態遷移中”にされる。また、ユーザCに対する呼処理を実行中のASNとしてASN1bが登録される。ユーザCの呼状態(ステート情報)が更新されると呼処理管理用データベース10からASN1bに更新完了通知が送信される(S11)。
また、呼処理管理用データベース10では、呼情報取得要求に基づいて、ユーザCに係る呼情報が読み出されて、呼処理管理用データベース10からASN1bに呼情報取得応答として送信される(S11)。更新完了通知と呼情報取得応答とは同一の信号によって行われてもよいし、別々の信号によって行われてもよい。
ASN1bでは、取得部23によって呼情報が受信される(S11、取得ステップ)。ここで取得される呼情報は、待受中である旨の情報を含む呼情報である。これにより、ASN1bは、呼処理の状態を示すステート情報やユーザCに係る加入者プロファイルを含む呼情報を保持した状態となる。受信された呼情報は、取得部23から呼処理部24に出力される。
続いて、呼処理部24によって、取得部23によって取得された呼情報に基づいて、発信要求に係る呼処理が実行される(S12、呼処理ステップ)。ここでの呼処理は呼接続を確立するための発信処理であり、他のサーバとの間で呼接続を確立する発信シーケンスに沿って処理が行われる。
ここで(S09以降、S18以前のタイミングで)、CSN1の負荷を分散させるために、CSN1bが増設される(S13)。この増設は、例えば、移動体通信システム1の通信事業者によって行われる。移動体通信システム1では、ネットワークマネージャ40のノード状態把握部41によって、各呼処理サーバ20の状態の把握が行われる(S14、ノード状態把握ステップ)。このとき、ノード状態把握部41によって、CSN1bの増設も把握される。各呼処理サーバ20の状態を示す情報は、ノード状態把握部41から制御部42に出力される。
呼処理サーバ20が仮想化されていた場合には、S13は以下のような処理にすることができる。即ち、例えば輻輳等によって呼処理サーバ20の処理能力不足をノード状態把握部41が把握し、制御部42に通知する。制御部42は仮想マシン制御部へ呼処理サーバ20の追加を指示する。仮想マシン制御部は、呼処理サーバ20を新たにプロビジョニングする。
続いて、制御部42によって、各呼処理サーバ20の状態を示す情報に基づいて呼処理を行う呼処理サーバ20が決定されて、決定された呼処理サーバ20に呼処理の要求が送信されるようにフローエントリが生成される(S15、制御ステップ)。ここでは、CSN1bが新たに増設されたので、ここで生成されるフローエントリは、呼処理を行う呼処理サーバ20として、新たに増設されたCSN1bを含むものとされたものとなる。例えば、図7(a)に示すように、ユーザC,Dに係る呼処理はCSN1bによって実行されるものとして(ユーザC,DがCSN1bに収容されるものとして)フローエントリが生成される。
生成されたフローエントリは、オープンフローネットワーク30の各ノード31に送信される(S15、制御ステップ)。オープンフローネットワーク30の各ノード31では、当該フローエントリが受信されて、当該フローエントリに基づいてフロー(呼処理の要求等の信号)の送信が行われる。
ASN1bでは、呼処理部24による呼処理が完了すると、ユーザCに係るASNの通信状態が、例えば発信中状態である“状態2”に状態遷移される。呼処理部24によって行われた呼処理の結果の情報(“状態2”に状態遷移された呼情報)は、呼処理部24から呼処理結果格納部25に出力される。
続いて、呼処理結果格納部25によって、動的ステート情報更新要求が呼処理管理用データベース10に送信される(S16、呼処理結果格納ステップ)。ここで送信される動的ステート情報更新要求は、自ノードにおける呼処理が終了して、ユーザCにおける呼処理の状態を状態遷移中から何れの呼処理サーバ20においても呼処理が実行中でない状態に移行した旨を通知する信号である。動的ステート情報更新要求は、ユーザCのユーザ識別子とASN1bのノードIDとが含まれる。
また、呼処理の結果が反映された呼情報が、呼処理結果格納部25から呼処理管理用データベース10に呼情報更新要求として送信される(S16、呼処理結果格納ステップ)。なお、呼情報更新要求と動的ステート情報更新要求とは同一の信号によって行われてもよいし、別々の信号によって行われてもよい。
呼処理管理用データベース10では、動的ステート情報更新要求及び呼情報更新要求が受信される。呼処理管理用データベース10では、図7(b)に示すように、動的ステート情報更新要求に基づいて、管理されているユーザCに係るASNの呼状態が“状態遷移中”から“状態2”にされる。ユーザCの呼状態(ステート情報)が更新されると呼処理管理用データベース10からASN1bに更新完了通知が送信される(S17)。
また、呼処理管理用データベース10では、呼情報更新要求に基づいて、ユーザCに係る情報が受信した情報で更新される。即ち、更新後の呼情報は“状態2”である旨の情報を含む。更新が行われると、呼情報更新応答が呼処理管理用データベース10からASN1bに送信される(S17)。なお、更新完了通知と呼情報更新応答とは同一の信号によって行われてもよいし、別々の信号によって行われてもよい。
ASN1bでは、呼情報更新応答が受信されると、発信応答に係る信号がCSN1に送信される(S18)。送信された発信応答は、オープンフローネットワーク30の所定のノード31(ASN1bと接続されているノード31)によって受信される。当該ノード31によって、フローエントリに基づいて、要求先(送信先)のCSN1(CNS1b)が決定される。上述したように、フローエントリは、ユーザCの呼処理を行うCSNは増設されたCSN1bとされている。続いて、当該ノード31からCSN1bに発信応答が送信される(S18、制御ステップ)。
発信応答が送信されたCSN1bでは、呼処理要求受付部21によって発信応答が受信される(S18、呼処理要求受付ステップ)。呼処理要求受付部21によって受け付けられた発信応答の情報は、登録部22、取得部23及び呼処理部24に出力される。
CSN1bは、今までユーザCの呼処理を行っていた呼処理サーバ20ではないのでユーザCに係る情報を保持していない。まず、CSN1bでは、登録部22によって、当該発信応答に基づいて動的ステート情報取得要求が呼処理管理用データベース10に送信される(S19、登録ステップ)。動的ステート情報取得要求は、当該発信応答に係る呼処理の要求元のユーザCに対する呼処理を実行中のCSNとして登録されているCSNのノードIDを要求する信号(ユーザCのCNSに関する状態がどうなっているかを問い合わせる信号)である。また、動的ステート情報取得要求は、当該発信応答に係る呼処理の要求元のユーザCに対する呼処理を実行中のCSNとして自ノードを呼処理管理用データベース10に登録する信号でもある。動的ステート情報更新要求は、ユーザCのユーザ識別子とCSN1bのノードIDとが含まれる。
呼処理管理用データベース10では、動的ステート情報取得要求が受信される。呼処理管理用データベース10では、動的ステート情報取得要求に対する応答として、ユーザCに対する呼処理を実行中のCSNとして登録されているCSNのノードID(CSN1aのノードID)(CSN1aがS06で登録した情報)をCSN1bに送信する(S20)。また、呼処理管理用データベース10では、図7(c)に示すように、動的ステート情報取得要求に基づいて、ユーザCに対する呼処理を実行中のCSNとしてCSN1bが登録される。なお、ユーザCに係るCSNの呼状態は“状態遷移中”のままである。ユーザCの呼状態(ステート情報)が更新されると呼処理管理用データベース10からCSN1bに更新完了通知が送信される(S20)。なお、動的ステート情報取得要求に対する応答と更新完了通知とは同一の信号によって行われてもよいし、別々の信号によって行われてもよい。
CSN1bでは、図7(d)に示すように、取得部23によって、呼処理管理用データベース10から送信された、ユーザCに対する呼処理を実行中のCSNとして登録されているCSNのノードIDによって示されるCSN1aとの間でユーザCに関して呼処理を実行するための情報が同期される。情報の同期は、CSN1bの取得部23からCSN1aに対して同期の要求が行われて(S21)、CSN1aから当該要求に応じて送信された情報の受信が行われる(S22)ことで行われる。
ここで、CSN1aからCSN1bに送信されるユーザCに係る情報には、呼処理の途中で用いられる一時的な情報が含まれる。また、当該情報には、CSN1aが呼処理管理用データベース10から取得された呼処理の状態を示すステート情報やユーザCに係る加入者プロファイルを含む呼情報が含まれていてもよい。但し、呼処理管理用データベース10から取得可能な情報は、CSN1aから取得せずに呼処理管理用データベース10から取得してもよい。このように取得部23によって取得された、ユーザCに係る呼処理を継続するための情報は取得部23から呼処理部24に出力される。
続いて、呼処理部24によって、取得部23によって取得された呼情報に基づいて、発信応答(発信要求)に係る呼処理が実行される(S23、呼処理ステップ)。
呼処理部24による呼処理が完了すると、ユーザCに係るCSNの通信状態が“状態2”に状態遷移される。呼処理部24によって行われた呼処理の結果の情報(“状態2”に状態遷移された呼情報)は、呼処理部24から呼処理結果格納部25に出力される。
続いて、呼処理結果格納部25によって、動的ステート情報更新要求が呼処理管理用データベース10に送信される(S24、呼処理結果格納ステップ)。ここで送信される動的ステート情報更新要求は、自ノードにおける呼処理が終了して、ユーザCにおける呼処理の状態を状態遷移中から何れの呼処理サーバ20においても呼処理が実行中でない状態に移行した旨を通知する信号である。動的ステート情報更新要求は、ユーザCのユーザ識別子とCSN1bのノードIDとが含まれる。
また、呼処理の結果が反映された呼情報が、呼処理結果格納部25から呼処理管理用データベース10に呼情報更新要求として送信される(S25、呼処理結果格納ステップ)。なお、呼情報更新要求と動的ステート情報更新要求とは同一の信号によって行われてもよいし、別々の信号によって行われてもよい。
呼処理管理用データベース10では、動的ステート情報更新要求及び呼情報更新要求が受信される。呼処理管理用データベース10では、図8(a)に示すように、動的ステート情報更新要求に基づいて、管理されているユーザCに係るCSNの呼状態が“状態遷移中”から“状態2”にされる。ユーザCの呼状態(ステート情報)が更新されると呼処理管理用データベース10からCSN1bに更新完了通知が送信される(S25)。
また、呼処理管理用データベース10では、呼情報更新要求に基づいて、ユーザCに係る情報が受信した情報で更新される。即ち、更新後の呼情報は“状態2”である旨の情報を含む。更新が行われると、呼情報更新応答が呼処理管理用データベース10からCSN1bに送信される(S25)。なお、更新完了通知と呼情報更新応答とは同一の信号によって行われてもよいし、別々の信号によって行われてもよい。
CSN1bでは、呼情報更新応答が受信されると、発信応答に係る信号がP−CSCF1に送信される(S26)。送信された発信応答は、オープンフローネットワーク30の所定のノード31(CSN1bと接続されているノード31)によって受信される。当該ノード31によって、フローエントリに基づいて、要求先(送信先)のP−CSCF1(P−CSCF1b)が決定される。続いて、当該ノード31からP−CSCF1bに発信応答が送信される(S26、制御ステップ)。
発信応答が送信されたP−CSCF1bでは、呼処理要求受付部21によって発信応答が受信される(S26、呼処理要求受付ステップ)。呼処理要求受付部21によって受け付けられた発信応答の情報は呼処理部24に出力される。
P−CSCF1bでは、呼処理部24によって、入力された発信応答と、S04における処理で用いた情報とに基づいて、発信応答(発信要求)に係る呼処理が実行される(S27、呼処理ステップ)。
呼処理部24による呼処理が完了すると、ユーザCに係るP−CSCFの通信状態が“状態2”に状態遷移される。呼処理部24によって行われた呼処理の結果の情報(“状態2”に状態遷移された呼情報)は、呼処理部24から呼処理結果格納部25に出力される。
続いて、呼処理結果格納部25によって、動的ステート情報更新要求が呼処理管理用データベース10に送信される(S28、呼処理結果格納ステップ)。ここで送信される動的ステート情報更新要求は、自ノードにおける呼処理が終了して、ユーザCにおける呼処理の状態を状態遷移中から何れの呼処理サーバ20においても呼処理が実行中でない状態に移行した旨を通知する信号である。動的ステート情報更新要求は、ユーザCのユーザ識別子とP−CSCF1bのノードIDとが含まれる。
また、呼処理の結果が反映された呼情報が、呼処理結果格納部25から呼処理管理用データベース10に呼情報更新要求として送信される(S28、呼処理結果格納ステップ)。なお、呼情報更新要求と動的ステート情報更新要求とは同一の信号によって行われてもよいし、別々の信号によって行われてもよい。
呼処理管理用データベース10では、動的ステート情報更新要求及び呼情報更新要求が受信される。呼処理管理用データベース10では、図8(b)に示すように、動的ステート情報更新要求に基づいて、管理されているユーザCに係るP−CSCFの呼状態が“状態遷移中”から“状態2”にされる。ユーザCの呼状態(ステート情報)が更新されると呼処理管理用データベース10からP−CSCF1bに更新完了通知が送信される(S29)。
また、呼処理管理用データベース10では、呼情報更新要求に基づいて、ユーザCに係る情報が受信した情報で更新される。即ち、更新後の呼情報は“状態2”である旨の情報を含む。更新が行われると、呼情報更新応答が呼処理管理用データベース10からP−CSCF1bに送信される(S29)。なお、更新完了通知と呼情報更新応答とは同一の信号によって行われてもよいし、別々の信号によって行われてもよい。
P−CSCF1bでは、呼情報更新応答が受信されると、発信応答に係る信号がP−GWに送信される(S30)。また、発信応答に係る信号は、P−GWからユーザCに送信される。以上の処理により、ユーザCは発信中状態(“状態2”)となり、呼情報に含まれるユーザCの通信状態(移動体通信網で管理されるユーザCの通信状態)も発信中状態(“状態2”)に状態遷移される。
以上が、ユーザ識別子が“C”である移動通信端末50から別の端末への発信等の呼処理の要求があり、その呼処理の途中で呼処理サーバ20が増設されてスケールアウトされた場合の処理である。上記は、発信の際の処理であったが、その他の呼処理についても同様に行われる。例えば、移動通信端末50が位置登録を行う場合には、位置登録要求を受信した呼処理サーバ20は、図5のS02、S03、S06、S07、S10、S11、S19、S20、S21、S22に相当する処理によって、当該移動通信端末50が圏外、あるいは別の位置登録エリアに在圏している呼情報を取得する。そして、S04、S08、S12、S23、S27に相当する処理によって位置登録処理を行う。そして、S16、S17、S24、S25、S28、S29に相当する処理によって、位置登録後(あるいは更新後)の位置登録エリアと、待受中の情報とを含む、当該移動通信端末50に係る更新後の呼情報を呼処理管理用データベース10に格納する。また、対向装置から呼接続の要求があった場合も、同様の処理を適用することができる。
引き続いて、図9のシーケンス図及び図10〜図12を用いて、ユーザCから別の端末への発信等の呼処理の要求があり、その呼処理の途中で呼処理サーバ20が減設された場合の処理について説明する。本処理では、CSNが減設される例について説明する。また、図3に示すように呼処理サーバとして、P−CSCF、CSN及びASNが設けられている例について説明する。
呼処理サーバ(P−CSCF1、CSN1、ASN1)20は、それぞれユーザA,B,C,Dを収容している。P−CSCF1aはユーザA,Bを、P−CSCF1bはユーザC,Dを、CSN1aはユーザA,Bを、CSN1bはユーザC,Dを、ASN1aはユーザA,Bを、ASN1bはユーザC,Dをそれぞれ収容している。本処理の初期状態では、図10(a)に示すように、何れのユーザの呼処理の状態も、呼処理が実行中でない状態である、例えば、待受状態である“状態1”となっている。上記のように本処理では、ユーザCに着目する。図9のシーケンス図には、呼処理管理用データベース10で保持されるユーザCの情報(図3に示す情報と同様の情報)を示す。
移動体通信システム1では、ネットワークマネージャ40のノード状態把握部41によって、各呼処理サーバ20の状態の把握が行われている。各呼処理サーバ20の状態を示す情報は、ノード状態把握部41から制御部42に出力される。続いて、制御部42によって、各呼処理サーバ20の状態を示す情報に基づいて呼処理を行う呼処理サーバ20が決定されて、決定された呼処理サーバ20に呼処理の要求が送信されるようにフローエントリが生成されている。生成されたフローエントリは、オープンフローネットワーク30の各ノード31に送信されている。オープンフローネットワーク30の各ノード31では、当該フローエントリが受信されて、当該フローエントリに基づいてフロー(呼処理の要求等の信号)の送信が行われる。なお、図9においては、オープンフローネットワーク30の図示を省略する。
本処理では、まず、ユーザCから移動体通信システム1(移動体通信網)に対して発信要求が行われる。発信要求は、別の端末(例えば、ユーザX)と通信を行うための呼接続の要求である。当該発信要求に係る信号(発信信号)は、P−GWに受信される。
続いて、発信信号は、P-GWからP−CSCF1に対して送信される。送信された発信信号は、オープンフローネットワーク30の所定のノード31(P-GWと接続されているノード31)によって受信される。当該ノード31によって、フローエントリに基づいて、要求先(送信先)のP−CSCF1(P−CSCF1b)が決定される。続いて、当該ノード31からP−CSCF1bに発信信号が送信される(S41、制御ステップ)。
発信信号が送信されたP−CSCF1bでは、呼処理要求受付部21によって発信信号が受信される(S41、呼処理要求受付ステップ)。呼処理要求受付部21によって受け付けられた発信要求の情報は、登録部22、取得部23及び呼処理部24に出力される。P−CSCF1bでは、登録部22によって、当該発信信号に基づいて動的ステート情報更新要求が呼処理管理用データベース10に送信される(S42、登録ステップ)。動的ステート情報更新要求は、当該発信信号に係る呼処理の要求元のユーザCに対する呼処理を実行中のP−CSCFとして自ノードを呼処理管理用データベース10に登録する信号である。動的ステート情報更新要求は、ユーザCのユーザ識別子とP−CSCF1bのノードIDとが含まれる。
なお、P−CSCF1bでは、呼処理に必要なユーザCのデータ、即ち、呼処理の状態を示すステート情報やユーザCに係る加入者プロファイルを含む呼情報を保持していない。
そこで、P−CSCF1bでは、動的ステート情報更新要求の送信と合わせて、取得部23から呼処理管理用データベース10に対して、発信要求を行ったユーザCに係る呼情報を要求する呼情報取得要求が行われる(S42、取得ステップ)。動的ステート情報更新要求と呼情報取得要求とは同一の信号によって行われてもよいし、別々の信号によって行われてもよい。
呼処理管理用データベース10では、動的ステート情報更新要求及び呼情報取得要求が受信される。呼処理管理用データベース10では、図10(b)に示すように、動的ステート情報更新要求に基づいて、管理されているユーザCに係るP−CSCFの呼状態が“状態1”から“状態遷移中”にされる。また、ユーザCに対する呼処理を実行中のP−CSCFとしてP−CSCF1bが登録される。ユーザCの呼状態(ステート情報)が更新されると呼処理管理用データベース10からP−CSCF1bに更新完了通知が送信される(S43)。
また、呼処理管理用データベース10では、呼情報取得要求に基づいて、ユーザCに係る呼情報が読み出されて、呼処理管理用データベース10からP−CSCF1bに呼情報取得応答として送信される(S43)。更新完了通知と呼情報取得応答とは同一の信号によって行われてもよいし、別々の信号によって行われてもよい。
P−CSCF1bでは、取得部23によって呼情報が受信される(S43、取得ステップ)。ここで取得される呼情報は、待受中である旨の情報を含む呼情報である。これにより、P−CSCF1bは、呼処理の状態を示すステート情報やユーザCに係る加入者プロファイルを含む呼情報を保持した状態となる。受信された呼情報は、取得部23から呼処理部24に出力される。
続いて、呼処理部24によって、取得部23によって取得された呼情報に基づいて、発信要求に係る呼処理が実行される(S44、呼処理ステップ)。ここでの呼処理は呼接続を確立するための発信処理であり、他のサーバとの間で呼接続を確立する発信シーケンスに沿って処理が行われる。呼処理中の情報は、上述した一時的な情報として保持されている。
続いて、当該呼処理の一つとして、発信信号が、呼処理部24からCSN1に対して送信される。送信された発信信号は、オープンフローネットワーク30の所定のノード31(P−CSCF1bと接続されているノード31)によって受信される。当該ノード31によって、フローエントリに基づいて、要求先(送信先)のCSN1(CSN1b)が決定される。続いて、当該ノード31からCSN1bに発信信号が送信される(S45、制御ステップ)。
発信信号が送信されたCSN1bでは、呼処理要求受付部21によって発信信号が受信される(S45、呼処理要求受付ステップ)。呼処理要求受付部21によって受け付けられた発信要求の情報は、登録部22、取得部23及び呼処理部24に出力される。CSN1bでは、登録部22によって、当該発信信号に基づいて動的ステート情報更新要求が呼処理管理用データベース10に送信される(S46、登録ステップ)。動的ステート情報更新要求は、当該発信信号に係る呼処理の要求元のユーザCに対する呼処理を実行中のCSNとして自ノードを呼処理管理用データベース10に登録する信号である。動的ステート情報更新要求は、ユーザCのユーザ識別子とCSN1bのノードIDとが含まれる。
なお、CSN1bでは、呼処理に必要なユーザCのデータ、即ち、呼処理の状態を示すステート情報やユーザCに係る加入者プロファイルを含む呼情報を保持していない。
そこで、CSN1bでは、動的ステート情報更新要求の送信と合わせて、取得部23から呼処理管理用データベース10に対して、発信要求を行ったユーザCに係る呼情報を要求する呼情報取得要求が行われる(S46、取得ステップ)。動的ステート情報更新要求と呼情報取得要求とは同一の信号によって行われてもよいし、別々の信号によって行われてもよい。
呼処理管理用データベース10では、動的ステート情報更新要求及び呼情報取得要求が受信される。呼処理管理用データベース10では、図10(c)に示すように、動的ステート情報更新要求に基づいて、管理されているユーザCに係るCSNの呼状態が“状態1”から“状態遷移中”にされる。また、ユーザCに対する呼処理を実行中のCSNとしてCSN1bが登録される。ユーザCの呼状態(ステート情報)が更新されると呼処理管理用データベース10からCSN1bに更新完了通知が送信される(S47)。
また、呼処理管理用データベース10では、呼情報取得要求に基づいて、ユーザCに係る呼情報が読み出されて、呼処理管理用データベース10からCSN1aに呼情報取得応答として送信される(S47)。更新完了通知と呼情報取得応答とは同一の信号によって行われてもよいし、別々の信号によって行われてもよい。
CSN1bでは、取得部23によって呼情報が受信される(S47、取得ステップ)。ここで取得される呼情報は、待受中である旨の情報を含む呼情報である。これにより、CSN1bは、呼処理の状態を示すステート情報やユーザCに係る加入者プロファイルを含む呼情報を保持した状態となる。受信された呼情報は、取得部23から呼処理部24に出力される。
続いて、呼処理部24によって、取得部23によって取得された呼情報に基づいて、発信要求に係る呼処理が実行される(S48、呼処理ステップ)。ここでの呼処理は呼接続を確立するための発信処理であり、他のサーバとの間で呼接続を確立する発信シーケンスに沿って処理が行われる。呼処理中の情報は、上述した一時的な情報として保持されている。
続いて、当該呼処理の一つとして、発信信号が、呼処理部24からASN1に対して送信される。送信された発信信号は、オープンフローネットワーク30の所定のノード31(CSN1bと接続されているノード31)によって受信される。当該ノード31によって、フローエントリに基づいて、要求先(送信先)のASN1(ASN1b)が決定される。続いて、当該ノード31からASN1bに発信信号が送信される(S49、制御ステップ)。
発信信号が送信されたASN1bでは、呼処理要求受付部21によって発信信号が受信される(S49、呼処理要求受付ステップ)。呼処理要求受付部21によって受け付けられた発信要求の情報は、登録部22、取得部23及び呼処理部24に出力される。ASN1bでは、登録部22によって、当該発信信号に基づいて動的ステート情報更新要求が呼処理管理用データベース10に送信される(S51、登録ステップ)。動的ステート情報更新要求は、当該発信信号に係る呼処理の要求元のユーザCに対する呼処理を実行中のASNとして自ノードを呼処理管理用データベース10に登録する信号である。動的ステート情報更新要求は、ユーザCのユーザ識別子とASN1bのノードIDとが含まれる。
なお、ASN1bでは、呼処理に必要なユーザCのデータ、即ち、呼処理の状態を示すステート情報やユーザCに係る加入者プロファイルを含む呼情報を保持していない。
そこで、ASN1bでは、動的ステート情報更新要求の送信と合わせて、取得部23から呼処理管理用データベース10に対して、発信要求を行ったユーザCに係る呼情報を要求する呼情報取得要求が行われる(S50、取得ステップ)。動的ステート情報更新要求と呼情報取得要求とは同一の信号によって行われてもよいし、別々の信号によって行われてもよい。
呼処理管理用データベース10では、動的ステート情報更新要求及び呼情報取得要求が受信される。呼処理管理用データベース10では、図10(d)に示すように、動的ステート情報更新要求に基づいて、管理されているユーザCに係るASNの呼状態が“状態1”から“状態遷移中”にされる。また、ユーザCに対する呼処理を実行中のASNとしてASN1bが登録される。ユーザCの呼状態(ステート情報)が更新されると呼処理管理用データベース10からASN1bに更新完了通知が送信される(S51)。
また、呼処理管理用データベース10では、呼情報取得要求に基づいて、ユーザCに係る呼情報が読み出されて、呼処理管理用データベース10からASN1bに呼情報取得応答として送信される(S51)。更新完了通知と呼情報取得応答とは同一の信号によって行われてもよいし、別々の信号によって行われてもよい。
ASN1bでは、取得部23によって呼情報が受信される(S51、取得ステップ)。ここで取得される呼情報は、待受中である旨の情報を含む呼情報である。これにより、ASN1bは、呼処理の状態を示すステート情報やユーザCに係る加入者プロファイルを含む呼情報を保持した状態となる。受信された呼情報は、取得部23から呼処理部24に出力される。
続いて、呼処理部24によって、取得部23によって取得された呼情報に基づいて、発信要求に係る呼処理が実行される(S52、呼処理ステップ)。ここでの呼処理は呼接続を確立するための発信処理であり、他のサーバとの間で呼接続を確立する発信シーケンスに沿って処理が行われる。
ここで(S49以降、S58以前のタイミングで)、CSN1の負荷を集約させるために、CSN1bが減設される(S53)。CSN1bの減設によって、CSN1bに収容されていたユーザがCSN1aに片寄せされる。この減設は、例えば、移動体通信システム1の通信事業者によって行われる。移動体通信システム1では、ネットワークマネージャ40のノード状態把握部41によって、各呼処理サーバ20の状態の把握が行われる(S54、ノード状態把握ステップ)。このとき、ノード状態把握部41によって、CSN1bの減設も把握される。各呼処理サーバ20の状態を示す情報は、ノード状態把握部41から制御部42に出力される。
呼処理サーバ20が仮想化されていた場合には、S53は以下のような処理にすることができる。即ち、例えば同一種類の複数の呼処理サーバ20の処理能力が過剰であることをノード状態把握部41が把握し、制御部42に通知する。制御部42は仮想マシン制御部へ呼処理サーバ20の削減を指示する。仮想マシン制御部は、複数の呼処理サーバ20の減設をする。
続いて、制御部42によって、各呼処理サーバ20の状態を示す情報に基づいて呼処理を行う呼処理サーバ20が決定されて、決定された呼処理サーバ20に呼処理の要求が送信されるようにフローエントリが生成される(S55、制御ステップ)。ここでは、CSN1bが減設されたので、ここで生成されるフローエントリは、呼処理を行う呼処理サーバ20として、減設されたCSN1bを含まないものとされたものとなる。例えば、図11(a)に示すように、ユーザC,Dに係る呼処理はCSN1aによって実行されるものとして(ユーザC,DがCSN1aに収容されるものとして)フローエントリが生成される。
生成されたフローエントリは、オープンフローネットワーク30の各ノード31に送信される(S55、制御ステップ)。オープンフローネットワーク30の各ノード31では、当該フローエントリが受信されて、当該フローエントリに基づいてフロー(呼処理の要求等の信号)の送信が行われる。
ASN1bでは、呼処理部24による呼処理が完了すると、ユーザCに係るASNの通信状態が、例えば発信中状態である“状態2”に状態遷移される。呼処理部24によって行われた呼処理の結果の情報(“状態2”に状態遷移された呼情報)は、呼処理部24から呼処理結果格納部25に出力される。
続いて、呼処理結果格納部25によって、動的ステート情報更新要求が呼処理管理用データベース10に送信される(S56、呼処理結果格納ステップ)。ここで送信される動的ステート情報更新要求は、自ノードにおける呼処理が終了して、ユーザCにおける呼処理の状態を状態遷移中から何れの呼処理サーバ20においても呼処理が実行中でない状態に移行した旨を通知する信号である。動的ステート情報更新要求は、ユーザCのユーザ識別子とASN1bのノードIDとが含まれる。
また、呼処理の結果が反映された呼情報が、呼処理結果格納部25から呼処理管理用データベース10に呼情報更新要求として送信される(S56、呼処理結果格納ステップ)。なお、呼情報更新要求と動的ステート情報更新要求とは同一の信号によって行われてもよいし、別々の信号によって行われてもよい。
呼処理管理用データベース10では、動的ステート情報更新要求及び呼情報更新要求が受信される。呼処理管理用データベース10では、図11(b)に示すように、動的ステート情報更新要求に基づいて、管理されているユーザCに係るASNの呼状態が“状態遷移中”から“状態2”にされる。ユーザCの呼状態(ステート情報)が更新されると呼処理管理用データベース10からASN1bに更新完了通知が送信される(S57)。
また、呼処理管理用データベース10では、呼情報更新要求に基づいて、ユーザCに係る情報が受信した情報で更新される。即ち、更新後の呼情報は“状態2”である旨の情報を含む。更新が行われると、呼情報更新応答が呼処理管理用データベース10からASN1bに送信される(S57)。なお、更新完了通知と呼情報更新応答とは同一の信号によって行われてもよいし、別々の信号によって行われてもよい。
ASN1bでは、呼情報更新応答が受信されると、発信応答に係る信号がCSN1に送信される(S58)。送信された発信応答は、オープンフローネットワーク30の所定のノード31(ASN1bと接続されているノード31)によって受信される。当該ノード31によって、フローエントリに基づいて、要求先(送信先)のCSN1(CNS1a)が決定される。上述したように、フローエントリは、ユーザCの呼処理を行うCSNは、減設されたCSN1bではなくCSN1aとされている。続いて、当該ノード31からCSN1aに発信応答が送信される(S58、制御ステップ)。
発信応答が送信されたCSN1aでは、呼処理要求受付部21によって発信応答が受信される(S58、呼処理要求受付ステップ)。呼処理要求受付部21によって受け付けられた発信応答の情報は、登録部22、取得部23及び呼処理部24に出力される。
CSN1aは、今までユーザCの呼処理を行っていた呼処理サーバ20ではないのでユーザCに係る情報を保持していない。まず、CSN1aでは、登録部22によって、当該発信応答に基づいて動的ステート情報取得要求が呼処理管理用データベース10に送信される(S59、登録ステップ)。動的ステート情報取得要求は、当該発信応答に係る呼処理の要求元のユーザCに対する呼処理を実行中のCSNとして登録されているCSNのノードIDを要求する信号(ユーザCのCNSに関する状態がどうなっているかを問い合わせる信号)である。また、動的ステート情報取得要求は、当該発信応答に係る呼処理の要求元のユーザCに対する呼処理を実行中のCSNとして自ノードを呼処理管理用データベース10に登録する信号でもある。動的ステート情報更新要求は、ユーザCのユーザ識別子とCSN1aのノードIDとが含まれる。
呼処理管理用データベース10では、動的ステート情報取得要求が受信される。呼処理管理用データベース10では、動的ステート情報取得要求に対する応答として、ユーザCに対する呼処理を実行中のCSNとして登録されているCSNのノードID(CSN1bのノードID)(CSN1bがS46で登録した情報)をCSN1aに送信する(S60)。また、呼処理管理用データベース10では、図11(c)に示すように、動的ステート情報取得要求に基づいて、ユーザCに対する呼処理を実行中のCSNとしてCSN1aが登録される。なお、ユーザCに係るCSNの呼状態は“状態遷移中”のままである。ユーザCの呼状態(ステート情報)が更新されると呼処理管理用データベース10からCSN1bに更新完了通知が送信される(S60)。なお、動的ステート情報取得要求に対する応答と更新完了通知とは同一の信号によって行われてもよいし、別々の信号によって行われてもよい。
CSN1aでは、図11(d)に示すように、取得部23によって、呼処理管理用データベース10から送信された、ユーザCに対する呼処理を実行中のCSNとして登録されているCSNのノードIDによって示されるCSN1bとの間でユーザCに関して呼処理を実行するための情報が同期される。情報の同期は、CSN1aの取得部23からCSN1bに対して同期の要求が行われて(S61)、CSN1bから当該要求に応じて送信された情報の受信が行われる(S62)ことで行われる。
ここで、CSN1bからCSN1aに送信されるユーザCに係る情報には、呼処理の途中で用いられる一時的な情報が含まれる。また、当該情報には、CSN1bが呼処理管理用データベース10から取得された呼処理の状態を示すステート情報やユーザCに係る加入者プロファイルを含む呼情報が含まれていてもよい。但し、呼処理管理用データベース10から取得可能な情報は、CSN1bから取得せずに呼処理管理用データベース10から取得してもよい。このように取得部23によって取得された、ユーザCに係る呼処理を継続するための情報は取得部23から呼処理部24に出力される。
続いて、呼処理部24によって、取得部23によって取得された呼情報に基づいて、発信応答(発信要求)に係る呼処理が実行される(S63、呼処理ステップ)。
呼処理部24による呼処理が完了すると、ユーザCに係るCSNの通信状態が“状態2”に状態遷移される。呼処理部24によって行われた呼処理の結果の情報(“状態2”に状態遷移された呼情報)は、呼処理部24から呼処理結果格納部25に出力される。
続いて、呼処理結果格納部25によって、動的ステート情報更新要求が呼処理管理用データベース10に送信される(S64、呼処理結果格納ステップ)。ここで送信される動的ステート情報更新要求は、自ノードにおける呼処理が終了して、ユーザCにおける呼処理の状態を状態遷移中から何れの呼処理サーバ20においても呼処理が実行中でない状態に移行した旨を通知する信号である。動的ステート情報更新要求は、ユーザCのユーザ識別子とCSN1aのノードIDとが含まれる。
また、呼処理の結果が反映された呼情報が、呼処理結果格納部25から呼処理管理用データベース10に呼情報更新要求として送信される(S65、呼処理結果格納ステップ)。なお、呼情報更新要求と動的ステート情報更新要求とは同一の信号によって行われてもよいし、別々の信号によって行われてもよい。
呼処理管理用データベース10では、動的ステート情報更新要求及び呼情報更新要求が受信される。呼処理管理用データベース10では、図12(a)に示すように、動的ステート情報更新要求に基づいて、管理されているユーザCに係るCSNの呼状態が“状態遷移中”から“状態2”にされる。ユーザCの呼状態(ステート情報)が更新されると呼処理管理用データベース10からCSN1aに更新完了通知が送信される(S65)。
また、呼処理管理用データベース10では、呼情報更新要求に基づいて、ユーザCに係る情報が受信した情報で更新される。即ち、更新後の呼情報は“状態2”である旨の情報を含む。更新が行われると、呼情報更新応答が呼処理管理用データベース10からCSN1aに送信される(S65)。なお、更新完了通知と呼情報更新応答とは同一の信号によって行われてもよいし、別々の信号によって行われてもよい。
CSN1aでは、呼情報更新応答が受信されると、発信応答に係る信号がP−CSCF1に送信される(S66)。送信された発信応答は、オープンフローネットワーク30の所定のノード31(CSN1aと接続されているノード31)によって受信される。当該ノード31によって、フローエントリに基づいて、要求先(送信先)のP−CSCF1(P−CSCF1b)が決定される。続いて、当該ノード31からP−CSCF1bに発信応答が送信される(S66、制御ステップ)。
発信応答が送信されたP−CSCF1bでは、呼処理要求受付部21によって発信応答が受信される(S66、呼処理要求受付ステップ)。呼処理要求受付部21によって受け付けられた発信応答の情報は呼処理部24に出力される。
P−CSCF1bでは、呼処理部24によって、入力された発信応答と、S04における処理で用いた情報とに基づいて、発信応答(発信要求)に係る呼処理が実行される(S67、呼処理ステップ)。
呼処理部24による呼処理が完了すると、ユーザCに係るP−CSCFの通信状態が“状態2”に状態遷移される。呼処理部24によって行われた呼処理の結果の情報(“状態2”に状態遷移された呼情報)は、呼処理部24から呼処理結果格納部25に出力される。
続いて、呼処理結果格納部25によって、動的ステート情報更新要求が呼処理管理用データベース10に送信される(S68、呼処理結果格納ステップ)。ここで送信される動的ステート情報更新要求は、自ノードにおける呼処理が終了して、ユーザCにおける呼処理の状態を状態遷移中から何れの呼処理サーバ20においても呼処理が実行中でない状態に移行した旨を通知する信号である。動的ステート情報更新要求は、ユーザCのユーザ識別子とP−CSCF1bのノードIDとが含まれる。
また、呼処理の結果が反映された呼情報が、呼処理結果格納部25から呼処理管理用データベース10に呼情報更新要求として送信される(S68、呼処理結果格納ステップ)。なお、呼情報更新要求と動的ステート情報更新要求とは同一の信号によって行われてもよいし、別々の信号によって行われてもよい。
呼処理管理用データベース10では、動的ステート情報更新要求及び呼情報更新要求が受信される。呼処理管理用データベース10では、図12(b)に示すように、動的ステート情報更新要求に基づいて、管理されているユーザCに係るP−CSCFの呼状態が“状態遷移中”から“状態2”にされる。ユーザCの呼状態(ステート情報)が更新されると呼処理管理用データベース10からP−CSCF1bに更新完了通知が送信される(S69)。
また、呼処理管理用データベース10では、呼情報更新要求に基づいて、ユーザCに係る情報が受信した情報で更新される。即ち、更新後の呼情報は“状態2”である旨の情報を含む。更新が行われると、呼情報更新応答が呼処理管理用データベース10からP−CSCF1bに送信される(S69)。なお、更新完了通知と呼情報更新応答とは同一の信号によって行われてもよいし、別々の信号によって行われてもよい。
P−CSCF1bでは、呼情報更新応答が受信されると、発信応答に係る信号がP−GWに送信される(S70)。また、発信応答に係る信号は、P−GWからユーザCに送信される。以上の処理により、ユーザCは発信中状態(“状態2”)となり、呼情報に含まれるユーザCの通信状態(移動体通信網で管理されるユーザCの通信状態)も発信中状態(“状態2”)に状態遷移される。
以上が、ユーザCから別の端末への発信等の呼処理の要求があり、その呼処理の途中で呼処理サーバ20が減設された場合の処理である。上記は、発信の際の処理であったが、その他の呼処理についても上述したように同様に行われる。
上述したように本実施形態に係る移動体通信システム1では、呼処理ノードである呼処理サーバ20と別構成となっている呼処理管理用データベース10において、呼処理に必要な移動通信端末50毎のデータが保持されており、呼処理が行われる毎にその情報が参照されて新たに格納される。従って、本移動体通信システム1では、どの移動通信端末50に係る呼処理でも、任意の呼処理サーバ20によって実行されえる。そして、本移動体通信システム1では、移動通信端末50毎に呼処理を行う呼処理ノードが決まっておらず、呼処理の要求毎にネットワークマネージャ40によって決定される呼処理サーバ20で呼処理が行われることとすることができる。
なお、従来の移動体通信システムでは、在圏処理等によって移動通信端末の呼処理を行う呼処理サーバが一旦決まると、その呼処理サーバにおいて当該移動通信端末に呼処理に必要な情報であるステート情報が保持されるため、他の呼処理サーバに呼処理を代替させることができなかった。従って、従来の移動体通信システムでは、上述したように呼処理サーバをact/sby構成とした冗長化を図っていた。
上記のように本移動体通信システム1では、個々の呼処理サーバ20がsby系あるいはact系と設定されるものではなく任意の呼処理サーバ20によって呼処理が実行できるため、より経済的な呼処理ノードの冗長化を可能にしている。また、何れかの呼処理サーバ20が動作していれば呼処理が可能となるため、より確実な呼処理サーバ20の冗長化を可能にしている。また、個々の呼処理サーバ20が呼処理に必要な移動通信端末50毎のデータを保持しないのでスケールアウトも容易に実現することが可能となる。
より具体的には、上述したように個々の呼処理サーバ20の故障の際に切替が可能になる。また、呼処理サーバ20の故障(突発停止)だけでなく計画停止の際にも容易に切替が可能になる。また、呼処理サーバ20をスケールアウトする際に、位置登録処理等を契機とせずに容易に増設した呼処理サーバ20にユーザを移すことができる。従来の移動体通信システムでは、上述したように既に在圏している移動通信端末を別の呼処理サーバに移すことが難しかったため、呼処理サーバを増設しても徐々にしかユーザを移すことができなかった。
更に、本実施形態に係る移動体通信システム1では、呼処理管理用データベース10に呼処理を実行中の呼処理サーバ20が登録される。呼処理を実行中の呼処理サーバ20とは別の呼処理サーバ20(図5の例におけるCSN1b、図9の例におけるCSN1a)によって呼処理の要求が受け付けられた場合、呼処理を実行中の呼処理サーバ20として登録されている他の呼処理サーバ20(図5の例におけるCSN1a、図9の例におけるCSN1b)から呼処理の要求に係る移動通信端末50の情報(呼処理の状態遷移中の情報)が取得される。
従って、もし、呼処理の途中で呼処理を行う呼処理サーバ20が変更されたとしても、呼処理サーバ20間で呼処理の要求に係る移動通信端末50の情報が引き継がれるため、変更後の呼処理サーバ20において、変更前の呼処理サーバ20で取得された情報を再送制御による処理救済等で改めて取得する必要がない。従って、呼処理の途中で呼処理を行う呼処理サーバ20が変更されたとしても、効率的な処理を行うことが可能となる。より具体的には、上述したように、仮想化サーバを用いた呼処理サーバ20の増設及び減設時において、通信中呼が切断されることなく、別の呼処理サーバ20に処理を引き継ぐことができる。このように、本移動体通信システム1によれば、優れた確実性、経済性、柔軟性を有する呼処理ノードの冗長化が可能となる。
また、本実施形態のようにオープンフローネットワークを利用することとしてもよい。この構成によれば、呼処理サーバ20が位置登録エリアに対応付けられたものではなくなるため、位置登録エリア等によらない呼処理サーバ20の冗長化が可能となるため、本発明による上記の効果をより大きいものとすることができる。但し、呼処理サーバが位置登録エリアに対応付けられている態様で本発明で実施することができる。その場合、位置登録エリア内での、優れた確実性、経済性、柔軟性を有する呼処理サーバの冗長化が実現できる。