Content for  TS 23.203  Word version:  19.0.0

The PCEF encompasses service data flow detection, policy enforcement and flow based charging functionalities. This functional entity is located at the Gateway (e.g. GGSN in the GPRS case, and PDG in the WLAN case). It provides service data flow detection, user plane traffic handling, triggering control plane session management (where the IP-CAN permits), QoS handling, and service data flow measurement as well as online and offline charging interactions. A PCEF shall ensure that an IP packet, which is discarded at the PCEF as a result from PCC rule enforcement or flow based charging, is neither reported for offline charging nor cause credit consumption for online charging. The PCEF is enforcing the Policy Control as indicated by the PCRF in two different ways:

• Gate enforcement. The PCEF shall allow a service data flow, which is subject to policy control, to pass through the PCEF if and only if the corresponding gate is open;
• QoS enforcement:
  • QoS class identifier correspondence with IP-CAN specific QoS attributes. The PCEF shall be able to convert a QoS class identifier value to IP-CAN specific QoS attribute values and determine the QoS class identifier value from a set of IP-CAN specific QoS attribute values.
  • PCC rule QoS enforcement. The PCEF shall enforce the authorized QoS of a service data flow according to the active PCC rule (e.g. to enforce uplink DSCP marking).
  • IP-CAN bearer QoS enforcement. The PCEF controls the QoS that is provided to a combined set of service data flows. The policy enforcement function ensures that the resources which can be used by an authorized set of service data flows are within the "authorized resources" specified via the Gx interface by "authorized QoS". The authorized QoS provides an upper bound on the resources that can be reserved (GBR) or allocated (MBR) for the IP-CAN bearer. The authorized QoS information is mapped by the PCEF to IP-CAN specific QoS attributes. During IP-CAN bearer QoS enforcement, if packet filters are provided to the UE, the PCEF shall provide packet filters with the same content as that in the SDF template filters received over the Gx interface.

The PCEF is enforcing the charging control in the following way:

• For a service data flow (defined by an active PCC rule) that is subject to charging control, the PCEF shall allow the service data flow to pass through the PCEF if and only if there is a corresponding active PCC rule with and, for online charging, the OCS has authorized credit for the charging key. The PCEF may let a service data flow pass through the PCEF during the course of the credit re-authorization procedure.

For a service data flow (defined by an active PCC rule) that is subject to both Policy Control and Charging Control, the PCEF shall allow the service data flow to pass through the PCEF if and only if the right conditions from both policy control and charging control happen. I.e. the corresponding gate is open and in case of online charging the OCS has authorized credit for its charging key. For a service data flow (defined by an active PCC rule) that is subject to policy control only and not charging control, the PCEF shall allow the service data flow to pass through the PCEF if and only if the conditions for policy control are met. A PCEF may be served by one or more PCRF nodes. The PCEF shall contact the appropriate PCRF based on the packet data network (PDN) connected to, together with, a UE identity information (if available, and which may be IP-CAN specific). It shall be possible to ensure that the same PCRF is contacted for a specific UE irrespective of the IP-CAN used. The operator may configure an indicator in HSS which is delivered to the PCEF within the Charging Characteristics and used by the PCEF to not establish the Gx session during the IP-CAN session establishment procedure. The PCEF shall, on request from the PCRF, modify a PCC rule, using the equivalent PCEF behaviour as the removal of the old and the activation of the new (modified) PCC rule. The PCEF shall modify a PCC rule as an atomic operation. The PCEF shall not modify a predefined PCC rule on request from the PCRF. The PCEF should support predefined PCC rules. For online charging, the PCEF shall manage credit as defined in clause 6.1.3. The operator may apply different PCC rules depending on different PLMN. The PCEF shall be able to provide identifier of serving network to the PCRF, which may be used by the PCRF in order to select the PCC rule to be applied. The operator may configure whether Policy and Charging Control is to be applied based on different access point. The PCEF shall gather and report IP-CAN bearer usage information according to clause 6.1.2. The PCEF may have a pre-configured Default charging method. Upon the initial interaction with the PCRF, the PCEF shall provide pre-configured Default charging method if available. At IP-CAN session establishment the PCEF shall initiate the IP-CAN Session Establishment procedure, as defined in clause 7.2. In case the SDF is tunnelled at the BBERF, the PCEF shall inform the PCRF about the mobility protocol tunnelling header of the service data flows. In case 2a, defined in clause 7.1, the PCEF may provide charging ID information to the PCRF. The PCEF shall inform the PCRF on whether it is enhanced with ADC, or provide the TDF address, if one is configured at the PCEF. If no PCC rule was activated for the IP-CAN session, the PCEF shall reject the IP-CAN session establishment. If there is no PCC rule active for a successfully established IP-CAN session at any later point in time, e.g., through a PCRF initiated IP-CAN session modification, the PCEF shall initiate an IP-CAN session termination procedure, as defined in clause 7.3.2. If the PCRF terminates the Gx session, the PCEF shall initiate an IP-CAN session termination procedure, as defined in clause 7.3.2. If there is no PCC rule active for a successfully established IP-CAN bearer at any later point in time, e.g., through a PCRF initiated IP-CAN session modification, the PCEF shall initiate an IP-CAN bearer termination procedure, as defined in clause 7.4.1. If the IP-CAN session is modified, e.g. by changing the characteristics for an IP-CAN bearer, the PCEF shall first use the event trigger to determine whether to request the PCC rules for the modified IP-CAN session from the PCRF; afterwards, the PCEF shall use the re-authorisation triggers, if available, in order to determine whether to require re-authorisation for the PCC rules that were either unaffected or modified. If the PCEF receives an unsolicited update of the PCC rules from the PCRF (IP-CAN session modification, clause 7.4.2), the PCC rules shall be activated, modified or removed as indicated by the PCRF. The PCEF shall inform the PCRF about the outcome of a PCC rule operation. If network initiated procedures apply to the PCC rule and the corresponding IP-CAN bearer can not be established or modified to satisfy the bearer binding, then the PCEF shall reject the activation of a PCC rule. The PCEF shall inform the PCRF about any removal of a PCC rule, that the PCRF has activated, that occurs without explicit instruction from the PCRF. When IP-CAN bearer resources are released, i.e. at IP-CAN session termination or PCEF-initiated IP-CAN session modification notifying that PCC Rules are removed, the PCEF shall also provide, if available, the reason why resources are released, i.e. RAN/NAS Release Cause, TWAN Release Cause or UWAN Release Cause. If network initiated procedures for IP-CAN bearer establishment apply this also includes provisioning the UE with traffic mapping information. See clause 6.1.9, Annex A and Annex D for details. If another IP-CAN session is established by the same user, this is treated independently from the existing IP-CAN session. To support the different IP-CAN bearer establishment modes (UE-only or UE/NW) the PCEF shall:

• forward the network and UE capabilities to the PCRF;
• apply the IP-CAN bearer establishment mode for the IP-CAN session set by the PCRF.

During an IP-CAN session modification, the PCEF shall provide information (belonging to the IP-CAN bearer established or modified) to the PCRF as follows:

• in UE-only bearer establishment mode, the PCEF shall send the full QoS and traffic mapping information;
• in UE/NW bearer establishment mode, the PCEF shall:
  • at UE-initiated bearer establishment, send the full QoS and traffic mapping information;
  • at UE-initiated bearer modification, send information on the requested change to QoS bitrates and changes to the traffic mapping information;
• at NW-initiated bearer establishment or modification, the PCEF shall not send any QoS or traffic mapping information.

When flow mobility as specified in TS 23.261 applies, the PCEF shall provide IP flow mobility routing information to the PCRF as follows:

• the default route to be used if no explicit routing information for a service data flow is provided;
• the route for an IP flow.

The PCEF shall derive the routing information from the IP flow mobility flow bindings installed in the PCEF, as defined in TS 23.261. If there are events which can not be monitored in the PCEF, the PCEF shall provide the information about the required event triggers to the PCRF using the PCEF initiated IP-CAN Session Modification procedure, as defined in clause 7.4.1, or in the response to a PCRF initiated IP-CAN Session Modification, as defined in clause 7.4.3. If the triggers were provided by the OCS at credit authorization, it is an implementation option whether a successful confirmation is required from the PCRF in order for the PCEF to consider the credit (re-)authorization procedure to be successful. IP-CAN-specific parameters may be sent by the PCRF to the PCEF or the PCEF to the PCRF. The IP-CAN Session Modification procedure may be used to deliver these parameters to allow interaction between the BBERF and the PCEF by way of the PCRF. This is required in accesses that require these parameters to be sent indirectly. The PCEF shall support usage monitoring as specified in clause 4.4. The PCEF enhanced with ADC shall handle application traffic detection as per request from PCRF as well as report about the detected application traffic along with service data flow descriptions, if deducible, to the PCRF, if requested by the PCRF. The PCEF shall support traffic steering as specified in clause 6.1.17. The PCEF shall support 3GPP PS Data Off as specified in clause 6.1.21. The PCEF forwards the Maximum Packet Loss Rate for UL and DL, if received from PCRF for the PCC rule bound to a QCI=1 bearer. In the case multiple PCC Rules share one QCI=1 bearer and the PCEF received multiple Maximum Packet Loss Rates, the PCEF chooses the lowest value per direction related to these PCC rules. When the PCRF provides updated PCC rules for the IP-CAN session to the PCEF, and the PCC rules were not enforced due to that the UE is in suspend state, e.g. due to SRVCC to GERAN without DTM support as specified in clause 6.2.2.1 in the TS 23.216 or CSFB to UTRAN without PS Handover as specified in clause 6.5 in the TS 23.272, the PCEF shall indicate to the PCRF that the PCC Rules were not enforced with the reason that the UE is in suspend state. Upon reception of the failure indication, the PCRF may subscribe to UE resumed from suspend state event trigger.

This clause refers to the detection process that identifies the packets belonging to a service data flow. Each PCC rule contains a service data flow template, which defines the data for the service data flow detection as a set of service data flow filters or an application identifier referring to an application detection filter. For PCC rules that contain an application identifier (i.e. that refer to an application detection filter), the order and the details of the detection are implementation specific. The application detection filter may be extended with the PFDs provided by the PFDF as described in clause 6.1.20. The new PFDs provided by the PFDF replace the existing ones in the PCEF. When multiple PFDs are associated with application identifier, the application is detected when any of the PFDs associated with the application identifier is matched. In addition, if a PFD contains multiple attributes, the PFD is only matched when every attribute contained in the PFD has a matching value. Once an application has been detected, enforcement and charging shall however be applied under consideration of the PCC rule precedence, i.e. when multiple PCC rules overlap, only the enforcement and charging actions of the PCC rule with the highest precedence shall be applied. For PCC Rules that contain an application identifier (i.e. that refer to an application detection filter) the detection of the uplink part of the service data flow may be active in parallel on other bearers with non-GBR QCI (e.g. the default bearer) in addition to the bearer where the PCC rule is bound to. The PCEF shall discard a packet in the case that there is no service data flow template of the same direction (i.e. of the IP-CAN session for the downlink or of the IP-CAN bearer for the uplink) detecting the packet. The remainder of this clause describes the detection of service data flows identified by a service data flow filter (i.e. does not apply to PCC rules containing an application identifier):

• Each service data flow template may contain any number of service data flow filters;
• Each service data flow filter is applicable uplink, downlink or both uplink and downlink;
• Service data flow filters are applied for each direction, so that the detection is applied independently for the downlink and uplink directions;
• Each service data flow filter may contain information about whether the explicit signalling of the corresponding traffic mapping information to the UE is required.

Service data flow filters identifying the service data flow may:

• be a pattern for matching the IP 5 tuple (source IP address or IPv6 network prefix, destination IP address or IPv6 network prefix, source port number, destination port number, protocol ID of the protocol above IP). In the pattern:
  • a value left unspecified in a filter matches any value of the corresponding information in a packet;
  • an IP address may be combined with a prefix mask;
  • port numbers may be specified as port ranges.
  • the pattern can be extended by the Type of Service (TOS) (IPv4) / Traffic class (IPv6) and Mask;
• consist of the destination IP address and optional mask, protocol ID of the protocol above IP, the Type of Service (TOS) (IPv4) / Traffic class (IPv6) and Mask and the IPSec Security Parameter Index (SPI);
• consist of the destination IP address and optional mask, the Type of Service (TOS) (IPv4) / Traffic class (IPv6) and Mask and the Flow Label (IPv6).
• extend the packet inspection beyond the possibilities described above and look further into the packet and/or define other operations (e.g. maintaining state). Such service data flow filters must be predefined in the PCEF.

For downlink traffic, the downlink parts of all the service data flow templates associated with the IP-CAN session for the destination address are candidates for matching in the detection process.

For uplink traffic, the uplink parts of all the service data flow templates associated with the IP-CAN bearer (details according to Annex A), are candidates for matching in the detection process.

Service data flow templates shall be applied in the order of their precedence.

The PCEF shall support data volume, duration, combined volume/duration and event based measurement for charging. The Measurement method indicates what measurement type is applicable to the PCC rule. The PCEF measurement measures all the user plane traffic, except traffic that PCC causes to be discarded. The PCEF shall maintain a measurement per IP-CAN bearer (IP-CAN specific details according to Annex A and Annex D), and Charging Key combination. If Service identifier level reporting is mandated in a PCC rule, the PCEF shall maintain a measurement for that Charging Key and Service Identifier combination, for the IP-CAN bearer (IP-CAN specific details according to Annex A and Annex D). For usage monitoring, the PCEF shall support volume and time measurement for an IP-CAN session and maintain a measurement for each IP-CAN session for which the PCRF has requested the Usage report trigger and provided threshold values on an IP-CAN session level. The PCEF shall be able to support volume and time measurements simultaneously for a given IP-CAN session. The PCEF shall support volume and time measurement per Monitoring key and maintain a measurement for each Monitoring key if the PCRF has requested the Usage report trigger and provided threshold values on Monitoring key level. The PCEF shall be able to support volume and time measurements simultaneously for a given Monitoring Key. The PCEF shall support simultaneous volume and time measurement for usage monitoring on IP-CAN session level and Monitoring key level for the same IP-CAN session. Volume and time measurements for usage monitoring purposes on IP-CAN session level and on Monitoring key level shall be performed independently of each other. If the PCC rule is associated with an indication of exclusion from session level monitoring, the PCEF shall not consider the corresponding service data flow for the volume and time measurement on IP-CAN session level. If the Usage report reached event trigger is set and a volume or a time threshold is reached, the PCEF shall report this event to the PCRF. The PCEF shall continue to perform volume or time measurement after the threshold is reached and before a new threshold is provided by the PCRF. At IP-CAN session termination or if the conditions defined in clause 6.6.2 for continued monitoring are no longer met, or if the PCRF explicitly requests a usage report, the PCEF shall inform the PCRF about the resources that have been consumed by the user since the last usage report for the affected Monitoring keys, including the resources consumed before and after the Monitoring time was reached, if provided according to clause 6.2.1.0. If combined volume and time measurements are requested by the PCRF, then the reporting shall be done for both together. For example, if the volume threshold is reached, the consumed time shall be reported as well and, in order to continue combined volume and time measurements, the PCRF shall provide a new time threshold along with a new volume threshold. The PCEF shall continue to perform volume and time measurement after the threshold is reached and before a new threshold is provided by the PCRF. If new threshold is provided only for time or volume, then the measurements shall continue only for that provided type and the accumulated usage for the non provided type shall be discarded by the PCEF. When the PCRF requests to report usage, the PCEF shall report the accumulated usage to the PCRF according to the provided usage threshold, i.e. the PCEF reports accumulated volume when the volume threshold was provided by the PCRF, accumulated time when the time threshold was provided by the PCRF and both accumulated volume and accumulated time when volume threshold and time threshold were provided by the PCRF. If the Usage thresholds for a Monitoring key are not provided to the PCEF in the acknowledgement of an IP-CAN Session modification where its usage was reported, then the usage monitoring shall not continue in the PCEF for that Monitoring key. When the Monitoring time occurs, the accumulated volume and/or time usage shall be recorded by the PCEF and:

• If the subsequent usage threshold value is provided, the usage threshold shall be reset to this value by the PCEF.
• Otherwise, the usage threshold shall be set by the PCEF to the remaining value of the threshold previously sent by the PCRF (i.e. excluding the accumulated usage).

The first usage report after the Monitoring Time was reached shall indicate the usage up to the Monitoring time and usage after the Monitoring time. In order to support time based usage monitoring, the PCRF may optionally indicate to the PCEF, along with other usage monitoring information provided, the Inactivity Detection Time. This value represents the time interval after which the time measurement shall stop for the Monitoring key, if no packets are received belonging to the corresponding Monitoring Key during that time period. Time measurement shall resume on receipt of a further packet belonging to the Monitoring key. Time measurement for a Monitoring key shall also be stopped when time based usage monitoring is disabled, if this happens before the Inactivity Detection Time is reached. If an Inactivity Detection Time value of zero is provided, or if no Inactivity Detection Time is present within the usage monitoring information provided by the PCRF, the time measurement shall be performed continuously from the point at which it was started until time based usage monitoring is disabled.

The PCEF enforces the authorized QoS for an IP-CAN bearer according to the information received via the Gx interface and depending on the bearer establishment mode. Only the GBR per bearer is used for resource reservation (e.g. admission control in the RAN). The MBR (per PCC rule / per bearer) is used for rate policing. For a UE-initiated IP-CAN bearer establishment or modification the PCEF receives the authorized QoS (QCI, ARP, GBR, MBR) for a bearer that the PCEF has identified for the PCRF. The PCEF shall enforce it which may lead to a downgrading or upgrading of the requested bearer QoS. For a network initiated IP-CAN bearer establishment or modification the PCEF receives the authorized QoS per PCC rule (QCI, ARP, GBR, MBR). For GBR bearers the PCEF should set the bearer's GBR to the sum of the GBRs of all PCC rules that are active and bound to that GBR bearer. If a set of PCC Rules is subject to resource sharing as specified in clause 6.1.14 the PCEF should use, for each applicable direction, the highest GBR from the set of PCC Rules sharing resources as input for calculating the bearer's GBR. For GBR bearers the PCEF should set the bearer's MBR to the sum of the MBRs of all PCC rules that are active and bound to that GBR bearer. If a set of PCC Rules is subject to resource sharing as specified in clause 6.1.14 the PCEF may, for each applicable direction, use the highest MBR from the set of PCC Rules as input for calculating the bearer's MBR. For an IP-CAN that supports non-GBR bearers that have a separate MBR (e.g. GPRS) the PCEF may, before or in connection with activation of the first PCC rule with a certain QCI, receive the authorized QoS (QCI, MBR) for that QCI. The authorized MBR per QCI only applies to non-GBR bearers, and it sets an upper limit for the MBR that the PCEF assigns to a non-GBR bearer with that QCI. In case multiple IP-CAN bearers within the same IP-CAN session are assigned the same QCI, the authorized MBR per QCI applies independently to each of those IP-CAN bearers. The PCRF may change the authorized MBR per QCI at any time. An authorized GBR per QCI shall not be signalled on Gx.

The PCEF shall detect Start and Stop of the application traffic for the PCC rules used for application detection (i.e. with application identifier) that the PCRF has activated at the PCEF. The PCEF shall report, if the PCRF has subscribed to the event, unless the notification is muted for the specific PCC Rule, to the PCRF:

• For the Start of application event trigger: the application identifier and, when service data flow descriptions are deducible, the application instance identifier and the service data flow descriptions to use for detecting that application traffic with a dynamic PCC rule as defined in clause 6.1.4.
• For the Stop of application event trigger: the application identifier and if the application instance identifier was reported for the Start, also the application instance identifier as defined in the clause 6.1.4.

When the PCRF provides a Traffic Steering Policy Identifier(s) in a PCC rule, the PCEF shall enforce the referenced traffic steering policy for the service data flow. A traffic steering policy is locally configured and can be used for the uplink, the downlink or for both directions. To enforce the traffic steering policy, the PCEF performs deployment specific actions as configured for that traffic steering policy. The PCEF may for example perform packet marking where, for the traffic identified by the service data flow template (defined by an active PCC rule), the PCEF provides information for traffic steering, as part of the packets, to the (S)Gi-LAN. This information for traffic steering identifies, explicitly or implicitly, a specific set of service functions and their order via which the traffic needs to be steered in the (S)Gi-LAN.