6.3 Policy and charging control rule
23.5033GPPPolicy and charging control framework for the 5G System (5GS)Release 18Stage 2TS
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 PCF to the SMF, while the predefined PCC rules are configured into the SMF, as described in TS 23.501 [2], and only referenced by the PCF.
NOTE 1: The procedure for provisioning predefined PCC rules is out of scope for this specification.
The operator defines the PCC rules.
Table 6.3.1 lists the information contained in a PCC rule, including the information name, the description and whether the PCF may modify this information in a dynamic PCC rule which is active in the SMF. 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.
The differences with table 6.3 in TS 23.203 [4] are shown, either "none" means that the IE applies in 5GS or "removed" meaning that the IE does not apply in 5GS, this is due to the lack of support in the 5GS for this feature or "modified" meaning that the IE applies with some modifications defined in the IE.
Table 6.3.1: The PCC rule information in 5GC
|
Information name |
Description |
Category |
PCF permitted to modify for a dynamic PCC rule in the SMF |
Differences compared with table 6.3. in TS 23.203 [4] |
|---|---|---|---|---|
|
Rule identifier |
Uniquely identifies the PCC rule, within a PDU Session. It is used between PCF and SMF for referencing PCC rules. |
Mandatory |
No |
None |
|
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 1). |
Conditional (NOTE 2) |
Yes |
None |
|
Service data flow template |
For IP PDU traffic: 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. For Ethernet PDU traffic: Combination of traffic patterns of the Ethernet PDU traffic. It is defined in clause 5.7.6.3 of TS 23.501 [2]. |
Mandatory (NOTE 3) |
Conditional (NOTE 4) |
Modified (packet filters for Ethernet PDU traffic added) |
|
Mute for notification |
Defines whether application’s start or stop notification is to be muted. |
Conditional (NOTE 5) |
No |
None |
|
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 (NOTE 22) |
The charging system (CHF) uses the charging key to determine the tariff to apply to the service data flow. |
Yes |
None |
|
|
Service identifier |
The identity of the service or service component the service data flow in a rule relates to. |
Yes |
None |
|
|
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 |
None |
|
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 |
None |
|
Charging method |
Indicates the required charging method for the PCC rule. Values: online or offline or neither. |
Conditional |
No |
None |
|
Service Data flow handling while requesting credit |
Indicates whether the service data flow is allowed to start while the SMF is waiting for the response to the credit request. Only applicable for charging method online. Values: blocking or non-blocking |
No |
New |
|
|
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 |
None |
|
|
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 |
None |
|
|
Service Identifier Level Reporting |
Indicates that separate usage reports shall be generated for this Service Identifier. Values: mandated or not required |
Yes |
None |
|
|
Policy control |
This part defines how to 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). |
Yes |
None |
|
|
5G QoS Identifier (5QI) |
The 5QI authorized for the service data flow. |
Conditional |
Yes |
Modified (corresponds to QCI in TS 23.203 [4]) |
|
QoS Notification Control (QNC) |
Indicates whether notifications are requested from 3GPP RAN when the GFBR can no longer (or can again) be guaranteed for a QoS Flow during the lifetime of the QoS Flow. |
Conditional |
Yes |
Added |
|
Reflective QoS Control |
Indicates to apply reflective QoS for the SDF. |
Yes |
Added |
|
|
UL-maximum bitrate |
The uplink maximum bitrate authorized for the service data flow |
Yes |
None |
|
|
DL-maximum bitrate |
The downlink maximum bitrate authorized for the service data flow |
Yes |
None |
|
|
UL-guaranteed bitrate |
The uplink guaranteed bitrate authorized for the service data flow |
Yes |
None |
|
|
DL-guaranteed bitrate |
The downlink guaranteed bitrate authorized for the service data flow |
Yes |
None |
|
|
UL sharing indication |
Indicates resource sharing in uplink direction with service data flows having the same value in their PCC rule |
No |
None |
|
|
DL sharing indication |
Indicates resource sharing in downlink direction with service data flows having the same value in their PCC rule |
No |
None |
|
|
Redirect |
Redirect state of the service data flow (enabled/disabled) |
Conditional (NOTE 8) |
Yes |
None |
|
Redirect Destination |
Controlled Address to which the service data flow is redirected when redirect is enabled |
Conditional (NOTE 9) |
Yes |
None |
|
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 |
None |
|
Bind to QoS Flow associated with the default QoS rule |
Indicates that the dynamic PCC rule shall always have its binding with the QoS Flow associated with the default QoS rule (NOTE 11). |
Yes |
Modified (corresponds to bind to the default bearer in TS 23.203 [4]) |
|
|
Bind to QoS Flow associated with the default QoS rule and apply PCC rule parameters |
Indicates that the dynamic PCC rule shall always have its binding with the QoS Flow associated with the default QoS rule. It also indicates that the that the QoS related attributes of the PCC rule shall be applied to derive the QoS parameters of the QoS Flow associated with the default QoS rule instead of the PDU Session related parameters Authorized default 5QI/ARP. |
Conditional |
Yes |
Added |
|
PS to CS session continuity |
Indicates whether the service data flow is a candidate for vSRVCC. |
Removed |
||
|
Priority Level |
Indicates a priority in scheduling resources among QoS Flows (NOTE 14). |
Yes |
Added |
|
|
Averaging Window |
Represents the duration over which the guaranteed and maximum bitrate shall be calculated (NOTE 14). |
Yes |
Added |
|
|
Maximum Data Burst Volume |
Denotes the largest amount of data that is required to be transferred within a period of 5G-AN PDB (NOTE 14). |
Yes |
Added |
|
|
Disable UE notifications at changes related to Alternative QoS Profiles |
Indicates to disable QoS Flow parameters signalling to the UE when the SMF is notified by the NG-RAN of changes in the fulfilled QoS situation. The fulfilled situation is either the QoS profile or an Alternative QoS Profile. |
Conditional (NOTE 25) |
Yes |
Added |
|
Precedence for TFT packet filter allocation |
Determines the order of TFT packet filter allocation for PCC rules |
Conditional (NOTE 28) |
Yes |
Added |
|
Access Network Information Reporting |
This part describes access network information to be reported for the PCC rule when the corresponding QoS Flow is established, modified or terminated. |
|||
|
User Location Report |
The serving cell of the UE is to be reported. When the corresponding QoS Flow is deactivated, and if available, information on when the UE was last known to be in that location is also to be reported. |
Yes |
None |
|
|
UE Timezone Report |
The time zone of the UE is to be reported. |
Yes |
None |
|
|
Usage Monitoring Control |
This part describes identities required for Usage Monitoring Control. |
None |
||
|
Monitoring key (NOTE 23) |
The PCF uses the monitoring key to group services that share a common allowed usage. |
Yes |
None |
|
|
Indication of exclusion from session level monitoring |
Indicates that the service data flow shall be excluded from PDU Session usage monitoring |
Yes |
None |
|
|
N6-LAN Traffic Steering Enforcement Control (NOTE 18) |
This part describes information required for N6-LAN Traffic Steering. |
|||
|
Traffic steering policy identifier(s) |
Reference to a pre-configured traffic steering policy at the SMF (NOTE 12). |
Yes |
None |
|
|
AF influenced Traffic Steering Enforcement Control (NOTE 18) |
This part describes information required for AF influenced Traffic Steering. |
|||
|
Data Network Access Identifier |
Identifier(s) of the target Data Network Access (DNAI). It is defined in clause 5.6.7 of TS 23.501 [2]. |
Yes |
Added |
|
|
Per DNAI: Traffic steering policy identifier |
Reference to a pre-configured traffic steering policy at the SMF (NOTE 19). |
Yes |
Added |
|
|
Per DNAI: N6 traffic routing information |
Describes the information necessary for traffic steering to the DNAI. It is described in clause 5.6.7 of TS 23.501 [2] (NOTE 19). |
Yes |
Added |
|
|
Information on AF subscription to UP change events |
Indicates whether notifications in the case of change of UP path are requested and optionally indicates whether acknowledgment to the notifications shall be expected (as defined in clause 5.6.7 of TS 23.501 [2]). |
Yes |
Added |
|
|
Indication of UE IP address preservation |
Indicates UE IP address should be preserved. It is defined in clause 5.6.7 of TS 23.501 [2]. |
Yes |
Added |
|
|
Indication of traffic correlation (NOTE 29) |
Indicates that the target PDU Sessions should be correlated via a common DNAI in the user plane. It is described in clause 5.6.7 of TS 23.501 [2]. |
Yes |
Added |
|
|
Information on User Plane Latency requirements |
Indicates the user plane latency requirements. It is defined in clause 6.3.6 of TS 23.548 [33]. |
Yes |
Added |
|
|
Indication for Simultaneous Connectivity at Edge Relocation |
Indicates request for simultaneous connectivity over source and target PSA from the AF (see clause 5.6.7 of TS 23.501 [2]). |
Yes |
Added |
|
|
Information for EAS IP Replacement in 5GC |
Indicates the Source EAS identifier and Target EAS identifier, (i.e. IP addresses and port numbers of the source and target EAS). (see clause 5.6.7 of TS 23.501 [2]). |
Yes |
Added |
|
|
EAS Correlation indication |
Indicates selecting a common EAS for the application identified by Service data flow template accessed by the UEs with the same Traffic Correlation ID. |
Yes |
Added |
|
|
Traffic Correlation ID |
Identifies a set of UEs. |
Yes |
Added |
|
|
NBIFOM related control Information |
This part describes PCC rule information related with NBIFOM. |
|||
|
Allowed Access Type |
The access to be used for traffic identified by the PCC rule. |
Removed |
||
|
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 the service data flow. It is defined in clause 5.7.2.8 of TS 23.501 [2]. |
Conditional (NOTE 13) |
Yes |
None |
|
DL Maximum Packet Loss Rate |
The maximum rate for lost packets that can be tolerated in the downlink direction for the service data flow. It is defined in clause 5.7.2.8 of TS 23.501 [2]. |
Conditional (NOTE 13) |
Yes |
None |
|
MA PDU Session Control (NOTE 20) |
This part defines information supporting control of MA PDU Sessions |
Yes |
New |
|
|
Application descriptors |
Identifies the application traffic for which MA PDU Session control is required based on the Steering Functionality, the Steering Mode, Steering Mode Indicator and Threshold Values. It is described in clause 5.32.8 of TS 23.501 [2]. |
Conditional (NOTE 27) |
Yes |
New |
|
Steering Functionality |
Indicates the applicable traffic steering functionality. |
Conditional (NOTE 21) |
Yes |
New |
|
Steering Mode |
Indicates the rule for distributing traffic between accesses together with associated steering parameters (if any). |
Conditional (NOTE 21) |
Yes |
New |
|
Steering Mode Indicator |
Indicates either autonomous load-balance operation or UE-assistance operation, if the Steering Mode is set to "Load Balancing", as defined in TS 23.501 [2]. |
Yes |
New |
|
|
Threshold Values |
A Maximum RTT or a Maximum Packet Loss Rate or both. |
Yes |
New |
|
|
Charging key for Non-3GPP access (NOTE 22) |
Indicates the Charging key used for charging packets carried via Non-3GPP access for a MA PDU Session. |
Yes |
New |
|
|
Monitoring key for Non-3GPP access (NOTE 23) |
Indicates the Monitoring key used to monitor usage of the packets carried via Non-3GPP access for a MA PDU Session. |
Yes |
New |
|
|
QoS Monitoring for URLLC |
This part describes PCC rule information related with QoS Monitoring for URLLC. |
|||
|
QoS parameter(s) to be measured |
UL packet delay, DL packet delay or round trip packet delay. |
Yes |
Added |
|
|
Reporting frequency |
Defines the frequency for the reporting, such as event triggered, periodic, or when the PDU Session is released. |
Yes |
Added |
|
|
Target of reporting |
Defines the target of the QoS Monitoring reports, it can be the NEF, the AF or the Local NEF. |
Yes |
Added |
|
|
Indication of direct event notification |
Indicates that the QoS Monitoring event shall be reported by the UPF directly to the NF indicated by the Target of reporting. |
Yes |
Added |
|
|
Alternative QoS Parameter Sets (NOTE 24) (NOTE 26) |
This part defines Alternative QoS Parameter Sets for the service data flow. |
|||
|
Packet Delay Budget |
The Packet Delay Budget in this Alternative QoS Parameter Set. |
Yes |
Added |
|
|
Packet Error Rate |
The Packet Error Rate in this Alternative QoS Parameter Set. |
Yes |
Added |
|
|
UL-guaranteed bitrate |
The uplink guaranteed bitrate in this Alternative QoS Parameter Set. |
Yes |
Added |
|
|
DL-guaranteed bitrate |
The downlink guaranteed bitrate in this Alternative QoS Parameter Set. |
Yes |
Added |
|
|
TSC Assistance Container |
This part defines parameters provided by TSN AF or TSCTSF. The parameters are defined in clause 5.27.2 of TS 23.501 [2]. |
No |
Added |
|
|
Downlink Data Notification Control |
This part describes information required for controlling the sending of Downlink data delivery status event and DDN Failure event notifications as specified in clause 4.15.3 of TS 23.502 [3]. |
|||
|
Notification control for DDD status |
Indicates that notifications of downlink data delivery status are required and the requested type of such notifications. |
Yes |
Added |
|
|
Notification Control for DDN Failure |
Indicates that notifications of DDN Failure are required. |
Yes |
Added |
|
|
NOTE 1: 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 2: 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 SMF or provided in the PCC rule from PCF. NOTE 3: Either service data flow filter(s) or application identifier shall be defined per each rule. NOTE 4: YES, if the service data flow template consists of a set of service data flow filters. NO if the service data flow template consists of an application identifier NOTE 5: Optional and applicable only if application identifier exists within the rule. NOTE 6: Applicable to sponsored data connectivity. NOTE 7: Mandatory if there is no default charging method for the PDU Session. NOTE 8: Optional and applicable only if application identifier exists within the rule. NOTE 9: If Redirect is enabled. NOTE 10: Mandatory when Bind to QoS Flow associated with the default QoS rule is not present. NOTE 11: The presence of this attribute causes the 5QI/ARP/QNC/Priority Level/Averaging Window/Maximum Data Burst Volume of the rule to be ignored for the QoS Flow binding. NOTE 12: 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 13: Optional and applicable only for voice service data flow in this release. NOTE 14: Optional and applicable only when a value different from the standardized value for this 5QI in Table 5.7.4-1 TS 23.501 [2] is required. NOTE 15: Optional and applicable only for GBR service data flow. NOTE 16: Usage of the charging information in described in TS 32.255 [21]. NOTE 17: Only one PCC rule can contain this attribute and this PCC rule shall not contain the attribute Bind to QoS Flow associated with the default QoS rule. NOTE 18: Only one of the two shall be present in a PCC rule. NOTE 19: Per DNAI, a Traffic steering policy identifier and/or N6 traffic routing information can be provided. If the pre-configured traffic steering policy (that is referenced by the Traffic steering policy identifier) contains information that is overlapping with the N6 traffic routing information, the N6 traffic routing information shall take precedence. NOTE 20: Only applicable to a PCC Rules provided to a MA PDU Session. NOTE 21: Mandatory when MA PDU Session Control information is provided. NOTE 22: When a Charging key for Non-3GPP access is provided, the parameters in the Charging Section (other than the Charging key) apply to both accesses and the Charging key (in the Charging Section) shall be used for charging packets carried via the 3GPP access. NOTE 23: When a Monitoring key for Non-3GPP access is provided, the Monitoring key (in the Usage Monitoring Control Section) shall be used to monitor usage of the packets carried via the 3GPP access. NOTE 24: Optional and applicable only for GBR service data flow with QoS Notification Control enabled. NOTE 25: Optional and applicable only for GBR service data flow for which Alternative QoS Parameter Set(s) are provided. NOTE 26: One or more Alternative QoS Parameter Sets can be provided in a prioritized order starting with the Alternative QoS Parameter Set that has the highest priority. NOTE 27: Mandatory in MA PDU Session Control information only when there is application identifier in the service data flow template. NOTE 28: If this parameter is used, it has to be present in every PCC rule of the PDU Session. NOTE 29: The use of traffic correlation is defined in TS 23.501 [2], clauses 5.6.7.1 and 5.29. |
||||
The Rule identifier shall be unique for a PCC rule within a PDU 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 PDU Session.
The Precedence defines in what order the activated PCC rules within the same PDU Session shall be applied at the UPF 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.
NOTE 2: The operator shall ensure that overlap between the predefined PCC rules can be resolved based on precedence of each predefined PCC rule in the SMF. The PCF shall ensure that overlap between the dynamically allocated PCC rules can be resolved based on precedence of each dynamically allocated PCC rule.
For downlink packets all the service data flow templates, activated for the PDU Session shall be applied for service data flow detection and for the mapping to the correct QoS Flow. For uplink packets the service data flow templates activated on their QoS Flow shall be applied for service data flow detection (further details are provided in clause 6.2.2.2).
The Service data flow template may comprise any number of Service data flow filters or an application identifier as is defined in table 6.3.1.
NOTE 3: Predefined PCC rules may include service data flow templates, which support extended capabilities, including enhanced capabilities to identify events associated with application protocols.
A Service data flow filter contains information for matching user plane packets for IP PDU traffic or Ethernet PDU traffic. All Service data flow filters of a Service data flow template shall be of the same type, i.e. either Packet Filters for IP or Ethernet PDU traffic (defined in clause 5.7.6 of TS 23.501 [2]). The Service data flow template information within an activated PCC rule is applied by the SMF to instruct the UPF to identify the packets belonging to a particular service data flow.
For the IP PDU Session type only, the Service data flow template may consist 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 a dynamic PCC rule and one or multiple predefined PCC rules. If so, the PCF shall ensure that there is at most one PCC rule active per application identifier value at any time.
The Mute for notification defines whether notification to the PCF of application’s starts or stops shall be muted. Absence of this parameter means that start/stop notifications shall be sent.
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 4: Assigning the same Charging key for several service data flows implies that the charging does not require the credit management to be handled separately.
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 5: 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 or offline charging is 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 SMF shall apply the default charging method provided within the PDU Session related policy information (see clause 6.4). The Charging method is mandatory if there is no default charging method for the PDU Session.
NOTE 6: With converged charging architecture for 5GC, online charging method also includes usage reporting from the SMF to the CHF. Hence, setting the charging method to online will also result in usage reports and thus allow for offline charging being performed by the CHF.
The Service Data Flow handling while requesting credit indicates either "blocking" if a credit for the Charging Key needs to be granted as a condition for the PCC Rule to be active or "non-blocking" if a credit for the Charging Key has been requested as a condition for the PCC Rule to be active.
The Measurement method indicates what measurements apply to charging for a PCC rule.
The Service Identifier Level Reporting indicates whether the SMF shall generate reports per Service Identifier. The SMF 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 (i.e. CDR), generated as a result of the PCC rule by the SMF, 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. If exclusive charging information related to the Application function record information is required, the PCF shall provide a service identifier, not used by any other PCC rule of the PDU Session at this point in time, for the AF session.
NOTE 7: For example, the PCF 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 PCF shall select a value, which is not used at this point in time, within that range. The uniqueness of the service identifier in the SMF ensures a separate accounting/credit management while the AF record information identifies the instance of the service.
The Gate indicates whether the SMF shall instruct the UPF to let a packet identified by the PCC rule pass through (gate is open) to discard the packet (gate is closed).
NOTE 8: A packet, matching a PCC Rule with an open gate, may be discarded due to credit management reasons.
The 5G QoS Identifier, 5QI, represents the QoS parameters for the service data flow. The 5G QoS identifier is scalar and accommodates the need for differentiating QoS in both 3GPP and non-3GPP access type.
The bitrates indicate the authorized bitrates at the IP packet level of the SDF, i.e. the bitrates of the IP packets before any access 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 SMF to determine resource allocation demands.
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 SMF as described in clause 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 SMF as described in clause 6.2.2.4.
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 Priority Level is signalled together with the 5QI to the (R)AN and UPF, only when a value different from the standardized value in the QoS characteristics Table 5.7.4-1 in TS 23.501 [2] is required.
The Averaging Window is signalled together with the 5QI to the (R)AN and UPF, only when a value different from the standardized value in the QoS characteristics Table 5.7.4-1 in TS 23.501 [2] is required.
The Maximum Data Burst Volume is signalled together with the 5QI to the (R)AN, only when a value different from the standardized value in the QoS characteristics Table 5.7.4-1 in TS 23.501 [2] is required.
The Bind to QoS Flow associated with the default QoS rule indicates that the SDF shall be bound to the QoS Flow associated with the default QoS rule. The presence of this parameter attribute causes the 5QI/ARP of the rule to be ignored by the SMF during the QoS Flow binding.
The Bind to QoS Flow associated with the default QoS rule and apply PCC rule parameters indicates that the SDF shall be bound to the QoS Flow associated with the default QoS rule and that the QoS related attributes of the PCC rule shall be applied by the SMF to derive the QoS parameters of the QoS Flow associated with the default QoS rule instead of the PDU Session related information Authorized default 5QI/ARP.
NOTE 9: The Bind to QoS Flow associated with the default QoS rule and apply PCC rule parameters Indication has to be used whenever the PDU Session related information Authorized default 5QI/ARP (as described in clause 6.3.1) cannot be directly used as the QoS parameters of the QoS Flow associated with the default QoS rule, for example when a GBR 5QI is used or the 5QI priority level has to be changed.
The QoS Notification Control, QNC, indicates whether notifications are requested from the access network (i.e. 3GPP RAN) when the GFBR can no longer (or can again) be guaranteed for a QoS Flow during the lifetime of the QoS Flow. If it is set and the GFBR can no longer (or can again) be guaranteed, the access network (i.e. 3GPP RAN) sends a notification towards the SMF, which then notifies the PCF.
The Disable UE notifications at changes related to Alternative QoS Profiles parameter indicates to disable QoS Flow parameters signalling to the UE when the SMF is notified by the NG-RAN of changes in the fulfilled QoS situation. The fulfilled situation is either the QoS profile or an Alternative QoS Profile.
The Precedence for TFT packet filter allocation parameter determines the order in which TFT packet filters are allocated for PCC rules. The PCF may include this parameter if there is a possibility to run into a restriction regarding the number of TFT packet filters that can be allocated for the PDU Session and interworking with EPS with N26 deployment is supported (see also clause 4.11.1 of TS 23.502 [3]).
NOTE 9a: PCF can know that interworking with EPS with N26 is supported based on DNN and S-NSSAI of the PDU Session.
The Reflective QoS Control indicates to apply reflective QoS for the service data flow. The indication is used to control the RQI marking in the DL packets of the service data flow and may trigger the sending of the RQA parameter for the QoS Flow the service data flow is bound to. Reflective QoS is defined in clause 5.7.5 of TS 23.501 [2].
NOTE 10: While the UE applies a standardized value for the precedence of all UE derived QoS rules, PCC rules require different precedence values and PCF configuration has to ensure that there is a large enough value range for the precedence of PCC rules corresponding to UE derived QoS rules. To avoid that the precedence of network provided QoS rules need to be changed when Reflective QoS is activated and filters are overlapping, the PCF will take the standardized value for the precedence of UE derived QoS rules into account when setting the precedence value of PCC rules subject to Reflective QoS.
The Reflective QoS Control parameter shall not be used for the PCC rule with match-all SDF template. If PCC rule with match-all SDF template is present, the Reflective QoS Control parameter shall not be used for PCC rules which contain the Bind to QoS Flow of the default QoS rule parameter, either.
The N6-LAN Traffic Steering Enforcement Control contains Traffic steering policy identifier(s) for steering traffic onto N6-LAN to the appropriate N6 service functions deployed by the operator.
The access network information reporting parameters (User Location Report, UE Timezone Report) instruct the SMF about what information to forward to the PCF 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 PDU Session usage monitoring.
The AF influenced Traffic Steering Enforcement Control may contain:
– a set of DNAI(s) (i.e. a reference to the DNAI(s) the SMF needs to consider for UPF selection/reselection), an optional Indication of traffic correlation and, per DNAI, a corresponding Traffic steering policy identifier (i.e. a reference to a pre-configured traffic steering policy at the SMF), and/or a corresponding N6 traffic routing information (when the N6 traffic routing information is provided explicitly as part of the AF influence request, as described in clause 5.6.7 of TS 23.501 [2]), or;
– an AF subscription to UP change events parameter which contains subscription information defined in clause 5.2.8.3 of TS 23.502 [3] for the change of UP path Event Id i.e. an Indication of early and/or late notification and information on where to provide the corresponding notifications (Notification Target Address + Notification Correlation ID as specified in clause 4.15.1 of TS 23.502 [3]) and optionally an indication of "AF acknowledgment to be expected" to the corresponding notifications as described in clause 5.6.7 of TS 23.501 [2].
– a user plane latency requirements parameter which contains AF requested information on the requirements for user plane latency defined in TS 23.548 [33].
– an indication for Simultaneous Connectivity at Edge Relocation, which includes Keep existing PSA indication to provide guidance to the network on whether to provide simultaneous connectivity over source and target PSA at edge relocation; also, optionally a related Keep existing PSA timer that indicates the minimum time interval to be considered for inactivity for the traffic described before the connectivity over the source PSA may be removed, as defined in TS 23.548 [33].
– an EAS Correlation indication, which indicates selecting a common EAS for the application identified by Service data flow template accessed by the UEs with the same Traffic Correlation ID.
– a Traffic Correlation ID, which identifies a set of UEs.
Editor’s note: How Traffic Correlation ID is designed is FFS.
The Traffic Steering Enforcement Control may contain Indication of UE IP address preservation. The SMF takes this indication into account when determining whether to reselect PSA UPF, as specified in clause 5.6.7 of TS 23.501 [2].
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 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.
The Application descriptors provides one or several instances of the OSId and OSAppId combination. It is used by the UE to identify the application traffic for which steering is required based on the Steering Functionality, the Steering Mode, the Steering Mode Indicator and the Threshold Values.
The Steering Functionality indicates the method for how traffic matching the SDF template in the UPF or a Traffic descriptor in the UE is sent over the MA PDU Session. The method ATSSS_LL indicates that the traffic matching the SDF template is sent over the MA PDU Session without additional tunnelling, e.g. with IP flow switching. The method MPTCP indicates that the traffic matching the SDF template is sent over the MA PDU Session using MPTCP.
The Steering Mode indicates the rule for distributing downlink SDFs in the UPF or uplink traffic in the UE between accesses, together with the associated steering parameters. The PCF may indicate separate values for uplink and downlink directions. The available Steering Modes are defined in TS 23.501 [2].
The Steering Mode Indicator indicates that the UE or the UPF or both may change the steering parameters provided in the Steering Mode and may adjust the traffic steering based on their own decisions, as further defined in TS 23.501 [2]. When the PCF selects the Load-Balancing Steering Mode for both the uplink and the downlink, and the PCF provides a Steering Mode Indicator for the uplink equal to UE-assistance operation, then the PCF shall provide the same Steering Mode Indicator for the downlink.
The Threshold Values indicate the authorized RTT or Packet Loss Rate for a SDF. The PCF may include one threshold value for RTT and one threshold value for Packet Loss Rate per SDF. The PCF may indicate separate values for uplink and downlink directions. The Steering Modes that may use the threshold values and how the UE and UPF enforces them are defined in TS 23.501 [2].
The Charging key for Non-3GPP access indicates the Charging key that shall be used for charging the detected service data flow traffic carried via Non-3GPP access. The other charging related parameters apply for both accesses.
The Monitoring key for Non-3GPP access indicates the Monitoring key that shall be used for monitoring the usage of the detected service data flow traffic carried via Non-3GPP access.
The QoS parameter(s) to be measured indicates the UL packet delay, DL packet delay or round trip packet delay between the UE and the UPF is to be monitored when the QoS Monitoring for URLLC is enabled for the service data flow.
The Reporting frequency indicates the frequency for the reporting, such as event triggered, periodic, or when the PDU Session is released. The following applies:
– If the Reporting frequency indicates "periodic", the reporting period shall also be included in the PCC rule.
– The reporting period shall also be used for reporting measurement failure in any of the Reporting frequency modes "periodic" or "event triggered": if no measurement result is available in the UPF within the reporting period, the UPF shall report to the SMF and the SMF shall report to the PCF or to the AF indicating a measurement failure.
– If the Reporting frequency indicates "event triggered", the reporting period, Reporting threshold(s) and the minimum waiting time shall also be included in the PCC rule. The Reporting threshold(s) indicates the measurement threshold for each of the included QoS parameter(s) to be measured, i.e. the UL packet delay, DL packet delay or round trip packet delay. When Reporting threshold(s) is exceeded, the UPF shall report to the SMF and the SMF shall report to the PCF or to the AF. If more than one value is received at one given point of time for UL packet delay, DL packet delay or round trip packet delay respectively, the SMF reports the minimum and maximum packet delays to the PCF or the AF. The SMF sends the first report when the Reporting threshold is exceeded and the minimum waiting time is applied for the subsequent report (if the threshold is exceeded after the waiting time).
The Target of reporting indicates the target for the QoS Monitoring reports sent as notifications. It can be either the NEF, the AF or the Local NEF, indicated as Notification Target Address + Notification Correlation ID.
The Indication of direct event notification indicates that the QoS Monitoring reports shall be sent by the UPF directly to the NF indicated by the Target of reporting (i.e. to the Local NEF or the AF as described in clause 6.4 of TS 23.548 [33]).
The Alternative QoS Parameter Set(s) define alternative set(s) of QoS parameters for the service data flow. Every set consists of a PER, a PDB, as well as an UL and a DL guaranteed bitrate QoS parameter.
The content of the TSC Assistance Container is defined in clause 5.27.2 of TS 23.501 [2].
The Downlink Data Notification Control applies to the control of subscription to Downlink Data Delivery status event notifications and DDN Failure event notifications as specified in clause 4.15.3 of TS 23.502 [3]. The following parameters are included:
– The Notification control for DDD status applies as described in clause 4.15.3.2.8 of TS 23.502 [3] and contains the following parameters:
– indication that notifications of Downlink Data Delivery status are required; and
– the requested type of such notifications (notifications about downlink packets being buffered, and/or discarded).
– The Notification Control for DDN Failure applies as described in clause 4.15.3.2.9 of TS 23.502 [3] and contains the following parameters:
– indication that notifications of DDN Failure are required.
NOTE 11: Downlink Data Notification Control information is provided to assist the SMF in the generation/update of N4 information. The PCF will not be notified about the Downlink data delivery status events or the DDN Failure events.
6.3.2 Policy and charging control rule operations
Policy and Charging Rule operations consist of activation, modification and de-activation of PCC rules. The PCF may activate, modify and deactivate a PCC rule at any time. However, the modification is applicable to dynamic PCC rules only.
Activation of a dynamic PCC rule provides the PCC rule information to the SMF. Activation of a predefined PCC rule provides an identifier of the relevant PCC rule to the SMF.
Each PCC rule shall be installed for a single QoS Flow only (for further details about predefined PCC rules see below).
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 QoS Flow determined by the QoS Flow binding;
– the service data flow template shall be used for service data flow detection of uplink packets on the PDU Session determined by the QoS Flow binding;
– usage data for the service data flow shall be recorded;
– 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 PCF, if applicable and requested by the PCF. 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.
– Either one of the conditions below:
– a credit has been granted for the service data flow. Applicable when the Charging method is set to "online" and the Service Data Flow handling while requesting credit is set to "blocking"; or
– a credit has been requested for the service data flow. Applicable when the Charging method is set to "online" and the Service Data Flow handling while requesting credit is set to "non-blocking".
A predefined PCC rule is known at least, within the scope of one PDU Session.
NOTE 1: The same predefined PCC rule can be activated for multiple QoS Flows in multiple PDU Sessions.
A predefined PCC rule is bound to one and only one QoS Flow per PDU 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 SMF may request the UPF to apply the uplink service data flow detection at additional QoS Flows with non-GBR 5QI of the same PDU Session. The deactivation of such a predefined PCC rule ceases its service data flow detection for the whole PDU Session.
The PCF may, at any time, deactivate an active PCC rule in the SMF. At QoS Flow termination all active PCC rules on that QoS Flow are deactivated without explicit instructions from the PCF 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 PCF. When modifying a dynamic PCC rule by setting, modifying or clearing its deferred activation and/or deactivation time or by changing any other attribute of a PCC rule having a deferred activation and/or deactivation time, the PCF shall provide all attributes of that PCC rule, including attributes that have not changed.
NOTE 2: In this case, the PCF 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 QoS Flow associated with the default QoS rule that allows all UL packets.
Deferred modification of PCC rules shall not be applied for changes of the QoS or service data flow filter information of PCC rules.
NOTE 3: This limitation prevents dependencies on the signalling of changed traffic mapping information towards the UE.