Contents

1   Fair Usage Function

Fair Usage function enables users to perform policy control per subscriber based on actual usage in terms of volume, time or both for prepaid and postpaid subscriptions.

There are several use cases where the Fair Usage Control functionality is used, for example:

• To give a volume limit for a certain period at a specific bandwidth
• To limit the amount of data per IP session
• To limit the time usage for a certain service

1.1   Fair Usage Overview

Fair Usage Control provides the capability to control the accumulated volume or time consumed by a subscriber for a service or for a group of services during a period. For example, a period can be monthly or during an IP session. The SAPC can take certain actions, such as QoS change, rating group change, or deny access to a service whenever any of the usage limits configured for a subscriber are surpassed, according to a policy decision.

The next figure shows an example of the Fair Usage Control function. When a subscriber reaches the usage limit, bandwidth is downgraded.

At IP session activation, the Enforcement Function (EF) requests the SAPC for authorized data for the subscriber. The SAPC evaluates Fair Usage Control policies and directs the EF to report usage downloading a quota. If a quota is received, the EF performs usage detection.

After the quota is consumed or an event is reported, the SAPC receives the usage reporting from the EF. The usage reporting consists of volume information consumed by the subscriber. Time quotas are controlled internally by the SAPC. The SAPC updates the usage accumulators for the subscriber with the information from the EF about the usage. The SAPC also indicates the newly available volume quota to the EF or stores internally the time quota. When a limit is exceeded, the SAPC uses its configured policies to determine the appropriate control action to take, and informs the EF.

The following figure shows the main modules involved in this function:

• Usage detection detects and measures the volume or time consumption, and reports the usage to the usage accumulator.
• Usage accumulator accumulates and stores the usage reports received from the EF in case of volume, or calculated internally in case of time, for the different services. The usage accumulator also computes the quota left for the subscriber.
• Decision engine takes decisions based on the accumulated usage, such as change of QoS and change in authorized services.
• Policy enforcement enforces the decisions taken by the decision engine.

Usage detection for volume quotas and policy enforcement modules are located in the EF. Each module can be located in different EFs. The usage accumulator can be located in the SAPC or in an external database, usage detection for time quotas and Decision engine is located in the SAPC.

1.2   Fair Usage Control Options

The following figure illustrates examples of Fair Usage Control offers:

Also, some offerings can be provided only during a certain period. This functionality enables an operator to provide turbo button offerings, where a subscriber buys a voucher valid during a certain period, and with a higher priority compared to a regular subscription.

There are two important data for Fair Usage Control function:

• Fair Usage Profile includes the set of Reporting Groups to monitor, the associated volume or time limits, and the set of data that specifies their usage accumulator characteristics, such as subscription date, reset period, reporting interval time.

  Whenever a subscriber surpasses the usage limit of a Reporting Group associated with the subscriber profile, subscriber-related policy evaluation is triggered to determine the appropriate control actions to take.

• Usage accumulator is a counter that stores the accumulated volume or time of each Reporting Group consumed by a subscriber. Each usage accumulator has an expiration date, after which the usage accumulators can be reset or can be prevented from updating.

The following subsections explain all the options provided by Fair Usage Control function:

• What is accumulated in the usage accumulators?

  Volume or time, during the IP session lifetime or for the different IP sessions established during a time period, always or only when specific conditions are fulfilled. See Section 1.2.1 for more information.

• What type of user traffic is accumulated?

  Total traffic, a set of services, or a service. See Section 1.2.2 for more information.

• How long does the SAPC accumulate volume or time information?

  For a configured period or time, only once or repeatedly. See Section 1.2.3 for more information.

• Who is entitled to accumulate is described in Section 1.2.4
• When does the SAPC receive new usage reporting?

  The SAPC receives new usage reporting, depending upon the time interval configured. See Section 1.2.5 for more information.

These options can be used together simultaneously.

1.2.1   Usage Limits Types

Usage limits can be applied to:

• Volume

  It is possible to limit the accumulated volume usage (for example, 2 GB). It is also possible to define different volume limits for downlink, uplink, and for bidirectional traffic.

• Time

  It is possible to limit the accumulated time usage (for example, 50 hours).

According to the period of usage accumulation, the following usage limits can be defined:

• Absolute limits apply for a period, for example, monthly, daily, 5 days, 10 hours, or a fixed date. When a limit is defined for a period, the usage is accumulated and maintained across the different IP sessions established during that period.
• Complementary limits control the accumulated usage for a shorter period than the reset period of the absolute limit. This allows for instance to have a monthly limit and also a daily limit for a specific service or set of services.
• IP session limits apply during the IP session lifetime. The SAPC controls the usage during the IP session lifetime, and resets the usage accumulators when the subscriber terminates the IP session. This is done to protect the operator network.

According to the accumulation conditions, the following usage limits can be defined:

• Conditional limits apply only when certain conditions are fulfilled, as defined by the accumulation policies and conditions. See Section 1.3 for more information.

  Conditional limits may control accumulated usage during a period (absolute limits and complementary limits) or during the IP session (IP session limits).

Each usage limit defined in the SAPC has associated an usage accumulator.

Figure 5 shows a Data Plan example where subscriber usage is accumulated on a monthly basis with an absolute volume limit of 4 GB, and on a weekly basis with a complementary limit of 1 GB and a conditional limit of 500 MB that applies in case of roaming.

Intermediate limits

It is also possible to define intermediate limits (that is, multiple thresholds) per usage accumulator. Defining multiple thresholds enables an operator to take different actions associated with each of the configured limits. For example, an action when the 50% of the defined volume limit is reached, and a different action when the 100% of the defined volume limit is reached.

Intermediate limits can be defined as percentage values of the whole limit. Percentage values can be provisioned to:

• Absolute volume limits
• Complementary volume limits
• IP session volume limits
• Conditional volume limits

1.2.2   Fair Usage Control Granularity

It is possible to control volume, time usage or both at the level of:

• Service level

  It is possible to control usage per service or set of services IP flows that are treated as group from the perspective of Fair Usage Control. A Reporting Group can be mapped to a single service or to a set of services that share a common Fair Usage Profile. For example, p2p.

  The SAPC can track the usage information reported by the EF for each defined Reporting Group.

• Total traffic

  The SAPC can control time or volume usage for the total amount of traffic consumed by the IP session.

  A Reporting Group can be mapped to total traffic.

1.2.3   Fair Usage Control Subscriptions Types

Two types of Fair Usage Control subscription types are possible:

• Postpaid: The subscriber has a subscription with certain usage limits configured for a period. For example, 1 GB per month. At the end of the defined period, the SAPC automatically resets the associated usage accumulators, and the initial conditions are restored for the subscriber. For example, the bandwidth limitation applied when the limit was surpassed is revoked.

  In postpaid subscription, the SAPC automatically resets complementary usage accumulators when the associated reset period expires, and also when the reset period of the absolute usage accumulator expires.

• Prepaid: The subscriber has a voucher with certain usage limits, and a period of validity. When any of the established limits are surpassed or the expiration date of the voucher is reached, the service conditions are limited according to the configured policies, but usage accumulators are not automatically reset. The service conditions are re-established when the subscriber refills the voucher.

  The subscriber can also have multiple vouchers with the same absolute usage limits and use them one by one. In this case, the usage accumulator can be reset automatically.

  The expiration date for prepaid subscriptions is the date when the prepaid subscription stops being valid. See more information in Section 1.4.

  However, during the prepaid subscription the SAPC automatically resets complementary usage accumulators when the reset period of the complementary usage accumulator expires.

1.2.4   Usage Control at Subscriber or shared dataplan Level

The SAPC can perform usage accumulation at subscriber and/or shared dataplan level. The usage accumulation at shared dataplan level allows more than one subscriber to share a common usage limit. See Section 1.7 for more information.

Each subscriber handled by the SAPC can be associated to a shared dataplan (only one) to share a common Fair Usage Profile. The usage performed by every member with the same shared dataplan is accumulated in the same usage accumulators and is controlled by common usage limits.

Each shared dataplan can be associated to one or several subscriber groups.

Fair Usage Profiles can be configured at the following levels:

• Subscriber level
• Subscriber Group level

  Fair Usage Profiles defined at Subscriber level apply for the concrete subscriber, while Fair Usage Profiles defined at Subscriber Group level apply for all subscribers belonging to that Subscriber Group and all shared dataplans associated to that Subscriber Group.

  Fair Usage Profiles defined at Subscriber Group level allow a more efficient provisioning management.

Note:  

If there is a conflict between provisioned usage limits for the same Reporting Group, the SAPC applies a precedence criteria according to the steps described in Section 1.9.2 .

For each usage limit configured at subscriber or subscriber group level, a usage accumulator is created that stores the accumulation done for the Reporting Group. This usage accumulation is stored as follows:

• per subscriber
• per shared dataplan

  As stated before, notice that usageperformed by all members of the same shared dataplan is accumulated in the same usage accumulator. And therefore, all members share the usage limits.

Figure 6 shows the relationship between subscriber, shared dataplan and subscriber group:

The figure shows relationships for Fair Usage Profiles defined at Subscriber and Subscriber Group level.For subscribers having Fair Usage Profile defined at Subscriber level, it can be seen that the usage limit and the usage accumulator are part of the Subscriber data.For subscribers belonging to a subscriber group with Fair Usage Profile, limits are defined at Subscriber Group level and the usage accumulator is part of the Subscriber data.

For shared data plans, limits are defined at subscriber group level and the usage performed by all the members of the shared data plan is accumulated in the same usage accumulator (associated to the shared dataplan).

Figure 7 shows the differences in the accumulation for the different Fair Usage Profile users:

Figure 7 shows how Fair Usage Profiles can be assigned to individual subscribers and subscriber groups. A Fair Usage Profile with usage limit for total traffic of 6 GB is assigned to Subscriber 5 and also to the Gold subscriber group. Therefore, this Fair Usage Profile will be also assigned to all subscribers and shared dataplans belonging to Gold subscriber group. Usage is accumulated in different usage accumulators for each subscriber or for each group of subscribers sharing the same usage quota (shared dataplan). Usage of members belonging to the same shared dataplan is accumulated in the same usage accumulator, as can be seen in the usage accumulator associated with the shared dataplan defined for the "Martin" family. Meanwhile the usage performed for those individual subscribers belonging to Gold group is accumulated in independent subscriber usage accumulators.

1.2.5   Usage Limits Split in Intervals

Usage limits can be divided in slices or intervals. This prevents the SAPC from not receiving usage reporting data for too long or too short periods. In addition, it permits the SAPC to manage in an accurate way, the common limits shared among the subscribers belonging to a shared dataplan, and also the common limits for the different IP sessions established by a subscriber.

The following intervals can be defined:

• Minimum quota time or volume

  It is the minimum time or volume quota that can be assigned to a Reporting Group. It prevents the SAPC from receiving usage reporting too often or being calculating time usage too frequently, and avoids signalling storms when a subscriber is reaching the end of the usage limit.

• Slice time or volume

  It is the maximum time or volume quota that can be assigned to a Reporting Group. It is used to control the common limits shared among the subscribers belonging to the same shared dataplan and among the different IP sessions established by a subscriber.

• Reporting interval time

  It specifies the maximum time between usage reports, to force the reception of volume usage information or calculate time usage information in regular time intervals, independently of the number of bytes or time consumed by the subscriber. It prevents the SAPC from not accumulating usage reporting for a long period.

1.3   Accumulate Usage Depending on Conditions

Fair Usage Control function also enables the SAPC to perform usage accumulation based on certain conditions configured using policies. For example, accumulate only when subscriber is roaming or only in rush hours.

These conditions can be different per Reporting Group or can be applied to all the Reporting Groups of the subscriber. It is possible to use the following conditions:

• Time conditions, such as accumulate usage from 8:00 a.m. to 17:00 p.m., or accumulate usage only during working days.

  Note:  

  If the PCEF has sent the UE time zone offset and the SAPC is configured to accept it, the time conditions are corrected with this offset. Otherwise, only the SAPC local time is considered.

  
  
• Dynamic conditions, using the information received in the incoming traffic message, such as user location, access type.

  For example, accumulate VoIP usage only at roaming. However, the rest of the services are always accumulated.

  The SAPC can also be configured to only accumulate the roaming traffic within countries in the European Union, and so on. This scenario requires that the SAPC is subscribed to the corresponding event triggers (such as SGSN change), so the PCEF informs the SAPC when the dynamic conditions change (such as location area change, access type change).

• Dynamic information about access data for Fair Usage, such as the accumulated usage, if the expiration date has been reached, whether a limit has been surpassed.
• Subscriber information, using subscriber data stored in the database, such as age of the subscriber.

If there is no policy applicable to the Reporting Group, the SAPC determines that usage control is always performed.

Multiple usage accumulators depending on accumulation conditions

It is possible to accumulate usage data of each Reporting Group in different usage accumulators depending on accumulation conditions by defining conditional limits. For example, for the P2P Reporting Group, two different usage accumulators can be defined to accumulate the traffic for roaming traffic and for home-generated traffic.

Operators must define the corresponding volume or time condition limits for each usage accumulator. For example, 1 GB limit for P2P while roaming, and 3 GB limit at home.

The SAPC can execute different actions according to the policies associated with the conditional limits defined for each usage accumulator.

Usage Accumulation Policies evaluation

Evaluation of usage accumulation policies is used to determine which of the reporting groups and usage accumulators of the subscriber are subject to usage control, depending on the configured usage accumulation conditions. Therefore, evaluation of usage accumulation policies determines if accumulation is performed or not at next reception of the usage data from the EF. As a result, the SAPC enables the usage accumulators to be updated with the next usage report and disables the rest.

The SAPC applies the following priorities between accumulation policies:

• Policies applicable to a particular usage accumulator in a particular Reporting Group. For example, to limit data usage of P2P services in roaming.
• Policies applicable to a particular usage accumulator in any Reporting Group. For example, to limit data usage in roaming for any service.
• Policies applicable to all usage accumulators in a particular Reporting Group. For example, to limit data usage in a particular PDN connection for a particular service or group of services.
• Global accumulation policies applicable to all usage accumulators in all Reporting Groups. For example, to limit data usage in a particular PDN connection for all services.

If no usage accumulator is specified in the policies, the result of the evaluation of the usage accumulation policies applies to all usage accumulators of the Reporting Group.

If there is no policy applicable to the Reporting Group, the SAPC determines that usage control must always be done.

Note:  

In a scenario in which multiple IP sessions exist for a subscriber, it is possible to accumulate usage data for each Reporting Group in different usage accumulators, depending on accumulation conditions. For example, for a Reporting Group, a usage accumulator can be defined to accumulate the traffic generated towards a certain APN, for example, APN1. The IP sessions established by the subscriber towards APN1 accumulate in the usage accumulator of APN1, while the rest of the IP sessions do not result in updating that usage accumulator.

1.4   Usage Accumulators Life Cycle

The SAPC allows the definition of the usage accumulators life cycle within the provisioned Fair Usage Profile.

Subscription Date

Operators can provision a subscription date for each Fair Usage Profile for a subscriber or a subscriber group indicating the date when the Fair Usage Control function starts. The subscription date for a subscriber or shared dataplan depends on the following conditions:

• For Fair Usage Profiles provisioned with a subscription date either at subscriber or subscriber group level, the subscription date is considered.
• For Fair Usage Profiles provisioned at subscriber level without a subscription date, the considered subscription date is the system date and time at the moment of starting the first IP session.
• For Fair Usage Profiles provisioned at subscriber group level without a subscription date, with the following characteristics:
  • Part of a Temporary Subscriber Group and the subscriber group is assigned to the subscriber or shared dataplan without a start date

  The subscription date considered is the system date and time at the moment this subscriber starts the first IP session, applicable to that usage accumulator. See Temporary Subscriber Groups in Subscription and Policy Management.

• For Fair Usage Profiles provisioned at subscriber group level without a subscription date, with the following characteristics.
  • Part of a Temporary Subscriber Group and the subscriber group is assigned to the subscriber or shared dataplan with a start date

  The subscription date considered is the date when this temporary service offering starts. This allows the operator the flexibility to assign a fixed billing period to the subscriber without assigning a reporting group at subscriber level, simplifying this way the operator provisions tasks.

Note:  

If the PCEF has sent the UE time zone offset, and the SAPC is configured to accept it, this offset is considered while calculating the subscription date. Otherwise, only the SAPC local time is considered.

Reset Period

The supported reset periods are as follows:

• Reset on specific dates (applicable only to postpaid subscriptions), like day xx/hour yy/minute zz of each month or week or hour yy/minute zz of each day.
• Periods of fixed length: monthly, number of days, or number of hours

Complementary Usage Accumulators life cycle

It is possible to specify a reset period that applies to all usage accumulators of a Reporting Group, but it is also possible to specify independent reset periods per established complementary limit (for example, weekly or daily limits). In this case, the following conditions apply:

• The reset period of the absolute usage accumulator must be always longer than the reset period of the complementary usage accumulators, otherwise the SAPC returns a provisioning error message.
• If the reset period for the absolute usage accumulator is not provisioned, each complementary limit has an independent accumulation period.

In addition, it is possible to monitor the usage during a specific period, for example monitor subscriber usage per day, per week or per month, without taking any policy control action when the limit is reached.

Expiration Date

The SAPC calculates the expiration date for the absolute usage accumulator and the expiration date for each complementary usage accumulator independently, according to the reset period configured for each usage limit and for the Reporting Group.

• Prepaid subscriptions

  The expiration date for the Reporting Group in prepaid subscriptions is calculated as the sum of the subscription date and the reset period. This is the date when the prepaid subscription stops being valid. When reset period for the Reporting Group is not configured, the end-date for the subscriber group association is the time when the reporting group becomes inactive. If end-date for the subscriber group association is not defined, the prepaid subscription is always active.

  If the operator has defined complementary usage limits with independent reset periods, the SAPC updates periodically the expiration date for each complementary usage accumulator either on specific dates or as the sum of the previous expiration date and the reset period.

• Postpaid subscriptions

  The expiration date for postpaid subscriptions is periodically updated for both, the Reporting Group and for each complementary usage accumulator. When the expiration date is not configured as a specific date, it is calculated as the sum of the previous expiration date and the reset period.

  When the expiration date is configured as a reset on specific dates, the expiration date is derived as follows:

  • The specified day, hour, or minute of current month, week, or day if the expiration date has not already been reached
  • Next month, week, or day if the expiration date has passed the previously configured expiration date

If the reset period is a month, the expiration date for the next period is calculated as the same day, same hour, and same minute of the previous month.

If the subscription date or reset period is the 29th, 30th, or 31st and this day does not exist in the next month, the expiration date is adjusted to the last day of the month.

Note:  

If the PCEF has sent the UE time zone offset, and the SAPC is configured to accept it, this offset is considered while calculating the expiration date. Otherwise, only the SAPC local time is considered.

Mechanism to avoid overload situations

For postpaid subscriber groups, if a reset on specific dates is configured, Ericsson recommends not specifying the second or minute in the configured period to avoid congestion situations. The SAPC calculates the expiration date for each subscriber of the subscriber group considering a random number of seconds or minutes from 0 to 59.
This avoids sending many messages simultaneously reporting usage for all the subscribers belonging to the same subscriber group. It is also possible not to specify the specific hour for a fixed reset period. In this case, the expiration date is reached at any hour of the day.

For more information about this mechanism, refer to Overload Control.

Reset of usage accumulators

The SAPC automatically resets all the usage accumulators associated with a Reporting Group under the following circumstances:

• When the expiration date of the absolute usage accumulator for postpaid subscriptions is reached.
• When subscription date of a Reporting Group is changed.

  A voucher can be refilled by modifying the subscription date of a Reporting Group assigned to the subscriber. The usage accumulator is reset when the Reporting Group becomes active again.

  The SAPC calculates the new expiration date as the sum of the new subscription date and the reset period (if a reset period has not been configured on a specific date).

• When the start date of the subscriber group to which the Reporting Group is assigned (if any) is updated.

  A voucher can be refilled by modifying the start date of the subscriber group. The usage accumulator is reset when the new start date is reached.

• When the second or subsequent voucher is activated, among multiple vouchers with the same absolute usage limits associated with a subscriber group for prepaid subscriptions.
• When ordered by provisioning interface.

When the expiration date of a complementary usage accumulator is reached, only this particular usage accumulator is reset.

When the expiration date of the absolute usage accumulator in prepaid subscriptions is reached, usage accumulators are not reset but the Reporting Group is considered expired.

If the subscription type of a Reporting Group changes from prepaid to postpaid or the opposite way, the usage accumulators are not reset. The usage reporting received after the subscription change is added to the previously stored accumulated data.

If the reset period is changed, the usage accumulators are not reset. The SAPC calculates the new expiration date as the sum of the subscription date and the new reset period, if a reset is not configured on specific dates. If the new expiration date is before the current date, and it is a postpaid Reporting Group, the reset period is added again until the expiration date is later than current date.

When a postpaid subscriber establishes multiple IP sessions, the usage accumulators are reset when the SAPC receives the first usage reporting from an IP session of the subscriber when expiration date is reached. When the SAPC receives the usage reporting from the other IP sessions, usage accumulators are not updated.

1.5   Actions When Limit is Reached

When any usage limit is reached or when the subscription expires, an operator can use the Fair Usage Control functionality to take any of the following actions supported by the SAPC:

• Access control

  The SAPC can deny access to a certain service or group of services if subscriber consumption has reached the limit or the expiration date. For example, if a subscriber can use up to 20 hours of VoIP in a month and 1 GB of data of a P2P application within one day, access to both services are denied when these limits are reached. If Ericsson Gx+ is used and enhanced service authorization capability can be used, the SAPC can inform the PCEF about the reason for denying access.

• Default bearer QoS control

  For example, the SAPC can change the default bearer QoS profile (QCI, MBR, and so on) when usage limit or expiration date is reached.

• Throttling

  The SAPC can downgrade the rate limit once the usage limit or expiration date is reached. For example, a subscriber can be granted a maximum bandwidth of 3 Mbps for P2P and VoIP for the first 1 GB of data consumed during a month. However, for all consumption over 1 GB during the rest of the month, the maximum bandwidth is 500 Kbps.

  Also, it is possible to configure subscriber policies in such a way that a certain bandwidth is granted up to 3 hours of usage per day but the bandwidth is decreased if this time is exceeded during the day.

  The following figure shows how P2P rate is downgraded after the volume threshold is reached:

  

• Sending of notifications

  The SAPC can send a notification when the subscriber has reached a configured usage limit or expiration date.

  

• Charging control

  For example, rating group change for voucher subscriptions, when the expiration date is reached the subscriber loses its flat rate and is charged again as normal.

• Session termination
• Any other action that can be taken by the SAPC

Fair Usage Control actions are configured using policies. The SAPC evaluates all policies applicable to the subscriber. See more information about how policies are evaluated in the SAPC in Subscription and Policy Management.

Note:  

When the usage limit associated with a subscriber is reached after usage reporting is received (volume) or calculated (time) for one of the subscriber's IP sessions, the SAPC applies the configured actions to this IP session and to each one of the IP sessions established by the subscriber.

Shared dataplans

The policy decision when the usage limit for the shared dataplan has been surpassed is typically the same for all the members of the shared dataplan (family, corporation,...). However, if specific policy decisions have been configured for the Subscriber, they prevail over the policy decisions defined for the shared dataplan.

When the usage limit associated with a shared dataplan is reached by one of its members, the SAPC applies the configured actions to this subscriber but not simultaneously to all members associated to the shared dataplan. To apply configured actions to each member the SAPC waits for their usage reporting (once their granted slice is consumed).

1.6   Multiple Services Offering

A subscriber can be subscribed to multiple services offering plans, vouchers, and promotions, having each services offering different Fair Usage Profiles. Services offerings, promotions, and so on, are managed in the SAPC through subscriber group management.

As explained in Section 1.2.4, all the subscribers or families belonging to the same subscriber group have the same services offerings, and therefore the same Fair Usage Profile.

The association between a subscriber or shared dataplan and the related subscriber groups can include:

• A priority that the SAPC uses as criteria to decide which Reporting Group is selected in case there are conflicts between the different Fair Usage Profiles.
• Start, end date or both of the subscriber group association.

  This enables the subscriber to be subscribed to vouchers or promotions during the desired period.

The SAPC initiates a reauthorization message towards the EF when a subscriber group becomes active. The SAPC initiates another reauthorization message when the subscriber group becomes inactive to get the usage information and update the usage accumulator, before activating the new subscriber group.

Using the multiple services offering function, it is possible to implement basic turbo button use cases (see Section 3.6.1) where a subscriber buys a turbo button services offering valid during a certain period and with higher priority compared to the subscriber normal services offering . The SAPC models this scenario by associating a subscriber with two different subscriber groups The association between the subscriber and the turbo button has a validity time (defined by the start or the end date), and a higher priority compared to the normal subscriber group.

In addition to the association between a subscriber or shared dataplan and the related subscriber groups, the SAPC supports dynamic selection of subscriber groups, using dynamic group selection policies (including operator configured conditions based on dynamic access information, accumulated usage, time, and date conditions, and so on). These policies are evaluated in the SAPC only for the list of groups associated with the subscriber and when current date is between the start and the end date. Refer to Subscription and Policy Management.

This allows the SAPC to support advanced turbo button use cases (see Section 3.6.2 ) where the turbo button services offering described in the previous paragraph are only valid while there is remaining quota. The SAPC models this scenario by adding a dynamic group selection policy (refer to Subscription and Policy Management) to select the turbo button service offering based on the remaining quota.

Different usage accumulator per services offering

The SAPC accumulates the usage data of those Reporting Groups assigned to different subscriber groups (that is, different services offering) in separate usage accumulators, one per subscriber group to which the Reporting Group is assigned to. For example, if a subscriber belongs to 'Silver' and 'Turbo' subscriber groups and the Reporting Group p2p is assigned to both groups, the SAPC accumulates the usage of p2p service in a usage accumulator when the 'Turbo' group is active and in a different usage accumulator when the 'Silver' group is the active one.

Each usage accumulator specifies the subscriber group name to which the Reporting Group (if any) is assigned. If the subscriber group name is not specified, that means that the Reporting Group is assigned at subscriber level. This information enables an operator to know which usage accumulator is associated with each subscriber group.

The following figure shows how a subscriber (John) can be subscribed to three different services offerings: VoIP for families, Silver, and Turbo. Each services offering has a different Fair Usage Profiles. John is also subscribed to a particular Fair Usage Profile for Mobile-TV, all these Fair Usage Profiles are applied to the subscriber.

The figure shows how usage is accumulated for each Reporting Group in different usage accumulators. If the same Reporting Group is configured for different subscriber groups (p2p in this example), the SAPC solves the conflict by taking into account the priority and the time period during which the subscriber group is active. See how the SAPC selects the Reporting Groups in Section 1.9.2 . The graphic shows the period in which a turbo subscriber group and a silver subscriber group are active. The turbo subscriber group has a higher priority than silver group, so the SAPC selects p2p associated with the Turbo group, and then the usage accumulator is accumulated in the p2p Turbo usage accumulator between 8:00 to 17:00. The usage during the rest of the day is accumulated in the p2p silver usage accumulator.

1.7   Shared Subscriber Plans Support

The SAPC supports Shared Subscriber Plans in which more than one subscriber share common usage limits and usage accumulators.

The SAPC enables the following Shared Subscriber Plans functionality:

• Defines a common limit for all subscribers associated to the shared dataplan.
  The SAPC applies the desired policy decisions for all members, such as disabling the accumulation, bearer QoS downgrade, terminate IP-CAN session when that shared limit is surpassed and there is no remaining quota to be used.
• Defines individual limits per shared dataplan member or per category of members (group of family members categorized in the same way such as, children for domestic shared plans or owner of the plan, who is the person paying for the plan).

  These individual limits are defined using conditional accumulation.

  The SAPC also applies the desired policy decisions, such as disabling the accumulation, bearer QoS downgrade, terminate IP-CAN session when these additional limits are surpassed.

• Monitors the usage per shared dataplan member or specific category using conditional accumulation.
• Defines prepaid and postpaid shared subscriber plans (or basic and enhanced turbo button plans). A prepaid plan is selected until it expires or there is no quota left. Dynamic group selection policies are a prerequisite to achieve this functionality.
• Combines individual subscriber plans with shared subscriber plans. Either the individual plan or the shared plan is selected until the corresponding limit is surpassed and there is no remaining quota left to be used. Dynamic group selection policies are a prerequisite to achieve this functionality.

1.8   Shared Devices Plans Support

The SAPC supports Shared Devices Plans, in which one subscriber can pool multiple devices (tablet, dongle, mobile phone, and so on.) Under the same data plan.

In this offering, one subscriber has several devices with different SIM cards but the same MSISDN (shared subscription). As all SIM cards are associated with the same subscriber identifier (MSISDN), all SIM cards share common usage control limits and accumulate usage in shared usage accumulators. The different devices and SIM cards that share the data plan can be identified by the International Mobile Subscriber Identity (IMSI) or by the International Mobile Station Equipment Identity (IMEI).

The SAPC enables the following Shared Devices Plans functionality:

• Defines a shared limit for all devices.

  The SAPC also applies the desired policy decisions, such as QoS downgrade, rating change, access not allowed and notification sent when that shared limit is surpassed and there is no remaining quota to be used.

• Defines individual limit for a specific IMEI or IMSI.

  These individual limits are defined using conditional accumulation (Section 1.3.
  Specific policy decisions can be applied based on having surpassed these additional limits, such as QoS downgrade, rating change, access not allowed and notification sent.

• Monitors the usage per IMSI or IMEI using conditional accumulation.
• Defines prepaid and postpaid shared devices plans (or basic and enhanced turbo button plans). A prepaid plan is selected until it expires or there is no quota left. Dynamic group selection policies are a prerequisite to achieve this functionality.

1.9   Fair Usage Control Procedure

Fair Usage Control procedure is performed whenever a session is authorized, even when an event trigger different to usage report is received. It consists mainly of the following steps:

• Usage Update

  The PCEF reports the volume usage to the SAPC or the SAPC calculates time usage and the SAPC uses this information to update the usage accumulators.

  Usage update is performed at quota expiration or at reception of update message only if usage report event trigger is received.

• Selection of Reporting Groups

  The SAPC selects the Reporting Groups of the subscriber according to Section 1.9.2.

• Verification of usage accumulator reset

  If a selected postpaid Reporting Group reaches its expiration date, the SAPC resets its usage accumulator.

• Evaluation of usage accumulation policies for the selected Reporting Groups

  Depending on the configured usage accumulation conditions, the SAPC determines which Reporting Groups of the subscriber and also which usage accumulators of these Reporting Groups can be enabled for accumulation at next reception of usage data from PCEF for each established IP-CAN session (according to Section 1.3 ).

  Policies associated to the subscriber, the groups to which the subscriber belongs to (including subscriber groups assigned to the subscriber shared dataplan, if any), and global policies for the selected active Reporting Groups are evaluated. See how the SAPC solves policies conflicts in Subscription and Policy Management.

  If there is no policy applicable to the Reporting Group, the SAPC determines that usage control is always performed.

• Quota Calculation for the selected Reporting Groups
• Session reauthorization, to enforce new Policy and Charging Control (PCC) data applicable in the PCEF when the conditions specified in Section 1.9.4 occur:

1.9.1   Usage Update

If the PCEF supports Fair Usage Control and the subscriber has a Fair Usage Profile provisioned, the PCEF provides regular updates about volume usage. For the case of time limits, the SAPC regularly calculates time usage.

When the SAPC receives volume usage reporting with a certain traffic identity or calculates time usage, the SAPC looks for the corresponding subscriber identifier, based on the identity mapping information. The subscriber identifier obtained is used for usage accumulation. If the SAPC does not find any mapping or an unknown subscriber is applied, the SAPC uses the traffic identity.

For each selected Reporting Group of the subscriber, the SAPC updates the corresponding usage accumulators that are enabled for the IP-CAN session with the usage received from the PCEF. The SAPC updates the corresponding usage accumulators by adding the information of usage received to the information previously stored in the accumulation repository. If no usage information is received in the request, the SAPC considers that the usage from the last report is zero.

The accumulated usage for the IP-CAN session only persists during the duration of an IP-CAN session. The accumulated usage for the subscriber persists along the different IP-CAN sessions established by the subscriber.

If the subscriber is associated to a shared dataplan, the SAPC updates the corresponding usage accumulator for the shared dataplan with the information of usage received from the PCEF.

The following usage information can be received from the PCEF per service or set of services or for the total traffic:

• Volume uplink used
• Volume downlink used
• Bidirectional volume used, which is the sum of the volume used in the uplink and downlink directions

The SAPC provides a mechanism to accumulate and internally control the time usage of the total traffic consumed. When the SAPC receives a request message from the PCEF or at any event that causes a reauthorization of the IP-CAN session (such as update user profile), the SAPC automatically adds the time elapsed since the last event to the corresponding time usage accumulator for total traffic.

The SAPC can activate and deactivate usage reporting during an IP-CAN session lifetime.

1.9.2   Selection of Reporting Groups

The SAPC obtains Fair Usage Profiles information from the subscriber profile and from the active subscriber groups the subscriber belongs to. The SAPC selects the active subscriber groups for the subscriber according to Subscription and Policy Management.

The SAPC also checks if the subscriber is associated to a shared dataplan and obtains the Fair Usage Profiles from the Subscriber Groups provisioned to the shared dataplan. These are the Reporting Groups for the shared dataplan.

To avoid conflicts when the same Reporting Group is configured at subscriber and subscriber group level, the SAPC determines the following order of priority to select the Reporting Groups applicable to a subscriber:

1. Subscriber profile.
2. Active Subscriber Group profile provisioned to the shared dataplan.

   If the same Reporting Group is defined for several Subscriber Group profiles provisioned the shared dataplan, the Reporting Group defined for the active Subscriber Group with higher priority is selected. See more information about priority for Subscriber Groups in Subscription and Policy Management.

3. Active Subscriber Group profile.

   If the same Reporting Group is defined for several Subscriber Group profiles provisioned to the subscriber, the Reporting Group defined for the active Subscriber Group with higher priority is selected. See more information about priority for Subscriber Groups in Subscription and Policy Management.

Note:  

When the subscriber belongs to subscriber groups and is also a member of a shared dataplan , and there exists the same Reporting Group in Fair Usage Profiles in Subscriber Groups associated to the subscriber and to the shared dataplan, the SAPC can bypass, by defining dynamic group selection policies (refer to Subscription and Policy Management, the selection sequence for Reporting groups described earlier. The selection sequence is bypassed by selecting the subscriber or shared dataplan subscriber group, based on dynamic conditions.

For the rest of Reporting Groups (not in conflict), the SAPC selects all the Reporting Groups assigned to the subscriber and all the Reporting Groups assigned to every active Subscriber Group to which the subscriber or the dataplan is provisioned.

1.9.2.1   Status of Selected Reporting Groups

Each selected Reporting Group can be in any of the following statuses:

• Inactive

  A Reporting Group is considered inactive if the subscription date is later than the current date, or current date is later than the end-date of the subscriber group.

• Active

  A Reporting Group is considered active if its subscription date is equal to or before the current date, and its expiration date has not yet been reached

• Enable for accumulation

  Only the usage accumulators belonging to Reporting Groups in active status can be considered to be in status "enable for accumulation". This status occurs if as result of evaluating the usage accumulation conditions, it is determined that when the next usage report is received from the PCEF, accumulation must be performed for the usage accumulator.

• Disable for accumulation

  Only the usage accumulators belonging to Reporting Groups in active status can be considered to be in status "disable for accumulation". This status occurs if as result of evaluating the usage accumulation conditions, it is determined that when the next usage report is received from the PCEF, accumulation must not be performed for the usage accumulator.

• Expired

  A Reporting Group is considered expired when current date is later than its expiration date, and the end date of the subscriber group (if the Reporting Group is assigned to a subscriber group) is not reached. Accumulation is not applicable to expired Reporting Groups.

  Postpaid Reporting Groups can never be in status "expired" because if the expiration date is before the current date, then the reset period is added again until the expiration date is later than the current date.

When a subscriber establishes multiple IP-CAN sessions, the SAPC maintains the status of the usage accumulators for each of the IP-CAN sessions so that the SAPC can consider a usage accumulator as enabled for one IP-CAN session, and disabled for another IP-CAN session of the subscriber

1.9.3   Quota Calculation

Calculation of available volume or time quota

The SAPC sends the available volume or time quota, which is the number of bytes or seconds allowed for the subscriber to the PCEF. When the quota is used, the PCEF can send another update event requesting further quota.

Note:  

It can be possible that the subscriber gets more usage than the limit when the subscriber has several simultaneous IP-CAN sessions. The additional usage is proportional to the configured limit or slice value multiplied by the number of sessions.

The SAPC calculates volume and time quota using the following steps:

Volume calculation

The SAPC calculates the volume quota (uplink, downlink, and bidirectional) for each selected Reporting Group in active status according to the following steps:

1. Calculate the available volume (uplink or downlink or bidirectional for each of the volume limits that are defined for the Reporting Group, and whose corresponding usage accumulator is enabled. See EnableForAccumulationStep for the IP-CAN session, that is, considering the volume limits that apply for a period, the volume limits that apply to the IP-CAN session duration, and the intermediate limits.

   For each of the volume limits defined with the correspondingly enabled usage accumulator, if the limit has not yet been reached, this available volume is calculated as the corresponding volume limit minus the accumulated used volume.

2. Calculate the minimum of the available volume quotas for the Reporting Group calculated in previous step, but differentiated for uplink, downlink, and bidirectional traffic. If there is any available volume equal to zero, it is not considered in the calculation. If all the volume limits of the Reporting Group have been reached or the Reporting Group does not have any usage accumulator enabled, it implies that volume usage reporting for this Reporting Group is not required during the next period.
3. Select the minimum value between the value obtained in previous step (uplink, downlink, and bidirectional volume) and the configured slice volume.

   The slice volume is the maximum allowed volume that can be consumed between usage reporting updates received from the PCEF.

4. If the configured minimum volume quota is higher than the uplink, or downlink, or bidirectional volume obtained in previous step, the minimum quota is used instead of the value obtained in previous step.

   The minimum quota volume is the minimum allowed volume that can be assigned as quota for a Reporting Group.

The result obtained is the uplink, downlink, and bidirectional volume quota for each selected Reporting Group in active status, and enabled for accumulation.

Time quota calculation

The SAPC calculates the time quota for each selected Reporting Group in active status according to the following steps:

1. Calculate the available time for each of the time limits that are defined for the Reporting Group, and whose corresponding usage accumulator is enabled for the IP-CAN session. Consider the time limits that apply for a period, the time limits that apply to the IP-CAN session duration, and the intermediate limits.

   For each of the time limits defined with the corresponding enable usage accumulator, if the limit has not been reached, the available time is calculated as the corresponding time limit minus the accumulated used time.

2. Calculate the minimum of the available times calculated in the previous step. If there is any available time equal to zero, it is not considered in the calculation. This minimum value is the time quota of the Reporting Group.

   If all the time limits of the Reporting Group have been reached or the reporting group does not have any usage accumulator enabled, it implies that time usage control for this Reporting Group is not required during the next period.

3. Select the minimum value between the value obtained in previous step and the configured slice time.

   The slice time is the maximum allowed time that can be consumed between usage reporting updates.

4. Time quota of the Reporting Group is the maximum value between the value obtained in the previous step and the configured minimum quota time.

   The minimum quota time is the minimum allowed time that can be assigned as quota for a Reporting Group.

Validity Time calculation

The SAPC also calculates the validity time for the next Fair Usage Control cycle, considering the following:

• The minimum time until expiration date is reached for either the volume limit or the time limit.
• The time until subscription date is reached, in case current date is before subscription date.
• The remaining time until any of the accumulation time conditions of the Reporting Group changes its evaluation result.

  Configured usage accumulation conditions can be based on time restrictions, so the accumulated decision is only applicable during a period.

• The maximum reporting interval time, if the Reporting Group is enabled for accumulation.

  It is possible to configure the maximum allowed time between usage reporting updates per Reporting Group.

  Note:  

  If there are configured usage accumulation conditions based on time restriction and current time is out of the accumulation period time, the maximum reporting interval time is not considered in the validity time calculation.

  
  

The validity time for the quota of the Reporting Group is calculated as the minimum value from the previous list. If no time is obtained as a result of the calculations in the previous list, it implies that usage reporting control is not required for this Reporting Group.

1.9.3.1   Quota Calculation for shared dataplans

As explained in Section 1.2.4, usage limits configured for the subscriber groups provisioned to a shared dataplan are shared by all members of the shared dataplan. The usage limit is divided in slices to control the quota assigned to each of the subscribers of the shared dataplan. See slice time and volume parameters in Section 1.2.5).

When the SAPC performs quota calculation for a member of a shared dataplan, if the available volume or time of the Reporting Group is higher than the configured slice, the slice value is the quota assigned to the subscriber for that Reporting Group (if the minimum quota is lower than slice as explained in previous steps). But the SAPC does not reserve the slice provided to this subscriber, so if the SAPC receives a request from any other member of the shared dataplan and quota calculation is performed before the previous member reports usage, the SAPC does not take into account that a quota was provided to the first member and another slice is assigned to the second member.

Therefore, it can be possible that the shared dataplan manages more usage than the limit when many of the shared dataplan members are simultaneously connected, and the extra usage is proportional to the configured slice value.

1.9.4   Session Reauthorization

Session reauthorization is performed to enforce new Policy and Charging Control (PCC) data applicable in the PCEF when the following occurs:

• Any usage accumulator that was previously enabled reaches the limit. See Section 1.5 for more information.
• The expiration date is reached
• usage accumulators have been reset because of:
  • An update of the subscription date of the Reporting Group assigned to the subscriber.
  • An update of the start date of the subscriber group to which the Reporting Group is assigned (if any).
• The selected Reporting Groups change.
• The validity time associated with a time limit expires.

Note:  

Session reauthorization is not performed at reception of IP-CAN session modification request if only usage report event trigger is received and none usage accumulator reaches the intermediate or final limit.

1.9.4.1   Force Usage Reporting from the PCEF

The SAPC requests the PCEF for usage reporting by sending a reauthorization message when:

• The subscription date of a selected Reporting Group is updated.

  Then the subscription date is updated to a date in the future, the SAPC forces the usage reporting disabling that usage monitoring in the PCEF.

• A new subscriber group becomes active for the subscriber, and at least one of its new Reporting Groups is in conflict with an active Reporting Group.

  In case the new Reporting Groups do not conflict with an active Reporting Group a reauthorization message is sent to provide quota for the subscriber; no usage reporting is requested.

• A subscriber group becomes inactive for the subscriber.

  When a subscriber group becomes not subscribed for the subscriber, and there is not any other subscriber group active with the same Reporting Group, the SAPC forces the usage reporting disabling that usage monitoring in the PCEF. This can occur in the following situations:

  • Removal of the association between a subscriber and a shared dataplan.
  • Removal of the association between a subscriber and a subscriber group.
  • The start date of a subscriber group is updated to a date in the future.
• A Reporting Group becomes disabled because of accumulation policies.
• A usage accumulator becomes disabled because of accumulation policies.
• The validity time associated with a volume limit is reached.

1.10   Quota Rollover

If a subscriber or shared data plan has not consumed the entire volume or time quota at the end of a billing period, the SAPC provides the possibility to transfer the remaining data to the next period. This does not apply to successive periods. The usage limit of the next period consists of the rollover and the data plan quota.

The Quota Rollover applies to postpaid Reporting Groups for both absolute and conditional volume and time limits. The same applies to shared data plans. Exceptions include the complementary, session limits, prepaid plans, and Aggregable Dataplans for Fair Usage Policies.

The following configuration options are available for operators:

• Set rollover limits for some usage limits to specify the maximum amount of data that can be transferred to the next period, but not for others within the same plan. For example, administer a rollover to absolute limit but not to the conditional limits, or apply a rollover limit to the absolute limit different from the conditional limits.
• Select if the rollover quota is used before or after the data plan at Reporting Group level.
• Quota Rollover activation at limit level.

Figure 14 shows examples of Quota Rollover behaviors. Two scenarios are described: when the rollover quota is used first, and when the data plan is used first.

Example 1 describes the Rollover Quota First scenario.
The data plan is 100 MB of with a rollover limit of 50%, so the maximum amount of data to rollover to next period is 50 MB.
Period 1 has 30 MB unused data, which is transferred to Period 2 making the total quota 130 MB.
In Period 2 the rollover amount is consumed first, and after it is depleted, the end user consumes the usage limit defined in the subscription. 20 MB of data remains, which is transferred to Period 3 where 120 MB of data can be consumed.
The end user has 70 MB remaining data in Period 3, but only 50 MB can be transferred because of the 50% rollover limit of the usage limit defined in the subscription. So only 50 MB of data is transmitted to Period 4, where this amount is consumed first again.

Example 2 describes the Data Plan First scenario.
The data plan is also 100 MB with a rollover limit 50%, and the maximum amount of data to rollover to next period is 50 MB.
In Period 1 the end user has 30 MB remaining data which is transferred to Period 2 as rollover quota. This means that after the end user consumed the usage limit defined for the subscription, so the 100 MB, the 30 MB from the previous period can be used.
In Period 2 the end user consumed 110 MB out of the 130 MB. Again, the usage limit defined in the dataplan is consumed first, and 10 MB of the rollover quota is also used. In this case the end user spent the usage limit defined in the subscription, the 100 MB. So the remaining 20 MB of data is not transferred to Period 3.
In Period 3 the end user has the total quota 100 MB to consume.
The end user has 70 MB remaining data in Period 3, but only 50 MB can be transferred because of the 50% rollover limit of the usage limit defined in the subscription. So only 50 MB of data is transmitted to Period 4, where this amount is consumed after the end user consumes the usage limit defined for the subscription.

1.10.1   Fair Usage Control Procedure

The Fair Usage procedure described in previous chapters is applicable when the Quota Rollover function is used, but with the considerations detailed in the following subsections.

1.10.1.1   Quota Rollover Calculation on Reset

When the expiration date of a postpaid Reporting Group is reached, the SAPC automatically resets all usage accumulators associated with the Reporting Group, including rollover usage accumulators. Rollover usage accumulators are the counters that accumulate the number of seconds or bytes of rollover quota that a subscriber or a shared data plan has consumed.

If the Quota Rollover license is active and the rollover limit is greater than 0%, before resetting the accumulators, the SAPC calculates the rollover quota for the next period associated with the absolute and conditional limits as MIN (data plan usage limit – data plan usage accumulator, Rollover Limit data).

Note:  

Quota Rollover is calculated when there is an open session. If a session is created, the rollover quota is calculated when the expiration time is reached. The SAPC manages it by using a time trigger. If there is no session, the SAPC calculates the rollover quota the next time a session is opened and the expiration time is surpassed.

1.10.1.2   Usage Update

Before updating information in the enabled accumulators, the SAPC checks if any rollover quota remained from the previous period.

In case there are remaining quota, the SAPC checks the configuration of the quota to determine whether it is to be consumed before or after the data plan. It also checks if the quota is based on volume or time usage limits.

The following section describes the possible outcomes of quota rollover.

Volume and Time Usage Limit:

The PCEF provides update about data usage in these cases.

The SAPC provides a mechanism to accumulate and internally control the time usage performed. When the SAPC receives a request message from the PCEF or a reauthorization of the IP-CAN session happens, the SAPC adds the time elapsed since the last event to corresponding time rollover usage accumulators and time usage accumulators for total traffic in the same way as the SAPC does for the volume received.

1.10.1.3   Quota Calculation

The SAPC calculates volume quota, which consists of uplink, downlink, or bidirectional link, and time quota for each selected Reporting Group in active status and for the total traffic based on the following logic:

If the rollover quota is greater than 0 and the data plan usage limit + rollover quota – data plan usage accumulator – rollover usage accumulator = 0, the PCEF stops usage reporting.

Otherwise, the SAPC calculates the quota downloaded to the PCEF according to the following logic: MAX [MIN (Slice Volume, Volume Limit + RolloverFromPreviousPeriod - Accumulated Usage - RolloverAccumulated), Minimum Quota Volume].

The following section describes the possible outcomes of quota calculation.

Intermediate Limit

If an intermediate limit is configured as a percentage of the final limit, the SAPC calculates the intermediate limit as percentage value * (data plan usage limit + rollover quota).

1.10.1.4   Notifications

The SAPC supports sending notifications on rollover quota in the following ways:

• When the expiration date is reached, the SAPC is able to notify the end user with the remaining data to be transferred.
• Once the rollover quota is consumed, the SAPC sends a notification to the end user.
• At any point, the SAPC is able to send a notification about the rollover data that is consumed.

1.11   Access to Usage Information

The Fair Usage Control function enables access through REST interface to the accumulated usage information (time and volume) stored in its internal database. REST interface can also be used to reset usage accumulators. This enables a customer care system or any other external system the capacity to acquire a report with the usage accumulator information.

1.12   Integration with an External Database

The Fair Usage Control function supports the accumulation of usage information in the SAPC internal database or in an external database depending on the type of deployment. The SAPC can read and write the usage accumulators to the external repository using LDAP.

The flexibility provided by the SAPC makes it possible to provision to a subscriber the Reporting Groups or Subscriber Groups in an external database and write accumulated usage data to an internal SAPC database.

1.13   Aggregable Dataplans for Fair Usage Policies

The SAPC supports aggregation of a subscriber's absolute usage limits from different subscriber groups and performs fair usage control for the aggregated usage limits.

• The SAPC adds respectively the uplink, downlink, bidirectional volume limits and time limits from aggregable Reporting Groups of subscriber groups to which the subscriber belongs.

  The aggregable Reporting Groups are postpaid Reporting Groups defined as aggregable with the same name (also "total", or no name).

• The SAPC takes each one of the different intermediate volume limits from the aggregable Reporting Group associated with the highest priority subscriber group containing that type of limit.
• The SAPC does not aggregate other fair usage data; other data are taken from associated subscriber group with the highest priority.

The following figure shows an example of usage limits aggregation.

The subscriber John is provisioned with Gold and Silver subscriber groups. The SAPC aggregates respectively the uplink limits and downlink limits. The SAPC takes "30%", "60%", and "90%" intermediate uplink limits from Gold group because it has higher priority than Silver group. The SAPC takes "50%" intermediate downlink limit from Silver group because intermediate downlink limit is not configured in Gold group. The SAPC takes the reset period from Gold subscriber group only.

The SAPC does not aggregate the usage limits from Reporting Groups provisioned at subscriber level or in shared subscriber plans.

Fair Usage Control Procedure

The fair usage control procedure is similar to Section 1.9, with the details related to Aggregable Dataplans for Fair Usage Policies as follows:

• Usage Limits Aggregation

  At the beginning of each fair usage control procedure, the SAPC searches the subscriber groups with aggregable Reporting Groups. The SAPC performs aggregation for the aggregable Reporting Groups associated with the subscriber groups under these conditions:

  • The current date is equal to or after the subscription date for aggregable Reporting Groups with subscription date.
  • The current date is between the start date and end date of subscriber groups assigned to the subscriber.

  The following aggregation mechanism is applied:

  • The aggregable data are absolute uplink, downlink, bidirectional volume limits and time limit.
  • For each volume limit, the SAPC takes the percentage intermediate volume limits from the associated subscriber group with the highest priority. If the highest priority subscriber group does not contain percentage intermediate volume limits, the SAPC takes the percentage values from the next highest priority group and so on.
  • Intermediate volume limits not expressed as percentage and intermediate time limits are not applicable for usage limits aggregation.

  The SAPC performs the aggregation of usage limits without taking into account Dynamic Group Selection policies.

• Usage Update

  The SAPC uses the aggregated usage accumulator to accumulate the volume or time usage of Reporting Groups that are aggregated. The SAPC distinguishes it from other usage accumulators using the "_Aggregated_" subscriber group name.

• Selection of Reporting Groups

  If the same Reporting Group is defined as aggregable and not aggregable for several Subscriber Groups assigned to the subscriber, the Reporting Group defined for an active subscriber group with the highest priority is selected.

  • If the selected Reporting Group is defined as aggregable, the SAPC takes into account for the Fair Usage procedure the aggregation of the Reporting Groups only defined as aggregable.
  • If the selected Reporting Group is not defined as aggregable, the SAPC takes into account for the Fair Usage procedure only that Reporting Group.
• Quota Calculation

  The SAPC calculates available volume or time quota based on the aggregated usage limits, if an aggregated Reporting Group is selected.

The aggregated limits data (such as the accumulated usage, whether the expiration date has been reached, or whether a limit has been surpassed) can be used in policy evaluation. For multiple service offerings, the "_Aggregated_" group name should be used in the policy conditions to point to the aggregated usage accumulator.

1.14   Stackable Dataplans

The SAPC uses multiple instances to handle multiple vouchers with the same absolute volume or time limits for prepaid subscriptions. Durations containing multiple sets of start date and end date of instances are provisioned in the association of subscriber and subscriber group. Depending on the provisioned durations, the subscriber group is assigned to the subscriber during multiple periods of time. Therefore, the subscriber can use multiple times the same absolute volume or time limits from the Reporting Groups of the subscriber group.

This functionality does not apply to the subscriber groups containing complementary, session, or conditional limits in the fair usage profile.

The following figure shows an example of multiple instances for prepaid subscriptions.

The subscriber John belongs to Gold subscriber group which has 2 GB limit for total traffic. John can use 2 GB traffic between 06-06 and 06-07, 2 GB traffic between 06-07 and 06-08, and 2 GB traffic between 24-08 and 24-09.

The same usage accumulator is used by the multiple instances associated with the subscriber groups for the subscriber. The SAPC marks the instance in use in the usage accumulator, for the subscriber group associated with multiple instances. The usage accumulator only stores the accumulated volume or time of the instance in use and calculates quota based on the instance in use. For the instances provisioned with overlapped durations, the SAPC records the list of used instances overlapped with the instance in use.

The fair usage procedure follows the description in Section 1.9 with the following exceptions:

• Instance Selection

  In the fair usage procedure, the SAPC checks if an instance is in use in the usage accumulator immediately after usage update.

  • If an instance is in use, its usage limits are not surpassed, and the expiration date of the instance is not reached, the SAPC keeps this instance in use.
  • If no instance is in use or the usage limits of the instance in use are surpassed or the expiration date of the instance is reached, the SAPC selects a new valid instance to activate. That is, the usage limits of a new instance are not surpassed and the current date is between its start date and end date.

    If two or more instances are valid, the SAPC selects one valid instance in the following order of priority:

    • Earlier end date, higher priority
    • Earlier start date, higher priority if end dates are the same
• Usage Accumulator Reset

  When the SAPC automatically activates the second or subsequent instance, the SAPC resets the usage accumulator and marks the new instance in use.

The SAPC supports notifications to the subscriber on the use of multiple instances for prepaid subscriptions.

2   Fair Usage Network Deployment

The following PCEFs support the Fair Usage Control function:

• Ericsson EPG using Ericsson Rel9 Gx+ onwards interface, where 3GPP Gx usage monitoring is used. In this case, usage reporting per service or set of services and for the total traffic are supported. Time usage is only supported for the total traffic, and it is not reported by the PCEF, but controlled internally by the SAPC.
• Rel9 Gx onwards compliant PCEF. In this case, usage reporting per Reporting Group and on total traffic are supported. Time usage is only supported for the total traffic, and it is not reported by the PCEF, but controlled internally by the SAPC.
• Multiple PCEFs.

  Figure 17 shows how the SAPC can interact with multiple PCEFs for the same IP-CAN session. For example, multiple PCEF support can be used to get usage reporting information from the DPI node, while the policy control based on actions related to accumulated usage is enforced in the GGSN.

3   Fair Usage Traffic Cases

This chapter explains the interface involved in Fair Usage Control. The SAPC supports 3GPP Gx usage monitoring for any deployment where Rel9 Gx onwards or Rel9 Gx+ onwards is used. For modification of Fair Usage Profile, the SAPC provides a REST interface when the profiles are stored in the SAPC internal repository. When the profiles are stored in an external repository, the SAPC offers a web service interface for receiving notification of changes from the external repository.

Though for detailed description of the interface supported it can be consulted the referenced interface description, it is highlighted some important considerations:

• Volume quota is provided, differentiated for bidirectional, uplink, and downlink volume traffic for the total traffic or per Reporting Group (per service or set of services).
• When the volume limit is reached, but the reporting group (or accumulator) remains enabled, the SAPC sends a high volume quota to the PCEF in order not to disable the volume reporting. When the reporting group (or accumulator) status changes the SAPC downloads quota zero to the PCEF.
• The SAPC forces usage reporting from the PCEF sending a RAR message which contains the grouped Usage-Monitoring-Information AVP. This AVP contains the Usage-Monitoring-Report AVP with value USAGE_MONITORING_REPORT_REQUIRED.

  The way to force usage reporting from the PCEF asking for the deactivation of the usage reporting is sending a reauthorization message with Usage-Monitoring-Support AVP set to USAGE_MONITORING_DISABLED.

  In both cases, the SAPC receives a Gx CCR Update message from the PCEF with the Usage-Monitoring-Information AVP which contains the Used-Service-Unit AVP with the volume quota information for total, UL and DL traffic mapped directly to CC-Total-Octets, CC-Input-Octets and CC-Output-Octets AVP AVP.

• When any event triggers a reauthorization of an IP-CAN session and there is at least one Reporting Group enabled for this IP-CAN session, the SAPC sends the available volume quota to the PCEF, even when it has not changed.
• The SAPC does not provide time quota. The SAPC provides a mechanism to accumulate and control internally the time usage of the total traffic. Each time a request message from PCEF is received, or when any IP-CAN session reauthorization event happens (see Section 1.9.4), the SAPC internally updates the time usage accumulator with the time elapsed since the last time, then the SAPC calculates the time quota and the validity time and sets an internal timer to the minimum value between the time quota and the validity time.

3.1   Basic Traffic Case

The following chapter shows the basic steps applicable for a subscriber with volume and time limits. Only the significant Fair Usage Control attributes for this Use Case are described in the following subchapter.

3.1.1   Protocol Binding for Rel9 Gx onwards

1. The SAPC receives a Gx CCR Initial message from PCEF indicating IP-CAN session establishment.
   • The SAPC performs Selection of Reporting Groups and Usage Accumulation policies evaluation, according to Section 1.9.
   • The SAPC calculates the volume quota for UL, DL, and bidirectional according to Section 1.9.3.
2. The SAPC calculates time quota and validity time according to Section 1.9.3 and obtains the minimum time value among Reporting Groups of the subscriber. A timer is set to the minimum value obtained.
3. The Gx CCA message is sent to the PCEF including the information previously computed. This message contains the following AVPs among others:
   • Usage-Monitoring-Information AVP, per Reporting Group. This is a grouped AVP which contains the AVPs explained following:
     • Granted-Service-Unit AVP is used to send the volume quota calculated in the previous step. This AVP maps the available volume for UL, DL, or bidirectional directly to the AVPs CC-Total-Octets, CC-Input-Octets and CC-Output-Octets AVP respectively.
     • Usage-Monitoring-Level AVP is used to monitoring control level. It takes the value SESSION_LEVEL to indicate if the usage Monitoring Key applies to the IP-CAN session or PCC_RULE_LEVEL if the usage Monitoring Key applies to a Reporting Group.
     • Monitoring-Key AVP is used as the identifier of the Reporting Group.
   • Event-Trigger AVP set to USAGE_REPORT to activate usage monitoring at the PCEF.
4. The SAPC receives a Gx CCR Update message indicating an IP-CAN session modification because of a Fair Usage Control related event through the Event-Trigger AVP set to USAGE_REPORT
   • The SAPC receives the Usage-Monitoring-Information AVP which contains Monitoring-Key AVP, Used-Service-Unit AVP with CC-Total-Octets, CC-Input-Octets, and CC-Output-Octets AVPs to indicate Total, UL and DL volume quota consumed respectively.

   When any event triggers a reauthorization of an IP-CAN session and there is at least one Reporting Group enabled for this IP-CAN session, the SAPC sends the available volume or time quota to the PCEF, even when it has not changed.

5. At this point:
   • The SAPC performs Volume Usage Update function according to Section 1.9.1.
   • The SAPC performs Time Usage Update function adding to the time usage accumulators that are enabled, the current time minus time of last event reception.
   • The SAPC performs Selection of Reporting Groups and Usage Accumulation policies evaluation, according to Section 1.9.
   • The SAPC recalculates the time quota and validity time according to ValidityTime and obtains the minimum time value among all the active Reporting Groups of the subscriber. The timer is updated to this minimum value to control time usage.
   • The SAPC calculates the volume quota for UL, DL, and bidirectional total traffic as it is indicated in Section 1.9.3.
   • The SAPC checks if any of the limits have been surpassed or if usage accumulators have been reset or if the validity time is reached or if the selected Reporting Groups have been changed. If any of the previous conditions happen, the SAPC evaluates operator configured actions such as IP Session Access Control, Service Access Control, Subscriber QoS Control, Charging control. If the volume limit has been surpassed, the quota value in CC-Total-Octets, CC-Input-Octets, and CC-Output-Octets AVPs are set to a high value, to continue receiving usage monitoring.

     Note:  

     When CC-Total-Octets, CC-Input-Octets, CC-Output-Octets AVPs are not included within Granted-Service-Units AVP or included with zero value, the usage monitoring is stopped. No zero values are sent in the AVPs to continue usage monitoring.

     
     

     Extension:

     • If there are multiple PCEFs controlling the triggering IP-CAN session and there are any limits that have been surpassed or usage accumulators have been reset, for each PCEF controlling the triggering IP-CAN session (apart from the requesting PCEF), a Gx RAR message is sent requesting Reauthorization.
     • If there are more IP-CAN sessions for the subscriber and there are any limits that have been surpassed, each additional IP-CAN session is reauthorized, and a Gx RAR message is sent with the new quota and the information corresponding to the policy evaluation result.
6. The Gx CCA message is sent to the PCEF including the information previously computed through the Usage-Monitoring-Information AVP which contains these AVPs:
   • Monitoring-Key AVP is used to identify the Reporting Group.
   • Usage-Monitoring-Level AVP with value SESSION_LEVEL if the usage Monitoring Key applies to the IP-CAN session or PCC_RULE_LEVEL if the usage Monitoring Key applies to a Reporting Group.
   • Granted-Service-Unit AVP with the computed values for UL, DL, and bidirectional mapped directly to the CC-Total-Octets, CC-Input-Octets, and CC-Output-Octets AVPs respectively.
7. The timer expires because time limit is reached.
8. The SAPC performs Time Usage Update according to Section 1.9.1. The SAPC evaluates operator configured actions such as IP Session Access Control, Service Access Control, Subscriber QoS Control, Charging control.
9. The SAPC sends a RAR to the PCEF with the new policy decisions to apply.

   Note:  

   As the volume quota was previously surpassed, its value is set to a high value in the RAR message, to continue receiving usage monitoring.

   When CC-Total-Octets, CC-Input-Octets, CC-Output-Octets AVPs are not included within Granted-Service-Units AVP or included with zero value, the usage monitoring is stopped. No zero values are sent in the AVPs to continue usage monitoring.

   
   

   Extension:

   • If there are multiple PCEFs controlling the triggering IP-CAN session and there are any limits that have been surpassed or usage accumulators have been reset, for each PCEF controlling the triggering IP-CAN session (apart from the requesting PCEF), a Gx RAR message is sent requesting Reauthorization.
   • If there are more IP-CAN sessions for the subscriber and there are any limits that have been surpassed, each additional IP-CAN session is reauthorized, and a Gx RAR message is sent with the new quota and the information corresponding to the policy evaluation result. If a use accumulator has been reset, the SAPC evaluates operator configured actions for the additional IP-CAN sessions for which the accumulator is not active and a Gx RAR message is sent with the new information corresponding to the policy evaluation result if applicable.
10. The PCEF answers with a RAA.
11. The SAPC recalculates the time quota and validity time according to ValidityTime and obtains the minimum time value among all the active Reporting Groups of the subscriber. The SAPC starts a timer that is set to the minimum value calculated.
12. The SAPC receives a Gx CCR Termination message from the PCEF requesting the termination of the IP-CAN session.
    • The SAPC updates the volume usage information following the procedure explained at Section 1.9.3 and taking into account the volume information received through the Usage-Monitoring-Information AVP which contains the Used-Service-Unit AVP to indicate Total, UL and DL volume consumed in CC-Total-Octets, CC-Input-Octets, and CC-Output-Octets respectively.
    • The SAPC performs Time Usage Update, adding to the time usage accumulator that are enabled, the current time minus time of last event reception.
    • The timer used to control time usage is deactivated.
13. The SAPC performs Usage Update and the timer is stopped.
14. The SAPC sends a CCA message to the PCEF including the Result Code.

Note:  

The SAPC provides in the CAA or RAR command the Usage-Monitoring-Information AVP including the Monitoring-Key AVP and the Granted-Service-Unit AVP.

3.2   Update subscriber profile

The following subsections show examples of updating an ongoing offer:

• Usage limits update.
• Removal of volume limit.
• Temporary extension of an offer adding a subscriber group to the subscriber.
• Update any subscriber data or subscriber qualification data.

3.2.1   Update Usage Limits

3.2.1.1   Protocol Binding for Rel9 Gx onwards Update usage limits

1. The Provisioning System updates through REST interface any Usage Limit data under the Subscriber profile.
2. The SAPC reauthorizes the IP-CAN session and performs Fair Usage Control Procedure according to Section 1.9 (except Usage Update):

   Gx RAR is sent to PCEF per affected IP-CAN session with the granted volume information, regardless it is new/modified or not. If the time limit is modified, the associated timer is updated internally, time information is not included in the Gx RAR message.

3. Gx RAA including Result-Code is returned by the client.

3.2.2   Removal of Volume Limit

This use case is used when the reporting is disabled from the SAPC. This happens when a subscriber has a volume limit and during an active IP-CAN session the volume limit is removed.

3.2.2.1   Protocol Binding Rel9 Gx onwards

1. The PCEF establishes an IP-CAN session as it is indicated in step 1 in Section 3.1.1.
2. The SAPC answers with a CCA activating the Usage Monitoring with the Event-Trigger AVP set to USAGE_REPORT and the volume quota for the total traffic or per service or set of services set in the Usage-Monitoring-Information AVP within the Granted-Service-Unit which contains CC-Total-Octets, CC-Input-Octets, and CC-Output-Octets AVP. The Monitoring-key AVP is included also.
3. The operator deletes the volume limit for the subscriber.
4. The SAPC sends a RAR with the AVP sage-Monitoring-Support set to USAGE_MONITORING_DISABLED.
5. The PCEF accepts the RAA.
6. The PCEF sends the used volume in a CCR update.
7. The SAPC ignores the volume usage, therefore it does not update the volume quota.
8. The SAPC accepts the CCR with a CCA. The SAPC evaluates all policy controls to obtain the policies to apply in the PCEF.

   Note:  

   If the limit that is removed from the subscriber is a time limit, the SAPC reevaluates the time-related policies and updates the information of the timer stored internally. There is no action towards the PCEF to disable reporting, as time usage reporting is controlled by the SAPC.

   
   

3.2.3   Subscription Temporary Extension

The subscriber has a normal post-paid Fair Usage Control subscription in this scenario. Once the subscriber reaches its limit, the limit is extended but only until the beginning of next billing period. When the billing period is reached, the normal subscription with its limits applies again automatically to the subscriber . A voucher purchase implies a similar traffic case.

We can model this traffic case defining two subscriber groups. One called 'normal', containing the basic post-paid subscription, and another one called 'extension', defining the subscription temporary extension characteristics.

The 'normal' subscriber group has a 2 GB monthly limit, whereas the 'extension' subscriber group has a 250 MB limit and the end date of this group corresponds to the first day of April, so the first day of April normal conditions are restored and normal usage accumulator is reset.

3.2.3.1   Protocol Binding for Rel9 Gx onwards Subscription Temporary Extension

• 1–2: IP-CAN session is established as steps described in Section 3.1.1.

  Subscriber group 'normal' is active for the subscriber.

• 3-6: Idem as steps 4–6 in Section 3.1.1. The SAPC receives a CCR update message and checks if any of the limits have been surpassed. If so, the SAPC evaluates operator configured policies for the subscriber to perform the configured actions, such as IP Session Access Control, Service Access Control, IP-CAN bearer QoS Control. The information corresponding to the policy evaluation result is included in Gx CCA message together with a high volume quota; in this case it is shown that a lower Bearer QoS profile is assigned to the subscriber.
• 7: The SAPC sends an SMS notification message to inform the subscriber that the subscriber limit has been reached and explaining the possibility of extending temporarily the subscription data until the next billing period.
• 8: The SAPC receives an update user profile, a new subscriber group called 'extension' with higher priority is provisioned to the subscriber, defining the subscription temporary extension characteristics.
• 9: The SAPC forces usage reporting from PCEF as explained in Section 3 Fair Usage Traffic Cases, to accumulate usage data in usage accumulator associated with 'normal' subscriber group.

  The RAR is sent with the Usage-Monitoring-Information AVP with the Usage-Monitoring-Report AVP set to USAGE_MONITORING_REPORT_REQUIRED.

• 10: RAA including Result-Code is returned by the client.
• 11-15: The SAPC receives a Gx CCR Update message from the PCEF. The CCR update message contains the Used-Service-Unit AVP with the volume information for total, uplink, and downlink set in Used-Service-Unit AVP through CC-Total-Octets, CC-Input-Octets, and CC-Output-Octets respectively.
  • 12: The SAPC performs Usage Update function, according to Section 1.9.1. Volume usage is accumulated in usage accumulator associated with 'normal' subscriber group, as well, the time usage is updated in the time usage accumulator associated with 'normal' subscriber.
  • 13: The SAPC performs Selection of Reporting Groups and Usage Accumulation policies evaluation, according to Section 1.9. Reporting Groups associated with 'extension' subscriber group is selected.
  • 14: The SAPC calculates the volume quota according to Section 1.9.3. The SAPC calculates the validity time according to TimeQuotaCalculation. The timer is set to the obtained validity time (in this case the expiration date).
  • 15: The SAPC evaluates the applicable controls configured for the PCEF, such as IP Session Access Control, service access control, for the 'extension' subscriber group.
• 16: The CCA message is sent to the PCEF only including the calculated quota in the Usage-Monitoring-Information AVP which contains the total, downlink, and uplink quota mapped directly to the CC-Total-Octets, CC-Input-Octets, and CC-Output-Octets AVPs respectively. The CCA message also contains the new/modified Policy and Charging Control information.
• 17: The SAPC detects that at first day of April a re-evaluation shall be performed since Extension Group stops being active; so the application sets up a timer.
• 18: The first day of April the timer expires, then Extension Group becomes inactive and Normal Group becomes active again for the subscriber, the normal subscription with its limits can be applied again to the subscriber.
• 19: The SAPC forces usage reporting from PCEF as explained in Section 3 Fair Usage Traffic Cases, to accumulate usage data in usage accumulator associated with 'extension' subscriber group.
• 20: RAA including Result-Code is returned by the client.
• 21-25: The SAPC receives a Gx CCR Update message from the PCEF. The CCR Update message contains the volume information for the total traffic or the service through the grouped Usage-Monitoring-Information AVP.
  • 22: The SAPC performs Usage Update function, according to Section 1.9.1. Volume usage is accumulated in usage accumulator associated with 'extension' subscriber group, as well, the time usage is updated in the time usage accumulator associated with 'extension' subscriber group.
  • 23: The SAPC performs Selection of Reporting Groups and Usage Accumulation policies evaluation, according to Section 1.9. Reporting Group associated with 'normal' subscriber group is selected.
  • 24: The SAPC resets the 'normal' usage accumulator since it becomes active again its expiration date has been reached. The SAPC calculates the volume quota of 'normal' usage accumulator according to Section 1.9.3. The SAPC calculates the validity time according to Section 1.9.3. The timer is set to the obtained validity time (in this case the expiration date).
  • 25: The SAPC evaluates the applicable controls configured for the PCEF, such as IP Session Access Control, service access control, for the 'normal' subscriber group.
• 26: The CCA message is sent to the PCEF only including the calculated quota in the Usage-Monitoring-Information AVP which contains the total, downlink, and uplink quota mapped directly to the CC-Total-Octets, CC-Input-Octets, and CC-Output-Octets AVPs respectively. As well the CCA message contains the new/modified Policy and Charging Control information.

3.2.4   Update any subscriber data or subscriber qualification data

In the case Provisioning System updates any subscriber data or subscriber qualification data, the SAPC reauthorizes IP-CAN session of the subscriber and performs Fair Usage Control Procedure according to Section 1.9 (except Usage Update).

The SAPC sends a Gx RAR message to PCEF per affected IP-CAN session for which any Reporting Group is enabled, regardless there is new or modified data for the PCEF, including at least the granted quota information.

3.3   Conditional Accumulation Traffic Cases

3.3.1   Conditional Accumulation with Multiple IP-CAN Sessions

The multiple IP-CAN sessions traffic case consists of a subscriber with a normal post-paid Fair Usage Control subscription that establishes several IP-CAN sessions simultaneously. The SAPC keeps control of the Reporting Groups enabled for each IP-CAN session to update the proper usage accumulator after each usage reporting and to reauthorize the proper IP-CAN sessions when any usage limit is surpassed for a Reporting Group. In next example, a subscriber establishes two IP-CAN sessions towards different APNs (APN1 and APN2). The subscriber belongs to a subscriber group "normal" with a Reporting Group for Total Traffic and the Reporting Group contains conditional volume and time limits for traffic towards APN1. There are configured QoS policies to perform throttling when the limit is reached for Total traffic and for APN1 conditional limit. Moreover, there are policies in the SAPC to re-establish the initial QoS when reset period is reached for the Reporting Group. In the example, policies associated with APN1 conditional limit are applicable only to IP-CAN sessions established towards APN1.

3.3.1.1   Protocol Binding for Rel 9 Gx

• 1-2: IP-CAN session 'S1' is established as in Section 3.1.1. Subscriber group 'normal' is active for the subscriber. Reporting Group Total Traffic is enabled for the IP-CAN session and also the usage accumulator for APN1 because of the IP-CAN session 'S1' is established towards APN1.
• 3-4: IP-CAN session 'S2' is established towards APN2 as in Section 3.1.1. Subscriber group 'normal' is active for the subscriber. Reporting Group Total Traffic is enabled for the IP-CAN session but not the usage accumulator for APN1 because of the IP-CAN session 'S2' is established towards APN2.
• 5-11: The SAPC receives a Gx CCR Update message from the PCEF for IP-CAN session 'S1'. This message contains the Used-Service-Unit AVP with the quota volume consumed for UL, DL, and bidirectional set in Used-Service-Unit AVP and mapped directly to CC-Input-Octets , CC-Output-Octets and CC-Total-Octets AVPS.
  • 6: The SAPC performs Usage Update function, according to Section 1.9.1. Usage is accumulated in usage accumulator associated with Total Traffic and also in usage accumulator for APN1.
  • 7: The SAPC performs Selection of Reporting Groups and Usage Accumulation policies evaluation, according to Section 1.9. Reporting Group associated with 'normal' subscriber group is selected resulting in Total Traffic Reporting Group and APN1 usage accumulator are enabled for this IP-CAN session.
  • 8-9: The SAPC calculates the quota for volume and/or time of Total Traffic usage accumulator according to Section 1.9.3. The quota volume is calculated and set in the Usage-Monitoring-Information AVP which contains the Granted-Service-Unit AVP with Total, UL and DL volume quota indicated in CC-Total-Octets, CC-Input-Octets and CC-Output-Octets AVPs respectively, also the time quota and validity time for 'normal' group usage accumulator is updated by the SAPC and corresponding timer is stored.
  • 10: The SAPC evaluates the applicable policies configured for the subscriber as usage limit associated with APN1 is reached.
  • 11: The Gx CCA message is sent to the PCEF including the information previously computed.

    Note:  

    IP-CAN session 'S2' is reauthorized but as policies are applicable only for IP-CAN sessions in APN1, no RAR message is sent for IP-CAN session S2.

    
    
• 12-18: The SAPC receives a Gx CCR Update message from the PCEF for IP-CAN session 'S2'. This message contains the Used-Service-Unit AVP with the quota volume consumed for UL, DL, and bidirectional set in Used-Service-Unit AVP and mapped directly to CC-Input-Octets , CC-Output-Octets and CC-Total-Octets AVPS.
  • 13: The SAPC performs Usage Update function, according to Section 1.9.1. Usage is accumulated in usage accumulator associated with Total Traffic.
  • 14: The SAPC performs Selection of Reporting Groups and Usage Accumulation policies evaluation, according to Section 1.9. Reporting Group associated with 'normal' subscriber group is selected resulting in Total Traffic Reporting Group enabled for this IP-CAN session.
  • 15-16: The SAPC calculates the quota for volume and/or time of Total Traffic usage accumulator according to Section 1.9.3. The quota volume is calculated and set in the Usage-Monitoring-Information AVP which contains the Granted-Service-Unit AVP with Total, UL and DL volume quota indicated in CC-Total-Octets, CC-Input-Octets and CC-Output-Octets AVPs respectively; a high volume quota is downloaded as the Total volume traffic is reached. Also the time quota and validity time for 'normal' group usage accumulator is updated by the SAPC and corresponding timer is stored.
  • 17: The SAPC evaluates the applicable policies configured for the subscriber as usage limit associated with Total Traffic is reached.
  • 18: The Gx CCA message is sent to the PCEF including the information previously computed.
• 19-21: The SAPC reauthorizes the IP-CAN session 'S1' and performs Fair Usage Control Procedure according to Section 1.9 (except Usage Update): the SAPC sends a Gx RAR message with the information previously computed.
  • 20: RAA including Result-Code is returned by the PCEF.
  • 21: The SAPC recalculates the time quota and validity time according to ValidityTime and obtains the minimum time value among all the active Reporting Groups of the subscriber. The SAPC starts a timer that is set to the minimum value calculated

Next picture shows how the SAPC resets the usage accumulator when its expiry date is reached in case the subscriber has multiple IP-CAN sessions established.

The steps explaining how the IP-CAN sessions are established for the subscriber, are explained in previous figure.

• 1-2: Timers expire in the SAPC because of expiry date of the reporting group is reached.
• 3-4: The SAPC sends a Gx RAR message requesting forced usage reporting to PCEF for IP-CAN session 'S1', to accumulate usage data in usage accumulator associated with Total Traffic. The RAR message contains Usage-Monitoring-Report AVP with value USAGE_MONITORING_REPORT_REQUIRED.
  • 4: RAA including Result-Code is returned by the PCEF.
• 5-6: The SAPC sends a Gx RAR message requesting forced usage reporting to PCEF for IP-CAN session 'S2', to accumulate usage data in usage accumulator associated with Total Traffic. The RAR message contains Usage-Monitoring-Report AVP with value USAGE_MONITORING_REPORT_REQUIRED.
  • 6: RAA including Result-Code is returned by the PCEF.
• 7-14: The SAPC receives a Gx CCR Update message from the PCEF for IP-CAN session 'S2'. This message contains the Used-Service-Unit AVP with the quota volume consumed for UL, DL, and bidirectional set in Used-Service-Unit AVP and mapped directly to CC-Input-Octets , CC-Output-Octets and CC-Total-Octets AVPS.
  • 8: The SAPC performs Usage Update function, according to Section 1.9.1. Usage is accumulated in usage accumulator associated with Total Traffic.
  • 9: The SAPC performs Selection of Reporting Groups and Usage Accumulation policies evaluation, according to Section 1.9. Reporting Group associated with 'normal' subscriber group is selected resulting in Total Traffic Reporting Group is enabled for this IP-CAN session.
  • 10: The SAPC detects that expiration date has been reached for the Reporting Group so usage accumulators are reset.
  • 11-12: The SAPC calculates the quota for volume and/or time of Total Traffic usage accumulator according to Section 1.9.3. The quota volume is calculated and set in the Usage-Monitoring-Information AVP which contains the Granted-Service-Unit AVP with Total, UL and DL volume quota indicated in CC-Total-Octets, CC-Input-Octets and CC-Output-Octets AVPs respectively, also the time quota and validity time for 'normal' group usage accumulator is updated by the SAPC and corresponding timer is stored.
  • 13: The SAPC evaluates the applicable policies configured for the subscriber because of usage accumulators have been reset.
  • 14: The Gx CCA message is sent to the PCEF including the information previously computed.
• 15-21: The SAPC receives a Gx CCR Update message from the PCEF for IP-CAN session 'S1'. This message contains the Used-Service-Unit AVP with the quota volume consumed for UL, DL, and bidirectional set in Used-Service-Unit AVP and mapped directly to CC-Input-Octets , CC-Output-Octets and CC-Total-Octets AVPS.
  • 16: The SAPC does not perform Usage Update because of this report has been received after usage accumulators have been reset because of expiry date reached. This usage reporting belongs to a previous period.
  • 17: The SAPC performs Selection of Reporting Groups and Usage Accumulation policies evaluation, according to Section 1.9. Reporting Group associated with 'normal' subscriber group is selected resulting in Total Traffic Reporting Group and APN1 usage accumulators are enabled for this IP-CAN session.
  • 18-19: The SAPC calculates the quota for volume and/or time of Total Traffic usage accumulator according to Section 1.9.3. The quota volume is calculated and set in the Usage-Monitoring-Information AVP which contains the Granted-Service-Unit AVP with Total, UL and DL volume quota indicated in CC-Total-Octets, CC-Input-Octets and CC-Output-Octets AVPs respectively, also the time quota and validity time for 'normal' group usage accumulator is updated by the SAPC and corresponding timer is stored.
  • 20: The SAPC evaluates the applicable policies because of usage accumulators have been reset.
  • 21: The Gx CCA message is sent to the PCEF including the information previously computed.
• 22-24: The SAPC receives a Gx CCR Terminate message from the PCEF for IP-CAN session 'S1'. This message contains the Used-Service-Unit AVP with the quota volume consumed for UL, DL, and bidirectional set in Used-Service-Unit AVP and mapped directly to CC-Input-Octets , CC-Output-Octets and CC-Total-Octets AVPS.
  • 23: The SAPC performs Usage Update function, according to Section 1.9.1. Usage is accumulated in usage accumulator associated with Total Traffic and also in usage accumulator for APN1.
  • 24: The SAPC sends a CCA message to the PCEF including the Result Code.
• 25-27: The SAPC receives a Gx CCR Terminate message from the PCEF for IP-CAN session 'S2'. This message contains the Used-Service-Unit AVP with the quota volume consumed for UL, DL, and bidirectional set in Used-Service-Unit AVP and mapped directly to CC-Input-Octets , CC-Output-Octets and CC-Total-Octets AVPS.
  • 26: The SAPC performs Usage Update function, according to Section 1.9.1. Usage is accumulated in usage accumulator associated with Total Traffic.
  • 27: The SAPC sends a CCA message to the PCEF including the Result Code.

3.3.2   Accumulation based on time conditions and Bearer QoS change

This chapter shows an example of Bearer QoS change and Accumulation based on time conditions in Rel9 Gx onwards.

The purpose of the use case is two-folded:

• To throttle users during the peak hour.
• To detect heavy users and further throttle them during the peak hour.

The subscriber has an initial speed of 5 Mbps. The operator wants to monitor the volume usage during the peak hour period and simultaneously wants to downgrade the Bearer QoS when the peak hour period starts. During the peak hour, the speed is initially throttled to 1 Mbps, and once the volume limit is reached, to 512 Kbps. Accumulation is reset daily.

For this purpose, the operator defines:

• A policy rule of Bearer QoS based on time (peak hour period) and peak hour use.
• A policy rule of Usage Reporting for the peak hour.

At the start of the peak hour, the SAPC performs the policy evaluation and downgrades the Bearer QoS while providing the usage monitoring information. At the end of peak hour, the SAPC sends a request of usage monitoring information towards the PCEF, when receiving the usage information the SAPC performs the policy evaluation and upgrades the Bearer QoS accordingly.

1. IP-CAN session is established out of the peak hour. The SAPC receives a Gx CCR Initial message from PCEF indicating IP-CAN session establishment.
   • The SAPC performs Selection of Reporting Groups and Usage Accumulation policies evaluation, according to Section 1.9.
   • The SAPC calculates the volume quota for UL, DL, and bidirectional according to Section 1.9.3.
2. The SAPC calculates time quota and validity time according to Section 1.9.3 and obtains the minimum time value among all the active Reporting Groups of the subscriber. The SAPC starts a timer that is set to the minimum value of the validity time among all the active Reporting Groups of the subscriber. In this example, there is only one Reporting Group for the total traffic. The time conditions for accumulation based on time are also taken into account in the calculation of the timer. The obtained validity time is the start of the peak hour.
3. The SAPC performs IP-CAN bearer QoS control, and the information corresponding to the policy evaluation result is included in Gx CCA message. This message contains the QoS-Information AVP with the resulting Policy Control information, DEFAULT 5MBPS.

   Note:  

   When the SAPC performs IP-CAN bearer QoS control, the bearer QoS policy based on time is also evaluated but it must be noticed that the validity for this policy is the start of the peak hour as well so, the SAPC initiates a timer at begin of peak hour as stated in previous step.

   
   
4. The timer expires as the peak hour begins.
5. The SAPC performs Fair Usage Control Procedure according to Section 1.9 (except Usage Update) to start accumulation for the peak hour and reauthorizes the IP-CAN session.
6. The SAPC starts a timer that is set to the minimum value of the validity time among all the active Reporting Groups of the subscriber. Validity time is the end of the peak hour.

   Note:  

   When the SAPC performs IP-CAN bearer QoS control, the bearer QoS policy based on time is also considered but it must be noticed that result in a time trigger to be set by the SAPC at end of peak hour as well so the SAPC initiates a timer at end of peak hour as stated in previous step.

   
   
7. A RAR is sent to the PCEF including the calculated quota in the Usage-Monitoring-Information AVP which contains the total, downlink, and uplink quota mapped directly to the CC-Total-Octets, CC-Input-Octets, and CC-Output-Octets AVPs respectively for the total traffic Reporting Group. The message also contains the QoS-Information AVP with the new/modified Policy Control information. Bearer QoS is downgraded as it corresponds to the peak hour to PEAK_HOUR_NOT_SURPASSED 1MBPS and accumulation is started.
8. RAA including Result-Code is returned by the client.
9. Granted quota within the peak hour is exhausted before the peak hour period ends. The SAPC receives a Gx CCR Update message with the Usage-Monitoring-Information AVP which contains Monitoring-Key AVP =N, Used-Service-Unit AVP with CC-Total-Octets, CC-Input-Octets, and CC-Output-Octets AVPs to indicate Total, UL and DL volume quota consumed respectively.
10. The timer stops because of usage reporting received.
11. At this point:
    • The SAPC performs Volume Usage Update function according to Section 1.9.1 and the consumed traffic in this period is accumulated.
    • The SAPC performs selection of Reporting Groups and Usage Accumulation policies evaluation, according to Section 1.9. In this case, a policy of limit surpassed is evaluated.
    • The SAPC calculates the volume quota for the total traffic.
12. The SAPC starts a timer that is set to the minimum value of the validity time among all the active Reporting Groups of the subscriber. The obtained validity time is the end of the peak hour.

    Note:  

    When the SAPC performs IP-CAN bearer QoS control, the bearer QoS policy based on time is also considered but it must be noticed that result in a time trigger to be set by the SAPC at end of peak hour as well so the SAPC initiates a timer at end of peak hour as stated in previous step.

    
    
13. The CCA message is sent to the PCEF including the calculated quota in the Usage-Monitoring-Information AVP which contains the total, downlink, and uplink quota mapped directly to the CC-Total-Octets, CC-Input-Octets, CC-Output-Octets AVPs respectively for the total traffic Reporting Group. As well the CCA message contains the QoS-Information AVP with the new/modified Policy Control information. The volume limit has been surpassed. The quota value is set to a high value, to continue receiving usage monitoring and accumulate it.

    As the quota has been exceeded, Bearer QoS is downgraded to the limit surpassed values for the peak hour, PEAK_HOUR_SURPASSED 512KBPS.

    Note:  

    When CC-Total-Octets, CC-Input-Octets, and CC-Output-Octets AVPs are not included within Granted-Service-Units AVP or included with zero value, the usage monitoring is stopped. No zero values are sent in the AVPs to continue usage monitoring.

    
    
14. The timer expires as the peak hour period is finished.
15. The SAPC forces usage reporting from PCEF as explained in Section 3 Fair Usage Traffic Cases, to accumulate usage data in usage accumulator of the peak hour.

    The RAR is sent with the Usage-Monitoring-Report AVP set to USAGE_MONITORING_REPORT_REQUIRED for the total traffic Reporting Group.

16. RAA including Result-Code is returned by the client.
17. The SAPC receives a CCR containing the Usage-Monitoring-Information AVP which contains Monitoring-Key AVP =N, Used-Service-Unit AVP with CC-Total-Octets, CC-Input-Octets, CC-Output-Octets AVPs to indicate Total, UL and DL volume quota consumed respectively.
18. At this point:
    • The SAPC performs Volume Usage Update function according to Section 1.9.1 and the consumed traffic in this period is accumulated.
    • The SAPC performs selection of Reporting Groups and Usage Accumulation policies evaluation, according to Section 1.9.
19. The SAPC starts a timer that is set to the minimum value of the validity time among all the active Reporting Groups of the subscriber. The obtained validity time is the daily reset time.
20. The CCA message is sent to the PCEF including the calculated QoS-Information AVP . Bearer QoS is upgraded, DEFAULT 5MBPS, as it corresponds to the non-peak hour. No Usage-Monitoring-Information AVP is sent, as no accumulation is done out of the peak hour.
21. The timer expires as the daily reset period time is reached.
22. The SAPC resets the total traffic usage accumulator. As the usage accumulator has been reset, the SAPC evaluates applicable policies and as there is no modified data to send to the PCEF, no message is sent.
23. The SAPC starts a timer that is set to the minimum value of the validity time among all the active Reporting Groups of the subscriber. The obtained validity time is the begin of the peak hour.

    Note:  

    When the SAPC performs IP-CAN bearer QoS control, the bearer QoS policy based on time is also considered but it must be noticed that result in a time trigger to be set by the SAPC at begin of peak hour as well so the SAPC initiates a timer at begin of peak hour as stated in previous step.

    
    
24. The PCEF sends a CCR terminate before the timer expires.
25. The timer stops because of end of IP-CAN session received.
26. The SAPC answers with a CCA terminate and the IP-CAN session is closed.

3.4   Volume Usage at Reporting Group Level

This chapter shows an example of volume usage for a service type (for example, P2P) with different reset period per established limit. The subscriber has an absolute volume limit for the Reporting Group with a monthly reset period, and also a complementary daily limit. Service type P2P is associated with Monitoring Key=1 (Reporting Group).

3.4.1   Protocol Binding Rel 9 Gx

• 1–3.: IP-CAN session is established as steps described in chapter Section 3.1.1. Only PCC_RULE_LEVEL applies.

  Usage-Monitoring-Level AVP is set to PCC_RULE_LEVEL to indicate that the usage Monitoring Key applies to a Reporting Group.

  Volume quota calculation is performed for the Reporting Group (MK1) belonging to P2P and is sent in the CCA in the Usage-Monitoring-Information AVP which contains the total, downlink, and uplink quota mapped directly to the CC-Total-Octets, CC-Input-Octets, CC-Output-Octets AVPs.

• 4.: The SAPC starts a timer that is set to the minimum value of the validity time among all the active Reporting Groups of the subscriber. In this example, there is only one Reporting Group for P2P (the Monitoring-Key used=1).
• 5.: The SAPC receives a Gx CCR Update message indicating an IP-CAN session modification because of a Fair Usage Control related event through the Event-Trigger AVP set to USAGE_REPORT.

  The SAPC receives the Usage-Monitoring-Information AVP which contains Monitoring-Key AVP =1, Used-Service-Unit AVP with CC-Total-Octets, CC-Input-Octets, CC-Output-Octets AVPs to indicate Total, UL and DL volume quota consumed respectively.

• 6.: At this point:
  • The SAPC performs Volume Usage Update function according to Section 1.9.1, updating absolute (monthly) and daily P2P usage accumulators.
  • The SAPC performs selection of Reporting Groups and Usage Accumulation policies evaluation, according to Section 1.9.
  • The SAPC calculates the volume quota for the Reporting Group belonging to P2P, and initiates a timer with the minimum validity as described in step 4.
• 7.: The CCA message is sent to the PCEF including the calculated quota in the Usage-Monitoring-Information AVP which contains the total, downlink, and uplink quota mapped directly to the CC-Total-Octets, CC-Input-Octets, CC-Output-Octets AVPs respectively for the specific Reporting Group. In addition, the CCA message contains the new/modified Policy and Charging Control information.
• 8-9.: At the end of the reset period for the daily P2P usage accumulator, the timer expires and the SAPC triggers a reauthorization.
• 10.: The SAPC forces usage reporting from PCEF as explained in Section 3 Fair Usage Traffic Cases, to accumulate usage data in usage accumulator associated with P2P subscriber group.

  The RAR is sent with the Usage-Monitoring-Information AVP with the Usage-Monitoring-Report AVP set to USAGE_MONITORING_REPORT_REQUIRED.

• 11.: RAA including Result-Code is returned by the client.
• 12.: The SAPC receives a Gx CCR Update message from the PCEF. The CCR update message contains the Used-Service-Unit AVP with the volume information for total, uplink, and downlink set in Used-Service-Unit AVP through CC-Total-Octets, CC-Input-Octets, and CC-Output-Octets respectively.
• 13–14.: At this point:
  • The SAPC performs Volume Usage Update function according to Section 1.9.1, updating absolute (monthly) and daily P2P usage accumulators.
  • The SAPC performs selection of Reporting Groups and Usage Accumulation policies evaluation, according to Section 1.9. The SAPC resets only the usage accumulator that has expired (in this case, the daily P2P usage accumulator).
  • The SAPC calculates the volume quota for the Reporting Group belonging to P2P.
• 15.: The CCA message is sent to the PCEF including the calculated quota in the Usage-Monitoring-Information AVP which contains the total, downlink, and uplink quota mapped directly to the CC-Total-Octets, CC-Input-Octets, CC-Output-Octets AVPs respectively for the specific Reporting Group. As well the CCA message contains the new/modified Policy and Charging Control information.
• 16–19.: The SAPC starts a timer for the validity time, and the IP session continues as in steps 4–7.
• 20–21.: At the end of the reset period for the Reporting Group, the timer expires and the SAPC triggers a reauthorization.
• 22.: The SAPC forces usage reporting from the PCEF as in step 10.
• 23.: RAA message is received from the PCEF.
• 24.: The SAPC receives a Gx CCR Update message from the PCEF as in step 12.
• 25–26.: At this point:
  • The SAPC performs Volume Usage Update function according to Section 1.9.1.
  • The SAPC performs selection of Reporting Groups and Usage Accumulation policies evaluation, according to Section 1.9. The SAPC resets all usage accumulators in the Reporting Group.
  • The SAPC calculates the volume quota for the Reporting Group belonging to P2P.
• 27.: The CCA message is sent to the PCEF as in step 15. The IP session continues.

3.5   Time Usage Control

3.5.1   Protocol Binding Rel9 Gx onwards

This scenario presents a postpaid subscriber which has time limit for the total traffic (for example 100 hours at 10 MB/second per month). Once the time limit is reached, the MBR is downgraded to 2MB/second and once the expiration date is reached, the original QoS and usage limits are re-established.

1. The PCEF establishes an IP-CAN session as it is explained in Section 3.1.1.
   • The SAPC performs Selection of Reporting Groups and Usage Accumulation policies evaluation, according to Section 1.9.
   • The SAPC calculates time quota and validity time according to Section 1.9.3.
2. The SAPC starts a timer that is set to the minimum value between quota time and validity time among all the active Reporting Groups of the subscriber.
3. The SAPC answers with a CCA indicating the PCC rules, QoS information, and so on.
4. The PCEF sends a CCR update before the timer expires because of SGSN change.
5. The SAPC stops the timer that was initiated.
6. The SAPC performs:
   • The SAPC performs Time Usage Update function adding to the time usage accumulators that are enabled, the current time minus time of last reception of message.
   • The SAPC performs Selection of Reporting Groups and Usage Accumulation policies evaluation, according to Section 1.9.
   • The SAPC recalculates the time quota and validity time according to ValidityTime and obtains the minimum time value among all the active Reporting Groups of the subscriber.
   • The SAPC evaluates operator configured actions such as IP Session Access Control, Service Access Control, Subscriber QoS Control, Charging control and so on.
7. The SAPC updates the timer that is set to the minimum value between quota time and validity time among all the active Reporting Groups of the subscriber.
8. The SAPC sends a CCA with the new policy decisions to apply.
9. The timer expires because time limit is reached (100 hours consumed).
10. The SAPC performs Time Usage Update according to Section 1.9.1. The SAPC evaluates operator configured actions such as IP Session Access Control, Service Access Control, Subscriber QoS Control, Charging control and so on.
11. The SAPC also recalculates the timer with the minimum value between quota time and validity time. In this case, the quota time is 0 and it is not considered for timer calculation, therefore the timer is set to the validity time.
12. The SAPC sends a RAR to the PCEF with the new policy decisions to apply.
13. The PCEF answers with a RAA.
14. The timer expires because the validity time (new month) is reached. The SAPC resets time usage accumulator.
15. The SAPC evaluates operator configured actions such as IP Session Access Control, Service Access Control, Subscriber QoS Control and Charging control.
16. The SAPC performs Selection of Reporting Groups and Usage Accumulation policies evaluation, according to Section 1.9. The SAPC recalculates the time quota and validity time according to ValidityTime and obtains the minimum time value among all the active Reporting Groups of the subscriber. The SAPC starts a timer that is set to the minimum value calculated.
17. The SAPC sends a RAR to the PCEF with the new policy decisions to apply (initial QoS value is restored).
18. The PCEF sends a CCR terminate before timer expires.
19. The SAPC performs Time Usage Update as it is explained at Section 1.9.1. The timer is stopped.
20. The SAPC answers a CCA terminate.

3.6   Multiple Services Offering

3.6.1   Basic Turbo Button Traffic Case Based on Temporary Subscriber Groups

The basic turbo-button traffic case consists of a subscriber with a normal post-paid Fair Usage Control subscription (for example, 2G at 1 Mbps, and then the speed is throttled to 64 Kbps), that orders during a certain time a higher bandwidth with different limits (for example 250 MB at 3 Mbps, from 20:00 to 22:00 the 4th of July). In fact, this is like ordering a high-speed voucher with time limitation.

For this purpose, the subscriber is subscribed to two subscriber groups. One called normal, containing the basic post-paid subscription, and another one called turbo including the turbo-button characteristics (turbo group has the highest priority and it is temporarily subscribed from 2014-07-04 20:00 to 2014-07-04 22:00 p.m. Each subscriber group has configured the QoS policies to perform throttling when the limit is reached.

The SAPC initiates a reauthorization towards PCEF when a subscriber group becomes active and another reauthorization when the subscriber groups become inactive.

3.6.1.1   Protocol Binding for Rel9 Gx onwards

• 1–2: IP-CAN session is established as chapter Section 3.1.1. Subscriber group 'normal' is active for the subscriber.
• 3: The SAPC detects that at 20:00 Turbo Group can become active for a period. The SAPC also determines the validity time among all the active Reporting Groups of the subscriber. In this case, the Turbo Group starts before the validity time is reached, the SAPC starts a timer that is expires when the Turbo Group is active.
• 4: At 20:00, the timer expires and Turbo Group becomes active.
• 5: The SAPC sends a Gx RAR message requesting forced usage reporting to the PCEF, to accumulate usage data in usage accumulator associated with 'normal' subscriber group. The RAR message contains the Usage-Monitoring-Report AVP with value USAGE_MONITORING_REPORT_REQUIRED.
• 6: RAA including Result-Code is returned by the client.
• 7-11: The SAPC receives a Gx CCR Update message from the PCEF.
  • This message contains the Usage-Monitoring-Information AVP with the Used-Service-Unit AVP which contains the Total, uplink and downlink volume quota consumed indicated in CC-Total-Octets, CC-Input-Octets, CC-Output-Octets AVPs respectively.
  
  
  • 8: The SAPC performs Usage Update function, according to Section 1.9.1. Usage volume is accumulated in usage accumulator associated with 'normal' subscriber group.
  • 9: The SAPC performs Selection of Reporting Groups and Usage Accumulation policies evaluation, according to Section 1.9. Reporting Group associated with 'turbo' subscriber group is selected.
  • 10: The SAPC calculates the quota for volume and/or time of 'turbo' usage accumulator according to Section 1.9.3. The calculated volume quota for UL, DL, and bidirectional quota is set in the Granted-Service-Unit AVP through CC-Input-Octets, CC-Output-Octets, and CC-Total-Octets AVPs.
  • 11: The SAPC evaluates the applicable controls configured for the PCEF, such as IP Session Access Control, service access control, and so on applicable to 'turbo' subscriber group.
• 12: The CCA message is sent to the PCEF only including the new/modified Policy and Charging Control information and the applicable volume quota calculated previously.
• 13: The SAPC detects that at 22:00 a re-evaluation shall be performed since Turbo Group stops being active; the SAPC also determines the minimum value between the validity time among all the active Reporting Groups of the subscriber. In this case, the Turbo Group stops being active before the validity time is reached, the SAPC starts a timer that is expires when the Turbo Group stops being active.
• 14: At 22:00 the timer expires, then Turbo Group becomes inactive and Normal Group becomes active again for the subscriber. The SAPC updates the accumulated time as is indicated in previous step Section 1.9.1 for the usage accumulator associated with 'turbo' group.
• 15: The SAPC sends a Gx RAR message requesting forced usage reporting to PCEF, to accumulate usage data in usage accumulator associated with 'turbo' subscriber group.
  • The RAR message contains Usage-Monitoring-Report AVP with value USAGE_MONITORING_REPORT_REQUIRED.
• 16: RAA including Result-Code is returned by the client.
• 17-21: The SAPC receives a Gx CCR Update message from the PCEF. This message contains the Used-Service-Unit AVP with the quota volume consumed for UL, DL, and bidirectional set in Used-Service-Unit AVP and mapped directly to CC-Input-Octets , CC-Output-Octets and CC-Total-Octets AVPS.
  • 18: The SAPC performs Usage Update function, according to Section 1.9.1. Usage is accumulated in usage accumulator associated with 'turbo' subscriber group.
  • 19: The SAPC performs Selection of Reporting Groups and Usage Accumulation policies evaluation, according to Section 1.9. Reporting Group associated with 'normal' subscriber group is selected.
  • 20: The SAPC calculates the quota for volume and/or time of 'normal' usage accumulator according to Section 1.9.3. The quota volume is calculated and set in the Usage-Monitoring-Information AVP which contains the Granted-Service-Unit AVP with Total, UL and DL volume quota indicated in CC-Total-Octets, CC-Input-Octets and CC-Output-Octets AVPs respectively, also the validity time for 'normal' group usage accumulator is updated by the SAPC and corresponding timer is stored.
  • 21: The SAPC evaluates the applicable controls configured for the PCEF, such as IP Session Access Control, service access control, and so on applicable to 'normal' subscriber group. The SAPC also calculates a timer that is set to the minimum validity time among all the active Reporting Groups of the subscriber.
• 22: The CCA message is sent to the PCEF only including the new/modified Policy and Charging Control information.

3.6.2   Advanced Turbo Button Traffic Case with Dynamic Group Selection Based on Usage Conditions

This advanced turbo button traffic case shows how the SAPC dynamically selects a subscriber group depending on its usage conditions, only until there is no remaining quota to be used.

In this traffic case it is considered a subscriber that is statically associated with two subscriber groups:

• General group, priority 1, from start-date 2012-03-01 to end-date 2013-03-01.
• Advanced group, priority 0, from start-date 2012-04-01 to end-date 2012-05-01.

  Priority 0 means higher priority than 1.

Also, Dynamic Group Selection policies are defined for Advanced group, at Global level (for any subscriber), to select it only if there is remaining quota.

1. The SAPC receives a Gx CCR-initial message from PCEF indicating IP-CAN session establishment after 2012-04-01 and before 2012-05-01.

   The SAPC looks for the subscriber and subscriber group data. Since it is between 2012-04-01 and 2012-05-01 and there is available remaining quota for Advanced group, both General and Advanced groups are selected as active subscriber groups.

2. The SAPC authorizes the IP-CAN session; the SAPC evaluates the applicable controls configured for the PCEF, such as IP-CAN Session Access Control, service access control, applicable to both General and Advanced groups. Advanced group is selected whenever conflicts arise between Fair Usage Profiles as it has higher priority. Therefore, quota for the Reporting Group associated with Advanced group is considered.
3. The information obtained in the previous steps is included in the CCA answer message.
4. When the quota downloaded by the SAPC for Advanced is reached, the SAPC receives a Gx CCR-Update message from PCEF indicating the Quota has been exhausted.
5. The SAPC updates usage for Advanced group-related accumulators.
6. The SAPC looks for the subscriber and subscriber group data. Dynamic Group Selection policies defined for Advanced group are also evaluated. As there is no remaining quota for Advanced, General group is selected as active subscriber group.
7. The SAPC authorizes the IP-CAN session; the SAPC evaluates the applicable controls configured for the PCEF, such as IP-CAN Session Access Control, service access control, applicable to General group. Quota for the Reporting Group associated with General group is considered.
8. The information obtained in the previous steps is included in the CCA answer message.

3.6.3   Multiple Packages Traffic Case

This chapter shows an example of Multiple Packages offering, using static access policies.

The user has a basic package with services Chat and Facebook. The Provisioning system informs the SAPC that an advanced package with service Chat has been added to the subscriber, with a higher volume limit. The user is subscribed to this advanced package for Chat, that has more priority than the Basic Package, until the provided volume is consumed. Once the volume limit is surpassed, the user accumulation applies back to the basic package for both Chat and Facebook again.

Initially the volume usage for both services is controlled using Monitoring-Key 1. Monitoring-Key 1 (MK1) is defined in the SAPC with volume limit "X" Megabytes. The SAPC provides a static PCC rule for Chat, PCC Rule Chat Basic, a static PCC rule for FaceBook, PCC Rule FaceBookBasic, and a Monitoring-Key for them, MK1. PCEF does the mapping of MK1 to PCC rule Chat Basic and PCC rule Facebook.

Chat service is associated afterwards in the SAPC to the static PCCRule_ChatAdvanced when the Advanced Package for Chat is provisioned. Monitoring-Key 2 (MK2) is defined in the SAPC with volume limit "Y" Megabytes. MK2 is mapped to control PCCRule_ChatAdvanced in the PCEF.

When both MK1 and MK2 are active, PCCRule_FaceBookBasic and PCCRule_ChatAdvanced are applied. PCCRule_ChatAdvanced has more priority than PCCRule_ChatBasic, so PCCRule_ChatBasic is removed from the PCEF until the provided volume for MK2 is reached. Once the Advanced Package limit is finished, PCCRule_ChatBasic is restored. Static access policies are used for this purpose.

1. IP-CAN session is established as steps described in chapter Section 3.1.1.

   Usage-Monitoring-Level AVP is used to monitoring control level. It takes the value PCC_RULE_LEVEL to indicate that the usage Monitoring Key applies to a Reporting Group.

2. 2. The Gx CCA message is sent to the PCEF including the QoS-information previously computed. This message contains the following AVPs among others:
   • Charging-Rule-Install includes PCCRule ChatBasic and PCCRule_FacebookBasic.
   • Usage-Monitoring-Information AVP is a grouped AVP which contains the AVPs explained next:
     • Granted-Service-Unit AVP is used to send the volume quota calculated in the previous step. This AVP maps the available volume for UL, DL, or bidirectional directly to the AVPs CC-Total-Octets, CC-Input-Octets and CC-Output-Octets AVP respectively.
     • Usage-Monitoring-Level AVP takes the value PCC_RULE_LEVEL to indicate that the usage Monitoring Key applies to a Reporting Group.
     • Monitoring-Key AVP is the identifier of the Reporting Group, MK1.
   • Event-Trigger AVP set to USAGE_REPORT to activate usage monitoring at the PCEF.
3. The SAPC starts a timer that is set to the minimum value of the validity time among all the active Reporting Groups of the subscriber. In this example, there is only one Reporting Group for both ChatBasic and FacebookBasic (MK1). As the subscriber uses both Chat and Facebook, the traffic corresponding to these services is counted by the PCEF in the usage accumulator for MK1.
4. The provisioning system informs the SAPC that an Advanced Chat package has been added to the subscriber.

   The user is subscribed to an Advanced Package for Chat that has more priority than the Basic Package. Chat service is associated in the SAPC to the static PCCRule_ChatAdvanced in this Advanced Package for Chat. The Monitoring-Key 2 (MK2) is defined in the SAPC with volume limit "Y" Megabytes. MK2 is mapped to PCCRule_ChatAdvanced in the PCEF.

5. The timer stops.
6. The SAPC evaluates the applicable policies.
7. The SAPC calculates the new quota applicable and validity time according to ValidityTime and obtains the minimum time value among all the active Reporting Groups of the subscriber.
8. The SAPC sends a RAR to remove the PCCRule_ChatBasic (Charging-Rule-Remove (PCC ChatBasic)) and activate the temporary alternative, PCCRule_ChatAdvanced (Charging-Rule-Install (PCC ChatAdvanced)). Usage-Monitoring-Information AVP is sent for MK1 and MK2.
9. Timer is started with the minimum value of the validity time.
10. RAA including Result-Code is returned by the PCEF.

    At this step, both Monitoring-Keys are active in the PCEF. MK1 is mapped to PCCRule_FaceBookBasic and MK2 to PCCRule_ChatAdvanced. The subscriber uses both Chat and Facebook. The traffic corresponding to Facebook is counted by the PCEF in the usage accumulator for MK1 and the traffic corresponding to Chat is counted by the PCEF in the usage accumulator for MK2.

11. PCEF detects that the quota for MK2 is empty and triggers reporting of usage for MK2.
12. The SAPC receives a Gx CCR Update message from the PCEF. It contains the Used-Service-Unit AVP with the time and/or usage information for the traffic in MK2.
13. The SAPC updates the usage information related to MK2.
14. The SAPC evaluates the applicable policies for MK2. As usage limit has been surpassed, the SAPC de-authorizes the service and removes the PCCrule_ChatAdvanced.
15. An updated quota is calculated by the SAPC.
16. The CCA message is sent to the PCEF including the new/modified Policy and Charging Control information, related to MK1 Reporting Group limits. PCCRule_ChatAdvanced is removed (Charging-Rule-Remove PCCRule_ChatAdvanced) and PCCRule_ChatBasic is installed (Charging-Rule-Install).

    Note:  

    The SAPC sends a very high value of quota when the limit is reached for MK2 in order not to disable the usage monitoring in the PCEF. This is because if usage monitoring is disabled is not possible later to obtain usage monitoring information by sending a RAR with the USAGE_MONITORING_REQUIRED.

    
    

3.7   Shared Subscriber Plans

3.7.1   Prepaid and Postpaid Shared Subscriber Plans

This chapter shows an example of Shared Subscriber Plans where all members of a family have a shared Total volume limit of 2 GB to be consumed per month (Postpaid shared dataplan).

Also, an advanced package has been added to the shared dataplan with an extra shared Total volume limit of 1 GB to be used during one week (Prepaid shared dataplan). The Prepaid shared dataplan is assigned with higher priority and can be applied whenever it has not expired and there is remaining quota for it.

Once any of these conditions is not fulfilled, the Postpaid shared dataplan is applied.

For this purpose, the subscribers sharing these data plans are defined as members of "Smith family" shared dataplan (see Section 1.2.4). Smith shared dataplan (and implicitly all its members) is subscribed to two subscriber groups:

• Postpaid group, with a monthly reset period, Total volume limit of 2 GB and a slice volume of 100 MB, at 1 Mbps.
• Prepaid group, with higher priority, a reset period of one week, a Total volume limit of 1 GB and a slice volume of 200 MB, at 3 Mbps.

Dynamic Group Selection policies are defined for Prepaid group, at Global level (for any subscriber), to select it only if it is not expired and there is remaining quota.

Note:  

The refill of a Prepaid shared dataplan is performed modifying the start date of the corresponding subscriber group.

• 1–7: IP-CAN session is established as steps described in chapter Section 3.1.1.
  • A CCR Initial message is received for Smith family member MSISDN1 during the week when both Postpaid and Prepaid Shared Subscriber Plans are applicable.
  • Postpaid group is selected as active. Prepaid Group is also dynamically selected as active because it is not expired and there is remaining quota for it. Therefore, when both Postpaid and Prepaid Groups are active, the one with more priority is considered to select the applicable Reporting Group (Prepaid group with 1 GB of quota limit and 200 MB of slice).
  • 200 MB slice is considered as minimum quota to be downloaded to the PCEF. The SAPC also calculates the validity time, initiating internally a timer to control the expiration date for Prepaid Group (valid for one week).
  • The SAPC evaluates the rest of policies (bearer QoS...) to select the information to be downloaded to the PCEF. 3 Mbps is selected as applicable QoS.
  • The Gx CCA message is sent to the PCEF including, among others, the following AVPs:
    • Usage-Monitoring-Information with the Granted-Service-Unit and Usage-Monitoring-Level with SESSION_LEVEL to indicate that it is referring to Total traffic.
    • Event-Trigger AVP set to USAGE_REPORT to activate usage monitoring at the PCEF.
    • QoS information.
• 8: IP-CAN sessions are also established for Smith family members MSISDN2 and MSISDN3 as described in steps 1–7.
• 9- 15: The SAPC receives a Gx CCR Update message from the PCEF for MSISDN2 containing the Used-Service-Unit AVP with the usage information for the total traffic because the slice of 200 MB has been consumed.
  • 200 MB used quota is accumulated.
  • Postpaid group is selected as active. Prepaid Group is also dynamically selected as active because it is not expired and there is remaining quota for it. Therefore, when both Postpaid and Prepaid Groups are active, the one with more priority is considered to select the applicable Reporting Group (Prepaid group with 1 GB of quota limit and 200 MB of slice).
  • 200 MB slice is considered again as minimum quota to be downloaded to the PCEF.
  • The SAPC evaluates the rest of policies (bearer QoS...) to select the information to be downloaded to the PCEF. 3 Mbps is selected as applicable QoS.
  • The Gx CCA message is sent to the PCEF including, among others, the Usage-Monitoring-Information with the new Granted-Service-Unit.
• 16: The SAPC receives a Gx CCR Update message from the PCEF for MSISDN3, MSISDN1, and MSISDN2 containing the Used-Service-Unit AVP with the usage information for the total traffic when the slice of 200 MB has been consumed respectively. These messages are handled as described in steps 9–15.
• 17–23: The SAPC receives a Gx CCR Update message from the PCEF for MSISDN3 containing the Used-Service-Unit AVP with the usage information for the total traffic because the slice of 200 MB has been consumed.
  • 200 MB used quota is accumulated.
  • Although being not expired, Prepaid Group is not dynamically selected as active because there is no remaining quota for it. The Postpaid Group is considered to select the applicable Reporting Group (2 GB of quota limit and 100 MB of slice).
  • 100 MB slice is considered again as minimum quota to be downloaded to the PCEF.
  • The SAPC evaluates the rest of policies (bearer QoS...) to select the information to be downloaded to the PCEF. 1 Mbps is selected as applicable QoS.
  • The Gx CCA message is sent to the PCEF including, among others, the Usage-Monitoring-Information with the new Granted-Service-Unit and the QoS information.

Note:  

For MSISND1 and MSISDN2, Postpaid Group related quota and characteristics are applied when the corresponding CCR-U request messages are received.

3.7.2   Combination of individual and shared dataplan for a subscriber

This chapter shows an example for combination of Individual and shared dataplan where all members of a family have a shared Total volume limit of 1 GB to be consumed per month and, also, one of the subscribers has an Individual subscriber plan for YouTube traffic with a limit of 500 MB per month.

The Individual subscriber plan for YouTube is only applied to that subscriber when the limit for the shared dataplan has been surpassed.

Also, the members of the family shared dataplan categorized as children have a specific category limit, that is, a sub limit within the shared dataplan of 500 MB of Total volume per month

For this purpose, the subscribers sharing the dataplan (MSISDN1, MSISDN2, and MSISDN3) are defined as "family Smith" shared dataplan members. Some of the members (MSISDN2 and MSISDN3) are categorized as children.

• Smith family (and implicitly all its members) is subscribed to a Shared group, with a monthly reset period, Total volume limit of 1 GB and a slice volume of 250 MB. There is an extra Total volume limit of 500 MB not to be surpassed for the children of Smith family.
• One of the family members, MSISDN1 subscriber, is subscribed to a YouTube group, with a monthly reset period, YouTube volume limit of 500 MB.

Dynamic Group Selection policies are defined at subscriber level (only for the subscriber with the Individual subscriber plan) to select:

• Shared group if the shared limit for Total traffic has not been surpassed.
• YouTube group for YouTube traffic only if the limit for the shared dataplan has been surpassed.

Specific policy decisions to be applied to the subscribers belonging to the same category or to the same shared dataplan, that is, sharing a limit (among others, disabling the accumulation, Bearer QoS downgrade, Bearer Access Control) can be taken based on surpassing that limit.

• 1–6: IP-CAN session is established as steps described in chapter Section 3.1.1.
  • A CCR Initial message is received for Smith family member MSISDN1 when both Individual and Shared Subscriber Plans are applicable.
  • Both YouTube (for YouTube traffic) and Shared (for Total traffic) Groups are statically subscribed to MSISDN1 but only the Shared Group is selected according to the defined Dynamic Group Selection policies for that specific subscriber, which states that the YouTube Group is selected whenever the Shared limit for Total traffic has been surpassed.

    MSISDN1 is not categorized as children and therefore, 1 GB of quota limit and 250 MB of slice are considered.

  • 250 MB slice is considered as minimum quota to be downloaded to the PCEF. The SAPC also calculates the validity time, initiating internally a timer to control the expiration date for the applicable Group (monthly periodicity).
  • The SAPC evaluates the rest of policies (bearer QoS...) to select the information to be downloaded to the PCEF.
  • The Gx CCA message is sent to the PCEF including, among others, the following AVPs:
    • Usage-Monitoring-Information with the Granted-Service-Unit and Usage-Monitoring-Level with SESSION_LEVEL to indicate that it is referring to Total traffic.
    • Event-Trigger AVP set to USAGE_REPORT to activate usage monitoring at the PCEF.
• 7–12: IP-CAN session are established as steps described in chapter Section 3.1.1 for MSISDN2 and MSISDN3.
  • A CCR Initial message is received for Smith family member MSISDN2 and MSISDN3.
  • Only Shared (for Total traffic) Group is statically subscribed to MSISDN2 and MSISDN3.

    As the subscriber is categorized as children, the corresponding category limit is also applied and the shared limit. 1 GB of shared quota limit, 500 MB of children quota limit and 250 MB of slice are considered.

  • 250 MB slice is considered as minimum quota to be downloaded to the PCEF. The SAPC also calculates the validity time, initiating internally a timer to control the expiration date for the applicable Group (monthly periodicity).
  • The SAPC evaluates the rest of policies (bearer QoS...) to select the information to be downloaded to the PCEF.
  • The Gx CCA message is sent to the PCEF including, among others, the following AVPs:
    • Usage-Monitoring-Information with the Granted-Service-Unit and Usage-Monitoring-Level with SESSION_LEVEL to indicate that it is referring to Total traffic.
    • Event-Trigger AVP set to USAGE_REPORT to activate usage monitoring at the PCEF.
• 13: The SAPC receives a Gx CCR Update message from the PCEF for MSISDN2 containing the Used-Service-Unit AVP with the usage information for the total traffic when the slice of 250 MB has been consumed. The received 250 MB used quota is accumulated and the selection of active groups, corresponding Reporting Group, and quota calculation is described in steps 8–12.
• 14–20: The SAPC receives a Gx CCR Update message from the PCEF for MSISDN3 containing the Used-Service-Unit AVP with the usage information for the total traffic because the slice of 250 MB has been consumed.
  • 250 MB used quota is accumulated.
  • The children category limit has been reached and although the Shared Group is considered active, specific accumulation policies could have been defined to disable the whole Reporting Group when a subscriber categorized as children reaches the corresponding category limit.
  • As the Reporting Group is disabled because of accumulation policies, the SAPC considers there is no quota to be downloaded to the PCEF.
  • The SAPC evaluates the rest of policies (bearer QoS...) to select the information to be downloaded to the PCEF (that is, Bearer QoS to be downloaded) or to take the corresponding action (that is, release the session because of Bearer Access Control policies).
  • The Gx CCA message is sent to the PCEF. In this case, no granted quota is downloaded.
• 21: The SAPC receives a Gx CCR Update message from the PCEF for MSISDN1 containing the Used-Service-Unit AVP with the usage information for the total traffic when the slice of 250 MB has been consumed. The received 250 MB used quota is accumulated and the selection of active groups, corresponding Reporting Group, and quota calculation is described in steps 2–7.
• 22–28: The SAPC receives a Gx CCR Update message from the PCEF for MSISDN1 containing the Used-Service-Unit AVP with the usage information for the total traffic because the slice of 250 MB has been consumed.
  • 250 MB used quota is accumulated.
  • Both YouTube (for YouTube traffic) and Shared (for Total traffic) Groups are statically subscribed to MSISDN1 but now, the YouTube Group is selected according to the defined Dynamic Group Selection policies for that specific subscriber, which states that the YouTube Group is selected if the Shared limit for Total traffic has been surpassed.
  • 500 MB for YouTube traffic is considered as minimum quota to be downloaded to the PCEF.
  • The SAPC evaluates the rest of policies (bearer QoS...) to select the information to be downloaded to the PCEF (that is, Bearer QoS to be downloaded) or to take the corresponding action (that is, release the session because of Bearer Access Control policies).
  • The Gx CCA message is sent to the PCEF including, among others, the following AVPs:
    • Usage-Monitoring-Information with the Granted-Service-Unit and Usage-Monitoring-Level with PCC_RULE_LEVEL to indicate that it is referring to YouTube traffic.
    • Event-Trigger AVP set to USAGE_REPORT to activate usage monitoring at the PCEF.

Note:  

For MSISDN2, the behavior when the corresponding CCR-U is received is the described in steps 14–20.

3.8   Shared Devices Plans

3.8.1   Multi-SIM Data Plan with Shared Limit

The subscriber has a volume limit for the total traffic generated from all devices during a given period. Usage from all devices is accumulated in the same usage accumulator. When the shared limit is reached, the maximum bandwidth is throttled to 64 Kbps for all devices.

3.8.1.1   Protocol Binding for Rel9 Gx onwards

• 1–2: IP-CAN session 'S1' is established from one device as in Section 3.1.1. The SAPC finds the subscriber identifier that maps to the traffic identity received in the request (IMSI_1), and initiates fair usage control.
• 3-4: IP-CAN session 'S2' is established from another device as in Section 3.1.1. From the mapping of traffic identities (IMSI_2) to subscriber identifier, the SAPC knows that this IP-CAN session is from the same subscription as IP-CAN session 'S1'. Hence, fair usage control uses the same volume limits and common usage accumulators.
• 5-11: The SAPC receives a Gx CCR Update message from the PCEF for IP-CAN session 'S1'. This message contains the Used-Service-Unit AVP with the quota volume consumed.
  • 6: The SAPC performs Usage Update function, according to Section 1.9.1. Usage is accumulated in the usage accumulator associated with Total Traffic for the subscriber.
  • 7: The SAPC evaluates Usage Accumulation policies evaluation, according to Section 1.9.
  • 8-9: The SAPC calculates the quota for volume of Total Traffic usage accumulator according to Section 1.9.3.
  • 10: The SAPC detects that the usage limit associated with Total Traffic has been reached, and evaluates the applicable policies configured for the subscriber.
  • 11: The Gx CCA message is sent to the PCEF including the new QoS information.
• 12-13: The SAPC reauthorizes the IP-CAN session 'S2' and performs Fair Usage Control Procedure according to Section 1.9 (except Usage Update).
  • 12: The SAPC sends a Gx RAR message with the new QoS information previously computed.
  • 13: RAA message including Result-Code is returned by the PCEF.

3.8.2   Multi-SIM Data Plan with Device Limits

The subscriber has several devices that share data plan but have different volume limits for the total traffic consumed from each device. When the usage limit for a given device is reached, the maximum bandwidth for this device is throttled to 64 Kbps, but there is no impact to the bandwidth allocated to the other devices. Different volume limits from each device can be configured using conditional accumulation policies based on IMEI.

3.8.2.1   Protocol Binding for Rel9 Gx onwards

• 1–2: IP-CAN session 'S1' is established from device IMEI_1 as in Section 3.1.1. The SAPC finds the subscriber identifier that maps to the traffic identity received in the request (IMSI_1). The SAPC, according to the subscriber profile, evaluates the accumulation policies to find out which usage accumulator can be used when the first usage reporting arrives. In this case, the SAPC selects the usage accumulator for IMEI_1 based on the information received in the CCR-initial message.
• 3-4: IP-CAN session 'S2' is established from device IMEI_2 as in Section 3.1.1. From the mapping of traffic identities (IMSI_2) to subscriber identifier, the SAPC knows that this IP-CAN session is from the same subscription as IP-CAN session 'S1'. The SAPC evaluates the accumulation policies and selects the usage accumulator for IMEI_2.
• 5-11: The SAPC receives a Gx CCR Update message from the PCEF for IP-CAN session 'S1'. This message contains the Used-Service-Unit AVP with the quota volume consumed.
  • 6: The SAPC performs Usage Update function, according to Section 1.9.1. Usage is accumulated in the usage accumulator for IMEI_1.
  • 7: The SAPC evaluates Usage Accumulation policies evaluation, according to Section 1.9.
  • 8-9: The SAPC calculates the quota for volume of Total Traffic usage accumulator according to Section 1.9.3.
  • 10: The SAPC detects that the usage limit for IMEI_1 has been reached, and evaluates the applicable policies.
  • 11: The Gx CCA message is sent to the PCEF including the new QoS information.
• 12-14: The SAPC receives a Gx CCR Update message from the PCEF for IP-CAN session 'S2'. This message contains the Used-Service-Unit AVP with the quota volume consumed. The SAPC performs fair usage control procedure according to Section 1.9.

3.9   Interaction with External Database

The following chapters show the messages exchanged when the usage accumulators and/or Fair Usage Profile are stored in an external database. The detailed description of the steps describing fair usage functionality is the same as in Section 3.1.

3.9.1   Fair Usage Profile in External Database, Usage Accumulator in the SAPC Internal Database

The following sequence diagram shows the messages exchanged when the Fair Usage Profiles are stored in an external database, meanwhile usage accumulators are stored in the SAPC internal database:

The number of accesses to get subscriber data to the external database depends on how entity data sources are configured and the external database data model.

3.9.2   Subscriber Information and Usage Accumulator in External Database

The following sequence diagram shows the messages exchanged when the subscriber data and usage accumulators are stored in an external database:

The number of accesses to the external database depends on how entity data sources are configured and the external database data model.

At Gx CCR Initial message reception, the SAPC initializes in the external database the usage accumulator (for example, validity time).