4.2.6 Provisioning and Enforcement of Policy Decisions

29.5123GPP5G SystemRelease 18Session Management Policy Control ServiceStage 3TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

4.2.6.1 General

Policy Decisions are provided from the PCF to the NF service consumer (SMF) as part of the following service operations:

– the Npcf_SMPolicyControl_Create Service Operation described in clause 4.2.2;

– the SM Policy Association Notification request as part of the Npcf_SMPolicyControl_UpdateNotify Service Operation as described in clause 4.2.3.2; and

– the Npcf_SMPolicyControl_Update service operation as described in clause 4.2.4

Policy decisions shall be encoded within the SmPolicyDecision data structure defined in clause 5.6.2.4

Policy decisions may include:

– Session Rule(s), as described in clause 4.1.4.3, encoded within the "sessRules" attribute;

– PCC Rule(s), as described in clause 4.1.4.2, encoded within the "pccRules" attribute;

– QoS decision(s), as described in clause 4.1.4.4.3, which can be referenced from PCC rule(s), encoded within the "qosDecs" attribute;

– Charging decision(s), as described in clause 4.1.4.4.4, which can be referenced from PCC rule(s), encoded within the "chgDecs" attribute;

– Traffic control decision(s), as described in clause 4.1.4.4.2, which can be referenced from PCC rule(s), encoded within the "traffContDecs" attribute;

– Usage monitoring control decision(s), as described in clause 4.1.4.4.5, which can be referenced from PCC rule(s) and session rule(s), encoded within the "umDecs" attribute;

– QoS monitoring decision, as described in clause 4.1.4.4.6, which can be referenced from PCC rule(s), encoded within the "qosMonDecs" attribute;

– Condition(s) that can be referenced from PCC rule(s) and session rule(s), encoded within the "conds" attribute;

– QoS characteristics for non-standard 5QIs and non-preconfigured 5QIs provided within the "qosChars" attribute;

– A reflective QoS timer;

– Policy control request triggers and applicable additional information, e.g. Revalidation Time, PRA information;

– Last requested rule data;

– Last requested usage data;

– Default charging method of the PDU session;

– "PDU Session with offline charging only" indication;

– Charging information;

– P-CSCF Restoration Indication;

– IP index information;

– Presence Reporting Area information;

– TSC user plane node management information;

– port management information for the DS-TT port;

– port management information for the NW-TT port;

– The request of the PDU session termination;

– Usage of QoS flow;

– Redundant PDU session indication.

For the Npcf_SMPolicyControl_Create Service Operation, the SmPolicyDecision data structure shall contain a full description of all policy decision(s) provided by the PCF for the policy association.

For the Npcf_SMPolicyControl_UpdateNotify service operation for the SM Policy Association Notification request and for the Npcf_SMPolicyControl_Update service operation, the SmPolicyDecision data structure shall contain a description of the changes to the policy decision(s) with respect to the last provided policy decision(s) for the corresponding policy association. The redundant PDU session indication, the default charging method of the PDU session, the "PDU Session with offline charging only" indication, the charging information, the Reflective QoS Timer and the IP index information shall not be updated by the PCF.

If no other rule is defined for specific data types within the SmPolicyDecision data structure, the encoding of changes of the policy decision(s) in the SmPolicyDecision data structure shall follow the following principles:

1) To modify an attribute with a value of type map (e.g. the "sessRules" attribute, the "pccRules" attribute, the "qosDecs" attribute, the "traffContDecs" attribute, the "umDecs" attribute, the "conds" attribute, etc.), this attribute shall be provided with a value containing a map with entries according to the following principles:

– A new entry of the map shall be added by supplying a new identifier (e.g. rule / decision identifier) as the key and the corresponding structured data type instance (e.g. PCC rule) with the complete content as the value.

– An existing entry of the map shall be modified by supplying the existing identifier as the key and the corresponding structured data type instance as the value, with the same existing identifier (e.g. set the "qosId" to the same existing QoS data decision identifier), which shall describe the modifications following bullets 1 to 6.

– An existing entry of the map shall be deleted by supplying the existing identifier as the key and "NULL" as the value.

– For an unmodified entry of the map, no entry needs to be provided within the map.

2) To modify an attribute with a structured data type instance as the value, the attribute shall be provided with a value containing a structured data type instance with entries according to bullets 1 to 6.

3) To modify an attribute with another type than map or structured data type as the value, the attribute shall be provided with a complete representation of its value, which shall replace the previous value.

4) To create an attribute of any type, the attribute shall be provided with a complete representation of its value.

5) To delete an attribute of any type, the attribute shall be provided with "NULL" as the value.

NOTE 1: Attributes that are allowed to be deleted need to be marked as "nullable" within the OpenAPI file in Annex A.

6) Attributes that are not added, modified or deleted do not need to be provided.

NOTE 2: In the related data structures, no attribute can be marked as mandatory except the attribute containing the identifier (e.g. rule / decision identifier).

The PCF shall not remove a provisioned policy decision data or condition data from the SMF when the associated reference(s) from the PCC rule(s) or session rule(s) are still valid except the usage montoring data referred by the pre-defined PCC rule(s) (see clause 4.2.6.5.3.2 for further information). If the PCF determines that the policy decision or condition data shall be used for future PCC or session rule(s), the PCF may keep a policy decision data or condition data valid when the PCF removes all the PCC rule or session rule(s) referring to that policy decision data or condition data; otherwise the PCF shall remove the provisioned policy decision data or condition data when the PCF removes all the PCC or session rule(s) referring to the policy decision data or condition data.

When the NF service consumer (SMF) accepts the notification of policy updates, and/or when after receiving the response to the request of policies the SM Policy association is retained in the NF service consumer (SMF), if the installation/activation of one or more new PCC rule(s) or the installation of one or more session rule(s) (i.e. rules which were not previously successfully installed) fails, although the failed PCC rule(s) or session rule(s) are removed, the policy decision and/or condition data which are referred by the failed PCC rule(s) or session rule(s) may remain applicable in the SMF until the PCF removes them. If the PCF determines that the policy decision or condition data that remain applicable shall be used for future PCC or session rule(s) (e.g. because the PCF reattempts to install the failed PCC rule) the PCF may keep these policy decision data or condition data valid; otherwise the PCF shall immediately remove these policy data or condition data from the SMF.

NOTE 3: Due to internal policies, the SMF could decide to remove the policy decision and/or condition data not referred by any PCC and/or session rule(s) before the PCF decides to remove them. When the PCF decides to remove the policy decision and/or condition data that were silently removed by the SMF, the SMF accepts the removal indication, as specified in clauses 4.2.3.26 and 4.2.4.26. When the PCF decides to reuse the policy decision and/or condition data that were silently removed by the SMF, the SMF reports PCC and/or session rule error as specified in clauses 4.2.3.16, 4.2.4.15, 4.2.3.20 and 4.2.4.21.

NOTE 4: When the PCF notification of policy updates is rejected as specified in clauses 4.2.3.16 and 4.2.3.20 with a HTTP "400 Bad Request" status code, the whole update is rejected, including the provided policy decision and/or condition data. When the SMF reports PCC and/or session rule(s) error as specified in clauses 4.2.4.15 and 4.2.4.21 for all the provisioned PCC rule and/or session rule(s), the valid policy decision and/or condition data provided in the corresponding update response can remain valid in the SMF until the PCF removes them.

The error handling for the policy decision and/or condition data which are not referred by any PCC rule and/or session rule stored at the SMF is defined in clause 4.2.3.26 and 4.2.4.26.

4.2.6.2 PCC Rules

4.2.6.2.1 Overview

The PCF may perform an operation on a single PCC rule or a group of PCC rules. The impacted PCC rule(s) shall be included in the "pccRules" map attribute within the SmPolicyDecision data structure with the associated "pccRuleId" as the key of the map. For activating a pre-defined PCC rule or installing or modifying a dynamic PCF-provisioned PCC rule, the corresponding PccRule data structure shall be provided as the map entry value. For deactivating or removing a PCC rule, the map entry value shall be set to "NULL".

NOTE 1: When deactivating a predefined PCC rule that is activated in more than one QoS flow, this predefined PCC rule is deactivated simultaneously in all the QoS flows where it was previously activated.

In order to activate a pre-defined PCC rule, the PCF shall include within the PccRule data structure the pre-defined PCC rule identifier within the "pccRuleId" attribute and the "refCondData" attribute, if applicable, i.e. the PccRule data structure is empty, except for the "pccRuleId" attribute and the "refCondData" attribute, if applicable. If the "refCondData" attribute is applicable, a "conds" attribute containing the corresponding ConditionData data structure referred by this PCC rule shall be included in the SmPolicyDecision data structure, if it has not been previously provided.

In order to install a new dynamic PCF-provisioned PCC rule, the PCF shall further set other attributes within the PccRule data structure as follows:

– It may include the precedence of a PCC rule among the other PCC rules of the PDU session, within the "precedence" attribute. Within a PDU session, the PCF shall authorize different precedence values for the PCC rules whose packet filters contained within the "flowDescription" attribute or the "ethFlowDescription" attribute include the "packetFilterUsage" attribute set to "true".

NOTE 2: The SMF sets the precedence value of a QoS rule to the precedence value of the PCC rule for which the QoS rule is generated. The UE considers as an error when two or more QoS rules associated with a PDU session have identical precedence values.

– It shall include either the flow information within the "flowInfos" attribute or the application identifier within the "appId" attribute.

– It shall include one reference to the QosData data structure within the "refQosData" attribute. In this case, a "qosDecs" attribute containing the corresponding QoS data policy decision shall be included in the SmPolicyDecision data structure, if it has not been previously provided.

– It may include one or more reference(s) to the QosData structure within the "refAltQosParams" attribute to refer to the Alternative QoS parameter set(s) of the service data flow. In this case, a "qosDecs" attribute containing the corresponding alternative QoS data policy decision(s) shall be included in the SmPolicyDecision data structure, if it has not been previously provided,

– It shall include one reference to the TrafficControlData data structure within the "refTcData" attribute. In this case, a "traffContDecs" attribute containing the corresponding Traffic Control data policy decision shall be included in the SmPolicyDecision data structure, if it has not been previously provided.

– It may include one reference to the ChargingData data structure within the "refChgData" attribute. In this case, a "chgDecs" attribute containing the corresponding Charging Data policy decision shall be included in the SmPolicyDecision data structure, if it has not been previously provided.

– It may include one reference to the UsageMonitoringData data structure within the "refUmData" attribute. In this case, a "umDecs" attribute containing the corresponding Usage Monitoring data policy decision shall be included in the SmPolicyDecision data structure, if it has not been previously provided.

– It may include one reference to the QosMonitoringData data structure within the "refQosMon" attribute. In this case, a "qosMonDecs" attribute containing the corresponding QoS Monitoring data policy decision shall be included in the SmPolicyDecision data structure, if it has not been previously provided.

– It may include one reference to the ConditionData data type within the "refCondData" attribute. In this case, a "conds" attribute containing the corresponding Condition Data shall be included in the SmPolicyDecision data structure, if it has not been previously provided.

In order to modify an existing dynamic PCF-provisioned PCC rule, the PCF shall further set other attributes within the PccRule data structure as follows:

– If the PCF needs to modify attribute(s) within a PCC rule, the PCF shall include the modified attribute(s) with their new value(s) within the associated PccRule data instance in the SmPolicyDecision data structure. Previously supplied attribute(s) not supplied in the modified PCC rule instance shall remain valid.

– If the PCF only needs to modify the content of the referenced policy decision data (e.g. QosData, ChargingData, etc.) and/or condition data for one or more PCC rule(s), the PCF shall include, within the SmPolicyDecision data structure, the corresponding policy decision data and/or condition data within the corresponding map attribute(s) (e.g. include the QoS data decision(s) within the "qosDecs" attribute).

– In order to modify the content of the referenced condition data for one or more existing pre-defined PCC rule(s), the PCF shall include, within the SmPolicyDecision data structure, the corresponding condition data within the "conds" attribute.

NOTE 3: To update a policy decision data and/or condition data instance, the PCF can provide only the modified attribute(s) with their new value(s) or could provide both, the modified attribute(s) with their new value(s) and the unmodified attributes. When only the modified attribute(s) are provided, the previously supplied attribute(s) not supplied in the modified policy decision data and/or condition data instance remain valid.

– PCF may also perform a full replacement of a policy decision data and/or condition data instance by including the new reference to the policy decision data and/or condition data instance within the associated PCC rule and the corresponding policy decision and/or condition data in the SmPolicyDecision data structure, if it has not been previously provided.

The PCF may combine multiple of the above PCC rule operations in a single message.

The SMF shall ensure that at least one PCC Rule bound to the default QoS flow is activated for the PDU Session. If the PCF does not provision any PCC rule, the SMF shall activate at least one pre-defined PCC rule which is not known by the PCF and bind it to the default QoS flow.

If the authorized default QoS is GBR type or delay critical GBR type as defined in clause 4.2.6.3.3, to ensure that one and only one of the authorized PCC rules is bound to the default QoS flow the PCF shall indicate that one and only one PCC rule is bound to the default QoS flow as defined in clause 4.2.6.2.10. The SMF shall not bind any other PCC rule to the default QoS flow with a GBR or delay critical GBR 5QI.

4.2.6.2.2 Gate Function

The Gate Function is a user plane function that permits to control, i.e. enabling or disabling, the forwarding of data packets belonging to a service data flow. A gate is provisioned by the PCF within a PCC rule, enforced by the SMF and ultimately applied by the UPF.

If a PCC rule contains the "flowInfos" attribute applicable for uplink service data flow(s), it shall describe a gate for the corresponding uplink service data flow(s). If a PCC rule contains the "flowInfos" attribute(s) applicable for downlink service data flow(s), it shall describe a gate for the corresponding downlink service data flow(s). If the PCC rule contains an "appId" attribute, it shall describe a gate for the corresponding detected application traffic. In order to do so, the "flowStatus" attribute within the TrafficControlData data structure to which the PCC rule refers shall describe if uplink and/or downlink gate(s) is/are open or closed.

The commands to open or close a gate shall lead to enabling or disabling the passage of the corresponding data packets. If a gate is closed, all data packets of the related service data flow(s) are dropped by the UPF. If a gate is open, the data packets of the related service data flow(s) are allowed to be forwarded by the UPF.

4.2.6.2.3 Policy enforcement for authorized QoS per PCC Rule

The PCF may provide the authorized QoS for a PCC rule to the SMF. The Provisioning of the authorized QoS per PCC Rule shall be performed using the PCC rule provisioning procedure defined in clause 4.2.6.2.1. For a PCF-provided PCC rule, the authorized QoS shall be encoded using the QosData data structure. The PCF shall include for this purpose a reference to this QosData data structure within the "refQosData" attribute of the PCC rule and a "qosDecs" attribute containing this QoS data decision within the SmPolicyDecision data structure.

If the authorized QoS is provided for a PCC rule, the SMF shall derive the associated QoS profile towards the access network, if applicable, the associated QoS rule towards the UE, if applicable, and the associated QoS information with the PDR(s) towards the UPF.

4.2.6.2.4 Redirect Function

When the ADC feature is supported, the PCF may provide the redirect instructions for one or several dynamic PCC rule(s) to the SMF. This Provisioning shall be performed using the policy provisioning procedure defined in clause 4.2.6.1.

The "traffContDecs" attribute within the SmPolicyDecision is used to provide traffic control decision(s). The redirect instructions shall be encoded using the "redirectInfo" attribute within the corresponding TrafficControlData data structure, and used to provide a RedirectInformation data structure with the following components:

– The "redirectEnabled" attribute to indicate whether redirect is enabled or not. It shall be included and set to true when the redirect instruction is initially provisioned and may be included in subsequent updates of the RedirectInformation to enable or disable the redirect instruction.

– The redirect address may be provided using the "redirectAddressType" and "redirectServerAddress" attributes or it may be preconfigured in the SMF/UPF. A redirect destination provided within the "redirectServerAddress" attribute for a dynamic PCC Rule shall override the redirect destination preconfigured in the SMF/UPF.

NOTE 1: The SMF/UPF uses the preconfigured redirection address only if it can be applied to the application traffic being detected, e.g. the redirection destination address could be preconfigured on a per application identifier basis.

If redirect action(s) need to be applied to a dynamic PCC rule, this PCC rule shall reference a traffic control decision with the relevant redirect instructions. If a dynamic PCC rule includes flow information for UE IPv4 address and IPv6 prefix address(es) related to the same application identifier and the ADCmultiRedirection feature is supported, the "addRedirectInfo" attribute including more than one RedirectInformation data structure may be provided simultaneously to the redirect instruction.

If the "redirectInfo" attribute is provided for a dynamic PCC rule, the SMF shall instruct the UPF to perform the requested redirection as defined in 3GPP TS 29.244 [13].

If the "redirectServerAddress" attribute is not provided in the dynamic PCC rule and the redirection address is not preconfigured in the SMF/UPF for this PCC rule, the SMF shall perform PCC Rule Error Report, as specified in clauses 4.2.3.16 and 4.2.4.15, and set the "failureCode" attribute to "MISS_REDI_SER_ADDR".

NOTE 2: When the redirect server address is not provided by the PCC rule, the SMF determines the "MISS_REDI_SER_ADDR" error, e.g. when the SMF determines the redirect destination is not pre-configured at both the SMF and the UPF.

To disable the redirect function for one or more already installed PCC Rule(s), the PCF shall:

– update the PCC rule to modify the reference to Traffic Control Data decision to point to another (existing or new) Traffic Control Data decision that does not have "redirectInfo" instructions; or

– update the Traffic Control Data decision that the PCC rule refers to with the "redirectEnabled" attribute set to false, if the PCF disables the redirect function for all the PCC rules that refer to this Traffic Control Data decision.

For a predefined PCC rule, the redirect information shall be included in the rule definition at the SMF/UPF. Redirect information shall be activated for predefined PCC rules while those rules are active.

4.2.6.2.5 Usage Monitoring Control

Usage monitoring may be performed for service data flows associated with one or more PCC rules.

The provisioning of usage monitoring control per PCC rule shall be performed using the PCC rule provisioning procedure as defined in clause 4.2.6.2.1. For a dynamic PCC rule, the reference to the UsageMonitoringData data structure of the usage monitoring control instance, which is related with the PCC rule, shall be included within the "refUmData" attribute of the PccRule data structure of the PCC rule(s). For a predefined PCC rule, the reference to a usage monitoring control instance shall be included in the rule definition at the SMF. Usage monitoring shall be activated for both service data flows associated with predefined PCC rules and dynamic PCC rules, including rules with deferred activation and/or deactivation times while those rules are active.

4.2.6.2.6 Traffic Steering Control support

If the TSC feature is supported, the PCF may instruct the SMF to apply a traffic steering control for the purpose of steering the subscriber’s traffic to an appropriate operator or 3^rd party service functions (e.g. NAT, antimalware, parental control, DdoS protection) in the N6-LAN or 5G-LAN type of services, or enabling the routing of the user traffic to a local Data Network identified by a DNAI per AF request.

4.2.6.2.6.1 Steering the traffic in the N6-LAN or steering the 5G-LAN type of services

This procedure is only applicable in non-roaming and home-routed scenarios.

For the purpose of steering the subscriber’s traffic to an appropriate operator or 3^rd party service functions in the N6-LAN or steering the 5G-LAN type of services, the PCF shall include within the PccRule data structure a reference to the relevant Traffic Control Data decision and:

– include within the PccRule data structure either the application to be detected identified by the "appId" attribute or the service data flow to be detected identified by the "flowInfos" attribute; and

– include a "traffContDecs" attribute containing the corresponding Traffic Control Data decision within the SmPolicyDecision, if it has not been previously provided. In this case, the PCF shall include directly within this Traffic Control Data decision a traffic steering policy identifier for downlink within the "trafficSteeringPolIdDl" attribute and/or a traffic steering policy identifier for uplink within the "trafficSteeringPolIdUl" attribute.

The PCF may also provision the traffic steering control information by activating pre-defined PCC rule(s) in the SMF.

If traffic steering policy provided in the "trafficSteeringPolIdUl" and/or "trafficSteeringPolIdDl" attribute are invalid or unknown, or the enforcement of the steering of the traffic failed, the SMF shall return a PCC Rule Error Report, as specified in clauses 4.2.3.16 and 4.2.4.15, and set the "failureCode" attribute to "TRAFFIC_STEERING_ERROR".

4.2.6.2.6.2 Steering the traffic to a local access of the data network

This procedure is only applicable in non-roaming and visited access (i.e. LBO) scenarios.

The PCF shall determine if the ongoing PDU Session is impacted by the routing of traffic to a local access to a data network as follows:

– If the AF request includes the individual IP address/ prefix allocated to a UE or the UE MAC address, the PCF shall store the received traffic routing information and perform session binding as defined in clause 6.2 of 3GPP TS 29.513 [7] to determine the impacted PDU session.

– Otherwise, the PCF fetches from the UDR, as defined in 3GPP TS 29.519 [15], the traffic routing data information applicable for a UE, any UE or an Internal Group Id (if received in the SMF request).

Then the PCF authorizes the request for influencing SMF routing decisions. For the impacted PDU Session that corresponds to the AF request, the PCF shall take into account, if available, the local routing indication stored in the policy data subscription information in the UDR, as defined in 3GPP TS 29.519 [15], to determine whether it is allowed to generate PCC rules with traffic routing information. When allowed, the PCC rules are generated based on the AF request as follows:

– When the request is for influencing SMF routing decisions, based on traffic routing information, operator’s policy, etc., the PCF determines the traffic steering policy. The traffic steering policy indicates, for each DNAI, a traffic steering policy identifier configured in the SMF and/or if the N6 routing information associated to the application is explicitly provided by the AF, the N6 routing information (as provided by the AF). The traffic steering policy identifier is derived by the PCF from the routing profile Id provided by the AF and is related to the mechanism enabling traffic steering to the DN. Then:

– The PCF shall include within each PccRule data structure the necessary information to identify the concerned traffic within either the "flowInfos" attribute or the "appId" attribute, and include within the TrafficControlData data type that the PCC rule refers to a list of locations that the traffic shall be routed to in the "routeToLocs" attribute, and, if the "AF_latency" feature is supported, the PCF shall include the maximum allowed user plane latency within the "maxAllowedUpLat" attribute if available. If "EASIPreplacement" feature is supported, the PCF shall include the EAS IP replacement information within the "easIpReplaceInfos" attribute if available.

– Within each RouteToLocation instance, the PCF shall include a DNAI in the "dnai" attribute to indicate the location of the application towards which the traffic routing is applied, and a traffic steering policy identifier in the "routeProfId" attribute, to indicate the traffic steering policy that applies to the indicated DNAI, and/ or the explicit N6 traffic routing information in the "routeInfo" attribute.

– If the AF provides both a routing profile Id and N6 routing information for a DNAI, the PCF may include a RouteToLocation instance with the required information or may include two RouteToLocation instances with the same DNAI within the "dnai" attribute and a traffic steering policy identifier within the "routeProfId" attribute in one instance and explicit routing information within the "routeInfo" attribute in the other instance.

NOTE 1: The N6 traffic routing requirements are related to the mechanism enabling traffic steering in the local access to the DN. The routing profile ID refers to a pre-agreed policy between the AF and the 5GC. This policy may refer to different steering policy identifier(s) sent to the SMF and e.g. based on time of the day, etc.

NOTE 2: When per DNAI both, the "routeProfId" and the "routeInfo"attributes are provided, if the pre-configured traffic steering policy referenced by the "routeProfId" attribute contains information that is overlapping with the N6 traffic routing information provided in the "routeInfo" attribute, the N6 traffic routing information takes precedence.

NOTE 3: In this release of the specification, either a traffic steering policy identifier for UL or a traffic steering policy identifier for DL can be defined per DNAI.

– When the request is for subscribing to UP path change events of the PDU session, the PCF shall include the information on AF subscription to UP path change events within the PCC rule(s) to request the SMF to create a subscription to such notifications for the AF. In order to do so, the PCF shall include within each PccRule data structure the necessary information to identify the concerned traffic within either the "flowInfos" attribute or the "appId" attribute, and include within the Traffic Control Data decision that the PCC rule refers to the information on AF subscription to events within the "upPathChgEvent" attribute. Within this "upPathChgEvent" attribute, the PCF shall include the "dnaiChgType" attribute to indicate the type of notification (i.e. early notification, late notification or both), the notification URI within the "notificationUri" attribute, the notification correlation Id within the "notifCorreId" attribute, and if the URLLC feature is supported, an indication of AF acknowledgement to be expected within the "afAckInd" attribute. In order to enable the AF to identify the AF request to which the notification corresponds when the AF receives a UP path change notification from the SMF, as defined in clause 4.2.2.2 of 3GPP TS 29.508 [12], the PCF shall set the values of the "notificationUri" attribute and "notifCorreId" attribute respectively as follows:

– If the PCF fetches the traffic routing data information from the UDR, the PCF shall set the value of the "notificationUri" attribute to the value of the "upPathChgNotifUri" attribute of the TrafficInfluData data structure and set the value of the "notifCorreId" attribute to the value of the "upPathChgNotifCorreId" attribute of the TrafficInfluData data structure as defined in 3GPP TS 29.519 [15].

– If the PCF receives the traffic routing data information from the AF via N5 interface, the PCF shall set the values of the "notificationUri" attribute and the "notifCorreId" attribute according to the "upPathChgSub" attribute within the AfRoutingRequirement data structure as defined in 3GPP TS 29.514 [17].

– If the AF request includes an indication that application relocation is not possible, the PCF shall include within the PccRule data instance(s) the necessary information to identify the traffic within either the "flowInfos" attribute or the "appId" attribute and the "appReloc" attribute set to true. In this case, the SMF shall ensure that for the traffic related with the concerned application, no DNAI change takes place once selected initially for this application.

– If the "EASDiscovery" feature is supported and the AF request includes an indication that EAS rediscovery is required, the PCF shall include within the PccRule data instance(s) the necessary information to identify the traffic within the "appId" attribute and the "easRedisInd" attribute set to true.

– If the URLLC feature is supported and the AF request includes an indication that the UE IP address preservation should be considered, the PCF shall include within the concerned PccRule data instance(s) the "addrPreserInd" attribute set to true.

– If the AF request includes an indication that the PDU session should be correlated via a common DNAI for a given traffic, the PCF shall include within the TrafficControlData data instance provisioned for one or more PCC rule(s), the "traffCorreInd" attribute set to true.

NOTE 4: The indication of traffic correlation can be provided together with the traffic routing information by the AF for all the members of the 5G VN group. Referred to clause 5.29.4 of 3GPP TS 23.501 [2].

– If the feature "SimultConnectivity" is supported and the AF request includes an indication that the simultaneous connectivity may be temporarily maintained for the target and the source PSA during the edge re-location procedure, the PCF may include within the TrafficControlData data instance provisioned for one or more PCC rule(s) the "simConnInd" attribute set to true, as indicated by the AF. If the feature "SimultConnectivity" is supported and the AF request includes the time interval to be considered for inactivity of the traffic routed through the source PSA after which the simultaneous connectivity can be terminated, the PCF may also include the received duration within the "simConnTerm" attribute.

The PCF shall provide the PCC rule(s) as defined in clause 4.2.6.2.1.

If the temporal validity condition is received, the PCF shall evaluate the temporal validity condition of the AF request and inform the SMF to install or remove the corresponding PCC rule(s) according to the evaluation result. When policies specific to the PDU Session and policies general to multiple PDU Sessions exist, the PCF gives precedence to the PDU Session specific policies over the general policies.

If the spatial validity condition is received, the PCF considers the latest known UE location to determine the PCC rules provided to the SMF. In order to do that, the PCF shall request the SMF to report the notifications about change of UE location in an area of interest (i.e. Presence Reporting Area) as defined in clauses 4.2.2.13 or 4.2.3.19. The subscribed area of interest may be the same as the one provided in spatial validity condition, or may be a subset of the spatial validity condition (e.g. a list of TAs) based on the latest known UE location. When the SMF detects that the UE entered the area of interest subscribed by the PCF, the SMF notifies the PCF and the PCF provides to the SMF the PCC rule(s) described above. When the SMF becomes aware that the UE left the area subscribed by the PCF, the SMF notifies the PCF and the PCF may remove or provide updated PCC rule(s) to the SMF.

When the PCC rules are installed, the SMF may, based on local policies, take the information in the PCC rule(s) into account to:

– if the PDU Session is of IP type and the "addrPreserInd" attribute is included and set to true in the PCC rule(s), the SMF should preserve the UE IP address and, if necessary, not reselect the related PSA UPF for the traffic identified in the PCC rule once the PSA UPF is selected; otherwise, the SMF (re)selects UPF(s) as it might be required for PDU Sessions.

– activate mechanisms for traffic multi-homing or enforcement of an UL Classifier (UL CL).

– inform the AF of the (re)selection of the UP path (change of DNAI).

– determine the target DNAI(s) for the current UE location, which may imply I-SMF selection or removal to be requested to the AMF as defined in 3GPP TS 29.502 [22].

– if the "traffCorreInd" attribute set to true is included in the TrafficControlData data type referenced by a set of PCC rules, based on SMF implementation and local configuration, the SMF should select a common DNAI from the list of DNAI included in the "routeToLocs" attribute for the identified traffic of the PDU session.

– if the "simConnInd" attribute set to true is included in the TrafficControlData data type referenced by a set of PCC rules, the SMF may temporarily maintain simultaneous connectivity for the source and target PSA at edge relocation procedure, and may influence the establishment of a temporary N9 forwarding tunnel between the source UL CL and target UL CL. If the "simConnTerm" attribute is also included, the SMF may consider the indicated time interval as the minimum one to be considered for inactivity for the described traffic before the connectivity over the source PSA may be removed.

– if the "maxAllowedUpLat" attribute is received, SMF may use this value to decide whether edge relocation is needed to ensure that the user plane latency does not exceed the value and whether to relocate the PSA UPF to satisfy the user plane latency.

– if the "easIpReplaceInfos" attribute is received, the SMF may instruct the local PSA UPF with the EAS IP replacement information using "Outer Header Creation" as defined in 3GPP TS 29.244 [13] clause 8.2.56 and "Outer Header Removal" as defined in 3GPP TS 29.244 [13] clause 8.2.64. The PSA UPF shall be configured by the SMF to perform one creation and one removal of the appropriate outer header(s) both in the uplink and in the downlink direction in a way that the address information indicated by the "source" attribute (within "easIpReplaceInfos") is used in the headers of the packets towards the UE and the address information indicated by the "target" attribute (within "easIpReplaceInfos") is used in the headers of the packets towards the DN.

– if the "easRedisInd" attribute set to true is included, the SMF may indicate the UE to refresh the cached EAS information as defined in clause 6.3.2 of 3GPP TS 24.501 [20].

If routing of traffic to a local access to a data network policy provided in the "routeToLocs" attribute is invalid, unknown or not applicable, or the enforcement of the steering of the traffic to the indicated DNAI failed, the SMF shall return a PCC Rule Error Report, as specified in clauses 4.2.3.16 and 4.2.4.15, and set the "failureCode" attribute to "DNAI_STEERING_ERROR".

4.2.6.2.7 Conditioned PCC rule

The PCF may control at what time the status of a PCC rule changes. In order to provision a PCC rule with conditional data, the PCF shall provision a PCC rule as defined in clause 4.2.6.2.1and include within its "refCondData" attribute the value of the "condId" attribute of the targeted ConditionData instance. The PCF shall also ensure that this referenced ConditionData instance is included in the "conds" map attribute within the SmPolicyDecision data structure, following the procedures defined in clause 4.2.6.1.

Within the ConditionData instance, the PCF shall include the activation time within the "activationTime" attribute and/or the deactivation time within the "deactivationTime" attribute.

When the SMF receives a conditioned PCC rule, the SMF shall act as follows:

1) If only the "activationTime" attribute is provided by the PCF and the time specified in it is in the future, then the SMF shall set the PCC rule to inactive state and only change it to active state at the specified time. If this time specified in the "activationTime" attribute is in the past, then the SMF shall immediately set the PCC rule to active state.

2) If only the "deactivationTime" attribute is provided by the PCF and the time specified in it is in the future, then the SMF shall set the PCC rule to active state and only change it to inactive state at the specified time. If this time specified in the "deactivationTime" is in the past, then the SMF shall immediately set the PCC rule to inactive state.

3) If both the "activationTime" attribute and the "deactivationTime" attribute are provided by the PCF, and the value specified in the "activationTime" occurs before the value specified in the "deactivationTime" attribute, and also when the PCC rule is provided before or at the value specified in the "deactivationTime", the SMF shall handle the PCC rule first as defined in 1) and then as defined in 2).

4) If both the "activationTime" attribute and the "deactivationTime" attribute are provided by the PCF, and the value specified in the "deactivationTime" attribute occurs before the value specified in the "activationTime", and also when the PCC rule is provided before or at the value specified in the "activationTime" attribute, the SMF shall handle the PCC rule first as defined in 2) and then as defined in 1).

5) If both the "activationTime" attribute and the "deactivationTime" attribute are provided by the PCF and are both in the past, and the value specified in the "activationTime" occurs before the value specified in the "deactivationTime" attribute, then the SMF shall immediately set the PCC rule to inactive state.

6) If both the "activationTime" attribute and the "deactivationTime" attribute are provided by the PCF and are both in the past, and the value specified in the "deactivationTime" attribute occurs before the value specified in the "activationTime" attribute, then the SMF shall immediately set the PCC rule to active state.

7) If both "activationTime" attribute and "deactivationTime" attribute are specified with the same time, the SMF shall report a PCC rule error for the concerned PCC rule(s), as specified in clauses 4.2.3.16 and 4.2.4.15, and set the "failureCode" attribute to "INCORRECT_COND_DATA".

The PCF may modify a currently installed/activated PCC rule, including setting, modifying or deleting its deferred activation and/or deactivation time as follows:

1) When modifying a PCC rule by newly setting the deferred activation time and/or deactivation time, the PCF shall update the PCC rule by including the corresponding ConditionData instance ‘s "condId" attribute value within the "refCondData" attribute and including within the SmPolicyDecision data structure this ConditionData instance within the "conds" map attribute, if not previously provisioned.

2) When modifying a PCC rule by modifying the already provisioned deferred activation time and/or deactivation time:

– the PCF may update the PCC rule by replacing the existing ConditionData instance’s "condId" attribute value within the "refCondData" attribute with a another one pointing to another ConditionData instance and including within the SmPolicyDecision data structure this new ConditionData instance within the "conds" attribute, if not previously provisioned; or

– the PCF may update the condition data decision to which the PCC rule refers by updating the corresponding ConditionData instance in the SmPolicyDecision data structure, as defined in clause 4.2.6.1. The PCF may add an activation time and/or a deactivation time, update the values of the existing activation time and/or deactivation time, or delete either the existing activation time or the existing deactivation time.

3) When modifying a PCC rule by deleting the previously provisioned deferred activation time and/or deactivation time:

– the PCF shall delete the reference to the corresponding ConditionData instance within the PCC rule by updating the "refCondData" attribute of the PCC rule to "NULL" value; and

– the PCF may also delete this condition data decision to which the PCC rule refers as defined in clause 4.2.6.1 (i.e. delete the corresponding ConditionData instance within the SmPolicyDecision data structure), if no other PCC rule is referring to this condition data decision.

To delete a conditioned PCC rule, the PCF shall run the procedures as defined in clause 4.2.6.2.1.

The UE timezone information, if available, may be used by the PCF to construct the values of the "activationTime" attribute and/or the "deactivationTime" attribute.

The PCC rule(s) including a reference to a Condition Data decision which includes an "activationTime" attribute and/or a "deactivationTime" attribute shall be bound to a QoS flow associated with a default QoS rule that allows all UL packets. If such PCC rule(s) are not bound to a QoS flow associated with a default QoS rule, the SMF shall report a failure to the PCF by including the "ruleReports" attribute with the "failureCode" attribute set to the value "NO_QOS_FLOW_BOUND" for the affected PCC rule(s). Changes of the QoS profile or QoS rule which will initiate signalling towards the access network and/or UE in such PCC rule(s) shall also not be applied.

NOTE: This limitation prevents dependencies on the signalling of changed traffic mapping information towards the UE.

4.2.6.2.8 PCC rule for resource sharing

If the ResShare feature is supported by both the SMF and PCF as described in clause 5.8, the PCF may indicate that the SMF should commonly reserve resources for a set of PCC rules. The SMF shall then, for PCC rules bound to the same QoS flow and the same sharing key value , use the highest GBR value among those PCC rules as input for calculating the common GBR value when reserving QoS flow resources. The GBR value for each direction shall be considered separately, so that the uplink and downlink GBR values may originate from different PCC rules.

The SMF may, based on internal logic, use the highest MBR value among the provided PCC rules indicated to share resources, when determining the MBR for the QoS flow. Each individual PCC rule is still subject to data rate policing based on its own MBR values.

The PCF shall provide the "sharingKeyDl" attribute and/or "sharingKeyUl" attribute within the QosData data structure which the PCC rules refers to in order to indicate that the related PCC rule may share resources with other PCC rules bound to the same QoS flow.

The SMF shall apply resource sharing if at least two PCC rules bound to the same QoS flow share the same value in the "sharingKeyDl" attribute and/or "sharingKeyUl" attribute.

When modifying the value of "sharingKeyDl" attribute and/or "sharingKeyUl" attribute of the QosData data structure, which a PCC rule refers to for the PCC rule that is subject to resource sharing the SMF may adjust the resource sharing of the remaining PCC rules.

NOTE 1: A PCC rule that is deleted is also removed from the resource sharing, while the remaining PCC rules continue their sharing relationship.

NOTE 2: The state of resource sharing ends when less than two of the PCC rules in the set remains.

4.2.6.2.9 Resource reservation for services sharing priority

When the PCF derives PCC Rules corresponding to a service related to an AF that has indicated that priority sharing is allowed for that service over Rx interface or within the Npcf_PolicyAuthorization service, it derives the corresponding PCC Rules according to current procedures as described in 3GPP TS 29.513 [7], clause 7.3. The PCF may additionally take the suggested pre-emption capability and vulnerability values into account if the AF provided them when the PCF determines the ARP pre-emption capability and vulnerability. The ARP derived at this point and the priority sharing indicator provided over Rx reference point (see 3GPP TS 29.214 [18] for further information) or over the Npcf_PolicyAuthorization service (see 3GPP TS 29.514 [17] for further information) related to these derived PCC Rules are stored for later use.

For PCC Rules related to the same PDU session with the same assigned 5QI and with the priority sharing indicator enabled (see 3GPP TS 29.214 [18], clause 4.4.8, or 3GPP TS 29.514 [17], clauses 4.2.2.21, 4.2.3.21 and 4.2.4.9), the PCF shall rederive the ARP into a shared ARP for these PCC Rules as follows:

– The Priority Level shall be set to the lowest value (i.e. highest priority) among the Priority Level values derived for the PCC rules that include the priority sharing indicator.

– The Pre-emption Capability shall be set to true if any of the original derived PCC Rules have the Pre-emption-Capability value set to true.

– The Pre-emption Vulnerability shall be set to true if all the original derived PCC Rules have the Pre-emption Vulnerability value set to true.

NOTE 1: Having the same setting for the ARP parameter in the PCC Rules with the priority sharing indicator set enables the usage of the same QoS flow. Furthermore, a combined modification of the ARP parameter in the PCC rules ensures that a QoS flow modification is triggered when a media flow with higher service priority starts.

If the 5QI and/or ARP related to any of the PCC Rules that share priority is changed (e.g. based on local policies), the PCF shall rederive the ARP for the impacted PCC Rules following the same procedure as defined in this clause.

The PCF shall provision the PCC Rules according to the rederived ARP information as described in clause 4.2.6.2.1.

If the PCF receives a report that a PCC rule provisioning or modification failed due to the resource reservation failure as defined in clauses 4.2.3.1.6 and 4.2.4.15 (PCC Rule Error Report) and if the PCF supports the MCPTT-Preemption feature as defined in clause 5.4.1 of 3GPP TS 29.214 [18] or in clause 5.8 of 3GPP TS 29.514 [17], the PCF shall check if pre-emption control based on the pre-emption control information provided by the AF as defined in clauses 4.4.1 or 4.4.2 of 3GPP TS 29.214 [18] or in clauses 4.2.2.21, 4.2.3.21 or 4.2.4.9 of 3GPP TS 29.514 [17] applies.

NOTE 2: The PCF determines that pre-emption control applies based on the presence of the Pre-emption-Control-Info AVP received over Rx reference point as defined in 3GPP TS 29.214 [18] or "preemptControlInfo" attribute received over N5 reference point as defined in 3GPP TS 29.514 [17] and operator policies.

If pre-emption control applies, the PCF shall check the corresponding derived PCC Rules (before applying priority sharing procedures). If the Pre-emption Capability of the derived PCC Rule is disabled the PCF shall notify that resource allocation has failed for this PCC rule to the AF as defined in clauses 4.4.1 or 4.4.2 of 3GPP TS 29.214 [18] or in clauses 4.2.2.21, 4.2.3.21 or 4.2.4.9 of 3GPP TS 29.514 [17]. Otherwise, if the Pre-emption Capability of the derived PCC Rule is enabled, the PCF shall perform the pre-emption control as follows:

– For all the active PCC rule(s) that applied priority sharing mechanism, the PCF shall identify the PCC Rules that have the Pre-emption Vulnerability enabled. For those selected PCC Rule(s), the PCF shall check the Priority Level value.

– If there is only one PCC Rule with the Priority Level value higher (i.e. lower priority) than the derived Priority Level value of new or modified PCC Rule, the PCF shall remove this PCC rule. The PCF shall retry the PCC rule provisioning or modification procedure for the PCC rule that failed.

– Otherwise, if there are more than one PCC Rule with the Priority Level value higher (i.e. lower priority) than the derived Priority Level value of new or modified PCC Rule, the PCF shall remove the PCC Rule with the highest Priority Level from the SMF. The PCF shall retry the PCC rule provisioning or modification procedure for the PCC rule that failed; If more than one PCC Rule have the same highest Priority Level, the PCF shall check the Pre-Emption-Control-Info AVP received over Rx interface as defined in 3GPP TS 29.214 [18], or the "preemptControlInfo" attribute received over N5 interface as defined in 3GPP TS 29.514 [17] and remove the PCC Rule that matches the condition.

– Otherwise, if there is at least one PCC Rule with the same Priority Level value than the derived Priority Level value of new or modified PCC Rule, the PCF shall check the Pre-emption-Control-Info AVP received over Rx interface as defined in 3GPP TS 29.214 [18] or the "preemptControlInfo" attribute received over N5 interface as defined in 3GPP TS 29.514 [17] for these PCC Rules and remove the PCC Rule that matches the condition.

– Otherwise, the PCF shall notify that resource allocation has failed for this PCC rule to the AF as defined in clauses 4.4.1 or 4.4.2 of 3GPP TS 29.214 [18] or in clauses 4.2.2.21 or 4.2.3.21 of 3GPP TS 29.514 [17].

If there is no active PCC Rule with the Pre-emption Vulnerability enabled, the PCF shall notify that resource allocation has failed for this PCC rule to the AF as defined in clauses 4.4.1 or 4.4.2 of 3GPP TS 29.214 [18].

NOTE 3: If the PCF receives a report that a PCC rule provisioning or modification failed due to the resource reservation failure and the PCF does not support the MCPTT-Preemption feature as defined in clause 5.4.1 of 3GPP TS 29.214 [18] or clause 5.8 of 3GPP TS 29.514 [17], the PCF can apply pre-emption and remove active PCC rules from the SMF and then retry the PCC rule provisioning or modification procedure. Otherwise, the PCF will notify it to the AF as defined in clauses 4.4.1 or 4.4.2 of 3GPP TS 29.214 [18] or in clauses 4.2.2.21 or 4.2.3.21 of 3GPP TS 29.514 [17]. How the PCF applies the pre-emption depends on the implementation.

4.2.6.2.10 PCC rule bound to the default QoS flow

The PCF may indicate to the SMF that a PCC rule shall be bound to the default QoS flow and remain on the default QoS flow. The SMF shall then, for the indicated PCC rule, bind it to the default QoS flow until this PCC rule is removed or until the PCF modifies this PCC rule to set the "defQosFlowIndication" attribute to false. For this second case, Tthe SMF case shall evaluate the full QoS information within the QosData data structure to which the PCC rule refers and follow normal policy enforcement procedures for authorized QoS per service data flow as described in clause 4.2.6.2.3.

NOTE: 5QI, ARP, QNC (if available), Priority Level (if available), Averaging Window (if available) and Maximum Data Burst Volume (if available) within the QoS Data decision referred by the PCC rule are only used by the SMF for QoS flow binding purposes when the "defQosFlowIndication" attribute is not included in the QoS Data decision or it is included and set to false.

The PCF shall provide the "defQosFlowIndication" attribute set to true in order to indicate that the related PCC rule shall be bound to the default QoS flow.

If the "defQosFlowIndication" attribute is provided and set to true within the QosData data structure to which the PCC rule refers, the SMF shall bind the related PCC rule to the default QoS flow. This binding remains valid until the related PCC rule is removed or if the PCF indicates to the SMF that the binding to the default QoS flow for this PCC rule no longer applies.

The SMF shall ignore the values of the other attributes, including 5QI, ARP, QNC (if available), Priority Level (if available), Averaging Window (if available) and Maximum Data Burst Volume (if available), provided within the QosData data structure if the "defQosFlowIndication" attribute is provided by the PCF and set to true. If the PCF has previously indicated to the SMF that a PCC rule shall be bound to the default QoS flow, and desires to indicate that this binding no longer applies the PCF shall update this PCC rule by including the "defQosFlowIndication" attribute set to false. The SMF shall in this case evaluate the full QoS information within the QosData data structure to which the PCC rule refers and follow normal policy enforcement procedures for authorized QoS per service data flow as described in clause 4.2.6.2.3.

If the PCF has not previously indicated to the SMF that a PCC rule shall be bound to the default QoS flow (i.e. it may be bound to another QoS flow), in order to indicate that the binding to the default QoS flow shall now apply for this PCC rule, the PCF shall update the PCC rule by including (or updating) the "defQosFlowIndication" attribute and set it to true. The SMF shall in this case follow the procedures described in this clause.

4.2.6.2.11 PCC rule for Application Detection and Control

If the ADC feature is supported, the user subscription indicates that application detection and control is enabled, and the PCF determines that application detection is required because of e.g. an internal/external trigger or the PCF has received from an NF service consumer (e.g. another PCF) a subscription to the event for application start/stop traffic detection (see TS 29.514 [17], clause 4.2.6.9), the PCF may instruct the SMF to detect application(s) by installing or activating PCC rule(s).

An application to be detected is identified by an application identifier, which shall be provided within the "appId" attribute for dynamic PCC rules or pre-provisioned for predefined PCC rules. If the PCF requires to be notified when application start/stop is detected, it shall also provide the APP_STA and APP_STO policy control request triggers to the SMF as defined in clause 4.2.4.6. For dynamic PCC rules, the PCF may also mute such notifications for a specific detected application by including a "traffContDecs" attribute to contain a Traffic Control Data decision which contains the "muteNotif" attribute set to true and including a "refTcData" attribute referring to this Traffic Control Data decision within the concerned PCC rule.

If the application identifier provided in the "appId" attribute is invalid, unknown or not applicable, the SMF shall return a PCC Rule Error Report, as specified in clauses 4.2.3.16 and 4.2.4.15, and set the "failureCode" attribute to "APP_ID_ERR".

The SMF shall reject the update of the mute indication for a provisioned PCC rule as specified in clause 4.2.3.16 and 4.2.4.15, and set the "failureCode" attribute to "MUTE_CHG_NOT_ALLOWED".

In this release of the specification Application Detection and Control applies only to the IP PDU session type.

4.2.6.2.12 Provisioning of PCC Rules for Multimedia Priority Services

4.2.6.2.12.1 General

The provision of PCC Rules corresponding to both MPS and non-MPS service shall be performed as described in clause 4.2.6.2.1 "Provisioning of PCC rules".

When the PCF derives PCC Rules corresponding to MPS service, the ARP and 5QI shall be set as appropriate for the prioritized service, e.g. an IMS Multimedia Priority Service. The PCF may authorize a standardized 5QI or a standardized 5QI with a specific 5QI priority level as defined in clause 4.2.6.6.2. The PCF may also authorize a non-standardized 5QI with explicitly signalled QoS characteristics as defined in clause 4.2.6.6.3.

When the PCF derives PCC Rules corresponding to non-MPS service, the PCF shall generate the PCC Rules as per normal procedures. At the time the Priority PDU connectivity services is invoked based on the subscription profile stored in the UDR (i.e. Indication for support of Priority PDU connectivity service and MPS Priority Level are set in the UDR) or by the AF (e.g., MPS for DTS is invoked as described in 3GPP TS 29.214 [18] and 3GPP TS 29.514 [17]), the PCF shall upgrade the ARP and/or change 5QI for the PCC Rules to appropriate values as needed for MPS. The PCF shall change the ARP and/or 5QI (also associated QoS characteristics if applicable) modified for the Priority PDU connectivity service to an appropriate value according to PCF decision.

When the PCF receives an HTTP POST message as defined in clause 4.2.2.1, the PCF shall check whether any of these parameters is stored in the UDR: indication for support of Priority PDU connectivity service, MPS Priority Level and/or indication of IMS priority service support. The PCF shall derive the applicable PCC rules and default QoS flow QoS based on that information. If the indication of IMS priority service support is set and the "dnn" attribute corresponds to a DNN dedicated for IMS, the PCF shall assign an ARP corresponding to MPS for the default QoS flow and for the PCC Rules corresponding to the IMS signalling QoS flow. If the "dnn" does not correspond to a DNN dedicated for IMS, the ARP shall be derived without considering IMS Signalling Priority.

NOTE 1: Subscription data for MPS is provided to PCF through the Nudr service.

Once the PCF receives a notification of a change in Priority PDU connectivity services support, MPS Priority Level and/or IMS priority service support from the UDR, the PCF shall make the corresponding policy decisions (i.e. ARP and/or 5QI (also associated QoS characteristics if applicable) change) and, if applicable, shall initiate an HTTP POST message as defined in clause 4.2.3.2 to provision the modified data.

NOTE 2: The details associated with the UDR service are specified in 3GPP TS 29.519 [15].

NOTE 3: The MPS Priority Level is one among other input data such as operator policy for the PCF to set the ARP.

Whenever one or more AF sessions of an MPS service are active within the same PDU session, the PCF shall ensure that the ARP priority level of the default QoS flow is at least as high as the highest ARP priority level used by any authorized PCC rules belonging to an MPS service. If the ARP pre-emption capability is enabled for any of the authorized PCC rules belonging to an MPS service, the PCF shall also enable the ARP pre-emption capability for the default QoS Flow.

NOTE 4: This ensures that services using dedicated QoS flows are not terminated because of a default QoS flow with a lower ARP priority level or disabled ARP pre-emption capability being dropped during mobility events.

NOTE 5: This PCF capability does not cover interactions with services other than MPS services.

4.2.6.2.12.2 Invocation/Revocation of Priority PDU connectivity services

When a Priority PDU connectivity services is invoked, the PCF shall:

– Derive the corresponding PCC Rules with the ARP and 5QI (also associated QoS characteristics if applicable) set as appropriate for a prioritized service.

– Set the ARP of the default QoS flow as appropriate for a Priority PDU connectivity services under consideration of the requirement described in clause 4.2.6.2.12.1.

– Set the 5QI (also associated QoS characteristics if applicable) of the default QoS flow as appropriate for the Priority PDU connectivity services.

– Set the ARP of PCC Rules installed before the activation of the Priority PDU connectivity services to the ARP as appropriate for the Priority PDU connectivity services under the consideration of the requirements described in clause 4.2.6.2.12.1.

– Set the 5QI of the PCC Rules installed before the activation of the Priority PDU connectivity services to the 5QI (also associated QoS characteristics if applicable) as appropriate for the Priority PDU connectivity services if modification of the 5QI of the PCC Rules is required.

When a Priority PDU connectivity services is revoked, the PCF shall:

– Delete the PCC Rules corresponding to the Priority PDU connectivity services if they were previously provided.

– Set the ARP of the default QoS flow to the normal ARP under the consideration of the requirements described in clause 4.2.6.2.12.1.

– Set the 5QI of the default QoS flow as appropriate for PCF decision.

– Set the ARP of all active PCC Rules as appropriate for the PCF under the consideration of the requirements described in clause 4.2.6.2.12.1.

– Set the 5QI to an appropriate value according to PCF decision if modification of the 5QI of PCC Rules is required.

NOTE: Priority PDU connectivity services can be explicitly invoked/revoked via UDR MPS user profile (Indication of Priority PDU connectivity services, MPS Priority Level). An AF for MPS Priority Service can also be used to provide Priority PDU connectivity services using network-initiated resource allocation procedures (via interaction with PCC) for originating accesses.

The PCF shall provision the SMF with the applicable PCC Rules upon Priority PDU connectivity services activation and deactivation as described above. The provision of the QoS information applicable for the PCC Rules shall be performed as described in clause 4.5.6.2. The provision of QoS information for the default QoS flow shall be performed as described in clause 4.2.6.3.

4.2.6.2.12.3 Invocation/Revocation of IMS Multimedia Priority Services

If the PCF receives service information including an MPS session indication and the service priority level from the P-CSCF or at reception of the indication that IMS priority service is active for the PDU session, the PCF shall under consideration of the requirements described in clause 4.2.6.2.12.1:

– if required, set the ARP and 5QI (also associated QoS characteristics if applicable) of the default QoS flow as appropriate for the prioritized service;

– if required, set the ARP and 5QI (also associated QoS characteristics if applicable) of all PCC rules assigned to the IMS signalling QoS flow as appropriate for IMS Multimedia Priority Services;

– derive the PCC Rules corresponding to the IMS Multimedia Priority Service and set the ARP and 5QI (also associated QoS characteristics if applicable) of these PCC Rules based on the information received over N5/Rx.

If the PCF detects that the P-CSCF released all the MPS session and the IMS priority service has been deactivated for the PDU session the PCF shall under consideration of the requirements described in clause 4.2.6.2.12.1:

– delete the PCC Rules corresponding to the IMS Multimedia Priority Service;

– if required, set the ARP and 5QI of the default QoS flow as appropriate for the IMS Multimedia Priority set to inactive;

– replace the ARP and 5QI of all PCC Rules assigned to the IMS signalling QoS flow as appropriate when the IMS Multimedia Priority is inactive.

4.2.6.2.12.4 Invocation/Revocation of MPS for DTS

When the PCF receives from the AF an indication of invocation/revocation of MPS for DTS as specified in 3GPP TS 29.514 [17] or 3GPP TS 29.214[10], and if the "MPSforDTS" feature is supported, the PCF shall make the corresponding policy decisions (i.e. ARP and/or 5QI change for the default QoS) and, if applicable, shall initiate an Npcf_SMPolicyControl_UpdateNotify to provision the modified data.

For the invocation of MPS for DTS, the PCF shall:

– Set the ARP of the default QoS flow as appropriate for MPS for DTS.

– Set the 5QI (also associated QoS characteristics if applicable) of the default QoS flow as appropriate for MPS for DTS.

NOTE 1: For PCC Rules that had the same ARP and 5QI as the original default QoS flow: the PCF indicates to the SMF that the PCC rule is to be bound to the default QoS flow by setting the "defQosFlowIndication" attribute within the QosData data structure to true; or sets the ARP as appropriate for MPS for DTS and the 5QI (also associated QoS characteristics if applicable) as appropriate for MPS for DTS.

For the revocation of MPS for DTS, to revert the MPS for DTS values of the default QoS flow and the PCC rules bound to the default QoS flow, the PCF shall set the ARP and the 5QI of the default QoS flow as appropriate for PCF decision.

NOTE 2: For PCC Rules that had the same ARP and 5QI as the default QoS flow, or had the "defQosFlowIndication" attribute set to true: the PCF sets the ARP; and the 5QI (also associated QoS characteristics if applicable) as appropriate for PCF decision. The provision of the QoS information applicable for the PCC Rules is performed as described in clause 4.2.6.6.

NOTE 3: Revocation may require more complex logic on the part of the PCF beyond simply restoring the prior ARP and 5QI values as set prior to invocation of MPS for DTS, if these values and/or the defQosFlowIndication were modified by another service during the time that MPS for DTS was enabled. The corresponding logic is dependent on the identification of particular services that may be deployed and the desired interactions between MPS for DTS and any such services. These aspects are not considered in the present specification.

The PCF shall provision the SMF upon MPS for DTS invocation and revocation as described above for the default QoS flow as described in clause 4.2.3.6.

On receipt from an AF of a request to report the successful outcome of the MPS for DTS invocation/revocation of priority handling for the default QoS flow (see 3GPP TS 29.214 [18] and 3GPP TS 29.514 [17]), the PCF shall request the SMF to confirm that the resources associated to the MPS for DTS invocation/revocation are successfully allocated. The PCF does this by setting the "policyCtrlReqTriggers" attribute in the "SmPolicyDecision" data structure to the value "SUCC_QOS_UPDATE". On receipt of the "repPolicyCtrlReqTriggers" attribute in the SmPolicyUpdateContextData data structure set to the value "SUCC_QOS_UPDATE" from the SMF, the PCF shall inform the AF that it successfully acted upon the "mpsAction" attribute as defined in 3GPP TS 29.514 [17] or the MPS-Action AVP as defined in 3GPP TS 29.214 [18].

The SMF shall report MPS for DTS invocation/revocation failure to the PCF according to clause 4.2.4.21 if requested to do so by the AF as described in 3GPP TS 29.214 [18], clause 4.4.11 or as described in 3GPP TS 29.514 [17], clause 4.2.2.12.2.

4.2.6.2.13 Sponsored Data Connectivity

Sponsored data connectivity may be performed for service data flows associated with one or more PCC rules if the information about the sponsor, the application service provider and optionally the threshold values are provided by the AF and if the AF has not indicated to disable/not enable sponsored data connectivity as described in 3GPP TS 29.214 [18] clauses 4.4.1 and 4.4.2 or 3GPP TS 29.514 [17] clauses 4.2.2.5 and 4.2.3.5.

The provisioning of sponsored data connectivity per PCC rule shall be performed using the PCC rule provisioning procedure as defined in clause 4.2.6.2.1. The sponsor identity shall be set using the "sponsorId" attribute within the ChargingData data type which the PCC rule refers to. The application service provider identity shall be set using the "appSvcProvId" attribute within the ChargingData data type which the PCC rule refers to. The "sponsorId" attribute and "appSvcProvId" shall be set if the "reportingLevel" attribute within the ChargingData data type which the PCC rule refers to is set to the value "SPON_CON_LEVEL".

When receiving the usage thresholds from the AF, the PCF shall use the sponsor identity to generate a value of "umId" attribute of the UsageMonitoringData data type which the PCC rule refers to and request usage monitoring control for the sponsored data connectivity by following the procedures specified in clauses 4.2.6.2.5.

When the AF disables sponsoring a service (See 3GPP TS 29.214 [18] clause 4.4.2 or 3GPP TS 29.514 [17] clause 4.2.3.5), the PCF

– may modify the PCC rules in order to set the "reportingLevel" attribute to "SER_ID_LEVEL" or "RAT_GR_LEVEL" within the ChargingData data type which the PCC rule refers to and not include the "sponsorId" attribute and "appSvcProvId" attribute if they were included previously.

– may modify the PCC rules to update the charging key by setting the new value of the "ratingGroup" attribute within the ChargingData data type which the PCC rule refers to.

NOTE: A specific charging key can be applied to the sponsored data connectivity for online charging.

– shall disable the usage monitoring for the sponsored data connectivity according to clause 4.2.6.2.5 if it was enabled previously. As a result, PCF gets the accumulated usage of the sponsored data connectivity.

4.2.6.2.14 Support for PCC rule versioning

The support of PCC rule versioning is optional. When the "RuleVersioning" feature is supported, the SMF and the PCF shall comply with the procedures specified in this clause.

If required by operator policies, the PCF shall assign a content version for each generated PCC rule and shall include the assigned version in the "contVer" attribute included within the PccRule data structure. Upon each PCC rule modification, if the content version was previously assigned to a PCC rule, the PCF shall assign a new content version. In this case, all the content related to that PCC rule shall be included. If the PCF needs to modify the attribute(s) within the PCC rule, the PCF shall include the new content version within the "contVer" attribute together with all modified and unmodified applicable attribute(s) within the PccRule data structure. If the PCF only needs to modify the content of referenced policy decision data and/or condition data for one or more PCC rules, the PCF shall additionally provide the PCC rule(s) which is referring to the modified policy decision data and/or condition data. Within each PCC rule instance, the PCF shall include all unmodified applicable attribute(s) and the new assigned version in the "contVer" attribute. The content version is unique for the lifetime of the PCC rule.

NOTE 1: The PCF will include all the content of the PCC rule in each modification of the PCC rule in order to ensure that the rule is installed with the proper information regardless of the outcome of the QoS flow procedure related to previous rule provisioning versions that are not reported yet.

NOTE 2: The operation policies can take into account whether the AF provides the related content version information over Rx reference point (see clause 4.4.9 in 3GPP TS 29.214 [18]), or over Npcf_PolicyAuthorization service (see clauses 4.2.2.13 and 4.2.3.13 in 3GPP TS 29.514 [17]).

Whenever the SMF provides a PCC rule report for rules that were provisioned with a content version, the SMF shall include the "contVers" attribute defined in the RuleReport data structure for those corresponding PCC rules. In case it is required to report the content version of multiple PCC rules, the SMF shall use one instance of RuleReport data structure per PCC rule, and shall include in the "pccRuleIds" attribute only the identifier of the corresponding PCC rule. The SMF may include more than one content version in the "contVers" attribute for the same PCC rule within the corresponding RuleReport instance included in the "ruleReports" attribute (e.g. the SMF has combined multiple PCC rule versions enforcement into one QoS flow operation). In this case, the "ruleStatus" attribute shall indicate the final status of the PCC rule.

NOTE 3: The PCF will use the content version to identify the PCC rule version that failed or succeeded when multiple provisions of the same PCC rule occur in a short period of time. If required by the AF, the PCF will inform the AF according to 3GPP TS 29.214 [18], clause 4.4.9, or according to 3GPP TS 29.514 [17], clause 4.2.5.8 about the failure or success for the media component version associated to the PCC rule version.

4.2.6.2.15 Background data transfer support

If the PCF receives Reference Id within the service information from the AF as defined in 3GPP TS 29.514 [17] or 3GPP TS 29.214 [18] or if "EnhancedBackgroundDataTransfer" feature as defined in clause 5.8 is supported and the PCF receives the Reference Id(s) within the PDU session related subscription information from the UDR as defined in 3GPP TS 29.519 [15], the PCF shall retrieve the corresponding transfer policy from the UDR based on the Reference Id(s) as defined in 3GPP TS 29.519 [15]. The PCF shall use the retrieved transfer policy as input for policy decisions (e.g. setting the charging key equal to the charging key of the transfer policy, rule activation/deactivation time according to the time window).

During PDU session establishment, if "EnhancedBackgroundDataTransfer" feature as defined in clause 5.8 is supported and if validation conditions (i.e. Time Window and/or Location Criteria) of the transfer policy are not satisfied then the PCF may reject corresponding SM Policy Association as defined in clause 4.2.2.2 and include in an HTTP "403 Forbidden" response message the "cause" attribute of the ProblemDetails data structure set to "VALIDATION_CONDITION_NOT_MET". And based on this feedback, the SMF shall reject the PDU session setup.

After successful PDU session establishment, if "EnhancedBackgroundDataTransfer" feature as defined in clause 5.8 is supported, PCF may request the PDU session termination if the validation conditions become not satisfied as defined in clause 4.2.3.3. Within the TerminationNotification, the PCF shall include the "cause" attribute set to "VALIDATION_CONDITION_NOT_MET".

If "BDTPolicyRenegotiation" feature as defined in clause 5.8 is supported and if the PCF retrieves the BDT policy and corresponding related information (e.g. network area information, the volume of data to be transferred per UE, etc.) within the BdtData data type, and with the "bdtpStatus" attribute within the BdtData data type set to value "INVALID", the PCF may reject the SM Policy Association establishment or defer to make the policy decisions until the PCF is informed of the result of BDT policy re-negotiation finally. If the PCF determines to reject the SM Policy Association establishment based on the invalid BDT policy, the PCF shall include in an HTTP "403 Forbidden" response message the "cause" attribute of the ProblemDetails data structure set to "INVALID_BDT_POLICY". If the PCF defers to make the policy decisions, then based on the result of the BDT policy renegotiation, the PCF may make the policy decisions or terminate the SM Policy Association as defined in this clause.

4.2.6.2.16 Number of supported packet filter for signalled QoS rule limitation support

If the PCF includes the flow information within the "flowInfos" attribute and if the number of supported packet filter for signalled QoS rules within the "numOfPackFilter" attribute is received from the SMF during the PDU session establishment, the PCF shall ensure that for all the dynamic PCC rules of a PDU session, the number of packet filters contained within the "flowDescription" attribute or the "ethFlowDescripiont" attribute with the "packetFilterUsage" set to true does not exceed the value of the "numOfPackFilter" attribute.

NOTE: The maximum number of packet filters sent to the UE per QoS rule is additionally limited by the access type. When the UE is camping in 5GS the number of packet filters is limited as specified in 3GPP TS 24.501[20].

If the PCF determines that there is a possibility to run into a restriction regarding the number of TFT packet filters that can be allocated for the PDU Session, interworking with N26 deployment is supported and "PackFiltAllocPrecedence" feature is supported, the PCF may behave as described in Annex B.3.2.0, B.3.3.0 and B.3.4.0.

4.2.6.2.17 Access traffic steering, switching and splitting support

If both the SMF and the PCF support the "ATSSS" feature as defined in clause 5.8, the PCF may enable the control of traffic steering, switching and splitting for a detected service data flow by including MA PDU Session control information within the PCC rule. In order to do so, within the PccRule data structure the PCF:

– may include one reference to the ChargingData data structure within the "refChgN3gData" attribute if the PCF determines that the specific charging parameters used for packets carried via Non-3GPP access. In this case, a "chgDecs" attribute containing the corresponding Charging Data policy decisions shall be included in the SmPolicyDecision data structure if it has not been provided;

– may include one reference to the UsageMonitoringData data structure within the "refUmN3gData" attribute if the PCF determines that the specific usage monitoring parameters used for packets carried via Non-3GPP access. In this case, a "umDecs" attribute containing the corresponding Usage Monitoring Data policy decisions shall be included in the SmPolicyDecision data structure if it has not been provided;

– may include the ATSSS rule application descriptor within "appDescriptor" attribute if the SDF template included in the PCC rule contains an Application Identifier in the "appId" attribute (see clause 4.2.6.2.1). The PCF may retrieve the OS Id(s) from the "UEPolicySet" resource in the UDR as described in 3GPP TS 29.519 [15] to determine, by internal configuration, the OS Application Identifier supported by the OS Id that corresponds to the application identifier included in the SDF template. If no OS Id is available in the UDR, the PCF may use the PEI to determine the OS Id supported by the UE;

NOTE 1: If the PCF does not take into account the received PEI and/or the retrieved OSid(s) to derive the application descriptor, then the PCF can include in the PCC rule multiple application descriptors associated to multiple operating systems.

NOTE 2: If only one UE OSid is stored in the UDR and the PCF takes it into account to derive the application descriptor, then the PCF can omit the OS Id in the application descriptor included in the PCC rule.

– may include the ATSSS policies within the Traffic Control Data decision which the PCC rule refers to. Within the TrafficControlData data structure, based on the ATSSS capability supported for the MA PDU Session, the PCF shall include:

– the applicable access traffic steering method, "ATSSS_LL" or "MPTCP", for the UL and DL traffic, encoded in the "steerFun" attribute; and

– the steering rule for access traffic distribution across the 3GPP and Non-3GPP accesses encoded in a "SteeringMode" data structure within the "steerModeDl" attribute for the DL traffic and within the "steerModeUl" attribute for the UL traffic.

The "SteeringMode" data structure shall include:

– the steering mode value determined by the PCF within the "steerModeValue" attribute as follows:

a. "ACTIVE_STANDBY" indicates the traffic of a SDF is steered on one access (the Active access), when this access is available, and switched to the other access (the Standby access), when Active access becomes unavailable. When the Active access becomes available again, the SDF is switched back to this access. If the Standby access is not defined, then the SDF is only allowed on the Active access and cannot be transferred on another access.

b. "LOAD_BALANCING" indicates that the traffic of an SDF is split percentually between the 3GPP and Non-3GPP accesses.

c. "SMALLEST_DELAY" indicates that the traffic of an SDF is steered and/or switched to the access that has the smallest delay (e.g. smallest RTT).

d. "PRIORITY_BASED" indicates that the traffic of an SDF is steered to the high priority access until the access is determined to be congested. In this case, the traffic of the SDF is also sent to the low priority access, i.e. the SDF traffic is split over the two accesses. When the high priority access becomes unavailable, all SDF traffic is switched to the low priority access. How UE and UPF determine when a congestion occurs on an access is implementation dependent.

– When the access traffic steering mode in the "steerModeValue" attribute is "ACTIVE_STANDBY", the active access encoded within the "active" attribute, and the standby access, if defined, in the "standby" attribute; or

– When the access traffic steering mode in the "steerModeValue" attribute is "LOAD_BALANCING", the traffic load distributed across 3GPP and Non-3GPP accesses encoded within the "3gLoad" attribute as the 3GPP access traffic weight percentage. The sum of the Non-3GPP access traffic weight percentage and the 3GPP access traffic weight percentage must be 100; or

– When the access traffic steering mode in the "steerModeValue" attribute is "PRIORITY_BASED", the high priority access type encoded within the "prioAcc" attribute.

If the EnATSSS feature is supported, the PCF may provide either the steering mode indicator or the authorized threshold values for RTT and/or Packet Loss Rate within the "SteeringMode" data structure as follows:

a. when the access traffic steering mode within the "steerModeValue" attribute is "LOAD_BALANCING" with fixed split percentages or "PRIORITY_BASED", the PCF may provide, within the "thresValue" attribute, the authorized threshold value of RTT encoded in the "rttThres" attribute and/or the authorized threshold value of Packet Loss Rate encoded in the "plrThres" attribute.

– For "LOAD_BALANCING" steering mode with fixed split percentages (i.e., without the "AUTO_LOAD_BALANCE" or "UE_ASSISTANCE" steering mode indicator), the traffic load distributed across accesses indicated in"3gLoad" attribute shall only apply when the measurement of RTT and/or Packet Loss Rate on both accesses do not exceed the values for RTT and/or Packet Loss Rate provided respectively in the "rttThres" and/or "plrThres" attributes. When at least one measured parameter on one access exceeds the provided threshold value, the UE and UPF may stop sending traffic on this access, or may continue sending traffic on this access, but should reduce the traffic on this access and shall send the amount of reduced traffic on the other access. How UE and UPF adjust the traffic load distributed across accesses is implementation dependent.

– For "PRIORITY_BASED" steering mode, when the measurement of RTT and/or Packet Loss Rate on the high priority access type exceeds the values for RTT and/or Packet Loss Rate provided respectively in the "rttThres" and/or "plrThres" attributes, this access may be considered as congested by the UE and the UPF. In this case, the traffic of the SDF is also sent to the low priority access.

b. when the access traffic steering mode in the "steerModeValue" attribute is "LOAD_BALANCING", the PCF may provide within the "steerModeInd" attribute:

– "AUTO_LOAD_BALANCE", when the UE and UPF are allowed to autonomously determine the traffic load of an SDF distributed across accesses; or

– "UE_ASSISTANCE", when the UE is allowed to decide how to distribute the UL traffic of an SDF and the UE may inform the UPF how it decided to distribute the UL traffic. In the normal cases, although with this indicator provided, the UE shall apply the Steering Mode provided by the network.

When the "steerModeInd" attribute is provided, the traffic load distributed across accesses indicated in "3gLoad" attribute may be ignored by the UE and UPF.

If the value of "atsssCapab" attribute received from the SMF is "MPTCP_ATSSS_LL_WITH_EXSDMODE_DL_ASMODE_UL", the PCF shall provide a PCC Rule for non-MPTCP traffic. To enable non-MPTCP traffic, the PCF shall include a "match all" packet filter within the "flowInfos" attribute, the highest value within the "precedence" attribute of the PCC rule, and within the TrafficControlData data structure referred by the PCC rule, set the "steerFun" attribute to the "ATSSS_LL", the "steerModeValue"attribute of the "steerModeUl" attribute to "ACTIVE_STANDBY", and the "steerModeValue"attribute of the "steerModeDl" attribute to any supported steering mode except the "SMALLEST_DELAY" steering mode.

If the value of "atsssCapab" received from the SMF is "MPTCP_ATSSS_LL_WITH_ASMODE_UL", the PCF shall provide a PCC rule for non-MPTCP traffic. To enable non-MPTCP traffic, the PCF shall include a "match all" packet filter within the "flowInfos" attribute, the highest value within the "precedence" attribute of the PCC rule, and within the TrafficControlData data structure referred by the PCC rule, set the "steerFun" attribute to the "ATSSS_LL", the "steerModeValue"attribute of the "steerModeUl" attribute to "ACTIVE_STANDBY", and the "steerModeValue"attribute of the "steerModeDl" attribute to any supported steering mode.

If the value of "atsssCapab" received from the SMF is "MPTCP_ATSSS_LL_WITH_ASMODE_DLUL", the PCF shall provide a PCC rule for non-MPTCP traffic. To enable non-MPTCP traffic, the PCF shall include a "match all" packet filter within the "flowInfos" attribute, the highest value within the "precedence" attribute of the PCC rule, and within the TrafficControlData data structure referred by the PCC rule, set the "steerFun" attribute to the "ATSSS_LL", the "steerModeValue"attribute of the "steerModeUl" attribute and the "steerModeDl" attribute to "ACTIVE_STANDBY.

If the value of "atsssCapab" received from the SMF is "MPTCP_ATSSS_LL", the PCF shall provide a PCC rule for non-MPTCP traffic. To enable non-MPTCP traffic, the PCF may include a "match all" packet filter within the "flowInfos" attribute, the highest value within the "precedence" attribute of the PCC rule, and within the TrafficControlData data structure referred by the PCC rule, set the "steerFun" attribute to the "ATSSS_LL", the "steerModeValue"attribute of the "steerModeUl" attribute and the "steerModeDl" attribute to any supported steering mode.

Upon receipt of the PCC rule with the MA PDU Session control information, the SMF shall:

– derive the ATSSS rules to deliver to the UE for UL traffic steering as defined in 3GPP TS 29.502 [22]. When the EnATSSS feature is supported and the SMF received for UL traffic steering either the steering mode indicator within the "steerModeInd" attribute or the threshold value(s) within the "thresValue" attribute, the SMF includes the received steering mode indication or the received threshold value(s) in the derived ATSSS Rule sent to the UE as defined in 3GPP TS 29.502 [22];;

NOTE 3: The Traffic Descriptor in the ATSSS rule is genereated by the SMF from the SDF template of the PCC rule. If the PccRule data structure contains the "flowInfos" attribute, the SMF uses the UL SDF filters for the generation of the IP descriptors or Non-IP descriptors. If the PccRule data structure contains the "appId" attribute, the SMF includes the application descriptors received from the PCF in the "appDescriptor" attribute of the PCC rule.

– derive the QoS profile and provide it to the access network(s) as follows:

– for a Non-GBR QoS flow,

a) the SMF shall provide the QoS profile to both access networks if the UE is registered over both accesses during MA PDU Session Establishment procedure;

b) the SMF shall provide the QoS profile to the access networks over which the user plane resources are activated during MA PDU Session Modification procedure.

– for a GBR QoS flow,

a) if the Multi Access policies of the PCC rule indicate the GBR SDF is handled only in one access (i.e. , the SMF shall provide the QoS profile to the access network indicated by the PCC rule;

b) if the Multi Access policies of the PCC rule indicate the GBR SDF is handled in both accesses, the SMF shall decide to which access network to provide the QoS profile for the GBR SDF based on its local policy (e.g. the local policy is configured the access where the traffic is ongoing according to the Multi Access policies of the PCC rule).

c) for a GBR QoS flow, traffic splitting is not supported because the QoS profile is provided to a single access network at a given time, and the traffic can be steered or switched as indicated by the "ACTIVE_STANDBY" steering mode. If the SMF receives the report that the current active access is not available from the UPF, the SMF shall perform as follows:

– if the corresponding PCC rule allows the GBR QoS flow only on this access or if the corresponding PCC rule allows the GBR QoS flow on both accesses but the other access is not available, the SMF shall release the resources for the GBR QoS flow and report to the PCF about the removal of the PCC rule as defined in clause 4.2.4.15.

– if the corresponding PCC rule allows the GBR QoS flow on both accesses and the other access is available, the SMF shall try to move the GBR QoS flow to the other access. The SMF may trigger a PDU session modification procedure to provide the QoS profile to the other access and release the resources for the GBR QoS flow in the current access.

– if the QoS notification control is not enabled for the corresponding PCC rule and the other access does not accept the QoS profile, the SMF shall release the resources for the GBR QoS flow and report to the PCF about the removal of the PCC rule as defined in clause 4.2.4.15.

– if the QoS notification control is enabled for the corresponding PCC rule, the SMF shall notify the PCF within the "qncReports" attribute that the QoS targets of the SDFs are not guaranteed. After the other access accepts the QoS profile, the SMF shall notify the PCF within the "qncReports" attribute that the QoS targets of the SDFs are guaranteed again. If the other access does not accept the QoS profile, the SMF shall delete the GBR QoS flow and report to the PCF about the removal of the PCC rule as defined in clause 4.2.4.15.

– instruct the UPF for DL access traffic steering as defined in 3GPP TS 29.244 [13]. When the EnATSSS feature is supported and the SMF received for DL traffic steering either the steering mode indicator within the "steerModeInd" attribute or the threshold value(s) within the "thresValue" attribute, the SMF includes the received steering mode indication or the received threshold value(s) in the derived the multi-access rule sent to the UPF as defined in 3GPP TS 29.244 [13];

– apply charging information depending on the used access type if indicated in the PCC rule; and

– apply usage monitoring control depending on the used access type if indicated in the PCC rule.

The PCF may update the steering rule for access traffic distribution across the 3GPP and Non-3GPP accesses for a PCC rule. In order to do so, the PCF may:

– within the corresponding PccRule data structure, include a new reference of a Traffic Control Data decision and provide the Traffic Control Data decision if not provided yet.

– update the Traffic Control Data decision by including the appropriate attribute value(s) within the "steerFun" attribute, "steerModeDl" attribute and/or "steerModeUl" attribute.

4.2.6.2.18 Void

4.2.6.2.19 Provisioning of PCC Rules for Mission Critical Services

4.2.6.2.19.1 General

The provision of PCC Rules corresponding to both MCS and non-MCS service shall be performed as described in clause 4.2.6.2.1 "Provisioning of PCC rules".

When the PCF derives PCC Rules corresponding to MCS service, the ARP and 5QI shall be set as appropriate for the prioritized service, e.g. an IMS Mission Critical Service. The PCF may authorize a standardized 5QI or a standardized 5QI with a specific 5QI priority level as defined in clause 4.2.6.6.2. The PCF may also authorize a non-standardized 5QI with explicitly signalled QoS characteristics as defined in clause 4.2.6.6.3.

At the time the Priority PDU connectivity services is invoked (i.e. Indication for support of priority PDU connectivity service and MCS Priority Level are set), the PCF shall upgrade the ARP and/or change 5QI for the PCC Rules to appropriate values as needed for MCS. The PCF shall change the ARP and/or 5QI (also associated QoS characteristics if applicable) modified for the priority PDU connectivity service to an appropriate value according to PCF decision.

When the PCF receives an HTTP POST message as defined in clause 4.2.2.1, the PCF shall check whether any of these parameters is stored in the UDR: indication for support of priority PDU connectivity service, indication for support of MCS Priority Level. The PCF shall derive the applicable PCC rules and default QoS flow QoS based on that information. If the indication of IMS priority service support is set and the "dnn" attribute corresponds to a DNN dedicated for IMS, the PCF shall assign an ARP corresponding to MCS for the default QoS flow and for the PCC Rules corresponding to the IMS signalling QoS flow. If the "dnn" does not correspond to a DNN dedicated for IMS, the ARP shall be derived without considering IMS Signalling Priority.

NOTE 1: Subscription data for MCS is provided to the PCF through the Nudr service.

Once the PCF receives a notification of a change in Priority PDU connectivity services support, MCS Priority Level and/or IMS priority service support from the UDR, the PCF shall make the corresponding policy decisions (i.e. ARP and/or 5QI (also associated QoS characteristics if applicable) change) and, if applicable, shall initiate an HTTP POST message as defined in clause 4.2.3.2 to provision the modified data.

NOTE 2: The details associated with the UDR service are specified in 3GPP TS 29.519 [15].

NOTE 3: The MCS Priority Level is one among other input data such as operator policy for the PCF to set the ARP.

Whenever one or more AF sessions of an MCS service are active within the same PDU session, the PCF shall ensure that the ARP priority level of the default QoS flow is at least as high as the highest ARP priority level used by any authorized PCC rules belonging to an MCS service. If the ARP pre-emption capability is enabled for any of the authorized PCC rules belonging to an MCS service, the PCF shall also enable the ARP pre-emption capability for the default QoS Flow.

NOTE 5: This PCF capability does not cover interactions with services other than MCS services.

4.2.6.2.19.2 Invocation/Revocation of Priority PDU connectivity services

When a Priority PDU connectivity services is invoked, the PCF shall:

– Derive the corresponding PCC Rules with the ARP and 5QI (also associated QoS characteristics if applicable) set as appropriate for a prioritized service.

– Set the ARP of the default QoS flow as appropriate for a Priority PDU connectivity services under consideration of the requirement described in clause 4.2.6.2.19.1.

– Set the 5QI (also associated QoS characteristics if applicable) of the default QoS flow as appropriate for the Priority PDU connectivity services.

When a Priority PDU connectivity services is revoked, the PCF shall:

– Delete the PCC Rules corresponding to the Priority PDU connectivity services if they were previously provided.

– Set the ARP of the default QoS flow to the normal ARP under the consideration of the requirements described in clause 4.2.6.2.19.1.

– Set the 5QI of the default QoS flow as appropriate for PCF decision.

– Set the ARP of all active PCC Rules as appropriate for the PCF under the consideration of the requirements described in clause 4.2.6.2.19.1.

– Set the 5QI to an appropriate value according to PCF decision if modification of the 5QI of PCC Rules is required.

NOTE: Priority PDU connectivity services can be explicitly invoked/revoked via UDR MCS user profile (Indication of Priority PDU connectivity services, MCS Priority Level). An AF for MCS Priority Service can also be used to provide Priority PDU connectivity services using network-initiated resource allocation procedures (via interaction with PCC) for originating accesses.

4.2.6.2.19.3 Invocation/Revocation of IMS Mission Critical Services

If the PCF receives service information including an MCS session indication and the service priority level from the P-CSCF or at reception of the indication that IMS priority service is active for the PDU session, the PCF shall under consideration of the requirements described in clause 4.2.6.2.19.1:

– if required, set the ARP and 5QI (also associated QoS characteristics if applicable) of the default QoS flow as appropriate for the prioritized service;

– if required, set the ARP and 5QI (also associated QoS characteristics if applicable) of all PCC rules assigned to the IMS signalling QoS flow as appropriate for IMS Mission Critical Services;

– derive the PCC Rules corresponding to the IMS Mission Critical Service and set the ARP and 5QI (also associated QoS characteristics if applicable) of these PCC Rules based on the information received over N5/Rx.

If the PCF detects that the P-CSCF released all the MCS session and the IMS priority service has been deactivated for the PDU session the PCF shall under consideration of the requirements described in clause 4.2.6.2.19.1:

– delete the PCC Rules corresponding to the IMS Mission Critical Service;

– if required, set the ARP and 5QI of the default QoS flow as appropriate for the IMS Mission Critical set to inactive;

– replace the ARP and 5QI of all PCC Rules assigned to the IMS signalling QoS flow as appropriate when the IMS Mission Critical Service is inactive.

4.2.6.2.20 PCC rules authorization with preliminary service information

If the PCF receives a request for PCC rules for a PDU session from the SMF, while no suitable authorized PCC rules are configured in the PCF or can be derived from service information provisioned by an AF, but the user is allowed to access AF session based services, the PCF may, depending e.g. on the user’s subscription details or operator policy, authorise the requested QoS for a timer supervised grace period (the timer started by the PCF by the request from the SMF) to wait for AF service information. If an AF session bound to the same PDU session is ongoing and only preliminary service information was received within this AF session, the PCF shall base the authorization of the requested QoS on the preliminary service information.

NOTE 1: This scenario can for instance be encountered for a UE terminated IMS session establishment or modification with UE initiated resource reservation, refer to 3GPP TS 29.214 [18] or 3GPP TS 29.514 [17]. If the PCF does not authorize a request for PCC rules in this scenario, the IMS session setup can fail.

NOTE 2: During the grace period, the QoS and packet filters requested by the UE need to be authorized even if the user is not allowed to request for resources for services not known to the PCF or if the requested 5QI is not allowed for services not known to the PCF as it is not clear at this point in time whether the UE resource request belongs to an AF session or to a service not known to the PCF.

If the preliminary service information is insufficient to construct appropriate PCC rules or no preliminary service information is available, the PCF shall provide preliminary PCC rules to authorize the UE requested QoS and packet filters. Therefore, the preliminary PCC rules shall contain wildcarded flow description or flow description derived from possible packet filters received as part of the request for PCC rules. The PCF may apply a dedicated charging key value to indicate to the charging subsystem that the charging key is preliminary and may be corrected later on.

NOTE 3: With the dedicated charging key, the PCF instructs the charging subsystem to recalculate the applicable charge for the time when the dedicated charging key value was applied once the dedicated charging key value is replaced with some other value in a new provisioning of PCC rules. For example, if online charging applies, Session Charging with Unit Reservation (SCUR) can be used .When the charging key changes, the SMF will return initially reserved credit units and the CHF then can recalculate the consumed credit units applying the rate derived from the new other charging key value and update the user’s credit accordingly.

NOTE 4: A preliminary PCC rule is a normal PCC rule containing preliminary information.

If the PCF receives AF service information while the timer-supervised grace period is running, the PCF shall stop the timer and may derive authorized PCC rules from this service information and update or replace the preliminary PCC rules that were previously provided for the UE requested QoS and packet filters, for instance by choosing service specific QoS parameters and charging keys.

NOTE 5: The dedicated preliminary charging key value that was previously provided by the PCF instructs the charging subsystem to recalculate the applicable charge when the new service specific charging key is provided. The recalculation covers the time when the previous dedicated charging key value was active. The new service specific charging key is applied from that time onwards.

If the timer expires and the PCF has not received any AF service information, the PCF should apply the policy for services not known to the PCF and may downgrade or revoke the authorization for the preliminary PCC rules (previously provided for the UE requested QoS and packet filters) in accordance with the policy for services not known to the PCF. The PCF should adjust the charging keys within the PCC rules and should downgrade the authorized QoS to the allowed value for the services not known to the PCF, if required.

4.2.6.3 Session Rules

4.2.6.3.1 Overview

The PCF may perform operations on session rules. The impacted rules shall be included in the "sessRules" map attribute within the SmPolicyDecision data structure with the "sessRuleId" as a key. For installing or modifying a session rule, the corresponding SessionRule data instance shall be provided as the map entry value. For removing a session rule, the map entry value shall be set to NULL.

In order to install a new session rule, the PCF shall further set other attributes within the SessionRule data structure as follows:

– if the "subsSessAmbr" has been previously received by the PCF, it shall include the authorized Session-AMBR within the "authSessAmbr" attribute;

– when the "subsDefQos" has been previously received by the PCF, it shall include the authorized default QoS within the "authDefQos" attribute using the procedure as defined in clause 4.2.6.3.3;

– it may include one reference to the UsageMonitoringData data structure within the "refUmData" attribute. In this case, a "umDecs" attribute containing the corresponding Usage Monitoring data policy decisions shall be included in SmPolicyDecision data structure if it has not been previously provided;

– if the "ATSSS" feature is supported, it may include one reference to the UsageMonitoringData data structure to apply for the Non-3GPP access within the "refUmN3gData" attribute. In this case, a "umDecs" attribute containing the corresponding Usage Monitoring data policy decisions shall be included in SmPolicyDecision data structure if it has not been previously provided; and

– it may include one reference to the ConditionData data structure within the "refCondData" attribute. In this case, a "conds" attribute containing the corresponding Condition Data decision shall be included in SmPolicyDecision data structure if it has not been previously provided.

In order to modify an existing session rule, the PCF shall further set other attributes within the SessionRule data structure as follows:

– If the PCF needs to modify the attribute(s) within a session rule, the PCF shall include the modified attribute(s) with the new value(s) within the SessionRule data instance. Previously supplied attributes not supplied in the modified PCC rule instance shall remain valid.

– If the PCF only needs to modify the content of referenced policy decision data (e.g. UsageMonitoringData, etc.) and/or condition data for one or more session rules, the PCF shall, within the SmPolicyDecision data structure, include the corresponding policy decision data and/or condition data within the corresponding map attributes (e.g. include the usage monitoring data decision within the "umDecs" attribute).

The PCF may combine multiple of the above session rule operations in a single message, but the PCF shall ensure that one and only one session rule is enforced in the SMF at a certain point in time.

NOTE: Either there is always an unconditional session rule provisioned in the NF service consumer (SMF), or there is always a conditioned session rule applicable in the NF service consumer (SMF).

4.2.6.3.2 Conditioned Session rule

4.2.6.3.2.1 General

Up to four conditioned session rules (i.e. authorized Session-AMBR and authorized default QoS) may be provisioned by the PCF. In order to provision a session rule with conditional data, the PCF shall provision a session rule as defined in clause 4.2.6.3.1 and include within its "refCondData" attribute the corresponding ConditionData’s "condId" attribute value. The PCF shall also ensure that the referenced ConditionData instance is included in the "conds" map within the SmPolicyDecision data structure following the procedures defined in clause 4.2.6.1 and that the referenced usage monitoring data is the same for all the provisioned conditioned and non-conditioned session rule(s).

Within the ConditionData instance, the PCF shall include the activation time within the "activationTime" attribute for the time conditioned authorized Session-AMBR and authorized default QoS (deactivation time does not apply for a session rule). If the "AccessTypeCondition" feature as defined in clause 5.8 is supported, the PCF may include for the access type conditioned session rule the access type within the "accessType" attribute and RAT type within the "ratType" attribute if applicable for the access type conditioned authorized Session-AMBR.

NOTE 1: The SMF retains remaining time conditioned session rules that have an execution time in the future.

NOTE 2: Time condition and access type condition can both apply to authorize the Session-AMBR within a session rule.

The PCF shall ensure that a time conditioned session rule and a session rule without time condition for the same session differ only in the authorized session-AMBR and authorized default QoS properties.

When the SMF detects that the referenced usage monitoring data of the enforced session rule is not the same for all the provisioned session rule(s) the SMF shall report the session rule error for the not enforced session rule(s) as defined in clauses 4.2.3.20 and 4.2.4.21, and shall set the "failureCode" attribute to "INCORRECT_UM".

If the SMF receives the conditioned session rule, when the condition indicated in the related attribute(s) within the Condition Data decision (e.g. at the time indicated in the "activationTime" attribute) is met, the SMF shall perform the conditional policy without interaction with the PCF. If the Condition Data decision includes more than one type of conditions and all the types of conditions are met, the SMF shall perform the conditional policy.

If time conditioned session rule(s) to change the non-conditioned session rule are received by the SMF and the earliest Activation Time is in the past, then the SMF shall immediately enforce the most recent time conditioned instance that is not in the future.

The PCF may modify a currently installed session rule, including setting, modifying or deleting its condition(s) as follows:

1) When modifying a session rule by setting the condition(s), the PCF shall update the session rule by including the corresponding ConditionData’s "condId" attribute value within the "refCondData" attribute and within the SmPolicyDecision data structure include the ConditionData instance within the "conds" attribute if not provisioned yet.

2) When modifying a session rule by modifying the condition(s):

– the PCF may update the session rule by replacing the existing ConditionData instance’s "condId" attribute value within the "refCondData" attribute with a new one and within the SmPolicyDecision data structure include the new ConditionData instance within the "conds" attribute if not provisioned yet; or

– the PCF may update the condition data decision which the session rule refers to by updating the corresponding ConditionData instance as defined in clause 4.2.6.1. The PCF may update the value of the condition within the related attribute (e.g. the value of the existing deferred activation time within the "activationTime" attribute).

3) When modifying a session rule by deleting the condition(s):

– the PCF shall delete the reference to the ConditionData instance within the session rule by updating session rule with the "refCondData" attribute set to NULL; and

– the PCF may delete the condition data decision which the session rule refers to as defined in clause 4.2.6.1 if no other session rules are referring to the condition data decision.

To delete a conditioned session rule, the PCF shall perform the deletion of session rule as defined in clause 4.2.6.3.1. The "ueTimeZone" attribute, if available, may be used by the PCF to derive the value for the "activationTime" attribute.

NOTE 3: Conditioned Session-AMBR and default QoS change helps reducing the signalling load over N7. However, the Session-AMBR and default QoS change needs to be communicated to the UE. Consequently a simultaneous change of the Session-AMBR and default QoS for many UE(s) may introduce a signalling storm in the 5GC (e.g. over N1/N2/N4/N11). The PCF can avoid this simultaneous change of the Session-AMBRSession-AMBR and default QoS (e.g. spread the time conditioned change over time for many UEs).

NOTE 4: For services that depend on specific Session-AMBR and/or default QoS change (e.g. an MPS session), the PCF is responsible to ensure that no conditioned session rules interfere with the service (e.g., ensure proper MPS operation by removing time conditioned settings that would later impact MPS).

4.2.6.3.2.2 Time conditioned authorized Session-AMBR

The procedures in clause 4.2.6.3.2.1 apply with clarifications in the present clause.

Each instance of the session rule shall include authorized Session-AMBR within the "authSessAmbr" attribute.

If the "VPLMN-QoS-Control" feature is supported and the PCF receives the session AMBR constraints from the SMF, the PCF shall ensure that the authorized session AMBR value within each instance of the session rule does not exceed the session AMBR supported by the VPLMN, if applicable.

The SMF shall, after applying a time conditioned instruction to change the authorized AMBR, apply the corresponding procedures towards to the access network, the UE and the UPF for the enforcement of the AMBR per PDU session.

4.2.6.3.2.3 Time conditioned authorized default QoS

The procedures in clause 4.2.6.3.2.1 apply with clarifications in the present clause.

Each instance of the session rule shall include authorized default QoS within the "authDefQos" attribute.

If the "VPLMN-QoS-Control" feature is supported and the PCF receives the default QoS constraints from the SMF, the PCF shall ensure that the authorized default QoS containing a 5QI and ARP value within each instance of the session rule is supported by the VPLMN, if applicable.

The SMF shall, after applying a time conditioned instruction to change the authorized default QoS, apply the corresponding procedures towards to the access network, the UE and the UPF for the enforcement of the authorized default QoS. All PCC rule(s) with the "defQosFlowIndication" attribute set to true shall remain bound to the default QoS flow. For any other PCC rule previously bound to the default QoS flow, SMF shall then perform the QoS flow binding according to clause 6.4 in 3GPP TS 29.513 [7].

4.2.6.3.2.4 Access type conditioned authorized Session-AMBR

The SMF shall enforce the Session-AMBR values corresponding to the session rule whose referred ConditionData instance contains the "accessType" attribute and "ratType" attribute matching the current access type and RAT type of the UE for the given PDU session. If the "VPLMN-QoS-Control" feature is supported and the PCF receives the session AMBR constraints from the SMF, the PCF shall ensure that the authorized session AMBR value within each instance of the session rule does not exceed the session AMBR supported by the VPLMN, if applicable.

The PCF shall ensure that an access type conditioned session rule and a session rule without any access type condition for the same session differ only in the authorized session-AMBR property. If more than one access type conditioned session rules are provisioned, and if there is no session rule without any access type condition provisioned in the SMF, the PCF shall ensure that any two access type conditioned session rules for the same session differ only in the authorized session-AMBR property.

NOTE: Access type conditions are only applicable to the authorized session-AMBR.

If there is a session rule whose authorized Session-AMBR does not depend on any access type condition provided and there is also a session rule with an access type conditioned authorized Session-AMBR provided, then the access type conditioned session rule where the conditions specified within the Condition Data decision are met shall be enforced. Otherwise, the session rule with the authorized Session-AMBR without any access type condition shall be enforced.

If conditions from multiple access type conditioned the session rule with authorized Session-AMBR are met at the same time then the session rule related to the most strict matching condition is enforced, e.g. Policy1 specifies access type only and Policy2 specifies access type (with the value same as in Policy1) and an RAT Type, both, then the Policy2 shall be enforced when the UE’s current access type and RAT type matches with the condition specified by Policy2.

If conditions from multiple access type conditioned the session rule with authorized Session-AMBR are met at the same time and all of these policies are equally applicable, e.g. Policy1 specifies access type only and Policy2 specifies RAT type only and if the UE’s current access type matches with Policy1 and the UE’s current RAT type matches with Policy2, then the SMF should apply the Session-AMBR with Policy2.

An access type conditioned session rule does not apply to a MA PDU session. When the "ATSSS" feature is supported, and the PDU session is a MA PDU session, the PCF shall not provide to the SMF access type conditioned session rules. If access type conditioned session rules are provisioned in the SMF for a MA PDU session (e.g. because of error in the PCF or EPS to 5GS handover) they shall be ignored.

4.2.6.3.3 Provisioning of authorized default QoS

The PCF can provide the authorized default QoS for a session rule to the SMF. The provisioning of authorized default QoS for a session rule shall be performed using the session rule provisioning procedure as defined in clause 4.2.6.3.1. The authorized default QoS shall be encoded using an AuthorizedDefaultQos data structure.

In order to provision authorized default QoS for a new session rule, the PCF shall include the assigned 5QI value within the "5qi" attribute and the assigned ARP value within the "arp" attribute in the AuthorizedDefaultQos data structure. The PCF may include the "priorityLevel" attribute in the AuthorizedDefaultQos data structure to authorize the particular 5QI priority level to override the default value for a standardized or pre-configured 5QI. The PCF may include a "QosCharacteristics" entry in the "qosChars" attribute map to provide explicitly signalled QoS characteristics associated with a 5QI that is neither standardized nor pre-configured. When the authorized default QoS applies to explicitly signalled QoS Characteristics, it shall be provisioned as defined in clause 4.2.6.6.3. For 5QI of GBR type or delay critical GBR type, the PCF shall additionally include max bandwidth in uplink within the "maxbrUl" attribute and/or max bandwidth in downlink within the "maxbrDl" attribute, the guaranteed bandwidth in uplink within the "gbrUl" attribute and/or the guaranteed bandwidth in downlink within the "gbrDl" attribute and may include the particular averaging window within the "averWindow" attribute and/or particular maximum data burst volume within the "maxDataBurstVol" or "extMaxDataBurstVol" (if supported, see clause 4.2.2.1) attribute to override the default values for a standardized or pre-configured 5QI.

In order to modify authorized default QoS for an existing session rule, the PCF shall include the modified attribute(s) with the new value(s) within the AuthorizedDefaultQos data structure and provision a new QoS Characteristics if applicable. Previously supplied attributes not supplied in the AuthorizedDefaultQos data structure shall remain valid.

4.2.6.3.4 Access traffic steering, switching and splitting support

If both the SMF and the PCF support the "ATSSS" feature, the PCF may enable the control of the PDU session level Usage Monitoring information depending on what access type is used to carry service data flows.

When the PCF determines that at PDU session level different usage monitoring data shall be defined for the 3GPP and the Non-3GPP access, the PCF shall include within the SessionRule data structure one reference to the UsageMonitoringData policy decision to apply for the Non-3GPP access within the "refUmN3gData" attribute, and a "umDecs" attribute containing the corresponding Usage Monitoring Data policy decisions if it has not been previously provided. When the "refUmN3gData" is omitted, the attribute "refUmData" contains the reference to the UsageMonitoringData policy decision to apply for both, 3GPP and Non-3GPP, accesses.

NOTE: To ensure that the traffic of a set of service data flows is excluded for both, the 3GPP access and Non-3GPP access, from the PDU session level usage monitoring, the "exUsagePccRuleIds" attribute is set to the same value within the Usage Monitoring Control decision referred by the "refUmN3gData" attribute and within the Usage Monitoring Control decision referred by the "refUmData" attribute.

4.2.6.3.5 Usage Monitoring Control

Usage monitoring may be performed for all the traffic of a PDU session in the SMF or for all the traffic of a PDU session excluding the traffic of a service data flow or a group of service data flows.

The provisioning of usage monitoring control for the traffic of a PDU session shall be performed using the session rule provisioning procedure as defined in clause 4.2.6.3.1. When the traffic of a service data flow or a group of service data flows is excluded from the traffic of the PDU session, the UsageMonitoringData policy decision referred within the "refUmData" attribute, and/or the UsageMonitoringData policy decision referred within the "refUmN3gData" attribute when the "ATSSS" feature is supported, shall include the "exUsagePccRuleIds" attribute as defined in clause 4.2.6.5.3.1.

Usage monitoring for all the session rules (conditioned and non-conditioned) shall refer to the same UsageMonitoringData policy decision(s), i.e., the monitoring key that applies to all the traffic of a PDU session, or to all the traffic of a PDU session except certain service data flow(s), shall not change because of the activation of a conditioned session rule.

4.2.6.4 Policy control request triggers

The PCF may provide one or several policy control request trigger(s) to the SMF. In order to do so, the PCF shall include one or several policy control request trigger(s) within the "policyCtrlReqTriggers" attribute within the SmPolicyDecision data structure.

During the lifetime of the PDU session, the PCF may update or remove the policy control request triggers. In order to update the policy control request trigger, the PCF shall provide the new complete list of applicable policy control request triggers by including one or several policy control request trigger(s) within the "policyCtrlReqTriggers" attribute within the SmPolicyDecision data structure.

The PCF may remove all previously provided policy control request triggers by providing a "policyCtrlReqTriggers" attribute set to the value NULL. Upon reception of a policy control request trigger with this value, the SMF shall not inform PCF of any trigger except for those triggers that are always reported and do not require provisioning from the PCF.

Whenever the PCF provisions one or several policy control request trigger(s) by using an HTTP POST message as defined in clause 4.2.3.2, unless otherwise specified in a policy control request trigger’s value definition, the SMF shall send the corresponding currently applicable values (e.g. access type, RAT type, user location information, etc.) to the PCF within the UeCampingRep data structure in the response of the HTTP POST message, and in this case, the "repPolicyCtrlReqTriggers" attribute shall not be included.

4.2.6.5 Encoding of the request of information reporting

4.2.6.5.1 Request of Access Network Charging Identifier

When the Access Network Charging Identifier is unknown for an AF session to the PCF, the PCF may request the SMF to provide the Access Network Charging Identifier associated to the dynamic PCC rules. To do so, the PCF shall within SmPolicyDecision data structure provide the "policyCtrlReqTriggers" attribute with the value "AN_CH_COR" if the policy control request trigger is not previously set and the "lastReqRuleData" attribute. For the RequestedRuleData instance, the PCF shall include the CH_ID within the "reqData" attribute and reference of the PCC rule within the "refPccRuleIds" attribute.

The PCF shall interpret that the Access Network Charging Identifier is known when the PCF receives an "accNetChId" attribute with the "sessionChScope" attribute included and set to true as defined in clause 4.2.2.11 and 4.2.4.13.

4.2.6.5.2 RAN NAS Cause Support

When the RAN-NAS-Cause feature is supported, the PCF may request the SMF to inform it of the result of PCC rule(s) removal, when the PCF removes PCC rule(s). In order to do so, the PCF shall additionally include the "policyCtrlReqTriggers" attribute containing the "RES_RELEASE" value if this policy control request trigger was not previously set, and the "lastReqRuleData" attribute. Within the RequestedRuleData instance, the PCF shall include the "RES_RELEASE" value within the "reqData" attribute and reference the removed PCC rule within the "refPccRuleIds" attribute.

NOTE: This is done to allow the PCF to notify the AF when there is an abnormal termination of the QoS flow. The PCF does not have to retry the removal of these PCC Rules.

4.2.6.5.3 Provisioning of the Usage Monitoring Control Policy

4.2.6.5.3.1 General

The PCF may indicate the need to apply monitoring control of the accumulated usage of network resources on a per PDU session basis. Usage is defined as volume or time of user plane traffic. Monitoring for traffic volume and traffic time can be performed in parallel. The data collection for usage monitoring control shall be performed per monitoring key, which may apply to a single service data flow, a set of service data flows or all the traffic in a PDU session. If usage monitoring at PDU session level is enabled, the PCF may request the SMF to exclude a single service data flow or a set of service data flows from usage monitoring at PDU session level.

During PDU session establishment, the PCF may receive information from the UDR about total the allowed usage per DNN / S-NSSAI combination and UE, i.e. the overall amount of allowed traffic volume and/or time of usage that are to be monitored per DNN / S-NSSAI combination and UE and/or the total allowed usage for Monitoring key(s) per DNN / S-NSSAI combination and UE.

NOTE 1: It depends on the implementation of UDR whether to provide the total allowed usage per DNN / S-NSSAI combination and UE to different PCFs if these different PCFs are serving PDU sessions with the same value of DNN / S-NSSAI combination and UE.

If the SMF supports the UMC feature, the PCF may request usage monitoring control for a PDU session. If at that time the PCF has not provided "US_RE" policy control request trigger to the SMF, the PCF shall include the "policyCtrlReqTriggers" attribute with the value "US_RE" and provide it to the SMF as defined in clause 4.2.6.4. The PCF shall not remove the "US_RE" policy control request trigger while usage monitoring is still active in the SMF.

At PDU session establishment and modification, the PCF may provide to the SMF, for each usage monitoring control instance, the applicable threshold(s), i.e. volume threshold, time threshold or both volume threshold and time threshold. To provide the initial threshold(s) for each usage monitoring control instance, the PCF shall include these threshold(s) within the "umDecs" attribute within the SmPolicyDecision data structure.

The PCF may provide a monitoring time to the SMF for the usage monitoring control instance(s) and optionally specify a subsequent threshold value for the usage after the monitoring time.

Threshold levels may be defined for:

– the total volume only; or

– the uplink volume only; or

– the downlink volume only; or

– the uplink and downlink volume; and/or

– the time.

Threshold levels, monitoring time, if applicable, and inactive time, if applicable, for each usage monitoring control instance may be provisioned within an entry of the "umDecs" attribute as follows:

– the total volume threshold, if applicable, within the "volumeThreshold" attribute;

– the uplink volume threshold, if applicable, within the "volumeThresholdUplink" attribute;

– the downlink volume threshold, if applicable, within the "volumeThresholdDownlink" attribute;

– the time threshold, if applicable, within the "timeThreshold" attribute;

. the total volume threshold after the monitoring time, if applicable, within the "nextVolThreshold" attribute;

– the uplink volume threshold after the monitoring time, if applicable, within the "nextVolThresholdUplink" attribute;

– the downlink volume threshold after the monitoring time, if applicable, within the "nextVolThresholdDownlink" attribute;

– the time threshold after the monitoring time, if applicable, within the "nextTimeThreshold" attribute;

– the monitoring time, if applicable, within the "monitoringTime" attribute;

– the inactive time, if applicable, within the "inactivityTime" attribute.

If the SMF reports usage before the monitoring time is reached, the monitoring time is not retained by the SMF. Therefore, the PCF may again provide in the response a monitoring time and optionally the subsequent threshold value(s) for the usage after the monitoring time.

The "inactivityTime" attribute represents the time interval after which the time measurement shall stop for the Monitoring Key, if no packets belonging to the corresponding Monitoring Key are received. Time measurement shall resume again 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 "inactivityTime" attribute with value of zero is provided, or if no "inactivityTime" attribute is present within the usage monitoring control instance provided by the PCF, the time measurement shall be performed continuously from the point the first packet is received matching the applicable Monitoring Key is received and until time based usage monitoring is disabled.

If the usage monitoring control instance applies to the PDU session level, the PCF shall include the reference to the Usage Monitoring Data decision within the "refUmData" attribute of the related session rule.

If the usage monitoring control instance applies to a service data flow or a group of service data flows, the PCF shall include the reference to the Usage Monitoring Data decision within the "refUmData" attribute of the related PCC rule(s).

The PCF may provide one usage monitoring control instance applicable at PDU session level and one or more usage monitoring control instances applicable at PCC Rule(s) level.

If the PDU session level usage monitoring is enabled and service data flow(s) need to be excluded from this PDU session level usage monitoring, the PCF shall include the corresponding PCC rule identifier(s) within the "exUsagePccRuleIds" attribute of the UsageMonitoringData instance of PDU session level usage monitoring. If the exclusion is enabled, the PCF may disable the exclusion again for service data flow(s) by removing the corresponding PCC rule identifier(s) from "exUsagePccRuleIds" attribute.

The PCF may provide new volume threshold(s) and/or a new time threshold to the SMF. The new threshold value(s) override the existing value(s) in the SMF.

When the SMF receives above the usage monitoring control request from the PCF, the SMF shall initiate the PFCP Session Establishment procedure as defined in clause 7.5.2, or the PFCP Session Modification procedure, as defined in clause 7.5.4 of 3GPP TS 29.244 [13], to request the UPF to perform the usage monitoring control.

If the reset time of the usage monitoring related information (see clause 5.4.2.7 of 3GPP TS 29.519 [15]) is reached, the PCF shall reset the remaining allowed usage to the value(s) indicated in the usage monitoring related information and shall then interact with the SMF to undo any previously applied policy decisions related to remaining allowed usage of zero (or below zero).

NOTE 2: The PCF can also update the related usage monitoring information in the UDR as defined in 3GPP TS 29.519 [15] according to the performed reset action.

4.2.6.5.3.2 Disabling Usage Monitoring

After usage monitoring is enabled, the PCF may explicitly disable usage monitoring as a result of receiving an SM Policy association update from the SMF which is not related to reporting usage, but to other external triggers (e.g., receiving an AF request, subscriber profile update), or a PCF internal trigger. When the PCF disables usage monitoring, the SMF shall report the accumulated usage which has occurred while usage monitoring was enabled since the last report.

To disable usage monitoring for a monitoring key, the PCF shall provide either the SMF with the corresponding applicable attributes of the usage monitoring control instance containing a NULL value (e.g. the previous provided "volumeThreshold" is set to NULL"), or:

– for dynamic PCC rule(s) or session rule(s), remove the reference to the corresponding usage monitoring control instance from all the dynamic PCC rule(s) or session rule(s) referencing it;

NOTE: The PCF could keep the UsageMonitoringData policy decision valid in the SMF.

– for predefined PCC rule(s), remove the UsageMonitoringData policy decision referred from all the activated predefined PCC rule(s).

When the PCF disables usage monitoring for usage monitoring key(s) via a Npcf_SMPolicyControl_UpdateNotify or a Npcf_SMPolicyControl_Update service operation, the SMF shall trigger a new Npcf_SMPolicyControl_Update service operation using the procedures specified in clause 4.2.4.10 to report accumulated usage for the disabled usage monitoring key(s).

4.2.6.5.3.3 PCF Requested Usage Report

When usage monitoring is enabled, the PCF may request the SMF to report the accumulated usage for one or more enabled usage monitoring control instance(s) regardless of whether associated usage threshold(s) have been reached or not. In order do so, the PCF shall include the "lastReqUsageData" attribute containing one or more reference(s) to usage monitoring data decision(s) within the "refUmIds" attribute or the "allUmIds" attribute set to true in an HTTP POST request or in the response of an HTTP POST request from the SMF. The PCF shall require the SMF to report accumulated usage for one or more enabled usage monitoring control instance(s) only in a response to received HTTP POST request from the SMF when the SMF has not provided accumulated usage in this HTTP POST request for the same usage monitoring control instance(s).

4.2.6.5.4 Request for Access Network Information

When the NetLoc feature is supported, if the AF requests the PCF to report the access network information as described in clauses 4.2.2, 4.2.3 or 4.2.4 of 3GPP TS 29.514 [17] or in clauses 4.1 and 4.2 of 3GPP TS 29.214 [18], the PCF shall perform the PCC rule provisioning procedure as defined in clause 4.2.6.2.1 and additionally provide the requested access network information indication (e.g. user location and/or user timezone information) to the SMF as follows:

– it shall include the "lastReqRuleData" attribute to contain the "reqData" attribute with the value(s) MS_TIME_ZONE and/or USER_LOC_INFO and the "refPccRuleIds" attribute to contain the related installed/modified/removed PCC rule identifier(s).

– it shall provide the AN_INFO policy control request rigger within the "policyCtrlReqTriggers" attribute (if not yet set).

For those PCC Rule(s) based on preliminary service information as described in 3GPP TS 29.514 [17] or in 3GPP TS 29.214 [18], the PCF may assign the 5QI and ARP of the default QoS flow to avoid signalling to the UE. These PCC Rules shall not include the "packetFilterUsage" attribute set to true within the "flowInfos" attribute.

For those PCC Rule(s) based on AF signalling as described in 3GPP TS 29.514 [17] or in 3GPP TS 29.214 [18], the PCF may use 5QI and ARP for AF signalling to avoid signalling to the UE. These PCC Rules shall not include the "packetFilterUsage" attribute set to true within the "flowInfos" attribute.

NOTE: Similarly, for predefined PCC rules based on AF signalling, these PCC Rule(s) could be defined with the 5QI and ARP for AF signalling, and cannot include packet filter usage information.

4.2.6.5.5 Request for the successful resource allocation notification

The PCF may request the SMF to confirm that the resources associated to a PCC rule are successfully allocated. To do so, the PCF shall provide within the "policyCtrlReqTriggers" attribute of the SmPolicyDecision data structure the value "SUCC_RES_ALLO ", if this policy control request trigger was not previously set, and provide the "lastReqRuleData" attribute as well. For the associated RequestedRuleData instance, the PCF shall include the value "SUCC_RES_ALLO" within the "reqData" attribute and the reference to the PCC rule within the "refPccRuleIds" attribute.

4.2.6.5.6 Provisioning of Presence Reporting Area Information

When the PRA or ePRA feature is supported, the PCF may determine during the lifetime of the PDU session whether reports on the change of UE presence in Presence Reporting Area(s) are desired for this PDU session based on the subscriber’s profile configuration. If such reporting is desired for a PDU session, the PCF shall provide the "praInfos" attribute within the SmPolicyDecision data structure. Within each associated PresenceInfoRm data structure, the PCF shall include the Presence Reporting Area Identifier within the "praId" attribute, and, for a UE-dedicated Presence Reporting Area, the list of elements composing the presence reporting area within the "trackingAreaList" attribute, the "ecgiList" attribute, the "ncgiList" attribute, the "globaleNbIdList" attribute and/or the "globalRanNodeIdList" attribute. The PCF shall also activate the reporting of the changes of UE presence in the provided Presence Reporting Area(s) by provisioning the "PRA_CH" policy control request trigger to the SMF, within the "policyCtrlReqTriggers" attribute.

NOTE 1: If this feature is not supported, the PCF can instead activate location change reporting that enables to receive reports of the actual location of the UE. Due to the potential increase in signalling load, careful consideration of the network load is necessary for such reporting, e.g. by limiting the number of subscribers subject to such reporting.

If the PCF is configured with a Presence Reporting Area identifier referring to a list of Presence Reporting Area Identifier(s) within a Set of Core Network predefined Presence Reporting Areas as defined in 3GPP TS 23.501 [2], the PCF shall include only the identifier of the Presence Reporting Area Set within the "praId" attribute.

NOTE 2: The Presence Reporting Area Identifier can correspond to a list of Presence Reporting Area Identifier(s) within a Set of Core Network predefined Presence Reporting Areas (PRA set identifier) as defined in 3GPP TS 23.501 [2].

The PCF may modify the list of PRA Identifier(s) by providing new Presence Reporting Area(s) or removing existing Presence Reporting Area(s), or modify the list of Presence Reporting Area element(s) by providing the updated Presence Reporting Area(s). In order to do that,

– when the PRA feature is supported, the PCF shall follow the general procedure defined in clause 4.2.6.1 and supply the Presence Reporting Area identifier(s) as key(s) of "praInfos" the map attribute; or

– when the ePRA feature is supported, the PCF shall follow the general procedure defined in clause 4.2.6.1 and supply the Presence Reporting Area identifier(s) as key(s) of "praInfos" map, with the exception that for the modification of the list of the Presence Reporting Area element(s) the PCF shall fully replace the Presence Reporting Areas(s) previously provided with the new complete list of Presence Reporting Area element(s).

NOTE 3: When the PRA feature is supported, the PCF cannot indicate the SMF to remove an existing Presence Reporting Area element(s) from a Presence Reporting Area by providing the updated Presence Reporting Area as defined in clause 4.2.6.1. How to support it depends on implementation.

When PRA or ePRA feature is supported, the PCF may remove the associated policy control request trigger (i.e. "PRA_CH") as defined in clause 4.2.6.4, if previously activated.

If the NF service consumer and the PCF support both PRA and ePRA features, the NF service consumer and PCF shall perform the behaviours as the ePRA feature defined.

If the "PRA_CH" policy control request trigger is provisioned, when the PCF provides a list of presence reporting areas as described above, the PCF shall ensure that the maximum number of provisioned Presence Reporting Area Identifiers is not exceeded. The maximum number of PRAs may be configured in the PCF. The PCF may have independent configuration of the maximum number for Core Network pre-configured PRAs and UE-dedicated PRAs.

NOTE 4: For all the Presence Reporting Area(s) provided by the PCF, the SMF can store the Presence Reporting Area Identifier(s) together with an indication that states that it relates to PCF requested PRA status changes.

NOTE 5: This information is needed so that if both the PCF and the CHF request the reporting of PRA status changes, the SMF is able to differentiate whether the reported PRA changes are relevant to the PCF or the CHF.

The SMF shall invoke the Namf_EventExposure service in the AMF to handle the subscription to the presence state of a UE in an area of interest as specified in 3GPP TS 29.518 [36].

The PCF may be notified during the lifetime of a PDU session that the targeted UE is located in an access network where local configuration indicates that reporting changes of UE presence in Presence Reporting Area(s) is not supported. The PCF may then remove the associated policy control request trigger (i.e. "PRA_CH"), if previously activated. In this case, the PCF shall also remove the provisioned Presence Reporting Area(s) by including the "praInfos" attribute set to NULL within the SmPolicyDecision data structure.

The SMF shall remove the Namf_EventExposure service subscription with the AMF for the reporting of Changes of UE presence in Presence Reporting Area(s), when the PCF and CHF remove the associated request triggers.

4.2.6.5.7 Policy provisioning and enforcement of reflective QoS

If the PCF receives the "refQosIndication" attribute set to true as defined in clauses 4.2.2.2 or 4.2.4.2, and if the PCF determines that Reflective QoS Control will be enabled for the PDU session based on the operator’s policy and user subscriptions, the PCF may provision the Reflective QoS Timer by including the "reflectiveQoSTimer" attribute within the SmPolicyDecision data structure in the response message.

The provisioning of reflective QoS may be performed for service data flows associated with one or more PCC rules, and shall be performed using the PCC rule provisioning procedure. The PCF may within a QoS data decision which a PCC rule refer to include the "reflectiveQos" attribute set to true to enable the Reflective QoS control to a non-GBR downlink service data flow when the PCF authorizes the QoS for the service data flow as defined in clause 4.2.6.6.2.

The PCF shall ensure that both, uplink and downlink traffic for such non-GBR service data flow are allowed.

NOTE 1: The PCF can allow both uplink and downlink traffic for the non-GBR service data flow in several ways, e.g. by installing a PCC rule with uplink and downlink flow information, or by installing separate PCC rules for the uplink flows and downlink flows, or by installing a PCC rule with only the application identifier.

The PCF shall activate the reporting changes of reflective QoS indication by provisioning the "REF_QOS_IND_CH" policy control request trigger to the SMF.

NOTE 2: While the UE applies a standardized value for the precedence of all UE derived QoS rules, PCC rules precedence values can vary 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 and will setting the precedence value of PCC rules subject to Reflective QoS to a value in the range from 70 to 99 (decimal), as specified in 3GPP TS 24.501 [20], clause 6.2.5.1.1.3.

The SMF shall apply reflective QoS control for the downlink traffic of the service data flows of the PCC rules that reference a QosData decision that includes "reflectiveQos" attribute set to true.

The PCF shall not include the "reflectiveQos" attribute set to true within the QoS data decision which the PCC rule with match-all SDF template refers to. If a PCC rule with match-all SDF template has been provisioned to the SMF, the PCF shall not include the "reflectiveQos" attribute within the QoS data decision which contains the "defQosFlowIndication" attribute, either.

If the PCF receives the "refQosIndication" attribute set to false as defined in clause 4.2.4.2, the PCF shall disable the reflective QoS Control for the PDU session. In order to do so, the PCF shall within the QoS data decision which affected PCC rule refer to include the "reflectiveQos" attribute set to false and may update other QoS parameters within the QoS data decision and/or update the flow information of PCC rule by including the "packetFilterUsage" attribute set to true.

4.2.6.6 Authorized QoS

4.2.6.6.1 General

The PCF shall provision the authorized QoS. The authorized QoS may apply to a PCC rule or to a PDU session.

– When the authorized QoS applies to a PCC rule, it shall be provisioned within the corresponding PCC rule as defined in clause 4.2.6.6.2.

– When the authorized QoS for a PCC rule with a GBR QCI is candidate for resource sharing an instruction on the allowed sharing may be provisioned as defined in clause 4.2.6.2.8.

– When the authorized QoS applies to a PDU session, it shall be provisioned as defined in clause 4.2.6.3.1.

– When the authorized QoS applies to the default QoS flow, it shall be provisioned as defined in clause 4.2.6.3.1.

– When the authorized QoS applies to an explicitly signalled QoS Characteristics, it shall be provisioned as defined in clause 4.2.6.6.3.

– When the authorized QoS applies to the Reflective QoS, it shall be provisioned as defined in clause 4.2.6.5.7.

The authorized QoS provides appropriate values for the resources to be enforced. The authorized QoS for a PCC rule is a request for allocating the corresponding resources. The Provisioning of authorized QoS per PCC rule is a part of PCC rule provisioning procedure.

If the SMF cannot allocate any of the resources as authorized by the PCF, the SMF informs the PCF and acts as described in clauses 4.2.3.16 and 4.2.4.15.

The SMF shall interact with the (R)AN, UPF and UE for enforcing the policy based authorization.

QoS authorization information may be dynamically provisioned by the PCF or it may be a pre-defined PCC rule in the SMF. Moreover, all the parameters of the authorized QoS may be changed.

NOTE 1: A change of 5QIs cannot be described as an upgrade or downgrade and also no 5QI can be referred to as the higher or lower. Whether the 5QI is permitted to be changed or not is subject to both operator policies and normal restrictions on changing from a non-GBR 5QI value to GBR 5QI value on an IP flow.

NOTE 2: All attributes of the ARP QoS parameter can be changed but only the ARP priority level represents an ordered range of values. The ARP priority level attribute represents the actual priority for the service/user with the value 1 as the highest and can thus be upgraded and downgraded.

If the PCF is unable to make a decision for the response to the HTTP POST message by the SMF, the PCF may reject the request as described in clause 5.7.

4.2.6.6.2 Policy provisioning and enforcement of authorized QoS per service data flow

The Provisioning of authorized QoS per service data flow is a part of PCC rule provisioning procedure, as described in clause 4.2.6.2.1.

The authorized QoS per service data flow shall be provisioned within a QosData data structure. The PCF shall include a "qosDecs" attribute containing the corresponding QoS data decision within the SmPolicyDecision data structure and include the reference to this QoS data decision within the "refQosData" attribute of the PccRule data instance.

When network slice data rate policy control applies and the authorized QoS per service data flow refers to a 5QI of GBR type, the PCF shall derive the authorized QoS per service data flow as described in clause 4.2.6.8.

Within the QoS data decision, for 5QI of GBR type or delay critical GBR type, the PCF shall include the authorized GBR 5QI or delay critical GBR 5QI respectively within the "5qi" attribute, the ARP within the "arp" attribute, and max bandwidth in uplink within the "maxbrUl" attribute and/or max bandwidth in downlink within the "maxbrDl" attribute, the guaranteed bandwidth in uplink within the "gbrUl" attribute and/or the guaranteed bandwidth in downlink within the "gbrDl" attribute. If the PCF determines that the application traffic can be adapted to the change in the QoS based on the configuration (e.g. if the AF is capable to trigger rate adaptation), the PCF may request a notification when authorized GBR or delay critical GBR cannot be guaranteed or can be guaranteed again by including the "qnc" attribute set to true.

Within the QoS data decision, for 5QI of non-GBR type, the PCF shall include the authorized non-GBR 5QI within the "5qi" attribute and the ARP within the "arp" attribute. The PCF may authorize the max bandwidth in uplink within the "maxbrUl" attribute and/or max bandwidth in downlink within the "maxbrDl" attribute.

When the PCF authorizes a standardized 5QI but a Priority Level, an Averaging Window and/or a Maximum Data Burst Volume which are different from the standardized value in the table 5.7.4-1 of 3GPP TS 23.501 [2] are required, the PCF shall include the Priority Level within the "priorityLevel" attribute, the Averaging Window within the "averWindow" attribute and/or the Maximum Data Burst Volume within the "maxDataBurstVol" attribute or the "extMaxDataBurstVol" attribute (if supported, see clause 4.2.2.1).

NOTE 1: For the non-standardized or non-configured 5QI, the PCF needs to authorize explicitly signalled QoS Characteristics associated with the 5QI if the PCF has not provisioned it.

If the configured policy allows at reception of the service information from the AF and the application of the rules of the QoS mapping procedures defined in 3GPP TS 29.513 [7] clause 7.3.2 for the received service information result in a 5QI of 1 associated with the corresponding flows, and the RAN-Support-Info feature as defined clause 5.8 is supported, the PCF shall determine the Maximum Packet Loss Rate for UL and DL for those flows associated within 5QI of 1. In this case, the PCF shall include the value of Maximum Packet Loss Rate for UL within the "maxPacketLossRateUl" attribute and/or the value of Maximum Packet Loss Rate for DL within the "maxPacketLossRateDl" attribute.

NOTE 2: If CHEM feature is supported, then PCF as described in clause 7.2.3 of 3GPP TS 29.513 [7] or based on local configuration, the PCF sets the downlink and uplink maximum packet loss rates corresponding to either the most robust codec mode or the least robust codec mode of the negotiated set in each direction.

If the PCF wants to ensure that a PCC Rule is always bound to the default QoS flow, the policy provisioning for the related authorized QoS shall be done as described in clause 4.2.6.2.10.

The SMF shall perform a QoS flow binding based on the QoS information within the Qos data decision as defined in clause 6.4 of 3GPP TS 29.513 [7] after the SMF installs or activates the PCC rules.

The SMF shall reserve the resources necessary for the guaranteed bitrate for the PCC rule upon receipt of a PCC rule provisioning including QoS information. For GBR QoS flows the SMF should set the QoS flow’s GBR to the sum of the GBRs of all PCC rules that are active/installed and bound to that GBR QoS flow. For GBR QoS flow the SMF should set the QoS flow’s MBR to the sum of the MBRs of all PCC rules that are active/installed and bound to that GBR QoS flow.

NOTE 3: Since the PCF controls the GBR value in the PCC rule, the PCF can prevent that uplink GBR resources are reserved by providing an uplink GBR value of zero for that PCC rule This may be useful e.g. for a PCC rule with application identifier as the uplink traffic can be received in other QoS flow than the one the PCC rule is bound to.

The SMF shall assign a QFI if a new QoS flow needs to be established and shall derive, if applicable, the QoS profile required towards the Access Network, the QoS rule required towards the UE and the QoS information with PDRs towards to the UPF. If multiple PCC rules with the Maximum Packet Loss Rate for UL and DL are bound to the same QoS flow, the SMF shall choose the lowest value per direction related to the PCC rules within the QoS profile towards to the access network.

If one or more of the 5QI, ARP, QNC, Priority level, Averaging Window and Maximum Data Burst Volume attributes of a PCC rule are modified to the same updated values for all the PCC rules bound to the same QoS flow, then the SMF should modify the corresponding attributes for that impacted QoS flow.

Upon deactivation or removal of a PCC rule, the SMF shall free the resources reserved for that PCC rule, and initiate the corresponding procedure with access network, UE and UPF to remove the resources.

4.2.6.6.3 Policy provisioning and enforcement of authorized explicitly signalled QoS Characteristics

The PCF may provision a dynamically assigned 5QI value (from the non-standardized and non-preconfigured value range) and the associated 5G QoS characteristics to the SMF. In order to do so, the PCF shall include within the SmPolicyDecision data structure the "qosChars" attribute to contain one or more authorized signalled QosCharacteristics instance(s). For each QosCharacteristics instance, the PCF shall include the assigned 5QI value within the "5qi" attribute, the resource type value within the "resourceType" attribute, the 5QI Priority Level value within the "priorityLevel" attribute, the Packet Delay Budget value within the "packetDelayBudget" attribute, the Packet Error Rate value within the "packetErrorRate" attribute, the Averaging Window value within the "averagingWindow" attribute, if applicable, and the Maximum Data Burst Volume value within the "maxDataBurstVol" attribute or the "extMaxDataBurstVol" attribute (if supported, see clause 4.2.2.1), if applicable. If the PCF has provisioned an authorized signalled QosCharacteristics instance to the SMF, the PCF shall not update nor remove it during the lifetime of the policy association.

Upon receiving the authorized explicitly signalled QoS characteristics, the SMF shall derive the QoS profile for the access network and provide it to the access network by invoking the corresponding procedure.

NOTE: Operator configuration is assumed to ensure that the assigned dynamic 5QI value is unique and references the same set of QoS characteristics within the whole PLMN at a given time.

4.2.6.7 Monitoring the data rate per network slice for a UE

The PCF can support monitoring of data rate per S-NSSAI for a UE.

During PDU session establishment, if the PCF supports monitoring of the data rate per S-NSSAI for a UE, the PCF may retrieve for the UE and S-NSSAI to which the PDU session is allocated the UE-Slice-MBR (i.e. the aggregate data rate that can be expected to be provided across all GBR and Non-GBR QoS Flows of a UE for a network slice identified by an S-NSSAI) from the UDR as defined in clause 5.4.2.14 of 3GPP TS 29.519 [15]. The PCF shall monitor the data rate for this S-NSSAI and UE by deriving the utilized data rate based on the authorized Session-AMBR and/or the authorized QoS per service data flow in all PDU session(s) established for the UE in the concerned S-NSSAI and checking the derived value against the UE-Slice-MBR set by the PCF based on the UE-Slice-MBR value retrieved from the UDR and operator policies available at the PCF.

As part of the PDU session modification procedure(s) targeting the PDU session(s) established for the UE in the concerned S-NSSAI, whenever the PCF needs to provide the associated authorized Session-AMBR(s), install new or updated PCC Rule(s) and/or delete PCC Rule(s) related to GBR service data flow(s), the PCF shall calculate the utilized data rate as described in clause 4.2.6.8.2.

At the termination of a PDU session established for the UE in the concerned S-NSSAI, the PCF shall adjust the utilized data rate for the UE based on the release of the Session-AMBR and the removal of all the PCC Rule(s) related to GBR service data flow(s) associated to that PDU session.

To enable this monitoring, the SMF shall select the same PCF instance for all PDU sessions of the UE to the S-NSSAI that is subject to this monitoring as defined in clause 8.3 of 3GPP TS 29.513 [7].

When the calculated utilized data rate for the S-NSSAI and UE reaches a certain percentage of the UE-Slice-MBR value, the PCF may apply a policy decision to strengthen the traffic restrictions for individual PDU session(s) or PCC rule(s) (e.g. change the authorized Session-AMBR as defined in clause 4.2.6.3.1, change the authorized QoS per service data flow as defined in clause 4.2.6.6.2, or change the charging keys) within individual PDU session(s) established for the UE in the concerned S-NSSAI. When the calculated utilized data rate per S-NSSAI for a UE falls below that percentage of the UE-Slice-MBR value, the PCF may relax the traffic restrictions for individual PDU session(s) or PCC rule(s) within individual PDU session(s) established for the UE in the concerned S-NSSAI.

As part of the policy decision to strengthen the traffic restrictions for individual PDU session(s), the PCF may reject the establishment or SMF-initiated modification of the associated SM Policy Association(s) with an HTTP "403 Forbidden" response message including the "cause" attribute of the ProblemDetails data structure set to "EXCEEDED_UE_SLICE_DATA_RATE".

NOTE: It is recommended to avoid frequent policy decisions which trigger a signalling with the UE (like change of the authorized Session-AMBR or change of the authorized QoS per service data flow).

4.2.6.8 Network slice related data rate policy control

4.2.6.8.1 General

A PCF that supports network slice related data rate policy control shall be able to control and manage the network slice data rate.

A Maximum Slice Data Rate may be configured by the operator (e.g. based on an SLA related to the associated network slice identified by an S-NSSAI).

NOTE 1: The Maximum Slice Data Rate defines the maximum allowed aggregate data rate across all GBR and Non-GBR QoS Flows within the network slice identified by an S-NSSAI as defined in 3GPP TS 29.519 [15].

NOTE 2: The maximum data rate of Non-GBR QoS Flow(s) is controlled via the authorized Session-AMBR, while the maximum data rate of a GBR QoS Flow is controlled via the authorized MBR value of the associated PCC rule.

The PCF shall determine, based on local configuration, if the network slice data rate is controlled via PCF-based monitoring by using QoS parameters or with assistance of the NWDAF.

The PCF shall monitor the data rate of the network slice and ensure that it does not exceed the Maximum Slice Data Rate for that network slice by e.g. rejecting new SM Policy Associations, changing the authorized Session-AMBR values (if allowed by the HPLMN), changing the MBR values in PCC rules belonging to GBR service data flows or other actions depending on operator’s policies.

NOTE 3: Based on operator’s policies, it is also possible for the PCF to accept that new PDU session(s) or PCC rule(s) belonging to GBR service data flow(s) lead to exceeding the Maximum Slice Data Rate and apply a different charging for them. Once the Maximum Slice Data Rate is no longer exceeded, the PCF can decide to go back to applying the previous charging.

NOTE 4: Subject to operator policy and national/regional regulations, prioritised services and emergency services may be exempted from network slice data rate policy control.

NOTE 5: A single PCF can be used for the monitoring and limitation of the network slice related data rate. To enable this, the SMF has to select the same PCF instance for all PDU Sessions of the UE to the S-NSSAI.

4.2.6.8.2 PCF-based network slice data rate policy control by using QoS parameters

If the NWDAF is not deployed or not used for network slice data rate policy control and PCF-based monitoring of network slice data rate by using QoS parameters applies, the UDR shall maintain the Remaining Maximum Slice Data Rate per S-NSSAI as part of the network slice specific policy control data as defined in 3GPP TS 29.519 [15].

Whenever the PCF needs to calculate the data rate related to authorized Session-AMBR and/or the MBR(s) of the GBR Service Data Flow(s), the PCF shall obtain the Remaining Maximum Slice Data Rate by interacting with the UDR as defined in 3GPP TS 29.519 [15]. When the PCF interacts with the UDR may be based on operator policies.

When the PCF needs to provide the authorized Session-AMBR and/or install new or updated PCC Rule(s) and/or delete PCC Rule(s) related to GBR service data flow(s), the PCF shall:

– calculate the difference between the previously authorized Session-AMBR, if applicable, and the new authorized Session-AMBR; and/or

– calculate the difference between the previously authorized MBR and the new authorized MBR(s) for the authorized PCC Rule(s) related to GBR service data flow(s);

And then:

– Calculate the utilized data rate, i.e. the sum of the previously calculated differences, which is to be substracted from the Remaining Maximum Slice Data rate.

NOTE 1: For example, when the PCF modifies as part of the same operation the MBR of PCC Rule A from 100 to 150 and the MBR of PCC Rule B from 30 to 20, deletes PCC Rule C with an MBR of 50 and adds a PCC Rule D of MBR 75, the final calculated value will be +50-10-50+75, i.e. 65. If the authorized Session-AMBR is also updated from 1000 to 2000, the final derived value will be 1065.

NOTE 2: The utilized data rate can be a negative value. In this case, the final Remaining Maximum Slice Data Rate is increased.

Therefore, the PCF shall behave as follows:

– At PDU session establishment, the PCF shall check whether the Remaining Maximum Slice Data Rate is higher than the calculated utilized data rate (e.g. based on the authorized Session-AMBR). If it is the case, the PCF shall deduct the value of the utilized data rate from the Remaining Maximum Slice Data Rate for the concerned S-NSSAI in the UDR. If however the Remaining Maximum Slice Data Rate is not sufficient, the PCF may reject the establishment of the SM Policy Association with an HTTP "403 Forbidden" response message including the "cause" attribute of the ProblemDetails data structure set to "EXCEEDED_SLICE_DATA_RATE".

– At PDU session modification initiated by the SMF, the PCF shall check whether the Remaining Maximum Slice Data Rate is higher than the calculated utilized data rate (e.g. based on the authorized Session-AMBR). If it is the case, the PCF shall deduct the value of the utilized data rate from the Remaining Maximum Slice Data Rate for the concerned S-NSSAI in the UDR. If however the Remaining Maximum Slice Data Rate is not sufficient, the PCF may reject the modification of the SM Policy Association with an HTTP "403 Forbidden" response message including the "cause" attribute of the ProblemDetails data structure set to "EXCEEDED_SLICE_DATA_RATE".

– When a PCC rule of a GBR service data flow is installed, modified, removed, activated or deactivated in the SMF,

– the PCF shall derive the authorized QoS for the service data flow and the associated utilized data rate and update the Remaining Maximum Slice Data Rate for the concerned S-NSSAI in the UDR accordingly;

– the PCF may request the SMF to confirm that the resources associated to that PCC rule are successfully allocated as defined in clause 4.2.6.5.5 or released as defined in clauses 4.2.3.13 and 4.2.4.12;

– if the SMF reports that some of or all the resources cannot be successfully allocated, the PCF shall recalculate the authorized QoS for the service data flow and the associated utilized data rate and update the Remaining Maximum Slice Data Rate for the concerned S-NSSAI in the UDR accordingly.

– When the authorized Session-AMBR changes and/or one or several PCC Rule(s) of a GBR service data flow(s) are installed, removed or modified, the PCF shall calculate the new utilized data rate and update the Remaining Maximum Slice Data Rate for that S-NSSAI in the UDR accordingly.

– At PDU session termination, the PCF shall add the value of the related previously utilized data rate (i.e. based on the authorized Session-AMBR allocated to the PDU session and the previously utilized data rate by the removed PCC Rule(s) related to GBR service data flow(s)) to the Remaining Maximum Slice Data Rate for the concerned S-NSSAI in the UDR.

– If the Remaining Maximum Slice Data Rate for that S-NSSAI reaches a (operator defined) threshold that indicates that it is closer or equal to zero, the PCF may apply policy decision(s) to strengthen the traffic restrictions for the concerned PDU Session(s).

– If the Remaining Maximum Slice Data Rate for that S-NSSAI returns to a value below the (operator defined) threshold, the PCF may apply policy decision(s) to recover the initially derived value(s) for the concerned PDU Session(s).

NOTE 3: While the Remaining Maximum Slice Data Rate is relatively high, the PCF can be configured to maintain a local Remaining Maximum Slice Data Rate and to only interact with the UDR to update the Remaining Maximum Slice Data Rate when a certain threshold is reached, or a certain time window has passed. The higher the configured values are the lower the chances for an accurate limitation of the slice data rate becomes. When multiple PCFs for the same S-NSSAI are deployed, each PCF can also subscribe to the change of the Network slice specific policy control data in the UDR. The UDR will then send a notification to each subscribed PCF when the Remaining Maximum Slice Data Rate per S-NSSAI changes.

NOTE 4: Multiple PCFs responsible for PDU Sessions of UEs to the same S-NSSAI can read and update the Remaining Maximum Slice Data Rate for the S-NSSAI in the UDR using the conditional requests with preconditions for the update of the Remaining Maximum Slice Data Rate, this mechanism using Etags is defined in Table 5.2.2.2-2 of 3GPP TS 29.500 [4] to ensure a proper update of the UDR data in case of simultaneous access from different PCFs.

4.2.6.8.3 Network slice data rate policy control with assistance of the NWDAF

If the NWDAF is used for network slice data rate policy control, the PCF uses the Data Volume Dispersion Analytics provided by the NWDAF. For this purpose, the PCF subscribes to the NWDAF for periodic reporting of the Data Volume Dispersion Analytics statistics for all the UEs using the concerned network slice. The PCF subscribes to the NWDAF for Data Volume Dispersion Analytics reporting at the establishment of the first PDU session within the concerned S-NSSAI (subject to network slice data rate limitation) and cancels this subscription at the termination of the last PDU session within the concerned S-NSSAI as described in 3GPP TS 29.520 [51].

The PCF calculates the utilized data rate of the S-NSSAI by using the Data Volume Dispersion Analytics statistics reported by the NWDAF. When the utilized data rate of the S-NSSAI in UL and/or DL is getting close to or exceeding respectively the value of the "mbrUl" attribute and/or the value of the "mbrDl" attribute of the SlicePolicyData data structure as defined in 3GPP TS 29.519 [15], based on operator policy, the PCF may apply policy decision(s) to strengthen the traffic restrictions for individual PDU sessions and/or PCC rules. For example:

– The PCF may reject the creation or modification of SM Policy Associations that require the increase of the utilized data rate for the S-NSSAI with an HTTP "403 Forbidden" response message including the "cause" attribute of the ProblemDetails data structure set to "EXCEEDED_SLICE_DATA_RATE".

– The PCF may refrain from sending new and/or updated PCC Rules that require the increase of the utilized data rate.

When the utilized data rate of the S-NSSAI in UL and/or DL falls below respectively the value of the "mbrUl" attribute and/or the value of the "mbrDl" attribute of the SlicePolicyData data structure, the PCF may relax the traffic restrictions for individual PDU sessions and/or PCC rules.

When multiple PCFs for the same S-NSSAI are deployed, each PCF subscribes to the analytics from the NWDAF separately.

NOTE: When multiple PCFs are used for the concerned S-NSSAI, the NWDAF triggers Data Volume Dispersion Analytics notifications towards all these PCFs, but their policy decisions can be different.4.2.7 Detection and handling of late arriving requests

4.2.7.1 Handling of requests which collide with an existing SM Policy Association

The PCF may receive an Originating Time Stamp parameter within the 3gpp-Sbi-Origination-Timestamp header, which is set by the AMF, by the Npcf_SMPolicyControl_Create service request.

NOTE 1: The SMF forwards the Origination Time Stamp to the PCF, when received from the AMF to allow the handling of colliding requests at the PCF based on network conditions.

Upon receipt of a Npcf_SMPolicyControl_Create service request which collides with an existing SM Policy Association for the same UE (i.e. same values of "supi" attribute) and the same PDU session Id (i.e. same values of "pduSessionId" attribute), the PCF shall accept the new request only if it contains a more recent timestamp within the 3gpp-Sbi-Origination-Timestamp header than the origination timestamp stored for the existing SM Policy Association. An incoming Npcf_SMPolicyControl_Create service request shall be considered as more recent than an existing SM Policy Association and be accepted if no 3gpp-Sbi-Origination-Timestamp header was provided for at least one of the two SM Policy Associations. The PCF shall reject an incoming request whose timestamp is less recent than the timestamp of the existing SM Policy Association with the HTTP status code "403 Forbidden" and the application error "LATE_OVERLAPPING_REQUEST".

NOTE 2: When the PCF accepts the new request that contains a more recent timestamp within the 3gpp-Sbi-Origination-Timestamp header than the timestamp stored for the SM Policy Association, the PCF performs implementation specific, e.g. locally deletes the existing Individual SM Policy Association.