4.2.3 Npcf_SMPolicyControl_UpdateNotify Service Operation

29.5123GPP5G SystemRelease 18Session Management Policy Control ServiceStage 3TS

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

4.2.3.1 General

The UpdateNotify service operation provides updated Session Management related policies to the NF service consumer (SMF) or triggers the deletion of the context of SM related policies. The POST method is used for both update and terminate operations.

The following procedures using the Npcf_SMPolicyControl_UpdateNotify service operation are supported:

– PCF initiated update of the policies associated with a PDU session.

– PCF initiated deletion of the SM Policy Association of a PDU session.

– Provisioning of PCC rules.

– Provisioning of policy control request triggers.

– Provisioning of revalidation time.

– Policy provisioning and enforcement of the authorized AMBR per PDU session.

– Policy provisioning and enforcement of the authorized default QoS.

– Provisioning of PCC rules for Application Detection and Control.

– 3GPP PS Data Off Support.

– IMS Emergency Session Support.

– Request Access Network Information.

– Request Usage Monitoring Control.

– Request for the result of PCC rule removal.

– Access Network Charging Identifier request.

– Request successful resource allocation notifications.

– IMS Restoration Support.

– P-CSCF Restoration Enhancement Support.

– Access traffic steering, switching and splitting support.

– Policy provisioning and enforcement of AF session with required QoS.

– Forwarding of TSC user plane node management information and port management information received from the TSN AF or TSCTSF.

– Provisioning of TSCAI input information and TSC QoS related data.

– Policy provisioning of QoS Monitoring to assist URLLC Service.

– Policy decision and condition data error handling.

– Network slice related data rate policy control.

– Request of Presence Reporting Area Change Report.

– PCC Rule Error Report.

– Session Rule Error Report.

4.2.3.2 SM Policy Association Update request

Figure 4.2.3.2-1: SM Policy Association Update request

The PCF may decide to provision policies related to an Individual SM Policy resource without obtaining a request from the NF service consumer, e.g. in response to information provided to the PCF via the Rx or N5 reference points, or in response to an internal trigger within the PCF. The PCF shall send for this purpose a POST request to the NF service consumer (e.g. SMF) using the URI"{notificationUri}/update". The payload body of the message shall contain a SmPolicyNotification data structure that contains:

– the representation of the updated policies within the "smPolicyDecision" attribute; and

– the resource URI of the Individual SM Policy resource related to the notification within the "resourceUri" attribute.

Detailed procedures related to the provisioning and enforcement of the policy decisions contained within the SmPolicyDecision data structure are provided in clause 4.2.6.

In case of a successful update of SM policies:

– if the PCF provisioned the policy control request triggers related to access type change, RAT change or location change, a "200 OK" response code and a response body with the corresponding available information in the "UeCampingRep" data structure shall be returned in the response;

– otherwise, a "204 No Content" response code shall be returned in the response.

NOTE: When there is an ongoing procedure that collisions with the update of SM policies (e.g. during handover from 5GS to EPS) the SMF, based on operator policies, can delay the update of SM policies and return a "204 No Content" response code. In this case the SMF will process the request when the procedure is finished.

If errors occur when processing the HTTP POST request, the NF service consumer shall send an HTTP error response as specified in clause 5.7.

If the feature "ES3XX" is supported, and the NF service consumer determines the received HTTP POST request needs to be redirected, the NF service consumer shall send an HTTP redirect response as specified in clause 6.10.9 of 3GPP TS 29.500 [4].

If the "SessionRuleErrorHandling" feature is not supported and the NF service consumer received one or more PCC rules from the PCF, but the validation of all these PCC Rules was unsuccessful, the NF service consumer shall reject the request and include in an HTTP "400 Bad Request" response message the ErrorReport data structure. Within the ErrorReport data structure, the NF service consumer shall include the "error" attribute containing the "cause" attribute of the ProblemDetails data structure set to "PCC_RULE_EVENT" or "PCC_QOS_FLOW_EVENT" and the "ruleReports" attribute to report the PCC rule status of the affected PCC rules as defined in clause 4.2.3.16.

If the "SessionRuleErrorHandling" feature is supported and the NF service consumer received one or more PCC rules and/or session rules from the PCF but the validation of all these PCC Rules and/or session rules was unsuccessful, the NF service consumer shall reject the request and include in an HTTP "400 Bad Request" response message the ErrorReport data structure. Within the ErrorReport data structure, the NF service consumer shall include the "error" attribute containing the "cause" attribute of the ProblemDetails data structure set to "RULE_PERMANENT_ERROR" or "RULE_TEMPORARY_ERROR" and the "ruleReports" attribute to report the PCC rule status of the affected PCC rules as defined in clause 4.2.3.16 and/or the "sessRuleReports" attribute to report the session rule status of the affected session rules as defined in clause 4.2.3.20.

If in the cases above, if the "PolicyDecisionErrorHandling" feature is supported, the PCF provisioned policy decisions and/or condition data which are not referred by any PCC rules or session rules and, in addition of the report of the faulty PCC rule(s) and/or session rule(s), the NF service consumer needs to report the failed policy decisions and/or condition data, the "policyDecFailureReports" attribute shall also be provided as described in clause 4.2.3.26. Additionally, if the "ExtPolicyDecisionErrorHandling" feature is supported the NF service consumer may also provide the "invalidPolicyDecs" as described in clause 4.2.3.26.2.

If the "Ext2PolicyDecisionErrorHandling" feature is supported, the NF service consumer did not receive neither PCC rules nor session rules and received policy decision types and/or condition types which are not referred by any PCC rules or session rules, and the storage of all the policy decision types and/or condition data was unsuccessful (e.g. the policy decision could not be successfully stored due to a limitation of resources at the SMF) or there were semantical inconsistencies in the provided data, the NF service consumer shall include in an HTTP "400 Bad Request" response message the ErrorReport data structure including the "error" attribute containing the "cause" attribute of the ProblemDetails data structure set to "POL_DEC_ERROR" and shall behave as defined in clause 4.2.3.26.

If the "SessionRuleErrorHandling" feature is not supported and if the NF service consumer received one or more PCC rules from the PCF but the validation of some of them was unsuccessful, the NF service consumer shall include an HTTP "200 OK" status code together with one or more RuleReport data structure(s) to report the PCC rule status of the affected PCC rules as defined in clause 4.2.3.16 in the "PartialSuccessReport" data structure included in the response message. The "failureCause" attribute of the "PartialSuccessReport" shall be set to "PCC_RULE_EVENT" or "PCC_QOS_FLOW_EVENT".

If the "SessionRuleErrorHandling" feature is supported and the NF service consumer received one or more PCC rule and/or session rules from the PCF but the validation of some of them was unsuccessful, the NF service consumer shall include an HTTP "200 OK" status code together with the "ruleReports" attribute to report the PCC rule status of the affected PCC rules as defined in clause 4.2.3.16 and/or the "sessRuleReports" attribute to report the session rule status of the affected session rules as defined in clause 4.2.3.20 in the "PartialSuccessReport" data structure included in the response message. The "failureCause" attribute of the "PartialSuccessReport" shall be set to "RULE_PERMANENT_ERROR" or "RULE_TEMPORARY_ERROR".

If the "PolicyDecisionErrorHandling" feature is supported, the NF service consumer received policy decision types and/or condition types which are not referred by any PCC rules or session rules, and the storage or validation of not all the policy decision types and/or condition data was unsuccessful, the NF service consumer shall reply with an HTTP "200 OK" response message and behave as described in clause 4.2.3.26.

If the PCF provisioned policy control request triggers and the NF service consumer needs to report partial success information, the NF service consumer may include in the "PartialSuccessReport" data structure the "ueCampingRep" attribute with the corresponding available information. When it is required to report multiple instances of the "PartialSuccessReport" data structure due to different "failureCause" values, the NF service consumer shall use only one instance of the "PartialSuccessReport" data structure to include the "ueCampingRep" attribute with the corresponding available information.

4.2.3.3 SM Policy Association termination request

Figure 4.2.3.3-1: SM Policy Association termination request

The PCF may request PDU session termination and the corresponding deletion of the Individual SM policy resource in the following circumstances:

– If the PCF decides to terminate a PDU session due to an internal trigger or a trigger from the UDR.

– The PCF may also decide to terminate a PDU session upon receiving a POST message from the NF service consumer (e.g. when data usage quota is reached).

The PCF shall send a POST request to the NF service consumer (e.g. SMF) using the URI {notificationUri}/terminate and include the TerminationNotification data structure in the body of the HTTP POST request. Within the TerminationNotification data structure, the PCF shall include:

– the resource URI of the Individual SM policy resource related to the termination request within the "resourceUri" attribute; and

– the cause of why the PCF requests the termination of the policy association within the "cause" attribute.

If the NF service consumer accepts the received POST request, the NF service consumer shall send a "204 No Content" response.

After the successful processing of the HTTP POST request, the NF service consumer shall invoke the Npcf_SMPolicyControl_Delete Service Operation defined in clause 4.2.5 to terminate the policy association and initiate the procedure to terminate the PDU session as defined in 3GPP TS 29.502 [22].

If errors occur when processing the HTTP POST request, the NF service consumer shall send an HTTP error response as specified in clause 5.7.

4.2.3.4 Provisioning of revalidation time

During the lifetime of a PDU session, within the SmPolicyDecision data structure, the PCF may provide the revalidation time within the "revalidationTime" attribute and the "RE_TIMEOUT" policy control request trigger within the "policyCtrlReqTriggers" attribute to instruct the SMF to trigger an interaction with the PCF to request PCC rule(s) if not provided yet. The PCF may also update the revalidation time by including the new value within the "revalidationTime" attribute. The PCF may disable the revalidation function by removing the "RE_TIMEOUT" policy control request trigger, if it has been previously provided.

When the SMF receives the revalidation time within the "revalidationTime" attribute, the SMF shall store the received value and start the associated timer based on it. Then, the SMF shall trigger a PCC rule request towards the PCF before the indicated revalidation time.

If the "RE_TIMEOUT" policy control request trigger is removed, the SMF shall stop the associated timer.

NOTE: By disabling the revalidation function, the revalidation time value previously provided to the SMF is not applicable anymore.

4.2.3.5 Policy provisioning and enforcement of authorized AMBR per PDU session

The PCF may modify the authorized Session-AMBR at any time during the lifetime of the PDU session and provision it to the SMF by invoking the procedure defined in clause 4.2.3.2.

If the "VPLMN-QoS-Control" feature is supported, the PCF shall ensure that the authorized Session-AMBR value does not exceed the Session-AMBR supported by the VPLMN, if applicable.

The PCF shall provision the new authorized session AMBR to the SMF as defined in clauses 4.2.6.3.1 and 4.2.6.3.2.

Upon reception of the authorized Session-AMBRR, the SMF shall apply the corresponding procedures towards the access network, the UE and the UPF for the enforcement of the AMBR for the concerned PDU session.

For UL Classifier or Multi-homing PDU Sessions, the SMF will provision the policies of session-AMBR for the downlink and uplink directions to the UL Classifier/Branching Point functionality and in addition provision the policies of Session-AMBR for the downlink direction to all the PDU session anchors, as defined in clause 5.4.4 of 3GPP TS 29.244 [13].

4.2.3.6 Policy provisioning and enforcement of authorized default QoS

The PCF may modify the authorized default QoS during the lifetime of the PDU session and provision it to the SMF by invoking the procedure defined in clause 4.2.3.2.

If the "VPLMN-QoS-Control" feature is supported, the PCF shall ensure that the authorized default QoS contains a 5QI and ARP value, and MBR/GBR, if applicable, supported by the VPLMN, if applicable.

The PCF shall provision the authorized default QoS to the SMF as defined in clauses 4.2.6.3.1 and 4.2.6.3.2.

Upon reception of the authorized default QoS, the SMF enforces it, which may lead to the change of the subscribed default QoS. The SMF shall apply the corresponding procedures towards the access network, the UE and the UPF for the enforcement of the authorized default QoS for the concerned PDU session.

4.2.3.7 Provisioning of 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 provision PCC rule(s) for application detection and control as defined in clause 4.2.6.2.11 in the notification (i.e. HTTP POST) request.

When the PCF provisions PCC rule(s) for application detection and control the PCF update of the mute indication is not allowed during the PDU session lifetime, i.e., if for the PCC rule, the application’s start or stop notifications are muted, the PCC rule shall remain with the application’s start or stop notifications muted along the PDU session lifetime, and viceversa, if for the PCC rule, the application’s start or stop notifications are not muted, the PCC rule shall remain with the application’s start or stop notifications not muted along the PDU session lifetime. The SMF shall reject the PCC rule modification as specified in clause 4.2.6.2.11.

If the SMF receives PCC rule(s) for application detection and control, the SMF shall instruct the UPF to detect the application traffic as defined in 3GPP TS 29.244 [13].

4.2.3.8 3GPP PS Data Off Support

When the PCF receives service information from the AF while the 3GPP PS Data Off handling functionality is active as described in clause 4.2.2.8 or 4.2.4.8, the PCF shall check:

– for a non-MA PDU session, whether the corresponding service is a 3GPP PS Data Off Exempt Service and permissible according to the user´s subscription and the policies of the PCF;

– for a MA PDU session:

a. whether the corresponding service is a 3GPP Data Off Exempt Service and permissible according to the user’s subscription and the policies of the PCF; or

b. whether the corresponding service does not belong to the 3GPP PS Data Off Exempt Services, but:

– the non-3GPP access is available; and

– the PCF policies allow all the traffic of the service to be forwarded using the non-3GPP access.

If so, the PCF shall install, modify or delete thecorresponding PCC rules. For a MA PDU session and when theservice does not belong to the 3GPP PS Data Off Exempt Services, the policy for ATSSS Control included in the PCC rule, as specified in clause 4.2.6.2.17, shall enable all the traffic to be forwarded using only the non-3GPP access.

Otherwise, the PCF shall reject the service information from the AF.

If the PCF determines that the 3GPP PS Data Off handling functionality becomes inactive, the PCF shall make the necessary policy control decisions and provision the PCC rules to make sure that services are allowed according to the user’s subscription and operator policy (irrespective of whether they belong to the list of 3GPP PS Data Off Exempt Services).

NOTE: The PCF can then open gates via the "flowStatus" attribute for active PCC rules associated to services not contained in the list of 3GPP PS Data Off Exempt Services. The PCF can also install PCC rules or activate predefined PCC rules for some services not belonging to the list of 3GPP PS Data Off Exempt Services. If the PCF activates or installs a PCC rule with wildcarded filters, it can remove or de-activate PCC rules for 3GPP PS Data Off Exempt Services that are redundant to this PCC rule.

4.2.3.9 IMS Emergency Session Support

4.2.3.9.1 Provisioning of PCC rule

When the PCF receives IMS service information from the AF for an Emergency service and derives authorized PCC Rules from the service information, the "priorityLevel", the "preemptCap" and the "preemptVuln" attributes of the Arp data structure within the QoS data decision to which each PCC Rule refers shall be assigned values (i.e. priority and pre-emption level) as required by local operator policies (e.g. if an IMS Emergency session is prioritized, the "priorityLevel" attribute may contain a value that is reserved for an operator domain use of IMS Emergency session).

The PCF shall immediately initiate the procedures described in clause 4.2.6.2.1 to provision the necessary PCC Rules and the procedures described in clause 4.2.6.2.3 to provision the authorized QoS perPCC rule.

The provisioning at the SMF of PCC Rules, which require the establishment of a dedicated QoS flow for emergency services, shall cancel the inactivity timer in the SMF, if it started running as defined in the clause 4.2.3.9.2.

Any SMF-initiated request for PCC Rules for an IMS Emergency service with the "repPolicyCtrlReqTriggers" attribute containing the "RES_MO_RE" value (i.e. UE-initiated resource reservation) shall be rejected by the PCF via an HTTP "403 Forbidden" response message including the "cause" attribute of the ProblemDetails data structure set to "ERROR_TRAFFIC_MAPPING_INFO_REJECTED".

The SMF shall execute the procedures to ensure that a new QoS flow is established for the Emergency service.

When the SMF detects that the provisioning of PCC Rules failed, the PCC rule error handling procedure shall be performed.

4.2.3.9.2 Removal of PCC Rules for Emergency Services

The reception by the PCF of a request to terminate an AF session for an IMS Emergency service triggers the removal by the PCF of the PCC Rules assigned to the terminated IMS Emergency Service in the SMF, using the procedure defined in clause 4.2.6.2.1.

At reception of an HTTP POST message that removes one or several PCC Rules from a PDU Session restricted to emergency services, the SMF shall:

– initiate a QoS flow termination procedure, when all the PCC Rules bound to a QoS flow are removed; or

– initiate a QoS flow modification procedure, when not all the PCC Rules bound to a QoS flow are removed.

In addition, the SMF shall initiate an inactivity timer if all PCC Rules with a 5QI other than the 5QI of the default QoS flow or the 5QI used for IMS signalling were removed from the PDU session restricted to Emergency Services (e.g. to enable PSAP Callback session). When the inactivity timer expires, the SMF shall initiate a PDU session termination procedure as defined in clause 4.2.5.

4.2.3.10 Request of Access Network Information

If the NetLoc feature defined in clause 5.8 is supported, the PCF may request the SMF to report the access network information as defined in clause 4.2.6.5.4.

4.2.3.11 Request Usage Monitoring Control

If the UMC feature defined in clause 5.8 is supported, the PCF may provision the usage monitoring control policy to the SMF, as defined in clause 4.2.6.5.3, to request the activation of usage monitoring control.

4.2.3.12 Ipv6 Multi-homing support

During the lifetime of the Multi-homing PDU session, the PCF shall provision the PCC rules and session rules to the SMF. The SMF shall derive the appropriate policies based on the policies provisioned by the PCF and provision them to the appropriate UPF, if applicable, access network, if applicable, and UE, if applicable.

4.2.3.13 Request for the result of PCC rule removal

If 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) as defined in clause 4.2.6.5.2.

When the SMF receives the request, the SMF shall maintain locally the removed PCC rules(s) until it receives the resource release outcome from the network.

4.2.3.14 Access Network Charging Identifier request

The PCF may request the SMF to provide the Access Network Charging Identifier associated to the dynamic PCC rules as defined in clause 4.2.6.5.1.

4.2.3.15 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 as defined in clause 4.2.6.5.5.

4.2.3.16 PCC Rule Error Report

If the SMF receives one or more PCC rule(s) as defined in clause 4.2.3.1. but the validation of all the received PCC Rules was unsuccessful, the SMF shall reject the request via an HTTP "400 Bad Request" status code and include in the corresponding response message the "ruleReports" attribute containing RuleReport data structure(s) to report the failure for the affected PCC rule(s) within the ErrorReport data structure; otherwise, if the validation of only some of the received PCC rules was unsuccessful, the SMF shall reply to the PCF with an HTTP "200 OK" status code and include in the corresponding response message one or more RuleReport data structure(s) to report the failure for the affected PCC rule(s) within the PartialSuccessReport data structure.

Within each RuleReport instance, the SMF shall identify the failed PCC rule(s) by including their identifiers within the "pccRuleIds" attribute, identify the failure reason code by including a "failureCode" attribute, and include the PCC rule(s) status within the "ruleStatus" attribute containing a value as follows:

– If the installation/activation of one or more new PCC rules (i.e. rules which were not previously successfully installed) fails, the SMF shall set the "ruleStatus" attribute value to "INACTIVE".

– If the modification of a currently active PCC rule fails, the SMF shall retain the existing PCC rule as active without any modification, unless the reason for the failure has an impact also on the existing PCC rule.

The removal of a PCC rule shall never fail, even if the related PDU session procedures with the UE fail. The SMF shall the retain information on the removal of the PDU session and conduct the necessary PDU session procedures with the UE when it is possible.

Depending on the value of the "failureCode" attribute, the PCF may decide whether retaining, re-installation, modification or removal of the old PCC rule or any other action applies.

If the "RuleVersioning" feature is supported and the PCF included the "contVer" attribute for a specific PCC rule instance in the "pccRules" attribute when provisioning this PCC rule to the SMF, then if the resource allocation for the corresponding PCC rule was unsuccessful, the SMF shall include the "contVers" attribute in the corresponding RuleReport instance within the "ruleReports" attribute. Depending on the value of the "failureCode" attribute, and when applicable, depending also on the value of the "contVer" attribute, the PCF may decide whether retaining, re-installation, modification, removal of the old PCC rule or any other action applies.

4.2.3.17 IMS Restoration Support

If the ProvAFsignalFlow feature defined in clause 5.8 is supported, and in order to support IMS Restoration procedures (refer to 3GPP TS 23.380 [21]), the PCF needs to convey the AF address to the SMF. In order to do so, in case the AF provisions information about the AF signalling flows between the UE and the AF, as defined in clause 4.4.5a of 3GPP TS 29.214 [18], or in clauses 4.2.2.16 and 4.2.3.17 of 3GPP TS 29.514 [17], the PCF shall install the corresponding dynamic PCC rules (if not installed before) as defined in clause 4.2.6.2.1. The PCF shall include within the associated PccRule instance(s) the signalling flows between the UE and the AF within the "flowInfos" attribute and the "afSigProtocol" attribute set to the value corresponding to the signalling protocol used between the UE and the AF.

The SMF shall respond to the PCF with an HTTP "204 no content" and initiate the corresponding QoS flow procedures, if required. The SMF shall extract the AF address from the provisioned PCC rule(s) and use it for the monitoring procedures as defined for the different access types.

NOTE 1: The SMF can use the extracted AF address from the PCC rule(s) to check if the monitoring procedures have to be started for the corresponding AF.

In case the AF de-provisions information about the AF signalling flows between the UE and the AF, as defined in clause 4.4.5a of 3GPP TS 29.214 [18], or in clauses 4.2.2.16 and 4.2.3.17 of 3GPP TS 29.514 [17], the PCF shall remove the corresponding dynamic PCC rule(s) by triggering a notification (i.e. HTTP POST) message towards the SMF. The PCF shall then apply the procedures defined in clause 4.2.6.2.1.

The SMF shall send an HTTP response message to the PCF.

NOTE 2: The SMF can use the AF address associated with the removed PCC rule(s) to check if it can stop monitoring the corresponding AF.

4.2.3.18 P-CSCF Restoration Enhancement Support

This clause is applicable when the PCF-based P-CSCF Restoration Enhancement, as defined in 3GPP TS 23.380 [21] and controlled by the feature "PCSCF-Restoration-Enhancement" defined in clause 5.8, is supported by both the PCF and the SMF.

If the PCF receives a request for P-CSCF restoration from the P-CSCF as defined in clause 4.4.7 of 3GPP TS 29.214 [18] or in clause 4.2.2.27 of 3GPP TS 29.514 [17], the PCF shall send a notification (i.e. HTTP POST) message to the SMF including the "pcscfRestIndication" attribute set to true for the corresponding PDU session.

The SMF shall acknowledge the PCF and initiate the corresponding QoS flow procedures for the IMS PDU connection as defined in 3GPP TS 23.380 [21].

4.2.3.19 Request of Presence Reporting Area Change Report

If the PRA or ePRA feature defined in clause 5.8 is supported, the PCF may provision the Presence Reporting Area Information to the SMF as defined in clause 4.2.6.5.6.

4.2.3.20 Session Rule Error Report

If the "SessionRuleErrorHandling" feature is supported and the SMF receives one or more session rule(s) as defined in clause 4.2.6.3.1 but the validation of all the received session rules was unsuccessful, the SMF shall reject the request via an HTTP "400 Bad Request" status code and include in the corresponding response message the "sessRuleReports" attribute containing SessionRuleReport data structure(s) to report the failure for the affected session rule(s) within the ErrorReport data structure; otherwise, if the validation of some of the received session rules was unsuccessful, the SMF shall reply to the PCF with an HTTP "200 OK" status code and include in the corresponding response message the "sessRuleReports" attribute containing one or more SessionRuleReport data structure(s) to report the failure for the affected session rule(s) within the PartialSuccessReport data structure.

Within each SessionRuleReport instance, the SMF shall identify the failed session rule(s) by including their identifier(s) within the "ruleIds" attribute, identify the failure reason code by including a "sessRuleFailureCode" attribute, and include the session rule(s) status within the "ruleStatus" attribute containing a value as follows:

– If the installation of one or more new session rule(s) (i.e. rules which were not previously successfully installed) fails, the SMF shall set the "ruleStatus" attribute value to "INACTIVE".

– If the modification of a currently provisioned session rule fails, the SMF shall retain the existing session rule as provisioned without any modification, unless the reason for the failure has an impact also on the existing session rule. The SMF shall report the modification failure to the PCF.

The removal of a session rule shall never fail, even if the related PDU session procedures with the UE fail. The SMF shall then retain information on the removal of the PDU session and conduct the necessary PDU session procedures with the UE when it is possible.

Depending on the value of the "sessRuleFailureCode" attribute, the PCF may decide whether retaining, re-installation, modification or removal of the old session rule, or any other action applies.

4.2.3.21 Access traffic steering, switching and splitting support

If the PCF supports the "ATSSS" feature, the PCF may provide PCC rules and/or session rules for the MA PDU session as defined in clause 4.2.6.2.17 and clause 4.2.6.3.4.

4.2.3.22 Policy provisioning and enforcement of the AF session with required QoS

If the PCF receives a QoS reference parameter during the initial provisioning of service information as defined in clause 4.2.2.32 of 3GPP TS 29.514 [17] , or if the PCF receives individual QoS parameters during the initial provisioning of service information as defined in clause 4.2.2.24 of 3GPP TS 29.514 [17], the PCF shall authorize the service information from the AF and derive the QoS parameters of the related PCC rule(s) based on the received service information and the indicated QoS reference parameter or the indicated individual QoS parameters (e.g, Requested Maximum Bitrate and Requested Guaranteed Bitrate).

NOTE: A SLA has to be in place between the operator and the ASP defining the possible QoS levels and their charging rates. For each possible pre-defined QoS information set, the PCF needs to be configured with the corresponding QoS parameters and their values as well as the appropriate Charging key (or receive this information from the UDR).

If the PCF receives a different QoS reference parameter or different individual QoS parameters during the modification of service information as defined in clause 4.2.3.30 of 3GPP TS 29.514 [17], the PCF shall update accordingly the related QoS parameters corresponding to the new QoS parameter in the related PCC rule(s).

If the AF subscribes to Service Data Flow QoS notification control, the PCF may additionally receive the Alternative Service Requirements during the initial provisioning of service information as defined in clause 4.2.2.32 of 3GPP TS 29.514 [17].

In this case, when the PCF authorizes service information based on the indicated QoS reference parameter or individual QoS parameters, or individual QoS parameters, and the "AuthorizationWithRequiredQoS" feature is supported, the PCF shall additionally derive alternative QoS parameter sets for the concerned PCC rule(s) based on the QoS reference parameters or individual QoS parameters provided in the Alternative Service Requirements. In order to do so, the PCF shall include one or more references to the QosData data structure within the "refAltQosParams" attribute of the concerned PCC rule(s) and a "qosDecs" attribute containing these QoS data decision(s) within the SmPolicyDecision data structure. In each QoS data decision instance, the PCF shall include the alternative QoS parameter set Id within the "qosId" attribute, the alternative packet delay budget within the "packetDelayBudget" attribute, the alternative packet error rate within the "packetErrorRate" attribute, the alternative guaranteed bandwidth in uplink within the "gbrUl" attribute and the alternative guaranteed bandwidth in downlink within the "gbrDl" attribute. The "refAltQosParams" attribute is an ordered list of alternative QoS parameter sets, where the lower the index of the array for a given entry, the higher the priority.

If the AF changes or newly provides the Alternative Service Requirements during the modification of service information as defined in clause 4.2.3.30 of 3GPP TS 29.514 [17], the PCF shall update accordingly or provide the Alternative QoS parameter sets in the related PCC rule(s).

The PCF shall provision the related PCC rule(s) with alternative QoS parameter set(s) and enable QoS Notification Control, if it has not been enabled yet, as defined in clause 4.2.3.30 of 3GPP TS 29.514 [17].

If the "DisableUENotification" feature is supported and if the AF indicated to the PCF that the UE does not need to be informed about changes related to Alternative QoS Profiles as as defined in clause 4.2.2.32 or 4.2.3.30 of 3GPP TS 29.514 [17] and the PCF decides to disable the notifications to the UE when changes related to the Alternative QoS Profiles occur, the PCF shall include the "disUeNotif" attribute set to true within the corresponding the PCC rule instance.

When the SMF receives PCC rule(s) with alternative QoS parameter sets, the SMF shall enforce these PCC rule(s) and derive in addition the alternative QoS profile(s) towards the access network based on the received alternative QoS parameter set(s).

4.2.3.23 Forwarding of TSC user plane node management information and port management information received from the TSN AF or TSCTSF

During the lifetime of a PDU session enabling Time Sensitive Communications and Time Synchronization the PCF may receive a UMIC and/or one or more PMIC(s) from the TSN AF or TSCTSF within the service information as defined in 3GPP TS 29.514 [17]. A UMIC carries TSC user plane node management information. A PMIC carries port management information for a port located in DS-TT and/or NW-TT.

If the feature "TimeSensitiveNetworking" or "TimeSensitiveCommunication" is supported the PCF initiates the Npcf_SMPolicyControl_UpdateNotify request and sends possibly updated policy information about the PDU Session and/or the UMIC and/or the PMIC(s) to the SMF via the SmPolicyDecision structure, in which the UMIC is encoded in the "tsnBridgeManCont" attribute, the DS-TT PMIC is encoded in the "tsnPortManContDstt" attribute and the one or more NW-TT PMIC(s) are encoded in the "tsnPortManContNwtts" attribute.

The PMIC(s) are encoded in the "PortManagementContainer" data type, that includes the port management information in the "portManCont" attribute and the related port number in the "portNum" attribute. If the port is on DS-TT the SMF forwards the PMIC(s) to the DS-TT port. If the port is on NW-TT the SMF forwards the PMIC(s) to the NW-TT port.

The UMIC is encoded in the "BridgeManagementContainer" data type, that includes the TSC user plane node management information in the "bridgeManCont" attribute. The SMF always forwards the UMIC to the TSC user plane node functionality of the UPF/NW-TT.

4.2.3.24 Provisioning of TSCAI input information and TSC QoS related data

The PCF may receive the TSCAI input information in the TSC assistance container and TSC traffic QoS related information from the TSN AF or TSCTSF.

If the feature "TimeSensitiveNetworking" or "TimeSensitiveCommunication" is supported by both the SMF and PCF as described in clause 5.8, the PCF shall provide for the derived PCC rule(s):

– the 5G QoS parameters and the optional 5G QoS characteristics corresponding to a 5QI for a delay-critical GBR derived from the TSC traffic QoS information received from the TSN AF or TSCTSF encoded within a QosData type referred in the "refQosData" of the PCC rule; and

– the TSCAI input information as received from the TSN AF or TSCTSF, with the periodicity, and burst arrival time encoded in the "tscaiInputUl" attribute and/or "tscaiInputDl" attribute of the PCC rule and, when the feature "TimeSensitiveCommunication" is supported, the survival time encoded in the "tscaiInputUl" attribute and/or "tscaiInputDl" attribute and the (TSN)AF (g)PTP domain encoded in the "tscaiTimeDom" attribute.

The values of MDBV and PDB applied to the derived 5QI shall follow principles defined in clause 5.27.3 of 3GPP TS 23.501 [2].

For IEEE TSN networks, the value of the MBR, if applicable, and the GBR are derived using the Maximum Bit Rate provided by the TSN AF. For other time sensitive communication networks, the value of the GBR may be derived using the input provided by the TSCTSF (e.g. the Minimum Bit Rate) and applying the QoS mapping procedures as specified in clause 7.3.3 of 3GPP TS 29.513 [7].

The ARP is assigned a value preconfigured for TSC services.

As specified in clause 4.2.3.22, when the PCF receives a QoS reference from the TSCTSF, the PCF shall derive the above QoS parameters based on pre-defined QoS parameters referenced by the QoS reference. When the PCF receives individual QoS parameters from the TSCTSF, the PCF shall set derived QoS parameters based on the received individual QoS parameters and applying the QoS mapping procedures as specified in clause 7.3.3 of 3GPP TS 29.513 [7].

If the PCF receives Alternative Service Requirements that contain QoS references from the TSCTSF, the PCF shall derive the alternative QoS parameter set(s) based on the pre-defined QoS parameters referenced by the received Alternative Service Requirements as defined in clause 4.2.3.22. If the PCF receives Alternative Service Requirements that contain Requested Alternative QoS Parameter Set(s) from the TSCTSF, the PCF shall set the alternative QoS parameter set(s) based on the Requested Alternative QoS Parameter Set(s) contained in the received Alternative Service Requirements as defined in clause 4.2.3.22.

The SMF shall convert the received TSCAI input information from the external GM into the 5G GM based on the time offset and cumulative rateRatio (when available) between external time and 5GS time as measured and reported by the UPF and, forward the derived TSCAI parameters per QoS Flow basis to the AN-RAN as follows:

– For the traffic in downlink direction, the SMF shall correct the value of the "burstArrivalTime" attribute of the "tscaiInputDl" attribute based on the latest received time offset measurement from the UPF and set the downlink TSCAI Burst Arrival Time as the sum of the corrected value and the CN PDB as described in clause 5.7.3.4 of 3GPP TS 23.501 [2], representing the latest possible time when the first packet of the data burts arrives at the AN.

– For the traffic in uplink direction, the SMF shall correct the value of "burstArrivalTime" attribute of the "tscaiInputUl" attribute based on the latest received time offset measurement from the UPF and set the uplink TSCAI Burst Arrival Time as the sum of corrected value and the UE-DS-TT Residence Time representing the latest possible time when the first packet of the data burst arrives at the egress of the UE. How the SMF corrects the Burst Arrival Time if the UE-DS-TT residence time has not been provided by the UE is up to SMF implementation.

– The SMF shall correct the value of "periodicity" attribute of the "tscaiInputUl" and/or "tscaiInputDl" using the cumulative rateRatio if the cumulative rateRation measurement was previously received from the UPF and set the TSCAI Periodicity as the corrected value. Otherwise, the SMF shall set the periodicity in the TSCAI Periodicity without any correction.

– If the "TimeSensitiveCommunication" feature is supported and the TSCAI Survival Time Information is received:

– when the "surTimeInNumMsg" attribute is received, the SMF shall convert the value of "surTimeInNumMsg" attribute of the "tscaiInputUl" and/or "tscaiInputDl" attributes into time units by multiplying its value by the corrected uplink TSCAI Periodicity and/or downlink TSCAI Periodicity respectively, and set the TSCAI Survival Time to the calculated value; or

– when the "surTimeInTime" is received, the SMF shall correct the value of "surTimeInTime" attribute of the "tscaiInputUl" and/or "tscaiInputDl" attributes using the cumulative rateRatio if the cumulative rateRatio measurement was previously received from the UPF and set the TSCAI Survival Time to the corrected value. Otherwise, the SMF shall set the TSCAI Survival Time without correction.

If the "TimeSensitiveCommunication" feature is supported, depending on whether the Time Domain information is included in the "tscaiTimeDom" attribute of the PCC rule, SMF may perform the following:

– if the "tscaiTimeDom" attribute is not included in the PCC rule, the SMF provisions the UPF/NW-TT to report the clock drifting between 5G clock and the external GM clock for the (g)PTP time domain number that is configured to the NW-TT.

– if the "tscaiTimeDom" attribute is included in the PCC rule and does not indicate Time Domain = "5GS", the SMF provisions the UPF/NW-TT to report the clock drifting between 5G clock and the external GM clock for the received Time Domain information.

NOTE: The Time Domain value corresponding to "5GS" is locally configured in the SMF and in the TSCTSF and indicates that the AF does not provide a Time Domain, as specified in 3GPP TS 29.565 [53], and it is not needed to adjust the TSCAI input information. The omission of the Time Domain within the "tscaiTimeDom" attribute of the PCC rule indicates it is needed to apply the TSN AF time domain, configured in the NW-TT, to adjust the TSCAI input information.

The SMF shall use the N4 Association Setup or Update procedures as described in 3GPP TS 29.244 [13] to provision the UPF to report the clock drifting.

If the SMF receives the clock drifting from the UPF for a Time Domain, and

– if the received Time Domain matches the Time Domain information within the "tscaiTimeDom" attribute included in the PCC rule; or

– the "tscaiTimeDom" attribute is not included within the PCC rule,

then the SMF may determine the time offset and cumulative rateRatio (when available) based on received Time Domain information and adjust the TSCAI information as described above.

If the received clock drifting from the UPF does not match the Time Domain information within the "tscaiTimeDom" attribute of the PCC rule or the received "tscaiTimeDom" attribute of the PCC rule indicates Time Domain = "5GS" then the SMF will not adjust the TSCAI information.

The provisioning of TSCAI input information and TSC traffic QoS configuration per PCC Rule shall be performed using the PCC rule provisioning procedure as defined in clause 4.2.6.2.1.

4.2.3.25 Policy provisioning of QoS Monitoring to Assist URLLC Service

The QoS Monitoring for URLLC refers to the real time packet delay measurement between the UE and the UPF for a QoS flow corresponding to an URLLC service.

If the "QosMonitoring" feature is supported, the PCF may generate the authorized QoS Monitoring data decision for the service data flow based on the QoS Monitoring request if received from the AF and may determine whether the QoS monitoring report is sent to the AF/NEF by the SMF bypassing the PCF or by the PCF. When the feature "ExposureToEAS" is supported and the AF indication of direct notification is received, the PCF may determine whether duplicate notification is required, i.e., whether the QoS monitoring report is sent to the local AF/NEF by both, the UPF and the PCF.

The PCF shall include within the SmPolicyDecision data structure one or more QosMonitoringData instances within the "qosMonDecs" attribute if not provided yet and, if the PCF determines that the QoS monitoring report shall be sent by the PCF from the SMF, "QOS_MONITORING" within the "policyCtrlReqTriggers" attribute, if it has not been provisioned yet.

NOTE 1: The QoS monitoring report can be sent by the SMF to the PCF as described in clause 4.2.4.24. The QoS monitoring report of the PCF to the AF/NEF is described in 3GPP TS 29.514 [17], the QoS monitoring report of the SMF to the AF/NEF bypassing the PCF is described in 3GPP TS 29.508 [12] and the QoS monitoring report to the Local NEF/AF by the UPF is described in 3GPP TS 29.564 [50].

For each QosMonitoringData instance, PCF shall include:

– the requested QoS monitoring parameter(s) to be measured (i.e. DL, UL and/or round trip packet delay) within the "reqQosMonParams" attribute;

– the frequency(s) of reporting (e.g. event triggered, periodic, or when the PDU Session is released, and/or any combination) within the "repFreqs" attribute;

– for the case the "repFreqs" attribute includes the value "EVENT_TRIGGERED":

– the delay threshold for downlink with the "repThreshDl" attribute if "reqQosMonParams" attribute includes DOWNLINK;

– the delay threshold for uplink with the "repThreshUl" attribute if "reqQosMonParams" attribute includes UPLINK; and/or

– the delay threshold for round trip with the "repThreshRp" attribute if "reqQosMonParams" attribute includes ROUND_TRIP; and

– the minimum waiting time between subsequent reports within the "waitTime" attribute;

– for the case the "repFreqs" attribute includes "PERIODIC", the reporting period within the "repPeriod" attribute;

– either the notification URI within the "notifyUri" attribute and the notification correlation id within the "notifyCorreId" attribute if the PCF determines that the notification shall be sent to the AF directly from the SMF or the notification URI within the "notifyUri" attribute, the notification correlation id within the "notifyCorreId" attribute corresponding to the Local NEF or AF and the "directNotifInd" attribute set to true if the feature "ExposureToEAS" is supported and the PCF determines that the direct notification by the UPF to the Local NEF or AF is required based on the indication of direct notification received from the AF.

NOTE 2: If the feature "ExposureToEAS" is supported and if the PCF determines to receive QoS Monitoring report while direct UPF notification is also required, the PCF can provision the "QOS_MONITORING" policy control request trigger to the SMF together with the "directNotifInd" attribute set to true.

The PCF shall include the value of QoS Monitoring Data ID of QosMonitoringData instance within the "refQosMon" attribute of the corresponding PCC rule and provide the QoS monitoring data decision together with the PCC rule if it has not been provisioned to the SMF. When the SMF receives the PCC rule, the SMF shall send a QoS Monitoring request to the PSA UPF via N4 as defined in 3GPP TS 29.244 [13] and NG-RAN via N2 signalling to request the QoS monitoring between PSA UPF and NG-RAN as defined in 3GPP TS 29.502 [22]. If the feature "ExposureToEAS" is supported and if the SMF receives both the "QOS_MONITORING" policy control request trigger and the indication of direct notifcation, the SMF shall request the UPF to perform duplicated notification as defined in 3GPP TS 29.244 [13].

If the PCF receives the request from the local NEF/AF to disable the QoS monitoring from the AF or the Local NEF, the PCF shall update the PCC rule with the "refQosMon" attribute set to NULL. The PCF may also remove the corresponding QoS Monitoring Data if no PCC rule is referring to it.

If the PCF receives the request to disable the direct event notification to the local NEF or AF by the UPF, the PCF shall determine whether the PCF or the SMF bypassing the PCF sends the QoS monitoring reports to the local AF/NEF:

a. if the QoS monitoring reports are sent by the SMF bypassing the PCF:

– update the PCC rule with the "refQosMon" attribute referring a QosMonitoringData instance which does not include the "directNotifInd" attribute set to true and still includes the "notifyUri", and the "notifyCorreId" attributes; or

– update the corresponding QosMonitoringData instance by including the "directNotifInd" attribute set to false and still keeping the "notifyUri", and the "notifyCorreId" attributes;

b. if the QoS monitoring reports are sent by the PCF:

– update the PCC rule with the "refQosMon" attribute referring a QosMonitoringData instance which does not include the "directNotifInd", the "notifyUri", and the "notifyCorreId" attributes or update the QosMonitoringData instance by removing the "directNotifInd", the "notifyUri", and the "notifyCorreId" attributes; and

– provision the value "QOS_MONITORING" within the "policyCtrlReqTriggers" attribute, if not previously provided.

The SMF shall request to the UPF to disable the notification to the AF/(Local)NEF via N4 as defined in 3GPP TS 29.244 [13] and shall start sending the related notifications to PCF or to the indicated Notification URI and notification correlation Id, as applicable.

If the PCF determines that QoS monitoring report shall be sent to the PCF from the SMF instead of sent from the SMF bypassing the PCF, the PCF shall replace the QosMonitoringData instance with an instance that does not include the "notifyUri" and the "notifyCorrelId" attributes and include "QOS_MONITORING" within the "policyCtrlReqTriggers" attribute if it has not been provisioned yet. If the PCF determines that QoS monitoring report shall be sent from the SMF bypassing the PCF instead of sent from the SMF to the PCF, the PCF shall update the QosMonitoringData instance by including the the notification URI within the "notifyUri" attribute and the notification correlation id within the "notifyCorreId" attribute, and remove the value "QOS_MONITORING" within the "policyCtrlReqTriggers" attribute.

4.2.3.26 Policy decision error handling

4.2.3.26.1 Policy decision types and condition data error handling

If the "PolicyDecisionErrorHandling" feature is supported and the "ExtPolicyDecisionErrorHandling" feature is not supported, and the SMF receives one or more policy decision type(s) (as defined in clause 4.1.4.4) and/or condition data (as defined in clause 4.1.8), which are not referred by any provisioned PCC rule or session rule as defined in clause 4.2.3.2, but the storage of the policy decision types and/or condition data was unsuccessful (e.g. the policy decision could not be successfully stored due to a limitation of resources at the SMF) or there are semantical inconsistencies in the provided data, the SMF shall behave as follows:

– Include an HTTP "200 OK" status code and one or more PolicyDecisionFailureCode data types to indicate the type(s) of the failed policy decisions and/or condition data in the response message, if the SMF does not need to report any other information (e.g. the failure reports of the PCC rule(s) or session rule(s) which are provisioned in the same message, are not needed).

– Include an HTTP "200 OK" status code and one or more PartialSuccessReport data structure(s) including the "policyDecFailureReports" attribute to indicate the type(s) of the failed policy decisions and/or condition data and the "failureCause" attribute set to "POL_DEC_ERROR" in the response message, if the SMF needs to report partial success (e.g. some of the PCC rules and/or session rules provisioned by the PCF in the same message were not installed/activated successfully).

– Include an HTTP "400 Bad Request" status code and the ErrorReport data structure including the "policyDecFailureReports" attribute to indicate the type(s) of the failed policy decisions and/or condition data in the response message, if the SMF needs to reject the request (e.g. all the PCC rules and/or session rules provisioned by the PCF in the same message were not installed/activated successfully).

NOTE: An error within a policy decision type and/or condition data not referred by any PCC rules or session rules is encoded within the "policyDecFailureReports" attribute as specified in the PolicyDecisionFailureCode data structure defined in clause 5.6.3.28.

When the PCF receives the above reports, the PCF shall consider all the instances of the policy decisions and/or condition data which were provisioned in the request message and indicated in the PolicyDecisionFailureCode data type as removed from the SMF. When the PCF receives a response with HTTP "400 Bad Request" status code but the "policyDecFailureReports" attribute is not included in the provided ErrorReport data structure, the PCF shall consider all the provisioned instances of the policy decsions and/or condition data in the request message as removed from the SMF.

The removal of a policy decision type and/or condition data shall not fail.

4.2.3.26.2 Policy decision types, condition data and other policy decisions error handling

If the "ExtPolicyDecisionErrorHandling" feature is supported and the SMF receives one or more policy decision type(s) (as defined in clause 4.1.4.4) and/or condition data (as defined in clause 4.1.8), which are not referred by any provisioned PCC rule or session rule as defined in clause 4.2.3.2, and/or other SM policy decisions (e.g. the SMF receives policy control request triggers and applicable additional information) and the SMF detects that the received policy decision(s) cannot be enforced (e.g, because of semantical inconsistencies in the provided data):

– If the SMF does not need to reject the request (e.g. none, or only some but not all, of the PCC rule(s) and/or session rule(s) provisioned by the PCF in the same message are not installed/activated successfully), the SMF shall include one or more PartialSuccessReport data structure(s) in the response message with an HTTP "200 OK" status code. In order to report the partial success of policy decision and/or condition data, the SMF shall include in the related PartialSuccessReport data structure(s) the "failureCause" attribute set to "POL_DEC_ERROR" and the "policyDecFailureReports" attribute to indicate the failed policy decision type(s) and/or condition data that are not referred by any provisioned PCC rule or session rule and/or in other SM policy decision(s), and may include the "invalidPolicyDecs" attribute to provide more details on these failed policy decision type(s) and/or condition data that are not referred by any provisioned PCC rule or session rule and/or other SM policy decisions.

– If the SMF needs to reject the request (e.g. all the PCC rules and/or session rules provisioned by the PCF in the same message are not installed/activated successfully), the SMF shall include an ErrorReport data structure within a response message with an HTTP "400 Bad Request" status code. The SMF shall include the "policyDecFailureReports" attribute to indicate a failed policy decision type(s) and/or condition data that are not referred by any provisioned PCC rule or session rule and/or in other SM policy decisions, and may include the "invalidPolicyDecs" attribute to provide more details on these failed policy decision types and/or condition data that are not referred by any provisioned PCC rule or session rule and/or other SM policy decisions. In addition, when "Ext2PolicyDecisionErrorHandling" feature is supported and the NF service consumer needs to reject the request because the PCF only provided policy decision/condition data and all of them were faulty, the NF service consumer shall include the ErrorReport data structure with the "error" attribute containing the "cause" attribute of the ProblemDetails data structure set to "POL_DEC_ERROR".

NOTE 1: An error within a policy decision type and/or condition data not referred by any PCC rules or session rules and/or an error in other policy decisions is encoded within the "policyDecFailureReports" attribute as specified in the PolicyDecisionFailureCode data structure defined in clause 5.6.3.28.

When the PCF receives the above reports, the PCF shall behave as follows:

– For the policy decisions and/or condition data:

a. The PCF shall consider all the instances of the policy decision(s) and/or condition data which are provisioned in the request message and indicated in the PolicyDecisionFailureCode data type as removed from the SMF.

b. When the PCF receives a response with HTTP "400 Bad Request" status code but the "policyDecFailureReports" attribute is not included in the provided ErrorReport data structure, the PCF shall consider all the provisioned instance(s) of the policy decision(s) and/or condition data in the request message as removed from the SMF.

c. The removal of a policy decision type and/or condition data shall not fail.

– For the other policy decisions:

a. The PCF shall consider all the new failed policy decisions provisioned in the request message and indicated in the PolicyDecisionFailureCode data type as not installed in the SMF.

b. The PCF shall consider all the modified policy decisions provisioned in the request message and indicated in the PolicyDecisionFailureCode data type as unmodified in the SMF.

c. The PCF shall consider all the removed policy decisions provided in the request message as deleted in the SMF.

NOTE 2: The removal of a policy decision does not fail. Even if there is an inconsistency e.g. between the deletion of a policy control request trigger and the deletion of the applicable additional information, the whole related policy decision is removed.

4.2.3.27 Network slice related data rate policy control

At the time a PCF-initiated change of the authorized Session-AMBR occurs or PCC Rule(s) for GBR service data flow(s) need to be provisioned at the SMF, the PCF may check if the concerned S-NSSAI is subject to network slice data rate policy control. If it is the case, the PCF shall apply network slice data rate control as described in clause 4.2.6.8.