4 High level requirements

23.2033GPPPolicy and charging control architectureRelease 17TS

4.1 General requirements

It shall be possible for the PCC architecture to base decisions upon subscription information.

It shall be possible to apply policy and charging control to any kind of 3GPP IP‑CAN and any non-3GPP accesses connected via EPC complying with TS 23.402 [18]. Applicability of PCC to other IP‑CANs is not restricted. However, it shall be possible for the PCC architecture to base decisions upon the type of IP‑CAN used (e.g. GPRS, etc.).

The policy and charging control shall be possible in the roaming and local breakout scenarios defined in TS 23.401 [17] and TS 23.402 [18].

The PCC architecture shall discard packets that don’t match any service data flow of the active PCC rules. It shall also be possible for the operator to define PCC rules, with wild-carded service data flow filters, to allow for the passage and charging for packets that do not match any service data flow template of any other active PCC rules.

The PCC architecture shall allow the charging control to be applied on a per service data flow and on a per application basis, independent of the policy control.

The PCC architecture shall have a binding method that allows the unique association between service data flows and their IP‑CAN bearer.

A single service data flow detection shall suffice for the purpose of both policy control and flow based charging.

A PCC rule may be predefined or dynamically provisioned at establishment and during the lifetime of an IP‑CAN session. The latter is referred to as a dynamic PCC rule.

The number of real-time PCC interactions shall be minimized although not significantly increasing the overall system reaction time. This requires optimized interfaces between the PCC nodes.

It shall be possible to take a PCC rule into service, and out of service, at a specific time of day, without any PCC interaction at that point in time.

It shall be possible to take APN-related policy information into service, and out of service, once validity conditions specified as part of the APN-related policy information are fulfilled or not fulfilled anymore, respectively, without any PCC interaction at that point in time.

PCC shall be enabled on a per PDN basis (represented by an access point and the configured range of IP addresses) at the PCEF. It shall be possible for the operator to configure the PCC architecture to perform charging control, policy control or both for a PDN access.

PCC shall support roaming users.

The PCC architecture shall allow the resolution of conflicts which would otherwise cause a subscriber’s Subscribed Guaranteed Bandwidth QoS to be exceeded.

The PCC architecture shall support topology hiding.

It should be possible to use PCC architecture for handling IMS-based emergency service and Restricted Local Operator Services.

It shall be possible with the PCC architecture, in real-time, to monitor the overall amount of resources that are consumed by a user and to control usage independently from charging mechanisms, the so-called usage monitoring control.

It shall be possible for the PCC architecture to provide application awareness even when there is no explicit service level signalling.

The PCC architecture shall support making policy decisions based on subscriber spending limits.

The PCC architecture shall support making policy decisions based on RAN user plane congestion status.

The PCC architecture shall support making policy decisions for multi-access IP flow mobility solution described in TS 23.161 [43].

The PCC architecture shall support making policy decisions for (S)Gi-LAN traffic steering.

4.2 Charging related requirements

4.2.1 General

In order to allow for charging control on service data flow, the information in the PCC rule identifies the service data flow and specifies the parameters for charging control. The PCC rule information may depend on subscription data.

In order to allow for charging control on detected application traffic identified by ADC Rule for the TDF, the information in the ADC rule contains the application identifier and specifies the parameters for charging control. The ADC rule information may depend on subscription data.

For the purpose of charging correlation between application level (e.g. IMS) and service data flow level, applicable charging identifiers shall be passed along within the PCC architecture, if such identifiers are available.

For the purpose of charging correlation between service data flow level and application level (e.g. IMS) as well as on-line charging support at the application level, applicable charging identifiers and IP‑CAN type identifiers shall be passed from the PCRF to the AF, if such identifiers are available.

4.2.2 Charging models

The PCC charging shall support the following charging models both for charging performed by PCEF and charging performed by TDF:

– Volume based charging;

– Time based charging;

– Volume and time based charging;

– Event based charging;

– No charging.

NOTE 1: The charging model – "No charging" implies that charging control is not applicable.

Shared revenue services shall be supported. In this case settlement for all parties shall be supported, including the third parties that may have been involved providing the services.

NOTE 2: When developing a charging solution, the PCC charging models may be combined to form the solution. How to achieve a specific solution is however not within the scope of this TS.

NOTE 3: The Event based charging defined in this specification applies only to session based charging as defined by the charging specifications.

4.2.2a Charging requirements

The requirements in this clause apply to both PCC rules based charging and ADC rules based charging unless exceptions are explicitly mentioned.

It shall be possible to apply different rates and charging models when a user is identified to be roaming from when the user is in the home network. Furthermore, it shall be possible to apply different rates and charging models based on the location of a user, beyond the granularity of roaming.

It shall be possible to apply different rates and charging models when a user consuming network services via a CSG cell or a hybrid cell according to the user CSG information. User CSG information includes CSG ID, access mode and CSG membership indication.

It shall be possible to apply a separate rate to a specific service, e.g. allow the user to download a certain volume of data, reserved for the purpose of one service for free, and then continue with a rate causing a charge.

It shall be possible to change the rate based on the time of day.

It shall be possible to enforce per-service identified by PCC Rule/per-application identified by ADC Rule usage limits for a service data flow using online charging on a per user basis (may apply to prepaid and post-paid users).

It shall be possible to apply different rates depending on the access used to carry a Service Data Flow. This applies also to a PDN connection supporting NBIFOM.

It shall be possible for the online charging system to set and send the thresholds (time and/or volume based) for the amount of remaining credit to the PCEF or TDF for monitoring. In case the PCEF or TDF detects that any of the time based or volume based credit falls below the threshold, the PCEF or TDF shall send a request for credit re-authorization to the OCS with the remaining credit (time and/or volume based).

It shall be possible for the charging system to select the applicable rate based on:

– home/visited IP‑CAN;

– User CSG information;

– IP‑CAN bearer characteristics (e.g. QoS);

– QoS provided for the service;

– time of day;

– IP‑CAN specific parameters according to Annex A.

IP-CAN bearer characteristics are not applicable to charging performed in TDF.

NOTE 1: The same IP-CAN parameters related to access network/subscription/location information as reported for service data flow based charging may need to be reported for the application based charging at the beginning of the session and following any of the relevant re-authorization triggers.

The charging system maintains the tariff information, determining the rate based on the above input. Thus the rate may change e.g. as a result of IP‑CAN session modification to change the bearer characteristics provided for a service data flow.

The charging rate or charging model applicable to a service data flow/detected application traffic may change as a result of events in the service (e.g. insertion of a paid advertisement within a user requested media stream).

The charging model applicable to a service data flow/detected application traffic may change as a result of events identified by the OCS (e.g. after having spent a certain amount of time and/or volume, the user gets to use some services for free).

The charging rate or charging model applicable to a service data flow/detected application traffic may change as a result of having used the service data flow/detected application traffic for a certain amount of time and/or volume.

For online charging, it shall be possible to apply an online charging action upon PCEF or TDF events (e.g. re-authorization upon QoS change).

It shall be possible to apply an online charging action for detected application upon Application Start/Stop events.

It shall be possible to indicate to the PCEF or TDF that interactions with the charging systems are not required for a PCC or ADC rule, i.e. to perform neither accounting nor credit control for the service data flow/detected application traffic, and then no offline charging information is generated.

This specification supports charging and enforcement being done in either the PCEF or the TDF for a certain IP-CAN session, but not both for the same IP-CAN session (applies to all IP-CAN sessions belonging to the same APN).

NOTE 2: The above requirement is to ensure that there is no double charging in both TDF and PCEF or over charging in case of packet discarded at PCEF or TDF.

4.2.3 Examples of Service Data Flow Charging

There are many different services that may be used within a network, including both user-user and user-network services. Service data flows from these services may be identified and charged in many different ways. A number of examples of configuring PCC rules for different service data flows are described below.

EXAMPLE 1: A network server provides an FTP service. The FTP server supports both the active (separate ports for control and data) and passive modes of operation. A PCC rule is configured for the service data flows associated with the FTP server for the user. The PCC rule uses a filter specification for the uplink that identifies packets sent to port 20 or 21 of the IP address of the server, and the origination information is wildcarded. In the downlink direction, the filter specification identifies packets sent from port 20 or 21 of the IP address of the server.

EXAMPLE 2: A network server provides a "web" service. A PCC rule is configured for the service data flows associated with the HTTP server for the user. The PCC rule uses a filter specification for the uplink that identifies packets sent to port 80 of the IP address of the server, and the origination information is wildcarded. In the downlink direction, the filter specification identifies packets sent from port 80 of the IP address of the server.

EXAMPLE 3: The same server provides a WAP service. The server has multiple IP addresses, and the IP address of the WAP server is different from the IP address of the web server. The PCC rule uses the same filter specification as for the web server, but with the IP addresses for the WAP server only.

EXAMPLE 4: An operator offers a zero rating for network provided DNS service. A PCC rule is established setting all DNS traffic to/from the operators DNS servers as offline charged. The data flow filter identifies the DNS port number, and the source/destination address within the subnet range allocated to the operators network nodes.

EXAMPLE 5: An operator has a specific charging rate for user-user VoIP traffic over the IMS. A PCC rule is established for this service data flow. The filter information to identify the specific service data flow for the user-user traffic is provided by the P‑CSCF (AF).

EXAMPLE 6: An operator is implementing UICC based authentication mechanisms for HTTP based services utilizing the GAA Framework as defined in TR 33.919 [11] by e.g. using the Authentication Proxy. The Authentication Proxy may appear as an AF and provide information to the PCRF for the purpose of selecting an appropriate PCC Rule.

4.3 Policy control requirements

4.3.1 General

The policy control features comprise gating control and QoS control.

The concept of QoS class identifier and the associated bitrates specify the QoS information for service data flows and bearers on the Gx and Gxx reference points.

4.3.2 Gating control

Gating control shall be applied by the PCEF on a per service data flow basis.

To enable the PCRF gating control decisions, the AF shall report session events (e.g. session termination, modification) to the PCRF. For example, session termination, in gating control, may trigger the blocking of packets or "closing the gate".

4.3.3 QoS control

4.3.3.1 QoS control at service data flow level

It shall be possible to apply QoS control on a per service data flow basis in the PCEF.

QoS control per service data flow allows the PCC architecture to provide the PCEF with the authorized QoS to be enforced for each specific service data flow. Criteria such as the QoS subscription information may be used together with policy rules such as, service-based, subscription-based, or predefined PCRF internal policies to derive the authorized QoS to be enforced for a service data flow.

It shall be possible to apply multiple PCC rules, without application provided information, using different authorised QoS within a single IP‑CAN session and within the limits of the Subscribed QoS profile.

4.3.3.2 QoS control at IP‑CAN bearer level

It shall be possible for the PCC architecture to support control of QoS reservation procedures (UE-initiated or network-initiated) for IP‑CANs that support such procedures for its IP‑CAN bearers in the PCEF or the BBERF, if applicable. It shall be possible to determine the QoS to be applied in QoS reservation procedures (QoS control) based on the authorised QoS of the service data flows that are applicable to the IP‑CAN bearer and on criteria such as the QoS subscription information, service based policies, and/or predefined PCRF internal policies. Details of QoS reservation procedures are IP‑CAN specific and therefore, the control of these procedures is described in Annex A and Annex D.

It shall be possible for the PCC architecture to support control of QoS for the packet traffic of IP‑CANs.

The PCC architecture shall be able to provide policy control in the presence of NAT devices. This may be accomplished by providing appropriate address and port information to the PCRF.

The enforcement of the control for QoS reservation procedures for an IP‑CAN bearer shall allow for a downgrading or an upgrading of the requested QoS as part of a UE-initiated IP‑CAN bearer establishment and modification. The PCC architecture shall be able to provide a mechanism to initiate IP‑CAN bearer establishment and modification (for IP‑CANs that support such procedures for its bearers) as part of the QoS control.

The IP‑CAN shall prevent cyclic QoS upgrade attempts due to failed QoS upgrades.

NOTE: These measures are IP‑CAN specific.

The PCC architecture shall be able to handle IP‑CAN bearers that require a guaranteed bitrate (GBR bearers) and IP‑CAN bearers for which there is no guaranteed bitrate (non-GBR bearers).

4.3.3.3 QoS Conflict Handling

It shall be possible for the PCC architecture to support conflict resolution in the PCRF when the authorized bandwidth associated with multiple PCC rules exceeds the Subscribed Guaranteed bandwidth QoS.

4.3.3.4 QoS control at APN level

It shall be possible for the PCRF to authorize the APN-AMBR to be enforced by the PCEF as defined in TS 23.401 [17]. The APN-AMBR applies to all IP‑CAN sessions of a UE to the same APN and has separate values for the uplink and downlink direction.

It shall be possible for the PCRF to provide the authorized APN-AMBR values unconditionally or conditionally, i.e. per IP-CAN type and/or RAT type.

It shall be possible for the PCRF to request a change of the unconditional or conditional authorized APN-AMBR value(s) at a specific point in time.

The details are specified in clause 6.4b.

4.3.4 Subscriber Spending Limits

It shall be possible to enforce policies based on subscriber spending limits as per TS 22.115 [27]. The OCS shall maintain policy counter(s) to track spending for a subscription. These policy counters must be available in the OCS prior to their use over the Sy interface.

NOTE 1: The mechanism for provisioning the policy counters in the OCS is out of scope of this document.

NOTE 2: A policy counter in the OCS can represent the spending for one or more services, one or more devices, one or more subscribers, etc. The representation is operator dependent. There is no explicit relationship between Charging-Key and policy counter.

The PCRF shall request information regarding the subscriber’s spending from the OCS, to be used as input for dynamic policy decisions for the subscriber, using subscriptions to spending limit reports. The OCS shall make information regarding the subscriber’s spending available to the PCRF using spending limit reports.

4.4 Usage Monitoring Control

It shall be possible to apply usage monitoring for the accumulated usage of network resources on a per IP-CAN session and user basis. This capability is required for enforcing dynamic policy decisions based on the total network usage in real-time.

The PCRF that uses usage monitoring for making dynamic policy decisions shall set and send the applicable thresholds to the PCEF or TDF for monitoring. The usage monitoring thresholds shall be based either on time, or on volume. The PCRF may send both thresholds to the PCEF or TDF. The PCEF or TDF shall notify the PCRF when a threshold is reached and report the accumulated usage since the last report for usage monitoring. If both time and volume thresholds were provided to the PCEF or TDF, the accumulated usage since last report shall be reported when either the time or the volume thresholds are reached.

NOTE: There are reasons other than reaching a threshold that may cause the PCEF/TDF to report accumulated usage to the PCRF as defined in clauses 6.2.2.3 and 6.6.2.

The usage monitoring capability shall be possible for an individual or a group of service data flow(s), or for all traffic of an IP-CAN session in the PCEF. When usage monitoring for all traffic of an IP-CAN session is enabled, it shall be possible to exclude an individual SDF or a group of service data flow(s) from the usage monitoring for all traffic of this IP-CAN session. It shall be possible to activate usage monitoring both to service data flows associated with predefined PCC rules and dynamic PCC rules, including rules with deferred activation and/or deactivation times while those rules are active.

The usage monitoring capability shall be possible for an individual or a group of detected application(s) traffic, or all detected traffic belonging to a specific TDF session. When usage monitoring for all traffic of a TDF session is enabled, it shall be possible to exclude an individual application or a group of detected application(s) from the usage monitoring for all traffic belonging to this TDF session if usage monitoring. It shall be possible to activate usage monitoring both to predefined ADC rules and to dynamic ADC rules, including rules with deferred activation and/or deactivation times while those rules are active.

If service data flow(s)/application(s) need to be excluded from IP-CAN/TDF session level usage monitoring and IP‑CAN /TDF session level usage monitoring is enabled, the PCRF shall be able to provide the an indication of exclusion from session level monitoring associated with the respective PCC/ADC rule(s).

It shall be possible to apply different usage monitoring depending on the access used to carry a Service Data Flow. This applies also to a PDN connection supporting NBIFOM. IP-CAN session level usage monitoring is not dependent on the access used to carry a Service Data Flow.

4.5 Application Detection and Control

The application detection and control feature comprise the request to detect the specified application traffic, report to the PCRF on the start or stop of application traffic and to apply the specified enforcement and charging actions.

The application detection and control shall be implemented either by the TDF or by the PCEF enhanced with ADC.

Two models may be applied, depending on operator requirements: solicited and unsolicited application reporting. The unsolicited application reporting is only supported by the TDF.

Solicited application reporting: The PCRF shall instruct the TDF, or the PCEF enhanced with ADC, on which applications to detect and whether to report start or stop event to the PCRF by activating the appropriate ADC/PCC rules in the TDF/PCEF enhanced with ADC. Reporting notifications of start and stop of application detection to the PCRF may be muted, in addition, per specific ADC/PCC rule. The PCRF may, in a dynamic ADC/PCC rule, instruct the TDF or PCEF enhanced with ADC, what enforcement actions to apply to the detected application traffic. The PCRF may activate application detection only if user profile configuration allows this.

Unsolicited application reporting: The TDF is pre-configured on which applications to detect and report. The PCRF may enable enforcement in the PCEF based on the service data flow description provided to PCRF by the TDF. It is assumed that user profile configuration indicating whether application detection and control can be enabled is not required.

The report to the PCRF shall include the same information for solicited and unsolicited application reporting that is whether the report is for start or stop, the detected application identifier and, if deducible, the service data flow descriptions for the detected application traffic.

For the application types, where service data flow descriptions are deducible, the Start and Stop of the application may be indicated multiple times, including the application instance identifier to inform the PCRF about the service data flow descriptions belonging to that application instance. The application instance identifier is dynamically assigned by the TDF or by the PCEF enhanced with ADC in order to allow correlation of application Start and Stop events to the specific service data flow description.

NOTE 1: The reporting to the PCRF on the start or stop of application traffic is not depending on any enforcement action of the ADC/PCC rule. Unless the PCRF muted the reporting for the ADC/PCC rule, every detected start or stop event is reported even if the application traffic is discarded due to enforcement actions of the ADC/PCC rule.

For the TDF operating in the solicited application reporting model:

– When the TDF cannot provide to the PCRF the service data flow description for the detected applications, the TDF shall perform charging, gating, redirection and bandwidth limitation for the detected applications, as defined in the ADC rule. The existing PCEF functionality remains unchanged.

NOTE 2: Redirection may not be possible for all types of detected application traffic (e.g. this may only be performed on specific HTTP based flows).

– When the TDF provides to the PCRF the service data flow description, the PCRF may take control over the actions resulting of application detection, by applying the charging and policy enforcement per service data flow as defined in this document, or the TDF may perform charging, gating, redirection and bandwidth limitation as described above. It is the PCRF’s responsibility to coordinate the PCC rules with ADC rules in order to ensure consistent service delivery.

Usage monitoring as described in clause 4.4 may be activated in conjunction with application detection and control. The usage monitoring functionality is only applicable to the solicited application reporting model.

For TDF, ADC rule based charging is applicable. ADC rule based charging, as described in clause 4.2.2a, may be activated in conjunction with application detection and control. The charging functionality is only applicable to the solicited application reporting model.

In order to avoid charging for the same traffic in both the TDF and the PCEF, this specification supports charging and enforcement implemented in either the PCEF or the TDF for a certain IP-CAN session, but not both for the same IP-CAN session.

The ADC rules are used to determine the online and offline characteristics for charging. For offline charging, usage reporting over the Gzn interface shall be used. For online charging, credit management and reporting over the Gyn interface shall be used. The PCEF is in this case not used for charging and enforcement (based on active PCC rules and APN-AMBR configuration), but shall still be performing bearer binding based on the active PCC rules. In order to avoid having traffic that is charged in the TDF later discarded by the policing function in the PCEF, the assumption is that no GBR bearers are required when TDF is the charging and policy enforcement point. In addition, the DL APN-AMBR in PCEF shall be configured with such high values that it does not result in discarded packets.

NOTE 3: An example of applicability is IMS APN, which would require dynamic PCC rules, would be configured such that PCEF based charging and enforcement is employed, but for regular internet access APN, the network would be configured such that the TDF performs both charging and enforcement.

NOTE 4: An operator may also apply this solution with both PCEF and TDF performing enforcement and charging for a single IP-CAN session as long as the network is configured in such a way that the traffic charged and enforced in the PCEF does not overlap with the traffic charged and enforced by the TDF.

NOTE 5: The PCEF may still do enforcement actions on uplink traffic without impacting the accuracy of the charging information produced by the TDF.

If only charging for a service data flow identified by a PCC Rule is required for the corresponding IP-CAN session, the PCEF performs charging and policy enforcement for the IP-CAN session. The TDF may be used for application detection and reporting of application start/stop and for enforcement actions on downlink traffic.

4.6 RAN user plane congestion detection, reporting and mitigation

It shall be possible to transfer RAN user plane congestion information from the RAN to the Core Network in order to mitigate the congestion by measures selected by the PCRF and applied by the PCEF/TDF/AF. The detailed description of this functionality can be found in TS 23.401 [17] and TS 23.060 [12].

4.7 Support for service capability exposure

It shall be possible to transfer information related to service capability exposure between the PCRF and the AF via an SCEF (see TS 23.682 [42]).

4.8 Traffic Steering Control

Traffic Steering Control refers to the capability to activate/deactivate traffic steering policies from the PCRF in the PCEF, the TDF or the TSSF for the purpose of steering the subscriber’s traffic to appropriate operator or 3rd party service functions (e.g. NAT, antimalware, parental control, DDoS protection) in the (S)Gi-LAN.

The traffic steering control is supported in non-roaming and home-routed scenarios only.

4.9 Management of Packet Flow Descriptions in the PCEF/TDF using the PFDF

Management of Packet Flow Descriptions in the PCEF/TDF using the PFDF refers to the capability to create, update or remove PFDs in the PFDF via the SCEF (as described in TS 23.682 [42]) and the distribution from the PFDF to the PCEF or the TDF or both. This feature may be used when the PCEF or the TDF is configured to detect a particular application provided by an ASP.

NOTE 1: A possible scenario for the management of PFDs in the PCEF/TDF is when an application, identified by an application detection filter in the PCEF/TDF, deploys a new server or reconfiguration at the ASP network occurs which impacts the application detection filters of that particular application.

NOTE 2: The management of application detection filters in the PCEF/TDF can still be performed by using operation and maintenance procedures.

NOTE 3: This feature aims for both: to enable accurate application detection at the PCEF and at the TDF and to minimize storage requirements for the PCEF and the TDF.

The management of Packet Flow Descriptions is supported in non-roaming and home-routed scenarios for those ASPs that have a business relation with the home operator.