(57)【要約】【課題】課金情報の送信遅延を抑制することを課題とする。【解決手段】CGFは、通信料金の請求に利用される課金情報を生成するCDFとの間で確立される第１のコネクションを経由して、課金情報を受信する。そして、CGFは、CDFとの通信が遮断された後、CDFとの通信が復旧した場合に、CDFとの間で１のコネクションおよび第２のコネクションを確立する。その後、CGFは、第１のコネクションを経由して、通信が復旧した後に生成された第１の課金情報を受信し、第２のコネクションを経由して、通信の遮断中に生成された第２の課金情報を取得する。【選択図】図３
2019213037.tif 000002
【特許請求の範囲】
【請求項１】
通信料金の請求に利用される課金情報を生成する課金生成装置との間で確立される第１のコネクションを経由して、前記課金情報を受信する受信部と、
前記課金生成装置との通信が遮断された後、前記課金生成装置との通信が復旧した場合に、前記課金生成装置との間で前記第１のコネクションおよび第２のコネクションを確立する確立部と、
前記第１のコネクションを経由して、前記通信が復旧した後に生成された第１の課金情報を受信し、前記第２のコネクションを経由して、前記通信の遮断中に生成された第２の課金情報を取得する受信制御部と
を有することを特徴とする制御装置。
【請求項２】
前記確立部は、前記第２の課金情報の取得が完了した場合に、前記第１のコネクションの確立を維持しつつ、前記第２のコネクションを切断することを特徴とする請求項１に記載の制御装置。
【請求項３】
前記受信制御部は、前記第２の課金情報の取得または削除に関する対応指示を含めた要求を、前記第２のコネクションを経由して前記課金生成装置に送信することを特徴とする請求項１に記載の制御装置。
【請求項４】
前記確立部は、前記制御装置が冗長化された複数の制御装置のうちの待機系の制御装置である場合に、前記課金生成装置との通信が復旧後に、縮退用として使用予定である前記第１のコネクションを確立するとともに、前記第２のコネクションの確立を抑制し、
前記受信制御部は、前記第１のコネクションを経由して、前記第２の課金情報を取得することを特徴とする請求項１に記載の制御装置。
【請求項５】
前記確立部は、３ＧＰＰ（Third  Generation  Partnership  Project)ネットワークのオフライン課金アーキテクチャで利用されるＧＰＲＳ（General  Packet  Radio  Service）トンネリングプロトコルを用いて、前記第１のコネクションおよび前記第２のコネクションを確立することを特徴とする請求項１に記載の制御装置。
【請求項６】
コンピュータが、
通信料金の請求に利用される課金情報を生成する課金生成装置との間で確立される第１のコネクションを経由して、前記課金情報を受信し、
前記課金生成装置との通信が遮断された後、前記課金生成装置との通信が復旧した場合に、前記課金生成装置との間で前記第１のコネクションおよび第２のコネクションを確立し、
前記第１のコネクションを経由して、前記通信が復旧した後に生成された第１の課金情報を受信し、前記第２のコネクションを経由して、前記通信の遮断中に生成された第２の課金情報を取得する
処理を実行することを特徴とする課金取得方法。
【請求項７】
コンピュータに、
通信料金の請求に利用される課金情報を生成する課金生成装置との間で確立される第１のコネクションを経由して、前記課金情報を受信し、
前記課金生成装置との通信が遮断された後、前記課金生成装置との通信が復旧した場合に、前記課金生成装置との間で前記第１のコネクションおよび第２のコネクションを確立し、
前記第１のコネクションを経由して、前記通信が復旧した後に生成された第１の課金情報を受信し、前記第２のコネクションを経由して、前記通信の遮断中に生成された第２の課金情報を取得する
処理を実行させることを特徴とする課金取得プログラム。
【請求項８】
課金生成装置と制御装置とを含む課金システムにおいて、
前記課金生成装置は、
通信料金の請求に利用される課金情報を生成する生成部と、
前記制御装置との間で確立される第１のコネクションを経由して、前記課金情報を送信する送信部と、を有し、
前記制御装置は、
前記課金生成装置との間で確立される前記第１のコネクションを経由して、前記課金情報を受信する受信部と、
前記課金生成装置との通信が遮断された後、前記課金生成装置との通信が復旧した場合に、前記課金生成装置との間で前記第１のコネクションおよび第２のコネクションを確立する確立部と、
前記第１のコネクションを経由して、前記通信が復旧した後に生成された第１の課金情報を受信し、前記第２のコネクションを経由して、前記通信の遮断中に生成された第２の課金情報を取得する受信制御部と
を有することを特徴とする課金システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、制御装置、課金取得方法、課金取得プログラムおよび課金システムに関する。
【背景技術】
【０００２】
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）の転送に使用される。
【０００３】
図２３は、オフライン課金アーキテクチャを説明する図である。図２３に示すように、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）に転送する。
【０００４】
図２３に示すネットワークにおける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を冗長化することも行われている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１０−１４７６４４号公報
【特許文献２】特表２０１０−５１５３５５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ところで、障害によって遮断されたCDFとCGFとの通信が復旧した後、障害によって送信されなかった旧CDRと障害が復旧するまでの間に新規に生成された新CDRとが混在することがある。上記技術では、CDFの退避用ストレージに旧CDRを保持したとしても、復旧後にCGFへ自動的に転送するプロトコルの規定がないことから、CDFに直接ログインして旧CDRを手動で収集し、Bxフォーマットに変換してBDに送信することが行われている。
【０００７】
また、CDFが、旧CDRを退避用ストレージに保存しておき、障害復旧後に、旧CDRおよび新CDRをCGFへ送信することも考えられるが、この手法では新CDRの送信遅延が発生する。例えば、シーケンス番号１００のCDRを送信中に障害が発生し、障害の間にシーケンス番号５００までのCDRが生成されたとする。この場合、CDFは、シーケンス番号１００から５００までの４００個の旧CDRを蓄積しておき、障害復旧後に順次送信する。しかし、障害復旧後には新たに生成されたシーケンス番号５０１の新CDRが、障害時に蓄積された４００個の旧CDRの送信後に送信されることになり、リアルタイム送信が実行できない。
【０００８】
なお、CDRの送信には、3GPPにおいて「near  real  time」として１分が設定されており、障害時に蓄積されるCDRの数が多いほど、この制約を遵守することができない。また、障害時に蓄積されたCDRを廃棄することも考えられるが、廃棄すると課金を正しく行うことができなくなるので、好ましい手法ではない。
【０００９】
一つの側面では、課金情報の送信遅延を抑制することができる制御装置、課金取得方法、課金取得プログラムおよび課金システムを提供することを目的とする。
【課題を解決するための手段】
【００１０】
第１の案では、制御装置は、通信料金の請求に利用される課金情報を生成する課金生成装置との間で確立される第１のコネクションを経由して、前記課金情報を受信する受信部を有する。制御装置は、前記課金生成装置との通信が遮断された後、前記課金生成装置との通信が復旧した場合に、前記課金生成装置との間で前記第１のコネクションおよび第２のコネクションを確立する確立部を有する。制御装置は、前記第１のコネクションを経由して、前記通信が復旧した後に生成された第１の課金情報を受信し、前記第２のコネクションを経由して、前記通信の遮断中に生成された第２の課金情報を取得する受信制御部を有する。
【発明の効果】
【００１１】
一実施形態によれば、課金情報の送信遅延を抑制することができる。
【図面の簡単な説明】
【００１２】
【図１】図１は、実施例１にかかるオフライン課金アーキテクチャのシステム構成を示す図である。
【図２】図２は、CDRの送信経路を示す図である。
【図３】図３は、実施例１にかかるCDFとCGFの機能構成を示す機能ブロック図である。
【図４】図４は、通常運用時から障害復旧後までのコネクションの確立関係を説明する図である。
【図５】図５は、実施例１にかかるCDFの障害発生時の全体的な処理の流れを示すフローチャートである。
【図６】図６は、実施例１にかかるCGFの障害発生時の全体的な処理の流れを示すフローチャートである。
【図７】図７は、実施例１にかかる通信障害時の流れを示すシーケンス図である。
【図８】図８は、Data  Record  Transfer  Requestのフォーマット例を示す図である。
【図９】図９は、Redirection  Requestのフォーマット例を示す図である。
【図１０】図１０は、Data  Record  Transfer  Requestのフォーマット例を示す図である。
【図１１】図１１は、Data  Record  Transfer  Responseのフォーマット例を示す図である。
【図１２】図１２は、実施例１にかかるシステム障害時の流れを示すシーケンス図である。
【図１３】図１３は、Node  Alive  Responseのフォーマット例を示す図である。
【図１４】図１４は、実施例２にかかるCGF冗長化システムにおける通信障害時の流れを示すシーケンス図である。
【図１５】図１５は、実施例２にかかるCGF冗長化システムにおけるシステム障害時の流れを示すシーケンス図である。
【図１６】図１６は、実施例３にかかる保守端末主導による通信障害時の流れを示すシーケンス図である。
【図１７】図１７は、実施例３にかかる保守端末主導時に退避CDRがない場合の処理の流れを示すシーケンス図である。
【図１８】図１８は、実施例３にかかる保守端末主導による退避CDRの削除時の流れを示すシーケンス図である。
【図１９】図１９は、実施例４にかかる障害復旧後の送信エラー時の流れを示すシーケンス図である。
【図２０】図２０は、実施例４にかかる障害復旧後の応答エラー時の流れを示すシーケンス図である。
【図２１】図２１は、実施例４にかかる退避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）を収集して課金を行うオフライン課金システムである。
【００１５】
RNCは、無線通信ネットワーク全体を制御する制御局である。SGSNは、3G無線アクセスにおける端末の移動管理や認証（セキュリティ制御）などを行う装置である。eNodeBは、LTE（Long  Term  Evolution）を利用した携帯電話の通信で使われている基地局である。EPCは、LTEのアクセス網を収容するコアネットワークである。BDは、課金情報を収集して課金を行う課金装置を含む料金請求システムである。VGNは、LTEのデータ通信を用いて音声通話を実現させるためのゲートウェイノードである。ISPは、インターネットを利用するユーザに対して、ユーザのコンピュータをインターネットへ接続するための手段をサービスとして提供する事業者である。
【００１６】
また、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アクセスを収容するゲートウェイ装置である。
【００１７】
CDF１０は、Rf参照ポイントを経たCTFからのChargingイベントを受信し、受信したChargingイベントに含まれている情報を用いてCDRを生成し、Ga参照ポイントを介してCGFに転送する装置である。CGF３０は、CDFによって生成されたCDRを、Ga参照ポイントを介して受信し、受信したCDRの検証、統合、再フォーマットなどを行い、CDRファイルを生成してBx参照ポイントを介して、BDに転送する装置である。
【００１８】
また、CDF１０は、３GPP標準で課金が定義されているネットワーク要素の実装形態により、システム内での配置位置が異なる。そのような場合であっても、CDF１０からCGF30へのGa参照ポインタの位置によってCDRの送信経路を特定することができる。図２は、CDRの送信経路を示す図である。図２の（ａ）は、CDF１０が他のネットワーク要素に統合されているシステム例を示す。この場合、物理的なNEがCDRを生成し、それらをCGFに送信する。したがって、Ga参照ポインタは、物理インタフェースとしてNE内に実装される。
【００１９】
図２の（ｂ）は、CDF１０がネットワーク要素として存在するシステム例を示す。この場合、NE、CDF１０、及びCGF３０の物理インタフェースとしてすべての参照ポイントを実装する。つまり、NEは、Rf参照ポインタを用いて、システム内から収集した課金イベントをCDF１０に送信する。CDF１０は、課金イベントからCDRを生成し、Ga参照ポイントを介してCGF３０に送信する。CGF30は、CDF１０から受信したCDRに対して所定の処理を行い、Bx参照ポインタを介して、BDに送信する。
【００２０】
上記いずれの場合でも実施例１を適用することができるが、実施例１では、一例として、図２の（ｂ）を用いて説明する。
【００２１】
このようなシステムにおいて、CGF３０は、通信料金の請求に利用される課金情報を生成するCDF１０との間で確立される第１のコネクションを経由して、課金情報を受信する。そして、CGF３０は、CDF１０との通信が遮断された後、CDF１０との通信が復旧した場合に、CDF１０との間で第１のコネクションおよび第２のコネクションを確立する。その後、CGF30は、第１のコネクションを経由して、通信が復旧した後に生成された第１の課金情報を受信し、第２のコネクションを経由して、通信の遮断中に生成された第２の課金情報を取得する。
【００２２】
つまり、CGF３０は、障害が復旧した後は、帯域やメモリなどの空きリソースを用いて、通常時に使用される第１のコネクションと異なる第２のコネクションを、CDF１０との間で構築する。そして、CGF３０は、障害復旧後に生成される通常時のCDRを、障害発生前と同様の第１のコネクションで受信する。その一方で、CGF30は、障害発生中に生成されて退避されていたCDRを、通常の第１のコネクションとは異なる第２のコネクションで受信する。
【００２３】
このようにすることで、CGF３０は、正常なCDRの受信に影響を与えることなく、障害発生中に生成されたCDRを正常に受信することができるとともに、障害復旧後に正常に生成されるCDRを遅滞なく受信することができる。
【００２４】
［機能構成］
次に、図１に示したシステムの各要素（装置）について説明するが、CDF１０とCGF３０以外の他の要素は、３GPPの課金アーキテクチャで使用される要素と同様の構成を有するので、詳細な説明は省略する。ここでは、図３を用いて、CDF１０とCGF３０について説明する。図３は、実施例１にかかるCDF１０とCGF３０の機能構成を示す機能ブロック図である。
【００２５】
（CDF１０の機能構成）
図３に示すように、CDF１０は、通信部１１、記憶部１２、制御部２０を有する。通信部１１は、ネットワークを介して、他の装置のとの間の通信を制御する処理部である。例えば、通信部１１は、S-GWやP-GWのCTFから課金イベントを受信し、CDRをCGF３０に送信する。また、通信部１１は、CGF３０との間で、コネクションを確立要求や各種メッセージの送受信を実行する。また、通信部１１は、CGF３０との間で、GTPコネクションを確立して、CDRを送信する。
【００２６】
記憶部１２は、プログラムやデータを記憶する記憶装置の一例であり、例えばメモリやハードディスクなどである。この記憶部１２は、制御部２０によって生成されたCDRを記憶する。また、記憶部１２は、退避ＤＢ１３を記憶する。退避ＤＢ１３は、障害等によってCGF３０への送信が未完了であるCDR（以降では退避CDRと記載する場合がある）を記憶する記憶部である。例えば、退避DB１３は、生成された順でCDRを一時的に記憶する。
【００２７】
制御部２０は、CDF１０全体を司る処理部であり、例えばプロセッサなどである。制御部２０は、イベント受付部２１、CDR生成部２２、CDR送信部２３、障害処理部２４を有する。なお、イベント受付部２１、CDR生成部２２、CDR送信部２３、障害処理部２４は、プロセッサが有する電子回路の一例やプロセッサが実行するプロセスの一例である。
【００２８】
イベント受付部２１は、CTFから課金イベントを受信する処理部である。具体的には、イベント受付部２１は、端末間の通話等が発生したなどの課金対象のイベントが発生した場合に、課金対象の事象に関する情報である課金イベントをCTFから受信する。例えば、イベント受付部２１は、ユーザ間で音声通話が発生した場合に、セッションの開始、終了など、通信に必要なネットワークリソースの使用状況を通知する課金イベントをCTFから受信する。
【００２９】
CDR生成部２２は、イベント受付部２１により受け付けられた課金イベントに基づいて、CDRを生成する処理部である。例えば、CDR生成部２２は、イベント受付部２１から課金イベントを取得し、通話時間、通話時間帯、通話相手などの課金に必要な情報を含むCDRを生成する。そして、CDR生成部２２は、生成したCDRをCDR送信部２３に出力する。
【００３０】
CDR送信部２３は、GTPコネクション（GTPトンネル）を介して、CDRをCGF３０に送信する処理部である。例えば、CDR送信部２３は、CDR１０とCGF３０との間で通常時に確立されているGTPコネクションを介して、CDR生成部２２から入力されたCDRをCGF３０に送信する。また、CDR送信部２３は、CDRが生成されてから１分以内のように３GPPで規定される遅延時間を遵守して、CDRの送信を実行する。
【００３１】
障害処理部２４は、CDR退避部２５と障害対応部２６とを有し、CDF１０とCGF３０との通信障害、または、CDR１０やCGF３０のシステム障害を検出し、障害対応を実行する処理部である。例えば、障害処理部２４は、CDRを送信した後に受信応答を所定時間の間にCGF３０から受信できない場合に、障害を検出する。また、障害処理部２４は、障害復旧通知やCDRの再送要求などをCGF３０から受信した場合に、障害復旧と判定する。
【００３２】
CDR退避部２５は、障害が検出された場合に、CDRを退避する処理部である。例えば、CDR退避部２５は、障害が検出された場合に、障害が復旧するまでに生成されたCDRを退避ＤＢ１３に退避させる。このとき、CDR退避部２５は、退避対象の各CDRに対して、生成された順、すなわち送信順でシーケンシャル番号を付与することで、退避対象のCDRを管理することもできる。
【００３３】
障害対応部２６は、障害復旧時に、コネクション等の管理や退避されるCDRの送信を行う処理部である。具体的には、障害対応部２６は、CGF３０との通信が復旧した場合に、CGF３０との間で、通常時に使用されるGTPコネクションを確立する。そして、障害対応部２６は、CDR送信部２３に通常処理を指示する。これにより、障害復旧後に生成されるCDRは、通常時と同様のGTPコネクションを用いて送信される。
【００３４】
障害対応部２６は、障害復旧後に上記処理と並行して、CGF３０からの要求に応じて、退避されたCDR送信用の退避用GTPコネクションをCGF３０との間に確立する。そして、障害対応部２６は、新たに退避した退避用GTPコネクションを介して、退避ＤＢ１３に記憶される各退避CDRをCGF３０に送信する。すなわち、障害対応部２６は、未使用の帯域やメモリなどの空きリソースを使用して新たな退避用GTPコネクションを確立し、退避用GTPコネクションを介して未送信のCDRの再送を実行する。
【００３５】
このとき、障害対応部２６は、管理しているシーケンシャル番号の順番で退避CDRを送信することで、CDRを生成順で送信することができる。また、障害対応部２６は、退避ＤＢ１３に記憶される全退避CDRの送信が完了すると、退避用GTPコネクションを切断する。この結果、CDF１０とCGF３０との間のGTPコネクションは、障害発生前と同様、通常時に使用されるGTPコネクションのみが確立された状態となる。
【００３６】
（CGF３０の機能構成）
図３に示すように、CGF３０は、通信部３１、記憶部３２、制御部４０を有する。通信部３１は、ネットワークを介して、他の装置のとの間の通信を制御する処理部である。例えば、通信部３１は、CDF１０との間で、コネクションを確立要求や各種メッセージの送受信を実行する。また、通信部３１は、CDF１０との間でGTPコネクションを確立して、CDRを受信する。また、通信部３１は、BDとの間の通信を制御する。
【００３７】
記憶部３２は、プログラムやデータを記憶する記憶装置の一例であり、例えばメモリやハードディスクなどである。記憶部１２は、受信されたCDRを記憶するCDR格納ＤＢ３３を記憶する。CDR格納ＤＢ３３は、CDF１０から受信されたCDRを、BDに送信されるまで保持する。
【００３８】
制御部４０は、CGF３０全体を司る処理部であり、例えばプロセッサなどである。制御部４０は、通常処理部５０と障害処理部６０を有する。なお、通常処理部５０と障害処理部６０は、プロセッサが有する電子回路の一例やプロセッサが実行するプロセスの一例である。
【００３９】
通常処理部５０は、CDR受信部５１とCDR処理部５２とを有し、障害発生前や障害復旧後に、通常通り、CDF１０からCDRを受信してBDへ送信する処理部である。
【００４０】
CDR受信部５１は、CDF１０との間でGTPコネクションを確立し、GTPコネクションを介して、CDRを受信する処理部である。例えば、CDR受信部５１は、３GPPの遅延時間を遵守して送信されたCDRを、生成された順でCDF１０から順次受信する。そして、CDR受信部５１は、受信したCDRを、受信順でCDR格納ＤＢ３３に格納する。
【００４１】
CDR処理部５２は、CDF１０から受信されたCDRを、Bx参照ポイントを介してBDに送信する処理部である。例えば、CDR処理部５２は、CDR格納ＤＢ３３に記憶されるCDRを読み出し、読み出したCDRに対して、CDRの検証、統合、再フォーマットなどの各種処理を実行する。その後、CDR処理部５２は、Bxフォーマットに変換したCDRを、BDに送信する。このとき、CDR処理部５２は、CDRが生成された順で、各種処理を実行してBDに送信する。なお、上記各種処理は、３GPPのオフライン課金で実行される一般的な処理と同様の処理なので、詳細な説明は省略する。
【００４２】
障害処理部６０は、プロトコル制御部６１とCDR対応部６２とを有し、CDF１０とCGF３０との通信障害、または、CDR１０やCGF３０のシステム障害を検出し、障害対応を実行する処理部である。例えば、障害処理部６０は、CDRを受信してから予め指定される所定時間が経過するまでに次のCDRを受信しない場合に、通信障害を検出する。また、障害処理部６０は、CGF３０のシステム障害により各種データ（パケット）の送受信がエラーとなった場合に、障害を検出する。また、障害処理部６０は、通信障害やシステム障害が復旧した場合、GTPコネクションの確立要求やCDRの再送要求などをCDF１０に送信する。
【００４３】
プロトコル制御部６１は、障害復旧後に、GTPコネクションの確立を実行する処理部である。例えば、プロトコル制御部６１は、障害処理部６０によって障害復旧が検出されると、障害発生前の通常時に確立されていたGTPコネクションを、CDF１０との間で再度確立する。この結果、CDF１０が障害発生後に新たに生成したCDRを、通常時のGTPコネクションを受信することができる。
【００４４】
この通常時のGTPコネクションの確立と並行して、プロトコル制御部６１は、障害復旧後に、退避用のGTPコネクションの確立を実行する。例えば、プロトコル制御部６１は、障害が復旧すると、CDF１０に退避用コネクションの確立要求を送信する。そして、プロトコル制御部６１は、当該要求に対する応答をCDF１０から受信すると、未使用の帯域やメモリなどの空きリソースを使用して、退避された退避CDRの送信用である退避用GTPコネクションをCDF１０との間に確立する。その後、プロトコル制御部６１は、障害中に退避されたCDRの送信が完了すると、退避用GTPコネクションを切断して、リソースを解放する。
【００４５】
CDR対応部６２は、障害復旧後に、CDF１０内で退避されていた退避CDRに関する処理を実行する処理部である。例えば、CDR対応部６２は、退避用GTPコネクションが確立されると、退避用GTPコネクションを介して、障害発生中に生成されて退避されていたCDR（退避CDR）を受信する。そして、CDR対応部６２は、受信した退避CDRに受信順でシーケンシャル番号などを付与してCDR格納ＤＢ３３に格納する。このようにして、CDR対応部６２は、退避されていた退避CDRの受信状況を管理する。なお、CDR格納ＤＢ３３に格納されたCDR（退避CDR）は、障害発生後の新たに生成されたCDR（新CDR）よりも先に、CDR処理部５２によってBDに送信される。このようにして、CDRの生成順でBDに送信することができる。
【００４６】
［コネクション状況］
次に、図４を用いて、GTPコネクションの確立関係を説明する。図４は、通常運用時から障害復旧後までのコネクションの確立関係を説明する図である。図４に示すように、障害発生前の通常時は、CDF１０とCGF３０との間で、１つのGTPコネクションを常時確立し、CDRの送受信を実行する。
【００４７】
そして、障害が発生し、GTPコネクションが切断されると、CDF１０は、生成したCDRを退避ＤＢ１３に退避させて、CGF３０への送信を抑制する。その後、障害が復旧すると、CGF３０は、CDF１０との間に、通常時のGTPコネクションと退避用GTPコネクションの２つのコネクションを確立する。
【００４８】
そして、CDF１０は、通常時のGTPコネクションを用いて、障害発生後に生成されたCDRをCGF３０に送信する一方で、退避用GTPコネクションを用いて、障害時に退避されていた退避CDRをCGF３０に送信する。
【００４９】
その後、CGF３０は、退避されていた全退避CDRの受信が完了すると、退避用GTPコネクションのみを切断する。この結果、CDF１０とCGF３０のコネクションは、障害発生前と同様の状態となる。
【００５０】
［フローチャート］
次に、CDF１０とCGF３０のそれぞれについて、障害発生時の全体的な処理の流れを説明する。
【００５１】
（CDF１０のフローチャート）
図５は、実施例１にかかるCDF１０の障害発生時の全体的な処理の流れを示すフローチャートである。CDF１０は、CGF３０との通信が一定期間以上切断した場合、CDF１０のストレージもしくは外部ストレージなどに全CDRを退避する。
【００５２】
図５に示すように、CDF１０の障害処理部２４は、CGF３０へData  Record  Transfer  RequestをCGF３０へ送信し（Ｓ１０１）、応答メッセージであるData  Record  Transfer  Responseの受信待ちタイマを設定する（Ｓ１０２）。
【００５３】
その後、応答メッセージが未受信かつ受信待ちタイマが満了となった場合（Ｓ１０３：Ｙｅｓ）、障害処理部２４は、Data  Record  Transfer  RequestをCGF３０へ送信し（Ｓ１０４）、応答メッセージであるData  Record  Transfer  Responseの受信待ちタイマを設定する（Ｓ１０５）。
【００５４】
そして、応答メッセージが未受信かつ受信待ちタイマが満了かつ再送回数が満了となった場合（Ｓ１０６：Ｙｅｓ）、障害処理部２４は、CGF３０との間の障害発生を検出する（Ｓ１０７）。その後、障害処理部２４は、障害発生中にCDR生成部２２による生成されるCDRを退避ＤＢ１３に退避させる（Ｓ１０８）。
【００５５】
そして、障害処理部２４は、定期的にCGF３０に、Echo  Requestを送信する（Ｓ１０９）。ここで、障害処理部２４は、Node  Alive  RequestをCGF３０から受信すると（Ｓ１１０：Ｙｅｓ）、障害復旧を検出する（Ｓ１１１）。続いて、障害処理部２４は、Node  Alive  ResponseをCGF３０へ送信した後（Ｓ１１２）、Data  Record  Transfer  Request（空パケット）をCGF３０へ送信する（Ｓ１１３）。この結果、通常時とは別のGTPコネクションが確立される。
【００５６】
一方、障害処理部２４は、Echo  ResponseをCGF３０から受信すると（Ｓ１１４：Ｙｅｓ）、障害復旧を検出する（Ｓ１１５）。続いて、障害処理部２４は、Data  Record  Transfer  Request（空パケット）をCGF３０へ送信する（Ｓ１１６）。この結果、通常時とは別のGTPコネクションが確立される。
【００５７】
（CGF３０のフローチャート）
図６は、実施例１にかかるCGF３０の障害発生時の全体的な処理の流れを示すフローチャートである。CGF３０は、自動または保守者手動で退避されたCDRを収集することを可能とする。なお、ここでは、システム障害時のフローと通信障害時のフローとをあわせて説明するが、これに限定されるものではなく、別々のフローを用いて判定することもできる。
【００５８】
図６に示すように、CGF３０の通常処理部５０は、CDFG１０からData  Record  Transfer  Requestを受信すると（Ｓ２０１）、CDRをCDR格納ＤＢ３３に格納し、Data  Record  Transfer  ResponseをCDF１０へ送信する（Ｓ２０２）。
【００５９】
その後、CGF３０の障害処理部６０は、Data  Record  Transfer  RequestをCDF１０から受信できない場合（Ｓ２０３：Ｙｅｓ）、通信障害を検出する（Ｓ２０４）。その後、障害処理部６０は、Echo  RequestをCDF１０から受信すると（Ｓ２０５：Ｙｅｓ）、障害復旧を検出し（Ｓ２０６）、Echo  ResponseをCDF１０へ送信する（Ｓ２０７）。
【００６０】
その後、障害処理部６０は、Data  Record  Transfer  Request（空パケット）をCDF１０から受信すると（Ｓ２０８：Ｙｅｓ）、Data  Record  Transfer  ResponseをCDF１０へ送信する（Ｓ２０９）。
【００６１】
そして、障害処理部６０は、退避CDRが存在する場合（Ｓ２１０：Ｙｅｓ）、退避用のGTPコネクションの確立等を含む退避処理を実行し（Ｓ２１１）、退避CDRが存在しない場合（Ｓ２１０：Ｎｏ）、処理を終了する。
【００６２】
一方、CGF３０の通常処理部５０は、CDFG１０からData  Record  Transfer  Requestを受信すると（Ｓ２１２）、通常処理を実行する。その後、CGF３０でシステム障害が発生したとする（Ｓ２１３）。
【００６３】
そして、システム障害が復旧すると（Ｓ２１４：Ｙｅｓ）、障害処理部６０は、Node  Alive  RequestをCDF１０へ送信し（Ｓ２１５）、Node  Alive  ResponseをCDF１０から受信すると（Ｓ２１６）、Ｓ２０８以降を実行する。
【００６４】
［シーケンス図（通信障害）］
図７は、実施例１にかかる通信障害時の流れを示すシーケンス図である。図７に示すように、CDF１０とCGF３０との間で通信障害が発生し（Ｓ３０１）、その後に障害復旧して（Ｓ３０２）、通信可能となったとする。
【００６５】
すると、CDF１０は、障害の間に再送を繰り返していたEcho  RequestをCGF３０に送信する（Ｓ３０３とＳ３０４）。障害復旧により、このEcho  Requestを受信したCGF３０の通常処理部５０は、Echo  ResponseをCDF１０に応答する（Ｓ３０５とＳ３０６）。
【００６６】
続いて、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によって指定することができる。
【００６７】
その後、CDF１０とCGF３０との間で通常のGTPコネクションが再確立されて、障害発生後の生成されたCDRの送信が、通常のGTPコネクションを介して実行される（Ｓ３０９）。
【００６８】
この通常処理と並行して、CGF３０の障害処理部６０は、退避用のコネクション要求をCDF１０に送信し（Ｓ３１０とＳ３１１）、CDF１０の障害処理部２４は、コネクション要求に対する応答をCGF３０に送信する（Ｓ３１２とＳ３１３）。この結果、CGF３０の障害処理部６０は、CDF１０との間で、退避用GTPコネクションを確立する（Ｓ３１４）。
【００６９】
続いて、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の要求を検出することができる。
【００７０】
そして、CDF１０の障害処理部２４は、CGF３０からのRedirection  Requestの応答として、Redirection  ResponseをCGF３０に送信する（Ｓ３１７とＳ３１８）。このとき、Cause  IEに「Request  Accepted」が設定される。また、CDF１０は、退避用CDR転送のためのシーケンス番号を管理する。
【００７１】
その後、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）などの４つの情報を指定できる。
【００７２】
その後、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へ送信される。
【００７３】
そして、Data  Record  Transfer  Responseメッセージを受信したCDF１０の障害処理部２４は、退避ＤＢ１３から転送済みの退避CDRを削除する（Ｓ３２５）。このようにして、退避されていたCDR（退避CDR）の転送が、退避用GTPコネクションを用いて実行される。
【００７４】
その後、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）を追加する。
【００７５】
続いて、CGF３０の障害処理部６０は、受信したCDRを記憶部３２のCDR格納ＤＢ３３に格納し（Ｓ３２８とＳ３２９）、受信応答のメッセージとしてData  Record  Transfer  ResponseをCDF１０に送信する（Ｓ３３０とＳ３３１）。このとき、Data  Record  Transfer  ResponseのメッセージのCause  IEに「Request  Accepted」が設定される。CGF３０で管理される、退避CDR用のインスタンスデータ（シーケンス番号など）は、ここで解放される。
【００７６】
その後、Data  Record  Transfer  Responseメッセージを受信したCDF１０の障害処理部２４は、退避ＤＢ１３から転送済みの最後の退避CDRを削除する（Ｓ３３２）。そして、CGF３０の障害処理部６０は、退避用GTPコネクションを切断し、リソースを解放する（Ｓ３３３とＳ３３４）。
【００７７】
［シーケンス図（システム障害）］
図１２は、実施例１にかかるシステム障害時の流れを示すシーケンス図である。図１２に示すように、CGF３０にシステム障害が発生してCDF１０とCGF３０との通信が遮断され（Ｓ４０１）、その後に障害復旧して（Ｓ４０２）、通信可能となったとする。
【００７８】
すると、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が存在することを検出できる。
【００７９】
その後、CDF１０の障害処理部２４は、Data  Record  Transfer  Request（空パケット）をCGF３０に送信する（Ｓ４０７とＳ４０８）。その際、Ｓ４０５の代わりに、図７と同様、オプションIEであるSave  CDR  Information  IEを設定することで、退避CDRが存在することをCGFに通知することもできる。
【００８０】
その後、CDF１０とCGF３０との間で通常のGTPコネクションが再確立されて、障害発生後の生成されたCDRの送信が、通常のGTPコネクションを介して実行される（Ｓ４０９）。
【００８１】
この通常処理と並行して、CGF３０の障害処理部６０は、退避用のコネクション要求をCDF１０に送信し（Ｓ４１０とＳ４１１）、CDF１０の障害処理部２４は、コネクション要求に対する応答をCGF３０に送信する（Ｓ４１２とＳ４１３）。この結果、CGF３０の障害処理部６０は、CDF１０との間で、退避用GTPコネクションを確立する（Ｓ４１４）。
【００８２】
続いて、CGF３０の障害処理部６０は、CDF１０に対し、Redirection  Requestを送信する（Ｓ４１５とＳ４１６）。このとき、当該メッセージのCause  IEに「Saved  CDR  transfer  Request」を設定し、CDF１０に対し退避CDR３０の転送を要求する。
【００８３】
そして、CDF１０の障害処理部２４は、CGF３０からのRedirection  Requestの応答として、Redirection  ResponseをCGF３０に送信する（Ｓ４１７とＳ４１８）。このとき、Cause  IEに「Request  Accepted」が設定される。また、CDF１０は、退避用CDR転送のためのシーケンス番号を管理する。
【００８４】
その後、CDF１０の障害処理部２４は、退避していたCDR（退避CDR）を、退避用GTPコネクションを介してCGF３０に送信する（Ｓ４１９とＳ４２０）。このとき、CDF１０は、CGF３０に、Packet  Transfer  Command  IEに「Send  Data  Record  Packet」を設定したData  Record  Transfer  Requestを送信し、CDR（退避CDR）を転送する。
【００８５】
その後、CGF３０の障害処理部６０は、受信したCDRを記憶部３２のCDR格納ＤＢ３３に格納し（Ｓ４２１とＳ４２２）、受信応答のメッセージとしてData  Record  Transfer  ResponseをCDF１０に送信する（Ｓ４２３とＳ４２４）。このとき、Data  Record  Transfer  ResponseのメッセージのCause  IEに「Request  Accepted」が設定される。
【００８６】
そして、Data  Record  Transfer  Responseメッセージを受信したCDF１０の障害処理部２４は、退避ＤＢ１３から転送済みの退避CDRを削除する（Ｓ４２５）。このようにして、退避されていたCDR（退避CDR）の転送が、退避用GTPコネクションを用いて実行される。なお、その後の処理は、図７と同様なので、詳細な説明は省略する。
【００８７】
［効果］
上述したように、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３０に転送することができる。
【００８８】
この結果、Ga参照ポイントのCDR転送に影響を与えずに、通信障害中に退避されたCDRの転送を実現することが可能となり、CDRが欠損することなく自動で自動的に収集できる。また、Bxフォーマットに変換後に、BDに転送することができる。また、CGF３０主導で退避CDRの収集を行うことで、保守者に柔軟な選択を提供することができる。
【００８９】
ここで、通信障害中に退避されるCDRの数から、退避されたCDRを一般的なプロトコル規定で転送した場合のCDRの転送遅延時間を算出し、実施例１と一般技術とを対比する。まず、算出条件として、１時間あたりに生成されるCDR数を「1,800,000［CDR／H］」、通信障害が発生した時間は５分間、Ga参照ポイントで１分間に転送できるCDRの数を「60,000［CDR］」とする。
【００９０】
このような条件で、退避された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］・・・（３）となる。
【００９１】
そして、（３）の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］となる。
【００９２】
このように、最終的にリアルタイムに転送できるようになるまでの時間は、（２）＋（４）＋（６）＋（８）＋α（約２０秒）＝約５分となる。つまり、障害復旧後から約５分後に、新たに生成されるCDRのリアルタイム転送が可能となり、約５分の間に生成されるCDRについては３GPPの制約を遵守できない恐れが高い。これに対して、実施例１による手法では、新規のCDRと退避CDRとを別々のコネクションで送信することができるので、一般的なプロトコルによる送信遅延を改善することができる。
【実施例２】
【００９３】
ところで、課金アーキテクチャでは、CGF３０としてプライマリ（運用系）とセカンダリ（待機系）を用意することで、CGF30を冗長化することもある。この場合、通常時は使用されない空きリソースであるセカンダリのCGFを用いることで、一般的なプロトコルによる送信遅延を改善することができる。
【００９４】
そこで、実施例２では、CGF冗長化システムを例にして、退避CDRの転送を説明する。ここでは、プライマリとしてCGF３０、セカンダリとしてCGF８０を用いるが、CGF８０は、CGF３０と同様の機能構成を有するものとする。
【００９５】
［シーケンス図（通信障害）］
図１４は、実施例２にかかるCGF冗長化システムにおける通信障害時の流れを示すシーケンス図である。図１４に示すように、CDF１０と各CGF（CGF３０、CGF８０）との間で通信障害が発生し（Ｓ５０１）、その後に障害復旧して（Ｓ５０２）、通信可能となったとする。
【００９６】
すると、CDF１０は、障害の間に再送を繰り返していたEcho  RequestをCGF３０に送信する（Ｓ５０３とＳ５０４）。障害復旧により、このEcho  Requestを受信したCGF３０は、Echo  RequestをCDF１０に応答する（Ｓ５０５とＳ５０６）。
【００９７】
続いて、CDF１０は、Data  Record  Transfer  Request（空パケット）をCGF３０に送信する（Ｓ５０７とＳ５０８）。この結果、CDF１０とプライマリであるCGF３０との間で通常のGTPコネクションが再確立されて、障害発生後の生成されたCDRの送信が、通常のGTPコネクションを介して実行される（Ｓ５０９）。
【００９８】
CDF１０は、プライマリのCGF３０への上記処理と並行して、Echo  RequestをセカンダリのCGF８０に送信する（Ｓ５１０とＳ５１１）。障害復旧により、このEcho  Requestを受信したCGF８０は、Echo  ResponseをCDF１０に応答する（Ｓ５１２とＳ５１３）。
【００９９】
続いて、CDF１０は、Data  Record  Transfer  Request（空パケット）をCGF８０に送信する（Ｓ５１４とＳ５１５）。その際、オプションIEであるSave  CDR  Information  IEを設定することで、退避CDRが存在することをCGFに通知する。
【０１００】
そして、CGF８０は、Data  Record  Transfer  Requestの応答として、リクエスト受信応答であるData  Record  Transfer  ResponseをCDF１０に送信する（Ｓ５１６とＳ５１７）。このとき、Cause  IEに「Request  Accepted」が設定される。
【０１０１】
その後、CGF８０は、退避用のコネクション要求をCDF１０に送信し（Ｓ５１８とＳ５１９）、CDF１０は、コネクション要求に対する応答をCGF８０に送信する（Ｓ５２０とＳ５２１）。この結果、CDF１０とセカンダリであるCGF８０との間で、退避用GTPコネクションが確立される（Ｓ５２２）。
【０１０２】
続いて、CGF８６０は、CDF１０に対し、Redirection  Requestを送信する（Ｓ５２３とＳ５２４）。このとき、当該メッセージのCause  IEに「Saved  CDR  transfer  Request」を設定し、CDF１０に対し退避CDRの転送を要求する。
【０１０３】
そして、CDF１０は、CGF８０からのRedirection  Requestの応答として、Redirection  ResponseをCGF８０に送信する（Ｓ５２５とＳ５２６）。このとき、Cause  IEに「Request  Accepted」が設定される。また、CDF８０は、退避用CDR転送のためのシーケンス番号を管理する。
【０１０４】
その後、CDF１０は、退避していたCDR（退避CDR）を、退避用のGTPコネクションを介してCGF８０に送信する（Ｓ５２７とＳ５２８）。このとき、CDF１０は、CGF８０に、Packet  Transfer  Command  IEに「Send  Data  Record  Packet」を設定したData  Record  Transfer  Requestを送信し、CDR（退避CDR）を転送する。
【０１０５】
その後、CGF８０は、受信したCDRを記憶部に格納し（Ｓ５２９）、受信応答のメッセージとしてData  Record  Transfer  ResponseをCDF１０に送信する（Ｓ５３０とＳ５３１）。このとき、Data  Record  Transfer  ResponseのメッセージのCause  IEに「Request  Accepted」が設定される。
【０１０６】
そして、Data  Record  Transfer  Responseメッセージを受信したCDF１０は、退避ＤＢ１３から転送済みの退避CDRを削除する（Ｓ５３２）。このようにして、退避されていたCDR（退避CDR）が、退避用のGTPコネクションを用いてセカンダリのCGF８０に転送される。
【０１０７】
その後、CDF１０は、最後の退避CDRを送信するとき、Data  Record  Transfer  RequestのPacket  Transfer  Command  IEに「Last  Send  Data  Record  Packet」を設定し、CGF８０に終了を通知する（Ｓ５３３とＳ５３４）。
【０１０８】
続いて、CGF８０は、受信したCDRを記憶部に格納し（Ｓ５３５）、受信応答のメッセージとしてData  Record  Transfer  ResponseをCDF１０に送信する（Ｓ５３６とＳ５３７）。このとき、Data  Record  Transfer  ResponseのメッセージのCause  IEに「Request  Accepted」が設定される。
【０１０９】
その後、Data  Record  Transfer  Responseメッセージを受信したCDF１０は、退避ＤＢ１３から転送済みの最後の退避CDRを削除する（Ｓ５３８）。そして、CGF８０は、退避用のGTPコネクションを切断し、リソースを解放する（Ｓ５３９とＳ５４０）。
【０１１０】
［シーケンス図（システム障害）］
図１５は、実施例２にかかるCGF冗長化システムにおけるシステム障害時の流れを示すシーケンス図である。図１５に示すように、CGF３０にシステム障害が発生してCDF１０とCGF３０との通信が遮断され（Ｓ６０１とＳ６０２）、その後に障害復旧して（Ｓ６０３）、通信可能となったとする。
【０１１１】
すると、CGF３０は、Node  Alive  RequestのメッセージをCDF１０に送信し（Ｓ６０４とＳ６０５）、CDF１０は、応答として、Node  Alive  ResponseをCGF３０に送信する（Ｓ６０６とＳ６０７）。
【０１１２】
その後、CDF１０は、Data  Record  Transfer  Request（空パケット）をCGF３０に送信する（Ｓ６０８とＳ６０９）。このようにして、CDF１０とCGF３０との間で通常のGTPコネクションが再確立されて、障害発生後の生成されたCDRの送信が、通常のGTPコネクションを介して実行される（Ｓ６１０）。
【０１１３】
プライマリのCGF３０への上記処理と並行して、CGF８０は、Node  Alive  RequestのメッセージをCDF１０に送信し（Ｓ６１１とＳ６１２）、CDF１０は、応答として、Node  Alive  ResponseをCGF３０に送信する（Ｓ６１３とＳ６１４）。ここで、CDF１０は、Node  Alive  Responseに「Save  CDR  Information」を設定することで、退避CDRが存在することをCGF８０に通知する。
【０１１４】
その後、GF８０は、退避用のコネクション要求をCDF１０に送信し（Ｓ６１５とＳ６１６）、CDF１０は、コネクション要求に対する応答をCGF８０に送信する（Ｓ６１７とＳ６１８）。この結果、CGF８０は、CDF１０との間で、退避用のGTPコネクションを確立する（Ｓ６１９）。なお、その後の処理は、図１４と同様なので、詳細な説明は省略する。
【０１１５】
このように、冗長化構成されているセカンダリのCGF８０を利用することで、プライマリであるCGF３０の処理負荷が高くなることを抑制でき、通常業務の影響を極小化し、CGF３０の故障発生や処理遅延発生を抑制することができる。なお、実施例２では、CDF１０とプライマリであるCGF８０との間で、退避用のGTPコネクションを確立する例を説明したが、これに限定されるものではない。例えば、CGF３０の縮退時用としてCDF１０とCGF８０との間で通常時から確立されるGTPコネクションを用いて、CDF１０からCGF８０へ退避CDRを転送することもできる。
【実施例３】
【０１１６】
ところで、退避されていたCDRの転送は、保守者のタイミングで実行することもできる。そこで、実施例３では、保守者が使用する保守端末９０が主導で、退避されていたCDRの取得などの各種処理を実行する例を説明する。なお、ここでは、一例として、通信障害を例にして説明すると、システム障害や冗長化構成であっても同様に処理することができる。
【０１１７】
［シーケンス図（通信障害）］
図１６は、実施例３にかかる保守端末主導による通信障害時の流れを示すシーケンス図である。図１６に示すように、CDF１０とCGF３０との間で通信障害が発生し（Ｓ７０１）、その後に障害復旧して（Ｓ７０２）、通信可能となったとする。
【０１１８】
すると、CDF１０は、障害の間に再送を繰り返していたEcho  RequestをCGF３０に送信する（Ｓ７０３とＳ７０４）。障害復旧により、このEcho  Requestを受信したCGF３０は、Echo  ResponseをCDF１０に応答する（Ｓ７０５とＳ７０６）。
【０１１９】
続いて、CDF１０は、Data  Record  Transfer  Request（空パケット）をCGF３０に送信する（Ｓ７０７とＳ７０８）。その際、CDF１０は、オプションIEであるSave  CDR  Information  IEを設定することで、退避CDRが存在することをCGF３０に通知する。この結果、CDF１０とCGF３０との間で通常のGTPコネクションが再確立されて、障害発生後の生成されたCDRの送信が、通常のGTPコネクションを介して実行される（Ｓ７０９）。
【０１２０】
その後、保守端末９０は、CGF３０に、退避CDRの収集要求を送信する（Ｓ７１０とＳ７１１）。この要求を受信したCGF３０の障害処理部６０は、退避用のコネクション要求をCDF１０に送信し（Ｓ７１２とＳ７１３）、CDF１０は、コネクション要求に対する応答をCGF３０に送信する（Ｓ７１４とＳ７１５）。この結果、CGF３０の障害処理部６０は、CDF１０との間で、退避用のGTPコネクションを確立する（Ｓ７１６）。その後の処理は、実施例１の図７と同様なので、詳細な説明は省略する。
【０１２１】
なお、CGF３０の障害処理部６０は、退避用のGTPコネクションを切断してリソースを解放した後（Ｓ７１７とＳ７１８）、退避CDRの収集終了通知（正常）を保守端末９０に送信する（Ｓ７１９とＳ７２０）。
【０１２２】
［シーケンス図（退避CDRなし）］
図１７は、実施例３にかかる保守端末主導時に退避CDRがない場合の処理の流れを示すシーケンス図である。図１７に示すように、CDF１０とCGF３０との間で発生した通信障害が復旧し、通常処理が実行されているものとする（Ｓ８０１）。
【０１２３】
その後、保守端末９０は、CGF３０に、退避CDRの収集要求を送信する（Ｓ８０２とＳ８０３）。この要求を受信したCGF３０の障害処理部６０は、退避用のコネクション要求をCDF１０に送信し（Ｓ８０４とＳ８０５）、CDF１０は、コネクション要求に対する応答をCGF３０に送信する（Ｓ８０６とＳ８０７）。この結果、CGF３０の障害処理部６０は、CDF１０との間で、退避用のGTPコネクションを確立する（Ｓ８０８）。
【０１２４】
続いて、CGF３０の障害処理部６０は、CDF１０に対し、Redirection  Requestを送信する（Ｓ８０９とＳ８１０）。このとき、当該メッセージのCause  IEに「Saved  CDR  transfer  Request」を設定し、CDF１０に対し退避CDR３０の転送を要求する。
【０１２５】
そして、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がないことを検出することができる。
【０１２６】
この結果、CGF３０の障害処理部６０は、退避用のGTPコネクションを切断してリソースを解放し（Ｓ８１３とＳ８１４）、退避CDRの収集終了通知（退避CDRなし）を保守端末９０に送信する（Ｓ８１５とＳ８１６）。
【０１２７】
［シーケンス図（退避CDRの削除）］
図１８は、実施例３にかかる保守端末主導による退避CDRの削除時の流れを示すシーケンス図である。図１８に示すように、CDF１０とCGF３０との間で発生した通信障害が復旧し、通常処理が実行されているものとする（Ｓ９０１）。
【０１２８】
その後、保守端末９０は、CGF３０に、退避CDRの削除要求を送信する（Ｓ９０２とＳ９０３）。この要求を受信したCGF３０の障害処理部６０は、退避用のコネクション要求をCDF１０に送信し（Ｓ９０４とＳ９０５）、CDF１０は、コネクション要求に対する応答をCGF３０に送信する（Ｓ９０６とＳ９０７）。この結果、CGF３０の障害処理部６０は、CDF１０との間で、退避用のGTPコネクションを確立する（Ｓ９０８）。
【０１２９】
続いて、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の削除要求を検出することができる。
【０１３０】
そして、CDF１０の障害処理部２４は、CGF３０からのRedirection  Requestに「Saved  CDR  delete  request」が設定されていることにより、退避ＤＢ１３に退避していた退避CDRを、CGF３０へ送信することなく削除する（Ｓ９１１）。
【０１３１】
その後、CDF１０の障害処理部２４は、「Request  Accepted」が設定されたRedirection  ResponseをCGF３０に送信する（Ｓ９１２とＳ９１３）。そして、CGF３０の障害処理部６０は、退避用のGTPコネクションを切断してリソースを解放し（Ｓ９１４とＳ９１５）、退避CDRの削除終了通知（正常）を保守端末９０に送信する（Ｓ９１６とＳ９１７）。
【０１３２】
［効果］
上述したように、CGF３０主導で退避CDRの収集を行うことで、退避CDRの取得や削除などのサービスを提供することができる結果、保守者は、障害状況や契約状況等に基づく柔軟な対応を選択することができる。また、柔軟な対応の提供により、汎用性が向上し、システムの普及も期待できる。
【実施例４】
【０１３３】
ところで、障害復旧後の退避CDRの送信中に新たな障害が発生し、退避CDRの送信エラーが発生することも考えられる。そこで、実施例４では、退避CDRの送信エラー時の対応例を説明する。
【０１３４】
［送信エラー］
図１９は、実施例４にかかる障害復旧後の送信エラー時の流れを示すシーケンス図である。図１９に示すように、Ｓ１００１からＳ１０１４までの処理は、図７のＳ３１０からＳ３１４までの処理と同様なので、詳細な説明は省略する。
【０１３５】
退避用のGTPコネクションが確立されると、CGF３０の障害処理部６０は、CDF１０に対し、「Saved  CDR  transfer  request」を設定したRedirection  Requestを送信する（Ｓ１０１５とＳ１０１６）。
【０１３６】
そして、CDF１０は、CGF３０からのRedirection  Requestの応答として、「Request  Accepted」を設定したRedirection  Responseを、CGF３０の障害処理部６０に送信する（Ｓ１０１７とＳ１０１８）。
【０１３７】
その後、CDF１０は、シーケンシャル番号１（Seq：１）の退避CDRに該当するData  Record  Transfer  Requestに、「Send  Data  Record  Packet」を設定し、退避用のGTPコネクションを介して、障害処理部６０に送信する（Ｓ１０１９とＳ１０２０）。ところが、転送途中で通信障害が発生し、CGF３０の障害処理部６０はシーケンシャル番号１の退避CDRを受信できない。このため、CGF３０の障害処理部６０は、CDF１０に、応答であるData  Record  Transfer  Responseを送信できない。
【０１３８】
そして、障害が復旧すると（Ｓ１０２１）、CDF１０は、シーケンシャル番号１（Seq：１）のData  Record  Transfer  Requestの受信応答を受信していないことから、退避用のGTPコネクションを介して、シーケンシャル番号１（Seq：１）の退避CDR（Data  Record  Transfer  Request）を、CGF３０の障害処理部６０に再度送信する（Ｓ１０２２とＳ１０２３）。このときのData  Record  Transfer  Requestにも「Send  Data  Record  Packet」が設定される。
【０１３９】
その後、CGF３０の障害処理部６０は、受信したシーケンシャル番号１の退避CDRを記憶部３２のCDR格納ＤＢ３３に格納し（Ｓ１０２４とＳ１０２５）、受信応答のメッセージとしてData  Record  Transfer  ResponseをCDF１０に送信する（Ｓ１０２６とＳ１０２７）。
【０１４０】
そして、Data  Record  Transfer  Responseメッセージを受信したCDF１０は、退避ＤＢ１３から、転送済みであるシーケンシャル番号１の退避CDRを削除する（Ｓ１０２８）。このようにして、退避されていたCDR（退避CDR）の転送が、退避用のGTPコネクションを用いて実行される。その後のシーケンシャル番号：２以降の送信処理については、図７のＳ３１９からＳ３３４と同様なので、詳細な説明は省略する。
【０１４１】
［応答エラー］
図２０は、実施例４にかかる障害復旧後の応答エラー時の流れを示すシーケンス図である。図２０に示すように、Ｓ２００１からＳ２０１４までの処理は、図７のＳ３１０からＳ３１４までの処理と同様なので、詳細な説明は省略する。
【０１４２】
退避用のGTPコネクションが確立されると、CGF３０の障害処理部６０は、CDF１０に対し、「Saved  CDR  transfer  request」を設定したRedirection  Requestを送信する（Ｓ２０１５とＳ２０１６）。
【０１４３】
そして、CDF１０は、CGF３０からのRedirection  Requestの応答として、「Request  Accepted」を設定したRedirection  Responseを、CGF３０の障害処理部６０に送信する（Ｓ２０１７とＳ２０１８）。
【０１４４】
その後、CDF１０は、シーケンシャル番号１（Seq：１）の退避CDRに該当するData  Record  Transfer  Requestに、「Send  Data  Record  Packet」を設定し、退避用のGTPコネクションを介して、障害処理部６０に送信する（Ｓ２０１９とＳ２０２０）。
【０１４５】
続いて、CGF３０の障害処理部６０は、受信したCDRを記憶部３２のCDR格納ＤＢ３３に格納し（Ｓ２０２１とＳ２０２２）、受信応答のメッセージとして、「Request  Accepted」を設定したData  Record  Transfer  ResponseをCDF１０に送信する（Ｓ２０２３と２０２４）。ところが、転送途中で通信障害が発生し、CDF１０は、Data  Record  Transfer  Responseを受信できない。
【０１４６】
そして、障害が復旧すると（Ｓ２０２５）、CDF１０は、シーケンシャル番号１（Seq：１）のData  Record  Transfer  Requestの受信応答を受信していないことから、退避用のGTPコネクションを介して、シーケンシャル番号１（Seq：１）のCDR（Data  Record  Transfer  Request）を、CGF３０の障害処理部６０に再度送信する（Ｓ２０２６とＳ２０２７）。このときのData  Record  Transfer  Requestにも「Send  Data  Record  Packet」が設定される。
【０１４７】
その後、CGF３０の障害処理部６０は、受信したシーケンシャル番号１の退避CDRがすでに受信済みであることから破棄し（Ｓ２０２８）、受信応答のメッセージとして、「Request  already  fulfilled」を設定したData  Record  Transfer  ResponseをCDF１０に送信する（Ｓ２０２９とＳ２０３０）。
【０１４８】
その後のシーケンシャル番号：２以降の送信処理については、図７のＳ３１９からＳ３３４と同様なので、詳細な説明は省略する。
【０１４９】
［最後のCDRで送信エラー］
図２１は、実施例４にかかる退避CDRの最後でエラーが発生した時の流れを示すシーケンス図である。図２１に示すように、障害が発生してから最後の退避CDRを転送するまでの処理であるＳ３００１からＳ３０１１は、図７のＳ３０１からＳ３２５までの処理と同様なので、詳細な説明は省略する。
【０１５０】
その後、CDF１０は、最後のCDRである（Seq：Last）の退避CDRを退避CDRに該当するData  Record  Transfer  Requestに、「Last  Send  Data  Record  Packet」を設定し、退避用のGTPコネクションを介して、障害処理部６０に送信する（Ｓ３０１２とＳ３０１３）。
【０１５１】
続いて、CGF３０の障害処理部６０は、受信した最後の退避CDRを記憶部３２のCDR格納ＤＢ３３に格納する（Ｓ３０１４とＳ３０１５）。ここで、CGF３０の障害処理部６０は、退避CDR用のインスタンスデータ（シーケンス番号など）を解放する。
【０１５２】
そして、CGF３０の障害処理部６０は、受信応答のメッセージとして、「Request  Accepted」を設定したData  Record  Transfer  ResponseをCDF１０に送信する（Ｓ３０１６とＳ３０１７）。ところが、転送途中で通信障害が発生し、CDF１０は、Data  Record  Transfer  Responseを受信できない。
【０１５３】
そして、障害が復旧すると（Ｓ３０１８）、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」が設定される。
【０１５４】
その後、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」を設定する。
【０１５５】
その後、Data  Record  Transfer  Responseメッセージを受信したCDF１０は、退避ＤＢ１３から転送済みの最後の退避CDRを削除する（Ｓ３０２４）。そして、CGF３０の障害処理部６０は、退避用のGTPコネクションを切断し、リソースを解放する（Ｓ３０２５とＳ３０２６）。なお、Ｓ３０１７からＳ３０１８までの障害発生中に新たに発生した退避CDRに対しては、Ｓ３０２５の前に、実施例１と同様の手法で転送処理が実行される。
【０１５６】
［効果］
上述したように、退避CDRの送信処理でエラーが発生した場合であっても、エラーのタイミングに関わらず、退避エラーの送信を遅滞なく実行することができるとともに、シーケンシャル番号を遵守して送信することができる。
【実施例５】
【０１５７】
さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。
【０１５８】
［対応指示の指定］
上記実施例では、退避CDRの削除を指定する例を説明したが、これに限定されるものではない。例えば、退避CDRの取得開始時間の指定、複数のCGFが存在する場合に転送先のCGFを指定するなど、各種対応指示を指定することもできる。
【０１５９】
［CGFの冗長化］
例えば、CGFが冗長化されている場合に待機系のCGFを利用して退避CDRを取得する例を説明したが、退避用のGTPコネクションの代わりに、縮退時用のGTPコネクションを利用することもできる。この場合、待機系のCGFは、障害復旧後に、退避用のコネクションの確立を抑制し、通常時に確立される縮退時用のGTPコネクションのみを復旧させることもできる。
【０１６０】
［システム］
上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。また、実施例で説明した具体例、分布、数値などは、あくまで一例であり、任意に変更することができる。
【０１６１】
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散や統合の具体的形態は図示のものに限られない。つまり、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
【０１６２】
［ハードウェア］
図２２は、ハードウェア構成例を説明する図である。なお、CDF１０とCGF３０とは同様の構成を有するので、ここでは、情報処理装置１００として説明する。図２２に示すように、情報処理装置１００は、通信装置１０ａ、ＨＤＤ（Hard  Disk  Drive）１０ｂ、メモリ１０ｃ、プロセッサ１０ｄを有する。また、図２２に示した各部は、バス等で相互に接続される。
【０１６３】
通信装置１０ａは、ネットワークインタフェースカードなどであり、他のサーバとの通信を行う。ＨＤＤ１０ｂは、図３に示した機能を動作させるプログラムやＤＢを記憶する。
【０１６４】
プロセッサ１０ｄは、図２に示した各処理部と同様の処理を実行するプログラムをＨＤＤ１０ｂ等から読み出してメモリ１０ｃに展開することで、図３等で説明した各機能を実行するプロセスを動作させる。例えば、CDF１０を例にすると、このプロセスは、CDF１０が有する各処理部と同様の機能を実行する。具体的には、プロセッサ１０ｄは、イベント受付部２１、CDR生成部２２、CDR送信部２３、障害処理部２４等と同様の機能を有するプログラムをＨＤＤ１０ｂ等から読み出す。そして、プロセッサ１０ｄは、イベント受付部２１、CDR生成部２２、CDR送信部２３、障害処理部２４等と同様の処理を実行するプロセスを実行する。
【０１６５】
このように情報処理装置１００は、プログラムを読み出して実行することで制御方法を実行する情報処理装置として動作する。また、情報処理装置１００は、媒体読取装置によって記録媒体から上記プログラムを読み出し、読み出された上記プログラムを実行することで上記した実施例と同様の機能を実現することもできる。なお、この他の実施例でいうプログラムは、情報処理装置１００によって実行されることに限定されるものではない。例えば、他のコンピュータまたはサーバがプログラムを実行する場合や、これらが協働してプログラムを実行するような場合にも、本発明を同様に適用することができる。
【０１６６】
このプログラムは、インターネットなどのネットワークを介して配布することができる。また、このプログラムは、ハードディスク、フレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＭＯ（Magneto−Optical  disk）、ＤＶＤ（Digital  Versatile  Disc）などのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行することができる。
【符号の説明】
【０１６７】
１０  CDF
１１  通信部
１２  記憶部
１３  退避ＤＢ
２０  制御部
２１  イベント受付部
２２  CDR生成部
２３  CDR送信部
２４  障害処理部
２５  CDR退避部
２６  障害対応部
３０  CGF
３１  通信部
３２  記憶部
３３  CDR格納ＤＢ
４０  制御部
５０  通常処理部
５１  CDR受信部
５２  CDR処理部
６０  障害処理部
６１  プロトコル制御部
６２  CDR対応部
【図１】
2019213037.tif 000003
【図２】
2019213037.tif 000004
【図３】
2019213037.tif 000005
【図４】
2019213037.tif 000006
【図５】
2019213037.tif 000007
【図６】
2019213037.tif 000008
【図７】
2019213037.tif 000009
【図８】
2019213037.tif 000010
【図９】
2019213037.tif 000011
【図１０】
2019213037.tif 000012
【図１１】
2019213037.tif 000013
【図１２】
2019213037.tif 000014
【図１３】
2019213037.tif 000015
【図１４】
2019213037.tif 000016
【図１５】
2019213037.tif 000017
【図１６】
2019213037.tif 000018
【図１７】
2019213037.tif 000019
【図１８】
2019213037.tif 000020
【図１９】
2019213037.tif 000021
【図２０】
2019213037.tif 000022
【図２１】
2019213037.tif 000023
【図２２】
2019213037.tif 000024
【図２３】
2019213037.tif 000025