移動体通信ゲートウェイ装置及び移動体通信ゲートウェイ制御方法
【課題】パケット順序の逆転及びパケットのロスが発生した場合であっても、現用系と予備系との各呼状態の同期を維持する移動体通信ゲートウェイを提供する。
【解決手段】端末を接続する第１のノードから通信サービスを提供する第２のノードへ、ユーザトラフィックを転送する移動体通信ゲートウェイ装置であって、スイッチ部は、第１のノードから送信された呼処理パケットを複製し、一方を、第１の呼処理パケットとし、他方を第２の呼処理パケットとし、第１の呼処理パケットを、現用系の呼処理部に送信し、第２の呼処理パケットを、予備系の呼処理部に送信し、現用系から送信された第１の呼処理パケットを第１のノードに送信し、予備系から送信された第２の呼処理パケットを廃棄し、第１及び第２の呼処理パケットの送受信の状態に基づいて、現用系の呼状態と予備系の呼状態とが一致するか否かを検出する。
【解決手段】端末を接続する第１のノードから通信サービスを提供する第２のノードへ、ユーザトラフィックを転送する移動体通信ゲートウェイ装置であって、スイッチ部は、第１のノードから送信された呼処理パケットを複製し、一方を、第１の呼処理パケットとし、他方を第２の呼処理パケットとし、第１の呼処理パケットを、現用系の呼処理部に送信し、第２の呼処理パケットを、予備系の呼処理部に送信し、現用系から送信された第１の呼処理パケットを第１のノードに送信し、予備系から送信された第２の呼処理パケットを廃棄し、第１及び第２の呼処理パケットの送受信の状態に基づいて、現用系の呼状態と予備系の呼状態とが一致するか否かを検出する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、移動体通信ゲートウェイ装置の呼処理部を並列多重処理方式によって冗長化する技術に関する。
【背景技術】
【０００２】
３ＧＰＰ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）のＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）に代表される第３．９世代移動体通信網では、ネットワークは、すべてＩＰ化される。このため、従来は回線交換網によって提供されてきた電話サービスがＩＰ網によって提供されるようになる。したがって、今後は移動体通信ゲートウェイにも電話交換機と同程度の高信頼性が要求されるようになる。
【０００３】
ネットワーク装置を高信頼化する方式には、並列多重処理方式及び待機冗長方式がある。並列多重処理方式は、現用系の装置と予備系の装置とが並列に処理を実行する。待機冗長方式は、１台の現用系の装置が処理を実行し、現用系の装置が故障した場合、予備系の装置が処理を引き継ぐ。
【０００４】
並列多重処理方式は、現用系から予備系に系切替えを実行する場合、予備系の起動処理が不要であるので、系切替えのための時間を短縮することができる。しかしながら、並列多重処理方式は、正常稼働時にも計算リソースを多く消費する。このため、並列多重処理方式は、比較的処理が単純であり、高速な系切替えが要求される信号処理装置などに利用されている。
【０００５】
例えば、ＡＴＭ（Ａｓｙｎｃｈｒｏｎｏｕｓ Ｔｒａｎｓｆｅｒ Ｍｏｄｅ）セル伝送装置を二重化（冗長化）する場合、現用系と予備系との同期を短時間で確立し、無瞬断で系切替えを実行するための技術が提案されている（例えば、特許文献１参照）。また、電話交換機の信号処理部を二重化する場合、現用系と予備系との同期を確立するために用いられる交絡信号数を削減する技術が提案されている（例えば、特許文献２参照）。
【０００６】
一方、待機冗長方式は、現用系から予備系に系切替えを実行する場合、予備系の起動処理に時間を要するが、正常稼働時は１台の現用系のみが処理を実行するので、計算リソースを有効に活用することができる。このため、待機冗長方式は、処理が複雑であり、比較的長い時間を要する系切替えが許容される、ＯＳＩ（Ｏｐｅｎ Ｓｙｓｔｅｍｓ Ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ）第３層以上のネットワーク装置などに広く利用されている。
【０００７】
例えば、待機冗長方式を利用したルータにおいて、現用系ルータが作成したルーティングテーブルを予備系ルータに常時転写することによって、系切替え時のルーティングテーブルの再計算処理を不要とする技術が提案されている（例えば、特許文献３参照）。また、待機冗長方式の一種であるＮ対１予備構成に基づく電話交換機の呼制御処理部が提案されている（例えば、非特許文献１参照）。非特許文献１に記載された電話交換機の呼制御処理部には待機冗長方式が採用されているが、呼制御処理部は、現用系と予備系との共有メモリを利用し、呼状態を引き継ぐことができるので、短時間で系切替えを実行することができる。
【０００８】
ここで、移動体通信ゲートウェイは、一般的に、ＡＴＣＡ（Ａｄｖａｎｃｅｄ Ｔｅｌｅｃｏｍ Ｃｏｍｐｕｔｉｎｇ Ａｒｃｈｉｔｅｃｔｕｒｅ）などの汎用装置に実装されるので、待機冗長方式を採用する場合、共有メモリを設けることによって、系切替えを高速化することが困難である。そこで、通常は、例えば、特許文献３に記載された技術によって、ネットワークを経由して、現用系が作成した呼状態（端末接続情報）を現用系から予備系に常時転写する。
【０００９】
しかしながら、現用系から予備系に呼状態を転写する場合、現用系に余分な転送負荷がかかる。さらに、現用系の故障の状態によっては呼状態を現用系から予備系に完全に転写できないまま、系切替えが実行されてしまう可能性がある。
【００１０】
また、ＯＳＩ第４層のプロトコル（例えば、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）、ＳＣＴＰ（Ｓｔｒｅａｍ Ｃｏｎｔｒｏｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｐｒｏｔｏｃｏｌ）など）は、通常ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）内に実装される。このため、ＴＣＰ／ＳＣＴＰコネクションの状態、及び呼処理アプリケーションが管理する呼状態を一の処理で転写することは難しい。また、系切替え時において、ＴＣＰ／ＳＣＴＰコネクション情報を引継がずに、動的にＴＣＰ／ＳＣＴＰコネクションが再確立されると、系切替え時間が増大してしまう。
【００１１】
そこで、近年では、これらの問題を解決するため、ＯＳＩ第３層以上の処理を実行するネットワーク装置にも並列多重処理方式を適用することが検討されている。
【００１２】
例えば、並列多重処理方式によって冗長化されたルータの経路制御モジュールにおいて、現用系と予備系とが互いの処理状況を把握するために、予備系が処理した経路制御パケットの識別子を現用系に通知する技術が提案されている（例えば、特許文献４参照）。
【００１３】
また、複雑なフロー状態を管理するルータクラスタにおいて、フロー状態の転写の負荷を軽減するために、現用系ルータと予備系ルータとが二重にパケット処理を実行する技術が提案されている（例えば、非特許文献２参照）。
【００１４】
また、冗長化された各ＳＩＰサーバの間において、ＴＣＰ／ＳＣＴＰコネクション情報を引継ぐために、現用系と予備系とのＴＣＰ／ＳＣＴＰプロトコルスタックが並列にパケット処理を実行する技術が提案されている（例えば、非特許文献３参照）。
【先行技術文献】
【特許文献】
【００１５】
【特許文献１】特開平６−２３２８９２号公報
【特許文献２】特開２０００−３２５７４号公報
【特許文献３】特開２００２−８４３１３号公報
【特許文献４】特開２００５−３０３５０１号公報
【非特許文献】
【００１６】
【非特許文献１】山田喬彦、小川聡、須山正人、堀好徳、「ディジタル交換機用マルチプロセッサの故障処理」１９８８年３月、信学論（Ｂ）、Ｊ７１−Ｂ、３、ｐ．３３９−３４９
【非特許文献２】狩野秀一、地引昌弘、「ルータクラスタにおける二重パケット処理冗長方式」、２００５年１０月、信学論、Ｖｏｌ．Ｊ８８−Ｂ、Ｎｏ．１０、ｐ．１９５６−１９６７
【非特許文献３】狩野秀一、地引昌弘、「トランスポート端点のポータブルなクラスタ方式」、２００７年５月、信学技法、ＩＡ２００７−２、ｐ．５−１０
【発明の概要】
【発明が解決しようとする課題】
【００１７】
移動体通信ゲートウェイは、移動端末の接続状態を管理する呼処理部と、呼処理部によって作成されたパス情報に基づいて、ユーザトラフィックを転送するパケット転送部と、を備える。呼処理部は大量の呼状態（端末接続情報）を管理する。また、一部の呼処理プロトコルにＳＣＴＰが利用される。このため、移動体通信ゲートウェイに並列多重処理方式を適用することが検討されている。
【００１８】
しかしながら、特許文献１〜２、４及び非特許文献３〜４に記載された技術によっては、移動体通信ゲートウェイが備える呼処理部に並列多重処理方式を適用することはできない。以下に示す理由のためである。
【００１９】
まず、移動体通信ゲートウェイは、一般的にＥｔｈｅｒｎｅｔ(登録商標、以下同じ）等の信頼性の低い回線によって、現用系と予備系との間、又はこれらと外部装置との間が接続される。このため、現用系と予備系とのどちらか一方で呼処理パケットが欠落する可能性がある。この場合、現用系と予備系との各呼状態がずれるが、非特許文献３〜４に記載された技術のように、現用系と予備系との各呼状態を同期させないで、現用系と予備系とを並列に動作させると、現用系と予備系との各呼状態に不一致が発生し、発生した不一致が移動体通信ゲートウェイに認識されずに呼処理が継続されてしまう問題がある。
【００２０】
また、移動体通信ゲートウェイの呼処理部は、ハードウェア及びソフトウェアによって、多段のキューを経由し、パケットを処理する。また、ソフトウェアがマルチスレッドの構成である場合、複数のパケットを並列に処理する。このため、パケットの順序が容易に逆転する。よって、特許文献１〜２に記載された、現用系と予備系との間に比較回路又は交絡信号を設けた構成によっては、現用系と予備系との各呼状態の不一致を検出することができず、また、不一致となった各呼状態を再同期することができない。
【００２１】
また、移動体通信ゲートウェイにおいて、１つの呼処理パケットが欠落しても、わずか１ユーザの接続情報が失われるだけであるので、欠落した呼処理パケットに対応する各呼状態のみを再同期し、呼処理を継続することが望ましい。しかし、特許文献４に記載された技術によっては、現用系と予備系のとの各呼状態がずれてしまった場合、このずれた各呼状態のみを再同期することができない。特許文献４に記載された技術では、呼状態の不一致が発生した場合、直ちに系切替えを実行しなければならないためである。
【００２２】
本発明は、前述した問題に鑑みてなされたものであり、並列多重方式によって冗長化され、パケット順序の逆転及びパケットのロスが発生した場合であっても、現用系と予備系との各呼状態の同期を維持することができる移動体通信ゲートウェイを提供することを目的とする。
【課題を解決するための手段】
【００２３】
本発明の代表的な一例を示せば以下のとおりである。すなわち、端末を接続する第１のノードから前記端末に通信サービスを提供する第２のノードへ、前記端末が送受信するユーザトラフィックを転送する移動体通信ゲートウェイ装置であって、前記第１のノードによって、所定の呼処理プロトコルを用いて送信された呼処理パケットに基づいて、前記端末の接続情報を示す呼状態を作成する少なくとも二つ以上の呼処理部と、前記第１のノードと前記呼処理部との間で前記呼処理パケットを転送するスイッチ部と、を備え、前記スイッチ部は、前記第１のノードから送信された前記呼処理パケットを受信すると、前記受信した呼処理パケットを複製し、その一方を、第１の呼処理パケットとし、他方を第２の呼処理パケットとし、前記第１の呼処理パケットを、現用系の前記呼処理部に送信し、前記第２の呼処理パケットを、予備系の前記呼処理部に送信し、前記現用系の呼処理部から送信された前記第１の呼処理パケットを受信すると、前記受信した第１の呼処理パケットを前記第１のノードに送信し、前記予備系の呼処理部から送信された前記第２の呼処理パケットを受信すると、前記受信した第２の呼処理パケットを前記第１のノードに送信しないで廃棄し、前記第１及び第２の呼処理パケットの送受信の状態を記憶し、前記記憶された第１及び第２の呼処理パケットの送受信の状態に基づいて、前記現用系の呼処理部によって作成される呼状態と前記予備系の呼処理部によって作成される呼状態とが一致するか否かを検出することを特徴とする。
【発明の効果】
【００２４】
本発明の一実施形態によれば、移動体通信ゲートウェイ装置の呼処理部を並列多重方式によって冗長化する場合、パケットの順序の逆転及びパケットのロスが発生しても、現用系と予備系と間で呼状態の同期を維持することができる。
【図面の簡単な説明】
【００２５】
【図１Ａ】本発明の第１の実施形態のサービス網ゲートウェイの構成を示すブロック図である。
【図１Ｂ】本発明の第２の実施形態のサービス網ゲートウェイの構成を示すブロック図である。
【図２】本発明の第１の実施形態のネットワークの構成を示す説明図である。
【図３】本発明の第１の実施形態のサービス網ゲートウェイのハードウェアの構成を示すブロック図である。
【図４】本発明の第１の実施形態の呼処理管理テーブルの構成を示す説明図である。
【図５】本発明の第１の実施形態の呼状態管理テーブルの構成を示す説明図である。
【図６Ａ】本発明の第１の実施形態のＧＴＰ−Ｃセッション管理テーブルの構成を示す説明図である。
【図６Ｂ】本発明の第１の実施形態のＧＴＰ−Ｃトランザクション管理テーブルの構成の例を示す説明図である。
【図７】本発明の第１の実施形態のＧＴＰ−Ｃトランザクション状態遷移を示す説明図である。
【図８】本発明の第１の実施形態のサービス網ゲートウェイが端末を接続する場合の正常系コールフローを示す説明図である。
【図９】本発明の第１の実施形態のサービス網ゲートウェイが端末を接続する場合の準正常系コールフローを示す説明図である。
【図１０】本発明の第１の実施形態のサービス網ゲートウェイが端末を切断する場合のコールフローを示す説明図である。
【図１１】本発明の第１の実施形態のサービス網ゲートウェイが現用系の呼処理部から予備系の呼処理部へ系切替えを実行する場合のコールフローを示す説明図である。
【図１２】本発明の第１の実施形態のＧＴＰ−Ｃパケット転送ルーチンを示すフローチャートである。
【図１３】本発明の第１の実施形態の呼識別子抽出ルーチンを示すフローチャートである。
【図１４】本発明の第２の実施形態の呼処理管理テーブルの構成を示す説明図である。
【図１５】本発明の第２の実施形態の呼状態管理テーブルの構成を示す説明図である。
【図１６Ａ】本発明の第２の実施形態のＧＴＰ−Ｃセッション管理テーブルの構成を示す説明図である。
【図１６Ｂ】本発明の第２の実施形態のＧＴＰ−Ｃトランザクション管理テーブルの構成を示す説明図である。
【図１６Ｃ】本発明の第２の実施形態のＧＴＰ−Ｃパス管理テーブルの構成を示す説明図である。
【図１７】本発明の第２の実施形態のＵＤＰ管理テーブルの構成を示す説明図である。
【図１８】本発明の第２の実施形態のサービス網ゲートウェイを起動する場合、及びサービス網ゲートウェイが端末を接続する場合のコールフローを示す説明図である。
【図１９】本発明の第２の実施形態のサービス網ゲートウェイの現用系の呼処理部に障害が発生した場合のコールフローを示す説明図である。
【図２０】本発明の第２の実施形態のサービス網ゲートウェイの予備系の呼処理部に障害が発生した場合のコールフローを示す説明図である。
【図２１】本発明の第２の実施形態のＧＴＰ−Ｃパケット転送ルーチンを示すフローチャートである。
【図２２】本発明の第２の実施形態のＧＴＰ−Ｃパケット転送ルーチンを示すフローチャートである。
【発明を実施するための形態】
【００２６】
以下、図面を用いて本発明の実施形態について説明する。なお、以下では、主に３ＧＰＰのＬＴＥに用いられる移動体通信ゲートウェイ（サービス網ゲートウェイ）について説明するが、本発明は、ＬＴＥに用いられる移動体通信ゲートウェイに限定されない。本発明は、ＬＴＥと同様の、他のアクセス網に用いられる移動体通信ゲートウェイにも適用することができる。
【００２７】
［実施形態１］
以下、本発明の第１の実施形態について図面を参照して説明する。
【００２８】
第１の実施形態では、サービス網ゲートウェイは、現用系と予備系との呼処理のトランザクション状態を管理する呼処理同期状態管理部を備える。呼処理同期状態管理部は、呼処理のトランザクション状態に基づいて、現用系と予備系との各呼状態の不一致を検出し、不一致が検出された各呼状態を再同期する。
【００２９】
［１．ネットワークの構成］
図２は、本発明の第１の実施形態のネットワークの構成を示す説明図である。
【００３０】
本発明の第１の実施形態のネットワーク（移動体通信網）は、サービス網１、ユーザホーム網２、無線アクセス網３及び無線アクセス網４を備える。
【００３１】
無線アクセス網３は、端末５を収容するためのネットワークであり、基地局３１Ａ、３１Ｂ、移動管理サーバ３２及びアクセスゲートウェイ３３を備え、例えば、無線インタフェースを介してデータ通信をする端末５に接続する。
【００３２】
基地局３１Ａ、３１Ｂは、基地局３１Ａ、３１Ｂと接続された端末５との間で、無線信号と有線信号とを相互に変換する。なお、図２では、例として、基地局を二つ図示したが、基地局は所要の数が備えられる。
【００３３】
アクセスゲートウェイ３３は、基地局３１Ａ、３１Ｂから受信したユーザトラフィックをユーザホーム網２に転送する。
【００３４】
また、移動管理サーバ３２は、端末５の接続状況を管理し、また、基地局３１Ａ、３１Ｂとアクセスゲートウェイ３３との間のパスを制御する。
【００３５】
無線アクセス網４は、無線アクセス網３と同じであり、基地局４１Ａ、４１Ｂ、移動管理サーバ４２及びアクセスゲートウェイ（ＡＧＷ：Ａｃｃｅｓｓ Ｇａｔｅｗａｙ）４３を備え、無線インタフェースを介して、データ通信をする端末を接続する。基地局４１Ａ、４１Ｂ、移動管理サーバ４２及びアクセスゲートウェイ４３は、各々、基地局３１Ａ、３１Ｂ、移動管理サーバ３２及びアクセスゲートウェイ３３と同じである。なお、図２では、例として、二つの無線アクセス網を図示したが、三つ以上の無線アクセス網が備えられてもよい。
【００３６】
ユーザホーム網２は、加入者情報を管理し、端末５をサービス網１に接続するためのネットワークであり、サービス網ゲートウェイ（ＳＮＧＷ：Ｓｅｒｖｉｃｅ Ｎｅｔｗｏｒｋ Ｇａｔｅｗａｙ）２１、ポリシーサーバ２２及び認証サーバ２３を備える。
【００３７】
サービス網ゲートウェイ２１は、アクセスゲートウェイ３３、４３から受信したユーザトラフィックを適切なサービス網１に転送する。また、ポリシーサーバ２２は、サービス網ゲートウェイ２１にユーザトラフィックの課金の情報及びＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）を通知する。また、認証サーバ２３は、ユーザ（端末５）の加入者情報を管理する。
【００３８】
サービス網１には、端末５にサービスを提供するためのネットワークであり、端末５にサービスを提供するアプリケーションサーバ１１を備える。
【００３９】
なお、ＬＴＥでは、基地局３１Ａ、３１Ｂ、４１Ａ、４１Ｂは、ｅＮＢ （ｅｖｏｌｖｅｄ Ｎｏｄｅ Ｂ）である。また、アクセスゲートウェイ３３、４３は、Ｓ−ＧＷ（Ｓｅｒｖｉｎｇ Ｇａｔｅｗａｙ）である。また、移動管理サーバ３２、４２は、ＭＭＥ（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）である。また、サービス網ゲートウェイ２１は、Ｐ−ＧＷ（Ｐａｃｋｅｔ Ｄａｔａ Ｎｅｔｗｏｒｋ Ｇａｔｅｗａｙ）である。また、ポリシーサーバ２２は、ＰＣＲＦ（Ｐｏｌｉｃｙ ａｎｄ Ｃｈａｒｇｉｎｇ Ｒｕｌｅｓ Ｆｕｎｃｔｉｏｎ）である。また、認証サーバ２３は、ＨＳＳ（Ｈｏｍｅ Ｓｕｂｓｃｒｉｂｅｒ Ｓｅｒｖｅｒ）である。
【００４０】
以下に、サービス網ゲートウェイ２１の構成及び処理について説明する。なお、ＬＴＥでは、サービス網ゲートウェイ２１とアクセスゲートウェイ３３、４３との間の呼処理プロトコルにＧＴＰ−Ｃを使用する。また、サービス網ゲートウェイ２１とポリシーサーバ２２との間の呼処理プロトコルにＤｉａｍｅｔｅｒを使用する。なお、本実施形態では、これらの呼処理プロトコルを使用する場合について説明するが、本発明はこれらの呼処理プロトコルに限定されず、他の呼処理プロトコルを使用してもよい。
【００４１】
［２．サービス網ゲートウェイ２１の構成］
図３は、本発明の第１の実施形態のサービス網ゲートウェイ２１のハードウェアの構成を示すブロック図である。
【００４２】
サービス網ゲートウェイ２１は、ＰＢ（Ｐａｙｌｏａｄ Ｂｌａｄｅ）＃１＿１００からＰＢ＃ｎ＿１００−ｎ、及びＳＷＢ（Ｓｗｉｔｃｈ Ｂｌａｄｅ）１２０を備える。ＰＢ＃１＿１００からＰＢ＃ｎ＿１００−ｎは、例えば、ブレードサーバであり、呼処理及びユーザトラフィック転送の機能を実現する。ＰＢ＃１＿１００からＰＢ＃ｎ＿１００−ｎは、それぞれ、同じである。
【００４３】
ＰＢ＃１＿１００は、ＦＲＯＭ１０１、ＣＰＵ１０２、メモリ１０３、及びＩＦ１０４、１０５を備え、これらはバス１０６を介して互いに接続される。ＦＲＯＭ１０１は、サービス網ゲートウェイ２１の機能を実現するためのプログラム、具体的には、例えば、呼処理部（ＡＣＴ）１５１又は呼処理部（ＳＢＹ）１５３（図１Ａ参照）が実行する処理のためのプログラムを格納する。ＣＰＵ１０２は、サービス網ゲートウェイ２１が起動した時に、ＦＲＯＭ１０１に格納されたプログラムをメモリ１０３に展開し、展開されたプログラムを順次読み出し、読み出されたプログラムを実行する。
【００４４】
ＩＦ１０４、１０５は、Ｅｔｈｅｒｎｅｔ回線を介して、ＳＷＢ１２０に接続される。なお、例えば、ＩＦ１０４は、データ通信用に使用され、ＩＦ１０５は、装置の制御用に使用されてもよい。
【００４５】
ＳＷＢ１２０は、例えば、ブレードサーバであり、Ｅｔｈｅｒｎｅｔのスイッチの機能を実現する。ＳＷＢ１２０は、ＩＦ１２３−１〜ｍ、ＩＦ１２２−１〜２ｎ、スイッチ部１２１、ＦＲＯＭ１２４、ＣＰＵ１２５、及びメモリ１２６を備える。ＩＦ１２３−１〜ｍは、外部装置に接続される。ＩＦ１２２−１〜２ｎは、ＰＢ＃１＿１００〜ＰＢ＃ｎ＿１００−ｎに接続される。スイッチ部１２１は、各ＩＦを介して、パケットを中継する。
【００４６】
また、ＦＲＯＭ１２４、ＣＰＵ１２５、及びメモリ１２６は、スイッチ部１２１が所定のルールに基づき抽出したパケットを処理する。具体的には、ＦＲＯＭ１２４は、呼処理同期状態管理部１５５（図１Ａ参照）が実行する処理のためのプログラムを格納する。ＣＰＵ１１２５は、ＦＲＯＭ１１２４に格納されたプログラムをメモリ１１２６に展開し、展開されたプログラムを順次読み出し、読み出されたプログラムを実行する。
【００４７】
［３．サービス網ゲートウェイ２１の冗長化］
図１Ａは、本発明の第１の実施形態のサービス網ゲートウェイ２１の構成を示すブロック図である。
【００４８】
ＰＢ＃１＿１００−１は、現用系であり、呼処理部（ＡＣＴ）１５１及びパケット転送部（ＡＣＴ）１５２を備える。ＰＢ＃２＿１００−２は、予備系であり、呼処理部（ＳＢＹ）１５３及びパケット転送部（ＳＢＹ）１５４（休止中）を備える。
【００４９】
呼処理部（ＡＣＴ）１５１と呼処理部（ＳＢＹ）１５３とは、並列多重処理方式によって冗長化される。つまり、サービス網ゲートウェイ２１は、現用系の呼処理部（ＡＣＴ）１５１及び予備系の呼処理部（ＳＢＹ）１５３を、それぞれ、ＰＢ＃１＿１００−１及びＰＢ＃２＿１００−２において独立に動作させる。そして、ＳＷＢ１２０は、並列多重処理を実現するため、他ノード（ＡＧＷ３３、４３等）から送信された呼処理パケットを受信し、受信した呼処理パケットを少なくとも一つ複製し、これらの呼処理パケットをそれぞれ、呼処理部（ＡＣＴ）１５１及び呼処理部（ＳＢＹ）１５３に転送する。
【００５０】
また、呼処理部（ＡＣＴ）１５１及び呼処理部（ＳＢＹ）１５３の双方は、サービス網ゲートウェイ２１から他ノード（ＡＧＷ３３、４３等）に送信する呼処理パケットをＳＷＢ１２０に送信する。ただし、ＳＷＢ１２０は、呼処理部（ＡＣＴ）１５１から送信された呼処理パケットのみを他ノードに転送し、呼処理部（ＳＢＹ）１５３から送信された呼処理パケットを転送せずに廃棄する。
【００５１】
一方、パケット転送部（ＡＣＴ）１５２、及びパケット転送部（ＳＢＹ）１５４は、１対１待機冗長方式によって、冗長化される。つまり、現用系のパケット転送部（ＡＣＴ）１５２は、ＰＢ＃１＿１００−１で動作し、予備系のパケット転送部（ＳＢＹ）１５４は、ＰＢ＃２＿１００−２で動作する。他ノードから転送されたユーザトラフィックは、ＳＷＢ１２０を経由して、パケット転送部（ＡＣＴ）１５２に転送される。
【００５２】
ＳＷＢ１２０は、呼処理同期状態管理部１５５を備える。呼処理同期状態管理部１５５は、呼処理部（ＡＣＴ）１５１と呼処理部（ＳＢＹ）１５３との各呼状態の同期を管理する。ＳＷＢ１２０のＣＰＵ１２５は、メモリ１２６に格納されたプログラムによって、呼処理同期状態管理部１５５の処理を実行する。
【００５３】
また、呼処理同期状態管理部１５５は、呼処理部（ＡＣＴ）１５１と呼処理部（ＳＢＹ）１５３との呼処理のトランザクション状態を管理することによって、呼状態の同期を管理する。具体的には、呼処理同期状態管理部１５５は、一定時間が経過しても呼処理のトランザクション状態が所定の状態にならない場合、同期していない呼の識別子を呼処理部（ＳＢＹ）１５３に通知する。これによって、呼処理同期状態管理部１５５は、呼処理部（ＡＣＴ）１５１及び呼処理部（ＳＢＹ）１５３のいずれか一方のみで、呼処理パケットが消失し、各呼処理部の呼状態が一致しなくなった場合であっても、各呼状態の不一致を検出し、不一致が検出された各呼状態を同期させることができる。呼処理同期状態管理部１５５の処理の詳細については、図４から図１３を用いて後述する。
【００５４】
［４．呼処理管理テーブル３００］
［４−１．呼処理管理テーブル３００の構成］
呼処理同期状態管理部１５５は、呼処理管理テーブル３００を備える。なお、呼処理管理テーブル３００は、ＳＷＢ１２０のメモリ１２６に格納される。以下に、呼処理管理テーブル３００の構成について、図４から６を用いて説明する。
【００５５】
図４は、本発明の第１の実施形態の呼処理管理テーブル３００の構成を示す説明図である。
【００５６】
呼処理管理テーブル３００は、呼状態管理テーブル３１０、呼処理プロトコル管理テーブル３２０及びトランスポートプロトコル管理テーブル３３０を含む。
【００５７】
呼状態管理テーブル３１０は、呼処理プロトコルに依存しないサービス網毎、ユーザ毎の接続状況を管理するためのテーブルである。呼状態管理テーブル３１０の具体的な構成の例については、図５を用いて後述する。
【００５８】
呼処理プロトコル管理テーブル３２０は、本実施形態において呼処理プロトコルとして用いられるＧＴＰ−Ｃ、Ｄｉａｍｅｔｅｒなどの呼処理プロトコル状態を管理するためのテーブルである。呼処理プロトコル管理テーブル３２０は、呼処理プロトコル毎に定義され、例えば、ＧＴＰ−Ｃ管理テーブル３２１、Ｄｉａｍｅｔｅｒ管理テーブル３２２などを含む。
【００５９】
ＧＴＰ−Ｃ管理テーブル３２１は、ＧＴＰ−Ｃプロトコルの呼処理プロトコル状態を管理するためのテーブルであり、ＧＴＰ−Ｃセッション管理テーブル３２１−１、及びＧＴＰ−Ｃトランザクション管理テーブル３２１−２を含む。なお、ＧＴＰ−Ｃ管理テーブル３２１の具体的な構成の例については、図６Ａから図６Ｂを用いて後述する。
【００６０】
また、Ｄｉａｍｅｔｅｒ管理テーブル３２２は、Ｄｉａｍｅｔｅｒプロトコルの呼処理プロトコル状態を管理するためのテーブルであり、Ｄｉａｍｅｔｅｒセッション管理テーブル３２２−１、及びＤｉａｍｅｔｅｒトランザクション管理テーブル３２２−２を含む。
【００６１】
なお、前述した呼状態管理テーブル３１０及び呼処理プロトコル管理テーブルは、呼処理部（ＡＣＴ）１５１及び呼処理部（ＳＢＹ）１５３が備える呼状態及び呼処理プロトコルを管理するためのテーブル（図示省略）の一部である。
【００６２】
トランスポートプロトコル管理テーブル３３０は、ＳＣＴＰなどのトランスポートプロトコルの状態を管理するためのテーブルであり、トランスポートプロトコル毎に定義され、例えば、ＳＣＴＰ管理テーブル３３２を含む。ＳＣＴＰ管理テーブル３３２は、具体的には、送信元ＩＰアドレス、送信元ポート番号、宛先ＩＰアドレス、宛先ポート番号、コネクション状態、ストリーム情報、シーケンス番号などを含む。なお、ＧＴＰ−Ｃでは、トランスポートプロトコルとしてＵＤＰが使用されるが、ＵＤＰはコネクションレスであるので、本実施形態はＵＤＰの状態を管理しなくてもよい。
【００６３】
［４−２．呼状態管理テーブル３１０の構成］
図５は、本発明の第１の実施形態の呼状態管理テーブル３１０の構成を示す説明図である。
【００６４】
呼状態管理テーブル３１０は、呼識別子３６１、ベアラ情報（ＧＴＰ−Ｕエンドポイント情報）３６２及び呼処理プロトコル管理テーブルへのポインタ３６３を含む。
【００６５】
呼識別子３６１は、例えば、端末５が接続するサービス網を識別するためのサービス網ＩＤ３６１Ａと、端末５を識別するためのユーザＩＤ３６１Ｂと、の組み合わせである。
【００６６】
ベアラ情報３６２は、各呼識別子に対して一つ以上設定されるベアラ情報（ＧＴＰ−Ｕエンドポイント情報）である。ここで、ＧＴＰ−Ｕエンドポイント情報とは、ユーザトラフィックを転送するために設定される仮想トンネル（ＧＴＰ−Ｕトンネル）の端点のＩＰアドレスと、ＧＴＰ−Ｕトンネルを識別するためのＧＴＰ−ＵトンネルＩＤとの組み合わせである。
【００６７】
具体的には、ベアラ情報３６２は、各ベアラについて、ベアラを識別するためのベアラＩＤ３６２Ａ、アクセスゲートウェイ３３のＧＴＰ−Ｕエンドポイント情報３６２Ｂ、呼処理部（ＡＣＴ）１５１が割り当てるパケット転送部（ＡＣＴ）１５２のＧＴＰ−Ｕエンドポイント情報３６２Ｃ、及び呼処理部（ＳＢＹ）１５３が割り当てるパケット転送部（ＳＢＹ）１５４のＧＴＰ−Ｕエンドポイント情報３６２Ｄを含む。
【００６８】
呼処理プロトコル管理テーブルへのポインタ３６３は、ＧＴＰ−Ｃセッション管理テーブル３２１−１及びＤｉａｍｅｔｅｒセッション管理テーブル３２２−１のエントリを呼び出すためのポインタである。
【００６９】
呼処理同期状態管理部１５５は、呼状態管理テーブル３１０の呼処理プロトコル管理テーブルへのポインタ３６３を参照することによって、呼処理プロトコルのトランザクション状態（各呼処理部の呼状態の不一致）がどの呼に影響するのかを容易に特定することができる。
【００７０】
また、呼処理同期状態管理部１５５は、呼処理部（ＡＣＴ）１５１から呼処理部（ＳＢＹ）１５３に系切替えが実行された場合、ベアラ情報３６２を参照し、ユーザトラフィックの転送先をパケット転送部（ＡＣＴ）１５２からパケット転送部（ＳＢＹ）１５４へ書き換える。これによって、サービス網ゲートウェイ２１は、ユーザトラフィックの転送処理を継続することができる。
【００７１】
［４−３．ＧＴＰ−Ｃ管理テーブル３２１の構成］
以下に、ＧＴＰ−Ｃ管理テーブル３２０について、図６Ａ及び図６Ｂを用いて説明する。
【００７２】
［４−３−１．ＧＴＰ−Ｃセッション管理テーブル３２１−１の構成］
図６Ａは、本発明の第１の実施形態のＧＴＰ−Ｃセッション管理テーブル３２１−１の構成を示す説明図である。
【００７３】
ＧＴＰ−Ｃセッション管理テーブル３２１−１は、ＧＴＰ−Ｃエンドポイント情報３７１、呼状態管理テーブルへのポインタ３７２、及びＧＴＰ−Ｃトランザクション管理テーブルへのポインタ３７３を含む。
【００７４】
ここで、ＧＴＰ−Ｃエンドポイント情報とは、呼処理パケット（例えば、ＬＥＴにおいては、ＧＴＰ−Ｃパケット）を転送するために設定される仮想トンネル（ＧＴＰ−Ｃトンネル）の端点のＩＰアドレスと、ＧＴＰ−Ｃトンネルを識別するためのＧＴＰ−ＣトンネルＩＤとの組み合わせである。
【００７５】
具体的には、ＧＴＰ−Ｃエンドポイント情報３７１は、アクセスゲートウェイ３３のＧＴＰ−Ｃエンドポイント情報３７１Ａ、呼処理部（ＡＣＴ）１５１のＧＴＰ−Ｃエンドポイント情報３７１Ｂ、呼処理部（ＳＢＹ）１５３のＧＴＰ−Ｃエンドポイント情報３７１Ｃを含む。
【００７６】
呼状態管理テーブルへのポインタ３７２は、呼状態管理テーブル３１０のエントリを呼び出すためのポインタである。ＧＴＰ−Ｃトランザクション管理テーブルへのポインタ３７３は、ＧＴＰ−Ｃトランザクション管理テーブル３２１−１のエントリを呼び出すためのポインタである。
【００７７】
呼処理同期状態管理部１５５は、ＧＴＰ−Ｃセッション管理テーブル３２１−１の呼状態管理テーブルへのポインタ３７２及びＧＴＰ−Ｃトランザクション管理テーブルへのポインタ３７３を参照することによって、呼処理プロトコルのトランザクション状態（各呼処理部の呼状態の不一致）がどの呼に影響するのかを容易に特定することができる。
【００７８】
また、呼処理同期状態管理部１５５は、呼処理部（ＡＣＴ）１５１から呼処理部（ＳＢＹ）１５３に系切替えが実行された場合、ＧＴＰ−Ｃエンドポイント情報３７１を参照し、呼処理パケット（ＧＴＰ−Ｃパケット）の転送先を呼処理部（ＡＣＴ）１５１から呼処理部（ＳＢＹ）１５３へ書き換える。つまり、ＧＴＰ−Ｃパケットの転送先であるＧＴＰ−Ｃエンドポイント情報を呼処理部（ＡＣＴ）のＧＴＰ−ＣトンネルＩＤから呼処理部（ＳＢＹ）のＧＴＰ−ＣトンネルＩＤに書き換える。これによって、サービス網ゲートウェイ２１は、ＧＴＰ−Ｃパケットの転送処理を継続することができる。
【００７９】
［４−３−２．ＧＴＰ−Ｃトランザクション管理テーブル３２１−２の構成］
図６Ｂは、本発明の第１の実施形態のＧＴＰ−Ｃトランザクション管理テーブル３２１−２の構成の例を示す説明図である。
【００８０】
ＧＴＰ−Ｃトランザクション管理テーブル３２１−２は、トランザクションＩＤ３８１、トランザクション状態３８２、及びＧＴＰ−Ｃセッション管理テーブルへのポインタ３８３を含む。トランザクションＩＤ３８１は、アクセスゲートウェイ３３によって割り当てられるＧＴＰ−ＣトランザクションＩＤであり、例えば、ＩＰアドレス、ＵＤＰポート番号、ＧＴＰ−Ｃシーケンス番号である。
【００８１】
トランザクション状態３８２は、呼処理部（ＡＣＴ）１５１と呼処理部（ＳＢＹ）１５３とのＧＴＰ−Ｃトランザクション状態（リクエスト／レスポンスの送受信状態）を示す状態変数である。なお、トランザクション状態３８２の遷移の例については、図７を用いて後述する。
【００８２】
ＧＴＰ−Ｃセッション管理テーブルへのポインタ３８３は、ＧＴＰ−Ｃセッション管理テーブル３２１−１のエントリを呼び出すためのポインタである。
【００８３】
呼処理同期状態管理部１５５は、ＧＴＰ−Ｃセッション管理テーブルへのポインタ３８３を参照することによって、呼処理プロトコルのトランザクション状態の不一致（各呼処理部の呼状態の不一致）がどの呼に影響するのかを容易に特定することができる。また、呼処理同期状態管理部１５５は、トランザクション状態３８２を参照することによって、呼処理部（ＡＣＴ）と呼処理部（ＳＢＹ）との各呼状態の不一致を判定することができる。
【００８４】
［５．ＧＴＰ−Ｃトランザクション状態の遷移］
図７は、本発明の第１の実施形態のＧＴＰ−Ｃトランザクション状態遷移５００を示す説明図である。
【００８５】
はじめに、トランザクション状態の初期状態は、「ＮＵＬＬ」である。次に、アクセスゲートウェイ３３から、ＧＴＰ−Ｃリクエスト受信イベント（Ｅ５０１）が通知されると、トランザクション状態は、「ＲＥＱ＿ＲＥＣＥＩＶＥＤ」に遷移する。また、「ＲＥＱ＿ＲＥＣＥＩＶＥＤ」に遷移すると、タイマＡが開始される。
【００８６】
次に、「ＲＥＱ＿ＲＥＣＥＩＶＥＤ」の後の状態遷移（Ｅ５０２〜Ｅ５０４）について説明する。まず、呼処理部（ＡＣＴ）１５１から、ＧＴＰ−Ｃレスポンス受信イベント（Ｅ５０２）が通知されると、トランザクション状態は、「ＡＣＴ＿ＲＳＰ＿ＳＥＮＴ」に遷移し、さらに、タイマＢが開始される。また、呼処理部（ＳＢＹ）１５３から、ＧＴＰ−Ｃレスポンス受信イベント（Ｅ５０３）が通知されると、トランザクション状態は、「ＳＢＹ＿ＲＳＰ＿ＳＥＮＴ」に遷移し、さらに、タイマＣが開始される。なお、呼処理部（ＡＣＴ）１５１及び呼処理部（ＳＢＹ）１５３のいずれのレスポンスも受信されないで、タイマＡの満了イベント（Ｅ５０４）が通知されると、トランザクション状態は、再び、「ＮＵＬＬ」にリセットされる。
【００８７】
次に、「ＡＣＴ＿ＲＳＰ＿ＳＥＮＴ」の後の状態遷移（Ｅ５０５〜Ｅ５０６）について説明する。まず、呼処理部（ＳＢＹ）１５３から、ＧＴＰ−Ｃレスポンス受信イベント（Ｅ５０５）が通知されると、トランザクション状態は、同期確立状態を示す「ＲＳＰ＿ＳＥＮＴ」に遷移し、再び、「ＮＵＬＬ」にリセットされる。また、呼処理部（ＳＢＹ）１５３からのレスポンスが受信されないで、タイマＢ満了イベント（Ｅ５０６）が通知されると、呼処理同期状態管理部１５５は、呼処理部（ＳＢＹ）１５３に同期確立要求を送信する。同期確立要求が送信されると、トランザクション状態は、同期確立開始を示す「ＳＹＮＣ＿ＳＴＡＲＴ」に遷移し、タイマＤが開始される。
【００８８】
次に、「ＳＢＹ＿ＲＳＰ＿ＳＥＮＴ」からの状態遷移（Ｅ５０７〜Ｅ５０８）について説明する。まず、呼処理部（ＡＣＴ）から、ＧＴＰ−Ｃレスポンス受信イベント（Ｅ５０７）が通知されると、トランザクション状態は、同期確立状態を示す「ＲＳＰ＿ＳＥＮＴ」に遷移し、再び、「ＮＵＬＬ」にリセットされる。また、呼処理部（ＡＣＴ）１５１からのレスポンスが受信されずに、タイマＣ満了イベント（Ｅ５０８）が通知されると、呼処理同期状態管理部１５５は、呼処理部（ＳＢＹ）１５３に同期確立要求を送信する（Ｅ５０８）。同期確立要求が送信されると、トランザクション状態は、同期確立開始を示す「ＳＹＮＣ＿ＳＴＡＲＴ」に遷移し、タイマＤが開始される。
【００８９】
最後に、「ＳＹＮＣ＿ＳＴＡＲＴ」の後の状態遷移（Ｅ５０９〜Ｅ５１０）について説明する。まず、呼処理部（ＳＢＹ）１５３から、同期完了通知受信イベント（Ｅ５０９）が通知されると、同期再確立に成功したと判定され、トランザクション状態は、再び、「ＮＵＬＬ」にリセットされる。また、呼処理部（ＳＢＹ）１５３からの同期完了通知が受信されないで、タイマＤ満了イベント（Ｅ５１０）が通知されると、同期再確立に失敗したと判定され、トランザクション状態は、「ＳＹＳＴＥＭ＿ＥＲＲＯＲ」に遷移する。
【００９０】
なお、トランザクション状態の状態変数（例えば、「ＮＵＬＬ」、「ＲＥＱ＿ＲＥＣＥＩＶＥＤ」など）は、図６Ｂに示したＧＴＰ−Ｃトランザクション管理テーブル３２１−２のトランザクション状態３８２に格納される。
【００９１】
［６．コールフロー］
以下に、図８から図１３を用いて、第１の実施形態におけるコールフローについて説明する。
【００９２】
［６−１．端末５接続時の正常系コールフロー］
図８は、本発明の第１の実施形態のサービス網ゲートウェイ２１が端末５を接続する場合の正常系コールフローを示す説明図である。
【００９３】
図８に示したコールフローでは、呼処理部（ＡＣＴ）１５１と呼処理部（ＳＢＹ）１５３との各呼状態の不一致は発生せず、正常に呼処理が実行される場合が示される。
【００９４】
はじめに、端末５は、基地局３１Ｂ、移動管理サーバ３２に接続要求を送信する（６０１）。接続要求には、ユーザＩＤが含まれる。次に、移動管理サーバ３２は、端末５から送信されたユーザＩＤを認証サーバ２３に転送する。認証サーバ２３は、ユーザ認証を実行する（６０２）。
【００９５】
次に、移動管理サーバ３２は、アクセスゲートウェイ３３にセッション確立要求を送信する（６０３）。セッション確立要求には、サービス網ＩＤ、ユーザＩＤ及びベアラＩＤが含まれる。ここで、移動管理サーバ３２は、認証サーバ２３から取得された、端末５の加入者情報に基づいて、接続先のサービス網ＩＤを指定する。また、移動管理サーバ３２は、端末５のユーザトラフィックを転送するために設定された仮想トンネルを識別するためのベアラＩＤを設定する。
【００９６】
なお、ベアラＩＤは、アクセスゲートウェイ３３とサービス網ゲートウェイ２１との間に設立される仮想トンネル（ＧＴＰ−Ｕトンネル）の端点の情報に対応付けられる。また、ベアラＩＤは、さらに、基地局３１Ｂとアクセスゲートウェイ３３との間に設定される仮想トンネルの端点の情報に対応付けられてもよい。
【００９７】
次に、アクセスゲートウェイ３３は、指定されたサービス網ＩＤに対応するサービス網ゲートウェイ２１にセッション確立要求を送信する（６０４）。セッション確立要求には、サービス網ＩＤ、ユーザＩＤ、アクセスゲートウェイ３３のＧＴＰ−ＣトンネルＩＤ、ベアラＩＤ、及びアクセスゲートウェイ３３のＧＴＰ−ＵトンネルＩＤが含まれる。
【００９８】
なお、このＧＴＰ−ＣトンネルＩＤは、端末５の呼処理のために、アクセスゲートウェイ３３とサービス網ゲートウェイ２１との間に設定された仮想トンネル（ＧＴＰ−Ｃトンネル）において、アクセスゲートウェイ３３側のＧＴＰ−Ｃエンドポイントを識別するための識別子である。
【００９９】
また、このＧＴＰ−ＵトンネルＩＤは、端末５のユーザトラフィックの転送のために、アクセスゲートウェイ３３とサービス網ゲートウェイ２１の間に設定された仮想トンネル（ＧＴＰ−Ｕトンネル）において、アクセスゲートウェイ３３側のＧＴＰ−Ｕエンドポイントを識別するための識別子である。ＧＴＰ−ＵトンネルＩＤは、前述したベアラＩＤに対応付けられる。
【０１００】
次に、セッション確立要求がサービス網ゲートウェイ２１に送信されると、まず、ＳＷＢ１２０内の呼処理同期状態管理部１５５は、セッション確立要求を受信する。そして、呼処理同期状態管理部１５５は、ＧＴＰ−Ｃパケット転送ルーチンＰ１＿８００（図１２参照）を実行する（６０５）。
【０１０１】
図１２は、本発明の第１の実施形態のＧＴＰ−Ｃパケット転送ルーチンＰ１＿８００を示すフローチャートである。
【０１０２】
はじめに、呼処理同期状態管理部１５５は、端末５を接続するための呼処理パケット（ＧＴＰ−Ｃパケット）の内容に基づいて、ＧＴＰ−Ｃトランザクション管理テーブル３２１−２を更新する（８０１）。次に、ＧＴＰ−Ｃセッション管理テーブル３２１−１を更新する（８０２）。次に、呼状態管理テーブル３１０を更新する（８０３）。
【０１０３】
そして、呼処理同期状態管理部１５５は、受信したＧＴＰ−Ｃパケットの送信元を判定する（８０４）。ステップ８０４において、送信元が他ノード（ＡＧＷ）であると判定された場合、呼処理同期状態管理部１５５は、受信したＧＴＰ−Ｃパケットを、呼処理部（ＡＣＴ）１５１及び呼処理部（ＳＢＹ）１５３の双方に転送する（８０５）。
【０１０４】
また、ステップ８０４において、送信元が呼処理部（ＡＣＴ）１５１であると判定された場合、呼処理同期状態管理部１５５は、受信したＧＴＰ−Ｃパケットを、他ノード（ＡＧＷ）に転送する（８０６）。また、ステップ８０４において、送信元が呼処理部（ＳＢＹ）１５３であると判定された場合、呼処理同期状態管理部１５５は、受信したＧＴＰ−Ｃパケットを転送せず、破棄する。
【０１０５】
なお、呼処理同期状態管理部１５５は、ステップ８０１に対応する処理として、ＧＴＰ−Ｃトランザクション管理テーブル３２１−２に新規エントリを追加し、追加された新規エントリのトランザクションＩＤ３８１に、アクセスゲートウェイ３３によって割り当てられた値を設定する。また、図７に示した状態遷移に従って、追加された新規エントリのトランザクション状態３８２に状態変数「ＲＥＱ＿ＲＥＣＥＩＶＥＤ」を設定する。また、追加された新規エントリのＧＴＰ−Ｃセッション管理テーブルへのポインタ３８３に、ＧＴＰ−Ｃセッション管理テーブル３２１−１へのポインタを設定する。
【０１０６】
また、呼処理同期状態管理部１５５は、ステップ８０２に対応する処理として、ＧＴＰ−Ｃセッション管理テーブル３２１−１に新規エントリを追加し、追加された新規エントリのＧＴＰ−Ｃエンドポイント情報（ＡＧＷ）３７１Ａに、アクセスゲートウェイ３３側のＧＴＰ−Ｃトンネルの端点の情報（ＧＴＰ−ＣトンネルＩＤ）を設定する。また、追加された新規エントリのＧＴＰ−Ｃトランザクション管理テーブルへのポインタ３７３に、ＧＴＰ−Ｃトランザクション管理テーブル３２１−２へのポインタを設定する。
【０１０７】
また、呼処理同期状態管理部１５５は、ステップ８０３に対応する処理として、呼状態管理テーブル３１０に新規エントリを追加し、追加された新規エントリのサービス網ＩＤ３６１Ａ、ユーザＩＤ３６１Ｂ、ベアラＩＤ３６２Ａ、ＧＴＰ−Ｕエンドポイント情報（ＡＧＷ）３６２Ｂのそれぞれに、アクセスゲートウェイ３３から送信されたサービス網ＩＤ、ユーザＩＤ、ベアラＩＤ、ＧＴＰ−ＵトンネルＩＤ（及びＩＰアドレス）を設定する。また、追加された新規エントリの呼処理プロトコル管理テーブルへのポインタ（ＧＴＰ）３６３Ａに、ＧＴＰ−Ｃセッション管理テーブル３２１−１へのポインタを設定する。
【０１０８】
また、呼処理同期状態管理部１５５は、ステップ８０５に対応する処理として、セッション確立要求を、呼処理部（ＡＣＴ）１５１及び呼処理部（ＳＢＹ）１５３の双方に転送する（図８の６０６−１、６０６−２）。
【０１０９】
図８のステップ６０５以降の説明に戻る。ＧＴＰ−Ｃパケット転送ルーチンＰ１＿８００が実行される（６０５）と、セッション確立要求がＰＢ＃１＿１００−１とＰＢ＃２＿１００−２の双方に転送される（６０６−１、６０６−２）。そして、ＰＢ＃１＿１００−１内の呼処理部（ＡＣＴ）１５１は、セッション確立要求に対応する呼処理を実行し、セッション確立応答（ＡＣＴ）をＳＷＢ１２０内の呼処理同期状態管理部１５５に送信する（６０７）。セッション確立応答（ＡＣＴ）には、呼処理部（ＡＣＴ）１５１のＧＴＰ−ＣトンネルＩＤ、ベアラＩＤ、及び呼処理部（ＡＣＴ）１５１のＧＴＰ−ＵトンネルＩＤが含まれる。
【０１１０】
ＧＴＰ−ＣトンネルＩＤは、端末５の呼処理のために、アクセスゲートウェイ３３とサービス網ゲートウェイ２１との間に設定された仮想トンネル（ＧＴＰ−Ｃ）において、サービス網ゲートウェイ２１側のＧＴＰ−Ｃエンドポイントを識別するための識別子である。
【０１１１】
また、ＧＴＰ−ＵトンネルＩＤは、端末５のユーザトラフィック転送のために確立された、アクセスゲートウェイ３３とサービス網ゲートウェイ２１の間に設定されるＧＴＰ−Ｕ仮想トンネルにおいて、サービス網ゲートウェイ２１側のＧＴＰ−Ｕエンドポイントを識別するためのＩＤである。
【０１１２】
次に、ＳＷＢ１２０内の呼処理同期状態管理部１５５は、セッション確立応答（ＡＣＴ）を受信する（６０７）と、再び、ＧＴＰ−Ｃパケット転送ルーチンＰ１＿８００を実行する（６０８）。なお、この場合、呼処理同期状態管理部１５５は、図１２のステップ８０１に対応する処理として、ステップ６０５において、ＧＴＰ−Ｃトランザクション管理テーブル３２１−２に新規に追加されたエントリのトランザクション状態３８２を「ＡＣＴ＿ＲＳＰ＿ＳＥＮＴ」に更新する。
【０１１３】
また、呼処理同期状態管理部１５５は、図１２のステップ８０２に対応する処理として、ステップ６０５において、ＧＴＰ−Ｃセッション管理テーブル３２１−１に新規に追加されたエントリのＧＴＰ−Ｃエンドポイント情報（呼処理部（ＡＣＴ））３７１Ｂに、呼処理部（ＡＣＴ）１５１から送信されたＧＴＰ−ＣトンネルＩＤを設定する。
【０１１４】
また、呼処理同期状態管理部１５５は、図１２のステップ８０３に対応する処理として、ステップ６０５において、呼状態管理テーブル３１０に新規に追加されたエントリのＧＴＰ−Ｕエンドポイント情報３６２Ｃに、呼処理部（ＡＣＴ）１５１から送信されたＧＴＰ−ＵトンネルＩＤを設定する。
【０１１５】
また、呼処理同期状態管理部１５５は、ステップ８０６に対応する処理として、呼処理部（ＡＣＴ）１５１から送信されたセッション確立応答（ＡＣＴ）をアクセスゲートウェイ３３に転送する（６０９）。
【０１１６】
次に、ＰＢ＃２＿１００−２内の呼処理部（ＳＢＹ）１５３は、セッション確立要求（６０６−２）に対応する呼処理を実行し、セッション確立応答（ＳＢＹ）をＳＷＢ１２０内の呼処理同期状態管理部１５５に送信する（６１０）。
【０１１７】
このセッション確立応答（ＳＢＹ）には、呼処理部（ＳＢＹ）１５３のＧＴＰ−ＣトンネルＩＤ、ベアラＩＤ、及び呼処理部（ＳＢＹ）１５３のＧＴＰ−ＵトンネルＩＤが含まれる。なお、ＧＴＰ−ＣトンネルＩＤ及びＧＴＰ−ＵトンネルＩＤは、呼処理部（ＳＢＹ）１５３が割り当てる識別子であるので、ステップ６０７において、呼処理部（ＡＣＴ）１５１が割り当てる識別子とは異なる場合がある。
【０１１８】
次に、ＳＷＢ１２０内の呼処理同期状態管理部１５５は、セッション確立応答（ＳＢＹ）を受信する（６１０）と、再び、図１２に示したＧＴＰ−Ｃパケット転送ルーチンＰ１＿８００を実行する（６１１）。
【０１１９】
なお、この場合、呼処理同期状態管理部１５５は、図１２のステップ８０１に対応する処理として、ステップ６０５において、ＧＴＰ−Ｃトランザクション管理テーブル３２１−２に新規に追加されたエントリのトランザクション状態３８２を「ＲＳＰ＿ＳＥＮＴ」に更新する。なお、その後、トランザクション状態３８２が「ＮＵＬＬ」に更新されると、ＧＴＰ−Ｃトランザクション管理テーブル（３２１−２）から、ステップ６０５において追加されたエントリは削除される。
【０１２０】
また、呼処理同期状態管理部１５５は、図１２のステップ８０２に対応する処理として、ステップ６０５において、ＧＴＰ−Ｃセッション管理テーブル３２１−１に新規に追加されたエントリの、ＧＴＰ−Ｃエンドポイント情報（呼処理部（ＳＢＹ））３７１Ｃに、呼処理部（ＳＢＹ）から送信されたＧＴＰ−ＣトンネルＩＤを設定する。
【０１２１】
また、呼処理同期状態管理部１５５は、図１２のステップ８０３に対応する処理として、ステップ６０５において、呼状態管理テーブル３１０に新規に追加されたエントリのＧＴＰ−Ｕエンドポイント情報（パケット転送部（ＳＢＹ））３６２Ｄに、呼処理部（ＳＢＹ）１５３から送信されたＧＴＰ−ＵトンネルＩＤを設定する。
【０１２２】
なお、図１２のステップ８０４において、呼処理同期状態管理部１５５が受信したＧＴＰ−Ｃパケットの送信元は呼処理部（ＳＢＹ）１５３であると判定されるので、呼処理同期状態管理部１５５は、セッション確立応答（ＳＢＹ）をアクセスゲートウェイ３３に転送せず、廃棄する。
【０１２３】
次に、アクセスゲートウェイ３３は、セッション確立応答（ＡＣＴ）を受信する（６０９）と、受信したセッション確立応答を移動管理サーバ３２に送信する（６１２）。移動管理サーバ３２は、端末５に接続許可を送信する（６１３）。端末５は、移動管理サーバ３２に接続確認を送信する（６１４）。移動管理サーバ３２は、端末５から送信された接続確認を受信する（６１４）と、アクセスゲートウェイ３３にベアラ更新要求を送信する（６１５）。最後に、アクセスゲートウェイ３３は、移動管理サーバ３２にベアラ更新応答を送信する（６１６）。
【０１２４】
以上説明した処理によって、端末５の接続処理が完了し、端末５と、基地局３１Ｂと、アクセスゲートウェイ３３と、サービス網ゲートウェイ２１と、アプリケーションサーバ１１との間のユーザトラフィックの経路（パス）が確立する（６１７）。
【０１２５】
［６−２．端末５接続時の準正常系コールフロー］
図９は、本発明の第１の実施形態のサービス網ゲートウェイ２１が端末５を接続する場合の準正常系コールフローを示す説明図である。
【０１２６】
図９に示したコールフローでは、呼処理部（ＳＢＹ）１５３側のみで呼処理パケット（ＧＴＰ−Ｃパケット）が消失したため、呼処理部（ＡＣＴ）１５１と呼処理部（ＳＢＹ）１５３との各呼状態の不一致が発生するが、呼処理同期状態管理部１５５が各呼状態の不一致を検出し、各呼状態を再同期する場合が示される。
【０１２７】
はじめに、図８のステップ６０１から６０５に対応する処理が実行される。つまり、ＳＷＢ１２０内の呼処理同期状態管理部１５５は、セッション確立要求を受信すると、ＧＴＰ−Ｃパケット転送ルーチンＰ１＿８００を実行し、ＰＢ＃１＿１００−１内の呼処理部（ＡＣＴ）１５１及びＰＢ＃２＿１００−２内の呼処理部（ＳＢＹ）１５３の双方に、セッション確立要求を送信する（６３１−１、６３１−２）。
【０１２８】
ＰＢ＃１＿１００−１内の呼処理部（ＡＣＴ）１５１は、セッション確立要求に対応する呼処理を実行し、セッション確立応答（ＡＣＴ）をＳＷＢ１２０に送信する（６３２）。ＳＷＢ１２０内の呼処理同期状態管理部１５５は、セッション確立応答（ＡＣＴ）を受信すると、図１２に示したＧＴＰ−Ｃパケット転送ルーチンＰ１＿８００を実行する（６３３）。
【０１２９】
そして、呼処理同期状態管理部１５５は、セッション確立応答（ＡＣＴ）をアクセスゲートウェイ３３に送信する（６３４）。一方、ＰＢ＃２＿１００−２に送信されたセッション確立要求は消失した（６３１−２）ので、ＰＢ＃２＿１００−２内の呼処理部（ＳＢＹ）１５３からセッション確立応答が送信されない。このため、呼処理同期状態管理部１５５が管理するトランザクションの管理タイマ（図７のタイマＢ）が満了する（６３５）。タイマＢが満了すると、呼処理同期状態管理部１５５は、各呼状態に不一致が発生したと判定し、図１３に示す呼識別子抽出ルーチンＰ２＿８２０を実行する（６３６）。
【０１３０】
図１３は、本発明の第１の実施形態の呼識別子抽出ルーチンＰ２＿８２０を示すフローチャートである。
【０１３１】
はじめに、呼処理同期状態管理部１５５は、図６Ｂに示したＧＴＰ−Ｃトランザクション管理テーブル３２１−２のＧＴＰ−Ｃセッション管理テーブルへのポインタ３８３を参照して、各呼状態の不一致が発生しているＧＴＰ−Ｃセッション管理テーブル３２１−１のエントリを特定する（８２１）。次に、特定されたＧＴＰ−Ｃセッション管理テーブル３２１−１のエントリの呼状態管理テーブルへのポインタ３７２を参照し、各呼状態の不一致が発生している呼状態管理テーブル３１０のエントリを特定する（８２２）。特定されたエントリの呼識別子３６１を特定する（８２３）。以上の処理によって、呼識別子抽出ルーチンＰ２＿８２０が終了する。
【０１３２】
図９のステップ６３６以降の説明に戻る。ＳＷＢ１２０内の呼処理同期状態管理部１５５は、ステップ６３６の後、ＰＢ＃２＿１００−２内の呼処理部（ＳＢＹ）１５３に、同期要求を送信する（６３７）。なお、ステップ６３６は、図７に示した呼処理部（ＳＢＹ）１５３への同期要求の送信（Ｅ５０６）に対応する。この同期要求には、ステップ６３６で特定された呼識別子３６１（すなわち、サービス網ＩＤ３６１ＡとユーザＩＤ３６１Ｂとの組）が含まれる。
【０１３３】
次に、呼処理部（ＳＢＹ）１５３は、ＰＢ＃１＿１００−１内の呼処理部（ＡＣＴ）１５１に、呼状態要求を送信し、特定された呼識別子に対応する、呼処理部（ＡＣＴ）１５１の呼状態を問い合わせる（６３８）。呼処理部（ＡＣＴ）１５１は、呼処理部（ＳＢＹ）１５３に、呼状態応答を送信する（６３９）。
【０１３４】
呼処理部（ＳＢＹ）１５３は、呼処理部（ＳＢＹ）１５３が備える内部テーブル（図示省略）に、特定された呼識別子（サービス網ＩＤ及びユーザＩＤ）に対応するエントリを設定し、さらに、設定されたエントリに呼処理部（ＡＣＴ）１５１から送信された呼状態の情報（例えば、ＧＴＰ−ＣトンネルＩＤ及びＧＴＰ−ＵトンネルＩＤ）を設定する。その後、呼処理部（ＳＢＹ）１５３は、呼処理同期状態管理部１５５に、セッション確立応答（ＳＢＹ）を含む同期完了通知を送信する（６４０）。なお、ステップ６４０は、図７に示した呼処理部（ＳＢＹ）１５３からの同期完了の通知（Ｅ５０９）に対応する。
【０１３５】
以上の処理によって、呼処理同期状態管理部１５５は、各呼状態の不一致を検出し、各呼状態を再同期させることができる。
【０１３６】
［６−３．端末５切断時のコールフロー］
図１０は、本発明の第１の実施形態のサービス網ゲートウェイ２１が端末５を切断する場合のコールフローを示す説明図である。
【０１３７】
図１０に示したコールフローでは、正常に呼が切断され、呼処理管理テーブル３００から端末５の情報がすべて削除される場合が示される。
【０１３８】
はじめに、端末５は、基地局３１Ｂ及び移動管理サーバ３２に切断要求を送信する（６５１）。次に、移動管理サーバ３２は、アクセスゲートウェイ３３にセッション切断要求を送信する（６５２）。次に、アクセスゲートウェイ３３は、サービス網ゲートウェイ２１にセッション切断要求を送信する（６５３）。
【０１３９】
ＳＷＢ１２０内の呼処理同期状態管理部１５５は、セッション切断要求６５３を受信すると、図１２に示したＧＴＰ−Ｃパケット転送ルーチンＰ１＿８００を実行する（６５４）。ＧＴＰ−Ｃパケット転送ルーチンＰ１＿８００が実行されると、セッション切断要求が、ＰＢ＃１＿１００−１及びＰＢ＃２＿１００−２の双方に送信される（６５５−１、６５５−２）。
【０１４０】
ＰＢ＃１＿１００−１内の呼処理部（ＡＣＴ）１５１は、セッション切断要求（６５５−１）に対応する処理を実行し、ＳＷＢ１２０にセッション切断応答（ＡＣＴ）を送信する（６５６）。ＳＷＢ１２０内の呼処理同期状態管理部１５５は、セッション切断応答（ＡＣＴ）を受信すると、図１２に示したＧＴＰ−Ｃパケット転送ルーチンＰ１＿８００を再び実行する（６５７）。そして、ＧＴＰ−Ｃパケット転送ルーチンＰ１＿８００が実行されると、セッション切断応答（ＡＣＴ）がアクセスゲートウェイ３３に転送される（６５８）。
【０１４１】
また、ＰＢ＃２＿１００−２内の呼処理部（ＳＢＹ）１５３は、セッション切断要求に対応する処理を実行し、ＳＷＢ１２０にセッション切断応答（ＳＢＹ）を送信する（６５９）。ＳＷＢ１２０内の呼処理同期状態管理部１５５は、セッション切断応答（ＳＢＹ）を受信する（６５９）と、図１２に示したＧＴＰ−Ｃパケット転送ルーチンＰ１＿８００を再び実行する（６６０）。
【０１４２】
なお、この場合、呼処理同期状態管理部１５５は、図１２のステップ８０１から８０３に対応する処理として、ＧＴＰ−Ｃトランザクション管理テーブル３２１、ＧＴＰ−Ｃセッション管理テーブル３２１−１、及び呼状態管理テーブル３１０から、端末５のユーザＩＤに対応するエントリをすべて削除する。また、図１２のステップ８０４において、ＧＴＰ−Ｃパケットの送信元は呼処理部（ＳＢＹ）１５３であると判定されるので、呼処理同期状態管理部１５５は、セッション切断応答（ＳＢＹ）をアクセスゲートウェイ３３に転送せず、廃棄する。
【０１４３】
次に、アクセスゲートウェイ３３は、セッション切断応答（ＡＣＴ）を受信する（６５８）と、移動管理サーバ３２にセッション切断応答を送信する（６６１）。移動管理サーバ３２は、基地局３１Ｂ及び端末５にセッション切断応答を送信する（６６２）。
【０１４４】
［６−４．系切替え時のコールフロー］
図１１は、本発明の第１の実施形態のサービス網ゲートウェイ２１が現用系の呼処理部から予備系の呼処理部へ系切替えを実行する場合のコールフローを示す説明図である。
【０１４５】
ＰＢ＃１＿１００−１内の呼処理部（ＡＣＴ）１５１と、ＰＢ＃２＿１００−２内の呼処理部（ＳＢＹ）１５３と、は常時互いの稼働状況を監視する（６８１）。そして、呼処理部（ＡＣＴ）１５１に障害が発生すると、呼処理部（ＳＢＹ）１５３は、その障害を検出する（６８２）。この場合、呼処理部（ＳＢＹ）１５３は、まず呼処理を一旦停止し（６８３）、ＳＷＢ１２０内の呼処理同期状態管理部１５５に、切換え要求を送信する（６８４）。
【０１４６】
ＳＷＢ１２０内の呼処理同期状態管理部１５５は、切換え要求を受信すると、図１３に示した呼識別子抽出ルーチンＰ２＿８２０を実行し、同期が確立していない呼識別子を特定し、特定された呼識別子のリストを含む切換え応答を、呼処理部（ＳＢＹ）１５３に送信する（６８６）。
【０１４７】
呼処理部（ＳＢＹ）１５３は、送信された呼識別子に対応する呼状態を無効化した（６８７）する。具体的には、呼処理部（ＳＢＹ）１５３が備える呼状態を管理するためのテーブル（図示省略）から、送信された呼識別子に対応する呼状態が格納されたエントリを削除する。その後、呼処理を再開し（６８８）、呼処理部（ＡＣＴ）１５１の処理を引き継ぐ。
【０１４８】
なお、ＳＷＢ１２０内の呼処理同期状態管理部１５５は、切換え応答を送信した（６８６）後、ＧＴＰ−Ｃパケットの転送先を呼処理部（ＡＣＴ）１５１から呼処理部（ＳＢＹ）１５３に書き換える。つまり、ＧＴＰ−Ｃパケットの転送先であるＧＴＰ−Ｃエンドポイント情報を呼処理部（ＡＣＴ）１５１のＧＴＰ−ＣトンネルＩＤから呼処理部（ＳＢＹ）１５３のＧＴＰ−ＣトンネルＩＤに書き換える（６８９）。
【０１４９】
また、呼処理同期状態管理部１５５は、ユーザトラフィックの転送先をパケット転送部（ＡＣＴ）１５２からパケット転送部（ＳＢＹ）１５４へ書き換える。つまり、ユーザトラフィックの転送先であるＧＴＰ−Ｕエンドポイント情報を呼処理部（ＡＣＴ）１５１のＧＴＰ−ＵトンネルＩＤから呼処理部（ＳＢＹ）１５３のＧＴＰ−ＵトンネルＩＤに書き換える（６９０）。なお、この場合、呼処理同期状態管理部１５５は、休止している呼処理部（ＳＢＹ）１５３を起動する。
【０１５０】
これによって、サービス網ゲートウェイ２１は、呼処理部（ＡＣＴ）１５１に障害が発生した場合であっても、ＧＴＰ−Ｃパケット及びユーザトラフィックの転送処理を継続することができる。
【０１５１】
以上説明したように、第１の実施形態では、呼処理同期状態管理部１５５が呼処理部（ＡＣＴ）１５１及び呼処理部（ＳＢＹ）１５３に呼処理パケット（ＧＴＰ−Ｃパケット）を転送し、転送されたＧＴＰ−Ｃパケットの内容に基づいて、トランザクション状態を管理するので、サービス網ゲートウェイ２１は、トランザクション状態に基づいて、呼処理部（ＳＢＹ）と呼処理部（ＡＣＴ）との各呼状態の同期を維持することができる。
【０１５２】
［実施形態２］
以下、本発明の第２の実施形態について図面を参照して説明する。第２の実施形態では、予備系の呼処理部（ＳＢＹ）１５３が呼処理プロトコルを中継し、現用系の呼処理部（ＡＣＴ）１５１の呼状態を常時ミラーリングすることによって、各呼状態の同期を維持する。
【０１５３】
［１．ネットワーク及びサービス網ゲートウェイ２１の構成］
第２の実施形態のネットワークの構成は、図２に示した第１の実施形態のネットワークの構成と同じである。また、第２の実施形態のサービス網ゲートウェイ２１のハードウェアの構成は、図３に示した第１の実施形態のサービス網ゲートウェイ２１のハードウェアの構成と同じである。
【０１５４】
［２．サービス網ゲートウェイ２１の冗長化］
図１Ｂは、本発明の第２の実施形態のサービス網ゲートウェイ２１の構成を示すブロック図である。
【０１５５】
ＰＢ＃１＿１００−１は、現用系であり、呼処理部（ＡＣＴ）１１５１及びパケット転送部（ＡＣＴ）１１５２を備える。ＰＢ＃２＿１００−２は、予備系であり、呼処理部（ＳＢＹ）１１５３及びパケット転送部（ＳＢＹ）１１５４（休止中）を備える。
【０１５６】
呼処理部（ＡＣＴ）１１５１及び呼処理部（ＳＢＹ）１１５３は、並列多重処理方式によって、冗長化される。つまり、サービス網ゲートウェイ２１は、現用系の呼処理部（ＡＣＴ）１１５１及び予備系の呼処理部（ＳＢＹ）１１５３を、それぞれ、ＰＢ＃１＿１００−１及びＰＢ＃２＿１００−２において独立に動作させる。ただし、呼処理部（ＳＢＹ）１１５３は、呼処理部（ＡＣＴ）１１５１と全く独立に動作するのではなく、呼処理部（ＡＣＴ）１１５１が送受信するＧＴＰ−Ｃパケットを中継し、呼処理部（ＡＣＴ）１１５１の呼状態を抽出する点で、第１の実施形態のサービス網ゲートウェイ２１と異なる。
【０１５７】
また、呼処理部（ＳＢＹ）１１５３は、呼処理部（ＡＣＴ）１１５１に障害が発生した場合、ＧＴＰ−Ｃパケットから抽出された呼状態を用いて、呼処理部（ＡＣＴ）１１５１の処理を引き継ぐ。また、このような冗長化を実現するために、サービス網ゲートウェイ２１は、パス管理部（図示省略）を備えてもよい。パス管理部は、他ノード（ＡＧＷ）から受信したＧＴＰ−Ｃパケットを、ＳＷＢ１２０を経由して、呼処理部（ＳＢＹ）１１５３に転送するためのパスを設定する。また、呼処理部（ＳＢＹ）１１５３に転送されたＧＴＰ−Ｃパケットを、ＳＷＢ１２０を経由して、呼処理部（ＡＣＴ）１１５１に転送するためのパスを設定する。
【０１５８】
さらに、パス管理部は、呼処理部（ＡＣＴ）１１５１から送信されたＧＴＰ−Ｃパケットを、ＳＷＢ１２０を経由して、呼処理部（ＳＢＹ）１１５３に転送するためのパスを設定する。また、パス管理部は、呼処理部（ＳＢＹ）１１５３が受信したＧＴＰ−Ｃパケットを、ＳＷＢ１２０を経由して、他ノードに転送するためのパスを設定する。なお、サービス網ゲートウェイ２１の装置内のパスは、例えば、ＶＬＡＮ、ＩＰｉｎＩＰトンネル等によって実現される。
【０１５９】
一方、パケット転送部（ＡＣＴ）１１５２、及びパケット転送部（ＳＢＹ）１１５４は、第１の実施形態のサービス網ゲートウェイ２１と同様に、１対１待機冗長方式によって、冗長化される。つまり、現用系のパケット転送部（ＡＣＴ）１１５２は、ＰＢ＃１＿１００−１で動作し、予備系のパケット転送部（ＳＢＹ）１１５４は、ＰＢ＃２＿１００−２で動作する。そして、ＳＷＢ１２０は、サービス網ゲートウェイ２１のパケット転送部（ＡＣＴ）１１５２と、他ノードとの間で、ユーザトラフィックを転送する。
【０１６０】
なお、呼処理部（ＡＣＴ）１１５１とパケット転送部（ＡＣＴ）１１５２とは対で動作する。また、呼処理部（ＳＢＹ）１１５３とパケット転送部（ＳＢＹ）１１５４とは対で動作する。サービス網ゲートウェイ２１は、呼処理部（ＡＣＴ）１１５１から呼処理部（ＳＢＹ）１１５３への系切替えを実行する場合、パケット転送部（ＡＣＴ）１１５２からパケット転送部（ＳＢＹ）１１５４への系切替えも同時に実行する。
【０１６１】
［３．呼処理管理テーブル１３００］
以下に、呼処理管理テーブル１３００の構成について、図１４から図１７を用いて説明する。なお、呼処理管理テーブル１３００は、呼処理部（ＳＢＹ）１１５３が、呼処理部（ＡＣＴ）１１５１の呼状態を管理するためのテーブルである。呼処理管理テーブル１３００は、ＰＢ＃２＿１００−２のメモリ１０３に格納される。
【０１６２】
［３−１．呼処理管理テーブル１３００の構成］
図１４は、本発明の第２の実施形態の呼処理管理テーブル１３００の構成を示す説明図である。
【０１６３】
呼処理管理テーブル１３００は、呼状態管理テーブル１３１０、呼処理プロトコル管理テーブル１３２０及びトランスポートプロトコル管理テーブル１３３０を含む。呼状態管理テーブル１３１０は、呼処理プロトコルに依存しないサービス網毎、ユーザ毎の接続状況を管理するためのテーブルである。
【０１６４】
呼処理プロトコル管理テーブル１３２０は、呼処理プロトコルとして用いられるＧＴＰ−Ｃ、Ｄｉａｍｅｔｅｒなどの呼処理プロトコル状態を管理するためのテーブルである。
【０１６５】
トランスポートプロトコル管理テーブル１３３０は、ＵＤＰ、ＳＣＴＰなどのトランスポートプロトコルの状態を管理するためのテーブルであり、トランスポートプロトコル毎に定義される。
【０１６６】
呼処理管理テーブル１３００は、図４に示した呼処理管理テーブル３００よりも、管理する情報量（テーブル数）が多い。なぜならば、第１の実施形態の呼処理管理テーブル３００は、呼状態の不一致の判定、及び系切替え時のトンネル宛先変換に用いる情報のみを管理するが、第２の実施系の呼処理管理テーブル１３００は、系切替え時に呼処理を引き継ぐための情報をすべて管理するからである。そのため、呼処理管理テーブル１３００は、第１の実施形態の呼処理管理テーブル３００が含む各テーブルのほか、さらに、ＧＴＰ−Ｃパス管理テーブル１３２１−３、Ｄｉａｍｅｔｅｒピア管理テーブル１３２２−３、ＵＤＰ管理テーブル１３３１を含む。
【０１６７】
なお、第１の実施形態の呼処理管理テーブル３００は、呼処理部（ＡＣＴ）１５１及び呼処理部（ＳＢＹ）１５３の両方の状態を管理するが、第２の実施形態の呼処理管理テーブル１３００は、呼処理部（ＡＣＴ）１１５１の状態のみを管理する。
【０１６８】
以下に、呼状態管理テーブル１３１０の構成の例について、図１５を用いて説明する。また、ＧＴＰ−Ｃセッション管理テーブル１３２１−１、ＧＴＰ−Ｃトランザクション管理テーブル１３２１−２、及びＧＴＰ−Ｃパス管理テーブル１３２１−３の構成の例について、図１６を用いて説明する。また、ＵＤＰ管理テーブル１３３１の構成の例について図１７を用いて説明する。なお、Ｄｉａｍｅｔｅｒセッション管理テーブル１３２２−１、Ｄｉａｍｅｔｅｒトランザクション管理テーブル１３２２−２、及びＤｉａｍｅｔｅｒピア管理テーブル１３２２−３の構成については説明を省略するが、これらは、各々、ＧＴＰ−Ｃセッション管理テーブル１３２１−１、ＧＴＰ−Ｃトランザクション管理テーブル１３２１−２、及びＧＴＰ−Ｃパス管理テーブル１３２１−３とほぼ同じ構成である。また、ＳＣＴＰ管理テーブル１３３２の構成については説明を省略するが、ＳＣＴＰ管理テーブル１３３２は、ＵＤＰ管理テーブル１３３１とほぼ同じ構成である。
【０１６９】
［３−２．呼処理管理テーブル１３００の構成］
図１５は、本発明の第２の実施形態の呼状態管理テーブル１３１０の構成を示す説明図である。
【０１７０】
呼状態管理テーブル１３１０は、呼識別子１３６１、ベアラ情報（ＧＴＰ−Ｕエンドポイント情報）１３６２及び呼処理プロトコル管理テーブルへのポインタ１３６３を含む。
【０１７１】
呼状態管理テーブル１３１０の呼識別子１３６１、ベアラ情報（ＧＴＰ−Ｕエンドポイント情報）１３６２及び呼処理プロトコル管理テーブルへのポインタ１３６３は、各々、図５に示した呼状態管理テーブル３１０の呼識別子３６１、ベアラ情報（ＧＴＰ−Ｕエンドポイント情報）３６２及び呼処理プロトコル管理テーブルへのポインタ３６３と同じである。ただし、ベアラ情報（ＧＴＰ−Ｕエンドポイント情報）１３６２は、パケット転送部（ＳＢＹ）のベアラ情報を含まない。
【０１７２】
図１６Ａは、本発明の第２の実施形態のＧＴＰ−Ｃセッション管理テーブル１３２１−１の構成を示す説明図である。
【０１７３】
ＧＴＰ−Ｃセッション管理テーブル１３２１−１は、ＧＴＰ−Ｃエンドポイント情報１３７１、呼状態管理テーブルへのポインタ１３７２、及びＧＴＰ−Ｃトランザクション管理テーブルへのポインタ１３７３を含む。ＧＴＰ−Ｃセッション管理テーブル１３２１−１のＧＴＰ−Ｃエンドポイント情報１３７１、呼状態管理テーブルへのポインタ１３７２、及びＧＴＰ−Ｃトランザクション管理テーブルへのポインタ１３７３は、図６Ａに示したＧＴＰ−Ｃセッション管理テーブル３２１−１のＧＴＰ−Ｃエンドポイント情報３７１、呼状態管理テーブルへのポインタ３７２、及びＧＴＰ−Ｃトランザクション管理テーブルへのポインタ３７３と同じである。ただし、ＧＴＰ−Ｃエンドポイント情報１３７１は、呼処理部（ＳＢＹ）１１５３のエンドポイント情報を含まない。
を含む。
【０１７４】
図１６Ｂは、本発明の第２の実施形態のＧＴＰ−Ｃトランザクション管理テーブル１３２１−２の構成を示す説明図である。
【０１７５】
ＧＴＰ−Ｃトランザクション管理テーブル１３２１−２は、トランザクションＩＤ１３８１、トランザクション状態１３８２、及びＧＴＰ−Ｃセッション管理テーブルへのポインタ１３８３を含む。ＧＴＰ−Ｃトランザクション管理テーブル１３２１−２のトランザクションＩＤ１３８１、トランザクション状態１３８２、及びＧＴＰ−Ｃセッション管理テーブルへのポインタ１３８３は、各々、図６Ｂに示したＧＴＰ−Ｃトランザクション管理テーブル３２１−２のトランザクションＩＤ３８１、トランザクション状態３８２、及びＧＴＰ−Ｃセッション管理テーブルへのポインタ３８３と同じである。
【０１７６】
ただし、ＧＴＰ−Ｃトランザクション管理テーブル１３２１−２のトランザクション状態１３８２には、図７に示した状態変数のうちの一部は設定されない。具体的には、第２の実施形態では、呼処理部（ＳＢＹ）１１５３が、呼処理部（ＡＣＴ）１１５１と呼処理部（ＳＢＹ）１１５３との各呼状態の同期を管理するので、図７に示した状態変数「ＡＣＴ＿ＲＳＰ＿ＳＥＮＴ」及び「ＳＢＹ＿ＲＳＰ＿ＳＥＮＴ」はトランザクション状態１３８２には設定されない。
【０１７７】
これは、第２の実施形態のＧＴＰ−Ｃトランザクション状態遷移では、図７に示したイベントＥ５０２の後、状態変数は「ＲＥＱ＿ＲＥＣＥＩＶＥＤ」から「ＲＥＰ＿ＳＥＮＴ」に遷移し、Ｅ５０４の後、状態変数は、「ＲＥＱ＿ＲＥＣＥＩＶＥＤ」から「ＳＹＮＣ＿ＳＴＡＲＴ」に遷移するためである。
【０１７８】
図１６Ｃは、本発明の第２の実施形態のＧＴＰ−Ｃパス管理テーブル１３２１−３の構成を示す説明図である。
【０１７９】
ＧＴＰ−Ｃパス管理テーブル１３２１−３は、ＧＴＰ−Ｃエンドポイント情報１４０１を含む。ＧＴＰ−Ｃエンドポイント情報１４０１は、アクセスゲートウェイ３３のＧＴＰ−Ｃエンドポイント情報（ＡＧＷ）１４０１Ａ及び呼処理部（ＡＣＴ）１１５１のＧＴＰ−Ｃエンドポイント情報（呼処理部（ＡＣＴ））１４０１Ｂを含む。ＧＴＰ−Ｃエンドポイント情報とは、例えば、ＩＰアドレス、ポート番号、最新のＧＴＰ−Ｃシーケンス番号などである。
【０１８０】
図１７は、本発明の第２の実施形態のＵＤＰ管理テーブル１３３１の構成を示す説明図である。
【０１８１】
ＵＤＰ管理テーブル１３３１は、ＵＤＰエンドポイント情報１４２１を含む。ＵＤＰエンドポイント情報１４２１は、アクセスゲートウェイ３３のＵＤＰエンドポイント情報１４２１Ａ、及び呼処理部（ＡＣＴ）１１５１のＵＤＰエンドポイント情報１４２１Ｂを含む。ＵＤＰエンドポイント情報とは、例えば、ＩＰアドレス、ポート番号などである。
【０１８２】
［４．コールフロー］
［４−１．端末５接続時の正常系コールフロー］
図１８は、本発明の第２の実施形態のサービス網ゲートウェイ２１を起動する場合、及びサービス網ゲートウェイ２１が端末５を接続する場合のコールフローを示す説明図である。
【０１８３】
サービス網ゲートウェイ２１が起動する場合、サービス網ゲートウェイ２１の装置内のパスが設定される（１６０１）。まず、サービス網ゲートウェイ２１は、ＧＴＰ−Ｃパケットを、ＳＷＢ１２０を経由して、ＰＢ＃２＿１００−２の呼処理部（ＳＢＹ）１１５３に転送する。そして、さらに、呼処理部（ＳＢＹ）１１５３に転送されたＧＴＰ−Ｃパケットを、ＳＷＢ１２０を経由して、ＰＢ＃１＿１００−１の呼処理部（ＡＣＴ）１１５１に転送する（１６０１−１）。
【０１８４】
また、サービス網ゲートウェイ２１は、ユーザトラフィックを、ＳＷＢ１２０を経由して、ＰＢ＃１＿１００−１のパケット転送部（ＡＣＴ）１１５２に転送する（１６０１−２）。
【０１８５】
次に、サービス網ゲートウェイ２１が端末５を接続する場合、サービス網ゲートウェイ２１は、図８に示したステップ６０１から６０３の処理を実行する。その後、アクセスゲートウェイ３３は、セッション確立要求をサービス網ゲートウェイ２１に送信する。次に、サービス網ゲートウェイ２１のＳＷＢ１２０は、セッション確立要求をＰＢ＃２＿１００−２の呼処理部（ＳＢＹ）１１５３に送信する（１６１１）。呼処理部（ＳＢＹ）１１５３は、セッション確立要求を受信すると、ＧＴＰ−Ｃパケット転送ルーチンＰ３＿１８００（図２１参照）を実行する（１６１２）。
【０１８６】
図２１は、本発明の第２の実施形態のＧＴＰ−Ｃパケット転送ルーチンＰ３＿１８００を示すフローチャートである。
【０１８７】
呼処理部（ＳＢＹ）１１５３は、受信したＧＴＰ−Ｃパケットの内容に基づいて、ＵＤＰ管理テーブル１３３１を更新する（１８０１）。次に、ＧＴＰ−Ｃパス管理テーブル１３２１−３を更新する（１８０２）。次に、ＧＴＰ−Ｃトランザクション管理テーブル１３２１−２を更新する（１８０３）。次に、ＧＴＰ−Ｃセッション管理テーブル１３２１−１を更新する（１８０４）。次に、呼状態管理テーブル１３１０を更新する（１８０５）。最後に、呼処理部（ＳＢＹ）１１５３は、ＧＴＰ−Ｃパケットを呼処理部（ＡＣＴ）１１５１に転送し（１８０６）、処理を終了する。
【０１８８】
呼処理部（ＳＢＹ）１１５３は、ステップ１８０１に対応する処理として、ＵＤＰ管理テーブル１３３１に新規エントリを追加し、追加された新規エントリのＵＤＰエンドポイント情報（ＡＧＷ）１４２１Ａに、アクセスゲートウェイ３３のＩＰアドレス及びポート番号を設定する。また、ＧＴＰ−Ｃパス管理テーブル１３２１−３に新規エントリを追加し、追加された新規エントリのＧＴＰ−Ｃエンドポイント情報（ＡＧＷ）１４０１Ａに、アクセスゲートウェイ３３のＩＰアドレス及びポート番号を設定する。
【０１８９】
なお、アクセスゲートウェイ３３とサービス網ゲートウェイ２１との間にＧＴＰ−Ｃパスが既に設定されている場合、ステップ１８０１は実行されない。
【０１９０】
次に、呼処理部（ＳＢＹ）１１５３は、ステップ１８０２に対応する処理として、ＧＴＰ−Ｃパス管理テーブル１３２１−３に追加された新規エントリのＧＴＰ−Ｃエンドポイント情報（ＡＧＷ）１４０１Ａに、最新のＧＴＰ−Ｃシーケンス番号を設定する。
【０１９１】
次に、呼処理部（ＳＢＹ）１１５３は、ステップ１８０３に対応する処理として、ＧＴＰ−Ｃトランザクション管理テーブル１３２１−２に新規エントリを追加し、追加された新規エントリのトランザクションＩＤ１３８１に、アクセスゲートウェイ３３が割り当てたＩＰアドレス、ＵＤＰポート番号、ＧＴＰ−Ｃシーケンス番号を設定する。また、追加された新規エントリのトランザクション状態１３８２に、トランザクション状態の状態変数（例えば、ＲＥＱ＿ＲＥＣＥＩＶＥＤ）を設定する。
【０１９２】
次に、呼処理部（ＳＢＹ）１１５３は、ステップ１８０４に対応する処理として、ＧＴＰ−Ｃセッション管理テーブル１３２１−１に新規エントリを追加し、追加された新規エントリのＧＴＰ−Ｃエンドポイント情報（ＡＧＷ）１３７１Ａに、アクセスゲートウェイ３３のＩＰアドレス及びＧＴＰ−ＣトンネルＩＤを設定する。
【０１９３】
次に、呼処理部（ＳＢＹ）１１５３は、ステップ１８０５に対応する処理として、呼状態管理テーブル１３１０に新規エントリを追加し、追加された新規エントリのサービス網ＩＤ１３６１Ａ、ユーザＩＤ１３６１Ｂ、ベアラＩＤ１３６２Ａ、ＧＴＰ−Ｕエンドポイント情報（ＡＧＷ）１３６２Ｂに、アクセスゲートウェイ３３から送信されたサービス網ＩＤ、ユーザＩＤ、ベアラＩＤ、ＧＴＰ−ＵトンネルＩＤ及びＩＰアドレスを設定する。
【０１９４】
ここで、図１８の説明に戻る。
【０１９５】
ステップ１６１２の後、ＰＢ＃２＿１００−２の呼処理部（ＳＢＹ）１１５３は、サービス網ゲートウェイ２１に設定された呼処理プロトコル（ＧＴＰ−Ｃ）のパスに従って、ＳＷＢ１２０を経由して、ＰＢ＃１＿１００−１の呼処理部（ＡＣＴ）１１５１に、セッション確立要求を送信する（１６１３）。ＰＢ＃１＿１００−１の呼処理部（ＡＣＴ）１１５１は、同様に、ＳＷＢ１２０を経由して、ＰＢ＃２＿１００−２の呼処理部（ＳＢＹ）１１５３に、セッション確立応答を送信する（１６１４）。
【０１９６】
そして、ＰＢ＃２＿１００−２の呼処理部（ＳＢＹ）１１５３は、セッション確立応答を受信すると、ＧＴＰ−Ｃパケット転送ルーチンＰ４＿１８２０（図２２参照）を実行する（１６１５）。
【０１９７】
図２２は、本発明の第２の実施形態のＧＴＰ−Ｃパケット転送ルーチンＰ４＿１８２０を示すフローチャートである。
【０１９８】
呼処理部（ＳＢＹ）１１５３は、受信したＧＴＰ−Ｃパケットの内容に基づいて、呼状態管理テーブル１３１０を更新する（１８２１）。次に、ＧＴＰ−Ｃセッション管理テーブル１３２１−１を更新する（１８２２）。次に、ＧＴＰ−Ｃトランザクション管理テーブル１３２１−２を更新する（１８２３）。次に、ＧＴＰ−Ｃパス管理テーブル１３２１−３を更新する（１８２４）。次に、ＵＤＰ管理テーブル１３３１を更新する（１８２５）。最後に、呼処理部（ＳＢＹ）１１５３は、宛先の他ノード（ＡＧＷ）へＧＴＰ−Ｃパケットを転送し（１８２６）、処理を終了する。
【０１９９】
ここで、呼処理部（ＳＢＹ）１１５３は、ステップ１８２１に対応する処理として、ステップ１８０５において追加された、呼状態管理テーブル１３１０の新規エントリのＧＴＰ−Ｕエンドポイント情報１３６２Ｃに、呼処理部（ＡＣＴ）１１５１から送信されたパケット転送部（ＡＣＴ）１１５２のＩＰアドレス及びＧＴＰ−ＵトンネルＩＤを設定する。
【０２００】
また、呼処理部（ＳＢＹ）１１５３は、ステップ１８２２に対応する処理として、ステップ１８０４において追加された、ＧＴＰ−Ｃセッション管理テーブル１３２１−１の新規エントリのＧＴＰ−Ｃエンドポイント情報（呼処理部（ＡＣＴ））１３７１Ｂに呼処理部（ＡＣＴ）１１５１から送信されたＩＰアドレス及びＧＴＰ−ＣトンネルＩＤを設定する。
【０２０１】
また、呼処理部（ＳＢＹ）１１５３は、ステップ１８２３に対応する処理として、ステップ１８０３において追加された、ＧＴＰ−Ｃトランザクション管理テーブル１３２１−２の新規エントリのトランザクション状態１３８２を更新する。
【０２０２】
また、呼処理部（ＳＢＹ）１１５３は、ステップ１８２４に対応する処理として、ステップ１８０１において追加された、ＧＴＰ−Ｃパス管理テーブル１３２１の新規エントリのＧＴＰ−Ｃエンドポイント情報（呼処理部（ＡＣＴ））１４０１Ｂに、呼処理部（ＡＣＴ）１１５１から送信されたＩＰアドレス、ポート番号、及び最新のＧＴＰ-Ｃシーケンス番号を設定する。
【０２０３】
また、呼処理部（ＳＢＹ）１１５３は、ステップ１８２５に対応する処理として、ステップ１８０１において追加された、ＵＤＰ管理テーブル１３３１の新規エントリのＵＤＰエンドポイント情報（呼処理部（ＡＣＴ））１４２１Ｂに、呼処理部（ＡＣＴ）１１５１のＩＰアドレス及びポート番号を設定する。
【０２０４】
呼処理部（ＳＢＹ）１１５３は、ステップ１８２６に対応する処理として、ＳＷ１２０を経由して、他ノード（ＡＧＷ）にＧＴＰ−Ｃパケットを送信する。
【０２０５】
図１８の説明に戻る。
【０２０６】
ステップ１６１５の後、ＰＢ＃２＿１００−２の呼処理部（ＳＢＹ）１１５３は、セッション確立応答（図２２のステップ１８２６のＧＴＰ−Ｃパケット）をＳＷＢ１２０に送信する。ＳＷＢ１２０は、セッション確立応答をアクセスゲートウェイ３３に送信する（１６１６）。その後、呼処理部（ＳＢＹ）１１５３は、図８に示したステップ６１２から６１７の処理を実行する。以上の処理によって、サービス網ゲートウェイ２１は、端末５を接続する。
【０２０７】
［４−２．系切替え時のコールフロー１］
図１９は、本発明の第２の実施形態のサービス網ゲートウェイの現用系の呼処理部に障害が発生した場合のコールフローを示す説明図である。
【０２０８】
系切替えの前に、サービス網ゲートウェイ２１の装置内のパスが設定される（１６５１）。設定されるＧＴＰ−Ｃパケット及びユーザトラフィックのパスは、それぞれ、図１８のステップ１６０１−１及び１６０１−２に示したパスと同じである。
【０２０９】
また、ＰＢ＃１＿１００−１の呼処理部（ＡＣＴ）１１５１とＰＢ＃２＿１００−２の呼処理部（ＳＢＹ）１１５３とは、常時互いの稼働状況を監視する（１６５２）。
【０２１０】
ここで、呼処理部（ＡＣＴ）１１５１に障害が発生すると、呼処理部（ＳＢＹ）１１５３は、呼処理部（ＡＣＴ）１１５１に発生した障害を検出する（１６５３）。この場合、呼処理部（ＳＢＹ）１１５３は、まず、呼処理を一旦停止し（１６５４）、サービス網ゲートウェイ２１の装置内のパスを再設定する（１６５５）。
【０２１１】
具体的には、呼処理部（ＳＢＹ）１１５３は、ＧＴＰ−Ｃパケットを転送するために、ＳＷＢ１２０とＰＢ＃２＿１００−２の呼処理部（ＳＢＹ）１１５３との間にパスを設定する（１６５５−１）。
【０２１２】
また、呼処理部（ＳＢＹ）１１５３は、ユーザトラフィックを転送するために、休止しているＰＢ＃２＿１００−２のパケット転送部（ＳＢＹ）１１５４を起動し、ＳＷＢ１２０と起動したパケット転送部（ＳＢＹ）１１５４との間にパスを設定する（１６５５−２）。
【０２１３】
そして、呼処理部（ＳＢＹ）１１５３は、呼処理を再開する（１６５６）。以上の処理によって、呼処理部（ＡＣＴ）１１５１に障害が発生した場合であっても、呼処理部（ＳＢＹ）１１５３は、呼処理部（ＡＣＴ）１１５１の処理を引き継ぐことができる。
【０２１４】
［４−３．系切替え時のコールフロー２］
図２０は、本発明の第２の実施形態のサービス網ゲートウェイの予備系の呼処理部に障害が発生した場合のコールフローを示す説明図である。
【０２１５】
系切替えの前に、サービス網ゲートウェイ２１の装置内のパスが設定される（１６７１）。設定されるＧＴＰ−Ｃパケット及びユーザトラフィックのパスは、それぞれ、図１８のステップ１６０１−１及び１６０１−２に示したパスと同じである。
【０２１６】
また、ＰＢ＃１＿１００−１の呼処理部（ＡＣＴ）１１５１とＰＢ＃２＿１００−２の呼処理部（ＳＢＹ）１１５３とは、常時互いの稼働状況を監視する（１６７２）。
【０２１７】
ここで、呼処理部（ＳＢＹ）１１５３に障害が発生すると、呼処理部（ＡＣＴ）１１５１は、呼処理部（ＳＢＹ）１１５３に発生した障害を検出する（１６７３）。この場合、呼処理部（ＡＣＴ）１１５１は、まず、呼処理を一旦停止し（１６７４）、サービス網ゲートウェイ２１の装置内のパスを再設定する。
【０２１８】
具体的には、呼処理部（ＡＣＴ）１１５１は、ＧＴＰ−Ｃパケットを転送するために、ＳＷＢ１２０とＰＢ＃１＿１００−１の呼処理部（ＡＣＴ）１１５１との間にパスを設定する（１６７５−１）。
【０２１９】
また、呼処理部（ＡＣＴ）１１５１は、ユーザトラフィックを転送するために、ＳＷＢ１２０とＰＢ＃１＿１００−１のパケット転送部（ＡＣＴ）１１５２との間にパスを設定する（１６７５−２）。そして、呼処理部（ＡＣＴ）１１５１は、呼処理を再開し、処理を継続する。
【０２２０】
以上説明したように、第２の実施形態では、呼処理部（ＳＢＹ）が呼処理パケットを中継し、処理部（ＡＣＴ）に呼処理パケットを転送するので、サービス網ゲートウェイ２１は、呼処理部（ＳＢＹ）が呼処理パケットから抽出した呼状態に基づいて、呼処理部（ＳＢＹ）と呼処理部（ＡＣＴ）との間の各呼状態の同期を維持することができる。
【符号の説明】
【０２２１】
１ サービス網、
２ ユーザホーム網
３ 無線アクセス網
４ 無線アクセス網
５ 端末
１１ アプリケーションサーバ
２１ サービス網ゲートウェイ（ＳＮＧＷ）
２２ ポリシーサーバ
２３ 認証サーバ
３１Ａ、Ｂ 基地局
３２ 移動管理サーバ
３３ アクセスゲートウェイ（ＡＧＷ）
４１Ａ、Ｂ 基地局
４２ 移動管理サーバ
４３ アクセスゲートウェイ（ＡＧＷ）
３１０ 呼状態管理テーブル
３２１−１ ＧＴＰ−Ｃセッション管理テーブル
３２１−１ ＧＴＰ−Ｃトランザクション管理テーブル
５００ ＧＴＰ−Ｃトランザクション状態遷移図
８００ ＧＴＰ−Ｃパケット転送ルーチンＰ１
８２０ 呼識別子抽出ルーチンＰ２
１３１０ 呼状態管理テーブル
１３２１−１ ＧＴＰ−Ｃセッション管理テーブル
１３２１−２ ＧＴＰ−Ｃトランザクション管理テーブル
１３２１−３ ＧＴＰ−Ｃパス管理テーブル
１３３１ ＵＤＰ管理テーブル
１８００ 自宛ＧＴＰ−Ｃパケット転送ルーチンＰ３
１８２０ 自発ＧＴＰ−Ｃパケット転送ルーチンＰ４
【技術分野】
【０００１】
本発明は、移動体通信ゲートウェイ装置の呼処理部を並列多重処理方式によって冗長化する技術に関する。
【背景技術】
【０００２】
３ＧＰＰ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）のＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）に代表される第３．９世代移動体通信網では、ネットワークは、すべてＩＰ化される。このため、従来は回線交換網によって提供されてきた電話サービスがＩＰ網によって提供されるようになる。したがって、今後は移動体通信ゲートウェイにも電話交換機と同程度の高信頼性が要求されるようになる。
【０００３】
ネットワーク装置を高信頼化する方式には、並列多重処理方式及び待機冗長方式がある。並列多重処理方式は、現用系の装置と予備系の装置とが並列に処理を実行する。待機冗長方式は、１台の現用系の装置が処理を実行し、現用系の装置が故障した場合、予備系の装置が処理を引き継ぐ。
【０００４】
並列多重処理方式は、現用系から予備系に系切替えを実行する場合、予備系の起動処理が不要であるので、系切替えのための時間を短縮することができる。しかしながら、並列多重処理方式は、正常稼働時にも計算リソースを多く消費する。このため、並列多重処理方式は、比較的処理が単純であり、高速な系切替えが要求される信号処理装置などに利用されている。
【０００５】
例えば、ＡＴＭ（Ａｓｙｎｃｈｒｏｎｏｕｓ Ｔｒａｎｓｆｅｒ Ｍｏｄｅ）セル伝送装置を二重化（冗長化）する場合、現用系と予備系との同期を短時間で確立し、無瞬断で系切替えを実行するための技術が提案されている（例えば、特許文献１参照）。また、電話交換機の信号処理部を二重化する場合、現用系と予備系との同期を確立するために用いられる交絡信号数を削減する技術が提案されている（例えば、特許文献２参照）。
【０００６】
一方、待機冗長方式は、現用系から予備系に系切替えを実行する場合、予備系の起動処理に時間を要するが、正常稼働時は１台の現用系のみが処理を実行するので、計算リソースを有効に活用することができる。このため、待機冗長方式は、処理が複雑であり、比較的長い時間を要する系切替えが許容される、ＯＳＩ（Ｏｐｅｎ Ｓｙｓｔｅｍｓ Ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ）第３層以上のネットワーク装置などに広く利用されている。
【０００７】
例えば、待機冗長方式を利用したルータにおいて、現用系ルータが作成したルーティングテーブルを予備系ルータに常時転写することによって、系切替え時のルーティングテーブルの再計算処理を不要とする技術が提案されている（例えば、特許文献３参照）。また、待機冗長方式の一種であるＮ対１予備構成に基づく電話交換機の呼制御処理部が提案されている（例えば、非特許文献１参照）。非特許文献１に記載された電話交換機の呼制御処理部には待機冗長方式が採用されているが、呼制御処理部は、現用系と予備系との共有メモリを利用し、呼状態を引き継ぐことができるので、短時間で系切替えを実行することができる。
【０００８】
ここで、移動体通信ゲートウェイは、一般的に、ＡＴＣＡ（Ａｄｖａｎｃｅｄ Ｔｅｌｅｃｏｍ Ｃｏｍｐｕｔｉｎｇ Ａｒｃｈｉｔｅｃｔｕｒｅ）などの汎用装置に実装されるので、待機冗長方式を採用する場合、共有メモリを設けることによって、系切替えを高速化することが困難である。そこで、通常は、例えば、特許文献３に記載された技術によって、ネットワークを経由して、現用系が作成した呼状態（端末接続情報）を現用系から予備系に常時転写する。
【０００９】
しかしながら、現用系から予備系に呼状態を転写する場合、現用系に余分な転送負荷がかかる。さらに、現用系の故障の状態によっては呼状態を現用系から予備系に完全に転写できないまま、系切替えが実行されてしまう可能性がある。
【００１０】
また、ＯＳＩ第４層のプロトコル（例えば、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）、ＳＣＴＰ（Ｓｔｒｅａｍ Ｃｏｎｔｒｏｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｐｒｏｔｏｃｏｌ）など）は、通常ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）内に実装される。このため、ＴＣＰ／ＳＣＴＰコネクションの状態、及び呼処理アプリケーションが管理する呼状態を一の処理で転写することは難しい。また、系切替え時において、ＴＣＰ／ＳＣＴＰコネクション情報を引継がずに、動的にＴＣＰ／ＳＣＴＰコネクションが再確立されると、系切替え時間が増大してしまう。
【００１１】
そこで、近年では、これらの問題を解決するため、ＯＳＩ第３層以上の処理を実行するネットワーク装置にも並列多重処理方式を適用することが検討されている。
【００１２】
例えば、並列多重処理方式によって冗長化されたルータの経路制御モジュールにおいて、現用系と予備系とが互いの処理状況を把握するために、予備系が処理した経路制御パケットの識別子を現用系に通知する技術が提案されている（例えば、特許文献４参照）。
【００１３】
また、複雑なフロー状態を管理するルータクラスタにおいて、フロー状態の転写の負荷を軽減するために、現用系ルータと予備系ルータとが二重にパケット処理を実行する技術が提案されている（例えば、非特許文献２参照）。
【００１４】
また、冗長化された各ＳＩＰサーバの間において、ＴＣＰ／ＳＣＴＰコネクション情報を引継ぐために、現用系と予備系とのＴＣＰ／ＳＣＴＰプロトコルスタックが並列にパケット処理を実行する技術が提案されている（例えば、非特許文献３参照）。
【先行技術文献】
【特許文献】
【００１５】
【特許文献１】特開平６−２３２８９２号公報
【特許文献２】特開２０００−３２５７４号公報
【特許文献３】特開２００２−８４３１３号公報
【特許文献４】特開２００５−３０３５０１号公報
【非特許文献】
【００１６】
【非特許文献１】山田喬彦、小川聡、須山正人、堀好徳、「ディジタル交換機用マルチプロセッサの故障処理」１９８８年３月、信学論（Ｂ）、Ｊ７１−Ｂ、３、ｐ．３３９−３４９
【非特許文献２】狩野秀一、地引昌弘、「ルータクラスタにおける二重パケット処理冗長方式」、２００５年１０月、信学論、Ｖｏｌ．Ｊ８８−Ｂ、Ｎｏ．１０、ｐ．１９５６−１９６７
【非特許文献３】狩野秀一、地引昌弘、「トランスポート端点のポータブルなクラスタ方式」、２００７年５月、信学技法、ＩＡ２００７−２、ｐ．５−１０
【発明の概要】
【発明が解決しようとする課題】
【００１７】
移動体通信ゲートウェイは、移動端末の接続状態を管理する呼処理部と、呼処理部によって作成されたパス情報に基づいて、ユーザトラフィックを転送するパケット転送部と、を備える。呼処理部は大量の呼状態（端末接続情報）を管理する。また、一部の呼処理プロトコルにＳＣＴＰが利用される。このため、移動体通信ゲートウェイに並列多重処理方式を適用することが検討されている。
【００１８】
しかしながら、特許文献１〜２、４及び非特許文献３〜４に記載された技術によっては、移動体通信ゲートウェイが備える呼処理部に並列多重処理方式を適用することはできない。以下に示す理由のためである。
【００１９】
まず、移動体通信ゲートウェイは、一般的にＥｔｈｅｒｎｅｔ(登録商標、以下同じ）等の信頼性の低い回線によって、現用系と予備系との間、又はこれらと外部装置との間が接続される。このため、現用系と予備系とのどちらか一方で呼処理パケットが欠落する可能性がある。この場合、現用系と予備系との各呼状態がずれるが、非特許文献３〜４に記載された技術のように、現用系と予備系との各呼状態を同期させないで、現用系と予備系とを並列に動作させると、現用系と予備系との各呼状態に不一致が発生し、発生した不一致が移動体通信ゲートウェイに認識されずに呼処理が継続されてしまう問題がある。
【００２０】
また、移動体通信ゲートウェイの呼処理部は、ハードウェア及びソフトウェアによって、多段のキューを経由し、パケットを処理する。また、ソフトウェアがマルチスレッドの構成である場合、複数のパケットを並列に処理する。このため、パケットの順序が容易に逆転する。よって、特許文献１〜２に記載された、現用系と予備系との間に比較回路又は交絡信号を設けた構成によっては、現用系と予備系との各呼状態の不一致を検出することができず、また、不一致となった各呼状態を再同期することができない。
【００２１】
また、移動体通信ゲートウェイにおいて、１つの呼処理パケットが欠落しても、わずか１ユーザの接続情報が失われるだけであるので、欠落した呼処理パケットに対応する各呼状態のみを再同期し、呼処理を継続することが望ましい。しかし、特許文献４に記載された技術によっては、現用系と予備系のとの各呼状態がずれてしまった場合、このずれた各呼状態のみを再同期することができない。特許文献４に記載された技術では、呼状態の不一致が発生した場合、直ちに系切替えを実行しなければならないためである。
【００２２】
本発明は、前述した問題に鑑みてなされたものであり、並列多重方式によって冗長化され、パケット順序の逆転及びパケットのロスが発生した場合であっても、現用系と予備系との各呼状態の同期を維持することができる移動体通信ゲートウェイを提供することを目的とする。
【課題を解決するための手段】
【００２３】
本発明の代表的な一例を示せば以下のとおりである。すなわち、端末を接続する第１のノードから前記端末に通信サービスを提供する第２のノードへ、前記端末が送受信するユーザトラフィックを転送する移動体通信ゲートウェイ装置であって、前記第１のノードによって、所定の呼処理プロトコルを用いて送信された呼処理パケットに基づいて、前記端末の接続情報を示す呼状態を作成する少なくとも二つ以上の呼処理部と、前記第１のノードと前記呼処理部との間で前記呼処理パケットを転送するスイッチ部と、を備え、前記スイッチ部は、前記第１のノードから送信された前記呼処理パケットを受信すると、前記受信した呼処理パケットを複製し、その一方を、第１の呼処理パケットとし、他方を第２の呼処理パケットとし、前記第１の呼処理パケットを、現用系の前記呼処理部に送信し、前記第２の呼処理パケットを、予備系の前記呼処理部に送信し、前記現用系の呼処理部から送信された前記第１の呼処理パケットを受信すると、前記受信した第１の呼処理パケットを前記第１のノードに送信し、前記予備系の呼処理部から送信された前記第２の呼処理パケットを受信すると、前記受信した第２の呼処理パケットを前記第１のノードに送信しないで廃棄し、前記第１及び第２の呼処理パケットの送受信の状態を記憶し、前記記憶された第１及び第２の呼処理パケットの送受信の状態に基づいて、前記現用系の呼処理部によって作成される呼状態と前記予備系の呼処理部によって作成される呼状態とが一致するか否かを検出することを特徴とする。
【発明の効果】
【００２４】
本発明の一実施形態によれば、移動体通信ゲートウェイ装置の呼処理部を並列多重方式によって冗長化する場合、パケットの順序の逆転及びパケットのロスが発生しても、現用系と予備系と間で呼状態の同期を維持することができる。
【図面の簡単な説明】
【００２５】
【図１Ａ】本発明の第１の実施形態のサービス網ゲートウェイの構成を示すブロック図である。
【図１Ｂ】本発明の第２の実施形態のサービス網ゲートウェイの構成を示すブロック図である。
【図２】本発明の第１の実施形態のネットワークの構成を示す説明図である。
【図３】本発明の第１の実施形態のサービス網ゲートウェイのハードウェアの構成を示すブロック図である。
【図４】本発明の第１の実施形態の呼処理管理テーブルの構成を示す説明図である。
【図５】本発明の第１の実施形態の呼状態管理テーブルの構成を示す説明図である。
【図６Ａ】本発明の第１の実施形態のＧＴＰ−Ｃセッション管理テーブルの構成を示す説明図である。
【図６Ｂ】本発明の第１の実施形態のＧＴＰ−Ｃトランザクション管理テーブルの構成の例を示す説明図である。
【図７】本発明の第１の実施形態のＧＴＰ−Ｃトランザクション状態遷移を示す説明図である。
【図８】本発明の第１の実施形態のサービス網ゲートウェイが端末を接続する場合の正常系コールフローを示す説明図である。
【図９】本発明の第１の実施形態のサービス網ゲートウェイが端末を接続する場合の準正常系コールフローを示す説明図である。
【図１０】本発明の第１の実施形態のサービス網ゲートウェイが端末を切断する場合のコールフローを示す説明図である。
【図１１】本発明の第１の実施形態のサービス網ゲートウェイが現用系の呼処理部から予備系の呼処理部へ系切替えを実行する場合のコールフローを示す説明図である。
【図１２】本発明の第１の実施形態のＧＴＰ−Ｃパケット転送ルーチンを示すフローチャートである。
【図１３】本発明の第１の実施形態の呼識別子抽出ルーチンを示すフローチャートである。
【図１４】本発明の第２の実施形態の呼処理管理テーブルの構成を示す説明図である。
【図１５】本発明の第２の実施形態の呼状態管理テーブルの構成を示す説明図である。
【図１６Ａ】本発明の第２の実施形態のＧＴＰ−Ｃセッション管理テーブルの構成を示す説明図である。
【図１６Ｂ】本発明の第２の実施形態のＧＴＰ−Ｃトランザクション管理テーブルの構成を示す説明図である。
【図１６Ｃ】本発明の第２の実施形態のＧＴＰ−Ｃパス管理テーブルの構成を示す説明図である。
【図１７】本発明の第２の実施形態のＵＤＰ管理テーブルの構成を示す説明図である。
【図１８】本発明の第２の実施形態のサービス網ゲートウェイを起動する場合、及びサービス網ゲートウェイが端末を接続する場合のコールフローを示す説明図である。
【図１９】本発明の第２の実施形態のサービス網ゲートウェイの現用系の呼処理部に障害が発生した場合のコールフローを示す説明図である。
【図２０】本発明の第２の実施形態のサービス網ゲートウェイの予備系の呼処理部に障害が発生した場合のコールフローを示す説明図である。
【図２１】本発明の第２の実施形態のＧＴＰ−Ｃパケット転送ルーチンを示すフローチャートである。
【図２２】本発明の第２の実施形態のＧＴＰ−Ｃパケット転送ルーチンを示すフローチャートである。
【発明を実施するための形態】
【００２６】
以下、図面を用いて本発明の実施形態について説明する。なお、以下では、主に３ＧＰＰのＬＴＥに用いられる移動体通信ゲートウェイ（サービス網ゲートウェイ）について説明するが、本発明は、ＬＴＥに用いられる移動体通信ゲートウェイに限定されない。本発明は、ＬＴＥと同様の、他のアクセス網に用いられる移動体通信ゲートウェイにも適用することができる。
【００２７】
［実施形態１］
以下、本発明の第１の実施形態について図面を参照して説明する。
【００２８】
第１の実施形態では、サービス網ゲートウェイは、現用系と予備系との呼処理のトランザクション状態を管理する呼処理同期状態管理部を備える。呼処理同期状態管理部は、呼処理のトランザクション状態に基づいて、現用系と予備系との各呼状態の不一致を検出し、不一致が検出された各呼状態を再同期する。
【００２９】
［１．ネットワークの構成］
図２は、本発明の第１の実施形態のネットワークの構成を示す説明図である。
【００３０】
本発明の第１の実施形態のネットワーク（移動体通信網）は、サービス網１、ユーザホーム網２、無線アクセス網３及び無線アクセス網４を備える。
【００３１】
無線アクセス網３は、端末５を収容するためのネットワークであり、基地局３１Ａ、３１Ｂ、移動管理サーバ３２及びアクセスゲートウェイ３３を備え、例えば、無線インタフェースを介してデータ通信をする端末５に接続する。
【００３２】
基地局３１Ａ、３１Ｂは、基地局３１Ａ、３１Ｂと接続された端末５との間で、無線信号と有線信号とを相互に変換する。なお、図２では、例として、基地局を二つ図示したが、基地局は所要の数が備えられる。
【００３３】
アクセスゲートウェイ３３は、基地局３１Ａ、３１Ｂから受信したユーザトラフィックをユーザホーム網２に転送する。
【００３４】
また、移動管理サーバ３２は、端末５の接続状況を管理し、また、基地局３１Ａ、３１Ｂとアクセスゲートウェイ３３との間のパスを制御する。
【００３５】
無線アクセス網４は、無線アクセス網３と同じであり、基地局４１Ａ、４１Ｂ、移動管理サーバ４２及びアクセスゲートウェイ（ＡＧＷ：Ａｃｃｅｓｓ Ｇａｔｅｗａｙ）４３を備え、無線インタフェースを介して、データ通信をする端末を接続する。基地局４１Ａ、４１Ｂ、移動管理サーバ４２及びアクセスゲートウェイ４３は、各々、基地局３１Ａ、３１Ｂ、移動管理サーバ３２及びアクセスゲートウェイ３３と同じである。なお、図２では、例として、二つの無線アクセス網を図示したが、三つ以上の無線アクセス網が備えられてもよい。
【００３６】
ユーザホーム網２は、加入者情報を管理し、端末５をサービス網１に接続するためのネットワークであり、サービス網ゲートウェイ（ＳＮＧＷ：Ｓｅｒｖｉｃｅ Ｎｅｔｗｏｒｋ Ｇａｔｅｗａｙ）２１、ポリシーサーバ２２及び認証サーバ２３を備える。
【００３７】
サービス網ゲートウェイ２１は、アクセスゲートウェイ３３、４３から受信したユーザトラフィックを適切なサービス網１に転送する。また、ポリシーサーバ２２は、サービス網ゲートウェイ２１にユーザトラフィックの課金の情報及びＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）を通知する。また、認証サーバ２３は、ユーザ（端末５）の加入者情報を管理する。
【００３８】
サービス網１には、端末５にサービスを提供するためのネットワークであり、端末５にサービスを提供するアプリケーションサーバ１１を備える。
【００３９】
なお、ＬＴＥでは、基地局３１Ａ、３１Ｂ、４１Ａ、４１Ｂは、ｅＮＢ （ｅｖｏｌｖｅｄ Ｎｏｄｅ Ｂ）である。また、アクセスゲートウェイ３３、４３は、Ｓ−ＧＷ（Ｓｅｒｖｉｎｇ Ｇａｔｅｗａｙ）である。また、移動管理サーバ３２、４２は、ＭＭＥ（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）である。また、サービス網ゲートウェイ２１は、Ｐ−ＧＷ（Ｐａｃｋｅｔ Ｄａｔａ Ｎｅｔｗｏｒｋ Ｇａｔｅｗａｙ）である。また、ポリシーサーバ２２は、ＰＣＲＦ（Ｐｏｌｉｃｙ ａｎｄ Ｃｈａｒｇｉｎｇ Ｒｕｌｅｓ Ｆｕｎｃｔｉｏｎ）である。また、認証サーバ２３は、ＨＳＳ（Ｈｏｍｅ Ｓｕｂｓｃｒｉｂｅｒ Ｓｅｒｖｅｒ）である。
【００４０】
以下に、サービス網ゲートウェイ２１の構成及び処理について説明する。なお、ＬＴＥでは、サービス網ゲートウェイ２１とアクセスゲートウェイ３３、４３との間の呼処理プロトコルにＧＴＰ−Ｃを使用する。また、サービス網ゲートウェイ２１とポリシーサーバ２２との間の呼処理プロトコルにＤｉａｍｅｔｅｒを使用する。なお、本実施形態では、これらの呼処理プロトコルを使用する場合について説明するが、本発明はこれらの呼処理プロトコルに限定されず、他の呼処理プロトコルを使用してもよい。
【００４１】
［２．サービス網ゲートウェイ２１の構成］
図３は、本発明の第１の実施形態のサービス網ゲートウェイ２１のハードウェアの構成を示すブロック図である。
【００４２】
サービス網ゲートウェイ２１は、ＰＢ（Ｐａｙｌｏａｄ Ｂｌａｄｅ）＃１＿１００からＰＢ＃ｎ＿１００−ｎ、及びＳＷＢ（Ｓｗｉｔｃｈ Ｂｌａｄｅ）１２０を備える。ＰＢ＃１＿１００からＰＢ＃ｎ＿１００−ｎは、例えば、ブレードサーバであり、呼処理及びユーザトラフィック転送の機能を実現する。ＰＢ＃１＿１００からＰＢ＃ｎ＿１００−ｎは、それぞれ、同じである。
【００４３】
ＰＢ＃１＿１００は、ＦＲＯＭ１０１、ＣＰＵ１０２、メモリ１０３、及びＩＦ１０４、１０５を備え、これらはバス１０６を介して互いに接続される。ＦＲＯＭ１０１は、サービス網ゲートウェイ２１の機能を実現するためのプログラム、具体的には、例えば、呼処理部（ＡＣＴ）１５１又は呼処理部（ＳＢＹ）１５３（図１Ａ参照）が実行する処理のためのプログラムを格納する。ＣＰＵ１０２は、サービス網ゲートウェイ２１が起動した時に、ＦＲＯＭ１０１に格納されたプログラムをメモリ１０３に展開し、展開されたプログラムを順次読み出し、読み出されたプログラムを実行する。
【００４４】
ＩＦ１０４、１０５は、Ｅｔｈｅｒｎｅｔ回線を介して、ＳＷＢ１２０に接続される。なお、例えば、ＩＦ１０４は、データ通信用に使用され、ＩＦ１０５は、装置の制御用に使用されてもよい。
【００４５】
ＳＷＢ１２０は、例えば、ブレードサーバであり、Ｅｔｈｅｒｎｅｔのスイッチの機能を実現する。ＳＷＢ１２０は、ＩＦ１２３−１〜ｍ、ＩＦ１２２−１〜２ｎ、スイッチ部１２１、ＦＲＯＭ１２４、ＣＰＵ１２５、及びメモリ１２６を備える。ＩＦ１２３−１〜ｍは、外部装置に接続される。ＩＦ１２２−１〜２ｎは、ＰＢ＃１＿１００〜ＰＢ＃ｎ＿１００−ｎに接続される。スイッチ部１２１は、各ＩＦを介して、パケットを中継する。
【００４６】
また、ＦＲＯＭ１２４、ＣＰＵ１２５、及びメモリ１２６は、スイッチ部１２１が所定のルールに基づき抽出したパケットを処理する。具体的には、ＦＲＯＭ１２４は、呼処理同期状態管理部１５５（図１Ａ参照）が実行する処理のためのプログラムを格納する。ＣＰＵ１１２５は、ＦＲＯＭ１１２４に格納されたプログラムをメモリ１１２６に展開し、展開されたプログラムを順次読み出し、読み出されたプログラムを実行する。
【００４７】
［３．サービス網ゲートウェイ２１の冗長化］
図１Ａは、本発明の第１の実施形態のサービス網ゲートウェイ２１の構成を示すブロック図である。
【００４８】
ＰＢ＃１＿１００−１は、現用系であり、呼処理部（ＡＣＴ）１５１及びパケット転送部（ＡＣＴ）１５２を備える。ＰＢ＃２＿１００−２は、予備系であり、呼処理部（ＳＢＹ）１５３及びパケット転送部（ＳＢＹ）１５４（休止中）を備える。
【００４９】
呼処理部（ＡＣＴ）１５１と呼処理部（ＳＢＹ）１５３とは、並列多重処理方式によって冗長化される。つまり、サービス網ゲートウェイ２１は、現用系の呼処理部（ＡＣＴ）１５１及び予備系の呼処理部（ＳＢＹ）１５３を、それぞれ、ＰＢ＃１＿１００−１及びＰＢ＃２＿１００−２において独立に動作させる。そして、ＳＷＢ１２０は、並列多重処理を実現するため、他ノード（ＡＧＷ３３、４３等）から送信された呼処理パケットを受信し、受信した呼処理パケットを少なくとも一つ複製し、これらの呼処理パケットをそれぞれ、呼処理部（ＡＣＴ）１５１及び呼処理部（ＳＢＹ）１５３に転送する。
【００５０】
また、呼処理部（ＡＣＴ）１５１及び呼処理部（ＳＢＹ）１５３の双方は、サービス網ゲートウェイ２１から他ノード（ＡＧＷ３３、４３等）に送信する呼処理パケットをＳＷＢ１２０に送信する。ただし、ＳＷＢ１２０は、呼処理部（ＡＣＴ）１５１から送信された呼処理パケットのみを他ノードに転送し、呼処理部（ＳＢＹ）１５３から送信された呼処理パケットを転送せずに廃棄する。
【００５１】
一方、パケット転送部（ＡＣＴ）１５２、及びパケット転送部（ＳＢＹ）１５４は、１対１待機冗長方式によって、冗長化される。つまり、現用系のパケット転送部（ＡＣＴ）１５２は、ＰＢ＃１＿１００−１で動作し、予備系のパケット転送部（ＳＢＹ）１５４は、ＰＢ＃２＿１００−２で動作する。他ノードから転送されたユーザトラフィックは、ＳＷＢ１２０を経由して、パケット転送部（ＡＣＴ）１５２に転送される。
【００５２】
ＳＷＢ１２０は、呼処理同期状態管理部１５５を備える。呼処理同期状態管理部１５５は、呼処理部（ＡＣＴ）１５１と呼処理部（ＳＢＹ）１５３との各呼状態の同期を管理する。ＳＷＢ１２０のＣＰＵ１２５は、メモリ１２６に格納されたプログラムによって、呼処理同期状態管理部１５５の処理を実行する。
【００５３】
また、呼処理同期状態管理部１５５は、呼処理部（ＡＣＴ）１５１と呼処理部（ＳＢＹ）１５３との呼処理のトランザクション状態を管理することによって、呼状態の同期を管理する。具体的には、呼処理同期状態管理部１５５は、一定時間が経過しても呼処理のトランザクション状態が所定の状態にならない場合、同期していない呼の識別子を呼処理部（ＳＢＹ）１５３に通知する。これによって、呼処理同期状態管理部１５５は、呼処理部（ＡＣＴ）１５１及び呼処理部（ＳＢＹ）１５３のいずれか一方のみで、呼処理パケットが消失し、各呼処理部の呼状態が一致しなくなった場合であっても、各呼状態の不一致を検出し、不一致が検出された各呼状態を同期させることができる。呼処理同期状態管理部１５５の処理の詳細については、図４から図１３を用いて後述する。
【００５４】
［４．呼処理管理テーブル３００］
［４−１．呼処理管理テーブル３００の構成］
呼処理同期状態管理部１５５は、呼処理管理テーブル３００を備える。なお、呼処理管理テーブル３００は、ＳＷＢ１２０のメモリ１２６に格納される。以下に、呼処理管理テーブル３００の構成について、図４から６を用いて説明する。
【００５５】
図４は、本発明の第１の実施形態の呼処理管理テーブル３００の構成を示す説明図である。
【００５６】
呼処理管理テーブル３００は、呼状態管理テーブル３１０、呼処理プロトコル管理テーブル３２０及びトランスポートプロトコル管理テーブル３３０を含む。
【００５７】
呼状態管理テーブル３１０は、呼処理プロトコルに依存しないサービス網毎、ユーザ毎の接続状況を管理するためのテーブルである。呼状態管理テーブル３１０の具体的な構成の例については、図５を用いて後述する。
【００５８】
呼処理プロトコル管理テーブル３２０は、本実施形態において呼処理プロトコルとして用いられるＧＴＰ−Ｃ、Ｄｉａｍｅｔｅｒなどの呼処理プロトコル状態を管理するためのテーブルである。呼処理プロトコル管理テーブル３２０は、呼処理プロトコル毎に定義され、例えば、ＧＴＰ−Ｃ管理テーブル３２１、Ｄｉａｍｅｔｅｒ管理テーブル３２２などを含む。
【００５９】
ＧＴＰ−Ｃ管理テーブル３２１は、ＧＴＰ−Ｃプロトコルの呼処理プロトコル状態を管理するためのテーブルであり、ＧＴＰ−Ｃセッション管理テーブル３２１−１、及びＧＴＰ−Ｃトランザクション管理テーブル３２１−２を含む。なお、ＧＴＰ−Ｃ管理テーブル３２１の具体的な構成の例については、図６Ａから図６Ｂを用いて後述する。
【００６０】
また、Ｄｉａｍｅｔｅｒ管理テーブル３２２は、Ｄｉａｍｅｔｅｒプロトコルの呼処理プロトコル状態を管理するためのテーブルであり、Ｄｉａｍｅｔｅｒセッション管理テーブル３２２−１、及びＤｉａｍｅｔｅｒトランザクション管理テーブル３２２−２を含む。
【００６１】
なお、前述した呼状態管理テーブル３１０及び呼処理プロトコル管理テーブルは、呼処理部（ＡＣＴ）１５１及び呼処理部（ＳＢＹ）１５３が備える呼状態及び呼処理プロトコルを管理するためのテーブル（図示省略）の一部である。
【００６２】
トランスポートプロトコル管理テーブル３３０は、ＳＣＴＰなどのトランスポートプロトコルの状態を管理するためのテーブルであり、トランスポートプロトコル毎に定義され、例えば、ＳＣＴＰ管理テーブル３３２を含む。ＳＣＴＰ管理テーブル３３２は、具体的には、送信元ＩＰアドレス、送信元ポート番号、宛先ＩＰアドレス、宛先ポート番号、コネクション状態、ストリーム情報、シーケンス番号などを含む。なお、ＧＴＰ−Ｃでは、トランスポートプロトコルとしてＵＤＰが使用されるが、ＵＤＰはコネクションレスであるので、本実施形態はＵＤＰの状態を管理しなくてもよい。
【００６３】
［４−２．呼状態管理テーブル３１０の構成］
図５は、本発明の第１の実施形態の呼状態管理テーブル３１０の構成を示す説明図である。
【００６４】
呼状態管理テーブル３１０は、呼識別子３６１、ベアラ情報（ＧＴＰ−Ｕエンドポイント情報）３６２及び呼処理プロトコル管理テーブルへのポインタ３６３を含む。
【００６５】
呼識別子３６１は、例えば、端末５が接続するサービス網を識別するためのサービス網ＩＤ３６１Ａと、端末５を識別するためのユーザＩＤ３６１Ｂと、の組み合わせである。
【００６６】
ベアラ情報３６２は、各呼識別子に対して一つ以上設定されるベアラ情報（ＧＴＰ−Ｕエンドポイント情報）である。ここで、ＧＴＰ−Ｕエンドポイント情報とは、ユーザトラフィックを転送するために設定される仮想トンネル（ＧＴＰ−Ｕトンネル）の端点のＩＰアドレスと、ＧＴＰ−Ｕトンネルを識別するためのＧＴＰ−ＵトンネルＩＤとの組み合わせである。
【００６７】
具体的には、ベアラ情報３６２は、各ベアラについて、ベアラを識別するためのベアラＩＤ３６２Ａ、アクセスゲートウェイ３３のＧＴＰ−Ｕエンドポイント情報３６２Ｂ、呼処理部（ＡＣＴ）１５１が割り当てるパケット転送部（ＡＣＴ）１５２のＧＴＰ−Ｕエンドポイント情報３６２Ｃ、及び呼処理部（ＳＢＹ）１５３が割り当てるパケット転送部（ＳＢＹ）１５４のＧＴＰ−Ｕエンドポイント情報３６２Ｄを含む。
【００６８】
呼処理プロトコル管理テーブルへのポインタ３６３は、ＧＴＰ−Ｃセッション管理テーブル３２１−１及びＤｉａｍｅｔｅｒセッション管理テーブル３２２−１のエントリを呼び出すためのポインタである。
【００６９】
呼処理同期状態管理部１５５は、呼状態管理テーブル３１０の呼処理プロトコル管理テーブルへのポインタ３６３を参照することによって、呼処理プロトコルのトランザクション状態（各呼処理部の呼状態の不一致）がどの呼に影響するのかを容易に特定することができる。
【００７０】
また、呼処理同期状態管理部１５５は、呼処理部（ＡＣＴ）１５１から呼処理部（ＳＢＹ）１５３に系切替えが実行された場合、ベアラ情報３６２を参照し、ユーザトラフィックの転送先をパケット転送部（ＡＣＴ）１５２からパケット転送部（ＳＢＹ）１５４へ書き換える。これによって、サービス網ゲートウェイ２１は、ユーザトラフィックの転送処理を継続することができる。
【００７１】
［４−３．ＧＴＰ−Ｃ管理テーブル３２１の構成］
以下に、ＧＴＰ−Ｃ管理テーブル３２０について、図６Ａ及び図６Ｂを用いて説明する。
【００７２】
［４−３−１．ＧＴＰ−Ｃセッション管理テーブル３２１−１の構成］
図６Ａは、本発明の第１の実施形態のＧＴＰ−Ｃセッション管理テーブル３２１−１の構成を示す説明図である。
【００７３】
ＧＴＰ−Ｃセッション管理テーブル３２１−１は、ＧＴＰ−Ｃエンドポイント情報３７１、呼状態管理テーブルへのポインタ３７２、及びＧＴＰ−Ｃトランザクション管理テーブルへのポインタ３７３を含む。
【００７４】
ここで、ＧＴＰ−Ｃエンドポイント情報とは、呼処理パケット（例えば、ＬＥＴにおいては、ＧＴＰ−Ｃパケット）を転送するために設定される仮想トンネル（ＧＴＰ−Ｃトンネル）の端点のＩＰアドレスと、ＧＴＰ−Ｃトンネルを識別するためのＧＴＰ−ＣトンネルＩＤとの組み合わせである。
【００７５】
具体的には、ＧＴＰ−Ｃエンドポイント情報３７１は、アクセスゲートウェイ３３のＧＴＰ−Ｃエンドポイント情報３７１Ａ、呼処理部（ＡＣＴ）１５１のＧＴＰ−Ｃエンドポイント情報３７１Ｂ、呼処理部（ＳＢＹ）１５３のＧＴＰ−Ｃエンドポイント情報３７１Ｃを含む。
【００７６】
呼状態管理テーブルへのポインタ３７２は、呼状態管理テーブル３１０のエントリを呼び出すためのポインタである。ＧＴＰ−Ｃトランザクション管理テーブルへのポインタ３７３は、ＧＴＰ−Ｃトランザクション管理テーブル３２１−１のエントリを呼び出すためのポインタである。
【００７７】
呼処理同期状態管理部１５５は、ＧＴＰ−Ｃセッション管理テーブル３２１−１の呼状態管理テーブルへのポインタ３７２及びＧＴＰ−Ｃトランザクション管理テーブルへのポインタ３７３を参照することによって、呼処理プロトコルのトランザクション状態（各呼処理部の呼状態の不一致）がどの呼に影響するのかを容易に特定することができる。
【００７８】
また、呼処理同期状態管理部１５５は、呼処理部（ＡＣＴ）１５１から呼処理部（ＳＢＹ）１５３に系切替えが実行された場合、ＧＴＰ−Ｃエンドポイント情報３７１を参照し、呼処理パケット（ＧＴＰ−Ｃパケット）の転送先を呼処理部（ＡＣＴ）１５１から呼処理部（ＳＢＹ）１５３へ書き換える。つまり、ＧＴＰ−Ｃパケットの転送先であるＧＴＰ−Ｃエンドポイント情報を呼処理部（ＡＣＴ）のＧＴＰ−ＣトンネルＩＤから呼処理部（ＳＢＹ）のＧＴＰ−ＣトンネルＩＤに書き換える。これによって、サービス網ゲートウェイ２１は、ＧＴＰ−Ｃパケットの転送処理を継続することができる。
【００７９】
［４−３−２．ＧＴＰ−Ｃトランザクション管理テーブル３２１−２の構成］
図６Ｂは、本発明の第１の実施形態のＧＴＰ−Ｃトランザクション管理テーブル３２１−２の構成の例を示す説明図である。
【００８０】
ＧＴＰ−Ｃトランザクション管理テーブル３２１−２は、トランザクションＩＤ３８１、トランザクション状態３８２、及びＧＴＰ−Ｃセッション管理テーブルへのポインタ３８３を含む。トランザクションＩＤ３８１は、アクセスゲートウェイ３３によって割り当てられるＧＴＰ−ＣトランザクションＩＤであり、例えば、ＩＰアドレス、ＵＤＰポート番号、ＧＴＰ−Ｃシーケンス番号である。
【００８１】
トランザクション状態３８２は、呼処理部（ＡＣＴ）１５１と呼処理部（ＳＢＹ）１５３とのＧＴＰ−Ｃトランザクション状態（リクエスト／レスポンスの送受信状態）を示す状態変数である。なお、トランザクション状態３８２の遷移の例については、図７を用いて後述する。
【００８２】
ＧＴＰ−Ｃセッション管理テーブルへのポインタ３８３は、ＧＴＰ−Ｃセッション管理テーブル３２１−１のエントリを呼び出すためのポインタである。
【００８３】
呼処理同期状態管理部１５５は、ＧＴＰ−Ｃセッション管理テーブルへのポインタ３８３を参照することによって、呼処理プロトコルのトランザクション状態の不一致（各呼処理部の呼状態の不一致）がどの呼に影響するのかを容易に特定することができる。また、呼処理同期状態管理部１５５は、トランザクション状態３８２を参照することによって、呼処理部（ＡＣＴ）と呼処理部（ＳＢＹ）との各呼状態の不一致を判定することができる。
【００８４】
［５．ＧＴＰ−Ｃトランザクション状態の遷移］
図７は、本発明の第１の実施形態のＧＴＰ−Ｃトランザクション状態遷移５００を示す説明図である。
【００８５】
はじめに、トランザクション状態の初期状態は、「ＮＵＬＬ」である。次に、アクセスゲートウェイ３３から、ＧＴＰ−Ｃリクエスト受信イベント（Ｅ５０１）が通知されると、トランザクション状態は、「ＲＥＱ＿ＲＥＣＥＩＶＥＤ」に遷移する。また、「ＲＥＱ＿ＲＥＣＥＩＶＥＤ」に遷移すると、タイマＡが開始される。
【００８６】
次に、「ＲＥＱ＿ＲＥＣＥＩＶＥＤ」の後の状態遷移（Ｅ５０２〜Ｅ５０４）について説明する。まず、呼処理部（ＡＣＴ）１５１から、ＧＴＰ−Ｃレスポンス受信イベント（Ｅ５０２）が通知されると、トランザクション状態は、「ＡＣＴ＿ＲＳＰ＿ＳＥＮＴ」に遷移し、さらに、タイマＢが開始される。また、呼処理部（ＳＢＹ）１５３から、ＧＴＰ−Ｃレスポンス受信イベント（Ｅ５０３）が通知されると、トランザクション状態は、「ＳＢＹ＿ＲＳＰ＿ＳＥＮＴ」に遷移し、さらに、タイマＣが開始される。なお、呼処理部（ＡＣＴ）１５１及び呼処理部（ＳＢＹ）１５３のいずれのレスポンスも受信されないで、タイマＡの満了イベント（Ｅ５０４）が通知されると、トランザクション状態は、再び、「ＮＵＬＬ」にリセットされる。
【００８７】
次に、「ＡＣＴ＿ＲＳＰ＿ＳＥＮＴ」の後の状態遷移（Ｅ５０５〜Ｅ５０６）について説明する。まず、呼処理部（ＳＢＹ）１５３から、ＧＴＰ−Ｃレスポンス受信イベント（Ｅ５０５）が通知されると、トランザクション状態は、同期確立状態を示す「ＲＳＰ＿ＳＥＮＴ」に遷移し、再び、「ＮＵＬＬ」にリセットされる。また、呼処理部（ＳＢＹ）１５３からのレスポンスが受信されないで、タイマＢ満了イベント（Ｅ５０６）が通知されると、呼処理同期状態管理部１５５は、呼処理部（ＳＢＹ）１５３に同期確立要求を送信する。同期確立要求が送信されると、トランザクション状態は、同期確立開始を示す「ＳＹＮＣ＿ＳＴＡＲＴ」に遷移し、タイマＤが開始される。
【００８８】
次に、「ＳＢＹ＿ＲＳＰ＿ＳＥＮＴ」からの状態遷移（Ｅ５０７〜Ｅ５０８）について説明する。まず、呼処理部（ＡＣＴ）から、ＧＴＰ−Ｃレスポンス受信イベント（Ｅ５０７）が通知されると、トランザクション状態は、同期確立状態を示す「ＲＳＰ＿ＳＥＮＴ」に遷移し、再び、「ＮＵＬＬ」にリセットされる。また、呼処理部（ＡＣＴ）１５１からのレスポンスが受信されずに、タイマＣ満了イベント（Ｅ５０８）が通知されると、呼処理同期状態管理部１５５は、呼処理部（ＳＢＹ）１５３に同期確立要求を送信する（Ｅ５０８）。同期確立要求が送信されると、トランザクション状態は、同期確立開始を示す「ＳＹＮＣ＿ＳＴＡＲＴ」に遷移し、タイマＤが開始される。
【００８９】
最後に、「ＳＹＮＣ＿ＳＴＡＲＴ」の後の状態遷移（Ｅ５０９〜Ｅ５１０）について説明する。まず、呼処理部（ＳＢＹ）１５３から、同期完了通知受信イベント（Ｅ５０９）が通知されると、同期再確立に成功したと判定され、トランザクション状態は、再び、「ＮＵＬＬ」にリセットされる。また、呼処理部（ＳＢＹ）１５３からの同期完了通知が受信されないで、タイマＤ満了イベント（Ｅ５１０）が通知されると、同期再確立に失敗したと判定され、トランザクション状態は、「ＳＹＳＴＥＭ＿ＥＲＲＯＲ」に遷移する。
【００９０】
なお、トランザクション状態の状態変数（例えば、「ＮＵＬＬ」、「ＲＥＱ＿ＲＥＣＥＩＶＥＤ」など）は、図６Ｂに示したＧＴＰ−Ｃトランザクション管理テーブル３２１−２のトランザクション状態３８２に格納される。
【００９１】
［６．コールフロー］
以下に、図８から図１３を用いて、第１の実施形態におけるコールフローについて説明する。
【００９２】
［６−１．端末５接続時の正常系コールフロー］
図８は、本発明の第１の実施形態のサービス網ゲートウェイ２１が端末５を接続する場合の正常系コールフローを示す説明図である。
【００９３】
図８に示したコールフローでは、呼処理部（ＡＣＴ）１５１と呼処理部（ＳＢＹ）１５３との各呼状態の不一致は発生せず、正常に呼処理が実行される場合が示される。
【００９４】
はじめに、端末５は、基地局３１Ｂ、移動管理サーバ３２に接続要求を送信する（６０１）。接続要求には、ユーザＩＤが含まれる。次に、移動管理サーバ３２は、端末５から送信されたユーザＩＤを認証サーバ２３に転送する。認証サーバ２３は、ユーザ認証を実行する（６０２）。
【００９５】
次に、移動管理サーバ３２は、アクセスゲートウェイ３３にセッション確立要求を送信する（６０３）。セッション確立要求には、サービス網ＩＤ、ユーザＩＤ及びベアラＩＤが含まれる。ここで、移動管理サーバ３２は、認証サーバ２３から取得された、端末５の加入者情報に基づいて、接続先のサービス網ＩＤを指定する。また、移動管理サーバ３２は、端末５のユーザトラフィックを転送するために設定された仮想トンネルを識別するためのベアラＩＤを設定する。
【００９６】
なお、ベアラＩＤは、アクセスゲートウェイ３３とサービス網ゲートウェイ２１との間に設立される仮想トンネル（ＧＴＰ−Ｕトンネル）の端点の情報に対応付けられる。また、ベアラＩＤは、さらに、基地局３１Ｂとアクセスゲートウェイ３３との間に設定される仮想トンネルの端点の情報に対応付けられてもよい。
【００９７】
次に、アクセスゲートウェイ３３は、指定されたサービス網ＩＤに対応するサービス網ゲートウェイ２１にセッション確立要求を送信する（６０４）。セッション確立要求には、サービス網ＩＤ、ユーザＩＤ、アクセスゲートウェイ３３のＧＴＰ−ＣトンネルＩＤ、ベアラＩＤ、及びアクセスゲートウェイ３３のＧＴＰ−ＵトンネルＩＤが含まれる。
【００９８】
なお、このＧＴＰ−ＣトンネルＩＤは、端末５の呼処理のために、アクセスゲートウェイ３３とサービス網ゲートウェイ２１との間に設定された仮想トンネル（ＧＴＰ−Ｃトンネル）において、アクセスゲートウェイ３３側のＧＴＰ−Ｃエンドポイントを識別するための識別子である。
【００９９】
また、このＧＴＰ−ＵトンネルＩＤは、端末５のユーザトラフィックの転送のために、アクセスゲートウェイ３３とサービス網ゲートウェイ２１の間に設定された仮想トンネル（ＧＴＰ−Ｕトンネル）において、アクセスゲートウェイ３３側のＧＴＰ−Ｕエンドポイントを識別するための識別子である。ＧＴＰ−ＵトンネルＩＤは、前述したベアラＩＤに対応付けられる。
【０１００】
次に、セッション確立要求がサービス網ゲートウェイ２１に送信されると、まず、ＳＷＢ１２０内の呼処理同期状態管理部１５５は、セッション確立要求を受信する。そして、呼処理同期状態管理部１５５は、ＧＴＰ−Ｃパケット転送ルーチンＰ１＿８００（図１２参照）を実行する（６０５）。
【０１０１】
図１２は、本発明の第１の実施形態のＧＴＰ−Ｃパケット転送ルーチンＰ１＿８００を示すフローチャートである。
【０１０２】
はじめに、呼処理同期状態管理部１５５は、端末５を接続するための呼処理パケット（ＧＴＰ−Ｃパケット）の内容に基づいて、ＧＴＰ−Ｃトランザクション管理テーブル３２１−２を更新する（８０１）。次に、ＧＴＰ−Ｃセッション管理テーブル３２１−１を更新する（８０２）。次に、呼状態管理テーブル３１０を更新する（８０３）。
【０１０３】
そして、呼処理同期状態管理部１５５は、受信したＧＴＰ−Ｃパケットの送信元を判定する（８０４）。ステップ８０４において、送信元が他ノード（ＡＧＷ）であると判定された場合、呼処理同期状態管理部１５５は、受信したＧＴＰ−Ｃパケットを、呼処理部（ＡＣＴ）１５１及び呼処理部（ＳＢＹ）１５３の双方に転送する（８０５）。
【０１０４】
また、ステップ８０４において、送信元が呼処理部（ＡＣＴ）１５１であると判定された場合、呼処理同期状態管理部１５５は、受信したＧＴＰ−Ｃパケットを、他ノード（ＡＧＷ）に転送する（８０６）。また、ステップ８０４において、送信元が呼処理部（ＳＢＹ）１５３であると判定された場合、呼処理同期状態管理部１５５は、受信したＧＴＰ−Ｃパケットを転送せず、破棄する。
【０１０５】
なお、呼処理同期状態管理部１５５は、ステップ８０１に対応する処理として、ＧＴＰ−Ｃトランザクション管理テーブル３２１−２に新規エントリを追加し、追加された新規エントリのトランザクションＩＤ３８１に、アクセスゲートウェイ３３によって割り当てられた値を設定する。また、図７に示した状態遷移に従って、追加された新規エントリのトランザクション状態３８２に状態変数「ＲＥＱ＿ＲＥＣＥＩＶＥＤ」を設定する。また、追加された新規エントリのＧＴＰ−Ｃセッション管理テーブルへのポインタ３８３に、ＧＴＰ−Ｃセッション管理テーブル３２１−１へのポインタを設定する。
【０１０６】
また、呼処理同期状態管理部１５５は、ステップ８０２に対応する処理として、ＧＴＰ−Ｃセッション管理テーブル３２１−１に新規エントリを追加し、追加された新規エントリのＧＴＰ−Ｃエンドポイント情報（ＡＧＷ）３７１Ａに、アクセスゲートウェイ３３側のＧＴＰ−Ｃトンネルの端点の情報（ＧＴＰ−ＣトンネルＩＤ）を設定する。また、追加された新規エントリのＧＴＰ−Ｃトランザクション管理テーブルへのポインタ３７３に、ＧＴＰ−Ｃトランザクション管理テーブル３２１−２へのポインタを設定する。
【０１０７】
また、呼処理同期状態管理部１５５は、ステップ８０３に対応する処理として、呼状態管理テーブル３１０に新規エントリを追加し、追加された新規エントリのサービス網ＩＤ３６１Ａ、ユーザＩＤ３６１Ｂ、ベアラＩＤ３６２Ａ、ＧＴＰ−Ｕエンドポイント情報（ＡＧＷ）３６２Ｂのそれぞれに、アクセスゲートウェイ３３から送信されたサービス網ＩＤ、ユーザＩＤ、ベアラＩＤ、ＧＴＰ−ＵトンネルＩＤ（及びＩＰアドレス）を設定する。また、追加された新規エントリの呼処理プロトコル管理テーブルへのポインタ（ＧＴＰ）３６３Ａに、ＧＴＰ−Ｃセッション管理テーブル３２１−１へのポインタを設定する。
【０１０８】
また、呼処理同期状態管理部１５５は、ステップ８０５に対応する処理として、セッション確立要求を、呼処理部（ＡＣＴ）１５１及び呼処理部（ＳＢＹ）１５３の双方に転送する（図８の６０６−１、６０６−２）。
【０１０９】
図８のステップ６０５以降の説明に戻る。ＧＴＰ−Ｃパケット転送ルーチンＰ１＿８００が実行される（６０５）と、セッション確立要求がＰＢ＃１＿１００−１とＰＢ＃２＿１００−２の双方に転送される（６０６−１、６０６−２）。そして、ＰＢ＃１＿１００−１内の呼処理部（ＡＣＴ）１５１は、セッション確立要求に対応する呼処理を実行し、セッション確立応答（ＡＣＴ）をＳＷＢ１２０内の呼処理同期状態管理部１５５に送信する（６０７）。セッション確立応答（ＡＣＴ）には、呼処理部（ＡＣＴ）１５１のＧＴＰ−ＣトンネルＩＤ、ベアラＩＤ、及び呼処理部（ＡＣＴ）１５１のＧＴＰ−ＵトンネルＩＤが含まれる。
【０１１０】
ＧＴＰ−ＣトンネルＩＤは、端末５の呼処理のために、アクセスゲートウェイ３３とサービス網ゲートウェイ２１との間に設定された仮想トンネル（ＧＴＰ−Ｃ）において、サービス網ゲートウェイ２１側のＧＴＰ−Ｃエンドポイントを識別するための識別子である。
【０１１１】
また、ＧＴＰ−ＵトンネルＩＤは、端末５のユーザトラフィック転送のために確立された、アクセスゲートウェイ３３とサービス網ゲートウェイ２１の間に設定されるＧＴＰ−Ｕ仮想トンネルにおいて、サービス網ゲートウェイ２１側のＧＴＰ−Ｕエンドポイントを識別するためのＩＤである。
【０１１２】
次に、ＳＷＢ１２０内の呼処理同期状態管理部１５５は、セッション確立応答（ＡＣＴ）を受信する（６０７）と、再び、ＧＴＰ−Ｃパケット転送ルーチンＰ１＿８００を実行する（６０８）。なお、この場合、呼処理同期状態管理部１５５は、図１２のステップ８０１に対応する処理として、ステップ６０５において、ＧＴＰ−Ｃトランザクション管理テーブル３２１−２に新規に追加されたエントリのトランザクション状態３８２を「ＡＣＴ＿ＲＳＰ＿ＳＥＮＴ」に更新する。
【０１１３】
また、呼処理同期状態管理部１５５は、図１２のステップ８０２に対応する処理として、ステップ６０５において、ＧＴＰ−Ｃセッション管理テーブル３２１−１に新規に追加されたエントリのＧＴＰ−Ｃエンドポイント情報（呼処理部（ＡＣＴ））３７１Ｂに、呼処理部（ＡＣＴ）１５１から送信されたＧＴＰ−ＣトンネルＩＤを設定する。
【０１１４】
また、呼処理同期状態管理部１５５は、図１２のステップ８０３に対応する処理として、ステップ６０５において、呼状態管理テーブル３１０に新規に追加されたエントリのＧＴＰ−Ｕエンドポイント情報３６２Ｃに、呼処理部（ＡＣＴ）１５１から送信されたＧＴＰ−ＵトンネルＩＤを設定する。
【０１１５】
また、呼処理同期状態管理部１５５は、ステップ８０６に対応する処理として、呼処理部（ＡＣＴ）１５１から送信されたセッション確立応答（ＡＣＴ）をアクセスゲートウェイ３３に転送する（６０９）。
【０１１６】
次に、ＰＢ＃２＿１００−２内の呼処理部（ＳＢＹ）１５３は、セッション確立要求（６０６−２）に対応する呼処理を実行し、セッション確立応答（ＳＢＹ）をＳＷＢ１２０内の呼処理同期状態管理部１５５に送信する（６１０）。
【０１１７】
このセッション確立応答（ＳＢＹ）には、呼処理部（ＳＢＹ）１５３のＧＴＰ−ＣトンネルＩＤ、ベアラＩＤ、及び呼処理部（ＳＢＹ）１５３のＧＴＰ−ＵトンネルＩＤが含まれる。なお、ＧＴＰ−ＣトンネルＩＤ及びＧＴＰ−ＵトンネルＩＤは、呼処理部（ＳＢＹ）１５３が割り当てる識別子であるので、ステップ６０７において、呼処理部（ＡＣＴ）１５１が割り当てる識別子とは異なる場合がある。
【０１１８】
次に、ＳＷＢ１２０内の呼処理同期状態管理部１５５は、セッション確立応答（ＳＢＹ）を受信する（６１０）と、再び、図１２に示したＧＴＰ−Ｃパケット転送ルーチンＰ１＿８００を実行する（６１１）。
【０１１９】
なお、この場合、呼処理同期状態管理部１５５は、図１２のステップ８０１に対応する処理として、ステップ６０５において、ＧＴＰ−Ｃトランザクション管理テーブル３２１−２に新規に追加されたエントリのトランザクション状態３８２を「ＲＳＰ＿ＳＥＮＴ」に更新する。なお、その後、トランザクション状態３８２が「ＮＵＬＬ」に更新されると、ＧＴＰ−Ｃトランザクション管理テーブル（３２１−２）から、ステップ６０５において追加されたエントリは削除される。
【０１２０】
また、呼処理同期状態管理部１５５は、図１２のステップ８０２に対応する処理として、ステップ６０５において、ＧＴＰ−Ｃセッション管理テーブル３２１−１に新規に追加されたエントリの、ＧＴＰ−Ｃエンドポイント情報（呼処理部（ＳＢＹ））３７１Ｃに、呼処理部（ＳＢＹ）から送信されたＧＴＰ−ＣトンネルＩＤを設定する。
【０１２１】
また、呼処理同期状態管理部１５５は、図１２のステップ８０３に対応する処理として、ステップ６０５において、呼状態管理テーブル３１０に新規に追加されたエントリのＧＴＰ−Ｕエンドポイント情報（パケット転送部（ＳＢＹ））３６２Ｄに、呼処理部（ＳＢＹ）１５３から送信されたＧＴＰ−ＵトンネルＩＤを設定する。
【０１２２】
なお、図１２のステップ８０４において、呼処理同期状態管理部１５５が受信したＧＴＰ−Ｃパケットの送信元は呼処理部（ＳＢＹ）１５３であると判定されるので、呼処理同期状態管理部１５５は、セッション確立応答（ＳＢＹ）をアクセスゲートウェイ３３に転送せず、廃棄する。
【０１２３】
次に、アクセスゲートウェイ３３は、セッション確立応答（ＡＣＴ）を受信する（６０９）と、受信したセッション確立応答を移動管理サーバ３２に送信する（６１２）。移動管理サーバ３２は、端末５に接続許可を送信する（６１３）。端末５は、移動管理サーバ３２に接続確認を送信する（６１４）。移動管理サーバ３２は、端末５から送信された接続確認を受信する（６１４）と、アクセスゲートウェイ３３にベアラ更新要求を送信する（６１５）。最後に、アクセスゲートウェイ３３は、移動管理サーバ３２にベアラ更新応答を送信する（６１６）。
【０１２４】
以上説明した処理によって、端末５の接続処理が完了し、端末５と、基地局３１Ｂと、アクセスゲートウェイ３３と、サービス網ゲートウェイ２１と、アプリケーションサーバ１１との間のユーザトラフィックの経路（パス）が確立する（６１７）。
【０１２５】
［６−２．端末５接続時の準正常系コールフロー］
図９は、本発明の第１の実施形態のサービス網ゲートウェイ２１が端末５を接続する場合の準正常系コールフローを示す説明図である。
【０１２６】
図９に示したコールフローでは、呼処理部（ＳＢＹ）１５３側のみで呼処理パケット（ＧＴＰ−Ｃパケット）が消失したため、呼処理部（ＡＣＴ）１５１と呼処理部（ＳＢＹ）１５３との各呼状態の不一致が発生するが、呼処理同期状態管理部１５５が各呼状態の不一致を検出し、各呼状態を再同期する場合が示される。
【０１２７】
はじめに、図８のステップ６０１から６０５に対応する処理が実行される。つまり、ＳＷＢ１２０内の呼処理同期状態管理部１５５は、セッション確立要求を受信すると、ＧＴＰ−Ｃパケット転送ルーチンＰ１＿８００を実行し、ＰＢ＃１＿１００−１内の呼処理部（ＡＣＴ）１５１及びＰＢ＃２＿１００−２内の呼処理部（ＳＢＹ）１５３の双方に、セッション確立要求を送信する（６３１−１、６３１−２）。
【０１２８】
ＰＢ＃１＿１００−１内の呼処理部（ＡＣＴ）１５１は、セッション確立要求に対応する呼処理を実行し、セッション確立応答（ＡＣＴ）をＳＷＢ１２０に送信する（６３２）。ＳＷＢ１２０内の呼処理同期状態管理部１５５は、セッション確立応答（ＡＣＴ）を受信すると、図１２に示したＧＴＰ−Ｃパケット転送ルーチンＰ１＿８００を実行する（６３３）。
【０１２９】
そして、呼処理同期状態管理部１５５は、セッション確立応答（ＡＣＴ）をアクセスゲートウェイ３３に送信する（６３４）。一方、ＰＢ＃２＿１００−２に送信されたセッション確立要求は消失した（６３１−２）ので、ＰＢ＃２＿１００−２内の呼処理部（ＳＢＹ）１５３からセッション確立応答が送信されない。このため、呼処理同期状態管理部１５５が管理するトランザクションの管理タイマ（図７のタイマＢ）が満了する（６３５）。タイマＢが満了すると、呼処理同期状態管理部１５５は、各呼状態に不一致が発生したと判定し、図１３に示す呼識別子抽出ルーチンＰ２＿８２０を実行する（６３６）。
【０１３０】
図１３は、本発明の第１の実施形態の呼識別子抽出ルーチンＰ２＿８２０を示すフローチャートである。
【０１３１】
はじめに、呼処理同期状態管理部１５５は、図６Ｂに示したＧＴＰ−Ｃトランザクション管理テーブル３２１−２のＧＴＰ−Ｃセッション管理テーブルへのポインタ３８３を参照して、各呼状態の不一致が発生しているＧＴＰ−Ｃセッション管理テーブル３２１−１のエントリを特定する（８２１）。次に、特定されたＧＴＰ−Ｃセッション管理テーブル３２１−１のエントリの呼状態管理テーブルへのポインタ３７２を参照し、各呼状態の不一致が発生している呼状態管理テーブル３１０のエントリを特定する（８２２）。特定されたエントリの呼識別子３６１を特定する（８２３）。以上の処理によって、呼識別子抽出ルーチンＰ２＿８２０が終了する。
【０１３２】
図９のステップ６３６以降の説明に戻る。ＳＷＢ１２０内の呼処理同期状態管理部１５５は、ステップ６３６の後、ＰＢ＃２＿１００−２内の呼処理部（ＳＢＹ）１５３に、同期要求を送信する（６３７）。なお、ステップ６３６は、図７に示した呼処理部（ＳＢＹ）１５３への同期要求の送信（Ｅ５０６）に対応する。この同期要求には、ステップ６３６で特定された呼識別子３６１（すなわち、サービス網ＩＤ３６１ＡとユーザＩＤ３６１Ｂとの組）が含まれる。
【０１３３】
次に、呼処理部（ＳＢＹ）１５３は、ＰＢ＃１＿１００−１内の呼処理部（ＡＣＴ）１５１に、呼状態要求を送信し、特定された呼識別子に対応する、呼処理部（ＡＣＴ）１５１の呼状態を問い合わせる（６３８）。呼処理部（ＡＣＴ）１５１は、呼処理部（ＳＢＹ）１５３に、呼状態応答を送信する（６３９）。
【０１３４】
呼処理部（ＳＢＹ）１５３は、呼処理部（ＳＢＹ）１５３が備える内部テーブル（図示省略）に、特定された呼識別子（サービス網ＩＤ及びユーザＩＤ）に対応するエントリを設定し、さらに、設定されたエントリに呼処理部（ＡＣＴ）１５１から送信された呼状態の情報（例えば、ＧＴＰ−ＣトンネルＩＤ及びＧＴＰ−ＵトンネルＩＤ）を設定する。その後、呼処理部（ＳＢＹ）１５３は、呼処理同期状態管理部１５５に、セッション確立応答（ＳＢＹ）を含む同期完了通知を送信する（６４０）。なお、ステップ６４０は、図７に示した呼処理部（ＳＢＹ）１５３からの同期完了の通知（Ｅ５０９）に対応する。
【０１３５】
以上の処理によって、呼処理同期状態管理部１５５は、各呼状態の不一致を検出し、各呼状態を再同期させることができる。
【０１３６】
［６−３．端末５切断時のコールフロー］
図１０は、本発明の第１の実施形態のサービス網ゲートウェイ２１が端末５を切断する場合のコールフローを示す説明図である。
【０１３７】
図１０に示したコールフローでは、正常に呼が切断され、呼処理管理テーブル３００から端末５の情報がすべて削除される場合が示される。
【０１３８】
はじめに、端末５は、基地局３１Ｂ及び移動管理サーバ３２に切断要求を送信する（６５１）。次に、移動管理サーバ３２は、アクセスゲートウェイ３３にセッション切断要求を送信する（６５２）。次に、アクセスゲートウェイ３３は、サービス網ゲートウェイ２１にセッション切断要求を送信する（６５３）。
【０１３９】
ＳＷＢ１２０内の呼処理同期状態管理部１５５は、セッション切断要求６５３を受信すると、図１２に示したＧＴＰ−Ｃパケット転送ルーチンＰ１＿８００を実行する（６５４）。ＧＴＰ−Ｃパケット転送ルーチンＰ１＿８００が実行されると、セッション切断要求が、ＰＢ＃１＿１００−１及びＰＢ＃２＿１００−２の双方に送信される（６５５−１、６５５−２）。
【０１４０】
ＰＢ＃１＿１００−１内の呼処理部（ＡＣＴ）１５１は、セッション切断要求（６５５−１）に対応する処理を実行し、ＳＷＢ１２０にセッション切断応答（ＡＣＴ）を送信する（６５６）。ＳＷＢ１２０内の呼処理同期状態管理部１５５は、セッション切断応答（ＡＣＴ）を受信すると、図１２に示したＧＴＰ−Ｃパケット転送ルーチンＰ１＿８００を再び実行する（６５７）。そして、ＧＴＰ−Ｃパケット転送ルーチンＰ１＿８００が実行されると、セッション切断応答（ＡＣＴ）がアクセスゲートウェイ３３に転送される（６５８）。
【０１４１】
また、ＰＢ＃２＿１００−２内の呼処理部（ＳＢＹ）１５３は、セッション切断要求に対応する処理を実行し、ＳＷＢ１２０にセッション切断応答（ＳＢＹ）を送信する（６５９）。ＳＷＢ１２０内の呼処理同期状態管理部１５５は、セッション切断応答（ＳＢＹ）を受信する（６５９）と、図１２に示したＧＴＰ−Ｃパケット転送ルーチンＰ１＿８００を再び実行する（６６０）。
【０１４２】
なお、この場合、呼処理同期状態管理部１５５は、図１２のステップ８０１から８０３に対応する処理として、ＧＴＰ−Ｃトランザクション管理テーブル３２１、ＧＴＰ−Ｃセッション管理テーブル３２１−１、及び呼状態管理テーブル３１０から、端末５のユーザＩＤに対応するエントリをすべて削除する。また、図１２のステップ８０４において、ＧＴＰ−Ｃパケットの送信元は呼処理部（ＳＢＹ）１５３であると判定されるので、呼処理同期状態管理部１５５は、セッション切断応答（ＳＢＹ）をアクセスゲートウェイ３３に転送せず、廃棄する。
【０１４３】
次に、アクセスゲートウェイ３３は、セッション切断応答（ＡＣＴ）を受信する（６５８）と、移動管理サーバ３２にセッション切断応答を送信する（６６１）。移動管理サーバ３２は、基地局３１Ｂ及び端末５にセッション切断応答を送信する（６６２）。
【０１４４】
［６−４．系切替え時のコールフロー］
図１１は、本発明の第１の実施形態のサービス網ゲートウェイ２１が現用系の呼処理部から予備系の呼処理部へ系切替えを実行する場合のコールフローを示す説明図である。
【０１４５】
ＰＢ＃１＿１００−１内の呼処理部（ＡＣＴ）１５１と、ＰＢ＃２＿１００−２内の呼処理部（ＳＢＹ）１５３と、は常時互いの稼働状況を監視する（６８１）。そして、呼処理部（ＡＣＴ）１５１に障害が発生すると、呼処理部（ＳＢＹ）１５３は、その障害を検出する（６８２）。この場合、呼処理部（ＳＢＹ）１５３は、まず呼処理を一旦停止し（６８３）、ＳＷＢ１２０内の呼処理同期状態管理部１５５に、切換え要求を送信する（６８４）。
【０１４６】
ＳＷＢ１２０内の呼処理同期状態管理部１５５は、切換え要求を受信すると、図１３に示した呼識別子抽出ルーチンＰ２＿８２０を実行し、同期が確立していない呼識別子を特定し、特定された呼識別子のリストを含む切換え応答を、呼処理部（ＳＢＹ）１５３に送信する（６８６）。
【０１４７】
呼処理部（ＳＢＹ）１５３は、送信された呼識別子に対応する呼状態を無効化した（６８７）する。具体的には、呼処理部（ＳＢＹ）１５３が備える呼状態を管理するためのテーブル（図示省略）から、送信された呼識別子に対応する呼状態が格納されたエントリを削除する。その後、呼処理を再開し（６８８）、呼処理部（ＡＣＴ）１５１の処理を引き継ぐ。
【０１４８】
なお、ＳＷＢ１２０内の呼処理同期状態管理部１５５は、切換え応答を送信した（６８６）後、ＧＴＰ−Ｃパケットの転送先を呼処理部（ＡＣＴ）１５１から呼処理部（ＳＢＹ）１５３に書き換える。つまり、ＧＴＰ−Ｃパケットの転送先であるＧＴＰ−Ｃエンドポイント情報を呼処理部（ＡＣＴ）１５１のＧＴＰ−ＣトンネルＩＤから呼処理部（ＳＢＹ）１５３のＧＴＰ−ＣトンネルＩＤに書き換える（６８９）。
【０１４９】
また、呼処理同期状態管理部１５５は、ユーザトラフィックの転送先をパケット転送部（ＡＣＴ）１５２からパケット転送部（ＳＢＹ）１５４へ書き換える。つまり、ユーザトラフィックの転送先であるＧＴＰ−Ｕエンドポイント情報を呼処理部（ＡＣＴ）１５１のＧＴＰ−ＵトンネルＩＤから呼処理部（ＳＢＹ）１５３のＧＴＰ−ＵトンネルＩＤに書き換える（６９０）。なお、この場合、呼処理同期状態管理部１５５は、休止している呼処理部（ＳＢＹ）１５３を起動する。
【０１５０】
これによって、サービス網ゲートウェイ２１は、呼処理部（ＡＣＴ）１５１に障害が発生した場合であっても、ＧＴＰ−Ｃパケット及びユーザトラフィックの転送処理を継続することができる。
【０１５１】
以上説明したように、第１の実施形態では、呼処理同期状態管理部１５５が呼処理部（ＡＣＴ）１５１及び呼処理部（ＳＢＹ）１５３に呼処理パケット（ＧＴＰ−Ｃパケット）を転送し、転送されたＧＴＰ−Ｃパケットの内容に基づいて、トランザクション状態を管理するので、サービス網ゲートウェイ２１は、トランザクション状態に基づいて、呼処理部（ＳＢＹ）と呼処理部（ＡＣＴ）との各呼状態の同期を維持することができる。
【０１５２】
［実施形態２］
以下、本発明の第２の実施形態について図面を参照して説明する。第２の実施形態では、予備系の呼処理部（ＳＢＹ）１５３が呼処理プロトコルを中継し、現用系の呼処理部（ＡＣＴ）１５１の呼状態を常時ミラーリングすることによって、各呼状態の同期を維持する。
【０１５３】
［１．ネットワーク及びサービス網ゲートウェイ２１の構成］
第２の実施形態のネットワークの構成は、図２に示した第１の実施形態のネットワークの構成と同じである。また、第２の実施形態のサービス網ゲートウェイ２１のハードウェアの構成は、図３に示した第１の実施形態のサービス網ゲートウェイ２１のハードウェアの構成と同じである。
【０１５４】
［２．サービス網ゲートウェイ２１の冗長化］
図１Ｂは、本発明の第２の実施形態のサービス網ゲートウェイ２１の構成を示すブロック図である。
【０１５５】
ＰＢ＃１＿１００−１は、現用系であり、呼処理部（ＡＣＴ）１１５１及びパケット転送部（ＡＣＴ）１１５２を備える。ＰＢ＃２＿１００−２は、予備系であり、呼処理部（ＳＢＹ）１１５３及びパケット転送部（ＳＢＹ）１１５４（休止中）を備える。
【０１５６】
呼処理部（ＡＣＴ）１１５１及び呼処理部（ＳＢＹ）１１５３は、並列多重処理方式によって、冗長化される。つまり、サービス網ゲートウェイ２１は、現用系の呼処理部（ＡＣＴ）１１５１及び予備系の呼処理部（ＳＢＹ）１１５３を、それぞれ、ＰＢ＃１＿１００−１及びＰＢ＃２＿１００−２において独立に動作させる。ただし、呼処理部（ＳＢＹ）１１５３は、呼処理部（ＡＣＴ）１１５１と全く独立に動作するのではなく、呼処理部（ＡＣＴ）１１５１が送受信するＧＴＰ−Ｃパケットを中継し、呼処理部（ＡＣＴ）１１５１の呼状態を抽出する点で、第１の実施形態のサービス網ゲートウェイ２１と異なる。
【０１５７】
また、呼処理部（ＳＢＹ）１１５３は、呼処理部（ＡＣＴ）１１５１に障害が発生した場合、ＧＴＰ−Ｃパケットから抽出された呼状態を用いて、呼処理部（ＡＣＴ）１１５１の処理を引き継ぐ。また、このような冗長化を実現するために、サービス網ゲートウェイ２１は、パス管理部（図示省略）を備えてもよい。パス管理部は、他ノード（ＡＧＷ）から受信したＧＴＰ−Ｃパケットを、ＳＷＢ１２０を経由して、呼処理部（ＳＢＹ）１１５３に転送するためのパスを設定する。また、呼処理部（ＳＢＹ）１１５３に転送されたＧＴＰ−Ｃパケットを、ＳＷＢ１２０を経由して、呼処理部（ＡＣＴ）１１５１に転送するためのパスを設定する。
【０１５８】
さらに、パス管理部は、呼処理部（ＡＣＴ）１１５１から送信されたＧＴＰ−Ｃパケットを、ＳＷＢ１２０を経由して、呼処理部（ＳＢＹ）１１５３に転送するためのパスを設定する。また、パス管理部は、呼処理部（ＳＢＹ）１１５３が受信したＧＴＰ−Ｃパケットを、ＳＷＢ１２０を経由して、他ノードに転送するためのパスを設定する。なお、サービス網ゲートウェイ２１の装置内のパスは、例えば、ＶＬＡＮ、ＩＰｉｎＩＰトンネル等によって実現される。
【０１５９】
一方、パケット転送部（ＡＣＴ）１１５２、及びパケット転送部（ＳＢＹ）１１５４は、第１の実施形態のサービス網ゲートウェイ２１と同様に、１対１待機冗長方式によって、冗長化される。つまり、現用系のパケット転送部（ＡＣＴ）１１５２は、ＰＢ＃１＿１００−１で動作し、予備系のパケット転送部（ＳＢＹ）１１５４は、ＰＢ＃２＿１００−２で動作する。そして、ＳＷＢ１２０は、サービス網ゲートウェイ２１のパケット転送部（ＡＣＴ）１１５２と、他ノードとの間で、ユーザトラフィックを転送する。
【０１６０】
なお、呼処理部（ＡＣＴ）１１５１とパケット転送部（ＡＣＴ）１１５２とは対で動作する。また、呼処理部（ＳＢＹ）１１５３とパケット転送部（ＳＢＹ）１１５４とは対で動作する。サービス網ゲートウェイ２１は、呼処理部（ＡＣＴ）１１５１から呼処理部（ＳＢＹ）１１５３への系切替えを実行する場合、パケット転送部（ＡＣＴ）１１５２からパケット転送部（ＳＢＹ）１１５４への系切替えも同時に実行する。
【０１６１】
［３．呼処理管理テーブル１３００］
以下に、呼処理管理テーブル１３００の構成について、図１４から図１７を用いて説明する。なお、呼処理管理テーブル１３００は、呼処理部（ＳＢＹ）１１５３が、呼処理部（ＡＣＴ）１１５１の呼状態を管理するためのテーブルである。呼処理管理テーブル１３００は、ＰＢ＃２＿１００−２のメモリ１０３に格納される。
【０１６２】
［３−１．呼処理管理テーブル１３００の構成］
図１４は、本発明の第２の実施形態の呼処理管理テーブル１３００の構成を示す説明図である。
【０１６３】
呼処理管理テーブル１３００は、呼状態管理テーブル１３１０、呼処理プロトコル管理テーブル１３２０及びトランスポートプロトコル管理テーブル１３３０を含む。呼状態管理テーブル１３１０は、呼処理プロトコルに依存しないサービス網毎、ユーザ毎の接続状況を管理するためのテーブルである。
【０１６４】
呼処理プロトコル管理テーブル１３２０は、呼処理プロトコルとして用いられるＧＴＰ−Ｃ、Ｄｉａｍｅｔｅｒなどの呼処理プロトコル状態を管理するためのテーブルである。
【０１６５】
トランスポートプロトコル管理テーブル１３３０は、ＵＤＰ、ＳＣＴＰなどのトランスポートプロトコルの状態を管理するためのテーブルであり、トランスポートプロトコル毎に定義される。
【０１６６】
呼処理管理テーブル１３００は、図４に示した呼処理管理テーブル３００よりも、管理する情報量（テーブル数）が多い。なぜならば、第１の実施形態の呼処理管理テーブル３００は、呼状態の不一致の判定、及び系切替え時のトンネル宛先変換に用いる情報のみを管理するが、第２の実施系の呼処理管理テーブル１３００は、系切替え時に呼処理を引き継ぐための情報をすべて管理するからである。そのため、呼処理管理テーブル１３００は、第１の実施形態の呼処理管理テーブル３００が含む各テーブルのほか、さらに、ＧＴＰ−Ｃパス管理テーブル１３２１−３、Ｄｉａｍｅｔｅｒピア管理テーブル１３２２−３、ＵＤＰ管理テーブル１３３１を含む。
【０１６７】
なお、第１の実施形態の呼処理管理テーブル３００は、呼処理部（ＡＣＴ）１５１及び呼処理部（ＳＢＹ）１５３の両方の状態を管理するが、第２の実施形態の呼処理管理テーブル１３００は、呼処理部（ＡＣＴ）１１５１の状態のみを管理する。
【０１６８】
以下に、呼状態管理テーブル１３１０の構成の例について、図１５を用いて説明する。また、ＧＴＰ−Ｃセッション管理テーブル１３２１−１、ＧＴＰ−Ｃトランザクション管理テーブル１３２１−２、及びＧＴＰ−Ｃパス管理テーブル１３２１−３の構成の例について、図１６を用いて説明する。また、ＵＤＰ管理テーブル１３３１の構成の例について図１７を用いて説明する。なお、Ｄｉａｍｅｔｅｒセッション管理テーブル１３２２−１、Ｄｉａｍｅｔｅｒトランザクション管理テーブル１３２２−２、及びＤｉａｍｅｔｅｒピア管理テーブル１３２２−３の構成については説明を省略するが、これらは、各々、ＧＴＰ−Ｃセッション管理テーブル１３２１−１、ＧＴＰ−Ｃトランザクション管理テーブル１３２１−２、及びＧＴＰ−Ｃパス管理テーブル１３２１−３とほぼ同じ構成である。また、ＳＣＴＰ管理テーブル１３３２の構成については説明を省略するが、ＳＣＴＰ管理テーブル１３３２は、ＵＤＰ管理テーブル１３３１とほぼ同じ構成である。
【０１６９】
［３−２．呼処理管理テーブル１３００の構成］
図１５は、本発明の第２の実施形態の呼状態管理テーブル１３１０の構成を示す説明図である。
【０１７０】
呼状態管理テーブル１３１０は、呼識別子１３６１、ベアラ情報（ＧＴＰ−Ｕエンドポイント情報）１３６２及び呼処理プロトコル管理テーブルへのポインタ１３６３を含む。
【０１７１】
呼状態管理テーブル１３１０の呼識別子１３６１、ベアラ情報（ＧＴＰ−Ｕエンドポイント情報）１３６２及び呼処理プロトコル管理テーブルへのポインタ１３６３は、各々、図５に示した呼状態管理テーブル３１０の呼識別子３６１、ベアラ情報（ＧＴＰ−Ｕエンドポイント情報）３６２及び呼処理プロトコル管理テーブルへのポインタ３６３と同じである。ただし、ベアラ情報（ＧＴＰ−Ｕエンドポイント情報）１３６２は、パケット転送部（ＳＢＹ）のベアラ情報を含まない。
【０１７２】
図１６Ａは、本発明の第２の実施形態のＧＴＰ−Ｃセッション管理テーブル１３２１−１の構成を示す説明図である。
【０１７３】
ＧＴＰ−Ｃセッション管理テーブル１３２１−１は、ＧＴＰ−Ｃエンドポイント情報１３７１、呼状態管理テーブルへのポインタ１３７２、及びＧＴＰ−Ｃトランザクション管理テーブルへのポインタ１３７３を含む。ＧＴＰ−Ｃセッション管理テーブル１３２１−１のＧＴＰ−Ｃエンドポイント情報１３７１、呼状態管理テーブルへのポインタ１３７２、及びＧＴＰ−Ｃトランザクション管理テーブルへのポインタ１３７３は、図６Ａに示したＧＴＰ−Ｃセッション管理テーブル３２１−１のＧＴＰ−Ｃエンドポイント情報３７１、呼状態管理テーブルへのポインタ３７２、及びＧＴＰ−Ｃトランザクション管理テーブルへのポインタ３７３と同じである。ただし、ＧＴＰ−Ｃエンドポイント情報１３７１は、呼処理部（ＳＢＹ）１１５３のエンドポイント情報を含まない。
を含む。
【０１７４】
図１６Ｂは、本発明の第２の実施形態のＧＴＰ−Ｃトランザクション管理テーブル１３２１−２の構成を示す説明図である。
【０１７５】
ＧＴＰ−Ｃトランザクション管理テーブル１３２１−２は、トランザクションＩＤ１３８１、トランザクション状態１３８２、及びＧＴＰ−Ｃセッション管理テーブルへのポインタ１３８３を含む。ＧＴＰ−Ｃトランザクション管理テーブル１３２１−２のトランザクションＩＤ１３８１、トランザクション状態１３８２、及びＧＴＰ−Ｃセッション管理テーブルへのポインタ１３８３は、各々、図６Ｂに示したＧＴＰ−Ｃトランザクション管理テーブル３２１−２のトランザクションＩＤ３８１、トランザクション状態３８２、及びＧＴＰ−Ｃセッション管理テーブルへのポインタ３８３と同じである。
【０１７６】
ただし、ＧＴＰ−Ｃトランザクション管理テーブル１３２１−２のトランザクション状態１３８２には、図７に示した状態変数のうちの一部は設定されない。具体的には、第２の実施形態では、呼処理部（ＳＢＹ）１１５３が、呼処理部（ＡＣＴ）１１５１と呼処理部（ＳＢＹ）１１５３との各呼状態の同期を管理するので、図７に示した状態変数「ＡＣＴ＿ＲＳＰ＿ＳＥＮＴ」及び「ＳＢＹ＿ＲＳＰ＿ＳＥＮＴ」はトランザクション状態１３８２には設定されない。
【０１７７】
これは、第２の実施形態のＧＴＰ−Ｃトランザクション状態遷移では、図７に示したイベントＥ５０２の後、状態変数は「ＲＥＱ＿ＲＥＣＥＩＶＥＤ」から「ＲＥＰ＿ＳＥＮＴ」に遷移し、Ｅ５０４の後、状態変数は、「ＲＥＱ＿ＲＥＣＥＩＶＥＤ」から「ＳＹＮＣ＿ＳＴＡＲＴ」に遷移するためである。
【０１７８】
図１６Ｃは、本発明の第２の実施形態のＧＴＰ−Ｃパス管理テーブル１３２１−３の構成を示す説明図である。
【０１７９】
ＧＴＰ−Ｃパス管理テーブル１３２１−３は、ＧＴＰ−Ｃエンドポイント情報１４０１を含む。ＧＴＰ−Ｃエンドポイント情報１４０１は、アクセスゲートウェイ３３のＧＴＰ−Ｃエンドポイント情報（ＡＧＷ）１４０１Ａ及び呼処理部（ＡＣＴ）１１５１のＧＴＰ−Ｃエンドポイント情報（呼処理部（ＡＣＴ））１４０１Ｂを含む。ＧＴＰ−Ｃエンドポイント情報とは、例えば、ＩＰアドレス、ポート番号、最新のＧＴＰ−Ｃシーケンス番号などである。
【０１８０】
図１７は、本発明の第２の実施形態のＵＤＰ管理テーブル１３３１の構成を示す説明図である。
【０１８１】
ＵＤＰ管理テーブル１３３１は、ＵＤＰエンドポイント情報１４２１を含む。ＵＤＰエンドポイント情報１４２１は、アクセスゲートウェイ３３のＵＤＰエンドポイント情報１４２１Ａ、及び呼処理部（ＡＣＴ）１１５１のＵＤＰエンドポイント情報１４２１Ｂを含む。ＵＤＰエンドポイント情報とは、例えば、ＩＰアドレス、ポート番号などである。
【０１８２】
［４．コールフロー］
［４−１．端末５接続時の正常系コールフロー］
図１８は、本発明の第２の実施形態のサービス網ゲートウェイ２１を起動する場合、及びサービス網ゲートウェイ２１が端末５を接続する場合のコールフローを示す説明図である。
【０１８３】
サービス網ゲートウェイ２１が起動する場合、サービス網ゲートウェイ２１の装置内のパスが設定される（１６０１）。まず、サービス網ゲートウェイ２１は、ＧＴＰ−Ｃパケットを、ＳＷＢ１２０を経由して、ＰＢ＃２＿１００−２の呼処理部（ＳＢＹ）１１５３に転送する。そして、さらに、呼処理部（ＳＢＹ）１１５３に転送されたＧＴＰ−Ｃパケットを、ＳＷＢ１２０を経由して、ＰＢ＃１＿１００−１の呼処理部（ＡＣＴ）１１５１に転送する（１６０１−１）。
【０１８４】
また、サービス網ゲートウェイ２１は、ユーザトラフィックを、ＳＷＢ１２０を経由して、ＰＢ＃１＿１００−１のパケット転送部（ＡＣＴ）１１５２に転送する（１６０１−２）。
【０１８５】
次に、サービス網ゲートウェイ２１が端末５を接続する場合、サービス網ゲートウェイ２１は、図８に示したステップ６０１から６０３の処理を実行する。その後、アクセスゲートウェイ３３は、セッション確立要求をサービス網ゲートウェイ２１に送信する。次に、サービス網ゲートウェイ２１のＳＷＢ１２０は、セッション確立要求をＰＢ＃２＿１００−２の呼処理部（ＳＢＹ）１１５３に送信する（１６１１）。呼処理部（ＳＢＹ）１１５３は、セッション確立要求を受信すると、ＧＴＰ−Ｃパケット転送ルーチンＰ３＿１８００（図２１参照）を実行する（１６１２）。
【０１８６】
図２１は、本発明の第２の実施形態のＧＴＰ−Ｃパケット転送ルーチンＰ３＿１８００を示すフローチャートである。
【０１８７】
呼処理部（ＳＢＹ）１１５３は、受信したＧＴＰ−Ｃパケットの内容に基づいて、ＵＤＰ管理テーブル１３３１を更新する（１８０１）。次に、ＧＴＰ−Ｃパス管理テーブル１３２１−３を更新する（１８０２）。次に、ＧＴＰ−Ｃトランザクション管理テーブル１３２１−２を更新する（１８０３）。次に、ＧＴＰ−Ｃセッション管理テーブル１３２１−１を更新する（１８０４）。次に、呼状態管理テーブル１３１０を更新する（１８０５）。最後に、呼処理部（ＳＢＹ）１１５３は、ＧＴＰ−Ｃパケットを呼処理部（ＡＣＴ）１１５１に転送し（１８０６）、処理を終了する。
【０１８８】
呼処理部（ＳＢＹ）１１５３は、ステップ１８０１に対応する処理として、ＵＤＰ管理テーブル１３３１に新規エントリを追加し、追加された新規エントリのＵＤＰエンドポイント情報（ＡＧＷ）１４２１Ａに、アクセスゲートウェイ３３のＩＰアドレス及びポート番号を設定する。また、ＧＴＰ−Ｃパス管理テーブル１３２１−３に新規エントリを追加し、追加された新規エントリのＧＴＰ−Ｃエンドポイント情報（ＡＧＷ）１４０１Ａに、アクセスゲートウェイ３３のＩＰアドレス及びポート番号を設定する。
【０１８９】
なお、アクセスゲートウェイ３３とサービス網ゲートウェイ２１との間にＧＴＰ−Ｃパスが既に設定されている場合、ステップ１８０１は実行されない。
【０１９０】
次に、呼処理部（ＳＢＹ）１１５３は、ステップ１８０２に対応する処理として、ＧＴＰ−Ｃパス管理テーブル１３２１−３に追加された新規エントリのＧＴＰ−Ｃエンドポイント情報（ＡＧＷ）１４０１Ａに、最新のＧＴＰ−Ｃシーケンス番号を設定する。
【０１９１】
次に、呼処理部（ＳＢＹ）１１５３は、ステップ１８０３に対応する処理として、ＧＴＰ−Ｃトランザクション管理テーブル１３２１−２に新規エントリを追加し、追加された新規エントリのトランザクションＩＤ１３８１に、アクセスゲートウェイ３３が割り当てたＩＰアドレス、ＵＤＰポート番号、ＧＴＰ−Ｃシーケンス番号を設定する。また、追加された新規エントリのトランザクション状態１３８２に、トランザクション状態の状態変数（例えば、ＲＥＱ＿ＲＥＣＥＩＶＥＤ）を設定する。
【０１９２】
次に、呼処理部（ＳＢＹ）１１５３は、ステップ１８０４に対応する処理として、ＧＴＰ−Ｃセッション管理テーブル１３２１−１に新規エントリを追加し、追加された新規エントリのＧＴＰ−Ｃエンドポイント情報（ＡＧＷ）１３７１Ａに、アクセスゲートウェイ３３のＩＰアドレス及びＧＴＰ−ＣトンネルＩＤを設定する。
【０１９３】
次に、呼処理部（ＳＢＹ）１１５３は、ステップ１８０５に対応する処理として、呼状態管理テーブル１３１０に新規エントリを追加し、追加された新規エントリのサービス網ＩＤ１３６１Ａ、ユーザＩＤ１３６１Ｂ、ベアラＩＤ１３６２Ａ、ＧＴＰ−Ｕエンドポイント情報（ＡＧＷ）１３６２Ｂに、アクセスゲートウェイ３３から送信されたサービス網ＩＤ、ユーザＩＤ、ベアラＩＤ、ＧＴＰ−ＵトンネルＩＤ及びＩＰアドレスを設定する。
【０１９４】
ここで、図１８の説明に戻る。
【０１９５】
ステップ１６１２の後、ＰＢ＃２＿１００−２の呼処理部（ＳＢＹ）１１５３は、サービス網ゲートウェイ２１に設定された呼処理プロトコル（ＧＴＰ−Ｃ）のパスに従って、ＳＷＢ１２０を経由して、ＰＢ＃１＿１００−１の呼処理部（ＡＣＴ）１１５１に、セッション確立要求を送信する（１６１３）。ＰＢ＃１＿１００−１の呼処理部（ＡＣＴ）１１５１は、同様に、ＳＷＢ１２０を経由して、ＰＢ＃２＿１００−２の呼処理部（ＳＢＹ）１１５３に、セッション確立応答を送信する（１６１４）。
【０１９６】
そして、ＰＢ＃２＿１００−２の呼処理部（ＳＢＹ）１１５３は、セッション確立応答を受信すると、ＧＴＰ−Ｃパケット転送ルーチンＰ４＿１８２０（図２２参照）を実行する（１６１５）。
【０１９７】
図２２は、本発明の第２の実施形態のＧＴＰ−Ｃパケット転送ルーチンＰ４＿１８２０を示すフローチャートである。
【０１９８】
呼処理部（ＳＢＹ）１１５３は、受信したＧＴＰ−Ｃパケットの内容に基づいて、呼状態管理テーブル１３１０を更新する（１８２１）。次に、ＧＴＰ−Ｃセッション管理テーブル１３２１−１を更新する（１８２２）。次に、ＧＴＰ−Ｃトランザクション管理テーブル１３２１−２を更新する（１８２３）。次に、ＧＴＰ−Ｃパス管理テーブル１３２１−３を更新する（１８２４）。次に、ＵＤＰ管理テーブル１３３１を更新する（１８２５）。最後に、呼処理部（ＳＢＹ）１１５３は、宛先の他ノード（ＡＧＷ）へＧＴＰ−Ｃパケットを転送し（１８２６）、処理を終了する。
【０１９９】
ここで、呼処理部（ＳＢＹ）１１５３は、ステップ１８２１に対応する処理として、ステップ１８０５において追加された、呼状態管理テーブル１３１０の新規エントリのＧＴＰ−Ｕエンドポイント情報１３６２Ｃに、呼処理部（ＡＣＴ）１１５１から送信されたパケット転送部（ＡＣＴ）１１５２のＩＰアドレス及びＧＴＰ−ＵトンネルＩＤを設定する。
【０２００】
また、呼処理部（ＳＢＹ）１１５３は、ステップ１８２２に対応する処理として、ステップ１８０４において追加された、ＧＴＰ−Ｃセッション管理テーブル１３２１−１の新規エントリのＧＴＰ−Ｃエンドポイント情報（呼処理部（ＡＣＴ））１３７１Ｂに呼処理部（ＡＣＴ）１１５１から送信されたＩＰアドレス及びＧＴＰ−ＣトンネルＩＤを設定する。
【０２０１】
また、呼処理部（ＳＢＹ）１１５３は、ステップ１８２３に対応する処理として、ステップ１８０３において追加された、ＧＴＰ−Ｃトランザクション管理テーブル１３２１−２の新規エントリのトランザクション状態１３８２を更新する。
【０２０２】
また、呼処理部（ＳＢＹ）１１５３は、ステップ１８２４に対応する処理として、ステップ１８０１において追加された、ＧＴＰ−Ｃパス管理テーブル１３２１の新規エントリのＧＴＰ−Ｃエンドポイント情報（呼処理部（ＡＣＴ））１４０１Ｂに、呼処理部（ＡＣＴ）１１５１から送信されたＩＰアドレス、ポート番号、及び最新のＧＴＰ-Ｃシーケンス番号を設定する。
【０２０３】
また、呼処理部（ＳＢＹ）１１５３は、ステップ１８２５に対応する処理として、ステップ１８０１において追加された、ＵＤＰ管理テーブル１３３１の新規エントリのＵＤＰエンドポイント情報（呼処理部（ＡＣＴ））１４２１Ｂに、呼処理部（ＡＣＴ）１１５１のＩＰアドレス及びポート番号を設定する。
【０２０４】
呼処理部（ＳＢＹ）１１５３は、ステップ１８２６に対応する処理として、ＳＷ１２０を経由して、他ノード（ＡＧＷ）にＧＴＰ−Ｃパケットを送信する。
【０２０５】
図１８の説明に戻る。
【０２０６】
ステップ１６１５の後、ＰＢ＃２＿１００−２の呼処理部（ＳＢＹ）１１５３は、セッション確立応答（図２２のステップ１８２６のＧＴＰ−Ｃパケット）をＳＷＢ１２０に送信する。ＳＷＢ１２０は、セッション確立応答をアクセスゲートウェイ３３に送信する（１６１６）。その後、呼処理部（ＳＢＹ）１１５３は、図８に示したステップ６１２から６１７の処理を実行する。以上の処理によって、サービス網ゲートウェイ２１は、端末５を接続する。
【０２０７】
［４−２．系切替え時のコールフロー１］
図１９は、本発明の第２の実施形態のサービス網ゲートウェイの現用系の呼処理部に障害が発生した場合のコールフローを示す説明図である。
【０２０８】
系切替えの前に、サービス網ゲートウェイ２１の装置内のパスが設定される（１６５１）。設定されるＧＴＰ−Ｃパケット及びユーザトラフィックのパスは、それぞれ、図１８のステップ１６０１−１及び１６０１−２に示したパスと同じである。
【０２０９】
また、ＰＢ＃１＿１００−１の呼処理部（ＡＣＴ）１１５１とＰＢ＃２＿１００−２の呼処理部（ＳＢＹ）１１５３とは、常時互いの稼働状況を監視する（１６５２）。
【０２１０】
ここで、呼処理部（ＡＣＴ）１１５１に障害が発生すると、呼処理部（ＳＢＹ）１１５３は、呼処理部（ＡＣＴ）１１５１に発生した障害を検出する（１６５３）。この場合、呼処理部（ＳＢＹ）１１５３は、まず、呼処理を一旦停止し（１６５４）、サービス網ゲートウェイ２１の装置内のパスを再設定する（１６５５）。
【０２１１】
具体的には、呼処理部（ＳＢＹ）１１５３は、ＧＴＰ−Ｃパケットを転送するために、ＳＷＢ１２０とＰＢ＃２＿１００−２の呼処理部（ＳＢＹ）１１５３との間にパスを設定する（１６５５−１）。
【０２１２】
また、呼処理部（ＳＢＹ）１１５３は、ユーザトラフィックを転送するために、休止しているＰＢ＃２＿１００−２のパケット転送部（ＳＢＹ）１１５４を起動し、ＳＷＢ１２０と起動したパケット転送部（ＳＢＹ）１１５４との間にパスを設定する（１６５５−２）。
【０２１３】
そして、呼処理部（ＳＢＹ）１１５３は、呼処理を再開する（１６５６）。以上の処理によって、呼処理部（ＡＣＴ）１１５１に障害が発生した場合であっても、呼処理部（ＳＢＹ）１１５３は、呼処理部（ＡＣＴ）１１５１の処理を引き継ぐことができる。
【０２１４】
［４−３．系切替え時のコールフロー２］
図２０は、本発明の第２の実施形態のサービス網ゲートウェイの予備系の呼処理部に障害が発生した場合のコールフローを示す説明図である。
【０２１５】
系切替えの前に、サービス網ゲートウェイ２１の装置内のパスが設定される（１６７１）。設定されるＧＴＰ−Ｃパケット及びユーザトラフィックのパスは、それぞれ、図１８のステップ１６０１−１及び１６０１−２に示したパスと同じである。
【０２１６】
また、ＰＢ＃１＿１００−１の呼処理部（ＡＣＴ）１１５１とＰＢ＃２＿１００−２の呼処理部（ＳＢＹ）１１５３とは、常時互いの稼働状況を監視する（１６７２）。
【０２１７】
ここで、呼処理部（ＳＢＹ）１１５３に障害が発生すると、呼処理部（ＡＣＴ）１１５１は、呼処理部（ＳＢＹ）１１５３に発生した障害を検出する（１６７３）。この場合、呼処理部（ＡＣＴ）１１５１は、まず、呼処理を一旦停止し（１６７４）、サービス網ゲートウェイ２１の装置内のパスを再設定する。
【０２１８】
具体的には、呼処理部（ＡＣＴ）１１５１は、ＧＴＰ−Ｃパケットを転送するために、ＳＷＢ１２０とＰＢ＃１＿１００−１の呼処理部（ＡＣＴ）１１５１との間にパスを設定する（１６７５−１）。
【０２１９】
また、呼処理部（ＡＣＴ）１１５１は、ユーザトラフィックを転送するために、ＳＷＢ１２０とＰＢ＃１＿１００−１のパケット転送部（ＡＣＴ）１１５２との間にパスを設定する（１６７５−２）。そして、呼処理部（ＡＣＴ）１１５１は、呼処理を再開し、処理を継続する。
【０２２０】
以上説明したように、第２の実施形態では、呼処理部（ＳＢＹ）が呼処理パケットを中継し、処理部（ＡＣＴ）に呼処理パケットを転送するので、サービス網ゲートウェイ２１は、呼処理部（ＳＢＹ）が呼処理パケットから抽出した呼状態に基づいて、呼処理部（ＳＢＹ）と呼処理部（ＡＣＴ）との間の各呼状態の同期を維持することができる。
【符号の説明】
【０２２１】
１ サービス網、
２ ユーザホーム網
３ 無線アクセス網
４ 無線アクセス網
５ 端末
１１ アプリケーションサーバ
２１ サービス網ゲートウェイ（ＳＮＧＷ）
２２ ポリシーサーバ
２３ 認証サーバ
３１Ａ、Ｂ 基地局
３２ 移動管理サーバ
３３ アクセスゲートウェイ（ＡＧＷ）
４１Ａ、Ｂ 基地局
４２ 移動管理サーバ
４３ アクセスゲートウェイ（ＡＧＷ）
３１０ 呼状態管理テーブル
３２１−１ ＧＴＰ−Ｃセッション管理テーブル
３２１−１ ＧＴＰ−Ｃトランザクション管理テーブル
５００ ＧＴＰ−Ｃトランザクション状態遷移図
８００ ＧＴＰ−Ｃパケット転送ルーチンＰ１
８２０ 呼識別子抽出ルーチンＰ２
１３１０ 呼状態管理テーブル
１３２１−１ ＧＴＰ−Ｃセッション管理テーブル
１３２１−２ ＧＴＰ−Ｃトランザクション管理テーブル
１３２１−３ ＧＴＰ−Ｃパス管理テーブル
１３３１ ＵＤＰ管理テーブル
１８００ 自宛ＧＴＰ−Ｃパケット転送ルーチンＰ３
１８２０ 自発ＧＴＰ−Ｃパケット転送ルーチンＰ４
【特許請求の範囲】
【請求項１】
端末を接続する第１のノードから前記端末に通信サービスを提供する第２のノードへ、前記端末が送受信するユーザトラフィックを転送する移動体通信ゲートウェイ装置であって、
前記第１のノードによって、所定の呼処理プロトコルを用いて送信された呼処理パケットに基づいて、前記端末の接続情報を示す呼状態を作成する少なくとも二つ以上の呼処理部と、前記第１のノードと前記呼処理部との間で前記呼処理パケットを転送するスイッチ部と、を備え、
前記スイッチ部は、
前記第１のノードから送信された前記呼処理パケットを受信すると、前記受信した呼処理パケットを複製し、その一方を、第１の呼処理パケットとし、他方を第２の呼処理パケットとし、
前記第１の呼処理パケットを、現用系の前記呼処理部に送信し、
前記第２の呼処理パケットを、予備系の前記呼処理部に送信し、
前記現用系の呼処理部から送信された前記第１の呼処理パケットを受信すると、前記受信した第１の呼処理パケットを前記第１のノードに送信し、
前記予備系の呼処理部から送信された前記第２の呼処理パケットを受信すると、前記受信した第２の呼処理パケットを前記第１のノードに送信しないで廃棄し、
前記第１及び第２の呼処理パケットの送受信の状態を記憶し、
前記記憶された第１及び第２の呼処理パケットの送受信の状態に基づいて、前記現用系の呼処理部によって作成される呼状態と前記予備系の呼処理部によって作成される呼状態とが一致するか否かを検出することを特徴とする移動体通信ゲートウェイ装置。
【請求項２】
前記スイッチ部は、
前記第１及び第２の呼処理パケットから抽出された呼識別子を記憶し、
前記記憶された第１及び第２の呼処理パケットの送受信の状態に基づいて、所定の時間が経過しても前記送受信の状態が一致していない呼処理パケットを特定し、
前記記憶された呼識別子に基づいて、前記特定された送受信の状態が一致していない呼処理パケットの呼識別子を特定し、
前記特定された呼識別子を前記予備系の呼処理部に送信し、
前記予備系の呼処理部は、
前記送信された呼識別子に対応する呼状態を前記現用系の呼処理部から取得し、
前記取得した呼状態に基づいて、前記予備系の呼処理部の呼状態を前記現用系の呼処理部の呼状態に一致させることを特徴とする請求項１に記載の移動体通信ゲートウェイ装置。
【請求項３】
前記スイッチ部は、
前記第１及び第２の呼処理パケットから抽出された呼識別子を記憶し、
前記現用系の呼処理部が故障した場合、前記第１及び第２の呼処理パケットの送受信の状態に基づいて、前記送受信の状態が一致していない呼処理パケットを特定し、
前記記憶された呼識別子に基づいて、前記特定された送受信の状態が一致していない呼処理パケットの前記呼識別子を特定し、
前記特定された呼識別子を前記予備系の呼処理部に送信し、
前記予備系の呼処理部は、
前記予備系の呼処理部によって作成された呼状態から、前記送信された呼識別子に対応する呼状態を削除することによって、前記現用系の呼処理部の呼状態を前記現用系の呼処理部の呼状態に一致させ、
前記現用系の呼処理部が実行していた呼処理を実行することを特徴とする請求項１に記載の移動体通信ゲートウェイ装置。
【請求項４】
端末を接続する第１のノードから前記端末に通信サービスを提供する第２のノードへ、前記端末が送受信するユーザトラフィックを転送する移動体通信ゲートウェイ装置であって、
前記第１のノードによって、所定の呼処理プロトコルを用いて送信された呼処理パケットに基づいて、前記端末の接続情報を示す呼状態を作成する少なくとも二つ以上の呼処理部と、前記第１のノードと前記各呼処理部との間で前記呼処理パケットを転送するスイッチ部と、前記各処理部と前記スイッチ部との間で前記呼処理パケットを転送するためのパスを設定するパス管理部と、を備え、
前記パス管理部は、
前記第１のノードから現用系の前記呼処理部に送信された前記呼処理パケットを、前記スイッチ部を経由して、予備系の前記呼処理部に転送し、
前記予備系の呼処理部に転送された前記呼処理パケットを、前記スイッチ部を経由して、前記現用系の呼処理部に転送し、
さらに、前記現用系の呼処理部から前記第１のノードに送信された前記呼処理パケットを、前記スイッチ部を経由して、前記予備系の呼処理部に転送し、
前記予備系の呼処理部に転送された前記呼処理パケットを、前記スイッチ部に転送するための第１パスを設定し、
前記予備系の呼処理部は、
前記現用系の呼処理部と前記第１のノードとの間で、前記設定された第１パスによって転送される前記呼処理パケットの送受信の状態を記憶し、
前記記憶された呼処理パケットの送受信の状態に基づいて、前記現用系の呼処理部によって作成される呼状態と前記予備系の呼処理部によって作成される呼状態とが一致するか否かを検出することを特徴とする移動体通信ゲートウェイ装置。
【請求項５】
前記予備系の呼処理部は、
前記転送される前記呼処理パケットから抽出された呼識別子を記憶し、
前記現用系の呼処理部が故障した場合、前記記憶された呼処理パケットの送受信の状態に基づいて、前記送受信の状態が所定の状態とならない呼処理パケットを特定し、
前記記憶された呼識別子に基づいて、前記特定された送受信の状態が所定の状態にならない呼処理パケットの呼識別子を特定し、
前記予備系の呼処理部によって作成される呼状態を、前記特定された呼識別子に対応する前記現用系の呼処理部によって作成される呼状態に一致させ、
前記パス管理部は、前記第１のノードから送信された前記呼処理パケットを、前記スイッチ部を経由して、直接前記予備系の呼処理部に転送し、さらに、前記予備系の呼処理部から前記第１のノードに送信された前記呼処理パケットを、直接前記スイッチ部に転送するための第２パスを設定し、
前記予備系の呼処理部は、前記設定された第２パスによって、前記現用系の呼処理部が実行していた呼処理を実行することを特徴とする請求項４に記載の移動体通信ゲートウェイ装置。
【請求項６】
前記パス管理部は、前記予備系の呼処理部が故障した場合、前記第１のノードから前記現用系の呼処理部に送信された前記呼処理パケットを、前記スイッチ部を経由して、前記現用系の呼処理部に直接転送し、さらに、前記現用系の呼処理部から前記第１のノードに送信された前記呼処理パケットを、前記スイッチ部に直接転送するための第３パスを設定することを特徴とする請求項４に記載の移動体通信ゲートウェイ装置。
【請求項７】
端末を接続する第１のノードから前記端末に通信サービスを提供する第２のノードへ、前記端末が送受信するユーザトラフィックを転送する移動体通信ゲートウェイ装置において実行される制御方法であって、
前記移動体通信ゲートウェイ装置は、前記第１のノードによって、所定の呼処理プロトコルを用いて送信された呼処理パケットに基づいて、前記端末の接続情報を示す呼状態を作成する少なくとも二つ以上の呼処理部と、前記第１のノードと前記呼処理部との間で前記呼処理パケットを転送するスイッチ部と、を備え、
前記制御方法は、
前記スイッチ部が、
前記第１のノードから送信された前記呼処理パケットを受信すると、前記受信した呼処理パケットを複製し、その一方を、第１の呼処理パケットとし、他方を第２の呼処理パケットとし、
前記第１の呼処理パケットを、現用系の前記呼処理部に送信し、
前記第２の呼処理パケットを、予備系の前記呼処理部に送信し、
前記現用系の呼処理部から送信された前記第１の呼処理パケットを受信すると、前記受信した第１の呼処理パケットを前記第１のノードに送信し、
前記予備系の呼処理部から送信された前記第２の呼処理パケットを受信すると、前記受信した第２の呼処理パケットを前記第１のノードに送信しないで廃棄し、
前記第１及び第２の呼処理パケットの送受信の状態を記憶し、
前記記憶された第１及び第２の呼処理パケットの送受信の状態に基づいて、前記現用系の呼処理部によって作成される呼状態と前記予備系の呼処理部によって作成される呼状態とが一致するか否かを検出することを特徴とする制御方法。
【請求項８】
前記スイッチ部が、
前記第１及び第２の呼処理パケットから抽出された呼識別子を記憶し、
前記記憶された第１及び第２の呼処理パケットの送受信の状態に基づいて、所定の時間が経過しても前記送受信の状態が一致していない呼処理パケットを特定し、
前記記憶された呼識別子に基づいて、前記特定された送受信の状態が一致していない呼処理パケットの呼識別子を特定し、
前記特定された呼識別子を前記予備系の呼処理部に送信し、
前記予備系の呼処理部が、
前記送信された呼識別子に対応する呼状態を前記現用系の呼処理部から取得し、
前記取得した呼状態に基づいて、前記予備系の呼処理部の呼状態を前記現用系の呼処理部の呼状態に一致させることを特徴とする請求項７に記載の制御方法。
【請求項９】
前記スイッチ部が、
前記第１及び第２の呼処理パケットから抽出された呼識別子を記憶し、
前記現用系の呼処理部が故障した場合、前記第１及び第２の呼処理パケットの送受信の状態に基づいて、前記送受信の状態が一致していない呼処理パケットを特定し、
前記記憶された呼識別子に基づいて、前記特定された送受信の状態が一致していない呼処理パケットの前記呼識別子を特定し、
前記特定された呼識別子を前記予備系の呼処理部に送信し、
前記予備系の呼処理部が、
前記予備系の呼処理部によって作成された呼状態から、前記送信された呼識別子に対応する呼状態を削除することによって、前記現用系の呼処理部の呼状態を前記現用系の呼処理部の呼状態に一致させ、
前記現用系の呼処理部が実行していた呼処理を実行することを特徴とする請求項７に記載の制御方法。
【請求項１０】
端末を接続する第１のノードから前記端末に通信サービスを提供する第２のノードへ、前記端末が送受信するユーザトラフィックを転送する移動体通信ゲートウェイ装置において実行される制御方法であって、
前記移動体通信ゲートウェイ装置は、前記第１のノードによって、所定の呼処理プロトコルを用いて送信された呼処理パケットに基づいて、前記端末の接続情報を示す呼状態を作成する少なくとも二つ以上の呼処理部と、前記第１のノードと前記各呼処理部との間で前記呼処理パケットを転送するスイッチ部と、前記各呼処理部と前記スイッチ部との間で前記呼処理パケットを転送するためのパスを設定するパス管理部と、を備え、
前記制御方法は、
前記パス管理部が、
前記第１のノードから現用系の前記呼処理部に送信された前記呼処理パケットを、前記スイッチ部を経由して、予備系の前記呼処理部に転送し、
前記予備系の呼処理部に転送された前記呼処理パケットを、前記スイッチ部を経由して、前記現用系の呼処理部に転送し、
さらに、前記現用系の呼処理部から前記第１のノードに送信された前記呼処理パケットを、前記スイッチ部を経由して、前記予備系の呼処理部に転送し、
前記予備系の呼処理部に転送された前記呼処理パケットを、前記スイッチ部に転送するための第１パスを設定し、
前記予備系の呼処理部が、
前記現用系の呼処理部と前記第１のノードとの間で、前記設定された第１パスによって転送される前記呼処理パケットの送受信の状態を記憶し、
前記記憶された呼処理パケットの送受信の状態に基づいて、前記現用系の呼処理部によって作成される呼状態と前記予備系の呼処理部によって作成される呼状態とが一致するか否かを検出することを特徴とする制御方法。
【請求項１１】
前記予備系の呼処理部が、
前記転送される前記呼処理パケットから抽出された呼識別子を記憶し、
前記現用系の呼処理部が故障した場合、前記記憶された呼処理パケットの送受信の状態に基づいて、前記送受信の状態が所定の状態とならない呼処理パケットを特定し、
前記記憶された呼識別子に基づいて、前記特定された送受信の状態が所定の状態にならない呼処理パケットの呼識別子を特定し、
前記予備系の呼処理部によって作成される呼状態を、前記特定された呼識別子に対応する前記現用系の呼処理部によって作成される呼状態に一致させ、
前記パス管理部が、前記第１のノードから送信された前記呼処理パケットを、前記スイッチ部を経由して、直接前記予備系の呼処理部に転送し、さらに、前記予備系の呼処理部から前記第１のノードに送信された前記呼処理パケットを、直接前記スイッチ部に転送するための第２パスを設定し、
前記予備系の呼処理部が、前記設定された第２パスによって、前記現用系の呼処理部が実行していた呼処理を実行することを特徴とする請求項１０に記載の制御方法。
【請求項１２】
前記パス管理部が、前記予備系の呼処理部が故障した場合、前記第１のノードから前記現用系の呼処理部に送信された前記呼処理パケットを、前記スイッチ部を経由して、前記現用系の呼処理部に直接転送し、さらに、前記現用系の呼処理部から前記第１のノードに送信された前記呼処理パケットを、前記スイッチ部に直接転送するための第３パスを設定することを特徴とする請求項１０に記載の制御方法。
【請求項１】
端末を接続する第１のノードから前記端末に通信サービスを提供する第２のノードへ、前記端末が送受信するユーザトラフィックを転送する移動体通信ゲートウェイ装置であって、
前記第１のノードによって、所定の呼処理プロトコルを用いて送信された呼処理パケットに基づいて、前記端末の接続情報を示す呼状態を作成する少なくとも二つ以上の呼処理部と、前記第１のノードと前記呼処理部との間で前記呼処理パケットを転送するスイッチ部と、を備え、
前記スイッチ部は、
前記第１のノードから送信された前記呼処理パケットを受信すると、前記受信した呼処理パケットを複製し、その一方を、第１の呼処理パケットとし、他方を第２の呼処理パケットとし、
前記第１の呼処理パケットを、現用系の前記呼処理部に送信し、
前記第２の呼処理パケットを、予備系の前記呼処理部に送信し、
前記現用系の呼処理部から送信された前記第１の呼処理パケットを受信すると、前記受信した第１の呼処理パケットを前記第１のノードに送信し、
前記予備系の呼処理部から送信された前記第２の呼処理パケットを受信すると、前記受信した第２の呼処理パケットを前記第１のノードに送信しないで廃棄し、
前記第１及び第２の呼処理パケットの送受信の状態を記憶し、
前記記憶された第１及び第２の呼処理パケットの送受信の状態に基づいて、前記現用系の呼処理部によって作成される呼状態と前記予備系の呼処理部によって作成される呼状態とが一致するか否かを検出することを特徴とする移動体通信ゲートウェイ装置。
【請求項２】
前記スイッチ部は、
前記第１及び第２の呼処理パケットから抽出された呼識別子を記憶し、
前記記憶された第１及び第２の呼処理パケットの送受信の状態に基づいて、所定の時間が経過しても前記送受信の状態が一致していない呼処理パケットを特定し、
前記記憶された呼識別子に基づいて、前記特定された送受信の状態が一致していない呼処理パケットの呼識別子を特定し、
前記特定された呼識別子を前記予備系の呼処理部に送信し、
前記予備系の呼処理部は、
前記送信された呼識別子に対応する呼状態を前記現用系の呼処理部から取得し、
前記取得した呼状態に基づいて、前記予備系の呼処理部の呼状態を前記現用系の呼処理部の呼状態に一致させることを特徴とする請求項１に記載の移動体通信ゲートウェイ装置。
【請求項３】
前記スイッチ部は、
前記第１及び第２の呼処理パケットから抽出された呼識別子を記憶し、
前記現用系の呼処理部が故障した場合、前記第１及び第２の呼処理パケットの送受信の状態に基づいて、前記送受信の状態が一致していない呼処理パケットを特定し、
前記記憶された呼識別子に基づいて、前記特定された送受信の状態が一致していない呼処理パケットの前記呼識別子を特定し、
前記特定された呼識別子を前記予備系の呼処理部に送信し、
前記予備系の呼処理部は、
前記予備系の呼処理部によって作成された呼状態から、前記送信された呼識別子に対応する呼状態を削除することによって、前記現用系の呼処理部の呼状態を前記現用系の呼処理部の呼状態に一致させ、
前記現用系の呼処理部が実行していた呼処理を実行することを特徴とする請求項１に記載の移動体通信ゲートウェイ装置。
【請求項４】
端末を接続する第１のノードから前記端末に通信サービスを提供する第２のノードへ、前記端末が送受信するユーザトラフィックを転送する移動体通信ゲートウェイ装置であって、
前記第１のノードによって、所定の呼処理プロトコルを用いて送信された呼処理パケットに基づいて、前記端末の接続情報を示す呼状態を作成する少なくとも二つ以上の呼処理部と、前記第１のノードと前記各呼処理部との間で前記呼処理パケットを転送するスイッチ部と、前記各処理部と前記スイッチ部との間で前記呼処理パケットを転送するためのパスを設定するパス管理部と、を備え、
前記パス管理部は、
前記第１のノードから現用系の前記呼処理部に送信された前記呼処理パケットを、前記スイッチ部を経由して、予備系の前記呼処理部に転送し、
前記予備系の呼処理部に転送された前記呼処理パケットを、前記スイッチ部を経由して、前記現用系の呼処理部に転送し、
さらに、前記現用系の呼処理部から前記第１のノードに送信された前記呼処理パケットを、前記スイッチ部を経由して、前記予備系の呼処理部に転送し、
前記予備系の呼処理部に転送された前記呼処理パケットを、前記スイッチ部に転送するための第１パスを設定し、
前記予備系の呼処理部は、
前記現用系の呼処理部と前記第１のノードとの間で、前記設定された第１パスによって転送される前記呼処理パケットの送受信の状態を記憶し、
前記記憶された呼処理パケットの送受信の状態に基づいて、前記現用系の呼処理部によって作成される呼状態と前記予備系の呼処理部によって作成される呼状態とが一致するか否かを検出することを特徴とする移動体通信ゲートウェイ装置。
【請求項５】
前記予備系の呼処理部は、
前記転送される前記呼処理パケットから抽出された呼識別子を記憶し、
前記現用系の呼処理部が故障した場合、前記記憶された呼処理パケットの送受信の状態に基づいて、前記送受信の状態が所定の状態とならない呼処理パケットを特定し、
前記記憶された呼識別子に基づいて、前記特定された送受信の状態が所定の状態にならない呼処理パケットの呼識別子を特定し、
前記予備系の呼処理部によって作成される呼状態を、前記特定された呼識別子に対応する前記現用系の呼処理部によって作成される呼状態に一致させ、
前記パス管理部は、前記第１のノードから送信された前記呼処理パケットを、前記スイッチ部を経由して、直接前記予備系の呼処理部に転送し、さらに、前記予備系の呼処理部から前記第１のノードに送信された前記呼処理パケットを、直接前記スイッチ部に転送するための第２パスを設定し、
前記予備系の呼処理部は、前記設定された第２パスによって、前記現用系の呼処理部が実行していた呼処理を実行することを特徴とする請求項４に記載の移動体通信ゲートウェイ装置。
【請求項６】
前記パス管理部は、前記予備系の呼処理部が故障した場合、前記第１のノードから前記現用系の呼処理部に送信された前記呼処理パケットを、前記スイッチ部を経由して、前記現用系の呼処理部に直接転送し、さらに、前記現用系の呼処理部から前記第１のノードに送信された前記呼処理パケットを、前記スイッチ部に直接転送するための第３パスを設定することを特徴とする請求項４に記載の移動体通信ゲートウェイ装置。
【請求項７】
端末を接続する第１のノードから前記端末に通信サービスを提供する第２のノードへ、前記端末が送受信するユーザトラフィックを転送する移動体通信ゲートウェイ装置において実行される制御方法であって、
前記移動体通信ゲートウェイ装置は、前記第１のノードによって、所定の呼処理プロトコルを用いて送信された呼処理パケットに基づいて、前記端末の接続情報を示す呼状態を作成する少なくとも二つ以上の呼処理部と、前記第１のノードと前記呼処理部との間で前記呼処理パケットを転送するスイッチ部と、を備え、
前記制御方法は、
前記スイッチ部が、
前記第１のノードから送信された前記呼処理パケットを受信すると、前記受信した呼処理パケットを複製し、その一方を、第１の呼処理パケットとし、他方を第２の呼処理パケットとし、
前記第１の呼処理パケットを、現用系の前記呼処理部に送信し、
前記第２の呼処理パケットを、予備系の前記呼処理部に送信し、
前記現用系の呼処理部から送信された前記第１の呼処理パケットを受信すると、前記受信した第１の呼処理パケットを前記第１のノードに送信し、
前記予備系の呼処理部から送信された前記第２の呼処理パケットを受信すると、前記受信した第２の呼処理パケットを前記第１のノードに送信しないで廃棄し、
前記第１及び第２の呼処理パケットの送受信の状態を記憶し、
前記記憶された第１及び第２の呼処理パケットの送受信の状態に基づいて、前記現用系の呼処理部によって作成される呼状態と前記予備系の呼処理部によって作成される呼状態とが一致するか否かを検出することを特徴とする制御方法。
【請求項８】
前記スイッチ部が、
前記第１及び第２の呼処理パケットから抽出された呼識別子を記憶し、
前記記憶された第１及び第２の呼処理パケットの送受信の状態に基づいて、所定の時間が経過しても前記送受信の状態が一致していない呼処理パケットを特定し、
前記記憶された呼識別子に基づいて、前記特定された送受信の状態が一致していない呼処理パケットの呼識別子を特定し、
前記特定された呼識別子を前記予備系の呼処理部に送信し、
前記予備系の呼処理部が、
前記送信された呼識別子に対応する呼状態を前記現用系の呼処理部から取得し、
前記取得した呼状態に基づいて、前記予備系の呼処理部の呼状態を前記現用系の呼処理部の呼状態に一致させることを特徴とする請求項７に記載の制御方法。
【請求項９】
前記スイッチ部が、
前記第１及び第２の呼処理パケットから抽出された呼識別子を記憶し、
前記現用系の呼処理部が故障した場合、前記第１及び第２の呼処理パケットの送受信の状態に基づいて、前記送受信の状態が一致していない呼処理パケットを特定し、
前記記憶された呼識別子に基づいて、前記特定された送受信の状態が一致していない呼処理パケットの前記呼識別子を特定し、
前記特定された呼識別子を前記予備系の呼処理部に送信し、
前記予備系の呼処理部が、
前記予備系の呼処理部によって作成された呼状態から、前記送信された呼識別子に対応する呼状態を削除することによって、前記現用系の呼処理部の呼状態を前記現用系の呼処理部の呼状態に一致させ、
前記現用系の呼処理部が実行していた呼処理を実行することを特徴とする請求項７に記載の制御方法。
【請求項１０】
端末を接続する第１のノードから前記端末に通信サービスを提供する第２のノードへ、前記端末が送受信するユーザトラフィックを転送する移動体通信ゲートウェイ装置において実行される制御方法であって、
前記移動体通信ゲートウェイ装置は、前記第１のノードによって、所定の呼処理プロトコルを用いて送信された呼処理パケットに基づいて、前記端末の接続情報を示す呼状態を作成する少なくとも二つ以上の呼処理部と、前記第１のノードと前記各呼処理部との間で前記呼処理パケットを転送するスイッチ部と、前記各呼処理部と前記スイッチ部との間で前記呼処理パケットを転送するためのパスを設定するパス管理部と、を備え、
前記制御方法は、
前記パス管理部が、
前記第１のノードから現用系の前記呼処理部に送信された前記呼処理パケットを、前記スイッチ部を経由して、予備系の前記呼処理部に転送し、
前記予備系の呼処理部に転送された前記呼処理パケットを、前記スイッチ部を経由して、前記現用系の呼処理部に転送し、
さらに、前記現用系の呼処理部から前記第１のノードに送信された前記呼処理パケットを、前記スイッチ部を経由して、前記予備系の呼処理部に転送し、
前記予備系の呼処理部に転送された前記呼処理パケットを、前記スイッチ部に転送するための第１パスを設定し、
前記予備系の呼処理部が、
前記現用系の呼処理部と前記第１のノードとの間で、前記設定された第１パスによって転送される前記呼処理パケットの送受信の状態を記憶し、
前記記憶された呼処理パケットの送受信の状態に基づいて、前記現用系の呼処理部によって作成される呼状態と前記予備系の呼処理部によって作成される呼状態とが一致するか否かを検出することを特徴とする制御方法。
【請求項１１】
前記予備系の呼処理部が、
前記転送される前記呼処理パケットから抽出された呼識別子を記憶し、
前記現用系の呼処理部が故障した場合、前記記憶された呼処理パケットの送受信の状態に基づいて、前記送受信の状態が所定の状態とならない呼処理パケットを特定し、
前記記憶された呼識別子に基づいて、前記特定された送受信の状態が所定の状態にならない呼処理パケットの呼識別子を特定し、
前記予備系の呼処理部によって作成される呼状態を、前記特定された呼識別子に対応する前記現用系の呼処理部によって作成される呼状態に一致させ、
前記パス管理部が、前記第１のノードから送信された前記呼処理パケットを、前記スイッチ部を経由して、直接前記予備系の呼処理部に転送し、さらに、前記予備系の呼処理部から前記第１のノードに送信された前記呼処理パケットを、直接前記スイッチ部に転送するための第２パスを設定し、
前記予備系の呼処理部が、前記設定された第２パスによって、前記現用系の呼処理部が実行していた呼処理を実行することを特徴とする請求項１０に記載の制御方法。
【請求項１２】
前記パス管理部が、前記予備系の呼処理部が故障した場合、前記第１のノードから前記現用系の呼処理部に送信された前記呼処理パケットを、前記スイッチ部を経由して、前記現用系の呼処理部に直接転送し、さらに、前記現用系の呼処理部から前記第１のノードに送信された前記呼処理パケットを、前記スイッチ部に直接転送するための第３パスを設定することを特徴とする請求項１０に記載の制御方法。
【図１Ａ】
【図１Ｂ】
【図２】
【図３】
【図４】
【図５】
【図６Ａ】
【図６Ｂ】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６Ａ】
【図１６Ｂ】
【図１６Ｃ】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図１Ｂ】
【図２】
【図３】
【図４】
【図５】
【図６Ａ】
【図６Ｂ】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６Ａ】
【図１６Ｂ】
【図１６Ｃ】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【公開番号】特開２０１１−４０９３１（Ｐ２０１１−４０９３１Ａ）
【公開日】平成２３年２月２４日（２０１１．２．２４）
【国際特許分類】
【出願番号】特願２００９−１８５６１４（Ｐ２００９−１８５６１４）
【出願日】平成２１年８月１０日（２００９．８．１０）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
【公開日】平成２３年２月２４日（２０１１．２．２４）
【国際特許分類】
【出願日】平成２１年８月１０日（２００９．８．１０）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
[ Back to top ]