IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ オラクル・インターナショナル・コーポレイションの特許一覧

特表2023-503889ロックフリー通信ネットワークリソース割当て共有のための方法、システムおよびコンピュータ読取可能媒体
<>
  • 特表-ロックフリー通信ネットワークリソース割当て共有のための方法、システムおよびコンピュータ読取可能媒体 図1
  • 特表-ロックフリー通信ネットワークリソース割当て共有のための方法、システムおよびコンピュータ読取可能媒体 図2
  • 特表-ロックフリー通信ネットワークリソース割当て共有のための方法、システムおよびコンピュータ読取可能媒体 図3A
  • 特表-ロックフリー通信ネットワークリソース割当て共有のための方法、システムおよびコンピュータ読取可能媒体 図3B
  • 特表-ロックフリー通信ネットワークリソース割当て共有のための方法、システムおよびコンピュータ読取可能媒体 図4
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2023-02-01
(54)【発明の名称】ロックフリー通信ネットワークリソース割当て共有のための方法、システムおよびコンピュータ読取可能媒体
(51)【国際特許分類】
   H04M 15/00 20060101AFI20230125BHJP
   H04M 11/00 20060101ALI20230125BHJP
【FI】
H04M15/00 G
H04M11/00 302
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2022529372
(86)(22)【出願日】2020-10-28
(85)【翻訳文提出日】2022-07-12
(86)【国際出願番号】 US2020057718
(87)【国際公開番号】W WO2021101685
(87)【国際公開日】2021-05-27
(31)【優先権主張番号】16/690,058
(32)【優先日】2019-11-20
(33)【優先権主張国・地域又は機関】US
(81)【指定国・地域】
(71)【出願人】
【識別番号】502303739
【氏名又は名称】オラクル・インターナショナル・コーポレイション
(74)【代理人】
【識別番号】110001195
【氏名又は名称】弁理士法人深見特許事務所
(72)【発明者】
【氏名】デイ,デブドゥラル
【テーマコード(参考)】
5K201
【Fターム(参考)】
5K201BD02
5K201CB12
5K201CC07
5K201EC06
5K201ED05
5K201FA07
5K201FB01
(57)【要約】
ロックフリー通信ネットワークリソース割当て共有のための方法の例が、複数の課金ノードを含む分散型課金システムの第1の課金ノードで行われる。方法の例は、共有リソースプランからの第1のリソース量を要求する第1の通信ネットワークリソース割当て要求を、要求エンティティから受信することと、共有リソースプランが第1のリソース量を割当てるのに利用可能な十分なリソースを有することを確認することなしに、第1のメンバーの第1の通信ネットワークリソース割当てを要求エンティティに提供することとを備え、第1の通信ネットワークリソース割当ては、第1のリソース量よりも少ない第2のリソース量を示し、かつ/または、第1の通信ネットワークリソース割当ては、第1の通信ネットワークリソース割当ての有効期限が切れる時を示す有効時間と関連付けられており、方法の例はさらに、共有リソースプランのリソースを確保する第1のリソース確保要求を、第2の課金ノードに送信することを備える。
【特許請求の範囲】
【請求項1】
ロックフリー通信ネットワークリソース割当て共有のための、コンピュータによって実現される方法であって、
第1の課金ノードが、共有リソースプランの第1のメンバーと関連付けられた通信ネットワークリソース割当て要求に対応するためのものであり、第2の課金ノードが、前記共有リソースプランと関連付けられたリソース確保を管理する前記共有リソースプランの第1のメンバーと関連付けられている、複数の課金ノードを含む分散型課金システムの前記第1の課金ノードにおいて、前記方法は、
前記共有リソースプランからの第1のリソース量を要求する第1の通信ネットワークリソース割当て要求を、要求エンティティから受信することと、
前記共有リソースプランが前記第1のリソース量を割当てるのに利用可能な十分なリソースを有することを確認することなしに、前記第1のメンバーの第1の通信ネットワークリソース割当てを、前記要求エンティティに提供することとを備え、前記第1の通信ネットワークリソース割当ては、前記第1のリソース量よりも少ない第2のリソース量を示し、かつ/または、前記第1の通信ネットワークリソース割当ては、前記第1の通信ネットワークリソース割当ての有効期限が切れる時を示す有効時間と関連付けられており、前記方法はさらに、
前記共有リソースプランのリソースを確保する第1のリソース確保要求を、前記第2の課金ノードに送信することを備える、方法。
【請求項2】
前記第1のメンバーに前記第1の通信ネットワークリソース割当てが割当てられるのと同時に、第3の通信ネットワークリソース割当てが前記共有リソースプランの第2のメンバーに割当てられる、請求項1に記載のコンピュータによって実現される方法。
【請求項3】
前記第1のリソース量は、データ使用量、時間使用量、金額またはクレジット額を含む、請求項1または2に記載のコンピュータによって実現される方法。
【請求項4】
前記第1のリソース確保要求は、前記共有リソースプランが利用可能な残りのリソース量よりも多いリソース量を受信するためのものであり、前記第2の課金ノードは、前記共有リソースプランが消費可能なリソースをそれ以上有していないことを示すフラグを設定することによって、前記第1の課金ノードに通知する、かつ/または、前記第1のリソース確保要求で要求される前記リソース量の少なくとも一部を提供する、先行する請求項のいずれか1項に記載のコンピュータによって実現される方法。
【請求項5】
前記第1の通信ネットワークリソース割当てを提供する前に、フラグが設定されていないと判断することを備え、前記フラグは、前記共有リソースプランが消費可能なリソースをそれ以上有していないことを示す、先行する請求項のいずれか1項に記載のコンピュータによって実現される方法。
【請求項6】
前記第1のリソース確保要求に基づいて、確保リソース量を前記第2の課金ノードから受信することと、
前記共有リソースプランからの第3のリソース量を要求する第2の通信ネットワークリソース割当て要求を、前記要求エンティティから受信することと、
前記確保リソース量を使用して、前記第1のメンバーの第2の通信ネットワークリソース割当てを、要求エンティティに提供することとを備える、先行する請求項のいずれか1項に記載のコンピュータによって実現される方法。
【請求項7】
前記第2の課金ノードに、前記共有リソースプランの追加リソースを確保する第2のリソース確保要求を要求することを備える、請求項6に記載のコンピュータによって実現される方法。
【請求項8】
前記要求エンティティは、Diameterネットワーク要素、パケットデータネットワークゲートウェイ(PGW)、ポリシーおよび課金実施機能(PCEF)、ベアラ結合およびイベント報告機能(BBERF)、トラフィック検出機能(TDF)、または深層パケット探査(DPI)機能を含む、先行する請求項のいずれか1項に記載のコンピュータによって実現される方法。
【請求項9】
前記第1の課金ノードおよび前記第2の課金ノードは、オンライン課金システム(OCS)ノードであり、前記第1の通信ネットワークリソース割当て要求は、DiameterメッセージまたはDiameterクレジット制御要求(CCR)を含む、先行する請求項のいずれか1項に記載のコンピュータによって実現される方法。
【請求項10】
通信ネットワークリソース割当て共有のためのシステムであって、
少なくとも1つのプロセッサと、
メモリと、
複数の課金ノードを含む分散型課金システムの第1の課金ノードとを備え、前記第1の課金ノードは、前記少なくとも1つのプロセッサと前記メモリとを使用して実装され、前記第1の課金ノードは、共有リソースプランの第1のメンバーと関連付けられた通信ネットワークリソース割当て要求に対応するためのものであり、第2の課金ノードは、前記共有リソースプランと関連付けられたリソース確保を管理し、前記第1の課金ノードは、
前記共有リソースプランからの第1のリソース量を要求する第1の通信ネットワークリソース割当て要求を、要求エンティティから受信し、
前記共有リソースプランが前記第1のリソース量を割当てるのに利用可能な十分なリソースを有することを確認することなしに、前記第1のメンバーの第1の通信ネットワークリソース割当てを、前記要求エンティティに提供するために構成され、前記第1の通信ネットワークリソース割当ては、前記第1のリソース量よりも少ない第2のリソース量を示し、かつ/または、前記第1の通信ネットワークリソース割当ては、前記第1の通信ネットワークリソース割当ての有効期限が切れる時を示す有効時間と関連付けられており、前記第1の課金ノードはさらに、
前記共有リソースプランのリソースを確保する第1のリソース確保要求を、前記第2の課金ノードに送信するために構成される、システム。
【請求項11】
前記第1のメンバーに前記第1の通信ネットワークリソース割当てが割当てられるのと同時に、前記共有リソースプランの第2のメンバーに第3の通信ネットワークリソース割当てが割当てられる、請求項10に記載のシステム。
【請求項12】
前記第1のリソース量は、データ使用量、時間使用量、金額またはクレジット額を含む、請求項10または11に記載のシステム。
【請求項13】
前記第1のリソース確保要求は、前記共有リソースプランが利用可能な残りのリソース量よりも多いリソース量を確保するためのものであり、前記第2の課金ノードは、前記共有リソースプランが消費可能なリソースをそれ以上有していないことを示すフラグを設定することによって、前記第1の課金ノードに通知する、かつ/または、前記第1のリソース確保要求で要求される前記リソース量の少なくとも一部を提供する、請求項10~12のいずれか1項に記載のシステム。
【請求項14】
前記第1の課金ノードは、前記第1の通信ネットワークリソース割当てを提供する前に、フラグが設定されていないと判断するために構成され、前記フラグは、前記共有リソースプランが消費可能なリソースをそれ以上有していないことを示す、請求項10~13のいずれか1項に記載のシステム。
【請求項15】
前記第1の課金ノードは、
前記第1のリソース確保要求に基づいて確保リソース量を、前記第2の課金ノードから受信し、
前記共有リソースプランからの第3のリソース量を要求する第2の通信ネットワークリソース割当て要求を、前記要求エンティティから受信し、
前記確保リソース量を使用して、前記第1のメンバーの第2の通信ネットワークリソース割当てを、前記要求エンティティに提供するために構成される、請求項10~14のいずれか1項に記載のシステム。
【請求項16】
前記第1の課金ノードは、前記第2の課金ノードに、前記共有リソースプランの追加リソースを確保する第2のリソース確保要求を要求するために構成される、請求項15に記載のシステム。
【請求項17】
前記要求エンティティは、Diameterネットワーク要素、パケットデータネットワークゲートウェイ(PGW)、ポリシーおよび課金実施機能(PCEF)、ベアラ結合およびイベント報告機能(BBERF)、トラフィック検出機能(TDF)、または深層パケット探査(DPI)機能を含む、請求項10~16のいずれか1項に記載のシステム。
【請求項18】
前記第1の課金ノードおよび前記第2の課金ノードは、オンライン課金システム(OCS)ノードであり、前記第1の通信ネットワークリソース割当て要求は、DiameterメッセージまたはDiameterクレジット制御要求(CCR)を含む、請求項10~17のいずれか1項に記載のシステム。
【請求項19】
コンピュータの少なくとも1つのプロセッサによって実行されると、前記コンピュータにステップを実行させる実行可能な命令を格納した非一時的なコンピュータ読取可能媒体であって、
第1の課金ノードが、共有リソースプランの第1のメンバーと関連付けられた通信ネットワークリソース割当て要求に対応するためのものであり、かつ、第2の課金ノードが、前記共有リソースプランと関連付けられたリソース確保を管理する前記共有リソースプランの第1のメンバーと関連付けられている、複数の課金ノードを含む分散型課金システムの前記第1の課金ノードにおいて、前記ステップは、
前記共有リソースプランからの第1のリソース量を要求する第1の通信ネットワークリソース割当て要求を、要求エンティティから受信することと、
前記共有リソースプランが前記第1のリソース量を割当てるのに利用可能な十分なリソースを有することを確認することなしに、前記第1のメンバーの第1の通信ネットワークリソース割当てを、前記要求エンティティに提供することとを含み、前記第1の通信ネットワークリソース割当ては、前記第1のリソース量よりも少ない第2のリソース量を示し、かつ/または、前記第1の通信ネットワークリソース割当ては、前記第1の通信ネットワークリソース割当ての有効期限が切れる時を示す有効時間と関連付けられており、前記ステップはさらに、
前記共有リソースプランのリソースを確保する第1のリソース確保要求を、前記第2の課金ノードに送信することを含む、非一時的なコンピュータ読取可能媒体。
【請求項20】
前記第1のメンバーに前記第1の通信ネットワークリソース割当てが割当てられるのと同時に、前記共有リソースプランの第2のメンバーに第3の通信ネットワークリソース割当てが割当てられる、請求項19に記載の非一時的なコンピュータ読取可能媒体。
【発明の詳細な説明】
【技術分野】
【0001】
優先権主張
本願は、2019年11月20日に出願された米国特許出願継続番号第16/690,058号に基づく利益を主張し、その開示全体を本明細書に引用により援用する。
【0002】
技術分野
本明細書に記載の主題は、通信ネットワークに関する。特に、本明細書に記載の主題は、ロックフリー通信ネットワークリソース割当て共有のための方法、システムおよびコンピュータ読取可能媒体に関する。
【背景技術】
【0003】
背景
通信ネットワークサービスプロバイダは、モバイルデバイスの加入者に、多様な異なるネットワークサービスを提供することができる。サービスプロバイダによって提供されるリソースプランは、通常、異なる性能カテゴリとさまざまなリソース量との組合せによって特徴付けられる。たとえば、加入者は、所与の帯域幅速度、所与のリソース量のダウンロードサイズリソース割当て、および/または特定のサービス品質(quality of service:QoS)レベルのリソースプラン(たとえば、モバイルデータプランまたは加入プラン)に対して月額料金を支払う。同様に、別の加入者は、より低い帯域幅速度、より少ないリソース割当て配分、および/またはより低いQoSレベルの異なるリソースプランに加入することが可能である。
【0004】
加入者がリソースプラン(たとえば、データプランまたはクレジットプラン)を共有する場合がある。たとえば、家族共有データプランでは、(たとえば、夫、妻、およびその子供の)複数のユーザデバイスが、1ヶ月ごとに高速データ割当て(20ギガバイト)を共有することができる。この例では、ほとんどのデータプランと同様に、サービスプロバイダは、共有データが消費されると、加入者のサービスを停止するのが一般的である。別の例では、家族共有プランは、1人以上のメンバーが費やした料金の一部を共有することを含む場合がある。たとえば、家族共有プランは、最高額(たとえば、プランのクレジット限度額)を上限として、子供メンバーの料金の20%を支払うことができる。
【0005】
共有リソースプランのメンバーによるリソースの過剰消費を防ぐ方法として考えられるある方法では、プランのあるメンバーがリソース割当て要求を行うと、共有リソースプランにロックを使用することが含まれる。ロックを使用すると、データの過剰消費を防ぐことができる(かつ、サービスプロバイダの収益が影響を受けるのを軽減することができる)が、そのような解決策は、ネットワークにおけるレイテンシおよび性能に影響を与える可能性がある。オンライン課金システム(online charging system:OCS)が分散型アーキテクチャを利用し、一部のOCSノードが異なるリソースプランに対応する、および/または一部のOCSノードが同じ共有リソースプランの異なるメンバーのリソース割当て要求に対応する場合、さらに他の問題が生じる可能性がある。
【0006】
したがって、ロックフリー通信ネットワークリソース割当て共有のための方法、システムおよびコンピュータ読取可能媒体が必要である。
【発明の概要】
【課題を解決するための手段】
【0007】
概要
ロックフリー通信ネットワークリソース割当て共有のための方法、システム、およびコンピュータ読取可能媒体が開示される。いくつかの実施形態では、方法の例は、複数の課金ノードを含む分散型課金システムの第1の課金ノードにおいて行われ、第1の課金ノードは、共有リソースプランの第1のメンバーと関連付けられた通信ネットワークリソース割当て要求に対応するためのものであり、第2の課金ノードが、共有リソースプランと関連付けられたリソース確保を管理する。方法の例は、共有リソースプランからの第1のリソース量を要求する第1の通信ネットワークリソース割当て要求を、要求エンティティから受信することと、共有リソースプランが第1のリソース量を割当てるのに利用可能な十分なリソースを有することを確認することなしに、第1のメンバーの第1の通信ネットワークリソース割当てを、要求エンティティに提供することとを備え、第1の通信ネットワークリソース割当ては、第1のリソース量よりも少ない第2のリソース量を示し、かつ/または、第1の通信ネットワークリソース割当ては、第1の通信ネットワークリソース割当ての有効期限が切れる時を示す有効時間と関連付けられており、方法の例はさらに、共有リソースプランのリソースを確保する第1のリソース確保要求を、第2の課金ノードに送信することを備える。
【0008】
いくつかの実施形態では、システムの例は、複数の課金ノードを含む分散型課金システムの第1の課金ノードを備える。第1の課金ノードは、少なくとも1つのプロセッサとメモリとを使用して実装される。第1の課金ノードは、共有リソースプランの第1のメンバーと関連付けられた通信ネットワークリソース割当て要求に対応するためのものであり、第2の課金ノードが、共有リソースプランと関連付けられたリソース確保を管理する。第1の課金ノードは、共有リソースプランからの第1のリソース量を要求する第1の通信ネットワークリソース割当て要求を、要求エンティティから受信し、共有リソースプランが第1のリソース量を割当てるのに利用可能な十分なリソースを有することを確認することなしに、第1のメンバーの第1の通信ネットワークリソース割当てを、要求エンティティに提供するために構成され、第1の通信ネットワークリソース割当ては、第1のリソース量よりも少ない第2のリソース量を示し、かつ/または、第1の通信ネットワークリソース割当ては、第1の通信ネットワークリソース割当ての有効期限が切れる時を示す有効時間と関連付けられており、第1の課金ノードはさらに、共有リソースプランのリソースを確保する第1のリソース確保要求を、第2の課金ノードに送信するために構成される。
【0009】
本明細書に記載の主題は、ハードウェアおよび/またはファームウェアと組合せてソフトウェアで実装され得る。たとえば、本明細書に記載の主題は、プロセッサによって実行されるソフトウェアで実装され得る。実装の一例では、本明細書に記載の主題は、コンピュータのプロセッサによって実行されると、ステップを実行するようにコンピュータを制御するコンピュータ実行可能命令を格納したコンピュータ読取可能媒体を使用して実装され得る。実行されるステップは、本発明に関連して本明細書に記載のステップのうちの任意の1つ以上に対応することができる。本明細書に記載の主題を実現するのに適したコンピュータ読取可能媒体の例は、ディスクメモリデバイス、チップメモリデバイス、プログラマブルロジックデバイス、および特定用途向け集積回路などの非一時的なデバイスを含む。さらに、本明細書に記載の主題を実現するコンピュータ読取可能媒体は、単一のデバイスもしくはコンピューティングプラットフォーム上に配置されてもよい、または、複数のデバイスもしくはコンピューティングプラットフォームにわたって分散されてもよい。
【0010】
本明細書で使用する場合、「ノード」という用語は、1つ以上のプロセッサとメモリとを含む少なくとも1つの物理的なコンピューティングプラットフォームを指す。
【0011】
本明細書で使用する場合、「機能」または「モジュール」という用語は、本明細書に記載の機能を実装するためのハードウェアおよび/またはファームウェアと組合せたソフトウェアを指す。
【0012】
本明細書に記載の主題を、添付の図面を参照して以下で説明する。
【図面の簡単な説明】
【0013】
図1】ロックフリー通信ネットワークリソース割当て共有のための通信環境の例を示すブロック図である。
図2】ロックフリー通信ネットワークリソース割当て共有のためのオンライン課金システム(OCS)クラスタの例を示すブロック図である。
図3A】ロックフリー通信ネットワークリソース割当て共有に関連付けられたメッセージの例を示すメッセージフロー図である。
図3B】ロックフリー通信ネットワークリソース割当て共有に関連付けられたメッセージの例を示すメッセージフロー図である。
図4】ロックフリー通信ネットワークリソース割当て共有の処理例を示すフロー図である。
【発明を実施するための形態】
【0014】
詳細な説明
本明細書に記載の主題は、ロックフリー(ロックレス)通信ネットワークリソース割当て共有のための方法、システムおよびコンピュータ読取可能媒体に関する。共有リソースプランは、さまざまな通信ネットワークの加入者が利用可能である。たとえば、携帯電話サービスプロバイダは、家族共有プランを販売しており、これらのプランでは、多数の家族メンバー(またはそのユーザデバイス)が、プランの総量(たとえば、毎月の割当て量)から時間またはデータを共有することができる。別の例では、家族共有課金プランは、家族メンバーがクレジットまたは課金を共有することを可能にし、たとえば、課金の少なくとも一部が共有クレジットまたは金銭の割当てによって支払われる場合がある。
【0015】
ロックベースの課金アーキテクチャは、プランの子メンバーがリソースを要求すると、プランまたは関連する親アカウントをロックすることによって、共有リソースプランに対応して、並行または同時のイベント(たとえば、共有リソースプランの他のメンバーに関連付けられている)がプランまたは親アカウントからリソースを(過剰)消費できないようにすることができる。プランまたは親アカウントをロックすることで、過剰消費の可能性によって収益が影響を受けるのが防止されるが、このようなロックは、システムのレイテンシおよび性能に大きな影響を与える可能性がある。さらに、オンライン課金システム(OCS)が、一部のOCSノードが同じ共有リソースプランの異なるメンバーに対応する分散型アーキテクチャを利用する場合、ロックベースの課金アーキテクチャを使用してリソース割当て共有を達成するために、複雑性がさらに必要になる場合がある。
【0016】
本明細書に記載の主題のいくつかの態様によると、ロックフリー通信ネットワークリソース割当て共有のための技術、方法、システムまたは機構が開示される。いくつかの実施形態では、ロックフリー通信ネットワークリソース割当て共有は、親アカウントをロックすることなく共有リソースプランのメンバーをランク付けする(たとえば、メンバーが使用するためのリソース割当てを提供する)ために利用可能である。たとえば、本明細書に記載の少なくともいくつかの態様に係る課金ノード(たとえば、OCSノード)または関連モジュールが、共有リソースプラン(たとえば、家族データ共有プラン)のメンバーに関連するリソース割当て要求を受信し、これに応答して、共有リソースプランをロックせずに、および/またはリソース割当て要求を完全に認可するために共有リソースプランの十分なリソースを確保する前に(たとえば、別のOCSノード経由で)少ないリソース割当て(たとえば、5メガバイト(MB)のデータ)を提供することができる。この例では、要求エンティティ(たとえば、パケットゲートウェイ)は、加入者が、たとえば、加入者データセッション中に、初期リソース割当てを消費することを可能にしてもよい。初期リソース割当てが消費されている間、課金ノードは、加入者が使用するための追加リソースを確保するために、別の課金ノードに問合せることができる。この例を続けると、要求エンティティが追加リソース割当てを要求する時間までに、課金ノードは、この後続のリソース割当て要求を完全に認可するのに十分なリソースを確保している可能性がある。または、課金ノードが、加入者が消費される残りのリソースを有していないと判断した場合(たとえば、共有リソースアカウントを管理する別の課金ノードと通信することによって)、課金ノードは、後続のリソース割当て要求を拒否して、収益の潜在的損失を最初の少ないリソース割当てに限定することができる。
【0017】
本明細書に記載の主題のいくつかの態様によると、ロックフリー通信ネットワークリソース割当て共有アルゴリズムまたは関連する実装は、分散型OCS(たとえば、OCSクラスタ)の複数の課金ノード(たとえば、OCSノード)上で実装されてもよい。たとえば、アルゴリズムは、最小割当て(たとえば、比較的小さくてもよい所定量のリソース)および/または有効時間(たとえば、リソース割当ての有効期限が切れる時を示す時間)を提供することによって、分散型OCSの課金ノードにイベントに反応するように指示してもよく、課金ノードに親(たとえば、関連の共有リソースプランに対するリソース確保および/または割当てに対応する課金ノード)からリソースを確保するように指示してもよく、課金ノードに、共有リソースプランからそれ以上のリソースを利用可能でない場合を除いて、最小割当てまたは所定の値を確保するように指示してもよい。
【0018】
有利なことに、ロックフリー通信ネットワークリソース割当て共有を利用することにより、リソース共有および関連のある課金に関連するレイテンシならびに性能の問題を、緩和または防止することができる。さらに、ネットワークを介したおよびリクエストのインラインでの同期ロックを必要とせず、関連するロックオーバーヘッドが回避されるので、ロックフリー通信ネットワークリソース割当て共有を利用する分散型OCSクラスタは、分散型OCSクラスタの異なるノードが共有リソースプランの異なるメンバーに対応するシナリオに関わる複雑さを低減することが可能である。
【0019】
本明細書に記載の主題のさまざまな実施形態について以下で詳細に参照し、その例を添付の図面に示す。可能な限り、同一または類似の部品を参照するために、同じ参照番号が図面全体にわたって使用される。
【0020】
図1は、ロックフリー通信ネットワークリソース割当て共有のための通信環境100の例を示すブロック図である。通信環境100は、さまざまなデータ、アプリケーション、および/またはサービス、たとえば、電話、インターネット、テキストメッセージなどを提供するための1つ以上の通信ネットワークを表すことができる。
【0021】
図1を参照すると、通信環境100は、ポリシーサーバ102、加入者プロファイルリポジトリ(subscriber profile repository:SPR)104、オンライン課金システム(OCS)クラスタ106、およびパケットデータネットワーク(packet data network:PDN)ゲートウェイ(PGW)108、および請求システム110を含み得る。通信環境100は、加入者に関連付けられたユーザ機器(user equipment:UE)デバイス112にPGW108を通信可能に接続するアクセスネットワーク116を含み得る。UEデバイス112は、アクセスネットワーク116を介して通信環境100内のさまざまなネットワークノードに接続可能なコンピュータもしくはデバイス(たとえば、モバイルスマートフォン、タブレットコンピュータデバイス、パーソナルデジタルアシスタント(PDA)等)を表してもよい、および/または(たとえば、PGW108を介した)インターネットへの接続、もしくは通信環境100を使用したサービスもしくはデータの受信が可能でもよい。
【0022】
OCSクラスタ106は、1つ以上のOCSノードを含む分散型OCSを表してもよい。OCSクラスタ106またはそのノード(複数可)は、1つ以上の課金機能を実行するための任意の適切な1つまたは複数のエンティティ(たとえば、少なくとも1つのプロセッサ上で実行される1つ以上のコンピューティングプラットフォームまたはソフトウェア)でもよい。たとえば、OCSクラスタ106の一部のノードは、異なる加入者のためのリソース割当て要求の加工または対応を行ってもよい。この例では、OCSクラスタ106の一部のノードは、同じ共有リソースプラン、たとえば、家族データ共有プランの加入者からのリソース割当て要求に対応してもよい。
【0023】
いくつかの実施形態では、共有リソースプランは、メンバー(たとえば、モバイルネットワーク加入者)がプランの総リソース量(たとえば、総月間割当て量)から通信ネットワーク関連リソースを共有または使用することを可能にする場合がある。たとえば、共有リソースは、データ量(たとえば、5ギガバイト(GB))、時間(たとえば、100分のインターネットサービス)、またはクレジット額(たとえば、200ドル)を含む場合がある。
【0024】
いくつかの実施形態では、OCSクラスタ106またはそのノード(複数可)は、PGW108および/または別のエンティティから加入者利用データ(たとえば、UE112によって生成または受信されたトラフィックおよびシグナリングデータ)を受信してもよい。OCSクラスタ106またはそのノード(複数可)は、PGW108から受信したさまざまな加入者の加入者利用データを記録および格納するために、加入者利用データベースを維持するように構成されてもよい。いくつかの実施形態では、OCSクラスタ106またはそのノード(複数可)は、使用量データベースを利用して、加入者ごとの特定のデータ使用量(たとえば、割当てバケット単位で)を区別し、追跡するように構成されてもよい。
【0025】
いくつかの実施形態では、OCSクラスタ106またはそのノード(複数可)は、ロックフリー通信ネットワークリソース割当て共有アルゴリズムまたは本明細書に記載のさまざまな態様を利用するための機能(たとえば、1つ以上のモジュール)を含み得る。たとえば、QME206は、共有リソースプラン(たとえば、家族データ共有プラン)のメンバーに関連するリソース割当て要求を受信し、これに応答して、共有リソースプランをロックすることなく、および/または、共有リソースプランのリソースの割当ておよび/もしくは確保を管理する別のOCSノード(たとえば、OCSノード204)を介して共有リソースプランの十分なリソースを確保する前に、少なくとも最小リソース割当てを提供するために構成されてもよい。
【0026】
PGW108は、アクセスネットワーク116を介してUE112からパケット通信を受信するとともに、UE112に関連する利用状況を(たとえば、Gyインターフェイスを介して)OCSクラスタ106またはそのノードに報告するように構成された通信環境100内の任意の適切なエンティティを表してもよい。PGW108はまた、ネットワーク状態データ(たとえば、トラフィック負荷状態)を、ポリシーサーバ102および/またはOCSクラスタ106もしくはそのノード(複数可)に提供するように構成されてもよい。PGW108はまた、ポリシーサーバ102が提供するポリシー規則を実行または実施するように構成されてもよい。いくつかの実施形態では、PGW108は、ポリシーおよび課金実施機能(policy and charging enforcement function:PCEF)、ベアラ結合およびイベント報告機能(bearer binding and event reporting function:BBERF)、ディープパケット検査(deep packet inspection:DPI)機能、トラフィック検出機能(traffic detection function:TDF)、または他の同様のネットワーク要素機能のうちの少なくとも1つをサポートまたはホストするように構成された任意のネットワーク要素を含み得る。
【0027】
いくつかの実施形態では、PGW108は、さまざまな加入者に対してリソース割当てを要求し、実施するように構成されてもよい。たとえば、加入者または関連するUE112がアクセスネットワーク116または通信環境100に接続すると、PGW108は、加入者が使用するためのリソース割当てを要求および受信するために、OCSクラスタ106またはそのノード(複数可)に、リソース割当て要求を送信してもよい。この例では、加入者がその割当てられたリソースを使用すると(たとえば、PGW108におけるリソース割当ての残量が閾値に達する、またはそれを下回ると)、PGW108は、加入者によって使用される追加リソース割当てを要求し受信するために、OCSクラスタ106またはそのノード(複数可)に別のリソース割当て要求を送信してもよい。この例を続けると、加入者がネットワークからログオフする、またはセッションを終了すると、PGW108は、今後の使用のために、OCSクラスタ106またはそのノード(複数可)に戻す任意の残りの割当てを解放または放棄してもよい。
【0028】
請求システム110は、1つ以上の請求および/または課金機能を実行するように構成された通信環境100内の任意の適切なエンティティを表してもよい。いくつかの実施形態では、請求システム110は、請求目的で、および/または加入者が請求書を支払うこともしくは追加リソースを購入することを可能にするためのインターフェイスを提供するために、リソース使用量を計算もしくは集計するように使用されてもよい。たとえば、請求システム110は、加入者が共有リソースプランのための追加リソースを満たす(チャージ)もしくは購入することを可能にするためのユーザインターフェイスまたは他の通信インターフェイスを提供してもよい。この例では、加入者が共有リソースプランのリソースを購入するトランザクションを完了すると、請求システム110は、これらのリソースが、たとえば、共有リソースプランの一人以上のメンバーによって利用可能になるように、OCSクラスタ106またはそのノードに通知してもよい。
【0029】
ポリシーサーバ102は、1つ以上のポリシー機能および/または課金機能を実行するための任意の適切なエンティティを表してもよい。たとえば、ポリシーサーバ102は、通信環境100においてサービスに加入する加入者のためのポリシー規則を決定し、作成するように構成されてもよい。この例では、ポリシーサーバ102は、ポリシーおよび課金制御(policy and charging control:PCC)規則を生成し、これらの規則を1つ以上のネットワーク要素(たとえば、PGW108)に提供してもよい。この例を続けると、ポリシーサーバ102によって作成されたPCC規則は、一人以上の加入者に関連するサービス、QoSレベル、および課金規則に関するものでもよい。いくつかの実施形態では、ポリシーサーバ102は、ポリシーおよび課金規則機能(policy and charging rules function:PCRF)を含み得る、ならびに/またはDiameterベースのネットワーク要素もしくはサーバによって、ホストされ実行されてもよい。
【0030】
いくつかの実施形態では、ポリシーサーバ102または別のエンティティは、OCSクラスタ106またはそのOCSノードから割当て使用情報を要求するように構成されてもよい。割当て使用情報は、OCSクラスタ106またはそのノード(複数可)とのアプリケーションインターフェイス(たとえば、Syインターフェイス)を介して、要求および受信されてもよい。いくつかの実施形態では、ポリシーサーバ102は、Diameterセッション識別子情報、加入者識別子情報(たとえば、IMSI)、加入者ティア情報、加入者サービスタイプ識別子情報、および/または他の情報のうちの少なくとも1つを含み得るDiameter要求メッセージを送信することにより、OCSクラスタ106またはそのノード(複数可)に割当て使用情報を要求してもよい。要求を受信すると、OCSクラスタ106またはそのノード(複数可)は、適切な加入者割当て使用情報を決定するように提供された情報を使用するように構成されてもよく、これは最終的に要求ポリシーサーバ102に返されることがある。
【0031】
SPR104は、通信環境100の加入者に関連するプロファイル情報を格納するように構成されたデータベースを含み得る。たとえば、格納された加入者プロファイルデータは、リソースプランコード(たとえば、請求プランコードまたは名前)およびリソースプランコードに関連付けられたエンタイトルメントを含み得る。例示的なエンタイトルメントには、VoIP(voice over Internet protocol)サービス、ビデオチャット、国内ローミング、国際ローミング、MiFi、データ、ギフト(たとえば、特別キャンペーン)、および特定の機器が含まれるが、これらに限定されない。いくつかの実施形態では、SPR104は、1つ以上のネットワーク要素と統合されてもよい、または複数のコンピューティングプラットフォームもしくはデバイスにわたって分散されてもよい。
【0032】
いくつかの実施形態では、UE112は、ネットワークアタッチメント手順を開始することによって、通信ネットワークにサービスを登録し得る。たとえば、UE112は、ユーザアタッチ要求メッセージをPGW108に送信することができる。アタッチメント要求メッセージの受信に応答して、PGW108は、Diameterクレジット制御要求(credit control request:CCR)メッセージをポリシーサーバ102に送信し得る。次に、ポリシーサーバ102は、ユーザ識別子を含むDiameterユーザデータ要求(UDR)メッセージをSPR104に送信して、加入者に関連付けられたリソースプランコードおよび/またはプランエンタイトルメントを要求してもよい。たとえば、SPR104は、リソースプランデータをローカルプロファイルデータベース114に格納するように構成されてもよい。または、SPR104は、加入者のリソースプラン情報を含む外部データベースに問合せてもよい。
【0033】
図1は説明のためのものであり、図1に関連して上述したさまざまなノードおよび/またはモジュール、位置、および/または機能は、変更、改変、追加、または削除されてもよいことが理解されるであろう。
【0034】
図2は、ロックフリー通信ネットワークリソース割当て共有のためのOCSクラスタ106を示すブロック図である。図2を参照すると、OCSクラスタ106は、1つ以上のOCSノード、たとえば、OCSノード200~204を含み得る。OCSノード200~204の各々は、1つ以上の課金関連機能を実行するための任意の適切なエンティティ(たとえば、計算プラットフォーム、または少なくとも1つのプロセッサ上で実行されるソフトウェア)でもよい。いくつかの実施形態では、OCSノード200~204の各々は、少なくとも1つの加入者からのリソース割当て要求がOCSノード200~204の全てによって対応されない、複数の加入者からのリソース割当て要求の対応を担ってもよい。たとえば、OCSノード200は、第1のモバイル加入者からのリソース割当て要求に対応してもよく、OCSノード202は、第2のモバイル加入者からのリソース割当て要求に対応してもよく、OCSノード200は、第3のモバイル加入者からのリソース割当て要求に対応してもよい。
【0035】
いくつかの実施形態では、異なるOCSノードに関連付けられる加入者は、同じ共有リソースプランのメンバーでもよい。たとえば、共有リソースプランは、家族用のデータ共有プランを表してもよく、OCSノード200および202は、共有リソースプランの子または二次メンバーからの割当て要求に対応し、OCSノード204は、共有リソースプランの親または一次メンバーを管理する。この例では、OCSノード204が共有リソースプランのリソースのリソース確保を管理すると仮定すると、OCSノード200~202の各々は、リソース確保をOCSノード204に送信することができる。
【0036】
OCSノード200~204の各々は、割当て管理エンジン(quota management engine:QME)206およびデータストレージ、たとえば、データストレージ208~212のうちの1つを含み得る。QME206は、リソース割当てまたは割当て関連情報を維持、調整、提供、および/または報告するための任意の適切なエンティティ(たとえば、少なくとも1つのプロセッサ上で実行するソフトウェア)でもよい。QME206は、さまざまなデータベースおよび/またはデータストレージにアクセスしてもよい。たとえば、QME206は、一人以上の加入者についての割当て使用情報(たとえば、確保リソース量、プランの残りのリソース量など)を含むデータベースにアクセスしてもよい。QME206はまた、通信環境100内のさまざまなノードおよびエンティティ(たとえば、他のOCSノードおよび/またはQME)と通信してもよい。
【0037】
いくつかの実施形態では、QME206は、ロックフリー通信ネットワークリソース割当て共有アルゴリズムまたは本明細書に記載のさまざまな態様を利用するための機能を含み得る。たとえば、QME206は、共有リソースプラン(たとえば、家族データ共有プラン)のメンバーに関連するリソース割当て要求を受信し、これに応答して、共有リソースプランをロックせずに、および/または共有リソースプランのリソースの割当ておよび/もしくは確保を管理する別のOCSノード(たとえば、OCSノード204)を介して共有リソースプランの十分なリソースを確保する前に、少なくとも最小リソース割当てを提供するために構成されてもよい。この例では、共有リソースプランをロックしないことによって、共有リソースプランの複数のメンバーは、OCSクラスタ106内の1つまたは複数のOCSノードからリソース割当てを同時に要求および/または受信することが可能である。
【0038】
いくつかの実施形態では、(たとえば、OCSノード200の)QME206は、共有リソースプランからの第1のリソース量を要求する第1のリソース割当て要求を、要求エンティティ(たとえば、PGW108)から受信し、第1のリソース確保要求を第2の課金ノード(たとえば、OCSノード204)に送信する前に、第1のメンバーの第1のリソース割当てを、要求エンティティに提供するために構成されてもよく、第1のリソース割当ては、第1のリソース量よりも少ない第2のリソース量を示し、QME206はさらに、共有リソースプランのリソースを確保する第1のリソース確保要求を、第2の課金ノードに送信するために構成されてもよい。
【0039】
データストレージ208~212の各々は、リソース割当て、確保リソース量、トリガ、およびデータ使用規則を含む、データ利用に関連するデータを格納するための任意の適切なエンティティ(たとえば、1つ以上の非一時的なコンピュータ読取可能媒体または1つ以上の記憶装置)を含み得る。たとえば、図2に示されているように、データストレージ208は、共有リソースプランの第1の加入者(たとえば、子メンバー)に関連付けられたリソース割当て要求を認可するために使用可能なリソース関連情報(たとえば、確保リソース量)を格納してもよく、データストレージ210は、共有リソースプランの第2の加入者(たとえば、第2の子メンバー)に関連付けられたリソース割当て要求を認可するために使用可能なリソース関連情報(たとえば、確保リソース量)を格納してもよく、データストレージ212は、共有リソースプランの第3の加入者(たとえば、主メンバー)に関連付けられたリソース割当て要求を認可するために使用可能なリソース関連情報(たとえば、確保リソース量、消費可能な残りの加入者使用量)を格納してもよい。
【0040】
いくつかの実施形態では、データストレージ208~212の各々は、それぞれのQME206もしくは関連するOCSノードに対してローカルでもよい、またはそれによってアクセス可能でもよい。たとえば、データストレージ208は、OCSノード200と統合されても、またはOCSノード200の外部に位置してもよく、データストレージ210は、OCSノード202と統合されても、またはOCSノード200の外部に位置してもよく、かつ、データストレージ212は、OCSノード204と統合されても、またはOCSノード204の外部に位置してもよい。
【0041】
図2およびその関連する説明は例示のためのものであり、図2におけるOCSクラスタ106および/またはさまざまな他のエンティティは、追加および/または異なるモジュール、コンポーネント、もしくは機能を含み得ることが理解されるであろう。
【0042】
図3A図3Bは、ロックフリー通信ネットワークリソース割当て共有に関連付けられたメッセージの例を示すメッセージフロー図である。図3A~3Bにおいて、Diameterクライアント300は、OCSクラスタ106またはその中のOCSノード(たとえば、OCSノード202および204)と対話するためのDiameterプロトコルおよび/または他のプロトコルを利用する要求エンティティ(たとえば、ネットワークノード)を表す。たとえば、Diameterクライアント300は、リソース割当てを要求および/または実施し、リソース使用量を追跡し、および/またはリソース使用情報を提供するエンティティを表してもよい。いくつかの実施形態では、Diameterクライアント300は、PCEFまたはPCEFに類似する機能を含み得る。たとえば、Diameterクライアント300は、PGW、PCEF、BBERF、TDF、もしくはDPI機能をサポートまたはホストするように構成されたネットワーク要素を含み得る。
【0043】
いくつかの実施形態では、たとえば、図3A~3Bに示されているように、OCSノード202およびOCSノード204は、OCSクラスタ106のノードを表してもよく、OCSノード202は、共有リソースプランの子メンバー(たとえば、二次メンバー)である第1の移動加入者に対応し、OCSノード204は、共有リソースプランの親メンバー(たとえば、主メンバー)である異なる移動加入者に対応する。そのような実施形態では、OCSノード204は、共有リソースプランに関連するプランの総リソース量(たとえば、総月間割当て量)を管理してもよく、関連リソース確保の対応、たとえば、共有リソースプランのさまざまなメンバーによる使用のために、プランの総リソース量からの一部のOCSノード202および/または他のOCSノードに対する割当てを担ってもよい。
【0044】
図3Aを参照すると、ステップ301において、Diameter CCR initial(CCR-I)メッセージまたは別の割当て要求メッセージが、Diameterクライアント300からOCSノード202に送信されてもよく、CCR-Iメッセージは、要求リソース量(たとえば、50MB)を示す要求サービスユニット(requested service unit:RSU)属性値ペア(attribute value pair:AVP)を含む。たとえば、共有リソースプランの加入者または関連UE112がアクセスネットワーク116または環境100にアタッチした後、Diameterクライアント300は、加入者に関連するリソース割当て(たとえば、データ使用量、時間使用量、または金銭使用量)を要求するDiameter CCR-Iメッセージを送信し得る。
【0045】
いくつかの実施形態では、Diameterクライアント300は、共有リソースプランのメンバー(たとえば、子メンバー)である移動加入者のトラフィックに対応するPCEFでもよく、OCSノード202は、この加入者に対応し、任意のリソース割当てを実施するために構成されてもよい。このような実施形態では、共有リソースプランまたはプランの総リソース量は、OCSクラスタ106内の異なるOCSノード(OCSノード204)によって管理される。
【0046】
ステップ302において、Diameterクレジット制御応答初期(credit control answer initial:CCA-I)メッセージまたは別の割当て応答メッセージが、OCSノード202からDiameterクライアント300に送信されてもよく、CCA-Iメッセージは、認可リソース量(たとえば、5MB)を示す認可サービスユニット(granted service unit:GSU)AVPを含む。
【0047】
いくつかの実施形態では、OCSノード202は、加入者または関連する共有リソースプランが、リソース割当て要求を認可するのに十分な残りのリソースを有するかどうかを知ることなく、リソース割当て要求を認可してもよい。そのような実施形態では(たとえば、リソース割当てを完全に認可することができるかどうかをOCSノード202が知らない場合)、OCSノード202は、加入者のためにDiameterクライアント300によって要求された量よりも少ないリソース量を認可してもよい。
【0048】
いくつかの実施形態では、(たとえば、リソース割当て要求が完全に認可され得るかどうかをOCSノード202が知らない場合)、OCSノード202によって最初に認可されるリソース量は、所定の値または割合に基づいてもよい。たとえば、所定の値または割合は、最小割当てと呼ばれてもよく、プランの初期の総リソース量(たとえば、プランの周期の最初の開始リソース割当て量)より大幅に少なくてもよい。この例では、プランの最初の総リソース量(最大量とも呼ばれる)が5GBであると仮定すると、最小割当ては、5MBすなわち最大量の1000分の1でもよい。
【0049】
いくつかの実施形態では、(たとえば、リソース割当て要求が完全に認可され得るかどうかをOCSノード202が知らない場合)、要求よりも少ないリソース割当てを提供することに代えて、またはそれに加えて、OCSノード202によって認可されるリソース量は、リソース割当ての有効期限が切れる時を示すための「短い」有効時間と関連付けられることがある。たとえば、「短い」有効時間は、完全に認可されるリソース割当て要求に対して使用されるデフォルトまたは典型的な有効時間(たとえば、30分)よりも短い時間(たとえば、30秒)でもよい。この例では、「短い」有効時間は、サービスプロバイダの収益が影響を受けるのを制限するため、および/または、OCSノード202が、たとえば、OCSノード204から共有リソースプランのリソースを確保した後に、要求エンティティ(たとえば、Diameterクライアント300)が新しいリソース割当てを要求するトリガとして使用されてもよい。
【0050】
いくつかの実施形態では、(たとえば、リソース割当て要求が完全に認可され得るとOCSノード202が知っている場合)、OCSノード202によって最初に認可されるリソース量は、要求リソース量に対するものでもよい。たとえば、OCSノード202が共有リソースプランの十分なリソースを以前に確保している場合、OCSノード202は、確保リソース量以下のリソース量のリソース割当て要求を認可することができる。
【0051】
ステップ303において、共有リソースプランに関連付けられたリソースを確保する確保要求が、OCSノード202からOCSノード204に送信されてもよい。たとえば、OCSノード202は、共有リソースプランの確保リソース量が再注文閾値に達するかまたはそれより低くなるたびに、OCSノード202が共有リソースプランに関連付けられたリソースを確保するためのトリガとして再注文閾値を使用するように構成されてもよい。この例では、再注文閾値は、プランの最大量の一部、たとえば、25MBまたはプランの最大量である5GBの100分の5でもよい。
【0052】
いくつかの実施形態では、確保要求は、所定の値または割合に基づいてリソースの量を確保してもよい。たとえば、OCSノード202は、50MBすなわちプランの最大量である5GBの100分の1の割当て確保単位を使用するように構成されてもよい。この例では、OCSノード202は、50GBまたはその倍数が加入者のために確保されるように要求してもよい。
【0053】
ステップ304Aにおいて、少なくとも一部の要求リソースが確保されたことを示すための確保応答が、OCSノード204からOCSノード202に送信されてもよい。たとえば、共有リソースプランの残りのリソース量が十分である場合、OCSノード204は、確保要求を完全に認可し(たとえば、要求リソース量を確保し)、OCSノード202に通知してもよい。同様に、この例では、共有リソースプランの残りのリソース量が十分でない場合、OCSノード204は、確保要求を部分的に認可し(たとえば、要求リソース量の一部のみを確保し)、OCSノード202に通知してもよい。
【0054】
ステップ304Bにおいて、共有リソースプランが消費可能な残りのリソースを有さない場合、OCSノード202および/またはOCSクラスタ106内の他のノードにこれを示すための「割当てなし」フラグが設定され得る。たとえば、OCSノード204が、共有リソースプランが消費可能な残りのリソースを有していないと決定した場合、OCSノード204は、OCSノード202および/またはOCSクラスタ106内の他のOCSノードに通知してもよい。この例では、OCSノード204は、OCSノード202および/またはOCSクラスタ106内の他のノードによって共有される、またはアクセス可能なメモリに「割当てなし」フラグを設定してもよい。別の例では、OCSノード204は、共有リソースプランが消費可能な残りのリソースを有していないことを示すためのローカルな「割当てなし」フラグを設定するために、メッセージを送信してもよい、または他の態様では、OCSノード202および/または他のエンティティをトリガしてもよい。
【0055】
いくつかの実施形態では、たとえば、共有リソースが消費されるクレジットまたは金銭である場合、OCSノード204は、加入者関連料金(または共有プランに適用される部分)が共有プランの利用可能クレジット限度を超えるたびに、OCSノード202および/またはOCSクラスタ106内の他のOCSノードに通知してもよい。そのような実施形態では、OCSノード202および/またはOCSクラスタ106内の他のOCSノードは、たとえば、加入者の承認によってなど共有プランに追加のクレジットもしくは金銭が適用または認可されるまで、そのようなトランザクションが利用可能クレジットを必要とする場合、その加入者に関わるその後のトランザクションを拒否してもよい。
【0056】
ステップ305において、Diameter CCR update(CCR-U)メッセージまたは別の割当て要求メッセージが、Diameterクライアント300からOCSノード202に送信されてもよく、CCR-Uメッセージは、要求リソース量(たとえば、50MB)を示すRSU AVPを含む。たとえば、共有リソースプランの加入者または関連するUE112が初期または既存の割当て量を使用した後、Diameterクライアント300は、加入者に関連する追加リソース割当てを要求するDiameter CCR-Uメッセージを送信してもよい。
【0057】
いくつかの実施形態では、CCR-Uメッセージは、加入者によって使用されたリソースの量を示すための使用サービスユニット(used service unit:USU)AVPを含み得る。たとえば、USU AVPは、サービスがアクティブになった時点から、または前の測定が終了した時点から測定された使用単位の量を示してもよい。この例では、使用情報は、監査、請求、および/または他の目的で使用可能である。
【0058】
ステップ302において、Diameter CCA update(CCA-U)メッセージまたは別の割当て応答メッセージが、OCSノード202からDiameterクライアント300に送信されてもよく、CCA-Uメッセージは、認可リソース量(たとえば、50MB)を示すGSU AVPを含む。
【0059】
いくつかの実施形態では、OCSノード202は、確保リソース量(たとえば、OCSノード204を介して以前に確保された量)に基づいて、リソース割当て要求を認可してもよい。たとえば、OCSノード202が共有リソースプランの加入者のために確保されたリソースへのアクセスを有する場合、OCSノード202は、最大で確保リソース量のリソース割当て、およびこの量を含むリソース割当てを提供してもよい。別の例では、予め定義された最小割当て量が確保リソース量より多い場合、OCSノード202は、最小割当て量のリソース割当てを提供してもよい。
【0060】
いくつかの実施形態では、リソース割当てを認可または提供する前に、OCSノード202は、「割当てなし」フラグが設定されているかどうかを決定してもよい。たとえば、フラグが設定されていることは、共有リソースプランが消費可能な残りのリソースを有していないことを示し得る。この例では、フラグが設定されている場合(および以前の確保から利用可能な確保リソースがない場合)、OCSノード202は、リソース割当て要求を拒否してもよい、または他の態様では、割当てが利用可能でないことをDiameterクライアント300に示してもよい。
【0061】
図3Bを参照すると、ステップ307において、Diameter CCR terminate(CCR-T)メッセージまたは別の割当て要求メッセージが、Diameterクライアント300からOCSノード202に送信されてもよく、CCR-Tメッセージは、加入者によって使用されたリソースの量を示すUSU AVPを含む。たとえば、共有リソースプランの加入者もしくは関連UE112がセッションを終了またはログアウトした後で、Diameterクライアント300は、クレジット制御セッションを終了させるためのDiameter CCR-Tメッセージを送信してもよい。
【0062】
ステップ308において、Diameter CCA terminate(CCA-T)メッセージまたは別の割当て応答メッセージが、CCR-Tメッセージが受信され確認されたことを示すために、OCSノード202からDiameterクライアント300に送信されてもよい。
【0063】
いくつかの実施形態では、OCSノード202は、請求、監査、および/または他の目的で、Diameterクライアント300から(たとえば、CCR-Tで)受信した使用情報を使用することができる。たとえば、OCSノード202は、加入者に関連付けられた使用情報を使用して、解放する確保リソースの量を決定してもよい。この例では、OCSノード202は、Diameterクライアント300から受信した使用情報に基づいて、リソース割当てのかなりの部分が消費されなかったと判断してもよく、そのため、OCSノード202は、確保解放をOCSノード204に送信することによって、これらのリソースまたはその一部を解放してもよい。
【0064】
ステップ309において、共有リソースプランに関連付けられた確保リソース(たとえば、25MB)を解放するための確保解放が、OCSノード202からOCSノード204に送信されてもよい。たとえば、確保解放を受信した後、OCSノード204は、解放されるリソースの量だけ共有リソースプランに関連付けられた残りのリソース量を増加させてもよい。
【0065】
いくつかの実施形態では、更新プロセスは、加入者が共有リソースプランの利用可能なリソースをチャージ(満たす)またはリロードするときに発生し得る。たとえば、UE112を使用する加入者は、請求システム110と対話して、追加リソース(たとえば、5GBのデータまたは50ドルのクレジット)を購入することができる。この例では、更新プロセスは、請求システム110がOCSノード204および/またはOCSクラスタ106内の他のノードに通知し、それによって、Diameterクライアント300が追加リソース割当ての要求および受信を可能にするさまざまな動作(たとえば、「割当てなし」フラグのクリアまたは設定削除)をトリガすることを含む場合がある。
【0066】
ステップ310において、共有リソースプランが消費される追加のリソースを有することを示すための新しい割当て認可が、請求システム110からOCSノード204に送信されてもよい。
【0067】
ステップ311において、OCSノード204は、「割当てなし」フラグ(たとえば、OCS204におけるローカルフラグ)をクリアし、それによって、共有リソースプランが消費されるリソースを有することを示してもよい。
【0068】
ステップ312において、OCSノード204は、共有リソースプランが消費されるリソースを有することを、OCSノード202およびOCSクラスタ106内の他のノードに通知してもよい。たとえば、OCSノード202(およびOCSノード200)は、リソースが共有リソースプランに追加されたことを示すOCSノード204からの通知を受信してもよく、これに応答して、OCSノード202(およびOCSノード200)はローカルフラグをクリアし、それによって、共有リソースプランが消費されるリソースを有することを示してもよい。
【0069】
図3A図3Bは例示のためのものであり、図3A図3Bに示されているものとは異なるおよび/または追加のメッセージ、ステップ、および/または動作が使用されてもよいことが理解されるであろう。また、本明細書に記載のさまざまなメッセージ、ステップ、および/または動作は、図3A図3Bに示されている順序またはシーケンスとは異なる順序またはシーケンスで行われてもよいことが理解されるであろう。
【0070】
図4は、ロックフリー通信ネットワークリソース割当て共有のプロセス400の例を示す図である。いくつかの実施形態では、本明細書に記載のプロセス400またはその一部は、ネットワークノード(たとえば、OCSノード202もしくは204)、QME206、および/または別のモジュールもしくはノードにおいて実行されてもよい、またはそれによって実行されてもよい。いくつかの実施形態では、プロセス400または関連する動作は、複数の課金ノードを含む通信ネットワーク(たとえば、環境100)に関連付けられた分散型課金システム(たとえば、OCSクラスタ106)の第1の課金ノード(たとえば、OCSノード202)によって実行されてもよく、第1の課金ノードは、共有リソースプランの第1のメンバー(たとえば、子メンバー)に関連付けられた通信ネットワークリソース割当て要求に対応するためのものであり、第2の課金ノード(たとえば、OCSノード204)は、共有リソースプランに関連付けられたリソース確保を管理する。
【0071】
プロセス400を参照すると、ステップ402において、共有リソースプランからの第1のリソース量を要求する共有リソースプランの第1のメンバーに関連付けられた第1の通信ネットワークリソース割当て要求が、要求エンティティから受信されてもよい。たとえば、PGW108またはDiameterクライアント300は、通信ネットワーク加入者が通信ネットワークリソース割当てを必要とすることを示すネットワークアタッチメント要求または他のメッセージを受信してもよい。この例では、PGW108またはDiameterクライアント300は、通信ネットワーク加入者が使用するための通信ネットワークリソース割当てを要求するDiameter CCRメッセージを、OCSクラスタ106またはそのノード(たとえば、OCSノード202)に送信してもよい。
【0072】
ステップ404において、共有リソースプランが第1のリソース量を割当てるのに利用可能な十分なリソースを有することを確認することなく、第1のメンバーの第1の通信ネットワークリソース割当てが要求エンティティに提供されてもよく、第1の通信ネットワークリソース割当ては、第1のリソース量よりも少ない第2のリソース量を示し、かつ/または、第1の通信ネットワークリソース割当ては、第1の通信ネットワークリソース割当ての有効期限が切れる時を示す有効時間に関連付けられている。たとえば、OCSノード202は、共有リソースプラン(または関連アカウント)をロックすることなく、ならびに/または(たとえば、共有リソースプランのリソースの割当ておよび/もしくは確保を管理するOCSノード204から)要求リソースが消費可能であるという確認を受信することなく、共有リソースプランの加入者の最小割当て(たとえば、所定量のリソース)をPGW108またはDiameterクライアント300に提供するように構成されてもよい。別の例では、OCSノード202は、PGW108またはDiameterクライアント300に、共有リソースプランの加入者に対してリソース割当ての有効期限が切れる時を示す有効時間を有するリソース割当てを提供するように構成されてもよい。この例では、有効時間は、リソース割当てを認可するときに使用される典型的なまたはデフォルトの有効時間(たとえば、60分)に対して短い時間(たとえば、30秒)でもよい。この例を続けると、リソース割当ての有効期限が切れた後、PGW108またはDiameterクライアント300は、別のリソース割当てを要求する必要がある(これは、OCSノード202がOCSノード204から共有リソースプランのリソースを要求および確保するのに十分な時間を提供してもよい)。
【0073】
ステップ406において、共有リソースプランのリソースを確保する第1のリソース確保要求が、第2の課金ノードに送信されてもよい。たとえば、共有リソースプランの加入者のための最小割当て(たとえば、2MB)をPGW108またはDiameterクライアント300に提供した後、OCSノード202は、OCSノード202が共有リソースプランの一部のリソースを確保し、確保されたリソースを使用して加入者のために後続の通信ネットワークリソース割当て要求を認可できるように、リソース確保要求をOCSノード204に送信してもよい。
【0074】
いくつかの実施形態では、共有リソースプランの第1のメンバーは、共有リソースプランの第2のメンバーに通信ネットワークリソース割当てが割当てられるのと同時に、通信ネットワークリソース割当てを割当てられてもよい。そのような実施形態では、異なるメンバーに配分される割当ては、同じ量でもよい、または異なる量でもよい。
【0075】
たとえば、OCSノード200および/または関連するQME206は、共有リソースプランの第1のメンバーに関わる割当て関連トランザクションを実行してもよく、OCSノード202および/または関連付けられたQME206は、共有リソースプランの第2のメンバーに関わる割当て関連トランザクションを同時に実行してもよい。この例では、OCSノード200、OCSノード202、およびOCSクラスタ106内の他のOCSノードは、共有リソースプランに関連付けられた複数の割当て関連トランザクションが同時に(たとえば、並行してまたはほぼ並行して)発生することを可能にするロックフリー割当て管理アルゴリズムを使用してもよい。これに対して、ロックベースの割当て管理システムは、共有リソースプランに関連付けられた第1の割当て関連トランザクションが発生している間、たとえば、OCSクラスタ106内のどのOCSノードが割当て関連トランザクションに対応していたかに関係なく、共有リソースプランに関連付けられた割当て関連トランザクションが処理されるのを防止することになる。
【0076】
いくつかの実施形態では、第1のリソース量は、データ使用量、時間使用量、金額、またはクレジット額を含む。たとえば、PGW108は、通信環境100を介してデータおよび/またはサービスにアクセスするために、OCSノード202にデータ使用量割当てを要求し、OCSノード202からデータ使用量割当てを受信してもよい。別の例では、PGW108は、通信環境100に関連付けられたサービスまたはアイテムを課金するために、OCSノード202にクレジットまたは金銭の割当てを要求し、OCSノード202からクレジットまたは金銭の割当てを受信してもよい。
【0077】
いくつかの実施形態では、第1のリソース確保要求が、共有リソースプランが利用可能な残りのリソース量よりも大きいリソース量を確保するためのものである場合、第2の課金ノード(たとえば、OCSノード204)は、共有リソースプランが消費可能なリソースがそれ以上ないことを示すフラグを設定することによって第1の課金ノード(たとえば、OCSノード202)に通知する、かつ/または、第1のリソース確保要求で要求されたリソース量の少なくとも一部を提供する。
【0078】
いくつかの実施形態では、プロセス400は、第1の通信ネットワークリソース割当てを提供する前に、フラグが設定されていないと判断することを含んでもよく、フラグが設定されていることは、共有リソースプランが消費可能なリソースをそれ以上有していない(たとえば、消費するインターネットデータまたは消費する金銭をそれ以上有していない)ことを示す。
【0079】
いくつかの実施形態では、プロセス400は、第1のリソース確保要求に基づいて、第2の課金ノードから確保リソース量を受信することと、共有リソースプランからの第3のリソース量を要求する第2の通信ネットワークリソース割当て要求を、要求エンティティから受信することと、確保リソース量を使用して、共有リソースプランの第1のメンバーの第2の通信ネットワークリソース割当てを、要求エンティティに提供することとを含み得る。
【0080】
いくつかの実施形態では(たとえば、第3のリソース量が確保リソース量より多い、または確保リソース量が再オーダー閾値に達する、もしくはそれ以下になる場合)、第2の課金ノードに、共有リソースプランからの追加のデータを確保する第2のリソース確保要求を要求すること。
【0081】
いくつかの実施形態では、通信ネットワークリソース割当て要求は、DiameterメッセージまたはDiameter CCRを含み得る。たとえば、PGW108は、通信ネットワークリソース割当てを要求するRSU AVPを含むCCR-Iメッセージを、OCSノード202に送信してもよい。別の例では、Diameterクライアント199(たとえば、PCEF)は、RSU AVPを含むCCR-UメッセージをOCSノード200に送信してもよい。
【0082】
いくつかの実施形態では、プロセス400における要求エンティティは、PGW108、Diameterネットワーク要素、PCEF、BBERF、TDF、またはDPI機能を含み得る。
【0083】
いくつかの実施形態では、第1の課金ノードおよび第2の課金ノードは、分散型OCS、たとえば、OCSクラスタ106に関連付けられてもよい。
【0084】
図4は例示のためのものであり、異なるおよび/もしくは追加のステップならびに/または動作が使用されてもよいことが理解されるであろう。また、本明細書に記載のさまざまなステップおよび/または動作は、異なる順序またはシーケンスで発生してもよいことも理解されるであろう。
【0085】
なお、課金ノード、OCSクラスタ106、OCSノード200、OCSノード202、OCSノード204、QME206、および/または本明細書に記載の機能は、特殊目的のコンピューティングデバイスを構成し得る。さらに、課金ノード、OCSクラスタ106、OCSノード200、OCSノード202、OCSノード204、QME206、および/または本明細書に記載の機能は、通信ネットワーク、OCSアーキテクチャ、およびリソース共有の技術分野を向上させることが可能である。たとえば、ロックフリー通信ネットワークリソース割当て共有を利用することによって、リソース共有および関連する課金に関連するレイテンシおよび性能の問題を緩和または防止することができる。さらに、ロックを必要とせず、関連するロックオーバーヘッドが回避されるので、ロックフリー通信ネットワークリソース割当て共有を利用する分散型OCSクラスタは、共有リソースプランの異なるメンバーが分散型OCSクラスタの異なるノードによって処理されるシナリオに関わる複雑さを低減することが可能である。
【0086】
本明細書に記載の主題のさまざまな詳細事項は本明細書に記載の主題の範囲を逸脱することなく変更可能であることが、理解されるであろう。さらに、前述の記載は制限を目的としているのではなく、説明を目的としているにすぎない。
図1
図2
図3A
図3B
図4
【国際調査報告】