[0001] The present disclosure relates to policy and charging control applications, and more specifically, relates to a method and a system for rule-based database proxy to be implemented between an application and a database. The present application is based on and claims priority from an Indian Application Number 202011038535 filed on 7th Sept 2020, the disclosure of which is incorporated herein.

BACKGROUND
[0002] Database management system (or database or DBMS) plays an important role in data storage and retrieval in a computing environment. Different types of databases may be a distributed database, an operational database, a NoSQL database, a relational database, a reference database, a centralized database, an in-memory data base, Combination of SQL and NO-SQL Database, an end-user database, or the like. A typical database handles a large amount of incoming data and organizes it to further provide the data to a user in a required form, which is generally extracted using a set of queries or a user command. These databases typically execute a large number of transactions. Contrarily, due to the large number of transactions, the database fails to achieve scalability and resilience as response time to handle and return required information increases.
[0003] Thus, a system that needs to support a high transaction database becomes a bottleneck as it is not scalable and resilient. To resolve the aforesaid issues, several solutions have been suggested. One of the solutions is using a database proxy. The database proxy acts as a middleware to smoothen the database transactions by filtering out calls to the database from an application and make it scalable. In the current solutions, the database proxy usually uses a cache to keep data handy for faster response. The cache may be implemented in two ways i.e., either as an individual cache or as a centralized cache.
[0004] However, having the individual cache for each database proxy means the database proxy can handle a limited amount of information or calls at a time, else needs to refresh the cache all the time. Similarly, having the centralized cache means that cache will become the bottleneck if multiple instances of database proxy are accessing the same cache. Thus, using the cache in the database proxy does not reduce the transaction processing time and fails to scale-out the transactions between the application and the database. Further, the use of the cache in the database proxy requires hardware resources such as storage, which may be problematic in case of limited hardware resources and may lead to slower response time during high transactions.
[0005] For example, in a prior art reference “Improving Application Performance with No Code Changes Using Heimdall’s Database Proxy for Amazon Redshift”, the Heimdall proxy routes queries to appropriate database instances without code changes and allows load balancing across replicas for better utilization, avoiding DNS issues, due to which users receive up-to-date data with replication lag detection.
[0006] Further, in a prior art reference “Database Load Balancing for MySQL and MariaDB with ProxySQL”, ProxySQL understands MySQL protocol, where rules engine matches incoming traffic, and defines whether to cache a query, or block, re-route, re-write or mirror it onto a hostgroup target.
[0007] Further, a prior art reference “US9118763B1” discloses customer service, customer feedback and voice-of-the-customer infrastructure, and more particularly, teaches automating and aggregating actionable, rules-based actions to connect users with customer service agents in real time or to schedule mass communications on behalf of the enterprise.
[0008] Furthermore, a prior art reference “US9065765B2” discloses a proxy server or component associated with or residing on a mobile carrier or mobile operator side for enhancing mobile traffic management in a mobile network. The proxy server, can delay, clump, block or otherwise manage incoming traffic initiated by one or more application servers and directed to one or more mobile applications associated with the one or more applications servers installed on a mobile device. The proxy server can manage the incoming traffic based on traffic category, time criticality, priority and/or other criteria. The proxy server can further transfer the traffic that was delayed to the mobile device in response to a trigger such as promotion of a radio state on the mobile device or a start of an interval for transferring incoming to the mobile device and outgoing traffic from the mobile device.
[0009] In light of above discussion and in consideration with prior-arts, there remains a need for a scalable database proxy implementation between the application and the database to execute the large number of transactions with the faster response time.
[0010] Any references to methods, apparatus or documents of the prior art are not to be taken as constituting any evidence or admission that they formed, or form part of the common general knowledge.

OBJECT OF THE DISCLOSURE
[0011] A principal object of the present disclosure is to provide a method and a system for implementing a rule-based database proxy between an application and a database.
[0012] Another object of the present disclosure is to provide a scalable and resilient rule-based database proxy system and method.
[0013] Another object of the present disclosure is to provide the rule-based database proxy that executes large number of transactions with the faster response time and without any hardware resource constraint.

SUMMARY
[0014] Accordingly, the present disclosure provides a scalable database proxy implementation between an application and a database to execute the large number of transactions with the faster response time. The database proxy is a rule-based database proxy. The rule-based database proxy contains a set of rules that works on an input received from the application i.e., PCC (Policy and Charging Control) and can be evaluated by pre-defined rules. The rule-based database proxy provides scalability between the PCC and the database during high transactions (load) without any limit. Further, the rule-based database proxy does not maintain any state or save information related to an operation. Further, the rule-based database proxy filters calls to the database from the application (PCC).
[0015] To provide scalability, the rules are made common to all instances of the database proxy. If any proxy instance goes down, another instance takes up the load as there is no extra information required for the database proxy to work. The present disclosure implements the rule-based database proxy wherein any new instance can come up and start handling the high transaction load immediately.
[0016] These and other aspects herein will be better appreciated and understood when considered in conjunction with the following description and the accompanying drawings. It should be understood, however, that the following descriptions, while indicating preferred embodiments and numerous specific details thereof, are given by way of illustration and not of limitation. Many changes and modifications may be made within the scope of the embodiments herein without departing from the spirit thereof, and the embodiments herein include all such modifications.

BRIEF DESCRIPTION OF FIGURES
[0017] The method and system are illustrated in the accompanying drawings, throughout which like reference letters indicate corresponding parts in the drawings. The embodiments herein will be better understood from the following description with reference to the drawings, in which:
[0018] FIG. 1 is an example system implementing a rule-based database proxy for transaction management.
[0019] FIG. 1A illustrates an architecture of an application of the system of FIG. 1.
[0020] FIG. 2 is an example rule implementation for a subscription lookup.
[0021] FIG. 3 is an example rule implementation for a real-time quota provision.
[0022] FIG. 4 is an example rule implementation for a session lookup.
[0023] FIG. 5 is an example rule implementation for a subscriber lookup.
[0024] FIG. 6 is an example rule implementation for a monetary balance lookup.
[0025] FIG. 7 is an example rule implementation for a non-monetary balance lookup.
[0026] FIG. 8 is an example rule implementation for a dependent transaction check.
[0027] FIG. 9 is a flow-chart illustrating a method of transaction management in an application.

DETAILED DESCRIPTION
[0028] In the following detailed description of embodiments of the invention, numerous specific details are set forth in order to provide a thorough understanding of the embodiment of invention. However, it will be obvious to a person skilled in the art that the embodiments of the invention may be practiced with or without these specific details. In other instances, well known methods, procedures and components have not been described in details so as not to unnecessarily obscure aspects of the embodiments of the invention.
[0029] Furthermore, it will be clear that the invention is not limited to these embodiments only. Numerous modifications, changes, variations, substitutions and equivalents will be apparent to those skilled in the art, without parting from the scope of the invention.
[0030] The accompanying drawings are used to help easily understand various technical features and it should be understood that the embodiments presented herein are not limited by the accompanying drawings. As such, the present disclosure should be construed to extend to any alterations, equivalents and substitutes in addition to those which are particularly set out in the accompanying drawings. Although the terms first, second, etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are generally only used to distinguish one element from another.
[0031] The present disclosure achieves a method and a system for rule-based database proxy. The rule-based database proxy contains a set of rules that works on an input received and can be evaluated by pre-defined rules. As the database proxy is rule-based, it can provide scalability between an application and a database during high transactions without any limit. Since, the database proxy is rule-based, there is no need for the database proxy to maintain any state or save information unlike conventional database proxies. The rule-based database proxy filters calls to the database from the application.
[0032] Further, the rules are common to all instances of the database proxy. Thus, if any proxy instance goes down, another instance can take up the load as there is no extra information required for it to work. The present disclosure achieves a method and a system for rule-based database proxy wherein any new instance can come up and start handling the high transaction load immediately.
[0033] Unlike conventional database proxies, there is no need to cache and refresh information at database proxy level. Further, there is no need to have a centralized cache for transaction handling. The present disclosure provides horizontal scaling using the rule-based database proxy, wherein the rules return information to the application rather than storing the information in the cache.
[0034] Referring now to the drawings, and more particularly to FIGS. 1 through 8.
[0035] FIG. 1 is an example system (100) implementing a rule-based database proxy (or database proxy) (104) for transaction management. The system (100) includes an application (102) and a database (106) implementing the database proxy (104).
[0036] The application (102) may be a framework or a server that operates and hosts applications for end users. The application (102) may be related to email, e-commerce, web application or the like. The applications reside in a device or a user equipment present with the end users. The device may be any type of computing device, such as, but not limited to, mobile phone, laptop, personal computer. The applications are accessible via a user interface of the device. The application (102) provides environment to run the applications.
[0037] FIG. 1A illustrates an architecture of the application (102) of the system (100) of FIG. 1. The application (102) corresponds to a Policy and Charging Control (PCC). The Policy and Charging Control (PCC), also known as an integrated PCC, is a policy management that enables operators to dynamically control network resources with real-time policies based on service, subscriber or usage context.
[0038] As shown in FIG. 1A, an Application Function (AF) (110) is an element implementing applications that require dynamic policy and/or charging control of traffic plane resources. A Policy and Charging Enforcement Function (PCEF) (120) provides service data flow detection, charging, and policy enforcement of the user plane traffic. Further, a Policy and Charging Rules Function (PCRF) (130) is a separate logical node and sits in between of the Application layer (e.g., service offering sources/applications on subscriber device/user equipment), where services (e.g., for example, stream live match, telecommunication-based services, data-file request, and the like) are initiated and service characteristics are negotiated, and the user plane where the actual service is being provided. The PCRF (130) provides policy and flow-based charging control functions, using subscriber data stored in a Subscription Profile Repository (SPR) (150) (defining the subscription details that user has subscribed to for example, Gold Package subscription for viewing the Direct-to-Home (DTH) television services). The PCRF (130) receives service information (e.g., application identifier, type of media, bandwidth, IP address and port number) from the AF (110) over the Rx interface, and uses this to install PCC rules into the PCEF (120) which in turn ensures that only authorized media flows associated with the requested services are allowed, and that the correct bandwidth, charging and priority are applied. The PCEF (120) provides real-time charging information (for e.g., prepaid services) to an Online Charging System (OCS) (140) over a Gy interface and generates reports for an Offline Charging System (OFCS) regarding resource usage (for e.g., postpaid services) over a Gz interface. In general, Gy interface functions as DCCA (Diameter Credit-Control Application) proxy between the PCEF (120) and the OCS (140) to allow online credit control and Gz interface is used as an offline charging interface.
[0039] The AF (110) may modify session Information at any time, for example due to an AF session modification or internal AF trigger. Modification is achieved by the AF (110) sending an AA-Request command to the PCRF (130) over the Rx reference point containing the Media-Component-Description Attribute-Value Pairs (AVPs), with the updated service Information as defined in communication standards. The PCRF (130) processes the received service information according to the operator policy and may decide whether the request is accepted or not. If the request is accepted, the PCRF (130) updates the pre-existing service information with the new information. The updated service information may require the PCRF (130) to create, modify or delete the related PCC rules and provide the updated information towards the PCEF (120) over the Gx reference point as specified in communication standards. Typically, Gx interface is used to provision service data flow as per charging rules between the PCRF (130) and the PCEF (120). The procedures used to update the Authorized QoS for the affected IP-CAN bearer are also specified in communication standards. Currently specified procedures for modification of the service information for PCC provide for the immediate activation, replacement and removal of filter description information at the PCEF (120).
[0040] As can be derived from aforementioned description, the PCEF (120) can be an access gateway or an interface or gateway configured to receive a request such as, but not limited to, subscription request from the user equipment (170).
[0041] The database (106) is associated with a respective application. The database may be, but not limited to, a distributed database, application database, reference database, an operational database, a NoSQL database, combination of SQL and NoSQL database, in-memory database, a relational database, a centralized database, an end-user database. Upon requests made by the end user via the application residing in the device, the application (102) communicates with the database (106) to return relevant information to the end user. Herein, the end user or the user is a customer or subscriber who is a consumer of services provided by the telecommunication service providers. The end user may be an individual or an organization.
[0042] The database proxy (104) acts as a middleware between the application (102) and the database (106) to handle transactions. The database proxy (104) may reside in the application (102). Alternatively, the database proxy (104) may reside in the database (106). Alternatively, the database proxy (104) may act as an independent component/entity. The database proxy (104) acts as an intelligent proxy that utilizes rules for scheduling of transactions from the application (102). The database proxy (104) runs on multiple instances and provides scaling capabilities whenever required, without any hardware resource constraint. The database proxy herein is a rule-based database proxy that does not essentially require caching of transactions, before sending it to the database (106), for processing purposes. The rules itself decide if the transaction information should go to a queue for batch processing or if it should go to the database for real-time processing or if it needs to be dropped, in case processing of transaction is not required. The database proxy (104) filters transactions to the database (106), which is a main database.
[0043] In an example, the database proxy (104) schedules queries to be processed at the database (106) based on a user subscription information. The database proxy (104) implements multiple rules without cache and schedules call transaction processing to the database (106) based on a rule checking process that performs scheduling of call transactions as processing transaction as queue or batch if a user plan (or package) is unlimited, processing transactions in real-time if the user plan is limited and number of remaining calls is less than a threshold, processing transaction as queue or batch, if the user plan is limited and number of remaining calls is greater than the threshold, and performing dropping of a transaction request sending to the database that must have already taken place (in case of dependent calls).
[0044] In general, the user plan or package (also be referred to as user service plan) is an agreement between a telecommunication service provider and the end user that specifies how much voice and/or data the end user can access for a specific period and for a specific fee. The limited user service plan corresponds to a plan with restricted amount of voice, data or both in a specific fee for a specific period. For e.g., 1 GB data and 120 minutes of voice calls at 100/- for one month. On the other hand, the unlimited user service plan corresponds to a plan without usage limitation of voice, data or both.
[0045] It is evident from the above disclosure, that the application (102) communicates with the database (106) via the database proxy (104). The term “database proxy” and “rule-based database proxy” may interchangeably be used throughout the present disclosure.
[0046] Once a transaction request (or a query (or queries) or a transaction data or a request) is initiated by the user equipment (170), it is transmitted to the application (102). The application (102) creates session, makes an authorization check and fetches a complete profile of the subscriber including subscriptions or pack information based on the transaction request. The application (102) routes the transaction request to the database proxy (104) for processing, where the database proxy (104) analyzes the transaction request before sending it to the database (106) by applying rules on the transaction request and decides the scheduling/filtering of the transaction request, that is to be sent to the database (106). The database proxy (104) is capable to perform scheduling/filtering of transaction request to the database (106) based on rules stored in it. In an example, the database proxy (104) transmits the transaction request to the database (106) based on a user subscription plan (or available balance).
[0047] In an example, the transaction request may be related to voice, data, message, mms or any event or services. When the transaction request from the application (102) is sent to the database (106) for processing, the database proxy (104) pre-processes data by applying the rules stored in it and decides the scheduling/filtering of the call, data, voice, message, mms, events or services and processing data, that is to be sent to the database (106).
[0048] In an example, a rule may be related to unlimited plan (or package) for voice and/or data. In case, if the end user has the unlimited plan for voice and/or data, the database proxy (104) adds the transaction request in a queue to update database offline for batch processing. In another example, the rule may be related to a limited plan for voice, data, message, mms, any event or services . In case, if the end user has the limited plan for voice and/or data, the database proxy (104) performs read/write operation in real-time. The read/write database operation is performed in real-time, when the end-user has remaining number of calls less than the threshold, wherein a reserve call is decided by a telecommunication service provider. Thereafter, the transaction request (a call transaction data) is added in a queue for batch processing, when the end user has remaining number of calls in abundant, i.e., greater than the threshold. The threshold may be a pre-defined value defined by the telecommunication service provider according to the voice and/or data plans.
[0049] For instance, if the end-user (or the user or the subscriber) is assigned with 10GB data and unlimited calls and has consumed 1GB data or subscriber has 1000$ as a monetary balance and consumed 100$. The database proxy (104) will check that 10GB is limited but the user has consumed 1GB only and 9GB data is still available or proxy will check that 1000$ is limited but subscriber has consumed only 100$ and the same will be routed to and uploaded in the database in offline mode to save hits of the transaction request on the database (106). Similarly, if the user has consumed 80% of the data limit, the database proxy (104) will consider the transaction request as an update for the database (106) in real-time, so that user’s service does not get affected. This transaction request will be routed to the database (106) in real time and a response will be sent to the user equipment as a message/alert/notification.
[0050] In yet another example, the rule may be related to dependent calls. When any of the transactions starts, the application (102) checks for authentication of the end-user, so no separate check for the authentication of the end-user is required. In case of dependent calls, the database proxy (104) performs dropping of the call transaction data sending to the database (106) which must have already taken place, i.e., dropping data corresponding to the Gx interface, if the call transaction data corresponding to the Gy interface is received. As mentioned earlier (in FIG. 1A), the Gx interface is located between the Policy and Charging Rules Function (PCRF) and the Policy and Charging Enforcement Function (PCEF) and used for provisioning and removal of PCC (Policy and Charging Control) rules from the PCRF to the PCEF and transmission of traffic plane events from the PCEF to the PCRF. The Gx interface may be used for traffic detection and control of the application (102). Further, the Gy interface allows online credit control for service data flow-based charging. The Gy interface resides between the Online Charging System (OCS) and the PCEF and the PCEF obtains credits from the OCS via the Gy interface. The Gx interface is dependent on the Gy interface, where the Gx interface takes care of connection such as whether the end-user is connected or not, details of user and the Gy interface takes care of consumption of data by the end-user or which plan the end-user has subscribed to, and remains in terms of voice and/or data.
[0051] The database proxy (104) reduces the transaction processing at the database (106) by allowing multiple instances of the database proxy (104) to communicate with the PCC for receiving transaction request and performing several rules checking. The rules checking allows to decide if the transaction is actually required to be processed by the database (106) or if the transaction is required to be processed by the database (106) in real-time or if the transaction can be managed with batch (queue) processing, thereby reducing load at the database and hence reducing latency.
[0052] For voice and/or data, several rules are checked at the database proxy (104), once the database proxy (104) receives call transaction request from the PCC. Herein, a single database proxy is used. Alternatively, multiple database proxies may be utilized. The term “application”, and “PCC (Policy and Charging Control)” may interchangeably be used but not limited to PCC, it can be used for PCRF/OCS/PCF/CHF
[0053] A few exemplary rules are defined below which are checked at/stored in the database proxy (104), once the database proxy (104) receives the transaction request from the PCC i.e., the application (102).
[0054] FIG. 2 is an example rule implementation for a subscription lookup (200). In general, subscription corresponds to a package that the end user purchases or subscribes to e.g., rate cutter plans (reduce the calling tariff), night plans, 2GB quota per day. Details related to the subscription is stored in the database (106). The application (102) provides quality of service (QoS), maintains quota/balance and charges the subscriber in real-time based on available packages/subscription that he/she has subscribed to.
[0055] When the subscriber enables any data connection or makes any call from the user equipment (170), a first request that latches to the application is an initial request (INIT). In the initial request, the application (102) evaluates all the packages that the subscriber has subscribed to and provides best QoS along with grant of initial quota and a session is established. Accordingly, an entry is also created in the database (106) for the session that contains information corresponding to the subscriber, session start time, initial QoS provided, initial granted quota or the like.
[0056] Once the session has been established after the initial request/create request (in case of 5G), the application updates, using UPDATE request, the details based on usage of the service(s) (i.e., data connection, call etc.). That is, the subscriber keeps using the data or voice service. As the subscriber is continuously using the services, the current/ongoing consumption of quota reported by the gateway to the application. For example, after 80MB or 10mins, the gateway sends the update request of the subscriber to the application (102) along with details of consumption. Such interim requests before terminating the service(s) are called update requests. Advantageously, such requests enable the application (102) to provide best user experience based on availability of packages in real time with low revenue loss.
[0057] Further, when the subscriber terminates the services e.g., disconnects voice call or disables data from the user equipment (170), request is generated from the gateway towards the application (102) in form of TERMINATE /RELEASE (in case of 5G) request mentioning that current session or call is terminated by the subscriber along with consumption of that interval since last update so that all the balance related operations can be settled.
[0058] On initial request to identify an available subscription(s) for the subscriber, the application (102) calls the database (106) to fetch details from the database (106) as the application (102) doesn’t have any prior information of the subscriber before the initial request INIT. When the application (102) receives a request as defined above, the same is transmitted to the database proxy (104) for decision making. Based on metadata in the request, the database proxy (104) decides whether to look up from the database directly or if existing information can be used.
[0059] That is, the application (102) passes the request (network request) along with the metadata about the subscriber as parameters to the database proxy (104). The database proxy (104) evaluates the parameters to return. If the request is initial, then a subscription detail is returned in real-time. If the request is not initial, then the subscriber’s state is checked. If the subscriber state has changed where subscriber state (what are all subscription, balances subscriber currently have, any new subscription or any top up to balances or change in existing subscription) then it is required to look up for subscription in update call. The parameters may be INIT and UPDATE/TERMINATE. INIT tags some meta data in session for threshold level quota. The database proxy (104) gets the subscription details in real time and saves the information in the subscriber session in database (106).
[0060] Similarly, if the quota is above threshold level then UPDATE/TERMINATE returns response and update later offline into the database (106). The UPDATE/TERMINATE allows the database proxy (104) to check the metadata for state change of the subscriber, such as any new subscription or removal of any subscription or the like. If the subscriber state has not changed between INIT and UPDATE, then no need to look up for subscription in the update call. If the state has changed, the database proxy (104) gets the latest subscriptions from the database (106) and saves in the existing session else reads the information saved in the session to process the request.
[0061] In other words, the proxy (104) checks whether the request, that is incoming, is the initial request. If yes, evaluation on available packages is performed and subscription details is fetched in real time from the database (106) and stored in the session. If no, the database proxy (104) checks the subscription state i.e., whether any new package is subscribed by the subscriber or any existing subscription is expired during in between the initial and update request. In short, the subscription state that is available at the initial request is still the same or not on update request. If the subscription state is the same, the request is not transmitted to the database (106). If there is change in current subscription state which is available at the session is invalid now, thus it is required to update latest valid information. In this scenario, the request is transmitted to the database (106) to fetch latest information and the updated information is stored into the database (106) for further request.
[0062] In order to identify the subscription state, a flag is managed at session level for the subscription state. Whenever any new subscriptions are made, the flag is set by the application (102) for all available sessions in real-time. Advantageously, for the subscription look up, the database proxy (104) takes decision whether to fetch data in real-time from the database (106) or existing subscription details available in session can be used that further reduces database hits in real-time and make the system (100) smooth with balanced load.
[0063] FIG. 3 is an example rule implementation for a real-time quota provision (300). In the application (102), to serve any request, it is required to have balance/quota available for the subscriber during that time. Which implies, in case of no balance, the subscriber won’t be able to use the service(s). So, whenever any new subscription takes place, the application (102) creates entries in the database (106). The entries may be, but not limited to, subscription details, balance details respective to the subscription. Upon any service request, the application (102) checks the subscription and its respective balance. For example, Subscriber A has purchased a package ABC on 01/01/2020 with details: Validity 6 months, 10 GB quota per month. In this case, only one entry will be made to a subscription table 1 as the subscription is purchased only one time by the subscriber, however in a balance table 2, there can be multiple entries as shown below:
Table 1: Subscription details
Start Time End Time Package Name
01/01/2020 30/06/2020 ABC

Table 2: Balance Details

Start time End time quota
01/01/2020 31/01/2020 10GB
01/02/2020 28/02/2020 10GB
01/03/2020 31/03/2020 10GB
01/04/2020 30/04/2020 10GB
01/05/2020 31/05/2020 10GB
01/06/2020 30/06/2020 10GB

[0064] It can be seen that the application (102) creates entries for current month only, not for all the months from second month onwards. When any request from the subscriber is received at the application (102) after the first month, the application checks whether any balance entry for the subscription that is valid for current month but no balance entry is identified. So, the application (102) creates a new entry for balance for the subscriber in real time and returns a response. This provisioning process of balance/quota based on subscription validity is called real time quota provision.
[0065] In the real time quota provisioning scenario, there may be high chances of surge in the database hit when subscribers connect in the next billing cycle or month. For example, when millions of subscribers reach the next billing cycle, in that case for all the subscribers, the real time quota provisioning will be performed by the application (102) that will create a spike in the database hit and performance may be hampered. To overcome the aforesaid issue, whenever a request received at the application (102), the application transmits the request to the database proxy (104) to take decision on real time quota provisioning based on a threshold time. The threshold time is the time after which the real time quota provisioning can be started. For e.g., billing cycle-2 days, if billing cycle is 30, so in this case threshold time will be 28 (i.e., 30-2). Similarly, if request time is greater than the threshold time, then the database proxy (104) identifies that the subscriber packages are eligible for the next billing cycle also.
[0066] In short, the application (i.e., PCC) passes the request along with metadata about the subscriber as parameters to the database proxy (104). The database proxy (104) evaluates the parameters. If the request is received before threshold time and the metadata notifies that quota provision is pending, then request is added to the batch of new quota provision using INIT/UPDATE/TERMINATE (as described above) and SUCCESS is returned. Similarly, if the request is received after the threshold time and the metadata notifies that the quota provision is pending, then the new quota is provisioned in real-time using INIT/UPDATE/TERMINATE and SUCCESS is returned.
[0067] FIG. 4 is an example rule implementation for a session lookup (400). In general, the session identifies a type of connection the subscriber has with the application. For e.g., a voice call or data connection is identified by a unique session in the application and a unique session identifier (ID) is provided by the application that is used to identify the session at any point.
[0068] Whenever the request is received by the application (102), the session information is updated in case of INITIAL request and SUCCESS is returned immediately and the session information is saved in the database (106) in a batch process with other related details like Quota available, Quota Reserve and later used in subsequent requests. When an Update or Terminate request is received, the session is checked in real-time but updated in batch mode in the database if Quota is not exhausted and is available for use.
[0069] For the session lookup, the parameters and rules are defined as below:
INIT - A request comes from network to PCC, the PCC sends filtered request to the database proxy (104), the database proxy returns SUCCESS. Session information is saved in the database (106) in a batch process with other related details like Quota available, Quota Reserve and later used in subsequent requests.
UPDATE/TERMINATE - A request comes from the network to the PCC, the PCC sends filtered request to the database proxy (104), the session is checked in real time but updated in batch mode in the database (106) if Quota is not exhausted and is available for use.
[0070] FIG. 5 is an example rule implementation for a subscriber lookup (500). The role of the application (102) is to provide the best QoS based on the availability of packages and balance. However, before reaching to this level, it is required to authenticate the subscriber, whether the requesting subscriber is a valid user or not or the subscriber having valid packages or not. The subscriber information is fetched from the subscriber profile from the SPR (subscriber profile repository) (150). The operation of fetching of subscriber profile from the SPR is called subscriber lookup. In the application (102), it is required to fetch the subscriber profile on every INIT, UPDATE and TERMINATE request to know current state of the subscriber to further decrease the database hits.
[0071] The database proxy (104) significantly reduces the database hits. On every initial call, it is mandatory to fetch the subscriber profile that can be stored in the session. On every update and termination request at the end of call, the database proxy identifies whether the subscriber state (as explained above) has been changed or not. From the initial request, if no, same profile can be used which is available in the session. If yes, the latest subscriber profile can be fetched from the SPR and stored in the database.
[0072] For the subscriber lookup, the parameters and rules are defined as below:
INIT – The PCC sends filtered network request to the database proxy (104). The database proxy (104) fetches the subscriber details, Returns SUCCESS and save the required data in session in batch.
UPDATE/TERMINATE - The PCC sends filtered network request to the database proxy (104), the database proxy (104) fetches the session in real time, if there is any change in the subscriber state in the session then fetches the subscriber again else returns SUCCESS and updates the database (106) in batch for the changes received in the request.
[0073] FIG. 6 is an example rule implementation for a monetary balance lookup (600). In general, a monetary balance corresponds to prepaid balance or postpaid credit limit or usage limit. Whenever the request is received from the application, the monetary balance is checked for availability. If enough quota is available, the voice call/data session/SMS/other events/services are continued else they may be stopped. When the request (service request) is received from the application, the database proxy (104) identifies if the subscriber has enough balance in real-time but when usage is reported and remaining balance is greater than a threshold value, the usage is updated via batch process otherwise in real time. Herein, a subscriber metadata is used to identify the state of the subscriber, whether subscriber is unlimited or within threshold or outside threshold.
[0074] For the monetary balance lookup, the parameters and rules are defined as below:
INIT – The PCC calls the database proxy (104) filtered network request and subscriber metadata as parameters. The database proxy (104) checks the balance in real time, allocates the balance to initiate the voice call/data session
UPDATE/TERMINATE – The PCC calls the database proxy (104) filtered network request and subscriber metadata as parameters, the database proxy (104) will identify if (remaining balance – usage reported) > threshold value, the usage is updated via batch process otherwise in real time.
[0075] FIG. 7 is an example rule implementation for a non-monetary balance lookup (700). A non-monetary balance is a balance that does not involve any monetary value. Such as any type of quota e.g., 50 Free Mins of Local Calls, 100 Free Mins of STD/ISD. 3GB Daily, 100 SMS etc. is called non-monetary balance.
[0076] Whenever the request is received, the balance/quota is checked for availability. If enough quota is available, the voice call/data session/SMS/other events/services are continued else they may be stopped. Based on the metadata received during the request (service request or transaction request), the database proxy identifies if the subscriber has unlimited quota available for service requested. If yes, no request will be transmitted to the database (106) in real-time to check quota balance and success will be returned. In case of usage of the services, when the subscriber is having the unlimited quota, data related to consumption or the like is updated in the database (106) via the batch process and the transaction request to the database (106) in the real-time is skipped. On the other hand, for the subscriber with limited quota, e.g., 100 voice mins, when the request is received by the application (102), the quota is fetched in real time but when usage is reported and remaining quota is greater than the threshold value, the usage is updated via batch process otherwise in real time. A subscriber metadata is used to identify the state of the subscriber, whether subscriber is unlimited or within threshold or outside threshold.
[0077] For the non-monetary balance lookup, the parameters and rules are defined as below:
INIT – The PCC sends filtered network request and the subscriber metadata to the database proxy (104). The database proxy (104) fetches balance in real time, If subscriber has unlimited balance then return SUCCESS, and saves information in session in batch.
UPDATE/TERMINATE – The PCC sends filtered network request and the subscriber metadata to the database proxy (104). The database proxy (104) checks if balance is unlimited or greater than the threshold value then updates the balance in the database (106) via batch, else updates the database (106) in real time.
[0078] FIG. 8 is an example rule implementation for a dependent transaction check (800). As mentioned earlier, Gx is the communication interface between the PCEF (120) and the PCRF (130) for Quality of service, Rx is the communication interface between the AF (110) and the PCRF (130) for multimedia services and Gy is the communication interface between the PCEF (120) and the OCS (140) for usage of voice/data/SMS/other services. Rx mandates Gx session presence and Gy mandates Gx session presence.
[0079] But 99.999% of times, Gx session is received and present in the database (106) prior to Rx and Gy. If the Gx session is not present, then there may be issues with the application. So, if an environment flag is SET, presence of Gx session will be presumed and continue with Rx and Gy calls, else presence of the Gx session is checked in real-time.
[0080] For the dependent transaction check, the parameters and rules are defined as below:
INIT – The PCC sends filtered network request to the database proxy (104), the database proxy (104) checks if Dependency Check flag is set or not. If Dependency Check flag is set, it checks for dependent session and continues the flow else ignores the dependent session and continues the flow.
UPDATE – No change.
TERMINATE – Removes the current and dependent session in batch.
[0081] Alternatively, the database proxy (104) may be used for other types of operations such as move/delete information from a main table/database to a history table/database, transfer of Monetary/Non-Monetary Balance from one subscriber to another or the like.
[0082] The move/delete information from the main table/database to the history table/database may consider sources and destination tables as an input. Further, the rule may include a polling to be done by the database proxy (104) for pre-configured tables with respect to entries marked for removal or movement at regular interval and either delete or move table entries in a batch process.
[0083] Further, for the transfer of monetary/non-monetary balance from one subscriber to another, the rule may include sending source subscriber, destination subscriber and balance details from the PCC (102) to the database proxy (104). The database proxy (104) returns success and collects the requests in a batch and does the balance movements from one subscriber to another.
[0084] The present disclosure is not limited to the aforementioned rule implementation. There may be other possible operations for which rules can be defined by the present disclosure, wherein the operations may be related to balance look up/update for data, balance monetary update, event non-monetary, voice non-monetary, real time provisioning, real time removal, non-monetary balance history move operation, monetary balance history move operation, data balance history move operation, subscription history move operation, addon sharing cache from voltdb, cug cache, alternate id cache, test subscriber, update usage limit and credit limit APIs, transfer monetary balance or the like.
[0085] In one implementation, the parameters such as INIT/UPDATE/TERMINATE may be used for 5G and other telecommunication generations. In another implementation, parameters such as INITIAL/UPDATE/RELEASE may be used for 5G and other telecommunication generations.
[0086] The database proxy (104) uses rules to return the data/information to the application (102) rather than storing the data in cache that improves scalability unlike cache-based systems.
[0087] FIG. 9 is a flow-chart (900) illustrating a method of transaction management in the application i.e., the Policy and Charging Control (102). The PCC comprising the database proxy (104) between the database (106) and the user equipment (UE) (170). The method has been explained in conjunction with FIG. 1 to FIG. 8.
[0088] At step (902), the method includes receiving the transaction request from the UE (170) at the database proxy (104), wherein the UE is associated with the subscriber.
[0089] At step (904), the method includes queuing the transaction request when the subscriber is associated with one or more of the unlimited package, wherein the database proxy does not have the cache, whereby reducing transaction load on the database.
[0090] In addition to the above steps, the method may also include:
? Queuing the transaction request includes allocating the transaction request to the database (106) for offline uploading.
? creating a session, wherein the session enables storing data for the subscriber against a unique session identifier (ID), when the subscriber logs into the PCC, it creates the session identified by a session ID and returns a session state, to prove to the PCC that the subscriber has been authenticated; and fetching package information of the subscriber associated with the UE from the database (106), wherein the package information corresponds to existing package details, details of the subscriber.
? updating the transaction request to the database in a real-time when the subscriber is associated with one or more of a limited package and the subscriber has consumed more than a predefined threshold of the limited package.
? updating the transaction request to the database in the real-time when the subscriber is associated with one or more of a limited package and the subscriber has consumed more than a predefined threshold of the limited package; and sending a response to the UE, wherein the response corresponds to an alert message or notification related to usage and consumption of the limited package.
? based on dependent calls, performing dropping of transaction request sending to the database (106) that must have already taken place, i.e., dropping the transaction request corresponding to Gx interface if the transaction request corresponding to Gy interface is received.
? a transaction that is already taken place is defined by session creation for authorization check, whereby reducing the transaction load on the database (106) by dropping the transaction request related to dependent calls.
? based on metadata during the transaction request received from the PCC (102), the database proxy (104) identifies if subscriber has unlimited quota available for service requested, if yes, the transaction request to the database (106) to check quota balance is not placed in the real-time and success is returned and when usage is reported by the PCC and the subscriber is having unlimited quota, the transaction request to the database (106) in the real-time is skipped and data is updated in the database (106) via a batch process.
[0091] The methods and processes (900) described herein may have fewer or additional steps or states and the steps or states may be performed in a different order. Not all steps or states need to be reached. The methods and processes described herein may be embodied in, and fully or partially automated via, software code modules executed by one or more general purpose computers. The code modules may be stored in any type of computer-readable medium or other computer storage device. Some or all of the methods may alternatively be embodied in whole or in part in specialized computer hardware.
[0092] The embodiments disclosed herein can be implemented using at least one software program running on at least one hardware device and performing network management functions to control the elements.
[0093] It will be apparent to those skilled in the art that other embodiments of the invention will be apparent to those skilled in the art from consideration of the specification and practice of the invention. While the foregoing written description of the invention enables one of ordinary skill to make and use what is considered presently to be the best mode thereof, those of ordinary skill will understand and appreciate the existence of variations, combinations, and equivalents of the specific embodiment, method, and examples herein. The invention should therefore not be limited by the above described embodiment, method, and examples, but by all embodiments and methods within the scope of the invention. It is intended that the specification and examples be considered as exemplary, with the true scope of the invention being indicated by the claims.
[0094] The results of the disclosed methods may be stored in any type of computer data repository, such as relational databases and flat file systems that use volatile and/or non-volatile memory (e.g., magnetic disk storage, optical storage, EEPROM and/or solid state RAM).
[0095] The various illustrative logical blocks, modules, routines, and algorithm steps described in connection with the embodiments disclosed herein can be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. The described functionality can be implemented in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the disclosure.
[0096] Moreover, the various illustrative logical blocks and modules described in connection with the embodiments disclosed herein can be implemented or performed by a machine, such as a general purpose processor device, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components or any combination thereof designed to perform the functions described herein. A general purpose processor device can be a microprocessor, but in the alternative, the processor device can be a controller, microcontroller, or state machine, combinations of the same, or the like. A processor device can include electrical circuitry configured to process computer-executable instructions. In another embodiment, a processor device includes an FPGA or other programmable device that performs logic operations without processing computer-executable instructions. A processor device can also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. Although described herein primarily with respect to digital technology, a processor device may also include primarily analog components. A computing environment can include any type of computer system, including, but not limited to, a computer system based on a microprocessor, a mainframe computer, a digital signal processor, a portable computing device, a device controller, or a computational engine within an appliance, to name a few.
[0097] The elements of a method, process, routine, or algorithm described in connection with the embodiments disclosed herein can be embodied directly in hardware, in a software module executed by a processor device, or in a combination of the two. A software module can reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of a non-transitory computer-readable storage medium. An exemplary storage medium can be coupled to the processor device such that the processor device can read information from, and write information to, the storage medium. In the alternative, the storage medium can be integral to the processor device. The processor device and the storage medium can reside in an ASIC. The ASIC can reside in a user terminal. In the alternative, the processor device and the storage medium can reside as discrete components in a user terminal.
[0098] Conditional language used herein, such as, among others, "can," "may," "might," "may," “e.g.,” and the like, unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain embodiments include, while other embodiments do not include, certain features, elements and/or steps. Thus, such conditional language is not generally intended to imply that features, elements and/or steps are in any way required for one or more embodiments or that one or more embodiments necessarily include logic for deciding, with or without other input or prompting, whether these features, elements and/or steps are included or are to be performed in any particular embodiment. The terms “comprising,” “including,” “having,” and the like are synonymous and are used inclusively, in an open-ended fashion, and do not exclude additional elements, features, acts, operations, and so forth. Also, the term “or” is used in its inclusive sense (and not in its exclusive sense) so that when used, for example, to connect a list of elements, the term “or” means one, some, or all of the elements in the list.
[0099] Disjunctive language such as the phrase “at least one of X, Y, Z,” unless specifically stated otherwise, is otherwise understood with the context as used in general to present that an item, term, etc., may be either X, Y, or Z, or any combination thereof (e.g., X, Y, and/or Z). Thus, such disjunctive language is not generally intended to, and should not, imply that certain embodiments require at least one of X, at least one of Y, or at least one of Z to each be present.
[00100] While the above detailed description has shown, described, and pointed out novel features as applied to various embodiments, it can be understood that various omissions, substitutions, and changes in the form and details of the devices or algorithms illustrated can be made without departing from the scope of the disclosure. As can be recognized, certain embodiments described herein can be embodied within a form that does not provide all of the features and benefits set forth herein, as some features can be used or practiced separately from others.

CLAIMS:CLAIMS
We Claim:

1. A method of transaction management in a Policy and Charging Control (102), wherein the PCC comprising a database proxy (104) between a database (106) and a user equipment (UE) (170), the method comprising:
receiving a transaction request from the UE (170) at the database proxy (104), wherein the UE is associated with a subscriber; and
queuing the transaction request when the subscriber is associated with one or more of an unlimited package, wherein the database proxy does not have a cache, whereby reducing transaction load on the database.
2. The method as claimed in claim 1, wherein the unlimited package corresponds to voice, message or data or combination thereof.
3. The method as claimed in claim 1, wherein queuing the transaction request comprising allocating the transaction request to the database (106) for offline uploading.
4. The method as claimed in claim 1 further comprising one or more of:
creating a session, wherein the session enables storing data for the subscriber against a unique session identifier (ID), when the subscriber logs into the PCC, it creates the session identified by a session ID and returns a session state, to prove to the PCC that the subscriber has been authenticated; and
fetching package information of the subscriber associated with the UE from the database (106), wherein the package information corresponds to existing package details, details of the subscriber.
5. The method as claimed in claim 1 further comprising updating the transaction request to the database in a real-time when the subscriber is associated with one or more of a limited package/non-monetary/limited monetary balance/usage limit/credit limit etc. and the subscriber has consumed more than a predefined threshold of the limited package.
6. The method as claimed in claim 1 further comprising:
updating the transaction request to the database in the real-time when the subscriber is associated with one or more of a limited package and the subscriber has consumed more than a predefined threshold of the limited package; and
sending a response to the UE, wherein the response corresponds to an alert message or notification related to usage and consumption of the limited package.
7. The method as claimed in claim 1, wherein based on dependent calls, performing dropping of transaction request sending to the database (106) that must have already taken place, i.e., dropping the transaction request corresponding to Gx interface if the transaction request corresponding to Gy interface is received.
8. The method as claimed in claim 1, wherein a transaction that is already taken place is defined by session creation for authorization check, whereby reducing the transaction load on the database (106) by dropping the transaction request related to dependent calls.
9. The method as claimed in claim 1, wherein based on metadata during the transaction request received from the PCC (102), the database proxy (104) identifies if subscriber has unlimited quota available for service requested, if yes, the transaction request to the database (106) to check quota balance is not placed in the real-time and success is returned and when usage is reported by the PCC and the subscriber is having unlimited quota, the transaction request to the database (106) in the real-time is skipped and data is updated in the database (106) via a batch process.