(57)【要約】  サービス・プロバイダ・ネットワークのネットワーク要素（ＮＥ）によって提供されるサービスの明細を明らかにする課金システムを使用するための方法は、課金システムにおけるルータにおいて、ＮＥからアカウンティング要求（ＡＣＲ）を受信するステップであって、ＡＣＲは、通信セッションに関連して、サービス・プロバイダ・ネットワークにおけるＮＥによって提供されるサービスに関連づけられる、受信するステップと、修正されたＡＣＲを形成するように、ＡＣＲを修正するステップと、課金収集機能（ＣＣＦ）サーバに対して修正されたＡＣＲを送信するステップと、ＣＣＦサーバが、修正されたＡＣＲを処理することができなかったことを示すアカウンティング応答をＣＣＦサーバから受信するステップと、ＣＣＦサーバに対して修正されたＡＣＲを再送信するステップ、または改訂されたＡＣＲを形成するように、修正されたＡＣＲを変更するステップ、および代替のＣＣＦサーバに対して改訂されたＡＣＲを送信するステップとを含む。本方法に関連するルータは、サービス・ネットワーク通信モジュールと、メッセージ処理モジュールと、課金システム通信モジュールとを含む。
2014531875.tif 000002
【特許請求の範囲】
【請求項１】
サービス・プロバイダ・ネットワークのネットワーク要素によって提供されるサービスの明細を明らかにする課金システムを使用するための方法であって、
課金システムにおけるルータにおいて、サービス・プロバイダ・ネットワークのネットワーク要素からアカウンティング要求を受信するステップであって、前記アカウンティング要求は、通信セッションに関連して、前記サービス・プロバイダ・ネットワークにおける前記ネットワーク要素によって提供されるサービスに関連づけられ、前記課金システムは、１つまたは複数の通信セッションに関連して、前記サービス・プロバイダ・ネットワークの１つまたは複数のネットワーク要素からのアカウンティング要求を処理するための、前記ルータに関連する複数の課金収集機能サーバを含む、受信するステップと、
修正されたアカウンティング要求を形成するように、前記ルータにおいて前記受信されたアカウンティング要求を修正するステップと、
前記ルータから、前記複数の課金制御機能サーバから選択される第１の課金収集機能サーバへ前記修正されたアカウンティング要求を送信するステップと、
前記第１の課金収集機能サーバが、前記修正されたアカウンティング要求を処理することができなかったことを示すアカウンティング応答を前記ルータにおける前記第１の課金収集機能サーバから受信するステップと、
前記ルータから前記第１の課金収集機能サーバへと前記修正されたアカウンティング要求を再送信するステップ、または改訂されたアカウンティング要求を形成するように、前記ルータにおいて前記修正されたアカウンティング要求を変更し、前記ルータから、前記複数の課金制御機能サーバから選択される代替の課金収集機能サーバへと前記改訂されたアカウンティング要求を送信するステップと
を含む方法。
【請求項２】
前記受信されたアカウンティング要求における情報に少なくとも部分的に基づいて、前記ルータにおいて、前記修正されたアカウンティング要求についての宛先として前記第１の課金収集機能サーバを選択するステップ
をさらに含む、請求項１に記載の方法。
【請求項３】
前記修正されたアカウンティング要求の中間のソースとして前記ルータを表現するために、前記受信されたアカウンティング要求を修正することに関連して、前記受信されたアカウンティング要求の発信元のソースとして前記ネットワーク要素を表現する起点情報を変更するステップと、
前記修正されたアカウンティング要求の選択された宛先として前記第１の課金収集機能サーバを表現するために、前記受信されたアカウンティング要求を修正することに関連して、前記受信されたアカウンティング要求の中間の宛先として前記ルータを表現する宛先情報を変更するステップと、
前記修正されたアカウンティング要求における前記受信されたアカウンティング要求の前記発信元のソースとして前記ネットワーク要素を表現するために、前記受信されたアカウンティング要求を修正することに関連して、前記受信されたアカウンティング要求にルート・レコード情報を追加するステップと
をさらに含む、請求項１に記載の方法。
【請求項４】
前記アカウンティング応答が、前記第１の課金収集機能サーバが過負荷状態に起因して、前記修正されたアカウンティング要求を処理することができないことを示すことを判定するステップをさらに含み、前記修正されたアカウンティング要求は、前記改訂されたアカウンティング要求を形成するように、変更され、前記改訂されたアカウンティング要求は、前記修正されたアカウンティング要求を再送信する代わりに前記代替の課金収集機能サーバに対して送信される、請求項１に記載の方法。
【請求項５】
前記アカウンティング応答が、前記第１の課金収集機能サーバが過渡的な故障状態に起因して前記修正されたアカウンティング要求を処理することができないことを示すことを判定するステップをさらに含み、前記修正されたアカウンティング要求は、前記改訂されたアカウンティング要求を送信する代わりに前記第１の課金収集機能サーバに対して再送信される、請求項１に記載の方法。
【請求項６】
サービス・プロバイダ・ネットワークのネットワーク要素によって提供されるサービスの明細を明らかにする課金システムにおいて使用するための装置であって、
サービス・プロバイダ・ネットワークのネットワーク要素からアカウンティング要求を受信するためのサービス・ネットワーク通信モジュールであって、前記アカウンティング要求は、通信セッションに関連して、前記サービス・プロバイダ・ネットワークにおける前記ネットワーク要素によって提供されるサービスに関連づけられ、前記課金システムは、１つまたは複数の通信セッションに関連して、前記サービス・プロバイダ・ネットワークの１つまたは複数のネットワーク要素からのアカウンティング要求を処理するための複数の課金収集機能サーバを含む、サービス・ネットワーク通信モジュールと、
修正されたアカウンティング要求を形成するように、前記受信されたアカウンティング要求を修正するための前記サービス・ネットワーク通信モジュールと動作可能に通信しているメッセージ処理モジュールと、
前記複数の課金制御機能サーバから選択される第１の課金収集機能サーバに対して前記修正されたアカウンティング要求を送信するための前記メッセージ処理モジュールと動作可能に通信している課金システム通信モジュールと
を備え、
前記課金システム通信モジュールはまた、前記第１の課金収集機能サーバが、前記修正されたアカウンティング要求を処理することができなかったことを示すアカウンティング応答を前記第１の課金収集機能サーバから受信するためのものであり、
前記メッセージ処理モジュールはまた、前記課金システム通信モジュールを経由して前記第１の課金収集機能サーバに対して前記修正されたアカウンティング要求を再送信すべきか、または改訂されたアカウンティング要求を形成するように、前記修正されたアカウンティング要求を変更し、前記課金システム通信モジュールを経由して代替の課金収集機能サーバに対して前記改訂されたアカウンティング要求を送信すべきかを決定するためのものであり、前記代替の課金収集機能サーバは、前記複数の課金制御機能サーバから選択されている、装置。
【請求項７】
前記メッセージ処理モジュールはまた、前記受信されたアカウンティング要求における情報に少なくとも部分的に基づいて、前記修正されたアカウンティング要求についての宛先として前記第１の課金収集機能サーバを選択するためのものである、請求項６に記載の装置。
【請求項８】
前記メッセージ処理モジュールはまた、前記修正されたアカウンティング要求の中間のソースとして前記装置を表現するために、前記受信されたアカウンティング要求を修正することに関連して、前記受信されたアカウンティング要求の発信元のソースとして前記ネットワーク要素を表現する起点情報を変更し、前記修正されたアカウンティング要求の選択された宛先として前記第１の課金収集機能サーバを表現するために、前記受信されたアカウンティング要求を修正することに関連して、前記受信されたアカウンティング要求の中間の宛先として前記装置を表現する宛先情報を変更し、また前記修正されたアカウンティング要求における前記受信されたアカウンティング要求の前記発信元のソースとして前記ネットワーク要素を表現するために、前記受信されたアカウンティング要求を修正することに関連して、前記受信されたアカウンティング要求にルート・レコード情報を追加するためのものである、請求項６に記載の装置。
【請求項９】
前記メッセージ処理モジュールはまた、前記アカウンティング応答が、前記第１の課金収集機能サーバが過負荷状態に起因して前記修正されたアカウンティング要求を処理することができないことを示すことを判定し、また前記修正されたアカウンティング要求が、前記改訂されたアカウンティング要求を形成するように、変更され、前記修正されたアカウンティング要求を再送信する代わりに前記課金システム通信モジュールにより前記代替の課金収集機能サーバに対して送信されるべきであることを決定し、また前記複数の課金収集機能サーバのうちの処理する負荷の分布に関連した負荷分布関数を含むアルゴリズムに少なくとも部分的に基づいて前記修正されたアカウンティング要求についての代替の宛先として前記代替の課金収集機能サーバを選択するためのものであり、前記装置は、
リンクされた関係にある前記通信セッションのためのセッション識別子と、発信元のソース識別子と、選択された宛先識別子とを記憶するためのストレージ・デバイス
をさらに備える、請求項６に記載の装置。
【請求項１０】
前記メッセージ処理モジュールはまた、前記アカウンティング応答が、前記第１の課金収集機能サーバが過渡的な故障状態に起因して前記修正されたアカウンティング要求を処理することができないことを示すことを判定し、また前記修正されたアカウンティング要求が、前記改訂されたアカウンティング要求を送信する代わりに前記課金システム通信モジュールにより前記第１の課金収集機能サーバに対して再送信されるべきであることを決定するためのものである、請求項６に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、サービス・プロバイダ・ネットワークのネットワーク要素（ＮＥ：ｎｅｔｗｏｒｋ  ｅｌｅｍｅｎｔ）によって提供されるサービスの明細を明らかにする課金システムにおけるルータの使用に関する。ルータおよびその使用についての方法の例示の実施形態が説明される。ルータは、サービス・プロバイダ・ネットワークにおいて、ＮＥからアカウンティング要求（ＡＣＲ：ａｃｃｏｕｎｔｉｎｇ  ｒｅｑｕｅｓｔｓ）を受信し、課金システムにおける課金制御機能（ＣＣＦ：ｃｈａｒｇｅ  ｃｏｎｔｒｏｌ  ｆｕｎｃｔｉｏｎｓ）に対してＡＣＲをルーティングするためのプロキシとして、またアカウンティング応答（ＡＣＡ：ａｃｃｏｕｎｔｉｎｇ  ａｎｓｗｅｒｓ）についてはＡＣＲとは逆の作動をするためのプロキシとしての機能を果たす。ルータは、ＡＣＡが、過負荷や過渡的な故障状態など、ある種のエラー状態または故障状態を示すときに、ＡＣＲについてさらに処理するためのインテリジェンスを提供する。これらの状態では、ルータは、ＡＣＲを同じＣＣＦに対して送信することを再試行すべきか否か、または代替のＣＣＦを選択すべきか否かを決定することができる。処理のためにＡＣＲをサブミットする、ルータによる後続の試みが、成功する場合、問題は、ＮＥを必要とすることなく解決される。様々な実施形態では、ＣＣＦがＡＣＲを処理するためにはあまりにもビジーであること（すなわち、結果コード３００４）、またはＣＣＦがＡＣＲを処理するためには少なくとも一時的に容量不足になっていること（すなわち、結果コード４００２）をＡＣＡが示す場合のエラー状態および故障状態について説明される。しかしながら、本明細書において説明される方法および装置を使用して、他の種類のエラー状態および故障状態を処理することもできる。
【背景技術】
【０００２】
電気通信ネットワークおよびデータ・ネットワークにおいては、オフラインの課金が、ＣＣＦを実装する多数のサーバによって提供される。ＣＣＦは、サービス・プロバイダにとって企業運営に不可欠な部分である。ＣＣＦは、サービス・プロバイダ・ネットワークに関連する通信セッションについての使用料を累積する複数のＣＣＦサーバ（すなわち、ノード）を含むことができる。例えば、サービス・プロバイダ・ネットワークは、様々なレガシー通信ネットワークと、インターネット・プロトコル（ＩＰ：ｉｎｔｅｒｎｅｔ  ｐｒｏｔｏｃｏｌ）マルチメディア・サブシステム（ＩＭＳ：ｉｎｔｅｒｎｅｔ  ｐｒｏｔｏｃｏｌ  ｍｕｌｔｉｍｅｄｉａ  ｓｕｂｓｙｓｔｅｍ）ネットワークと、ロング・ターム・エボリューション（ＬＴＥ：ｌｏｎｇ  ｔｅｒｍ  ｅｖｏｌｕｔｉｏｎ）ネットワークと、任意の適切な組合せでのその他の適切な通信サービス・ネットワークとを含むことができる。ＣＣＦは、これらの通信サービス・ネットワークにおいて、シグナリングＮＥおよびベアラＮＥからＡＣＲを受信する。ＮＥは、課金トリガ機能（ＣＴＦ：ｃｈｅｒｇｉｎｇ  ｔｒｉｇｇｅｒ  ｆｕｎｃｔｉｏｎ）を実装する。ＮＥの内部で統合されるＣＴＦは、ＣＣＦに対してＡＣＲを提供する。アカウンティングは、ショート・メッセージを送信する、または受信するなどのイベント、あるいは開始通知で開始され、ゼロ以上の中間のアカウンティング・メッセージのやりとりが行われ、停止通知で終了するセッションに関連したイベントにおけるように、離散的とすることができる。ＣＣＦは、ＡＣＡメッセージを経由してＡＣＲメッセージに肯定応答する。ＡＣＲメッセージとＡＣＡメッセージとは、例えば、ダイアメーター・ベース・プロトコル（Ｄｉａｍｅｔｅｒ  Ｂａｓｅ  Ｐｒｏｔｏｃｏｌ）に基づいたものとすることができる（リクエスト・フォー・コメンツ（ＲＦＣ：Ｒｅｑｕｅｓｔ  ｆｏｒ  Ｃｏｍｍｅｎｔｓ）３５８８を参照されたい）。ＲＦＣ  ３５８８ダイアメーター・ベース・プロトコルの内容は、参照により本明細書に完全に組み込まれている。ダイアメーター・ベース・プロトコルは、伝送制御プロトコル（ＴＣＰ）／ＩＰ、またはストリーム制御伝送プロトコル（ＳＣＴＰ）上で実行される。
【０００３】
大規模ネットワークにおいては、ＣＣＦの中に数百個のＣＴＦと、数十台のＣＣＦサーバとを見ることが、一般的である。セキュリティの理由のために、ＣＣＦサーバにおいてプロビジョニングされたＣＴＦのアイデンティティを有することが、一般的である。これにより、アカウンティング・メッセージが、ＣＴＦから到着するときに、対応するＣＣＦサーバが、メッセージが知られている、または信頼されているホストから来ていると判定できることが保証される。しかしながら、このセキュリティの様相は、プロビジョニング問題を引き起こし、ここでは、数百個のＣＴＦのうちのおのおのは、数十台のＣＣＦサーバのうちのおのおのにおいて個々に規定される必要がある。この問題を軽減するために、ダイアメーター・ルータ（Ｄ−ＲＴＲ）が使用されてもよい。例えば、図１は、Ｄ−ＲＴＲを有する課金システムを示すものである。Ｄ−ＲＴＲは、インテリジェント・プロキシ、またはインテリジェント・ルータとしての機能を果たす。例えば、数百個のＣＴＦのうちのおのおのから報告される各セッションは、Ｄ−ＲＴＲにおいて終了することができる。それに応じて、Ｄ−ＲＴＲは、ＣＣＦサーバに向かうメッセージングを開始する。ＣＣＦサーバからの応答は、Ｄ−ＲＴＲにおいて終了する。Ｄ−ＲＴＲは、対応するＡＣＲを開始した元のＣＴＦに対してそれらの応答を搬送して戻す。
ネットワーク要素＜Ｄ−ＲＴＲ＞ＣＣＦ−１、ＣＣＦ−２．．．ＣＣＦ−Ｎ
ＣＴＦを実装する＜機能＞
【０００４】
ここで、Ｄ−ＲＴＲのタスクは、ＡＣＲが、ＣＣＦサーバの間に多かれ少なかれ均一に分布していることを保証することである。ＣＴＦが参加している各通信セッションについての簡単なラウンド・ロビン方法として見られ得る、ＣＴＦの内部のクライアント・ベースのＣＣＦ負荷分布関数（ＬＤＦ：ｌｏａｄ  ｄｉｓｔｒｉｂｕｔｉｏｎ  ｆｕｎｃｔｉｏｎ）とは違って、Ｄ−ＲＴＲは、複数のＣＴＦと、複数台のＣＣＦサーバとにサービスしながら、２つの原理の制約条件、すなわち、１）１つのＮＥ／ＣＴＦからのダイアメーター・セッションの内部のＡＣＲは、同じＣＣＦサーバに対して転送される必要があり、また２）ＣＣＦサーバにより応答して送信されるＡＣＡメッセージは、対応するＡＣＲのＮＥ／ＣＴＦ発信元に対して搬送される必要があるという原理の制約条件の内部で動作する必要がある。
【０００５】
Ｄ−ＲＴＲの利点は、それが、一方でネットワーク・トポロジを隠し、その結果、ＣＴＦは、例えば、ＣＣＦの機能停止状態または故障状態の場合に、ＣＣＦサーバまたは代替のピアの選択について心配する必要なしに、それらのＡＣＲメッセージの宛先としてＤ−ＲＴＲを使用することができることである。Ｄ−ＲＴＲは、それが、進行中のセッションのカウントを、または個別のＣＣＦサーバの負荷搬送容量さえも監視して、新しいアカウンティング・セッションについての宛先を決定することができるという追加の利点を提供する。これは、ＣＣＦサーバが、多かれ少なかれ、それらのエンジニアが設計した限度以下で負荷をかけられるように保持する。
【０００６】
しかしながら、追加の問題を作り出すのは、トポロジを隠す部分である。既存の構成においては、特定のＣＣＦサーバが、過負荷を進展させ、または過渡的なエラー状態を報告し、また代替のピアを試みるようにＮＥ／ＣＴＦに示すときに、ＲＦＣ  ３５８８のように、対応するＮＥ／ＣＴＦは、それが、ＣＣＦサーバのトポロジが対応するＮＥ／ＣＴＦの視界から隠されるので、代替のピアを選択することができないようになるので、これに対してどのように反応すべきかを知らないであろう。既存のＤ−ＲＴＲ構成においては、万一ＮＥ／ＣＴＦが、ＡＣＲを再送信する場合に、上記で述べられる第１の原理の制約条件の下で機能する（すなわち、与えられたセッションについて与えられたＣＴＦから同じＣＣＦサーバへとＡＣＲを転送する）Ｄ−ＲＴＲは、ＣＴＦが代替のピアを選択すべきことを正に示した同じＣＣＦサーバに対してＡＣＲを送信する傾向があることになる。これは、少なくとも過負荷にされたＣＣＦサーバが過負荷状態から回復することができるまで、または過渡的なエラーが治まるまで、無限のまたは終わりのないループ状況を作り出す。Ｄ−ＲＴＲは、それが、一般的にＣＣＦサーバにおける負荷状況について知らないので、ＡＣＲメッセージを同じＣＣＦサーバに対して再送し続けるので、その状況は、さらに悪化させられ、また過負荷にされたＣＣＦサーバの回復は、さらに遅延させられる。
【０００７】
上記に基づいて、技法は、ＡＣＲを処理するために現在選択されているＣＣＦサーバが、ある種のタイプのエラー状態または故障状態を経験しているときに、課金システムにおけるルータが、ＡＣＲのインテリジェントなメッセージ処理を提供することを可能にする。さらに、ルータは、ＡＣＲを発信したＮＥを必要とすることなく、そのような状態を解決することできることが、望ましい。
【発明の概要】
【課題を解決するための手段】
【０００８】
一態様においては、サービス・プロバイダ・ネットワークのＮＥによって提供されるサービスの明細を明らかにする課金システムを使用するための方法が、提供される。一実施形態においては、本方法は、課金システムにおけるルータにおいて、サービス・プロバイダ・ネットワークのＮＥからＡＣＲを受信するステップであって、ＡＣＲは、通信セッションに関連して、サービス・プロバイダ・ネットワークにおけるＮＥによって提供されるサービスに関連づけられ、課金システムは、１つまたは複数の通信セッションに関連して、サービス・プロバイダ・ネットワークの１つまたは複数のＮＥからのＡＣＲを処理するための、ルータに関連する複数のＣＣＦサーバを含む、受信するステップと、修正されたＡＣＲを形成するように、ルータにおいて受信されたＡＣＲを修正するステップと、ルータから、複数の課金制御機能サーバから選択される第１のＣＣＦサーバへと修正されたＡＣＲを送信するステップと、第１のＣＣＦサーバが、修正されたＡＣＲを処理することができなかったことを示すＡＣＡをルータにおける第１のＣＣＦサーバから受信するステップと、ルータから第１のＣＣＦサーバへと修正されたＡＣＲを再送信するステップ、または改訂されたＡＣＲを形成するように、ルータにおいて修正されたＡＣＲを変更するステップ、およびルータから、複数の課金制御機能サーバから選択される代替のＣＣＦサーバへと改訂されたＡＣＲを送信するステップとを含む。
【０００９】
別の態様においては、サービス・プロバイダ・ネットワークのＮＥによって提供されるサービスの明細を明らかにする課金システムにおいて使用するための装置が、提供される。一実施形態においては、本装置は、サービス・プロバイダ・ネットワークのＮＥからＡＣＲを受信するためのサービス・ネットワーク通信モジュールであって、ＡＣＲは、通信セッションに関連して、サービス・プロバイダ・ネットワークにおけるＮＥによって提供されるサービスに関連づけられ、課金システムは、１つまたは複数の通信セッションに関連して、サービス・プロバイダ・ネットワークの１つまたは複数のＮＥからのＡＣＲを処理するための複数のＣＣＦサーバを含む、サービス・ネットワーク通信モジュールと、修正されたＡＣＲを形成するように、受信されたＡＣＲを修正するための、サービス・ネットワーク通信モジュールと動作可能に通信しているメッセージ処理モジュールと、複数の課金制御機能サーバから選択される第１のＣＣＦサーバに対して修正されたＡＣＲを送信するための、メッセージ処理モジュールと動作可能に通信している課金システム通信モジュールとを含む。この実施形態においては、課金システム通信モジュールはまた、第１のＣＣＦサーバが、修正されたＡＣＲを処理することができなかったことを示すＡＣＡを第１のＣＣＦサーバから受信するためのものでもある。説明されている実施形態においては、メッセージ処理モジュールはまた、課金システム通信モジュールを経由して第１のＣＣＦサーバに対して修正されたＡＣＲを再送信すべきか、または改訂されたＡＣＲを形成するように、修正されたＡＣＲを変更し、また課金システム通信モジュールを経由して代替のＣＣＦサーバに対して改訂されたＡＣＲを送信すべきかを決定するためのものでもあり、代替のＣＣＦサーバは、複数の課金制御機能サーバから選択されている。
【００１０】
別の態様においては、プログラム命令を記憶する非一時的コンピュータ読取り可能媒体が、提供される。コンピュータによって実行されるときに、プログラム命令は、課金システムにおける対応するコンピュータ制御されたルータが、サービス・プロバイダ・ネットワークのＮＥによって提供されるサービスの明細を明らかにする課金システムを使用するための方法を実行するようにさせる。一実施形態においては、本方法は、課金システムにおけるルータにおいて、サービス・プロバイダ・ネットワークのＮＥからＡＣＲを受信するステップであって、ＡＣＲは、通信セッションに関連して、サービス・プロバイダ・ネットワークにおけるＮＥによって提供されるサービスに関連づけられ、課金システムは、１つまたは複数の通信セッションに関連して、サービス・プロバイダ・ネットワークの１つまたは複数のＮＥからのＡＣＲを処理するための、ルータに関連する複数のＣＣＦサーバを含む、受信するステップと、修正されたＡＣＲを形成するように、ルータにおいて受信されたＡＣＲを修正するステップと、ルータから、複数の課金制御機能サーバから選択される第１のＣＣＦサーバへと修正されたＡＣＲを送信するステップと、第１のＣＣＦサーバが、修正されたＡＣＲを処理することができなかったことを示すＡＣＡをルータにおける第１のＣＣＦサーバから受信するステップと、ルータから第１のＣＣＦサーバへと修正されたＡＣＲを再送信するステップ、または改訂されたＡＣＲを形成するように、ルータにおいて修正されたＡＣＲを変更するステップ、およびルータから、複数の課金制御機能サーバから選択される代替のＣＣＦサーバへと改訂されたＡＣＲを送信するステップとを含む。
【００１１】
別の態様においては、サービス・プロバイダ・ネットワークのネットワーク要素によって提供されるサービスの明細を明らかにする課金システムを使用するための方法が、提供される。一実施形態においては、本方法は、課金システムにおけるルータにおいて、サービス・プロバイダ・ネットワークのネットワーク要素からアカウンティング要求を受信するステップであって、アカウンティング要求は、通信セッションに関連して、サービス・プロバイダ・ネットワークにおけるネットワーク要素によって提供されるサービスに関連づけられ、課金システムは、１つまたは複数の通信セッションに関連して、サービス・プロバイダ・ネットワークの１つまたは複数のネットワーク要素からのアカウンティング要求を処理するための、ルータに関連する複数の課金収集機能サーバを含む、受信するステップと、修正されたアカウンティング要求を形成するように、ルータにおいて受信されたアカウンティング要求を修正するステップと、ルータから、複数の課金制御機能サーバから選択される第１の課金収集機能サーバへ修正されたアカウンティング要求を送信するステップと、ルータにおいて第１の課金収集機能サーバからアカウンティング応答を受信するステップと、アカウンティング応答が、第１の課金収集機能サーバが修正されたアカウンティング要求を成功裏に処理したことを示すことを判定するステップと、修正されたアカウンティング応答を形成するように、ルータにおいて受信されたアカウンティング応答を修正するステップと、ルータからＮＥへと修正されたアカウンティング要求を送信するステップとを含む。
【００１２】
本発明の適用可能性のさらなる範囲は、以下で提供される詳細な説明から明らかになるであろう。しかしながら、本発明の趣旨および範囲の内部の様々な変更および修正が、当業者にとって明らかになるので、本発明の好ましい実施形態を示しながら、詳細な説明と特定の例とが、単に例証として与えられることを理解すべきである。
【００１３】
本発明は、デバイスの様々な部分と、方法のステップとについての構造、構成、および組合せのうちに存在し、これにより、企図される目的は、以下でより完全に記載されるように、特許請求の範囲において具体的に指摘されるように、また添付図面において示されるように達成される。
【図面の簡単な説明】
【００１４】
【図１】ＡＣＲを複数のＣＣＦに対してルーティングするための負荷分配器としての役割を果たすＤ−ＲＴＲを有する課金システムについての例示の実施形態を示す機能図である。
【図２】一次的なＣＣＦが、過負荷状態を報告するときに、ＡＣＲの二次的ルーティングを提供するＤ−ＲＴＲを有する課金システムについての別の例示の実施形態を示す機能図である。
【図３】一次的なＣＣＦが、過渡的な故障状態を報告するときに、ＡＣＲの二次的ルーティングを提供するＤ−ＲＴＲを有する課金システムについての別の例示の実施形態を示す機能図である。
【図４】サービス・プロバイダ・ネットワークのＮＥによって提供されるサービスの明細を明らかにする課金システムを使用するためのプロセスについての例示の一実施形態のフロー・チャートである。
【図５】図４と組み合わせて、サービス・プロバイダ・ネットワークのＮＥによって提供されるサービスの明細を明らかにする課金システムを使用するためのプロセスについての別の例示の実施形態のフロー・チャートである。
【図６】図４と組み合わせて、サービス・プロバイダ・ネットワークのＮＥによって提供されるサービスの明細を明らかにする課金システムを使用するためのプロセスについてのさらに別の例示の実施形態のフロー・チャートである。
【図７】図４と組み合わせて、サービス・プロバイダ・ネットワークのＮＥによって提供されるサービスの明細を明らかにする課金システムを使用するためのプロセスについてのさらに別の例示の実施形態のフロー・チャートである。
【図８】図４と組み合わせて、サービス・プロバイダ・ネットワークのＮＥによって提供されるサービスの明細を明らかにする課金システムを使用するためのプロセスについてのさらにまた別の例示の実施形態のフロー・チャートである。
【図９】サービス・プロバイダ・ネットワークのＮＥによって提供されるサービスの明細を明らかにする課金システムにおいて使用するためのルータについての例示の一実施形態のブロック図である。
【発明を実施するための形態】
【００１５】
サービス・プロバイダ・ネットワークにおけるＮＥによって提供されるサービスの明細を明らかにする課金システムにおいて、ルータと、そのルータを使用するための方法との様々な実施形態が、本明細書において開示される。例示の実施形態は、どのようにしてルータが、サービス・プロバイダ・ネットワークにおけるＮＥからＡＣＲを受信するための、また課金システムにおいてＡＣＲをＣＣＦに対してルーティングし、またＡＣＡを発信元のＮＥに対して中継して戻すためのプロキシとしての機能を果たすかについて説明している。例示の実施形態は、ＣＣＦからのＡＣＡが、過負荷状態や過渡的な故障状態など、ある種の例示のタイプのエラー状態または故障状態を示すときに、どのようにしてルータが、ＡＣＲのさらなる処理のためのインテリジェンスを提供するかについて説明している。これらの例示の状態では、ルータは、ＡＣＲを同じＣＣＦに対して送信することを再試行すべきか否か、または代替のＣＣＦを選択すべきか否かを決定することができる。処理のためにＡＣＲをサブミットする、ルータによる後続の試みが、成功する場合、問題は、ＮＥを必要とすることなく解決される。
【００１６】
上記で説明されるように、既存のＤ−ＲＴＲの典型的な動作は、過負荷状況について明示的に知らないまま、また代替のピアＣＣＦを選択することができないまま、過負荷にされたＣＣＦサーバにおいて減少する負荷を「期待する」ことであろう。これは、効率的または実用的な問題解決手法ではない。しかしながら、Ｄ−ＲＴＲを使用しないことは、上記でもまた述べられている他の欠点を有する。例えば、Ｄ−ＲＴＲが、使用されておらず、また中心的な要素管理システム（ＥＭＳ：ｅｌｅｍｅｎｔ  ｍａｎａｇｅｍｅｎｔ  ｓｙｓｔｅｍ）が、正しいプロビジョニングがＣＣＦサーバを通して維持されることを保証するために必要とされるときには、過剰なプロビジョニングが、必要とされる。ＣＣＦアーキテクチャとＣＴＦ／ＣＣＦ構成とに対するどのような後続の変更も、プロビジョニングのメンテナンスのために追加の運用費用（ＯＰＥＸ：ｏｐｅｒａｔｉｏｎａｌ  ｅｘｐｅｎｓｅ）をもたらす。
【００１７】
本明細書において説明される様々な実施形態においては、ＣＴＦは、Ｄ−ＲＴＲに接続し、またＡＣＲをＤ−ＲＴＲに対して送信する。Ｄ−ＲＴＲは、内部のテーブルを検査し、またはインテリジェンスを適用して（例えば、セッション識別子に対してハッシュ関数を使用して）、どのＣＣＦサーバが、アカウンティング・セッションを処理すべきかを選択することができる。Ｄ−ＲＴＲはまた、最もよく適合したものを選択する前に、ＣＣＦサーバのおのおのについての使用可能性と現在の負荷インデックスとを考慮することもできる。
【００１８】
本明細書において説明される様々な実施形態により、Ｄ−ＲＴＲは、往復時間（ＲＴＴ：ｒｏｕｎｄ  ｔｒｉｐ  ｔｉｍｅ）を不必要に遅延させないように、またアカウンティング・サービスを要求するクライアント（すなわち、ＮＥ／ＣＴＦ）からＣＣＦトポロジを依然として隠されたままに保持しながら、必要に応じて、インテリジェントな内部のリバウンドを開始することから構成される補正的ローカル・アクションを取らないようにするために、最適化されたやり方でＣＣＦサーバからの応答を検査することができるようになる。
【００１９】
各ＣＣＦサーバにおける負荷決定、新しいアカウンティング・セッションについてのＣＣＦサーバの後続の選択、および／またはＣＣＦ代替的ピア・サーバの後続の選択のための問題解決手法の一部分は、その内容が参照により本明細書に完全に組み込まれている、２０１０年１１月１５日に出願された、アルカテル・ルーセントＵＳＡ社（Ａｌｃａｔｅｌ−Ｌｕｃｅｎｔ  ＵＳＡ，  Ｉｎｃ．）に譲渡されたＳｈａｒｍａに対する米国特許出願シリアル番号第１２／９４６，３９４号において開示される過負荷中に代替のオフライン課金システムを選択するための以前の方法に基づいたものとすることができる。第’３９４号の出願は、ＣＣＦ負荷インデックスに基づいて使用可能なこれらのサーバのうちから適切なＣＣＦの代替的ピア・サーバを選択する観点から関連がある。
【００２０】
本明細書において開示される実施形態においては、ＣＴＦが、過負荷にされたＣＣＦサーバにより、または過渡的なエラーを経験しているＣＣＦサーバにより拒否されるＡＣＲを送信するときに、Ｄ−ＲＴＲは、代替のピア選択方法とインテリジェンスとを使用して、メッセージを処理するために適切なＣＣＦサーバに対して内部でメッセージを跳ね返す。
【００２１】
実装形態を説明するために、機能的なウォーク・スルーが、以下で提供される。この説明は、ステップごとのやり方で、機能の外部動作を説明している図２および３に対しても適用可能である。
【００２２】
図２を参照すると、課金システムの例示の一実施形態は、一次的なＣＣＦが、過負荷状態を報告するときに、ＡＣＲの二次的ルーティングを提供するＤ−ＲＴＲを含んでいる。第１のステップ（すなわち、１：ＡＣＲ）においては、ＣＴＦは、ＡＣＲを送信することによりセッションを明らかにする報告を開始する。ＲＦＣ  ３５８８についてのこのＡＣＲは、以下で与えられる構造と互換性がある。
＜ＡＣＲ＞：：＝＜ダイアメーター・ヘッダ：２７１，ＲＥＱ，ＰＸＹ＞
＜セッション−Ｉｄ＞
｛起点−ホスト｝
｛起点−領域（Ｒｅａｌｍ）｝
｛宛先−領域｝
｛アカウンティング−レコード−タイプ｝
｛アカウンティング−レコード−番号｝
［Ａｃｃｔ−アプリケーション−Ｉｄ］
［ベンダー−特有−アプリケーション−Ｉｄ］
［ユーザ−ネーム］
［アカウンティング−サブ−セッション−Ｉｄ］
［Ａｃｃｔ−セッション−Ｉｄ］
［Ａｃｃｔ−マルチ−セッション−Ｉｄ］
［Ａｃｃｔ−中間−間隔］
［アカウンティング−リアルタイム−必要（Ｒｅｑｕｉｒｅｄ）］
［起点−状態−Ｉｄ］
［イベント−タイムスタンプ］
＊［プロキシ−Ｉｎｆｏ］
＊［ルート−レコード］
＊［ＡＶＰ］
【００２３】
この要求の宛先−領域の属性−可変対（ＡＶＰ：ａｔｔｒｉｂｕｔｅ−ｖａｒｉａｂｌｅ  ｐａｉｒ）は、Ｄ−ＲＴＲについてのルーティング・アドレスを搬送する。ＣＴＦは、Ｄ−ＲＴＲの背後のＣＣＦトポロジを知らない。
【００２４】
ＡＣＲを受信した後に、Ｄ−ＲＴＲは、要求を検査し、またアカウンティング−レコード−タイプＡＶＰをチェックする。アカウンティング−レコード−タイプＡＶＰは、以下の意味、すなわち、１−イベント−レコードと、２−開始−レコードと、３−中間−レコードと、４−停止−レコードとの意味を有する１から４の列挙された値である。
【００２５】
１の値は、ＡＣＲが、セッションに関連していないアカウンティング・メッセージであることを示している。これらの状況の下では、Ｄ−ＲＴＲが、それを特定のＣＣＦサーバに対して送信するための必要条件が存在しないことを仮定することができる。言い換えれば、Ｄ−ＲＴＲは、各イベント−レコードについてどのような適切なＣＣＦサーバを選択することもできる。
【００２６】
２の値は、新しいセッションの報告を示している。これは、適しているＣＣＦサーバが、この新しいセッションを処理するために選択される必要があることを意味する。Ｄ−ＲＴＲは、ＣＣＦサーバを選択することができる。新しい要求を処理するための適切なＣＣＦサーバを選択する１つのやり方は、その内容が参照により本明細書に完全に組み込まれている、２０１０年１１月１５日に出願された、アルカテル・ルーセントＵＳＡ社に譲渡されたＳｈａｒｍａに対する米国特許出願シリアル番号第１２／９４６，３９４号の中で説明されている。第’３９４号の出願はまた、万一ＣＣＦサーバが過負荷を進展させる場合に、代替的ピアＣＣＦサーバの決定のためのロジックを提供している。本明細書において開示される実施形態のためのロジックは、セッションを処理するためのＣＣＦサーバの初期の選択が、単に、使用可能なＣＣＦサーバのおのおのについての負荷インデックスと負荷搬送容量とに基づいたものとすることができる点を除いて、第’３９４号の出願に基づいたものとすることができる。初期選択ステージにおいて関与するどのような過負荷のリダイレクトも存在していないこともある。代わりに、ラウンド・ロビン・スキーム、または重み付けされたラウンド・ロビン・スキームを使用して、新しいセッションのためにＡＣＲをサービスすべきＣＣＦサーバを決定することができる。例えば、あるアルゴリズムをセッション−ＩＤ  ＡＶＰに対して適用して、万一一次的なＣＣＦサーバが、偶然にもサービス停止（ＯＯＳ：ｏｕｔ−ｏｆ−ｓｅｒｖｉｃｅ）になる場合に、二次的なＣＣＦサーバを心に留めたまま、セッションを処理する一次的なＣＣＦサーバを決定することができる。
【００２７】
アカウンティング−レコード−タイプＡＶＰの中の３または４の値は、ＣＣＦサーバによって既にサービスされている進行中のセッションを示している。この場合には、Ｄ−ＲＴＲは、どのＣＣＦサーバが、セッションを処理しているかを判定する。これは、以下のやり方、すなわち１）セッション−ＩＤ  ＡＶＰに対して同じ機能を適用して、万一第１のＣＣＦサーバが偶然にもＯＯＳになる場合に、二次的なＣＣＦサーバを心に留めながら、開始−レコードのためと同じ方法でセッションを処理するダイアメーターＣＣＦサーバを決定することによるやり方、または２）Ｄ−ＲＴＲにおいてセッション−ホストのルックアップ・テーブル実装形態によるやり方のうちの一方で行われる。ルックアップ・テーブルは、ネットワークにおいて、その瞬間に進行中のすべての固有のセッション−識別子（ＩＤ）を含むことができる。一次的なＣＣＦサーバ・インスタンスと、二次的なＣＣＦサーバ・インスタンスとは、各セッション−ＩＤに関連づけられる。ルックアップ・テーブルはまた、ＣＣＦの負荷状態と使用可能性とについての他の表示を含むこともできる。ルックアップ・テーブルは、この通信セッションについての対応するＣＴＦのために割り当てられ、また代替のピアＣＣＦサーバが、対応するＣＴＦのための通信セッションに対して割り当てられるたびごとに、アップデートされる初期ＣＣＦサーバを識別することができる。
【００２８】
第１のステップ（すなわち、１：ＡＣＲ）の終わりには、Ｄ−ＲＴＲは、ＣＣＦサーバを識別しているべきである。図２を参照すると、これは、この例示のシナリオにおいてはＣＣＦ−１である。Ｄ−ＲＴＲは、要求において以下の修正を行った後にＡＣＲをＣＣＦ−１に対して転送する。
＜ＡＣＲ＞：：＝＜ダイアメーター・ヘッダ：２７１，ＲＥＱ，ＰＸＹ＞
＜セッション−Ｉｄ＞
｛起点−ホスト｝
｛起点−領域｝
｛宛先−領域｝
｛アカウンティング−レコード−タイプ｝
｛アカウンティング−レコード−番号｝
［Ａｃｃｔ−アプリケーション−Ｉｄ］
［ベンダー−特有−アプリケーション−Ｉｄ］
［ユーザ−ネーム］
［アカウンティング−サブ−セッション−Ｉｄ］
［Ａｃｃｔ−セッション−Ｉｄ］
［Ａｃｃｔ−マルチ−セッション−Ｉｄ］
［Ａｃｃｔ−中間−間隔］
［アカウンティング−リアルタイム−必要］
［起点−状態−Ｉｄ］
［イベント−タイムスタンプ］
＊［プロキシ−Ｉｎｆｏ］
＊［ルート−レコード］
＊［ＡＶＰ］
【００２９】
この転送されたＡＣＲの中の起点−ホスト情報と、起点−領域ＡＶＰ情報とは、Ｄ−ＲＴＲを識別するが、宛先−領域ＡＶＰ情報は、ＣＣＦ−１の領域を含んでいる。さらに、Ｄ−ＲＴＲは、この転送された要求に対してルート−レコードＡＶＰを追加する。ルート−レコードＡＶＰは、要求が受信されたＣＴＦのアイデンティティを含んでおり、本質的には、ＡＣＲの「真の」または「実際の」発信元を識別している。
【００３０】
第２のステップ（すなわち、２：ＯＶＬ）においては、ＣＣＦ−１が、過負荷を経験しており、また送信されたＡＣＲを信頼できるように処理することができないことを仮定すると、ＣＣＦ−１は、ＡＣＡにおいてエラー状態を宣言する必要がある。Ｄ−ＲＴＲが、以前に、ルーティングされたＡＣＲの起点−ホストＡＶＰの中にそのアイデンティティを挿入したので、このＡＣＡ応答は、Ｄ−ＲＴＲに対して返信される。ＣＣＦ−１からＤ−ＲＴＲへのＡＣＡ応答は、以下の形式のものになるであろう。
＜ＡＣＲ＞：：＝＜ダイアメーター・ヘッダ：２７１，ＰＸＹ＞
＜セッション−Ｉｄ＞
｛結果−コード｝
｛起点−ホスト｝
｛起点−領域｝
｛アカウンティング−レコード−タイプ｝
｛アカウンティング−レコード−番号｝
［Ａｃｃｔ−アプリケーション−Ｉｄ］
［ベンダー−特有−アプリケーション−Ｉｄ］
［ユーザ−ネーム］
［アカウンティング−サブ−セッション−Ｉｄ］
［Ａｃｃｔ−セッション−Ｉｄ］
［Ａｃｃｔ−マルチ−セッション−Ｉｄ］
［エラー−報告−ホスト］
［Ａｃｃｔ−中間−間隔］
［アカウンティング−リアルタイム−必要］
［起点−状態−Ｉｄ］
［イベント−タイムスタンプ］
＊［プロキシ−Ｉｎｆｏ］
＊［ＡＶＰ］
【００３１】
Ｄ−ＲＴＲによって検査されるＡＣＡ応答の中のＡＶＰのうちの１つは、結果−コードＡＶＰである。結果−コードＡＶＰ（コード２６８）は、例えば、値１００１と、２００１〜２００２と、３００１〜３０１０と、４００１〜４００２と、５００１〜５０１７と規定することができる。結果−コードＡＶＰの中の１ｘｘｘの値は、情報を含んでいる。２ｘｘｘの値は、成功を示している。それゆえに、Ｄ−ＲＴＲは、結果−コードＡＶＰの中の１ｘｘｘの値または２ｘｘｘの値を有するＡＣＡ応答が、発信元のＣＴＦに返信されることを可能にする。Ｄ−ＲＴＲは、ルート−レコードＡＶＰ情報を使用して、ＡＣＡ応答の中に起点−ホストＡＶＰを追加し、また対応するＡＣＲを開始したＣＴＦエンティティに対してＡＣＡ応答をルーティングする。
【００３２】
Ｄ−ＲＴＲは、本明細書において説明される様々な技法を使用して、セッションを処理するために現在割り当てられているＣＣＦサーバにおいてある種のエラー状態または故障状態を克服して、結果−コードＡＶＰについての残りの値のうちの少なくともいくつかを処理することができる。結果−コードＡＶＰの中の３ｘｘｘの値は、ある種のタイプのプロトコル・エラーを識別する。４ｘｘｘの値は、ある種の過渡的故障を識別する。結果−コードＡＶＰの中の５ｘｘｘの値は、ある種のタイプの恒久的故障を識別する。
【００３３】
例えば、ＣＣＦサーバにおいて過負荷状態を示す一般的に使用される技法は、結果−コードＡＶＰの中の３００４の値を有するＡＣＡを送信することである。３００４の値は、ダイアメーター＿トゥー＿ビジー（Ｄｉａｍｅｔｅｒ＿Ｔｏｏ＿Ｂｕｓｙ）エラーを表す。ダイアメーター＿トゥー＿ビジー・エラーは、Ｄ−ＲＴＲにとって特に興味のあるものである。結果−コードＡＶＰにおいてダイアメーター＿トゥー＿ビジー・エラーを報告する、ＣＣＦ−１からのＡＣＡを受信した後に、Ｄ−ＲＴＲは、所定の位置にある負荷インデックスと他のポリシー・ルールと一緒に、使用可能なＣＣＦサーバのうちから代替のピアＣＣＦサーバを決定する。図２を参照すると、この代替のピアＣＣＦサーバは、この例示のシナリオの場合に、偶然にもＣＣＦ−３であることもある。それゆえに、Ｄ−ＲＴＲは、以前に転送されたＡＣＲメッセージの中で宛先−領域を変更して、代替のピアＣＣＦサーバを反映させ、また新しい起点−ホストＡＶＰ情報と、ルート−レコードＡＶＰ情報とを用いて以前に修正された、改訂されたＡＣＲメッセージをＣＣＦ−３に対して送信する。これは、図２における第３のステップ（すなわち、３：ＡＣＲ）として示されている。第４のステップ（すなわち、４：ＡＣＡ）は、Ｄ−ＲＴＲに対して戻ってくるＡＣＡメッセージを示しており、このＡＣＡメッセージは、Ｄ−ＲＴＲによって修正されて、正しい起点−ホストＡＶＰ情報を反映させ、また元のＡＣＲについて発信元のＣＴＦに対してルーティングされる。
【００３４】
図３を参照すると、一次的なＣＣＦが、過渡的な故障状態を報告するときに、課金システムの別の例示の実施形態は、ＡＣＲの二次的ルーティングを提供するＤ−ＲＴＲを含んでいる。４ｘｘｘの結果−コード値に関しては、ＣＣＦサーバにおいてＡＣＲのストレージについての使用可能な空間の一次的な不足を示す一般的に使用される技法は、結果−コードＡＶＰにおいて４００２の値を有するＡＣＡを送信することである。４００２の値は、ダイアメーター＿アウト＿オブ＿スペース・エラーを表す。例示のシナリオでは、ＣＣＦ−１が、Ｄ−ＲＴＲからＡＣＲを受信することに応じてＡＣＡにおいてダイアメーター＿アウト＿オブ＿スペース・エラーを報告することを仮定する。問題になっているＣＣＦが、ストレージ空間状態の一次的な不足に起因して、受信されたＡＣＲが、ストレージを安定させることをコミットすることができなかったときに、これは、起こる。そのようにして、第１のステップ（すなわち、１：ＡＣＲ）において送信されるＡＣＲでは、図３を参照すると、ＣＣＦ−１は、第２のステップ（すなわち、２：ＴＲＥ）において、使用可能なストレージ空間の一次的な不足に起因した過渡的なエラーを示すように、結果−コードＡＶＰにおいて４００２の値を含むＡＣＡを用いて応答する。この例示のシナリオでは、Ｄ−ＲＴＲは、構成可能な長さの時間にわたって、一般的には数秒にわたって、待ち、また第３のステップ（すなわち、３：ＡＣＲ）で示されるように、修正されたＡＣＲを同じＣＣＦ−１に対して送信することを再試行する。ＡＣＲが、さらなるエラーなしにＣＣＦ−１によって受け入れられる場合、Ｄ−ＲＴＲは、結果−コードＡＶＰにおいて２ｘｘｘの値を有する肯定的なＡＣＡを受信する。これは、図３の第４のステップ（すなわち、４：ＡＣＡ）において示される。Ｄ−ＲＴＲは、元のＡＣＲを発行したダイアメーター・クライアント（すなわち、発信元のＣＴＦ）に対して肯定的なＡＣＡをルーティングして戻す。しかしながら、ダイアメーター＿アウト＿オブ＿スペース・エラーが、持続する場合、例えば、ＣＣＦサーバにおいて二次的なメモリ故障によって引き起こされる厳しい不足が存在するときに、ＣＣＦ−１は、エラー状態を反復することになる可能性が高い。この場合には、Ｄ−ＲＴＲの動作は、所定の回数にわたって再試行の試みを反復する可能性があり、また次いで、図２に示されるように、このＡＣＲを処理するために代替のピアＣＣＦサーバを選択することへと進む。代わりに、Ｄ−ＲＴＲは、第１の再試行の試みの失敗の後に、代替のピアＣＣＦサーバを選択することへと直接に進む可能性がある（図２参照）。
【００３５】
５ｘｘｘの結果−コード値に関しては、Ｄ−ＲＴＲはこれらのコードが、対応するＣＣＦサーバにおける恒久的な故障を表すので、結果−コードＡＶＰにおいて５ｘｘｘの値を有するＡＣＡを発信元のＣＴＦピアに対してルーティングして戻す。
【００３６】
要約すれば、本明細書において説明される様々な実施形態は、Ｄ−ＲＴＲが、発信元のＣＴＦからの、Ｄ−ＲＴＲによって受信されるＡＣＲをルーティングしている相手の現在割り当てられているＣＣＦサーバからＤ−ＲＴＲによって受信されるＡＣＡのインテリジェントな処理を提供する。本明細書において説明される様々な技法は、発信元のＣＴＦと、Ｄ−ＲＴＲと、現在割り当てられているＣＣＦサーバとの間の「無限のループ」状況を回避する。本明細書において説明される様々な実施形態は、発信元のＣＴＦと、宛先ＣＣＦサーバとの間の全体的なネットワーク・トポロジを隠すようにＤ−ＲＴＲを組み込むＣＣＦネットワーク・アーキテクチャを提供している。本明細書において説明される様々な実施形態はまた、Ｄ−ＲＴＲを使用することにより、発信元のＣＴＦと、宛先のＣＣＦサーバとにおけるプロビジョニングの低減を提供する。既存の問題解決手法は、元のＡＣＲメッセージを同じＣＣＦサーバに対して送信することをＣＴＦに反復させることにより、ＡＣＲの処理を遅延させ、またネットワーク・トラフィックを増大させる傾向がある。
【００３７】
示すことが例示の実施形態だけを示す目的のためにであり、また特許請求される範囲の主題を限定する目的のためではない図面をもう一度参照すると、図４は、４０２において開始される、サービス・プロバイダ・ネットワークのＮＥによって提供されるサービスの明細を明らかにする課金システムを使用するためのプロセス４００についての例示の一実施形態を示しており、ここでは、サービス・プロバイダ・ネットワークのＮＥからのＡＣＲは、課金システムの中のルータにおいて受信される。ＡＣＲは、通信セッションと一緒に、サービス・プロバイダ・ネットワークにおけるＮＥによって提供されるサービスに関連づけられている。課金システムは、１つまたは複数の通信セッションと一緒に、サービス・プロバイダ・ネットワークの１つまたは複数のＮＥからのＡＣＲを処理するためのルータに関連する複数のＣＣＦサーバを含むことができる。
【００３８】
次に、受信されたＡＣＲは、修正されたＡＣＲを形成するように、ルータにおいて修正される（４０４）。４０６において、修正されたＡＣＲは、ルータから、複数の課金制御機能サーバから選択される第１のＣＣＦサーバへと送信される。次に、第１のＣＣＦサーバが、修正されたＡＣＲを処理することができなかったことを示す、第１のＣＣＦサーバからのＡＣＡが、ルータにおいて受信される（４０８）。４１０において、修正されたＡＣＲが、ルータから第１のＣＣＦサーバへと再送信されるか、あるいは修正されたＡＣＲが、改訂されたＡＣＲを形成するように、ルータにおいて変更され、その改訂されたＡＣＲが、ルータから、複数の課金制御機能サーバから選択される代替のＣＣＦサーバへと送信されるかのいずれかである。
【００３９】
図４および５を参照すると、サービス・プロバイダ・ネットワークのＮＥによって提供されるサービスの明細を明らかにする課金システムを使用するためのプロセス５００の別の例示の実施形態は、図４のプロセス４００を含んでおり、また４０２から５０２へと継続され、ここで第１のＣＣＦサーバは、受信されたＡＣＲにおける情報に少なくとも部分的に基づいて、ルータにおける修正されたＡＣＲについての宛先として選択される。次に、プロセス５００は、図４の４０４へと進む。
【００４０】
別の実施形態においては、プロセス５００は、受信されたＡＣＲにおけるレコード・タイプ情報に少なくとも部分的に基づいて、受信されたＡＣＲが、ＮＥについての新しい通信セッションについての開始レコードであることを判定することを含んでいる。この実施形態においては、第１のＣＣＦサーバは、複数のＣＣＦサーバのうちの処理負荷の分布に関連した負荷分布関数を含むアルゴリズムに少なくとも部分的に基づいて選択される。
【００４１】
さらなる一実施形態においては、プロセス５００は、複数のＣＣＦサーバについての負荷インデックスに関連した第１のＣＣＦサーバについての１つまたは複数の負荷インデックスと、複数のＣＣＦサーバについての負荷搬送容量に関連した第１のＣＣＦサーバについての負荷搬送容量と、複数のＣＣＦサーバに関連したラウンド・ロビン・スキームと、複数のＣＣＦサーバに関連した重み付けされたラウンド・ロビン・スキームとに少なくとも部分的に基づいて、第１のＣＣＦサーバを選択することを含んでいる。説明されている実施形態のうちのさらなる一実施形態においては、負荷インデックスは、複数のＣＣＦサーバによりルータと共用される負荷情報に少なくとも部分的に基づいている。説明されている実施形態のうちの別のさらなる実施形態においては、ラウンド・ロビン・スキームと、重み付けされたラウンド・ロビン・スキームとのうちの少なくとも一方は、受信されたＡＣＲにおけるセッション識別子情報に対してアルゴリズムを適用することに少なくとも部分的に基づいている。
【００４２】
別のさらなる実施形態においては、プロセス５００は、ルータにアクセス可能なストレージ・デバイスにおいて、リンクされた関係にある新しい通信セッションのために、セッション識別子と、発信元のソース識別子と、選択された宛先識別子とを記憶することを含んでいる。説明されている実施形態のうちのさらなる一実施形態においては、セッション識別子は、新しい通信セッションを識別するように適合され、発信元のソース識別子は、新しい通信セッションと一緒に、受信されたＡＣＲについての発信元のソースとしてＮＥを識別するように適合され、また選択された宛先識別子は、ＮＥによって開始される新しい通信セッションについてＡＣＲを処理するために現在選択されているように第１のＣＣＦサーバを識別するように適合される。
【００４３】
さらに別の実施形態においては、プロセス５００は、受信されたＡＣＲにおけるレコード・タイプ情報に少なくとも部分的に基づいて、受信されたＡＣＲが、ＮＥについての進行中の通信セッションについての中間コードまたは停止コードであることを判定することを含んでいる。この実施形態においては、第１のＣＣＦサーバは、ＮＥを表す発信元のソース識別子と、第１のＣＣＦを表す選択された宛先識別子とにリンクされるセッション識別子に進行中の通信セッションをマッチングさせることに少なくとも部分的に基づいて選択される。セッション識別子と、発信元のソース識別子と、選択された宛先識別子とは、進行中の通信セッションについてＮＥから受信される以前のＡＣＲをルーティングすることと一緒に、ルータにアクセス可能なストレージ・デバイスにおいて、リンクされた関係で以前に記憶されている。さらなる一実施形態においては、セッション識別子は、進行中の通信セッションを識別するように適合され、発信元のソース識別子は、進行中の通信セッションと一緒に、受信されたＡＣＲについての発信元のソースとしてＮＥを識別するように適合され、また選択された宛先識別子は、ＮＥによって開始される進行中の通信セッションについてＡＣＲを処理するために現在選択されているように第１のＣＣＦサーバを識別するように適合される。
【００４４】
図４および６を参照すると、サービス・プロバイダ・ネットワークのＮＥによって提供されるサービスの明細を明らかにする課金システムを使用するためのプロセス６００の別の例示の実施形態は、図４のプロセス４００を含んでおり、また４０４から６０２へと継続され、ここでは、受信されたＡＣＲの発信元のソースとしてＮＥを表す起点情報は、修正されたＡＣＲの中間のソースとしてルータを表すように受信されたＡＣＲを修正することと一緒に変更される。次に、受信されたＡＣＲの中間の宛先としてルータを表す宛先情報は、修正されたＡＣＲの選択された宛先として第１のＣＣＦサーバを表すように受信されたＡＣＲを修正することと一緒に変更される（６０４）。６０６において、修正されたＡＣＲにおける受信されたＡＣＲの発信元のソースとしてＮＥを表すように、受信されたＡＣＲを修正することと一緒に、ルート・レコード情報が、受信されたＡＣＲに追加される。次に、プロセス６００は、図４の４０６へと進む。
【００４５】
プロセス６００の別の実施形態においては、受信され、また修正されたＡＣＲにおける起点情報は、起点ホスト情報と、起点領域情報とを含む。プロセス６００のさらに別の実施形態においては、受信され、また修正されたＡＣＲにおける宛先情報は、宛先領域情報を含んでいる。
【００４６】
図４および７を参照すると、サービス・プロバイダ・ネットワークのＮＥによって提供されるサービスの明細を明らかにする課金システムを使用するためのプロセス７００についての別の例示の実施形態は、図４のプロセス４００を含んでおり、また４０８から７０２へと継続され、ここでは、プロセスは、ＡＣＡが、第１のＣＣＦサーバが過負荷状態に起因して、修正されたＡＣＲを処理することができないことを示すと判定する。次に、プロセス７００は、図４の４１０へと進む。この実施形態では、４１０において、修正されたＡＣＲが、改訂されたＡＣＲを形成するように変更され、改訂されたＡＣＲは、修正されたＡＣＲを再送信する代わりに代替のＣＣＦサーバに対して送信される。
【００４７】
プロセス７００の別の実施形態においては、ＡＣＡは、第１のＣＣＦサーバが、修正されたＡＣＲを処理するにはあまりにもビジーすぎることを示す。プロセス７００のさらに別の実施形態においては、ＡＣＡは、３００４というコード値を有する結果コード情報を含んでいる。
【００４８】
さらに別の実施形態においては、プロセス７００はまた、複数のＣＣＦサーバのうちの処理する負荷の分布に関連した負荷分布関数を含むアルゴリズムに少なくとも部分的に基づいて、ルータにおける修正されたＡＣＲについて代替の宛先として代替のＣＣＦサーバを選択することを含んでいる。
【００４９】
さらなる一実施形態においては、プロセス７００はまた、複数のＣＣＦサーバについての負荷インデックスに関連した代替のＣＣＦサーバについての１つまたは複数の負荷インデックスと、複数のＣＣＦサーバについての負荷搬送容量に関連した代替のＣＣＦサーバについての負荷搬送容量と、複数のＣＣＦサーバに関連したラウンド・ロビン・スキームと、複数のＣＣＦサーバに関連した重み付けされたラウンド・ロビン・スキームとに少なくとも部分的に基づいて、代替のＣＣＦサーバを選択することを含んでいる。説明されている実施形態のうちのさらなる一実施形態においては、負荷インデックスは、複数のＣＣＦサーバによってルータと共用される負荷情報に少なくとも部分的に基づいている。説明されている実施形態のうちの別のさらなる実施形態においては、ラウンド・ロビン・スキームと、重み付けされたラウンド・ロビン・スキームとのうちの少なくとも一方は、修正されたＡＣＲにおけるセッション識別子情報に対してアルゴリズムを適用することに少なくとも部分的に基づいている。
【００５０】
別のさらなる実施形態においては、プロセス７００はまた、ルータにアクセス可能なストレージ・デバイスにおいて、リンクされた関係において通信セッションについてのセッション識別子と、発信元のソース識別子と、選択された宛先識別子とを記憶することを含んでいる。説明されている実施形態のうちのさらなる一実施形態においては、セッション識別子は、通信セッションを識別するように適合され、発信元のソース識別子は、通信セッションと一緒に、受信されたＡＣＲについての発信元のソースとしてＮＥを識別するように適合され、また選択された宛先識別子は、ＮＥによって開始される通信セッションについてＡＣＲを処理するために現在選択されているように代替のＣＣＦサーバを識別するように適合される。
【００５１】
さらに別の実施形態においては、プロセス７００はまた、代替のＣＣＦサーバが、成功裏に改訂されたＡＣＲを処理したことを示すＡＣＡをルータにおいて代替のＣＣＦサーバから受信することを含んでいる。この実施形態においては、受信されたＡＣＡは、修正されたＡＣＡを形成するように、ルータにおいて修正される。説明されている実施形態においては、修正されたＡＣＡは、ルータからＮＥへと送信される。
【００５２】
図４および８を参照して、サービス・プロバイダ・ネットワークのＮＥによって提供されるサービスの明細を明らかにする課金システムを使用するためのプロセス８００の別の例示の実施形態は、図４のプロセス４００を含んでおり、また４０８から８０２へと継続され、ここでは、プロセスは、ＡＣＡが、第１のＣＣＦサーバが過渡的な故障状態に起因して、修正されたＡＣＲを処理することができないことを示すと判定する。次に、プロセス８００は、図４の４１０へと進む。この実施形態では、４１０において、修正されたＡＣＲは、改訂されたＡＣＲを送信する代わりに第１のＣＣＦサーバに対して再送信される。
【００５３】
プロセス８００の別の実施形態においては、ＡＣＡは、第１のＣＣＦサーバが、修正されたＡＣＲを処理するには、少なくとも一時的に容量不足であることを示す。プロセス８００のさらに別の実施形態においては、ＡＣＡは、４００２というコード値を有する結果コード情報を含んでいる。さらに別の実施形態においては、プロセス８００はまた、ＡＣＡを受信した後に、修正されたＡＣＲを再送信する前に、構成可能な時間を待つことを含んでいる。
【００５４】
さらにまた別の実施形態においては、プロセス８００はまた、第１のＣＣＦサーバが、成功裏に修正されたＡＣＲを処理したことを示すＡＣＡをルータにおいて第１のＣＣＦサーバから受信することを含んでいる。この実施形態においては、受信されたＡＣＡは、修正されたＡＣＡを形成するように、ルータにおいて修正される。説明されている実施形態においては、修正されたＡＣＡは、ルータからＮＥへと送信される。
【００５５】
図９を参照すると、サービス・プロバイダ・ネットワーク９０６のＮＥ９０４によって提供されるサービスの明細を明らかにする課金システム９０２において使用するためのルータ９００の例示の一実施形態が、示されている。ルータ９００は、サービス・ネットワーク通信モジュール９０８と、メッセージ処理モジュール９１０と、課金システム通信モジュール９１２とを含む。サービス・ネットワーク通信モジュール９０８は、サービス・プロバイダ・ネットワーク９０６のＮＥ９０４からＡＣＲを受信するためのものである。ＡＣＲは、通信セッションに関連してサービス・プロバイダ・ネットワーク９０６におけるＮＥ９０４によって提供されるサービスに関連づけられる。課金システム９０２は、１つまたは複数の通信セッションに関連してサービス・プロバイダ・ネットワーク９０６の１つまたは複数のＮＥ（例えば、９０４）からのＡＣＲを処理するための複数のＣＣＦサーバ９１４を含んでいる。メッセージ処理モジュール９１０は、修正されたＡＣＲを形成するように、受信されたＡＣＲを修正するためのサービス・ネットワーク通信モジュール９０８と動作可能に通信している。課金システム通信モジュール９１２は、複数の課金制御機能サーバ９１４から選択される第１のＣＣＦサーバ９１６に対して修正されたＡＣＲを送信するためのメッセージ処理モジュール９１０と動作可能に通信している。課金システム通信モジュール９１２はまた、第１のＣＣＦサーバ９１６が、修正されたＡＣＲを処理することができなかったことを示すＡＣＡを第１のＣＣＦサーバ９１６から受信するためのものである。メッセージ処理モジュール９１０はまた、課金システム通信モジュール９１２を経由して修正されたＡＣＲを第１のＣＣＦサーバ９１６に対して再送信すべきか、または改訂されたＡＣＲを形成するように、修正されたＡＣＲを変更し、また課金システム通信モジュール９１２を経由して改訂されたＡＣＲを代替のＣＣＦサーバ９１８に対して送信すべきかを決定するためのものである。代替のＣＣＦサーバ９１８は、複数の課金制御機能サーバ９１４から選択される。
【００５６】
ルータ９００の別の実施形態においては、メッセージ処理モジュールはまた、受信されたＡＣＲにおける情報に少なくとも部分的に基づいて、修正されたＡＣＲについての宛先として第１のＣＣＦサーバ９１６を選択するためのものである。
【００５７】
ルータ９００のさらなる一実施形態においては、メッセージ処理モジュール９１０はまた、受信されたＡＣＲにおけるレコード・タイプ情報に少なくとも部分的に基づいて、受信されたＡＣＲが、ＮＥ９０４についての新しい通信セッションについての開始レコードであることを判定し、また複数のＣＣＦサーバ９１４のうちの処理する負荷の分布に関連している負荷分布関数を含むアルゴリズムに少なくとも部分的に基づいて、第１のＣＣＦサーバ９１６を選択するためのものである。
【００５８】
ルータ９００のまたさらなる一実施形態においては、メッセージ処理モジュール９１０はまた、複数のＣＣＦサーバ９１４についての負荷インデックスに関連した第１のＣＣＦサーバ９１６についての１つまたは複数の負荷インデックスと、複数のＣＣＦサーバ９１４についての負荷搬送容量に関連した第１のＣＣＦサーバ９１６についての負荷搬送容量と、複数のＣＣＦサーバ９１４に関連したラウンド・ロビン・スキームと、複数のＣＣＦサーバ９１４に関連した重み付けされたラウンド・ロビン・スキームとに少なくとも部分的に基づいて、第１のＣＣＦサーバ９１６を選択するためのものである。ルータ９００のさらにさらなる一実施形態においては、負荷インデックスは、課金システム通信モジュール９１２を経由して複数のＣＣＦサーバ９１４から受信される負荷情報に少なくとも部分的に基づいている。ルータ９００の別のさらにさらなる実施形態においては、ラウンド・ロビン・スキームと、重み付けされたラウンド・ロビン・スキームとのうちの少なくとも一方は、受信されたＡＣＲにおけるセッション識別子情報に対してアルゴリズムを適用することに少なくとも部分的に基づいている。
【００５９】
別のまたさらなる実施形態においては、ルータ９００はまた、リンクされた関係にある新しい通信セッションについてのセッション識別子と、発信元のソース識別子と、選択された宛先識別子とを記憶するための、メッセージ処理モジュール９１０と動作可能に通信しているストレージ・デバイス９２０を含んでいる。ルータ９００のまたさらなる一実施形態においては、セッション識別子は、新しい通信セッションを識別するように適合され、発信元のソース識別子は、新しい通信セッションに関連して受信されたＡＣＲについての発信元のソースとしてＮＥ９０４を識別するように適合され、また選択された宛先識別子は、ＮＥ９０４によって開始される新しい通信セッションについてのＡＣＲを処理するために現在選択されているように第１のＣＣＦサーバ９１６を識別するように適合される。他の実施形態においては、ストレージ・デバイス９２０は、ルータ９００の外部にある可能性がある。外部ストレージ・デバイス９２０は、課金システム９０２の任意の適切なＮＥの中に位置する可能性がある。
【００６０】
ルータ９００の別のさらなる実施形態においては、メッセージ処理モジュール９１０はまた、受信されたＡＣＲにおけるレコード・タイプ情報に少なくとも部分的に基づいて、受信されたＡＣＲが、ＮＥ９０４についての進行中の通信セッションについての中間レコードまたは停止レコードであることを判定し、またＮＥ９０４を表す発信元のソース識別子と、第１のＣＣＦ９１６を表す選択された宛先識別子とにリンクされるセッション識別子に進行中の通信セッションをマッチングさせることに少なくとも部分的に基づいて、第１のＣＣＦサーバ９１６を選択するためのものである。この実施形態においては、ルータ９００はまた、進行中の通信セッションについてＮＥ９０４から受信される以前のＡＣＲについてのルーティングに関連して、リンクされた関係にあるセッション識別子と、発信元のソース識別子と、選択された宛先識別子とを記憶するための、メッセージ処理モジュール９１０と動作可能に通信しているストレージ・デバイス９２０を含んでいる。他の実施形態においては、ストレージ・デバイス９２０は、ルータ９００の外部にある可能性がある。外部ストレージ・デバイス９２０は、課金システム９０２の任意の適切なＮＥの中に位置している可能性がある。
【００６１】
ルータ９００のまたさらなる一実施形態においては、セッション識別子は、進行中の通信セッションを識別するように適合され、発信元のソース識別子は、進行中の通信セッションに関連して、受信されたＡＣＲについての発信元のソースとしてＮＥ９０４を識別するように適合され、また選択された宛先識別子は、ＮＥ９０４によって開始される進行中の通信セッションについてのＡＣＲを処理するために現在選択されているように第１のＣＣＦサーバ９１６を識別するように適合される。
【００６２】
ルータ９００のさらに別の実施形態においては、メッセージ処理モジュール９１０は、修正されたＡＣＲの中間のソースとしてルータ９００を表現するために、受信されたＡＣＲを修正することに関連して、受信されたＡＣＲの発信元のソースとしてＮＥ９０４を表現する起点情報を変更し、修正されたＡＣＲの選択された宛先として第１のＣＣＦサーバ９１６を表現するために、受信されたＡＣＲを修正することに関連して、受信されたＡＣＲの中間の宛先としてルータ９００を表現する宛先情報を変更し、また修正されたＡＣＲにおいて受信されたＡＣＲの発信元のソースとしてＮＥ９０４を表現するために、受信されたＡＣＲを修正することに関連して、受信されたＡＣＲにルート・レコード情報を追加するためのものである。ルータ９００のさらなる一実施形態においては、受信され、また修正されたＡＣＲにおける起点情報は、起点ホスト情報と、起点領域情報とを含む。ルータ９００の別のさらなる実施形態においては、受信され、また修正されたＡＣＲにおける宛先情報は、宛先領域情報を含んでいる。
【００６３】
ルータ９００のさらに別の実施形態においては、メッセージ処理モジュール９１０はまた、ＡＣＡが、第１のＣＣＦサーバ９１６が過負荷状態に起因して、修正されたＡＣＲを処理することができないことを示すことを判定し、また修正されたＡＣＲが、改訂されたＡＣＲを形成するように変更され、修正されたＡＣＲを再送信する代わりに、課金システム通信モジュール９１２により代替のＣＣＦサーバ９１８に対して送信されるべきことを決定するためのものである。
【００６４】
ルータ９００のさらなる一実施形態においては、ＡＣＡは、第１のＣＣＦサーバ９１６が、修正されたＡＣＲを処理するにはあまりにもビジーであることを示す。ルータ９００の別のさらなる実施形態においては、ＡＣＡは、３００４というコード値を有する結果コード情報を含んでいる。
【００６５】
ルータ９００のまた別のさらなる実施形態においては、メッセージ処理モジュール９１０はまた、複数のＣＣＦサーバ９１４のうちの負荷を処理する分布に関連した負荷分布関数を含むアルゴリズムに少なくとも部分的に基づいて、修正されたＡＣＲについての代替の宛先として代替のＣＣＦサーバ９１８を選択するためのものである。
【００６６】
ルータ９００のまたさらなる一実施形態においては、メッセージ処理モジュール９１０はまた、複数のＣＣＦサーバ９１４についての負荷インデックスに関連した代替のＣＣＦサーバ９１８についての１つまたは複数の負荷インデックスと、複数のＣＣＦサーバ９１４についての負荷搬送容量に関連した代替のＣＣＦサーバ９１８についての負荷搬送容量と、複数のＣＣＦサーバ９１４に関連したラウンド・ロビン・スキームと、複数のＣＣＦサーバ９１４に関連した重み付けされたラウンド・ロビン・スキームとに少なくとも部分的に基づいて、代替のＣＣＦサーバ９１８を選択するためのものである。ルータ９００のさらにさらなる一実施形態においては、負荷インデックスは、課金システム通信モジュール９１２を経由して複数のＣＣＦサーバ９１４から受信される負荷情報に少なくとも部分的に基づいている。ルータ９００の別のさらにさらなる実施形態においては、ラウンド・ロビン・スキームと、重み付けされたラウンド・ロビン・スキームとのうちの少なくとも一方は、修正されたＡＣＲにおけるセッション識別子情報に対してアルゴリズムを適用することに少なくとも部分的に基づいている。
【００６７】
別のまたさらなる実施形態においては、ルータ９００はまた、リンクされた関係にある通信セッションについてのセッション識別子と、発信元のソース識別子と、選択された宛先識別子とを記憶するためのストレージ・デバイス９２０を含んでいる。ルータ９００のさらにさらなる一実施形態においては、セッション識別子は、通信セッションを識別するように適合され、発信元のソース識別子は、通信セッションに関連して、受信されたＡＣＲについての発信元のソースとしてＮＥ９０４を識別するように適合され、また選択された宛先識別子は、ＮＥ９０４によって開始される通信セッションについてのＡＣＲを処理するために現在選択されているように代替のＣＣＦサーバ９１８を識別するように適合される。ルータ９００のさらに別のさらなる実施形態においては、課金システム通信モジュール９１２はまた、代替のＣＣＦサーバ９１８が、改訂されたＡＣＲを成功裏に処理したことを示すＡＣＡを代替のＣＣＦサーバ９１８から受信するためのものである。この実施形態においては、メッセージ処理モジュール９１０はまた、修正されたＡＣＡを形成するように、受信されたＡＣＡを修正するためのものである。説明されている実施形態においては、サービス・ネットワーク通信モジュール９０８はまた、修正されたＡＣＡをＮＥ９０４に対して送信するためのものである。
【００６８】
ルータ９００のさらにまた別の実施形態においては、メッセージ処理モジュール９１０はまた、ＡＣＡが、第１のＣＣＦサーバ９１６が過渡的な故障状態に起因して、修正されたＡＣＲを処理することができないことを示すことを判定し、また修正されたＡＣＲが、改訂されたＡＣＲを送信する代わりに課金システム通信モジュール９１２によって第１のＣＣＦサーバ９１６に対して再送信されるべきであることを決定するためのものである。ルータ９００のさらなる一実施形態においては、ＡＣＡは、第１のＣＣＦサーバ９１６が修正されたＡＣＲを処理するためには少なくとも一時的に容量不足であることを示す。ルータ９００の別のさらなる実施形態においては、ＡＣＡは、４００２というコード値を有する結果コード情報を含んでいる。ルータ９００のまた別のさらなる実施形態においては、メッセージ処理モジュール９１０はまた、ＡＣＡを受信した後に修正されたＡＣＲを再送信する前に課金システム通信モジュール９１２に構成可能な時間を待つようにさせるためのものである。ルータ９００のさらに別のさらなる実施形態においては、課金システム通信モジュール９１２はまた、第１のＣＣＦサーバ９１６が、修正されたＡＣＲを成功裏に処理したことを示すＡＣＡを第１のＣＣＦサーバ９１６から受信するためのものである。この実施形態においては、メッセージ処理モジュール９１０はまた、修正されたＡＣＡを形成するように、受信されたＡＣＡを修正するためのものである。説明されている実施形態においては、サービス・ネットワーク通信モジュール９０８はまた、修正されたＡＣＡをＮＥ９０４に対して送信するためのものである。
【００６９】
図４をもう一度参照すると、コンピュータによって実行されるときに、サービス・プロバイダ・ネットワークのＮＥによって提供されるサービスの明細を明らかにする課金システムを使用するためのプロセスを実行するように、課金システムの中の対応するコンピュータ制御されたルータにさせるプログラム命令を記憶する非一次的コンピュータ読取り可能媒体の例示の一実施形態が、示される。様々な追加の実施形態においては、非一次的コンピュータ読取り可能媒体に記憶されるプログラム命令は、コンピュータによって実行されるときに、図４〜８を参照して、サービス・プロバイダ・ネットワークのＮＥによって提供されるサービスの明細を明らかにする課金システムを使用するためのプロセス４００、５００、６００、７００、８００に関連する機能の様々な組合せを実行するように、コンピュータ制御されたルータにさせることができる。言い換えれば、上記で説明されるプロセスの様々な実施形態は、非一次的コンピュータ読取り可能媒体に記憶されるプログラム命令によって実装される可能性がある。
【００７０】
同様に、様々な実施形態においては、非一次的コンピュータ読取り可能媒体に記憶されるプログラム命令は、コンピュータによって実行されるときに、図９を参照して、上記で説明されるルータ９００の様々な実施形態に関連する機能の様々な組合せを実行するように、コンピュータ制御されたルータにさせることができる。例えば、コンピュータ制御されたデバイスは、ルータ９００を含むことができる。図９を参照して上記で説明される任意の適切なモジュールは、プログラム命令に関連するコンピュータと非一次的コンピュータ読取り可能媒体とを含むことができる。代わりに、プログラム命令に関連するコンピュータと非一次的コンピュータ読取り可能媒体とは、図９を参照して上記で説明されるモジュールの任意の適切な組合せと動作可能に通信している個別のコンポーネント、または組み合わされたコンポーネントとすることができる。
【００７１】
上記説明は、単に本発明の特定の実施形態についての開示を提供しているにすぎず、また本発明をそれだけに限定する目的のために意図してはいない。したがって、本発明は、上記で説明された実施形態だけに限定されるものではない。むしろ、当業者なら、本発明の範囲内に含まれる代替の実施形態を思い付くことができることが、認識される。
【図１】
2014531875.tif 000003
【図２】
2014531875.tif 000004
【図３】
2014531875.tif 000005
【図４】
2014531875.tif 000006
【図５】
2014531875.tif 000007
【図６】
2014531875.tif 000008
【図７】
2014531875.tif 000009
【図８】
2014531875.tif 000010
【図９】
2014531875.tif 000011
【国際調査報告】
2014531875.tif 000012
2014531875.tif 000013