JP2013232864A - 移動体通信システム、呼処理ノード及び通信制御方法 - Google Patents

Abstract

【課題】 優れた確実性、経済性、柔軟性を有する呼処理ノードの冗長化を可能とする。
【解決手段】 移動体通信システム１は、複数の呼処理サーバ２０と、呼処理に必要なデータを保持する呼処理管理用データベース１０と、呼処理サーバ２０の状態に応じて呼処理を行う呼処理サーバ２０を制御するネットワークマネージャ４０とを含んで構成される。呼処理サーバ２０は、呼処理の要求を受け付ける呼処理要求受付部２１と、呼処理を実行中の呼処理サーバ２０として自ノードを登録する登録部２２と、呼処理の要求に係る移動通信端末５０の情報を呼処理管理用データベース１０、又は呼処理を実行中の呼処理サーバ２０として登録されている呼処理サーバ２０から情報を取得する取得部２３と、呼処理を行う呼処理部２４と、呼処理の結果の情報を呼処理管理用データベース１０に格納する呼処理結果格納部２５とを備える。
【選択図】 図１

Description

本発明は、移動体通信システム、当該移動体通信システムに含まれる呼処理ノード、及びそれらによる通信制御方法に関する。

移動体通信システムにおいて、呼処理を行う呼処理ノードがメンテナンス等の目的で計画停止したり、障害の発生等によって突発停止したりする。移動体通信システムの呼処理システムでは、上記の何れの場合にも通信呼が切断されない冗長性が求められている。そのため、運用系の呼処理ノード（ａｃｔ）と待機系の呼処理ノード（ｓｂｙ）とを設け、装置の冗長化（多重化）を行うことがおこなわれている（例えば、特許文献１参照）。

特開２００３−２４４１９１号公報

現在は各ノード単位の高可用ミドルウェアと通信アプリケーションの作り込みによって、ａｃｔ／ｓｂｙ間でリアルタイムに状態を同期することで上記の装置の多重化が行われている。従って、ａｃｔ／ｓｂｙ構成のサーバのペアは固定的に割り当てられており、呼処理ノード内のサーバ同士でしか組めない。そのため、災害時には通信ビルの被災等により、ａｃｔ／ｓｂｙが同時に使用できなくなり、冗長化が機能しない場合がある。上記のように二重化構成においてｓｂｙ系装置を複数のａｃｔ系装置で共用することができず、単純に２倍の設備量を持つことから、経済性が悪い。

また、呼処理ノードは、当該装置が収容するユーザの呼処理のみを行うため、ある呼処理ノードが障害になると、その装置が収容していたユーザの通信ができなくなる。特に移動体通信においては、特定地域にユーザが集まることで、ユーザが偏って収容されることが発生しえる。

また、呼処理ノードをスケールアウトして性能向上を行う場合、通信中ユーザを増設した呼処理ノードへ移動する手段がなかった。移動機電源オフ／オン等を契機とした位置登録処理（アタッチ処理）により新設サーバへユーザを移す等の手法を取らざるをえないため、スケールアウトに長い時間かかかる。

本発明は、上記の問題点に鑑みてなされたものであり、優れた確実性、経済性、柔軟性を有する呼処理ノードの冗長化を可能とする移動体通信システム、呼処理ノード及び通信制御方法を提供することを目的とする。

上記の目的を達成するために、本発明に係る移動体通信システムは、移動通信端末に移動体通信の機能を提供すると共に複数の呼処理ノードと、当該複数の呼処理ノードそれぞれと接続されており、呼処理に必要な当該移動通信端末毎のデータを保持する呼処理管理用データベースと、制御ノードとを含んで構成される移動体通信システムであって、制御ノードは、複数の呼処理ノードの状態を把握するノード状態把握手段と、ノード状態把握手段によって把握された複数の呼処理ノードの状態に基づいて、移動通信端末から呼処理の要求を処理する呼処理ノードを決定して決定した呼処理ノードによって当該呼処理の要求が処理されるように制御する制御手段と、を備え、呼処理ノードは、制御ノードの制御を受けた呼処理の要求を受け付ける呼処理要求受付手段と、呼処理要求受付手段によって呼処理の要求が受け付けられると、呼処理の要求に係る移動通信端末に対する呼処理を実行中の呼処理ノードとして自ノードを呼処理管理用データベースに登録する登録手段と、呼処理要求受付手段によって受け付けられた呼処理の要求に係る移動通信端末の情報を呼処理管理用データベースから取得すると共に呼処理管理用データベースに当該移動通信端末に対する呼処理を実行中の呼処理ノードとして登録されている呼処理ノードから呼処理の要求に係る移動通信端末の情報を取得する取得手段と、取得手段によって取得された情報を用いて当該要求に係る呼処理を行う呼処理手段と、呼処理手段によって行われた呼処理の結果の情報を呼処理管理用データベースに格納すると共に呼処理手段によって行われた呼処理が終了したら当該呼処理の要求に係る移動通信端末に対する呼処理を実行中の呼処理ノードとしての呼処理管理用データベースに対する登録を終了させる呼処理結果格納手段と、を備える。

本発明に係る移動体通信システムでは、呼処理ノードと別構成となっている呼処理管理用データベースにおいて、呼処理に必要な移動通信端末毎のデータが保持されており、呼処理が行われる毎にその情報が参照されて新たに格納される。従って、本移動体通信システムでは、どの移動通信端末に係る呼処理でも、任意の呼処理ノードによって実行されえる。そして、本移動体通信システムでは、移動通信端末毎に呼処理を行う呼処理ノードが決まっておらず、呼処理の要求毎に制御ノードによって決定される呼処理ノードで呼処理が行われるようにすることができる。

上記のように本発明に係る移動体通信システムでは、個々の呼処理ノードがｓｂｙ系あるいはａｃｔ系と設定されるものではなく任意の呼処理ノードによって呼処理が実行できるため、より経済的な呼処理ノードの冗長化を可能にしている。また、何れかの呼処理ノードが動作していれば呼処理が可能となるため、より確実な呼処理ノードの冗長化を可能にしている。また、個々の呼処理ノードが呼処理に必要な移動通信端末毎のデータを保持しないのでスケールアウトも容易に実現することが可能となる。

更に、本発明に係る移動体通信システムでは、呼処理管理用データベースに呼処理を実行中の呼処理ノードが登録される。呼処理を実行中の呼処理ノードとは別の呼処理ノードによって呼処理の要求が受け付けられた場合、呼処理を実行中の呼処理ノードとして登録されている他の呼処理ノードから呼処理の要求に係る移動通信端末の情報（呼処理の状態遷移中の情報）が取得される。従って、もし、呼処理の途中で呼処理を行う呼処理ノードが変更されたとしても、呼処理ノード間で呼処理の要求に係る移動通信端末の情報が引き継がれるため、変更後の呼処理ノードにおいて、変更前の呼処理ノードで取得された情報を再送制御による処理救済等で改めて取得する必要がない。従って、呼処理の途中で呼処理を行う呼処理ノードが変更されたとしても、効率的な処理を行うことが可能となる。このように、本移動体通信システムによれば、優れた確実性、経済性、柔軟性を有する呼処理ノードの冗長化が可能となる。

呼処理ノードは、仮想化された仮想マシンによって構成され、制御ノードは、ノード状態把握手段によって把握された複数の呼処理ノードの状態に基づいて、仮想化の制御を行う仮想化制御手段を、更に備えることとしてもよい。この構成によれば、呼処理ノードの状態に応じて、適切な仮想化を行うことができる。

移動体通信システムは、フロー制御ネットワークを更に含み、制御手段は、決定した呼処理ノードによって当該呼処理の要求が処理されるようにフロー制御ネットワークを設定することとしてもよい。この構成によれば、位置登録エリア等によらない呼処理ノードの冗長化が可能となるため、本発明による上記の効果をより大きいものとすることができる。

上記の移動体通信システムに含まれる呼処理ノードは、それら自体が新規な構成を有しており発明に相当する。即ち、本発明に係る呼処理ノードは、移動通信端末に移動体通信の機能を提供すると共に複数の呼処理ノードと、当該複数の呼処理ノードそれぞれと接続されており、呼処理に必要な当該移動通信端末毎のデータを保持する呼処理管理用データベースと、制御ノードとを含んで構成される移動体通信システムにおける呼処理ノードであって、制御ノードの制御を受けた呼処理の要求を受け付ける呼処理要求受付手段と、呼処理要求受付手段によって呼処理の要求が受け付けられると、呼処理の要求に係る移動通信端末に対する呼処理を実行中の呼処理ノードとして自ノードを呼処理管理用データベースに登録する登録手段と、呼処理要求受付手段によって受け付けられた呼処理の要求に係る移動通信端末の情報を呼処理管理用データベースから取得すると共に呼処理管理用データベースに当該移動通信端末に対する呼処理を実行中の呼処理ノードとして登録されている呼処理ノードから呼処理の要求に係る移動通信端末の情報を取得する取得手段と、取得手段によって取得された情報を用いて当該要求に係る呼処理を行う呼処理手段と、呼処理手段によって行われた呼処理の結果の情報を呼処理管理用データベースに格納すると共に呼処理手段によって行われた呼処理が終了したら当該呼処理の要求に係る移動通信端末に対する呼処理を実行中の呼処理ノードとしての呼処理管理用データベースに対する登録を終了させる呼処理結果格納手段と、を備える。

ところで、本発明は、上記のように移動体通信システム及び呼処理ノードの発明として記述できる他に、以下のように通信制御方法の発明としても記述することができる。これはカテゴリが異なるだけで、実質的に同一の発明であり、同様の作用及び効果を奏する。

即ち、本発明に係る通信制御方法は、移動通信端末に移動体通信の機能を提供すると共に複数の呼処理ノードと、当該複数の呼処理ノードそれぞれと接続されており、呼処理に必要な当該移動通信端末毎のデータを保持する呼処理管理用データベースと、制御ノードとを含んで構成される移動体通信システムによる通信制御方法であって、制御ノードが、複数の呼処理ノードの状態を把握するノード状態把握ステップと、ノード状態把握ステップにおいて把握された複数の呼処理ノードの状態に基づいて、移動通信端末から呼処理の要求を処理する呼処理ノードを決定して決定した呼処理ノードによって当該呼処理の要求が処理されるように制御する制御ステップと、呼処理ノードが、制御ノードの制御を受けた呼処理の要求を受け付ける呼処理要求受付ステップと、呼処理要求受付ステップにおいて呼処理の要求が受け付けられると、呼処理の要求に係る移動通信端末に対する呼処理を実行中の呼処理ノードとして自ノードを呼処理管理用データベースに登録する登録ステップと、呼処理要求受付ステップにおいて受け付けられた呼処理の要求に係る移動通信端末の情報を呼処理管理用データベースから取得すると共に呼処理管理用データベースに当該移動通信端末に対する呼処理を実行中の呼処理ノードとして登録されている呼処理ノードから呼処理の要求に係る移動通信端末の情報を取得する取得ステップと、取得ステップにおいて取得された情報を用いて当該要求に係る呼処理を行う呼処理ステップと、呼処理ステップにおいて行われた呼処理の結果の情報を呼処理管理用データベースに格納すると共に呼処理手段によって行われた呼処理が終了したら当該呼処理の要求に係る移動通信端末に対する呼処理を実行中の呼処理ノードとしての呼処理管理用データベースに対する登録を終了させる呼処理結果格納ステップと、を含む。

また、本発明に係る通信制御方法は、移動通信端末に移動体通信の機能を提供すると共に複数の呼処理ノードと、当該複数の呼処理ノードそれぞれと接続されており、呼処理に必要な当該移動通信端末毎のデータを保持する呼処理管理用データベースと、制御ノードとを含んで構成される移動体通信システムにおける呼処理ノードによる通信制御方法であって、制御ノードの制御を受けた呼処理の要求を受け付ける呼処理要求受付ステップと、呼処理要求受付ステップにおいて呼処理の要求が受け付けられると、呼処理の要求に係る移動通信端末に対する呼処理を実行中の呼処理ノードとして自ノードを呼処理管理用データベースに登録する登録ステップと、呼処理要求受付ステップにおいて受け付けられた呼処理の要求に係る移動通信端末の情報を呼処理管理用データベースから取得すると共に呼処理管理用データベースに当該移動通信端末に対する呼処理を実行中の呼処理ノードとして登録されている呼処理ノードから呼処理の要求に係る移動通信端末の情報を取得する取得ステップと、取得ステップにおいて取得された情報を用いて当該要求に係る呼処理を行う呼処理ステップと、呼処理ステップにおいて行われた呼処理の結果の情報を呼処理管理用データベースに格納すると共に呼処理手段によって行われた呼処理が終了したら当該呼処理の要求に係る移動通信端末に対する呼処理を実行中の呼処理ノードとしての呼処理管理用データベースに対する登録を終了させる呼処理結果格納ステップと、を含む。

本発明では、個々の呼処理ノードがｓｂｙ系あるいはａｃｔ系と設定されるものではなく任意の呼処理ノードによって呼処理が実行できるため、より経済的な呼処理ノードの冗長化を可能にしている。また、何れかの呼処理ノードが動作していれば呼処理が可能となるため、より確実な呼処理ノードの冗長化を可能にしている。また、個々の呼処理ノードが呼処理に必要な移動通信端末毎のデータを保持しないのでスケールアウトも容易に実現することが可能となる。

更に、本発明では、もし、呼処理の途中で呼処理を行う呼処理ノードが変更されたとしても、呼処理ノード間で呼処理の要求に係る移動通信端末の情報が引き継がれるため、変更後の呼処理ノードにおいて、変更前の呼処理ノードで取得された情報を再送制御による処理救済等で改めて取得する必要がない。従って、呼処理の途中で呼処理を行う呼処理ノードが変更されたとしても、効率的な処理を行うことが可能となる。このように、本発明によれば、優れた確実性、経済性、柔軟性を有する呼処理ノードの冗長化が可能となる。

本発明の実施形態に係る移動体通信システムの構成、及び移動体通信システムを構成する装置の機能構成を示す図である。 呼処理サーバで保持されるデータを示す図である。 詳細な呼処理サーバ、及び呼処理管理用データベースに格納される情報の一部を示す図である。 本発明の実施形態に係る移動体通信システムを構成する装置のハードウェア構成を示す図である。 本発明の実施形態に係る移動体通信システムで、呼処理サーバの増設が行われる時に実行される処理（通信制御方法）を示すシーケンス図である。 呼処理サーバの増設が行われる時に実行される処理における、詳細な呼処理サーバ、及び呼処理管理用データベースに格納される情報の一部を示す図である。 呼処理サーバの増設が行われる時に実行される処理における、詳細な呼処理サーバ、及び呼処理管理用データベースに格納される情報の一部を示す図である。 呼処理サーバの増設が行われる時に実行される処理における、詳細な呼処理サーバ、及び呼処理管理用データベースに格納される情報の一部を示す図である。 本発明の実施形態に係る移動体通信システムで、呼処理サーバの減設が行われる時に実行される処理（通信制御方法）を示すシーケンス図である。 呼処理サーバの減設が行われる時に実行される処理における、詳細な呼処理サーバ、及び呼処理管理用データベースに格納される情報の一部を示す図である。 呼処理サーバの減設が行われる時に実行される処理における、詳細な呼処理サーバ、及び呼処理管理用データベースに格納される情報の一部を示す図である。 呼処理サーバの減設が行われる時に実行される処理における、詳細な呼処理サーバ、及び呼処理管理用データベースに格納される情報の一部を示す図である。

以下、図面と共に本発明に係る移動体通信システム、呼処理ノード及び通信制御方法の実施形態について詳細に説明する。なお、図面の説明においては同一要素には同一符号を付し、重複する説明を省略する。

図１に本実施形態に係る移動体通信システム１の構成を示す。移動体通信システム１は、移動通信端末（移動機）５０に移動体通信の機能を提供するシステムである。移動通信端末５０は、ユーザにより用いられて移動体通信システム（移動体通信網）に無線通信によって接続して移動体通信を行う装置である。具体的には、移動通信端末５０は、携帯電話機等に相当する。移動通信端末５０は、例えば、移動体通信システム１を介して対向ノード６０との間で呼接続を確立して通信を行う。対向ノード６０は、例えば、別の移動通信端末や移動通信端末５０に様々なサービスを提供するサーバ装置、あるいは他の通信網に接続するための装置（例えば、ＧＧＳＮ（Gateway GPRS Support Node））等に相当する。移動通信端末５０は、移動通信端末５０のユーザが移動体通信システム１の通信事業者と契約することによって移動体通信を行うことが可能になる。なお、移動通信端末５０は、従来の移動通信端末と同様のものでよい。

図１に示すように、移動体通信システム１は、呼処理管理用データベース１０と、複数の呼処理サーバ２０と、オープンフローネットワーク３０と、ネットワークマネージャ４０とを含んで構成されている。なお、これらの構成１０，２０，３０，４０は、移動体通信システム１（移動体通信網）のコアネットワークを構成するものである。

呼処理管理用データベース１０は、呼処理に必要なデータを保持するデータベースである。呼処理管理用データベース１０は、このデータを、例えば、移動通信端末５０を特定する情報に対応付けて、移動通信端末５０毎に保持する。呼処理に必要なデータとしては、具体的には呼処理の状態を示すステート情報や移動通信端末５０に係る加入者プロファイルを保持する。ステート情報としては、移動通信端末５０の在圏エリアや、移動通信端末５０が通信中であるか待受中であるかの情報（静的ステート情報）である。この情報は、後述するように呼処理サーバ２０によって読み出されると共に更新（書き込み）される。呼処理管理用データベース１０は、更に本実施形態に係る動的ステート情報を保持する。動的ステート情報は、静的ステート情報と合わせてより詳細に後述する。

また、加入者プロファイルのデータとしては、移動通信端末５０の電話番号、認証情報、契約速度等の情報がある。これらの情報は、移動通信端末５０のユーザが移動体通信システム１の通信事業者と契約した時に呼処理管理用データベース１０に加入者プロファイルとして新たに記憶（生成）される。これらの情報は、呼処理サーバ２０によって読み出されるが呼処理サーバ２０による更新（書き込み）はなされない。なお、移動通信端末５０毎に記憶されるデータには、このように読み出し（Ｒｅａｄ）と書き込み（Ｗｒｉｔｅ）の両方が発生する項目と読み出し（Ｒｅａｄ）のみ発生する項目とがある。呼処理管理用データベース１０において、これらの項目のレコードを分けて管理することで、Ｗｒｉｔｅの同期待ちでＲｅａｄが遅延することを防止するように工夫することができる。

呼処理管理用データベース１０は、複数の呼処理サーバ２０それぞれと接続されており、呼処理サーバ２０によって、呼処理管理用データベース１０が保持するデータの参照や登録、更新が行われる。呼処理管理用データベース１０は、データベースとして任意の構成をとることができるが、呼処理に必要なデータを保持することを考慮して、図１に示すように、複数のサーバ装置で実現される分散データベースとし、ＳＰＯＦ（Single Point of Failure）が無いように構成することが望ましい。

ここで呼処理とは、移動体通信システム１を介して移動通信端末５０と対向ノード６０との呼接続に係る処理である。例えば、移動通信端末５０と対向ノード６０との間の呼接続（通信セッション接続とも呼ばれる）を確立する処理、あるいは切断する処理等である。また、移動体通信システム１に在圏するための処理、即ち、位置登録の処理も本実施形態における呼処理に含むこととしてもよい。

呼処理サーバ２０は、移動体通信システム１において呼処理を行う呼処理ノードである。呼処理サーバ２０は、図１に示すようにオープンフローネットワーク３０を介して、移動通信端末５０及び対向ノード６０と接続されており、移動通信端末５０からの要求等に応じて呼処理を行う。呼処理サーバ２０は、図２に示すようにＨＷ（ハードウェア）層、ＯＳ（オペレーティングシステム）層及びＡＰＬ（アプリケーション）層の機能によって実現される。また、後述の障害時やスケールアウト時の処理を容易にするため、仮想サーバとして実装してもよい。

図２に示すように、ＡＰＬ層では、呼情報、一時的な情報、プログラムがメモリ上に記憶される。呼情報は、呼処理に必要なデータであり、呼の状態遷移を保持するステート情報や加入者プロファイルである。ステート情報には、静的なステート情報（静的ステート情報）と動的なステート情報（動的ステート情報）とが含まれる。静的ステート情報は、例えば、待受中、発信中、通信中等の移動通信端末５０の通信状態（呼状態）を示す情報である。動的ステート情報は、実行中の呼処理に係る情報であり、例えば、最終更新日時や呼処理を行っている呼処理サーバ２０を特定する情報である更新ノードＩＤ（例えば、呼処理サーバ２０の一つであるＰ−ＣＳＣＦのＩＰアドレス）である。

呼情報は、呼処理管理用データベース１０から情報を取得する等して、呼処理の際のみに保持される。なお、呼情報は、呼処理後にも、キャッシュとして処理の効率化のために呼処理サーバ２０において保持されていてもよいが、呼処理サーバ２０は呼情報についての責任は持たない。一時的な情報は、呼処理（信号シーケンス）の途中で用いられる一時的な情報（位置登録、発信等のシーケンス途中の情報）である。例えば、待受中から通信中へ変わる過渡的な状態で用いられるテンポラリ情報である。この一時的な情報は、後述するように呼処理サーバ２０間で送受信される。プログラムは、呼処理サーバ２０の機能を実現するための実行コードそのもの（実行バイナリの情報）である。

移動体通信システム１には、複数の呼処理サーバ２０が含まれる。図１に示すように、災害により何れかの呼処理サーバ２０が故障する場合等を考慮して、複数の拠点（データセンタ等の場所）２を設け、それぞれの拠点２に１つ以上の呼処理サーバ２０を設けるようにすることが望ましい。呼処理サーバ２０は、望ましくはサーバ装置に仮想マシン技術を利用して、仮想化された仮想サーバとして実現される。なお、本実施形態では、呼処理ノードは仮想マシンとして説明するが、個々のサーバ装置による仮想マシンでない呼処理サーバとして実現されてもよい。呼処理サーバ２０は、従来の移動体通信システムでは例えば、ＳＧＳＮ（Serving GPRS Support Node）やＣＳＣＦ（Call SessionControl Function）、ＡＳ（Application Server）等のノードに相当する。

あるいは、ＩＭＳ（IP Multimedia Subsystem）では、図３に示すように、呼処理サーバ２０は、Ｐ−ＣＳＣＦ（Proxy- Call Session Control Function）、ＣＳＮ（CallSession control Node）及びＡＳＮ（Application Serving Node）である。移動体通信システム１に含まれるＰ−ＧＷ（Packet Data Network Gateway）から呼処理に係る信号がＰ−ＣＳＣＦに入力され、図３に示すように呼処理がＰ−ＣＳＣＦ、ＣＳＮ及びＡＳＮにおいて順次、行われる。本実施形態では、呼処理サーバ２０として、Ｐ−ＣＳＣＦ、ＣＳＮ及びＡＳＮを例に説明する。なお、本実施形態に係るＰ−ＣＳＣＦ、ＣＳＮ及びＡＳＮは、既存のＰ−ＣＳＣＦ、ＣＳＮ及びＡＳＮの機能に加えて、後述する本実施形態に係る機能を有する。

オープンフローネットワーク３０は、呼処理サーバ２０、移動通信端末５０及び対向ノード６０とそれぞれ接続されており、それらの装置の間の通信路を構成するフロー制御ネットワークである。なお、通常、オープンフローネットワーク３０と移動通信端末５０とは、基地局（ＢＴＳ）や無線制御装置（ＲＮＣ）を介して接続されている。オープンフローネットワーク３０は、互いに接続されているオープンフロースイッチである複数のノード３１によって構成されている。ノード３１は、通常オープンフローネットワークのオープンフロースイッチとして用いられる装置に相当する。後述するように、オープンフローネットワーク３０は、ネットワークマネージャ４０のオープンフローコントローラからの制御を受けて情報の送受信を行う。具体的には、オープンフローネットワーク３０の各ノード３１が、自身が受信した情報をどのノードに送信するかを示すフローエントリを、ネットワークマネージャ４０から受信して当該フローエントリに従った情報の送受信を行う。本説明では、オープンフローネットワークとして説明を行うが、ＳＤＮ（Softwarer difined network）と呼ばれる、同様のフロー制御とその制御に従ってフロー転送処理を行うネットワークでもよい。

ネットワークマネージャ４０は、オープンフローネットワーク３０における情報の送受信を制御する制御ノードである。制御は、例えば、ネットワークマネージャ４０が備える、負荷分散制御を行うオープンフローコントローラによって行われる。具体的にどのような制御を行うかについては後述する。ネットワークマネージャ４０は、呼処理サーバ２０のそれぞれと接続されており、情報の送受信を行うことができる。

引き続いて、ネットワークマネージャ４０及び呼処理サーバ２０の本実施形態に係る機能についてより詳細に説明する。図１に示すようにネットワークマネージャ４０は、ノード状態把握部４１と、制御部４２とを備えて構成される。また、呼処理サーバを仮想化して仮想マシンによって構成されることとした場合、ネットワークマネージャ４０は、仮想化された呼処理サーバ（仮想呼処理サーバ）の制御を行う仮想マシン制御部（図示せず）を、更に備えることとしてもよい。この制御によって、具体的には、仮想呼処理サーバのプロビジョニングが行われる。

ノード状態把握部４１は、複数の呼処理サーバ２０の状態を把握するノード状態把握手段である。まず、ノード状態把握部４１は、どの呼処理サーバ２０があるかを把握する。これは例えば、呼処理サーバ２０が、スケールアウト等のために新たに設置された場合に呼処理サーバ２０から新たに設置された旨の情報を受信することによって行われる。また、ノード状態把握部４１は、呼処理サーバ２０の状態として、それぞれのサーバの負荷や、故障が発生していないか否かの情報を把握する。これらの情報は、例えば、定期的なノード状態把握部４１からの問い合わせによって、あるいは、ノード状態把握部４１からの自発的な送信によって、呼処理サーバ２０からの情報を受信することによってノード状態把握部４１で把握される。ノード状態把握部４１は、把握した各呼処理サーバ２０の状態を示す情報を制御部４２に出力する。

制御部４２は、ノード状態把握部４１によって把握された複数の各呼処理サーバ２０の状態に基づいて、移動通信端末５０から呼処理の要求を処理する呼処理サーバ２０を決定して（割り当てして）決定した呼処理サーバ２０によって当該呼処理の要求が処理されるように制御する制御手段である。具体的には、制御部４２は、決定した呼処理サーバ２０によって当該呼処理の要求が処理されるようにオープンフローネットワーク３０を設定する。

制御部４２は、各呼処理サーバ２０の状態に基づいて、呼処理を制御する呼処理サーバ２０を決定する。例えば、故障している呼処理サーバ２０や一定の閾値以上の処理負荷がかかっている呼処理サーバ２０が、呼処理を処理する呼処理サーバ２０とならないように呼処理を処理する呼処理サーバ２０を決定する。また、呼処理サーバ２０間で、処理負荷がなるべく均一になるように呼処理を処理する呼処理サーバ２０を決定することとしてもよい。なお、呼処理を行う呼処理サーバ２０は、移動通信端末５０に応じて決定されてもよい。どのように呼処理を処理する呼処理サーバ２０を決定するかの基準（実施シナリオ）については、例えば、移動体通信システム１の通信事業者が予め制御部４２に記憶させておく。

制御部４２は、移動通信端末５０からの呼処理の要求が決定した呼処理サーバ２０に送信されるようにフローエントリを生成して、生成したフローエントリをオープンフローネットワーク３０の各ノード３１に送信する。

呼処理を処理する呼処理サーバ２０の決定、及びフローエントリの生成は、例えば、一定期間毎（例えば、特定の時刻毎）や、呼処理サーバ２０の状態が変更した場合（例えば、呼処理サーバ２０が故障や処理輻輳、保守作業等で停止する場合）等に行われることとすればよい。

なお、オープンフローネットワーク３０は、呼処理サーバ２０間にも設けられており、呼処理サーバ間（例えば、Ｐ−ＣＳＣＦとＣＳＮとの間やＣＳＮとＡＳＮとの間）における信号の送信先の制御も上述したように行う。

仮想マシン制御部は、呼処理サーバを仮想化した場合に、ノード状態把握部４１によって把握された複数の各呼処理サーバ２０の状態に基づいて、当該仮想化を制御する仮想化制御手段である。これは例えば、呼処理サーバ２０を、各呼処理サーバ２０の状態に応じてスケールアウト等のために増設したい場合に、仮想マシン制御部がＨｙｐｅｒｖｉｓｏｒに指示を送ることによって、仮想呼処理サーバ２０を新たにプロビジョニングさせる等の制御である。これによって、呼処理サーバ２０の状態に応じて、適切な仮想化を行うことができる。より具体的には、仮想マシン制御部による仮想マシンのプロビジョニングを統合制御することで（処理を同調させることで）、以下に説明するように更に適切なスケールアウト処理や、障害時処理が可能となる。

呼処理サーバ２０は、呼処理要求受付部２１と、登録部２２と、取得部２３と、呼処理部２４と、呼処理結果格納部２５とを備えて構成される。

呼処理要求受付部２１は、ネットワークマネージャ４０の制御を受けてオープンフローネットワーク３０から自ノード２０に送信された、呼処理の要求を受け付ける（受信する）呼処理要求受付手段である。呼処理の要求は、発信要求（呼接続確立の要求）や位置登録要求である。呼処理要求受付部２１は、受信した呼処理の要求を登録部２２、取得部２３及び呼処理部２４に出力する。

登録部２２は、呼処理要求受付部２１から呼処理の要求が入力されると、呼処理の要求に係る移動通信端末５０に対する呼処理を実行中の呼処理サーバ２０として自ノードを呼処理管理用データベース１０に登録する登録手段である。

図３に示すように、呼処理管理用データベース１０は、移動通信端末５０を特定する情報であるユーザ識別子に対応付けて、呼処理サーバ２０の種類毎の呼処理の状態を示す情報（Ｋｅｙ−Ｖａｌｕｅストア（ＫＶＳ））を保持する。呼処理サーバ２０の種類とは、Ｐ−ＣＳＣＦ、ＣＳＮ及びＡＳＮ等の種類である。呼処理の状態を示す情報とは、静的ステート情報と動的ステート情報である。これらの情報を参照することによって、当該移動通信端末５０に関してその種類の呼処理サーバ２０の何れかにおいて呼処理が実行中であるか否かを判断することができる。呼処理が実行中でない状態は、例えば、図３に示す“状態１”、“状態２”等の状態である。呼処理が実行中である（呼状態が遷移中である）状態は、例えば、図３に示す「状態遷移中」等の状態）である。なお、図３に示す凡例は、以降の図でも同様である。

動的ステート情報には、当該移動通信端末５０に関して呼処理を実行している呼処理サーバ２０を特定する情報である更新ノードＩＤ（例えば、呼処理サーバ２０のＩＰアドレス）が含まれる。図３に示すユーザ識別子が“Ｃ”である移動通信端末５０の情報の例では、ＡＳＮに係る呼処理の状態（ＡＳＮ状態）は“状態１（例えば、待受状態）”、ＣＳＮに係る呼処理の状態（ＡＳＮ状態）は“状態１”、Ｐ−ＣＳＣＦに係る呼処理の状態（Ｐ−ＣＳＣＦ状態）は“状態遷移中”である。また、Ｐ−ＣＳＣＦ状態を示す情報には、呼処理を実行している呼処理サーバ２０の更新ノードＩＤとして、Ｐ−ＣＳＣＦ１ｂのノードＩＤが含まれている。

登録部２２は、呼処理要求受付部２１から呼処理の要求が入力されると、当該要求から要求元の移動通信端末５０を特定する。例えば、呼処理の要求が、ユーザ識別子が“Ｃ”である移動通信端末５０から対抗ノードへの発信要求（ユーザＣからユーザＸへの発信要求）であった場合には、登録部２２は、ユーザ識別子が“Ｃ”である移動通信端末５０を、呼処理の要求元の移動通信端末５０として特定する。登録部２２は、特定したユーザ識別子と自ノードのノードＩＤとを含めた動的ステート情報更新要求を呼処理管理用データベース１０に送信する。呼処理管理用データベース１０は、動的ステート情報更新要求を受信して、受信した動的ステート情報更新要求に基づいて、ユーザ識別子に対応付けられた呼処理の状態を示す情報を、ユーザ識別子をキーとして更新（登録）する。この登録によって、当該移動通信端末５０の状態が、呼処理が実行中であるという状態（状態遷移中）となる。

取得部２３は、呼処理要求受付部２１によって受け付けられた呼処理の要求に係る移動通信端末５０の情報を呼処理管理用データベース１０から取得する取得手段である。取得部２３は、呼処理の要求に含まれる、当該呼処理の要求元である移動通信端末５０を特定する情報を抽出して、当該移動通信端末５０に係る情報を送信するように呼処理管理用データベース１０に対して要求する。ここで要求する情報は、図２に示す呼情報であり、具体的には上述したように電話番号、認証情報、契約速度、在圏エリア、通信中／待受中の情報である。なお、自ノード２０において移動通信端末５０に係る呼処理を行っており、自ノード２０に有効な呼情報のキャッシュが残っている場合には、キャッシュの最終更新時刻が、呼処理管理用データベース１０の最終更新時刻より古くなければ、取得部２３による取得が行われなくてもよい。取得部２３は、呼処理管理用データベース１０から取得した情報を呼処理部２４に出力する。

また、取得部２３は、自ノードと同じ種類で自ノード以外の別の呼処理サーバ２０が、呼処理の要求元である移動通信端末５０に対する呼処理を実行中である場合には、当該別の呼処理サーバ２０から呼処理のための情報を取得して、呼処理を引き継いで実行する。呼処理管理用データベース１０に呼処理の要求元である移動通信端末５０のユーザ識別子に対応付けられて保持された、自ノードと同じ種類の呼処理の状態を示す情報が、自ノード以外の別の呼処理サーバ２０において呼処理が実行中であることを示すものであった場合、取得部２３は、当該別の呼処理サーバ２０を特定する情報である更新ノードＩＤを取得する。

この取得は、例えば、取得部２３によって、呼処理管理用データベース１０に格納された、呼処理の要求元である移動通信端末５０が状態遷移中であるという情報（フラグ）が参照されておこなわれる。あるいは、登録部２２による呼処理管理用データベース１０への自ノードの登録の際に、自ノード以外の別の呼処理サーバ２０が呼処理の要求に係る移動通信端末５０に対する呼処理を実行中の呼処理サーバ２０として登録されていた場合、呼処理管理用データベース１０がその別の呼処理サーバ２０のサーバの更新ノードＩＤを送信することによって行われてもよい。

取得部２３は、当該別の呼処理サーバ２０から呼処理の要求に係る移動通信端末５０の情報を取得する。この情報の取得は、当該別の呼処理サーバ２０に移動通信端末５０の情報の同期を要求することによって行われる。ここで取得される情報は、呼処理（信号シーケンス）の途中で用いられる一時的な情報（位置登録、発信等のシーケンス途中の情報）であり、呼処理管理用データベース１０には登録されない情報である。

なお、別の呼処理サーバ２０から情報を取得して呼処理を引き継ぐ場合、別の呼処理サーバ２０から取得した情報だけで呼処理を継続できる場合には、呼処理管理用データベース１０から必ずしも情報を取得する必要はない。取得部２３は、別の呼処理サーバ２０から取得した情報を呼処理部２４に出力する。

なお、呼処理の途中で呼処理を実行する呼処理サーバ２０が変更するのは、呼処理サーバ２０の増設、減設、あるいはその他の原因によって、呼処理が実行されている間にオープンフローネットワーク３０によって信号の経路の変更が行われてしまうためである。本実施形態の構成は、このように呼処理が実行されている間にオープンフローネットワーク３０によって信号の経路の変更が行われた場合であっても、変更前の呼処理サーバ２０で取得された情報を再送制御による処理救済等で改めて取得せずに呼処理を継続できるようにするためのものである。

呼処理部２４は、取得部２３によって取得された情報を用いて当該要求に係る呼処理を行う呼処理手段である。具体的には、呼接続の確立や切断、あるいは位置登録の処理（在圏エリアの登録又は更新の処理）を行う。別の呼処理サーバ２０から呼処理のための情報を取得した場合には、呼処理部２４は、当該別の呼処理サーバ２０が行っていた呼処理を引き継いだ処理を行う。呼処理部２４は、呼処理の結果の情報を呼処理結果格納部２５に出力する。

呼処理結果格納部２５は、呼処理部２４によって行われた呼処理の結果の情報を呼処理管理用データベース１０に格納する呼処理結果格納手段である。具体的には、呼処理結果格納部２５は、呼処理によって更新された、移動通信端末５０の在圏エリアや、移動通信端末５０が通信中であるか待受中であるかの情報である。これらの情報は、当該移動通信端末５０に係る次の呼処理に必要な情報である。呼処理結果格納部２５による呼処理管理用データベース１０への情報の格納は、呼情報（ステート情報）に変更が生じた場合のみに行われることとしてもよい。呼処理結果格納部２５による呼処理管理用データベース１０への情報の格納が行われた場合、最終更新時刻を現在時刻にアップデートする。

呼処理結果格納部２５は、呼処理部２４によって行われた呼処理が終了したら当該呼処理の要求に係る移動通信端末５０に対する呼処理を実行中の呼処理サーバ２０としての呼処理管理用データベース１０に対する登録を終了させる。呼処理結果格納部２５は、呼処理管理用データベース１０に自ノードにおける呼処理が終了して、当該移動通信端末５０における自ノードの種類の呼処理の状態を状態遷移中から何れの呼処理サーバ２０においても呼処理が実行中でない状態に移行した旨を通知する。なお、この通知は、呼処理の結果の格納と合わせて行われてもよい。呼処理管理用データベース１０は、この通知を受け取り、通知に基づき当該移動通信端末５０における情報を更新する。以上が、ネットワークマネージャ４０及び呼処理サーバ２０の本実施形態に係る機能である。

図４に本実施形態に係る呼処理管理用データベース１０、呼処理サーバ２０、オープンフローネットワーク３０のノード３１及びネットワークマネージャ４０を構成するサーバ装置のハードウェア構成を示す。図４に示すように当該サーバ装置は、ＣＰＵ１０１、主記憶装置であるＲＡＭ（Random Access Memory）１０２及びＲＯＭ（Read OnlyMemory）１０３、通信を行うための通信モジュール１０４、並びにハードディスク等の補助記憶装置１０５等のハードウェアを備えるコンピュータを含むものとして構成される。これらの構成要素がプログラム等により動作することにより、上述した各ノード１０，２０，３１，４０の機能が発揮される。以上が、移動体通信システム１の構成である。

引き続いて、図５及び図９のシーケンス図、図６〜図８及び図１０〜図１２の図を用いて、本実施形態に係る移動体通信システム１で実行される処理である通信制御方法を説明する。まず、図５のシーケンス図及び図６〜図８を用いて、ユーザ識別子が“Ｃ”である移動通信端末５０から別の端末への発信等の呼処理の要求があり、その呼処理の途中で呼処理サーバ２０が増設されてスケールアウトされた場合の処理について説明する。本処理では、ＣＳＮが増設される例について説明する。また、図３に示すように呼処理サーバとして、Ｐ−ＣＳＣＦ、ＣＳＮ及びＡＳＮが設けられている例について説明する。

呼処理サーバ（Ｐ−ＣＳＣＦ１、ＣＳＮ１、ＡＳＮ１）２０は、それぞれユーザ識別子が“Ａ”、“Ｂ”、“Ｃ”及び“Ｄ”である移動通信端末５０（以降、それぞれユーザＡ，Ｂ，Ｃ，Ｄと呼ぶ）を収容している。本実施形態においては、ユーザを収容しているとは、当該ユーザに係る呼処理の信号がオープンフローネットワーク３０によって、それぞれの呼処理サーバ２０に振り分けられて処理することを言う。但し、呼処理の信号は、ユーザに応じて特定の呼処理サーバ２０に振り分けられる必要はなく、信号の中継時点でオープンフローネットワーク３０によってフローエントリに基づいて振り分け先が判断されてもよい。

Ｐ−ＣＳＣＦ１ａはユーザＡ，Ｂを、Ｐ−ＣＳＣＦ１ｂはユーザＣ，Ｄを、ＣＳＮ１ａはユーザＡ，Ｂ，Ｃ，Ｄを、ＡＳＮ１ａはユーザＡ，Ｂを、ＡＳＮ１ｂはユーザＣ，Ｄをそれぞれ収容している。本処理の初期状態では、図６（ａ）に示すように、何れのユーザの呼処理の状態も、呼処理が実行中でない状態である、例えば、待受状態である“状態１”となっている。上記のように本処理では、ユーザＣに着目する。図５のシーケンス図には、呼処理管理用データベース１０で保持されるユーザＣの情報（図３に示す情報と同様の情報）を示す。

移動体通信システム１では、ネットワークマネージャ４０のノード状態把握部４１によって、各呼処理サーバ２０の状態の把握が行われている。各呼処理サーバ２０の状態を示す情報は、ノード状態把握部４１から制御部４２に出力される。続いて、制御部４２によって、各呼処理サーバ２０の状態を示す情報に基づいて呼処理を行う呼処理サーバ２０が決定されて、決定された呼処理サーバ２０に呼処理の要求が送信されるようにフローエントリが生成されている。生成されたフローエントリは、オープンフローネットワーク３０の各ノード３１に送信されている。オープンフローネットワーク３０の各ノード３１では、当該フローエントリが受信されて、当該フローエントリに基づいてフロー（呼処理の要求等の信号）の送信が行われる。なお、図５においては、オープンフローネットワーク３０の図示を省略する。

本処理では、まず、ユーザＣから移動体通信システム１（移動体通信網）に対して発信要求が行われる。発信要求は、別の端末（例えば、ユーザＸ）と通信を行うための呼接続の要求である。当該発信要求に係る信号（発信信号）は、Ｐ−ＧＷに受信される。

続いて、発信信号は、Ｐ-ＧＷからＰ−ＣＳＣＦ１に対して送信される。送信された発信信号は、オープンフローネットワーク３０の所定のノード３１（Ｐ-ＧＷと接続されているノード３１）によって受信される。当該ノード３１によって、フローエントリに基づいて、要求先（送信先）のＰ−ＣＳＣＦ１（Ｐ−ＣＳＣＦ１ｂ）が決定される。続いて、当該ノード３１からＰ−ＣＳＣＦ１ｂに発信信号が送信される（Ｓ０１、制御ステップ）。

発信信号が送信されたＰ−ＣＳＣＦ１ｂでは、呼処理要求受付部２１によって発信信号が受信される（Ｓ０１、呼処理要求受付ステップ）。呼処理要求受付部２１によって受け付けられた発信要求の情報は、登録部２２、取得部２３及び呼処理部２４に出力される。Ｐ−ＣＳＣＦ１ｂでは、登録部２２によって、当該発信信号に基づいて動的ステート情報更新要求が呼処理管理用データベース１０に送信される（Ｓ０２、登録ステップ）。動的ステート情報更新要求は、当該発信信号に係る呼処理の要求元のユーザＣに対する呼処理を実行中のＰ−ＣＳＣＦとして自ノードを呼処理管理用データベース１０に登録する信号である。動的ステート情報更新要求は、ユーザＣのユーザ識別子とＰ−ＣＳＣＦ１ｂのノードＩＤとが含まれる。なお、動的ステート情報の更新や参照（ＫＶＳの更新、参照）は、呼処理サーバ２０に移動通信端末５０の情報のキャッシュがある場合でも行われる（以下についても同様である）。

なお、Ｐ−ＣＳＣＦ１ｂでは、呼処理に必要なユーザＣのデータ、即ち、呼処理の状態を示すステート情報やユーザＣに係る加入者プロファイルを含む呼情報を保持していない。

そこで、Ｐ−ＣＳＣＦ１ｂでは、動的ステート情報更新要求の送信と合わせて、取得部２３から呼処理管理用データベース１０に対して、発信要求を行ったユーザＣに係る呼情報を要求する呼情報取得要求が行われる（Ｓ０２、取得ステップ）。動的ステート情報更新要求と呼情報取得要求とは同一の信号によって行われてもよいし、別々の信号によって行われてもよい。

呼処理管理用データベース１０では、動的ステート情報更新要求及び呼情報取得要求が受信される。呼処理管理用データベース１０では、図６（ｂ）に示すように、動的ステート情報更新要求に基づいて、管理されているユーザＣに係るＰ−ＣＳＣＦの呼状態が“状態１”から“状態遷移中”にされる。また、ユーザＣに対する呼処理を実行中のＰ−ＣＳＣＦとしてＰ−ＣＳＣＦ１ｂが登録される。ユーザＣの呼状態（ステート情報）が更新されると呼処理管理用データベース１０からＰ−ＣＳＣＦ１ｂに更新完了通知が送信される（Ｓ０３）。

また、呼処理管理用データベース１０では、呼情報取得要求に基づいて、ユーザＣに係る呼情報が読み出されて、呼処理管理用データベース１０からＰ−ＣＳＣＦ１ｂに呼情報取得応答として送信される（Ｓ０３）。更新完了通知と呼情報取得応答とは同一の信号によって行われてもよいし、別々の信号によって行われてもよい。

Ｐ−ＣＳＣＦ１ｂでは、取得部２３によって呼情報が受信される（Ｓ０３、取得ステップ）。ここで取得される呼情報は、待受中である旨の情報を含む呼情報である。これにより、Ｐ−ＣＳＣＦ１ｂは、呼処理の状態を示すステート情報やユーザＣに係る加入者プロファイルを含む呼情報を保持した状態となる。受信された呼情報は、取得部２３から呼処理部２４に出力される。

続いて、呼処理部２４によって、取得部２３によって取得された呼情報に基づいて、発信要求に係る呼処理が実行される（Ｓ０４、呼処理ステップ）。ここでの呼処理は呼接続を確立するための発信処理であり、他のサーバとの間で呼接続を確立する発信シーケンスに沿って処理が行われる。呼処理中の情報は、上述した一時的な情報として保持されている。

続いて、当該呼処理の一つとして、発信信号が、呼処理部２４からＣＳＮ１に対して送信される。送信された発信信号は、オープンフローネットワーク３０の所定のノード３１（Ｐ−ＣＳＣＦ１ｂと接続されているノード３１）によって受信される。当該ノード３１によって、フローエントリに基づいて、要求先（送信先）のＣＳＮ１（ＣＳＮ１ａ）が決定される。続いて、当該ノード３１からＣＳＮ１ａに発信信号が送信される（Ｓ０５、制御ステップ）。

発信信号が送信されたＣＳＮ１ａでは、呼処理要求受付部２１によって発信信号が受信される（Ｓ０５、呼処理要求受付ステップ）。呼処理要求受付部２１によって受け付けられた発信要求の情報は、登録部２２、取得部２３及び呼処理部２４に出力される。ＣＳＮ１ａでは、登録部２２によって、当該発信信号に基づいて動的ステート情報更新要求が呼処理管理用データベース１０に送信される（Ｓ０６、登録ステップ）。動的ステート情報更新要求は、当該発信信号に係る呼処理の要求元のユーザＣに対する呼処理を実行中のＣＳＮとして自ノードを呼処理管理用データベース１０に登録する信号である。動的ステート情報更新要求は、ユーザＣのユーザ識別子とＣＳＮ１ａのノードＩＤとが含まれる。

なお、ＣＳＮ１ａでは、呼処理に必要なユーザＣのデータ、即ち、呼処理の状態を示すステート情報やユーザＣに係る加入者プロファイルを含む呼情報を保持していない。

そこで、ＣＳＮ１ａでは、動的ステート情報更新要求の送信と合わせて、取得部２３から呼処理管理用データベース１０に対して、発信要求を行ったユーザＣに係る呼情報を要求する呼情報取得要求が行われる（Ｓ０６、取得ステップ）。動的ステート情報更新要求と呼情報取得要求とは同一の信号によって行われてもよいし、別々の信号によって行われてもよい。

呼処理管理用データベース１０では、動的ステート情報更新要求及び呼情報取得要求が受信される。呼処理管理用データベース１０では、図６（ｃ）に示すように、動的ステート情報更新要求に基づいて、管理されているユーザＣに係るＣＳＮの呼状態が“状態１”から“状態遷移中”にされる。また、ユーザＣに対する呼処理を実行中のＣＳＮとしてＣＳＮ１ａが登録される。ユーザＣの呼状態（ステート情報）が更新されると呼処理管理用データベース１０からＣＳＮ１ａに更新完了通知が送信される（Ｓ０７）。

また、呼処理管理用データベース１０では、呼情報取得要求に基づいて、ユーザＣに係る呼情報が読み出されて、呼処理管理用データベース１０からＣＳＮ１ａに呼情報取得応答として送信される（Ｓ０７）。更新完了通知と呼情報取得応答とは同一の信号によって行われてもよいし、別々の信号によって行われてもよい。

ＣＳＮ１ａでは、取得部２３によって呼情報が受信される（Ｓ０７、取得ステップ）。ここで取得される呼情報は、待受中である旨の情報を含む呼情報である。これにより、ＣＳＮ１ａは、呼処理の状態を示すステート情報やユーザＣに係る加入者プロファイルを含む呼情報を保持した状態となる。受信された呼情報は、取得部２３から呼処理部２４に出力される。

続いて、呼処理部２４によって、取得部２３によって取得された呼情報に基づいて、発信要求に係る呼処理が実行される（Ｓ０８、呼処理ステップ）。ここでの呼処理は呼接続を確立するための発信処理であり、他のサーバとの間で呼接続を確立する発信シーケンスに沿って処理が行われる。呼処理中の情報は、上述した一時的な情報として保持されている。

続いて、当該呼処理の一つとして、発信信号が、呼処理部２４からＡＳＮ１に対して送信される。送信された発信信号は、オープンフローネットワーク３０の所定のノード３１（ＣＳＮ１ａと接続されているノード３１）によって受信される。当該ノード３１によって、フローエントリに基づいて、要求先（送信先）のＡＳＮ１（ＡＳＮ１ｂ）が決定される。続いて、当該ノード３１からＡＳＮ１ｂに発信信号が送信される（Ｓ０９、制御ステップ）。

発信信号が送信されたＡＳＮ１ｂでは、呼処理要求受付部２１によって発信信号が受信される（Ｓ０９、呼処理要求受付ステップ）。呼処理要求受付部２１によって受け付けられた発信要求の情報は、登録部２２、取得部２３及び呼処理部２４に出力される。ＡＳＮ１ｂでは、登録部２２によって、当該発信信号に基づいて動的ステート情報更新要求が呼処理管理用データベース１０に送信される（Ｓ１０、登録ステップ）。動的ステート情報更新要求は、当該発信信号に係る呼処理の要求元のユーザＣに対する呼処理を実行中のＡＳＮとして自ノードを呼処理管理用データベース１０に登録する信号である。動的ステート情報更新要求は、ユーザＣのユーザ識別子とＡＳＮ１ｂのノードＩＤとが含まれる。

なお、ＡＳＮ１ｂでは、呼処理に必要なユーザＣのデータ、即ち、呼処理の状態を示すステート情報やユーザＣに係る加入者プロファイルを含む呼情報を保持していない。

そこで、ＡＳＮ１ｂでは、動的ステート情報更新要求の送信と合わせて、取得部２３から呼処理管理用データベース１０に対して、発信要求を行ったユーザＣに係る呼情報を要求する呼情報取得要求が行われる（Ｓ１０、取得ステップ）。動的ステート情報更新要求と呼情報取得要求とは同一の信号によって行われてもよいし、別々の信号によって行われてもよい。

呼処理管理用データベース１０では、動的ステート情報更新要求及び呼情報取得要求が受信される。呼処理管理用データベース１０では、図６（ｄ）に示すように、動的ステート情報更新要求に基づいて、管理されているユーザＣに係るＡＳＮの呼状態が“状態１”から“状態遷移中”にされる。また、ユーザＣに対する呼処理を実行中のＡＳＮとしてＡＳＮ１ｂが登録される。ユーザＣの呼状態（ステート情報）が更新されると呼処理管理用データベース１０からＡＳＮ１ｂに更新完了通知が送信される（Ｓ１１）。

また、呼処理管理用データベース１０では、呼情報取得要求に基づいて、ユーザＣに係る呼情報が読み出されて、呼処理管理用データベース１０からＡＳＮ１ｂに呼情報取得応答として送信される（Ｓ１１）。更新完了通知と呼情報取得応答とは同一の信号によって行われてもよいし、別々の信号によって行われてもよい。

ＡＳＮ１ｂでは、取得部２３によって呼情報が受信される（Ｓ１１、取得ステップ）。ここで取得される呼情報は、待受中である旨の情報を含む呼情報である。これにより、ＡＳＮ１ｂは、呼処理の状態を示すステート情報やユーザＣに係る加入者プロファイルを含む呼情報を保持した状態となる。受信された呼情報は、取得部２３から呼処理部２４に出力される。

続いて、呼処理部２４によって、取得部２３によって取得された呼情報に基づいて、発信要求に係る呼処理が実行される（Ｓ１２、呼処理ステップ）。ここでの呼処理は呼接続を確立するための発信処理であり、他のサーバとの間で呼接続を確立する発信シーケンスに沿って処理が行われる。

ここで（Ｓ０９以降、Ｓ１８以前のタイミングで）、ＣＳＮ１の負荷を分散させるために、ＣＳＮ１ｂが増設される（Ｓ１３）。この増設は、例えば、移動体通信システム１の通信事業者によって行われる。移動体通信システム１では、ネットワークマネージャ４０のノード状態把握部４１によって、各呼処理サーバ２０の状態の把握が行われる（Ｓ１４、ノード状態把握ステップ）。このとき、ノード状態把握部４１によって、ＣＳＮ１ｂの増設も把握される。各呼処理サーバ２０の状態を示す情報は、ノード状態把握部４１から制御部４２に出力される。

呼処理サーバ２０が仮想化されていた場合には、Ｓ１３は以下のような処理にすることができる。即ち、例えば輻輳等によって呼処理サーバ２０の処理能力不足をノード状態把握部４１が把握し、制御部４２に通知する。制御部４２は仮想マシン制御部へ呼処理サーバ２０の追加を指示する。仮想マシン制御部は、呼処理サーバ２０を新たにプロビジョニングする。

続いて、制御部４２によって、各呼処理サーバ２０の状態を示す情報に基づいて呼処理を行う呼処理サーバ２０が決定されて、決定された呼処理サーバ２０に呼処理の要求が送信されるようにフローエントリが生成される（Ｓ１５、制御ステップ）。ここでは、ＣＳＮ１ｂが新たに増設されたので、ここで生成されるフローエントリは、呼処理を行う呼処理サーバ２０として、新たに増設されたＣＳＮ１ｂを含むものとされたものとなる。例えば、図７（ａ）に示すように、ユーザＣ，Ｄに係る呼処理はＣＳＮ１ｂによって実行されるものとして（ユーザＣ，ＤがＣＳＮ１ｂに収容されるものとして）フローエントリが生成される。

生成されたフローエントリは、オープンフローネットワーク３０の各ノード３１に送信される（Ｓ１５、制御ステップ）。オープンフローネットワーク３０の各ノード３１では、当該フローエントリが受信されて、当該フローエントリに基づいてフロー（呼処理の要求等の信号）の送信が行われる。

ＡＳＮ１ｂでは、呼処理部２４による呼処理が完了すると、ユーザＣに係るＡＳＮの通信状態が、例えば発信中状態である“状態２”に状態遷移される。呼処理部２４によって行われた呼処理の結果の情報（“状態２”に状態遷移された呼情報）は、呼処理部２４から呼処理結果格納部２５に出力される。

続いて、呼処理結果格納部２５によって、動的ステート情報更新要求が呼処理管理用データベース１０に送信される（Ｓ１６、呼処理結果格納ステップ）。ここで送信される動的ステート情報更新要求は、自ノードにおける呼処理が終了して、ユーザＣにおける呼処理の状態を状態遷移中から何れの呼処理サーバ２０においても呼処理が実行中でない状態に移行した旨を通知する信号である。動的ステート情報更新要求は、ユーザＣのユーザ識別子とＡＳＮ１ｂのノードＩＤとが含まれる。

また、呼処理の結果が反映された呼情報が、呼処理結果格納部２５から呼処理管理用データベース１０に呼情報更新要求として送信される（Ｓ１６、呼処理結果格納ステップ）。なお、呼情報更新要求と動的ステート情報更新要求とは同一の信号によって行われてもよいし、別々の信号によって行われてもよい。

呼処理管理用データベース１０では、動的ステート情報更新要求及び呼情報更新要求が受信される。呼処理管理用データベース１０では、図７（ｂ）に示すように、動的ステート情報更新要求に基づいて、管理されているユーザＣに係るＡＳＮの呼状態が“状態遷移中”から“状態２”にされる。ユーザＣの呼状態（ステート情報）が更新されると呼処理管理用データベース１０からＡＳＮ１ｂに更新完了通知が送信される（Ｓ１７）。

また、呼処理管理用データベース１０では、呼情報更新要求に基づいて、ユーザＣに係る情報が受信した情報で更新される。即ち、更新後の呼情報は“状態２”である旨の情報を含む。更新が行われると、呼情報更新応答が呼処理管理用データベース１０からＡＳＮ１ｂに送信される（Ｓ１７）。なお、更新完了通知と呼情報更新応答とは同一の信号によって行われてもよいし、別々の信号によって行われてもよい。

ＡＳＮ１ｂでは、呼情報更新応答が受信されると、発信応答に係る信号がＣＳＮ１に送信される（Ｓ１８）。送信された発信応答は、オープンフローネットワーク３０の所定のノード３１（ＡＳＮ１ｂと接続されているノード３１）によって受信される。当該ノード３１によって、フローエントリに基づいて、要求先（送信先）のＣＳＮ１（ＣＮＳ１ｂ）が決定される。上述したように、フローエントリは、ユーザＣの呼処理を行うＣＳＮは増設されたＣＳＮ１ｂとされている。続いて、当該ノード３１からＣＳＮ１ｂに発信応答が送信される（Ｓ１８、制御ステップ）。

発信応答が送信されたＣＳＮ１ｂでは、呼処理要求受付部２１によって発信応答が受信される（Ｓ１８、呼処理要求受付ステップ）。呼処理要求受付部２１によって受け付けられた発信応答の情報は、登録部２２、取得部２３及び呼処理部２４に出力される。

ＣＳＮ１ｂは、今までユーザＣの呼処理を行っていた呼処理サーバ２０ではないのでユーザＣに係る情報を保持していない。まず、ＣＳＮ１ｂでは、登録部２２によって、当該発信応答に基づいて動的ステート情報取得要求が呼処理管理用データベース１０に送信される（Ｓ１９、登録ステップ）。動的ステート情報取得要求は、当該発信応答に係る呼処理の要求元のユーザＣに対する呼処理を実行中のＣＳＮとして登録されているＣＳＮのノードＩＤを要求する信号（ユーザＣのＣＮＳに関する状態がどうなっているかを問い合わせる信号）である。また、動的ステート情報取得要求は、当該発信応答に係る呼処理の要求元のユーザＣに対する呼処理を実行中のＣＳＮとして自ノードを呼処理管理用データベース１０に登録する信号でもある。動的ステート情報更新要求は、ユーザＣのユーザ識別子とＣＳＮ１ｂのノードＩＤとが含まれる。

呼処理管理用データベース１０では、動的ステート情報取得要求が受信される。呼処理管理用データベース１０では、動的ステート情報取得要求に対する応答として、ユーザＣに対する呼処理を実行中のＣＳＮとして登録されているＣＳＮのノードＩＤ（ＣＳＮ１ａのノードＩＤ）（ＣＳＮ１ａがＳ０６で登録した情報）をＣＳＮ１ｂに送信する（Ｓ２０）。また、呼処理管理用データベース１０では、図７（ｃ）に示すように、動的ステート情報取得要求に基づいて、ユーザＣに対する呼処理を実行中のＣＳＮとしてＣＳＮ１ｂが登録される。なお、ユーザＣに係るＣＳＮの呼状態は“状態遷移中”のままである。ユーザＣの呼状態（ステート情報）が更新されると呼処理管理用データベース１０からＣＳＮ１ｂに更新完了通知が送信される（Ｓ２０）。なお、動的ステート情報取得要求に対する応答と更新完了通知とは同一の信号によって行われてもよいし、別々の信号によって行われてもよい。

ＣＳＮ１ｂでは、図７（ｄ）に示すように、取得部２３によって、呼処理管理用データベース１０から送信された、ユーザＣに対する呼処理を実行中のＣＳＮとして登録されているＣＳＮのノードＩＤによって示されるＣＳＮ１ａとの間でユーザＣに関して呼処理を実行するための情報が同期される。情報の同期は、ＣＳＮ１ｂの取得部２３からＣＳＮ１ａに対して同期の要求が行われて（Ｓ２１）、ＣＳＮ１ａから当該要求に応じて送信された情報の受信が行われる（Ｓ２２）ことで行われる。

ここで、ＣＳＮ１ａからＣＳＮ１ｂに送信されるユーザＣに係る情報には、呼処理の途中で用いられる一時的な情報が含まれる。また、当該情報には、ＣＳＮ１ａが呼処理管理用データベース１０から取得された呼処理の状態を示すステート情報やユーザＣに係る加入者プロファイルを含む呼情報が含まれていてもよい。但し、呼処理管理用データベース１０から取得可能な情報は、ＣＳＮ１ａから取得せずに呼処理管理用データベース１０から取得してもよい。このように取得部２３によって取得された、ユーザＣに係る呼処理を継続するための情報は取得部２３から呼処理部２４に出力される。

続いて、呼処理部２４によって、取得部２３によって取得された呼情報に基づいて、発信応答（発信要求）に係る呼処理が実行される（Ｓ２３、呼処理ステップ）。

呼処理部２４による呼処理が完了すると、ユーザＣに係るＣＳＮの通信状態が“状態２”に状態遷移される。呼処理部２４によって行われた呼処理の結果の情報（“状態２”に状態遷移された呼情報）は、呼処理部２４から呼処理結果格納部２５に出力される。

続いて、呼処理結果格納部２５によって、動的ステート情報更新要求が呼処理管理用データベース１０に送信される（Ｓ２４、呼処理結果格納ステップ）。ここで送信される動的ステート情報更新要求は、自ノードにおける呼処理が終了して、ユーザＣにおける呼処理の状態を状態遷移中から何れの呼処理サーバ２０においても呼処理が実行中でない状態に移行した旨を通知する信号である。動的ステート情報更新要求は、ユーザＣのユーザ識別子とＣＳＮ１ｂのノードＩＤとが含まれる。

また、呼処理の結果が反映された呼情報が、呼処理結果格納部２５から呼処理管理用データベース１０に呼情報更新要求として送信される（Ｓ２５、呼処理結果格納ステップ）。なお、呼情報更新要求と動的ステート情報更新要求とは同一の信号によって行われてもよいし、別々の信号によって行われてもよい。

呼処理管理用データベース１０では、動的ステート情報更新要求及び呼情報更新要求が受信される。呼処理管理用データベース１０では、図８（ａ）に示すように、動的ステート情報更新要求に基づいて、管理されているユーザＣに係るＣＳＮの呼状態が“状態遷移中”から“状態２”にされる。ユーザＣの呼状態（ステート情報）が更新されると呼処理管理用データベース１０からＣＳＮ１ｂに更新完了通知が送信される（Ｓ２５）。

また、呼処理管理用データベース１０では、呼情報更新要求に基づいて、ユーザＣに係る情報が受信した情報で更新される。即ち、更新後の呼情報は“状態２”である旨の情報を含む。更新が行われると、呼情報更新応答が呼処理管理用データベース１０からＣＳＮ１ｂに送信される（Ｓ２５）。なお、更新完了通知と呼情報更新応答とは同一の信号によって行われてもよいし、別々の信号によって行われてもよい。

ＣＳＮ１ｂでは、呼情報更新応答が受信されると、発信応答に係る信号がＰ−ＣＳＣＦ１に送信される（Ｓ２６）。送信された発信応答は、オープンフローネットワーク３０の所定のノード３１（ＣＳＮ１ｂと接続されているノード３１）によって受信される。当該ノード３１によって、フローエントリに基づいて、要求先（送信先）のＰ−ＣＳＣＦ１（Ｐ−ＣＳＣＦ１ｂ）が決定される。続いて、当該ノード３１からＰ−ＣＳＣＦ１ｂに発信応答が送信される（Ｓ２６、制御ステップ）。

発信応答が送信されたＰ−ＣＳＣＦ１ｂでは、呼処理要求受付部２１によって発信応答が受信される（Ｓ２６、呼処理要求受付ステップ）。呼処理要求受付部２１によって受け付けられた発信応答の情報は呼処理部２４に出力される。

Ｐ−ＣＳＣＦ１ｂでは、呼処理部２４によって、入力された発信応答と、Ｓ０４における処理で用いた情報とに基づいて、発信応答（発信要求）に係る呼処理が実行される（Ｓ２７、呼処理ステップ）。

呼処理部２４による呼処理が完了すると、ユーザＣに係るＰ−ＣＳＣＦの通信状態が“状態２”に状態遷移される。呼処理部２４によって行われた呼処理の結果の情報（“状態２”に状態遷移された呼情報）は、呼処理部２４から呼処理結果格納部２５に出力される。

続いて、呼処理結果格納部２５によって、動的ステート情報更新要求が呼処理管理用データベース１０に送信される（Ｓ２８、呼処理結果格納ステップ）。ここで送信される動的ステート情報更新要求は、自ノードにおける呼処理が終了して、ユーザＣにおける呼処理の状態を状態遷移中から何れの呼処理サーバ２０においても呼処理が実行中でない状態に移行した旨を通知する信号である。動的ステート情報更新要求は、ユーザＣのユーザ識別子とＰ−ＣＳＣＦ１ｂのノードＩＤとが含まれる。

また、呼処理の結果が反映された呼情報が、呼処理結果格納部２５から呼処理管理用データベース１０に呼情報更新要求として送信される（Ｓ２８、呼処理結果格納ステップ）。なお、呼情報更新要求と動的ステート情報更新要求とは同一の信号によって行われてもよいし、別々の信号によって行われてもよい。

呼処理管理用データベース１０では、動的ステート情報更新要求及び呼情報更新要求が受信される。呼処理管理用データベース１０では、図８（ｂ）に示すように、動的ステート情報更新要求に基づいて、管理されているユーザＣに係るＰ−ＣＳＣＦの呼状態が“状態遷移中”から“状態２”にされる。ユーザＣの呼状態（ステート情報）が更新されると呼処理管理用データベース１０からＰ−ＣＳＣＦ１ｂに更新完了通知が送信される（Ｓ２９）。

また、呼処理管理用データベース１０では、呼情報更新要求に基づいて、ユーザＣに係る情報が受信した情報で更新される。即ち、更新後の呼情報は“状態２”である旨の情報を含む。更新が行われると、呼情報更新応答が呼処理管理用データベース１０からＰ−ＣＳＣＦ１ｂに送信される（Ｓ２９）。なお、更新完了通知と呼情報更新応答とは同一の信号によって行われてもよいし、別々の信号によって行われてもよい。

Ｐ−ＣＳＣＦ１ｂでは、呼情報更新応答が受信されると、発信応答に係る信号がＰ−ＧＷに送信される（Ｓ３０）。また、発信応答に係る信号は、Ｐ−ＧＷからユーザＣに送信される。以上の処理により、ユーザＣは発信中状態（“状態２”）となり、呼情報に含まれるユーザＣの通信状態（移動体通信網で管理されるユーザＣの通信状態）も発信中状態（“状態２”）に状態遷移される。

以上が、ユーザ識別子が“Ｃ”である移動通信端末５０から別の端末への発信等の呼処理の要求があり、その呼処理の途中で呼処理サーバ２０が増設されてスケールアウトされた場合の処理である。上記は、発信の際の処理であったが、その他の呼処理についても同様に行われる。例えば、移動通信端末５０が位置登録を行う場合には、位置登録要求を受信した呼処理サーバ２０は、図５のＳ０２、Ｓ０３、Ｓ０６、Ｓ０７、Ｓ１０、Ｓ１１、Ｓ１９、Ｓ２０、Ｓ２１、Ｓ２２に相当する処理によって、当該移動通信端末５０が圏外、あるいは別の位置登録エリアに在圏している呼情報を取得する。そして、Ｓ０４、Ｓ０８、Ｓ１２、Ｓ２３、Ｓ２７に相当する処理によって位置登録処理を行う。そして、Ｓ１６、Ｓ１７、Ｓ２４、Ｓ２５、Ｓ２８、Ｓ２９に相当する処理によって、位置登録後（あるいは更新後）の位置登録エリアと、待受中の情報とを含む、当該移動通信端末５０に係る更新後の呼情報を呼処理管理用データベース１０に格納する。また、対向装置から呼接続の要求があった場合も、同様の処理を適用することができる。

引き続いて、図９のシーケンス図及び図１０〜図１２を用いて、ユーザＣから別の端末への発信等の呼処理の要求があり、その呼処理の途中で呼処理サーバ２０が減設された場合の処理について説明する。本処理では、ＣＳＮが減設される例について説明する。また、図３に示すように呼処理サーバとして、Ｐ−ＣＳＣＦ、ＣＳＮ及びＡＳＮが設けられている例について説明する。

呼処理サーバ（Ｐ−ＣＳＣＦ１、ＣＳＮ１、ＡＳＮ１）２０は、それぞれユーザＡ，Ｂ，Ｃ，Ｄを収容している。Ｐ−ＣＳＣＦ１ａはユーザＡ，Ｂを、Ｐ−ＣＳＣＦ１ｂはユーザＣ，Ｄを、ＣＳＮ１ａはユーザＡ，Ｂを、ＣＳＮ１ｂはユーザＣ，Ｄを、ＡＳＮ１ａはユーザＡ，Ｂを、ＡＳＮ１ｂはユーザＣ，Ｄをそれぞれ収容している。本処理の初期状態では、図１０（ａ）に示すように、何れのユーザの呼処理の状態も、呼処理が実行中でない状態である、例えば、待受状態である“状態１”となっている。上記のように本処理では、ユーザＣに着目する。図９のシーケンス図には、呼処理管理用データベース１０で保持されるユーザＣの情報（図３に示す情報と同様の情報）を示す。

移動体通信システム１では、ネットワークマネージャ４０のノード状態把握部４１によって、各呼処理サーバ２０の状態の把握が行われている。各呼処理サーバ２０の状態を示す情報は、ノード状態把握部４１から制御部４２に出力される。続いて、制御部４２によって、各呼処理サーバ２０の状態を示す情報に基づいて呼処理を行う呼処理サーバ２０が決定されて、決定された呼処理サーバ２０に呼処理の要求が送信されるようにフローエントリが生成されている。生成されたフローエントリは、オープンフローネットワーク３０の各ノード３１に送信されている。オープンフローネットワーク３０の各ノード３１では、当該フローエントリが受信されて、当該フローエントリに基づいてフロー（呼処理の要求等の信号）の送信が行われる。なお、図９においては、オープンフローネットワーク３０の図示を省略する。

本処理では、まず、ユーザＣから移動体通信システム１（移動体通信網）に対して発信要求が行われる。発信要求は、別の端末（例えば、ユーザＸ）と通信を行うための呼接続の要求である。当該発信要求に係る信号（発信信号）は、Ｐ−ＧＷに受信される。

続いて、発信信号は、Ｐ-ＧＷからＰ−ＣＳＣＦ１に対して送信される。送信された発信信号は、オープンフローネットワーク３０の所定のノード３１（Ｐ-ＧＷと接続されているノード３１）によって受信される。当該ノード３１によって、フローエントリに基づいて、要求先（送信先）のＰ−ＣＳＣＦ１（Ｐ−ＣＳＣＦ１ｂ）が決定される。続いて、当該ノード３１からＰ−ＣＳＣＦ１ｂに発信信号が送信される（Ｓ４１、制御ステップ）。

発信信号が送信されたＰ−ＣＳＣＦ１ｂでは、呼処理要求受付部２１によって発信信号が受信される（Ｓ４１、呼処理要求受付ステップ）。呼処理要求受付部２１によって受け付けられた発信要求の情報は、登録部２２、取得部２３及び呼処理部２４に出力される。Ｐ−ＣＳＣＦ１ｂでは、登録部２２によって、当該発信信号に基づいて動的ステート情報更新要求が呼処理管理用データベース１０に送信される（Ｓ４２、登録ステップ）。動的ステート情報更新要求は、当該発信信号に係る呼処理の要求元のユーザＣに対する呼処理を実行中のＰ−ＣＳＣＦとして自ノードを呼処理管理用データベース１０に登録する信号である。動的ステート情報更新要求は、ユーザＣのユーザ識別子とＰ−ＣＳＣＦ１ｂのノードＩＤとが含まれる。

なお、Ｐ−ＣＳＣＦ１ｂでは、呼処理に必要なユーザＣのデータ、即ち、呼処理の状態を示すステート情報やユーザＣに係る加入者プロファイルを含む呼情報を保持していない。

そこで、Ｐ−ＣＳＣＦ１ｂでは、動的ステート情報更新要求の送信と合わせて、取得部２３から呼処理管理用データベース１０に対して、発信要求を行ったユーザＣに係る呼情報を要求する呼情報取得要求が行われる（Ｓ４２、取得ステップ）。動的ステート情報更新要求と呼情報取得要求とは同一の信号によって行われてもよいし、別々の信号によって行われてもよい。

呼処理管理用データベース１０では、動的ステート情報更新要求及び呼情報取得要求が受信される。呼処理管理用データベース１０では、図１０（ｂ）に示すように、動的ステート情報更新要求に基づいて、管理されているユーザＣに係るＰ−ＣＳＣＦの呼状態が“状態１”から“状態遷移中”にされる。また、ユーザＣに対する呼処理を実行中のＰ−ＣＳＣＦとしてＰ−ＣＳＣＦ１ｂが登録される。ユーザＣの呼状態（ステート情報）が更新されると呼処理管理用データベース１０からＰ−ＣＳＣＦ１ｂに更新完了通知が送信される（Ｓ４３）。

また、呼処理管理用データベース１０では、呼情報取得要求に基づいて、ユーザＣに係る呼情報が読み出されて、呼処理管理用データベース１０からＰ−ＣＳＣＦ１ｂに呼情報取得応答として送信される（Ｓ４３）。更新完了通知と呼情報取得応答とは同一の信号によって行われてもよいし、別々の信号によって行われてもよい。

Ｐ−ＣＳＣＦ１ｂでは、取得部２３によって呼情報が受信される（Ｓ４３、取得ステップ）。ここで取得される呼情報は、待受中である旨の情報を含む呼情報である。これにより、Ｐ−ＣＳＣＦ１ｂは、呼処理の状態を示すステート情報やユーザＣに係る加入者プロファイルを含む呼情報を保持した状態となる。受信された呼情報は、取得部２３から呼処理部２４に出力される。

続いて、呼処理部２４によって、取得部２３によって取得された呼情報に基づいて、発信要求に係る呼処理が実行される（Ｓ４４、呼処理ステップ）。ここでの呼処理は呼接続を確立するための発信処理であり、他のサーバとの間で呼接続を確立する発信シーケンスに沿って処理が行われる。呼処理中の情報は、上述した一時的な情報として保持されている。

続いて、当該呼処理の一つとして、発信信号が、呼処理部２４からＣＳＮ１に対して送信される。送信された発信信号は、オープンフローネットワーク３０の所定のノード３１（Ｐ−ＣＳＣＦ１ｂと接続されているノード３１）によって受信される。当該ノード３１によって、フローエントリに基づいて、要求先（送信先）のＣＳＮ１（ＣＳＮ１ｂ）が決定される。続いて、当該ノード３１からＣＳＮ１ｂに発信信号が送信される（Ｓ４５、制御ステップ）。

発信信号が送信されたＣＳＮ１ｂでは、呼処理要求受付部２１によって発信信号が受信される（Ｓ４５、呼処理要求受付ステップ）。呼処理要求受付部２１によって受け付けられた発信要求の情報は、登録部２２、取得部２３及び呼処理部２４に出力される。ＣＳＮ１ｂでは、登録部２２によって、当該発信信号に基づいて動的ステート情報更新要求が呼処理管理用データベース１０に送信される（Ｓ４６、登録ステップ）。動的ステート情報更新要求は、当該発信信号に係る呼処理の要求元のユーザＣに対する呼処理を実行中のＣＳＮとして自ノードを呼処理管理用データベース１０に登録する信号である。動的ステート情報更新要求は、ユーザＣのユーザ識別子とＣＳＮ１ｂのノードＩＤとが含まれる。

なお、ＣＳＮ１ｂでは、呼処理に必要なユーザＣのデータ、即ち、呼処理の状態を示すステート情報やユーザＣに係る加入者プロファイルを含む呼情報を保持していない。

そこで、ＣＳＮ１ｂでは、動的ステート情報更新要求の送信と合わせて、取得部２３から呼処理管理用データベース１０に対して、発信要求を行ったユーザＣに係る呼情報を要求する呼情報取得要求が行われる（Ｓ４６、取得ステップ）。動的ステート情報更新要求と呼情報取得要求とは同一の信号によって行われてもよいし、別々の信号によって行われてもよい。

呼処理管理用データベース１０では、動的ステート情報更新要求及び呼情報取得要求が受信される。呼処理管理用データベース１０では、図１０（ｃ）に示すように、動的ステート情報更新要求に基づいて、管理されているユーザＣに係るＣＳＮの呼状態が“状態１”から“状態遷移中”にされる。また、ユーザＣに対する呼処理を実行中のＣＳＮとしてＣＳＮ１ｂが登録される。ユーザＣの呼状態（ステート情報）が更新されると呼処理管理用データベース１０からＣＳＮ１ｂに更新完了通知が送信される（Ｓ４７）。

また、呼処理管理用データベース１０では、呼情報取得要求に基づいて、ユーザＣに係る呼情報が読み出されて、呼処理管理用データベース１０からＣＳＮ１ａに呼情報取得応答として送信される（Ｓ４７）。更新完了通知と呼情報取得応答とは同一の信号によって行われてもよいし、別々の信号によって行われてもよい。

ＣＳＮ１ｂでは、取得部２３によって呼情報が受信される（Ｓ４７、取得ステップ）。ここで取得される呼情報は、待受中である旨の情報を含む呼情報である。これにより、ＣＳＮ１ｂは、呼処理の状態を示すステート情報やユーザＣに係る加入者プロファイルを含む呼情報を保持した状態となる。受信された呼情報は、取得部２３から呼処理部２４に出力される。

続いて、呼処理部２４によって、取得部２３によって取得された呼情報に基づいて、発信要求に係る呼処理が実行される（Ｓ４８、呼処理ステップ）。ここでの呼処理は呼接続を確立するための発信処理であり、他のサーバとの間で呼接続を確立する発信シーケンスに沿って処理が行われる。呼処理中の情報は、上述した一時的な情報として保持されている。

続いて、当該呼処理の一つとして、発信信号が、呼処理部２４からＡＳＮ１に対して送信される。送信された発信信号は、オープンフローネットワーク３０の所定のノード３１（ＣＳＮ１ｂと接続されているノード３１）によって受信される。当該ノード３１によって、フローエントリに基づいて、要求先（送信先）のＡＳＮ１（ＡＳＮ１ｂ）が決定される。続いて、当該ノード３１からＡＳＮ１ｂに発信信号が送信される（Ｓ４９、制御ステップ）。

発信信号が送信されたＡＳＮ１ｂでは、呼処理要求受付部２１によって発信信号が受信される（Ｓ４９、呼処理要求受付ステップ）。呼処理要求受付部２１によって受け付けられた発信要求の情報は、登録部２２、取得部２３及び呼処理部２４に出力される。ＡＳＮ１ｂでは、登録部２２によって、当該発信信号に基づいて動的ステート情報更新要求が呼処理管理用データベース１０に送信される（Ｓ５１、登録ステップ）。動的ステート情報更新要求は、当該発信信号に係る呼処理の要求元のユーザＣに対する呼処理を実行中のＡＳＮとして自ノードを呼処理管理用データベース１０に登録する信号である。動的ステート情報更新要求は、ユーザＣのユーザ識別子とＡＳＮ１ｂのノードＩＤとが含まれる。

なお、ＡＳＮ１ｂでは、呼処理に必要なユーザＣのデータ、即ち、呼処理の状態を示すステート情報やユーザＣに係る加入者プロファイルを含む呼情報を保持していない。

そこで、ＡＳＮ１ｂでは、動的ステート情報更新要求の送信と合わせて、取得部２３から呼処理管理用データベース１０に対して、発信要求を行ったユーザＣに係る呼情報を要求する呼情報取得要求が行われる（Ｓ５０、取得ステップ）。動的ステート情報更新要求と呼情報取得要求とは同一の信号によって行われてもよいし、別々の信号によって行われてもよい。

呼処理管理用データベース１０では、動的ステート情報更新要求及び呼情報取得要求が受信される。呼処理管理用データベース１０では、図１０（ｄ）に示すように、動的ステート情報更新要求に基づいて、管理されているユーザＣに係るＡＳＮの呼状態が“状態１”から“状態遷移中”にされる。また、ユーザＣに対する呼処理を実行中のＡＳＮとしてＡＳＮ１ｂが登録される。ユーザＣの呼状態（ステート情報）が更新されると呼処理管理用データベース１０からＡＳＮ１ｂに更新完了通知が送信される（Ｓ５１）。

また、呼処理管理用データベース１０では、呼情報取得要求に基づいて、ユーザＣに係る呼情報が読み出されて、呼処理管理用データベース１０からＡＳＮ１ｂに呼情報取得応答として送信される（Ｓ５１）。更新完了通知と呼情報取得応答とは同一の信号によって行われてもよいし、別々の信号によって行われてもよい。

ＡＳＮ１ｂでは、取得部２３によって呼情報が受信される（Ｓ５１、取得ステップ）。ここで取得される呼情報は、待受中である旨の情報を含む呼情報である。これにより、ＡＳＮ１ｂは、呼処理の状態を示すステート情報やユーザＣに係る加入者プロファイルを含む呼情報を保持した状態となる。受信された呼情報は、取得部２３から呼処理部２４に出力される。

続いて、呼処理部２４によって、取得部２３によって取得された呼情報に基づいて、発信要求に係る呼処理が実行される（Ｓ５２、呼処理ステップ）。ここでの呼処理は呼接続を確立するための発信処理であり、他のサーバとの間で呼接続を確立する発信シーケンスに沿って処理が行われる。

ここで（Ｓ４９以降、Ｓ５８以前のタイミングで）、ＣＳＮ１の負荷を集約させるために、ＣＳＮ１ｂが減設される（Ｓ５３）。ＣＳＮ１ｂの減設によって、ＣＳＮ１ｂに収容されていたユーザがＣＳＮ１ａに片寄せされる。この減設は、例えば、移動体通信システム１の通信事業者によって行われる。移動体通信システム１では、ネットワークマネージャ４０のノード状態把握部４１によって、各呼処理サーバ２０の状態の把握が行われる（Ｓ５４、ノード状態把握ステップ）。このとき、ノード状態把握部４１によって、ＣＳＮ１ｂの減設も把握される。各呼処理サーバ２０の状態を示す情報は、ノード状態把握部４１から制御部４２に出力される。

呼処理サーバ２０が仮想化されていた場合には、Ｓ５３は以下のような処理にすることができる。即ち、例えば同一種類の複数の呼処理サーバ２０の処理能力が過剰であることをノード状態把握部４１が把握し、制御部４２に通知する。制御部４２は仮想マシン制御部へ呼処理サーバ２０の削減を指示する。仮想マシン制御部は、複数の呼処理サーバ２０の減設をする。

続いて、制御部４２によって、各呼処理サーバ２０の状態を示す情報に基づいて呼処理を行う呼処理サーバ２０が決定されて、決定された呼処理サーバ２０に呼処理の要求が送信されるようにフローエントリが生成される（Ｓ５５、制御ステップ）。ここでは、ＣＳＮ１ｂが減設されたので、ここで生成されるフローエントリは、呼処理を行う呼処理サーバ２０として、減設されたＣＳＮ１ｂを含まないものとされたものとなる。例えば、図１１（ａ）に示すように、ユーザＣ，Ｄに係る呼処理はＣＳＮ１ａによって実行されるものとして（ユーザＣ，ＤがＣＳＮ１ａに収容されるものとして）フローエントリが生成される。

生成されたフローエントリは、オープンフローネットワーク３０の各ノード３１に送信される（Ｓ５５、制御ステップ）。オープンフローネットワーク３０の各ノード３１では、当該フローエントリが受信されて、当該フローエントリに基づいてフロー（呼処理の要求等の信号）の送信が行われる。

ＡＳＮ１ｂでは、呼処理部２４による呼処理が完了すると、ユーザＣに係るＡＳＮの通信状態が、例えば発信中状態である“状態２”に状態遷移される。呼処理部２４によって行われた呼処理の結果の情報（“状態２”に状態遷移された呼情報）は、呼処理部２４から呼処理結果格納部２５に出力される。

続いて、呼処理結果格納部２５によって、動的ステート情報更新要求が呼処理管理用データベース１０に送信される（Ｓ５６、呼処理結果格納ステップ）。ここで送信される動的ステート情報更新要求は、自ノードにおける呼処理が終了して、ユーザＣにおける呼処理の状態を状態遷移中から何れの呼処理サーバ２０においても呼処理が実行中でない状態に移行した旨を通知する信号である。動的ステート情報更新要求は、ユーザＣのユーザ識別子とＡＳＮ１ｂのノードＩＤとが含まれる。

また、呼処理の結果が反映された呼情報が、呼処理結果格納部２５から呼処理管理用データベース１０に呼情報更新要求として送信される（Ｓ５６、呼処理結果格納ステップ）。なお、呼情報更新要求と動的ステート情報更新要求とは同一の信号によって行われてもよいし、別々の信号によって行われてもよい。

呼処理管理用データベース１０では、動的ステート情報更新要求及び呼情報更新要求が受信される。呼処理管理用データベース１０では、図１１（ｂ）に示すように、動的ステート情報更新要求に基づいて、管理されているユーザＣに係るＡＳＮの呼状態が“状態遷移中”から“状態２”にされる。ユーザＣの呼状態（ステート情報）が更新されると呼処理管理用データベース１０からＡＳＮ１ｂに更新完了通知が送信される（Ｓ５７）。

また、呼処理管理用データベース１０では、呼情報更新要求に基づいて、ユーザＣに係る情報が受信した情報で更新される。即ち、更新後の呼情報は“状態２”である旨の情報を含む。更新が行われると、呼情報更新応答が呼処理管理用データベース１０からＡＳＮ１ｂに送信される（Ｓ５７）。なお、更新完了通知と呼情報更新応答とは同一の信号によって行われてもよいし、別々の信号によって行われてもよい。

ＡＳＮ１ｂでは、呼情報更新応答が受信されると、発信応答に係る信号がＣＳＮ１に送信される（Ｓ５８）。送信された発信応答は、オープンフローネットワーク３０の所定のノード３１（ＡＳＮ１ｂと接続されているノード３１）によって受信される。当該ノード３１によって、フローエントリに基づいて、要求先（送信先）のＣＳＮ１（ＣＮＳ１ａ）が決定される。上述したように、フローエントリは、ユーザＣの呼処理を行うＣＳＮは、減設されたＣＳＮ１ｂではなくＣＳＮ１ａとされている。続いて、当該ノード３１からＣＳＮ１ａに発信応答が送信される（Ｓ５８、制御ステップ）。

発信応答が送信されたＣＳＮ１ａでは、呼処理要求受付部２１によって発信応答が受信される（Ｓ５８、呼処理要求受付ステップ）。呼処理要求受付部２１によって受け付けられた発信応答の情報は、登録部２２、取得部２３及び呼処理部２４に出力される。

ＣＳＮ１ａは、今までユーザＣの呼処理を行っていた呼処理サーバ２０ではないのでユーザＣに係る情報を保持していない。まず、ＣＳＮ１ａでは、登録部２２によって、当該発信応答に基づいて動的ステート情報取得要求が呼処理管理用データベース１０に送信される（Ｓ５９、登録ステップ）。動的ステート情報取得要求は、当該発信応答に係る呼処理の要求元のユーザＣに対する呼処理を実行中のＣＳＮとして登録されているＣＳＮのノードＩＤを要求する信号（ユーザＣのＣＮＳに関する状態がどうなっているかを問い合わせる信号）である。また、動的ステート情報取得要求は、当該発信応答に係る呼処理の要求元のユーザＣに対する呼処理を実行中のＣＳＮとして自ノードを呼処理管理用データベース１０に登録する信号でもある。動的ステート情報更新要求は、ユーザＣのユーザ識別子とＣＳＮ１ａのノードＩＤとが含まれる。

呼処理管理用データベース１０では、動的ステート情報取得要求が受信される。呼処理管理用データベース１０では、動的ステート情報取得要求に対する応答として、ユーザＣに対する呼処理を実行中のＣＳＮとして登録されているＣＳＮのノードＩＤ（ＣＳＮ１ｂのノードＩＤ）（ＣＳＮ１ｂがＳ４６で登録した情報）をＣＳＮ１ａに送信する（Ｓ６０）。また、呼処理管理用データベース１０では、図１１（ｃ）に示すように、動的ステート情報取得要求に基づいて、ユーザＣに対する呼処理を実行中のＣＳＮとしてＣＳＮ１ａが登録される。なお、ユーザＣに係るＣＳＮの呼状態は“状態遷移中”のままである。ユーザＣの呼状態（ステート情報）が更新されると呼処理管理用データベース１０からＣＳＮ１ｂに更新完了通知が送信される（Ｓ６０）。なお、動的ステート情報取得要求に対する応答と更新完了通知とは同一の信号によって行われてもよいし、別々の信号によって行われてもよい。

ＣＳＮ１ａでは、図１１（ｄ）に示すように、取得部２３によって、呼処理管理用データベース１０から送信された、ユーザＣに対する呼処理を実行中のＣＳＮとして登録されているＣＳＮのノードＩＤによって示されるＣＳＮ１ｂとの間でユーザＣに関して呼処理を実行するための情報が同期される。情報の同期は、ＣＳＮ１ａの取得部２３からＣＳＮ１ｂに対して同期の要求が行われて（Ｓ６１）、ＣＳＮ１ｂから当該要求に応じて送信された情報の受信が行われる（Ｓ６２）ことで行われる。

ここで、ＣＳＮ１ｂからＣＳＮ１ａに送信されるユーザＣに係る情報には、呼処理の途中で用いられる一時的な情報が含まれる。また、当該情報には、ＣＳＮ１ｂが呼処理管理用データベース１０から取得された呼処理の状態を示すステート情報やユーザＣに係る加入者プロファイルを含む呼情報が含まれていてもよい。但し、呼処理管理用データベース１０から取得可能な情報は、ＣＳＮ１ｂから取得せずに呼処理管理用データベース１０から取得してもよい。このように取得部２３によって取得された、ユーザＣに係る呼処理を継続するための情報は取得部２３から呼処理部２４に出力される。

続いて、呼処理部２４によって、取得部２３によって取得された呼情報に基づいて、発信応答（発信要求）に係る呼処理が実行される（Ｓ６３、呼処理ステップ）。

呼処理部２４による呼処理が完了すると、ユーザＣに係るＣＳＮの通信状態が“状態２”に状態遷移される。呼処理部２４によって行われた呼処理の結果の情報（“状態２”に状態遷移された呼情報）は、呼処理部２４から呼処理結果格納部２５に出力される。

続いて、呼処理結果格納部２５によって、動的ステート情報更新要求が呼処理管理用データベース１０に送信される（Ｓ６４、呼処理結果格納ステップ）。ここで送信される動的ステート情報更新要求は、自ノードにおける呼処理が終了して、ユーザＣにおける呼処理の状態を状態遷移中から何れの呼処理サーバ２０においても呼処理が実行中でない状態に移行した旨を通知する信号である。動的ステート情報更新要求は、ユーザＣのユーザ識別子とＣＳＮ１ａのノードＩＤとが含まれる。

また、呼処理の結果が反映された呼情報が、呼処理結果格納部２５から呼処理管理用データベース１０に呼情報更新要求として送信される（Ｓ６５、呼処理結果格納ステップ）。なお、呼情報更新要求と動的ステート情報更新要求とは同一の信号によって行われてもよいし、別々の信号によって行われてもよい。

呼処理管理用データベース１０では、動的ステート情報更新要求及び呼情報更新要求が受信される。呼処理管理用データベース１０では、図１２（ａ）に示すように、動的ステート情報更新要求に基づいて、管理されているユーザＣに係るＣＳＮの呼状態が“状態遷移中”から“状態２”にされる。ユーザＣの呼状態（ステート情報）が更新されると呼処理管理用データベース１０からＣＳＮ１ａに更新完了通知が送信される（Ｓ６５）。

また、呼処理管理用データベース１０では、呼情報更新要求に基づいて、ユーザＣに係る情報が受信した情報で更新される。即ち、更新後の呼情報は“状態２”である旨の情報を含む。更新が行われると、呼情報更新応答が呼処理管理用データベース１０からＣＳＮ１ａに送信される（Ｓ６５）。なお、更新完了通知と呼情報更新応答とは同一の信号によって行われてもよいし、別々の信号によって行われてもよい。

ＣＳＮ１ａでは、呼情報更新応答が受信されると、発信応答に係る信号がＰ−ＣＳＣＦ１に送信される（Ｓ６６）。送信された発信応答は、オープンフローネットワーク３０の所定のノード３１（ＣＳＮ１ａと接続されているノード３１）によって受信される。当該ノード３１によって、フローエントリに基づいて、要求先（送信先）のＰ−ＣＳＣＦ１（Ｐ−ＣＳＣＦ１ｂ）が決定される。続いて、当該ノード３１からＰ−ＣＳＣＦ１ｂに発信応答が送信される（Ｓ６６、制御ステップ）。

発信応答が送信されたＰ−ＣＳＣＦ１ｂでは、呼処理要求受付部２１によって発信応答が受信される（Ｓ６６、呼処理要求受付ステップ）。呼処理要求受付部２１によって受け付けられた発信応答の情報は呼処理部２４に出力される。

Ｐ−ＣＳＣＦ１ｂでは、呼処理部２４によって、入力された発信応答と、Ｓ０４における処理で用いた情報とに基づいて、発信応答（発信要求）に係る呼処理が実行される（Ｓ６７、呼処理ステップ）。

呼処理部２４による呼処理が完了すると、ユーザＣに係るＰ−ＣＳＣＦの通信状態が“状態２”に状態遷移される。呼処理部２４によって行われた呼処理の結果の情報（“状態２”に状態遷移された呼情報）は、呼処理部２４から呼処理結果格納部２５に出力される。

続いて、呼処理結果格納部２５によって、動的ステート情報更新要求が呼処理管理用データベース１０に送信される（Ｓ６８、呼処理結果格納ステップ）。ここで送信される動的ステート情報更新要求は、自ノードにおける呼処理が終了して、ユーザＣにおける呼処理の状態を状態遷移中から何れの呼処理サーバ２０においても呼処理が実行中でない状態に移行した旨を通知する信号である。動的ステート情報更新要求は、ユーザＣのユーザ識別子とＰ−ＣＳＣＦ１ｂのノードＩＤとが含まれる。

また、呼処理の結果が反映された呼情報が、呼処理結果格納部２５から呼処理管理用データベース１０に呼情報更新要求として送信される（Ｓ６８、呼処理結果格納ステップ）。なお、呼情報更新要求と動的ステート情報更新要求とは同一の信号によって行われてもよいし、別々の信号によって行われてもよい。

呼処理管理用データベース１０では、動的ステート情報更新要求及び呼情報更新要求が受信される。呼処理管理用データベース１０では、図１２（ｂ）に示すように、動的ステート情報更新要求に基づいて、管理されているユーザＣに係るＰ−ＣＳＣＦの呼状態が“状態遷移中”から“状態２”にされる。ユーザＣの呼状態（ステート情報）が更新されると呼処理管理用データベース１０からＰ−ＣＳＣＦ１ｂに更新完了通知が送信される（Ｓ６９）。

また、呼処理管理用データベース１０では、呼情報更新要求に基づいて、ユーザＣに係る情報が受信した情報で更新される。即ち、更新後の呼情報は“状態２”である旨の情報を含む。更新が行われると、呼情報更新応答が呼処理管理用データベース１０からＰ−ＣＳＣＦ１ｂに送信される（Ｓ６９）。なお、更新完了通知と呼情報更新応答とは同一の信号によって行われてもよいし、別々の信号によって行われてもよい。

Ｐ−ＣＳＣＦ１ｂでは、呼情報更新応答が受信されると、発信応答に係る信号がＰ−ＧＷに送信される（Ｓ７０）。また、発信応答に係る信号は、Ｐ−ＧＷからユーザＣに送信される。以上の処理により、ユーザＣは発信中状態（“状態２”）となり、呼情報に含まれるユーザＣの通信状態（移動体通信網で管理されるユーザＣの通信状態）も発信中状態（“状態２”）に状態遷移される。

以上が、ユーザＣから別の端末への発信等の呼処理の要求があり、その呼処理の途中で呼処理サーバ２０が減設された場合の処理である。上記は、発信の際の処理であったが、その他の呼処理についても上述したように同様に行われる。

上述したように本実施形態に係る移動体通信システム１では、呼処理ノードである呼処理サーバ２０と別構成となっている呼処理管理用データベース１０において、呼処理に必要な移動通信端末５０毎のデータが保持されており、呼処理が行われる毎にその情報が参照されて新たに格納される。従って、本移動体通信システム１では、どの移動通信端末５０に係る呼処理でも、任意の呼処理サーバ２０によって実行されえる。そして、本移動体通信システム１では、移動通信端末５０毎に呼処理を行う呼処理ノードが決まっておらず、呼処理の要求毎にネットワークマネージャ４０によって決定される呼処理サーバ２０で呼処理が行われることとすることができる。

なお、従来の移動体通信システムでは、在圏処理等によって移動通信端末の呼処理を行う呼処理サーバが一旦決まると、その呼処理サーバにおいて当該移動通信端末に呼処理に必要な情報であるステート情報が保持されるため、他の呼処理サーバに呼処理を代替させることができなかった。従って、従来の移動体通信システムでは、上述したように呼処理サーバをａｃｔ／ｓｂｙ構成とした冗長化を図っていた。

上記のように本移動体通信システム１では、個々の呼処理サーバ２０がｓｂｙ系あるいはａｃｔ系と設定されるものではなく任意の呼処理サーバ２０によって呼処理が実行できるため、より経済的な呼処理ノードの冗長化を可能にしている。また、何れかの呼処理サーバ２０が動作していれば呼処理が可能となるため、より確実な呼処理サーバ２０の冗長化を可能にしている。また、個々の呼処理サーバ２０が呼処理に必要な移動通信端末５０毎のデータを保持しないのでスケールアウトも容易に実現することが可能となる。

より具体的には、上述したように個々の呼処理サーバ２０の故障の際に切替が可能になる。また、呼処理サーバ２０の故障（突発停止）だけでなく計画停止の際にも容易に切替が可能になる。また、呼処理サーバ２０をスケールアウトする際に、位置登録処理等を契機とせずに容易に増設した呼処理サーバ２０にユーザを移すことができる。従来の移動体通信システムでは、上述したように既に在圏している移動通信端末を別の呼処理サーバに移すことが難しかったため、呼処理サーバを増設しても徐々にしかユーザを移すことができなかった。

更に、本実施形態に係る移動体通信システム１では、呼処理管理用データベース１０に呼処理を実行中の呼処理サーバ２０が登録される。呼処理を実行中の呼処理サーバ２０とは別の呼処理サーバ２０（図５の例におけるＣＳＮ１ｂ、図９の例におけるＣＳＮ１ａ）によって呼処理の要求が受け付けられた場合、呼処理を実行中の呼処理サーバ２０として登録されている他の呼処理サーバ２０（図５の例におけるＣＳＮ１ａ、図９の例におけるＣＳＮ１ｂ）から呼処理の要求に係る移動通信端末５０の情報（呼処理の状態遷移中の情報）が取得される。

従って、もし、呼処理の途中で呼処理を行う呼処理サーバ２０が変更されたとしても、呼処理サーバ２０間で呼処理の要求に係る移動通信端末５０の情報が引き継がれるため、変更後の呼処理サーバ２０において、変更前の呼処理サーバ２０で取得された情報を再送制御による処理救済等で改めて取得する必要がない。従って、呼処理の途中で呼処理を行う呼処理サーバ２０が変更されたとしても、効率的な処理を行うことが可能となる。より具体的には、上述したように、仮想化サーバを用いた呼処理サーバ２０の増設及び減設時において、通信中呼が切断されることなく、別の呼処理サーバ２０に処理を引き継ぐことができる。このように、本移動体通信システム１によれば、優れた確実性、経済性、柔軟性を有する呼処理ノードの冗長化が可能となる。

また、本実施形態のようにオープンフローネットワークを利用することとしてもよい。この構成によれば、呼処理サーバ２０が位置登録エリアに対応付けられたものではなくなるため、位置登録エリア等によらない呼処理サーバ２０の冗長化が可能となるため、本発明による上記の効果をより大きいものとすることができる。但し、呼処理サーバが位置登録エリアに対応付けられている態様で本発明で実施することができる。その場合、位置登録エリア内での、優れた確実性、経済性、柔軟性を有する呼処理サーバの冗長化が実現できる。

１…移動体通信システム、２…拠点、１０…呼処理管理用データベース、２０…呼処理サーバ、２１…呼処理要求受付部、２２…登録部、２３…取得部、２４…呼処理部、２５…呼処理結果格納部、３０…オープンフローネットワーク、３１…ノード、４０…ネットワークマネージャ、４１…ノード状態把握部、４２…制御部、５０…移動通信端末、６０…対向ノード、１０１…ＣＰＵ、１０２…ＲＡＭ、１０３…ＲＯＭ、１０４…通信モジュール、１０５…補助記憶装置。

Claims (6)

1. 移動通信端末に移動体通信の機能を提供すると共に複数の呼処理ノードと、当該複数の呼処理ノードそれぞれと接続されており、呼処理に必要な当該移動通信端末毎のデータを保持する呼処理管理用データベースと、制御ノードとを含んで構成される移動体通信システムであって、
   前記制御ノードは、
   前記複数の呼処理ノードの状態を把握するノード状態把握手段と、
   前記ノード状態把握手段によって把握された前記複数の呼処理ノードの状態に基づいて、前記移動通信端末から呼処理の要求を処理する呼処理ノードを決定して決定した呼処理ノードによって当該呼処理の要求が処理されるように制御する制御手段と、を備え、
   前記呼処理ノードは、
   前記制御ノードの制御を受けた前記呼処理の要求を受け付ける呼処理要求受付手段と、
   前記呼処理要求受付手段によって前記呼処理の要求が受け付けられると、前記呼処理の要求に係る移動通信端末に対する呼処理を実行中の呼処理ノードとして自ノードを前記呼処理管理用データベースに登録する登録手段と、
   前記呼処理要求受付手段によって受け付けられた前記呼処理の要求に係る移動通信端末の情報を前記呼処理管理用データベースから取得すると共に前記呼処理管理用データベースに当該移動通信端末に対する呼処理を実行中の呼処理ノードとして登録されている呼処理ノードから前記呼処理の要求に係る移動通信端末の情報を取得する取得手段と、
   前記取得手段によって取得された情報を用いて当該要求に係る呼処理を行う呼処理手段と、
   前記呼処理手段によって行われた呼処理の結果の情報を前記呼処理管理用データベースに格納すると共に前記呼処理手段によって行われた呼処理が終了したら当該呼処理の要求に係る移動通信端末に対する呼処理を実行中の呼処理ノードとしての前記呼処理管理用データベースに対する登録を終了させる呼処理結果格納手段と、を備える移動体通信システム。
2. フロー制御ネットワークを更に含み、
   前記制御手段は、決定した呼処理ノードによって当該呼処理の要求が処理されるように前記フロー制御ネットワークを設定する請求項１に記載の移動体通信システム。
3. 前記呼処理ノードは、仮想化された仮想マシンによって構成され、
   前記制御ノードは、前記ノード状態把握手段によって把握された前記複数の呼処理ノードの状態に基づいて、前記仮想化の制御を行う仮想化制御手段を、更に備える請求項１又は２に記載の移動体通信システム。
4. 移動通信端末に移動体通信の機能を提供すると共に複数の呼処理ノードと、当該複数の呼処理ノードそれぞれと接続されており、呼処理に必要な当該移動通信端末毎のデータを保持する呼処理管理用データベースと、制御ノードとを含んで構成される移動体通信システムにおける呼処理ノードであって、
   前記制御ノードの制御を受けた前記呼処理の要求を受け付ける呼処理要求受付手段と、
   前記呼処理要求受付手段によって前記呼処理の要求が受け付けられると、前記呼処理の要求に係る移動通信端末に対する呼処理を実行中の呼処理ノードとして自ノードを前記呼処理管理用データベースに登録する登録手段と、
   前記呼処理要求受付手段によって受け付けられた前記呼処理の要求に係る移動通信端末の情報を前記呼処理管理用データベースから取得すると共に前記呼処理管理用データベースに当該移動通信端末に対する呼処理を実行中の呼処理ノードとして登録されている呼処理ノードから前記呼処理の要求に係る移動通信端末の情報を取得する取得手段と、
   前記取得手段によって取得された情報を用いて当該要求に係る呼処理を行う呼処理手段と、
   前記呼処理手段によって行われた呼処理の結果の情報を前記呼処理管理用データベースに格納すると共に前記呼処理手段によって行われた呼処理が終了したら当該呼処理の要求に係る移動通信端末に対する呼処理を実行中の呼処理ノードとしての前記呼処理管理用データベースに対する登録を終了させる呼処理結果格納手段と、
   を備える呼処理ノード。
5. 移動通信端末に移動体通信の機能を提供すると共に複数の呼処理ノードと、当該複数の呼処理ノードそれぞれと接続されており、呼処理に必要な当該移動通信端末毎のデータを保持する呼処理管理用データベースと、制御ノードとを含んで構成される移動体通信システムによる通信制御方法であって、
   前記制御ノードが、
   前記複数の呼処理ノードの状態を把握するノード状態把握ステップと、
   前記ノード状態把握ステップにおいて把握された前記複数の呼処理ノードの状態に基づいて、前記移動通信端末から呼処理の要求を処理する呼処理ノードを決定して決定した呼処理ノードによって当該呼処理の要求が処理されるように制御する制御ステップと、
   前記呼処理ノードが、
   前記制御ノードの制御を受けた前記呼処理の要求を受け付ける呼処理要求受付ステップと、
   前記呼処理要求受付ステップにおいて前記呼処理の要求が受け付けられると、前記呼処理の要求に係る移動通信端末に対する呼処理を実行中の呼処理ノードとして自ノードを前記呼処理管理用データベースに登録する登録ステップと、
   前記呼処理要求受付ステップにおいて受け付けられた前記呼処理の要求に係る移動通信端末の情報を前記呼処理管理用データベースから取得すると共に前記呼処理管理用データベースに当該移動通信端末に対する呼処理を実行中の呼処理ノードとして登録されている呼処理ノードから前記呼処理の要求に係る移動通信端末の情報を取得する取得ステップと、
   前記取得ステップにおいて取得された情報を用いて当該要求に係る呼処理を行う呼処理ステップと、
   前記呼処理ステップにおいて行われた呼処理の結果の情報を前記呼処理管理用データベースに格納すると共に前記呼処理ステップにおいて行われた呼処理が終了したら当該呼処理の要求に係る移動通信端末に対する呼処理を実行中の呼処理ノードとしての前記呼処理管理用データベースに対する登録を終了させる呼処理結果格納ステップと、を含む通信制御方法。
6. 移動通信端末に移動体通信の機能を提供すると共に複数の呼処理ノードと、当該複数の呼処理ノードそれぞれと接続されており、呼処理に必要な当該移動通信端末毎のデータを保持する呼処理管理用データベースと、制御ノードとを含んで構成される移動体通信システムにおける呼処理ノードによる通信制御方法であって、
   前記制御ノードの制御を受けた前記呼処理の要求を受け付ける呼処理要求受付ステップと、
   前記呼処理要求受付ステップにおいて前記呼処理の要求が受け付けられると、前記呼処理の要求に係る移動通信端末に対する呼処理を実行中の呼処理ノードとして自ノードを前記呼処理管理用データベースに登録する登録ステップと、
   前記呼処理要求受付ステップにおいて受け付けられた前記呼処理の要求に係る移動通信端末の情報を前記呼処理管理用データベースから取得すると共に前記呼処理管理用データベースに当該移動通信端末に対する呼処理を実行中の呼処理ノードとして登録されている呼処理ノードから前記呼処理の要求に係る移動通信端末の情報を取得する取得ステップと、
   前記取得ステップにおいて取得された情報を用いて当該要求に係る呼処理を行う呼処理ステップと、
   前記呼処理ステップにおいて行われた呼処理の結果の情報を前記呼処理管理用データベースに格納すると共に前記呼処理ステップにおいて行われた呼処理が終了したら当該呼処理の要求に係る移動通信端末に対する呼処理を実行中の呼処理ノードとしての前記呼処理管理用データベースに対する登録を終了させる呼処理結果格納ステップと、
   を含む通信制御方法。

Images