JP2017536720A - オフライン課金のためのｃｄｆトラッキング - Google Patents

Abstract

セッションについてのアカウンティング要求（ＡＲ）を取り扱う課金データ機能（ＣＤＦ）を追跡するシステム及び方法に関する。一実施形態は、セッションについての中間アカウンティング要求（ＩＡＲ）を受信するディストリビュータ・ユニット（ＤＵ）を備える。ＩＡＲは、セッションについてのＡＲを取り扱った１つ以上のＣＤＦを示している１つ以上のＣＤＦ識別子（ＩＤ）を含むトラッキング・パラメータを含む。ＤＵは、セッションについてのＡＲを取り扱った第１の宛先ＣＤＦについての第１のＣＤＦ ＩＤを識別するためにトラッキング・パラメータを処理する。第１の宛先ＣＤＦがＩＡＲを受信するために使用可能でない場合、ＤＵは、配信アルゴリズムに基づいてＩＡＲについての第２の宛先ＣＤＦを選択する。ＤＵは、ＩＡＲのトラッキング・パラメータの中に第２の宛先ＣＤＦについての第２のＣＤＦ ＩＤを追加し、第２の宛先ＣＤＦに対してＩＡＲを送信する。

Description

本開示は、通信システムの分野に関し、また詳細にはオフライン課金に関する。

サービス・プロバイダは、一般的に、エンド・ユーザ（加入者と称されることもある）に対して非常に多数の音声サービスと、データ・サービスとを提供する。音声サービスの例は、音声コール、コール転送、コール・ウェイティングなどである。データ・サービスの例は、ストリーミング・オーディオと、ストリーミング・ビデオと、ボイス・オーバー・インターネット・プロトコル（ＶｏＩＰ：Ｖｏｉｃｅ ｏｖｅｒ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）と、オンライン・ゲームと、ＩＰ−ＴＶとである。データ・サービスは、パケット・コア・ネットワークによって管理され、このパケット・コア・ネットワークは、インターネットなど、外部のパケット・データ・ネットワーク（ＰＤＮ：Ｐａｃｋｅｔ Ｄａｔａ Ｎｅｔｗｏｒｋｓ）とエンド・ユーザをインターフェースする。パケット・コア・ネットワークのいくつかの例は、汎用パケット無線サービス（ＧＰＲＳ：Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅ）コア・ネットワーク、ロング・ターム・エボリューション（ＬＴＥ：Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）ネットワークの進化型パケット・コア（ＥＰＣ：Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｃｏｒｅ）などである。セル電話、携帯情報端末、スマートフォン、ノートブック・コンピュータなどのモバイル・デバイスは、１つまたは複数の基地局を用いてエア・インターフェースの上のネットワークによって提供されるデータ・サービスにアクセスすることができる。

サービス・プロバイダは、オフライン課金機能とオンライン課金機能とを使用して、様々なサービスにアクセスする各デバイスによってもたらされるリソース使用を追跡する。３ＧＰＰ／３ＧＰＰ２標準グループは、様々なネットワーク・ドメイン（例えば、回路交換ドメイン、パケット交換ドメイン、および／またはワイヤレス・ドメイン）におけるオンライン課金システムおよびオフライン課金システムと、ＩＰマルチメディア・サブシステムと、新たに出現している３Ｇ／ＯＭＡアプリケーション・サービスとを実装するために使用され得る１組の仕様書を規定してきている。

３ＧＰＰ ＴＳ ３２．２４０によれば、オフライン課金は、ネットワーク・リソース使用についての課金情報が、リソース使用と同時に収集される場合のプロセスである。課金情報は、課金機能のチェーンを通して渡され、この課金機能のチェーンは、加入者課金および／またはオペレータ間アカウンティングのためのネットワーク・オペレータの課金ドメインに対して転送される課金データ・レコード（ＣＤＲ：Ｃｈａｒｇｉｎｇ Ｄａｔａ Ｒｅｃｏｒｄ）の生成をもたらす。オフライン課金を実装するために、課金トリガ機能（ＣＴＦ：Ｃｈａｒｇｉｎｇ Ｔｒｉｇｇｅｒ Ｆｕｎｃｔｉｏｎ）は、サービスを提供するネットワーク要素の中で実装される。ＣＴＦは、課金可能イベントに関連する情報を収集し、この情報をマッチする課金イベントの中へとアセンブルし、またそれらの課金イベントを課金データ機能（ＣＤＦ：Ｃｈａｒｇｉｎｇ Ｄａｔａ Ｆｕｎｃｔｉｏｎ）に対して送信し、この課金データ機能（ＣＤＦ）は、ネットワーク要素の中で、またはオフライン課金システム（ＯＦＣＳ：Ｏｆｆｌｉｎｅ Ｃｈａｒｇｉｎｇ Ｓｙｓｔｅｍ）の中で実装されることもある。課金イベントは、ダイアメータ・アカウンティング要求（ＡＣＲ：Ａｃｃｏｕｎｔｉｎｇ Ｒｅｑｕｅｓｔ）などのアカウンティング要求の形でＣＴＦによって提供されることもある。

ＣＤＦは、１つまたは複数のＣＴＦから課金イベントを受信し、また課金イベントの中に含まれる情報を使用して、ＣＤＲを構築する。ＣＤＲは、課金とアカウンティングとにおける使用のための、課金イベントについての情報（例えば、コールまたはセッションのセットアップの時間、コールまたはセッションの解体の時間、転送されるデータの量など）のフォーマットされた集まりである。次いで、ＣＤＦは、ＯＦＣＳの課金ゲートウェイ機能（ＣＧＦ：Ｃｈａｒｇｉｎｇ Ｇａｔｅｗａｙ Ｆｕｎｃｔｉｏｎ）に対してＣＤＲを送信する。ＣＧＦは、ネットワークと課金ドメインとの間のゲートウェイとしての役割を果たす。それゆえに、ＣＧＦは、ＣＤＦ（および他のＣＤＦ）からＣＤＲを収集し、オプションとして、ＣＤＲを相互に関連づけ、またＣＤＲをＣＤＲファイルに書き込み、またＣＤＲファイルを課金ドメインに対して使用可能にする。

典型的なオペレータ・ネットワークは、複数のＣＤＦとＣＧＦとを利用して、オフライン課金を実装することになる。それゆえに、ダイアメータ・ルーティング・エージェント（ＤＲＡ：Ｄｉａｍｅｔｅｒ Ｒｏｕｔｉｎｇ Ａｇｅｎｔ）などのフロント・エンド・デバイスをＯＦＣＳと一緒に使用して、ＣＴＦからＣＤＦへと課金イベントを配信する。フロント・エンド・デバイスは、一般的に、配信アルゴリズムを使用して、特定のセッションについてのＣＤＦを選択する。例えば、配信アルゴリズムは、ハッシング機能または別の機能を用いてダイアメータＡＣＲからのセッション識別子を処理して、ＣＤＦを選択することができる。次いで、フロント・エンド・デバイスは、ダイアメータＡＣＲを選択されたＣＤＦに対してルーティングする。

３ＧＰＰ ＴＳ ３２．２４０

本明細書において、説明される実施形態は、セッションについての課金イベントを取り扱うＣＤＦを追跡するための技法を提供している。セッション中に、セッションについての課金イベントを取り扱うために選択されるＣＤＦが、サービス停止（ＯＯＳ：ｏｕｔ−ｏｆ−ｓｅｒｖｉｃｅ）になり、また将来の課金イベントを取り扱うために使用不可能になる可能性がある。例えば、第１のＣＤＦ（ＣＤＦ１）が、セッションについてのアカウンティング要求を取り扱うために、フロント・エンド・デバイス（例えば、ＤＲＡ）によって選択される可能性がある。ＣＤＦ１が、セッション中にサービス停止になる場合、そのときにはフロント・エンド・デバイスは、第２のＣＤＦ（ＣＤＦ２）を選択して、セッションについてのアカウンティング要求を取り扱うことができる。どのＣＤＦが、セッションについてのアカウンティング要求を取り扱うために選択されてきているかを追跡するために、新しいトラッキング・パラメータが、ダイアメータ・プロトコルなどの課金プロトコルにおいて規定される。トラッキング・パラメータは、セッションについてのアカウンティング要求を取り扱うために選択されるＣＤＦについてのＣＤＦの識別子（ＩＤ）についてのものである。ＣＤＦ ＩＤは、トラッキング・パラメータの中に加えられ、その結果、ＣＤＦ ＩＤは、セッションについてのアカウンティング要求を取り扱ったＣＤＦを示している。例えば、トラッキング・パラメータは、上記の例における［ＣＤＦ１ ＩＤ，ＣＤＦ２ ＩＤ］を示すことができ、この［ＣＤＦ１ ＩＤ，ＣＤＦ２ ＩＤ］は、セッションについてのアカウンティング要求を取り扱ったＣＤＦを示している。オフライン課金において必要とされるエンティティは、次いで、トラッキング・パラメータを処理して、完全なＣＤＲの生成を取り扱うために、どのＣＤＦが、フェイル・オーバー・セッションについてのアカウンティング要求を所有しているかを決定することができる。

一実施形態は、オフライン課金システムの複数のＣＤＦに接続するように構成されたディストリビュータ・ユニットを備えている。ディストリビュータ・ユニットは、セッションについての課金トリガ機能（ＣＴＦ）から中間アカウンティング要求（例えば、ダイアメータ・アカウンティング要求（ＡＣＲ））を受信するように構成されており、ここで、中間アカウンティング要求は、セッションについてのアカウンティング要求を取り扱った宛先ＣＤＦを示しているＣＤＦ識別子（ＩＤ）を含むトラッキング・パラメータを含んでいる。ディストリビュータ・ユニットは、セッションについてのアカウンティング要求を取り扱った第１の宛先ＣＤＦについての第１のＣＤＦ ＩＤを識別するために、中間アカウンティング要求におけるトラッキング・パラメータを処理するように構成されている。第１の宛先ＣＤＦが、中間アカウンティング要求を受信するために使用可能でないときに、ディストリビュータ・ユニットは、配信アルゴリズムに基づいて、中間アカウンティング要求についての第２の宛先ＣＤＦを選択するように構成されている。ディストリビュータ・ユニットは、中間アカウンティング要求のトラッキング・パラメータの中に第２の宛先ＣＤＦについての第２のＣＤＦ ＩＤを追加し、また第２の宛先ＣＤＦに対して中間アカウンティング要求を送信するように構成されている。

別の実施形態においては、ディストリビュータ・ユニットは、第２のＣＤＦ ＩＤの出現についてのトラッキング・パラメータをスキャンし、また第２のＣＤＦ ＩＤがまだトラッキング・パラメータの中に出現していないときに、トラッキング・パラメータの中に第２のＣＤＦ ＩＤを追加するように構成されている。

別の実施形態においては、ディストリビュータ・ユニットは、配信アルゴリズムに基づいて、第２の宛先ＣＤＦを選択することに応じて、トラッキング・パラメータの中に第２のＣＤＦ ＩＤを追加するように構成されている。

別の実施形態においては、中間アカウンティング要求は、ダイアメータ・アカウンティング要求（ＡＣＲ）を含んでおり、またトラッキング・パラメータは、セッションについてのアカウンティング要求を取り扱ったＣＤＦを示しているＣＤＦ ＩＤについて規定されるダイアメータ属性値ペア（ＡＶＰ：Ａｔｔｒｉｂｕｔｅ Ｖａｌｕｅ Ｐａｉｒ）を含んでいる。

別の実施形態においては、ディストリビュータ・ユニットは、トラッキング・パラメータを含む第２の宛先ＣＤＦから中間アカウンティング応答を受信し、またＣＴＦに対して中間アカウンティング応答を送信するように構成されている。

別の実施形態においては、配信アルゴリズムは、中間アカウンティング要求におけるセッション識別子に基づいて、第２の宛先ＣＤＦを選択する整合したハッシング・アルゴリズムを含んでいる。

別の実施形態においては、第２の宛先ＣＤＦは、セッションに対する終了を示す、ＣＴＦから終了アカウンティング要求を受信するように構成されており、ここで、終了アカウンティング要求は、トラッキング・パラメータを含んでいる。第２の宛先ＣＤＦは、セッションについてのアカウンティング要求の合計回数を決定し、第２の宛先ＣＤＦによって取り扱われるアカウンティング要求の回数を決定し、また第２の宛先ＣＤＦによって取り扱われるアカウンティング要求のパーセンテージを算出するように構成されている。第２の宛先ＣＤＦによって取り扱われるアカウンティング要求のパーセンテージが５０％よりも大きいときに、第２の宛先ＣＤＦは、セッションについての課金データ・レコード（ＣＤＲ）を生成する調停ホストとしてそれ自体を選択するように構成されている。第２の宛先ＣＤＦによって取り扱われるアカウンティング要求のパーセンテージが５０％よりも小さいときに、第２の宛先ＣＤＦは、各宛先ＣＤＦによって取り扱われるアカウンティング要求の回数についてのトラッキング・パラメータの中に示される他の宛先ＣＤＦの問い合わせを行い、また最高回数のアカウンティング要求を取り扱った宛先ＣＤＦに基づいて、調停ホストを選択するように、構成されている。

別の実施形態は、アカウンティング要求を配信する方法を含んでいる。本方法は、セッションについて、ＣＴＦからディストリビュータ・ユニットにおける中間アカウンティング要求を受信するステップを含んでおり、ここでディストリビュータ・ユニットは、オフライン課金のために複数のＣＤＦに接続する。中間アカウンティング要求は、セッションについてのアカウンティング要求を取り扱った宛先ＣＤＦを示しているＣＤＦ ＩＤを含むトラッキング・パラメータを含んでいる。本方法は、セッションについてのアカウンティング要求を取り扱った第１の宛先ＣＤＦについての第１のＣＤＦ ＩＤを識別するために、中間アカウンティング要求の中のトラッキング・パラメータを処理するステップを含んでいる。第１の宛先ＣＤＦが、中間アカウンティング要求を受信するために使用可能でないときに、本方法は、配信アルゴリズムに基づいて、中間アカウンティング要求についての第２の宛先ＣＤＦを選択するステップを含んでいる。本方法は、中間アカウンティング要求のトラッキング・パラメータの中に第２の宛先ＣＤＦについての第２のＣＤＦ ＩＤを追加するステップと、第２の宛先ＣＤＦに対して中間アカウンティング要求を送信するステップとを含む。

別の実施形態は、セッションについてのオフライン課金のための複数のＣＤＦを備えている。それらのＣＤＦのうちの第１のＣＤＦは、セッションに対する終了を示すセッションについての終了アカウンティング要求を受信するように構成された選択ユニットを備えており、ここで終了アカウンティング要求は、セッションについてのアカウンティング要求を取り扱ったＣＤＦを示すＣＤＦ ＩＤを含むトラッキング・パラメータを含んでいる。選択ユニットは、調停ホストを選択して、トラッキング・パラメータの中で示されるＣＤＦからセッションについてのＣＤＲを生成するように構成されている。

上記の概要は、本明細書のいくつかの態様の基本的な理解を提供するものである。この概要は、本明細書の広範囲に及ぶ概説ではない。本明細書の重要な要素または不可欠な要素を識別することも、また本明細書の特定の実施形態のどのような範囲も、または特許請求の範囲のどのような範囲も示すことも意図してはいない。その唯一の目的は、後で提示される、より詳細な説明に対する前置きとして簡略化された形態で本明細書のいくつかの概念を提示することである。

本開示についてのいくつかの実施形態が、次に、例だけとして、また添付の図面を参照して、説明される。同じ参照番号は、すべての図面の上で、同じ要素、または同じタイプの要素を表している。

例示の一実施形態におけるオフライン課金アーキテクチャを示す図である。 例示の一実施形態におけるアカウンティング要求を配信する方法を示すフロー・チャートを示す図である。 例示の一実施形態におけるダイアメータＡＣＲの配信を示すメッセージ図である。 例示の一実施形態におけるＣＤＦを示す図である。 例示の一実施形態における調停ホストを選択する方法を示すフロー・チャートを示す図である。 例示の一実施形態におけるＣＤＲを生成する方法を示すフロー・チャートを示す図である。

図面と以下の説明とは、特定の例示の実施形態を示すものである。したがって、当業者なら、本明細書において明示的に説明されても、または示されてもいないが、実施形態の原理を実施し、また実施形態の範囲内に含まれる様々な構成を考案することができるようになることが、理解されるであろう。さらに、本明細書において説明されるどのような例も、本実施形態についての原理を理解する際に、助けとなることを意図しており、またそのように具体的に列挙された例および状態だけに限定することのないように解釈されるべきである。結果として、本発明の概念（単数または複数）は、以下で説明される特定の実施形態または例だけに限定されないが、特許請求の範囲とそれらの均等物とによって限定される。

図１は、例示の一実施形態におけるオフライン課金アーキテクチャ１００を示すものである。アーキテクチャ１００は、その加入者（すなわち、エンド・ユーザおよび関連するユーザ機器（ＵＥ：Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ））に対してサービスを提供して、加入者についてのオフライン課金を提供する回路交換ネットワークまたはパケット交換ネットワークの形で実装されることもある。いくつかの例示のネットワークは、ＩＰマルチメディア・サブシステム（ＩＭＳ：ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ）ネットワーク、ロング・ターム・エボリューション（ＬＴＥ）ネットワーク、汎用パケット無線サービス（ＧＰＲＳ）などを含む。

アーキテクチャ１００は、ディストリビュータ・ユニット１１０を通してオフライン課金システム（ＯＦＣＳ）１２０に接続するネットワーク要素１０２を含んでいる。ネットワーク要素１０２は、ネットワークによって提供されるサービスの提供において使用される装置または機器である。例えば、ネットワーク要素は、ＩＭＳネットワークのサービング・コール・セッション制御機能（Ｓ−ＣＳＣＦ：Ｓｅｒｖｉｎｇ−Ｃａｌｌ Ｓｅｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ）またはアプリケーション・サーバ（ＡＳ：ａｐｐｌｉｃａｔｉｏｎ ｓｅｒｖｅｒ）、ＬＴＥネットワークのサービング・ゲートウェイ（ＳＧＷ）またはパケット・データ・ネットワーク・ゲートウェイ（ＰＧＷ：Ｐａｃｋｅｔ Ｄａｔａ Ｎｅｔｗｏｒｋ Ｇａｔｅｗａｙ）などを備えていることができる。ネットワーク要素１０２は、ネットワーク要素１０２によって提供されるサービスについての課金可能イベントを検出し、課金可能イベントについての情報をマッチする課金イベントへとアセンブルし、またそれらの課金イベントを課金データ機能（ＣＤＦ）に対して送信する課金トリガ機能（ＣＴＦ）１０４を含んでいる。ネットワーク要素１０２の場合には、ＣＴＦ１０４は、ダイアメータＲｆインターフェースを使用することができる。それゆえに、ＣＴＦ１０４は、課金情報をダイアメータＲｆのアカウンティング要求（ＡＣＲ）などのアカウンティング要求へとアセンブルする。１つのＣＴＦ１０４が図１に示されるが、ディストリビュータ・ユニット１１０と連絡を取り合う多数のＣＴＦが存在する可能性がある。図１において具体的に示されてはいないが、ネットワーク要素１０２は、ＣＴＦ１０４を実装するプロセッサまたは他のハードウェア・コンポーネントを含むことができる。

ダイアメータ・プロトコルは、図１において課金プロトコルとして示される。しかしながら、他の課金プロトコルが、使用されることもある。それゆえに、本明細書において考察されるようなアカウンティング要求またはアカウンティング応答に対する言及は、ダイアメータ・プロトコルまたは別の課金プロトコルのことを意味することもある。

ＯＦＣＳ１２０は、ネットワークによって提供されるセッションまたはサービスについてのオフライン課金を実装するように構成される装置、サーバ、デバイス、または機器である。オフライン課金は、２つのタイプのもの、すなわち、セッション・ベースのもの、またはイベント・ベースのものとすることができる。イベント・ベースの課金においては、ＣＴＦは、提供される使用またはサービスを報告し、ここでは、サービスの提供は、加入者登録、再登録、登録解除など単一のオペレーションの形で提供される。ＣＴＦは、ＡＣＲイベント（ＡＣＲ ＥＶＥＮＴ）の形で、使用を報告する。セッション・ベースの課金は、セッションについての使用報告を報告するプロセスであり、また開始（ＳＴＡＲＴ）アカウンティング・データと、中間（ＩＮＴＥＲＩＭ）アカウンティング・データと、終了（ＳＴＯＰ）アカウンティング・データとを使用する。セッション中に、ＣＴＦ１０４は、セッションの手順に応じて０個の中間アカウンティング要求、１個の中間アカウンティング要求、または複数個の中間アカウンティング要求を送信することができる。

この実施形態においては、ＯＦＣＳ１２０は、複数のＣＤＦ（ＣＤＦ１〜ＣＤＦｎ）１２１〜１２４を含んでいる。ＣＤＦは、ネットワーク要素の内部のＣＴＦから課金イベントを受信し、課金イベントをＣＤＲへとフォーマットし、またＣＤＲをＣＧＦに対して送信する、ＯＦＣＳの内部の要素またはモジュールを備えている。ＯＦＣＳ１２０はまた、複数のＣＧＦ（ＣＧＦ１〜ＣＧＦｎ）１３１〜１３４を含んでいる。ＣＧＦは、セッションについてのＣＤＲを相互に関連づけ、また相互に関連づけられたＣＤＲを有するＣＤＲファイルを課金ドメイン１４０に対して転送するＯＦＣＳ１２０の内部の要素またはモジュールを備えている。課金ドメイン１４０は、課金調停アプリケーションと他の課金アプリケーション（例えば、統計アプリケーション）のためにＣＤＲファイルを受信し、また処理するオペレータ・ネットワークの一部分である。ＯＦＣＳ１２０の中のＣＤＦは、ダイアメータＧａインターフェースの上でＣＧＦと通信することができる。図１に示される場合には、ＧＴＰ’は、Ｇａインターフェースの上で使用されて、ＣＤＦからＣＧＦへとＣＤＲを移送することができる。１：１の関係が、図１におけるＣＤＦとＣＧＦとの間で示されるが、Ｎ：１の関係もまた、可能である。図１の中に具体的に示されてはいないが、ＯＦＣＳ１２０は、ＣＤＦ１２１〜１２４と、ＣＧＦ１３１〜１３４とを実装する１つまたは複数のプロセッサまたは他のハードウェア・コンポーネントを含むことができる。

ディストリビュータ・ユニット１１０は、ＯＦＣＳ１２０においてＣＴＦ（例えば、ＣＴＦ１０４）と、ＣＤＦ１２１〜１２４との間で実装される。ディストリビュータ・ユニット１１０の目的は、ＯＦＣＳ１２０の内部の複数のＣＤＦ１２１〜１２４のうちのＣＴＦからアカウンティング要求（例えば、ダイアメータＡＣＲ）を配信することである。アカウンティング要求は、課金イベントを報告するオフライン課金についてのメッセージを含んでおり、この一例は、ダイアメータＡＣＲである。

この実施形態においては、ディストリビュータ・ユニット１１０は、インターフェース（Ｉ／Ｆ）１１２と、プロセッサ（ＰＲＯＣ’Ｒ）１１４とを含む。インターフェース１１２は、ダイアメータＲｆプロトコル、または別のタイプの課金プロトコルを経由して、通信するためのコンポーネント（例えば、ハードウェア、ソフトウェア、またはハードウェアとソフトウェアとの組合せ）を備えている。プロセッサ１１４は、ＣＤＦ１２１〜１２４に対してアカウンティング要求を配信するロジックを実行するコンポーネント（すなわち、ハードウェア）を備えている。ディストリビュータ・ユニット１１０は、ＯＦＣＳ１２０の外側にあるように示されているが、ディストリビュータ・ユニット１１０は、ＯＦＣＳ１２０と同じプラットフォームの上に実装されることもある。

アカウンティング要求を配信するタスクは、セッションについてのアカウンティング要求を取り扱うためのＣＤＦインスタンスを選択するために、ＣＤＦ１２１〜１２４の重み、現在の負荷インデックス、および他のパラメータを考慮するステップを含むことができる。ディストリビュータ・ユニット１１０は、特定のセッションについてのＣＤＦを選択する際にラウンド・ロビン戦略に従うことができる。ディストリビュータ・ユニット１１０は、バック・ツー・バック・ユーザ・エージェント（Ｂ２ＢＵＡ：Ｂａｃｋ ｔｏ Ｂａｃｋ Ｕｓｅｒ Ａｇｅｎｔ）として機能することができ、ここではＣＴＦを伴う課金セッション（例えば、ダイアメータ・セッション）は、ディストリビュータ・ユニット１１０の上で終了され、また同等な、また対応する課金セッションは、ディストリビュータ・ユニット１１０と、選択されたＣＤＦとの間で開始される。各ＣＴＦは、ディストリビュータ・ユニット１１０との接続を確立し、またセッション識別子（ＩＤ）を含むディストリビュータ・ユニット１１０に対してアカウンティング要求を送信するであろう。セッションＩＤは、それが報告する各セッションについてのＣＴＦについて固有である。

ディストリビュータ・ユニット１１０は、配信アルゴリズムに基づいて、アカウンティング要求を取り扱うためのＣＤＦを選択するように構成されている。配信アルゴリズムは、セッションについてのＣＤＦ識別情報を算出するための任意の組のルールを含んでいる。一実施形態においては、ディストリビュータ・ユニット１１０は、「整合したハッシング」アルゴリズムを使用して、セッションについてのＣＤＦ識別情報を選択することができる。整合したハッシング・アルゴリズムは、アカウンティング要求におけるセッションＩＤと、ＣＤＦ識別子とを使用して、与えられたアカウンティング要求についてのＣＤＦを選択することができる。図１などにおけるようなｎ個のＣＤＦが存在すると、整合したハッシング・アルゴリズムは、与えられたセッションＩＤについての「ｎ」個の番号を生成することになる。それらの番号のうちの最高のものが、セッションについてのＣＤＦとして選択されることもある。例えば、ディストリビュータ・ユニット１１０は、その名前から各ＣＤＦインスタンスについてのハッシュ化された値を静的に決定することができる。
Ｈｓ＝Ｆ（ＣＤＦＮａｍｅ）
例えば、Ｈｓ１＝Ｆ（ＳｖｒＮｍＣＤＦ１）、Ｈｓ２＝Ｆ（ＳｖｒＮｍＣＤＦ２）、およびＨｓ３＝Ｆ（ＳｖｒＮｍＣＤＦ３）

次いで、ディストリビュータ・ユニット１１０は、各セッションＩＤ（ＳＩＤ）についてハッシュ化された値を動的に決定することができる。
Ｈｉ＝Ｆ（ＳｅｓｓｉｏｎＩＤ）

この値は、ＣＤＦのそれぞれについて（ＳＩＤ，ＣＤＦＮａｍｅ）の各組についてのハッシュを計算する際に使用される。
Ｈｃ＝Ｆ（Ｈｓ，Ｈｉ）、式中でｉ＝１．．．ｎ（この例においてはｎ＝３）

次いで、ディストリビュータ・ユニット１１０は、問題になっているセッションＩＤを有するセッションを取り扱うための最高のＨｃ値を有するＣＤＦを選択することができる。

ディストリビュータ・ユニット１１０が、あるセッションについてのＣＤＦを選択した後に、そのセッションについてのすべてのアカウンティング要求が、このＣＤＦに対して転送されることもある。しかしながら、１つまたは複数のＣＤＦが、ある期間にわたってサービス停止になり、またアカウンティング要求を取り扱うために使用可能でなくなる、という状況が起こる可能性がある。例えば、ＣＤＦがブレード・サーバの上で実行される場合、そのときには１つまたは複数のＣＤＦは、１つまたは複数のブレードを有する問題が存在する場合に、サービス停止になる可能性がある。あるセッションについて選択されるＣＤＦがサービス停止になる場合、そのときには従来の配信メカニズムは、後続のアカウンティング要求（例えば、ＡＣＲ（中間／終了））についての代替的なＣＤＦを選択するであろう。したがって、主要なＣＤＦは、そのセッションについてのいくつかのアカウンティング要求を受信することになり、また代替的なＣＤＦは、セッションについての他のアカウンティング要求を受信することになる。これは、セッションの第１の部分についての主要なＣＤＦの上の「不完全なＣＤＲ」の生成と、セッションの第２の部分についての代替的なＣＤＦの上の不完全なＣＤＲの生成とを引き起こすことになる。これは、ダウンストリーム課金調停システムが、複数の不完全なＣＤＲをセッションについてのコヒーレントで完全なＣＤＲへと組み合わせるための複雑さを増大させる。

以下の実施形態においては、新しいトラッキング・パラメータは、アカウンティング要求を受信する／取り扱うためにセッションについて選択されるＣＤＦを記録するように、課金プロトコル（例えば、ダイアメータ）において規定される。例えば、ＣＤＦ１が、最初にあるセッションについて選択され、使用不可能になる場合、そのときにはＣＤＦ２は、セッションについてのアカウンティング要求を受信するように選択されることもある。ＣＤＦ２が、使用不可能になる場合、そのときにはＣＤＦ３は、セッションについてアカウンティング要求を受信するように選択されることもある。したがって、トラッキング・パラメータは、［ＣＤＦ１，ＣＤＦ２，ＣＤＦ３］を示すことができ、この［ＣＤＦ１，ＣＤＦ２，ＣＤＦ３］は、セッションについてのアカウンティング要求を取り扱うように選択されたＣＤＦのシーケンスを示す。オフライン課金に関与するエンティティは、新しいＣＤＦが選択される場合にトラッキング・パラメータにＣＤＦ ＩＤを追加し、また付加することができ、かつ／またはトラッキング・パラメータにアクセスして、セッションについてのアカウンティング要求を受信したこれらのＣＤＦを識別することができる。特定のセッションについて選択されるＣＤＦは、そのセッションについての「宛先」ＣＤＦと称されることもある。

図１におけるトラッキング・パラメータの使用を例証すると、ＣＴＦ１０４は、ネットワーク要素１０２によって提供されるサービスについて課金可能イベントを検出し、またＣＴＦ１０４は、課金可能イベントについての情報をアカウンティング要求へとアセンブルする。例えば、アカウンティング要求は、ダイアメータＲｆ ＡＣＲを含むことができる。ＣＴＦ１０４は、トラッキング・パラメータをこの時点においてアカウンティング要求の中に挿入することができ、または挿入しなくてもよい。例えば、アカウンティング要求が、課金を開始するための開始要求（例えば、ＡＣＲ（開始））である場合、そのときには宛先ＣＤＦは、このセッションについて選択されてきている。したがって、ＣＴＦ１０４は、宛先ＣＤＦについてのＣＤＦ ＩＤをトラッキング・パラメータの中に挿入することができない。アカウンティング要求が、中間要求（例えば、ＡＣＲ（中間））または終了要求（例えば、ＡＣＲ（終了））である場合、そのときには宛先ＣＤＦは、このセッションについて選択されてきており、またＣＴＦ１０４は、トラッキング・パラメータを入力することができる可能性がある。次いで、ＣＴＦ１０４は、アカウンティング要求をＯＦＣＳ１２０に向かって送信する。

図２は、例示の一実施形態におけるアカウンティング要求を配信する方法２００を示すフロー・チャートを示すものである。方法２００のステップは、図１におけるディストリビュータ・ユニット１１０を参照して説明されることになるが、当業者なら、本方法２００が、他のシステムにおいても実行され得ることを理解するであろう。また、本明細書において説明されるフロー・チャートのステップは、必ずしもすべてを含んだものではなく、また示されていない他のステップを含むことができ、またそれらのステップは、代替的な順序で実行されることもある。

ディストリビュータ・ユニット１１０のインターフェース１１２は、セッションについてＣＴＦ１０４からアカウンティング要求を受信する（ステップ２０２）。次いで、プロセッサ１１４は、開始、中間、終了など、アカウンティング要求のタイプを決定する（ステップ２０３）。

アカウンティング要求が、課金セッションの開始を示す開始アカウンティング要求である場合、そのときにはプロセッサ１１４は、配信アルゴリズムに基づいて、アカウンティング要求についての宛先ＣＤＦ（例えば、ＣＤＦ１２１〜１２４のうちの１つ）を選択する（ステップ２０４）。配信アルゴリズムを使用して、ＣＤＦを選択するが、プロセッサ１１４は、ルックアップ・テーブルなどの配信アルゴリズム以外のＣＤＦを選択する他の方法を使用することができる。プロセッサ１１４は、アカウンティング要求のトラッキング・パラメータの中に、宛先ＣＤＦについてのＣＤＦ ＩＤを追加する（ステップ２０６）。これは、宛先ＣＤＦが、セッションについて選択されてきている第１の例であるので、トラッキング・パラメータの中に他のＣＤＦ ＩＤは存在していない。次いで、プロセッサ１１４は、インターフェース１１２を通して、宛先ＣＤＦに対してアカウンティング要求を送信する（ステップ２０８）。

アカウンティング要求が、課金セッション中の中間アカウンティング要求である場合、そのときにはプロセッサ１１４は、セッションについてのアカウンティング要求を取り扱った１つまたは複数の宛先ＣＤＦについてＣＤＦ ＩＤを識別するように、アカウンティング要求におけるトラッキング・パラメータを処理する（ステップ２１０）。中間アカウンティング要求が受信されるときに、宛先ＣＤＦがセッションについて既に選択されてきていることが、仮定される。それゆえに、トラッキング・パラメータは、少なくとも１つのＣＤＦ ＩＤが入力されている。複数の宛先ＣＤＦが選択されてきている（例えば、ＣＤＦが、サービス停止になってきており、そのようにして代替的なＣＤＦが、選択されてきている）場合、そのときにはトラッキング・パラメータは、セッションについて選択されるＣＤＦを示している複数のＩＤが入力されている。次いで、プロセッサ１１４は、トラッキング・パラメータにおけるＣＤＦ ＩＤを使用して、アカウンティング要求についての宛先ＣＤＦを識別することができる（ステップ２１２）。例えば、トラッキング・パラメータが１つのＣＤＦ ＩＤを含んでいる場合、そのときにはプロセッサ１１４は、ＣＤＦ ＩＤに基づいて、アカウンティング要求についての宛先ＣＤＦを識別することができる。トラッキング・パラメータが複数のＣＤＦ ＩＤを含んでいる場合、そのときにはプロセッサ１１４は、トラッキング・パラメータの中に示される最後のＣＤＦ ＩＤに基づいて、アカウンティング要求についての宛先ＣＤＦを識別することができる。例えば、トラッキング・パラメータが、［ＣＤＦ１ ＩＤ，ＣＤＦ２ ＩＤ，ＣＤＦ３ ＩＤ］を示している場合、そのときにはプロセッサ１１４は、これが、トラッキング・パラメータの中に示される最後のＣＤＦであるので、「ＣＤＦ３」として宛先ＣＤＦを識別することができる。プロセッサ１１４は、基本的に、アカウンティング要求が１つまたは複数の宛先ＣＤＦを示しているトラッキング・パラメータを含むときに、配信アルゴリズムを使用して、アカウンティング要求についての宛先ＣＤＦを選択するその通常のロジックをオーバーライドする。

次いで、プロセッサ１１４は、宛先ＣＤＦが使用可能であることを決定し、または検証する（ステップ２１４）。それは、１つまたは複数のＣＤＦ１２１〜１２４が、ある期間にわたってサービス停止になる場合である可能性がある。それゆえに、プロセッサ１１４は、宛先ＣＤＦがこのアカウンティング要求について、使用可能であるか、またはサービス中であるかを決定する。宛先ＣＤＦが、使用可能である場合、そのときにはプロセッサ１１４は、宛先ＣＤＦに対してアカウンティング要求を送信する（ステップ２０８）。アカウンティング要求は、依然としてトラッキング・パラメータを含んでいる。宛先ＣＤＦが使用可能でない場合、そのときにはプロセッサ１１４は、配信アルゴリズムに基づいて、アカウンティング要求についての代替的な宛先ＣＤＦ（例えば、ＣＤＦ１２１〜１２４のうちの１つ）を選択する（ステップ２１６）。プロセッサ１１４は、アカウンティング要求のトラッキング・パラメータの中に代替的な宛先ＣＤＦについてのＣＤＦ ＩＤを追加または付加する（ステップ２１８）。プロセッサ１１４は、代替的な宛先ＣＤＦに対してアカウンティング要求を送信する（ステップ２２０）。

ステップ２１８では、プロセッサ１１４は、パラメータの中の追加データとして、トラッキング・パラメータの中にＣＤＦ ＩＤを追加する。例えば、トラッキング・パラメータが、最初に［ＣＤＦ１ ＩＤ］を含んでいる場合、そのときにはプロセッサ１１４は、別の宛先ＣＤＦについてのＣＤＦ ＩＤを追加することができ、その結果、トラッキング・パラメータは、［ＣＤＦ１ ＩＤ，ＣＤＦ２ ＩＤ］を含むようになる。新しい宛先ＣＤＦが、フェイルオーバー・シナリオの中で選択されるときに、プロセッサ１１４は、宛先ＣＤＦのＣＤＦ ＩＤを置き換えることはない。その代わりに、プロセッサ１１４は、新しいＣＤＦ ＩＤを付加することにより、トラッキング・パラメータの中のデータに追加する。それゆえに、トラッキング・パラメータは、セッションについてのアカウンティング要求を取り扱うために選択される各宛先ＣＤＦのリストまたはレコードを示している。一実施形態においては、トラッキング・パラメータはまた、セッションについてのアカウンティング要求を取り扱うために選択される宛先ＣＤＦのシーケンスまたは順序を示すこともできる。例えば、トラッキング・パラメータが、［ＣＤＦ１ ＩＤ，ＣＤＦ２ ＩＤ］を含んでいる場合、これは、ＣＤＦ１が、最初に、セッションについてのアカウンティング要求を取り扱い、またフェイルオーバーが起こり、その結果、ＣＤＦ２がセッションについてのアカウンティング要求を取り扱ったことを示すことができる。トラッキング・パラメータが、［ＣＤＦ１ ＩＤ，ＣＤＦ２ ＩＤ，ＣＤＦ１ ＩＤ］を含んでいる場合、これは、ＣＤＦ１が、最初に、セッションについてのアカウンティング要求を取り扱い、フェイルオーバーが起こり、その結果、ＣＤＦ２は、セッションについてのアカウンティング要求を取り扱い、また次いでアカウンティング要求が、（回復されたＣＤＦ１を仮定すると）ＣＤＦ１に対して再び、ルーティングされたことを示すことができる。

トラッキング・パラメータにＣＤＦ ＩＤを追加するための異なるロジックが存在している可能性がある。一実施形態においては、プロセッサ１１４は、新しい宛先ＣＤＦがフェイルオーバー・シナリオの後に選択されていることに応じて、トラッキング・パラメータにＣＤＦ ＩＤを追加することができる。したがって、宛先ＣＤＦがフェイルオーバー中の異なる時刻に選択される場合に、ＣＤＦ ＩＤは、トラッキング・パラメータの中に複数回現れることができる。トラッキング・パラメータはまた、宛先ＣＤＦが、セッションについて選択されたシーケンスまたは順序を示すであろう。別の実施形態においては、プロセッサ１１４が、トラッキング・パラメータにＣＤＦ ＩＤを追加する前に、プロセッサ１１４は、ＣＤＦ ＩＤの出現についてトラッキング・パラメータをスキャンすることができる。ＣＤＦ ＩＤが、トラッキング・パラメータの中にまだ現れていないときだけに、プロセッサ１１４は、トラッキング・パラメータにＣＤＦ ＩＤを追加することができる。ＣＤＦ ＩＤが、既に現れている場合、そのときにはプロセッサ１１４は、トラッキング・パラメータにＣＤＦ ＩＤを追加しなくてもよい。このシナリオにおいては、トラッキング・パラメータは、アカウンティング要求を取り扱った宛先ＣＤＦを単に示すことになり、またパラメータの中のＣＤＦ ＩＤに対するどのような特定の順序も存在していないこともある。

アカウンティング要求が、課金セッションを終了させる終了アカウンティング要求である場合、そのときにはプロセッサ１１４は、中間アカウンティング要求と同様に動作する。

トラッキング・パラメータは、このセッションについてのすべてのアカウンティング・メッセージの中に挿入されることもある。例えば、ＣＤＦが、セッションについてディストリビュータ・ユニット１１０により（例えば、配信アルゴリズムに基づいて）選択された後に、ディストリビュータ・ユニット１１０は、セッションについての各アカウンティング・メッセージの中に宛先ＣＤＦの識別情報を有するトラッキング・パラメータを挿入することができる。それゆえに、ディストリビュータ・ユニット１１０から宛先ＣＤＦに対して送信されるアカウンティング要求は、トラッキング・パラメータを含んでいる。同様に、宛先ＣＤＦからディストリビュータ・ユニット１１０に対して送信されるアカウンティング応答（例えば、ダイアメータＡＣＡ）はまた、トラッキング・パラメータを含むこともできる。さらに、ディストリビュータ・ユニット１１０からＣＴＦ１０４に対して送信されるアカウンティング応答は、トラッキング・パラメータを含むこともできる。それゆえに、ディストリビュータ・ユニット１１０は、セッションについてのアカウンティング要求を取り扱ったＣＤＦについて他の要素（例えば、ＣＴＦ１０４および宛先ＣＤＦ）に通知することができる。

上記で説明されるような要求／応答の形でトラッキング・パラメータを提供するために、新しい属性値ペア（ＡＶＰ）が、ダイアメータ・プロトコルにおいて規定されることもある。新しいＡＶＰは、「ＣＤＦＴｒａｃｋｅｒ」という属性名を有することができるが、他の属性名が、使用されることもある。このＡＶＰは、オプションであり、またその目的は、特定のダイアメータ・セッションに属するメッセージについてのマーカーを作成することである。このＡＶＰは、タイプ「オクテット・ストリング」のものであり、またダイアメータ・セッションについて選択される１つまたは複数のＣＤＦインスタンスの識別情報で入力される。以下は、ダイアメータＡＣＲにおける新しいＡＶＰを示すものである。
＜ＡＣＲ＞：：＝＜Ｄｉａｍｅｔｅｒ Ｈｅａｄｅｒ：２７１，ＲＥＱ，ＰＸＹ＞
＜Ｓｅｓｓｉｏｎ−Ｉｄ＞
｛Ｏｒｉｇｉｎ−Ｈｏｓｔ｝
｛Ｏｒｉｇｉｎ−Ｒｅａｌｍ｝
｛Ｄｅｓｔｉｎａｔｉｏｎ−Ｒｅａｌｍ｝
｛Ａｃｃｏｕｎｔｉｎｇ−Ｒｅｃｏｒｄ−Ｔｙｐｅ｝
｛Ａｃｃｏｕｎｔｉｎｇ−Ｒｅｃｏｒｄ−Ｎｕｍｂｅｒ｝
［Ａｃｃｔ−Ａｐｐｌｉｃａｔｉｏｎ−Ｉｄ］
［Ｖｅｎｄｏｒ−Ｓｐｅｃｉｆｉｃ−Ａｐｐｌｉｃａｔｉｏｎ−Ｉｄ］
［Ｕｓｅｒ−Ｎａｍｅ］
［Ｄｅｓｔｉｎａｔｉｏｎ−Ｈｏｓｔ］
［Ａｃｃｏｕｎｔｉｎｇ−Ｓｕｂ−Ｓｅｓｓｉｏｎ−Ｉｄ］
［Ａｃｃｔ−Ｓｅｓｓｉｏｎ−Ｉｄ］
［Ａｃｃｔ−Ｍｕｌｔｉ−Ｓｅｓｓｉｏｎ−Ｉｄ］
［Ａｃｃｔ−Ｉｎｔｅｒｉｍ−Ｉｎｔｅｒｖａｌ］
［Ａｃｃｏｕｎｔｉｎｇ−Ｒｅａｌｔｉｍｅ−Ｒｅｑｕｉｒｅｄ］
［Ｏｒｉｇｉｎ−Ｓｔａｔｅ−Ｉｄ］
［Ｅｖｅｎｔ−Ｔｉｍｅｓｔａｍｐ］
＊［Ｐｒｏｘｙ−Ｉｎｆｏ］
＊［Ｒｏｕｔｅ−Ｒｅｃｏｒｄ］
［ＣＤＦＴｒａｃｋｅｒ］
＊［ＡＶＰ］

「ＳＩＳＥ」伝統的表現法に従って、ＣＤＦＴｒａｃｋｅｒ ＡＶＰは、「−ＩＳ−」に従うことが予想されることになり、それがＡＣＲ（開始）とＡＣＲ（イベント）との中では予想されないが、それは、ＡＣＲ（中間）とＡＣＲ（終了）との中で予想されることを意味している。

以下は、ダイアメータＡＣＡの形の新しいＡＶＰを示すものである。
＜ＡＣＡ＞：：＝＜Ｄｉａｍｅｔｅｒ Ｈｅａｄｅｒ：２７１， ＰＸＹ＞
＜Ｓｅｓｓｉｏｎ−Ｉｄ＞
｛Ｒｅｓｕｌｔ−Ｃｏｄｅ｝
｛Ｏｒｉｇｉｎ−Ｈｏｓｔ｝
｛Ｏｒｉｇｉｎ−Ｒｅａｌｍ｝
｛Ａｃｃｏｕｎｔｉｎｇ−Ｒｅｃｏｒｄ−Ｔｙｐｅ｝
｛Ａｃｃｏｕｎｔｉｎｇ−Ｒｅｃｏｒｄ−Ｎｕｍｂｅｒ｝
［Ａｃｃｔ−Ａｐｐｌｉｃａｔｉｏｎ−Ｉｄ］
［Ｖｅｎｄｏｒ−Ｓｐｅｃｉｆｉｃ−Ａｐｐｌｉｃａｔｉｏｎ−Ｉｄ］
［Ｕｓｅｒ−Ｎａｍｅ］
［Ａｃｃｏｕｎｔｉｎｇ−Ｓｕｂ−Ｓｅｓｓｉｏｎ−Ｉｄ］
［Ａｃｃｔ−Ｓｅｓｓｉｏｎ−Ｉｄ］
［Ａｃｃｔ−Ｍｕｌｔｉ−Ｓｅｓｓｉｏｎ−Ｉｄ］
［Ｅｒｒｏｒ−Ｍｅｓｓａｇｅ］
［Ｅｒｒｏｒ−Ｒｅｐｏｒｔｉｎｇ−Ｈｏｓｔ］
［Ｆａｉｌｅｄ−ＡＶＰ］
［Ａｃｃｔ−Ｉｎｔｅｒｉｍ−Ｉｎｔｅｒｖａｌ］
［Ａｃｃｏｕｎｔｉｎｇ−Ｒｅａｌｔｉｍｅ−Ｒｅｑｕｉｒｅｄ］
［Ｏｒｉｇｉｎ−Ｓｔａｔｅ−Ｉｄ］
［Ｅｖｅｎｔ−Ｔｉｍｅｓｔａｍｐ］
＊［Ｐｒｏｘｙ−Ｉｎｆｏ］
［ＣＤＦＴｒａｃｋｅｒ］
＊［ＡＶＰ］

「ＳＩＳＥ」伝統的表現法に従って、ＣＤＦＴｒａｃｋｅｒ ＡＶＰは、「ＳＩ−−」に従うことが予想されることになり、それがＡＣＡ（終了）とＡＣＡ（イベント）との中では予想されないが、それは、ＡＣＡ（開始）とＡＣＡ（中間）との中で予想されることを意味している。

トラッキング・パラメータの使用を例証するために、以下は、ＣＤＲＴｒａｃｋｅｒ ＡＶＰを使用したダイアメータ・メッセージングを説明している。図３は、例示の一実施形態におけるダイアメータＡＣＲの配信を示すメッセージ図を示すものである。図３における開始後、ＣＴＦ１０４は、ネットワーク要素１０２（図１参照）によって提供されるサービスについての課金可能イベントを検出し、またダイアメータ・セッションについてのＡＣＲ（開始）をアセンブルする。次いで、ＣＴＦ１０４は、ディストリビュータ・ユニット１１０に対してＡＣＲ（開始）を送信する。この時点において、ダイアメータ・セッションについて選択される宛先ＣＤＦが存在してきておらず、そのようにしてＣＴＦ１０４は、トラッキング・パラメータをＡＣＲ（開始）に入力することができない。

ＡＣＲ（開始）を受信することに応じて、ディストリビュータ・ユニット１１０は、配信アルゴリズム（すなわち、整合したハッシング・アルゴリズム）に基づいて、ダイアメータ・セッションについての宛先ＣＤＦを選択する。この例においては、ディストリビュータ・ユニット１１０は、ダイアメータ・セッションを取り扱うＣＤＦ１２１を選択する。ディストリビュータ・ユニット１１０はまた、ＣＤＦ１２１が使用可能であるか、またはサービス中（ＩＳ：ｉｎ−ｓｅｒｖｉｃｅ）であることを決定し、または検証する。新しい宛先ＣＤＦが（配信アルゴリズムなどに基づいて）セッションについて選択されるときに、ディストリビュータ・ユニット１１０は、ＡＣＲ（開始）についてのトラッキング・パラメータ（例えば、「ＣＤＦＴｒａｃｋｅｒ」ＡＶＰ）の中にＣＤＦ１２１についてのＣＤＦ ＩＤ（すなわち、ＣＤＦ−１２１）を追加する。次いで、ディストリビュータ・ユニット１１０は、ＡＣＲ（開始）をＣＤＦ１２１に対してルーティングする。

ＣＤＦ１２１は、ＡＣＡ（開始）でＡＣＲ（開始）に対して応答し、ディストリビュータ・ユニット１１０は、このＡＣＡ（開始）をＣＴＦ１０４に対してルーティングする。ＡＣＡメッセージはまた、ＣＤＦ１２１についてのＣＤＦ ＩＤが入力されたトラッキング・パラメータを含んでいる。

ＣＴＦ１０４がセッションについての別の課金可能イベントを検出するときに、それは、ＡＣＲ（中間）をアセンブルする。ＣＴＦ１０４はまた、宛先ＣＤＦが、既に先行するＡＣＡメッセージ（すなわち、ＡＣＡ（開始）の中で提供されるトラッキング・パラメータに基づいて、このダイアメータ・セッションについて選択されてきていることも決定する。それゆえに、ＣＴＦ１０４は、ＣＤＦ１２１の識別情報を示している値を用いて、ＡＣＲ（中間）におけるトラッキング・パラメータ（例えば、「ＣＤＦＴｒａｃｋｅｒ」ＡＶＰ）に入力する。次いで、ＣＴＦ１０４は、ディストリビュータ・ユニット１１０に対してＡＣＲ（中間）を送信する。ＡＣＲ（中間）を受信することに応じて、ディストリビュータ・ユニット１１０は、ＡＣＲ（中間）の中のトラッキング・パラメータを処理して、ダイアメータ・セッションについて既に選択された宛先ＣＤＦを識別し、この宛先ＣＤＦは、ＣＤＦ１２１である。ディストリビュータ・ユニット１１０は、ＣＤＦ１２１がＡＣＲ（中間）のために使用可能であることを決定し、または検証する。このメッセージでは、新しい宛先ＣＤＦは、セッションについて選択されなかった。それゆえに、ディストリビュータ・ユニット１１０が、ＡＣＲ（中間）のトラッキング・パラメータに対して新しいＣＤＦ ＩＤを追加する必要はない。次いで、ディストリビュータ・ユニット１１０は、ＡＣＲ（中間）をＣＤＦ１２１へとルーティングする。

ＣＤＦ１２１は、ＡＣＡ（中間）を用いてＡＣＲ（中間）に応答し、ディストリビュータ・ユニット１１０は、このＡＣＡ（中間）をＣＴＦ１０４へとルーティングする。ＡＣＡメッセージはまた、ＣＤＦ１２１についてのＣＤＦ ＩＤが入力されたトラッキング・パラメータを含んでいる。

ＣＴＦ１０４が別の課金可能イベントを検出するときに、それは、セッションについてのＡＣＲ（中間）をアセンブルし、またＣＤＦ１２１の識別情報を示している値を用いて、ＡＣＲ（中間）の中のトラッキング・パラメータ（例えば、「ＣＤＦＴｒａｃｋｅｒ」ＡＶＰ）に入力する。次いで、ＣＴＦ１０４は、ディストリビュータ・ユニット１１０に対してＡＣＲ（中間）を送信する。ＡＣＲ（中間）を受信することに応じて、ディストリビュータ・ユニット１１０は、ＡＣＲ（中間）の中のトラッキング・パラメータを処理して、ダイアメータ・セッションについて既に選択された宛先ＣＤＦを識別し、この宛先ＣＤＦは、ＣＤＦ１２１である。ディストリビュータ・ユニット１１０は、ＣＤＦ１２１がＡＣＲ（中間）のために使用可能であることを決定し、または検証する。この場合には、ＣＤＦ１２１は、サービス停止（ＯＯＳ）になってしまっており、またＡＣＲ（中間）のために使用可能ではない。それゆえに、ディストリビュータ・ユニット１１０は、配信アルゴリズムに基づいて、ダイアメータ・セッションについての代替的な宛先ＣＤＦ（例えば、ＣＤＦ１２２）を選択する。新しい宛先ＣＤＦが選択されるので、ディストリビュータ・ユニット１１０は、ＡＣＲ（中間）の中のトラッキング・パラメータ（例えば、「ＣＤＦＴｒａｃｋｅｒ」ＡＶＰ）の中にＣＤＦ１２２についてのＣＤＦ ＩＤ（すなわち、ＣＤＦ−１２２）を追加して、宛先ＣＤＦとしてＣＤＦ１２２を示す。ＣＤＦ ＩＤがこのようにして追加されるので、トラッキング・パラメータは、ダイアメータ・セッションについて選択される宛先ＣＤＦのシーケンスを［ＣＤＦ−１２１，ＣＤＦ−１２２］として示している。次いで、ディストリビュータ・ユニット１１０は、ＡＣＲ（中間）をＣＤＦ１２２へとルーティングする。

ＣＤＦ１２２は、ＡＣＡ（中間）を用いてＡＣＲ（中間）に応答し、ディストリビュータ・ユニット１１０は、このＡＣＡ（中間）をＣＴＦ１０４へとルーティングする。ＡＣＡメッセージはまた、ＣＤＦ１２１と、ＣＤＦ１２２とについてのＣＤＦ ＩＤが入力されたトラッキング・パラメータを含んでいる。

新しい宛先ＣＤＦがセッションについて選択される場合／ときに、ディストリビュータ・ユニット１１０は、セッションについての追加のＡＣＲ（中間）に応じて同様なやり方で動作して、ＣＤＦＴｒａｃｋｅｒ ＡＶＰにＣＤＦ ＩＤを追加することができる。

ある時点において、ＣＴＦ１０４は、セッションについてのＡＣＲ（終了）をアセンブルし、またＣＤＦ１２１とＣＤＦ１２２とについての識別情報を示している値を用いて、ＡＣＲ（終了）の中のトラッキング・パラメータ（例えば、「ＣＤＦＴｒａｃｋｅｒ」ＡＶＰ）に入力する。次いで、ＣＴＦ１０４は、ディストリビュータ・ユニット１１０に対してＡＣＲ（終了）を送信する。ＡＣＲ（終了）を受信することに応じて、ディストリビュータ・ユニット１１０は、ＡＣＲ（終了）の中のトラッキング・パラメータを処理して、ダイアメータ・セッションについて既に選択された宛先ＣＤＦを識別し、この宛先ＣＤＦは、ＣＤＦ１２２である。複数のＣＤＦ ＩＤが、トラッキング・パラメータの中でリストアップされるときに、ディストリビュータ・ユニット１１０は、トラッキング・パラメータの中でリストアップされた最後のＣＤＦ ＩＤを調べて、セッションについての現在の宛先ＣＤＦを識別することができる。ディストリビュータ・ユニット１１０は、ＣＤＦ１２２がＡＣＲ（終了）のために使用可能であるかどうかを決定する。この場合には、ＣＤＦ１２２は、ＡＣＲ（終了）のために使用可能である。それゆえに、ディストリビュータ・ユニット１１０は、ＡＣＲ（終了）をＣＤＦ１２２へとルーティングする。トラッキング・パラメータは、ＣＤＦ１２２についてのＣＤＦ ＩＤを既に含んでおり、そのようにしてディストリビュータ・ユニット１１０は、トラッキング・パラメータにＣＤＦ ＩＤを追加する必要はない。

ＣＤＦ１２２は、ＡＣＡ（終了）を用いてＡＣＲ（終了）に応答し、ディストリビュータ・ユニット１１０は、このＡＣＡ（終了）をＣＴＦ１０４へとルーティングする。

上記の実施形態は、どのようにしてディストリビュータ・ユニット１１０が、セッションについての宛先ＣＤＦに対してダイアメータＡＣＲなどのアカウンティング要求を配信するかを説明している。セッションが終了し、またディストリビュータ・ユニット１１０が、終了アカウンティング要求を受信するときに、ディストリビュータ・ユニット１１０は、終了アカウンティング要求を宛先ＣＤＦへとルーティングする。この時点において、セッションについてのアカウンティング要求は、ＣＤＦのうちの１つによって収集されて、課金データ・レコード（ＣＤＲ）を生成する。セッションについてのＣＤＲを生成するＣＤＦは、本明細書において、調停ホストと称される。以下は、ＣＤＦ１２２の構成を説明しており、このＣＤＦ１２２は、調停ホストとしての役割を果たすことができる。

図４は、例示の一実施形態におけるＣＤＦ１２２を示すものである。この実施形態においては、ＣＤＦ１２２は、インターフェース４１２と、プロセッサ４１４と、ストレージ・ユニット４１６とを含む。インターフェース４１２は、ＣＧＦと通信するためのコンポーネント（例えば、ハードウェア、ソフトウェア、またはハードウェアとソフトウェアとの組合せ）を備えている。インターフェース４１２は、通信のためにＧＴＰ’または別のプロトコルを使用することができる。プロセッサ４１４は、ＣＤＦの機能を実行するコンポーネントを備えている。ストレージ・ユニット４１６は、メモリなど、データを記憶するコンポーネントを備えている。この実施形態においては、ＣＤＦ１２２は、選択ユニット４１８を含んでおり、この選択ユニット４１８は、セッションについての調停ホストを選択することができるコンポーネント（例えば、ハードウェア、ソフトウェア、またはハードウェアとソフトウェアとの組合せ）である。ＣＤＦ１２２はまた、ＣＤＦジェネレータ４２０を含んでおり、このＣＤＦジェネレータ４２０は、セッションについてのアカウンティング要求を処理して、ＣＤＲを生成することができるコンポーネント（例えば、ハードウェア、ソフトウェア、またはハードウェアとソフトウェアとの組合せ）である。選択ユニット４１８と、ＣＤＲジェネレータ４２０とのより詳細な説明が、以下で提供される。ＯＦＣＳ１２０の内部の任意のＣＤＦは、ＣＤＦ１２２と類似した構成およびオペレーションを有することができる。

図５は、例示の一実施形態における調停ホストを選択する方法５００を示すフロー・チャートを示すものである。方法５００のステップが、図４におけるＣＤＦ１２２を参照して説明されることになるが、当業者なら、本方法５００が、他のシステムにおいても実行され得ることを理解するであろう。

初めに、ＣＤＦ１２２は、終了アカウンティング要求を受信する（ステップ５０２）。終了アカウンティング要求に応じて、ＣＤＦ１２２における選択ユニット４１８は、セッションについてのアカウンティング要求に基づいて、ＣＤＲを生成するための調停ホストを選択するプロセスを開始する。選択ユニット４１８は、様々なやり方で、調停ホストを選択することができる。本明細書において説明される実施形態においては、選択ユニット４１８は、セッションについてのアカウンティング要求の合計回数（Ｎｔｏｔａｌ）を決定することができる（ステップ５０４）。例えば、ダイアメータ・プロトコルが使用される場合、そのときには選択ユニット４１８は、セッションについての最後に受信されたメッセージのアカウンティング・レコード番号（ＡＲＮ：Ａｃｃｏｕｎｔｉｎｇ Ｒｅｃｏｒｄ Ｎｕｍｂｅｒ）ＡＶＰを処理することができ、この最後に受信されたメッセージは、ＡＣＲ（終了）である。ＡＲＮは、ＡＣＲ（開始）の場合に０に設定され、またそれぞれの後続のＡＣＲについては、番号は、ＡＣＲ（終了）が到達するまで、１だけ増分される。それゆえに、セッションについて受信されるＡＣＲの合計回数は、Ｎｔｏｔａｌ＝ＡＣＲ（終了）の中のＡＲＮ＋１として決定されることもある。

選択ユニット４１８はまた、セッションについてのＣＤＦ１２２によって取り扱われるアカウンティング要求の回数（Ｎｓｅｌｆ）を決定する（終了）。ＣＤＦ１２２が、このセッションについての（セッションＩＤによって示される）アカウンティング要求を受信し、また取り扱うので、ＣＤＦ１２２は、それがセッションについて取り扱うアカウンティング要求の回数を監視するようにカウンタを保持することができる。次いで、選択ユニット４１８は、セッションについてＣＤＦ１２２によって取り扱われるアカウンティング要求のパーセンテージ（Ｎ１）を算出する（ステップ５０８）。ＣＤＦ１２２によって取り扱われるアカウンティング要求のパーセンテージ（Ｎ１）は、
Ｎ１＝Ｎｓｅｌｆ／Ｎｔｏｔａｌ
によって決定される。例えば、２０回の全体のアカウンティング要求が、セッションについて取り扱われ、またＣＤＦ１２２が、これらのメッセージのうち１０回、取り扱った場合、そのときにはＣＤＦ１２２についてのアカウンティング要求のパーセンテージ（Ｎ１）は、５０％になるであろう。

ＣＤＦ１２２によって取り扱われるアカウンティング要求のパーセンテージ（Ｎ１）が５０％よりも大きい場合／ときに、選択ユニット４１８は、ＣＤＦ１２２が、セッションについてのアカウンティング要求の大多数を取り扱ってきていることを決定することができる。したがって、選択ユニット４１８は、セッションについての調停ホストとしてＣＤＦ１２２を選択する（ステップ５１０）。ＣＤＦ１２２が、セッションについてのアカウンティング要求の大多数を取り扱ってきているので、他のＣＤＦからセッションについてのアカウンティング要求のすべてを収集することが、より少ないリソースを必要とするので、ＣＤＦ１２２がセッションについての調停ホストとしての役割を果たすことが、望ましい。

ＣＤＦ１２２によって取り扱われるアカウンティング要求のパーセンテージ（Ｎ１）が５０％よりも小さい場合／ときに、選択ユニット４１８は、終了アカウンティング要求のトラッキング・パラメータにおいて示される他のＣＤＦに問い合わせを行う（ステップ５１２）。選択ユニット４１８は、各ＣＤＦによって取り扱われるアカウンティング要求の回数についてこれらのＣＤＦに問い合わせを行う。例えば、ＣＤＦ１２１とＣＤＦ１２３とが、トラッキング・パラメータにおいて示された場合、そのときには選択ユニット４１８は、それぞれ１つがセッションについて取り扱ったアカウンティング要求の回数についてＣＤＦ１２１とＣＤＦ１２３とに問い合わせを行うことができる。選択ユニット４１８は、セッションＩＤと一緒に、問い合わせの中にメッセージ・カウントについての要求を含んでいる。各ＣＤＦは、メッセージ・カウントで問い合わせに応答する。次いで、選択ユニット４１８は、最高に（すなわち、最高の回数）アカウンティング要求を取り扱ったＣＤＦに基づいて、セッションについての調停ホストを選択する（ステップ５１４）。例えば、ＣＤＦ１２１が、それが１２回のアカウンティング要求を取り扱ったことで選択ユニット４１８に応答し、またＣＤＦ１２３が、それが２０回のアカウンティング要求を取り扱ったことで選択ユニット４１８に応答する場合、そのときには選択ユニット４１８は、ＣＤＦ１２３が、セッションについての最高回数のアカウンティング要求を取り扱ったＣＤＦであったので、ＣＤＦ１２３を調停ホストとして選択することができる。２つ以上のＣＤＦが、同じ回数のアカウンティング要求を取り扱った場合、そのときには選択ユニット４１８は、乱数発生器または何らかの他のアルゴリズムに基づいて、セッションについての調停ホストを選択して、ＣＤＦのうちで公平に調停タスクを分配することができる。

選択ユニット４１８が、ステップ５１４などにおいて、調停ホスト（ＣＤＦ１２２以外の）を選択するときに、選択ユニット４１８は、調停ホストに対して通知メッセージを送信する。通知メッセージは、このＣＤＦがセッションについての調停ホストとしての役割を果たすべきであることを示しており、セッションについてのセッションＩＤを示しており、またセッションについてのアカウンティング要求を取り扱った他のＣＤＦを示してもいる。例えば、通知メッセージは、
通知（“調停ホスト、セッション＿ＩＤ、ＣＤＦ−１２１、ＣＤＦ−１２２）
である場合もある。

調停ホストが選択された後に、ホストは、セッションについてのアカウンティング要求に基づいて、セッションについてのＣＤＲを生成する。図６は、例示の一実施形態におけるＣＤＲを生成する方法６００を示すフロー・チャートである。方法６００のステップは、図４の中のＣＤＦ１２２に関連して説明されることになるが、当業者なら、方法６００が、他のシステムにおいても実行され得ることを理解するであろう。

この実施形態についても再び、ＣＤＦ１２２が調停ホストとして選択されたことを仮定する。ＣＤＦジェネレータ４２０は、セッションについてアカウンティング要求を取り扱った他のＣＤＦを識別する（ステップ６０２）。例えば、終了アカウンティング要求におけるトラッキング・パラメータは、セッションについてのアカウンティング要求を取り扱ったすべてのＣＤＦを示している。調停ホストが終了アカウンティング要求を受信した場合、そのときには調停ホストは、終了アカウンティング要求のトラッキング・パラメータを処理して、他のＣＤＦを識別することができる。調停ホストが終了アカウンティング要求を受信しなかった場合、そのときには調停ホストは、セッションについての他のアカウンティング要求を示す、上記で説明されるような通知メッセージを受信するであろう。

ＣＤＲジェネレータ４２０は、次いで、セッションについてのアカウンティング要求について他のＣＤＦに問い合わせを行う（ステップ６０４）。例えば、ＣＤＲジェネレータ４２０は、ある与えられたセッションＩＤに関連するアカウンティング要求についてＣＤＦ１２１とＣＤＦ１２３とに問い合わせを行うことができる。他のＣＤＦは、アカウンティング要求を用いてＣＤＦジェネレータ４２０に返答する。ＣＤＲジェネレータ４２０は、セッションについてのアカウンティング要求を処理して、ＣＤＲを生成することができる（ステップ６０６）。ダイアメータ・プロトコルを使用した例として、調停ホストは、ＡＲＮ ＡＶＰにおける値に基づいて、セッションについてのＡＣＲを照合し、どのような二重のＡＣＲ（ＡＲＮと一緒にメッセージのダイアメータ・ヘッダにおいて設定される再送信ビットによって示される）も取り除き、またＡＣＲに基づいて、セッションについてのＣＤＲを生成することができる。次いで、ＣＤＲジェネレータ４２０は、インターフェース４１２を通してＣＧＦ（例えば、ＣＧＦ１３２）に対してＣＤＲを送信することができる（ステップ６０８）。

この実施形態においては、調停ホストは、終了アカウンティング要求のトラッキング・パラメータの中の情報に基づいて、どのＣＤＦがセッションについてのアカウンティング要求を有するかを知っている。したがって、調停ホストは、ＣＤＦのうちのどれが与えられたセッションＩＤについてのアカウンティング要求を保持することができるかについて推測しなければならない代わりに、どのＣＤＦにアカウンティング要求について問い合わせを行うべきかを正確に知っている。これは、ＣＤＲを生成するプロセスをさらにいっそう効率的に、またＯＦＣＳの内部のリソースに対する負担をより少なくしている。

図面に示され、または本明細書において説明される様々な要素またはモジュールのうちのどれもが、ハードウェア、ソフトウェア、ファームウェア、またはこれらの何らかの組合せとして実装される可能性がある。例えば、ある要素は、専用のハードウェアとして実装されることもある。専用のハードウェア要素は、「プロセッサ」、「制御装置」、または何らかの類似した専門用語と称されることもある。プロセッサによって提供されるときに、それらの機能は、単一の専用プロセッサにより、単一の共用プロセッサにより、または複数の個別プロセッサによって提供されることもあり、これらの個別プロセッサのうちのうちのいくつかは、共用されることもある。さらに、「プロセッサ」または「制御装置」という用語の明示的な使用は、ソフトウェアを実行することができるハードウェアだけを排他的に意味するように解釈されるべきではなく、また限定することなく、デジタル信号プロセッサ（ＤＳＰ：ｄｉｇｉｔａｌ ｓｉｇｎａｌ ｐｒｏｃｅｓｓｏｒ）のハードウェア、ネットワーク・プロセッサ、特定用途向け集積回路（ＡＳＩＣ：ａｐｐｌｉｃａｔｉｏｎ ｓｐｅｃｉｆｉｃ ｉｎｔｅｇｒａｔｅｄ ｃｉｒｃｕｉｔ）または他の回路、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ：ｆｉｅｌｄ ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ）、ソフトウェアを記憶するためのリード・オンリー・メモリ（ＲＯＭ：ｒｅａｄ ｏｎｌｙ ｍｅｍｏｒｙ）、ランダム・アクセス・メモリ（ＲＡＭ：ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）、不揮発性ストレージ、ロジック、あるいは何らかの他の物理的なハードウェアのコンポーネントまたはモジュールを暗黙のうちに含むことができる。

また、ある要素は、プロセッサまたはコンピュータによって実行可能な命令として実装されて、その要素の機能を実行することができる。命令のいくつかの例は、ソフトウェアと、プログラム・コードと、ファームウェアとである。それらの命令は、プロセッサによって実行されるときに、要素の機能を実行するようにプロセッサに指示するように、動作可能である。それらの命令は、プロセッサによって読み取り可能であるストレージ・デバイスの上に記憶されることもある。ストレージ・デバイスのいくつかの例は、デジタル・メモリまたはソリッド・ステート・メモリ、磁気ディスクや磁気テープなどの磁気ストレージ媒体、ハード・ドライブ、あるいは光学的に読み取り可能なデジタル・データ・ストレージ媒体である。

特定の実施形態が、本明細書において説明されたが、本開示の範囲は、これらの特定の実施形態だけに限定されることはない。本開示の範囲は、添付の特許請求の範囲と、それらの任意の均等物とによって規定される。

Claims (10)

1. オフライン課金のための複数の課金データ機能（ＣＤＦ）に接続するように構成されたディストリビュータ・ユニットを備えており、
   前記ディストリビュータ・ユニットは、セッションについての課金トリガ機能（ＣＴＦ）から中間アカウンティング要求を受信するように構成されたプロセッサを備えており、前記中間アカウンティング要求は、前記セッションについてのアカウンティング要求を取り扱った少なくとも１つの宛先ＣＤＦを示している少なくとも１つのＣＤＦ識別子（ＩＤ）が入力されたトラッキング・パラメータを含んでおり、
   前記ディストリビュータ・ユニットは、前記セッションについてのアカウンティング要求を取り扱った第１の宛先ＣＤＦについての第１のＣＤＦ ＩＤを識別するために、前記中間アカウンティング要求における前記トラッキング・パラメータを処理するように構成されており、
   前記第１の宛先ＣＤＦが、前記中間アカウンティング要求を受信するために使用可能であるときに、前記ディストリビュータ・ユニットは、前記第１の宛先ＣＤＦに対して前記中間アカウンティング要求を送信するように構成されており、
   前記第１の宛先ＣＤＦが前記中間アカウンティング要求を受信するために使用可能でないときに、前記ディストリビュータ・ユニットは、配信アルゴリズムに基づいて、前記中間アカウンティング要求についての第２の宛先ＣＤＦを選択し、前記中間アカウンティング要求の前記トラッキング・パラメータの中に前記第２の宛先ＣＤＦについての第２のＣＤＦ ＩＤを追加し、また前記第２の宛先ＣＤＦに対して前記中間アカウンティング要求を送信するように構成されている、装置。
2. 前記ディストリビュータ・ユニットは、前記第２のＣＤＦ ＩＤの出現について前記トラッキング・パラメータをスキャンし、また前記第２のＣＤＦ ＩＤが前記トラッキング・パラメータの中にまだ出現していないときに、前記トラッキング・パラメータの中に前記第２のＣＤＦ ＩＤを追加するように構成されている、請求項１に記載の装置。
3. 前記ディストリビュータ・ユニットは、前記配信アルゴリズムに基づいて、前記第２の宛先ＣＤＦを選択することに応じて、前記トラッキング・パラメータの中に前記第２のＣＤＦ ＩＤを追加するように構成されており、その結果、前記トラッキング・パラメータは、前記セッションについてのアカウンティング要求を取り扱った宛先ＣＤＦのシーケンスを示している、請求項１に記載の装置。
4. 前記中間アカウンティング要求は、ダイアメータ・アカウンティング要求（ＡＣＲ）を含んでおり、また
   前記トラッキング・パラメータは、前記セッションについてのアカウンティング要求を取り扱った前記ＣＤＦを示している前記ＣＤＦ ＩＤについて規定されたダイアメータ属性値ペア（ＡＶＰ）を含んでいる、請求項１に記載の装置。
5. 前記セッションに対する終了を示す前記ＣＴＦから、前記トラッキング・パラメータを含む終了アカウンティング要求を受信するように構成された前記第２の宛先ＣＤＦ
   をさらに備えており、
   前記第２の宛先ＣＤＦは、前記セッションについての前記アカウンティング要求の合計回数を決定し、前記第２の宛先ＣＤＦによって取り扱われるアカウンティング要求の回数を決定し、また前記第２の宛先ＣＤＦによって取り扱われるアカウンティング要求のパーセンテージを算出するように構成されており、
   前記第２の宛先ＣＤＦによって取り扱われるアカウンティング要求の前記パーセンテージが５０％よりも大きいときに、前記第２の宛先ＣＤＦは、前記セッションについての課金データ・レコード（ＣＤＲ）を生成する調停ホストとしてそれ自体を選択するように構成されており、
   前記第２の宛先ＣＤＦによって取り扱われるアカウンティング要求の前記パーセンテージが５０％よりも小さいときに、前記第２の宛先ＣＤＦは、各宛先ＣＤＦによって取り扱われるアカウンティング要求の回数についての前記トラッキング・パラメータの中に示される他の宛先ＣＤＦへの問い合わせを行い、また最高回数のアカウンティング要求を取り扱った前記宛先ＣＤＦに基づいて、前記調停ホストを選択するように構成されている、請求項１に記載の装置。
6. セッションについての課金トリガ機能（ＣＴＦ）から、オフライン課金についての複数の課金データ機能（ＣＤＦ）に接続しているディストリビュータ・ユニットにおける中間アカウンティング要求を受信するステップであって、
   前記中間アカウンティング要求は、前記セッションについてのアカウンティング要求を取り扱った少なくとも１つの宛先ＣＤＦを示している少なくとも１つのＣＤＦ識別子（ＩＤ）が入力されたトラッキング・パラメータを含んでいる、受信するステップと、
   前記セッションについてのアカウンティング要求を取り扱った第１の宛先ＣＤＦについての第１のＣＤＦ ＩＤを識別するために、前記中間アカウンティング要求における前記トラッキング・パラメータを処理するステップと、
   前記第１の宛先ＣＤＦが前記中間アカウンティング要求を受信するために使用可能であるときに、前記第１の宛先ＣＤＦに対して前記中間アカウンティング要求を送信するステップと、
   前記第１の宛先ＣＤＦが前記中間アカウンティング要求を受信するために使用可能でないときに、
   配信アルゴリズムに基づいて、前記中間アカウンティング要求についての第２の宛先ＣＤＦを選択するステップと、
   前記中間アカウンティング要求の前記トラッキング・パラメータの中に前記第２の宛先ＣＤＦについての第２のＣＤＦ ＩＤを追加するステップと、
   前記第２の宛先ＣＤＦに対して前記中間アカウンティング要求を送信するステップと、
   を含む、方法。
7. 前記中間アカウンティング要求の前記トラッキング・パラメータの中に前記第２の宛先ＣＤＦについての第２のＣＤＦ ＩＤを追加するステップは、
   前記第２のＣＤＦ ＩＤの出現について前記トラッキング・パラメータをスキャンするステップと、
   前記第２のＣＤＦ ＩＤが前記トラッキング・パラメータの中にまだ出現していないときに、前記トラッキング・パラメータの中に前記第２のＣＤＦ ＩＤを追加するステップと、
   を含む、請求項６に記載の方法。
8. 前記中間アカウンティング要求の前記トラッキング・パラメータの中に前記第２の宛先ＣＤＦについての第２のＣＤＦ ＩＤを追加するステップは、
   前記配信アルゴリズムに基づいて、前記第２の宛先ＣＤＦを選択するステップに応じて、前記トラッキング・パラメータの中に前記第２のＣＤＦ ＩＤを追加するステップであって、その結果、前記トラッキング・パラメータは、前記セッションについてのアカウンティング要求を取り扱った宛先ＣＤＦのシーケンスを示している、追加するステップ
   を含む、請求項６に記載の方法。
9. 前記中間アカウンティング要求は、ダイアメータ・アカウンティング要求（ＡＣＲ）を含んでおり、また
   前記トラッキング・パラメータは、前記セッションについてのアカウンティング要求を取り扱った前記ＣＤＦを示している前記ＣＤＦ ＩＤについて規定されたダイアメータ属性値ペア（ＡＶＰ）を含んでいる、請求項６に記載の方法。
10. 前記セッションに対する終了を示している前記ＣＴＦから前記第２の宛先ＣＤＦにおける終了アカウンティング要求を受信するステップであって、前記終了アカウンティング要求は、前記トラッキング・パラメータを含んでいる、受信するステップと、
    前記第２の宛先ＣＤＦにおいて、前記セッションについての前記アカウンティング要求の合計回数を決定するステップと、
    前記第２の宛先ＣＤＦによって取り扱われるアカウンティング要求の回数を決定するステップと、
    前記第２の宛先ＣＤＦによって取り扱われるアカウンティング要求のパーセンテージを算出するステップと、
    前記第２の宛先ＣＤＦによって取り扱われるアカウンティング要求の前記パーセンテージが５０％よりも大きいときに、前記セッションについての課金データ・レコード（ＣＤＲ）を生成する調停ホストとして前記第２の宛先ＣＤＦを選択するステップと、
    前記第２の宛先ＣＤＦによって取り扱われるアカウンティング要求の前記パーセンテージが５０％よりも小さいときに、各宛先ＣＤＦによって取り扱われるアカウンティング要求の回数についての前記トラッキング・パラメータの中に示される他の宛先ＣＤＦの問い合わせを行い、また最高回数のアカウンティング要求を取り扱った前記宛先ＣＤＦに基づいて、前記調停ホストを選択するステップと、
    をさらに含む、請求項６に記載の方法。

Images