知財求人 - 知財ポータルサイト「IP Force」
特許7247477制御装置、課金取得方法、課金取得プログラムおよび課金システム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-03-20
(45)【発行日】2023-03-29
(54)【発明の名称】制御装置、課金取得方法、課金取得プログラムおよび課金システム
(51)【国際特許分類】
H04W 24/04 20090101AFI20230322BHJP
H04M 15/00 20060101ALI20230322BHJP
H04W 4/24 20180101ALI20230322BHJP
G06Q 30/04 20120101ALI20230322BHJP
H04W 76/10 20180101ALI20230322BHJP
【ＦＩ】
H04W24/04
H04M15/00 G
H04M15/00 E
H04W4/24
G06Q30/04
H04W76/10
【請求項の数】
8
(21)【出願番号】P 2018107237
(22)【出願日】2018-06-04
(65)【公開番号】P2019213037
(43)【公開日】2019-12-12
【審査請求日】2021-03-10
(73)【特許権者】
【識別番号】000005223
【氏名又は名称】富士通株式会社
(74)【代理人】
【識別番号】110002147
【氏名又は名称】弁理士法人酒井国際特許事務所
(72)【発明者】
【氏名】米永 伸江
【審査官】石原 由晴
(56)【参考文献】
【文献】特表２０１８－５０１６８５（ＪＰ，Ａ）
【文献】特表２０１３－５３５８８１（ＪＰ，Ａ）
【文献】米国特許出願公開第２０１５／０３５８４８０（ＵＳ，Ａ１）
【文献】3GPP TS 32.295 V14.0.0，2017年03月17日，pages 12-23
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｈ０４Ｂ ７／２４－７／２６
Ｈ０４Ｗ ４／００－９９／００
Ｈ０４Ｍ １５／００
Ｇ０６Ｑ ３０／０４
３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１－４
ＳＡ ＷＧ１－４
ＣＴ ＷＧ１、４
(57)【特許請求の範囲】
【請求項1】
通信料金の請求に利用される課金情報を生成する課金生成装置との間で確立される第１のコネクションを経由して、前記課金情報を受信する受信部と、前記課金生成装置との通信が遮断された後、前記課金生成装置との通信が復旧した場合に、前記課金生成装置との間で前記第１のコネクションおよび第２のコネクションを確立する確立部と、
前記第１のコネクションを経由して、前記通信が復旧した後に生成された第１の課金情報を受信し、前記第２のコネクションを経由して、前記通信の遮断中に生成された第２の課金情報を取得する受信制御部と
を有することを特徴とする制御装置。
【請求項2】
前記確立部は、前記第２の課金情報の取得が完了した場合に、前記第１のコネクションの確立を維持しつつ、前記第２のコネクションを切断することを特徴とする請求項１に記載の制御装置。
【請求項3】
前記受信制御部は、前記第２の課金情報の取得または削除に関する対応指示を含めた要求を、前記第２のコネクションを経由して前記課金生成装置に送信することを特徴とする請求項１に記載の制御装置。
【請求項4】
前記制御装置は、冗長化された複数の制御装置のうちの待機系の制御装置であり、前記確立部は、前記複数の制御装置と前記課金生成装置との通信が遮断されて復旧した後に、前記課金生成装置との間で、退避用の第２のコネクションを確立し、
前記受信制御部は、前記退避用の第２のコネクションを経由して、前記第２の課金情報を取得することを特徴とする請求項１に記載の制御装置。
【請求項5】
前記確立部は、３ＧＰＰ（Third Generation Partnership Project)ネットワークのオフライン課金アーキテクチャで利用されるＧＰＲＳ（General Packet Radio Service）トンネリングプロトコルを用いて、前記第１のコネクションおよび前記第２のコネクションを確立することを特徴とする請求項１に記載の制御装置。
【請求項6】
コンピュータが、通信料金の請求に利用される課金情報を生成する課金生成装置との間で確立される第１のコネクションを経由して、前記課金情報を受信し、
前記課金生成装置との通信が遮断された後、前記課金生成装置との通信が復旧した場合に、前記課金生成装置との間で前記第１のコネクションおよび第２のコネクションを確立し、
前記第１のコネクションを経由して、前記通信が復旧した後に生成された第１の課金情報を受信し、前記第２のコネクションを経由して、前記通信の遮断中に生成された第２の課金情報を取得する
処理を実行することを特徴とする課金取得方法。
【請求項7】
コンピュータに、通信料金の請求に利用される課金情報を生成する課金生成装置との間で確立される第１のコネクションを経由して、前記課金情報を受信し、
前記課金生成装置との通信が遮断された後、前記課金生成装置との通信が復旧した場合に、前記課金生成装置との間で前記第１のコネクションおよび第２のコネクションを確立し、
前記第１のコネクションを経由して、前記通信が復旧した後に生成された第１の課金情報を受信し、前記第２のコネクションを経由して、前記通信の遮断中に生成された第２の課金情報を取得する
処理を実行させることを特徴とする課金取得プログラム。
【請求項8】
課金生成装置と制御装置とを含む課金システムにおいて、前記課金生成装置は、
通信料金の請求に利用される課金情報を生成する生成部と、
前記制御装置との間で確立される第１のコネクションを経由して、前記課金情報を送信する送信部と、を有し、
前記制御装置は、
前記課金生成装置との間で確立される前記第１のコネクションを経由して、前記課金情報を受信する受信部と、
前記課金生成装置との通信が遮断された後、前記課金生成装置との通信が復旧した場合に、前記課金生成装置との間で前記第１のコネクションおよび第２のコネクションを確立する確立部と、
前記第１のコネクションを経由して、前記通信が復旧した後に生成された第１の課金情報を受信し、前記第２のコネクションを経由して、前記通信の遮断中に生成された第２の課金情報を取得する受信制御部と
を有することを特徴とする課金システム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、制御装置、課金取得方法、課金取得プログラムおよび課金システムに関する。
【背景技術】
【0002】
3GPP（Third Generation Partnership Project)ネットワークのオフライン課金アーキテクチャにおけるGa（Reference point between a CDF and the CGF for CDR transfer）参照ポイントに関して、3GPP TS 32.295で規定されている。オフライン課金は、月々請求される料金請求のように、呼（電話）の開始や終了時刻などの詳細な記録（CDR：Charging Data Record）を通じて、料金請求がされる課金の仕組みである。オフライン課金では、通信中のサービスに影響を即時に通信中に与えることはなく、料金請求後にサービスへの料金未払い等により、サービスが使えなくなるなどの影響が発生する。Gaは、課金データ機能（CDF：Charging Data Function）から課金ゲートウェイ機能（CGF：Charging Gateway Function）への参照ポイントであり、課金データレコード（CDR）の転送に使用される。
【0003】
図２３は、オフライン課金アーキテクチャを説明する図である。図２３に示すように、CTF（Charging Trigger Function）は、ネットワーク要素内の課金可能な事象に関する情報を収集し、この情報を対応する課金イベントに組み立て、Rf（Reference Point between the CTF within a 3G network element and the CDF for offline charging）参照ポイントを介してCDFに転送する。CDF（Charging Data Function）は、Rf参照ポイントを経たCTFからのChargingイベントを受信し、受信したChargingイベントに含まれている情報を用いてCDRを生成し、Ga参照ポイントを介してCGF（Charging Gateway Function）に転送する。CGFは、CDFによって生成されたCDRをGa参照ポイントを介して受信し、受信したCDRの検証、統合、再フォーマットなどを行い、CDRファイルを生成してBx（The reference point between any （generic） 3G domain, subsystem or service CGF and the BD）参照ポイントを介して、BD（Billing Domain）に転送する。
【0004】
図２３に示すネットワークにおけるCDRパケットの転送について具体的に説明する。まず、CDFは、CGFへData Record Transfer Requestメッセージを用いてCDRを送信する。続いて、CGFは、受信したCDRを冗長RAM（Random Access Memory）メモリユニットまたはミラーリングされた不揮発性メモリなどに格納する。格納したCDRは、BDに転送するためにBxフォーマットに変換される。その後、CGFは、CDFへData Record Transfer Responseメッセージを用いてCDR受信成功を送信する。このときのCause値は「Request Accepted」となる。そして、CDFは、Request Acceptedを受信した後、正常に送信されたCDRを送信バッファから削除する。このようにして、CDFで生成されたCDRは、CGFへリアルタイムに送信される。なお、CDFからCGFへのCDRの転送のための機能を提供するGa参照ポイントに関連するトランスポートプロトコルとしては、GTPプライム（GTP’）が利用される。近年では、システム障害やリンク障害などの障害時に備えて、CGFを冗長化することも行われている。
【先行技術文献】
【特許文献】
【0005】
【文献】特開２０１０－１４７６４４号公報
【文献】特表２０１０－５１５３５５号公報
【発明の概要】
【発明が解決しようとする課題】
【0006】
ところで、障害によって遮断されたCDFとCGFとの通信が復旧した後、障害によって送信されなかった旧CDRと障害が復旧するまでの間に新規に生成された新CDRとが混在することがある。上記技術では、CDFの退避用ストレージに旧CDRを保持したとしても、復旧後にCGFへ自動的に転送するプロトコルの規定がないことから、CDFに直接ログインして旧CDRを手動で収集し、Bxフォーマットに変換してBDに送信することが行われている。
【0007】
また、CDFが、旧CDRを退避用ストレージに保存しておき、障害復旧後に、旧CDRおよび新CDRをCGFへ送信することも考えられるが、この手法では新CDRの送信遅延が発生する。例えば、シーケンス番号１００のCDRを送信中に障害が発生し、障害の間にシーケンス番号５００までのCDRが生成されたとする。この場合、CDFは、シーケンス番号１００から５００までの４００個の旧CDRを蓄積しておき、障害復旧後に順次送信する。しかし、障害復旧後には新たに生成されたシーケンス番号５０１の新CDRが、障害時に蓄積された４００個の旧CDRの送信後に送信されることになり、リアルタイム送信が実行できない。
【0008】
なお、CDRの送信には、3GPPにおいて「near real time」として１分が設定されており、障害時に蓄積されるCDRの数が多いほど、この制約を遵守することができない。また、障害時に蓄積されたCDRを廃棄することも考えられるが、廃棄すると課金を正しく行うことができなくなるので、好ましい手法ではない。
【0009】
一つの側面では、課金情報の送信遅延を抑制することができる制御装置、課金取得方法、課金取得プログラムおよび課金システムを提供することを目的とする。
【課題を解決するための手段】
【0010】
第１の案では、制御装置は、通信料金の請求に利用される課金情報を生成する課金生成装置との間で確立される第１のコネクションを経由して、前記課金情報を受信する受信部を有する。制御装置は、前記課金生成装置との通信が遮断された後、前記課金生成装置との通信が復旧した場合に、前記課金生成装置との間で前記第１のコネクションおよび第２のコネクションを確立する確立部を有する。制御装置は、前記第１のコネクションを経由して、前記通信が復旧した後に生成された第１の課金情報を受信し、前記第２のコネクションを経由して、前記通信の遮断中に生成された第２の課金情報を取得する受信制御部を有する。
【発明の効果】
【0011】
一実施形態によれば、課金情報の送信遅延を抑制することができる。
【図面の簡単な説明】
【0012】
【発明を実施するための形態】
【0013】
以下に、本願の開示する制御装置、課金取得方法、課金取得プログラムおよび課金システムの実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が限定されるものではない。また、各実施例は、矛盾のない範囲内で適宜組み合わせることができる。
【実施例1】
【0014】
［全体構成］
図１は、実施例１にかかるオフライン課金アーキテクチャのシステム構成を示す図である。図１に示すシステムは、RNC（Radio Network Controller）、SGSN（Serving GPRS Support Node）、eNodeB（E-UTRAN NodeB）、EPC（Evolved Packet Core）、他EPC、BD（Billing Domain）、VGN（VoLTE Gateway Node）、ISP（Internet Service Provider）を有するシステムであり、音声通話などのように月々の料金請求に使用される詳細記録（CDR）を収集して課金を行うオフライン課金システムである。
図１は、実施例１にかかるオフライン課金アーキテクチャのシステム構成を示す図である。図１に示すシステムは、RNC（Radio Network Controller）、SGSN（Serving GPRS Support Node）、eNodeB（E-UTRAN NodeB）、EPC（Evolved Packet Core）、他EPC、BD（Billing Domain）、VGN（VoLTE Gateway Node）、ISP（Internet Service Provider）を有するシステムであり、音声通話などのように月々の料金請求に使用される詳細記録（CDR）を収集して課金を行うオフライン課金システムである。
【0015】
RNCは、無線通信ネットワーク全体を制御する制御局である。SGSNは、3G無線アクセスにおける端末の移動管理や認証（セキュリティ制御）などを行う装置である。eNodeBは、LTE（Long Term Evolution）を利用した携帯電話の通信で使われている基地局である。EPCは、LTEのアクセス網を収容するコアネットワークである。BDは、課金情報を収集して課金を行う課金装置を含む料金請求システムである。VGNは、LTEのデータ通信を用いて音声通話を実現させるためのゲートウェイノードである。ISPは、インターネットを利用するユーザに対して、ユーザのコンピュータをインターネットへ接続するための手段をサービスとして提供する事業者である。
【0016】
また、EPCは、MME（Mobility Management Entity）、PCRF（Policy and Charging Rule Function）／DRA（Diameter Routing Agent）、S-GW（Serving Gateway）、P-GW（Packet Data Network Gateway）、CDF１０、CGF３０を有する。MMEは、端末の移動管理、認証（セキュリティ制御）およびS-GWとeNodeB区間におけるユーザデータの転送経路の設定処理や制御信号に関する処理を実行する。PCRFは、P-GW、S-GWにおいて適用する、QoSなどのポリシー制御や課金制御ルールを決定するポリシー制御装置である。DRAは、Diameterルーティングエージェントであり、Diameterシグナリングを制御および管理する装置である。S-GWは、LTEおよび3G無線などの3GPP無線を収容し、ユーザデータを伝送する装置ある。また、S-GWは、LTEと3G無線アクセス収容網へのユーザデータ転送経路を切り替えるポイントでもある。P-GWは、IMS（IP Multimedia Subsystem）などのコアネットワーク外のパケット・ネットワーク(PDN：packet data network)との接続点となる装置である。P-GWは、IPアドレスの割り当てなどを行うとともに、3GPPアクセスおよび非3GPPアクセスを収容するゲートウェイ装置である。
【0017】
CDF１０は、Rf参照ポイントを経たCTFからのChargingイベントを受信し、受信したChargingイベントに含まれている情報を用いてCDRを生成し、Ga参照ポイントを介してCGFに転送する装置である。CGF３０は、CDFによって生成されたCDRを、Ga参照ポイントを介して受信し、受信したCDRの検証、統合、再フォーマットなどを行い、CDRファイルを生成してBx参照ポイントを介して、BDに転送する装置である。
【0018】
また、CDF１０は、３GPP標準で課金が定義されているネットワーク要素の実装形態により、システム内での配置位置が異なる。そのような場合であっても、CDF１０からCGF30へのGa参照ポインタの位置によってCDRの送信経路を特定することができる。図２は、CDRの送信経路を示す図である。図２の（ａ）は、CDF１０が他のネットワーク要素に統合されているシステム例を示す。この場合、物理的なNEがCDRを生成し、それらをCGFに送信する。したがって、Ga参照ポインタは、物理インタフェースとしてNE内に実装される。
【0019】
図２の（ｂ）は、CDF１０がネットワーク要素として存在するシステム例を示す。この場合、NE、CDF１０、及びCGF３０の物理インタフェースとしてすべての参照ポイントを実装する。つまり、NEは、Rf参照ポインタを用いて、システム内から収集した課金イベントをCDF１０に送信する。CDF１０は、課金イベントからCDRを生成し、Ga参照ポイントを介してCGF３０に送信する。CGF30は、CDF１０から受信したCDRに対して所定の処理を行い、Bx参照ポインタを介して、BDに送信する。
【0020】
上記いずれの場合でも実施例１を適用することができるが、実施例１では、一例として、図２の（ｂ）を用いて説明する。
【0021】
このようなシステムにおいて、CGF３０は、通信料金の請求に利用される課金情報を生成するCDF１０との間で確立される第１のコネクションを経由して、課金情報を受信する。そして、CGF３０は、CDF１０との通信が遮断された後、CDF１０との通信が復旧した場合に、CDF１０との間で第１のコネクションおよび第２のコネクションを確立する。その後、CGF30は、第１のコネクションを経由して、通信が復旧した後に生成された第１の課金情報を受信し、第２のコネクションを経由して、通信の遮断中に生成された第２の課金情報を取得する。
【0022】
つまり、CGF３０は、障害が復旧した後は、帯域やメモリなどの空きリソースを用いて、通常時に使用される第１のコネクションと異なる第２のコネクションを、CDF１０との間で構築する。そして、CGF３０は、障害復旧後に生成される通常時のCDRを、障害発生前と同様の第１のコネクションで受信する。その一方で、CGF30は、障害発生中に生成されて退避されていたCDRを、通常の第１のコネクションとは異なる第２のコネクションで受信する。
【0023】
このようにすることで、CGF３０は、正常なCDRの受信に影響を与えることなく、障害発生中に生成されたCDRを正常に受信することができるとともに、障害復旧後に正常に生成されるCDRを遅滞なく受信することができる。
【0024】
［機能構成］
次に、図１に示したシステムの各要素（装置）について説明するが、CDF１０とCGF３０以外の他の要素は、３GPPの課金アーキテクチャで使用される要素と同様の構成を有するので、詳細な説明は省略する。ここでは、図３を用いて、CDF１０とCGF３０について説明する。図３は、実施例１にかかるCDF１０とCGF３０の機能構成を示す機能ブロック図である。
次に、図１に示したシステムの各要素（装置）について説明するが、CDF１０とCGF３０以外の他の要素は、３GPPの課金アーキテクチャで使用される要素と同様の構成を有するので、詳細な説明は省略する。ここでは、図３を用いて、CDF１０とCGF３０について説明する。図３は、実施例１にかかるCDF１０とCGF３０の機能構成を示す機能ブロック図である。
【0025】
（CDF１０の機能構成）
図３に示すように、CDF１０は、通信部１１、記憶部１２、制御部２０を有する。通信部１１は、ネットワークを介して、他の装置のとの間の通信を制御する処理部である。例えば、通信部１１は、S-GWやP-GWのCTFから課金イベントを受信し、CDRをCGF３０に送信する。また、通信部１１は、CGF３０との間で、コネクションを確立要求や各種メッセージの送受信を実行する。また、通信部１１は、CGF３０との間で、GTPコネクションを確立して、CDRを送信する。
図３に示すように、CDF１０は、通信部１１、記憶部１２、制御部２０を有する。通信部１１は、ネットワークを介して、他の装置のとの間の通信を制御する処理部である。例えば、通信部１１は、S-GWやP-GWのCTFから課金イベントを受信し、CDRをCGF３０に送信する。また、通信部１１は、CGF３０との間で、コネクションを確立要求や各種メッセージの送受信を実行する。また、通信部１１は、CGF３０との間で、GTPコネクションを確立して、CDRを送信する。
【0026】
記憶部１２は、プログラムやデータを記憶する記憶装置の一例であり、例えばメモリやハードディスクなどである。この記憶部１２は、制御部２０によって生成されたCDRを記憶する。また、記憶部１２は、退避ＤＢ１３を記憶する。退避ＤＢ１３は、障害等によってCGF３０への送信が未完了であるCDR（以降では退避CDRと記載する場合がある）を記憶する記憶部である。例えば、退避DB１３は、生成された順でCDRを一時的に記憶する。
【0027】
制御部２０は、CDF１０全体を司る処理部であり、例えばプロセッサなどである。制御部２０は、イベント受付部２１、CDR生成部２２、CDR送信部２３、障害処理部２４を有する。なお、イベント受付部２１、CDR生成部２２、CDR送信部２３、障害処理部２４は、プロセッサが有する電子回路の一例やプロセッサが実行するプロセスの一例である。
【0028】
イベント受付部２１は、CTFから課金イベントを受信する処理部である。具体的には、イベント受付部２１は、端末間の通話等が発生したなどの課金対象のイベントが発生した場合に、課金対象の事象に関する情報である課金イベントをCTFから受信する。例えば、イベント受付部２１は、ユーザ間で音声通話が発生した場合に、セッションの開始、終了など、通信に必要なネットワークリソースの使用状況を通知する課金イベントをCTFから受信する。
【0029】
CDR生成部２２は、イベント受付部２１により受け付けられた課金イベントに基づいて、CDRを生成する処理部である。例えば、CDR生成部２２は、イベント受付部２１から課金イベントを取得し、通話時間、通話時間帯、通話相手などの課金に必要な情報を含むCDRを生成する。そして、CDR生成部２２は、生成したCDRをCDR送信部２３に出力する。
【0030】
CDR送信部２３は、GTPコネクション（GTPトンネル）を介して、CDRをCGF３０に送信する処理部である。例えば、CDR送信部２３は、CDR１０とCGF３０との間で通常時に確立されているGTPコネクションを介して、CDR生成部２２から入力されたCDRをCGF３０に送信する。また、CDR送信部２３は、CDRが生成されてから１分以内のように３GPPで規定される遅延時間を遵守して、CDRの送信を実行する。
【0031】
障害処理部２４は、CDR退避部２５と障害対応部２６とを有し、CDF１０とCGF３０との通信障害、または、CDR１０やCGF３０のシステム障害を検出し、障害対応を実行する処理部である。例えば、障害処理部２４は、CDRを送信した後に受信応答を所定時間の間にCGF３０から受信できない場合に、障害を検出する。また、障害処理部２４は、障害復旧通知やCDRの再送要求などをCGF３０から受信した場合に、障害復旧と判定する。
【0032】
CDR退避部２５は、障害が検出された場合に、CDRを退避する処理部である。例えば、CDR退避部２５は、障害が検出された場合に、障害が復旧するまでに生成されたCDRを退避ＤＢ１３に退避させる。このとき、CDR退避部２５は、退避対象の各CDRに対して、生成された順、すなわち送信順でシーケンシャル番号を付与することで、退避対象のCDRを管理することもできる。
【0033】
障害対応部２６は、障害復旧時に、コネクション等の管理や退避されるCDRの送信を行う処理部である。具体的には、障害対応部２６は、CGF３０との通信が復旧した場合に、CGF３０との間で、通常時に使用されるGTPコネクションを確立する。そして、障害対応部２６は、CDR送信部２３に通常処理を指示する。これにより、障害復旧後に生成されるCDRは、通常時と同様のGTPコネクションを用いて送信される。
【0034】
障害対応部２６は、障害復旧後に上記処理と並行して、CGF３０からの要求に応じて、退避されたCDR送信用の退避用GTPコネクションをCGF３０との間に確立する。そして、障害対応部２６は、新たに退避した退避用GTPコネクションを介して、退避ＤＢ１３に記憶される各退避CDRをCGF３０に送信する。すなわち、障害対応部２６は、未使用の帯域やメモリなどの空きリソースを使用して新たな退避用GTPコネクションを確立し、退避用GTPコネクションを介して未送信のCDRの再送を実行する。
【0035】
このとき、障害対応部２６は、管理しているシーケンシャル番号の順番で退避CDRを送信することで、CDRを生成順で送信することができる。また、障害対応部２６は、退避ＤＢ１３に記憶される全退避CDRの送信が完了すると、退避用GTPコネクションを切断する。この結果、CDF１０とCGF３０との間のGTPコネクションは、障害発生前と同様、通常時に使用されるGTPコネクションのみが確立された状態となる。
【0036】
（CGF３０の機能構成）
図３に示すように、CGF３０は、通信部３１、記憶部３２、制御部４０を有する。通信部３１は、ネットワークを介して、他の装置のとの間の通信を制御する処理部である。例えば、通信部３１は、CDF１０との間で、コネクションを確立要求や各種メッセージの送受信を実行する。また、通信部３１は、CDF１０との間でGTPコネクションを確立して、CDRを受信する。また、通信部３１は、BDとの間の通信を制御する。
図３に示すように、CGF３０は、通信部３１、記憶部３２、制御部４０を有する。通信部３１は、ネットワークを介して、他の装置のとの間の通信を制御する処理部である。例えば、通信部３１は、CDF１０との間で、コネクションを確立要求や各種メッセージの送受信を実行する。また、通信部３１は、CDF１０との間でGTPコネクションを確立して、CDRを受信する。また、通信部３１は、BDとの間の通信を制御する。
【0037】
記憶部３２は、プログラムやデータを記憶する記憶装置の一例であり、例えばメモリやハードディスクなどである。記憶部１２は、受信されたCDRを記憶するCDR格納ＤＢ３３を記憶する。CDR格納ＤＢ３３は、CDF１０から受信されたCDRを、BDに送信されるまで保持する。
【0038】
制御部４０は、CGF３０全体を司る処理部であり、例えばプロセッサなどである。制御部４０は、通常処理部５０と障害処理部６０を有する。なお、通常処理部５０と障害処理部６０は、プロセッサが有する電子回路の一例やプロセッサが実行するプロセスの一例である。
【0039】
通常処理部５０は、CDR受信部５１とCDR処理部５２とを有し、障害発生前や障害復旧後に、通常通り、CDF１０からCDRを受信してBDへ送信する処理部である。
【0040】
CDR受信部５１は、CDF１０との間でGTPコネクションを確立し、GTPコネクションを介して、CDRを受信する処理部である。例えば、CDR受信部５１は、３GPPの遅延時間を遵守して送信されたCDRを、生成された順でCDF１０から順次受信する。そして、CDR受信部５１は、受信したCDRを、受信順でCDR格納ＤＢ３３に格納する。
【0041】
CDR処理部５２は、CDF１０から受信されたCDRを、Bx参照ポイントを介してBDに送信する処理部である。例えば、CDR処理部５２は、CDR格納ＤＢ３３に記憶されるCDRを読み出し、読み出したCDRに対して、CDRの検証、統合、再フォーマットなどの各種処理を実行する。その後、CDR処理部５２は、Bxフォーマットに変換したCDRを、BDに送信する。このとき、CDR処理部５２は、CDRが生成された順で、各種処理を実行してBDに送信する。なお、上記各種処理は、３GPPのオフライン課金で実行される一般的な処理と同様の処理なので、詳細な説明は省略する。
【0042】
障害処理部６０は、プロトコル制御部６１とCDR対応部６２とを有し、CDF１０とCGF３０との通信障害、または、CDR１０やCGF３０のシステム障害を検出し、障害対応を実行する処理部である。例えば、障害処理部６０は、CDRを受信してから予め指定される所定時間が経過するまでに次のCDRを受信しない場合に、通信障害を検出する。また、障害処理部６０は、CGF３０のシステム障害により各種データ（パケット）の送受信がエラーとなった場合に、障害を検出する。また、障害処理部６０は、通信障害やシステム障害が復旧した場合、GTPコネクションの確立要求やCDRの再送要求などをCDF１０に送信する。
【0043】
プロトコル制御部６１は、障害復旧後に、GTPコネクションの確立を実行する処理部である。例えば、プロトコル制御部６１は、障害処理部６０によって障害復旧が検出されると、障害発生前の通常時に確立されていたGTPコネクションを、CDF１０との間で再度確立する。この結果、CDF１０が障害発生後に新たに生成したCDRを、通常時のGTPコネクションを受信することができる。
【0044】
この通常時のGTPコネクションの確立と並行して、プロトコル制御部６１は、障害復旧後に、退避用のGTPコネクションの確立を実行する。例えば、プロトコル制御部６１は、障害が復旧すると、CDF１０に退避用コネクションの確立要求を送信する。そして、プロトコル制御部６１は、当該要求に対する応答をCDF１０から受信すると、未使用の帯域やメモリなどの空きリソースを使用して、退避された退避CDRの送信用である退避用GTPコネクションをCDF１０との間に確立する。その後、プロトコル制御部６１は、障害中に退避されたCDRの送信が完了すると、退避用GTPコネクションを切断して、リソースを解放する。
【0045】
CDR対応部６２は、障害復旧後に、CDF１０内で退避されていた退避CDRに関する処理を実行する処理部である。例えば、CDR対応部６２は、退避用GTPコネクションが確立されると、退避用GTPコネクションを介して、障害発生中に生成されて退避されていたCDR（退避CDR）を受信する。そして、CDR対応部６２は、受信した退避CDRに受信順でシーケンシャル番号などを付与してCDR格納ＤＢ３３に格納する。このようにして、CDR対応部６２は、退避されていた退避CDRの受信状況を管理する。なお、CDR格納ＤＢ３３に格納されたCDR（退避CDR）は、障害発生後の新たに生成されたCDR（新CDR）よりも先に、CDR処理部５２によってBDに送信される。このようにして、CDRの生成順でBDに送信することができる。
【0046】
［コネクション状況］
次に、図４を用いて、GTPコネクションの確立関係を説明する。図４は、通常運用時から障害復旧後までのコネクションの確立関係を説明する図である。図４に示すように、障害発生前の通常時は、CDF１０とCGF３０との間で、１つのGTPコネクションを常時確立し、CDRの送受信を実行する。
次に、図４を用いて、GTPコネクションの確立関係を説明する。図４は、通常運用時から障害復旧後までのコネクションの確立関係を説明する図である。図４に示すように、障害発生前の通常時は、CDF１０とCGF３０との間で、１つのGTPコネクションを常時確立し、CDRの送受信を実行する。
【0047】
そして、障害が発生し、GTPコネクションが切断されると、CDF１０は、生成したCDRを退避ＤＢ１３に退避させて、CGF３０への送信を抑制する。その後、障害が復旧すると、CGF３０は、CDF１０との間に、通常時のGTPコネクションと退避用GTPコネクションの２つのコネクションを確立する。
【0048】
そして、CDF１０は、通常時のGTPコネクションを用いて、障害発生後に生成されたCDRをCGF３０に送信する一方で、退避用GTPコネクションを用いて、障害時に退避されていた退避CDRをCGF３０に送信する。
【0049】
その後、CGF３０は、退避されていた全退避CDRの受信が完了すると、退避用GTPコネクションのみを切断する。この結果、CDF１０とCGF３０のコネクションは、障害発生前と同様の状態となる。
【0050】
［フローチャート］
次に、CDF１０とCGF３０のそれぞれについて、障害発生時の全体的な処理の流れを説明する。
次に、CDF１０とCGF３０のそれぞれについて、障害発生時の全体的な処理の流れを説明する。
【0051】
（CDF１０のフローチャート）
図５は、実施例１にかかるCDF１０の障害発生時の全体的な処理の流れを示すフローチャートである。CDF１０は、CGF３０との通信が一定期間以上切断した場合、CDF１０のストレージもしくは外部ストレージなどに全CDRを退避する。
図５は、実施例１にかかるCDF１０の障害発生時の全体的な処理の流れを示すフローチャートである。CDF１０は、CGF３０との通信が一定期間以上切断した場合、CDF１０のストレージもしくは外部ストレージなどに全CDRを退避する。
【0052】
図５に示すように、CDF１０の障害処理部２４は、CGF３０へData Record Transfer RequestをCGF３０へ送信し（Ｓ１０１）、応答メッセージであるData Record Transfer Responseの受信待ちタイマを設定する（Ｓ１０２）。
【0053】
その後、応答メッセージが未受信かつ受信待ちタイマが満了となった場合（Ｓ１０３：Ｙｅｓ）、障害処理部２４は、Data Record Transfer RequestをCGF３０へ送信し（Ｓ１０４）、応答メッセージであるData Record Transfer Responseの受信待ちタイマを設定する（Ｓ１０５）。
【0054】
そして、応答メッセージが未受信かつ受信待ちタイマが満了かつ再送回数が満了となった場合（Ｓ１０６：Ｙｅｓ）、障害処理部２４は、CGF３０との間の障害発生を検出する（Ｓ１０７）。その後、障害処理部２４は、障害発生中にCDR生成部２２による生成されるCDRを退避ＤＢ１３に退避させる（Ｓ１０８）。
【0055】
そして、障害処理部２４は、定期的にCGF３０に、Echo Requestを送信する（Ｓ１０９）。ここで、障害処理部２４は、Node Alive RequestをCGF３０から受信すると（Ｓ１１０：Ｙｅｓ）、障害復旧を検出する（Ｓ１１１）。続いて、障害処理部２４は、Node Alive ResponseをCGF３０へ送信した後（Ｓ１１２）、Data Record Transfer Request（空パケット）をCGF３０へ送信する（Ｓ１１３）。この結果、通常時とは別のGTPコネクションが確立される。
【0056】
一方、障害処理部２４は、Echo ResponseをCGF３０から受信すると（Ｓ１１４：Ｙｅｓ）、障害復旧を検出する（Ｓ１１５）。続いて、障害処理部２４は、Data Record Transfer Request（空パケット）をCGF３０へ送信する（Ｓ１１６）。この結果、通常時とは別のGTPコネクションが確立される。
【0057】
（CGF３０のフローチャート）
図６は、実施例１にかかるCGF３０の障害発生時の全体的な処理の流れを示すフローチャートである。CGF３０は、自動または保守者手動で退避されたCDRを収集することを可能とする。なお、ここでは、システム障害時のフローと通信障害時のフローとをあわせて説明するが、これに限定されるものではなく、別々のフローを用いて判定することもできる。
図６は、実施例１にかかるCGF３０の障害発生時の全体的な処理の流れを示すフローチャートである。CGF３０は、自動または保守者手動で退避されたCDRを収集することを可能とする。なお、ここでは、システム障害時のフローと通信障害時のフローとをあわせて説明するが、これに限定されるものではなく、別々のフローを用いて判定することもできる。
【0058】
図６に示すように、CGF３０の通常処理部５０は、CDFG１０からData Record Transfer Requestを受信すると（Ｓ２０１）、CDRをCDR格納ＤＢ３３に格納し、Data Record Transfer ResponseをCDF１０へ送信する（Ｓ２０２）。
【0059】
その後、CGF３０の障害処理部６０は、Data Record Transfer RequestをCDF１０から受信できない場合（Ｓ２０３：Ｙｅｓ）、通信障害を検出する（Ｓ２０４）。その後、障害処理部６０は、Echo RequestをCDF１０から受信すると（Ｓ２０５：Ｙｅｓ）、障害復旧を検出し（Ｓ２０６）、Echo ResponseをCDF１０へ送信する（Ｓ２０７）。
【0060】
その後、障害処理部６０は、Data Record Transfer Request（空パケット）をCDF１０から受信すると（Ｓ２０８：Ｙｅｓ）、Data Record Transfer ResponseをCDF１０へ送信する（Ｓ２０９）。
【0061】
そして、障害処理部６０は、退避CDRが存在する場合（Ｓ２１０：Ｙｅｓ）、退避用のGTPコネクションの確立等を含む退避処理を実行し（Ｓ２１１）、退避CDRが存在しない場合（Ｓ２１０：Ｎｏ）、処理を終了する。
【0062】
一方、CGF３０の通常処理部５０は、CDFG１０からData Record Transfer Requestを受信すると（Ｓ２１２）、通常処理を実行する。その後、CGF３０でシステム障害が発生したとする（Ｓ２１３）。
【0063】
そして、システム障害が復旧すると（Ｓ２１４：Ｙｅｓ）、障害処理部６０は、Node Alive RequestをCDF１０へ送信し（Ｓ２１５）、Node Alive ResponseをCDF１０から受信すると（Ｓ２１６）、Ｓ２０８以降を実行する。
【0064】
［シーケンス図（通信障害）］
図７は、実施例１にかかる通信障害時の流れを示すシーケンス図である。図７に示すように、CDF１０とCGF３０との間で通信障害が発生し（Ｓ３０１）、その後に障害復旧して（Ｓ３０２）、通信可能となったとする。
図７は、実施例１にかかる通信障害時の流れを示すシーケンス図である。図７に示すように、CDF１０とCGF３０との間で通信障害が発生し（Ｓ３０１）、その後に障害復旧して（Ｓ３０２）、通信可能となったとする。
【0065】
すると、CDF１０は、障害の間に再送を繰り返していたEcho RequestをCGF３０に送信する（Ｓ３０３とＳ３０４）。障害復旧により、このEcho Requestを受信したCGF３０の通常処理部５０は、Echo ResponseをCDF１０に応答する（Ｓ３０５とＳ３０６）。
【0066】
続いて、CDF１０の障害処理部２４は、Data Record Transfer Request（空パケット）をCGF３０に送信する（Ｓ３０７とＳ３０８）。その際、オプションIE（Information Element）であるSave CDR Information IEを設定することで、退避CDRが存在することをCGF３０に通知する。図８は、Data Record Transfer Requestのフォーマット例を示す図である。図８に示すように、Data Record Transfer Requestに、IE（Information Element）として、Packet Transfer Commandなどの既存の項目に加えて、新たに「Save CDR Information」を追加する。CGF３０は、この「Save CDR Information」がData Record Transfer Requestに設定されている場合、退避CDRが存在することを検出できる。なお、「Save CDR Information」は、８ビットのTypeによって指定することができる。
【0067】
その後、CDF１０とCGF３０との間で通常のGTPコネクションが再確立されて、障害発生後の生成されたCDRの送信が、通常のGTPコネクションを介して実行される（Ｓ３０９）。
【0068】
この通常処理と並行して、CGF３０の障害処理部６０は、退避用のコネクション要求をCDF１０に送信し（Ｓ３１０とＳ３１１）、CDF１０の障害処理部２４は、コネクション要求に対する応答をCGF３０に送信する（Ｓ３１２とＳ３１３）。この結果、CGF３０の障害処理部６０は、CDF１０との間で、退避用GTPコネクションを確立する（Ｓ３１４）。
【0069】
続いて、CGF３０の障害処理部６０は、CDF１０に対し、Redirection Requestを送信する（Ｓ３１５とＳ３１６）。このとき、当該メッセージのCause IEに「Saved CDR transfer request」を設定し、CDF１０に対し退避CDRの転送を要求する。図９は、Redirection Requestのフォーマット例を示す図である。図９に示すように、Redirection Requestの設定として、Address of Recommended Nodeなどの既存の項目に加えて、新たに「Saved CDR transfer request」を追加する。CDF１０は、この「Saved CDR transfer request」がRedirection Requestに設定されていることによって、退避CDRの要求を検出することができる。
【0070】
そして、CDF１０の障害処理部２４は、CGF３０からのRedirection Requestの応答として、Redirection ResponseをCGF３０に送信する（Ｓ３１７とＳ３１８）。このとき、Cause IEに「Request Accepted」が設定される。また、CDF１０は、退避用CDR転送のためのシーケンス番号を管理する。
【0071】
その後、CDF１０の障害処理部２４は、退避していたCDR（退避CDR）を、退避用のGTPコネクションを介してCGF３０に送信する（Ｓ３１９とＳ３２０）。このとき、CDF１０は、CGF３０に、Packet Transfer Command IEに「Send Data Record Packet」を設定したData Record Transfer Requestを送信し、CDR（退避CDR）を転送する。図１０は、Data Record Transfer Requestのフォーマット例を示す図である。図１０に示すように、Data Record Transfer Requestの「Packet Transfer Command IE」には、１（Send Data Record Packet）などの４つの情報を指定できる。
【0072】
その後、CGF３０の障害処理部６０は、受信したCDRを記憶部３２のCDR格納ＤＢ３３に格納し（Ｓ３２１とＳ３２２）、受信応答のメッセージとしてData Record Transfer ResponseをCDF１０に送信する（Ｓ３２３とＳ３２４）。このとき、Data Record Transfer ResponseのメッセージのCause IEに「Request Accepted」が設定される。図１１は、Data Record Transfer Responseのフォーマット例を示す図である。図１１に示すように、Data Record Transfer Responseの「Cause」に、既存の「Request Accepted」を設定して、CDFへ送信される。
【0073】
そして、Data Record Transfer Responseメッセージを受信したCDF１０の障害処理部２４は、退避ＤＢ１３から転送済みの退避CDRを削除する（Ｓ３２５）。このようにして、退避されていたCDR（退避CDR）の転送が、退避用GTPコネクションを用いて実行される。
【0074】
その後、CDF１０の障害処理部２４は、最後の退避CDRを送信するとき、Data Record Transfer RequestのPacket Transfer Command IEに「Last Send Data Record Packet」を設定し、CGF３０に終了を通知する（Ｓ３２６とＳ３２７）。図１１に示すように、Data Record Transfer Requestの「Packet Transfer Command IE」には、１から４の既存の情報に加えて、新たに５（Last Send Data Record Packet）を追加する。
【0075】
続いて、CGF３０の障害処理部６０は、受信したCDRを記憶部３２のCDR格納ＤＢ３３に格納し（Ｓ３２８とＳ３２９）、受信応答のメッセージとしてData Record Transfer ResponseをCDF１０に送信する（Ｓ３３０とＳ３３１）。このとき、Data Record Transfer ResponseのメッセージのCause IEに「Request Accepted」が設定される。CGF３０で管理される、退避CDR用のインスタンスデータ（シーケンス番号など）は、ここで解放される。
【0076】
その後、Data Record Transfer Responseメッセージを受信したCDF１０の障害処理部２４は、退避ＤＢ１３から転送済みの最後の退避CDRを削除する（Ｓ３３２）。そして、CGF３０の障害処理部６０は、退避用GTPコネクションを切断し、リソースを解放する（Ｓ３３３とＳ３３４）。
【0077】
［シーケンス図（システム障害）］
図１２は、実施例１にかかるシステム障害時の流れを示すシーケンス図である。図１２に示すように、CGF３０にシステム障害が発生してCDF１０とCGF３０との通信が遮断され（Ｓ４０１）、その後に障害復旧して（Ｓ４０２）、通信可能となったとする。
図１２は、実施例１にかかるシステム障害時の流れを示すシーケンス図である。図１２に示すように、CGF３０にシステム障害が発生してCDF１０とCGF３０との通信が遮断され（Ｓ４０１）、その後に障害復旧して（Ｓ４０２）、通信可能となったとする。
【0078】
すると、CGF３０の通常処理部５０は、Node Alive RequestのメッセージをCDF１０に送信し（Ｓ４０３とＳ４０４）、CDF１０は、応答として、Node Alive ResponseをCGF３０に送信する（Ｓ４０５とＳ４０６）。ここで、オプションIEであるSave CDR Information IEを設定することで、退避CDRが存在することをCGF３０に通知することもできる。図１３は、Node Alive Responseのフォーマット例を示す図である。図１３に示すように、Node Alive responseに、IE（Information Element）として、Node Addressなどの既存の項目に加えて、新たに「Save CDR Information」を追加する。CGF３０は、この「Save CDR Information」がNode Alive responseに設定されている場合、退避CDRが存在することを検出できる。
【0079】
その後、CDF１０の障害処理部２４は、Data Record Transfer Request（空パケット）をCGF３０に送信する（Ｓ４０７とＳ４０８）。その際、Ｓ４０５の代わりに、図７と同様、オプションIEであるSave CDR Information IEを設定することで、退避CDRが存在することをCGFに通知することもできる。
【0080】
その後、CDF１０とCGF３０との間で通常のGTPコネクションが再確立されて、障害発生後の生成されたCDRの送信が、通常のGTPコネクションを介して実行される（Ｓ４０９）。
【0081】
この通常処理と並行して、CGF３０の障害処理部６０は、退避用のコネクション要求をCDF１０に送信し（Ｓ４１０とＳ４１１）、CDF１０の障害処理部２４は、コネクション要求に対する応答をCGF３０に送信する（Ｓ４１２とＳ４１３）。この結果、CGF３０の障害処理部６０は、CDF１０との間で、退避用GTPコネクションを確立する（Ｓ４１４）。
【0082】
続いて、CGF３０の障害処理部６０は、CDF１０に対し、Redirection Requestを送信する（Ｓ４１５とＳ４１６）。このとき、当該メッセージのCause IEに「Saved CDR transfer Request」を設定し、CDF１０に対し退避CDR３０の転送を要求する。
【0083】
そして、CDF１０の障害処理部２４は、CGF３０からのRedirection Requestの応答として、Redirection ResponseをCGF３０に送信する（Ｓ４１７とＳ４１８）。このとき、Cause IEに「Request Accepted」が設定される。また、CDF１０は、退避用CDR転送のためのシーケンス番号を管理する。
【0084】
その後、CDF１０の障害処理部２４は、退避していたCDR（退避CDR）を、退避用GTPコネクションを介してCGF３０に送信する（Ｓ４１９とＳ４２０）。このとき、CDF１０は、CGF３０に、Packet Transfer Command IEに「Send Data Record Packet」を設定したData Record Transfer Requestを送信し、CDR（退避CDR）を転送する。
【0085】
その後、CGF３０の障害処理部６０は、受信したCDRを記憶部３２のCDR格納ＤＢ３３に格納し（Ｓ４２１とＳ４２２）、受信応答のメッセージとしてData Record Transfer ResponseをCDF１０に送信する（Ｓ４２３とＳ４２４）。このとき、Data Record Transfer ResponseのメッセージのCause IEに「Request Accepted」が設定される。
【0086】
そして、Data Record Transfer Responseメッセージを受信したCDF１０の障害処理部２４は、退避ＤＢ１３から転送済みの退避CDRを削除する（Ｓ４２５）。このようにして、退避されていたCDR（退避CDR）の転送が、退避用GTPコネクションを用いて実行される。なお、その後の処理は、図７と同様なので、詳細な説明は省略する。
【0087】
［効果］
上述したように、CDF１０とCGF３０との間の通信障害が復旧した際、CDF１０は、CDRが退避されていることをCGF３０へ通知する。CGF３０は、自動で退避されたCDRを収集することができる。このとき、退避されたCDRの収集は、通常のCDR転送用のGTPトンネルを使用せず、CGF３０より新たにCDF１０へGTPトンネルを作成し、GTP’プロトコルを用いることでnear real timeなCDR転送に影響することなく、自動的に並列転送が可能となる。すなわち、3GPPオフライン課金アーキテクチャのGa参照ポイントにおけるCDR転送方式（GTP’プロトコル）を新たに定義し、通信障害からの復旧の際に、新規に発生するCDRのnear real time転送に影響を与えずにCGF３０に転送することができる。
上述したように、CDF１０とCGF３０との間の通信障害が復旧した際、CDF１０は、CDRが退避されていることをCGF３０へ通知する。CGF３０は、自動で退避されたCDRを収集することができる。このとき、退避されたCDRの収集は、通常のCDR転送用のGTPトンネルを使用せず、CGF３０より新たにCDF１０へGTPトンネルを作成し、GTP’プロトコルを用いることでnear real timeなCDR転送に影響することなく、自動的に並列転送が可能となる。すなわち、3GPPオフライン課金アーキテクチャのGa参照ポイントにおけるCDR転送方式（GTP’プロトコル）を新たに定義し、通信障害からの復旧の際に、新規に発生するCDRのnear real time転送に影響を与えずにCGF３０に転送することができる。
【0088】
この結果、Ga参照ポイントのCDR転送に影響を与えずに、通信障害中に退避されたCDRの転送を実現することが可能となり、CDRが欠損することなく自動で自動的に収集できる。また、Bxフォーマットに変換後に、BDに転送することができる。また、CGF３０主導で退避CDRの収集を行うことで、保守者に柔軟な選択を提供することができる。
【0089】
ここで、通信障害中に退避されるCDRの数から、退避されたCDRを一般的なプロトコル規定で転送した場合のCDRの転送遅延時間を算出し、実施例１と一般技術とを対比する。まず、算出条件として、１時間あたりに生成されるCDR数を「1,800,000［CDR／H］」、通信障害が発生した時間は５分間、Ga参照ポイントで１分間に転送できるCDRの数を「60,000［CDR］」とする。
【0090】
このような条件で、退避されたCDRを一般的なプロトコル規定で転送した場合のリアルタイムに生成されたCDRの転送遅延時間を算出する。通信障害が５分間発生しているので、退避されたCDR数は、1,800,000［CDR］／60［分］×5［分］＝150,000［CDR］・・・（１）となる。続いて、１分間に転送できるCDR数は、60,000［CDR］なので、（１）の全退避CDRの転送にかかる時間は、150,000［CDR］／60,000［CDR］＝ 2分30秒・・・（２）となる。また、（２）の退避CDRを転送している時間に生成される新たなCDR数は、1,800,000［CDR］／60［分］×2.5［分］＝75,000［CDR］・・・（３）となる。
【0091】
そして、（３）のCDRの転送にかかる時間は、75,000［CDR］／60,000［CDR］＝1分15秒・・・（４）となる。さらに、（４）のCDRを転送している時間に新たに生成されるCDR数は、1,800,000［CDR］／60［分］×1.25［分］＝37,500［CDR］・・・（５）となり、（５）のCDRの転送にかかる時間は、37,500［CDR］／60,000［CDR］＝40秒・・・（６）となる。さらに、（６）のCDRを転送している時間に新たに生成されるCDR数は、1,800,000［CDR］／60［分］×0.63［分］＝18,750［CDR］・・・（７）となり、（７）のCDRの転送にかかる時間は、18,750［CDR］／60,000［CDR］＝20秒・・・（８）となる。そして、（８）のCDRを転送している時間に新たに生成されるCDR数は、1,800,000［CDR］／60［分］×0.31［分］＝9,375［CDR］となる。
【0092】
このように、最終的にリアルタイムに転送できるようになるまでの時間は、（２）＋（４）＋（６）＋（８）＋α（約２０秒）＝約５分となる。つまり、障害復旧後から約５分後に、新たに生成されるCDRのリアルタイム転送が可能となり、約５分の間に生成されるCDRについては３GPPの制約を遵守できない恐れが高い。これに対して、実施例１による手法では、新規のCDRと退避CDRとを別々のコネクションで送信することができるので、一般的なプロトコルによる送信遅延を改善することができる。
【実施例2】
【0093】
ところで、課金アーキテクチャでは、CGF３０としてプライマリ（運用系）とセカンダリ（待機系）を用意することで、CGF30を冗長化することもある。この場合、通常時は使用されない空きリソースであるセカンダリのCGFを用いることで、一般的なプロトコルによる送信遅延を改善することができる。
【0094】
そこで、実施例２では、CGF冗長化システムを例にして、退避CDRの転送を説明する。ここでは、プライマリとしてCGF３０、セカンダリとしてCGF８０を用いるが、CGF８０は、CGF３０と同様の機能構成を有するものとする。
【0095】
［シーケンス図（通信障害）］
図１４は、実施例２にかかるCGF冗長化システムにおける通信障害時の流れを示すシーケンス図である。図１４に示すように、CDF１０と各CGF（CGF３０、CGF８０）との間で通信障害が発生し（Ｓ５０１）、その後に障害復旧して（Ｓ５０２）、通信可能となったとする。
図１４は、実施例２にかかるCGF冗長化システムにおける通信障害時の流れを示すシーケンス図である。図１４に示すように、CDF１０と各CGF（CGF３０、CGF８０）との間で通信障害が発生し（Ｓ５０１）、その後に障害復旧して（Ｓ５０２）、通信可能となったとする。
【0096】
すると、CDF１０は、障害の間に再送を繰り返していたEcho RequestをCGF３０に送信する（Ｓ５０３とＳ５０４）。障害復旧により、このEcho Requestを受信したCGF３０は、Echo RequestをCDF１０に応答する（Ｓ５０５とＳ５０６）。
【0097】
続いて、CDF１０は、Data Record Transfer Request（空パケット）をCGF３０に送信する（Ｓ５０７とＳ５０８）。この結果、CDF１０とプライマリであるCGF３０との間で通常のGTPコネクションが再確立されて、障害発生後の生成されたCDRの送信が、通常のGTPコネクションを介して実行される（Ｓ５０９）。
【0098】
CDF１０は、プライマリのCGF３０への上記処理と並行して、Echo RequestをセカンダリのCGF８０に送信する（Ｓ５１０とＳ５１１）。障害復旧により、このEcho Requestを受信したCGF８０は、Echo ResponseをCDF１０に応答する（Ｓ５１２とＳ５１３）。
【0099】
続いて、CDF１０は、Data Record Transfer Request（空パケット）をCGF８０に送信する（Ｓ５１４とＳ５１５）。その際、オプションIEであるSave CDR Information IEを設定することで、退避CDRが存在することをCGFに通知する。
【0100】
そして、CGF８０は、Data Record Transfer Requestの応答として、リクエスト受信応答であるData Record Transfer ResponseをCDF１０に送信する（Ｓ５１６とＳ５１７）。このとき、Cause IEに「Request Accepted」が設定される。
【0101】
その後、CGF８０は、退避用のコネクション要求をCDF１０に送信し（Ｓ５１８とＳ５１９）、CDF１０は、コネクション要求に対する応答をCGF８０に送信する（Ｓ５２０とＳ５２１）。この結果、CDF１０とセカンダリであるCGF８０との間で、退避用GTPコネクションが確立される（Ｓ５２２）。
【0102】
続いて、CGF８６０は、CDF１０に対し、Redirection Requestを送信する（Ｓ５２３とＳ５２４）。このとき、当該メッセージのCause IEに「Saved CDR transfer Request」を設定し、CDF１０に対し退避CDRの転送を要求する。
【0103】
そして、CDF１０は、CGF８０からのRedirection Requestの応答として、Redirection ResponseをCGF８０に送信する（Ｓ５２５とＳ５２６）。このとき、Cause IEに「Request Accepted」が設定される。また、CDF８０は、退避用CDR転送のためのシーケンス番号を管理する。
【0104】
その後、CDF１０は、退避していたCDR（退避CDR）を、退避用のGTPコネクションを介してCGF８０に送信する（Ｓ５２７とＳ５２８）。このとき、CDF１０は、CGF８０に、Packet Transfer Command IEに「Send Data Record Packet」を設定したData Record Transfer Requestを送信し、CDR（退避CDR）を転送する。
【0105】
その後、CGF８０は、受信したCDRを記憶部に格納し（Ｓ５２９）、受信応答のメッセージとしてData Record Transfer ResponseをCDF１０に送信する（Ｓ５３０とＳ５３１）。このとき、Data Record Transfer ResponseのメッセージのCause IEに「Request Accepted」が設定される。
【0106】
そして、Data Record Transfer Responseメッセージを受信したCDF１０は、退避ＤＢ１３から転送済みの退避CDRを削除する（Ｓ５３２）。このようにして、退避されていたCDR（退避CDR）が、退避用のGTPコネクションを用いてセカンダリのCGF８０に転送される。
【0107】
その後、CDF１０は、最後の退避CDRを送信するとき、Data Record Transfer RequestのPacket Transfer Command IEに「Last Send Data Record Packet」を設定し、CGF８０に終了を通知する（Ｓ５３３とＳ５３４）。
【0108】
続いて、CGF８０は、受信したCDRを記憶部に格納し（Ｓ５３５）、受信応答のメッセージとしてData Record Transfer ResponseをCDF１０に送信する（Ｓ５３６とＳ５３７）。このとき、Data Record Transfer ResponseのメッセージのCause IEに「Request Accepted」が設定される。
【0109】
その後、Data Record Transfer Responseメッセージを受信したCDF１０は、退避ＤＢ１３から転送済みの最後の退避CDRを削除する（Ｓ５３８）。そして、CGF８０は、退避用のGTPコネクションを切断し、リソースを解放する（Ｓ５３９とＳ５４０）。
【0110】
［シーケンス図（システム障害）］
図１５は、実施例２にかかるCGF冗長化システムにおけるシステム障害時の流れを示すシーケンス図である。図１５に示すように、CGF３０にシステム障害が発生してCDF１０とCGF３０との通信が遮断され（Ｓ６０１とＳ６０２）、その後に障害復旧して（Ｓ６０３）、通信可能となったとする。
図１５は、実施例２にかかるCGF冗長化システムにおけるシステム障害時の流れを示すシーケンス図である。図１５に示すように、CGF３０にシステム障害が発生してCDF１０とCGF３０との通信が遮断され（Ｓ６０１とＳ６０２）、その後に障害復旧して（Ｓ６０３）、通信可能となったとする。
【0111】
すると、CGF３０は、Node Alive RequestのメッセージをCDF１０に送信し（Ｓ６０４とＳ６０５）、CDF１０は、応答として、Node Alive ResponseをCGF３０に送信する（Ｓ６０６とＳ６０７）。
【0112】
その後、CDF１０は、Data Record Transfer Request（空パケット）をCGF３０に送信する（Ｓ６０８とＳ６０９）。このようにして、CDF１０とCGF３０との間で通常のGTPコネクションが再確立されて、障害発生後の生成されたCDRの送信が、通常のGTPコネクションを介して実行される（Ｓ６１０）。
【0113】
プライマリのCGF３０への上記処理と並行して、CGF８０は、Node Alive RequestのメッセージをCDF１０に送信し（Ｓ６１１とＳ６１２）、CDF１０は、応答として、Node Alive ResponseをCGF３０に送信する（Ｓ６１３とＳ６１４）。ここで、CDF１０は、Node Alive Responseに「Save CDR Information」を設定することで、退避CDRが存在することをCGF８０に通知する。
【0114】
その後、GF８０は、退避用のコネクション要求をCDF１０に送信し（Ｓ６１５とＳ６１６）、CDF１０は、コネクション要求に対する応答をCGF８０に送信する（Ｓ６１７とＳ６１８）。この結果、CGF８０は、CDF１０との間で、退避用のGTPコネクションを確立する（Ｓ６１９）。なお、その後の処理は、図１４と同様なので、詳細な説明は省略する。
【0115】
このように、冗長化構成されているセカンダリのCGF８０を利用することで、プライマリであるCGF３０の処理負荷が高くなることを抑制でき、通常業務の影響を極小化し、CGF３０の故障発生や処理遅延発生を抑制することができる。なお、実施例２では、CDF１０とプライマリであるCGF８０との間で、退避用のGTPコネクションを確立する例を説明したが、これに限定されるものではない。例えば、CGF３０の縮退時用としてCDF１０とCGF８０との間で通常時から確立されるGTPコネクションを用いて、CDF１０からCGF８０へ退避CDRを転送することもできる。
【実施例3】
【0116】
ところで、退避されていたCDRの転送は、保守者のタイミングで実行することもできる。そこで、実施例３では、保守者が使用する保守端末９０が主導で、退避されていたCDRの取得などの各種処理を実行する例を説明する。なお、ここでは、一例として、通信障害を例にして説明すると、システム障害や冗長化構成であっても同様に処理することができる。
【0117】
［シーケンス図（通信障害）］
図１６は、実施例３にかかる保守端末主導による通信障害時の流れを示すシーケンス図である。図１６に示すように、CDF１０とCGF３０との間で通信障害が発生し（Ｓ７０１）、その後に障害復旧して（Ｓ７０２）、通信可能となったとする。
図１６は、実施例３にかかる保守端末主導による通信障害時の流れを示すシーケンス図である。図１６に示すように、CDF１０とCGF３０との間で通信障害が発生し（Ｓ７０１）、その後に障害復旧して（Ｓ７０２）、通信可能となったとする。
【0118】
すると、CDF１０は、障害の間に再送を繰り返していたEcho RequestをCGF３０に送信する（Ｓ７０３とＳ７０４）。障害復旧により、このEcho Requestを受信したCGF３０は、Echo ResponseをCDF１０に応答する（Ｓ７０５とＳ７０６）。
【0119】
続いて、CDF１０は、Data Record Transfer Request（空パケット）をCGF３０に送信する（Ｓ７０７とＳ７０８）。その際、CDF１０は、オプションIEであるSave CDR Information IEを設定することで、退避CDRが存在することをCGF３０に通知する。この結果、CDF１０とCGF３０との間で通常のGTPコネクションが再確立されて、障害発生後の生成されたCDRの送信が、通常のGTPコネクションを介して実行される（Ｓ７０９）。
【0120】
その後、保守端末９０は、CGF３０に、退避CDRの収集要求を送信する（Ｓ７１０とＳ７１１）。この要求を受信したCGF３０の障害処理部６０は、退避用のコネクション要求をCDF１０に送信し（Ｓ７１２とＳ７１３）、CDF１０は、コネクション要求に対する応答をCGF３０に送信する（Ｓ７１４とＳ７１５）。この結果、CGF３０の障害処理部６０は、CDF１０との間で、退避用のGTPコネクションを確立する（Ｓ７１６）。その後の処理は、実施例１の図７と同様なので、詳細な説明は省略する。
【0121】
なお、CGF３０の障害処理部６０は、退避用のGTPコネクションを切断してリソースを解放した後（Ｓ７１７とＳ７１８）、退避CDRの収集終了通知（正常）を保守端末９０に送信する（Ｓ７１９とＳ７２０）。
【0122】
［シーケンス図（退避CDRなし）］
図１７は、実施例３にかかる保守端末主導時に退避CDRがない場合の処理の流れを示すシーケンス図である。図１７に示すように、CDF１０とCGF３０との間で発生した通信障害が復旧し、通常処理が実行されているものとする（Ｓ８０１）。
図１７は、実施例３にかかる保守端末主導時に退避CDRがない場合の処理の流れを示すシーケンス図である。図１７に示すように、CDF１０とCGF３０との間で発生した通信障害が復旧し、通常処理が実行されているものとする（Ｓ８０１）。
【0123】
その後、保守端末９０は、CGF３０に、退避CDRの収集要求を送信する（Ｓ８０２とＳ８０３）。この要求を受信したCGF３０の障害処理部６０は、退避用のコネクション要求をCDF１０に送信し（Ｓ８０４とＳ８０５）、CDF１０は、コネクション要求に対する応答をCGF３０に送信する（Ｓ８０６とＳ８０７）。この結果、CGF３０の障害処理部６０は、CDF１０との間で、退避用のGTPコネクションを確立する（Ｓ８０８）。
【0124】
続いて、CGF３０の障害処理部６０は、CDF１０に対し、Redirection Requestを送信する（Ｓ８０９とＳ８１０）。このとき、当該メッセージのCause IEに「Saved CDR transfer Request」を設定し、CDF１０に対し退避CDR３０の転送を要求する。
【0125】
そして、CDF１０の障害処理部２４は、CGF３０からのRedirection Requestの応答として、Redirection ResponseをCGF３０に送信する（Ｓ８１１とＳ８１２）。このとき、障害処理部２４は、退避CDRが存在しないことから、Cause IEに「CDR does not exist」を設定する。なお、Redirection Responseの設定として、既存の項目に加えて、新たに「CDR does not exist」を追加する。CGF３０は、この「CDR does not exist」がRedirection Responseに設定されていることによって、退避CDRがないことを検出することができる。
【0126】
この結果、CGF３０の障害処理部６０は、退避用のGTPコネクションを切断してリソースを解放し（Ｓ８１３とＳ８１４）、退避CDRの収集終了通知（退避CDRなし）を保守端末９０に送信する（Ｓ８１５とＳ８１６）。
【0127】
［シーケンス図（退避CDRの削除）］
図１８は、実施例３にかかる保守端末主導による退避CDRの削除時の流れを示すシーケンス図である。図１８に示すように、CDF１０とCGF３０との間で発生した通信障害が復旧し、通常処理が実行されているものとする（Ｓ９０１）。
図１８は、実施例３にかかる保守端末主導による退避CDRの削除時の流れを示すシーケンス図である。図１８に示すように、CDF１０とCGF３０との間で発生した通信障害が復旧し、通常処理が実行されているものとする（Ｓ９０１）。
【0128】
その後、保守端末９０は、CGF３０に、退避CDRの削除要求を送信する（Ｓ９０２とＳ９０３）。この要求を受信したCGF３０の障害処理部６０は、退避用のコネクション要求をCDF１０に送信し（Ｓ９０４とＳ９０５）、CDF１０は、コネクション要求に対する応答をCGF３０に送信する（Ｓ９０６とＳ９０７）。この結果、CGF３０の障害処理部６０は、CDF１０との間で、退避用のGTPコネクションを確立する（Ｓ９０８）。
【0129】
続いて、CGF３０の障害処理部６０は、CDF１０に対し、Redirection Requestを送信する（Ｓ９０９とＳ９１０）。このとき、当該メッセージのCause IEに「Saved CDR delete request」を設定し、CDF１０に対し退避CDR３０の削除を要求する。なお、図９に示すように、Redirection Requestの設定として、Address of Recommended Nodeなどの既存の項目に加えて、新たに「Saved CDR delete request」を追加する。CDF１０は、この「Saved CDR delete request」がRedirection Requestに設定されていることによって、退避CDRの削除要求を検出することができる。
【0130】
そして、CDF１０の障害処理部２４は、CGF３０からのRedirection Requestに「Saved CDR delete request」が設定されていることにより、退避ＤＢ１３に退避していた退避CDRを、CGF３０へ送信することなく削除する（Ｓ９１１）。
【0131】
その後、CDF１０の障害処理部２４は、「Request Accepted」が設定されたRedirection ResponseをCGF３０に送信する（Ｓ９１２とＳ９１３）。そして、CGF３０の障害処理部６０は、退避用のGTPコネクションを切断してリソースを解放し（Ｓ９１４とＳ９１５）、退避CDRの削除終了通知（正常）を保守端末９０に送信する（Ｓ９１６とＳ９１７）。
【0132】
［効果］
上述したように、CGF３０主導で退避CDRの収集を行うことで、退避CDRの取得や削除などのサービスを提供することができる結果、保守者は、障害状況や契約状況等に基づく柔軟な対応を選択することができる。また、柔軟な対応の提供により、汎用性が向上し、システムの普及も期待できる。
上述したように、CGF３０主導で退避CDRの収集を行うことで、退避CDRの取得や削除などのサービスを提供することができる結果、保守者は、障害状況や契約状況等に基づく柔軟な対応を選択することができる。また、柔軟な対応の提供により、汎用性が向上し、システムの普及も期待できる。
【実施例4】
【0133】
ところで、障害復旧後の退避CDRの送信中に新たな障害が発生し、退避CDRの送信エラーが発生することも考えられる。そこで、実施例４では、退避CDRの送信エラー時の対応例を説明する。
【0134】
［送信エラー］
図１９は、実施例４にかかる障害復旧後の送信エラー時の流れを示すシーケンス図である。図１９に示すように、Ｓ１００１からＳ１０１４までの処理は、図７のＳ３１０からＳ３１４までの処理と同様なので、詳細な説明は省略する。
図１９は、実施例４にかかる障害復旧後の送信エラー時の流れを示すシーケンス図である。図１９に示すように、Ｓ１００１からＳ１０１４までの処理は、図７のＳ３１０からＳ３１４までの処理と同様なので、詳細な説明は省略する。
【0135】
退避用のGTPコネクションが確立されると、CGF３０の障害処理部６０は、CDF１０に対し、「Saved CDR transfer request」を設定したRedirection Requestを送信する（Ｓ１０１５とＳ１０１６）。
【0136】
そして、CDF１０は、CGF３０からのRedirection Requestの応答として、「Request Accepted」を設定したRedirection Responseを、CGF３０の障害処理部６０に送信する（Ｓ１０１７とＳ１０１８）。
【0137】
その後、CDF１０は、シーケンシャル番号１（Seq：１）の退避CDRに該当するData Record Transfer Requestに、「Send Data Record Packet」を設定し、退避用のGTPコネクションを介して、障害処理部６０に送信する（Ｓ１０１９とＳ１０２０）。ところが、転送途中で通信障害が発生し、CGF３０の障害処理部６０はシーケンシャル番号１の退避CDRを受信できない。このため、CGF３０の障害処理部６０は、CDF１０に、応答であるData Record Transfer Responseを送信できない。
【0138】
そして、障害が復旧すると（Ｓ１０２１）、CDF１０は、シーケンシャル番号１（Seq：１）のData Record Transfer Requestの受信応答を受信していないことから、退避用のGTPコネクションを介して、シーケンシャル番号１（Seq：１）の退避CDR（Data Record Transfer Request）を、CGF３０の障害処理部６０に再度送信する（Ｓ１０２２とＳ１０２３）。このときのData Record Transfer Requestにも「Send Data Record Packet」が設定される。
【0139】
その後、CGF３０の障害処理部６０は、受信したシーケンシャル番号１の退避CDRを記憶部３２のCDR格納ＤＢ３３に格納し（Ｓ１０２４とＳ１０２５）、受信応答のメッセージとしてData Record Transfer ResponseをCDF１０に送信する（Ｓ１０２６とＳ１０２７）。
【0140】
そして、Data Record Transfer Responseメッセージを受信したCDF１０は、退避ＤＢ１３から、転送済みであるシーケンシャル番号１の退避CDRを削除する（Ｓ１０２８）。このようにして、退避されていたCDR（退避CDR）の転送が、退避用のGTPコネクションを用いて実行される。その後のシーケンシャル番号：２以降の送信処理については、図７のＳ３１９からＳ３３４と同様なので、詳細な説明は省略する。
【0141】
［応答エラー］
図２０は、実施例４にかかる障害復旧後の応答エラー時の流れを示すシーケンス図である。図２０に示すように、Ｓ２００１からＳ２０１４までの処理は、図７のＳ３１０からＳ３１４までの処理と同様なので、詳細な説明は省略する。
図２０は、実施例４にかかる障害復旧後の応答エラー時の流れを示すシーケンス図である。図２０に示すように、Ｓ２００１からＳ２０１４までの処理は、図７のＳ３１０からＳ３１４までの処理と同様なので、詳細な説明は省略する。
【0142】
退避用のGTPコネクションが確立されると、CGF３０の障害処理部６０は、CDF１０に対し、「Saved CDR transfer request」を設定したRedirection Requestを送信する（Ｓ２０１５とＳ２０１６）。
【0143】
そして、CDF１０は、CGF３０からのRedirection Requestの応答として、「Request Accepted」を設定したRedirection Responseを、CGF３０の障害処理部６０に送信する（Ｓ２０１７とＳ２０１８）。
【0144】
その後、CDF１０は、シーケンシャル番号１（Seq：１）の退避CDRに該当するData Record Transfer Requestに、「Send Data Record Packet」を設定し、退避用のGTPコネクションを介して、障害処理部６０に送信する（Ｓ２０１９とＳ２０２０）。
【0145】
続いて、CGF３０の障害処理部６０は、受信したCDRを記憶部３２のCDR格納ＤＢ３３に格納し（Ｓ２０２１とＳ２０２２）、受信応答のメッセージとして、「Request Accepted」を設定したData Record Transfer ResponseをCDF１０に送信する（Ｓ２０２３と２０２４）。ところが、転送途中で通信障害が発生し、CDF１０は、Data Record Transfer Responseを受信できない。
【0146】
そして、障害が復旧すると（Ｓ２０２５）、CDF１０は、シーケンシャル番号１（Seq：１）のData Record Transfer Requestの受信応答を受信していないことから、退避用のGTPコネクションを介して、シーケンシャル番号１（Seq：１）のCDR（Data Record Transfer Request）を、CGF３０の障害処理部６０に再度送信する（Ｓ２０２６とＳ２０２７）。このときのData Record Transfer Requestにも「Send Data Record Packet」が設定される。
【0147】
その後、CGF３０の障害処理部６０は、受信したシーケンシャル番号１の退避CDRがすでに受信済みであることから破棄し（Ｓ２０２８）、受信応答のメッセージとして、「Request already fulfilled」を設定したData Record Transfer ResponseをCDF１０に送信する（Ｓ２０２９とＳ２０３０）。
【0148】
その後のシーケンシャル番号：２以降の送信処理については、図７のＳ３１９からＳ３３４と同様なので、詳細な説明は省略する。
【0149】
［最後のCDRで送信エラー］
図２１は、実施例４にかかる退避CDRの最後でエラーが発生した時の流れを示すシーケンス図である。図２１に示すように、障害が発生してから最後の退避CDRを転送するまでの処理であるＳ３００１からＳ３０１１は、図７のＳ３０１からＳ３２５までの処理と同様なので、詳細な説明は省略する。
図２１は、実施例４にかかる退避CDRの最後でエラーが発生した時の流れを示すシーケンス図である。図２１に示すように、障害が発生してから最後の退避CDRを転送するまでの処理であるＳ３００１からＳ３０１１は、図７のＳ３０１からＳ３２５までの処理と同様なので、詳細な説明は省略する。
【0150】
その後、CDF１０は、最後のCDRである（Seq：Last）の退避CDRを退避CDRに該当するData Record Transfer Requestに、「Last Send Data Record Packet」を設定し、退避用のGTPコネクションを介して、障害処理部６０に送信する（Ｓ３０１２とＳ３０１３）。
【0151】
続いて、CGF３０の障害処理部６０は、受信した最後の退避CDRを記憶部３２のCDR格納ＤＢ３３に格納する（Ｓ３０１４とＳ３０１５）。ここで、CGF３０の障害処理部６０は、退避CDR用のインスタンスデータ（シーケンス番号など）を解放する。
【0152】
そして、CGF３０の障害処理部６０は、受信応答のメッセージとして、「Request Accepted」を設定したData Record Transfer ResponseをCDF１０に送信する（Ｓ３０１６とＳ３０１７）。ところが、転送途中で通信障害が発生し、CDF１０は、Data Record Transfer Responseを受信できない。
【0153】
そして、障害が復旧すると（Ｓ３０１８）、CDF１０は、シーケンシャル番号（Seq：Lat）のData Record Transfer Requestの受信応答を受信していないことから、退避用のGTPコネクションを介して、シーケンシャル番号（Seq：Last）のCDR（Data Record Transfer Request）を、CGF３０の障害処理部６０に再度送信する（Ｓ３０１９とＳ３０２０）。このときのData Record Transfer Requestにも「Last Send Data Record Packet」が設定される。
【0154】
その後、CGF３０の障害処理部６０は、受信したシーケンシャル番号１の退避CDRがすでに受信済みであることから破棄する（Ｓ３０２１）。そして、CGF３０の障害処理部６０は、退避CDR用のインスタンスデータが解放済みであることから、受信応答のメッセージとして、「Instance data already released」を設定したData Record Transfer ResponseをCDF１０に送信する（Ｓ３０２２とＳ３０２３）。なお、図１０に示すように、Data Record Transfer Requestの「Packet Transfer Command IE」には、１（Send Data Record Packet）などの４つの情報を以前から指定できるが、新たな項目として「Instance data already released」を設定する。
【0155】
その後、Data Record Transfer Responseメッセージを受信したCDF１０は、退避ＤＢ１３から転送済みの最後の退避CDRを削除する（Ｓ３０２４）。そして、CGF３０の障害処理部６０は、退避用のGTPコネクションを切断し、リソースを解放する（Ｓ３０２５とＳ３０２６）。なお、Ｓ３０１７からＳ３０１８までの障害発生中に新たに発生した退避CDRに対しては、Ｓ３０２５の前に、実施例１と同様の手法で転送処理が実行される。
【0156】
［効果］
上述したように、退避CDRの送信処理でエラーが発生した場合であっても、エラーのタイミングに関わらず、退避エラーの送信を遅滞なく実行することができるとともに、シーケンシャル番号を遵守して送信することができる。
上述したように、退避CDRの送信処理でエラーが発生した場合であっても、エラーのタイミングに関わらず、退避エラーの送信を遅滞なく実行することができるとともに、シーケンシャル番号を遵守して送信することができる。
【実施例5】
【0157】
さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。
【0158】
［対応指示の指定］
上記実施例では、退避CDRの削除を指定する例を説明したが、これに限定されるものではない。例えば、退避CDRの取得開始時間の指定、複数のCGFが存在する場合に転送先のCGFを指定するなど、各種対応指示を指定することもできる。
上記実施例では、退避CDRの削除を指定する例を説明したが、これに限定されるものではない。例えば、退避CDRの取得開始時間の指定、複数のCGFが存在する場合に転送先のCGFを指定するなど、各種対応指示を指定することもできる。
【0159】
［CGFの冗長化］
例えば、CGFが冗長化されている場合に待機系のCGFを利用して退避CDRを取得する例を説明したが、退避用のGTPコネクションの代わりに、縮退時用のGTPコネクションを利用することもできる。この場合、待機系のCGFは、障害復旧後に、退避用のコネクションの確立を抑制し、通常時に確立される縮退時用のGTPコネクションのみを復旧させることもできる。
例えば、CGFが冗長化されている場合に待機系のCGFを利用して退避CDRを取得する例を説明したが、退避用のGTPコネクションの代わりに、縮退時用のGTPコネクションを利用することもできる。この場合、待機系のCGFは、障害復旧後に、退避用のコネクションの確立を抑制し、通常時に確立される縮退時用のGTPコネクションのみを復旧させることもできる。
【0160】
［システム］
上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。また、実施例で説明した具体例、分布、数値などは、あくまで一例であり、任意に変更することができる。
上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。また、実施例で説明した具体例、分布、数値などは、あくまで一例であり、任意に変更することができる。
【0161】
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散や統合の具体的形態は図示のものに限られない。つまり、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
【0162】
［ハードウェア］
図２２は、ハードウェア構成例を説明する図である。なお、CDF１０とCGF３０とは同様の構成を有するので、ここでは、情報処理装置１００として説明する。図２２に示すように、情報処理装置１００は、通信装置１０ａ、ＨＤＤ（Hard Disk Drive）１０ｂ、メモリ１０ｃ、プロセッサ１０ｄを有する。また、図２２に示した各部は、バス等で相互に接続される。
図２２は、ハードウェア構成例を説明する図である。なお、CDF１０とCGF３０とは同様の構成を有するので、ここでは、情報処理装置１００として説明する。図２２に示すように、情報処理装置１００は、通信装置１０ａ、ＨＤＤ（Hard Disk Drive）１０ｂ、メモリ１０ｃ、プロセッサ１０ｄを有する。また、図２２に示した各部は、バス等で相互に接続される。
【0163】
通信装置１０ａは、ネットワークインタフェースカードなどであり、他のサーバとの通信を行う。ＨＤＤ１０ｂは、図３に示した機能を動作させるプログラムやＤＢを記憶する。
【0164】
プロセッサ１０ｄは、図２に示した各処理部と同様の処理を実行するプログラムをＨＤＤ１０ｂ等から読み出してメモリ１０ｃに展開することで、図３等で説明した各機能を実行するプロセスを動作させる。例えば、CDF１０を例にすると、このプロセスは、CDF１０が有する各処理部と同様の機能を実行する。具体的には、プロセッサ１０ｄは、イベント受付部２１、CDR生成部２２、CDR送信部２３、障害処理部２４等と同様の機能を有するプログラムをＨＤＤ１０ｂ等から読み出す。そして、プロセッサ１０ｄは、イベント受付部２１、CDR生成部２２、CDR送信部２３、障害処理部２４等と同様の処理を実行するプロセスを実行する。
【0165】
このように情報処理装置１００は、プログラムを読み出して実行することで制御方法を実行する情報処理装置として動作する。また、情報処理装置１００は、媒体読取装置によって記録媒体から上記プログラムを読み出し、読み出された上記プログラムを実行することで上記した実施例と同様の機能を実現することもできる。なお、この他の実施例でいうプログラムは、情報処理装置１００によって実行されることに限定されるものではない。例えば、他のコンピュータまたはサーバがプログラムを実行する場合や、これらが協働してプログラムを実行するような場合にも、本発明を同様に適用することができる。
【0166】
このプログラムは、インターネットなどのネットワークを介して配布することができる。また、このプログラムは、ハードディスク、フレキシブルディスク（ＦＤ）、ＣＤ－ＲＯＭ、ＭＯ（Magneto－Optical disk）、ＤＶＤ（Digital Versatile Disc）などのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行することができる。
【符号の説明】
【0167】
１０ CDF
１１ 通信部
１２ 記憶部
１３ 退避ＤＢ
２０ 制御部
２１ イベント受付部
２２ CDR生成部
２３ CDR送信部
２４ 障害処理部
２５ CDR退避部
２６ 障害対応部
３０ CGF
３１ 通信部
３２ 記憶部
３３ CDR格納ＤＢ
４０ 制御部
５０ 通常処理部
５１ CDR受信部
５２ CDR処理部
６０ 障害処理部
６１ プロトコル制御部
６２ CDR対応部
１１ 通信部
１２ 記憶部
１３ 退避ＤＢ
２０ 制御部
２１ イベント受付部
２２ CDR生成部
２３ CDR送信部
２４ 障害処理部
２５ CDR退避部
２６ 障害対応部
３０ CGF
３１ 通信部
３２ 記憶部
３３ CDR格納ＤＢ
４０ 制御部
５０ 通常処理部
５１ CDR受信部
５２ CDR処理部
６０ 障害処理部
６１ プロトコル制御部
６２ CDR対応部
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】