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. 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 and TS 23.402. 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. The PCC architecture shall support making policy decisions for (S)Gi-LAN traffic steering.

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. 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.

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. 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.
• 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. 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.

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 and TS 23.060.

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).

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.

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) 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. 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.