Method, system, and computer-readable medium for lock-free communication network resource allocation and sharing

Abstract

An example method for lock-free communication network resource allocation sharing is performed at a first charging node of a distributed charging system including multiple charging nodes. The example method comprises receiving, from a requesting entity, a first communication network resource allocation request requesting a first amount of resources from a shared resource plan; and providing to the requesting entity a first communication network resource allocation for a first member without verifying that the shared resource plan has sufficient resources available to allocate the first amount of resources, wherein the first communication network resource allocation indicates a second amount of resources that is less than the first amount of resources and / or the first communication network resource allocation is associated with a validity time that indicates when the first communication network resource allocation expires, and the example method further comprises transmitting, to a second charging node, a first resource reservation request to reserve resources in the shared resource plan.

Description

Technical Field

[0001] Priority Claim This application claims the benefit of U.S. Patent Application Serial No. 16 / 690,058, filed November 20, 2019, and the entire disclosure thereof is incorporated herein by reference.

[0002] Technical Field The subject matter described herein relates to communication networks. In particular, the subject matter described herein relates to methods, systems, and computer-readable media for lock-free communication network resource allocation sharing.

Background Art

[0003] Background A communication network service provider can provide a variety of different network services to subscribers of mobile devices. The resource plans provided by the service provider are typically characterized by combinations of different performance categories and various amounts of resources. For example, a subscriber pays a monthly fee for a given bandwidth speed, a given amount of resource allocation for download size resources, and / or a resource plan at a specific quality of service (QoS) level (e.g., a mobile data plan or a subscription plan). Similarly, another subscriber can subscribe to a different resource plan with a lower bandwidth speed, less resource allocation, and / or a lower QoS level.

[0004] Subscribers may share resource plans (e.g., data plans or credit plans). For example, in a family - shared data plan, multiple user devices (e.g., of a husband, wife, and their children) can share a high - speed data allocation (20 gigabytes) per month. In this example, as with most data plans, the service provider generally suspends the subscriber's service when the shared data is consumed. In another example, a family - shared plan may include sharing a portion of the fees paid by one or more members. For example, a family - shared plan can pay 20% of a child member's fees, with a maximum amount (e.g., the credit limit of the plan) as the upper limit.

[0005] In one method considered to prevent over - consumption of resources by members of a shared resource plan, when a member of the plan makes a resource allocation request, using a lock on the shared resource plan is involved. Using a lock can prevent over - consumption of data (and can reduce the impact on the service provider's revenue), but such a solution may affect latency and performance in the network. Further problems may occur when an online charging system (OCS) uses a distributed architecture, where some OCS nodes handle different resource plans and / or some OCS nodes handle resource allocation requests of different members of the same shared resource plan.

[0006] Therefore, there is a need for methods, systems, and computer - readable media for lock - free communication network resource allocation sharing. SUMMARY OF THE INVENTION MEANS FOR SOLVING THE PROBLEM

[0007] Overview A method, system, and computer-readable medium for lock-free communication network resource allocation sharing are disclosed. In some embodiments, an example of the method is performed at a first charging node of a distributed charging system that includes a plurality of charging nodes, the first charging node being for responding to a communication network resource allocation request associated with a first member of a shared resource plan, and a second charging node managing resource reservation associated with the shared resource plan. An example of the method includes receiving, from a requesting entity, a first communication network resource allocation request that requests a first amount of resources from the shared resource plan, and providing, to the requesting entity, a first communication network resource allocation of the first member without verifying that the shared resource plan has sufficient resources available to allocate the first amount of resources, the first communication network resource allocation indicating a second amount of resources that is less than the first amount of resources and / or the first communication network resource allocation being associated with an expiration time indicating when the first communication network resource allocation expires, the example of the method further including transmitting, to the second charging node, a first resource reservation request to reserve resources of the shared resource plan.

[0008] In some embodiments, an example of a system comprises a first charging node of a distributed charging system that includes a plurality of charging nodes. The first charging node is implemented using at least one processor and memory. The first charging node is for responding to a communication network resource allocation request associated with a first member of a shared resource plan, and a second charging node manages resource reservation associated with the shared resource plan. The first charging node receives, from a requesting entity, a first communication network resource allocation request that requests a first amount of resources from the shared resource plan, and configures to provide, to the requesting entity, a first communication network resource allocation for the first member without verifying that the shared resource plan has sufficient resources available to allocate the first amount of resources, the first communication network resource allocation indicates a second amount of resources that is less than the first amount of resources, and / or the first communication network resource allocation is associated with an expiration time indicating when the first communication network resource allocation expires, and the first charging node is further configured to send a first resource reservation request for reserving resources of the shared resource plan to the second charging node.

[0009] The subject matter described in this specification can be implemented in software in combination with hardware and / or firmware. For example, the subject matter described in this specification can be implemented in software executed by a processor. In one example of implementation, the subject matter described in this specification can be implemented using a computer-readable medium storing computer-executable instructions that, when executed by a processor of a computer, control the computer to perform steps. The steps to be executed can correspond to any one or more of the steps described herein in connection with the present invention. Examples of computer-readable media suitable for implementing the subject matter described in this specification include non-transitory devices such as disk memory devices, chip memory devices, programmable logic devices, and application specific integrated circuits. Further, the computer-readable media for implementing the subject matter described in this specification may be disposed on a single device or computing platform, or may be distributed across multiple devices or computing platforms.

[0010] As used herein, the term "node" refers to at least one physical computing platform including one or more processors and memory.

[0011] As used herein, the term "function" or "module" refers to software in combination with hardware and / or firmware for implementing the functions described herein.

[0012] The subject matter described in this specification is explained below with reference to the accompanying drawings.

Brief Description of the Drawings

[0013]

Figure 1

Figure 2

Figure 3A

Figure 3B

Figure 4

DETAILED DESCRIPTION OF THE INVENTION

[0014] Detailed Description The subject matter described herein relates to methods, systems, and computer-readable media for lock-free communication network resource allocation and sharing. Shared resource plans are available to subscribers of various communication networks. For example, a mobile phone service provider sells family sharing plans in which multiple family members (or their user devices) can share time or data from the total amount of the plan (e.g., monthly allocation). In another example, a family sharing billing plan enables family members to share credit or billing, such that at least a portion of the billing may be paid by a shared credit or monetary allocation.

[0015] A lock-based billing architecture can handle shared resource plans by locking the plan or associated parent account when a child member of the plan requests a resource, preventing parallel or concurrent events (e.g., associated with other members of the shared resource plan) from over-consuming resources from the plan or parent account. Locking the plan or parent account prevents revenue from being affected by the possibility of over-consumption, but such locks can have a significant impact on system latency and performance. Further, when an online charging system (OCS) utilizes a distributed architecture where some OCS nodes serve different members of the same shared resource plan, additional complexity may be required to achieve resource allocation sharing using a lock-based billing architecture.

[0016] According to some aspects of the subject matter described herein, techniques, methods, systems, or mechanisms for lock-free communication network resource allocation sharing are disclosed. In some embodiments, lock-free communication network resource allocation sharing is available for ranking members of a shared resource plan (e.g., providing resource allocations for members to use) without locking the parent account. For example, a charging node (e.g., an OCS node) or related module according to at least some aspects described herein receives a resource allocation request related to a member of a shared resource plan (e.g., a family data sharing plan), and in response, provides a small resource allocation (e.g., 5 megabytes (MB) of data) without locking the shared resource plan and / or before securing sufficient resources of the shared resource plan to fully approve the resource allocation request (e.g., via another OCS node). In this example, a requesting entity (e.g., a packet gateway) may allow a subscriber to consume the initial resource allocation, for example, during a subscriber data session. While the initial resource allocation is being consumed, the charging node can query another charging node to secure additional resources for the subscriber to use. Continuing with this example, by the time the requesting entity requests an additional resource allocation, the charging node may have secured sufficient resources to fully approve this subsequent resource allocation request. Or, if the charging node determines that it does not have the remaining resources to be consumed by the subscriber (e.g., by communicating with another charging node that manages the shared resource account), the charging node can reject the subsequent resource allocation request and limit the potential loss of revenue to the initial small resource allocation.

[0017] According to some aspects of the subject matter described herein, a lock-free communication network resource allocation sharing algorithm or related implementation may be implemented on multiple charging nodes (e.g., OCS nodes) of a distributed OCS (e.g., an OCS cluster). For example, the algorithm may direct the charging nodes of the distributed OCS to respond to events by providing a minimum allocation (e.g., a relatively small predetermined amount of resources) and / or an expiration time (e.g., a time indicating when the resource allocation expires), direct the charging nodes to secure resources from a parent (e.g., the charging node corresponding to the resource reservation and / or allocation for a related shared resource plan), and direct the charging nodes to secure a minimum allocation or a predetermined value, except when no further resources are available from the shared resource plan.

[0018] Advantageously, by utilizing lock-free communication network resource allocation sharing, latency and performance issues related to resource sharing and associated charging can be mitigated or prevented. Further, since no network-mediated and in-line synchronization locks for requests are required and the associated lock overhead is avoided, a distributed OCS cluster utilizing lock-free communication network resource allocation sharing can reduce the complexity associated with scenarios where different nodes of the distributed OCS cluster correspond to different members of a shared resource plan.

[0019] Various embodiments of the subject matter described herein are referred to in detail below and examples thereof are shown in the accompanying drawings. As far as possible, the same reference numbers are used throughout the drawings to refer to the same or similar parts.

[0020] FIG. 1 is a block diagram illustrating an example of a communication environment 100 for lock-free communication network resource allocation and sharing. The communication environment 100 can represent one or more communication networks for providing various data, applications, and / or services, such as telephone, Internet, text messages, and the like.

[0021] Referring to FIG. 1, the communication environment 100 can include a policy server 102, a subscriber profile repository (SPR) 104, an online charging system (OCS) cluster 106, and a packet data network (PDN) gateway (PGW) 108, and a billing system 110. The communication environment 100 can include an access network 116 that communicatively connects the PGW 108 to a user equipment (UE) device 112 associated with a subscriber. The UE device 112 can represent a computer or device (e.g., a mobile smartphone, a tablet computer device, a personal digital assistant (PDA), etc.) that is connectable to various network nodes within the communication environment 100 via the access network 116, and / or can be capable of connecting to the Internet (e.g., via the PGW 108), or receiving services or data using the communication environment 100.

[0022] OCS cluster 106 may represent a distributed OCS that includes one or more OCS nodes. The OCS cluster 106 or its node(s) may be any suitable one or more entities (e.g., one or more computing platforms or software executed on at least one processor) for performing one or more charging functions. For example, some nodes of the OCS cluster 106 may process or respond to resource allocation requests for different subscribers. In this example, some nodes of the OCS cluster 106 may respond to resource allocation requests from subscribers of the same shared resource plan, such as a family data sharing plan.

[0023] In some embodiments, the shared resource plan may enable a member (e.g., a mobile network subscriber) to share or use communication network-related resources from the total amount of resources of the plan (e.g., the total monthly allocation). For example, the shared resources may include an amount of data (e.g., 5 gigabytes (GB)), time (e.g., 100 minutes of internet service), or a credit amount (e.g., $200).

[0024] In some embodiments, the OCS cluster 106 or its node(s) may receive subscriber usage data (e.g., traffic and signaling data generated or received by the UE 112) from the PGW 108 and / or another entity. The OCS cluster 106 or its node(s) may be configured to maintain a subscriber usage database for recording and storing subscriber usage data of various subscribers received from the PGW 108. In some embodiments, the OCS cluster 106 or its node(s) may be configured to utilize a usage database to distinguish and track the specific data usage amounts (e.g., in allocation bucket units) for each subscriber.

[0025] In some embodiments, the OCS cluster 106 or its node(s) may include a lock-free communication network resource allocation sharing algorithm or functionality (e.g., one or more modules) for utilizing the various aspects described herein. For example, the QME 206 may receive resource allocation requests related to members of a shared resource plan (e.g., a family data sharing plan) and, in response, provide at least a minimum resource allocation without locking the shared resource plan and / or before securing sufficient resources of the shared resource plan via another OCS node (e.g., OCS node 204) that manages the allocation and / or reservation of resources of the shared resource plan.

[0026] The PGW 108 may represent any suitable entity within the communication environment 100 configured to receive packet communications from the UE 112 via the access network 116 and report the usage associated with the UE 112 to the OCS cluster 106 or its node(s) (e.g., via the Gy interface). The PGW 108 may also be configured to provide network state data (e.g., traffic load state) to the policy server 102 and / or the OCS cluster 106 or its node(s). The PGW 108 may also be configured to enforce or implement the policy rules provided by the policy server 102. In some embodiments, the PGW 108 may include any network element configured to support or host at least one of a policy and charging enforcement function (PCEF), a bearer binding and event reporting function (BBERF), a deep packet inspection (DPI) function, a traffic detection function (TDF), or other similar network element functions.

[0027] In some embodiments, the PGW 108 may be configured to request and perform resource allocations for various subscribers. For example, when a subscriber or associated UE 112 connects to the access network 116 or the communication environment 100, the PGW 108 may send a resource allocation request to the OCS cluster 106 or its node(s) to request and receive a resource allocation for use by the subscriber. In this example, when the subscriber uses its allocated resources (e.g., when the remaining amount of resource allocation at the PGW 108 reaches or falls below a threshold), the PGW 108 may send another resource allocation request to the OCS cluster 106 or its node(s) to request and receive an additional resource allocation used by the subscriber. Continuing with this example, when the subscriber logs off from the network or ends the session, the PGW 108 may release or relinquish any remaining allocations returned to the OCS cluster 106 or its node(s) for future use.

[0028] The billing system 110 may represent any suitable entity within the communication environment 100 configured to perform one or more billing and / or charging functions. In some embodiments, the billing system 110 may be used to calculate or aggregate resource usage amounts for billing purposes and / or to provide an interface to enable a subscriber to pay a bill or purchase additional resources. For example, the billing system 110 may provide a user interface or other communication interface to enable a subscriber to fulfill (charge) or purchase additional resources for a shared resource plan. In this example, when a subscriber completes a transaction to purchase resources for a shared resource plan, the billing system 110 may notify the OCS cluster 106 or its node(s) so that these resources become available to, for example, one or more members of the shared resource plan.

[0029] Policy server 102 may represent any suitable entity for performing one or more policy functions and / or charging functions. For example, policy server 102 may be configured to determine and create policy rules for subscribers subscribing to services in communication environment 100. In this example, policy server 102 may generate policy and charging control (PCC) rules and provide these rules to one or more network elements (e.g., PGW 108). Continuing with this example, the PCC rules created by policy server 102 may relate to services, QoS levels, and charging rules for one or more subscribers. In some embodiments, policy server 102 may include a policy and charging rules function (PCRF), and / or may be hosted and executed by a Diameter-based network element or server.

[0030] In some embodiments, policy server 102 or another entity may be configured to request allocation usage information from OCS cluster 106 or its OCS nodes. The allocation usage information may be requested and received via an application interface (e.g., Sy interface) with OCS cluster 106 or its node(s). In some embodiments, policy server 102 may request allocation usage information from OCS cluster 106 or its node(s) by transmitting a Diameter request message that may include at least one of Diameter session identifier information, subscriber identifier information (e.g., IMSI), subscriber tier information, subscriber service type identifier information, and / or other information. Upon receiving the request, OCS cluster 106 or its node(s) may be configured to use the provided information to determine appropriate subscriber allocation usage information, which may ultimately be returned to requesting policy server 102.

[0031] SPR104 may include a database configured to store profile information related to subscribers of the communication environment 100. For example, the stored subscriber profile data may include a resource plan code (e.g., a billing plan code or name) and entitlements associated with the resource plan code. Exemplary entitlements may include, but are not limited to, VoIP (voice over Internet protocol) service, video chat, domestic roaming, international roaming, MiFi, data, gifts (e.g., special campaigns), and specific devices. In some embodiments, SPR104 may be integrated with one or more network elements or may be distributed across multiple computing platforms or devices.

[0032] In some embodiments, UE112 may register for services with the communication network by initiating a network attachment procedure. For example, UE112 may be able to send a user attachment request message to PGW108. In response to receiving the attachment request message, PGW108 may send a Diameter credit control request (CCR) message to policy server 102. Next, policy server 102 may send a Diameter user data request (UDR) message including a user identifier to SPR104 to request the resource plan code and / or plan entitlements associated with the subscriber. For example, SPR104 may be configured to store the resource plan data in local profile database 114. Alternatively, SPR104 may query an external database containing the subscriber's resource plan information.

[0033] FIG. 1 is for illustrative purposes, and it will be understood that the various nodes and / or modules, locations, and / or functions described above in connection with FIG. 1 may be changed, modified, added, or deleted.

[0034] FIG. 2 is a block diagram showing an OCS cluster 106 for lock-free communication network resource allocation sharing. Referring to FIG. 2, the OCS cluster 106 may include one or more OCS nodes, such as OCS nodes 200-204. Each of the OCS nodes 200-204 may be any suitable entity (e.g., a computing platform, or software executed on at least one processor) for performing one or more charging-related functions. In some embodiments, each of the OCS nodes 200-204 may be responsible for handling resource allocation requests from a plurality of subscribers where the resource allocation requests from at least one subscriber are not handled by all of the OCS nodes 200-204. For example, OCS node 200 may handle a resource allocation request from a first mobile subscriber, OCS node 202 may handle a resource allocation request from a second mobile subscriber, and OCS node 200 may handle a resource allocation request from a third mobile subscriber.

[0035] In some embodiments, the subscribers associated with different OCS nodes may be members of the same shared resource plan. For example, the shared resource plan may represent a family data sharing plan, and OCS nodes 200 and 202 may handle allocation requests from children or secondary members of the shared resource plan, and OCS node 204 may manage the parent or primary member of the shared resource plan. In this example, assuming that OCS node 204 manages the resource reservation of the resources of the shared resource plan, each of the OCS nodes 200-202 may be able to send the resource reservation to OCS node 204.

[0036] Each of the OCS nodes 200-204 may include a quota management engine (QME) 206 and a data storage, such as one of data storages 208-212. The QME 206 may be any suitable entity (e.g., software running on at least one processor) for maintaining, adjusting, providing, and / or reporting resource allocation or allocation-related information. The QME 206 may access various databases and / or data storages. For example, the QME 206 may access a database containing allocation usage information (e.g., amount of resources secured, remaining resources of the plan, etc.) for one or more subscribers. The QME 206 may also communicate with various nodes and entities (e.g., other OCS nodes and / or QMEs) within the communication environment 100.

[0037] In some embodiments, the QME 206 may include a lock-free communication network resource allocation sharing algorithm or functionality for utilizing various aspects described herein. For example, the QME 206 may receive a resource allocation request related to a member of a shared resource plan (e.g., a family data sharing plan) and, in response, provide at least a minimum resource allocation without locking the shared resource plan and / or before securing sufficient resources of the shared resource plan via another OCS node (e.g., OCS node 204) that manages the allocation and / or reservation of the resources of the shared resource plan. In this example, by not locking the shared resource plan, multiple members of the shared resource plan can simultaneously request and / or receive resource allocations from one or more OCS nodes within the OCS cluster 106.

[0038] In some embodiments, the QME 206 (e.g., of the OCS node 200) may be configured to receive, from a requesting entity (e.g., the PGW 108), a first resource allocation request that requests a first amount of resources from a shared resource plan, and provide, to the requesting entity, a first resource allocation for a first member before sending a first resource reservation request to a second charging node (e.g., the OCS node 204), the first resource allocation indicating a second amount of resources that is less than the first amount of resources, and the QME 206 may further be configured to send a first resource reservation request to the second charging node to reserve resources of the shared resource plan.

[0039] Each of the data storages 208-212 may include any suitable entity (e.g., one or more non-transitory computer-readable media or one or more storage devices) for storing data related to data utilization, including resource allocations, reserved resource amounts, triggers, and data usage rules. For example, as shown in FIG. 2, the data storage 208 may store resource-related information (e.g., reserved resource amount) that can be used to approve a resource allocation request associated with a first subscriber (e.g., a child member) of a shared resource plan, the data storage 210 may store resource-related information (e.g., reserved resource amount) that can be used to approve a resource allocation request associated with a second subscriber (e.g., a second child member) of the shared resource plan, and the data storage 212 may store resource-related information (e.g., reserved resource amount, remaining consumable subscriber usage) that can be used to approve a resource allocation request associated with a third subscriber (e.g., a primary member) of the shared resource plan.

[0040] In some embodiments, each of data storages 208-212 may be local to or accessible by their respective QME 206 or associated OCS node. For example, data storage 208 may be integrated with OCS node 200 or located external to OCS node 200, data storage 210 may be integrated with OCS node 202 or located external to OCS node 200, and data storage 212 may be integrated with OCS node 204 or located external to OCS node 204.

[0041] FIG. 2 and its associated description are for illustrative purposes, and it will be understood that OCS cluster 106 and / or various other entities in FIG. 2 may include additional and / or different modules, components, or functions.

[0042] FIGS. 3A-3B are message flow diagrams showing examples of messages associated with lock-free communication network resource allocation sharing. In FIGS. 3A-3B, Diameter client 300 represents a requesting entity (e.g., a network node) that utilizes the Diameter protocol and / or other protocols to interact with OCS cluster 106 or an OCS node therein (e.g., OCS nodes 202 and 204). For example, Diameter client 300 may represent an entity that requests and / or enforces resource allocation, tracks resource usage, and / or provides resource usage information. In some embodiments, Diameter client 300 may include a PCEF or a function similar to PCEF. For example, Diameter client 300 may include a network element configured to support or host a PGW, PCEF, BBERF, TDF, or DPI function.

[0043] In some embodiments, for example, as shown in FIGS. 3A-3B, OCS node 202 and OCS node 204 may represent nodes of OCS cluster 106, OCS node 202 corresponds to a first mobile subscriber who is a child member (e.g., a secondary member) of a shared resource plan, and OCS node 204 corresponds to a different mobile subscriber who is a parent member (e.g., a primary member) of the shared resource plan. In such embodiments, OCS node 204 may manage the total amount of resources of the plan associated with the shared resource plan (e.g., the total monthly allocation), and be responsible for allocating a portion of the total amount of resources of the plan to some OCS nodes 202 and / or other OCS nodes for resource reservation handling, for example, for use by different members of the shared resource plan.

[0044] Referring to FIG. 3A, at step 301, a Diameter CCR initial (CCR-I) message or another allocation request message may be sent from Diameter client 300 to OCS node 202, and the CCR-I message includes a requested service unit (RSU) attribute value pair (AVP) indicating a requested amount of resources (e.g., 50 MB). For example, after a subscriber or associated UE 112 of a shared resource plan attaches to access network 116 or environment 100, Diameter client 300 may send a Diameter CCR-I message requesting resource allocation (e.g., data usage, time usage, or monetary usage) associated with the subscriber.

[0045] In some embodiments, the Diameter client 300 may be a PCEF corresponding to the traffic of a mobile subscriber who is a member (e.g., a child member) of a shared resource plan, and the OCS node 202 may correspond to this subscriber and may be configured to perform any resource allocation. In such embodiments, the shared resource plan or the total amount of resources of the plan is managed by different OCS nodes (OCS node 204) within the OCS cluster 106.

[0046] In step 302, a Diameter credit control answer initial (CCA-I) message or another allocation response message may be sent from the OCS node 202 to the Diameter client 300, and the CCA-I message includes a granted service unit (GSU) AVP indicating an authorized amount of resources (e.g., 5 MB).

[0047] In some embodiments, the OCS node 202 may approve a resource allocation request without knowing whether the subscriber or the associated shared resource plan has sufficient remaining resources to approve the resource allocation request. In such embodiments (e.g., when the OCS node 202 does not know whether the resource allocation can be fully approved), the OCS node 202 may approve an amount of resources less than the amount requested by the Diameter client 300 for the subscriber.

[0048] In some embodiments, (e.g., when the OCS node 202 does not know whether a resource allocation request can be fully approved), the amount of resources initially approved by the OCS node 202 may be based on a predetermined value or ratio. For example, the predetermined value or ratio may be referred to as a minimum allocation and may be significantly less than the total initial amount of resources of the plan (e.g., the initial start resource allocation amount of the plan period). In this example, assuming that the total initial amount of resources (also referred to as the maximum amount) of the plan is 5GB, the minimum allocation may be 5MB, i.e., 1 / 1000 of the maximum amount.

[0049] In some embodiments, (e.g., when the OCS node 202 knows that a resource allocation request can be fully approved), instead of, or in addition to, providing a resource allocation less than the request, the amount of resources approved by the OCS node 202 may be associated with a "short" expiration time to indicate when the resource allocation expires. For example, the "short" expiration time may be a time (e.g., 30 seconds) shorter than the default or typical expiration time (e.g., 30 minutes) used for a fully approved resource allocation request. In this example, the "short" expiration time may be used to limit the impact on the service provider's revenue and / or as a trigger for the requesting entity (e.g., the Diameter client 300) to request a new resource allocation after the OCS node 202 secures resources from, for example, the OCS node 204 for a shared resource plan.

[0050] In some embodiments, (e.g., when the OCS node 202 knows that a resource allocation request can be fully approved), the amount of resources initially approved by the OCS node 202 may be for the requested resource amount. For example, if the OCS node 202 has previously secured sufficient resources for a shared resource plan, the OCS node 202 can approve a resource allocation request for an amount of resources less than or equal to the secured resource amount.

[0051] In step 303, a reservation request to reserve resources associated with the shared resource plan may be sent from OCS node 202 to OCS node 204. For example, OCS node 202 may be configured to use the reorder threshold as a trigger for OCS node 202 to reserve resources associated with the shared resource plan whenever the reserved resource amount of the shared resource plan reaches or falls below the reorder threshold. In this example, the reorder threshold may be a part of the maximum amount of the plan, for example, 25 MB or 5 out of 100 of the maximum amount of the plan which is 5 GB.

[0052] In some embodiments, the reservation request may reserve the amount of resources based on a predetermined value or ratio. For example, OCS node 202 may be configured to use an allocation reservation unit of 50 MB, that is, 1 out of 100 of the maximum amount of the plan which is 5 GB. In this example, OCS node 202 may request that 50 GB or a multiple thereof be reserved for the subscriber.

[0053] In step 304A, a reservation response to indicate that at least some of the requested resources have been reserved may be sent from OCS node 204 to OCS node 202. For example, if the remaining resource amount of the shared resource plan is sufficient, OCS node 204 may fully approve the reservation request (for example, reserve the requested resource amount) and notify OCS node 202. Similarly, in this example, if the remaining resource amount of the shared resource plan is not sufficient, OCS node 204 may partially approve the reservation request (for example, reserve only a part of the requested resource amount) and notify OCS node 202.

[0054] In step 304B, if the shared resource plan does not have any remaining consumable resources, a "no allocation" flag may be set to indicate this to the OCS node 202 and / or other nodes within the OCS cluster 106. For example, if the OCS node 204 determines that the shared resource plan does not have any remaining consumable resources, the OCS node 204 may notify the OCS node 202 and / or other OCS nodes within the OCS cluster 106. In this example, the OCS node 204 may set the "no allocation" flag in the memory shared or accessible by the OCS node 202 and / or other nodes within the OCS cluster 106. In another example, the OCS node 204 may send a message or otherwise trigger the OCS node 202 and / or other entities to set a local "no allocation" flag to indicate that the shared resource plan does not have any remaining consumable resources.

[0055] In some embodiments, for example, if the shared resource is credit or money being consumed, the OCS node 204 may notify the OCS node 202 and / or other OCS nodes within the OCS cluster 106 each time the subscriber-related charge (or the portion applicable to the shared plan) exceeds the available credit limit of the shared plan. In such embodiments, the OCS node 202 and / or other OCS nodes within the OCS cluster 106 may reject subsequent transactions involving that subscriber if such transactions require available credit until additional credit or money is applied or authorized to the shared plan, for example, by approval of the subscriber.

[0056] In step 305, a Diameter CCR update (CCR-U) message or another allocation request message may be sent from the Diameter client 300 to the OCS node 202. The CCR-U message includes an RSU AVP indicating the requested resource amount (e.g., 50 MB). For example, after a subscriber of a shared resource plan or the associated UE112 uses the initial or existing allocation amount, the Diameter client 300 may send a Diameter CCR-U message requesting an additional resource allocation related to the subscriber.

[0057] In some embodiments, the CCR-U message may include a used service unit (USU) AVP for indicating the amount of resources used by the subscriber. For example, the USU AVP may indicate the amount of usage units measured from the time the service became active or from the time the previous measurement ended. In this example, the usage information can be used for auditing, billing, and / or other purposes.

[0058] In step 302, a Diameter CCA update (CCA-U) message or another allocation response message may be sent from the OCS node 202 to the Diameter client 300. The CCA-U message includes a GSU AVP indicating the authorized resource amount (e.g., 50 MB).

[0059] In some embodiments, the OCS node 202 may authorize a resource allocation request based on the amount of reserved resources (e.g., the amount previously reserved via the OCS node 204). For example, if the OCS node 202 has access to the resources reserved for a subscriber of a shared resource plan, the OCS node 202 may provide a resource allocation up to the maximum amount of reserved resources and a resource allocation including this amount. In another example, if a predefined minimum allocation amount is greater than the amount of reserved resources, the OCS node 202 may provide a resource allocation of the minimum allocation amount.

[0060] In some embodiments, before authorizing or providing resource allocation, the OCS node 202 may determine whether the "no allocation" flag is set. For example, the setting of the flag may indicate that the shared resource plan does not have remaining consumable resources. In this example, if the flag is set (and there are no reserved resources available from previous reservations), the OCS node 202 may reject the resource allocation request or, in other ways, indicate to the Diameter client 300 that the allocation is not available.

[0061] Referring to FIG. 3B, in step 307, a Diameter CCR terminate (CCR-T) message or another allocation request message may be sent from the Diameter client 300 to the OCS node 202, and the CCR-T message includes a USU AVP indicating the amount of resources used by the subscriber. For example, after the subscriber of the shared resource plan or the associated UE 112 terminates or logs out of the session, the Diameter client 300 may send a Diameter CCR-T message to terminate the credit control session.

[0062] In step 308, a Diameter CCA terminate (CCA-T) message or another allocation response message may be sent from the OCS node 202 to the Diameter client 300 to indicate that the CCR-T message has been received and confirmed.

[0063] In some embodiments, the OCS node 202 can use usage information received from the Diameter client 300 (e.g., in a CCR-T) for billing, auditing, and / or other purposes. For example, the OCS node 202 may use the usage information associated with a subscriber to determine the amount of resources to be released. In this example, the OCS node 202 may determine that a significant portion of the resource allocation was not consumed based on the usage information received from the Diameter client 300, and thus, the OCS node 202 may release these resources or a portion thereof by sending a reservation release to the OCS node 204.

[0064] In step 309, a reservation release for releasing reserved resources (e.g., 25 MB) associated with the shared resource plan may be sent from the OCS node 202 to the OCS node 204. For example, after receiving the reservation release, the OCS node 204 may increase the remaining resource amount associated with the shared resource plan by the amount of resources to be released.

[0065] In some embodiments, the update process may occur when a subscriber charges (fulfills) or reloads the available resources of the shared resource plan. For example, a subscriber using the UE112 can interact with the billing system 110 to purchase additional resources (e.g., 5 GB of data or $50 in credit). In this example, the update process may include the billing system 110 notifying the OCS node 204 and / or other nodes within the OCS cluster 106, thereby triggering various operations (e.g., clearing or setting the deletion of the "no allocation" flag) that enable the Diameter client 300 to request and receive an additional resource allocation.

[0066] In step 310, a new allocation authorization indicating that the shared resource plan has additional resources to be consumed may be sent from the billing system 110 to the OCS node 204.

[0067] In step 311, the OCS node 204 may clear the "unassigned" flag (e.g., the local flag in the OCS 204), thereby indicating that it has resources consumed by the shared resource plan.

[0068] In step 312, the OCS node 204 may notify the OCS node 202 and other nodes within the OCS cluster 106 that it has resources consumed by the shared resource plan. For example, the OCS node 202 (and the OCS node 200) may receive a notification from the OCS node 204 indicating that a resource has been added to the shared resource plan, and in response, the OCS node 202 (and the OCS node 200) may clear its local flag, thereby indicating that it has resources consumed by the shared resource plan.

[0069] Figures 3A - 3B are for illustration purposes, and it will be understood that different and / or additional messages, steps, and / or operations from those shown in Figures 3A - 3B may be used. Also, it will be understood that the various messages, steps, and / or operations described herein may be performed in an order or sequence different from the order or sequence shown in Figures 3A - 3B.

[0070] FIG. 4 is a diagram illustrating an example of a process 400 for lock-free communication network resource allocation sharing. In some embodiments, process 400 or a portion thereof described herein may be executed by or within a network node (e.g., OCS node 202 or 204), QME 206, and / or another module or node. In some embodiments, process 400 or related operations may be executed by a first charging node (e.g., OCS node 202) of a distributed charging system (e.g., OCS cluster 106) associated with a communication network (e.g., environment 100) that includes a plurality of charging nodes, where the first charging node is for responding to a communication network resource allocation request associated with a first member (e.g., a child member) of a shared resource plan, and a second charging node (e.g., OCS node 204) manages resource reservation associated with the shared resource plan.

[0071] Referring to process 400, at step 402, a first communication network resource allocation request associated with a first member of a shared resource plan that requests a first amount of resources from the shared resource plan may be received from a requesting entity. For example, PGW 108 or Diameter client 300 may receive a network attachment request or other message indicating that a communication network subscriber requires communication network resource allocation. In this example, PGW 108 or Diameter client 300 may send a Diameter CCR message requesting a communication network resource allocation for use by a communication network subscriber to OCS cluster 106 or a node thereof (e.g., OCS node 202).

[0072] In step 404, without verifying that the shared resource plan has sufficient resources available to allocate the first resource amount, the first communication network resource allocation of the first member may be provided to the requesting entity, where the first communication network resource allocation indicates a second resource amount that is less than the first resource amount and / or the first communication network resource allocation is associated with an expiration time indicating when the first communication network resource allocation expires. For example, the OCS node 202 may be configured to provide the minimum allocation (e.g., a predetermined amount of resources) of a subscriber of the shared resource plan to the PGW 108 or the Diameter client 300 without locking the shared resource plan (or related account) and / or without receiving confirmation (e.g., from the OCS node 204 that manages the allocation and / or reservation of resources of the shared resource plan) that the requested resources are consumable. In another example, the OCS node 202 may be configured to provide the PGW 108 or the Diameter client 300 with a resource allocation having an expiration time indicating when the resource allocation for a subscriber of the shared resource plan expires. In this example, the expiration time may be a short time (e.g., 30 seconds) relative to the typical or default expiration time (e.g., 60 minutes) used when authorizing the resource allocation. Continuing with this example, after the resource allocation has expired, the PGW 108 or the Diameter client 300 will need to request another resource allocation (which may provide the OCS node 202 with sufficient time to request and reserve resources of the shared resource plan from the OCS node 204).

[0073] In step 406, a first resource reservation request for reserving resources of the shared resource plan may be sent to the second charging node. For example, after providing a minimum allocation (e.g., 2 MB) for a subscriber of the shared resource plan to PGW 108 or the Diameter client 300, the OCS node 202 may send a resource reservation request to the OCS node 204 so that the OCS node 202 reserves some resources of the shared resource plan and can use the reserved resources to approve subsequent communication network resource allocation requests for the subscriber.

[0074] In some embodiments, a first member of the shared resource plan may be allocated a communication network resource allocation simultaneously with the allocation of the communication network resource allocation to a second member of the shared resource plan. In such embodiments, the allocations distributed to different members may be the same amount or different amounts.

[0075] For example, the OCS node 200 and / or the associated QME 206 may execute an allocation-related transaction involving a first member of the shared resource plan, and the OCS node 202 and / or the associated QME 206 may simultaneously execute an allocation-related transaction involving a second member of the shared resource plan. In this example, the OCS node 200, the OCS node 202, and other OCS nodes within the OCS cluster 106 may use a lock-free allocation management algorithm that allows multiple allocation-related transactions associated with the shared resource plan to occur simultaneously (e.g., in parallel or nearly in parallel). In contrast, a lock-based allocation management system would prevent the processing of allocation-related transactions associated with the shared resource plan while a first allocation-related transaction associated with the shared resource plan is occurring, regardless of which OCS node within the OCS cluster 106 was corresponding to the allocation-related transaction.

[0076] In some embodiments, the first resource amount includes data usage, time usage, amount of money, or credit amount. For example, the PGW 108 may request a data usage allocation from the OCS node 202 and receive a data usage allocation from the OCS node 202 to access data and / or services via the communication environment 100. In another example, the PGW 108 may request a credit or money allocation from the OCS node 202 and receive a credit or money allocation from the OCS node 202 to charge for services or items associated with the communication environment 100.

[0077] In some embodiments, when the first resource reservation request is for reserving a resource amount that is greater than the remaining resource amount available for the shared resource plan, the second charging node (e.g., the OCS node 204) notifies the first charging node (e.g., the OCS node 202) by setting a flag indicating that there are no more consumable resources for the shared resource plan, and / or provides at least a portion of the resource amount requested in the first resource reservation request.

[0078] In some embodiments, the process 400 may include determining that the flag is not set before providing the first communication network resource allocation, where setting the flag indicates that there are no more consumable resources for the shared resource plan (e.g., no more Internet data to consume or no more money to spend).

[0079] In some embodiments, the process 400 may include receiving a reserved resource amount from the second charging node based on the first resource reservation request, receiving from the requesting entity a second communication network resource allocation request for requesting a third resource amount from the shared resource plan, and providing, to the requesting entity, a second communication network resource allocation for a first member of the shared resource plan using the reserved resource amount.

[0080] In some embodiments (e.g., when the third resource amount is more than the reserved resource amount, or when the reserved resource amount reaches or is below the reorder threshold), a second resource reservation request for obtaining additional data from the shared resource plan is requested from the second charging node.

[0081] In some embodiments, the communication network resource allocation request may include a Diameter message or a Diameter CCR. For example, PGW 108 may send a CCR-I message including an RSU AVP requesting communication network resource allocation to OCS node 202. In another example, a Diameter client 199 (e.g., PCEF) may send a CCR-U message including an RSU AVP to OCS node 200.

[0082] In some embodiments, the requesting entity in process 400 may include PGW 108, a Diameter network element, PCEF, BBERF, TDF, or a DPI function.

[0083] In some embodiments, the first charging node and the second charging node may be associated with a distributed OCS, such as OCS cluster 106.

[0084] FIG. 4 is for illustration purposes, and it will be understood that different and / or additional steps and / or operations may be used. It will also be understood that the various steps and / or operations described herein may occur in a different order or sequence.

[0085] Note that the charging node, OCS cluster 106, OCS nodes 200, 202, 204, QME 206, and / or the functions described herein may constitute a special-purpose computing device. Further, the charging node, OCS cluster 106, OCS nodes 200, 202, 204, QME 206, and / or the functions described herein may be capable of improving the technical fields of communication networks, OCS architectures, and resource sharing. For example, by utilizing lock-free communication network resource allocation sharing, latency and performance issues related to resource sharing and associated charging can be mitigated or prevented. Further, since no locks are required and associated lock overhead is avoided, a distributed OCS cluster utilizing lock-free communication network resource allocation sharing can reduce the complexity involved in scenarios where different members of a shared resource plan are processed by different nodes of the distributed OCS cluster.

[0086] It will be understood that the various details of the subject matter described herein may be changed without departing from the scope of the subject matter described herein. Further, the foregoing description is not intended to be limiting, but is for purposes of illustration only.

Claims

1. A computer-implemented method for lock-free communication network resource allocation and sharing, comprising: at a first charging node of a distributed charging system including a plurality of charging nodes, where the first charging node is for responding to a communication network resource allocation request associated with a first member of a shared resource plan, and a second charging node is for managing resource reservation associated with the shared resource plan, the method comprising: receiving, from a requesting entity, a first communication network resource allocation request requesting a first amount of resources from the shared resource plan; providing, to the requesting entity, a first communication network resource allocation for the first member, the first communication network resource allocation indicating a second amount of resources less than the first amount of resources and / or the first communication network resource allocation being associated with an expiration time indicating when the first communication network resource allocation expires; the method further comprising: sending, to the second charging node, a first resource reservation request for reserving resources of the shared resource plan; wherein the first resource reservation request is for receiving an amount of resources greater than the remaining amount of resources available in the shared resource plan, and the second charging node notifies the first charging node by setting a flag indicating that the shared resource plan has no more consumable resources and / or provides at least a portion of the amount of resources requested in the first resource reservation request.

2. A computer-implemented method according to claim 1, wherein simultaneously with the first communication network resource allocation being allocated to the first member, a third communication network resource allocation is allocated to a second member of the shared resource plan, wherein the amount of the third communication network resource allocation indicates the same or a different amount as the amount of the first communication network resource allocation to the first member.

3. wherein the first amount of resources includes a data usage amount or a time usage amount. The method realized by the computer according to claim 1 or 2, wherein the data usage amount or time usage amount includes the data usage amount or time usage amount corresponding to an amount of money or a credit amount.

4. The method realized by the computer according to any one of claims 1 to 3, comprising determining that a flag is not set before providing the first communication network resource allocation, wherein the flag indicates that the shared resource plan does not have any more consumable resources.

5. Receiving, from the second charging node, an amount of reserved resources based on the first resource reservation request; Receiving, from the requesting entity, a second communication network resource allocation request for requesting a third amount of resources from the shared resource plan; The method realized by the computer according to any one of claims 1 to 4, comprising providing, to the requesting entity, a second communication network resource allocation for the first member using the amount of reserved resources.

6. The method realized by the computer according to claim 5, comprising requesting the second charging node to make a second resource reservation request for securing additional resources of the shared resource plan.

7. The method realized by the computer according to any one of claims 1 to 6, wherein the requesting entity includes a Diameter network element, a packet data network gateway (PGW), a policy and charging enforcement function (PCEF), a bearer binding and event reporting function (BBERF), a traffic detection function (TDF), or a deep packet inspection (DPI) function.

8. The method realized by the computer according to any one of claims 1 to 7, wherein the first charging node and the second charging node are online charging system (OCS) nodes, and the first communication network resource allocation request includes a Diameter message or a Diameter credit control request (CCR).

9. A system for sharing communication network resource allocation, comprising: At least one processor; A memory; A system comprising a storage medium storing a program that, when executed by the at least one processor, causes the at least one processor to execute the method according to any one of claims 1 to 8, wherein the first charging node is implemented using the at least one processor and the memory. **Claim 10** A program that, when executed by at least one processor of a computer, causes the computer to execute the method according to any one of claims 1 to 8.

Images