JP5709850B2 - 完全相関ｉｍｓ課金データ記録を生成する耐障害性の方法 - Google Patents

Description

本発明は、課金収集機能フェイルオーバ（ｆａｉｌｏｖｅｒ）の際に完全相関ＩＰマルチメディア・サブシステム（ＩＭＳ）課金データ記録を生成する耐障害性の方法および装置に関する。

本発明は特に電気通信の技術分野を対象としており、したがってそれに特に言及して説明するが、本発明は他の分野および応用例における有用性があり得ることを理解されたい。

背景として、人気を得ている通信ネットワークのタイプは、ＩＰマルチメディア・サブシステム（ＩＭＳ）ネットワークである。第３世代パートナーシップ・プロジェクト（３ＧＰＰ）に記載されているように、ＩＭＳは、様々なタイプのアクセス・ネットワークを可能にするネットワーク・アーキテクチャを有する共通コア・ネットワークを提供する。通信デバイスとＩＭＳネットワークの間のアクセス・ネットワークは、携帯用ネットワーク（例えば、ＣＤＭＡまたはＧＳＭ）、ＷＬＡＮ（例えば、ＷｉＦｉまたはＷｉＭＡＸ）、イーサネット・ネットワーク、または他のタイプの無線または有線アクセス・ネットワークであってもよい。ＩＭＳアーキテクチャは、ＩＰネットワークが、映像、音声およびデータを伝達するために最も費用削減したベアラ・ネットワークとなったので、インターネット・プロトコル（ＩＰ）ネットワーク上で通信デバイスにマルチメディア・サービスを提供するように、３ＧＰＰによって規定されている。サービス・プロバイダは、次世代ネットワーク進化においてこのアーキテクチャを許容している。

ＩＭＳネットワークでは、課金収集機能（ＣＣＦ）は、課金システムとして働き、コールおよびセッションに対するオフライン課金を行う。このオフライン課金は、様々なネットワーク要素（ＮＥ）によって送信される会計要求に基づいており、課金トリガ機能（ＣＴＦ）を実施している。ＮＥは、構成された課金トリガがＮＥで起こる場合、会計要求をＣＣＦに与える。ＣＣＦは、ダイアミタ（Ｄｉａｍｅｔｅｒ）会計要求（ＡＣＲ）メッセージを介してこれらの会計要求を得る。ＡＣＲメッセージは、ＣＣＦからＮＥ／ＣＴＦに送信される、会計回答（ＡＣＡ）メッセージによって認識される。ＡＣＡメッセージの受信の際、ＮＥ／ＣＴＦは、ＣＣＦに運ばれるメッセージの待ち行列からＡＣＲメッセージを取り除き、続いてＣＣＦに待ち行列内の次のメッセージを送信する。

ＩＥＴＦ ＲＦＣ ３５８８では、ダイアミタ・ベース・プロトコルはフェイルオーバ戦略を規定し、それによってダイアミタ・クライアント（この場合、ＮＥ／ＣＴＦ）は、タイムアウトして、認識（ＡＣＡ）を待つ可能性がある。会計サーバ（ＣＣＦ）があらゆる理由で応答していないことをクライアントが確立した場合、クライアントは会計の目的では別のＣＣＦノードである、ダイアミタ・ピアにフェイルオーバすることができる。これにより、１つのコールまたはセッションからの会計要求が２つ（以上）のＣＣＦにわたって分割されることにつながる。セッションに対するＡＣＲの完全セットは、単一のＣＣＦ上では利用可能ではない。この挙動は、標準仕様で説明およびサポートされている。例えば、セクション５．１．３．１．１６、不完全ＣＤＲ表示における、３ＧＰＰ ＴＳ ３２．２９８−８１０を参照のこと。

しかし、この分割の結果、各ＣＣＦは同じセッションに対して集約および相関課金データ記録（ＣＤＲ）を与え、セッションの異なる部分を含んでいる。これは、多数のＣＤＲが請求システムに現れ、それぞれ利用中であり、ＮＥからのセッション会計要求を処理する間に、セッションの一部を処理したＣＣＦによりもたらされるということを意味している。また、フェイルオーバがＣＣＦの完全な失敗により生じた場合、失敗した（１つまたは複数の）ＣＣＦで保持される記録は後まで利用可能ではない。ＣＣＦ機能停止、および請求システムにＣＤＲを提供する際の得られる遅延を説明することができるが、請求仲介システムの多くは、請求システムによる使用のために、同じセッションに関する２つ以上のＣＤＲを１つのＣＤＲにまとめることが可能ではない。このような仲介システムを使用した顧客は、不完全なＣＤＲを許容するのを拒否する可能性がある。これにより、収入漏出が生じる。加えて、同じセッションに対して２つ以上のＣＤＲを送信した結果、特にこれらのＣＤＲを請求システムに送信する間に遅延がある場合には、ＣＳＲに対する加入者待ち行列に潜在的につながる。というのは、それらは同じセッションまたはコールに対する二重（または三重）請求として認識される可能性があるからである。最後に、請求仲介は結局は不完全なＣＤＲを拒絶することになるので、ＣＣＦ失敗を処理するこのようなモードの結果、請求仲介システムへのリンク上に余分なトラフィックが生成され、非生産的である。

したがって、各セッションまたはコールが完全に相関されたＣＤＲを作り出すようにフェイルオーバを処理する必要性が存在する。

その開示を参照として本明細書に援用する、Ｓｈａｒｍａ他の「ネットワーク・ドメインにわたる請求記録の分配相関」という名称の２００９年４月１０日出願のＰＣＴ出願第ＰＣＴ／ＵＳ０９／４０１９７号が記載されている。ＰＣＴ出願第ＰＣＴ／ＵＳ０９／４０１９７号は、ＩＭＳドメインおよびパケット・ベアラ・ドメインなどの異なるネットワーク・ドメインに対して生成される請求記録を相関させる方法を記載している。

課金収集機能（ＣＣＦ）フェイルオーバの際に完全に相関された課金データ記録を生成する方法および装置が、提供される。

ＩＰマルチメディア・サブシステム（ＩＭＳ）ネットワーク内で会計要求（ＡＣＲ）メッセージを処理する方法が提供される。この方法は、第１の課金収集機能ノードによって受信されるセッションに対する任意のＡＣＲ［暫定］またはＡＣＲ［停止］に対して、対応するＡＣＲ［開始］が第１の課金収集機能ノードと一緒にない場合、ＡＣＲ［暫定］またはＡＣＲ［停止］が第１の課金収集機能ノードに関連する第１の不完全データベースに記憶されることを含んでいる。これらの会計要求に対する相関機能（「相関ホスト」）をホスティングする課金収集機能ノードが稼働中である場合、第１の課金収集機能ノードは、以下のとおり前記会計要求を処理する。第１の課金収集機能ノードが集約ＣＤＲを送信している場合、これらのＣＤＲは相関ホストの相関データベース内に書き込まれ、第１の課金収集機能ノードが第１の不完全データベースからＡＣＲを送信している場合、これらのＡＣＲは相関ホストの不完全データベース内に書き込まれる。第１および相関ホストの不完全データベース内の各セッションでは、以下のことが当てはまる。当該の課金収集機能ノードは、セッションに対する相関ホストであるが、セッションに対する会計開始または停止（または両方の）情報がなく、当該の課金収集機能ノードは相関ホストではないが、これらの記録を正しい相関ホストに、そのホストが非稼働中であるので送信することができない。

本発明の別の態様によると、ＡＣＲ処理方法はさらに、非稼働中課金収集機能ノードを回復させるステップと、以下の通りに回復させた課金収集機能ノードの対応する不完全データベースを処理するステップとを含むことができる。回復させた課金収集機能ノードが相関ホストでないＡＲＣメッセージでは、相関ホストを判断し、ホストの不完全データベースにメッセージを書き込む。回復させた課金収集機能ノードが相関ホストである回復させた課金収集機能ノードの不完全データベース内の懸案中のメッセージでは、課金収集機能ノードが回復されたことを示す「ノード・アライブ」メッセージをネットワーク内の他のノードにブロードキャストする。

本発明のさらに別の態様によると、ＡＣＲ処理方法はさらに、相関ホストが課金収集機能ノードであるかどうかを判断するために、第１の課金収集機能ノード上の常駐エージェントによって周期的評価を行うステップを含むことができる。相関ホストが課金収集機能ノードではない、課金収集機能ノード上の不完全データベース内の全てのメッセージでは、分配された相関アプローチ・アルゴリズムによって判断されるように、実際の稼働中相関ホストの不完全データベースにＡＣＲを書き込む。相関ホストが課金収集機能ノードではない、課金収集機能ノード上の不完全データベース内の全てのメッセージでは、次の評価サイクルに到達するまで、実際の相関ホストが非稼働中である場合に、不完全データベース内のＡＣＲまで待つ。課金収集機能ノード上の不完全データベース内の全てのメッセージでは、メッセージがＤＢ内にあり、適当な制御を行っていた時間を算出し、それによって最も古いメッセージが設定可能なデータベース・ウォーターマークを超える際に取り出され、このような取出しが、未処理記録にマーキングされたファイル・システムへの出力につながる。課金収集機能ノード上の不完全データベース内の全てのメッセージでは、メッセージが不完全データベース内にあり、適当な制御を行っていた時間を算出し、それによって古すぎて重要でないメッセージが、不完全データベースから取り出され、このような取出しが、未処理記録にマーキングされたファイル・システムへの出力につながる。課金収集機能ノードの不完全データベース内の残りのメッセージ全てでは、課金収集機能が相関ホストであると判断された場合に、全てのＡＣＲ［開始］およびＡＣＲ［停止］メッセージが不完全データベース内で利用可能であったかどうかをチェックし、そうである場合、集約および相関からなる通常の処理に進む。

本発明のさらに別の態様によると、ＩＰマルチメディア・サブシステム（ＩＭＳ）ネットワークでは、入力会計要求（ＡＣＲ）を処理するためのＩＭＳ課金システム・ノードが提供される。システム・ノードは、ＡＣＲメッセージを記憶するＡＣＲデータベースと、対応するＡＣＲ「開始」がＡＣＲデータベースに記憶されない場合、課金システム・ノードによって受信される任意のＡＲＣ［暫定］または［停止］を記憶する不完全データベースと、ＡＣＲを記憶するディスクと、ＣＤＲを集約させる第１の変換エンジンと、集約させたＣＤＲを記憶するＣＤＲ集約データベースと、ＣＤＲを相関させる第２の変換エンジンと、相関させたＣＤＲを記憶するＣＤＲ相関データベースと、相関させたＣＤＲを生成する第３の変換エンジンとを含んでおり、ＩＭＳ課金システム・ノードは、不完全ＣＤＲの生成を少なくするように、ＩＭＳネットワークにわたって他のＩＭＳ課金システムと協同するように動作可能である。

本発明の応用性のさらなる範囲は、以下に与える詳細な説明から明らかになるだろう。しかし、本発明の趣旨および範囲内の様々な変更形態および変形携帯は、当業者には自明のことであるので、詳細な説明および特定の例は、本発明の好ましい実施形態を示しているが、例示としてのみ与えられていることを理解されたい。

本発明は、デバイスの様々な部品、および方法のステップの構成、配置および組合せ内にあり、それによって考えられる対象は、これ以下により詳細に記載され、特許請求の範囲内で特に指摘され、添付の図面内で図示されているように達成される。

３ＧＰＰネットワーク用のオフライン課金アーキテクチャを示す図である。 ＣＤＲ生成プロセスの略図である。 ＣＣＦフェイルオーバの時間系列を示す図である。 本発明の態様による、改良型ＣＤＲ生成プロセスの略図である。

ネットワーク・インフラおよび関連サービスを利用するアクティビティが、「課金可能イベント」として知られている。課金可能イベントしては、例えば、（ａ）ユーザ間通信（例えば、単一コール、データ通信セッションまたはショート・メッセージ）、（ｂ）ユーザ／ネットワーク間通信（例えば、サービス・プロファイル管理）、（ｃ）相互接続ネットワーク通信（例えば、伝達コール、信号化、またはショート・メッセージ）、（ｄ）移動性（例えば、ローミングまたは相互接続システム・ハンドオーバ、および（ｅ）ネットワーク・オペレータが課金したいあらゆる他のアクティビティを挙げることができる。

「課金」は、それによって課金される当事者に請求することができる利用を判断することを可能にするために、課金可能イベントに関係する情報がフォーマット化され伝達される機能である。課金機能は必然的に、サービング当事者（加入者、ネットワークおよびコンテンツ・プロバイダ）の間での請求書の決済を含んでいる。ネットワーク利用の価格はまた、ローミングの場合にネットワーク・プロバイダ間で決済しなければならない。当事者（ユーザを含む）間の現金取引は普通、契約によって強制される。オフライン課金では、課金情報が請求後に収集され、したがって、加入者口座がサービス後に請求される。この情報はイベント／サービスの後に収集され、ネットワークを通して送信されるので、リアルタイム課金は普通は可能ではない。オンライン課金モードは、サービスが加入者がこれらに必要な金額を有する場合にのみ適用されることを保証する。

ＩＭＳネットワーク内のセッションへのオフライン課金を行うために、ＩＭＳネットワーク内のネットワーク要素が、セッションに対するダイアミタ会計要求（ＡＣＲ）メッセージを生成する。ネットワーク要素の例としては、サービング・コール・セッション制御機能（Ｓ−ＣＳＣＦ）、プロキシＣＳＣＦ（Ｐ−ＣＳＣＦ）、問合せＣＳＣＦ（Ｉ−ＣＳＣＦ）、マルチメディア・リソース機能コントローラ（ＭＲＦＣ）、アプリケーション・サーバ（ＡＳ）、メディア・ゲートウェイ制御機能（ＭＧＣＦ）、ブレークアウト・ゲートウェイ制御機能（ＢＧＣＦ）などが挙げられる。最初にセッションに関連している場合、ネットワーク要素はＡＣＲ［開始］メッセージを生成する。例えば、ＳＣＳＣＦがＳＩＰ ＩＮＶＩＴＥを受信してセッションを開始すると、その後、Ｓ−ＣＳＣＦはＡＣＲ［開始］メッセージを生成する。ネットワーク要素はその後、オフライン課金を助ける課金データ機能（ＣＤＦ）にＡＣＲ［開始］メッセージを伝達する。

次に、請求する主題を限定する目的ではなく、例示的な実施形態だけを示す目的で示されている図面を参照して、図１は３ＧＰＰネットワーク７０用のオフライン課金アーキテクチャを示している。図面では、同一の要素を示すために、同様の参照番号が全体を通して使用されている。

各ＩＭＳネットワーク要素（例えば、Ｐ−ＣＳＣＦ、Ｉ−ＣＳＣＦ、Ｓ−ＣＳＣＦ、ＢＧＣＦ、ＭＲＦＣ、ＭＧＣＦ、ＡＳ）は、課金トリガ機能（ＣＴＦ）７２を含んでいる。会計関連情報のほとんどが、これらのメッセージに含まれているので、オフライン課金機能は、様々なＳＩＰ方法またはＩＳＵＰメッセージの受信の際に会計情報を報告するＩＭＳネットワーク要素に基づいている。この報告は、ダイアミタ会計要求（ＡＣＲ）（開始、暫定、停止およびイベント）を各ＩＭＳネットワーク要素から課金データ機能（ＣＤＦ）７４に送信することによって達成される。ダイアミタ・クライアントは、成功するＳＩＰセッションに関連する手続きでＡＣＲ開始、暫定および停止を使用する。ダイアミタ・クライアントは成功しないＳＩＰセッション、およびセッション非関連手順にＡＣＲイベントを使用する。セッションに必要とされるネットワーク要素は、ＤＩＡＭＥＴＥＲ Ｒｆインターフェイスを使用して、会計情報を同じドメイン内に配置されたＣＤＦ７４に送信する。ＣＤＦ７４は、この情報全てを収集し、課金データ記録（ＣＤＲ）を構築し、これは課金ゲートウェイ機能（ＣＧＦ）７６を介して請求ドメイン（ＢＤ）７８に送信される。実際、ＣＤＦ７４およびＣＧＦ７６は、別の物理的要素内にある、または同じ物理要素内に一体化させることができる。共に、ＣＤＦおよびＣＧＦは、課金収集機能（ＣＣＦ）８０と呼ばれる。各セッションは、ＩＣＩＤ（ＩＭＳ課金識別子）を固有識別子として運ぶ。各ドメインは、その独自の課金ネットワークを有する。また、課金システムは異なるドメイン内で情報を交換し、それによってローミング課金を行うことができる。

セッションが確立された後に、ネットワーク要素はＡＣＲ［暫定］メッセージをＣＤＦ７４に周期的に伝達する。ネットワーク要素は、５分毎などの所定のインターバルにしたがって、またはサービスまたはメディアの変更の際に、ＡＣＲ［暫定］メッセージをＣＤＦ７４に伝達する。サービスまたはメディア変更は、所定のインターバルで設定されたタイマによって駆動される周期的「心拍」機構に対して、セッション中のあらゆる時に起こる可能性がある。ネットワーク要素が、ＳＩＰ ＢＹＥメッセージを受信することなどによって、セッションが終了したのを検出すると、その後、ネットワーク要素はＡＣＲ［停止］メッセージを生成する。ネットワーク要素はその後、ＡＣＲ［停止］メッセージをＣＤＦ７４に伝達する。

ＣＤＦ７４が最初にネットワーク要素からＡＣＲ［開始］メッセージを受信すると、ＣＤＦ７４はそのネットワーク要素用のセッションに対して課金データ記録（ＣＤＲ）を開く。ＣＤＦ７４はその後、ＡＣＲ［暫定］内の課金情報に基づいて、ネットワーク要素からＡＣＲ［暫定］メッセージを受信するたびに、開いたＣＤＲを更新する。この更新は、インターバル・タイマのリフレッシュ、および部分的セッション情報を捕捉する「部分的ＣＤＲ」の生成を必要とする可能性がある。セッションが終了すると、ＣＤＦ７４は、会計要求を送信する各ネットワーク要素からＡＣＲ［開始］メッセージを受信し、その後、ＣＤＦ７４はそのネットワーク要素用のセッションに対してＣＤＲを閉じる。

ＣＤＦ７４がネットワーク要素に対して不完全ＣＤＲを生成する例がある可能性がある。ＣＤＦ７４が最初にＡＣＲ［開始］メッセージをネットワーク要素から受信すると、ＣＤＦ７４はタイマを開始させ、会計暫定インタインターバルＡＶＰと呼ばれる属性値対（ＡＶＰ）を介してＮＥ／ＣＴＦにタイマの値を通信する。ＡＶＰ内に設定された値に基づいて、ＮＥ／ＣＴＦは、セッションに対する心拍として会計暫定メッセージを周期的に送信するために必要である。タイマを開始させた後に、ＣＤＦ７４がタイマの終了前にネットワーク要素からＡＣＲ［停止］メッセージを受信した場合、その後、ＣＤＦ７４はセッションに対してＣＤＲを閉じて、完全ＣＤＲを生成する。しかし、不時のシナリオでは、ＤＣＦ７４は、タイマの終了前にネットワーク要素からＡＣＲ［暫定］メッセージまたはＡＣＲ［停止］メッセージを取得しない可能性がある。この場合、ＣＤＦ７４はＣＤＲを閉じて、セッションに対して「不完全ＣＤＲ」を生成する。

ＣＤＦが完全または不完全ＣＤＲを生成するいずれの場合でも、セッションの終わりのある点で、セッションに対するＣＤＲは、請求システムに提示されるように集約および相関される。これに関して、次に、請求仲介システムに対する相関ＣＤＲに変換されるまで、入力ＡＣＲメッセージの処理段階の概略を与える図２を参照する。処理は、１つのＣＣＦノード上で行われる。

図２は、入力ＡＣＲの一般処理シーケンスを示している。ＡＣＲが存在する全ての必須パラメータで正確にフォーマット化されることが保証された後に、ディスク（８４）上でファイル上に書き込まれる前に、ＡＣＲは効率の理由（８２）でメモリ内データベース（ＤＢ）内に記憶される。ＡＣＲ［暫定］メッセージが受信されると、ＣＤＦ７４は部分ＣＤＲを生成し、これは変換処理ステップ（８６）内の集約のために変換される前に、集約ＤＢ（８８）に記憶される。セッションが終了すると、セッション終了インジケータが、Ｓ−ＣＳＣＦからのＡＣＲ［停止］メッセージの受信によって与えられ、例えば、ＣＤＦ７４は、集約データベース８８内の各ネットワーク要素（あれば）に対してＣＤＲを集約（８６）させる。本明細書で使用される場合、「集約」は、セッションに対してネットワーク要素用の部分ＣＤＲを識別し、これらの部分ＣＤＲを共に組み合わせるために行われる動作のことを言う。ＣＤＦ７４はその後、相関させる目的で、相関ホストにネットワーク要素全て用の集約ＣＤＲを伝達する。本明細書で使用される場合、「相関」とは、セッションをサービングする各ネットワーク要素用の完全および不完全ＣＤＲを識別し、セッションに対して単一の統一ＣＤＲを生成するためにＣＤＲを組み合わせるために行われる動作のことを言う。

相関ホストは、ＩＭＳ課金識別子（ＩＣＩＤ）を介して結合された所与のセッションに対して広まったＣＤＲを識別し、セッションに対して統一ＣＤＲを生成（９０）する。統一ＣＤＲはしたがって、ＩＭＳネットワーク内でセッションをサービングした、各ネットワーク要素用の課金情報を含んでいる。統一ＣＤＲはＣＧＦ７６に伝達され、統一ＣＤＲに持続型記憶を与え、その後、統一ＣＤＲを請求ドメイン７８に伝達して、セッションに対する請求を行う。したがって請求ドメイン７８はその後、ＣＧＦ７６から単一の統一ＣＤＲを受信する。

ＩＭＳネットワークは、セッションをセットアップおよび維持するためのコア・ネットワークであるので、ＩＭＳネットワークはセッション用の信号化ドメインであると考えられる。ベアラ・ドメインはまた、セッション内に必要である可能性がある。例えば、ＩＭＳ音声コールでは、音声コール用のアクセス・ネットワークは、汎用パケット無線サービス（ＧＰＲＳ）ネットワーク、ユニバーサル・モバイル・テレコミュニケーション・システム（ＵＭＴＳ）ネットワークなどであってもよい。コールの信号化部分は、ＩＭＳネットワーク上で処理され、ベアラ部分はＧＰＲＳネットワーク上でリアルタイム・プロトコル（ＲＴＰ）セッションとしてセットアップすることができる。ＩＭＳネットワークは、時間ベースである典型的なＲＴＰセッションに対して課金することが可能であるが、ベアラ・ネットワークならびに、信号化ネットワークからの課金情報を取得することが望ましい他の例がある。例えば、音声コール中に、コールに対する当事者は、ＧＰＲＳネットワーク上で映像をダウンロードすることがある。セッションの時間に加えて、映像ダウンロードのデータ・フローに対して課金することが望ましい可能性がある。したがって、異なるネットワーク・ドメインからの課金記録につながるＩＭＳドメインだけでなく、ＣＤＦに会計メッセージを提供する多数のドメインがあってもよい。

典型的な相関動作中に、ＣＣＦ８０はセッションに対するＩＣＩＤに基づいてＣＤＲを相関させる。典型的には、ＣＣＦ８０は、集約および相関を行うために、商業利用可能なデータベースを実行する商業利用可能なサーバを含んでいる。

標準仕様により、同じセッションに対する会計要求が２つ以上のＣＣＦの間で分割されるときに、記録クロージャの理由として適当な注釈でのＣＤＲのクロージャが可能になる。会計セッションは、ＡＣＲ［開始］で始まり、ＡＣＲ［停止］で終わる。これらの間に、１つまたは複数のＡＣＲ［暫定］メッセージがあってもよく、これらはＣＣＦとＣＴＦの間で交渉されるタイマの終了の際に、または請求する目的でＣＣＦがこのような変化の主な原因であることが必要とするメディアまたはサービスの変化によって生成される。フェイルオーバの場合、ＡＣＲ［開始］およびＡＣＲ［停止］は異なるＣＣＦで終了する可能性が高い。例えば、ＡＣＲ［開始］を得たが、対応するＡＣＲ［停止］、または適時のＡＣＲ［暫定］を得ないＣＣＦは、「紛失ＡＣＲ［停止］」としてマーキングされたクロージャの理由でＣＤＲを閉じる。同様に、ＡＣＲ［停止］に到達するが、対応するＡＣＲ［開始］がないＣＣＦは、「紛失ＡＣＲ［開始］」としてマーキングされたクロージャの理由でＣＤＲを閉じる。第３の例は、セッションに対してＡＣＲ［暫定］を受信するが、ＡＣＲ［開始］もＡＣＲ［停止］も受信しないＣＦＦであってもよく、この場合、ＡＣＲ［開始］およびＡＣＲ［停止］は紛失としてマーキングされる。これは、標準仕様の挙動である。実際、不完全ＣＤＲ表示は以下の表示を含むことができる。

Incomplete-CDR-Indication SET
{
aCRStartLost [0] BOOLEAN,-- TRUE if
ACR[Start] was lost, FALSE otherwise
aCRlnterimLost [1] ACRInterimLost,
aCRStopLost [2] BOOLEAN -- TRUE if
ACR[Stop] was lost, FALSE otherwise
}

このアプローチの欠点としては、例えば、セッションに対する２つ以上のＣＤＲの生成、請求仲介システムによって「不完全」としてマーキングされる生成ＣＤＲの拒絶、収入の一貫した漏出、同じコール／セッションに対する個別のＣＣＦノードでの処理際の増加、ＣＣＦと請求仲介システムの間のトラフィックの増加が挙げられる。

単一の失敗の状況は、以下のテキストライン図で説明することができる。

A: CTF → ACR[Start] → CCF1
CTF ← ACA ← CCF1
B: CTF → ACR[Interim] → CCF1
ACA タイムアウト／反応なし＿CCF1失敗！
C: CTF → ACR[Interim] → CCF2
CTF ← ACA ← CCF2
D: CTF → ACR[Stop] → CCF2
CTF ← ACA ← CCF2

上の点Ａで、ＮＥ／ＣＴＦは、ＩＣＩＤ１でセッションに対する会計開始を送信することによって、ＣＣＦ１として特定されるＣＣＦでダイアミタ・ダイアログをセットアップする。ＡＣＡ応答は、ＣＴＦがＡＣＲ［暫定］メッセージを介して報告を返すために心拍周波数を判断する、全てのＡＩＩＡＶＰを伝える。

上の点Ｂで、ＣＴＦは心拍メッセージでＣＣＦ１に戻る。しかし、この時、ＣＣＦ１は非稼働中であり、メッセージには応答しない。ＣＴＦは、ＣＣＦ１に設定可能な回数に対するＡＣＲ［暫定］を送信することを再試行することができるが、最後にあきらめる。

上の点Ｃで、ＣＴＦはＣＣＦ２として特定される別のＣＣＦにフェイルオーバし、ＩＣＩＤ１を運ぶ会計メッセージＡＣＲ［暫定］をこれに送信する。ＣＣＦ２は、確認（ＡＣＡ）で応答する。（ＩＣＩＤ１によって示される）同じセッションに対して、会計要求は次に、２つのＣＣＦ、ＣＣＦ１およびＣＣＦ２にわたって分割され、これらのうち、ＣＣＦ１は次に非稼働になることに留意されたい。

上の点Ｄでは、ＣＴＦはＩＣＩＤ１を運ぶＡＣＲ［停止］の送信によるセッションの終了を示しており、ＣＣＦ２から確認を得る。

したがって、結果として、オンラインに戻る場合にＣＣＦ１で不完全ＣＤＲ（許容できない）、およびＣＣＦ２で不完全ＣＤＲ（許容できない）である。

同様に、二重の失敗は以下に記載したように説明することができる。

A: CTF → ACR[Start] → CCF1
CTF ← ACA ← CCF1

B: CTF → ACR[Interim] → CCF1
ACA タイムアウト／反応なし＿CCF1失敗！

C: CTF → ACR[Interim] → CCF2
CTF ← ACA ← CCF2

D: CTF → ACR[Interim] → CCF2
ACA タイムアウト／反応なし＿CCF2失敗！

E: CTF → ACR[Interim] -→ CCF3
CTF ← ACA ← CCF3

F: CTF → ACR[Stop] → CCF3
CTF ← ACA ← CCF3

直ぐ上のステップＡ、ＢおよびＣは、前の例で見られるものと同一である。ステップＤは、ＣＣＦ（ＣＣＦ２）へのフェイルオーバも失敗し、その結果、ステップＥでＣＦＴが第３のＣＣＦ（ＣＣＦ３）に第２のフェイルオーバを行っていることを示している。ステップＦは、セッション完了表示を示している。

この第２の場合での結果は、オンラインに戻る場合にＣＣＦ１およびＣＣＦ２で不完全ＣＤＲ（許容できない）、およびＣＣＦ３で不完全ＣＤＲ（許容できない）である。

典型的なＣＤＲ生成プロセスは、有限状態機械として定式化することができ、ＣＤＲは、会計要求開始すなわちＡＣＲ［開始］の受信の際に「開かれる」または「開始され」、ＣＤＲは、ＡＣＲ［暫定］が受信されるたびに更新され、セッション関連のＣＤＲでは、ＣＤＲは会計停止要求すなわちＡＣＲ［停止］の受信の際に終了する。ＣＣＦは、入力ＡＣＲを処理して、これらのメモリ内データベースに、その後にディスク・ベースＤＢに記憶する。

次に、ＡＣＲメッセージを異なるＣＣＦ（ＣＣＦ１、ＣＣＦ２、ＣＣＦ３）に送信する１対のＮＥ（ＮＥ−１、ＮＥ−２）を示す、図３に示された図によりフェイルオーバの時間系列を検討する。系列は以下の通りである。
１．Ｔ＝１でのセッション開始の際、ＣＣＦ１およびＣＣＦ３は、ＮＥ−１およびＮＥ−２からＡＣＲをそれぞれ受信し始める。
２．ＣＣＦ１はＴ＝２で失敗する。ＮＥ−１は、２〜３回の連続した試みで、そのＡＣＲに対するＡＣＡを得ない。ＮＥ−１はＣＣＦ２へのフェイルオーバを実行する。ＣＣＦ２は、例えば２：２０で、２：０５のタイムスタンプで第１のＡＣＲを得る。
３．Ｔ＝５では、ＣＣＦ１が回復する。
４．Ｔ＝７では、セッションが終了する。

図３に関して、ＮＥ−１は、Ｔ=２の後のどこかでＣＣＦ２にフェイルオーバすると考えることができる。これにより、典型的には、それぞれＣＣＦ１（回復した場合）およびＣＣＦ２から、ＮＥ−１に対する２つ以上の集約ＣＤＲが生成される。ＮＥ−２から受信される会計要求に基づいて、ＣＣＦ３によって生成される第３の集約ＣＤＲがある。最後に、相関させたＣＤＲは選択的に、集約ＣＤＲを完全セッションを示すＣＤＲに折り畳む。この相関させたＣＤＲは、請求に使用される。

ＣＣＦ１は、Ｔ＝７でのセッション停止より早い、Ｔ＝５で回復することに留意されたい。これは、全ての場合に当てはまる、または当てはまらないこともある。また、本発明でなければ、得られる相関ＣＤＲは、ＣＣＦ１でのセッション会計を考慮せず、（ＣＣＦ２とＣＣＦ３の間の）１つの不完全な相関ＣＤＲ、およびＣＣＦ１からの（集約された可能性のある）不完全ＣＤＲにつながる可能性が高いことに留意されたい。

したがって、本発明は、相関処理のネットワーク規模の視野を導入することによって、ＡＣＲをＣＤＲに処理するための基本的ワークフローを改善し、ＣＣＦは、なくさない場合でも、「不完全ＣＤＲ」の生成を少なくするように互いに共同することができる。

このネットワーク規模の共同は、紛失開始または停止でセッションの一部を示す会計要求を保持する、ネットワーク内に新しい「不完全ＡＣＲ」データベースを組み込むことによって部分的に達成される。２つのノードを考えると、図４の図は、本発明の例示的な実施形態の概略を与えている。

図４の水平線１０２は、２つの異なる物理的に別のサーバ上で適切に実施される、２つのサーバＣＣＦ−１とＣＣＦ−２の間の分離を示している。相関を実行するための分配処理アプローチを仮定すると、ＩＣＩＤは、会計要求の処理を描くためのキーとして選択することができる。要するに、サーバ上の受信ＡＣＲメッセージは、異なるサーバまたは同じサーバ上の相関処理を意味することができる。

ＣＣＦノードによって受信されるあらゆるＡＣＲ［暫定］または［停止］では、対応するＡＣＲ［開始］がノードと一緒にない場合、ＡＣＲは新しいデータベース、すなわちＩｎｃ＿ＤＢ １０４−ｎ（不完全ＡＣＲデータベース用）に置かれる。継続しているセッションに関連する全ての他のＡＣＲメッセージでは、メモリ内ＡＣＲ ＤＢ８２−１、したがってディスク・ベースＡＣＲ ＤＢ８４−１が利用される。このような「通常」会計メッセージでは、集約および相関のプロセスは普通変わらないままである。

上で参照した「ネットワーク・ドメインにわたる請求記録の分配相関」は、ＩＣＩＤ値に基づいて、相関ホスト間のセッション分配を行う。要約すると、このように分配されたアーキテクチャは、集約ＣＤＲが生成されるまで、各ＣＣＦサーバにＡＣＲメッセージを受信および処理させる。実行の際にこの点に到達すると、サーバはＣＤＲに対する相関ホストを判断するアルゴリズムを使用することができる。その最も単純な実施形態では、ネットワーク内にＮ個のＣＣＦサーバがある場合、（ＩＣＩＤ ＭＯＤ Ｎ）は相関ホストを判断することができる。アルゴリズムからの結果は、相関ホスト機能のために、同じサーバまたは異なるサーバに向いている可能性がある。

Ｉｎｃ＿ＤＢ−ｎ内の各サーバＣＣＦ−ｎ上に集積されたメッセージでは、相関ホストがＣＣＦ−ｎであるかどうかを判断するために、サーバ上のエージェントによる周期的な評価がある。相関ホストがＣＣＦ−ｎでない、ＣＣＦ−ｎ上のＩｎｃ＿ＤＢ−ｎ内の全てのメッセージでは、メッセージは、分配された相関アプローチ・アルゴリズムによって判断されるように、対応する相関ホストＣＣＦ−ｍのＩｎｃ＿ＤＢ−ｍに書き込まれる。相関ホストＣＣＦ−ｍがたまたま非稼働である場合、設定可能な期間、記録が設定可能な期間ＣＣＦ−ｎ内に留まる。その後の評価により、利用可能性に関するこれらの記録を正しい相関ホストに移動させようとする。

サーバＣＣＦ−ｎ内のＩｎｃ＿ＤＢ−ｎ内の全ての残りのメッセージでは、ＣＣＦ−ｎが相関ホストであると判断された場合、評価サイクルはまた、全ての会計開始および停止メッセージが、正確な相関ＤＢオーナー／ホスト内への記録の周期的移動の場合と同様に、Ｉｎｃ＿ＤＢ−ｎ内で利用可能にされたかどうかをチェックする。ＣＣＦ−ｎが相関ホストである、特定された会計開始および停止メッセージを両方とも有するセッションは、相関機能実行に進む。このような記録は、（必要に応じて）集約およびその後の相関を行う変換エンジンにより、ファイナライズされ、通常処理に送信される。

以下の実施形態は、前に概要を説明した「Ｉｎｃ＿ＤＢ」強化に基づくものであり、分配された相関アプローチを使用する。本実施形態では、不完全記録が、適当なＩｎｃ＿ＤＢ内に最大（設定可能）時間の間保持される。失敗ＣＣＦノードがその時間内で復活させることができると仮定すると、記録の集約および相関は、請求システムに完全記録に関して与えることができる。

本実施形態は、以下に説明するようにＡＣＲの処理を変更する。
１．ＣＣＦノードによって受信されるあらゆるＡＣＲ［暫定］または［停止］では、対応するＡＣＲ［開始］がノードと一緒にない場合、ＡＣＲは新しいデータベース、すなわちＩｎｃ＿ＤＢ（不完全データベース用）内に置かれる。
２．このＩｎｃ＿ＤＢは、このＣＣＦノード上では集約および相関プロセスに触れられない。
３．加入者セグメンテーション／分配データベース・スキームに基づいて、ｆ（ＩＣＩＤ）に基づく、これらの記録の相関に対して１つのオーナーがある可能性がある。
４．これらの記録用のホストが稼働中である場合、記録は以下のように正確なホストに書き込まれる。
４ａ．送信ＣＣＦが集約ＣＤＲを送信している場合、その後、これらのＣＤＲは正確なホストの相関ＤＢ内に書き込まれる。
４ｂ．送信ＣＣＦがＩｎｃ＿ＤＢから記録を送信している場合、これらは相関ホストのＩｎｃ＿ＤＢに書き込まれる。
５．この時、セッションに対する開始または停止のいずれかがないので、各ＣＣＦは、完全ＣＤＲを生成するために処理することができない、Ｉｎｃ＿ＤＢ内にいくつかのＡＣＲメッセージを有すると仮定することができる。
６．各ＣＣＦノード内のＩｎｃ＿ＤＢの各記録／セッションでは、以下のことが当てはまる。
６ａ．当該のＣＣＦノードは、セッション用の相関ホストであるが、セッション開始または停止（または両方）の情報がない。
６ｂ．当該のＣＣＦノードは相関ホストではないが、ホストが非稼働中（ＯＯＳ）であるので、これらの記録を正確な相関ホストに送信することができない。

これは、定常状態である。すなわち、セッション全体を捕捉することができない、または相関ホストとしてこのホストを有していないいずれかであるので、「不完全ＤＢ」は、「不完全ＤＢ」ホスト上でファイナライズすることができない記録を保持する。

ＯＯＳ ＣＣＦが回復する場合に、第２の強化がここで行われる。この強化は、待機しているノードに、ＣＣＦが回復させたＣＣＦから他のＣＣＦに「自分はアライブである」というメッセージ／心拍を送信することによって再び稼働されることを分からせるためである。

定常状態では、Ｉｎｃ＿ＤＢ内に記録を備えたいくつかのＣＣＦがあることに留意されたい。各ＣＣＦは、ＡＣＲを送信または受信するいずれかのために待機しており、その結果、終了ＣＤＲとなる。
（ａ）当該のＣＣＦが相関ホストである場合、これらの記録を有するＣＣＦによって、残りのＡＣＲがＩｎｃ＿ＤＢに送信されるのを待っている。または、
（ｂ）ＣＣＦが相関ホストである場合、相関ホストが再び稼働するのを待っており、それによって、これらの記録を集約／相関の目的で正確なＣＣＦに送信することができる。

いずれの場合でも、Ｉｎｃ＿ＤＢ内の記録がＩｎｃ＿ＤＢ内にある「Ｎ」時間後、またはＩｎｃ＿ＤＢがＰ％フル（別の設定可能パラメータ、たとえば８０％）になるまでの、いずれか後に起こる時点で削除され、Ｉｎｃ＿ＤＢでの関連する監査プロセスが、設定可能タイマおよび／またはＩｎｃ＿ＤＢ充てん率で作用する。これは、Ｉｎｃ＿ＤＢ内の記録が、損失ＣＣＦの回復のためにＮ時間まで待機することができるということである。このパラメータを適切に調節し、ＣＣＦサーバに対するＭＴＴＲを検討することによって、ネットワーク・オペレータは、この解決法を使用した場合に、「不完全ＣＤＲ」に関連する問題を実質的になくすことができる。

ＯＯＳ ＣＣＦを復活させた場合、最初にその独自のＩｎｃ＿ＤＢを処理し、その後、以下のことを行う。
１．Ｎ時間より古いＩｎｃ＿ＤＢ内のメッセージでは、これらのＡＣＲは古く、いずれの場合でも不完全ＣＤＲにつながる可能性が高い。このようなＡＣＲを他のノードに送信する、または他のノードからの相補的セッション情報を待つこと無駄である。このようなＡＣＲは「損失」ＤＢに出力することができる。最悪の場合のＣＣＦ回復時間を処理するために「Ｎ」の大きな値を入れることによって、損失記録がない、または「損失」ＤＢに対する必要がないことに留意されたい。
２．Ｉｎｃ＿ＤＢ内の残りのメッセージでは、復活させたＣＣＦが相関ホストである、または復活させたＣＣＦがある他のノード用にこれらのメッセージを保持しているだけである場合に、メッセージの組合せがある。
３．復活させたＣＣＦが相関ホストでないメッセージでは、相関ホストを判断し、ｆ（ＩＣＩＤ）として正確に特定されたＣＣＦのＩｎｃ＿ＤＢにメッセージを書き込む。
４．Ｉｎｃ＿ＤＢ内にさらにペンディングのメッセージがある場合、復活させたＣＣＦはこのようなメッセージ用の相関ホストであると仮定することができる。対応するセッション用のＡＣＲはネットワーク内の残りのＣＣＦのいずれかと一緒である可能性があるので、このＣＣＦは「自分はアライブである」というメッセージをネットワーク内の他のノードにブロードキャストする。
５．メッセージは、このＣＣＦに対してＩｎｃ＿ＤＢ内に保持している記録を送信するように、他のＣＣＦに促す。
６．「自分はアライブである」というメッセージは、ＣＣＦ回復後に３〜４回送信して、（可能性は低いが）メッセージを読み損ねたあらゆるノードを補償することができる。

定常状態では、「自分はアライブである」というメッセージのブロードキャストは必要ではないことに留意されたい。ＣＣＦノードは、そのＤＢ（Ｉｎｃ＿ＤＢまたは相関ＤＢ）内に書き込もうと試みる際に、他のＣＣＦがＯＯＳであるかどうかを判断することができる。

また、ＣＣＦが他のＣＣＦに「誰がＩＣＩＤ＝ｘｙｚ？に対する記録を持っているのか」活動的および積極的に質問しないことに留意されたい。これにより、多くのネットワーク・トラフィックおよび処理負荷が作り出される。代わりに、各ＣＣＦは、特定の相関ホストに属するＡＣＲ（またはＣＤＲ）を忠実に転送する。サーバ・フェイルオーバによる相関の遅延処理は、請求システムへの非リアルタイムでの記録の伝達につながる。本発明はここでは、「不完全ＣＤＲを避けるための遅延クロージャ」として「記録クロージングの原因」（３ＧＰＰ ＴＳ ３２．２９８ ８１０、セクション５．１．３．１．８）に対する新しい値の使用を含んでいる。

したがって、本発明はたとえば、請求システムが不完全ＣＤＲを拒絶することができるので潜在的な収入漏出の防止を助け、利用可能なときはいつでも処理し、その後に拒絶の危険（二重損失、第１にＣＰＵ処理サイクルの意味で、第２に請求システムによりどっちにしても拒絶されること）を冒す代わりに、全ての記録が利用可能である場合に後の段階にこれを延期することによって処理を最適化し、請求仲介への請求記録への輸送の際に最適化し、同じセッションに対する２つ以上の不完全ＣＤＲの送信を避ける。

本明細書に記載されたネットワーク要素は、１つまたは複数のプロセッサ・ベース・デバイスにある。これらのデバイスは、本明細書に記載され、普通は３ＧＰＰ／３ＧＰＰ２無線システムに関連する機能を実施するためにプログラムを実行する。これらのプロセッサ・ベース・システムの可撓性により、本発明の態様によるＣＣＦフェイルオーバの際に、完全に相関させたＣＤＲを生成する方法のこれらのシステム内への即時の一体化が可能になる。しかし、本明細書で利用される場合、「プロセッサ」という用語は、ソフトウェアを実行することが可能なハードウェアのみのことを言うことを意図したものではないことに留意されたい。

上記説明は単に、本発明の特定の実施形態の開示を行うものであり、これに限ることを目的とすることを意図したものではない。したがって、本発明は上記実施形態のみに限るものではない。むしろ、当業者は本発明の範囲内に含まれる代替実施形態を考えることができることが分かる。

Claims (14)

1. ＩＰマルチメディア・サブシステム（ＩＭＳ）ネットワーク内で会計要求（ＡＣＲ）メッセージを処理する方法であって、
   課金収集機能ノードによって受信される、セッションに対するＡＣＲ［暫定］またはＡＣＲ［停止］メッセージについて、対応するＡＣＲ［開始］メッセージが前記課金収集機能ノードに記憶されていない場合、前記ＡＣＲ［暫定］またはＡＣＲ［停止］メッセージは、前記課金収集機能ノードに関連する不完全データベース内に記憶されることと、
   前記ＡＣＲに対する相関機能をホスティングする前記課金収集機能ノード（「相関ホスト」）が稼働中である場合、前記課金収集機能ノードは以下の一方のように前記ＡＣＲを処理すること、すなわち、
   前記課金収集機能ノードが前記相関ホストに集約ＣＤＲを送信している場合、その後、前記ＣＤＲは前記相関ホストの前記相関データベース内に書き込まれること、または
   前記課金収集機能ノードが前記不完全データベースから前記相関ホストにＡＣＲを送信している場合、その後、前記ＡＣＲは前記相関ホストの前記不完全データベースに書き込まれること、
   を含み、
   非稼働中の前記課金収集機能ノードが回復した場合、前記回復した課金収集機能ノードの対応する不完全データベースを以下の通り処理するステップ、すなわち、
   前記回復した課金収集機能ノードが前記相関ホストでないＡＣＲメッセージについて、前記ネットワーク内の複数の課金収集機能ノードの中から前記相関ホストを判断し、前記ホストの前記不完全データベースに前記ＡＣＲメッセージを書き込むステップと、
   前記判断し書き込むステップで処理されなかった、前記回復した課金収集機能ノードの前記不完全データベース内のペンディングのメッセージについて、前記不完全データベース内にペンディングのメッセージがあることから前記回復させた課金収集機能ノードは前記相関ホストであって、前記課金収集機能ノードが回復したことを示す「ノード・アライブ」メッセージを前記ネットワーク内の他のノードにブロードキャストするステップと
   をさらに含む、方法。
2. 前記「ノード・アライブ」メッセージが、前記回復させた課金収集機能ノードに対する独自の不完全データベース内に記憶している前記記録を送信するように、他の課金収集機能ノードに促す、請求項１に記載の方法。
3. 前記「ノード・アライブ」メッセージは、前記課金収集機能ノードが回復後に少なくとも３回送信されて、メッセージを読み損ねたあらゆる他の課金収集機能ノードに受信される、請求項２に記載の方法。
4. 第１の課金収集機能ノード上の常駐エージェントによって周期的評価を行うことで、前記相関ホストが前記第１の課金収集機能ノードであるかどうかを判断するステップと、
   前記相関ホストが前記第１の課金収集機能ノードではない、前記第１の課金収集機能ノード上の前記不完全データベース内のメッセージについて、実際の稼働中相関ホストの不完全データベースにＡＣＲを書き込むステップと、
   前記相関ホストが前記第１の課金収集機能ノードではない、前記第１の課金収集機能ノード上の前記不完全データベース内のメッセージについて、実際の相関ホストが非稼働中である場合に、前記不完全データベース内のＡＣＲを次の評価サイクルが到達するまで保持するステップと、
   前記第１の課金収集機能ノード上の前記不完全データベース内のメッセージについて、前記メッセージが前記不完全データベース内にあった時間を算出し、それによってタイマおよび／または不完全データベースの充てん率が設定可能な値を超える際に最も古いメッセージが取り出され、このような取り出しが、損失データベースへの出力につながるステップと、
   前記第１の課金収集機能ノード上の前記不完全データベース内のメッセージについて、前記メッセージが前記不完全データベース内にあった時間を算出し、それによって古すぎて重要でないメッセージが、前記不完全データベースから取り出され、このような取り出しが、損失データベースへの出力につながるステップと、
   前記第１の課金収集機能ノードの前記不完全データベース内の残りのメッセージについて、前記第１の課金収集機能ノードが前記相関ホストであると判断された場合に、ＡＣＲ［開始］およびＡＣＲ［停止］メッセージが前記不完全データベース内で利用可能であったかどうかを判断し、そうである場合、集約および相関の処理に進むステップとをさらに含む、請求項１に記載の方法。
5. 前記課金収集機能ノードが、３ＧＰＰ課金データ機能（ＣＤＦ）および課金ゲートウェイ機能（ＣＧＦ）を含んでいる、請求項１に記載の方法。
6. 前記ＣＤＦおよびＣＧＦが別の物理的要素内にある、請求項５に記載の方法。
7. 前記ＣＤＦおよびＣＧＦが同じ物理要素内に一体化される、請求項５に記載の方法。
8. ＩＰマルチメディア・サブシステム（ＩＭＳ）ネットワーク内で会計要求（ＡＣＲ）メッセージを処理するためのシステムであって、
   課金収集機能ノードによって受信される、セッションに対するＡＣＲ［暫定］またはＡＣＲ［停止］メッセージについて、対応するＡＣＲ［開始］メッセージが前記課金収集機能ノードに記憶されていない場合、前記ＡＣＲ［暫定］またはＡＣＲ［停止］メッセージは、前記課金収集機能ノードに関連する不完全データベース内に記憶されることと、
   前記ＡＣＲに対する相関機能をホスティングする前記課金収集機能ノード（「相関ホスト」）が稼働中である場合、前記課金収集機能ノードは以下の一方のように前記ＡＣＲを処理すること、すなわち、
   前記課金収集機能ノードが前記相関ホストに集約ＣＤＲを送信している場合、その後、前記ＣＤＲは前記相関ホストの前記相関データベース内に書き込まれること、または
   前記課金収集機能ノードが前記不完全データベースから前記相関ホストにＡＣＲを送信している場合、その後、前記ＡＣＲは前記相関ホストの前記不完全データベースに書き込まれること、
   を含み、
   非稼働中の前記課金収集機能ノードが回復した場合、前記回復した課金収集機能ノードの対応する不完全データベースを以下の通り処理するステップ、すなわち、
   前記回復した課金収集機能ノードが前記相関ホストでないＡＣＲメッセージについて、前記ネットワーク内の複数の課金収集機能ノードの中から前記相関ホストを判断し、前記ホストの前記不完全データベースに前記ＡＣＲメッセージを書き込むステップと、
   前記判断し書き込むステップで処理されなかった、前記回復した課金収集機能ノードの前記不完全データベース内のペンディングのメッセージについて、前記不完全データベース内にペンディングのメッセージがあることから前記回復させた課金収集機能ノードは前記相関ホストであって、前記課金収集機能ノードが回復したことを示す「ノード・アライブ」メッセージを前記ネットワーク内の他のノードにブロードキャストするステップと
   をさらに含む
   方法を実行するよう構成された１つまたは複数のプロセッサ・ベース・デバイスを備える、システム。
9. 前記「ノード・アライブ」メッセージが、前記回復させた課金収集機能ノードに対する独自の不完全データベース内に記憶している前記記録を送信するように、他の課金収集機能ノードに促す、請求項８に記載のシステム。
10. 前記「ノード・アライブ」メッセージは、前記課金収集機能ノードが回復後に少なくとも３回送信されて、メッセージを読み損ねたあらゆる他の課金収集機能ノードに受信される、請求項９に記載のシステム。
11. 請求項８に記載のシステムであって、前記方法は、
    第１の課金収集機能ノード上の常駐エージェントによって周期的評価を行うことで、前記相関ホストが前記第１の課金収集機能ノードであるかどうかを判断するステップと、
    前記相関ホストが前記第１の課金収集機能ノードではない、前記第１の課金収集機能ノード上の前記不完全データベース内のメッセージについて、実際の稼働中相関ホストの不完全データベースにＡＣＲを書き込むステップと、
    前記相関ホストが前記第１の課金収集機能ノードではない、前記第１の課金収集機能ノード上の前記不完全データベース内のメッセージについて、実際の相関ホストが非稼働中である場合に、前記不完全データベース内のＡＣＲを次の評価サイクルが到達するまで保持するステップと、
    前記第１の課金収集機能ノード上の前記不完全データベース内のメッセージについて、前記メッセージが前記不完全データベース内にあった時間を算出し、それによってタイマおよび／または不完全データベースの充てん率が設定可能な値を超える際に最も古いメッセージが取り出され、このような取り出しが、損失データベースへの出力につながるステップと、
    前記第１の課金収集機能ノード上の前記不完全データベース内のメッセージについて、前記メッセージが前記不完全データベース内にあった時間を算出し、それによって古すぎて重要でないメッセージが、前記不完全データベースから取り出され、このような取り出しが、損失データベースへの出力につながるステップと、
    前記第１の課金収集機能ノードの前記不完全データベース内の残りのメッセージについて、前記第１の課金収集機能ノードが前記相関ホストであると判断された場合に、ＡＣＲ［開始］およびＡＣＲ［停止］メッセージが前記不完全データベース内で利用可能であったかどうかを判断し、そうである場合、集約および相関の処理に進むステップと
    をさらに含む、システム。
12. 前記課金収集機能ノードが、３ＧＰＰ課金データ機能（ＣＤＦ）および課金ゲートウェイ機能（ＣＧＦ）を含んでいる、請求項８に記載のシステム。
13. 前記ＣＤＦおよびＣＧＦが別の物理的要素内にある、請求項１２に記載のシステム。
14. 前記ＣＤＦおよびＣＧＦが同じ物理要素内に一体化される、請求項１２に記載のシステム。

Images