JP2023503889A - ロックフリー通信ネットワークリソース割当て共有のための方法、システムおよびコンピュータ読取可能媒体 - Google Patents

Abstract

ロックフリー通信ネットワークリソース割当て共有のための方法の例が、複数の課金ノードを含む分散型課金システムの第１の課金ノードで行われる。方法の例は、共有リソースプランからの第１のリソース量を要求する第１の通信ネットワークリソース割当て要求を、要求エンティティから受信することと、共有リソースプランが第１のリソース量を割当てるのに利用可能な十分なリソースを有することを確認することなしに、第１のメンバーの第１の通信ネットワークリソース割当てを要求エンティティに提供することとを備え、第１の通信ネットワークリソース割当ては、第１のリソース量よりも少ない第２のリソース量を示し、かつ／または、第１の通信ネットワークリソース割当ては、第１の通信ネットワークリソース割当ての有効期限が切れる時を示す有効時間と関連付けられており、方法の例はさらに、共有リソースプランのリソースを確保する第１のリソース確保要求を、第２の課金ノードに送信することを備える。

Description

優先権主張
本願は、２０１９年１１月２０日に出願された米国特許出願継続番号第１６／６９０，０５８号に基づく利益を主張し、その開示全体を本明細書に引用により援用する。

技術分野
本明細書に記載の主題は、通信ネットワークに関する。特に、本明細書に記載の主題は、ロックフリー通信ネットワークリソース割当て共有のための方法、システムおよびコンピュータ読取可能媒体に関する。

背景
通信ネットワークサービスプロバイダは、モバイルデバイスの加入者に、多様な異なるネットワークサービスを提供することができる。サービスプロバイダによって提供されるリソースプランは、通常、異なる性能カテゴリとさまざまなリソース量との組合せによって特徴付けられる。たとえば、加入者は、所与の帯域幅速度、所与のリソース量のダウンロードサイズリソース割当て、および／または特定のサービス品質（ｑｕａｌｉｔｙ ｏｆ ｓｅｒｖｉｃｅ：ＱｏＳ）レベルのリソースプラン（たとえば、モバイルデータプランまたは加入プラン）に対して月額料金を支払う。同様に、別の加入者は、より低い帯域幅速度、より少ないリソース割当て配分、および／またはより低いＱｏＳレベルの異なるリソースプランに加入することが可能である。

加入者がリソースプラン（たとえば、データプランまたはクレジットプラン）を共有する場合がある。たとえば、家族共有データプランでは、（たとえば、夫、妻、およびその子供の）複数のユーザデバイスが、１ヶ月ごとに高速データ割当て（２０ギガバイト）を共有することができる。この例では、ほとんどのデータプランと同様に、サービスプロバイダは、共有データが消費されると、加入者のサービスを停止するのが一般的である。別の例では、家族共有プランは、１人以上のメンバーが費やした料金の一部を共有することを含む場合がある。たとえば、家族共有プランは、最高額（たとえば、プランのクレジット限度額）を上限として、子供メンバーの料金の２０％を支払うことができる。

共有リソースプランのメンバーによるリソースの過剰消費を防ぐ方法として考えられるある方法では、プランのあるメンバーがリソース割当て要求を行うと、共有リソースプランにロックを使用することが含まれる。ロックを使用すると、データの過剰消費を防ぐことができる（かつ、サービスプロバイダの収益が影響を受けるのを軽減することができる）が、そのような解決策は、ネットワークにおけるレイテンシおよび性能に影響を与える可能性がある。オンライン課金システム（ｏｎｌｉｎｅ ｃｈａｒｇｉｎｇ ｓｙｓｔｅｍ：ＯＣＳ）が分散型アーキテクチャを利用し、一部のＯＣＳノードが異なるリソースプランに対応する、および／または一部のＯＣＳノードが同じ共有リソースプランの異なるメンバーのリソース割当て要求に対応する場合、さらに他の問題が生じる可能性がある。

したがって、ロックフリー通信ネットワークリソース割当て共有のための方法、システムおよびコンピュータ読取可能媒体が必要である。

概要
ロックフリー通信ネットワークリソース割当て共有のための方法、システム、およびコンピュータ読取可能媒体が開示される。いくつかの実施形態では、方法の例は、複数の課金ノードを含む分散型課金システムの第１の課金ノードにおいて行われ、第１の課金ノードは、共有リソースプランの第１のメンバーと関連付けられた通信ネットワークリソース割当て要求に対応するためのものであり、第２の課金ノードが、共有リソースプランと関連付けられたリソース確保を管理する。方法の例は、共有リソースプランからの第１のリソース量を要求する第１の通信ネットワークリソース割当て要求を、要求エンティティから受信することと、共有リソースプランが第１のリソース量を割当てるのに利用可能な十分なリソースを有することを確認することなしに、第１のメンバーの第１の通信ネットワークリソース割当てを、要求エンティティに提供することとを備え、第１の通信ネットワークリソース割当ては、第１のリソース量よりも少ない第２のリソース量を示し、かつ／または、第１の通信ネットワークリソース割当ては、第１の通信ネットワークリソース割当ての有効期限が切れる時を示す有効時間と関連付けられており、方法の例はさらに、共有リソースプランのリソースを確保する第１のリソース確保要求を、第２の課金ノードに送信することを備える。

いくつかの実施形態では、システムの例は、複数の課金ノードを含む分散型課金システムの第１の課金ノードを備える。第１の課金ノードは、少なくとも１つのプロセッサとメモリとを使用して実装される。第１の課金ノードは、共有リソースプランの第１のメンバーと関連付けられた通信ネットワークリソース割当て要求に対応するためのものであり、第２の課金ノードが、共有リソースプランと関連付けられたリソース確保を管理する。第１の課金ノードは、共有リソースプランからの第１のリソース量を要求する第１の通信ネットワークリソース割当て要求を、要求エンティティから受信し、共有リソースプランが第１のリソース量を割当てるのに利用可能な十分なリソースを有することを確認することなしに、第１のメンバーの第１の通信ネットワークリソース割当てを、要求エンティティに提供するために構成され、第１の通信ネットワークリソース割当ては、第１のリソース量よりも少ない第２のリソース量を示し、かつ／または、第１の通信ネットワークリソース割当ては、第１の通信ネットワークリソース割当ての有効期限が切れる時を示す有効時間と関連付けられており、第１の課金ノードはさらに、共有リソースプランのリソースを確保する第１のリソース確保要求を、第２の課金ノードに送信するために構成される。

本明細書に記載の主題は、ハードウェアおよび／またはファームウェアと組合せてソフトウェアで実装され得る。たとえば、本明細書に記載の主題は、プロセッサによって実行されるソフトウェアで実装され得る。実装の一例では、本明細書に記載の主題は、コンピュータのプロセッサによって実行されると、ステップを実行するようにコンピュータを制御するコンピュータ実行可能命令を格納したコンピュータ読取可能媒体を使用して実装され得る。実行されるステップは、本発明に関連して本明細書に記載のステップのうちの任意の１つ以上に対応することができる。本明細書に記載の主題を実現するのに適したコンピュータ読取可能媒体の例は、ディスクメモリデバイス、チップメモリデバイス、プログラマブルロジックデバイス、および特定用途向け集積回路などの非一時的なデバイスを含む。さらに、本明細書に記載の主題を実現するコンピュータ読取可能媒体は、単一のデバイスもしくはコンピューティングプラットフォーム上に配置されてもよい、または、複数のデバイスもしくはコンピューティングプラットフォームにわたって分散されてもよい。

本明細書で使用する場合、「ノード」という用語は、１つ以上のプロセッサとメモリとを含む少なくとも１つの物理的なコンピューティングプラットフォームを指す。

本明細書で使用する場合、「機能」または「モジュール」という用語は、本明細書に記載の機能を実装するためのハードウェアおよび／またはファームウェアと組合せたソフトウェアを指す。

本明細書に記載の主題を、添付の図面を参照して以下で説明する。

ロックフリー通信ネットワークリソース割当て共有のための通信環境の例を示すブロック図である。 ロックフリー通信ネットワークリソース割当て共有のためのオンライン課金システム（ＯＣＳ）クラスタの例を示すブロック図である。 ロックフリー通信ネットワークリソース割当て共有に関連付けられたメッセージの例を示すメッセージフロー図である。 ロックフリー通信ネットワークリソース割当て共有に関連付けられたメッセージの例を示すメッセージフロー図である。 ロックフリー通信ネットワークリソース割当て共有の処理例を示すフロー図である。

詳細な説明
本明細書に記載の主題は、ロックフリー（ロックレス）通信ネットワークリソース割当て共有のための方法、システムおよびコンピュータ読取可能媒体に関する。共有リソースプランは、さまざまな通信ネットワークの加入者が利用可能である。たとえば、携帯電話サービスプロバイダは、家族共有プランを販売しており、これらのプランでは、多数の家族メンバー（またはそのユーザデバイス）が、プランの総量（たとえば、毎月の割当て量）から時間またはデータを共有することができる。別の例では、家族共有課金プランは、家族メンバーがクレジットまたは課金を共有することを可能にし、たとえば、課金の少なくとも一部が共有クレジットまたは金銭の割当てによって支払われる場合がある。

ロックベースの課金アーキテクチャは、プランの子メンバーがリソースを要求すると、プランまたは関連する親アカウントをロックすることによって、共有リソースプランに対応して、並行または同時のイベント（たとえば、共有リソースプランの他のメンバーに関連付けられている）がプランまたは親アカウントからリソースを（過剰）消費できないようにすることができる。プランまたは親アカウントをロックすることで、過剰消費の可能性によって収益が影響を受けるのが防止されるが、このようなロックは、システムのレイテンシおよび性能に大きな影響を与える可能性がある。さらに、オンライン課金システム（ＯＣＳ）が、一部のＯＣＳノードが同じ共有リソースプランの異なるメンバーに対応する分散型アーキテクチャを利用する場合、ロックベースの課金アーキテクチャを使用してリソース割当て共有を達成するために、複雑性がさらに必要になる場合がある。

本明細書に記載の主題のいくつかの態様によると、ロックフリー通信ネットワークリソース割当て共有のための技術、方法、システムまたは機構が開示される。いくつかの実施形態では、ロックフリー通信ネットワークリソース割当て共有は、親アカウントをロックすることなく共有リソースプランのメンバーをランク付けする（たとえば、メンバーが使用するためのリソース割当てを提供する）ために利用可能である。たとえば、本明細書に記載の少なくともいくつかの態様に係る課金ノード（たとえば、ＯＣＳノード）または関連モジュールが、共有リソースプラン（たとえば、家族データ共有プラン）のメンバーに関連するリソース割当て要求を受信し、これに応答して、共有リソースプランをロックせずに、および／またはリソース割当て要求を完全に認可するために共有リソースプランの十分なリソースを確保する前に（たとえば、別のＯＣＳノード経由で）少ないリソース割当て（たとえば、５メガバイト（ＭＢ）のデータ）を提供することができる。この例では、要求エンティティ（たとえば、パケットゲートウェイ）は、加入者が、たとえば、加入者データセッション中に、初期リソース割当てを消費することを可能にしてもよい。初期リソース割当てが消費されている間、課金ノードは、加入者が使用するための追加リソースを確保するために、別の課金ノードに問合せることができる。この例を続けると、要求エンティティが追加リソース割当てを要求する時間までに、課金ノードは、この後続のリソース割当て要求を完全に認可するのに十分なリソースを確保している可能性がある。または、課金ノードが、加入者が消費される残りのリソースを有していないと判断した場合（たとえば、共有リソースアカウントを管理する別の課金ノードと通信することによって）、課金ノードは、後続のリソース割当て要求を拒否して、収益の潜在的損失を最初の少ないリソース割当てに限定することができる。

本明細書に記載の主題のいくつかの態様によると、ロックフリー通信ネットワークリソース割当て共有アルゴリズムまたは関連する実装は、分散型ＯＣＳ（たとえば、ＯＣＳクラスタ）の複数の課金ノード（たとえば、ＯＣＳノード）上で実装されてもよい。たとえば、アルゴリズムは、最小割当て（たとえば、比較的小さくてもよい所定量のリソース）および／または有効時間（たとえば、リソース割当ての有効期限が切れる時を示す時間）を提供することによって、分散型ＯＣＳの課金ノードにイベントに反応するように指示してもよく、課金ノードに親（たとえば、関連の共有リソースプランに対するリソース確保および／または割当てに対応する課金ノード）からリソースを確保するように指示してもよく、課金ノードに、共有リソースプランからそれ以上のリソースを利用可能でない場合を除いて、最小割当てまたは所定の値を確保するように指示してもよい。

有利なことに、ロックフリー通信ネットワークリソース割当て共有を利用することにより、リソース共有および関連のある課金に関連するレイテンシならびに性能の問題を、緩和または防止することができる。さらに、ネットワークを介したおよびリクエストのインラインでの同期ロックを必要とせず、関連するロックオーバーヘッドが回避されるので、ロックフリー通信ネットワークリソース割当て共有を利用する分散型ＯＣＳクラスタは、分散型ＯＣＳクラスタの異なるノードが共有リソースプランの異なるメンバーに対応するシナリオに関わる複雑さを低減することが可能である。

本明細書に記載の主題のさまざまな実施形態について以下で詳細に参照し、その例を添付の図面に示す。可能な限り、同一または類似の部品を参照するために、同じ参照番号が図面全体にわたって使用される。

図１は、ロックフリー通信ネットワークリソース割当て共有のための通信環境１００の例を示すブロック図である。通信環境１００は、さまざまなデータ、アプリケーション、および／またはサービス、たとえば、電話、インターネット、テキストメッセージなどを提供するための１つ以上の通信ネットワークを表すことができる。

図１を参照すると、通信環境１００は、ポリシーサーバ１０２、加入者プロファイルリポジトリ（ｓｕｂｓｃｒｉｂｅｒ ｐｒｏｆｉｌｅ ｒｅｐｏｓｉｔｏｒｙ：ＳＰＲ）１０４、オンライン課金システム（ＯＣＳ）クラスタ１０６、およびパケットデータネットワーク（ｐａｃｋｅｔ ｄａｔａ ｎｅｔｗｏｒｋ：ＰＤＮ）ゲートウェイ（ＰＧＷ）１０８、および請求システム１１０を含み得る。通信環境１００は、加入者に関連付けられたユーザ機器（ｕｓｅｒ ｅｑｕｉｐｍｅｎｔ：ＵＥ）デバイス１１２にＰＧＷ１０８を通信可能に接続するアクセスネットワーク１１６を含み得る。ＵＥデバイス１１２は、アクセスネットワーク１１６を介して通信環境１００内のさまざまなネットワークノードに接続可能なコンピュータもしくはデバイス（たとえば、モバイルスマートフォン、タブレットコンピュータデバイス、パーソナルデジタルアシスタント（ＰＤＡ）等）を表してもよい、および／または（たとえば、ＰＧＷ１０８を介した）インターネットへの接続、もしくは通信環境１００を使用したサービスもしくはデータの受信が可能でもよい。

ＯＣＳクラスタ１０６は、１つ以上のＯＣＳノードを含む分散型ＯＣＳを表してもよい。ＯＣＳクラスタ１０６またはそのノード（複数可）は、１つ以上の課金機能を実行するための任意の適切な１つまたは複数のエンティティ（たとえば、少なくとも１つのプロセッサ上で実行される１つ以上のコンピューティングプラットフォームまたはソフトウェア）でもよい。たとえば、ＯＣＳクラスタ１０６の一部のノードは、異なる加入者のためのリソース割当て要求の加工または対応を行ってもよい。この例では、ＯＣＳクラスタ１０６の一部のノードは、同じ共有リソースプラン、たとえば、家族データ共有プランの加入者からのリソース割当て要求に対応してもよい。

いくつかの実施形態では、共有リソースプランは、メンバー（たとえば、モバイルネットワーク加入者）がプランの総リソース量（たとえば、総月間割当て量）から通信ネットワーク関連リソースを共有または使用することを可能にする場合がある。たとえば、共有リソースは、データ量（たとえば、５ギガバイト（ＧＢ））、時間（たとえば、１００分のインターネットサービス）、またはクレジット額（たとえば、２００ドル）を含む場合がある。

いくつかの実施形態では、ＯＣＳクラスタ１０６またはそのノード（複数可）は、ＰＧＷ１０８および／または別のエンティティから加入者利用データ（たとえば、ＵＥ１１２によって生成または受信されたトラフィックおよびシグナリングデータ）を受信してもよい。ＯＣＳクラスタ１０６またはそのノード（複数可）は、ＰＧＷ１０８から受信したさまざまな加入者の加入者利用データを記録および格納するために、加入者利用データベースを維持するように構成されてもよい。いくつかの実施形態では、ＯＣＳクラスタ１０６またはそのノード（複数可）は、使用量データベースを利用して、加入者ごとの特定のデータ使用量（たとえば、割当てバケット単位で）を区別し、追跡するように構成されてもよい。

いくつかの実施形態では、ＯＣＳクラスタ１０６またはそのノード（複数可）は、ロックフリー通信ネットワークリソース割当て共有アルゴリズムまたは本明細書に記載のさまざまな態様を利用するための機能（たとえば、１つ以上のモジュール）を含み得る。たとえば、ＱＭＥ２０６は、共有リソースプラン（たとえば、家族データ共有プラン）のメンバーに関連するリソース割当て要求を受信し、これに応答して、共有リソースプランをロックすることなく、および／または、共有リソースプランのリソースの割当ておよび／もしくは確保を管理する別のＯＣＳノード（たとえば、ＯＣＳノード２０４）を介して共有リソースプランの十分なリソースを確保する前に、少なくとも最小リソース割当てを提供するために構成されてもよい。

ＰＧＷ１０８は、アクセスネットワーク１１６を介してＵＥ１１２からパケット通信を受信するとともに、ＵＥ１１２に関連する利用状況を（たとえば、Ｇｙインターフェイスを介して）ＯＣＳクラスタ１０６またはそのノードに報告するように構成された通信環境１００内の任意の適切なエンティティを表してもよい。ＰＧＷ１０８はまた、ネットワーク状態データ（たとえば、トラフィック負荷状態）を、ポリシーサーバ１０２および／またはＯＣＳクラスタ１０６もしくはそのノード（複数可）に提供するように構成されてもよい。ＰＧＷ１０８はまた、ポリシーサーバ１０２が提供するポリシー規則を実行または実施するように構成されてもよい。いくつかの実施形態では、ＰＧＷ１０８は、ポリシーおよび課金実施機能（ｐｏｌｉｃｙ ａｎｄ ｃｈａｒｇｉｎｇ ｅｎｆｏｒｃｅｍｅｎｔ ｆｕｎｃｔｉｏｎ：ＰＣＥＦ）、ベアラ結合およびイベント報告機能（ｂｅａｒｅｒ ｂｉｎｄｉｎｇ ａｎｄ ｅｖｅｎｔ ｒｅｐｏｒｔｉｎｇ ｆｕｎｃｔｉｏｎ：ＢＢＥＲＦ）、ディープパケット検査（ｄｅｅｐ ｐａｃｋｅｔ ｉｎｓｐｅｃｔｉｏｎ：ＤＰＩ）機能、トラフィック検出機能（ｔｒａｆｆｉｃ ｄｅｔｅｃｔｉｏｎ ｆｕｎｃｔｉｏｎ：ＴＤＦ）、または他の同様のネットワーク要素機能のうちの少なくとも１つをサポートまたはホストするように構成された任意のネットワーク要素を含み得る。

いくつかの実施形態では、ＰＧＷ１０８は、さまざまな加入者に対してリソース割当てを要求し、実施するように構成されてもよい。たとえば、加入者または関連するＵＥ１１２がアクセスネットワーク１１６または通信環境１００に接続すると、ＰＧＷ１０８は、加入者が使用するためのリソース割当てを要求および受信するために、ＯＣＳクラスタ１０６またはそのノード（複数可）に、リソース割当て要求を送信してもよい。この例では、加入者がその割当てられたリソースを使用すると（たとえば、ＰＧＷ１０８におけるリソース割当ての残量が閾値に達する、またはそれを下回ると）、ＰＧＷ１０８は、加入者によって使用される追加リソース割当てを要求し受信するために、ＯＣＳクラスタ１０６またはそのノード（複数可）に別のリソース割当て要求を送信してもよい。この例を続けると、加入者がネットワークからログオフする、またはセッションを終了すると、ＰＧＷ１０８は、今後の使用のために、ＯＣＳクラスタ１０６またはそのノード（複数可）に戻す任意の残りの割当てを解放または放棄してもよい。

請求システム１１０は、１つ以上の請求および／または課金機能を実行するように構成された通信環境１００内の任意の適切なエンティティを表してもよい。いくつかの実施形態では、請求システム１１０は、請求目的で、および／または加入者が請求書を支払うこともしくは追加リソースを購入することを可能にするためのインターフェイスを提供するために、リソース使用量を計算もしくは集計するように使用されてもよい。たとえば、請求システム１１０は、加入者が共有リソースプランのための追加リソースを満たす（チャージ）もしくは購入することを可能にするためのユーザインターフェイスまたは他の通信インターフェイスを提供してもよい。この例では、加入者が共有リソースプランのリソースを購入するトランザクションを完了すると、請求システム１１０は、これらのリソースが、たとえば、共有リソースプランの一人以上のメンバーによって利用可能になるように、ＯＣＳクラスタ１０６またはそのノードに通知してもよい。

ポリシーサーバ１０２は、１つ以上のポリシー機能および／または課金機能を実行するための任意の適切なエンティティを表してもよい。たとえば、ポリシーサーバ１０２は、通信環境１００においてサービスに加入する加入者のためのポリシー規則を決定し、作成するように構成されてもよい。この例では、ポリシーサーバ１０２は、ポリシーおよび課金制御（ｐｏｌｉｃｙ ａｎｄ ｃｈａｒｇｉｎｇ ｃｏｎｔｒｏｌ：ＰＣＣ）規則を生成し、これらの規則を１つ以上のネットワーク要素（たとえば、ＰＧＷ１０８）に提供してもよい。この例を続けると、ポリシーサーバ１０２によって作成されたＰＣＣ規則は、一人以上の加入者に関連するサービス、ＱｏＳレベル、および課金規則に関するものでもよい。いくつかの実施形態では、ポリシーサーバ１０２は、ポリシーおよび課金規則機能（ｐｏｌｉｃｙ ａｎｄ ｃｈａｒｇｉｎｇ ｒｕｌｅｓ ｆｕｎｃｔｉｏｎ：ＰＣＲＦ）を含み得る、ならびに／またはＤｉａｍｅｔｅｒベースのネットワーク要素もしくはサーバによって、ホストされ実行されてもよい。

いくつかの実施形態では、ポリシーサーバ１０２または別のエンティティは、ＯＣＳクラスタ１０６またはそのＯＣＳノードから割当て使用情報を要求するように構成されてもよい。割当て使用情報は、ＯＣＳクラスタ１０６またはそのノード（複数可）とのアプリケーションインターフェイス（たとえば、Ｓｙインターフェイス）を介して、要求および受信されてもよい。いくつかの実施形態では、ポリシーサーバ１０２は、Ｄｉａｍｅｔｅｒセッション識別子情報、加入者識別子情報（たとえば、ＩＭＳＩ）、加入者ティア情報、加入者サービスタイプ識別子情報、および／または他の情報のうちの少なくとも１つを含み得るＤｉａｍｅｔｅｒ要求メッセージを送信することにより、ＯＣＳクラスタ１０６またはそのノード（複数可）に割当て使用情報を要求してもよい。要求を受信すると、ＯＣＳクラスタ１０６またはそのノード（複数可）は、適切な加入者割当て使用情報を決定するように提供された情報を使用するように構成されてもよく、これは最終的に要求ポリシーサーバ１０２に返されることがある。

ＳＰＲ１０４は、通信環境１００の加入者に関連するプロファイル情報を格納するように構成されたデータベースを含み得る。たとえば、格納された加入者プロファイルデータは、リソースプランコード（たとえば、請求プランコードまたは名前）およびリソースプランコードに関連付けられたエンタイトルメントを含み得る。例示的なエンタイトルメントには、ＶｏＩＰ（ｖｏｉｃｅ ｏｖｅｒ Ｉｎｔｅｒｎｅｔ ｐｒｏｔｏｃｏｌ）サービス、ビデオチャット、国内ローミング、国際ローミング、ＭｉＦｉ、データ、ギフト（たとえば、特別キャンペーン）、および特定の機器が含まれるが、これらに限定されない。いくつかの実施形態では、ＳＰＲ１０４は、１つ以上のネットワーク要素と統合されてもよい、または複数のコンピューティングプラットフォームもしくはデバイスにわたって分散されてもよい。

いくつかの実施形態では、ＵＥ１１２は、ネットワークアタッチメント手順を開始することによって、通信ネットワークにサービスを登録し得る。たとえば、ＵＥ１１２は、ユーザアタッチ要求メッセージをＰＧＷ１０８に送信することができる。アタッチメント要求メッセージの受信に応答して、ＰＧＷ１０８は、Ｄｉａｍｅｔｅｒクレジット制御要求（ｃｒｅｄｉｔ ｃｏｎｔｒｏｌ ｒｅｑｕｅｓｔ：ＣＣＲ）メッセージをポリシーサーバ１０２に送信し得る。次に、ポリシーサーバ１０２は、ユーザ識別子を含むＤｉａｍｅｔｅｒユーザデータ要求（ＵＤＲ）メッセージをＳＰＲ１０４に送信して、加入者に関連付けられたリソースプランコードおよび／またはプランエンタイトルメントを要求してもよい。たとえば、ＳＰＲ１０４は、リソースプランデータをローカルプロファイルデータベース１１４に格納するように構成されてもよい。または、ＳＰＲ１０４は、加入者のリソースプラン情報を含む外部データベースに問合せてもよい。

図１は説明のためのものであり、図１に関連して上述したさまざまなノードおよび／またはモジュール、位置、および／または機能は、変更、改変、追加、または削除されてもよいことが理解されるであろう。

図２は、ロックフリー通信ネットワークリソース割当て共有のためのＯＣＳクラスタ１０６を示すブロック図である。図２を参照すると、ＯＣＳクラスタ１０６は、１つ以上のＯＣＳノード、たとえば、ＯＣＳノード２００～２０４を含み得る。ＯＣＳノード２００～２０４の各々は、１つ以上の課金関連機能を実行するための任意の適切なエンティティ（たとえば、計算プラットフォーム、または少なくとも１つのプロセッサ上で実行されるソフトウェア）でもよい。いくつかの実施形態では、ＯＣＳノード２００～２０４の各々は、少なくとも１つの加入者からのリソース割当て要求がＯＣＳノード２００～２０４の全てによって対応されない、複数の加入者からのリソース割当て要求の対応を担ってもよい。たとえば、ＯＣＳノード２００は、第１のモバイル加入者からのリソース割当て要求に対応してもよく、ＯＣＳノード２０２は、第２のモバイル加入者からのリソース割当て要求に対応してもよく、ＯＣＳノード２００は、第３のモバイル加入者からのリソース割当て要求に対応してもよい。

いくつかの実施形態では、異なるＯＣＳノードに関連付けられる加入者は、同じ共有リソースプランのメンバーでもよい。たとえば、共有リソースプランは、家族用のデータ共有プランを表してもよく、ＯＣＳノード２００および２０２は、共有リソースプランの子または二次メンバーからの割当て要求に対応し、ＯＣＳノード２０４は、共有リソースプランの親または一次メンバーを管理する。この例では、ＯＣＳノード２０４が共有リソースプランのリソースのリソース確保を管理すると仮定すると、ＯＣＳノード２００～２０２の各々は、リソース確保をＯＣＳノード２０４に送信することができる。

ＯＣＳノード２００～２０４の各々は、割当て管理エンジン（ｑｕｏｔａ ｍａｎａｇｅｍｅｎｔ ｅｎｇｉｎｅ：ＱＭＥ）２０６およびデータストレージ、たとえば、データストレージ２０８～２１２のうちの１つを含み得る。ＱＭＥ２０６は、リソース割当てまたは割当て関連情報を維持、調整、提供、および／または報告するための任意の適切なエンティティ（たとえば、少なくとも１つのプロセッサ上で実行するソフトウェア）でもよい。ＱＭＥ２０６は、さまざまなデータベースおよび／またはデータストレージにアクセスしてもよい。たとえば、ＱＭＥ２０６は、一人以上の加入者についての割当て使用情報（たとえば、確保リソース量、プランの残りのリソース量など）を含むデータベースにアクセスしてもよい。ＱＭＥ２０６はまた、通信環境１００内のさまざまなノードおよびエンティティ（たとえば、他のＯＣＳノードおよび／またはＱＭＥ）と通信してもよい。

いくつかの実施形態では、ＱＭＥ２０６は、ロックフリー通信ネットワークリソース割当て共有アルゴリズムまたは本明細書に記載のさまざまな態様を利用するための機能を含み得る。たとえば、ＱＭＥ２０６は、共有リソースプラン（たとえば、家族データ共有プラン）のメンバーに関連するリソース割当て要求を受信し、これに応答して、共有リソースプランをロックせずに、および／または共有リソースプランのリソースの割当ておよび／もしくは確保を管理する別のＯＣＳノード（たとえば、ＯＣＳノード２０４）を介して共有リソースプランの十分なリソースを確保する前に、少なくとも最小リソース割当てを提供するために構成されてもよい。この例では、共有リソースプランをロックしないことによって、共有リソースプランの複数のメンバーは、ＯＣＳクラスタ１０６内の１つまたは複数のＯＣＳノードからリソース割当てを同時に要求および／または受信することが可能である。

いくつかの実施形態では、（たとえば、ＯＣＳノード２００の）ＱＭＥ２０６は、共有リソースプランからの第１のリソース量を要求する第１のリソース割当て要求を、要求エンティティ（たとえば、ＰＧＷ１０８）から受信し、第１のリソース確保要求を第２の課金ノード（たとえば、ＯＣＳノード２０４）に送信する前に、第１のメンバーの第１のリソース割当てを、要求エンティティに提供するために構成されてもよく、第１のリソース割当ては、第１のリソース量よりも少ない第２のリソース量を示し、ＱＭＥ２０６はさらに、共有リソースプランのリソースを確保する第１のリソース確保要求を、第２の課金ノードに送信するために構成されてもよい。

データストレージ２０８～２１２の各々は、リソース割当て、確保リソース量、トリガ、およびデータ使用規則を含む、データ利用に関連するデータを格納するための任意の適切なエンティティ（たとえば、１つ以上の非一時的なコンピュータ読取可能媒体または１つ以上の記憶装置）を含み得る。たとえば、図２に示されているように、データストレージ２０８は、共有リソースプランの第１の加入者（たとえば、子メンバー）に関連付けられたリソース割当て要求を認可するために使用可能なリソース関連情報（たとえば、確保リソース量）を格納してもよく、データストレージ２１０は、共有リソースプランの第２の加入者（たとえば、第２の子メンバー）に関連付けられたリソース割当て要求を認可するために使用可能なリソース関連情報（たとえば、確保リソース量）を格納してもよく、データストレージ２１２は、共有リソースプランの第３の加入者（たとえば、主メンバー）に関連付けられたリソース割当て要求を認可するために使用可能なリソース関連情報（たとえば、確保リソース量、消費可能な残りの加入者使用量）を格納してもよい。

いくつかの実施形態では、データストレージ２０８～２１２の各々は、それぞれのＱＭＥ２０６もしくは関連するＯＣＳノードに対してローカルでもよい、またはそれによってアクセス可能でもよい。たとえば、データストレージ２０８は、ＯＣＳノード２００と統合されても、またはＯＣＳノード２００の外部に位置してもよく、データストレージ２１０は、ＯＣＳノード２０２と統合されても、またはＯＣＳノード２００の外部に位置してもよく、かつ、データストレージ２１２は、ＯＣＳノード２０４と統合されても、またはＯＣＳノード２０４の外部に位置してもよい。

図２およびその関連する説明は例示のためのものであり、図２におけるＯＣＳクラスタ１０６および／またはさまざまな他のエンティティは、追加および／または異なるモジュール、コンポーネント、もしくは機能を含み得ることが理解されるであろう。

図３Ａ～図３Ｂは、ロックフリー通信ネットワークリソース割当て共有に関連付けられたメッセージの例を示すメッセージフロー図である。図３Ａ～３Ｂにおいて、Ｄｉａｍｅｔｅｒクライアント３００は、ＯＣＳクラスタ１０６またはその中のＯＣＳノード（たとえば、ＯＣＳノード２０２および２０４）と対話するためのＤｉａｍｅｔｅｒプロトコルおよび／または他のプロトコルを利用する要求エンティティ（たとえば、ネットワークノード）を表す。たとえば、Ｄｉａｍｅｔｅｒクライアント３００は、リソース割当てを要求および／または実施し、リソース使用量を追跡し、および／またはリソース使用情報を提供するエンティティを表してもよい。いくつかの実施形態では、Ｄｉａｍｅｔｅｒクライアント３００は、ＰＣＥＦまたはＰＣＥＦに類似する機能を含み得る。たとえば、Ｄｉａｍｅｔｅｒクライアント３００は、ＰＧＷ、ＰＣＥＦ、ＢＢＥＲＦ、ＴＤＦ、もしくはＤＰＩ機能をサポートまたはホストするように構成されたネットワーク要素を含み得る。

いくつかの実施形態では、たとえば、図３Ａ～３Ｂに示されているように、ＯＣＳノード２０２およびＯＣＳノード２０４は、ＯＣＳクラスタ１０６のノードを表してもよく、ＯＣＳノード２０２は、共有リソースプランの子メンバー（たとえば、二次メンバー）である第１の移動加入者に対応し、ＯＣＳノード２０４は、共有リソースプランの親メンバー（たとえば、主メンバー）である異なる移動加入者に対応する。そのような実施形態では、ＯＣＳノード２０４は、共有リソースプランに関連するプランの総リソース量（たとえば、総月間割当て量）を管理してもよく、関連リソース確保の対応、たとえば、共有リソースプランのさまざまなメンバーによる使用のために、プランの総リソース量からの一部のＯＣＳノード２０２および／または他のＯＣＳノードに対する割当てを担ってもよい。

図３Ａを参照すると、ステップ３０１において、Ｄｉａｍｅｔｅｒ ＣＣＲ ｉｎｉｔｉａｌ（ＣＣＲ－Ｉ）メッセージまたは別の割当て要求メッセージが、Ｄｉａｍｅｔｅｒクライアント３００からＯＣＳノード２０２に送信されてもよく、ＣＣＲ－Ｉメッセージは、要求リソース量（たとえば、５０ＭＢ）を示す要求サービスユニット（ｒｅｑｕｅｓｔｅｄ ｓｅｒｖｉｃｅ ｕｎｉｔ：ＲＳＵ）属性値ペア（ａｔｔｒｉｂｕｔｅ ｖａｌｕｅ ｐａｉｒ：ＡＶＰ）を含む。たとえば、共有リソースプランの加入者または関連ＵＥ１１２がアクセスネットワーク１１６または環境１００にアタッチした後、Ｄｉａｍｅｔｅｒクライアント３００は、加入者に関連するリソース割当て（たとえば、データ使用量、時間使用量、または金銭使用量）を要求するＤｉａｍｅｔｅｒ ＣＣＲ－Ｉメッセージを送信し得る。

いくつかの実施形態では、Ｄｉａｍｅｔｅｒクライアント３００は、共有リソースプランのメンバー（たとえば、子メンバー）である移動加入者のトラフィックに対応するＰＣＥＦでもよく、ＯＣＳノード２０２は、この加入者に対応し、任意のリソース割当てを実施するために構成されてもよい。このような実施形態では、共有リソースプランまたはプランの総リソース量は、ＯＣＳクラスタ１０６内の異なるＯＣＳノード（ＯＣＳノード２０４）によって管理される。

ステップ３０２において、Ｄｉａｍｅｔｅｒクレジット制御応答初期（ｃｒｅｄｉｔ ｃｏｎｔｒｏｌ ａｎｓｗｅｒ ｉｎｉｔｉａｌ：ＣＣＡ－Ｉ）メッセージまたは別の割当て応答メッセージが、ＯＣＳノード２０２からＤｉａｍｅｔｅｒクライアント３００に送信されてもよく、ＣＣＡ－Ｉメッセージは、認可リソース量（たとえば、５ＭＢ）を示す認可サービスユニット（ｇｒａｎｔｅｄ ｓｅｒｖｉｃｅ ｕｎｉｔ：ＧＳＵ）ＡＶＰを含む。

いくつかの実施形態では、ＯＣＳノード２０２は、加入者または関連する共有リソースプランが、リソース割当て要求を認可するのに十分な残りのリソースを有するかどうかを知ることなく、リソース割当て要求を認可してもよい。そのような実施形態では（たとえば、リソース割当てを完全に認可することができるかどうかをＯＣＳノード２０２が知らない場合）、ＯＣＳノード２０２は、加入者のためにＤｉａｍｅｔｅｒクライアント３００によって要求された量よりも少ないリソース量を認可してもよい。

いくつかの実施形態では、（たとえば、リソース割当て要求が完全に認可され得るかどうかをＯＣＳノード２０２が知らない場合）、ＯＣＳノード２０２によって最初に認可されるリソース量は、所定の値または割合に基づいてもよい。たとえば、所定の値または割合は、最小割当てと呼ばれてもよく、プランの初期の総リソース量（たとえば、プランの周期の最初の開始リソース割当て量）より大幅に少なくてもよい。この例では、プランの最初の総リソース量（最大量とも呼ばれる）が５ＧＢであると仮定すると、最小割当ては、５ＭＢすなわち最大量の１０００分の１でもよい。

いくつかの実施形態では、（たとえば、リソース割当て要求が完全に認可され得るかどうかをＯＣＳノード２０２が知らない場合）、要求よりも少ないリソース割当てを提供することに代えて、またはそれに加えて、ＯＣＳノード２０２によって認可されるリソース量は、リソース割当ての有効期限が切れる時を示すための「短い」有効時間と関連付けられることがある。たとえば、「短い」有効時間は、完全に認可されるリソース割当て要求に対して使用されるデフォルトまたは典型的な有効時間（たとえば、３０分）よりも短い時間（たとえば、３０秒）でもよい。この例では、「短い」有効時間は、サービスプロバイダの収益が影響を受けるのを制限するため、および／または、ＯＣＳノード２０２が、たとえば、ＯＣＳノード２０４から共有リソースプランのリソースを確保した後に、要求エンティティ（たとえば、Ｄｉａｍｅｔｅｒクライアント３００）が新しいリソース割当てを要求するトリガとして使用されてもよい。

いくつかの実施形態では、（たとえば、リソース割当て要求が完全に認可され得るとＯＣＳノード２０２が知っている場合）、ＯＣＳノード２０２によって最初に認可されるリソース量は、要求リソース量に対するものでもよい。たとえば、ＯＣＳノード２０２が共有リソースプランの十分なリソースを以前に確保している場合、ＯＣＳノード２０２は、確保リソース量以下のリソース量のリソース割当て要求を認可することができる。

ステップ３０３において、共有リソースプランに関連付けられたリソースを確保する確保要求が、ＯＣＳノード２０２からＯＣＳノード２０４に送信されてもよい。たとえば、ＯＣＳノード２０２は、共有リソースプランの確保リソース量が再注文閾値に達するかまたはそれより低くなるたびに、ＯＣＳノード２０２が共有リソースプランに関連付けられたリソースを確保するためのトリガとして再注文閾値を使用するように構成されてもよい。この例では、再注文閾値は、プランの最大量の一部、たとえば、２５ＭＢまたはプランの最大量である５ＧＢの１００分の５でもよい。

いくつかの実施形態では、確保要求は、所定の値または割合に基づいてリソースの量を確保してもよい。たとえば、ＯＣＳノード２０２は、５０ＭＢすなわちプランの最大量である５ＧＢの１００分の１の割当て確保単位を使用するように構成されてもよい。この例では、ＯＣＳノード２０２は、５０ＧＢまたはその倍数が加入者のために確保されるように要求してもよい。

ステップ３０４Ａにおいて、少なくとも一部の要求リソースが確保されたことを示すための確保応答が、ＯＣＳノード２０４からＯＣＳノード２０２に送信されてもよい。たとえば、共有リソースプランの残りのリソース量が十分である場合、ＯＣＳノード２０４は、確保要求を完全に認可し（たとえば、要求リソース量を確保し）、ＯＣＳノード２０２に通知してもよい。同様に、この例では、共有リソースプランの残りのリソース量が十分でない場合、ＯＣＳノード２０４は、確保要求を部分的に認可し（たとえば、要求リソース量の一部のみを確保し）、ＯＣＳノード２０２に通知してもよい。

ステップ３０４Ｂにおいて、共有リソースプランが消費可能な残りのリソースを有さない場合、ＯＣＳノード２０２および／またはＯＣＳクラスタ１０６内の他のノードにこれを示すための「割当てなし」フラグが設定され得る。たとえば、ＯＣＳノード２０４が、共有リソースプランが消費可能な残りのリソースを有していないと決定した場合、ＯＣＳノード２０４は、ＯＣＳノード２０２および／またはＯＣＳクラスタ１０６内の他のＯＣＳノードに通知してもよい。この例では、ＯＣＳノード２０４は、ＯＣＳノード２０２および／またはＯＣＳクラスタ１０６内の他のノードによって共有される、またはアクセス可能なメモリに「割当てなし」フラグを設定してもよい。別の例では、ＯＣＳノード２０４は、共有リソースプランが消費可能な残りのリソースを有していないことを示すためのローカルな「割当てなし」フラグを設定するために、メッセージを送信してもよい、または他の態様では、ＯＣＳノード２０２および／または他のエンティティをトリガしてもよい。

いくつかの実施形態では、たとえば、共有リソースが消費されるクレジットまたは金銭である場合、ＯＣＳノード２０４は、加入者関連料金（または共有プランに適用される部分）が共有プランの利用可能クレジット限度を超えるたびに、ＯＣＳノード２０２および／またはＯＣＳクラスタ１０６内の他のＯＣＳノードに通知してもよい。そのような実施形態では、ＯＣＳノード２０２および／またはＯＣＳクラスタ１０６内の他のＯＣＳノードは、たとえば、加入者の承認によってなど共有プランに追加のクレジットもしくは金銭が適用または認可されるまで、そのようなトランザクションが利用可能クレジットを必要とする場合、その加入者に関わるその後のトランザクションを拒否してもよい。

ステップ３０５において、Ｄｉａｍｅｔｅｒ ＣＣＲ ｕｐｄａｔｅ（ＣＣＲ－Ｕ）メッセージまたは別の割当て要求メッセージが、Ｄｉａｍｅｔｅｒクライアント３００からＯＣＳノード２０２に送信されてもよく、ＣＣＲ－Ｕメッセージは、要求リソース量（たとえば、５０ＭＢ）を示すＲＳＵ ＡＶＰを含む。たとえば、共有リソースプランの加入者または関連するＵＥ１１２が初期または既存の割当て量を使用した後、Ｄｉａｍｅｔｅｒクライアント３００は、加入者に関連する追加リソース割当てを要求するＤｉａｍｅｔｅｒ ＣＣＲ－Ｕメッセージを送信してもよい。

いくつかの実施形態では、ＣＣＲ－Ｕメッセージは、加入者によって使用されたリソースの量を示すための使用サービスユニット（ｕｓｅｄ ｓｅｒｖｉｃｅ ｕｎｉｔ：ＵＳＵ）ＡＶＰを含み得る。たとえば、ＵＳＵ ＡＶＰは、サービスがアクティブになった時点から、または前の測定が終了した時点から測定された使用単位の量を示してもよい。この例では、使用情報は、監査、請求、および／または他の目的で使用可能である。

ステップ３０２において、Ｄｉａｍｅｔｅｒ ＣＣＡ ｕｐｄａｔｅ（ＣＣＡ－Ｕ）メッセージまたは別の割当て応答メッセージが、ＯＣＳノード２０２からＤｉａｍｅｔｅｒクライアント３００に送信されてもよく、ＣＣＡ－Ｕメッセージは、認可リソース量（たとえば、５０ＭＢ）を示すＧＳＵ ＡＶＰを含む。

いくつかの実施形態では、ＯＣＳノード２０２は、確保リソース量（たとえば、ＯＣＳノード２０４を介して以前に確保された量）に基づいて、リソース割当て要求を認可してもよい。たとえば、ＯＣＳノード２０２が共有リソースプランの加入者のために確保されたリソースへのアクセスを有する場合、ＯＣＳノード２０２は、最大で確保リソース量のリソース割当て、およびこの量を含むリソース割当てを提供してもよい。別の例では、予め定義された最小割当て量が確保リソース量より多い場合、ＯＣＳノード２０２は、最小割当て量のリソース割当てを提供してもよい。

いくつかの実施形態では、リソース割当てを認可または提供する前に、ＯＣＳノード２０２は、「割当てなし」フラグが設定されているかどうかを決定してもよい。たとえば、フラグが設定されていることは、共有リソースプランが消費可能な残りのリソースを有していないことを示し得る。この例では、フラグが設定されている場合（および以前の確保から利用可能な確保リソースがない場合）、ＯＣＳノード２０２は、リソース割当て要求を拒否してもよい、または他の態様では、割当てが利用可能でないことをＤｉａｍｅｔｅｒクライアント３００に示してもよい。

図３Ｂを参照すると、ステップ３０７において、Ｄｉａｍｅｔｅｒ ＣＣＲ ｔｅｒｍｉｎａｔｅ（ＣＣＲ－Ｔ）メッセージまたは別の割当て要求メッセージが、Ｄｉａｍｅｔｅｒクライアント３００からＯＣＳノード２０２に送信されてもよく、ＣＣＲ－Ｔメッセージは、加入者によって使用されたリソースの量を示すＵＳＵ ＡＶＰを含む。たとえば、共有リソースプランの加入者もしくは関連ＵＥ１１２がセッションを終了またはログアウトした後で、Ｄｉａｍｅｔｅｒクライアント３００は、クレジット制御セッションを終了させるためのＤｉａｍｅｔｅｒ ＣＣＲ－Ｔメッセージを送信してもよい。

ステップ３０８において、Ｄｉａｍｅｔｅｒ ＣＣＡ ｔｅｒｍｉｎａｔｅ（ＣＣＡ－Ｔ）メッセージまたは別の割当て応答メッセージが、ＣＣＲ－Ｔメッセージが受信され確認されたことを示すために、ＯＣＳノード２０２からＤｉａｍｅｔｅｒクライアント３００に送信されてもよい。

いくつかの実施形態では、ＯＣＳノード２０２は、請求、監査、および／または他の目的で、Ｄｉａｍｅｔｅｒクライアント３００から（たとえば、ＣＣＲ－Ｔで）受信した使用情報を使用することができる。たとえば、ＯＣＳノード２０２は、加入者に関連付けられた使用情報を使用して、解放する確保リソースの量を決定してもよい。この例では、ＯＣＳノード２０２は、Ｄｉａｍｅｔｅｒクライアント３００から受信した使用情報に基づいて、リソース割当てのかなりの部分が消費されなかったと判断してもよく、そのため、ＯＣＳノード２０２は、確保解放をＯＣＳノード２０４に送信することによって、これらのリソースまたはその一部を解放してもよい。

ステップ３０９において、共有リソースプランに関連付けられた確保リソース（たとえば、２５ＭＢ）を解放するための確保解放が、ＯＣＳノード２０２からＯＣＳノード２０４に送信されてもよい。たとえば、確保解放を受信した後、ＯＣＳノード２０４は、解放されるリソースの量だけ共有リソースプランに関連付けられた残りのリソース量を増加させてもよい。

いくつかの実施形態では、更新プロセスは、加入者が共有リソースプランの利用可能なリソースをチャージ（満たす）またはリロードするときに発生し得る。たとえば、ＵＥ１１２を使用する加入者は、請求システム１１０と対話して、追加リソース（たとえば、５ＧＢのデータまたは５０ドルのクレジット）を購入することができる。この例では、更新プロセスは、請求システム１１０がＯＣＳノード２０４および／またはＯＣＳクラスタ１０６内の他のノードに通知し、それによって、Ｄｉａｍｅｔｅｒクライアント３００が追加リソース割当ての要求および受信を可能にするさまざまな動作（たとえば、「割当てなし」フラグのクリアまたは設定削除）をトリガすることを含む場合がある。

ステップ３１０において、共有リソースプランが消費される追加のリソースを有することを示すための新しい割当て認可が、請求システム１１０からＯＣＳノード２０４に送信されてもよい。

ステップ３１１において、ＯＣＳノード２０４は、「割当てなし」フラグ（たとえば、ＯＣＳ２０４におけるローカルフラグ）をクリアし、それによって、共有リソースプランが消費されるリソースを有することを示してもよい。

ステップ３１２において、ＯＣＳノード２０４は、共有リソースプランが消費されるリソースを有することを、ＯＣＳノード２０２およびＯＣＳクラスタ１０６内の他のノードに通知してもよい。たとえば、ＯＣＳノード２０２（およびＯＣＳノード２００）は、リソースが共有リソースプランに追加されたことを示すＯＣＳノード２０４からの通知を受信してもよく、これに応答して、ＯＣＳノード２０２（およびＯＣＳノード２００）はローカルフラグをクリアし、それによって、共有リソースプランが消費されるリソースを有することを示してもよい。

図３Ａ～図３Ｂは例示のためのものであり、図３Ａ～図３Ｂに示されているものとは異なるおよび／または追加のメッセージ、ステップ、および／または動作が使用されてもよいことが理解されるであろう。また、本明細書に記載のさまざまなメッセージ、ステップ、および／または動作は、図３Ａ～図３Ｂに示されている順序またはシーケンスとは異なる順序またはシーケンスで行われてもよいことが理解されるであろう。

図４は、ロックフリー通信ネットワークリソース割当て共有のプロセス４００の例を示す図である。いくつかの実施形態では、本明細書に記載のプロセス４００またはその一部は、ネットワークノード（たとえば、ＯＣＳノード２０２もしくは２０４）、ＱＭＥ２０６、および／または別のモジュールもしくはノードにおいて実行されてもよい、またはそれによって実行されてもよい。いくつかの実施形態では、プロセス４００または関連する動作は、複数の課金ノードを含む通信ネットワーク（たとえば、環境１００）に関連付けられた分散型課金システム（たとえば、ＯＣＳクラスタ１０６）の第１の課金ノード（たとえば、ＯＣＳノード２０２）によって実行されてもよく、第１の課金ノードは、共有リソースプランの第１のメンバー（たとえば、子メンバー）に関連付けられた通信ネットワークリソース割当て要求に対応するためのものであり、第２の課金ノード（たとえば、ＯＣＳノード２０４）は、共有リソースプランに関連付けられたリソース確保を管理する。

プロセス４００を参照すると、ステップ４０２において、共有リソースプランからの第１のリソース量を要求する共有リソースプランの第１のメンバーに関連付けられた第１の通信ネットワークリソース割当て要求が、要求エンティティから受信されてもよい。たとえば、ＰＧＷ１０８またはＤｉａｍｅｔｅｒクライアント３００は、通信ネットワーク加入者が通信ネットワークリソース割当てを必要とすることを示すネットワークアタッチメント要求または他のメッセージを受信してもよい。この例では、ＰＧＷ１０８またはＤｉａｍｅｔｅｒクライアント３００は、通信ネットワーク加入者が使用するための通信ネットワークリソース割当てを要求するＤｉａｍｅｔｅｒ ＣＣＲメッセージを、ＯＣＳクラスタ１０６またはそのノード（たとえば、ＯＣＳノード２０２）に送信してもよい。

ステップ４０４において、共有リソースプランが第１のリソース量を割当てるのに利用可能な十分なリソースを有することを確認することなく、第１のメンバーの第１の通信ネットワークリソース割当てが要求エンティティに提供されてもよく、第１の通信ネットワークリソース割当ては、第１のリソース量よりも少ない第２のリソース量を示し、かつ／または、第１の通信ネットワークリソース割当ては、第１の通信ネットワークリソース割当ての有効期限が切れる時を示す有効時間に関連付けられている。たとえば、ＯＣＳノード２０２は、共有リソースプラン（または関連アカウント）をロックすることなく、ならびに／または（たとえば、共有リソースプランのリソースの割当ておよび／もしくは確保を管理するＯＣＳノード２０４から）要求リソースが消費可能であるという確認を受信することなく、共有リソースプランの加入者の最小割当て（たとえば、所定量のリソース）をＰＧＷ１０８またはＤｉａｍｅｔｅｒクライアント３００に提供するように構成されてもよい。別の例では、ＯＣＳノード２０２は、ＰＧＷ１０８またはＤｉａｍｅｔｅｒクライアント３００に、共有リソースプランの加入者に対してリソース割当ての有効期限が切れる時を示す有効時間を有するリソース割当てを提供するように構成されてもよい。この例では、有効時間は、リソース割当てを認可するときに使用される典型的なまたはデフォルトの有効時間（たとえば、６０分）に対して短い時間（たとえば、３０秒）でもよい。この例を続けると、リソース割当ての有効期限が切れた後、ＰＧＷ１０８またはＤｉａｍｅｔｅｒクライアント３００は、別のリソース割当てを要求する必要がある（これは、ＯＣＳノード２０２がＯＣＳノード２０４から共有リソースプランのリソースを要求および確保するのに十分な時間を提供してもよい）。

ステップ４０６において、共有リソースプランのリソースを確保する第１のリソース確保要求が、第２の課金ノードに送信されてもよい。たとえば、共有リソースプランの加入者のための最小割当て（たとえば、２ＭＢ）をＰＧＷ１０８またはＤｉａｍｅｔｅｒクライアント３００に提供した後、ＯＣＳノード２０２は、ＯＣＳノード２０２が共有リソースプランの一部のリソースを確保し、確保されたリソースを使用して加入者のために後続の通信ネットワークリソース割当て要求を認可できるように、リソース確保要求をＯＣＳノード２０４に送信してもよい。

いくつかの実施形態では、共有リソースプランの第１のメンバーは、共有リソースプランの第２のメンバーに通信ネットワークリソース割当てが割当てられるのと同時に、通信ネットワークリソース割当てを割当てられてもよい。そのような実施形態では、異なるメンバーに配分される割当ては、同じ量でもよい、または異なる量でもよい。

たとえば、ＯＣＳノード２００および／または関連するＱＭＥ２０６は、共有リソースプランの第１のメンバーに関わる割当て関連トランザクションを実行してもよく、ＯＣＳノード２０２および／または関連付けられたＱＭＥ２０６は、共有リソースプランの第２のメンバーに関わる割当て関連トランザクションを同時に実行してもよい。この例では、ＯＣＳノード２００、ＯＣＳノード２０２、およびＯＣＳクラスタ１０６内の他のＯＣＳノードは、共有リソースプランに関連付けられた複数の割当て関連トランザクションが同時に（たとえば、並行してまたはほぼ並行して）発生することを可能にするロックフリー割当て管理アルゴリズムを使用してもよい。これに対して、ロックベースの割当て管理システムは、共有リソースプランに関連付けられた第１の割当て関連トランザクションが発生している間、たとえば、ＯＣＳクラスタ１０６内のどのＯＣＳノードが割当て関連トランザクションに対応していたかに関係なく、共有リソースプランに関連付けられた割当て関連トランザクションが処理されるのを防止することになる。

いくつかの実施形態では、第１のリソース量は、データ使用量、時間使用量、金額、またはクレジット額を含む。たとえば、ＰＧＷ１０８は、通信環境１００を介してデータおよび／またはサービスにアクセスするために、ＯＣＳノード２０２にデータ使用量割当てを要求し、ＯＣＳノード２０２からデータ使用量割当てを受信してもよい。別の例では、ＰＧＷ１０８は、通信環境１００に関連付けられたサービスまたはアイテムを課金するために、ＯＣＳノード２０２にクレジットまたは金銭の割当てを要求し、ＯＣＳノード２０２からクレジットまたは金銭の割当てを受信してもよい。

いくつかの実施形態では、第１のリソース確保要求が、共有リソースプランが利用可能な残りのリソース量よりも大きいリソース量を確保するためのものである場合、第２の課金ノード（たとえば、ＯＣＳノード２０４）は、共有リソースプランが消費可能なリソースがそれ以上ないことを示すフラグを設定することによって第１の課金ノード（たとえば、ＯＣＳノード２０２）に通知する、かつ／または、第１のリソース確保要求で要求されたリソース量の少なくとも一部を提供する。

いくつかの実施形態では、プロセス４００は、第１の通信ネットワークリソース割当てを提供する前に、フラグが設定されていないと判断することを含んでもよく、フラグが設定されていることは、共有リソースプランが消費可能なリソースをそれ以上有していない（たとえば、消費するインターネットデータまたは消費する金銭をそれ以上有していない）ことを示す。

いくつかの実施形態では、プロセス４００は、第１のリソース確保要求に基づいて、第２の課金ノードから確保リソース量を受信することと、共有リソースプランからの第３のリソース量を要求する第２の通信ネットワークリソース割当て要求を、要求エンティティから受信することと、確保リソース量を使用して、共有リソースプランの第１のメンバーの第２の通信ネットワークリソース割当てを、要求エンティティに提供することとを含み得る。

いくつかの実施形態では（たとえば、第３のリソース量が確保リソース量より多い、または確保リソース量が再オーダー閾値に達する、もしくはそれ以下になる場合）、第２の課金ノードに、共有リソースプランからの追加のデータを確保する第２のリソース確保要求を要求すること。

いくつかの実施形態では、通信ネットワークリソース割当て要求は、ＤｉａｍｅｔｅｒメッセージまたはＤｉａｍｅｔｅｒ ＣＣＲを含み得る。たとえば、ＰＧＷ１０８は、通信ネットワークリソース割当てを要求するＲＳＵ ＡＶＰを含むＣＣＲ－Ｉメッセージを、ＯＣＳノード２０２に送信してもよい。別の例では、Ｄｉａｍｅｔｅｒクライアント１９９（たとえば、ＰＣＥＦ）は、ＲＳＵ ＡＶＰを含むＣＣＲ－ＵメッセージをＯＣＳノード２００に送信してもよい。

いくつかの実施形態では、プロセス４００における要求エンティティは、ＰＧＷ１０８、Ｄｉａｍｅｔｅｒネットワーク要素、ＰＣＥＦ、ＢＢＥＲＦ、ＴＤＦ、またはＤＰＩ機能を含み得る。

いくつかの実施形態では、第１の課金ノードおよび第２の課金ノードは、分散型ＯＣＳ、たとえば、ＯＣＳクラスタ１０６に関連付けられてもよい。

図４は例示のためのものであり、異なるおよび／もしくは追加のステップならびに／または動作が使用されてもよいことが理解されるであろう。また、本明細書に記載のさまざまなステップおよび／または動作は、異なる順序またはシーケンスで発生してもよいことも理解されるであろう。

なお、課金ノード、ＯＣＳクラスタ１０６、ＯＣＳノード２００、ＯＣＳノード２０２、ＯＣＳノード２０４、ＱＭＥ２０６、および／または本明細書に記載の機能は、特殊目的のコンピューティングデバイスを構成し得る。さらに、課金ノード、ＯＣＳクラスタ１０６、ＯＣＳノード２００、ＯＣＳノード２０２、ＯＣＳノード２０４、ＱＭＥ２０６、および／または本明細書に記載の機能は、通信ネットワーク、ＯＣＳアーキテクチャ、およびリソース共有の技術分野を向上させることが可能である。たとえば、ロックフリー通信ネットワークリソース割当て共有を利用することによって、リソース共有および関連する課金に関連するレイテンシおよび性能の問題を緩和または防止することができる。さらに、ロックを必要とせず、関連するロックオーバーヘッドが回避されるので、ロックフリー通信ネットワークリソース割当て共有を利用する分散型ＯＣＳクラスタは、共有リソースプランの異なるメンバーが分散型ＯＣＳクラスタの異なるノードによって処理されるシナリオに関わる複雑さを低減することが可能である。

本明細書に記載の主題のさまざまな詳細事項は本明細書に記載の主題の範囲を逸脱することなく変更可能であることが、理解されるであろう。さらに、前述の記載は制限を目的としているのではなく、説明を目的としているにすぎない。

Claims (20)

1. ロックフリー通信ネットワークリソース割当て共有のための、コンピュータによって実現される方法であって、
   第１の課金ノードが、共有リソースプランの第１のメンバーと関連付けられた通信ネットワークリソース割当て要求に対応するためのものであり、第２の課金ノードが、前記共有リソースプランと関連付けられたリソース確保を管理する前記共有リソースプランの第１のメンバーと関連付けられている、複数の課金ノードを含む分散型課金システムの前記第１の課金ノードにおいて、前記方法は、
   前記共有リソースプランからの第１のリソース量を要求する第１の通信ネットワークリソース割当て要求を、要求エンティティから受信することと、
   前記共有リソースプランが前記第１のリソース量を割当てるのに利用可能な十分なリソースを有することを確認することなしに、前記第１のメンバーの第１の通信ネットワークリソース割当てを、前記要求エンティティに提供することとを備え、前記第１の通信ネットワークリソース割当ては、前記第１のリソース量よりも少ない第２のリソース量を示し、かつ／または、前記第１の通信ネットワークリソース割当ては、前記第１の通信ネットワークリソース割当ての有効期限が切れる時を示す有効時間と関連付けられており、前記方法はさらに、
   前記共有リソースプランのリソースを確保する第１のリソース確保要求を、前記第２の課金ノードに送信することを備える、方法。
2. 前記第１のメンバーに前記第１の通信ネットワークリソース割当てが割当てられるのと同時に、第３の通信ネットワークリソース割当てが前記共有リソースプランの第２のメンバーに割当てられる、請求項１に記載のコンピュータによって実現される方法。
3. 前記第１のリソース量は、データ使用量、時間使用量、金額またはクレジット額を含む、請求項１または２に記載のコンピュータによって実現される方法。
4. 前記第１のリソース確保要求は、前記共有リソースプランが利用可能な残りのリソース量よりも多いリソース量を受信するためのものであり、前記第２の課金ノードは、前記共有リソースプランが消費可能なリソースをそれ以上有していないことを示すフラグを設定することによって、前記第１の課金ノードに通知する、かつ／または、前記第１のリソース確保要求で要求される前記リソース量の少なくとも一部を提供する、先行する請求項のいずれか１項に記載のコンピュータによって実現される方法。
5. 前記第１の通信ネットワークリソース割当てを提供する前に、フラグが設定されていないと判断することを備え、前記フラグは、前記共有リソースプランが消費可能なリソースをそれ以上有していないことを示す、先行する請求項のいずれか１項に記載のコンピュータによって実現される方法。
6. 前記第１のリソース確保要求に基づいて、確保リソース量を前記第２の課金ノードから受信することと、
   前記共有リソースプランからの第３のリソース量を要求する第２の通信ネットワークリソース割当て要求を、前記要求エンティティから受信することと、
   前記確保リソース量を使用して、前記第１のメンバーの第２の通信ネットワークリソース割当てを、要求エンティティに提供することとを備える、先行する請求項のいずれか１項に記載のコンピュータによって実現される方法。
7. 前記第２の課金ノードに、前記共有リソースプランの追加リソースを確保する第２のリソース確保要求を要求することを備える、請求項６に記載のコンピュータによって実現される方法。
8. 前記要求エンティティは、Ｄｉａｍｅｔｅｒネットワーク要素、パケットデータネットワークゲートウェイ（ＰＧＷ）、ポリシーおよび課金実施機能（ＰＣＥＦ）、ベアラ結合およびイベント報告機能（ＢＢＥＲＦ）、トラフィック検出機能（ＴＤＦ）、または深層パケット探査（ＤＰＩ）機能を含む、先行する請求項のいずれか１項に記載のコンピュータによって実現される方法。
9. 前記第１の課金ノードおよび前記第２の課金ノードは、オンライン課金システム（ＯＣＳ）ノードであり、前記第１の通信ネットワークリソース割当て要求は、ＤｉａｍｅｔｅｒメッセージまたはＤｉａｍｅｔｅｒクレジット制御要求（ＣＣＲ）を含む、先行する請求項のいずれか１項に記載のコンピュータによって実現される方法。
10. 通信ネットワークリソース割当て共有のためのシステムであって、
    少なくとも１つのプロセッサと、
    メモリと、
    複数の課金ノードを含む分散型課金システムの第１の課金ノードとを備え、前記第１の課金ノードは、前記少なくとも１つのプロセッサと前記メモリとを使用して実装され、前記第１の課金ノードは、共有リソースプランの第１のメンバーと関連付けられた通信ネットワークリソース割当て要求に対応するためのものであり、第２の課金ノードは、前記共有リソースプランと関連付けられたリソース確保を管理し、前記第１の課金ノードは、
    前記共有リソースプランからの第１のリソース量を要求する第１の通信ネットワークリソース割当て要求を、要求エンティティから受信し、
    前記共有リソースプランが前記第１のリソース量を割当てるのに利用可能な十分なリソースを有することを確認することなしに、前記第１のメンバーの第１の通信ネットワークリソース割当てを、前記要求エンティティに提供するために構成され、前記第１の通信ネットワークリソース割当ては、前記第１のリソース量よりも少ない第２のリソース量を示し、かつ／または、前記第１の通信ネットワークリソース割当ては、前記第１の通信ネットワークリソース割当ての有効期限が切れる時を示す有効時間と関連付けられており、前記第１の課金ノードはさらに、
    前記共有リソースプランのリソースを確保する第１のリソース確保要求を、前記第２の課金ノードに送信するために構成される、システム。
11. 前記第１のメンバーに前記第１の通信ネットワークリソース割当てが割当てられるのと同時に、前記共有リソースプランの第２のメンバーに第３の通信ネットワークリソース割当てが割当てられる、請求項１０に記載のシステム。
12. 前記第１のリソース量は、データ使用量、時間使用量、金額またはクレジット額を含む、請求項１０または１１に記載のシステム。
13. 前記第１のリソース確保要求は、前記共有リソースプランが利用可能な残りのリソース量よりも多いリソース量を確保するためのものであり、前記第２の課金ノードは、前記共有リソースプランが消費可能なリソースをそれ以上有していないことを示すフラグを設定することによって、前記第１の課金ノードに通知する、かつ／または、前記第１のリソース確保要求で要求される前記リソース量の少なくとも一部を提供する、請求項１０～１２のいずれか１項に記載のシステム。
14. 前記第１の課金ノードは、前記第１の通信ネットワークリソース割当てを提供する前に、フラグが設定されていないと判断するために構成され、前記フラグは、前記共有リソースプランが消費可能なリソースをそれ以上有していないことを示す、請求項１０～１３のいずれか１項に記載のシステム。
15. 前記第１の課金ノードは、
    前記第１のリソース確保要求に基づいて確保リソース量を、前記第２の課金ノードから受信し、
    前記共有リソースプランからの第３のリソース量を要求する第２の通信ネットワークリソース割当て要求を、前記要求エンティティから受信し、
    前記確保リソース量を使用して、前記第１のメンバーの第２の通信ネットワークリソース割当てを、前記要求エンティティに提供するために構成される、請求項１０～１４のいずれか１項に記載のシステム。
16. 前記第１の課金ノードは、前記第２の課金ノードに、前記共有リソースプランの追加リソースを確保する第２のリソース確保要求を要求するために構成される、請求項１５に記載のシステム。
17. 前記要求エンティティは、Ｄｉａｍｅｔｅｒネットワーク要素、パケットデータネットワークゲートウェイ（ＰＧＷ）、ポリシーおよび課金実施機能（ＰＣＥＦ）、ベアラ結合およびイベント報告機能（ＢＢＥＲＦ）、トラフィック検出機能（ＴＤＦ）、または深層パケット探査（ＤＰＩ）機能を含む、請求項１０～１６のいずれか１項に記載のシステム。
18. 前記第１の課金ノードおよび前記第２の課金ノードは、オンライン課金システム（ＯＣＳ）ノードであり、前記第１の通信ネットワークリソース割当て要求は、ＤｉａｍｅｔｅｒメッセージまたはＤｉａｍｅｔｅｒクレジット制御要求（ＣＣＲ）を含む、請求項１０～１７のいずれか１項に記載のシステム。
19. コンピュータの少なくとも１つのプロセッサによって実行されると、前記コンピュータにステップを実行させる実行可能な命令を格納した非一時的なコンピュータ読取可能媒体であって、
    第１の課金ノードが、共有リソースプランの第１のメンバーと関連付けられた通信ネットワークリソース割当て要求に対応するためのものであり、かつ、第２の課金ノードが、前記共有リソースプランと関連付けられたリソース確保を管理する前記共有リソースプランの第１のメンバーと関連付けられている、複数の課金ノードを含む分散型課金システムの前記第１の課金ノードにおいて、前記ステップは、
    前記共有リソースプランからの第１のリソース量を要求する第１の通信ネットワークリソース割当て要求を、要求エンティティから受信することと、
    前記共有リソースプランが前記第１のリソース量を割当てるのに利用可能な十分なリソースを有することを確認することなしに、前記第１のメンバーの第１の通信ネットワークリソース割当てを、前記要求エンティティに提供することとを含み、前記第１の通信ネットワークリソース割当ては、前記第１のリソース量よりも少ない第２のリソース量を示し、かつ／または、前記第１の通信ネットワークリソース割当ては、前記第１の通信ネットワークリソース割当ての有効期限が切れる時を示す有効時間と関連付けられており、前記ステップはさらに、
    前記共有リソースプランのリソースを確保する第１のリソース確保要求を、前記第２の課金ノードに送信することを含む、非一時的なコンピュータ読取可能媒体。
20. 前記第１のメンバーに前記第１の通信ネットワークリソース割当てが割当てられるのと同時に、前記共有リソースプランの第２のメンバーに第３の通信ネットワークリソース割当てが割当てられる、請求項１９に記載の非一時的なコンピュータ読取可能媒体。

Images