TECHNICAL FIELD

[0001] Disclosed are embodiments related to a method and system for personalized overload control.

BACKGROUND

[0002] An Online Charging System (OCS) is a node which covers the charging control functionality, such as supported in 3G, 4G, and 5G networks. The common charging architecture, with respect to Charging Trigger and OCS or Converged Charging System (CCS) function is defined in 3GPP TS 32.240 V17.3.0 0 Release 17. Similarly, Network Elements (NEs) or Network Functions (NFs) towards OCS or CCS are known with different names in 3G, 4G or 5G networks, such as Policy and Charging Enforcement Function (PCEF) or an equivalent node in IMS or Session Management Function (SMF) in a 5G network. In a 5G network, an interfacing node in CCS towards NFs is known as Charging Function (CHF).

[0003] Additionally, these network nodes interact with OCS or CHF over different interfaces or protocols, e.g., Diameter based credit control client applications over Gy or Ro or Nchf (Service based Interface) which are defined in 3GPP TS 32.299 V17.0.0 for Diameter Charging Application and 3GPP TS 3GPP TS 32.290 V17.3.0 Release 17 for Service Based Interface (SBI).

[0004] Overload Control or Traffic Control is required when there is a lack of resources in a network node, e.g. memory, CPU capacity, or storage, due to which the network node acting as server is unable to process client requests. Traffic control ensures that requests are regulated during processing and that the network node can provide stable performance.

[0005] 3GPP TS 32.299 V17.0.0 Release 17, defines the Diameter overload control for diameter charging applications, together with IETF RFC 6733 and IETF RFC 7683. IETF RFC 6733 uses the protocol error “DIAMETER TOO BUSY”, 3004 error code in result code AVP of the answer message for related requests as a means to inform the client that there is an overload situation in the diameter server application side. A client may withhold requests for a configurable period of time or do rate limitations towards the server or may route the requests to an alternate diameter server application.

[0006] Additionally, this is further enhanced in IETF RFC 7683, which makes it possible for a server application (e.g. OCS) to indicate the overload situation to clients before it starts rejecting the client requests and thus prevents retransmission of requests. RFC 7683 defines a Diameter Overload Indication Conveyance (DOIC) mechanism which provides support for sending the information in additional AVPs (Chapter 7) with request type, reduction percentage, validity duration etc. in OC-OLR Grouped AVP.

[0007] 3GPP TS 32.299 V17.0.0 Release 17 as part of Annex B (normative) defines additional 3 GPP specific AVPs in OC-OLR AVP:

• OC-OLR : : = < AVP Header: 623 >

• < OC-Sequence-Number >

• < OC-Report-Type >

• [ OC-Reduction-Percentage ]

• [ OC-Validity-Duration ]

• [ 3GPP-OC-Specific-Reduction ]

• [ AVP ]

• 3GPP-OC-Specific-Reduction :: = < AVP Header: 1320 >

• [ 3GPP-OC-Rating-Group ]

• [ 3GPP-OC-Request-Type ]

• [ OC-Reduction-Percentage ]

• [ AVP ]

• 3GPP-OC-Request-Type can have following values:

• INITIAL REQUEST

• UPDATE REQUEST

• TERMINATION REQUEST

• EVENT REQUEST

[0008] 3GPP TS 32.299 version 16.2.0 Release 16 mentions that when the OCS needs to request a reduction in the traffic it is handling due to an overload condition, it shall include the OC-OLR AVP in answer messages. The OCS should include the OC-OLR AVP in the answer messages for as long as the overload condition applies. This shall be based on the OC- Supported-Features AVP, exchanged earlier as per RFC 7683.

[0009] Additionally, there is a technical report 3GPP TR 29.843 V16.0.0 for 5G compliant network nodes for load and overload control for service-based interfaces (SBI), which specify the equivalent overload control information exchange mechanism for overload situations in a network function service producer towards a network function service consumer.

[0010] Also, in some implementations, an online charging system (charging application server) based on pre-configured thresholds for system characteristics (CPU, memory, latency etc.) rejects the incoming traffic coming from a client (charging trigger functions) irrespective of specific high usage services consumed by end user.

SUMMARY

[0011] At least the following problems exist with current implementations of overload control. First, traffic requests coming from charging trigger functions may be denied or ratelimited or terminated based on pre-configured system performance characteristics which applies globally to all the impacted end users (consumer of services). Second, as an end user, the services for which the end user has higher usage historically or have higher revenue generation for the communication service provider (CSP) may be terminated or rejected, thereby leading to bad customer experience or loss of revenue to the CSP. Third, there is no personalized overload control for the services which an end user (subscriber) consumes. That is, during overload control in OCS, there is no mechanism to reject sessions which are non-critical for users (lesser usage and less revenue generating for CSP) and allow only services which are critical (higher usage and high revenue generating for CSP), based on the historical consumptions of the user. Therefore, systems and methods which improve upon current implementations of overload control are desired.

[0012] Embodiments herein provide for a method for differential or personalized handling of overload control at an OCS for different services for the subscribers based on past consumptions. Embodiments further provide an intelligent system which collects usage information (e.g., charging data records (CDRs)) from the network over a period, processes the usage information, and discovers a list of critical services with higher usage for the CSP on per subscriber level. For example, the system may identify the list of critical services if the usage are higher than a pre-configured value for usage. As used here, usage may include, for example, one or more of data usage amount (e.g., data in MB), time of usage (e.g., duration in seconds), and revenue amount (e.g., in USD). Embodiments further provide a database, which may store the list of critical services with priority information for each subscriber. In embodiments, on detection of an overload situation, the OCS queries the database and takes a configured action (e.g., rate-limit or allow) depending upon the priority.

[0013] For example, a configured action here may be sending an OCS-OLR AVP if DOIC is applicable with rate-limit information for any prioritized service, or if DOIC is not applicable, then depending upon the local configuration in OCS rejecting traffic selectively for prioritized services. Alternatively, the prioritized services could be allowed without ratelimiting. For non-prioritized services, i.e. all other services which are not part of priority list, OCS may send a charging response with rejection.

[0014] Advantages of embodiments include providing better personalized customer experience for the end user, efficient management of network resources during overload control by rejecting traffic for non-critical services, and allowing high revenue generating services for the CSP during overload control.

[0015] According to a first aspect, a method for overload control performed by an online charging system (OCS). The method includes receiving a list of prioritized services on a per- subscriber level based on usage information. The method includes detecting an overload situation. The method includes, as a result of detecting the overload situation, sending a message to a node indicating that a service is allowed without rate-limiting, allowed with rate-limiting, or rejected based on the list of prioritized services on a per-subscriber level.

[0016] In some embodiments, the method further includes collecting usage information; and identifying the list of prioritized services on a per-subscriber level based on the collected usage information. In some embodiments, the collected usage information includes information about one or more subscribers, one or more services associated with the one or more subscribers, and one or more of (i) an amount of data transferred, (ii) an amount charged, and (iii) a duration associated with each service. In some embodiments, identifying the list of prioritized services on a per-subscriber level based on the collected usage information comprises one or more of: (i) identifying subscribers and associated services based on a data usage amount exceeding a first threshold and a revenue amount exceeding a second threshold; and (ii) identifying subscribers and associated services based on a duration exceeding a third threshold. In some embodiments, the node comprises a credit control functionality toward an Online Charging System (OCS).

[0017] In some embodiments, sending the message indicating that the service is allowed without rate-limiting, allowed with rate-limiting, or rejected based on the list of prioritized services on a per-subscriber level comprises sending one or more of: (i) a charging response with rejection, (ii) a credit charging accept (CCA) message, and (iii) a CCA message comprising overload condition overload report (OC-OLR) attribute value pair (A VP) information. In some embodiments, sending the message indicating that the service is allowed without rate-limiting, allowed with rate-limiting, or rejected based on the list of prioritized services on a per-subscriber level comprises: for each of the services identified in the list of prioritized services, sending a message indicating that the service is allowed without rate-limiting; and for a service not in the list of prioritized services, sending a message indicating either that the service is allowed with rate-limiting or rejected.

[0018] In some embodiments, usage information comprises one or more charging data records (CDRs). In some embodiments, the usage information comprises information about one or more charging events, the information about the one or more charging events comprising one or more of: subscriber information, amount of data transferred information, amount charged information, timing information, and service information. In some embodiments, identifying a list of prioritized services on a per-subscriber level based on the collected usage information comprises providing a list of n services, where n is a pre-configured number, and is based on one or more of data usage amount, time of usage, and revenue amount.

[0019] According to a second aspect, a computer program is provided comprising instructions which when executed by processing circuitry of a node, causes the node to perform the method of any embodiment of the first aspect. [0020] According to a third aspect, a carrier containing the computer program of the second aspect is provided, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, and a computer readable storage medium.

[0021] According to a fourth aspect, a network node is provided. The network node includes processing circuitry; and a memory, the memory containing instructions executable by the processing circuitry, whereby the network node is configured to perform the method of any one the embodiments of the first aspect.

[0022] According to a fifth aspect, a network node for overload control is provided. The network node is configured to receive a list of prioritized services on a per-subscriber level based on usage information. The network node is configured to detect an overload situation. The network node is configured to, as a result of detecting the overload situation, send a message to a node indicating that a service is allowed without rate-limiting, allowed with rate-limiting, or rejected based on the list of prioritized services on a per-subscriber level.

BRIEF DESCRIPTION OF THE DRAWINGS

[0023] The accompanying drawings, which are incorporated herein and form part of the specification, illustrate various embodiments.

[0024] FIG. 1 illustrates a system according to an embodiment.

[0025] FIG. 2 illustrates a system according to an embodiment.

[0026] FIG. 3 illustrates a sequence diagram according to an embodiment.

[0027] FIG. 4 illustrates a sequence diagram according to an embodiment.

[0028] FIG. 5 illustrates a flowchart according to an embodiment.

[0029] FIG. 6 is a block diagram of an apparatus according to an embodiment.

DETAILED DESCRIPTION

[0030] FIG. 1 illustrates a system 100 according to an embodiment. As shown, system 100 (e.g., a communication system employing a network communication protocol such as 3G, 4G, or 5G) includes a UE 102, a radio network 104, a core network 106, an intelligent system 110, a subscriber database 112, and charging node 114. UE 102, also referred to as a subscriber may access a radio network 104, and radio network 104 may, in turn, communicate with core network 106. Core network 106 may be, e.g., a gateway general packet radio service (GPRS) support node (GGSN), a packet data network gateway control plane (PGW-C), a session management function (SMF) or other core network node, depending on the network communication protocol. Core network 106 includes a charging trigger function (CTF) functionality 108. Radio network 104 mediates between the UE 102 and the core network 106 for purposes of a user session. As UE 102 interacts with radio network 104, using one or more services of the communication system, core network 106 may access the CTF functionality 108. For example, CTF functionality 108 communicates with charging node 114. For example, charging node 114 may be one or more of an OCS, a CHF, and/or a Common API Core Framework (CAPIF) Core Function (CCF). Depending on the network communication protocol, this communication between the CTF functionality 108 and the charging node 114 may take place over the Gy, Ro, or Nchf interfaces.

[0031] Intelligent system 110 may receive usage information, such as one or more charging data records (CDRs). For example, intelligent system 110 may receive CDRs 122a from the CTF functionality 108 and CDRs 122b from the charging node 114. Intelligent system 110 collects CDRs, processes them, and from this information discovers a list of prioritized services 120 for each subscriber, which list may be stored on subscriber database 112. When the charging node 114 detects an overload condition, it can then query the subscriber database 112 for the list of prioritized services 120 for each subscriber. Based on this, the charging node 114 may send overload control information, if applicable, to the CTF functionality 108, and allow, rate-limit, or reject different services based on the list of prioritized services 120 for each subscriber.

[0032] FIG. 2 illustrates a system 200 according to an embodiment. System 200 includes a data source 202, a data collection unit 204, a data processing unit 206, a rule engine 208, and a data store 210. System 200 may be used to derive a list of priority services on a per subscriber level, e.g., by processing CDRs collected from network and charging nodes, such as the list of prioritized services 120 for each subscriber described in connection with FIG. 1 and system 100. System 200 is an example of intelligent system 110 described above in connection with FIG. 1 and system 100. [0033] Data collection unit 204 may collect information from data source 202. Data source 202 may include CDRs, such as from a network or charging node. The collected information may include, for one or more subscribes and one or more services associated with each subscriber, information about the subscriber, the service associated with the subscriber, and one or more of an amount of data transferred, a charged amount, and a timing/duration associated with the service. Data processing unit 206 may process the collected information into a format usable by rule engine 208. Rule engine 208 may determine a list of priority services on a per subscriber level based on configured rules. Examples of a few rules include one or more of:

• Identify users and their services with high usage of data (e.g., more than 1GB) and cumulative charged amount (e.g., more than USD50) in a period of (e.g., 7 days).

• Identify users and their services with long local voice sessions (e.g., more than 1 hour).

• Identify users having received many calls (e.g., more than 100) in a period (e.g., 7 days) from a set of phone numbers (e.g., emergency numbers).

[0034] Other rules are possible, and in some embodiments rules engine 208 may not use pre-configured rules but instead may determine rules on the fly.

[0035] System 200 may generate output that is saved to a data store 210 (such as the subscriber database 112 described above in connection with FIG. 1 and system 100). The output may include metadata to enable search and retrieval of generated statistics, and analytical records (e.g., Subscriber A, Streaming entertainment services and Video Conferencing service, Subscriber B, WhatsApp Voice call).

[0036] FIG. 3 illustrates a sequence diagram according to an embodiment.

[0037] As shown, CTF functionality 108, charging node 114, intelligent system 110, and subscriber database 112 may communicate with each other. For description purposes, with respect to FIG. 3, CTF functionality 108 is a policy and charging enforcement function (PCEF) and charging node 114 is an OCS. The numbered items 1-10 below correspond to the numbered items shown in FIG. 3.

[0038] 1. As soon as UE 102 attaches to the network, a session will be authorized by the charging node 114. Online charging control request (CCR)-initial is initiated by diameter charging client application, in this case it is PGW (PCEF) for a 4G network, which also acts as a Charging Trigger Function (CTF). OCS will respond back with Charging Control Answer (CCA)-initial after a successful authorization for initial request and grant the quota. OCS will start credit reservation. PCEF will send CCR Update for subsequent quota reservation. OCS will grant the subsequent quota if a sufficient balance is there and then responded back with CCA for an update. This process will continue, with charging taking place. CCR messages towards OCS for multiple services may be consumed by the UE 102.

[0039] 2. OCS will generate CDRs (with usage and rating information included for each subscriber and associated service information) which will be collected by intelligent system 110. Similarly, Intelligent System 110 will also collect network CDRs from the PCEF.

[0040] 3. Intelligent System 110 will collect and process the CDRs over a period and then generate a prioritized list of services per subscriber depending upon amount of usage, which may include a data usage amount, an amount of revenue (rated amount) for different services (identified based on Rating Group), a duration, or other usage in formation. The system can generate the “top n” number of prioritized services (e.g., for values of n of 2, 3, or 4), which is system configurable. The system may have a configurable threshold value for amount of usage to be qualified for personalized handling of services during congestion/overload control in OCS. For example, there may be a threshold for data usage and another threshold for an amount of revenue.

[0041] 4. The system may store the list of prioritized services per subscriber at subscriber database 112. The list may be stored with Rating Group ID and priority for each subscriber in the subscriber database.

[0042] 5. Congestion or Overload Control is detected in OCS. As a result of this:

[0043] 6. OCS may query the subscriber database 112 (or intelligent system 110) for the list of prioritized services per subscriber.

[0044] 7. If the PCEF included OC-Supported-Features AVP previously in the request, then send OC-OLR AVP towards the PCEF in the answer message for applicable prioritized services and request types. [0045] 8. Send CCA message with above mentioned AVP Info (for applicable services noted in 7).

[0046] 9. For all other services which are not part of prioritized service list simply reject the charging session.

[0047] 10. Send Session Charging response with release cause (for applicable services noted in 9).

[0048] FIG. 4 illustrates a sequence diagram according to an embodiment.

[0049] As shown, CTF functionality 108, charging node 114, intelligent system 110, and subscriber database 112 may communicate with each other. For description purposes, with respect to FIG. 4, CTF functionality 108 is a policy and charging enforcement function (PCEF) and charging node 114 is an OCS. The numbered items 1-10 below correspond to the numbered items shown in FIG. 4. The sequences shown in FIGS. 3 and 4 are similar, and differ with respect to whether DOIC is supported by the client charging application.

[0050] 1. As soon as UE 102 attaches to the network, a session will be authorized by the charging node 114. Online charging control request (CCR)-initial is initiated by diameter charging client application, in this case it is PGW (PCEF) for a 4G network, which also acts as a Charging Trigger Function (CTF). OCS will respond back with Charging Control Answer (CCA)-initial after a successful authorization for initial request and grant the quota. OCS will start credit reservation. PCEF will send CCR Update for subsequent quota reservation. OCS will grant the subsequent quota if a sufficient balance is there and then responded back with CCA for an update. This process will continue, with charging taking place. CCR messages towards OCS for multiple services may be consumed by the UE 102.

[0051] 2. OCS will generate CDRs (with usage and rating information included for each subscriber and associated service information) which will be collected by intelligent system 110. Similarly, Intelligent System 110 will also collect network CDRs from the PCEF.

[0052] 3. Intelligent System 110 will collect and process the CDRs over a period and then generate a prioritized list of services per subscriber depending upon amount of usage, which may include a data usage amount, an amount of revenue (rated amount) for different services (identified based on Rating Group), a duration, or other usage in formation. The system can generate the “top n” number of prioritized services (e.g., for values of n of 2, 3, or 4), which is system configurable. The system may have a configurable threshold value for amount of usage to be qualified for personalized handling of services during congestion/overload control in OCS. For example, there may be a threshold for data usage and another threshold for an amount of revenue.

[0053] 4. The system may store the list of prioritized services per subscriber at subscriber database 112. The list may be stored with Rating Group ID and priority for each subscriber in the subscriber database.

[0054] 5. Congestion or Overload Control is detected in OCS. As a result of this:

[0055] 6. OCS may query the subscriber database 112 (or intelligent system 110) for the list of prioritized services per subscriber.

[0056] 7. If PCEF does not support DOIC mechanism, allow local rejection of traffic based on local rate limit configuration in OCS if applicable for any prioritized services and allow Charging Sessions for only applicable services which are part of prioritized list of services.

[0057] 8. Send CCA message (for applicable services noted in 7).

[0058] 9. For all other services which are not part of prioritized service list simply reject the charging session.

[0059] 10. Send Session Charging response with release cause (for applicable services noted in 9).

[0060] FIG. 5 is a flowchart illustrating a process 500, according to an embodiment, for overload control performed by an online charging system (OCS). Process 500 may begin in step s502.

[0061] Step s502 comprises receiving a list of prioritized services on a per-subscriber level based on usage information.

[0062] Step s504 comprises detecting an overload situation. [0063] Step s506 comprises as a result of detecting the overload situation, sending a message to a node indicating that a service is allowed without rate-limiting, allowed with ratelimiting, or rejected based on the list of prioritized services on a per-subscriber level.

[0064] In some embodiments, the method further includes collecting usage information; and identifying the list of prioritized services on a per-subscriber level based on the collected usage information. In some embodiments, the collected usage information includes information about one or more subscribers, one or more services associated with the one or more subscribers, and one or more of (i) an amount of data transferred, (ii) an amount charged, and (iii) a duration associated with each service. In some embodiments, identifying the list of prioritized services on a per-subscriber level based on the collected usage information comprises one or more of: (i) identifying subscribers and associated services based on a data usage amount exceeding a first threshold and a revenue amount exceeding a second threshold; and (ii) identifying subscribers and associated services based on a duration exceeding a third threshold.

[0065] In some embodiments, the node comprises a credit control functionality toward an Online Charging System (OCS). In some embodiments, sending the message indicating that the service is allowed without rate-limiting, allowed with rate-limiting, or rejected based on the list of prioritized services on a per-subscriber level comprises sending one or more of: (i) a charging response with rejection, (ii) a credit charging accept (CCA) message, and (iii) a CCA message comprising overload condition overload report (OC-OLR) attribute value pair (A VP) information. In some embodiments, sending the message indicating that the service is allowed without rate-limiting, allowed with rate-limiting, or rejected based on the list of prioritized services on a per-subscriber level comprises: for each of the services identified in the list of prioritized services, sending a message indicating that the service is allowed without ratelimiting; and for a service not in the list of prioritized services, sending a message indicating either that the service is allowed with rate-limiting or rejected.

[0066] In some embodiments, usage information comprises one or more charging data records (CDRs). In some embodiments, the usage information comprises information about one or more charging events, the information about the one or more charging events comprising one or more of: subscriber information, amount of data transferred information, amount charged information, timing information, and service information. In some embodiments, identifying a list of prioritized services on a per-subscriber level based on the collected usage information comprises providing a list of n services, where n is a pre-configured number, and is based on one or more of data usage amount, time of usage, and revenue amount.

[0067] FIG. 6 is a block diagram of apparatus 600 (e.g., intelligent system 110, charging node 114), according to some embodiments, for performing the methods disclosed herein. As shown in FIG. 6, apparatus 600 may comprise: processing circuitry (PC) 602, which may include one or more processors (P) 655 (e.g., a general purpose microprocessor and/or one or more other processors, such as an application specific integrated circuit (ASIC), field-programmable gate arrays (FPGAs), and the like), which processors may be co-located in a single housing or in a single data center or may be geographically distributed (i.e., apparatus 600 may be a distributed computing apparatus); at least one network interface 648 comprising a transmitter (Tx) 645 and a receiver (Rx) 647 for enabling apparatus 600 to transmit data to and receive data from other nodes connected to a network 610 (e.g., an Internet Protocol (IP) network) to which network interface 648 is connected (directly or indirectly) (e.g., network interface 648 may be wirelessly connected to the network 610, in which case network interface 648 is connected to an antenna arrangement); and a storage unit (a.k.a., “data storage system”) 608, which may include one or more non-volatile storage devices and/or one or more volatile storage devices. Interface 660 may connect PC 602 and storage unit 608, interface 662 may connect PC 602 and network interface 648, and interface 664 may connect network interface 648 and network 610. In embodiments where PC 602 includes a programmable processor, a computer program product (CPP) 641 may be provided. CPP 641 includes a computer readable medium (CRM) 642 storing a computer program (CP) 643 comprising computer readable instructions (CRI) 644. CRM 642 may be a non-transitory computer readable medium, such as, magnetic media (e.g., a hard disk), optical media, memory devices (e.g., random access memory, flash memory), and the like. In some embodiments, the CRI 644 of computer program 643 is configured such that when executed by PC 602, the CRI causes apparatus 600 to perform steps described herein (e.g., steps described herein with reference to the flow charts). In other embodiments, apparatus 600 may be configured to perform steps described herein without the need for code. That is, for example, PC 602 may consist merely of one or more ASICs. Hence, the features of the embodiments described herein may be implemented in hardware and/or software. [0068] While various embodiments are described herein, it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of this disclosure should not be limited by any of the above described exemplary embodiments. Moreover, any combination of the above-described embodiments in all possible variations thereof is encompassed by the disclosure unless otherwise indicated herein or otherwise clearly contradicted by context.

[0069] Additionally, while the processes described above and illustrated in the drawings are shown as a sequence of steps, this was done solely for the sake of illustration. Accordingly, it is contemplated that some steps may be added, some steps may be omitted, the order of the steps may be re-arranged, and some steps may be performed in parallel.