6.3 Policy and charging control rule
23.2033GPPPolicy and charging control architectureRelease 17TS
6.3.1 General
The Policy and charging control rule (PCC rule) comprises the information that is required to enable the user plane detection of, the policy control and proper charging for a service data flow. The packets detected by applying the service data flow template of a PCC rule form a service data flow.
Two different types of PCC rules exist: Dynamic rules and predefined rules. The dynamic PCC rules are provisioned by the PCRF via the Gx reference point, while the predefined PCC rules are directly provisioned into the PCEF and only referenced by the PCRF. The usage of predefined PCC rules for QoS control is possible if the BBF remains in the PCEF during the lifetime of an IP-CAN session. In addition, predefined PCC rules may be used in a non-roaming situation and if it can be guaranteed that corresponding predefined QoS rules are configured in the BBF and activated along with the predefined PCC rules.
NOTE 1: The procedure for provisioning predefined PCC rules is out of scope for this specification.
NOTE 2: There may be another type of predefined rules that are not explicitly known in the PCRF and not under the control of the PCRF. The operator may define such predefined PCC rules, to be activated by the PCEF on one IP‑CAN bearer within the IP‑CAN session. The PCEF may only activate such predefined PCC rules if there is no UE provided traffic mapping information related to that IP‑CAN bearer. The IP‑CAN session termination procedure deactivates such predefined PCC rules.
There are defined procedures for activation, modification and deactivation of PCC rules (as described in clause 6.3.2). The PCRF may activate, modify and deactivate a PCC rule at any time, over the Gx reference point. However, the modification procedure is applicable to dynamic PCC rules only.
Each PCC rule shall be installed for a single IP‑CAN bearer only (for further details about predefined PCC rules see clause 6.3.2).
The operator defines the PCC rules.
Table 6.3 lists the information contained in a PCC rule, including the information name, the description and whether the PCRF may modify this information in a dynamic PCC rule which is active in the PCEF. The Category field indicates if a certain piece of information is mandatory or not for the construction of a PCC rule, i.e. if it is possible to construct a PCC rule without it.
Table 6.3: The PCC rule information
|
Information name |
Description |
Category |
PCRF permitted to modify for a dynamic PCC rule in the PCEF |
|---|---|---|---|
|
Rule identifier |
Uniquely identifies the PCC rule, within an IP‑CAN session. It is used between PCRF and PCEF for referencing PCC rules. |
Mandatory |
no |
|
Service data flow detection |
This part defines the method for detecting packets belonging to a service data flow. |
||
|
Precedence |
Determines the order, in which the service data flow templates are applied at service data flow detection, enforcement and charging. (NOTE 9). |
Conditional (NOTE 13) |
yes |
|
Service data flow template |
Either a list of service data flow filters or an application identifier that references the corresponding application detection filter for the detection of the service data flow. |
Mandatory (NOTE 7) |
Conditional (NOTE 12) |
|
Mute for notification |
Defines whether application’s start or stop notification is to be muted. |
Conditional (NOTE 8) |
No |
|
Charging |
This part defines identities and instructions for charging and accounting that is required for an access point where flow based charging is configured |
||
|
Charging key |
The charging system (OCS or OFCS) uses the charging key to determine the tariff to apply to the service data flow. |
yes |
|
|
Service identifier |
The identity of the service or service component the service data flow in a rule relates to. |
yes |
|
|
Sponsor Identifier |
An identifier, provided from the AF which identifies the Sponsor, used for sponsored flows to correlate measurements from different users for accounting purposes. |
Conditional (NOTE 6) |
yes |
|
Application Service Provider Identifier |
An identifier, provided from the AF which identifies the Application Service Provider, used for sponsored flows to correlate measurements from different users for accounting purposes. |
Conditional (NOTE 6) |
yes |
|
Charging method |
Indicates the required charging method for the PCC rule. Values: online, offline or neither. |
Conditional |
no |
|
Measurement method |
Indicates whether the service data flow data volume, duration, combined volume/duration or event shall be measured. This is applicable to reporting, if the charging method is online or offline. Note: Event based charging is only applicable to predefined PCC rules and PCC rules used for application detection filter (i.e. with an application identifier). |
yes |
|
|
Application Function Record Information |
An identifier, provided from the AF, correlating the measurement for the Charging key/Service identifier values in this PCC rule with application level reports. |
no |
|
|
Service identifier level reporting |
Indicates that separate usage reports shall be generated for this Service identifier. Values: mandated or not required |
Yes |
|
|
Policy control |
This part defines how the PCEF shall apply policy control for the service data flow. |
||
|
Gate status |
The gate status indicates whether the service data flow, detected by the service data flow template, may pass (Gate is open) or shall be discarded (Gate is closed) at the PCEF. |
Yes |
|
|
QoS class identifier |
Identifier for the authorized QoS parameters for the service data flow. |
Conditional |
Yes |
|
UL-maximum bitrate |
The uplink maximum bitrate authorized for the service data flow |
Conditional |
Yes |
|
DL-maximum bitrate |
The downlink maximum bitrate authorized for the service data flow |
Conditional |
Yes |
|
UL-guaranteed bitrate |
The uplink guaranteed bitrate authorized for the service data flow |
Yes |
|
|
DL-guaranteed bitrate |
The downlink guaranteed bitrate authorized for the service data flow |
Yes |
|
|
UL sharing indication |
Indicates resource sharing in uplink direction with service data flows having the same value in their PCC rule |
No |
|
|
DL sharing indication |
Indicates resource sharing in downlink direction with service data flows having the same value in their PCC rule |
No |
|
|
Redirect |
Redirect state of the service data flow (enabled/disabled) |
Conditional (NOTE 10) |
Yes |
|
Redirect Destination |
Controlled Address to which the service data flow is redirected when redirect is enabled |
Conditional (NOTE 11) |
Yes |
|
ARP |
The Allocation and Retention Priority for the service data flow consisting of the priority level, the pre-emption capability and the pre-emption vulnerability |
Conditional |
Yes |
|
Bind to Default Bearer |
Indicates that the dynamic PCC rule shall always have its bearer binding with the default bearer. |
Conditional |
Yes |
|
PS to CS session continuity |
Indicates whether the service data flow is a candidate for vSRVCC. |
Conditional |
No |
|
Access Network Information Reporting |
This part describes access network information to be reported for the PCC rule when the corresponding bearer is established, modified or terminated. |
||
|
User Location Report |
The serving cell of the UE is to be reported. When the corresponding bearer is deactivated, and if available, information on when the UE was last known to be in that location is also to be reported. |
Yes |
|
|
UE Timezone Report |
The time zone of the UE is to be reported. |
Yes |
|
|
Usage Monitoring Control |
This part describes identities required for Usage Monitoring Control. |
||
|
Monitoring key |
The PCRF uses the monitoring key to group services that share a common allowed usage. |
Yes |
|
|
Indication of exclusion from session level monitoring |
Indicates that the service data flow shall be excluded from the IP-CAN session usage monitoring |
Yes |
|
|
Traffic Steering Enforcement Control |
This part describes identities required for Traffic Steering Enforcement Control. |
||
|
Traffic steering policy identifier(s) |
Reference to a pre-configured traffic steering policy at the PCEF (NOTE 14). |
Yes |
|
|
NBIFOM related control Information |
This part describes PCC rule information related with NBIFOM (defined in TS 23.161 [43]. Refer also to clause 6.1.18. |
||
|
Allowed Access Type |
The access to be used for traffic identified by the PCC rule |
Yes |
|
|
Routing Rule Identifier |
The Routing Rule identifier to be used in NBIFOM routing rule |
No |
|
|
RAN support information |
This part defines information supporting the RAN for e.g. handover threshold decision. |
||
|
UL Maximum Packet Loss Rate |
The maximum rate for lost packets that can be tolerated in the uplink direction for service data flow. It is defined in clause 5.4.1 of TS 23.401 [17]. |
Conditional (NOTE 16) |
Yes |
|
DL Maximum Packet Loss Rate |
The maximum rate for lost packets that can be tolerated in the downlink direction for service data flow. It is defined in clause 5.4.1 of TS 23.401 [17]. |
Conditional (NOTE 16) |
Yes |
|
NOTE 1: The QoS class identifier is scalar and accommodates the need for differentiating QoS in all types of 3GPP IP‑CAN. The value range is expandable to accommodate additional types of IP‑CAN. NOTE 2: The QoS class identifier is mandatory when the bearer binding is allocated to the PCEF. NOTE 3: Mandatory when the QoS class identifier is of Resource Type GBR. Used to activate policy control on SDF level at the PCEF. NOTE 4: Mandatory if there is no default charging method for the IP‑CAN session. NOTE 5: Mandatory when policy control on SDF level applies unless otherwise stated in an access-specific Annex. NOTE 6: Applicable to sponsored data connectivity. NOTE 7: Either service data flow filter(s) or application identifier shall be defined per each rule. application identifier can only be used for PCEF enhanced with ADC. NOTE 8: Optional and applicable only if application identifier exists within the rule. NOTE 9: For PCC rules based on an application detection filter, the precedence is only relevant for the enforcement, i.e. when multiple PCC rules overlap, only the enforcement, reporting of application starts and stops, monitoring, and charging actions of the PCC rule with the highest precedence shall be applied. NOTE 10: Optional and applicable only if application identifier exists within the rule. NOTE 11: If Redirect is enabled. NOTE 12: YES, in case the service data flow template consists of a set of service data flow filters. NO in case the service data flow template consists of an application identifier. NOTE 13: The Precedence is mandatory for PCC rules with SDF template containing SDF filter(s). For dynamic PCC rules with SDF template containing an application identifier, the precedence is either preconfigured in PCEF or provided in the PCC rule from PCRF. NOTE 14: The Traffic steering policy identifier can be different for uplink and downlink direction. If two Traffic steering policy identifiers are provided, then one is for uplink direction, while the other one is for downlink direction. NOTE 15: The presence of this attribute causes the QCI/ARP of the rule to be ignored. This attribute is defined for selected accesses as specified in the access specific Annexes. NOTE 16: Optional and applicable only for voice service data flow in this Release. |
|||
The Rule identifier shall be unique for a PCC rule within an IP‑CAN session. A dynamically provided PCC rule that has the same Rule identifier value as a predefined PCC rule shall replace the predefined rule within the same IP‑CAN session.
The Service data flow template may comprise any number of Service data flow filters. A Service data flow filter contains information for matching user plane packets. A Service data flow filter, provided from the PCRF, contains information elements as described in clause 6.2.2.2. The Service data flow template filtering information within an activated PCC rule is applied at the PCEF to identify the packets belonging to a particular service data flow.
NOTE 3: Predefined PCC rules may include service data flow filters, which support extended capabilities, including enhanced capabilities to identify events associated with application protocols.
Alternatively, the Service data flow template consists of an application identifier that references an application detection filter that is used for matching user plane packets. The application identifier is also identifying the application, for which the rule applies. The same application identifier value can occur in more than one PCC rule with the following restrictions:
– The same application identifier value can be used for a dynamic PCC rule and one or multiple predefined PCC rules. If so, the PCRF shall ensure that there is at most one PCC rule active per application identifier value at any time.
NOTE 4: The configuration of the Application Identifier in the PCEF can include the set of information required for encrypted traffic detection as defined in Annex X.
The Mute for notification defines whether notification to the PCRF of application’s starts or stops shall be muted. Absence of this parameter means that start/stop notifications shall be sent.
The Precedence defines in what order the activated PCC rules within the same IP‑CAN session shall be applied at the PCEF for service data flow detection. When a dynamic PCC rule and a predefined PCC rule have the same precedence, the dynamic PCC rule takes precedence. For dynamic PCC rules that contain an application identifier, the Precedence shall be either preconfigured at the PCEF or provided dynamically by the PCRF within the PCC Rules.
NOTE 5: The operator shall ensure that overlap between the predefined PCC rules can be resolved based on precedence of each predefined PCC rule in the PCEF. The PCRF shall ensure that overlap between the dynamically allocated PCC rules can be resolved based on precedence of each dynamically allocated PCC rule. Further information about the configuration of the PCC rule precedence is described in Annex G.
NOTE 6: Whether precedence for dynamic PCC rules that contain an application identifier is preconfigured in PCEF or provided in the PCC rule from the PCRF depends on network configuration.
For downlink packets all the service data flow templates, activated for the IP‑CAN session shall be applied for service data flow detection and for the mapping to the correct IP‑CAN bearer. For uplink packets the service data flow templates activated on their IP‑CAN bearer shall be applied for service data flow detection (further details provided in clause 6.2.2.2 and the IP-CAN specific annexes).
The Charging key is the reference to the tariff for the service data flow. Any number of PCC Rules may share the same charging key value. The charging key values for each service shall be operator configurable.
NOTE 7: Assigning the same Charging key for several service data flows implies that the charging does not require the credit management to be handled separately.
NOTE 8: If the IP flow mobility is supported and the tariff depends on what access network is in use for the service data flow, then a separate Charging key can be allocated for each access network, and the PCRF can set the Charging key in accordance with the access network in use.
The Service identifier identifies the service. PCC Rules may share the same service identifier value. The service identifier provides the most detailed identification, specified for flow based charging, of a service data flow.
NOTE 9: The PCC rule service identifier need not have any relationship to service identifiers used on the AF level, i.e. is an operator policy option.
The Sponsor Identifier indicates the (3rd) party organization willing to pay for the operator’s charge for connectivity required to deliver a service to the end user.
The Application Service Provider Identifier indicates the (3rd) party organization delivering a service to the end user.
The Charging method indicates whether online charging, offline charging, or both are required or the service data flow is not subject to any end user charging. If the charging method identifies that the service data flow is not subject to any end user charging, a Charging key shall not be included in the PCC rule for that service data flow, along with other charging related parameters. If the charging method is omitted the PCEF shall apply the default charging method as determined at IP‑CAN session establishment (see clause 6.4). The Charging method is mandatory if there is no default charging method for the IP‑CAN session.
The Measurement method indicates what measurements apply to charging for PCC rule.
The Service Identifier Level Reporting indicates whether the PCEF shall generate reports per Service Identifier. The PCEF shall accumulate the measurements from all PCC rules with the same combination of Charging key/Service identifier values in a single report.
The Application function record information identifies an instance of service usage. A subsequently generated usage report, generated as a result of the PCC rule, may include the Application function record information, if available. The Application Function Record Information may contain the AF Charging Identifier and/or the Flow identifiers. The report is however not restricted to include only usage related to the Application function record information reported, as the report accumulates the usage for all PCC rules with the same combination of Charging key/Service identifier values. If exclusive charging information related to the Application function record information is required, the PCRF shall provide a service identifier, not used by any other PCC rule of the IP‑CAN session at this point in time, for the AF session.
NOTE 10: For example, the PCRF may be configured to maintain a range of service identifier values for each service which require exclusive per instance charging information. Whenever a separate counting or credit management for an AF session is required, the PCRF shall select a value, which is not used at this point in time, within that range. The uniqueness of the service identifier in the PCEF ensures a separate accounting/credit management while the AF record information identifies the instance of the service.
The Gate indicates whether the PCEF shall let a packet identified by the PCC rule pass through (gate is open) the PCEF, or the PCEF shall discard (gate is closed) the packet.
NOTE 11: A packet, matching a PCC Rule with an open gate, may be discarded due to credit management reasons.
The QoS Class Identifier for the service data flow. The QoS class identifier represents the QoS parameters for the service data flow. The PCEF maintains the mapping between QoS class identifier and the QoS concept applied within the specific IP‑CAN. The bitrate information is separate from the QoS class identifier value.
The bitrates indicate the authorized bitrates at the IP packet level of the SDF, i.e. the bitrates of the IP packets before any IP‑CAN specific compression or encapsulation.
The UL maximum-bitrate indicates the authorized maximum bitrate for the uplink component of the service data flow.
The DL maximum-bitrate indicates the authorized maximum bitrate for the downlink component of the service data flow.
The UL guaranteed-bitrate indicates the authorized guaranteed bitrate for the uplink component of the service data flow.
The DL guaranteed-bitrate indicates the authorized guaranteed bitrate for the downlink component of the service data flow.
The ‘Maximum bitrate’ is used for enforcement of the maximum bit rate that the SDF may consume, while the ‘Guaranteed bitrate’ is used by the PCEF to determine resource allocation.
The UL sharing indication indicates that resource sharing in uplink direction for service data flows with the same value in their PCC rule shall be applied by the PCEF as described in clauses 6.1.14 and 6.2.2.4.
The DL sharing indication indicates that resource sharing in downlink direction for service data flows with the same value in their PCC rule shall be applied by the PCEF as described in clauses 6.1.14 and 6.2.2.4.
The Redirect indicates whether the uplink part of the service data flow should be redirected to a controlled address.
The Redirect Destination indicates the target redirect address when Redirect is enabled.
The Allocation and Retention Priority indicates the allocation, retention and priority of the service data flow. The ARP contains information about the priority level, the pre-emption capability and the pre-emption vulnerability. The Allocation and Retention Priority resolves conflicts of demands for network resources.
The Bind to Default Bearer indicates that the dynamic PCC rule shall be bound to the default bearer.
The PS to CS session continuity is present if the service data flow is a candidate for vSRVCC according to TS 23.216 [28].
The access network information reporting parameters (User Location Report, UE Timezone Report) instruct the PCEF about what information to forward to the PCRF when the PCC rule is activated, modified or removed.
The Monitoring Key is the reference to a resource threshold. Any number of PCC Rules may share the same monitoring key value. The monitoring key values for each service shall be operator configurable.
The Indication of exclusion from session level monitoring indicates that the service data flow shall be excluded from the IP-CAN session usage monitoring.
The Traffic Steering Policy Identifier(s) is a reference to a pre-configured traffic steering policy at the PCEF as defined in clause 6.11.1.
The Allowed Access Type applies only in case of NBIFOM. The Allowed Access Type indicates the IP-CAN type that is to be used for the transfer of traffic identified by the PCC rule. The PCEF uses the Allowed Access Type as input for the bearer binding. When network-initiated NBIFOM mode applies, the PCEF shall also create / modify / delete a corresponding Routing Rule for such a PCC rule at the UE as described in clause 6.1.18.2. When the Allowed Access Type is not provided within a PCC rule, the traffic identified by the PCC rule is to be transferred on the default NBIFOM access.
The Routing Rule Identifier applies only in case of NBIFOM. The PCRF provides it to the PCEF only when network-initiated NBIFOM mode applies.
The UL Maximum Packet Loss Rate indicates the maximum rate for lost packets that can be tolerated in the uplink direction.
The DL Maximum Packet Loss Rate indicates the maximum rate for lost packets that can be tolerated in the downlink direction.
6.3.2 Policy and charging control rule operations
Policy and charging control rule operations consist of activation, modification and de-activation of PCC rules.
Activation of a dynamic PCC rule provides the PCC rule information to the PCEF via the Gx reference point.
Activation of a predefined PCC rule provides an identifier of the relevant PCC rule to the PCEF via the Gx reference point.
Activation of a predefined PCC rule, not known in the PCRF, may be done by the PCEF based on operator policy. The PCEF may only activate such predefined PCC rule if there are no UE provided traffic mapping information related to the IP‑CAN bearer. Further restrictions regarding the usage of predefined PCC rules are described in clause 6.3.1.
An active PCC rule means that:
– the service data flow template shall be used for service data flow detection;
– the service data flow template shall be used for mapping of downlink packets to the IP‑CAN bearer determined by the bearer binding;
– the service data flow template shall be used for service data flow detection of uplink packets on the IP‑CAN bearer determined by the bearer binding;
– usage data for the service data flow shall be recorded (further details can be found in clause 6.1.2 Reporting and clause 6.1.3 Credit Management);
– policies associated with the PCC rule, if any, shall be invoked.
– for service data flow detection with an application detection filter, the start or the stop of the application traffic is reported to the PCRF, if applicable and requested by the PCRF. In that case, the notification for Start may include service data flow filters, (if possible to provide) and the application instance identifier associated with the service data flow filters.
A predefined PCC rule is known at least, within the scope of one access point.
NOTE 1: The same predefined PCC rule can be activated for multiple IP‑CAN bearers in multiple IP‑CAN sessions.
A predefined PCC rule is bound to one and only one IP-CAN bearer per IP‑CAN session. For a predefined PCC rule whose service data flow cannot be fully reflected for the uplink direction in terms of traffic mapping information sent to the UE, the PCEF may apply the uplink service data flow detection at additional IP‑CAN bearers with non-GBR QCI of the same IP‑CAN session. The deactivation of such a predefined PCC rule ceases its service data flow detection for the whole IP‑CAN session.
The PCRF may, at any time, modify an active, dynamic PCC rule.
The PCRF may, at any time, deactivate an active PCC rule in the PCEF via the Gx reference point. At IP‑CAN bearer termination all active PCC rules on that bearer are deactivated without explicit instructions from the PCRF to do so.
Policy and charging control rule operations can be also performed in a deferred mode. A PCC rule may have either a single deferred activation time, or a single deferred deactivation time or both.
A PCC rule with only a deferred activation time shall be inactive until that time. A PCC rule with only a deferred deactivation time shall be active until that time. When the rule activation time occurs prior to the rule deactivation time, the rule is inactive until the activation and remains active until the deactivation time occurs. When the rule deactivation time occurs prior to the rule activation time, the rule is initially active until the deactivation time, then remains inactive until the activation time, and then becomes active again. An inactive PCC rule, that has not been activated yet, is still considered to be installed, and may be removed by the PCRF.
The PCRF may modify a currently installed PCC rule, including setting, modifying or clearing its deferred activation and/or deactivation time. When modifying a dynamic PCC rule with a prior and/or new deferred activation and/or deactivation time, the PCRF shall provide all attributes of that rule, including attributes that have not changed.
NOTE 2: In this case, the PCRF omission of an attribute that has a prior value will erase that attribute from the rule.
Deferred activation and deactivation of PCC rules can only be used for PCC rules that belong to the IP‑CAN bearer without traffic mapping information.
NOTE 3: This limitation prevents dependencies on the signalling of changed traffic mapping information towards the UE.
Deferred modification of PCC rules shall not be applied for changes of the QoS or service data flow filter information of PCC rules.