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

Description

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

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

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

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

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

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

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

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

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

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

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

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

上記の移動体通信システムに含まれる呼処理ノードは、それら自体が新規な構成を有しており発明に相当する。

本発明の一実施形態に係る呼処理ノードは、移動通信端末に移動体通信の機能を提供すると共に複数の呼処理ノードと、当該複数の呼処理ノードそれぞれと接続されており、呼処理に必要な当該移動通信端末毎のデータを保持する呼処理管理用データベースと、制御ノードとを含んで構成される移動体通信システムにおける呼処理ノードであって、制御ノードの制御を受けた呼処理の要求を受け付ける呼処理要求受付手段と、呼処理要求受付手段によって呼処理の要求が受け付けられた度に、一律に又は自ノード内に有効な当該呼処理の要求に係る移動通信端末の情報がなかった場合に、呼処理要求受付手段によって受け付けられた呼処理の要求に係る移動通信端末の情報を呼処理管理用データベースから取得する取得手段と、取得手段によって取得された情報を用いて当該要求に係る呼処理を行う呼処理手段と、呼処理手段によって行われた呼処理の結果の情報を呼処理管理用データベースに格納する呼処理結果格納手段と、を備える。

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

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

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

また、本発明は、上記のように移動体通信システム、呼処理ノード及び通信制御方法の発明として記述できる他に、以下のように通信システム、通信システムに含まれる呼処理ノード、並びにそれらによる通信制御方法の発明としても記述することができる。これらは、移動通信端末が通信端末である点、及び移動体通信が通信である点を除き上記の発明と実質的に同一の発明であり、同様の作用及び効果を奏する。

本発明の一実施形態に係る通信システムは、通信端末に通信の機能を提供すると共に複数の呼処理ノードと、当該複数の呼処理ノードそれぞれと接続されており、呼処理に必要な当該通信端末毎のデータを保持する呼処理管理用データベースと、制御ノードとを含んで構成される通信システムであって、制御ノードは、複数の呼処理ノードの状態を把握するノード状態把握手段と、ノード状態把握手段によって把握された複数の呼処理ノードの状態に基づいて、通信端末から呼処理の要求を処理する呼処理ノードを決定して決定した呼処理ノードによって当該呼処理の要求が処理されるように制御する制御手段と、を備え、呼処理ノードは、制御ノードの制御を受けた呼処理の要求を受け付ける呼処理要求受付手段と、呼処理要求受付手段によって呼処理の要求が受け付けられた度に、一律に又は自ノード内に有効な当該呼処理の要求に係る通信端末の情報がなかった場合に、呼処理要求受付手段によって受け付けられた呼処理の要求に係る通信端末の情報を呼処理管理用データベースから取得する取得手段と、取得手段によって取得された情報を用いて当該要求に係る呼処理を行う呼処理手段と、呼処理手段によって行われた呼処理の結果の情報を呼処理管理用データベースに格納する呼処理結果格納手段と、を備える。

本発明の一実施形態に係る呼処理ノードは、通信端末に通信の機能を提供すると共に複数の呼処理ノードと、当該複数の呼処理ノードそれぞれと接続されており、呼処理に必要な当該通信端末毎のデータを保持する呼処理管理用データベースと、制御ノードとを含んで構成される通信システムにおける呼処理ノードであって、制御ノードの制御を受けた呼処理の要求を受け付ける呼処理要求受付手段と、呼処理要求受付手段によって呼処理の要求が受け付けられた度に、一律に又は自ノード内に有効な当該呼処理の要求に係る通信端末の情報がなかった場合に、呼処理要求受付手段によって受け付けられた呼処理の要求に係る通信端末の情報を呼処理管理用データベースから取得する取得手段と、取得手段によって取得された情報を用いて当該要求に係る呼処理を行う呼処理手段と、呼処理手段によって行われた呼処理の結果の情報を呼処理管理用データベースに格納する呼処理結果格納手段と、を備える。

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

本発明の一実施形態に係る通信制御方法は、通信端末に通信の機能を提供すると共に複数の呼処理ノードと、当該複数の呼処理ノードそれぞれと接続されており、呼処理に必要な当該通信端末毎のデータを保持する呼処理管理用データベースと、制御ノードとを含んで構成される通信システムにおける呼処理ノードによる通信制御方法であって、制御ノードの制御を受けた呼処理の要求を受け付ける呼処理要求受付ステップと、呼処理要求受付ステップにおいて呼処理の要求が受け付けられた度に、一律に又は自ノード内に有効な当該呼処理の要求に係る通信端末の情報がなかった場合に、呼処理要求受付ステップにおいて受け付けられた呼処理の要求に係る通信端末の情報を呼処理管理用データベースから取得する取得ステップと、取得ステップにおいて取得された情報を用いて当該要求に係る呼処理を行う呼処理ステップと、呼処理ステップにおいて行われた呼処理の結果の情報を呼処理管理用データベースに格納する呼処理結果格納ステップと、を含む。

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

本発明の実施形態に係る移動体通信システムの構成、及び移動体通信システムを構成する装置の機能構成を示す図である。 呼処理管理用データベースで保持されるデータを示す図である。 本発明の実施形態に係る移動体通信システムを構成する装置のハードウェア構成を示す図である。 本発明の実施形態に係る移動体通信システムで、平常時に実行される処理（通信制御方法）を示すシーケンス図である。 本発明の実施形態に係る移動体通信システムで、呼処理サーバに故障が発生した時に実行される処理（通信制御方法）を示すシーケンス図である。 本発明の実施形態に係る移動体通信システムで、呼処理サーバのスケールアウトが行われる時に実行される処理（通信制御方法）を示すシーケンス図である。

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

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

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

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

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

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

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

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

図２に示すように、ＡＰＬ層では、呼情報、一時的な情報、プログラムがメモリ上に記憶される。呼情報は、呼処理に必要なデータであり、呼の状態遷移を保持するステート情報（例えば、通信中や待受中等の情報）や加入者プロファイルである。呼情報は、呼処理管理用データベース１０から情報を取得する等して、呼処理の際のみに保持される。なお、呼情報は、呼処理後にも、キャッシュとして処理の効率化のために呼処理サーバ２０において保持されていてもよいが、呼処理サーバ２０は呼情報についての責任は持たない。一時的な情報は、呼処理（信号シーケンス）の途中で用いられる一時的な情報（位置登録、発信等のシーケンス途中の情報）である。例えば、待受中から通信中へ変わる過渡的な状態で用いられるテンポラリ情報である。プログラムは、呼処理サーバ２０の機能を実現するための実行コードそのもの（実行バイナリの情報）である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

引き続いて、図４〜図６のシーケンス図を用いて、本実施形態に係る移動体通信システム１で実行される処理である通信制御方法を説明する。まず、図４のシーケンス図を用いて平常時に移動通信端末５０から別の端末に発信が行われる場合の処理について説明する。

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

ここで、移動通信端末５０から移動体通信システム１（移動体通信網）に対して発信要求が行われる（Ｓ０４）。発信要求は、別の端末と通信を行うための呼接続の要求である。発信要求は、オープンフローネットワーク３０の所定のノード３１（移動通信端末５０と接続されているノード３１）によって受信される。オープンフローネットワーク３０の所定のノード３１によって、フローエントリに基づいて、要求先（送信先）の呼処理サーバ２０が決定される（Ｓ０５、制御ステップ）。続いて、当該ノード３１から呼処理サーバ２０に発信要求が送信される（Ｓ０６、制御ステップ）。

発信要求が送信された呼処理サーバ２０では、呼処理要求受付部２１によって発信要求が受信される（Ｓ０６、呼処理要求受付ステップ）。呼処理要求受付部２１によって受け付けられた発信要求の情報は、取得部２２及び呼処理部２３に出力される。当該呼処理サーバ２０では、呼処理に必要な移動通信端末５０のデータ、即ち、呼処理の状態を示すステート情報や移動通信端末５０に係る加入者プロファイルを含む呼情報を保持していない。

続いて、取得部２２から呼処理管理用データベース１０に対して、発信要求を行った移動通信端末５０に係る呼情報を要求する呼情報取得要求が行われる（Ｓ０７、取得ステップ）。呼処理管理用データベース１０では、呼情報取得要求が受信される。続いて、当該移動通信端末５０に係る呼情報が読み出されて、呼処理管理用データベース１０から呼処理サーバ２０に呼情報取得応答として送信される。呼処理サーバ２０では、取得部２２によって呼情報が受信される（Ｓ０８、取得ステップ）。ここで取得される呼情報は、待受中である旨の情報を含む呼情報である。ここで、当該呼処理サーバ２０は、呼処理の状態を示すステート情報や移動通信端末５０に係る加入者プロファイルを含む呼情報を保持した状態となる。受信された呼情報は、取得部２２から呼処理部２３に出力される。

続いて、呼処理部２３によって、取得部２２によって取得された呼情報に基づいて、発信要求に係る呼処理が実行される（Ｓ０９、呼処理ステップ）。ここでの呼処理は呼接続を確立するための発信処理であり、他のサーバとの間で呼接続を確立する発信シーケンスに沿って処理が行われる。呼処理部２３による呼処理によって呼接続が確立されると、当該移動通信端末５０は通信中の状態となり、呼情報に含まれる移動通信端末５０の通信状態も通信中に状態遷移される。呼処理部２３によって行われた呼処理の結果の情報（通信中に状態遷移された呼情報）は、呼処理部２３から呼処理結果格納部２４に出力される。

続いて、呼処理の結果が反映された呼情報が、呼処理結果格納部２４から呼処理管理用データベース１０に呼情報更新要求として送信される（Ｓ１０、呼処理結果格納ステップ）。呼処理管理用データベース１０では、呼情報更新要求が受信されて、当該移動通信端末５０に係る情報が受信した情報で更新される。即ち、更新後の呼情報は通信中である旨の情報を含む。更新が行われると、呼情報更新応答が呼処理管理用データベース１０から呼処理サーバ２０に送信される（Ｓ１１）。呼処理サーバ２０では、呼情報更新応答が受信されると、発信応答がオープンフローネットワーク３０を介して発信要求を行った移動通信端末５０に送信される（Ｓ１２）。

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

続いて、図５のシーケンス図を用いて呼処理サーバ２０ａに故障が発生した時に移動通信端末５０から別の端末に発信が行われる場合の処理について説明する。なお、呼処理サーバ２０ａに故障が発生するまでは、移動通信端末５０の呼処理は呼処理サーバ２０ａが行っていた。

まず、呼処理サーバ２０ａに故障が発生する（Ｓ２１）。移動体通信システム１では、ネットワークマネージャ４０のノード状態把握部４１によって、各呼処理サーバ２０の状態の把握が行われる（Ｓ２２、ノード状態把握ステップ）。このとき、ノード状態把握部４１によって、呼処理サーバ２０ａの故障も把握される。なお、呼処理管理用データベース１０において記憶されている呼情報について、呼処理サーバ２０ａが信号処理中に故障が発生した場合には破棄（ロールバック）され、呼処理管理用データベース１０の書き換えは行われない。また、呼処理サーバ２０ａによって確立された通信中であった場合、通信中である情報は呼処理管理用データベース１０で管理されているので救済される。各呼処理サーバ２０の状態を示す情報は、ノード状態把握部４１から制御部４２に出力される。

続いて、制御部４２によって、各呼処理サーバ２０の状態を示す情報に基づいて呼処理を行う呼処理サーバ２０が決定されて、決定された呼処理サーバ２０に呼処理の要求が送信されるようにフローエントリが生成される（Ｓ２３、制御ステップ）。呼処理サーバ２０ａに故障が発生しているので、ここで生成されるフローエントリは、呼処理を行う呼処理サーバ２０は呼処理サーバ２０ａ以外の呼処理サーバ２０とされたものとなる。例えば、呼処理サーバ２０ｂが、呼処理サーバ２０ａが実行していた呼処理を実行するものとしてフローエントリが生成される。

呼処理サーバ２０が仮想化されていた場合、ネットワークマネージャ４０の仮想マシン制御部により、呼処理サーバ２０の状態に応じて新たにプロビジョニングされた仮想呼処理サーバが、呼処理サーバ２０ｂとなってもよい。

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

ここで、移動通信端末５０から移動体通信システム１（移動体通信網）に対して発信要求が行われる（Ｓ２５）。発信要求は、別の端末と通信を行うための呼接続の要求である。発信要求は、オープンフローネットワーク３０の所定のノード３１（移動通信端末５０と接続されているノード３１）によって受信される。オープンフローネットワーク３０の所定のノード３１によって、フローエントリに基づいて、要求先（送信先）の呼処理サーバ２０ｂが決定される（Ｓ２６、制御ステップ）。なお、移動通信端末５０から送信された発信要求の送信先を示す情報であるＩＰアドレスが、それまでの呼処理を行っていた呼処理サーバ２０ａであったとしても、オープンフローネットワーク３０によって上記のように経路が変更される。呼処理サーバ２０の切替については、例えば、移動通信端末５０のＳｒｃＩＰ（データの送信元のＩＰアドレス）のアドレス帯域毎に接続先呼処理サーバ２０を選択するフローエントリを設定することで実現できる。また、新たに割り当てられた呼処理サーバ２０ｂは、呼処理サーバ２０ａのＩＰアドレスを引き継ぐことで信号の到達を確保する。このような送信先の切替を行うことによって、移動通信端末５０側では、呼処理を行う呼処理サーバ２０を意識させずに（アプリケーション間の通信に関わる設定等を変えずに）呼処理サーバ２０の切替を行うことができる。続いて、当該ノード３１から呼処理サーバ２０ｂに発信要求が送信される（Ｓ２７、制御ステップ）。

発信要求が送信された呼処理サーバ２０ｂでは、呼処理要求受付部２１によって発信要求が受信される（Ｓ２７、呼処理要求受付ステップ）。呼処理要求受付部２１によって受け付けられた発信要求の情報は、取得部２２及び呼処理部２３に出力される。当該呼処理サーバ２０では、呼処理に必要な移動通信端末５０のデータ、即ち、呼処理の状態を示すステート情報や移動通信端末５０に係る加入者プロファイルを含む呼情報を保持していない。

続いて、取得部２２から呼処理管理用データベース１０に対して、発信要求を行った移動通信端末５０に係る呼情報を要求する呼情報取得要求が行われる（Ｓ２８、取得ステップ）。呼処理管理用データベース１０では、呼情報取得要求が受信される。続いて、当該移動通信端末５０に係る呼情報が読み出されて、呼処理管理用データベース１０から呼処理サーバ２０ｂに呼情報取得応答として送信される。呼処理サーバ２０ｂでは、取得部２２によって呼情報が受信される（プロビジョニング）（Ｓ２９、取得ステップ）。ここで取得される呼情報は、待受中である旨の情報を含む呼情報である。ここで、当該呼処理サーバ２０ｂは、（呼処理を行っていた２０ａが最後に書き込みを行った）呼処理の状態を示すステート情報や移動通信端末５０に係る加入者プロファイルを含む呼情報を保持した状態となる。受信された呼情報は、取得部２２から呼処理部２３に出力される。

続いて、呼処理部２３によって、取得部２２によって取得された呼情報に基づいて、発信要求に係る呼処理が実行される（Ｓ３０、呼処理ステップ）。ここでの呼処理は呼接続を確立するための発信処理であり、他のサーバとの間で呼接続を確立する発信シーケンスに沿って処理が行われる。呼処理部２３による呼処理によって呼接続が確立されると、当該移動通信端末５０は通信中の状態となり、呼情報に含まれる移動通信端末５０の通信状態も通信中に状態遷移される。呼処理部２３によって行われた呼処理の結果の情報（通信中に状態遷移された呼情報）は、呼処理部２３から呼処理結果格納部２４に出力される。

続いて、呼処理の結果が反映された呼情報が、呼処理結果格納部２４から呼処理管理用データベース１０に呼情報更新要求として送信される（Ｓ３１、呼処理結果格納ステップ）。呼処理管理用データベース１０では、呼情報更新要求が受信されて、当該移動通信端末５０に係る情報が受信した情報で更新される。即ち、更新後の呼情報は通信中である旨の情報を含む。更新が行われると、呼情報更新応答が呼処理管理用データベース１０から呼処理サーバ２０ｂに送信される（Ｓ３２）。呼処理サーバ２０ｂでは、呼情報更新応答が受信されると、発信応答がオープンフローネットワーク３０を介して発信要求を行った移動通信端末５０に送信される（Ｓ３３）。以上が、呼処理サーバ２０ａに故障が発生した時に発信が行われる場合の処理である。

続いて、図６のシーケンス図を用いて呼処理サーバ２０ｂが増設されてスケールアウトされた時に移動通信端末５０から別の端末に発信が行われる場合の処理について説明する。なお、呼処理サーバ２０ｂを増設するまでは、移動通信端末５０ａ及び移動通信端末５０ｂの呼処理は呼処理サーバ２０ａが行っていた。

まず、呼処理サーバ２０ｂが増設される（Ｓ４１）。この増設は、例えば、移動体通信システム１の通信事業者によって行われる。移動体通信システム１では、ネットワークマネージャ４０のノード状態把握部４１によって、各呼処理サーバ２０の状態の把握が行われる（Ｓ４２、ノード状態把握ステップ）。このとき、ノード状態把握部４１によって、呼処理サーバ２０ｂの増設も把握される。各呼処理サーバ２０の状態を示す情報は、ノード状態把握部４１から制御部４２に出力される。

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

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

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

ここで、移動通信端末５０ａから移動体通信システム１（移動体通信網）に対して発信要求が行われる（Ｓ４５）。発信要求は、別の端末と通信を行うための呼接続の要求である。発信要求は、オープンフローネットワーク３０の所定のノード３１（移動通信端末５０ａと接続されているノード３１）によって受信される。オープンフローネットワーク３０の所定のノード３１によって、フローエントリに基づいて、要求先（送信先）の呼処理サーバ２０ａが決定される（Ｓ４６、制御ステップ）。続いて、当該ノード３１から呼処理サーバ２０ｂに発信要求が送信される（Ｓ４７、制御ステップ）。なお、移動通信端末５０ａに係る呼処理は、図４及び図５に示したものと同様であるので、図示及び説明を省略する。

一方で、移動通信端末５０ｂから移動体通信システム１（移動体通信網）に対して発信要求が行われる（Ｓ４８）。発信要求は、別の端末と通信を行うための呼接続の要求である。発信要求は、オープンフローネットワーク３０の所定のノード３１（移動通信端末５０ｂと接続されているノード３１）によって受信される。オープンフローネットワーク３０の所定のノード３１によって、フローエントリに基づいて、要求先（送信先）の呼処理サーバ２０ｂが決定される（Ｓ４９、制御ステップ）。なお、移動通信端末５０ｂから送信された発信要求の送信先を示す情報であるＩＰアドレスが、それまでの呼処理を行っていた呼処理サーバ２０ａであったとしても、オープンフローネットワーク３０によって上記のように経路が捩じ曲げられる。呼処理サーバ２０の切替については、例えば、移動通信端末５０のＳｒｃＩＰ（データの送信元のＩＰアドレス）のアドレス帯域毎に接続先呼処理サーバ２０を選択するフローエントリを設定することで実現できる。また、新たに割り当てられた呼処理サーバ２０ｂは、呼処理サーバ２０ａのＩＰアドレスを引き継ぐことで信号の到達を確保する。このような送信先の切替を行うことによって、移動通信端末５０側では、呼処理を行う呼処理サーバ２０を意識させずに（アプリケーション間の通信に関わる設定等を変えずに）呼処理サーバ２０の増設を行って性能の増強することができる。続いて、当該ノード３１から呼処理サーバ２０ｂに発信要求が送信される（Ｓ５０、制御ステップ）。

発信要求が送信された呼処理サーバ２０ｂでは、呼処理要求受付部２１によって発信要求が受信される（Ｓ５０、呼処理要求受付ステップ）。呼処理要求受付部２１によって受け付けられた発信要求の情報は、取得部２２及び呼処理部２３に出力される。当該呼処理サーバ２０では、呼処理に必要な移動通信端末５０ｂのデータ、即ち、呼処理の状態を示すステート情報や移動通信端末５０ｂに係る加入者プロファイルを含む呼情報を保持していない。

続いて、取得部２２から呼処理管理用データベース１０に対して、発信要求を行った移動通信端末５０ｂに係る呼情報を要求する呼情報取得要求が行われる（Ｓ５１、取得ステップ）。呼処理管理用データベース１０では、呼情報取得要求が受信される。続いて、当該移動通信端末５０ｂに係る呼情報が読み出されて、呼処理管理用データベース１０から呼処理サーバ２０ｂに呼情報取得応答として送信される。呼処理サーバ２０ｂでは、取得部２２によって呼情報が受信される（Ｓ５２、取得ステップ）。ここで取得される呼情報は、待受中である旨の情報を含む呼情報である。ここで、当該呼処理サーバ２０ｂは、呼処理の状態を示すステート情報や移動通信端末５０ｂに係る加入者プロファイルを含む呼情報を保持した状態となる。受信された呼情報は、取得部２２から呼処理部２３に出力される。

続いて、呼処理部２３によって、取得部２２によって取得された呼情報に基づいて、発信要求に係る呼処理が実行される（Ｓ５３、呼処理ステップ）。ここでの呼処理は呼接続を確立するための発信処理であり、他のサーバとの間で呼接続を確立する発信シーケンスに沿って処理が行われる。呼処理部２３による呼処理によって呼接続が確立されると、当該移動通信端末５０ｂは通信中の状態となり、呼情報に含まれる移動通信端末５０ｂの通信状態も通信中に状態遷移される。呼処理部２３によって行われた呼処理の結果の情報（通信中に状態遷移された呼情報）は、呼処理部２３から呼処理結果格納部２４に出力される。

続いて、呼処理の結果が反映された呼情報が、呼処理結果格納部２４から呼処理管理用データベース１０に呼情報更新要求として送信される（Ｓ５４、呼処理結果格納ステップ）。呼処理管理用データベース１０では、呼情報更新要求が受信されて、当該移動通信端末５０ｂに係る情報が受信した情報で更新される。即ち、更新後の呼情報は通信中である旨の情報を含む。更新が行われると、呼情報更新応答が呼処理管理用データベース１０から呼処理サーバ２０ｂに送信される（Ｓ５５）。呼処理サーバ２０ｂでは、呼情報更新応答が受信されると、発信応答がオープンフローネットワーク３０を介して発信要求を行った移動通信端末５０ｂに送信される（Ｓ５６）。以上が、呼処理サーバ２０ｂが増設されてスケールアウトされた時に発信が行われる場合の処理である。

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

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

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

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

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

上述した実施形態では、移動通信端末に移動体通信の機能を提供する移動体通信システムであるものとしたが、本発明は、必ずしも移動体通信システムである必要はない。本発明は、固定の通信端末に固定通信の機能を提供する固定通信システムに適用することが可能である。固定の通信端末と固定通信システムとは、上述した移動体通信システムとは異なり、有線で接続されている。上述した実施形態を、移動通信端末を固定通信端末と、移動体通信を固定通信と、移動体通信システムを固定通信システムとそれぞれ置き換えることで本発明に係る固定通信システムの実施形態とすることができる。但し、この場合、具体的なノードは固定通信システムに応じたものである。また、上述した実施形態における在圏エリア等の移動体通信に特有の情報は、固定通信システムにおいては不要である。また、移動体通信と固定通信とが混在した通信システムにおいて本発明を実施することも可能である。

即ち、本発明は、移動通信端末、移動体通信及び移動体通信システムに限られるものではなく、上述した実施形態と同様の枠組みを有するものであれば、任意の通信端末、任意の通信、及び任意の通信システムに適用することが可能である。

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

Claims (10)

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

Images