Patent Description:
Online Charging is a billing methodology in telecommunication networks where charging information for network resource usage is collected in parallel along with the resource usage. <NPL>) defines online charging as a "charging mechanism where charging information can affect, in real-time, the service rendered and therefore a direct interaction of the charging mechanism with session/service control is required". The opposite of online charging is offline charging, and this is defined as a "charging mechanism where charging information does not affect, in real-time, the service rendered".

<FIG> from section <NUM> of <NPL>) illustrates an example of a high level common charging architecture applicable to all 3GPP network domains, subsystems and services. Note that <FIG> only provides a common logical view of the charging architecture and information flows for offline and online charging. The content of the dash dotted box with reference number 100a is applicable to the fourth Generation (<NUM>) communication technology and the content of the dashed box with reference number 100b is applicable to the fifth Generation (<NUM>) communication technology. <NUM> 100a comprises a rectangle illustrating offline charging 102a and another rectangle illustrating online charging 102b. <NUM> 100b comprises a rectangle illustrating converged online offline charging 102c.

<FIG> shows a billing domain <NUM> which is applicable to both <NUM> 100a and <NUM> 100b. The billing domain <NUM> provides charging information to the network.

For the offline charging 102a in <NUM> 100a, the billing domain <NUM> illustrated in <FIG> is adpated to be connected, via a Bx interface, to a Charging Gateway Function (CGF) <NUM>. The CGF <NUM> is adpated to be connected to, via a Ga interface, to a Charging Data Function (CDF) <NUM>. The CDF <NUM> is adpated to be connected to, via a Rf interface, to Network Elements (NE) <NUM>. For online charging 102b in <NUM> 100a, the billing domain <NUM> is adapted to be connected, via the Bx interface, to a Online Charging System (OCS) <NUM>. The OCS <NUM> is adpated to be connected to, via a Ro interface, to the NE <NUM>.

For <NUM> 100b which has converged online offline charging 102c, the billing domain <NUM> is adapted to be conencted, via the Bx interface, to the OCS <NUM>. Th eOCS <NUM> in <NUM> 100b is adpated to be connected to, vi a Nchf interface, Network Functions (NF) <NUM>.

Both <NUM> and <NUM> comprise methods for handling credit authorizations. <NUM> provides a method to reserve and commit credit of subscriber's credit account for a service which being used. In <NUM>, this is achieved by using the following REST based requests of the Nchf_ConvergedCharging service:.

<NUM> provides a method to reserve and commit credit of subscriber's account for a service being used. This is achieved in <NUM> by using the following diameter based requests:.

Today smart phones or feature phones are capable of running multiple services concurrently. For instance, it is always possible that mobile applications installed on a subscriber phone, i.e. the UE <NUM>, is consuming data in the background while the subscriber is making a long distance international call and at the same time some mobile application is sending a status SMS message to a remote server. Thus, these various services are being used by the subscriber in parallel and also charges are being deducted concurrently from subscriber's account. This may lead to reaching the low balance condition of the subscriber's account. The low balance condition may occur when a credit threshold has been reached or fallen below. The term low balance condition and credit threshold may be used interchangeably herein.

Consider the following scenario as an example:
John is an active prepaid subscriber in US having a mobile phone. John is a busy person and likes to multitask to save time. He has a Facebook application on his mobile phone which continuously synchronizes with Facebook servers to get the latest updates about his friends. He is also actively involved in share trading and has an application which continuously gets the latest updates from NASDAQ. These applications continuously consume credit of his prepaid account in real time. John also needs to talk to one of his business associate Mohan which is in India for some important business requirements. On a weekend, John makes a long-distance International call to Mohan and as he is talking, his account balance is getting consumed. Some minutes later, John's account balance reaches the threshold of low balance and he begins getting low balance indicators on his mobile phone. With the current technology, John has two options when the low balance threshold is reached. He is either forced to abort the call early or to do a refill so that he has sufficient balance to continue his communication.

From a <NUM> network point of view also, if John is using <NUM> different network slices for <NUM> different services consuming money from same balance account, he might also face the above described problem if his balance reaches a low balance condition.

Therefore, there is a need to at least mitigate or solve this issue.

<CIT> discloses dynamically allocating quotas for the access and use of a telecommunications network by consumers that use a shared balance account.

<CIT> discloses a prepaid billing system for wireless networks that involves receiving block of credits and measurement-method parameters from control device in response to request for wireless communication device.

<CIT> discloses detecting that the last credit for a service has been consumed, and in response executing a decision about handling network resources such as downgrading the Quality of Service being provided for the service.

<CIT> discloses a communication system to control communication usage among a group of users that comprise rating group.

<CIT> discloses a system and method for dynamically allocating quota for shared balances in distributed telecommunications networks.

<CIT> discloses a communication device and dynamic source determination of provisioning information on a wireless communication device.

An objective of embodiments herein is therefore to obviate at least one of the above disadvantages and to improve handling of a subscriber's communication services. Furthermore, the embodiments of the invention are those defined by the claims. Moreover, examples and embodiments, which are not covered by the claims are presented not as embodiments of the invention, but as background art or examples useful for understanding the invention.

According to a first aspect, the object is achieved by a method performed by a charging function for handling a subscriber's communication services. The charging function detects that a subscriber's credit account has reached or fallen below a credit threshold when the subscriber has multiple ongoing communication services consuming credit from the credit account. The charging function sends a threshold notification of the reached or fallen below credit threshold to a UE on which the subscriber has at least one of the multiple ongoing communication services. The charging function determines if a response to the threshold notification has been received from the UE with prioritization of one of the multiple ongoing communication services. If a response with prioritization of one communication service has been received, the charging function initiates termination of all ongoing communication services except the prioritized communication service and provides at least substantially all available credit to be available for the prioritized communication service.

According to a second aspect, the object is achieved by a method performed by a UE for handling a subscriber's communication services. The subscriber has at least one of multiple ongoing communications services ongoing on the UE. The UE receives, from a charging function, a threshold notification of that the subscriber's credit account has reached or fallen below a credit threshold for multiple ongoing communication services consuming credit from the same credit account.

According to a third aspect, the object is achieved by a charging function configured to detect that a subscriber's credit account has reached or fallen below a credit threshold when the subscriber has multiple ongoing communication services consuming credit from the credit account. The charging function is configured to send a threshold notification of the reached or fallen below credit threshold to a UE on which the subscriber has at least one of the multiple ongoing communication services. The charging function is configured to determine if a response to the threshold notification has been received from the UE with prioritization of one of the multiple ongoing communication services. The charging function is configured to, if a response with prioritization of one communication service has been received, initiate termination of all ongoing communication services except the prioritized communication service, and to provide at least substantially all available credit to be available for the prioritized communication service.

According to a fourth aspect, the object is achieved by a UE configured to receive, from a charging function, a threshold notification of that the subscriber's credit account has reached or fallen below a credit threshold for multiple ongoing communication services on the UE consuming credit from the same credit account.

Thanks to the prioritization of one of the multiple ongoing communication services by the UE, the communication service which is considered most important by the subscriber using the UE can continue when a credit threshold of the subscriber's credit account has been reached or fallen below. Consequently, the handling of the subscriber's communication service is improved.

Embodiments herein afford many advantages, of which a non-exhaustive list of examples follows:
One advantage of the embodiments herein is that they enable the system to gracefully handle a low balance condition which increases the user experience.

Another advantage of the embodiments herein is that it increases the user's convenience. The embodiments herein allows the user to focus on current task on his UE, for instance the user can continue talking in a voice call without manually aborting other services, which are consuming his account balance and thus continues his talk without any interruption.

Furthermore, an advantage of the embodiments herein is that they increase the user experience. The user can provide a priority for a prepaid service like voice, data and SMS over others. In case of contention of resource during a low balance condition, the service with highest priority is automatically continued by taking credit units from all other ongoing services. The user will then be able to use the prioritized service for a maximum time depending on the user's account balance.

Another advantage of the embodiments herein is that as a human, the user's attention span is limited to one ongoing activity and the fallback position of the embodiments herein enables prioritization of an ongoing activity without any manual intervention. This allows the user to focus on his current task, for instance the ongoing voice call, and all the remaining credit balance in the user's account is made available to the ongoing prioritized service.

A further advantage of the embodiments herein is that they also help in saving energy and power as any further communication request for credit resources will be blocked in case of the low balance condition, leading to reduced energy consumption.

The embodiments herein are not limited to the features and advantages mentioned above. A person skilled in the art will recognize additional features and advantages upon reading the following detailed description.

The embodiments herein will now be further described in more detail by way of example only in the following detailed description by reference to the appended drawings illustrating the embodiments and in which:.

The drawings are not necessarily to scale and the dimensions of certain features may have been exaggerated for the sake of clarity. Emphasis is instead placed upon illustrating the principle of the embodiments herein.

With the embodiments herein, in case of low balance, the subscriber may like to prioritize one service over all other ongoing services such that only prioritized service continues while all other ongoing services are disrupted. Current charging protocols and standards do not provide method for a subscriber to provide his preferences or priority of service continuation when the credit of the subscriber is low. Prepaid subscribers do not have a choice in giving preference to a service over other ongoing services when multiple services are running concurrently, and this becomes important when the subscriber's account reaches the low balance condition during the consumption.

Continuing with the example above with John who makes a long-distance International call to this friend Mohan in India, and as he is talking, his account balance is getting consumed. Some minutes later, John's account balance reaches the threshold of low balance and he begins getting low balance indicators on his mobile phone. At this point of time, John wants to prioritize his ongoing voice call over all other ongoing services for the remaining credit units in his account such that all other ongoing communications from his mobile phone are stopped, and so that he can continue with his international call for the maximum time allowed. John would like to have this option at runtime, e.g. during the ongoing call, where he is asked for this input and all other communication except the ongoing voice call from his mobile phone are denied credit units from his account. This allows John to consume his remaining account balance for his ongoing voice call with Mohan dedicatedly. John may also like to configure this priority for voice call in case of low balance condition as part of a setting in his account.

<FIG> depicts a communications system in which embodiments herein may be implemented. The communications system may in some embodiments apply to one or more radio access technologies such as for example Second Generation (<NUM>), Third Generation (<NUM>), Fourth Generation (<NUM>), Fifth Generation (<NUM>), or any other Third Generation Partnership Project (3GPP) radio access technology, or other radio access technologies such as e.g. WLAN.

The communication system comprises the UE <NUM> which is adapted to be connected to and communicate with a policy node <NUM>. The policy node <NUM> may be for example a PGW or a PCEF. The policy node <NUM> is adapted to be connected to and communicate with a charging function <NUM>. The charging function <NUM> may be for example an OCS <NUM> or a CHF. The charging function <NUM> may be implemented in or performed by a node, a device or any other suitable apparatus.

The UE <NUM> may be a device by which a subscriber may access services offered by an operator's network and services outside operator's network to which the operator's radio access network and core network provide access, e.g. access to the Internet. The UE <NUM> may be any device, mobile or stationary, enabled to communicate in the communications network, for instance but not limited to e.g. user equipment, mobile phone, smart phone, sensors, meters, vehicles, household appliances, medical appliances, media players, cameras, Machine to Machine (M2M) device, Device to Device (D2D) device, Internet of Things (IoT) device, terminal device, communication device or any type of consumer electronic, for instance but not limited to television, radio, lighting arrangements, tablet computer, laptop or Personal Computer (PC). The UE <NUM> may be portable, pocket storable, hand held, computer comprised, or vehicle mounted devices, enabled to communicate voice and/or data, via the radio access network, with another entity, such as another UE or a server.

A subscriber may be defined as a user of a UE <NUM> which is subscribing to a communication service which provides access to an operator's communication network using mobile communication technology. The subscription may be identified with an ID. The terms subscriber and user may be used interchangeably herein. The subscriber may have a credit account from which the operator charges the subscriber for its use of communication services. The credit account may be a pre-paid or a post-paid type of account. The subscriber may have one or a plurality of UEs <NUM> to which the same credit account is associated, i.e. the subscriber's subscription may be associated with one or a plurality of UEs <NUM>. With this, the user may have multiple ongoing communication services on one or multiple UEs <NUM> that is charged from the same credit account.

It should be noted that the communication links in the communications system <NUM> may be of any suitable kind including either a wired or wireless link. The link may use any suitable protocol depending on type and level of layer, e.g. as indicated by the Open Systems Interconnection (OSI) model, as understood by the person skilled in the art.

When a credit threshold is reached or fallen below, it is not possible to continue with all communication services for a long time. To increase the user experience, it will be an advantage if the subscriber is asked which service he wants to continue with using the remaining balance. When a credit threshold is reached or fallen below, the subscriber may be given an option to choose a service to continue with among all other concurrently ongoing services being used by him. The subscriber can prioritize any service of his choice. The subscriber may also be referred to as a user.

One example will now be described with reference to <FIG> and <FIG>. <FIG> illustrates steps <NUM>-<NUM> and <FIG> illustrates steps <NUM>-<NUM>, i.e. <FIG> is a continuation of <FIG>. Suppose that a subscriber A has a UE <NUM> which is adapted for multitasking. When the UE <NUM> is adapted for multitasking, it may be referred to as a smart UE <NUM>. The subscriber A is a prepaid subscriber with a current balance of $<NUM>. The subscriber A is making an international call to his friend in another country at the same time as a popular movie song app on his UE <NUM> is automatically downloading a movie song in the background. The friend is referred to as subscriber B. The subscriber A is consuming both data services and voice services at the same time. To charge the consumption of various ongoing communication services such as voice and data in real time, the subscriber A's account balance is continuously being reserved and decremented.

<FIG> and <FIG> show how various ongoing concurrent communication services such as voice and data consumed by the subscriber A are being charged in the telecommunication operator network. Assume that the prepaid subscriber A has $<NUM> in his account. Also assume that the credit threshold for low balance for the subscriber A is $<NUM>. So, when the account balance of the subscriber A's account is $<NUM> or below $<NUM>, the credit threshold is reached for the subscriber. The communication illustrated in <FIG> and <FIG> are between the UE <NUM> and a charging node <NUM>. The charging node <NUM> is associated with a certain telecommunication operator.

The method illustrated in <FIG> and <FIG> comprises at least one of the following steps, which steps may be performed in any suitable order than described below:.

This step is seen in <FIG>. Subscriber A using his UE <NUM> makes a voice call to another subscriber, e.g. subscriber B. This may also be described as a UE <NUM> sends a communication service request to a charging node <NUM> associated with the subscriber A's telecommunication operator. The charging node <NUM> receives the communication service request from the UE <NUM>. The requested communication service is exemplified with a voice call in <FIG>. The requested communication service may be referred to as a first communication service.

This step is seen in <FIG>. The communication service request for the voice leads to a reservation of $<NUM> for the voice service from the subscriber's prepaid account handled by the charging function <NUM>.

This step is seen in <FIG>. After steps <NUM> and <NUM>, or in parallel with steps <NUM> and <NUM>, a communication service request for data is sent from the UE <NUM> to the charging node <NUM>. An example of a communication service request for data may be that a song app in the UE <NUM> downloads a song. This communication service request for data may be referred to as a second communication service request.

This step is seen in <FIG>. The communication service request for the data leads to a reservation of another $<NUM> for the ongoing data service from the subscriber A's prepaid credit account.

This step is seen in <FIG>. The voice call started in step <NUM> continues.

This step is seen in <FIG>. The subscriber quickly exhausts $<NUM> for the voice call and again reserves further $<NUM> for continuing with the voice service.

Till now, the following is a breakup of credit reservation out of the total $<NUM> which is available in the subscriber's credit account:.

This step is seen in <FIG>. The voice call continues from subscriber A to subscriber B. With this, the UE <NUM> sends a request to commit further reservation of another $<NUM> to the charging function <NUM>.

This step is seen in <FIG>. Now as the voice call progress, a request to commit further reservation of another $<NUM> comes in to continue the voice call. Now $<NUM> are either reserved or consumed and $<NUM> are remaining in the subscriber account.

This step is seen in <FIG>. The credit reservation request in steps <NUM> and <NUM> will create a condition for low balance, as, after this reservation, the account balance of subscriber A is reduced to $<NUM> which is less than low balance threshold value of $<NUM>.

This step is seen in <FIG>. The charging function <NUM> sends a low balance indicator to the UE <NUM>.

With the existing technology the charging function <NUM> would either force the subscriber A to abort the call early or do a refill so that he has sufficient balance to continue his communication.

With the embodiments herein, the subscriber is asked to prioritize his ongoing voice call so that his voice call can get the maximum of remaining credit units when there is shortage of credit units (low balance condition). Credit units reserved by other sessions are made available to the voice service. Making the credit units available to the voice service may happen automatically without any intervention by the subscriber A, allowing the subscriber A to continue with his voice call to the maximum time without any disruption. It is up to the subscriber A to prioritize any ongoing service over others during the low balance condition.

This step is seen in <FIG>. The UE <NUM> sends, to the charging function <NUM>, information indicating that the voice call is the prioritized service.

This step is seen in <FIG>. The charging function <NUM> initiates termination of ongoing services except the prioritized voice call.

This step is seen in <FIG>. The charging function <NUM> may send, to the UE <NUM>, information indicating the termination of ongoing services except the prioritized voice call.

This step is seen in <FIG>. Subscriber A continues his remaining balance for the ongoing voice call. All remaining available resources are made available to ongoing voice for consumption. The subscriber A can later resume his services as before by doing refill and increase his account balance thus moving away from the low balance state.

The example in <FIG> and <FIG> is for a pre-paid credit account, but the example is also applicable to a post-paid credit account when the account balance is near to an allowed maximum credit limit, and then the subscriber services may be throttled if the maximum credit limit is exhausted.

In the embodiments herein, during usage of multiple services consuming balance from same account balance and when a credit threshold is reached or fallen below, the UE <NUM> is notified that "You have reached a low balance condition". Then the user of the UE <NUM> is asked to prioritize one of the ongoing communication services being consumed concurrently by him. If user wish, he can proceed to choose any one service of his choice to continue with among all concurrently ongoing services. If the user of the UE <NUM> does not choose any service, then a predefined or preconfigured fallback priority may be used. In case there is no fallback priority, the charging function <NUM> may apply a legacy method. Based on the user selection or based on a fallback priority, one of the ongoing services will keep on going while the rest are all terminated.

<FIG> and <FIG> is a generic flow chart illustrating the embodiments herein. <FIG> illustrates steps <NUM>-<NUM> and <FIG> illustrates steps <NUM>-<NUM>, i.e. <FIG> may be seen as a continuation of <FIG>. One difference between <FIG> and <FIG>, and <FIG> and <FIG> described above is that <FIG> and <FIG> illustrates the fallback priority. Note that this does not mean that the embodiments illustrated in <FIG> and <FIG> does not have a fallback priority, but <FIG> and <FIG> does not show the fallback priority for sake of simplicity. The fallback priority maybe present in the embodiment shown in <FIG> and <FIG> in the same way as it is illustrated in <FIG> and <FIG>.

The subscriber has sufficient balance on his credit account to use N number of communication services provided by the telecommunication operator, where N is any positive integer. The subscriber is currently consuming the N number of services provided by the telecommunication operator and is using his same credit account in real-time to pay for these communication services.

The method illustrated in <FIG> and <FIG> comprises at least one of the following steps, which steps are performed in any suitable order than described below:.

This step is seen in <FIG>. This step corresponds to steps <NUM>, <NUM>, <NUM> and <NUM> in <FIG> and <FIG>. The subscriber uses multiple communication service on at least one UE <NUM>. In <FIG>, it is exemplified that the subscriber uses <NUM>, <NUM>,. N communication services, where N is a positive integer.

This step is seen in <FIG>. This step corresponds to steps <NUM>, <NUM>, <NUM> and <NUM> in <FIG> and <FIG>. A monetary amount is reserved and committed from the credit account for the used ongoing services <NUM> to N for same subscriber balance. This step is performed by the credit function <NUM>.

This step is seen in <FIG>. This step corresponds to step <NUM> in <FIG>. The charging function <NUM> checks if the low balance condition has been reached for the subscriber's credit account balance, i.e. the current balance in the credit account has credit threshold has been reached or fallen below. The method goes back to step <NUM> if the credit threshold has not been reached, indicated with "no" in <FIG>. The method proceeds to step <NUM> if the credit threshold has been reached or fallen below, indicated with "yes" in <FIG>.

This step is seen in <FIG>. This step corresponds to step <NUM> in <FIG>. This step is performed if the credit threshold has been reached or fallen below, indicated with "yes" in <FIG>. The charging function <NUM> sends a low balance indicator to UE <NUM> and asks for input to prioritize one of the ongoing N communication services.

This step is seen in <FIG>. This step corresponds to steps <NUM> and <NUM> in <FIG>. The charging function <NUM> checks if it has received any input for a prioritized communication service from the UE <NUM>. The method proceeds to step <NUM> if no input has been received, indicated with "no" in <FIG>. The method proceeds to step <NUM> if input has been received, indicated with "yes" in <FIG>.

This step is seen in <FIG>. The step is performed if the charging function <NUM> has not received any input for a prioritized communication service from the UE <NUM>. The charging function <NUM> checks if a predefined priority exist for the subscriber. The fallback priority may also be referred to as a fallback priority, a predetermined priority or a default priority. The predefined priority may be defined by the subscriber via the UE <NUM> at subscription start, before communication service usage, by customer login on self-service portal etc. The telecommunication operator may also predefine the priorities for various services defined in its network for all or some set of subscribers.

The method proceeds to step <NUM> if a fallback priority does not exist, indicated with "no" in <FIG>. The method proceeds to step <NUM> if a fallback priority exist, indicated with "yes" in <FIG>.

This step is seen in <FIG>. This step if a predefined priority does not exist, indicated with "no" in <FIG>, i.e. when priority for any ongoing communication service is not found by the charging function <NUM>. A legacy call flow is performed for the credit flow application when there is no predefined priority. The legacy call flow comprises that all ongoing communication services consume credit until the balance drops to zero value without any priority.

This step is seen in <FIG>. This step corresponds to step <NUM> in <FIG>. This step may be performed if the charging function <NUM> has received input for priority in step <NUM>, i.e. when the UE <NUM> has sent information indicating that communication service X is prioritized out of N communication services. This step may be performed if the charging function <NUM> has a predefined priority, as checked in step <NUM>, i.e. when a predefined priority for communication service X out of N communication services exist for the subscriber at the charging function <NUM>. The predefined priority may be predefined by the UE <NUM> at some previous time instance before step <NUM>, it may be predetermined by the charging function <NUM> etc..

Communication service X is prioritized from all ongoing communication services for the subscriber. The charging function <NUM> initiates stop of the usage of the subscriber's credit account for all communication services except the prioritized communication service X.

This step is seen in <FIG>. This step corresponds to step <NUM> in <FIG>. All services except the prioritized service X are terminated.

This step is seen in <FIG>. The charging function <NUM> sends a notification to the UE <NUM> with the following message: "Your chosen service will resume, and others will be discontinued as low balance condition is reached. To start using all services please recharge".

This step is seen in <FIG>. The prioritized communication service X continues and all available credit is made available to communication service X. The communication service X will terminate when the credit account is reduced to zero value, but the usage of service X is extended for maximum possible time.

Later when the subscriber does a recharge of its credit account has exceeded the credit threshold all services will resume as before. The subscriber would not be able to use any additional service except the prioritized service before the recharge if this configuration is either enabled by the subscriber or the telecommunication operator.

The embodiments herein may also be illustrated with the signaling diagrams in <FIG>, <FIG> and <FIG>. <FIG>, <FIG> and <FIG> illustrate that the subscriber can be allowed optimum use of credit in case of a low balance condition. <FIG> illustrates steps <NUM>-<NUM>, <FIG> illustrates steps <NUM>-<NUM> and <FIG> illustrates steps <NUM>-<NUM>. <FIG> may be seen as a continuation of <FIG>, and <FIG> may be seen as a continuation of <FIG>. The dotted lines in <FIG>, <FIG>, and <FIG> may represent responses or acknowledgement of earlier requests or they may represent to convey information back to the network entities or nodes.

The Diameter based Credit Control method in a <NUM> network is used as an example in <FIG>, <FIG> and <FIG>, however the example is equally applicable to REST based NF-CHF communication in a <NUM> network. For the Diameter based <NUM> example in <FIG>, <FIG> and <FIG>, the charging function <NUM> is exemplified with an OCS and the policy node <NUM> is exemplified with a PCEF.

For brevity, not all method steps are shown in <FIG>, <FIG> and <FIG>. For instance, the following scenarios are not illustrated but may still be performed:.

Before step <NUM>, the following example balance for the credit account is assumed:.

The method illustrated in <FIG>, <FIG> and <FIG> comprises at least one of the following steps, which steps may be performed in any suitable order than described below:.

This step is seen in <FIG>. This step corresponds to steps <NUM>, <NUM>, <NUM> and <NUM> in <FIG> and step <NUM> in <FIG>. The UE <NUM> sends a voice and data service request to the PCEF <NUM>. The request may be sent via the telecommunication network, e.g. the access network node <NUM>. The access network node <NUM> may be for example a Radio Access Network (RAN) node, an evolved NB (eNB, e NodeB), a gNB, a Base Transceiver Station (BTS), Radio Network Controller (RNC), Radio Base Station (RBS) etc..

These steps are seen in <FIG>. Step <NUM> above may lead to a credit authorization request sent from the PCEF <NUM> to the OCS <NUM> to start the voice session and the data session for the UE <NUM>. Step <NUM> is the request message for the voice service and step <NUM> is the request for the data service. The following Credit Control Request (CCR) message is sent from the PCEF <NUM> to the OCS <NUM>:.

<Credit-Control-Request> ::=
{ CC-Request-Type } = INITIAL_REQUEST
*[ Multiple-Services-Credit-Control ]
*[ Service-Identifier ] = Voice_123
[ Requested-Service-Unit ]
[ Rating-Group ].

*[ Service-Identifier ] = Data_123
[ Requested-Service-Unit ]
[ Rating-Group ].

This step is seen in <FIG>. The OCS <NUM> performs a credit authorization logic and reserves credits for the data service and the voice service from the respective resource pools.

These steps are seen in <FIG>. These steps are response of steps <NUM>-<NUM> with the confirmation of reserved units. The OCS <NUM> may send the Credit Control Answer (CCA) messages to the PCEF <NUM>. Step <NUM> is the response message for the voice service and step <NUM> is the response for the data service.

<Credit-Control-Answer> ::=
{ CC-Request-Type } = INITIAL_REQUEST
*[ Multiple-Services-Credit-Control ]
*[ Service-Identifier ] = Voice_123
[ Granted-Service-Unit ]
[ Rating-Group ]
[ Result-Code ] = <NUM>.

*[ Service-Identifier ] = Data_123
[ Granted-Service-Unit ]
[ Rating-Group ]
[ Result-Code ] = <NUM>.

This step is seen in <FIG>. The PCEF <NUM> sends, to the UE <NUM>, possibly via the telecommunication network represented by the access network node <NUM>, information indicating that the voice and data communication service request has been accepted. Thus, in response of step <NUM>, the UE <NUM> is informed that it is allowed to use the voice service and data communication service that was requested.

The telecommunication network, e.g. represented by the access network node <NUM>, communicates to the PCEF <NUM> that reserved credits for requested services are consumed and there is a need to commit and reserve further credits to continue rendering service.

This step is seen in <FIG>. The UE <NUM> starts using the voice and data communication services.

These steps are seen in <FIG>. After the reserved quota of credit is consumed, a further credit authorization and request for used service is sent from the PCEF <NUM> to the OCS <NUM>. Step <NUM> is for the voice service and step <NUM> is for the data service. The following CCR-Update (CCR-U) request is sent from the PCEF <NUM> to the OCS <NUM>:.

<Credit-Control-Request> ::=
{ CC-Request-Type } = UPDATE_REQUEST
*[ Multiple-Services-Credit-Control ]
*[ Service-Identifier ] = Voice_123
[ Requested-Service-Unit ]
[ Used-Service-Unit ]
[ Rating-Group ].

*[ Service-Identifier ] = Data_123
[ Requested-Service-Unit ]
[ Used-Service-Unit ]
[ Rating-Group ].

This step is seen in <FIG>. The OCS <NUM> performs commit logic for the requested service unit and a further credit authorization for the requested service unit, and reserves credits for the data service and the voice service from the respective resource pools.

These steps are seen in <FIG>. The OCS <NUM> may send a response to the requests in step <NUM> and <NUM> to the PCEF <NUM> with the confirmation of reserved credit units. Step <NUM> is for the voice service and step <NUM> is for the data service. The following CCA-Update (CCA-U) response may be sent from the OCS <NUM> to the PCEF <NUM>:.

<Credit-Control-Answer> ::=
{ CC-Request-Type } = UPDATE_REQUEST
*[ Multiple-Services-Credit-Control ]
*[ Service-Identifier ] = Voice_123
[ Granted-Service-Unit ]
[ Rating-Group ]
[ Result-Code ] = <NUM>.

The PCEF <NUM> sends a response to the telecommunication network represented by the access network node <NUM>. The step is a response to the request in step 505a.

The telecommunication network represented by the access network node <NUM> sends a request to the PCEF <NUM>. The request may be an iterative request, and may be the same as the request in step 505a. The request in step 509b may be sent until the low balance condition indication arrives.

This step is seen in <FIG>. After the reserved quota of credit is consumed again, a further credit authorization and commit request for the used service is sent from the PCEF <NUM> to the OCS <NUM>. At least one of the following CCR request messages is sent from the PCEF <NUM> to the OCS <NUM>:
<Credit-Control-Request> ::=
{ CC-Request-Type } = UPDATE_REQUEST
*[ Multiple-Services-Credit-Control ]
*[ Service-Identifier ] = Voice_123
[ Requested-Service-Unit ]
[ Used-Service-Unit ]
[ Rating-Group ]
*[ Service-Identifier ] = Data_123
[ Requested-Service-Unit ]
[ Used-Service-Unit ]
[ Rating-Group ].

This step is seen in <FIG>. This step corresponds to step <NUM> in <FIG> and step <NUM> in <FIG>. The OCS <NUM> performs commit logic for the granted service unit and performs a further credit authorization for the requested service unit. The OCS <NUM> reserves credits for the data service and the voice service from the respective resource pools. This time, due to further reservation of units, a predefined credit threshold is reached or fallen below. The OCS <NUM> will add this information in the step <NUM> (response to step <NUM>).

This step is seen in <FIG>. This step corresponds to step <NUM> in <FIG> and step <NUM> in <FIG>. The OCS <NUM> may send a response, to the PCEF <NUM>, of the request in steps <NUM>-<NUM> and/or step <NUM> with the confirmation of reserved units. A "Low-Balance-Indication" Attribute-Value Pairs (AVP) may be comprised in response as the subscriber's credit account balance has reached or fallen below a credit threshold. <Credit-Control-Answer> ::=
{ CC-Request-Type } = UPDATE_REQUEST
[ Low-Balance-Indication ]
*[ Multiple-Services-Credit-Control ]
*[ Service-Identifier ] = Voice_123
[ Granted-Service-Unit ]
[ Rating-Group ]
[ Result-Code ] = <NUM>
*[ Service-Identifier ] = Data_123
[ Granted-Service-Unit ]
[ Rating-Group ]
[ Result-Code ] = <NUM>.

The response may be further sent from the PCEF <NUM> to the telecommunication network.

This step is seen in <FIG>. The PCEF <NUM> may communicate to the UE <NUM> via the telecommunication network that the credit threshold has been reached or fallen below. The telecommunication network may be represented by the access network node <NUM>.

This step is seen in <FIG>. The UE <NUM> may be asked, e.g. in the form of a pop-up message, a voice message, a SMS, USSD other any other suitable message format, which service to continue with, e.g. voice or data. The UE <NUM> prefers to continue with the voice service and agrees to terminate the ongoing data service. In other words, a request for prioritization of one of the ongoing services is sent to the UE <NUM>. The request may be in the form of a message.

Here one of the possible ways to choose the priority is exemplified. Though, there can be other ways also to choose the priority. For example, if the UE <NUM> is mobile, then a request in the form of tones/vibration may be more appropriate, and if the UE is a tablet computer, then the request may be in the form of a flash message notification for notifying the user that the threshold has been reached or fallen below. USSD or IVR may also be possible ways to get user's input of priority. In general, priority is dynamically chosen at run time by the user of the UE <NUM>.

If the user of the UE <NUM> has not chosen any prioritization among the ongoing services, then a fall back method may be performed. For more detail on the fallback method, please see <FIG> which will be described later.

This step is seen in <FIG>. This step corresponds to steps <NUM> and <NUM> in <FIG> and step <NUM> in <FIG>. The UE's <NUM> priority of service selection is communicated to the PCEF <NUM>, possibly via the telecommunication network which is represented by the access network node <NUM>.

This step is seen in <FIG>. This step corresponds to steps <NUM> and <NUM> in <FIG> and step <NUM> in <FIG>. The PCEF <NUM> conveys the user's priority to the OCS <NUM> by adding newly proposed AVP in a CCR message, where the newly proposed AVP is new with the embodiments herein:
<IMG>.

This step is seen in <FIG>. This step corresponds to step <NUM> in <FIG> and step <NUM> in <FIG>. Since the CCR received at the OCS <NUM> in step <NUM> comprises the "Service-Identifier-Priority" AVP, the OCS <NUM> does not authorize any further credit to any service except the service with "Service-Identifier = Voice_123" with Service-ldentifier-Priority=<NUM>.

This step is seen in <FIG>. The OCS <NUM> may send, to the PCEF122, a response to the request in step <NUM> with the confirmation of reserved units. <Credit-Control-Answer> ::=
{ CC-Request-Type } = UPDATE_REQUEST
*[ Multiple-Services-Credit-Control ]
*[ Service-Identifier ] = Voice_123
[ Granted-Service-Unit ]
[ Rating-Group ]
[ Result-Code ] = <NUM>
*[ Service-Identifier ] = Data_123
[Validity-Time] = <NUM>
[ Granted-Service-Unit ] = <NUM>
[ Final-Unit-Indication ] = <NUM>
[ Final-Unit-Action ] = TERMINATION_REQUEST
Rating-Group ]
[ Result-Code ] = <NUM>.

Step 518b is a response to step <NUM>. The PCEF <NUM> sends a response to the telecommunication network with information about which service will be continued and which will be stopped. The telecommunication network may be represented by the access network node <NUM>.

This step is seen in <FIG>. This step corresponds to step <NUM> in <FIG>. This step may be divided into the following two sub steps:.

With this, the OCS <NUM> will commit for used data services and will be able to release unused money that was reserved previously for data service to be used for prioritized service.

This step is seen in <FIG>. The UE <NUM> takes the necessary actions for notifying the user.

This step is seen in <FIG>. The UE <NUM> may acknowledge step <NUM> to the telecommunication network represented by the access network node <NUM>.

This step is seen in <FIG>. The telecommunication network represented by the access network node <NUM> ensures that user of the UE <NUM> should be notified informing him, "Your chosen service will resume, and others will be discontinued as low balance condition is reached. To start using all services please recharge". The OCS <NUM> may add a new logic ensuring this notification to be sent.

This step is seen in <FIG>. After the reserved quota of credit is consumed for voice, a further credit authorization and commit request for used voice service is sent from the PCEF <NUM> to the OCS <NUM>. The CCR sent from the PCEF <NUM> to the OCS <NUM> is as follows:
<Credit-Control-Request> ::=
{ CC-Request-Type } = UPDATE_REQUEST
*[ Multiple-Services-Credit-Control ]
*[ Service-Identifier ] = Voice_123
[ Requested-Service-Unit ]
[ Used-Service-Unit ]
[ Rating-Group ].

This step is seen in <FIG>. The OCS <NUM> performs commit logic for granted service unit and further credit authorization for the requested service unit, and reserves credits for voice service from the respective resource pools. The commit logic is logic at the OCS which ensures to update the account balance for the service usage till this point of time.

This step is seen in <FIG>. The OCS <NUM> may send, to the PCEF <NUM>, the following response to the request in step <NUM>, with the confirmation of reserved units:
<Credit-Control-Answer> ::=
{ CC-Request-Type } = UPDATE_REQUEST
*[ Multiple-Services-Credit-Control ]
*[ Service-Identifier ] = Voice_123
[ Granted-Service-Unit ]
[ Rating-Group ]
[ Result-Code ] = <NUM>.

This step is seen in <FIG>. The user of the UE <NUM> wants to send a SMS/MMS for which the UE <NUM> sends a SMS/MMS service request to the telecommunication network represented by the access network node <NUM>.

This step is seen in <FIG>. The telecommunication network propagates a credit control request for un-prioritized service to the PCEF <NUM>. The telecommunication network may be represented by the access network node <NUM>.

This step is seen in <FIG>. Step <NUM> above leads to a credit authorization request to be sent from the PCEF <NUM> to the OCS <NUM> to send a SMS/MMS. Please note that the voice service is already ongoing for the UE <NUM>. The request sent from the PCEF <NUM> to the OCS <NUM> may be as follows:
<Credit-Control-Request> ::=
{ CC-Request-Type } = UPDATE_REQUEST
*[ Multiple-Services-Credit-Control ]
*[ Service-Identifier ] = Voice_123
[ Requested-Service-Unit ]
[ Used-Service-Unit ]
[ Rating-Group ]
*[ Service-Identifier ] = SMS_123 / MMS_123
[ Requested-Service-Unit ]
[ Used-Service-Unit ]
[ Rating-Group ].

This step is seen in <FIG>. The CCR received at the OCS <NUM> in step <NUM> comprises a credit reservation request for SMS/MMS along with the ongoing voice. The OCS <NUM> checks if a priority pre-exists for any service. If yes, then the OCS <NUM> does not reserve any credit for SMS/MMS and rejects the credit authorization for requested service. If no, then the OCS <NUM> reserves credit for the requested service. In this example, the OCS <NUM> finds that priority is already set for the voice service, so credit will not be reserved for the SMS/MMS.

This step is seen in <FIG>. The OCS <NUM> may send, to the PCEF <NUM>, a response of step <NUM> with the confirmation of reserved units. The response may be as follows:
<Credit-Control-Answer> ::=
{ CC-Request-Type } = UPDATE_REQUEST
*[ Multiple-Services-Credit-Control ]
*[ Service-Identifier ] = Voice_123
[ Granted-Service-Unit ]
[ Rating-Group ]
[ Result-Code ] = <NUM>
*[ Service-Identifier ] = SMS_123 / MMS_123
[ Granted-Service-Unit ] = <NUM>.

This step is seen in <FIG>. Step 528b is a response to step 525b. The PCEF <NUM> sends a response to the telecommunication network represented by the access network node <NUM>. The response may comprise rejected service information with the rejection reason.

This step is seen in <FIG>. In response to step <NUM>, the user may not be allowed to use SMS/MMS service that was requested. The telecommunication network represented by the access network node <NUM> may in such case send a service request for SMS/MMS rejected to the UE <NUM>.

The OCS <NUM> will start granting additional service requests once the balance in the credit account is above the threshold, since the user has made a payment or recharge.

The prioritization of one of the multiple ongoing communication services may be transmitted from the UE <NUM> to the charging function <NUM> in any suitable message or parameter. The prioritization provides priority information for the current service id. For example, the prioritization may be transmitted in an Information Element (IE), an Attribute Value Pair (AVP), a TAG etc. The IE, the AVP or the TAG may be a new IE or AVP or TAG, or it may be a modification of an existing IE or AVP or TAG.

In an example with a new IE or AVP or TAG, the IE or AVP or TAG may be named "Service-Identifier-Priority". The new IE or AVP or TAG may be of type Unsigned32.

In an example with modification of an existing AVP, the AVP may be for example as follows in the CCR message:
<Credit-Control-Request> ::= < Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Auth-Application-Id }
{ Service-Context-Id }
{ CC-Request-Type }
{ CC-Request-Number }
[ Destination-Host ]
[ User-Name ]
[ CC-Sub-Session-Id ]
[ Acct-Multi-Session-Id ]
[ Origin-State-Id ]
[ Event-Timestamp ]
*[ Subscription-Id ]
{ Subscription-ld-Type }
{ Subscription-Id-Data }
[ Service-Identifier ]
[Service-Identifier-Priority] //subscriber chosen highest priority, New AVP
[ Termination-Cause ]
[ Requested-Service-Unit ]
[ CC-Time ]
[ CC-Money ]
{ Unit-Value }
[ Currency-Code ]
[ CC-Total-Octets ]
[ CC-Input-Octets ]
[ CC-Output-Octets ]
[ CC-Service-Specific-Units ]
*[ AVP ]
[ Requested-Action ]
*[ Used-Service-Unit ]
[ Tariff-Change-Usage ]
[ CC-Time ]
[ CC-Money ]
{ Unit-Value }
[ Currency-Code ]
[ CC-Total-Octets ]
[ CC-Input-Octets ]
[ CC-Output-Octets ]
[ CC-Service-Specific-Units ]
*[ AVP ]
[ Multiple-Services-Indicator ]
*[ Multiple-Services-Credit-Control ]
[ Requested-Service-Unit ]
[ CC-Time ]
[ CC-Money ]
{ Unit-Value }
[ Currency-Code ]
[ CC-Total-Octets ]
[ CC-Input-Octets ]
[ CC-Output-Octets ]
[ CC-Service-Specific-Units ]
*[ AVP ]
*[ Used-Service-Unit ]
[ Tariff-Change-Usage ]
[ CC-Time ]
[ CC-Money ]
{ Unit-Value }
[ Currency-Code ]
[ CC-Total-Octets ]
[ CC-Input-Octets ]
[ CC-Output-Octets ]
[ CC-Service-Specific-Units ]
*[ AVP ]
*[ Service-Identifier ]
[ Rating-Group ]
*[ AVP ]
*[ Service-Parameter-Info ]
{ Service-Parameter-Type }
{ Service-Parameter-Value }
[ CC-Correlation-Id ]
[ User-Equipment-Info ]
{ User-Equipment-Info-Type }
{ User-Equipment-Info-Value }
*[ Proxy-Info ]
*[ Route-Record ]
*[ AVP ].

As mentioned earlier, if the charging function does not receive a chosen priority among the ongoing services from the UE after the low balance condition has occurred, then a fallback method may be performed. The fallback method may involve use of a predefined priority or use of a legacy method. The following are some possible scenarios where a fallback method may be used:.

The fallback method may comprise predefining a subscriber's personalized priorities of subscribed communication services for example at a user portal, e.g. self-care. These predefined personalized priorities may be used as fallback priority for ongoing subscribed communication services of the user when the low balance condition of the subscriber's credit account balance is reached.

<FIG> is a signaling diagram illustrating an example of a fallback method. In <FIG>, the charging function <NUM> is exemplified with a CHF <NUM> and the policy node <NUM> is exemplified with a PCF <NUM>. The method shown in <FIG> comprises at least one of the following steps, which steps may be performed in any suitable order than described below:
Steps <NUM> to step <NUM> shown in <FIG> and described below are for the predefining of the personalized priorities of subscribed communication services of the subscriber:.

The subscriber may use a user portal (self-care) on the UE <NUM> to setup the priorities of its subscribed communication services, i.e. the subscriber predefines its priorities using the UE <NUM>. The user portal may be a webpage or a it may be a portal provided by the telecommunication operator where the user can login and configure his priorities.

The user portal sends the personalized priorities services and rating groups from the subscriber to a memory. In the example illustrated in <FIG>, the memory is exemplified with a Unified Data Repository (UDR). In the UDR, services and rating groups are connected to a priority. Services and rating groups are related in that a rating group may exist for a priority.

The memory may send an acknowledgement of the stored priorities.

The user portal sends the personalized priorities of the subscribed communication services to the charging function <NUM> for storing.

The charging function <NUM> may send an acknowledgement of the stored priorities.

Step <NUM> to step <NUM> shown in <FIG> and described below show how the predefined personalized priorities of the subscribed communication services of the subscriber may be used when the low balance condition is reached, and when no priority input has been dynamically received from the UE <NUM> after the low balance condition has been reached:.

The subscriber requests the network for services usage. In other words, the UE <NUM> sends, triggered by the subscriber, a request for service usage to the SMF. The services usage mentioned in step <NUM> is the amount of $ calculated by the charging function <NUM>. Step <NUM> represents the credit authorization request for the requested service.

The SMF requests the PCF <NUM> to retrieve requested service policies.

The PCF <NUM> requests the UDR to provide the predefined personalized priorities of requested communication services and rating groups of that subscriber. In other words, the PCF <NUM> sends a request for predefined user information to the UDR.

In response of step <NUM> above, the UDR may respond with the predefined priorities for requested communication services and rating groups.

In response of step <NUM> above, the PCF <NUM> may provide the SMF with the requested predefined priorities to the SMF. In other words, the PCF <NUM> may send the predefined setup priorities to the SMF.

The predefined priorities received in step <NUM> may be used by the SMF in the request to the CHF <NUM> for the reservation of credits in the credit balance to consume services requested by the subscriber.

The SMF sends a charging request of requested communication services with rating group and predefined priorities to the CHF <NUM>.

The difference between the priorities in step <NUM> and step <NUM> is that step <NUM> sends static prioritization information of offers at the charging function <NUM>, while step <NUM> represents credit authorization request with priority information of offers.

During the charging request processing at the CHF <NUM>, a low balance condition is reached. This step may be performed when the CHF <NUM> has not dynamically received any priority information from the UE <NUM> after the low balance condition has been reached. The CHF <NUM> may use the predefined priorities to decide which of the requested service should be allocated resource from the credit account. In other words, the CHF <NUM> checks if any ongoing communication services should be prioritized according to the received predefined priority information from step <NUM>, other than the one associated with the request in step <NUM>.

In response of step <NUM> above, the CHF <NUM> responds to the SMF with at least one of the following information:.

The above fallback method is exemplified above considering a <NUM> network. The same fallback method is equally applicable to <NUM>, e.g. LTE, and other networks, where one difference is that other network nodes are involved.

Below shows some examples of protocols, messages and entities which may be involved in the embodiments herein when used in a <NUM>, <NUM>, <NUM> and <NUM> communication system:.

The method described above will now be described seen from the perspective of the charging function <NUM>. <FIG> is a flowchart describing the present method performed by the charging function <NUM> for handling a subscriber's communication services. The charging function <NUM> may be for example an OCS <NUM> or a CHF. The method comprises at least one of the following steps to be performed by the charging function <NUM>, which steps may be performed in any suitable order than described below:.

This step corresponds to step <NUM> in <FIG>, step <NUM> in <FIG>, step <NUM> in <FIG> and step <NUM> in <FIG>. The charging function <NUM> detects that a subscriber's credit account has reached or fallen below a credit threshold when the subscriber has multiple ongoing communication services consuming credit from the credit account.

The multiple ongoing communication service may be on one or multiple UEs <NUM>. The balance on the same credit account is being consumed for all multiple ongoing services. The credit threshold may also be referred to as a low balance threshold or a credit limit threshold.

This step corresponds to step <NUM> in <FIG>, step <NUM> in <FIG> and step <NUM> in <FIG>. The charging function <NUM> sends a threshold notification of the reached or fallen below credit threshold to a UE <NUM> on which the subscriber has at least one of the multiple ongoing communication services.

The threshold notification may comprise a request for prioritization of one of the multiple ongoing communication services.

This step corresponds to step <NUM> in <FIG> and steps <NUM> and <NUM> in <FIG>. The charging function <NUM> may receive, from the UE <NUM>, a response to the threshold notification with prioritization of one of the multiple ongoing communication services.

This step corresponds to step <NUM> in <FIG>. The charging function <NUM> determines if a response to the threshold notification has been received from the UE <NUM> with prioritization of one of the multiple ongoing communication services.

This step corresponds to steps <NUM> and <NUM> in <FIG>. The charging function <NUM> may receive information indicating a predefined prioritized communication service from the UE <NUM> via at least one other node. The at least one other node may be for example a UDR, a PCF, a SMF etc..

This step corresponds to step <NUM> in <FIG>. The charging function <NUM> may, if a response with prioritization of one communication service has not been received, determine if information indicating a predefined prioritized communication service is available.

The reason for not receiving any response with prioritization may be that the user of the UE <NUM> has not provided any response, a timeout, that there is no mechanism implemented in the network for the user to send and select prioritization.

This step corresponds to step <NUM> in <FIG>. If information indicating a predefined prioritized communication service is not available, the charging function <NUM> may provide credit to all multiple ongoing communication services until at least substantially all available credit has been used.

This step corresponds to step <NUM> in <FIG>. The charging function <NUM> may, if information indicating the predefined prioritized communication service is available, initiate termination of all ongoing communication services except the predefined prioritized communication service.

This step corresponds to step <NUM> in <FIG>, steps <NUM> and <NUM> in <FIG>, and steps <NUM>, <NUM> and <NUM> in <FIG>. If a response with prioritization of one communication service has been received, the charging function <NUM> initiates terminations of all ongoing communication services except the prioritized communication service.

This step corresponds to step <NUM> in <FIG>, step <NUM> in <FIG> and steps <NUM> and <NUM> in <FIG>. The charging function <NUM> may send, to the UE <NUM>, a status notification of that the prioritized communication service will continue and that the other communication services will be terminated.

This step corresponds to step <NUM> in <FIG> and step <NUM> in <FIG>. The charging function <NUM> may send, to the UE <NUM>, a resume notification of that the terminated communication services can be resumed after credit recharge.

This step corresponds to step <NUM> in <FIG> and step <NUM> in <FIG>. The charging function <NUM> provides at least substantially all available credit to be available for the prioritized communication service. This may also be described as reserving or allocating at least substantially all available credit to be available for the prioritized communication service. In other words, the charging function <NUM> makes the remaining credit available for the prioritized communication service.

The method described above will now be described seen from the perspective of the UE <NUM>. <FIG> is a flowchart describing the present method performed by the UE <NUM> for handling a subscriber's communication services. The subscriber has at least one of multiple ongoing communications services ongoing on the UE <NUM>. The method comprises at least one of the following steps to be performed by the UE <NUM>, which steps may be performed in any suitable order than described below:.

This step corresponds to step <NUM> in <FIG>, step <NUM> in <FIG>, step <NUM> in <FIG> and steps <NUM> and <NUM> in <FIG>. The UE <NUM> may receive, from the charging function <NUM>, a status notification of that a prioritized communication service will continue and that other communication services will be terminated.

This step corresponds to step <NUM> in <FIG>, step <NUM> in <FIG> and step <NUM> in <FIG>. The UE <NUM> receives, from a charging function <NUM>, a threshold notification of that the subscriber's credit account has reached or fallen below a credit threshold for multiple ongoing communication services consuming credit from the same credit account.

The multiple ongoing communication service may be on one or multiple UEs <NUM>. The balance on the same credit account is being consumed for all multiple ongoing services.

The credit threshold may also be referred to as a low balance threshold or a credit limit threshold.

This step corresponds to step <NUM> in <FIG> and steps <NUM> and <NUM> in <FIG>. The UE <NUM> may send, to the charging function <NUM>, a response to the threshold notification with prioritization of one of the multiple ongoing communication services.

This step corresponds to steps <NUM>, <NUM>, <NUM>, <NUM> and <NUM> in <FIG>. The UE <NUM> may send information indicating a predefined prioritized communication service to the charging function <NUM> via at least one other node.

This step corresponds to step <NUM> in <FIG> and step <NUM> in <FIG>. The UE <NUM> may receive, from the charging function <NUM>, a resume notification of that the terminated communication services can be resumed after credit recharge.

To perform the method steps shown in <FIG> for handling a subscriber's communication services, the charging function <NUM> may comprise an arrangement as shown in <FIG>. The charging function <NUM> comprises an interface (IF_A) <NUM>, a processor_A <NUM> and a memory (MEM_A) <NUM>, in which memory instructions are stored for carrying out the method steps explained above. The charging function <NUM> communicates via the interface IF_A <NUM>. The IF_A <NUM> comprises both an external interface, communicating with a transmitter and receiver, and internal interfaces (not shown).

The charging function <NUM> is configured to, e.g. by means of the processor_A <NUM>, detect that a subscriber's credit account has reached or fallen below a credit threshold when the subscriber has multiple ongoing communication services consuming credit from the credit account.

The charging function <NUM> is configured to, e.g. by means of the IF_A <NUM>, send a threshold notification of the reached or fallen below credit threshold to a UE <NUM> on which the subscriber has at least one of the multiple ongoing communication services. The threshold notification may comprise a request for prioritization of one of the multiple ongoing communication services.

The charging function <NUM> is configured to, e.g. by means of the processor_A <NUM>, determine if a response to the threshold notification has been received from the UE <NUM> with prioritization of one of the multiple ongoing communication services.

The charging function <NUM> is configured to, e.g. by means of the processor_A <NUM>, if a response with prioritization of one communication service has been received, initiate termination of all ongoing communication services except the prioritized communication service.

The charging function <NUM> is configured to, e.g. by means of the processor_A <NUM>, provide at least substantially all available credit to be available for the prioritized communication service.

The charging function <NUM> may be configured to, e.g. by means of the IF_A <NUM>, receive, from the UE <NUM>, a response to the threshold notification with prioritization of one of the multiple ongoing communication services.

The charging function <NUM> may be configured to, e.g. by means of the processor_A <NUM>, if a response with prioritization of one communication service has not been received, determine if information indicating a predefined prioritized communication service is available.

The charging function <NUM> may be configured to, e.g. by means of the processor_A <NUM>, if information indicating the predefined prioritized communication service is available, initiate termination of all ongoing communication services except the predefined prioritized communication service.

The charging function <NUM> may be configured to, e.g. by means of the IF_A <NUM>, receive information indicating a predefined prioritized communication service from the UE <NUM> via at least one other node.

The charging function <NUM> may be configured to, e.g. by means of the processor_A <NUM>, if information indicating a predefined prioritized communication service is not available, provide credit to all multiple ongoing communication services until at least substantially all available credit has been used.

The charging function <NUM> may be configured to, e.g. by means of the IF_A <NUM>, send, to the UE <NUM>, a status notification of that the prioritized communication service will continue and that the other communication services will be terminated.

The charging function <NUM> may be configured to, e.g. by means of the IF_A <NUM>, send, to the UE <NUM>, a resume notification of that the terminated communication services can be resumed after credit recharge.

To perform the method steps shown in <FIG> and <FIG> for handling a subscriber's communication services, the UE <NUM> may comprise an arrangement as shown in <FIG>. The UE <NUM> comprises an interface (IF_B) <NUM>, a processor_B <NUM> and a memory (MEM_B) <NUM>, in which memory instructions are stored for carrying out the method steps explained above. The UE <NUM> communicates via the interface IF_B <NUM>. The IF_B <NUM> comprises both an external interface, communicating with a transmitter and receiver, and internal interfaces (not shown).

The UE <NUM> may be configured to, e.g. by means of the IF_B <NUM>, receive, from a charging function <NUM>, a threshold notification of that the subscriber's credit account has reached or fallen below a credit threshold for multiple ongoing communication services on the UE <NUM> consuming credit from the same credit account. The threshold notification may comprise a request for prioritization of one of the multiple ongoing communication services.

The UE <NUM> may be configured to, e.g. by means of the IF_B <NUM>, send, to the charging function <NUM>, a response to the threshold notification with prioritization of one of the multiple ongoing communication services.

The UE <NUM> may be configured to, e.g. by means of the IF_B <NUM>, receive, from charging function <NUM>, a status notification of that a prioritized communication service will continue and that other communication services will be terminated.

The UE <NUM> may be configured to, e.g. by means of the IF_B <NUM>, receive, from the charging function <NUM>, a resume notification of that the terminated communication services can be resumed after credit recharge.

The UE <NUM> may be configured to, e.g. by means of the IF_B <NUM>, send information indicating a predefined prioritized communication service to the charging function <NUM> via at least one other node.

The above apparatuses/entities are adapted to communicate over known external telecommunication interfaces or via application programming interfaces (API), as appropriate.

The present mechanism for handling a subscriber's communication services may be implemented through one or more processors, such as the processor_A <NUM> in the charging function arrangement depicted in <FIG> and the processor_B <NUM> in the UE arrangement depicted in <FIG> together with computer program code for performing the functions of the embodiments herein. The processor may be for example a Digital Signal Processor (DSP), Application Specific Integrated Circuit (ASIC) processor, Field-programmable gate array (FPGA) processor or microprocessor. The program code mentioned above may also be provided as a computer program product, for instance in the form of a data carrier carrying computer program code for performing the embodiments herein when being loaded into the charging function <NUM> and/or UE <NUM>. One such carrier may be in the form of a CD ROM disc. It is however feasible with other data carriers such as a memory stick. The computer program code can furthermore be provided as pure program code on a server and downloaded to the charging function <NUM> and/or UE <NUM>.

A first computer program may comprise instructions which, when executed on at least one processor, cause the at least one processor, e.g. the processor_A <NUM>, to carry out at least one of the method steps in at least one of <FIG>. A first carrier may comprise the computer program, and the first carrier is one of an electronic signal, optical signal, radio signal or computer readable storage medium.

A second computer program may comprise instructions which, when executed on at least one processor, cause the at least one processor, e.g. the processor_B <NUM>, to carry out at least one of the method steps in at least one of <FIG> and <FIG>. A second carrier may comprise the computer program, and the second carrier is one of an electronic signal, optical signal, radio signal or computer readable storage medium.

There is no way in current credit control application where a prepaid subscriber can prioritize one ongoing service over all other ongoing services when there is a shortage of credit units, i.e. when a low balance condition occurs.

The embodiments herein relate to providing the policy function with dynamically chosen priority information in case of a low balance, and then the policy function may select a priority communication service and drop the other ongoing communication services.

For credit authorization in an LTE network, e.g. <NUM>, a new AVP may be introduced in the CCR message of the diameter protocol to carry priority information of the communication service being used to the charging function <NUM>.

For credit authorization in a <NUM> network, a new TAG may be introduced in a REST message towards charging function <NUM>, e.g. the Nchf, to carry priority information of the communication service being used to the charging function <NUM>, e.g. Nchf.

The embodiments herein are not limited to the above described embodiments. Various alternatives, modifications and equivalents may be used. Therefore, the above embodiments should not be taken as limiting the scope of the embodiments, which is defined by the appended claims. A feature from one embodiment may be combined with one or more features of any other embodiment.

The term "at least one of A and B" should be understood to mean "only A, only B, or both A and B. ", where A and B are any parameter, number, indication used herein etc..

It should be emphasized that the term "comprises/comprising" when used in this specification is taken to specify the presence of stated features, integers, steps or components, but does not preclude the presence or addition of one or more other features, integers, steps, components or groups thereof. It should also be noted that the words "a" or "an" preceding an element do not exclude the presence of a plurality of such elements.

The term "configured to" used herein may also be referred to as "arranged to", "adapted to", "capable of" or "operative to".

Claim 1:
A method performed by a charging function (<NUM>) for handling a subscriber's communication services, the method comprising:
detecting (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>) that a subscriber's credit account has reached or fallen below a credit threshold when the subscriber has multiple ongoing communication services consuming credit from the credit account;
sending (<NUM>, <NUM>, <NUM>, <NUM>) a threshold notification of the reached or fallen below credit threshold to a user equipment, UE, (<NUM>) on which the subscriber has at least one of the multiple ongoing communication services;
receiving (<NUM>, <NUM>, <NUM>, <NUM>), from the UE (<NUM>), a response to the threshold notification with prioritization of one of the multiple ongoing communication services;
determining (<NUM>, <NUM>) if the response to the threshold notification has been received from the UE (<NUM>) with prioritization of one of the multiple ongoing communication services:
• if a response with prioritization of one communication service has been received, initiating (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>) termination of all ongoing communication services except the prioritized communication service;
sending (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>), to the UE (<NUM>), a status notification of that the prioritized communication service will continue and that the other communication services will be terminated;
sending (<NUM>, <NUM>, <NUM>), to the UE (<NUM>), a resume notification of that the terminated communication services can be resumed after credit recharge; and
providing (<NUM>, <NUM>, <NUM>) at least substantially all available credit to be available for the prioritized communication service; and
• if a response with prioritization of one communication service has not been received, determining (<NUM>, <NUM>) if information indicating a predefined prioritized communication service is available; and
if information indicating the predefined prioritized communication service is available, initiating (<NUM>, <NUM>) termination of all ongoing communication services except the predefined prioritized communication service.