WO2021245683A1

WO2021245683A1 - Operation of ocs when recovering from overload condition

Info

Publication number: WO2021245683A1
Application number: PCT/IN2020/050487
Authority: WO
Inventors: Ashish Gupta; Vikram AGARWAL; Atul Jain
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2020-06-02
Filing date: 2020-06-02
Publication date: 2021-12-09

Abstract

There is provided mechanisms for operating an OCS upon the OCS recovering from an overload condition. A method is performed by an OCF node of the OCS. The method comprises initiating, as a result of the OCS having recovered from the overload condition, reauthorization towards a CTF node for at least a subset of any communication sessions for which a higher amount of resources than requested by the CTF node has been granted by the OCS and for which granted resources are remaining upon the OCS having recovered from the overload condition.

Description

OPERATION OF OCS

WHEN RECOVERING FROM OVERLOAD CONDITION

TECHNICAL FIELD

Embodiments presented herein relate to a method, an Online Charging Function (OCF) node, a computer program, and a computer program product for operating Online Charging System (OCS) upon the OCS recovering from an overload condition.

BACKGROUND

In communications networks, there may be a challenge to obtain good performance and capacity for a given communications protocol, its parameters and the physical environment in which the communications network is deployed.

For example, online charging is a process where charging information for network resource usage is collected concurrently with that resource usage, but where authorization for the resource usage is obtained by the network as a predicate to allowing the actual resource usage to occur or continue. For example, assume that a subscriber attempts to connect to a data service through a wireless communication network and, according to online charging principles, a resource reservation is made against the subscriber account associated with the subscriber as part of the resource control that is performed before allowing a communication session (such as a data session) for the subscriber to be established. Further subsequent resource reservations may be made, as needed, to cover the costs associated with continuing the communication session. In this respect, the use of online charging is not limited to data services and applies to event -based communications as well as to session- based communications.

In a more detailed example of session-based online charging, a subscriber might request a communication service and an OCS initially reserves some amount of resources from the involved subscriber account. This reservation equates to some usage quota of resources for the service, which may be expressed in terms of the resource units by which the service is metered, such as in terms of minutes, bytes, etc. The service is initiated based on the quota and, when the quota is used up, the communication session might be terminated or further resource reservations might be made against the subscriber account, assuming that a sufficient amount of resources remains available in the account to authorize additional quota of resources. Once the communication session is terminated, information about the number of resources consumed is reported to the OCS in a final charging event.

In the context of networks based on the Third Generation Partnership Project (3GPP) specifications, the OCS might comprise an Online Charging Function (OCF) that in turn might comprise distinct modules, such as a Session Based Charging Function (SBCF), and an Event Based Charging Function or (EBCF). The SBCF is responsible for online charging of network/user communication sessions, e.g. voice calls, Internet Protocol Connectivity Access Network (IP CAN) bearers, IP CAN sessions, and IP Multimedia Subsystem (IMS) sessions. The EBCF performs event-based online charging, which is also referred to as content charging, in conjunction with any application server or service network element, including Session Initiation Protocol (SIP) application servers.

There could be situations where the OCS suffers from an overload condition. This is hereinafter denoted by that the OCS is in an overload condition. There could be different reasons as to why the OCS is in the overload condition. In general terms, the OCS is in an overload condition where requests for resources sent to the OCS cannot be processed by the OCS within a predefined time window. For example, so many requests for resources per time unit might be sent to the OCS that the OCS is not capable of receiving them all, or the OCS might have so many received but outstanding requests for resources that the OCS is not able to process them and respond to them within the predefined time window, etc.

During such an overload condition the OCS, when granting quota for a resource reservation request, can grant a higher than requested quota and give a higher validity time based on a load factor. The subscriber would thereby take more time to consume the increased quota of resources and hence the next resource reservation request and usage reporting request would be delayed by some time. This might give the OCS sufficient time to recover from the overloaded condition before a new request for the same subscriber is received.

Granting higher quota implies that a higher amount of resources is reserved on the subscriber account. This reserved amount of resources will be blocked for the time duration during which the resources are reserved. The available balance of resources for parallel new or ongoing communication sessions on the subscriber account may therefore not be sufficient.

Due to this, subsequent reservation requests for other services for the subscriber might not be granted, even though the OCS has recovered from the overload condition. This may result in a revenue loss for the mobile network operator as the reservation is not granted due to no reservation balance on the subscriber account. Also, this might result in a bad user experience for the subscriber due to the subscriber not being able to consume the service. Hence, there is still a need for an improved handling of situations where the OCS is in an overload condition.

SUMMARY

An object of embodiments herein is to provide efficient handling of situations where the OCS is in an overload condition. According to a first aspect there is presented a method for operating an OCS upon the OCS recovering from an overload condition. The method is performed by an OCF node of the OCS. The method comprises initiating, as a result of the OCS having recovered from the overload condition, reauthorization towards a CTF node for at least a subset of any communication sessions for which a higher amount of resources than requested by the CTF node has been granted by the OCS and for which granted resources are remaining upon the OCS having recovered from the overload condition. According to a second aspect there is presented an OCF node for operating an OCS upon the OCS recovering from an overload condition. The OCF node comprises processing circuitry. The processing circuitry is configured to cause the OCF node to initiate, as a result of the OCS having recovered from the overload condition, reauthorization towards a CTF node for at least a subset of any communication sessions for which a higher amount of resources than requested by the CTF node has been granted by the OCS and for which granted resources are remaining upon the OCS having recovered from the overload condition.

According to a third aspect there is presented an OCF node for operating an OCS upon the OCS recovering from an overload condition. The OCF node comprises an initiate module configured to initiate, as a result of the OCS having recovered from the overload condition, reauthorization towards a CTF node for at least a subset of any communication sessions for which a higher amount of resources than requested by the CTF node has been granted by the OCS and for which granted resources are remaining upon the OCS having recovered from the overload condition.

According to a fourth aspect there is presented a computer program for operating an OCS upon the OCS recovering from an overload condition, the computer program comprising computer program code which, when run on an OCF node, causes the OCF node to perform a method according to the first aspect. According to a fifth aspect there is presented a computer program product comprising a computer program according to the fourth aspect and a computer readable storage medium on which the computer program is stored. The computer readable storage medium could be a non-transitory computer readable storage medium. Advantageously, these aspects provide efficient handling of situations where the OCS is in an overload condition.

Advantageously, these aspects ensure an effective utilization of limited resources for a subscriber, driven by the OCS under overload conditions and thereafter. Other objectives, features and advantages of the enclosed embodiments will be apparent from the following detailed disclosure, from the attached dependent claims as well as from the drawings.

Generally, all terms used in the claims are to be interpreted according to their ordinary meaning in the technical field, unless explicitly defined otherwise herein. All references to "a/an/the element, apparatus, component, means, module, step, etc." are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, module, step, etc., unless explicitly stated otherwise. The steps of any method disclosed herein do not have to be performed in the exact order disclosed, unless explicitly stated.

BRIEF DESCRIPTION OF THE DRAWINGS

The inventive concept is now described, by way of example, with reference to the accompanying drawings, in which:

Fig. l is a schematic diagram illustrating a network according to embodiments; Fig. 2 is a signalling diagram of a method according to state of the art;

Figs. 3, 4, and 5 are flowcharts of methods according to embodiments;

Fig. 6 is a signalling diagram of a method according to an embodiment;

Fig. 8 is a schematic diagram showing functional units of an OCF node according to an embodiment; Fig. 9 is a schematic diagram showing functional modules of an OCF node according to an embodiment; and

Fig. 10 shows one example of a computer program product comprising computer readable storage medium according to an embodiment. DETAILED DESCRIPTION

The inventive concept will now be described more fully hereinafter with reference to the accompanying drawings, in which certain embodiments of the inventive concept are shown. This inventive concept may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided by way of example so that this disclosure will be thorough and complete, and will fully convey the scope of the inventive concept to those skilled in the art. Like numbers refer to like elements throughout the description. Any step or feature illustrated by dashed lines should be regarded as optional.

Fig. l is a schematic diagram illustrating a network 100 where embodiments presented herein can be applied. The network 100 could be a third generation (3G) telecommunications system, a fourth generation (4G) telecommunications system, or a fifth (5G) telecommunications system and support any 3GPP telecommunications standard, where applicable. A non-limiting example of a 4G telecommunications system is a Long-Term Evolution (LTE) telecommunications system. A non-limiting example of a 5G telecommunications system is a New Radio (NR) telecommunications system.

Although the Diameter terminology will be used in descriptions, explanations, and examples, the herein disclosed embodiments are applicable also in non-Diameter OCS with similar signaling characteristics. Further, although some of the messages and functional entities mentioned in descriptions, explanations, figures, and examples are exemplified by messages and functional entities used in 4G telecommunications systems, the corresponding messages and functional entities as specified for use in 5G telecommunications systems might also be used, without deviating from the herein disclosed embodiments. In Table 1 is summarized some of the messages and functional entities used in 4G telecommunications systems and their counterparts as specified for use in 5G telecommunications systems.

Table 1: Messages and functional entities used in 4G telecommunications systems and their counterparts as specified for use in 5G telecommunications systems The network 100 comprises a (radio) access network ((R)AN) 150, a core network (CN) 140, and a packet -based service network 170, such as the Internet. The radio access network 150 is operatively connected to the core network 140, which in turn is operatively connected to the packet-based service network 170. Subscribers 110, such as wireless devices, are thereby, via a radio base station 160 in the radio access network 150 and at least one gateway (GW) 120 in the core network 140 access services of, and exchange data with, the service network 170 during a communication session of the subscriber 110. The gateway 120 might be implemented by a packet gateway (PGW) or a session management function (SMF). As the skilled person understands, the network 100 might comprise further entities, functions, nodes, and devices, such as an offline charging system. The gateway 120 could be any of, or a combination of, a service gateway and a packet data network gateway.

Examples of radio base stations 160 are radio access network nodes, radio base stations, base transceiver stations, Node Bs, evolved Node Bs, gNBs, access points, access nodes, transmission and reception points, and backhaul nodes. Examples of subscribers 110 are wireless devices, terminal devices, mobile stations, mobile phones, handsets, wireless local loop phones, user equipment (UE), smartphones, laptop computers, tablet computers, network equipped sensors, network equipped vehicles, and so-called Internet of Things devices. When the subscriber no is to access services of, and exchange data with, the service network 170 during the communication session, the gateway 120, for example, requests network resources from a CTF node 180 located in the core network 140 for maintaining the communication session for the subscriber 110. The CTF node 180 might be part of, integrated with, or collocated with, the gateway 120, such as with a PGW or an SMF. In turn, the CTF node 180 requests resource units corresponding to the network resources from an OCF node 200 located in an OCS 130. Assuming that resource units are available for the subscriber no, the OCF node 200 responds with a grant of the resource units. The CTF node 180 then provides, to the gateway 120, a grant for the network resources for maintaining the communication session in accordance with the obtained grant.

As noted above when the OCS 130 is in an overload condition, the OCS 130 can grant a higher than requested quota of resources and give a higher validity time based on a load factor. The additional quota might be granted in a resource reservation request (or a credit control request (CCR)). This will typically mean that the next CCR from the network is triggered at the earliest of: 1) when the extended validity timer expires, and 2) the granted higher quota is exhausted by the user. This is true even if the OCS 130 recovers from the overloaded condition before this next CCR request was triggered. In yet further detail, consider the signalling diagram of Fig. 2 that illustrates a method for implementing proactive overload handling based on CPU utilization according to state of the art. Fig. 2 provides a simplified illustration of exchange of messages in one portion of the network 100 and is not intended to reflect every signal or communication exchanged between the entities of the network 100. Furthermore, some communication shown in Fig. 2 maybe indirect. For example, an indirect connection may involve the passing of messages by, and or through, an intermediary device (e.g., a Diameter signaling router) and/or an intermediary network not illustrated in Fig. 2.

Also, it is assumed that policy evaluation based on the policies on the subscriber profile information have been already been performed based on the communication between PGW and Policy and Charging Rules Function (PCRF), and Fig. 2 does not include any message exchange for the same.

As shown in Fig. 2, at step S201, a subscriber no attaches to the network 100 and initiates a communication session. As indicated at step S202 it is assumed that the initial available balance for subscriber 110 for reservation of resources is 750MB. At step S203, the CTF node 180 sends an initial credit control request (CCR-I) for service si to the OCS 130 (e.g. on the Gy interface) to request a quota of resources for the subscriber no. Assume, at step S204, that the OCS 130 does not detect any potential overload conditions. Thus, OCS 130 might allocate a standard quota of resources for the subscriber 110. The standard quota maybe, for example, 10% of the total data limit for the subscriber 110, with a maximum of 250 MB and a minimum of 50 MB. At step S205 the OCS 130 returns a CCA-I with the standard quota (e.g., 250 MB).

At step S206, assume that OCS 130 has entered an overload condition. An additional quota of resources is added to all granted CCRs until the OCS 130 has recovered from the overload condition. As indicated at step S207 the available balance for subscriber 110 is 500MB. At step S208 the CTF node 180 detects that the standard quota from step S205 is exhausted and, at step S209 the CTF node 180 sends an updated CCR (CCR-U) to the OCS 130 to request an updated quota of resources for the communication session for service si for subscriber 110. At step S210 the OCS 130 determines to add the additional quota to the standard quota for the CCR-U. Thus, at step S211 the OCS 130 returns a CCA-U with an additional quota (e.g., a total quota of 450 MB).

At step S212 it is assumed that the OCS 130 has recovered from the overload condition. Thus, no additional quota of resources is to be added when responding to the CCR-U. As indicated at step S213 the available balance for reservation for subscriber 110 is 50MB. Assume further that the CTF node 180 initiates a credit control request (CCR-U) for a new different service e.g. S2 to OCS 130 (e.g. on the Gy interface) to request a quota of resources (e.g. 100MB) for the subscriber 110 at step S214. Since there is not enough balance in the subscriber account, the request is rejected and a CCA-U is sent to the CTF node 180 in step S216. This leads to service denial for the subscriber 110 as there is no quota left in the subscriber account as more quota of resources was granted when the OCS 130 was in the overload condition.

The embodiments disclosed herein therefore relate to mechanisms for operating an OCS 130 upon the OCS 130 recovering from an overload condition. In order to obtain such mechanisms there is provided an OCF node 200, a method performed by the OCF node 200, a computer program product comprising code, for example in the form of a computer program, that when run on an OCF node 200, causes the OCF node 200 to perform the method. Fig. 3 is a flowchart illustrating embodiments of methods for operating an OCS 130 upon the OCS 130 recovering from an overload condition. The methods are performed by the OCF node 200. The methods are advantageously provided as computer programs 1020.

The methods are based on initiating re-authorization for any communication sessions where an excess quota of resources has been granted during the overload condition of the OCS 130. Hence, the OCF node 200 is configured to perform step S104:

S104: The OCF node 200 initiates, as a result of the OCS 130 having recovered from the overload condition, reauthorization towards a CTF node 180. Reauthorization is initiated for at least a subset of any communication sessions for which a higher amount of resources than requested by the CTF node 180 has been granted by the

OCS 130 and for which granted resources are remaining upon the OCS 130 having recovered from the overload condition.

This enables effective utilization of limited resources for a subscriber 110, driven by the OCS 130 under overload conditions and thereafter. The reauthorization would confirm that the subscriber 110 is still using the resources and the CTF node 180 needs to reauthorize the communication session (possibly indicating the current amount of resources used). This current reporting of the resource usage might be used by the OCF node 200 to update the subscriber balance, free up any unused reserved resources. This will enable parallel communication sessions/new communication session to utilize available reserved but unused resources. The CTF node 180 might then send a CCR update request towards the OCS 130 for new resources for the communication session. Embodiments relating to further details of operating an OCS 130 upon the OCS 130 recovering from an overload condition as performed by the OCF node 200 will now be disclosed.

There could be different types of resources. In some examples the resources are data resources, such as time/frequency resources in a time/frequency grid. In some examples the resources are given in terms of bytes of data, or equivalents thereof.

As noted above, the excess quota is granted whilst the OCS 130 is in an overload condition. That is, in some embodiments, the higher amount of resources than requested by the CTF node 180 was granted whilst the OCS 130 was in the overload condition.

There could be different ways for the OCF node 200 to initiate the reauthorization towards the CTF node 180. In some embodiments, the reauthorization is initiated by the OCF node 200 sending a reauthorization request message to the CTF node 180. It is here understood that one reauthorization request message might be sent per communication session for which reauthorization is initiated. In particular, in some examples, when the OCS 130 recovers from the overload condition, the OCF node 200 initiates reauthorization (and reauthentication) by issuing one RAR message for each communication session which have been granted additional/extra quota when the OCS 130 was in the overload condition. In some aspects, the OCF node 200 receives a response from the CTF node 180 upon having initiated the reauthorization towards the CTF node 180. In particular, in some embodiments, the OCF node 200 is configured to perform (optional) step S106:

S106: The OCF node 200 receives, from the CTF node 180, an answer to the reauthorization request message for one of the communication sessions for which reauthorization was initiated.

The answer might be a RAA message that thus is an acknowledgement of the RAR message. The OCF node 200 might then update the amount of reserved resources. In particular, in some embodiments, the OCF node 200 is configured to perform (optional) step S110:

S110: The OCF node 200 updates the amount of resources reserved for this communication session.

There could be different ways in which the amount of reserved resources is updated. For example, the OCF node 200 might in response to having received the RAA message release all reserved resources for this communication session.

In some aspects, the OCF node 200 receives an update request (CCR-U) message from the CTF 180, reporting of current usage of resources, and then reserve a new quota of resources for the communication session. In particular, in some embodiments, the OCF node 200 is configured to perform (optional) step S108:

S108: The OCF node 200 receives, from the CTF node 180, an update request for resources for this of the communication sessions. The update request further specifies a consumed amount of resources for this communication session. The amount of resources reserved for this communication session might then in step S110 be updated at least according to the remaining granted resources and the consumed amount of resources.

The OCF node 200 might thus from the CTF node 180 receive a request for a further amount of resources for service continuation of the communication session.

As indicated by the step numbering, step S108 is performed before step S110 is performed.

Further aspects of how the amount of reserved resources might be updated will be disclosed next. In some aspects, the update request specifies a new quota of resources to be reserved for the communication session. That is, in some embodiments, the update request for resources as received in step S108 specifies an amount of new resources requested to be reserved for this communication session. This could e.g. be the case when the amount of reserved resources does not equal a default value.

In some aspects, updating the reserved resources involves freeing up all unused previously reserved excess quota and reserving a new quota of resources. That is, in some embodiments, the amount of resources reserved for this communication session is updated by releasing all granted but still remaining resources for this communication session and reserving new resources for this communication session.

In some aspects, updating the reserved quota involves freeing up resources equal to a difference between unused previously reserved excess quota and new quota. That is, in some embodiments, the amount of resources reserved for this communication session is updated by releasing an amount of resources for the communication session equal to a difference between the granted but still remaining resources for this communication session and new resources for this communication session. Once the amount of reserved resources has been updated, the OCF node 200 might notify the CTF node 180 of this. In particular, in some embodiments, the OCF node 200 is configured to perform (optional) step S112:

S112: The OCF node 200 sends a confirmation of grant to the CTF node 180 of the updated resources reserved for this communication session. There could be different ways for the OCF node 200 to keep track of the communication sessions for which reauthorization should be initiated. In some aspects, these communication sessions are identified via stored metadata. In particular, in some embodiments, the subset of communication sessions is identified by stored metadata that specifies that higher amount of resources than requested by the CTF node 180 has been granted for the communication sessions.

In some aspects, in order to identify the subset of communication sessions using stored metadata, metadata is stored for any communication session having been granted an excess quota of resources. Therefore, in some embodiments, the OCF node 200 is configured to perform (optional) step S102:

S102: The OCF node 200 stores the metadata per communication session upon having granted the higher amount of resources than requested by the CTF node 180 per communication session.

In some embodiments, the metadata is stored only when the OCS 130 is in the overload condition.

Further aspects of storing metadata will be disclosed next with reference to Fig. 4. Fig. 4 is a flowchart of a method for the OCS 130 to reserve resource for a subscriber 110 according to an embodiment. At step S301 the OCS 130 receives a resource control request (or CCR) for a communication session for a subscriber 110 from the CTF node 180. At step S302 it is checked whether the OCS 130 is in an overload condition or not. If yes, step S303 is entered, and if no, step S305 is entered. At step S303 a higher quota of resources than requested is granted for the CCR request, assuming that such a higher quota of resources is available for the subscriber 110. The amount of additional quota can be determined according to configuration or be dynamically evaluated by the OCS 130 itself. At step S304 metadata of the communication session for which the higher quota of resources has been granted is stored. At step S305 a standard quota of resources is granted for the CCR request, assuming that such a standard quota of resources is available for the subscriber 110.

As noted above, reauthorization is initiated in step S104 towards the CTF node 180 for at least a subset of the communication sessions. There could be different ways to determine the order in which reauthorization of the communication sessions is initiated. Aspects of how reauthorization of the communication sessions might be initiated will be disclosed next with parallel reference to Fig. 5. Fig. 5 is a flowchart of a method for reauthorization of the communication sessions according to embodiments. At step S402 it is assumed that the OCS 130 is in a normal condition and thus normal operation is ongoing. At step S402 it is assumed that the OCS 130 is in an overload condition. At step S403 it is checked whether the OCS 130 has recovered from the overload condition or not. Step S405 is entered if the OCS 130 has recovered from the overload condition. Else (i.e., if the OCS 130 is still in the overload condition) step S404 is entered. At step S404 default overload handling of the OCS 130 is performed. At step S405 it is checked whether there are any ongoing communication sessions for which additional quota was granted whilst the OCS 130 was in the overload condition. Step S405 is entered if there are any such ongoing communication sessions. Else (i.e., if there are not any such ongoing communication sessions) step S401 is entered again. At step S406 all those communication sessions for which additional quota was granted whilst the OCS 130 was in overload condition are retrieved. A subset of those communication sessions is identified. At step S407 reauthorization of the subsets is initiated according to an order. As noted above, the reauthorization might be initiated by the OCF 200 sending RAR messages, on per communication session, to the CTF node 180. The order according to which reauthorization of the subsets is initiated is given by at least one criterion. There could be different examples of criteria. In some non-limiting examples the criterion pertains to: amount of time until a timer expires for the higher amount of resources than requested by the CTF node 180, amount of time since request for resources for which the higher amount of resources than requested by the CTF node 180 was granted (i.e., based on how long time ago the request was received), and/ or the order in which requests arrive at the OCS 130 for new resources for the communication sessions. The OCS 130 could thus use different strategies to identify the subsets of communication sessions, such as furthest time to the validity timer expiry of the communication session, batches of the first N number of requests, lazy or on-demand (for example, when the request for a quota of resources for the different service for the same subscriber no arrives at the OCS 130 then the OCS 130 might sends the RAR for the communication session which was granted higher quota for the same subscriber 110). Reauthorization of the subset of communication sessions might then be initiated for one subset after another subset according to the order until reauthorization for all the subsets has been initiated. This enables the reauthorization to be carried out in a controlled manner so that there is no sudden increased signalling from the CTF node 180 towards the OCS 130, which otherwise might cause the OCS 130 to again enter the overload condition. Steps S405, S406, S407 might thus be executed in a loop until all the outstanding communication sessions have been reauthorized. There might be a time delay introduced between each iteration so that the communication sessions are authorized by the OCS 130 whilst maintaining a manageable burst of requests from the CTF node 180. That is, in some embodiments, initiation of reauthorization between adjacent pairs of the subsets is delayed by a time amount.

Reference is now made to the signalling diagram of Fig. 6 illustrating a method for operating an OCS 130 upon the OCS 130 recovering from an overload condition according to an embodiment. The assumptions made in Fig. 2 are valid for Fig. 6 as well, except the operations that metadata for the communication session is stored and the operations performed when the OCS 130 recovers from the overload condition. As for Fig. 2, also Fig. 6 provides a simplified illustration of exchange of messages in one portion of the network 100 and is not intended to reflect every signal or communication exchanged between the entities of the network 100. Furthermore, some communication shown in Fig. 6 maybe indirect. For example, an indirect connection may involve the passing of messages by, and or through, an intermediary device (e.g., a Diameter signaling router) and/or an intermediary network not illustrated in Fig. 6. Also, it is assumed that policy evaluation based on the policies on the subscriber profile information have been already been performed based on the communication between PGW and PCRF, and Fig. 6 does not include any message exchange for the same.

As shown in Fig. 6, at step S501, a subscriber no attaches to the network 100 and initiates a communication session. As indicated at step S502 it is assumed that the initial available balance for subscriber 110 for reservation of resources is 750MB. At step S503, the CTF node 180 sends an initial credit control request (CCR-I) for service si to the OCS 130 (e.g. on the Gy interface) to request a quota of resources for the subscriber no. Assume, at step S504, that the OCS 130 does not detect any potential overload conditions. Thus, OCS 130 might allocate a standard quota of resources for the subscriber 110. The standard quota maybe, for example, 10% of the total data limit for the subscriber 110, with a maximum of 250 MB and a minimum of 50 MB. At step S505 the OCS 130 returns a CCA-I with the standard quota (e.g., 250 MB).

At step S506, assume that OCS 130 has entered an overload condition. An additional quota of resources is added to all granted CCRs until the OCS 130 has recovered from the overload condition. As indicated at step S507 the available balance for subscriber 110 is 500MB. At step S508 the CTF node 180 detects that the standard quota from step S505 is exhausted and, at step S509 the CTF node 180 sends an updated CCR (CCR-U) to the OCS 130 to request an update quota of resources for the communication session for service si for subscriber 110. At step S510 the OCS 130 determines to add the additional quota to the standard quota for the CCR-U. At Step S510 also the metadata information of the communication session for which the additional quota has been allocated when the OCS 130 is in the overload condition is stored. Thus, at step S511 the OCS 130 returns a CCA-U with an additional quota (e.g., a total quota of 450 MB).

At step S512 it is assumed that the OCS 130 has recovered from the overload condition. Thus, no additional quota of resources is to be added when responding to the CCR-U. As indicated at step S513 the available balance for reservation for subscriber 110 is 50MB.

At step S514 the OCF node 200 retrieves a subset of the communication sessions and retrieves the corresponding metadata. Different strategies to identify this subset of communication sessions have been disclosed above and apply also here. At step S515 the OCF node 200 for the identified communication sessions sends a RAR message to the CTF node 180.

At step S516 the CTF node 180 acknowledges receipt of the RAR message by sending an RAA message to the OCF node 200. Steps S514, S515, S516 are repeated for all the communication sessions within the identified subset. Further, steps S514, S515, S516 are be repeated until all the outstanding communication sessions, for which an additional quota of resources had been granted whilst the OCS 130 was in the overload condition, have been reauthorized.

At step S517 the CTF node 180 sends a CCR-U message for the service si to the OCS 130 reporting the current usage of the quota (e.g. 100MB) for the service si. This current reporting of the resource usage might by the OCF node 200 be used to update the subscriber balance and free up unused reserved resources. At step S518 a standard quota of resources (e.g. 250MB) is granted as the OCS 130 is not in overload condition. As indicated at step S519 the available balance for reservation for subscriber 110 is 150MB (since 50MB + 350MB - 250MB = 150 MB).

At step S520 the CTF node 180 sends a CCR-U message for a new, different, service s2 for the subscriber no to the OCS 130 (e.g. on the Gy interface) to request a quota of resources (e.g. 100MB) for the subscriber. Since there is now enough balance in the subscriber account for reservation, the OCF 200 responds with a CCA-U message with a quota of 100MB and there is no service denial. Hence the herein disclosed embodiments enable parallel communication sessions/new communication session to utilize this available balance, thus enabling better subscriber resources utilization than state of the art.

Fig. 8 schematically illustrates, in terms of a number of functional units, the components of an OCF node 200 according to an embodiment. Processing circuitry 210 is provided using any combination of one or more of a suitable central processing unit (CPU), multiprocessor, microcontroller, digital signal processor (DSP), etc., capable of executing software instructions stored in a computer program product 1010 (as in Fig. 10), e.g. in the form of a storage medium 230. The processing circuitry 210 may further be provided as at least one application specific integrated circuit (ASIC), or field programmable gate array (FPGA). Particularly, the processing circuitry 210 is configured to cause the OCF node 200 to perform a set of operations, or steps, as disclosed above. For example, the storage medium 230 may store the set of operations, and the processing circuitry 210 maybe configured to retrieve the set of operations from the storage medium 230 to cause the OCF node 200 to perform the set of operations. The set of operations maybe provided as a set of executable instructions.

Thus the processing circuitry 210 is thereby arranged to execute methods as herein disclosed. The storage medium 230 may also comprise persistent storage, which, for example, can be any single one or combination of magnetic memory, optical memory, solid state memory or even remotely mounted memory. The OCF node 200 may further comprise a communications interface 220 at least configured for communications with other functions, entities, nodes, and devices of the network 100, such as the OCF node 180 and the gateway 120. As such the communications interface 220 may comprise one or more transmitters and receivers, comprising analogue and digital components. The processing circuitry 210 controls the general operation of the OCF node 200 e.g. by sending data and control signals to the communications interface 220 and the storage medium 230, by receiving data and reports from the communications interface 220, and by retrieving data and instructions from the storage medium 230. Other components, as well as the related functionality, of the OCF node 200 are omitted in order not to obscure the concepts presented herein.

Fig. 9 schematically illustrates, in terms of a number of functional modules, the components of an OCF node 200 according to an embodiment. The OCF node 200 of Fig. 9 comprises an initiate module 210b configured to perform step S104. The OCF node 200 of Fig. 9 may further comprise a number of optional functional modules, such as any of a store module 210a configured to perform step S102, a receive module 210c configured to perform step S106, a receive module 2iod configured to perform step S108, a update module 2ioe configured to perform step S110, a send module 2iof configured to perform step S112. In general terms, each functional module 210a- 2iof may in one embodiment be implemented only in hardware and in another embodiment with the help of software, i.e., the latter embodiment having computer program instructions stored on the storage medium 230 which when run on the processing circuitry makes the OCF node 200 perform the corresponding steps mentioned above in conjunction with Fig 9. It should also be mentioned that even though the modules correspond to parts of a computer program, they do not need to be separate modules therein, but the way in which they are implemented in software is dependent on the programming language used. Preferably, one or more or all functional modules 2ioa-2iof may be implemented by the processing circuitry 210, possibly in cooperation with the communications interface 220 and/ or the storage medium 230. The processing circuitry 210 may thus be configured to from the storage medium 230 fetch instructions as provided by a functional module 2ioa-2iof and to execute these instructions, thereby performing any steps as disclosed herein.

The OCF node 200 maybe provided as a standalone device or as a part of at least one further device. For example, the OCF node 200 may be provided in a node of the OCS 130. Alternatively, functionality of the OCF node 200 maybe distributed between at least two devices, or nodes. These at least two nodes, or devices, may either be part of the same network part or maybe spread between at least two such network parts. In general terms, instructions that are required to be performed in real time may be performed in a device, or node, operatively closer to the cell than instructions that are not required to be performed in real time.

Thus, a first portion of the instructions performed by the OCF node 200 may be executed in a first device, and a second portion of the of the instructions performed by the OCF node 200 maybe executed in a second device; the herein disclosed embodiments are not limited to any particular number of devices on which the instructions performed by the OCF node 200 maybe executed. Hence, the methods according to the herein disclosed embodiments are suitable to be performed by an OCF node 200 residing in a cloud computational environment. Therefore, although a single processing circuitry 210 is illustrated in Fig. 8 the processing circuitry 210 may be distributed among a plurality of devices, or nodes. The same applies to the functional modules 2ioa-2iof of Fig. 9 and the computer program 1020 of Fig. 10.

Fig. 10 shows one example of a computer program product 1010 comprising computer readable storage medium 1030. On this computer readable storage medium 1030, a computer program 1020 can be stored, which computer program 1020 can cause the processing circuitry 210 and thereto operatively coupled entities and devices, such as the communications interface 220 and the storage medium 230, to execute methods according to embodiments described herein. The computer program 1020 and/or computer program product 1010 may thus provide means for performing any steps as herein disclosed.

In the example of Fig. 10, the computer program product 1010 is illustrated as an optical disc, such as a CD (compact disc) or a DVD (digital versatile disc) or a Blu-Ray disc. The computer program product 1010 could also be embodied as a memory, such as a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), or an electrically erasable programmable read-only memory (EEPROM) and more particularly as a non-volatile storage medium of a device in an external memory such as a USB (Universal Serial Bus) memory or a Flash memory, such as a compact Flash memory. Thus, while the computer program 1020 is here schematically shown as a track on the depicted optical disk, the computer program 1020 can be stored in any way which is suitable for the computer program product 1010.

The inventive concept has mainly been described above with reference to a few embodiments. However, as is readily appreciated by a person skilled in the art, other embodiments than the ones disclosed above are equally possible within the scope of the inventive concept, as defined by the appended patent claims.

Claims

1. A method for operating an Online Charging System, OCS, (130) upon the OCS (130) recovering from an overload condition, the method being performed by an Online Charging Function, OCF, node (200) of the OCS (130), the method comprising: initiating (S104), as a result of the OCS (130) having recovered from the overload condition, reauthorization towards a Charging Trigger Function, CTF, node (180) for at least a subset of any communication sessions for which a higher amount of resources than requested by the CTF node (180) has been granted by the OCS (130) and for which granted resources are remaining upon the OCS (130) having recovered from the overload condition.

2. The method according to claim 1, wherein the reauthorization is initiated by the OCF node (200) sending a reauthorization request message to the CTF node (180).

3. The method according to claim 2, further comprising: receiving (S106), from the CTF node (180), an answer to the reauthorization request message for one of the communication sessions for which reauthorization was initiated; and updating (S110) the amount of resources reserved for said one communication session.

4. The method according to claim 3, further comprising: receiving (S108), from the CTF node (180), an update request for resources for said one of the communication sessions, wherein the update request further specifies a consumed amount of resources for said one communication session, and wherein the amount of resources reserved for said one communication session is updated at least according to the remaining granted resources and the consumed amount of resources; and sending (S112) a confirmation of grant to the CTF node (180) of the updated resources reserved for said one communication session.

5. The method according to claim 4, wherein the amount of resources reserved for said one communication session is updated by releasing all granted but still remaining resources for said one communication session and reserving new resources for said one communication session.

6. The method according to claim 4, wherein the amount of resources reserved for said one communication session is updated by releasing an amount of resources for the communication session equal to a difference between the granted but still remaining resources for said one communication session and new resources for said one communication session.

7. The method according to any of claims 4, 5, or 6, wherein the update request for resources specifies an amount of new resources requested to be reserved for said one communication session.

8. The method according to any of the preceding claims, wherein reauthorization of the subsets is initiated according to an order, and wherein said order is given by at least one criterion.

9. The method according to claim 8, wherein said criterion pertains to: amount of time until a timer expires for the higher amount of resources than requested by the CTF node (180), amount of time since request for resources for which the higher amount of resources than requested by the CTF node (180) was granted, and/or the order in which requests arrive at the OCS (130) for new resources for the communication sessions.

10. The method according to claim 8 or 9, wherein the reauthorization of the subset of communication sessions is initiated for one subset after another subset according to the order until reauthorization for all the subsets has been initiated.

11. The method according to claim 10, wherein initiation of reauthorization between adjacent pairs of the subsets is delayed by a time amount.

12. The method according to any of the preceding claims, wherein the subset of communication sessions is identified by stored metadata that specifies that higher amount of resources than requested by the CTF node (180) has been granted for the communication sessions.

13. The method according to claim 12, further comprising: storing (S102) the metadata per communication session upon having granted said higher amount of resources than requested by the CTF node (180) per communication session.

14. The method according to claim 13, wherein the metadata is stored only when the OCS (130) is in the overload condition.

15. The method according to any of the preceding claims, wherein said higher amount of resources than requested by the CTF node (180) was granted whilst the OCS (130) was in the overload condition.

16. The method according to any of the preceding claims, wherein the CTF node (180) is part of, integrated with, or collocated with, a packet gateway, PGW, or a communication session management function, SMF.

17. An Online Charging Function, OCF, node (200) for operating an Online Charging System, OCS, (130) upon the OCS (130) recovering from an overload condition, the OCF node (200) comprising processing circuitry (210), the processing circuitry being configured to cause the OCF node (200) to: initiate, as a result of the OCS (130) having recovered from the overload condition, reauthorization towards a Charging Trigger Function, CTF, node (180) for at least a subset of any communication sessions for which a higher amount of resources than requested by the CTF node (180) has been granted by the OCS (130) and for which granted resources are remaining upon the OCS (130) having recovered from the overload condition.

18. An Online Charging Function, OCF, node (200) for operating an Online Charging System, OCS, (130) upon the OCS (130) recovering from an overload condition, the OCF node (200) comprising: an initiate module (210b) configured to initiate, as a result of the OCS (130) having recovered from the overload condition, reauthorization towards a Charging Trigger Function, CTF, node (180) for at least a subset of any communication sessions for which a higher amount of resources than requested by the CTF node (180) has been granted by the OCS (130) and for which granted resources are remaining upon the OCS (130) having recovered from the overload condition.

19. The OCF node (200) according to claim 17 or 18, further being configured to perform the method according to any of claims 2 to 16.

20. A computer program (1020) for operating an Online Charging System, OCS, (130) upon the OCS (130) recovering from an overload condition, the computer program comprising computer code which, when run on processing circuitry (210) of an Online Charging Function, OCF, node (200), causes the OCF node (200) to: initiate (S104), as a result of the OCS (130) having recovered from the overload condition, reauthorization towards a Charging Trigger Function, CTF, node (180) for at least a subset of any communication sessions for which a higher amount of resources than requested by the CTF node (180) has been granted by the OCS (130) and for which granted resources are remaining upon the OCS (130) having recovered from the overload condition.

21. A computer program product (1010) comprising a computer program (1020) according to claim 20, and a computer readable storage medium (1030) on which the computer program is stored.