以下、図面を用いて本発明の実施形態について説明する。なお、以下では、主に3GPPのLTEに用いられる移動体通信ゲートウェイ(サービス網ゲートウェイ)について説明するが、本発明は、LTEに用いられる移動体通信ゲートウェイに限定されない。本発明は、LTEと同様の、他のアクセス網に用いられる移動体通信ゲートウェイにも適用することができる。
[実施形態1]
以下、本発明の第1の実施形態について図面を参照して説明する。
第1の実施形態では、サービス網ゲートウェイは、現用系と予備系との呼処理のトランザクション状態を管理する呼処理同期状態管理部を備える。呼処理同期状態管理部は、呼処理のトランザクション状態に基づいて、現用系と予備系との各呼状態の不一致を検出し、不一致が検出された各呼状態を再同期する。
[1.ネットワークの構成]
図2は、本発明の第1の実施形態のネットワークの構成を示す説明図である。
本発明の第1の実施形態のネットワーク(移動体通信網)は、サービス網1、ユーザホーム網2、無線アクセス網3及び無線アクセス網4を備える。
無線アクセス網3は、端末5を収容するためのネットワークであり、基地局31A、31B、移動管理サーバ32及びアクセスゲートウェイ33を備え、例えば、無線インタフェースを介してデータ通信をする端末5に接続する。
基地局31A、31Bは、基地局31A、31Bと接続された端末5との間で、無線信号と有線信号とを相互に変換する。なお、図2では、例として、基地局を二つ図示したが、基地局は所要の数が備えられる。
アクセスゲートウェイ33は、基地局31A、31Bから受信したユーザトラフィックをユーザホーム網2に転送する。
また、移動管理サーバ32は、端末5の接続状況を管理し、また、基地局31A、31Bとアクセスゲートウェイ33との間のパスを制御する。
無線アクセス網4は、無線アクセス網3と同じであり、基地局41A、41B、移動管理サーバ42及びアクセスゲートウェイ(AGW:Access Gateway)43を備え、無線インタフェースを介して、データ通信をする端末を接続する。基地局41A、41B、移動管理サーバ42及びアクセスゲートウェイ43は、各々、基地局31A、31B、移動管理サーバ32及びアクセスゲートウェイ33と同じである。なお、図2では、例として、二つの無線アクセス網を図示したが、三つ以上の無線アクセス網が備えられてもよい。
ユーザホーム網2は、加入者情報を管理し、端末5をサービス網1に接続するためのネットワークであり、サービス網ゲートウェイ(SNGW:Service Network Gateway)21、ポリシーサーバ22及び認証サーバ23を備える。
サービス網ゲートウェイ21は、アクセスゲートウェイ33、43から受信したユーザトラフィックを適切なサービス網1に転送する。また、ポリシーサーバ22は、サービス網ゲートウェイ21にユーザトラフィックの課金の情報及びQoS(Quality of Service)を通知する。また、認証サーバ23は、ユーザ(端末5)の加入者情報を管理する。
サービス網1には、端末5にサービスを提供するためのネットワークであり、端末5にサービスを提供するアプリケーションサーバ11を備える。
なお、LTEでは、基地局31A、31B、41A、41Bは、eNB (evolved Node B)である。また、アクセスゲートウェイ33、43は、S−GW(Serving Gateway)である。また、移動管理サーバ32、42は、MME(Mobility Management Entity)である。また、サービス網ゲートウェイ21は、P−GW(Packet Data Network Gateway)である。また、ポリシーサーバ22は、PCRF(Policy and Charging Rules Function)である。また、認証サーバ23は、HSS(Home Subscriber Server)である。
以下に、サービス網ゲートウェイ21の構成及び処理について説明する。なお、LTEでは、サービス網ゲートウェイ21とアクセスゲートウェイ33、43との間の呼処理プロトコルにGTP−Cを使用する。また、サービス網ゲートウェイ21とポリシーサーバ22との間の呼処理プロトコルにDiameterを使用する。なお、本実施形態では、これらの呼処理プロトコルを使用する場合について説明するが、本発明はこれらの呼処理プロトコルに限定されず、他の呼処理プロトコルを使用してもよい。
[2.サービス網ゲートウェイ21の構成]
図3は、本発明の第1の実施形態のサービス網ゲートウェイ21のハードウェアの構成を示すブロック図である。
サービス網ゲートウェイ21は、PB(Payload Blade)#1_100からPB#n_100−n、及びSWB(Switch Blade)120を備える。PB#1_100からPB#n_100−nは、例えば、ブレードサーバであり、呼処理及びユーザトラフィック転送の機能を実現する。PB#1_100からPB#n_100−nは、それぞれ、同じである。
PB#1_100は、FROM101、CPU102、メモリ103、及びIF104、105を備え、これらはバス106を介して互いに接続される。FROM101は、サービス網ゲートウェイ21の機能を実現するためのプログラム、具体的には、例えば、呼処理部(ACT)151又は呼処理部(SBY)153(図1A参照)が実行する処理のためのプログラムを格納する。CPU102は、サービス網ゲートウェイ21が起動した時に、FROM101に格納されたプログラムをメモリ103に展開し、展開されたプログラムを順次読み出し、読み出されたプログラムを実行する。
IF104、105は、Ethernet回線を介して、SWB120に接続される。なお、例えば、IF104は、データ通信用に使用され、IF105は、装置の制御用に使用されてもよい。
SWB120は、例えば、ブレードサーバであり、Ethernetのスイッチの機能を実現する。SWB120は、IF123−1〜m、IF122−1〜2n、スイッチ部121、FROM124、CPU125、及びメモリ126を備える。IF123−1〜mは、外部装置に接続される。IF122−1〜2nは、PB#1_100〜PB#n_100−nに接続される。スイッチ部121は、各IFを介して、パケットを中継する。
また、FROM124、CPU125、及びメモリ126は、スイッチ部121が所定のルールに基づき抽出したパケットを処理する。具体的には、FROM124は、呼処理同期状態管理部155(図1A参照)が実行する処理のためのプログラムを格納する。CPU1125は、FROM1124に格納されたプログラムをメモリ1126に展開し、展開されたプログラムを順次読み出し、読み出されたプログラムを実行する。
[3.サービス網ゲートウェイ21の冗長化]
図1Aは、本発明の第1の実施形態のサービス網ゲートウェイ21の構成を示すブロック図である。
PB#1_100−1は、現用系であり、呼処理部(ACT)151及びパケット転送部(ACT)152を備える。PB#2_100−2は、予備系であり、呼処理部(SBY)153及びパケット転送部(SBY)154(休止中)を備える。
呼処理部(ACT)151と呼処理部(SBY)153とは、並列多重処理方式によって冗長化される。つまり、サービス網ゲートウェイ21は、現用系の呼処理部(ACT)151及び予備系の呼処理部(SBY)153を、それぞれ、PB#1_100−1及びPB#2_100−2において独立に動作させる。そして、SWB120は、並列多重処理を実現するため、他ノード(AGW33、43等)から送信された呼処理パケットを受信し、受信した呼処理パケットを少なくとも一つ複製し、これらの呼処理パケットをそれぞれ、呼処理部(ACT)151及び呼処理部(SBY)153に転送する。
また、呼処理部(ACT)151及び呼処理部(SBY)153の双方は、サービス網ゲートウェイ21から他ノード(AGW33、43等)に送信する呼処理パケットをSWB120に送信する。ただし、SWB120は、呼処理部(ACT)151から送信された呼処理パケットのみを他ノードに転送し、呼処理部(SBY)153から送信された呼処理パケットを転送せずに廃棄する。
一方、パケット転送部(ACT)152、及びパケット転送部(SBY)154は、1対1待機冗長方式によって、冗長化される。つまり、現用系のパケット転送部(ACT)152は、PB#1_100−1で動作し、予備系のパケット転送部(SBY)154は、PB#2_100−2で動作する。他ノードから転送されたユーザトラフィックは、SWB120を経由して、パケット転送部(ACT)152に転送される。
SWB120は、呼処理同期状態管理部155を備える。呼処理同期状態管理部155は、呼処理部(ACT)151と呼処理部(SBY)153との各呼状態の同期を管理する。SWB120のCPU125は、メモリ126に格納されたプログラムによって、呼処理同期状態管理部155の処理を実行する。
また、呼処理同期状態管理部155は、呼処理部(ACT)151と呼処理部(SBY)153との呼処理のトランザクション状態を管理することによって、呼状態の同期を管理する。具体的には、呼処理同期状態管理部155は、一定時間が経過しても呼処理のトランザクション状態が所定の状態にならない場合、同期していない呼の識別子を呼処理部(SBY)153に通知する。これによって、呼処理同期状態管理部155は、呼処理部(ACT)151及び呼処理部(SBY)153のいずれか一方のみで、呼処理パケットが消失し、各呼処理部の呼状態が一致しなくなった場合であっても、各呼状態の不一致を検出し、不一致が検出された各呼状態を同期させることができる。呼処理同期状態管理部155の処理の詳細については、図4から図13を用いて後述する。
[4.呼処理管理テーブル300]
[4−1.呼処理管理テーブル300の構成]
呼処理同期状態管理部155は、呼処理管理テーブル300を備える。なお、呼処理管理テーブル300は、SWB120のメモリ126に格納される。以下に、呼処理管理テーブル300の構成について、図4から6を用いて説明する。
図4は、本発明の第1の実施形態の呼処理管理テーブル300の構成を示す説明図である。
呼処理管理テーブル300は、呼状態管理テーブル310、呼処理プロトコル管理テーブル320及びトランスポートプロトコル管理テーブル330を含む。
呼状態管理テーブル310は、呼処理プロトコルに依存しないサービス網毎、ユーザ毎の接続状況を管理するためのテーブルである。呼状態管理テーブル310の具体的な構成の例については、図5を用いて後述する。
呼処理プロトコル管理テーブル320は、本実施形態において呼処理プロトコルとして用いられるGTP−C、Diameterなどの呼処理プロトコル状態を管理するためのテーブルである。呼処理プロトコル管理テーブル320は、呼処理プロトコル毎に定義され、例えば、GTP−C管理テーブル321、Diameter管理テーブル322などを含む。
GTP−C管理テーブル321は、GTP−Cプロトコルの呼処理プロトコル状態を管理するためのテーブルであり、GTP−Cセッション管理テーブル321−1、及びGTP−Cトランザクション管理テーブル321−2を含む。なお、GTP−C管理テーブル321の具体的な構成の例については、図6Aから図6Bを用いて後述する。
また、Diameter管理テーブル322は、Diameterプロトコルの呼処理プロトコル状態を管理するためのテーブルであり、Diameterセッション管理テーブル322−1、及びDiameterトランザクション管理テーブル322−2を含む。
なお、前述した呼状態管理テーブル310及び呼処理プロトコル管理テーブルは、呼処理部(ACT)151及び呼処理部(SBY)153が備える呼状態及び呼処理プロトコルを管理するためのテーブル(図示省略)の一部である。
トランスポートプロトコル管理テーブル330は、SCTPなどのトランスポートプロトコルの状態を管理するためのテーブルであり、トランスポートプロトコル毎に定義され、例えば、SCTP管理テーブル332を含む。SCTP管理テーブル332は、具体的には、送信元IPアドレス、送信元ポート番号、宛先IPアドレス、宛先ポート番号、コネクション状態、ストリーム情報、シーケンス番号などを含む。なお、GTP−Cでは、トランスポートプロトコルとしてUDPが使用されるが、UDPはコネクションレスであるので、本実施形態はUDPの状態を管理しなくてもよい。
[4−2.呼状態管理テーブル310の構成]
図5は、本発明の第1の実施形態の呼状態管理テーブル310の構成を示す説明図である。
呼状態管理テーブル310は、呼識別子361、ベアラ情報(GTP−Uエンドポイント情報)362及び呼処理プロトコル管理テーブルへのポインタ363を含む。
呼識別子361は、例えば、端末5が接続するサービス網を識別するためのサービス網ID361Aと、端末5を識別するためのユーザID361Bと、の組み合わせである。
ベアラ情報362は、各呼識別子に対して一つ以上設定されるベアラ情報(GTP−Uエンドポイント情報)である。ここで、GTP−Uエンドポイント情報とは、ユーザトラフィックを転送するために設定される仮想トンネル(GTP−Uトンネル)の端点のIPアドレスと、GTP−Uトンネルを識別するためのGTP−UトンネルIDとの組み合わせである。
具体的には、ベアラ情報362は、各ベアラについて、ベアラを識別するためのベアラID362A、アクセスゲートウェイ33のGTP−Uエンドポイント情報362B、呼処理部(ACT)151が割り当てるパケット転送部(ACT)152のGTP−Uエンドポイント情報362C、及び呼処理部(SBY)153が割り当てるパケット転送部(SBY)154のGTP−Uエンドポイント情報362Dを含む。
呼処理プロトコル管理テーブルへのポインタ363は、GTP−Cセッション管理テーブル321−1及びDiameterセッション管理テーブル322−1のエントリを呼び出すためのポインタである。
呼処理同期状態管理部155は、呼状態管理テーブル310の呼処理プロトコル管理テーブルへのポインタ363を参照することによって、呼処理プロトコルのトランザクション状態(各呼処理部の呼状態の不一致)がどの呼に影響するのかを容易に特定することができる。
また、呼処理同期状態管理部155は、呼処理部(ACT)151から呼処理部(SBY)153に系切替えが実行された場合、ベアラ情報362を参照し、ユーザトラフィックの転送先をパケット転送部(ACT)152からパケット転送部(SBY)154へ書き換える。これによって、サービス網ゲートウェイ21は、ユーザトラフィックの転送処理を継続することができる。
[4−3.GTP−C管理テーブル321の構成]
以下に、GTP−C管理テーブル320について、図6A及び図6Bを用いて説明する。
[4−3−1.GTP−Cセッション管理テーブル321−1の構成]
図6Aは、本発明の第1の実施形態のGTP−Cセッション管理テーブル321−1の構成を示す説明図である。
GTP−Cセッション管理テーブル321−1は、GTP−Cエンドポイント情報371、呼状態管理テーブルへのポインタ372、及びGTP−Cトランザクション管理テーブルへのポインタ373を含む。
ここで、GTP−Cエンドポイント情報とは、呼処理パケット(例えば、LETにおいては、GTP−Cパケット)を転送するために設定される仮想トンネル(GTP−Cトンネル)の端点のIPアドレスと、GTP−Cトンネルを識別するためのGTP−CトンネルIDとの組み合わせである。
具体的には、GTP−Cエンドポイント情報371は、アクセスゲートウェイ33のGTP−Cエンドポイント情報371A、呼処理部(ACT)151のGTP−Cエンドポイント情報371B、呼処理部(SBY)153のGTP−Cエンドポイント情報371Cを含む。
呼状態管理テーブルへのポインタ372は、呼状態管理テーブル310のエントリを呼び出すためのポインタである。GTP−Cトランザクション管理テーブルへのポインタ373は、GTP−Cトランザクション管理テーブル321−1のエントリを呼び出すためのポインタである。
呼処理同期状態管理部155は、GTP−Cセッション管理テーブル321−1の呼状態管理テーブルへのポインタ372及びGTP−Cトランザクション管理テーブルへのポインタ373を参照することによって、呼処理プロトコルのトランザクション状態(各呼処理部の呼状態の不一致)がどの呼に影響するのかを容易に特定することができる。
また、呼処理同期状態管理部155は、呼処理部(ACT)151から呼処理部(SBY)153に系切替えが実行された場合、GTP−Cエンドポイント情報371を参照し、呼処理パケット(GTP−Cパケット)の転送先を呼処理部(ACT)151から呼処理部(SBY)153へ書き換える。つまり、GTP−Cパケットの転送先であるGTP−Cエンドポイント情報を呼処理部(ACT)のGTP−CトンネルIDから呼処理部(SBY)のGTP−CトンネルIDに書き換える。これによって、サービス網ゲートウェイ21は、GTP−Cパケットの転送処理を継続することができる。
[4−3−2.GTP−Cトランザクション管理テーブル321−2の構成]
図6Bは、本発明の第1の実施形態のGTP−Cトランザクション管理テーブル321−2の構成の例を示す説明図である。
GTP−Cトランザクション管理テーブル321−2は、トランザクションID381、トランザクション状態382、及びGTP−Cセッション管理テーブルへのポインタ383を含む。トランザクションID381は、アクセスゲートウェイ33によって割り当てられるGTP−CトランザクションIDであり、例えば、IPアドレス、UDPポート番号、GTP−Cシーケンス番号である。
トランザクション状態382は、呼処理部(ACT)151と呼処理部(SBY)153とのGTP−Cトランザクション状態(リクエスト/レスポンスの送受信状態)を示す状態変数である。なお、トランザクション状態382の遷移の例については、図7を用いて後述する。
GTP−Cセッション管理テーブルへのポインタ383は、GTP−Cセッション管理テーブル321−1のエントリを呼び出すためのポインタである。
呼処理同期状態管理部155は、GTP−Cセッション管理テーブルへのポインタ383を参照することによって、呼処理プロトコルのトランザクション状態の不一致(各呼処理部の呼状態の不一致)がどの呼に影響するのかを容易に特定することができる。また、呼処理同期状態管理部155は、トランザクション状態382を参照することによって、呼処理部(ACT)と呼処理部(SBY)との各呼状態の不一致を判定することができる。
[5.GTP−Cトランザクション状態の遷移]
図7は、本発明の第1の実施形態のGTP−Cトランザクション状態遷移500を示す説明図である。
はじめに、トランザクション状態の初期状態は、「NULL」である。次に、アクセスゲートウェイ33から、GTP−Cリクエスト受信イベント(E501)が通知されると、トランザクション状態は、「REQ_RECEIVED」に遷移する。また、「REQ_RECEIVED」に遷移すると、タイマAが開始される。
次に、「REQ_RECEIVED」の後の状態遷移(E502〜E504)について説明する。まず、呼処理部(ACT)151から、GTP−Cレスポンス受信イベント(E502)が通知されると、トランザクション状態は、「ACT_RSP_SENT」に遷移し、さらに、タイマBが開始される。また、呼処理部(SBY)153から、GTP−Cレスポンス受信イベント(E503)が通知されると、トランザクション状態は、「SBY_RSP_SENT」に遷移し、さらに、タイマCが開始される。なお、呼処理部(ACT)151及び呼処理部(SBY)153のいずれのレスポンスも受信されないで、タイマAの満了イベント(E504)が通知されると、トランザクション状態は、再び、「NULL」にリセットされる。
次に、「ACT_RSP_SENT」の後の状態遷移(E505〜E506)について説明する。まず、呼処理部(SBY)153から、GTP−Cレスポンス受信イベント(E505)が通知されると、トランザクション状態は、同期確立状態を示す「RSP_SENT」に遷移し、再び、「NULL」にリセットされる。また、呼処理部(SBY)153からのレスポンスが受信されないで、タイマB満了イベント(E506)が通知されると、呼処理同期状態管理部155は、呼処理部(SBY)153に同期確立要求を送信する。同期確立要求が送信されると、トランザクション状態は、同期確立開始を示す「SYNC_START」に遷移し、タイマDが開始される。
次に、「SBY_RSP_SENT」からの状態遷移(E507〜E508)について説明する。まず、呼処理部(ACT)から、GTP−Cレスポンス受信イベント(E507)が通知されると、トランザクション状態は、同期確立状態を示す「RSP_SENT」に遷移し、再び、「NULL」にリセットされる。また、呼処理部(ACT)151からのレスポンスが受信されずに、タイマC満了イベント(E508)が通知されると、呼処理同期状態管理部155は、呼処理部(SBY)153に同期確立要求を送信する(E508)。同期確立要求が送信されると、トランザクション状態は、同期確立開始を示す「SYNC_START」に遷移し、タイマDが開始される。
最後に、「SYNC_START」の後の状態遷移(E509〜E510)について説明する。まず、呼処理部(SBY)153から、同期完了通知受信イベント(E509)が通知されると、同期再確立に成功したと判定され、トランザクション状態は、再び、「NULL」にリセットされる。また、呼処理部(SBY)153からの同期完了通知が受信されないで、タイマD満了イベント(E510)が通知されると、同期再確立に失敗したと判定され、トランザクション状態は、「SYSTEM_ERROR」に遷移する。
なお、トランザクション状態の状態変数(例えば、「NULL」、「REQ_RECEIVED」など)は、図6Bに示したGTP−Cトランザクション管理テーブル321−2のトランザクション状態382に格納される。
[6.コールフロー]
以下に、図8から図13を用いて、第1の実施形態におけるコールフローについて説明する。
[6−1.端末5接続時の正常系コールフロー]
図8は、本発明の第1の実施形態のサービス網ゲートウェイ21が端末5を接続する場合の正常系コールフローを示す説明図である。
図8に示したコールフローでは、呼処理部(ACT)151と呼処理部(SBY)153との各呼状態の不一致は発生せず、正常に呼処理が実行される場合が示される。
はじめに、端末5は、基地局31B、移動管理サーバ32に接続要求を送信する(601)。接続要求には、ユーザIDが含まれる。次に、移動管理サーバ32は、端末5から送信されたユーザIDを認証サーバ23に転送する。認証サーバ23は、ユーザ認証を実行する(602)。
次に、移動管理サーバ32は、アクセスゲートウェイ33にセッション確立要求を送信する(603)。セッション確立要求には、サービス網ID、ユーザID及びベアラIDが含まれる。ここで、移動管理サーバ32は、認証サーバ23から取得された、端末5の加入者情報に基づいて、接続先のサービス網IDを指定する。また、移動管理サーバ32は、端末5のユーザトラフィックを転送するために設定された仮想トンネルを識別するためのベアラIDを設定する。
なお、ベアラIDは、アクセスゲートウェイ33とサービス網ゲートウェイ21との間に設立される仮想トンネル(GTP−Uトンネル)の端点の情報に対応付けられる。また、ベアラIDは、さらに、基地局31Bとアクセスゲートウェイ33との間に設定される仮想トンネルの端点の情報に対応付けられてもよい。
次に、アクセスゲートウェイ33は、指定されたサービス網IDに対応するサービス網ゲートウェイ21にセッション確立要求を送信する(604)。セッション確立要求には、サービス網ID、ユーザID、アクセスゲートウェイ33のGTP−CトンネルID、ベアラID、及びアクセスゲートウェイ33のGTP−UトンネルIDが含まれる。
なお、このGTP−CトンネルIDは、端末5の呼処理のために、アクセスゲートウェイ33とサービス網ゲートウェイ21との間に設定された仮想トンネル(GTP−Cトンネル)において、アクセスゲートウェイ33側のGTP−Cエンドポイントを識別するための識別子である。
また、このGTP−UトンネルIDは、端末5のユーザトラフィックの転送のために、アクセスゲートウェイ33とサービス網ゲートウェイ21の間に設定された仮想トンネル(GTP−Uトンネル)において、アクセスゲートウェイ33側のGTP−Uエンドポイントを識別するための識別子である。GTP−UトンネルIDは、前述したベアラIDに対応付けられる。
次に、セッション確立要求がサービス網ゲートウェイ21に送信されると、まず、SWB120内の呼処理同期状態管理部155は、セッション確立要求を受信する。そして、呼処理同期状態管理部155は、GTP−Cパケット転送ルーチンP1_800(図12参照)を実行する(605)。
図12は、本発明の第1の実施形態のGTP−Cパケット転送ルーチンP1_800を示すフローチャートである。
はじめに、呼処理同期状態管理部155は、端末5を接続するための呼処理パケット(GTP−Cパケット)の内容に基づいて、GTP−Cトランザクション管理テーブル321−2を更新する(801)。次に、GTP−Cセッション管理テーブル321−1を更新する(802)。次に、呼状態管理テーブル310を更新する(803)。
そして、呼処理同期状態管理部155は、受信したGTP−Cパケットの送信元を判定する(804)。ステップ804において、送信元が他ノード(AGW)であると判定された場合、呼処理同期状態管理部155は、受信したGTP−Cパケットを、呼処理部(ACT)151及び呼処理部(SBY)153の双方に転送する(805)。
また、ステップ804において、送信元が呼処理部(ACT)151であると判定された場合、呼処理同期状態管理部155は、受信したGTP−Cパケットを、他ノード(AGW)に転送する(806)。また、ステップ804において、送信元が呼処理部(SBY)153であると判定された場合、呼処理同期状態管理部155は、受信したGTP−Cパケットを転送せず、破棄する。
なお、呼処理同期状態管理部155は、ステップ801に対応する処理として、GTP−Cトランザクション管理テーブル321−2に新規エントリを追加し、追加された新規エントリのトランザクションID381に、アクセスゲートウェイ33によって割り当てられた値を設定する。また、図7に示した状態遷移に従って、追加された新規エントリのトランザクション状態382に状態変数「REQ_RECEIVED」を設定する。また、追加された新規エントリのGTP−Cセッション管理テーブルへのポインタ383に、GTP−Cセッション管理テーブル321−1へのポインタを設定する。
また、呼処理同期状態管理部155は、ステップ802に対応する処理として、GTP−Cセッション管理テーブル321−1に新規エントリを追加し、追加された新規エントリのGTP−Cエンドポイント情報(AGW)371Aに、アクセスゲートウェイ33側のGTP−Cトンネルの端点の情報(GTP−CトンネルID)を設定する。また、追加された新規エントリのGTP−Cトランザクション管理テーブルへのポインタ373に、GTP−Cトランザクション管理テーブル321−2へのポインタを設定する。
また、呼処理同期状態管理部155は、ステップ803に対応する処理として、呼状態管理テーブル310に新規エントリを追加し、追加された新規エントリのサービス網ID361A、ユーザID361B、ベアラID362A、GTP−Uエンドポイント情報(AGW)362Bのそれぞれに、アクセスゲートウェイ33から送信されたサービス網ID、ユーザID、ベアラID、GTP−UトンネルID(及びIPアドレス)を設定する。また、追加された新規エントリの呼処理プロトコル管理テーブルへのポインタ(GTP)363Aに、GTP−Cセッション管理テーブル321−1へのポインタを設定する。
また、呼処理同期状態管理部155は、ステップ805に対応する処理として、セッション確立要求を、呼処理部(ACT)151及び呼処理部(SBY)153の双方に転送する(図8の606−1、606−2)。
図8のステップ605以降の説明に戻る。GTP−Cパケット転送ルーチンP1_800が実行される(605)と、セッション確立要求がPB#1_100−1とPB#2_100−2の双方に転送される(606−1、606−2)。そして、PB#1_100−1内の呼処理部(ACT)151は、セッション確立要求に対応する呼処理を実行し、セッション確立応答(ACT)をSWB120内の呼処理同期状態管理部155に送信する(607)。セッション確立応答(ACT)には、呼処理部(ACT)151のGTP−CトンネルID、ベアラID、及び呼処理部(ACT)151のGTP−UトンネルIDが含まれる。
GTP−CトンネルIDは、端末5の呼処理のために、アクセスゲートウェイ33とサービス網ゲートウェイ21との間に設定された仮想トンネル(GTP−C)において、サービス網ゲートウェイ21側のGTP−Cエンドポイントを識別するための識別子である。
また、GTP−UトンネルIDは、端末5のユーザトラフィック転送のために確立された、アクセスゲートウェイ33とサービス網ゲートウェイ21の間に設定されるGTP−U仮想トンネルにおいて、サービス網ゲートウェイ21側のGTP−Uエンドポイントを識別するためのIDである。
次に、SWB120内の呼処理同期状態管理部155は、セッション確立応答(ACT)を受信する(607)と、再び、GTP−Cパケット転送ルーチンP1_800を実行する(608)。なお、この場合、呼処理同期状態管理部155は、図12のステップ801に対応する処理として、ステップ605において、GTP−Cトランザクション管理テーブル321−2に新規に追加されたエントリのトランザクション状態382を「ACT_RSP_SENT」に更新する。
また、呼処理同期状態管理部155は、図12のステップ802に対応する処理として、ステップ605において、GTP−Cセッション管理テーブル321−1に新規に追加されたエントリのGTP−Cエンドポイント情報(呼処理部(ACT))371Bに、呼処理部(ACT)151から送信されたGTP−CトンネルIDを設定する。
また、呼処理同期状態管理部155は、図12のステップ803に対応する処理として、ステップ605において、呼状態管理テーブル310に新規に追加されたエントリのGTP−Uエンドポイント情報362Cに、呼処理部(ACT)151から送信されたGTP−UトンネルIDを設定する。
また、呼処理同期状態管理部155は、ステップ806に対応する処理として、呼処理部(ACT)151から送信されたセッション確立応答(ACT)をアクセスゲートウェイ33に転送する(609)。
次に、PB#2_100−2内の呼処理部(SBY)153は、セッション確立要求(606−2)に対応する呼処理を実行し、セッション確立応答(SBY)をSWB120内の呼処理同期状態管理部155に送信する(610)。
このセッション確立応答(SBY)には、呼処理部(SBY)153のGTP−CトンネルID、ベアラID、及び呼処理部(SBY)153のGTP−UトンネルIDが含まれる。なお、GTP−CトンネルID及びGTP−UトンネルIDは、呼処理部(SBY)153が割り当てる識別子であるので、ステップ607において、呼処理部(ACT)151が割り当てる識別子とは異なる場合がある。
次に、SWB120内の呼処理同期状態管理部155は、セッション確立応答(SBY)を受信する(610)と、再び、図12に示したGTP−Cパケット転送ルーチンP1_800を実行する(611)。
なお、この場合、呼処理同期状態管理部155は、図12のステップ801に対応する処理として、ステップ605において、GTP−Cトランザクション管理テーブル321−2に新規に追加されたエントリのトランザクション状態382を「RSP_SENT」に更新する。なお、その後、トランザクション状態382が「NULL」に更新されると、GTP−Cトランザクション管理テーブル(321−2)から、ステップ605において追加されたエントリは削除される。
また、呼処理同期状態管理部155は、図12のステップ802に対応する処理として、ステップ605において、GTP−Cセッション管理テーブル321−1に新規に追加されたエントリの、GTP−Cエンドポイント情報(呼処理部(SBY))371Cに、呼処理部(SBY)から送信されたGTP−CトンネルIDを設定する。
また、呼処理同期状態管理部155は、図12のステップ803に対応する処理として、ステップ605において、呼状態管理テーブル310に新規に追加されたエントリのGTP−Uエンドポイント情報(パケット転送部(SBY))362Dに、呼処理部(SBY)153から送信されたGTP−UトンネルIDを設定する。
なお、図12のステップ804において、呼処理同期状態管理部155が受信したGTP−Cパケットの送信元は呼処理部(SBY)153であると判定されるので、呼処理同期状態管理部155は、セッション確立応答(SBY)をアクセスゲートウェイ33に転送せず、廃棄する。
次に、アクセスゲートウェイ33は、セッション確立応答(ACT)を受信する(609)と、受信したセッション確立応答を移動管理サーバ32に送信する(612)。移動管理サーバ32は、端末5に接続許可を送信する(613)。端末5は、移動管理サーバ32に接続確認を送信する(614)。移動管理サーバ32は、端末5から送信された接続確認を受信する(614)と、アクセスゲートウェイ33にベアラ更新要求を送信する(615)。最後に、アクセスゲートウェイ33は、移動管理サーバ32にベアラ更新応答を送信する(616)。
以上説明した処理によって、端末5の接続処理が完了し、端末5と、基地局31Bと、アクセスゲートウェイ33と、サービス網ゲートウェイ21と、アプリケーションサーバ11との間のユーザトラフィックの経路(パス)が確立する(617)。
[6−2.端末5接続時の準正常系コールフロー]
図9は、本発明の第1の実施形態のサービス網ゲートウェイ21が端末5を接続する場合の準正常系コールフローを示す説明図である。
図9に示したコールフローでは、呼処理部(SBY)153側のみで呼処理パケット(GTP−Cパケット)が消失したため、呼処理部(ACT)151と呼処理部(SBY)153との各呼状態の不一致が発生するが、呼処理同期状態管理部155が各呼状態の不一致を検出し、各呼状態を再同期する場合が示される。
はじめに、図8のステップ601から605に対応する処理が実行される。つまり、SWB120内の呼処理同期状態管理部155は、セッション確立要求を受信すると、GTP−Cパケット転送ルーチンP1_800を実行し、PB#1_100−1内の呼処理部(ACT)151及びPB#2_100−2内の呼処理部(SBY)153の双方に、セッション確立要求を送信する(631−1、631−2)。
PB#1_100−1内の呼処理部(ACT)151は、セッション確立要求に対応する呼処理を実行し、セッション確立応答(ACT)をSWB120に送信する(632)。SWB120内の呼処理同期状態管理部155は、セッション確立応答(ACT)を受信すると、図12に示したGTP−Cパケット転送ルーチンP1_800を実行する(633)。
そして、呼処理同期状態管理部155は、セッション確立応答(ACT)をアクセスゲートウェイ33に送信する(634)。一方、PB#2_100−2に送信されたセッション確立要求は消失した(631−2)ので、PB#2_100−2内の呼処理部(SBY)153からセッション確立応答が送信されない。このため、呼処理同期状態管理部155が管理するトランザクションの管理タイマ(図7のタイマB)が満了する(635)。タイマBが満了すると、呼処理同期状態管理部155は、各呼状態に不一致が発生したと判定し、図13に示す呼識別子抽出ルーチンP2_820を実行する(636)。
図13は、本発明の第1の実施形態の呼識別子抽出ルーチンP2_820を示すフローチャートである。
はじめに、呼処理同期状態管理部155は、図6Bに示したGTP−Cトランザクション管理テーブル321−2のGTP−Cセッション管理テーブルへのポインタ383を参照して、各呼状態の不一致が発生しているGTP−Cセッション管理テーブル321−1のエントリを特定する(821)。次に、特定されたGTP−Cセッション管理テーブル321−1のエントリの呼状態管理テーブルへのポインタ372を参照し、各呼状態の不一致が発生している呼状態管理テーブル310のエントリを特定する(822)。特定されたエントリの呼識別子361を特定する(823)。以上の処理によって、呼識別子抽出ルーチンP2_820が終了する。
図9のステップ636以降の説明に戻る。SWB120内の呼処理同期状態管理部155は、ステップ636の後、PB#2_100−2内の呼処理部(SBY)153に、同期要求を送信する(637)。なお、ステップ636は、図7に示した呼処理部(SBY)153への同期要求の送信(E506)に対応する。この同期要求には、ステップ636で特定された呼識別子361(すなわち、サービス網ID361AとユーザID361Bとの組)が含まれる。
次に、呼処理部(SBY)153は、PB#1_100−1内の呼処理部(ACT)151に、呼状態要求を送信し、特定された呼識別子に対応する、呼処理部(ACT)151の呼状態を問い合わせる(638)。呼処理部(ACT)151は、呼処理部(SBY)153に、呼状態応答を送信する(639)。
呼処理部(SBY)153は、呼処理部(SBY)153が備える内部テーブル(図示省略)に、特定された呼識別子(サービス網ID及びユーザID)に対応するエントリを設定し、さらに、設定されたエントリに呼処理部(ACT)151から送信された呼状態の情報(例えば、GTP−CトンネルID及びGTP−UトンネルID)を設定する。その後、呼処理部(SBY)153は、呼処理同期状態管理部155に、セッション確立応答(SBY)を含む同期完了通知を送信する(640)。なお、ステップ640は、図7に示した呼処理部(SBY)153からの同期完了の通知(E509)に対応する。
以上の処理によって、呼処理同期状態管理部155は、各呼状態の不一致を検出し、各呼状態を再同期させることができる。
[6−3.端末5切断時のコールフロー]
図10は、本発明の第1の実施形態のサービス網ゲートウェイ21が端末5を切断する場合のコールフローを示す説明図である。
図10に示したコールフローでは、正常に呼が切断され、呼処理管理テーブル300から端末5の情報がすべて削除される場合が示される。
はじめに、端末5は、基地局31B及び移動管理サーバ32に切断要求を送信する(651)。次に、移動管理サーバ32は、アクセスゲートウェイ33にセッション切断要求を送信する(652)。次に、アクセスゲートウェイ33は、サービス網ゲートウェイ21にセッション切断要求を送信する(653)。
SWB120内の呼処理同期状態管理部155は、セッション切断要求653を受信すると、図12に示したGTP−Cパケット転送ルーチンP1_800を実行する(654)。GTP−Cパケット転送ルーチンP1_800が実行されると、セッション切断要求が、PB#1_100−1及びPB#2_100−2の双方に送信される(655−1、655−2)。
PB#1_100−1内の呼処理部(ACT)151は、セッション切断要求(655−1)に対応する処理を実行し、SWB120にセッション切断応答(ACT)を送信する(656)。SWB120内の呼処理同期状態管理部155は、セッション切断応答(ACT)を受信すると、図12に示したGTP−Cパケット転送ルーチンP1_800を再び実行する(657)。そして、GTP−Cパケット転送ルーチンP1_800が実行されると、セッション切断応答(ACT)がアクセスゲートウェイ33に転送される(658)。
また、PB#2_100−2内の呼処理部(SBY)153は、セッション切断要求に対応する処理を実行し、SWB120にセッション切断応答(SBY)を送信する(659)。SWB120内の呼処理同期状態管理部155は、セッション切断応答(SBY)を受信する(659)と、図12に示したGTP−Cパケット転送ルーチンP1_800を再び実行する(660)。
なお、この場合、呼処理同期状態管理部155は、図12のステップ801から803に対応する処理として、GTP−Cトランザクション管理テーブル321、GTP−Cセッション管理テーブル321−1、及び呼状態管理テーブル310から、端末5のユーザIDに対応するエントリをすべて削除する。また、図12のステップ804において、GTP−Cパケットの送信元は呼処理部(SBY)153であると判定されるので、呼処理同期状態管理部155は、セッション切断応答(SBY)をアクセスゲートウェイ33に転送せず、廃棄する。
次に、アクセスゲートウェイ33は、セッション切断応答(ACT)を受信する(658)と、移動管理サーバ32にセッション切断応答を送信する(661)。移動管理サーバ32は、基地局31B及び端末5にセッション切断応答を送信する(662)。
[6−4.系切替え時のコールフロー]
図11は、本発明の第1の実施形態のサービス網ゲートウェイ21が現用系の呼処理部から予備系の呼処理部へ系切替えを実行する場合のコールフローを示す説明図である。
PB#1_100−1内の呼処理部(ACT)151と、PB#2_100−2内の呼処理部(SBY)153と、は常時互いの稼働状況を監視する(681)。そして、呼処理部(ACT)151に障害が発生すると、呼処理部(SBY)153は、その障害を検出する(682)。この場合、呼処理部(SBY)153は、まず呼処理を一旦停止し(683)、SWB120内の呼処理同期状態管理部155に、切換え要求を送信する(684)。
SWB120内の呼処理同期状態管理部155は、切換え要求を受信すると、図13に示した呼識別子抽出ルーチンP2_820を実行し、同期が確立していない呼識別子を特定し、特定された呼識別子のリストを含む切換え応答を、呼処理部(SBY)153に送信する(686)。
呼処理部(SBY)153は、送信された呼識別子に対応する呼状態を無効化した(687)する。具体的には、呼処理部(SBY)153が備える呼状態を管理するためのテーブル(図示省略)から、送信された呼識別子に対応する呼状態が格納されたエントリを削除する。その後、呼処理を再開し(688)、呼処理部(ACT)151の処理を引き継ぐ。
なお、SWB120内の呼処理同期状態管理部155は、切換え応答を送信した(686)後、GTP−Cパケットの転送先を呼処理部(ACT)151から呼処理部(SBY)153に書き換える。つまり、GTP−Cパケットの転送先であるGTP−Cエンドポイント情報を呼処理部(ACT)151のGTP−CトンネルIDから呼処理部(SBY)153のGTP−CトンネルIDに書き換える(689)。
また、呼処理同期状態管理部155は、ユーザトラフィックの転送先をパケット転送部(ACT)152からパケット転送部(SBY)154へ書き換える。つまり、ユーザトラフィックの転送先であるGTP−Uエンドポイント情報を呼処理部(ACT)151のGTP−UトンネルIDから呼処理部(SBY)153のGTP−UトンネルIDに書き換える(690)。なお、この場合、呼処理同期状態管理部155は、休止している呼処理部(SBY)153を起動する。
これによって、サービス網ゲートウェイ21は、呼処理部(ACT)151に障害が発生した場合であっても、GTP−Cパケット及びユーザトラフィックの転送処理を継続することができる。
以上説明したように、第1の実施形態では、呼処理同期状態管理部155が呼処理部(ACT)151及び呼処理部(SBY)153に呼処理パケット(GTP−Cパケット)を転送し、転送されたGTP−Cパケットの内容に基づいて、トランザクション状態を管理するので、サービス網ゲートウェイ21は、トランザクション状態に基づいて、呼処理部(SBY)と呼処理部(ACT)との各呼状態の同期を維持することができる。
[実施形態2]
以下、本発明の第2の実施形態について図面を参照して説明する。第2の実施形態では、予備系の呼処理部(SBY)153が呼処理プロトコルを中継し、現用系の呼処理部(ACT)151の呼状態を常時ミラーリングすることによって、各呼状態の同期を維持する。
[1.ネットワーク及びサービス網ゲートウェイ21の構成]
第2の実施形態のネットワークの構成は、図2に示した第1の実施形態のネットワークの構成と同じである。また、第2の実施形態のサービス網ゲートウェイ21のハードウェアの構成は、図3に示した第1の実施形態のサービス網ゲートウェイ21のハードウェアの構成と同じである。
[2.サービス網ゲートウェイ21の冗長化]
図1Bは、本発明の第2の実施形態のサービス網ゲートウェイ21の構成を示すブロック図である。
PB#1_100−1は、現用系であり、呼処理部(ACT)1151及びパケット転送部(ACT)1152を備える。PB#2_100−2は、予備系であり、呼処理部(SBY)1153及びパケット転送部(SBY)1154(休止中)を備える。
呼処理部(ACT)1151及び呼処理部(SBY)1153は、並列多重処理方式によって、冗長化される。つまり、サービス網ゲートウェイ21は、現用系の呼処理部(ACT)1151及び予備系の呼処理部(SBY)1153を、それぞれ、PB#1_100−1及びPB#2_100−2において独立に動作させる。ただし、呼処理部(SBY)1153は、呼処理部(ACT)1151と全く独立に動作するのではなく、呼処理部(ACT)1151が送受信するGTP−Cパケットを中継し、呼処理部(ACT)1151の呼状態を抽出する点で、第1の実施形態のサービス網ゲートウェイ21と異なる。
また、呼処理部(SBY)1153は、呼処理部(ACT)1151に障害が発生した場合、GTP−Cパケットから抽出された呼状態を用いて、呼処理部(ACT)1151の処理を引き継ぐ。また、このような冗長化を実現するために、サービス網ゲートウェイ21は、パス管理部(図示省略)を備えてもよい。パス管理部は、他ノード(AGW)から受信したGTP−Cパケットを、SWB120を経由して、呼処理部(SBY)1153に転送するためのパスを設定する。また、呼処理部(SBY)1153に転送されたGTP−Cパケットを、SWB120を経由して、呼処理部(ACT)1151に転送するためのパスを設定する。
さらに、パス管理部は、呼処理部(ACT)1151から送信されたGTP−Cパケットを、SWB120を経由して、呼処理部(SBY)1153に転送するためのパスを設定する。また、パス管理部は、呼処理部(SBY)1153が受信したGTP−Cパケットを、SWB120を経由して、他ノードに転送するためのパスを設定する。なお、サービス網ゲートウェイ21の装置内のパスは、例えば、VLAN、IPinIPトンネル等によって実現される。
一方、パケット転送部(ACT)1152、及びパケット転送部(SBY)1154は、第1の実施形態のサービス網ゲートウェイ21と同様に、1対1待機冗長方式によって、冗長化される。つまり、現用系のパケット転送部(ACT)1152は、PB#1_100−1で動作し、予備系のパケット転送部(SBY)1154は、PB#2_100−2で動作する。そして、SWB120は、サービス網ゲートウェイ21のパケット転送部(ACT)1152と、他ノードとの間で、ユーザトラフィックを転送する。
なお、呼処理部(ACT)1151とパケット転送部(ACT)1152とは対で動作する。また、呼処理部(SBY)1153とパケット転送部(SBY)1154とは対で動作する。サービス網ゲートウェイ21は、呼処理部(ACT)1151から呼処理部(SBY)1153への系切替えを実行する場合、パケット転送部(ACT)1152からパケット転送部(SBY)1154への系切替えも同時に実行する。
[3.呼処理管理テーブル1300]
以下に、呼処理管理テーブル1300の構成について、図14から図17を用いて説明する。なお、呼処理管理テーブル1300は、呼処理部(SBY)1153が、呼処理部(ACT)1151の呼状態を管理するためのテーブルである。呼処理管理テーブル1300は、PB#2_100−2のメモリ103に格納される。
[3−1.呼処理管理テーブル1300の構成]
図14は、本発明の第2の実施形態の呼処理管理テーブル1300の構成を示す説明図である。
呼処理管理テーブル1300は、呼状態管理テーブル1310、呼処理プロトコル管理テーブル1320及びトランスポートプロトコル管理テーブル1330を含む。呼状態管理テーブル1310は、呼処理プロトコルに依存しないサービス網毎、ユーザ毎の接続状況を管理するためのテーブルである。
呼処理プロトコル管理テーブル1320は、呼処理プロトコルとして用いられるGTP−C、Diameterなどの呼処理プロトコル状態を管理するためのテーブルである。
トランスポートプロトコル管理テーブル1330は、UDP、SCTPなどのトランスポートプロトコルの状態を管理するためのテーブルであり、トランスポートプロトコル毎に定義される。
呼処理管理テーブル1300は、図4に示した呼処理管理テーブル300よりも、管理する情報量(テーブル数)が多い。なぜならば、第1の実施形態の呼処理管理テーブル300は、呼状態の不一致の判定、及び系切替え時のトンネル宛先変換に用いる情報のみを管理するが、第2の実施系の呼処理管理テーブル1300は、系切替え時に呼処理を引き継ぐための情報をすべて管理するからである。そのため、呼処理管理テーブル1300は、第1の実施形態の呼処理管理テーブル300が含む各テーブルのほか、さらに、GTP−Cパス管理テーブル1321−3、Diameterピア管理テーブル1322−3、UDP管理テーブル1331を含む。
なお、第1の実施形態の呼処理管理テーブル300は、呼処理部(ACT)151及び呼処理部(SBY)153の両方の状態を管理するが、第2の実施形態の呼処理管理テーブル1300は、呼処理部(ACT)1151の状態のみを管理する。
以下に、呼状態管理テーブル1310の構成の例について、図15を用いて説明する。また、GTP−Cセッション管理テーブル1321−1、GTP−Cトランザクション管理テーブル1321−2、及びGTP−Cパス管理テーブル1321−3の構成の例について、図16を用いて説明する。また、UDP管理テーブル1331の構成の例について図17を用いて説明する。なお、Diameterセッション管理テーブル1322−1、Diameterトランザクション管理テーブル1322−2、及びDiameterピア管理テーブル1322−3の構成については説明を省略するが、これらは、各々、GTP−Cセッション管理テーブル1321−1、GTP−Cトランザクション管理テーブル1321−2、及びGTP−Cパス管理テーブル1321−3とほぼ同じ構成である。また、SCTP管理テーブル1332の構成については説明を省略するが、SCTP管理テーブル1332は、UDP管理テーブル1331とほぼ同じ構成である。
[3−2.呼処理管理テーブル1300の構成]
図15は、本発明の第2の実施形態の呼状態管理テーブル1310の構成を示す説明図である。
呼状態管理テーブル1310は、呼識別子1361、ベアラ情報(GTP−Uエンドポイント情報)1362及び呼処理プロトコル管理テーブルへのポインタ1363を含む。
呼状態管理テーブル1310の呼識別子1361、ベアラ情報(GTP−Uエンドポイント情報)1362及び呼処理プロトコル管理テーブルへのポインタ1363は、各々、図5に示した呼状態管理テーブル310の呼識別子361、ベアラ情報(GTP−Uエンドポイント情報)362及び呼処理プロトコル管理テーブルへのポインタ363と同じである。ただし、ベアラ情報(GTP−Uエンドポイント情報)1362は、パケット転送部(SBY)のベアラ情報を含まない。
図16Aは、本発明の第2の実施形態のGTP−Cセッション管理テーブル1321−1の構成を示す説明図である。
GTP−Cセッション管理テーブル1321−1は、GTP−Cエンドポイント情報1371、呼状態管理テーブルへのポインタ1372、及びGTP−Cトランザクション管理テーブルへのポインタ1373を含む。GTP−Cセッション管理テーブル1321−1のGTP−Cエンドポイント情報1371、呼状態管理テーブルへのポインタ1372、及びGTP−Cトランザクション管理テーブルへのポインタ1373は、図6Aに示したGTP−Cセッション管理テーブル321−1のGTP−Cエンドポイント情報371、呼状態管理テーブルへのポインタ372、及びGTP−Cトランザクション管理テーブルへのポインタ373と同じである。ただし、GTP−Cエンドポイント情報1371は、呼処理部(SBY)1153のエンドポイント情報を含まない。
を含む。
図16Bは、本発明の第2の実施形態のGTP−Cトランザクション管理テーブル1321−2の構成を示す説明図である。
GTP−Cトランザクション管理テーブル1321−2は、トランザクションID1381、トランザクション状態1382、及びGTP−Cセッション管理テーブルへのポインタ1383を含む。GTP−Cトランザクション管理テーブル1321−2のトランザクションID1381、トランザクション状態1382、及びGTP−Cセッション管理テーブルへのポインタ1383は、各々、図6Bに示したGTP−Cトランザクション管理テーブル321−2のトランザクションID381、トランザクション状態382、及びGTP−Cセッション管理テーブルへのポインタ383と同じである。
ただし、GTP−Cトランザクション管理テーブル1321−2のトランザクション状態1382には、図7に示した状態変数のうちの一部は設定されない。具体的には、第2の実施形態では、呼処理部(SBY)1153が、呼処理部(ACT)1151と呼処理部(SBY)1153との各呼状態の同期を管理するので、図7に示した状態変数「ACT_RSP_SENT」及び「SBY_RSP_SENT」はトランザクション状態1382には設定されない。
これは、第2の実施形態のGTP−Cトランザクション状態遷移では、図7に示したイベントE502の後、状態変数は「REQ_RECEIVED」から「REP_SENT」に遷移し、E504の後、状態変数は、「REQ_RECEIVED」から「SYNC_START」に遷移するためである。
図16Cは、本発明の第2の実施形態のGTP−Cパス管理テーブル1321−3の構成を示す説明図である。
GTP−Cパス管理テーブル1321−3は、GTP−Cエンドポイント情報1401を含む。GTP−Cエンドポイント情報1401は、アクセスゲートウェイ33のGTP−Cエンドポイント情報(AGW)1401A及び呼処理部(ACT)1151のGTP−Cエンドポイント情報(呼処理部(ACT))1401Bを含む。GTP−Cエンドポイント情報とは、例えば、IPアドレス、ポート番号、最新のGTP−Cシーケンス番号などである。
図17は、本発明の第2の実施形態のUDP管理テーブル1331の構成を示す説明図である。
UDP管理テーブル1331は、UDPエンドポイント情報1421を含む。UDPエンドポイント情報1421は、アクセスゲートウェイ33のUDPエンドポイント情報1421A、及び呼処理部(ACT)1151のUDPエンドポイント情報1421Bを含む。UDPエンドポイント情報とは、例えば、IPアドレス、ポート番号などである。
[4.コールフロー]
[4−1.端末5接続時の正常系コールフロー]
図18は、本発明の第2の実施形態のサービス網ゲートウェイ21を起動する場合、及びサービス網ゲートウェイ21が端末5を接続する場合のコールフローを示す説明図である。
サービス網ゲートウェイ21が起動する場合、サービス網ゲートウェイ21の装置内のパスが設定される(1601)。まず、サービス網ゲートウェイ21は、GTP−Cパケットを、SWB120を経由して、PB#2_100−2の呼処理部(SBY)1153に転送する。そして、さらに、呼処理部(SBY)1153に転送されたGTP−Cパケットを、SWB120を経由して、PB#1_100−1の呼処理部(ACT)1151に転送する(1601−1)。
また、サービス網ゲートウェイ21は、ユーザトラフィックを、SWB120を経由して、PB#1_100−1のパケット転送部(ACT)1152に転送する(1601−2)。
次に、サービス網ゲートウェイ21が端末5を接続する場合、サービス網ゲートウェイ21は、図8に示したステップ601から603の処理を実行する。その後、アクセスゲートウェイ33は、セッション確立要求をサービス網ゲートウェイ21に送信する。次に、サービス網ゲートウェイ21のSWB120は、セッション確立要求をPB#2_100−2の呼処理部(SBY)1153に送信する(1611)。呼処理部(SBY)1153は、セッション確立要求を受信すると、GTP−Cパケット転送ルーチンP3_1800(図21参照)を実行する(1612)。
図21は、本発明の第2の実施形態のGTP−Cパケット転送ルーチンP3_1800を示すフローチャートである。
呼処理部(SBY)1153は、受信したGTP−Cパケットの内容に基づいて、UDP管理テーブル1331を更新する(1801)。次に、GTP−Cパス管理テーブル1321−3を更新する(1802)。次に、GTP−Cトランザクション管理テーブル1321−2を更新する(1803)。次に、GTP−Cセッション管理テーブル1321−1を更新する(1804)。次に、呼状態管理テーブル1310を更新する(1805)。最後に、呼処理部(SBY)1153は、GTP−Cパケットを呼処理部(ACT)1151に転送し(1806)、処理を終了する。
呼処理部(SBY)1153は、ステップ1801に対応する処理として、UDP管理テーブル1331に新規エントリを追加し、追加された新規エントリのUDPエンドポイント情報(AGW)1421Aに、アクセスゲートウェイ33のIPアドレス及びポート番号を設定する。また、GTP−Cパス管理テーブル1321−3に新規エントリを追加し、追加された新規エントリのGTP−Cエンドポイント情報(AGW)1401Aに、アクセスゲートウェイ33のIPアドレス及びポート番号を設定する。
なお、アクセスゲートウェイ33とサービス網ゲートウェイ21との間にGTP−Cパスが既に設定されている場合、ステップ1801は実行されない。
次に、呼処理部(SBY)1153は、ステップ1802に対応する処理として、GTP−Cパス管理テーブル1321−3に追加された新規エントリのGTP−Cエンドポイント情報(AGW)1401Aに、最新のGTP−Cシーケンス番号を設定する。
次に、呼処理部(SBY)1153は、ステップ1803に対応する処理として、GTP−Cトランザクション管理テーブル1321−2に新規エントリを追加し、追加された新規エントリのトランザクションID1381に、アクセスゲートウェイ33が割り当てたIPアドレス、UDPポート番号、GTP−Cシーケンス番号を設定する。また、追加された新規エントリのトランザクション状態1382に、トランザクション状態の状態変数(例えば、REQ_RECEIVED)を設定する。
次に、呼処理部(SBY)1153は、ステップ1804に対応する処理として、GTP−Cセッション管理テーブル1321−1に新規エントリを追加し、追加された新規エントリのGTP−Cエンドポイント情報(AGW)1371Aに、アクセスゲートウェイ33のIPアドレス及びGTP−CトンネルIDを設定する。
次に、呼処理部(SBY)1153は、ステップ1805に対応する処理として、呼状態管理テーブル1310に新規エントリを追加し、追加された新規エントリのサービス網ID1361A、ユーザID1361B、ベアラID1362A、GTP−Uエンドポイント情報(AGW)1362Bに、アクセスゲートウェイ33から送信されたサービス網ID、ユーザID、ベアラID、GTP−UトンネルID及びIPアドレスを設定する。
ここで、図18の説明に戻る。
ステップ1612の後、PB#2_100−2の呼処理部(SBY)1153は、サービス網ゲートウェイ21に設定された呼処理プロトコル(GTP−C)のパスに従って、SWB120を経由して、PB#1_100−1の呼処理部(ACT)1151に、セッション確立要求を送信する(1613)。PB#1_100−1の呼処理部(ACT)1151は、同様に、SWB120を経由して、PB#2_100−2の呼処理部(SBY)1153に、セッション確立応答を送信する(1614)。
そして、PB#2_100−2の呼処理部(SBY)1153は、セッション確立応答を受信すると、GTP−Cパケット転送ルーチンP4_1820(図22参照)を実行する(1615)。
図22は、本発明の第2の実施形態のGTP−Cパケット転送ルーチンP4_1820を示すフローチャートである。
呼処理部(SBY)1153は、受信したGTP−Cパケットの内容に基づいて、呼状態管理テーブル1310を更新する(1821)。次に、GTP−Cセッション管理テーブル1321−1を更新する(1822)。次に、GTP−Cトランザクション管理テーブル1321−2を更新する(1823)。次に、GTP−Cパス管理テーブル1321−3を更新する(1824)。次に、UDP管理テーブル1331を更新する(1825)。最後に、呼処理部(SBY)1153は、宛先の他ノード(AGW)へGTP−Cパケットを転送し(1826)、処理を終了する。
ここで、呼処理部(SBY)1153は、ステップ1821に対応する処理として、ステップ1805において追加された、呼状態管理テーブル1310の新規エントリのGTP−Uエンドポイント情報1362Cに、呼処理部(ACT)1151から送信されたパケット転送部(ACT)1152のIPアドレス及びGTP−UトンネルIDを設定する。
また、呼処理部(SBY)1153は、ステップ1822に対応する処理として、ステップ1804において追加された、GTP−Cセッション管理テーブル1321−1の新規エントリのGTP−Cエンドポイント情報(呼処理部(ACT))1371Bに呼処理部(ACT)1151から送信されたIPアドレス及びGTP−CトンネルIDを設定する。
また、呼処理部(SBY)1153は、ステップ1823に対応する処理として、ステップ1803において追加された、GTP−Cトランザクション管理テーブル1321−2の新規エントリのトランザクション状態1382を更新する。
また、呼処理部(SBY)1153は、ステップ1824に対応する処理として、ステップ1801において追加された、GTP−Cパス管理テーブル1321の新規エントリのGTP−Cエンドポイント情報(呼処理部(ACT))1401Bに、呼処理部(ACT)1151から送信されたIPアドレス、ポート番号、及び最新のGTP-Cシーケンス番号を設定する。
また、呼処理部(SBY)1153は、ステップ1825に対応する処理として、ステップ1801において追加された、UDP管理テーブル1331の新規エントリのUDPエンドポイント情報(呼処理部(ACT))1421Bに、呼処理部(ACT)1151のIPアドレス及びポート番号を設定する。
呼処理部(SBY)1153は、ステップ1826に対応する処理として、SW120を経由して、他ノード(AGW)にGTP−Cパケットを送信する。
図18の説明に戻る。
ステップ1615の後、PB#2_100−2の呼処理部(SBY)1153は、セッション確立応答(図22のステップ1826のGTP−Cパケット)をSWB120に送信する。SWB120は、セッション確立応答をアクセスゲートウェイ33に送信する(1616)。その後、呼処理部(SBY)1153は、図8に示したステップ612から617の処理を実行する。以上の処理によって、サービス網ゲートウェイ21は、端末5を接続する。
[4−2.系切替え時のコールフロー1]
図19は、本発明の第2の実施形態のサービス網ゲートウェイの現用系の呼処理部に障害が発生した場合のコールフローを示す説明図である。
系切替えの前に、サービス網ゲートウェイ21の装置内のパスが設定される(1651)。設定されるGTP−Cパケット及びユーザトラフィックのパスは、それぞれ、図18のステップ1601−1及び1601−2に示したパスと同じである。
また、PB#1_100−1の呼処理部(ACT)1151とPB#2_100−2の呼処理部(SBY)1153とは、常時互いの稼働状況を監視する(1652)。
ここで、呼処理部(ACT)1151に障害が発生すると、呼処理部(SBY)1153は、呼処理部(ACT)1151に発生した障害を検出する(1653)。この場合、呼処理部(SBY)1153は、まず、呼処理を一旦停止し(1654)、サービス網ゲートウェイ21の装置内のパスを再設定する(1655)。
具体的には、呼処理部(SBY)1153は、GTP−Cパケットを転送するために、SWB120とPB#2_100−2の呼処理部(SBY)1153との間にパスを設定する(1655−1)。
また、呼処理部(SBY)1153は、ユーザトラフィックを転送するために、休止しているPB#2_100−2のパケット転送部(SBY)1154を起動し、SWB120と起動したパケット転送部(SBY)1154との間にパスを設定する(1655−2)。
そして、呼処理部(SBY)1153は、呼処理を再開する(1656)。以上の処理によって、呼処理部(ACT)1151に障害が発生した場合であっても、呼処理部(SBY)1153は、呼処理部(ACT)1151の処理を引き継ぐことができる。
[4−3.系切替え時のコールフロー2]
図20は、本発明の第2の実施形態のサービス網ゲートウェイの予備系の呼処理部に障害が発生した場合のコールフローを示す説明図である。
系切替えの前に、サービス網ゲートウェイ21の装置内のパスが設定される(1671)。設定されるGTP−Cパケット及びユーザトラフィックのパスは、それぞれ、図18のステップ1601−1及び1601−2に示したパスと同じである。
また、PB#1_100−1の呼処理部(ACT)1151とPB#2_100−2の呼処理部(SBY)1153とは、常時互いの稼働状況を監視する(1672)。
ここで、呼処理部(SBY)1153に障害が発生すると、呼処理部(ACT)1151は、呼処理部(SBY)1153に発生した障害を検出する(1673)。この場合、呼処理部(ACT)1151は、まず、呼処理を一旦停止し(1674)、サービス網ゲートウェイ21の装置内のパスを再設定する。
具体的には、呼処理部(ACT)1151は、GTP−Cパケットを転送するために、SWB120とPB#1_100−1の呼処理部(ACT)1151との間にパスを設定する(1675−1)。
また、呼処理部(ACT)1151は、ユーザトラフィックを転送するために、SWB120とPB#1_100−1のパケット転送部(ACT)1152との間にパスを設定する(1675−2)。そして、呼処理部(ACT)1151は、呼処理を再開し、処理を継続する。
以上説明したように、第2の実施形態では、呼処理部(SBY)が呼処理パケットを中継し、処理部(ACT)に呼処理パケットを転送するので、サービス網ゲートウェイ21は、呼処理部(SBY)が呼処理パケットから抽出した呼状態に基づいて、呼処理部(SBY)と呼処理部(ACT)との間の各呼状態の同期を維持することができる。