Access and Charging Control (Gx)
Ericsson Service-Aware Policy Controller

Contents

1Access and Charging Control Introduction

2
Access and Charging Control Function
2.1IP-CAN session Access Control
2.2Service Access Control
2.2.1Selection of Rule Space (Ericsson Added Value)
2.2.2Service Selection
2.2.3Service Authorization
2.2.3.1Service Authorization Policies without Time of Day Conditions or with Time of Day Conditions where PCRF controls time
2.2.3.2Service Authorization Policies with Time of Day Conditions where the PCEF controls time
2.2.3.3One Time Redirect Control
2.2.4Static Services Qualification
2.2.4.1Static Service Qualification Policies with Time of Day Conditions
2.2.5Service Authorization and Static Service Qualification Policies with Time of Day Conditions where the PCEF controls time
2.2.6Notification of Errors in the Installation of Services
2.3Service Charging Control
2.3.1Charging Control for Static Services with the PCEF
2.3.2Charging Control for Preconfigured Services with the PCEF
2.4Subscriber Charging Control
2.5Content Filtering
2.6Event Triggers
2.7Multiple Gx Support
2.8Presence Reporting Area
2.9Diameter Race Condition Handling
2.9.1Handling of Concurrent Gx RAR and CCR messages
2.9.2Handling of Concurrent SAPC-initiated Reauthorizations

3
Access and Charging Control Network Deployments

4
Access and Charging Control Traffic Cases
4.1IP-CAN session Lifetime
4.1.1Protocol Binding for Rel9 Gx/Gx+ onwards
4.2Redirect Owing to non-authorized Static Service
4.3One Time Redirect for Authorized Static Services
4.4Service Authorization and Static Service Qualification Policies with Time of Day Conditions When the PCEF is Selected As Time Controller
4.4.1Time of Day Conditions Applied Only to Service Authorization Policies
4.4.2Time of Day Conditions Applied to Service Authorization and Static Service Qualification Policies
4.5Presence Reporting Area
4.6PCC Rule Error Handling
4.6.1Protocol Binding for Rel9 Gx/Gx+ onwards Notification of Error in the Installation of PCC rules
4.7Diameter Race Condition Handling
4.8Extended Event-Trigger for Tethering Detection Reporting over Gx
4.9Access and Charging Control Error Handling

Reference List

1   Access and Charging Control Introduction

This document describes the Access and Charging Control function provided by the SAPC when Gx interface is used.

2   Access and Charging Control Function

This function enables the SAPC to provide differentiated Access and Charging control per subscriber and service basis.

The services that the SAPC can handle through this function are the ones that can be identified through predefined filters statically defined either in the PCEF or in the SAPC. That is, services that do not require dynamic session negotiation. These last services require Dynamic PCC rules support in the SAPC, and they are described in Dynamic Policy Control (Rx).

Access and Charging control is performed handling PCC rules. A PCC rule is a set of information including:

This function uses two different types of PCC rules:

This function does not handle any QoS information as part of PCC rules. Refer to Bearer QoS and Bandwidth Management for a further description of QoS information handling performed by the SAPC.

Figure 1   Static and Preconfigured PCC rule Data

The SAPC supports IP address overlapping scenarios:

This function provides Ericsson proprietary enhancements to the standard 3GPP PCC Access and Charging control function, it includes, among others, rule Space management, IP-CAN session authorization, content filtering, and so on.

The function is supported in the following network scenarios:

2.1   IP-CAN session Access Control

IP-CAN session Access Control is used to allow or reject IP-CAN session operations and allows the possibility to request the termination of the IP-CAN session.

The SAPC decides if the IP-CAN session is authorized or rejected evaluating IP-CAN Session Access Control policies, these policies can take into account subscriber information, dynamic conditions and context information received (for example SGSN IP address, RAT, charging characteristics).

IP-CAN Session Access Control policies are evaluated according to the following precedence allocation and applying permit overrides algorithm among them (that is, if any policy evaluates to true, the IP-CAN session is authorized):

  1. Subject policy locator
  2. Subject group policy locator. All the active subscriber groups are considered.

    Therefore configure Dynamic Group Selection policies to evaluate only the desired subscriber group policies.

  3. Global policy locator.

In case there are conflicts among the rules within a policy, the result for the policy depends on the Rule combining algorithm configured. Refer to Solving Policies Conflicts section in Subscription and Policy Management.

By default IP-CAN sessions are authorized, therefore in case there are no IP-CAN Session Access Control policies configured or the IP-CAN Session Access Control is not configured for the requesting PCEF, the IP-CAN session is authorized.

IP-CAN session Access Control is performed at:

2.2   Service Access Control

Service Access Control determines the services that are authorized to run on a particular IP-CAN session.

Service Access Control decisions are based on policies (conditions) that can take into account the subscriber profile, time of day and network information received in the message. In addition, these policies can take into account usage information such as if the subscriber has surpassed the provisioned usage limit. For more information about policy management, refer to Subscription and Policy Management.

Service Access Control can purely follow 3GPP specifications, but can also be augmented with Ericsson Value Added function, depending on the information received from the PCEF about the support of each proprietary capability. Therefore, when working with the Ericsson Added Value function, there are some differences compared to the standard solution that are remarked in the corresponding section as “Ericsson Added Value”.

Service Access Control is performed at:

If the control is disabled for the requesting PCEF, the SAPC does not authorize any service for the subscriber.

Procedure to Determine the Authorized Services

The following procedure is used to determine the authorized services:

2.2.1   Selection of Rule Space (Ericsson Added Value)

A Rule Space can be configured in the PCEF and it defines a set of local data for the subscriber, such as the set of static PCC rules that might be potentially assigned to the subscriber and certain local profiles, such as QoS profile, content filtering profile, which Bandwidth Limitation or Rating Group to apply to each service, and so on. These local profiles associated to the rule space are used by the PCEF when the SAPC does not return these profile data.

The operator may define different Rule Spaces but only one can be active. Once the Rule Space has been selected by the SAPC at IP session setup, it cannot be modified during IP session lifetime.

The selection of the applicable Rule Space is done in the following way:

Static services can be grouped into Rule Spaces. Once the SAPC determines the applicable rule space, only the static services belonging to the selected rule space are considered in the following steps.

2.2.2   Service Selection

The services selected (static and preconfigured) are the final result of the following steps:

The following figure shows an example of how the SAPC performs the service selection:

Figure 2   Example of Service Selection

Note:  
Priority of subscriber groups is not applicable in service selection (for more information about priority of subscriber groups, refer to Subscription and Policy Management).

2.2.3   Service Authorization

For each of the selected services in the former process, the SAPC evaluates the configured policy conditions for Service Authorization.

Service Authorization policies are evaluated according to the following precedence allocation and applying permit overrides algorithm among them (that is, if any policy evaluates to true, the service is authorized):

  1. Subject policy locator
  2. Subject group policy locator. All the active subscriber groups are considered.

    Therefore configure Dynamic Group Selection policies to evaluate only the desired subscriber group policies.

  3. Global policy locator.

In case there are conflicts among the rules within a policy, the result for the policy depends on the Rule combining algorithm configured. Refer to Solving Policies Conflicts section in Subscription and Policy Management.

By default the selected services are authorized, therefore in case there are no Service Authorization policies configured for those services they are authorized.

Note:  
Time conditions are not considered in Service Authorization policies for dynamic services.

2.2.3.1   Service Authorization Policies without Time of Day Conditions or with Time of Day Conditions where PCRF controls time

The result of the evaluation process is:

If there are time of day conditions, the SAPC calculates an internal validity that is the minimum time and date conditions configured among all the evaluated rules. The SAPC triggers a new reauthorization when this time and date condition is reached. Refer to Policies based on Time of Day conditions section in Subscription and Policy Management.

The following figure shows how this process is performed:

Figure 3   Service Authorization Process

2.2.3.2   Service Authorization Policies with Time of Day Conditions where the PCEF controls time

Service Authorization policies can be based on time conditions, so, the authorization decision is only applicable during a period.

In addition to the authorization decision, the SAPC determines the Revalidation time (this time indicates the PCEF when to reauthorize the service) and service activation/deactivation times.

If there are configured policies based on time conditions, the SAPC performs the following authorization process:

  1. Determines if the service is authorized or not and the time when the authorization state should change (this time is the Validity Time)
  2. Using the smallest validity time obtained in previous step and considering that currently it is this time, determines again if the service is authorized or not and the time when the authorization state should change.
  3. The minimum validity time obtained in the second step is the Revalidation time, this time indicates to the PCEF when to reauthorize the service.

    For those services not changing the authorization state as a result of second step:

    • If the service is authorized, the SAPC installs the service with activation time equals to current time and deactivation time equals to its validity time obtained in the first step.
    • If the service is authorized and no authorization state change has been detected for the future, the SAPC installs the service without activation and deactivation times.
    • If the service is not authorized, it is not installed. If the service was authorized in previous request received from the PCEF, the SAPC will remove it if the service is not authorized again in the future (its validity time is infinite).

    For those services changing the authorization state as a result of second step:

    • If the service was authorized in first step and not authorized in second step, the SAPC installs the service with activation time equals to current time and deactivation time equals to its validity time obtained in the first step
    • If the service was not authorized in first step and authorized in second step, the SAPC installs the service with activation time equals to its validity time obtained in first step and deactivation time equals to the validity time from second step.

2.2.3.3   One Time Redirect Control

One Time Redirection (OTR) allows to temporary redirect the desired HTTP/WAP traffic to a landing page to show some advertisements to the subscriber or notify to the subscriber about any operator desired information.

When the SAPC informs the PCEF that OTR should be applied for a certain authorized static service, the PCEF at reception of the first HTTP/WAP request of such service from the user redirects the request to the configured page and disarms the OTR for such service for the rest of the IP-CAN session lifetime. So that, the next time the PCEF receives an HTTP/WAP request from the user for the same service along the IP-CAN session lifetime, redirection is not applied unless the SAPC informs again to the PCEF to apply it.

The SAPC indicates the activation or deactivation of One-Time Redirect towards the PCEF per service basis (it is only applicable to authorized static services).

At IP-CAN session establishment, the SAPC decides for which authorized static services OTR should be applied with checking the list of services to redirect provisioned for the subscriber and the active groups the subscriber belongs to. If the static service is authorized and OTR is provisioned, then the SAPC informs the PCEF that OTR is active for such service.

At IP-CAN session modification, the SAPC provides OTR information to the PCEF only when there is a change regarding the previously OTR provided information, that is:

2.2.4   Static Services Qualification

A Static Service can be identified by several static service names in the PCEF, each static service name assigns different characteristics (for example qualifying the service with rating group, service bandwidth) to the service. As an example, this enables the PCEF to perform service throttling.

Only one static service name at the time is applicable to the service.

The following figure shows how different characteristics can be assigned to a static service in the PCEF:

Figure 4   Example of Static Services Qualification

Static Services qualification policies can be applied by the SAPC to select which static service name is authorized and so to control the different set of service properties to be assigned by the PCEF. All properties configured for this static service name are configured in the PCEF.

For each static service authorized in the previous step, the SAPC evaluates the configured policies for static service qualification. The output result is the name of the qualified static service.

Static Services qualification policies are evaluated according to the following precedence allocation and applying permit overrides algorithm among them (if any policy evaluates to true, the static service is authorized):

  1. Subject policy locator
  2. Subject group policy locator. All the active subscriber groups are considered.

    Therefore configure Dynamic Group Selection policies to evaluate only the desired subscriber group policies.

  3. Global policy locator.

In case there are conflicts among the rules within a policy, the result for the policy depends on the rule combining algorithm configured. Refer to Solving Policies Conflicts section in Subscription and Policy Management.

If there are not configured static service qualification policies or policies are not fulfilled, the SAPC installs the service authorized in the previous step.

This option of using separately service authorization policies and static service qualification policies gives more flexibility and makes the configuration easier since it is possible to configure certain conditions for service authorization and different conditions to select the bandwidth, rating group, and so on. For example, authorize p2p service only if the subscriber is in his/her home network (with service authorization policies) and also select different bandwidth for p2p depending on time conditions (with static services qualification policies).

2.2.4.1   Static Service Qualification Policies with Time of Day Conditions

Static Service Qualification policies can be based on time conditions, so, the characteristics of the service (rating group, service bandwidth, and so on) is only applicable during a period.

  1. Static Service Qualification policies with time of day conditions where the PCEF controls times.

    Therefore, in addition to the PCC rule, the SAPC determines the Revalidation time (this time indicates the PCEF when to reauthorize the service) and service activation/deactivation times.

    If there are configured static service qualification policies based on time conditions, the SAPC performs the following process:

    1. Determines the static service name (Charging Rule Name) and the time when the static service name should change (this time is the Validity Time)
    2. The minimum validity time obtained in the first step is the Revalidation time, this time indicates to the PCEF when to reauthorize the service.

      For those static service names obtained in the first step and with finite validity, the SAPC installs the static service name with activation time equal to current time and deactivation time equal to its validity time obtained in the first step.

      For those static service names obtained in the first step and with infinity validity, the SAPC installs the static service name without activation or deactivation.

  2. Static Service Qualification policies with time of day conditions where PCRF controls times.

    When PCRF is chosen as controller of time of day conditions, neither service activation/deactivation times or revalidation time are provided to the PCEF.

    The SAPC calculates an internal validity that is the minimum time and date conditions configured among all the evaluated rules. The SAPC triggers a new reauthorization when this time and date condition is reached. Refer to Policies based on Time on Day Conditions section in Subscription and Policy Management.

2.2.5   Service Authorization and Static Service Qualification Policies with Time of Day Conditions where the PCEF controls time

When a service is configured with both Service Authorization and Static Qualification policies with Time Of Day conditions the service is selected by SAPC as follows:

  1. Determines if the service is authorized or not.
  2. If the service is authorized, the SAPC evaluates Static Qualification policies to determine the static service name (Charging Rule Name) and the time when the static service name should change (this time is the Validity Time)
  3. The minimum validity time obtained in the previous step is the Revalidation time. This time indicates to the PCEF when to reauthorize the service
    • For those static service names obtained in the first step and with finite validity, the SAPC installs the static service name with activation time equal to current time and deactivation time equal to its validity time obtained previously.
    • For those static service names obtained in the first step and with infinity validity, the SAPC installs the static service name without activation or deactivation times.

2.2.6   Notification of Errors in the Installation of Services

When a static or preconfigured service is not correctly installed or can no longer be maintained in the PCEF, it sends a notification towards the SAPC indicating that the corresponding PCC rules are not active, which means that the rules are removed (case of preconfigured) or deactivated (case of static) in the PCEF. The notification also includes a failure code that indicates the reason of the failure.

In such case, the SAPC also removes the PCC rules and performs policy evaluation ignoring the affected PCC rules, regardless of the failure code received.

The SAPC supports the notification of error for static, preconfigured, and dynamic PCC rules. For handling the notification of errors in the installation of dynamic PCC rules, refer to Dynamic Policy Control (Rx).

2.3   Service Charging Control

Service Charging Control allows SAPC to assign different charging data depending on service and subscriber basis.

2.3.1   Charging Control for Static Services with the PCEF

As it is explained in Static Services Qualification policies of Section 2.2, each static service can be associated with several static service names in the PCEF, each name is associated with a certain set of properties, one of these properties can be the Rating Group of the static service.

The SAPC is able to select the static service name to be applied to the static service by evaluating the Static Services qualification policies, that can take into account subscriber information, dynamic conditions and context information received (for example SGSN IP address, RAT). By this way, the SAPC can control the rating to be applied to static services handled by the PCEF.

Static Services qualification policies are evaluated each time service access control is performed (see Section 2.2).

2.3.2   Charging Control for Preconfigured Services with the PCEF

The SAPC is able to provide to the PCEF the following charging data applicable to authorized preconfigured services:

The SAPC selects the charging data to be applied to a service evaluating service charging policies according to the following precedence allocation:

  1. Subject policy locator
  2. Subject group policy locator. All the active subscriber groups are considered.

    Therefore configure Dynamic Group Selection policies to evaluate only the desired subscriber group policies.

  3. Global policy locator.

In case there are conflicts among the rules within a policy, the result for the policy depends on the Rule combining algorithm configured. Refer to Solving Policies Conflicts section in Subscription and Policy Management.

If there are not configured policies or the policies are not fulfilled, the SAPC obtains the charging profile provisioned for the service (Qualification data of service profile).

Service Charging Control is performed at:

If Service Charging Control is not configured for the requested PCEF, no charging data are either selected or sent to the PCEF as part of the authorized services.

2.4   Subscriber Charging Control

Subscriber Charging Control allows SAPC to assign different charging data depending on the subscriber or subscriber group.

The SAPC is able to provide to the PCEF the following charging information applicable for a subscriber:

The SAPC selects the charging data to be applied to a subscriber applying the mechanism for controls using both conditional (policies) and unconditional (static) qualification data explained in "Selection of Data to apply to the Subscriber" section in Subscription and Policy Management.

Subscriber Charging Control is performed at:

If Subscriber Charging Control is not configured for the requested PCEF, no subscriber charging data are either selected or sent to the PCEF for the IP-CAN session.

2.5   Content Filtering

The SAPC is able to provide the EPG with the applicable content filtering profile per subscriber (Ericsson Added Value). The EPG uses this profile to decide whether to allow or not the subscriber to access to a specific URL content. Content filtering may be required because of different reasons such as parental control, black/white lists, censorship, lack of subscription, or any content rights restrictions.

The SAPC selects the Content Filtering profile to be applied to a subscriber applying the mechanism for controls using both conditional (policies) and unconditional (static) qualification data explained in "Selection of Data to apply to the Subscriber" section in Subscription and Policy Management.

Content Filtering Control is performed at:

If Content Filtering Control is not configured for the requested PCEF no content filtering data is either selected or sent to the PCEF for the IP-CAN session.

2.6   Event Triggers

Event triggers define events that cause the PCEF to request new access and charging decisions to the SAPC. Some of the possible events are:

The SAPC performs the event trigger selection at:

The SAPC obtains all event triggers statically provisioned at subscriber, active subscriber groups and global subscriber group.

Also, the SAPC evaluates Event Trigger Selection policies applicable to the subscriber, that is, policies associated to the subscriber, the active groups to which the subscriber belongs to and the global policies. Event Trigger Selection policies allow multiple result, so the event triggers of all rules within all the selected policies that evaluate to true are obtained.

The SAPC extends the event triggers from the dynamic selection to the event triggers from the static selection. All event triggers in the list are summed up ensuring that no event triggers are repeated since no precedence is applied between the event triggers at the subscriber, active subscriber group, or the SAPC level.

Whenever event triggers are changed, the SAPC provides a new complete list of subscribed event triggers. In case the SAPC selects no event trigger after performing Event Triggers Selection, the SAPC sends the Event-Trigger AVP set to the special value NO_EVENT_TRIGGERS.

The SAPC is able to automatically subscribe and unsubscribe to the certain event triggers depending on the information received from the AF (for further details, refer to Dynamic Policy Control (Rx)).

2.7   Multiple Gx Support

The SAPC supports network scenarios where multiple PCEFs handle the same IP-CAN session for the same subscriber establishing multiple Gx sessions towards the SAPC. Multiple Gx support is an advanced feature offered by the SAPC that takes into account both events from bearers and DPI information to make the fine-tuned enforcement to the network.

In these scenarios, the SAPC consolidates the information received from all the multiple Gx sessions and is able to complement the information received from one Gx session with the information received from the others Gx sessions corresponding to the same IP-CAN session for the subscriber, that is, information received from one Gx session can be used to enforce policies in the other Gx session.

2.8   Presence Reporting Area

The SAPC supports Presence Reporting Area (PRA) following 3GPP specifications.

A Presence Reporting Area is an area defined within 3GPP Packet Domain for the purposes of reporting UE presence within that area due to policy control. A PRA may consist in a set of neighbor or non-neighbor Tracking Areas, or eNBs, cells, etc.

With the PRA function, the SAPC monitors the location change when the UE enters or leaves the pre-defined area for policy control. This means that the PCEF only notifies the SAPC when the UE enters or leaves the PRA. The SAPC has to subscribe to the event trigger for the presence status of the UE (within or outside the PRA) to the PCEF.

This function reduces the frequency of sending location change information so that the amount of signalling in the network is reduced. It also simplifies some location based use cases, as policies can be defined in the SAPC based solely in the UE presence in or out of the PRA.

There are two types of PRA over Gx:

The SAPC allows to select the PRA based on the following information:

The PRA selection is performed only in the Gx session establishment. Only one PRA can be selected per Gx session.

The SAPC can request to start reporting the UE presence changes in a PRA by subscribing the event trigger CHANGE_OF_UE_PRESENCE_IN_PRESENCE_REPORTING_AREA_REPORT. To stop the reporting, the SAPC removes the event trigger.

The policy decisions based on PRA status can be performed in Gx session modification and reauthorization.

The SAPC selects the PRA applying the mechanism for controls using both conditional and unconditional qualification data explained in Selection of Data to apply to the subscriber section in Subscription and Policy Management.

The following figure shows how to use PRA for policy control in the UE Attach or PDN connectivity scenario:

Figure 5   PRA over Gx

2.9   Diameter Race Condition Handling

The SAPC is able to handle diameter race conditions that may occur in the Gx and Ericsson Gx+ interfaces due to traffic events that happen concurrently or within a short time frame.

The solution involves two inter-related mechanisms:

2.9.1   Handling of Concurrent Gx RAR and CCR messages

The PCEF and the SAPC can initiate transactions that modify the state of the IP-CAN session independently (e.g. CCR from the PCEF and RAR from the SAPC) and potentially concurrently. Additionally, there may be diameter agents in between the PCEF and the SAPC that could cause messages to be delivered out of order. This can lead to race conditions that result in the wrong information maintained by the PCEF and/or the SAPC for the session.

Figure 6 shows the typical message flow that results in a diameter race condition. From the point of view of the PCEF, the re-authorization request from the SAPC has occurred after the PCEF has initiated an IP-CAN session modification procedure; and so the RAR message cannot be safely handled until the ongoing procedure has been completed. However, from the point of view of the SAPC, the CCR-U message is received when there is a pending re-authorization request to be completed.

Figure 6   Diameter Race Condition

The procedure to handle this race condition situation is as follows:

SAPC-initiated IP-CAN Session Termination

When the SAPC sends a request for session release (i.e. a RAR message with Session-Release-Cause AVP), the PCEF shall acknowledge the request immediately, wait for the current transaction to complete and perform the session termination procedure. However, if the PCEF returns an RAA with experimental result DIAMETER_PENDING_TRANSACTION, the SAPC re-attempts the RAR message with Session-Release-Cause AVP.

Maximum Number of Re-attempts

The SAPC implements a mechanism to limit the number of times to re-attempt the same request due to the reception of a DIAMETER_PENDING_TRANSACTION indication from the PCEF. This is to avoid infinite reattempting RARs. By default, the re-attempt mechanism is disabled. The maximum number of re-attempts is a node configuration parameter set by Ericsson personnel (default value is 0). When this value is reached, no further actions are taken.

Gx Feature Negotiation

Handling of diameter pending transactions is an optional feature that is negotiated during session establishment. However, the SAPC handles a race condition error received in the RAA message, regardless of whether the PCEF has indicated support of the optional feature in Gx CCR-I message or not.

Note:  
This is to enable inter-operability with legacy PCEFs that do not fully support the functionality according to the 3GPP standards.

2.9.2   Handling of Concurrent SAPC-initiated Reauthorizations

In certain network scenarios, the SAPC may need to perform multiple session reauthorizations within a short time period, triggered by either internal (e.g. time of day conditions) or external events (e.g. Sy events, AF events, subscriber profile change, etc.) that overlap in time. In this situation, the resulting RAR messages need to be sent to the PCEF sequentially, to avoid inconsistencies.

The SAPC does not send any new RAR message to the PCEF until the previous RAR has been acknowledged for the same IP-CAN session, or the maximum waiting time to receive the RAA message has been exceeded.

The procedure is as follows:

The maximum waiting time for reception of the RAA message is configured by Ericsson personnel (default value is 0).

3   Access and Charging Control Network Deployments

The SAPC can provide Access and Charging Control in the following network deployments:

4   Access and Charging Control Traffic Cases

This chapter explains the interfaces involved in Service Access and Charging Control.

For detailed description of each of the interfaces supported, the corresponding interface description should be consulted.

The precondition to all traffic cases is as follows:

4.1   IP-CAN session Lifetime

These traffic cases show the IP-CAN session life cycle: establishment, modification, and termination.

The following figure shows the Diameter messages exchanged in a communication between the PCEF and the SAPC:

Figure 7   Diameter communication between the PCEF and SAPC

The following sections explain each of these steps showing the specifics for each Gx protocol binding.

4.1.1   Protocol Binding for Rel9 Gx/Gx+ onwards

Session-Id AVP is mandatory for all the messages in Gx protocol. Session-Id AVP is globally unique and univocally identifies an IP-CAN session.

The SAPC identifies the subscriber IP-CAN session using Framed-IP-Address AVP or Framed-IPv6-Prefix AVP together with Called-Station-Id AVP and Subscription-Id AVP.

Note:  
Ericsson added value: new AVPs and standard AVPs including any modification to include extra function are marked in bold.

However, Ericsson added value function is optional and the service can always be provided as defined in standard without using the proprietary AVPs or the modifications of the standard ones.


IP-CAN session establishment

If Time of Day procedures are applicable and the PCEF is selected as time controller the following AVP is also included:

  • 9: The SAPC performs Service Charging Control for preconfigured services. The resulting charging profile data are included in the PCC rule definition charging data:
  • 10: The SAPC performs Subscriber Charging Control, obtaining the following data:
  • 11: The SAPC performs Content Filtering Control for Ericsson Rel9 Gx+ onwards. If the Content Filtering capability is set to "1" in step 5, the SAPC gets the Content Filtering to the applied subscriber. For more information, see section 2.6.

    If no Rule-Space-Id has been obtained after the rule-space negotiation process, service-domain is used as Resource in Content Filtering policies.

  • 12: The SAPC performs Event Triggers Selection, which selects the events that shall cause a re-request of PCC rules within the Event-Trigger AVP. The following values are applicable for this function:
  • 13: The CCA message is sent to the PCEF including the information previously computed (PCC rules installed, Charging data), Event triggers and Supported-Features AVP.

    • IP-CAN session modification

    IP-CAN session termination

    4.2   Redirect Owing to non-authorized Static Service

    This traffic case shows how non-authorization code can be used by the EPG to redirect the subscriber to a web portal, so the subscriber can subscribe to the service if desired.

    In this example, it is considered that HTTP-Streaming service is provisioned to the subscriber as static service but it is configured a Service Authorization policy that allows the usage of this service only if the subscriber is not roaming and in case roaming, such reason of non-authorization should be returned by the SAPC. Said non-authorization code triggers an HTTP redirection in EPG, so that the user is sent to a site where the user is informed about that HTTP-Streaming service is not available in roaming.

    This traffic case can be performed using Ericsson Rel9 Gx+ onwards.

    Figure 8   Redirect Owing to Non-authorized Static Service

    4.3   One Time Redirect for Authorized Static Services

    This traffic case shows how One Time Redirect is performed for any authorized static service.

    In this example, it is considered that HTTP-Streaming service is provisioned to the subscriber as static service and OTR is provisioned for this service.

    This traffic case can only be performed using Ericsson Rel9 Gx+ onwards.

    Figure 9   One Time Redirect for Authorized Static Services

    4.4   Service Authorization and Static Service Qualification Policies with Time of Day Conditions When the PCEF is Selected As Time Controller

    Either the PCRF or the PCEF can be selected as time controllers when Time of Day conditions applies in Service Access Control.

    These traffic cases show examples of Service Authorization and Static service qualification policies based on time conditions when the PCEF is the time controller.

    4.4.1   Time of Day Conditions Applied Only to Service Authorization Policies

    In this example it is considered that the following service authorization policies are configured for a subscriber:

    Static service qualification policies are not configured.

    The SAPC performs the following authorization process when receiving a CCR message at 12 p.m.:

    1. Determines if the service is authorized or not and the time when the authorization state should change (this time is the Validity Time)
      • Service 1 is authorized with a validity time = 17 p.m.
      • Service 2 is authorized with a validity time = 16 p.m.
    2. Using the smallest validity time obtained in previous step (16 p.m.) and considering that currently it is this time (16 p.m.), the SAPC determines again if the service is authorized or not and the time when the authorization state should change:
      • Service 1 is authorized with a validity time = 17 p.m.
      • Service 2 is not authorized with a validity time = 20 p.m.
    3. Finally, the SAPC includes the following information in CCA message:
      • Charging-Rule-Install AVP including:
        • Charging-Rule-Base-Name = 1
        • Rule-Activation-Time = 12 p.m.
        • Rule-Deactivation-Time = 17 p.m.
      • Charging-Rule-Install AVP including:
        • Charging-rule-name AVP = 2
        • Rule-Activation-Time = 12 p.m.
        • Rule-Deactivation-Time = 16 p.m.
      • Revalidation-Time = 17 p.m.

    The SAPC sends to the PCEF the active services at the moment of receiving the request message and the next active service. It also sends the Revalidation time as the time the second service becomes inactive, so that, the PCEF should request reauthorization towards the SAPC to get the next active service.

    4.4.2   Time of Day Conditions Applied to Service Authorization and Static Service Qualification Policies

    In this example it is considered that the following policies are configured for a subscriber:

    The SAPC performs the following process when receiving a CCR message at 12 p.m.:

    1. Service Authorization policies are evaluated, it determines if the service is authorized or not and the time when the authorization state should change (this time is the Validity Time), obtaining:
      • Service 1 is authorized with a validity time = 17 p.m.

        Static service qualification policies are evaluated, it determines the static service name (Charging Rule Name) and the time when the static service name should change:

        • Charging-rule-name-3 is obtained with a validity time = 12.30 p.m.
      • Service 2 is authorized with a validity time = 16 p.m.

        No Static Access policies are provisioned for this service.

    2. Using the smallest validity time obtained in previous step (12.30 p.m.) and considering that currently it is this time (12.30 p.m.), for services without static qualification policies, the SAPC determines again if the service is authorized or not and the time when the authorization state should change:
      • Service 2 is authorized with a validity time = 16 p.m.
    3. Finally, the SAPC includes the following information in CCA message:
      • Charging-Rule-Install AVP including:
        • Charging-rule-name AVP = 3
        • Rule-Activation-Time = 12 p.m.
        • Rule-Deactivation-Time = 12.30 p.m.
      • Charging-Rule-Install AVP including charging-rule-name AVP = 2
        • Rule-Activation-Time = 12 p.m.
        • Rule-Deactivation-Time = 16 p.m.
      • Revalidation-Time = 12.30 p.m.

    4.5   Presence Reporting Area

    These traffic cases show the Gx session life cycle with the PRA function: establishment, modification, and termination.

    Figure 10   Gx Session Lifetime with PRA Over Gx Function

    Gx session establishment

    PRA initial report

    Gx session termination

    4.6   PCC Rule Error Handling

    4.6.1   Protocol Binding for Rel9 Gx/Gx+ onwards Notification of Error in the Installation of PCC rules

    This traffic case shows the notification of an error in the installation of PCC rules. It is valid for GPRS and EPS scenarios.

    As an example of the Diameter messages exchange in a communication between the PCEF and the SAPC, see the following figure:

    Figure 11   Notification of Error in the Installation of PCC rules

    IP-CAN session modification

    If there are any dynamic PCC rules that are reported as inactive, the SAPC notifies the corresponding AF sessions, this is described in Dynamic Policy Control (Rx).

    4.7   Diameter Race Condition Handling

    The following traffic flow shows how the SAPC handles diameter race condition errors in an IP-CAN session.

    The precondition is that the IP-CAN session has been established, and race conditions happen due to internal or external events.

    Figure 12   Diameter Race Condition Handling

    4.8   Extended Event-Trigger for Tethering Detection Reporting over Gx

    This traffic case shows how the SAPC subscribes to Event-Trigger for Tethering at IP-CAN session establishment, and how the SAPC takes policy decisions based on the report of the Tethering traffic started at IP-CAN session modification.

    Figure 13   Extended Event-Trigger for Tethering Detection Reporting over Gx

    IP-CAN Session Establishment

    IP-CAN Session Modification

    4.9   Access and Charging Control Error Handling

    The SAPC may answer with the following error codes:

    Table 1    Error Handling

    Error Condition

    Action

    Code

    The SAPC receives a CCR and the corresponding IP-CAN session is not authorized.

    The SAPC returns a CCA indicating an error. No other information is included in the error message. In case of CCR-I, the Gx session is not established. In case of CCR-U, the PCEF shall send a new CCR-T immediately upon the reception of the CCA containing such error code.

    Result-Code AVP set to DIAMETER_AUTHORIZATION_REJECTED (5003)

    The SAPC receives a CCR-U/T for a diameter session not found in the SAPC

    The SAPC returns a CCA indicating an error

    Result-Code AVP set to DIAMETER_UNKNOWN_SESSION_ID (5002)

    The SAPC receives a CCR-I for a subscriber not defined in DB and autoprovisioning and subscriber unknown features are disabled.

    The SAPC returns a CCA indicating an error and the session is not established.

    Result-Code AVP set to DIAMETER_USER_UNKNOWN (5030)

    The SAPC receives a CCR request from a PCEF not configured in the SAPC

    The SAPC returns a CCA indicating an error.

    Result-Code AVP set to UNABLE_TO_COMPLY (5012)

    The SAPC receives a CCR that cannot be complied owing to an internal error (for example, because of temporal DB error)

    The SAPC returns a CCA indicating an error

    Result-Code AVP set to UNABLE_TO_COMPLY (5012)

    The SAPC receives a CCR with a mandatory parameter missed

    The SAPC returns a CCA indicating an error including a Failed-AVP AVP containing the AVPs that caused the failure

    Result-Code AVP set to DIAMETER_MISSING_AVP (5005)

    The SAPC receives a CCR with an invalid AVP value

    The SAPC returns a CCA indicating an error including a Failed-AVP AVP containing the AVPs that caused the failure

    Result-Code AVP set to DIAMETER_INVALID_AVP_VALUE (5004)

    The SAPC receives an IP-CAN session establishment request with Gx interface Release 7

    The SAPC rejects the IP-CAN session establishment and returns a CCA indicating an error

    Result-Code AVP set to DIAMETER_MISSING_AVP 5005

    The SAPC receives an IP-CAN session establishment request with Gx interface Release 8

    The SAPC rejects the IP-CAN session establishment and returns a CCA indicating an error

    Result-Code AVP set to DIAMETER_INVALID_AVP_VALUE 5004

    The SAPC receives an RAA message including the Experimental-Result-Code AVP set to DIAMETER_PENDING_TRANSACTION (4144) or DIAMETER_OUT_OF_SPACE (4002)

    The SAPC reauthorizes the IP-CAN session and determines the policy information to send to the PCEF to resolve the error

    		  

    Reference List

    Ericsson Documents
    [1] Bearer QoS and Bandwidth Management.
    [2] Dynamic Policy Control (Rx).
    [3] Subscription and Policy Management.
    Standards
    [4] Policy and charging control architecture - 3GPP TS 23.203
    Legal | © Ericsson España, S