TECHNICAL FIELD

The invention relates generally to communication networks and, more specifically but not exclusively, to optimizing policy and charging control

architecture in communication networks.

BACKGROUND

3GPP PCC (Policy and Charging Control) architecture introduced the logical entity PCRF (Policy and Charging Rule Function), PCEF (Policy and Charging Enforcement Function), and OCS (Online Charging Server) to provide dynamic QoS (Quality of Service) and traffic shaping. When a device initiates an IP session, the PCRF can provide rules to the PCEF to monitor the IP traffic volume and reports the accumulated usage to the PCRF when the usage threshold is reached. Such scenario is quite common in broadband service provider's network. A broadband subscriber will be allocated with a monthly usage plan, e.g. 50GB. For example, when the user has reached the limit of the plan, the bandwidth will downgraded from megabit per second to kilobit per second.

When the subscription is applied to a group of users, e.g. family members or enterprises, the current communication structure between PCRF and PCEF (3GPP Gx interface) or OCS and PCRF (3GPP Sy interface) is inefficient. First, as the PCEF doesn't maintain the high level group concept, the quota calculation must be maintained in the PCRFor OCS. Second, when the group quota limit is reached, PCRF (or OCS via PCRF) needs to update the policy rule for each subscriber on the PCEF. This will create a sudden communication surge between PCRF and PCEF. Last, when multiple users are accessing the network via different PCEF, there is a need for the PCRF to dynamically allocate and reclaim the credit among group users and use as less communication as possible.

One conventional approach to address this problem is defined in 3GPP TS

29.212 ("Policy and Charging Control (PCC) over Gx/Sd reference point", June, 2012), but it is lack of dynamic allocation mechanism that is based on the previous consumption and lack of coordination between the policy/credit control element and the enforcement element for credit sharing group users. Another traditional approach is described in "Credit Allocation for UMTS Preparid Service", IEEE Transactions on Vehicular Technology ( Issue 1 , Volume 55 , Phone Lin, Yi-Bing Lin, Chai-Hien Gan, and Jeu-Yih Jeng, January 2006), but it only addresses the credit reclaim without further optimising the communication from the PCEF to the PCRF or OCS. The optimisation lies with not only new indicator or parameters in the Diameter messages but also the control logic. In this approach, credit allocation is targeting one customer with multiple services and it is also lack of dynamic allocation mechanism that is based on the previous consumption and lack of coordination between the policy/credit control element and the enforcement element for credit sharing group users.

When a service quota, e.g. voice, video, data, etc. is allocated to more than one entity, e.g. subscriber, network element, the policy/charging server needs to adjust the quota allocation and re-allocation in an intelligent way. Such allocation algorithm directly impacts the traffic load between the control and policy/charging implementation element. Optimization is hence required.

SUMMARY

In light of the present need for a mechanism for credit controlling, a brief summary of various exemplary embodiments is presented. Some simplifications and omissions may be made in the following summary, which is intended to highlight and introduce some aspects of the various exemplary embodiments, but not to limit the scope of the invention. Detailed descriptions of a preferred exemplary embodiment adequate to allow those of ordinary skill in the art to make and use the inventive concepts will follow in the later sections.

In one embodiment, a method for credit controlling in a communication system is provided, in the communication system a Policy and Charging Rule Function PCRF entity is connected to at least one Policy and Charging Enforcement Function PCEF entities, said method comprising: querying association information identifying an association group including quota sharing sessions; when the PCRF entity receives a message from one PCEF entity reporting the reaching of threshold of quota, retrieving remaining credit for the association group based on the acquired association information; calculating credit allocation for said one PCEF entity based on the remaining credit for the association group; and pushing the calculated credit allocation to said one PCEF. In various embodiments, the association information comprises association type and association ID.

In a preferred embodiment, the calculating step further comprises considering the following factors: total subscriptions in the association group, total number of said at least one PCEFs, total subscriptions from said one PCEF, and the accumulated session consumption speed of all sessions in the association group.

In a preferred embodiment, the calculating step further comprises checking the calculated credit allocation against the minimum unit set in the communication system.

In one embodiment, a Policy and Charging Rule Function PCRF entity for credit controlling in a communication system is provided, in the communication system the PCRF entity is connected to at least one Policy and Charging

Enforcement Function PCEF entities, said PCRF entity comprising: querying module configured to query association information identifying an association group including quota sharing sessions; retrieving module configured to, when receiving a message from one PCEF entity reporting the reaching of threshold of quota, retrieve remaining credit for the association group based on the acquired association information; calculating module configured to calculate credit allocation for said one PCEF entity based on the remaining credit for the association group; and pushing module configured to push the calculated credit allocation to said one PCEF.

In one embodiment, a Policy and Charging Enforcement Function PCEF entity in a communication system is provided, the PCEF is connected to a Policy and Charging Rule Function PCRF entity, said PCEF entity comprising: acquiring module configured to acquire association information identifying an association group including quota sharing sessions from the PCRF entity; retrieving module configured to retrieve remaining credit for the association group based on the acquired association information; calculating module configured to calculate credit allocation based on the remaining credit for the association group; and reporting back the calculated credit allocation to the PCRF entity.

In a preferred embodiment, the calculating module is further configured to calculate credit allocation by considering the following factors: total subscriptions in the association group, and total subscriptions from the PCEF entity.

BRIEF DESCRIPTION OF THE DRAWINGS The teachings herein can be readily understood by considering the following detailed description in conjunction with the accompanying drawings, in which:

FIG. 1 depicts an exemplary Policy and Charging Control architecture according an embodiment;

FIG. 2 depicts an exemplary call flow for Policy and Charging Controlling according to an embodiment; and

FIG. 3 depicts an exemplary logic flow according to an embodiment.

To facilitate understanding, identical reference numerals have been used, where possible, to designate identical elements that are common to the figures.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

A dynamic policy and charging control mechanism with feedback from bandwidth consumption is depicted and described herein.

In some embodiments, PCRF and OCS will use a predictive quota allocation algorithm when deciding quotas among group members or PCEFs (e.g. PGW or GGSN). The SCS (Session Consumption Speed) helps the situation when users on one PCEF tend to consume more sessions/credits than others. Using unified credit reclaim strategy might end up with more and more requests coming from a certain PCEF. However, by considering the total traffic consumption from a certain subscriber against the overall traffic, the PCRF can give more credits to the PCEF that serves the subscriber . This will help smooth out the reclaim-related signalling traffic between PCRF and PCEF. The SCS (Session Consumption Speed) value could be reset based on the business requirements.

In some embodiments, when the PCEF initiates the session request, PCRF needs to indicate the association of the usage monitoring. It can be an association of the subscriptions (e.g. subscription-id), access packet network (e.g.

Called-Station-ld), etc. Then PCEF needs to take the association indicator into its usage calculation. For example, when the association indicator refers to the subscription-id, the PCEF need to calculate the total usage against the quota allocated per association id. When the associated usage limit is reached, the PCEF will report with one command to the PCRF. The PCRF will initiate a new policy that is associated with the same association id.

Hierarchical group information can be either maintained in the association database, which can be located on the PCRF, Spr (Subscription Profile Repository), or the OCS. Association ID allocation will be based on the hierarchical group relationship. When PCRF allocates quota across different PCEFs for credit-sharing group users, it will use the historical usage data to predict its next quota allocation. Basically, different members in the same group will be allocated with different quota (within the summation limit). This will save extra signalling exchanges.

Figure 1 shows an exemplary high level architecture 100 according to an embodiment. In architecture 100, PCRF 101 provides dynamic management capabilities by which the service provider may manage rules related to services provided via communication network (for example, 3G, LTE and the like) and rules related to charging for services provided via the communication network. PCRF 101 is controlling at least one PCEF (s) although only one PCEF ( i. e., 103) is shown in Figure 1 .

In Figure 1 , PCRF 101 and PCEF 103 communicates with each other via 3GPP Gx interface. In an alternative way, PCEF 103 and OCS 107 communicates with each other via 3GPP Sy interface.

In Figure 1 , IP sessions are established from subscribers 109 (Clients A1 ...

An) via PCEF 103 and other network elements. Association Database 105 can be located on the PCRF 101 , Spr (Subscription Profile Repository, not shown in Figure 1 ), or OCS 107. Association ID allocation will be based on the hierarchical group relationship.

If we use the 3GPP Gx interface for example, association information like type and ID can be typically carried in the Diameter Credit Control Answer (CCA) between the PCEF 103 and PCRF 101 . In other cases, association information can be carried in the Diameter Credit Control Request (CCR) between the PCEF 103 and PCRF 101 .

In various embodiments of the present invention, "association ID" is basically a new attribute to create for each subscriber. The "type" is an attribute we group subscribers together. The types of the association ID can be as follows:

1 . Subscription ID, which is normally the IMSI for a mobile subscriber. This is the straightforward way to group subscribers together.

2. Called-station-ID, or APN (Access Point Name).

This association will come to use when the operator wants to charge differently when the application uses different APN, e.g. VoIP is using a different APN from internet browsing.

3. User-location. This association will come to use when charging or QoS policy is related with different location. If subscribers (x1 , xn) belong to group A, which is constructed by subscription-id, subscribers (y1 , ym) belong to group B, then within group A, we would have (x1 , xj) belong to subgroup A_location_1 .

4. Access Technology, or IP-CAN (IP Connectivity Access Network) type.

This association will be used when the operator wants to give a different quota when the user comes from Xdsl (wifi) or 3G/LTE.

All possible association types can be used in various embodiments of the present invention.

FIG. 2 depicts an exemplary call flow for Policy and Charging Controlling according to an embodiment.

As shown at S21 , Session Establish Request is sent from an access network by UE which is typically a mobile station.

When PCEF 103 receives this request, it generates a credit control request CCR and transmits the CCR to PCRF 101 at step S22. The CCR typically includes called-station-id and subscription-ID for identifying The PCEF and the subscriber (i.e. session initiator).

At S22, in order to associate different IP sessions, PCRF 101 needs to query a database (internal or external) or via the Sy interface from the OCS, to identify the association type, association id, and the initial SCS value.

Take the subscriber association for example, the PCRF will decide the association type as subscriber. After query with the database, the PCRF will acquire the association ID. Such information will be used to populate the Credit Control Answer (CCA) or Request (CCR).

At S23, PCRF 101 responds with a Credit Control Answer (CCA) to PCEF

103. The CCA includes usage report, granted-service-unit and association information (type, id). The association information which comprises type of the association and particular ID is for example derived from DB 105 inside or outside PCRF 101 . The association information can also be derived from SPR (not shown in Figure 1 or 2), or the OCS 107 as mentioned above.

At S24, the IP session is established and Session Establish Response is sent from PCEF 103 to the UE.

As shown in S25, when plurality subscribers initiate IP sessions via a certain PCEF for example PCEF 103 in Figure 2, usage is calculated based on the association type and id. When PCRF is controlling multiple PCEFs, credit allocation must be based on the following factors:

total remaining credit (C) for the association group;

total subscriptions (N) in the association group;

total number of PCEFs (M);

total subscriptions from one PCEF (Ni, i=1 , ...M);

Session Consumption Speed (SCS) per subscription (Sj, j=1 , N). SCS is measured as bits per second;

the minimum allocation unit (m), e.g. 10 KB.

ertain PCEF (i), the overall session consumption speed (OSCS) will

That is, the OSCS is equal to the sum of every SCS of the subscribers in the association group.

When each subscription (e.g. subscriber) has the same speed of consumption, SPi is simply Ni.

dit allocation to an associated subscription on one of the PCEF (i) will be:

When there is only one PCEF (M=1 ), allocation is simply C.

Please note that the session consumption speed can be initialized to 1 as a monthly reset or be stored in the subscription database, e.g. Spr, to facilitate future initialization.

At S26, when PCEF sends a new CCR which comprises an

UPDATE_REQUEST, Association (type, id) and etc. to PCRF 101 , PCRF 101 will carry out calculation again and responds with CCA which comprises new policy and Association (type, id) at S27. After that, sessions with updated bandwidth are carried out.

During the calculation described herein, it is to be noted that, it is possible when there is only one connection from PCRF 101 to PCEF 103, that is to say, PCEF 103 covers all grouped sessions. In this case, PCEF 013 can do the calculation and reports back. When there are multiple connections from PCRF 101 to PCEF 103, due to the fact that each PCEF has only a partial view of the group user, PCRF 101 will calculate the usage for a certain PCEF. Figure 3 depicts an exemplary logic flow according to an embodiment. Please note that when PCEF doesn't support the association group concept, the logic flow still follows while all the calculation will be based on the individual subscription in stead of subscriptions per PCEF.

On the PCRF side:

When PCRF receives the CCR from PCEF reporting the reaching of the threshold, it needs to retrieve the policy according to the association and calculate the credit allocation based on the number of PCEFs and the accumulated SCS for each for them. The remaining credit can obtained from the policy. A weighted credit allocation will then be pushed to all the PCEFs.

The PCRF needs to check the remaining credit against the minimum unit setting in the system. Once the overall credit allocation is equal or below the minimum unit, it needs to reclaim the credit from the existing sessions and then redistribute the credit to all the live sessions. SCS per PCEF is introduced to minimize the needs of reclaiming because reclaiming will generate a lot of signaling traffic.

After reclaiming, if the reclaimed credit is still less than or equal to the minimum unit, the reclaimed credit should be allocate the requesting PCEF. If the weighted distribution to certain PCEF is less than or equal to the minimum unit, the minimum unit should be allocated to the PCEF.

On the PCEF side:

When association type and ID are carried in the Diameter Credit Control Answer (CCA) or Request (CCR) from the PCRF, together with the need to report usage, the PCEF need to take the Granted-Service-Unit as a grouped unit, which means the calculation of it needs to be based on multiple sessions that share the same association type and id. After the accumulated usage reaches the threshold, the PCEF should pick up one of the associated session together with the association type and id to report to the PCRF.

When the PCRF updates the policy for certain association, the PCEF needs to apply the policy for all sessions with the association.

At step 302, when PCRF 101 receives a new session request from a PCEF, for example PCEF 103, it needs to check the remaining credit against the minimum unit setting in the system.

At step 304, PCRF 101 determines whether the remaining credit is equal or below the minimum unit. Once the remaining credit is equal or below the minimum unit (Y branch), it needs to reclaim the credit from the existing sessions, as shown in step 308.

After reclaiming, PCRF 101 determines whether the total credit after

reclaiming is still less than or equal to the minimum unit at step 312.

If the reclaimed total credit is still less than or equal to the minimum unit (Y branch), the remaining credit (after reclaiming) should be allocate the requesting PCEF 103 at step 318.

Now we will consider the N branch in step 304.

Once the remaining credit is above the minimum unit (N branch), PCRF 101 determines whether this is initial allocation at step 306. If yes, SCS is set to 1 or SCS is retrieved for example from Spr, and then SPi is calculated for the PCEF 103 at step 310. And if no, SPi is calculated for the PCEF directly as shown at step 310. As described above, for a certain PCEF (i), the overall session consumption speed (OSC

Wherein, Sj is Session Consumption Speed (SCS) per subscription (j=1 , N). SCS is measured as bits per second.

At step 314, the weighted remaining credit allocation is calculated. The credit allocati associated subscription on one of the PCEF (i) will be:

Wherein,

C is total remaining credit for the association group,

N is total subscriptions in the association group,

M is total number of PCEFs,

Ni is total subscriptions from one PCEF, i=1 , .... M,

m is the minimum allocation unit , e.g. 10 KB,

Now we will consider the N branch in step 312.

As shown in Figure 3, if the reclaimed total credit is above the minimum unit (N branch), then, at step 314, the weighted remaining credit allocation is calculated.

At step 316, PCRF 101 determines whether the weighted remaining credit allocation is less than or equal to the minimum unit, If the weighted distribution to certain PCEF is less than or equal to the minimum unit (Y branch), the minimum unit should be allocated to the requesting PCEF, as shown in step 320.

If the weighted distribution to certain PCEF is above the minimum unit (N branch), the remaining credit should be allocated to the requesting PCEF, as shown in step 318.

It will be appreciated that the functions depicted and described herein may be implemented in software for executing on a general purpose computer (e.g., via execution by one or more processors) so as to implement a special purpose computer, and/or may be implemented in hardware (e.g., using one or more application specific integrated circuits (ASIC) and/or one or more other hardware equivalents).

It is contemplated that some of the steps discussed herein as software methods may be implemented within hardware, for example, as circuitry that cooperates with the processor to perform various method steps. Portions of the functions/elements described herein may be implemented as a computer program product wherein computer instructions, when processed by a computer, adapt the operation of the computer such that the methods and/or techniques described herein are invoked or otherwise provided. Instructions for invoking the inventive methods may be stored in fixed or removable media, transmitted via a data stream in a broadcast or other signal bearing medium, and/or stored within a memory within a computing device operating according to the instructions.