System, method, and computer program for monitoring and allocating a quota for a user session associated with a service corresponding to a communication service provider (CSP)

A system, method, and computer program product are provided for monitoring and allocating a quota for a user session associated with a service corresponding to a communication service provider (CSP). In operation, at least one user session associated with at least one user is identified for allocation of quota information (e.g. information associated with quota size, timeout, etc.) for use of a service associated with a communication service provider. The allocation of the quota information is based on an available balance for use by the at least one user. Further, at least one consumption report of previous quotas associated with the at least one user session is evaluated to identify intervals with high correlation of used service units for consecutive quotas. Additionally, a dynamic quota to allocate to the at least one user session is determined for at least one time period based on the identified intervals with high correlation of used service units for consecutive quotas. The dynamic quota includes at least one calculated quota for at least one specific future time interval based on actual past service usage by the at least one user session for at least one specific past time interval. Moreover, the dynamic quota is allocated to the at least one user session for use of the service associated with the communication service provider.

FIELD OF THE INVENTION

The present invention relates to quota monitoring and allocation for services associated with communication service providers.

BACKGROUND

As part of data charging for services associated with communication service providers, there is a process including a reservation of a balance against a quota (e.g. the amount of Mbytes granted to the network). After timeout (e.g. around 15 min, etc.), the network responds with a usage report indicating the amount of the Mbytes granted that were actually used and then requests a new quota. All traditional online charging systems work in this manner according to the established standard.

Operators limit their credit risk by using real time charging systems where authorization of services is continuously under surveillance by the charging system. Irrespective of whether a subscriber is given a zero credit limit, thereby having to prepay for their services, or allowed a non-zero credit limit to be paid after the service is rendered (e.g. via a monthly bill, etc.), real time charging is used to ensure that the subscriber cannot exceed an allowed credit limit. For similar reasons, end users expect control over their charges and demand equally safe control over their spending.

In order to handle charging control while coping with the increased need for real time credit control, the 3rd Generation Partnership Project 3GPP has (in TS 32.299) specified Diameter based offline and online charging applications for 3GPP networks. Using the offline charging mechanism, charging information does not affect, in real-time, the service rendered.

In contrast, online charging is the charging mechanism where charging information can affect, in real-time, the service rendered and therefore a direct interaction of the charging mechanism with session/service control is required.

However, a problem with the charging architecture as defined by 3GPP is that it does not provide a mechanism to handle the increased signaling and load on the communication network or a way to optimize the quota size and timeout to minimize this increase of load.

SUMMARY

A system, method, and computer program product are provided for monitoring and allocating a quota for a user session associated with a service corresponding to a communication service provider (CSP). In operation, at least one user session associated with at least one user is identified for allocation of quota information (e.g. information associated with quota size, timeout, etc.) for use of a service associated with a communication service provider. The allocation of the quota information is based on an available balance for use by the at least one user. Further, at least one consumption report of previous quotas associated with the at least one user session is evaluated to identify intervals with high correlation of used service units for consecutive quotas. Additionally, a dynamic quota to allocate to the at least one user session is determined for at least one time period based on the identified intervals with high correlation of used service units for consecutive quotas. The dynamic quota includes at least one calculated quota for at least one specific future time interval based on actual past service usage by the at least one user session for at least one specific past time interval. Moreover, the dynamic quota is allocated to the at least one user session for use of the service associated with the communication service provider.

DETAILED DESCRIPTION

FIG. 1illustrates a method100for monitoring and allocating a quota for a user session associated with a service corresponding to a communication service provider (CSP), in accordance with one embodiment.

As shown, at least one user session associated with at least one user is identified for allocation of quota information for use of a service associated with a communication service provider. See operation102. The allocation of the quota information is based on an available balance for use by the user. The quota information may include any information associated with a quota, such as quota size, timeout information, etc. The quota may be associated with data and/or voice, etc. The user session may include a user call session and/or a data usage session, etc.

Further, at least one consumption report of previous quotas associated with the user session is evaluated to identify intervals with high correlation of used service units for consecutive quotas. See operation104. The consumption report may include any data associated with previous quotas and the amount consumed.

Additionally, a dynamic quota to allocate to the user session is determined for at least one time period based on the identified intervals with high correlation of used service units for consecutive quotas. See operation106. The dynamic quota includes at least one calculated quota for at least one specific future time interval based on actual past service usage by the user session for at least one specific past time interval.

Moreover, the dynamic quota is allocated to the user session for use of the service associated with the communication service provider. See operation108. This may include allocating more data and/or voice minutes, etc.

It should be noted that the method100may be implemented utilizing various systems, hardware, software, applications, user interfaces, etc., as dictated by the implementer. For example, the method100may be implemented by a quota allocation system that includes one or more processors, etc. More illustrative information will now be set forth regarding various optional architectures and uses in which the foregoing method may or may not be implemented, per the desires of the user. It should be strongly noted that the following information is set forth for illustrative purposes and should not be construed as limiting in any manner. Any of the following features may be optionally incorporated with or without the exclusion of other features described.

As previously indicated, one problem with the current charging architecture as defined by 3GPP is that it does not provide a mechanism to handle the increased signaling and load on the communication network or a way to optimize the quota size and timeout to minimize this increase of load.

Accordingly, in one embodiment, the system (e.g. the quota allocation system ofFIG. 9, etc.) and techniques described herein may be utilized produce a dedicated detailed record for each quota (not only for the entire session). Since the reservation is done at a different point in time from the report against this allocation, it is complicated to conduct a correlation after-the-fact. The detailed record (DR) generated by the system (referred to herein as “Quota DR”), may be generated with data associated with both allocation and reports.

FIG. 2shows an example graph200showing quota allocation time and reporting time, in accordance with one embodiment. As an option, the graph200may be viewed in the context of the details ofFIG. 1and/or any subsequent figure(s). Of course, however, the graph200may be viewed in the context of any desired environment. Further, the aforementioned definitions may equally apply to the description below.

As shown, the graph200shows Granted Service Units (GSU) (i.e. Quota Size) and Used Service Units (USU) (i.e. the actual consumption).

The detailed record generated by the system (i.e. the Quota DR) may be used for further analysis (e.g. Big Data analysis, etc.), to recommend the best quota settings (e.g. size and expiration time, etc.) for different scenarios.

The system for generating Quota DR offers a solution for Quota Allocation tradeoff. Simply using a large quota is problematic to work with, because a large quota reduces subscriber balance immediately and limits simultaneous sessions. Whereas, a small quota increases the load on systems because of the need to reallocate frequently.

Many current systems provide “Static Quota” solutions, which includes a constant size of quota (and also constant Timeout, referred to as Validity Time [VT]). There could be several cases based on rating criteria at the beginning of a data session that would result in different “Static Quota” values. However, once a session begins, there are no changes to the quota settings.

FIG. 3shows an example graph300showing quota size versus validity time, in accordance with one embodiment. As an option, the graph300may be viewed in the context of the details of the previous figures and/or any subsequent figure(s). Of course, however, the graph300may be viewed in the context of any desired environment. Further, the aforementioned definitions may equally apply to the description below.

The validity time (VT) may also be referred to as a Quota Timeout. There may be many scenarios where a quota size was too big or too small, thus decreasing the utilization of a system. If the quota size were closer to the “ideal” allocation, then the load of quota requests per second, per system, would be lower.

To address this issue, the system described herein (e.g. the quota allocation system ofFIG. 9, etc.) may implement a “Dynamic Quota” allocation process to increase utilization. In this case, in a certain data session, there may be many quotas that have a high correlation to the previous quotas from a consumption perspective.

FIG. 4shows an example graph400showing high and low consumption periods for a user session, in accordance with one embodiment. As an option, the graph400may be viewed in the context of the details of the previous figures and/or any subsequent figure(s). Of course, however, the graph400may be viewed in the context of any desired environment. Further, the aforementioned definitions may equally apply to the description below.

In one embodiment, the system for quota allocation and for generating Quota DR may generate a Quota DR including a detailed record per quota allocation and usage, and also implement a scoring module (as fields in the Quota DR) that will give empiric results showing exactly how much the dynamic allocation increased utilization over a static allocation. This scoring module may also be implemented when the actual dynamic allocation is not enabled (e.g. static is the default) and can show “what if” results for a given setup.

FIG. 5shows a diagram500of a system workflow for a scoring module, in accordance with one embodiment. As an option, the diagram500may be viewed in the context of the details of the previous figures and/or any subsequent figure(s). Of course, however, the diagram500may be viewed in the context of any desired environment. Further, the aforementioned definitions may equally apply to the description below.

Data (volume) consumption, unlike voice (time) consumption, must work with quota allocations provided from OCS to the Network Element (NE) that controls the actual usage of the quota. The OCS relies on NE feedback regarding the actual usage. The OCS cannot anticipate when the NE will return back with a new quota request, unlike in time-based where the OCS may run a timer.

FIG. 6shows graphs600showing data and voice consumption versus time, in accordance with one embodiment. As an option, the graphs600may be viewed in the context of the details of the previous figures and/or any subsequent figure(s). Of course, however, the graphs600may be viewed in the context of any desired environment. Further, the aforementioned definitions may equally apply to the description below.

The quota mechanism requires the OCS to secure the balance that the quota is “worth”. This balance is kept “aside” and is refereed as the “Reservation”. The reservation ensures that when the actual usage is reported by the Network Element, the OCS will have enough balance from which to debit.

When the session ends, all reservations that are not used must be returned to the balance. This quota mechanism also enables simultaneous sessions to run in parallel, as each has its own reservation, and therefore there is no concern for a fraud situation.

The quota size is a tradeoff between being too big (which may cause a situation where a new session in parallel will not have enough balance left for reservation, thus affecting service and a potential loss of revenue, etc.) and being too small (which causes an overload of messages in Diameter and towards OCS, thus affecting capacity).

The 3GPP (32.299) defines the following Online Rating Flow: Session Charging with Unit Reservation (SCUR), which is relevant for long data sessions [CCR(I), several CCR(U) and CCR(T)].

FIG. 7shows a diagram700of a system workflow including CTF and OCS, in accordance with one embodiment. As an option, the diagram700may be viewed in the context of the details of the previous figures and/or any subsequent figure(s). Of course, however, the diagram700may be viewed in the context of any desired environment. Further, the aforementioned definitions may equally apply to the description below.

Quota DR is generated by the system for a quota at the time of reporting on its consumption and not at the time it was allocated. Thus, the OCS service will start preparing the Quota DR in step4in the diagram ofFIG. 7and the Quota DR will be concluded and generated in step6(same with steps8and10).

Thus, one improvement over conventional systems is generating statistics that OCS does as part of its logic and reservation logic that is run regardless. If the Quota DR is not generated by the OCS, it would have to be done afterwards in a data warehouse, which may be problematic in some cases as it will require OCS to generate separate reservation and consumption dedicated records per quota handling, and a correlation between pairs for the same quota.

In some cases, there could be tens of quotas per real-time subscriber, per day, so allocation can be a challenging task. With growth of data, this is only expected to grow.

Based on the Quota DR statistics, and based on the utilization (which is the USU/GSU factor), the system described herein may be utilized to set an appropriate quota size that will be best for the trade-off. The quota size is defined differently for each scenario, for example, per rating group (rating conditions), per RAT (Radio Access Technology, like 3G, LTE, etc.), etc.

Thus, there are multiple decisions per system, and such decisions may change over time, so usage, etc., needs to be monitored in an ongoing manner.

The system generates the Quota DR, which is on top of logic the OCS is running as part of standard OCS charging flow.

The system uses the scoring as a mechanism to empirically show if and by how much utilization has better results due to: change in static quota parameters; dynamic allocation over the static allocation; and “what if” scenarios applied to past results.

FIG. 8shows a diagram800illustrating how to generate dynamic and static quota scoring retroactively for a past quota, in accordance with one embodiment. As an option, the diagram800may be viewed in the context of the details of the previous figures and/or any subsequent figure(s). Of course, however, the diagram800may be viewed in the context of any desired environment. Further, the aforementioned definitions may equally apply to the description below.

It should be noted that the system described herein may perform quota allocation, generation of quota detailed reports (Quota DR), and/or scoring. Further, such system may include various hardware (e.g. memory, processors, servers, etc.) and may be associated with one or more communication service providers, billing systems, charging systems, etc.

In one embodiment, to generate the Quota DR, the system may implement a method, comprising: a) identifying at least one user session for allocation of a quota information (e.g. size, timeout, etc.) for use of a service associated with a communication service provider, where the quota allocation is based on available balance for use by the at least one user; b) determining at least one quota to allocate and balance reservation to the at least one user session for at least one time period; c) generating a record for each determined quota once its consumption report is received (one record per specific quota), where the report includes information associated with allocation and reporting of a single quota and also additional relevant protocol; and d) calculating utilization (consumption versus allocation) data corresponding to the at least one quota utilizing the generated record corresponding to the at least one quota. In this case, steps “a” and “b” may be according to industry Standard (RFC 4006) and may be common to all OCS (Online Charging Systems). With respect to step “c”, additional information may include Rating Group (linked to applications) and RAT (Radio Access Technology, like 3G, LTE, etc.), etc. Further, Quota DRs may be used as a basis for analytics and optimization.

Additionally, in one embodiment, the system may implement Quota Scoring by implementing a method, comprising: a) determining a grade that reflects the match between allocation and actual consumption based on a scoring method with a single scoring scale for both Service Units and Time based on information recorded in the Quota DR. The system may also implement a technique for comparing a score between alternative quota allocations to provide an overall empiric comparison as to improvement: between old static and new (changed) static allocations; between existing static and potential static allocations (i.e. a ‘what if’ scenario); and between static (non-dynamic) and dynamic quota.

Further, in one embodiment, the system may perform quota allocation by implementing a method, comprising: a) based on history of Quota DRs, identifying scenarios including intervals with high correlation of used service units for consecutive quotas where a dynamic quota is best to be used; b) determining a dynamic quota to allocate to the at least one user session for at least one time period based on the identified intervals with high correlation of used service units for consecutive quotas, the dynamic quota (combination of size (Granted Service Units) and timeout (Validity Time)) including at least one calculated quota for at least one specific future time interval, based on actual past service usage by the at least one user session for at least one specific past time interval; and c) allocating the dynamic quota to the at least one user session for use of the service associated with the communication service provider. In this case, steps “b” and “c” are innovative in that new quota allocation is also changing the default Validity Time and not only the Quota Size.

Quota DRs are beneficial for calculating systems measurements such as, for example: System Utilization as a percentage (Aggregative USU/Aggregative GSU); System Consumed Bandwidth in Gbytes per sec (by Aggregative USU/Time Interval); and System Consumed Load in Quota Requests per sec (by Aggregative Quota DR Count/Time Interval). All of these can be according to breakdown of dimensions within the Quota DR fields such as Rating Group/RAT/Time of day, etc. Extensions of Quota Validity Time in low usage scenarios (instead of going below a minimum Quota size) may also be used to reduce load.

FIG. 9shows a system900for monitoring and allocating a quota for a user session associated with a service corresponding to a communication service provider, in accordance with one embodiment. As an option, the system900may be implemented in the context of the details of the previous figures and/or any subsequent figure(s). Of course, however, the system900may be implemented in the context of any desired environment. Further, the aforementioned definitions may equally apply to the description below.

As shown, the system900includes a quota allocation system904, which may implement a variety of applications or software, etc. The quota allocation system904may be capable of communicating with a plurality of systems906, either directly or over one or more networks902.

The quota allocation system904is also in communication with one or more repositories/databases908.

In operation, the quota allocation system904identifies at least one user session associated with at least one user for allocation of quota information for use of a service associated with a communication service provider. The allocation of the quota information is based on an available balance for use by the user.

The quota allocation system904evaluates at least one consumption report of previous quotas associated with the user session to identify intervals with high correlation of used service units for consecutive quotas. Further, the quota allocation system904determines a dynamic quota to allocate to the user session for at least one time period based on the identified intervals with high correlation of used service units for consecutive quotas. The dynamic quota includes at least one calculated quota for at least one specific future time interval based on actual past service usage by the user session for at least one specific past time interval.

Moreover, the quota allocation system904allocates the dynamic quota to the user session for use of the service associated with the communication service provider.

In one embodiment, the quota allocation system904may also compare a score between a static (non-dynamic) quota and the dynamic quota to provide an overall empiric comparison as to improvement. Additionally, the quota allocation system904may identify scenario intervals with high correlation of used service units for consecutive quotas where the dynamic quota is best to be used, based on a history of quota detailed reports (DRs).

In one embodiment, the quota allocation system904may generate quota DRs by: identifying at least one user session associated with a user for allocation of quota information (e.g. information associated with quota size, timeout, etc.) for use of a service associated with a communication service provider, the quota allocation being based on an available balance for use by the at least one user; determining at least one quota and balance reservation to allocate to the at least one user session for at least one time period; generating a record for each determined quota once a corresponding consumption report is received (one record per specific quota), the report including information associated with allocation and reporting of a single quota and also additional relevant protocol; and calculating utilization (consumption versus allocation) data corresponding to the at least one quota utilizing the generated record corresponding to the at least one quota.

Still yet, in one embodiment, the quota allocation system904may determine a grade that reflects the match between allocation and actual consumption based on a scoring method with a single scoring scale for both service units and time.

FIG. 10illustrates a network architecture1000, in accordance with one possible embodiment. As shown, at least one network1002is provided. In the context of the present network architecture1000, the network1002may take any form including, but not limited to a telecommunications network, a local area network (LAN), a wireless network, a wide area network (WAN) such as the Internet, peer-to-peer network, cable network, etc. While only one network is shown, it should be understood that two or more similar or different networks1002may be provided.

Coupled to the network1002is a plurality of devices. For example, a server computer1004and an end user computer1006may be coupled to the network1002for communication purposes. Such end user computer1006may include a desktop computer, lap-top computer, and/or any other type of logic. Still yet, various other devices may be coupled to the network1002including a personal digital assistant (PDA) device1008, a mobile phone device1010, a television1012, etc.

FIG. 11illustrates an exemplary system1100, in accordance with one embodiment. As an option, the system1100may be implemented in the context of any of the devices of the network architecture1000ofFIG. 10. Of course, the system1100may be implemented in any desired environment.

As shown, a system1100is provided including at least one central processor1101which is connected to a communication bus1102. The system1100also includes main memory1104[e.g. random access memory (RAM), etc.]. The system1100also includes a graphics processor1106and a display1108.

The system1100may also include a secondary storage1110. The secondary storage1110includes, for example, a hard disk drive and/or a removable storage drive, representing a floppy disk drive, a magnetic tape drive, a compact disk drive, etc. The removable storage drive reads from and/or writes to a removable storage unit in a well-known manner.

Computer programs, or computer control logic algorithms, may be stored in the main memory1104, the secondary storage1110, and/or any other memory, for that matter. Such computer programs, when executed, enable the system1100to perform various functions (as set forth above, for example). Memory1104, storage1110and/or any other storage are possible examples of non-transitory computer-readable media.

The system1100may also include one or more communication modules1112. The communication module1112may be operable to facilitate communication between the system1100and one or more networks, and/or with one or more devices through a variety of possible standard or proprietary communication protocols (e.g. via Bluetooth, Near Field Communication (NFC), Cellular communication, etc.).