4.2.4 Npcf_SMPolicyControl_Update Service Operation

29.5123GPP5G SystemRelease 18Session Management Policy Control ServiceStage 3TS

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

4.2.4.1 General

The Npcf_SMPolicyControl_Update service operation provides means for the NF service consumer to inform the PCF that a policy control request trigger condition has been met and for the PCF to inform the NF service consumer of any resulting update of the Session Management related policies.

The following procedures using the Npcf_SMPolicyControl_Update service operation are supported:

– Provisioning of PCC rules.

– Provisioning of policy control request triggers.

– Request the policy based on revalidation time.

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

– Policy provisioning and enforcement of authorized default QoS.

– Application detection information reporting.

– Indication of QoS Flow Termination Implications.

– 3GPP PS Data Off Support.

– Request and report Access Network Information.

– Request Usage Monitoring Control and report Accumulated Usage.

– Ipv6 Multi-homing support.

– Request and report the result of PCC rule removal.

– Access Network Charging Identifier Request and report.

– Request and report the successful resource allocation notification.

– Negotiation of the QoS flow for IMS signalling.

– Notification about Service Data Flow QoS target enforcement.

– Request the termination of SM Policy association.

– Reporting of TSC user plane node management information and port management information.

– QoS Monitoring Report.

– Policy decision and condition data error handling.

– Request the policy after DDN failure events.

– Network slice related data rate policy control.

– Presence Reporting Area Information Report.

– PCC Rule Error Report.

– Session Rule Error Report.

– UE initiates a resource modification support.

– Trace Control.

4.2.4.2 Requesting the update of the Session Management related policies

Figure 4.2.4.2-1: Requesting the update of the Session Management related policies

When the NF service consumer detects that one or more policy control request triggers are met, the NF service consumer shall send a POST request to the PCF to update an Individual SM Policy resource. The {smPolicyId} in the URI identifies the Individual SM Policy resource to be updated. The NF service consumer include SmPolicyUpdateContextData data structure in the payload body of the HTTP POST to request a update of representation of the "Individual SM Policy" resource. The NF service consumer shall include the met policy control request trigger(s) within the "repPolicyCtrlReqTriggers" attribute and applicable updated value(s) in the corresponding attribute(s).

The NF service consumer shall include (if the corresponding policy control request trigger is met and the applicable information is available) in SmPolicyUpdateContextData data structure:

– type of access within the "accessType" attribute;

– type of the radio access technology within the "ratType" attribute;

– the new allocated UE Ipv4 address within the "ipv4Address" attribute and/or the UE Ipv6 prefix within the "ipv6AddressPrefix" attribute;

– multiple new allocated UE Ipv6 prefixes within the "addIpv6AddrPrefixes" attribute, if the "MultiIpv6AddrPrefix" feature is supported;

– the released UE Ipv4 address within the "relIpv4Address" attribute and/or the UE Ipv6 prefix within the "relIpv6AddressPrefix" attribute;

– multiple released UE Ipv6 prefixes within the "addRelIpv6AddrPrefixes" attribute, if the "MultiIpv6AddrPrefix feature" is supported;

– the UE MAC address within the "ueMac" attribute;

– the released UE MAC address within the "relUeMac" attribute;

– the indication of UE supporting reflective QoS within the "refQosIndication" attribute;

– access network charging identifier within the "accNetChIds" attribute;

– the 3GPP PS data off status within the "3gppPsDataOffStatus" attribute, if the "3GPP-PS-Data-Off" feature is supported;

– the UE time zone information within the "ueTimeZone" attribute;

– the UDM subscribed Session-AMBR or, if the "DN-Authorization" feature is supported, the DN-AAA authorized Session-AMBR within the "subsSessAmbr" attribute;

NOTE 1: When both, the UDM subscribed Session-AMBR and the DN-AAA authorized Session-AMBR are available in the NF service consumer, the NF service consumer includes the DN-AAA authorized Session-AMBR.

– if the "VPLMN-QoS-Control" feature is supported, the highest Session-AMBR and the default QoS supported in the VPLMN within the "vplmnQos" attribute, if available;

NOTE 2: In home routed roaming, the H-SMF may provide the QoS constraints received from the VPLMN (defined in 3GPP TS 23.502 [3] clause 4.3.2.2.2) to the PCF.

– if the "DN-Authorization" feature is supported, the DN-AAA authorization profile index within the "authProfIndex" attribute;

– subscribed Default QoS Information within the "subsDefQos" attribute;

– detected application information within the "appDetectionInfos" attribute;

– if the "UMC" feature is supported, the accumulated usage reports within the "accuUsageReports" attribute;

– if the "PRA" feature is supported, the reported presence reporting area information within the "repPraInfos" attribute;

– the QoS flow usage required of the default QoS flow within the "qosFlowUsage" attribute;

– indication whether the QoS targets of one or more SDFs are not guaranteed or guaranteed again within the "qncReports" attribute;

– user location(s) information within the "userLocationInfo" attribute;

NOTE 3: The SMF encodes both 3GPP and non-3GPP access UE location in the "userLocationInfo" attribute when they are both received from the AMF.

– if the "GroupIdListChange" feature is supported, the Internal Group Identifier(s) of the served UE within the "interGrpIds " attribute;

– if the "SatBackhaulCategoryChg" feature is supported, the satellite backhaul category or non-satellite backhaul within the "satBackhaulCategory" attribute;

– if the "AMInfluence" feature is supported, the PCF for the UE callback URI and, if received, SBA binding information within the "pcfUeInfo" attribute;

– serving network function identifier within the "servNfId" attribute;

– identifier of the serving network within the "servingNetwork" attribute; and

– when the "EneNA" feature is supported, the list of NWDAF instance IDs used for the PDU Session within the "nwdafInstanceId" and their associated Analytic ID(s) within "nwdafEvents" updated with the new values included within the "nwdafDatas" attribute.

NOTE 4: The NF service consumer provides the complete updated list of NWDAF instance IDs and associated Analytic ID(s) used for the PDU session. If all NWDAF data is deleted an empty list is included.

The NF service consumer may include in "SmPolicyUpdateContextData" data structure the IPv4 address domain identity within the "ipDomain" attribute.

In case of a successful update, "200 OK" response shall be returned. The PCF shall include in the "200 OK" response the representation of the updated policies within the SmPolicyDecision data structure. Detailed procedures related to the provisioning and enforcement of the policy decisions within the SmPolicyDecision data structure are contained in clause 4.2.6.

NOTE 5: An empty SmPolicyDecision data structure is included in the "200 OK" response when the PCF decides not to update policies.

If the PCF received a new list of NWDAF instance IDs used for the PDU Session in "nwdafInstanceId" attribute and their associated Analytic IDs in "nwdafEvents" attribute included within the "nwdafDatas" attribute the PCF may select those NWDAF instances based on this new list as described in 3GPP TS 29.513 [7].

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

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

If the PCF is, due to incomplete, erroneous or missing information (e.g. QoS, RAT type, subscriber information) not able to provision a policy decision as response to the request for PCC rules by the NF service consumer, the PCF may reject the request and include in an HTTP "400 Bad Request " response message the "cause" attribute of the ProblemDetails data structure set to "ERROR_INITIAL_PARAMETERS".

If the PCF receives the set of session information which is sent in the message originated due to a trigger being met is incoherent with the previous set of session information for the same session (E.g. trigger met was RAT changed, and the RAT notified is the same as before), the PCF may reject the request and include in an HTTP "400 Bad Request" response message the "cause" attribute of the ProblemDetails data structure set to "ERROR_TRIGGER_EVENT".

If the PCF detects that the packet filters in the request for new PCC rules received from the NF service consumer is covered by the packet filters of outstanding PCC rules that the PCF is provisioning to the NF service consumer, the PCF may reject the request and include in an HTTP "403 Forbidden" response message the "cause" attribute of the ProblemDetails data structure set to "ERROR_CONFLICTING_REQUEST".

If the PCF does not accept one or more of the traffic mapping filters provided by the NF service consumer in an HTTP POST request (e.g. because the PCF does not allow the UE to request enhanced QoS for services not known to the PCF), the PCF shall reject the request and include in an HTTP "403 Forbidden" response message the "cause" attribute of the ProblemDetails data structure set to "ERROR_TRAFFIC_MAPPING_INFO_REJECTED".

If the NF service consumer receives HTTP response with these codes, the NF service consumer shall reject the PDU session modification that initiated the HTTP Request.

The PCF shall not combine a rejection with provisioning of PCC rule operations in the same HTTP response message.

4.2.4.3 Request the policy based on revalidation time

If the timer for the policy revalidation is started, the SMF shall send the PCC rule request before the indicated revalidation time. The SMF shall within the SmPolicyUpdateContextData data structure include RE_TIMEOUT within the "repPolicyCtrlReqTriggers" attribute. The SMF shall stop the timer once the SMF sends the HTTP POST request.

NOTE 1: The PCF is expected to be prepared to provide a new policy, as desired for the revalidation time, during a preconfigured period before the revalidation time. The preconfigured periods in the SMF and PCF need to be aligned.

The PCF may instruct the SMF to revalidate the provided PCC rules by including the "revalidationTime" attribute within the SmPolicyDecision in the HTTP POST response.

NOTE 2: If the PCF omits the "revalidationTime" attribute the revalidation function remains enabled, but the timer remains stopped till the PCF provides a revalidation time within the "revalidationTime" attribute.

When the SMF receives the HTTP POST response message, the SMF shall start the timer for revalidation based on the received value of revalidation time if the revalidation function is not disabled; otherwise, the SMF shall not start the timer for revalidation.

The PCF may disable the revalidation function by removing the RE_TIMEOUT policy control request trigger in the HTTP POST response message. If the revalidation function is disabled, the SMF shall ignore any received value of revalidation time and shall not start the timer for revalidation.

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

4.2.4.4 Policy provisioning and enforcement of authorized AMBR per PDU session

When the SMF detects that the Session-AMBR changes, the SMF shall notify of the change to the PCF by invoking the procedure defined in clause 4.2.4.2, and shall include the new Session-AMBR within the "subsSessAmbr" attribute and the "SE_AMBR_CH" policy control request trigger within the "repPolicyCtrlReqTriggers" attribute.

If the "DN-Authorization" feature is supported, when both, the UDM subscribed Session-AMBR and the DN-AAA authorized Session-AMBR are available in the SMF, the DN-AAA authorized/re-authorized Session-AMBR shall take precedence over the changes on UDM subscribed Session-AMBR.

If the "VPLMN-QoS-Control" feature is supported,

– in the home routed scenario, when the SMF detects that the Session-AMBR supported in the VPLMN changes (i.e. when the UE moves from the HPLMN to a VPLMN with Session-AMBR constraints or between VPLMNs with different Session-AMBR constraints), the SMF shall notify of the change to the PCF by invoking the procedure defined in clause 4.2.4.2, and shall include the new VPLMN Session-AMBR within the "vplmnQos" attribute and the "VPLMN_QOS_CH" policy control request trigger within the "repPolicyCtrlReqTriggers" attribute.

– when the SMF detects that the UE moves from a VPLMN with Session-AMBR constraints to a VPLMN where the QoS constraints are not applicable in the home routed scenario or the UE moves back to the non-roaming scenario, the SMF shall notify the PCF that the QoS constraints in the VPLMN are not applicable by invoking the procedure defined in clause 4.2.4.2, and shall include the "vplmnQosNotApp" attribute set to true and the "VPLMN_QOS_CH" policy control request trigger within the "repPolicyCtrlReqTriggers" attribute.

Upon receiving the change of Session-AMBR, the PCF shall ensure that the authorized Session-AMBR value does not exceed the Session-AMBR supported by the VPLMN, if applicable, and provision the new authorized Session-AMBR to the SMF in the response as defined in clauses 4.2.6.3.1 and 4.2.6.3.2.

Upon receiving the authorized Session-AMBR from the PCF, the SMF shall apply the corresponding procedures towards the access network, the UE and the UPF for the enforcement of the AMBR per PDU session.

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

4.2.4.5 Policy provisioning and enforcement of authorized default QoS

When the SMF detects that the subscribed default QoS change, the SMF shall notify of the PCF by invoking the procedure as defined in clause 4.2.4.2, include the new subscribed default QoS within the "subsDefQos" attribute and "repPolicyCtrlReqTriggers" set to DEF_QOS_CH.

If the "VPLMN-QoS-Control" feature is supported,

– in the home routed scenario, when the SMF detects that the default QoS supported in the VPLMN changes (i.e. when the UE moves from the HPLMN to a VPLMN with default QoS constraints or between VPLMNs with different default QoS constraints), the SMF shall notify of the change to the PCF by invoking the procedure defined in clause 4.2.4.2, and shall include the new default QoS value supported in the VPLMN within the "vplmnQos" attribute and the "VPLMN_QOS_CH" policy control request trigger within the "repPolicyCtrlReqTriggers" attribute;

– when the SMF detects that the UE moves from a VPLMN with default QoS constraints to a VPLMN where the QoS constraints are not applicable in the home routed scenario or the UE moves back to the non-roaming scenario, the SMF shall notify the PCF that the QoS constraints in the VPLMN are not applicable by invoking the procedure defined in clause 4.2.4.2, and shall include the "vplmnQosNotApp" attribute set to true and the "VPLMN_QOS_CH" policy control request trigger within the "repPolicyCtrlReqTriggers" attribute.

Upon receiving the change of default QoS, the PCF shall ensure that the authorized default QoS contains a 5QI and ARP values supported by the VPLMN, if applicable, and shall provision the authorized default QoS to the SMF in the response of the message as defined in clauses 4.2.6.3.1 and 4.2.6.3.2.

Upon receiving 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.

4.2.4.6 Application detection information reporting

If the ADC feature is supported and if the SMF receives the PCC rule for application detection and control, the SMF shall instruct the UPF as defined in 3GPP TS 29.244 [13] to:

– Detect the application traffic.

– Report the detected application’s traffic start/stop events along with the application instance identifier and service data flow descriptions when service data flow descriptions are deducible.

When the start of the application’s traffic, identified by an application identifier, is received from the UPF, if PCF has previously provisioned the APP_STA/APP_STO policy control request trigger, unless a request to mute such a notification (i.e. the "muteNotif" attribute set to true within the Traffic Control Data decision which the PCC rule refers to), the SMF shall report the start of the application to the PCF.

In order to do so, the SMF shall perform the procedure as defined in clause 4.2.4.2 by including the information regarding the detected application`s traffic within the "appDetectionInfos" attribute and the "APP_STA" within the "repPolicyCtrlReqTriggers" attribute even if the application traffic is discarded due to enforcement actions of the PCC rule. In this case, within the each AppDetectionInfo instance, the SMF shall include the received application identifier within the "appId" attribute, and may include the detected service data flow description within the "sdfDescriptions" attribute if deducible and received and an allocated application instance identifier for the detected service data flow descriptions if received within the "instanceId". The "sdfDescriptions" attribute, if present, shall contain the "flowDescription" attribute and "flowDirection" attribute. The application instance identifier allows the correlation of APP_STA and APP_STO policy control request trigger to the specific service data flow descriptions.

When the stop of the application’s traffic, identified by an application identifier is received from the UPF and the SMF has reported the start of the application to the PCF, the SMF shall report the stop of the application to the PCF. In order to do so, the SMF shall perform the procedure as defined in clause 4.2.4.2 by including the information regarding the detected application`s traffic within the "appDetectionInfos" attribute and the "APP_STO" within the "repPolicyCtrlReqTriggers" attribute. For each AppDetectionInfo instance, the SMF shall include the received application identifier within the "appId" attribute and the application instance identifier received from the UPF within the "instanceId" if it is provided along with the APP_STA to the PCF.

The PCF then may make policy decisions based on the information received and send the corresponding updated PCC rules to the SMF.

When a PFD provisioned by the PFDF as specified in 3GPP TS 29.551 [46] is removed/modified and the removed/modified PFD was used to detect application traffic related to an application identifier in a PCC rule installed or activated for a PDU session, if the removed/modified PFD results in that the stop of an application or an application instance is not able to be detected, and if the SMF has reported the application start as described in this clause to the PCF for the application or application instance represented by this PFD, the SMF shall report the application stop to the PCF for the corresponding application or the corresponding application instance, if the stop of the application’s traffic, identified by the corresponding application or the corresponding application instance, is received from the UPF.

NOTE: Multiple PFDs can be associated with the application identifier. When the removed/modified PFD is the last one which is used to detect traffic identified by the "appId" attribute, the SMF reports application stop.

The PCF is not allowed to update the mute indication of a provisioned PCC rule(s) 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 update of the mute indication for a provisioned PCC rule as specified in clause 4.2.6.2.11.

4.2.4.7 Indication of QoS Flow Termination Implications

When the SMF detects that a dedicated QoS flow could not be activated or has been terminated it shall remove the affected PCC rules and send an HTTP POST request to the PCF with an SmPolicyUpdateContextData data structure, including the "ruleReports" attribute containing the RuleReport data instance which specifies the affected PCC rules within the "pccRuleIds" attribute, "INACTIVE" as the value within the "ruleStatus" attribute and the "RES_ALLO_FAIL" as the value of the "failureCode" attribute.

If the RAN-NAS-Cause feature is supported, the SMF shall provide the available access network information within the "userLocationInfo" attribute (if available), "userLocationInfoTime" attribute (if available) and "ueTimezone" attribute (if available). Additionally, if the SMF receives from the access network the RAN cause and/or the NAS cause due to QoS flow termination the SMF shall provide the received cause(s) in the "ranNasRelCauses" attribute included in RuleReport data instance.

If the NetLoc feature is supported, and if the identifier of the affected PCC rule was included within the "refPccRuleIds" attribute of the RequestedRuleData data structure when the affected PCC rule was installed or modified, the SMF shall provide the access network information to the PCF by including the user location(s) information within the "userLocationInfo" attribute (if requested by the PCF and if provided to the SMF), the information on when the UE was last known to be in that location within "userLocationInfoTime" attribute (if user location information was requested by the PCF and if the corresponding information was provided to the SMF), the PLMN Identifier or the SNPN Identifier (the PLMN Identifier and the NID) within the "servingNetwork" attribute (if the user location information was requested by the PCF but it is not provided to the SMF) and the timezone information within the "ueTimeZone" attribute (if requested by the PCF and available).

NOTE 1: The SMF derives the value of the "userLocationInfoTime" attribute from the age of location information received from the AMF at PDU session update as described in 3GPP TS 29.502[22]. Whether the "userLocationInfo" attribute also encodes the age of location is implementation specific.

NOTE 2: The SMF encodes both 3GPP and non-3GPP access UE location in the "userLocationInfo" attribute when they are both received from the AMF.

This shall be done whenever one of these conditions applies:

– The SMF is requested by the RAN to initiate the deactivation of a QoS flow.

– PCC rule(s) are removed/deactivated by the SMF without PCF request (e.g. due to unsuccessful reservation of resources to satisfy the QoS flow binding).

NOTE 3: The SMF will not initiate the deactivation of the QoS flow upon reception of the UE-initiated resource modification procedure indicating packet filter deletion. If all the PCC rules associated to a QoS flow have been deleted as a consequence of the PCF interaction, the SMF will initiate the QoS flow termination procedure towards the RAN.

Signalling flows for the QoS flow termination and details of the binding mechanism are presented in 3GPP TS 29.513 [7].

4.2.4.8 3GPP PS Data Off Support

If the SMF is informed that the 3GPP PS Data Off status of the UE changed, the SMF shall send an HTTP POST message to the PCF, as defined in clause 4.2.4.2, providing the "PS_DA_OFF" value within the "repPolicyCtrlReqTriggers" attribute and the "3gppPsDataOffStatus" attribute set to the value indicated by the UE within the"SmPolicyUpdateContextData" data structure.

Upon reception of this HTTP POST message with the "repPolicyCtrlReqTriggers" attribute set to the value "PS_DA_OFF" or "AC_TY_CH" the PCF shall determine whether the 3GPP PS Data Off handling functionality (as described below) becomes active or inactive. The 3GPP PS Data Off handling functionality is active if, and only if,

– the latest received "3gppPsDataOffStatus" attribute is set to true; and

NOTE 1: If the PS_DA_OFF policy control request trigger is received, the latest received value is the one received in the HTTP POST message. Otherwise, it corresponds to the stored value.

– the UE uses 3GPP access, i.e.:

– for a non MA PDU session, the "accessType" attribute is set to "3GPP_ACCESS"; and

– for a MA PDU session, either the "accessType" attribute or the "addAccessInfo"attribute indicate "3GPP_ACCESS", and the "relAccessInfo" attribute either is not available or does not indicate "3GPP_ACCESS".

If the PCF determines that the 3GPP PS Data Off handling functionality becomes active, the PCF shall configure the SMF in such a way that:

– only packets for services belonging to the list of 3GPP PS Data Off Exempt Services are forwarded over 3GPP access; and

– all other downlink packets and optionally uplink packets are:

– for a non-MA PDU session or a MA PDU session where non-3GPP access is not available, discarded by modifying or removing any related dynamic PCC rule(s) or by deactivating any related predefined PCC rule(s);

– for a MA PDU session where non-3GPP access is available, forwarded only via non-3GPP access, if it is ensured by the policy for ATSSS Control as specified in clause 4.2.6.2.17.

NOTE 2: In order for the UPF to prevent the services that do not belong to the list of 3GPP PS Data Off Exempt Services, if such services are controlled by dynamic PCC rules, the PCF can either close gates for the downlink and optionally the uplink directions via the "flowStatus" attribute in the related dynamic PCC rules or remove those dynamic PCC rules. If the services are controlled by predefined PCC rules, the PCF needs to deactivate those PCC rules. PCC rule(s) with wild-carded service data flow filters can be among the PCC rules that are modified, removed or disabled in that manner. It can then be necessary that the PCF at the same time installs or activates PCC rules for PS Data Off Exempt Services. The network configuration can ensure that at least one PCC rule is bound to the default QoS flow when PS Data Off is activated in order to avoid the deletion of an existing PDU session or to not fail a PDU session establishment.

If the PCF determines that the 3GPP PS Data Off handling functionality becomes inactive, the PCF shall make the necessary policy control decisions and perform PCC rule operations 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 or not).

NOTE 3: 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 with this PCC rule.

4.2.4.9 Request and Report of Access Network Information

If the NetLoc as 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.

If the AN_INFO policy control request trigger is set, upon receiving the "lastReqRuleData" attribute with the "reqData" attribute with the value(s) MS_TIME_ZONE and/or USER_LOC_INFO and the "refPccRuleIds" attribute containing the PCC rule identifier(s) corresponding to the PCC rule(s) which is being installed, modified or removed together, the SMF shall apply the Namf_EventExposure service for Time-Zone-Report and/or Location-Report event with One-Time Report type as defined in clause 5.3.1 and 5.3.2.2.2 of 3GPP TS 29.518 [36] if the related information is not available to obtain this information. When the SMF then receives access network information from the AMF, the SMF shall provide the required access network information to the PCF by as defined in clause 4.2.4.2 and set the corresponding attributes as follows:

– If the user location(s) information was requested by the PCF and was provided to the SMF, the SMF shall provide the user location information within the "userLocationInfo" attribute and the time when it was last known within "userLocationInfoTime" attribute (if available).

NOTE 1: The SMF derives the value of the "userLocationInfoTime" attribute from the age of location information received in the Location-Report (defined in clause 5.3.1 of 3GPP TS 29.518 [36]) from the AMF. Whether the "userLocationInfo" attribute also encodes the age of location is implementation specific.

NOTE 2: The SMF encodes both 3GPP and non-3GPP access UE location in the "userLocationInfo" attribute when they are both received from the AMF.

– If the user location information was requested by the PCF and was not provided to the SMF, the SMF shall provide the serving PLMN Identifier or the SNPN Identifier (the PLMN Identifier and the NID) within the "servingNetwork" attribute.

– If the time zone was requested by the PCF, the SMF shall provide it within the "ueTimeZone" attribute.

NOTE 3: If the SMF receives the access network information but receives the rejection of the QoS flow creation or modification, the SMF reports the the enforcement error of the PCC rule to the PCF as defined in clause 4.2.4.15.

In addition, the SMF shall provide the AN_INFO policy control request trigger within the "repPolicyCtrlReqTriggers" attribute.

The SMF shall not report any subsequent access network information updates received from the RAN without any further provisioning or removal of related PCC rules requesting the access network information unless the associated QoS flow or PDU session has been released.

4.2.4.10 Request Usage Monitoring Control and Reporting Accumulated Usage

4.2.4.10.1 General

If the UMC feature, as 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 usage monitoring control.

The SMF shall report the accumulated usage to the PCF in the following conditions:

– when a usage threshold is reached, as described in this clause;

– when all PCC rules for which usage monitoring is enabled for a particular usage monitoring key are removed or deactivated, as specified in clause 4.2.4.10.2;

– when usage monitoring is explicitly disabled by the PCF, as specified in clause 4.2.6.5.3.2;

– when a PDU session is terminated, as specified in clause 4.2.5.3;

– when requested by the PCF, as specified in clause 4.2.6.5.3.3.

The UPF measures the volume and/or the time of usage of all traffic of a PDU session or the corresponding service data flows. When the SMF receives the accumulated usage report from the UPF as defined in clauses 7.5.5.2, 7.5.7.2 or 7.5.8.3 of 3GPP TS 29.244 [13], the SMF shall send an HTTP POST message as defined in clause 4.2.4.2, including one or more accumulated usage reports within the "accuUsageReports" attribute and the "US_RE" value within the "repPolicyCtrlReqTriggers" attribute. Each AccuUsageReport data structure shall contain the accumulated usage report within one or two Usage Report information element, i.e. the accumulated usage before the monitoring time or the accumulated usage both before and after the monitoring time, corresponding to one usage monitoring control instance as requested by the PCF.

If the monitoring time is provided by the PCF for a usage monitoring control instance and:

– if the SMF receives only one Usage Report information elements corresponding to the usage monitoring control instance from the UPF, within the AccuUsageReport data structure, the SMF shall include the accumulated usage before the monitoring time within the "timeUsage" attribute, "volUsage" attribute, "volUsageUplink" attribute and/or "volUsageDownlink" attribute, if applicable; otherwise,

– if the SMF receives two Usage Report information elements corresponding to the usage monitoring control instance from the UPF, within the AccuUsageReport data structure, the SMF includes the accumulated usage before the monitoring time within the "timeUsage" attribute, "volUsage" attribute, "volUsageUplink" attribute and/or "volUsageDownlink" attribute, if applicable, and the accumulated usage after the monitoring time within the "nextTimeUsage" attribute, "nextVolUsage" attribute, "nextVolUsageUplink" attribute and/or "nextVolUsageDownlink" attribute, if applicable.

When the PCF receives the accumulated usage report in the HTTP POST message, the PCF shall indicate to the SMF if usage monitoring shall continue for this usage monitoring control instance as follows:

– if the PCF wishes to continue monitoring for the usage monitoring control instance and:

– if monitoring shall continue for specific level(s), the PCF shall provide in the response to the received HTTP POST message the new threshold(s) corresponding to these level(s) using the same attributes as before (i.e. "volumeThreshold", "volumeThresholdUplink", "volumeThresholdDownlink" and/or "timeThreshold"; "nextVolThreshold", "nextVolThresholdUplink", "nextVolThresholdDownlink", and/or "nextTimeThreshold" if the "monitoringTime" attribute is provided within an entry of the "umDecs" attribute); or

– if the PCF wishes to stop monitoring for specific level(s) the PCF shall not include in the response to the received HTTP POST message updated threshold(s) for these specific level(s), i.e. the corresponding "volumeThreshold" attribute, "volumeThresholdUplink" attribute, "volumeThresholdDownlink" attribute, "timeThreshold" attribute, "nextVolThreshold" attribute, "nextVolThresholdUplink" attribute, "nextVolThresholdDownlink" attribute, and/or "nextTimeThreshold" attribute shall not be included within an entry of the "umDecs" attribute.

– otherwise, if the PCF wishes to stop monitoring for the usage monitoring control instance, the PCF shall not include any thresholds of this usage monitoring control instance in the response to the HTTP POST message or remove the reference to the usage monitoring control instance from the concerned dynamic PCC rule or session rule.

If both volume and time thresholds were provided by the PCF and only one of these two thresholds is reached, the SMF shall report this event to the PCF and the accumulated usage since last report shall be reported for both measurements.

Upon reception of the reported usage from the SMF, the PCF shall deduct the value of the usage report from the total allowed usage for that PDU session, usage monitoring key, or both as applicable, and the PCF may also derive and update the PCC rules based on the remaining allowed usage or reported usage and provision them to the SMF. If the remaining allowed usage reaches a value zero (or below zero), the PCF may apply other policy decisions and interact with the SMF accordingly.

NOTE: The PCF can also update the related usage monitoring information in the UDR as defined in 3GPP TS 29.519 [15] according to the received usage report(s).

4.2.4.10.2 PCC Rule Removal

When the PCF removes or deactivates the last PCC rule associated with a usage monitoring key in an Npcf_SMPolicyControl_UpdateNotify request as described in clause 4.2.3.2 or in an Npcf_SMPolicyControl_Update response as described in clause 4.2.3.4 whose request was not related to reporting usage for the same monitoring key, the SMF shall send a new Npcf_SMPolicyControl_Update request including the "US_RE" value within the "repPolicyCtrlReqTriggers" attribute and one or more accumulated usage reports within the "accuUsageReports" attribute within the SmPolicyUpdateContextData data type of the HTTP POST request using the procedures to report accumulated usage defined in clause 4.2.4.10.

When the SMF reports that the last PCC rule associated with a usage monitoring key is inactive, the SMF shall report the accumulated usage for that monitoring key within the same HTTP POST request if the "ruleReports" attribute was included in the SmPolicyUpdateContextData data type; otherwise, if the "ruleReports" attribute was included in the HTTP POST response of an Npcf_SMPolicyControl_UpdateNotify request, the SMF shall invoke the Npcf_SMPolicyControl_Update service operation by sending a new HTTP POST request to report accumulated usage for the usage monitoring key.

4.2.4.11 Ipv6 Multi-homing support

The SMF may insert an additional PDU Session Anchor to an existing PDU session by using Ipv6 multi-homing mechanism. In this case, the SMF shall inform the PCF when one or more new Ipv6 prefix is allocated to the new PDU Session Anchor as defined in clause 4.2.4.2. The SMF shall, within the SmPolicyUpdateContextData data structure, include the "UE_IP_CH" within the "repPolicyCtrlReqTriggers" attribute and include the new Ipv6 prefix within the "ipv6AddressPrefix" attribute or multiple new Ipv6 prefixes within the "addIpv6AddrPrefixes" attribute, if the "MultiIpv6AddrPrefix" feature is supported.

When the PCF receives the request from the SMF indicating the addition of one or more new Ipv6 prefixes, the PCF shall determine the impacted PCC rules and/or session rules associated with each new Ipv6 prefix and provision them to the SMF as defined in clauses 5.6.2.6 and 5.6.2.7. 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. The PCF shall additionally consider the new Ipv6 prefix, or the multiple new Ipv6 prefixes if the "MultiIpv6AddrPrefix" feature is supported, during subsequent PCC rules and/or session rules updates.

When the SMF removes a PDU Session anchor from the Multi-homing PDU session, the SMF shall inform the PCF of the released Ipv6 prefix related to the PDU Session anchor as defined in clause 4.2.5.2. The SMF shall, within the SmPolicyUpdateContextData data structure, include the "UE_IP_CH" within the "repPolicyCtrlReqTriggers" attribute and include the released Ipv6 prefix within the "relIpv6AddressPrefix" attribute or multiple released UE Ipv6 prefixes within the "addRelIpv6AddrPrefixes" attribute, if the "MultiIpv6AddrPrefix feature" is supported.

When the PCF receives the request from the SMF indicating the release of one or more Ipv6 prefixes, the PCF shall determine the previously provisioned PCC rules and/or session rules associated with each released Ipv6 prefix and shall remove and/or update them from the SMF as applicable. The PCF shall remove the released Ipv6 prefix, or the multiple released Ipv6 prefixes if the "MultiIpv6AddrPrefix" is supported.

4.2.4.12 Request and report 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 the PCC rule removal when the PCF removes the PCC rule as defined in clause 4.2.6.5.2.

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

The SMF shall notify the PCF by include the "RES_RELEASE" within the "repPolicyCtrlReqTriggers" attribute and the affected rules indicated within one instance of the "ruleReports" attribute with the "ruleStatus" attribute set to the value INACTIVE.

If the QoS flow is terminated as a consequence of the removal of one or more PCC rules, the SMF shall inform the PCF about the completion of the QoS flow procedure related to the removal of PCC rules that indicated resource release notification by including the RequestedRuleData instance containing the "reqData" attribute with the RES_RELEASE referring to the PCC rule. If the SMF received from the access network some RAN/NAS release cause(s), the SMF shall also provide the received cause(s) in the "ruleReports" attribute. The SMF shall also provide the available access network information within the "userLocationInfo" attribute (if available), "userLocationInfoTime" attribute (if available) and "ueTimezone" attribute (if available).

4.2.4.13 Access Network Charging Identifier request and report

If the "policyCtrlReqTriggers" attribute with the value "AN_CH_COR" has been provided to the SMF, the SMF shall notify to the PCF the Access Network Charging Identifier that the SMF has assigned to the PDU session for the dynamic PCC Rules which referred from the RequestedRuleData data structure containing the CH_ID within the "reqData" attribute by including an "accNetChIds" attribute within the SmPolicyUpdateContextData data structure in the HTTP POST message.

If the the Access Network Charging Identifier is within the Uint32 value range; the SMF shall include one AccNetChId instance within the "accNetChIds" attribute and include the Access Network Charging Identifier within the "accNetChaIdValue" attribute and the "sessionChScope" attribute set to true; otherwise, if the "AccNetChargId_String" feature is supported by the SMF and the PCF, and the Access Network Charging Identifier value is longer than Uint32, the SMF shall include one AccNetChId instance within the "accNetChIds" attribute and the Access Network Charging Identifier within the "accNetChargIdString" attribute and the "sessionChScope" attribute set to true.

NOTE: As specified in 3GPP TS 32.255 [35] clause 5.1.4, the SMF assigns a charging identifier per PDU session and is used through the PDU session’s lifetime. The request of Access Network Charging Identifier(s) in 5GS and EPS interworking scenarios is described in clause B.3.4.11.

When the PCF does not have the access network charging identifier information for the PDU session, the PCF may request the SMF to provide the Access Network Charging Identifier associated to the new dynamic PCC rules as defined in clause 4.2.6.5.1 in the response message.

4.2.4.14 Request and report 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.

If the "policyCtrlReqTriggers" attribute with the value "SUCC_RES_ALLO" has been provided to the SMF, the SMF shall notify to the PCF that the resources associated to the PCC rules which were referred from an element of the "lastReqRuleData" attribute containing the "SUCC_RES_ALLO" within the "reqData" attribute are successfully allocated. When the SMF received successful resource allocation response from the access network, the SMF shall within the SmPolicyUpdateContextData data structure include the "SUCC_RES_ALLO" within the "repPolicyCtrlReqTriggers" attribute and "ruleReports" attribute. Within the RuleReport instance, the SMF shall include the corresponding PCC rule identifier(s) within the "pccRuleIds" attribute and the "ruleStatus" attribute set to value "ACTIVE".

If the "AuthorizationWithRequiredQoS" feature as defined in clause 5.8 is supported and if the SMF additionally receives the reference to the matching Alternative QoS Profile which the NG-RAN can guarantee, the SMF shall also include the reference to the QosData data structure for the Alternative QoS parameter set corresponding to the reference to the matching alternative QoS profile within the "altQosParamId" attribute. When the "AltQoSProfilesSupportReport" feature is supported, and the SMF received the indication that the lowest priority Alternative QoS profile cannot be fulfilled as specified in 3GPP TS 38.413 [54], the SMF shall set the "altQosNotSuppInd" attribute to false to indicate to the PCF that the lowest priority Alternative QoS profile cannot be fulfilled.

If the "RuleVersioning" feature is supported and the PCF included the "contVer" attribute for a specific PCC rule instance, and the resource allocation was successful for this PCC rule, the SMF shall include the rule content version within the "contVers" attribute in the corresponding RuleReport instance.

4.2.4.15 PCC Rule Error Report

If the installation/activation of one or more PCC rules fails using the procedure as defined in clause 4.2.2.1 or 4.2.4.1 or the PCF installed, activated or modified one or more PCC rules as defined in clause 4.2.3.1 but resource allocation for the PCC rule was unsuccessful or the UE was found temporarily unavailable, the SMF shall include the "ruleReports" attribute for the affected PCC rules to report the failure within the SmPolicyUpdateContextData data structure. Within each RuleReport instance, the SMF shall identify the failed PCC rule(s) by including the affected PCC rules within the "pccRuleIds" attribute, identify the failed reason code by including a "failureCode" attribute, and shall include rule status within the "ruleStatus" attribute with the value as described below.

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" to INACTIVE.

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

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 SMF shall report the modification failure to the PCF.

If a PCC rule was successfully installed/activated, but can no longer be enforced by the SMF, the SMF shall set the "ruleStatus" attribute to INACTIVE.

NOTE: When the PCF receives "ruleStatus" set to INACTIVE, the PCF does not need request the SMF to remove the inactive PCC rule.

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

If the feature "UEUnreachable" is supported, when the "failureCode" indicates "UE_TEMPORARILY_UNAVAILABLE" and the "retryTimer" is received, the PCF should not reattempt the installation, re-installation or modification of PCC rules until the received retry timer expires.

If the RAN-NAS-Cause feature is supported and as part of any of the procedures described in this clause the SMF receives from the access network some RAN/NAS release cause(s), the SMF shall also provide the received cause(s) in the RuleReport instance. If RAN-NAS-Cause feature is supported the SMF shall provide the available access network information within the "userLocationInfo" attribute (if available), "userLocationInfoTime" attribute (if available) and "ueTimezone" attribute (if available).

If the "RuleVersioning" feature is supported and the PCF included the "contVer" attribute for a specific PCC rule instance, and the resource allocation was unsuccessful as for any of the procedures described in this clause the SMF shall include the rule content version within the "contVers" attribute for the corresponding RuleReport instance.

4.2.4.16 Presence Reporting Area Information Report

If the PRA or ePRA feature as defined in clause 5.8 is supported and when the SMF receives the presence reporting area information from the serving node as defined in 3GPP TS 29.518 [36] indicating that the UE is inside or outside of one or more presence reporting areas or any of the presence reporting areas is set to inactive, the SMF shall check if the reported presence reporting area identifier corresponds to a presence reporting area that is relevant for the PCF. In that case, the SMF shall within the SmPolicyUpdateContextData data structure include the "PRA_CH" within the "repPolicyCtrlReqTriggers" attribute and one or more Presence Reporting Area Information Report within the "repPraInfos" attribute. For each PresenceInfo data structure, the SMF shall also include the presence reporting area status within the "presenceState" attribute and the presence reporting area identifier within the "praId" attribute for each of the presence reporting areas reported by the serving node.

If the SMF receives presence reporting area information for a Set of Core Network predefined Presence Reporting Area encoded within the "praId" attribute together with the individual PRA Identifier encoded within the "additionalPraId" attribute as described in 3GPP TS 29.518 [36], the SMF shall only provide the PCF with the presence reporting area information corresponding to the additional PRA information (i.e. the individual PRA identifier) encoded within the "praId" attribute.

NOTE 1: The SMF will receive additional presence reporting area information when the UE enters or leaves one or more presence reporting areas related to a PRA set. In that case, the additional presence reporting area information corresponds to the actual individual presence reporting area. The received presence reporting area identifier corresponds to the PRA set id and is used to identify the requester (PCF or CHF) of the notification information.

NOTE 2: The PCF can acquire the necessary data for presence reporting from the UDR.

NOTE 3: Homogeneous support of Presence Area reporting in a network is assumed.

NOTE 4: The serving node can activate the reporting for the PRAs which are inactive as described in the 3GPP TS 23.501 [2].

4.2.4.17 UE initiates a resource modification support

In the case that the UE initiates a resource modification procedure as defined in clause 6.4.2.2 of 3GPP 3GPP TS 24.501 [20], the SMF shall within the SmPolicyUpdateContextData data structure include the "RES_MO_RE" within the "repPolicyCtrlReqTriggers" attribute and shall include the UE request of specific QoS handling for selected SDF within the "ueInitResReq" attribute. Within the UeInitiatedResourceRequest data structure, the SMF shall include the "ruleOp" attribute, "packFiltInfo" attribute and "reqQos" attribute if applicable as follows:

– When the UE requests to "Create new QoS rule", the SMF shall include the "ruleOp" attribute set to "CREATE_PCC_RULE", the "packFiltInfo" attribute and "reqQos" attribute containing the requested QoS for the new PCC rule. Each PacketFilterInfo instance shall contain one packet filters requested for creating the new QoS rule. If the PCF authorizes the request, the PCF shall create a new PCC rule by including the new packet filters within the service data flow template of the PCC rule. When the SMF received the PCC rule, the SMF shall derive the QoS rule based on the PCC rule, assign a new QoS rule identifier within the PDU session for the QoS rule. The SMF shall keep the mapping between the PCC rule identifier and the QoS rule identifier.

– When the UE requests to "Modify existing QoS rule and add packet filters" for the QoS rule created as a result of the UE-initiated resource modification, SMF shall include the "ruleOp" attribute set to "MODIFY_PCC_RULE_AND_ADD_PACKET_FILTERS", the "pccRuleId" attribute including the PCC rule identifier corresponding the QoS rule identifier and the "packFiltInfo" attribute. Each PacketFilterInfo instance shall contain one packet filters requested for addition to this QoS Rule. If the UE request includes the modified QoS information the SMF shall also include the "reqQos" attribute to indicate the updated QoS for the affected PCC rule(s). If the PCF authorizes the request, the PCF shall update the PCC rule by adding the new packet filters to the service data flow template of the PCC rule.

– When the UE requests to "Modify existing QoS rule and replace all packet filters" for the QoS rule created as a result of the UE-initiated resource modification, SMF shall include the "ruleOp" attribute set to "MODIFY_PCC_RULE_AND_REPLACE_PACKET_FILTERS", the "pccRuleId" attribute including the PCC rule identifier corresponding the QoS rule identifier and the "packFiltInfo" attribute. Each PacketFilterInfo instance shall contain one packet filters requested for addition to this QoS Rule. If the UE request includes the modified QoS information the SMF shall also include the "reqQos" attribute to indicate the updated QoS for the affected PCC rule. If the PCF authorizes the request, the PCF shall update PCC rule by replacing the all existing packet filters within the service data flow template of the PCC rule with the new packet filter(s).

– When the UE requests to "Modify existing QoS rule and delete packet filters" for the QoS rule created as a result of the UE-initiated resource modification, SMF shall include the "ruleOp" attribute set to "MODIFY_PCC_RULE_AND_DELETE_PACKET_FILTERS", the "pccRuleId" attribute including the PCC rule identifier corresponding the QoS rule identifier and the "packFiltInfo" attribute. Each PacketFilterInfo instance shall within the "packFiltId" attribute include the removed packet filter identifier assigned by the PCF corresponding to the packet filter identifier received from the UE. If the UE request includes modified QoS information the SMF shall also include the "reqQos" attribute to indicate the updated QoS for the affected PCC rule(s). If the PCF authorizes the request, the PCF shall update PCC rule by removing the corresponding packet filters from the service data flow template of the PCC rule.

– When the UE requests to "Modify existing QoS rule without modifying packet filters" for the QoS rule created as a result of the UE-initiated resource modification, SMF shall include the "ruleOp" attribute set to "MODIFY_PCC_RULE_WITHOUT_MODIFY_PACKET_FILTERS", the "pccRuleId" attribute including the PCC rule identifier corresponding the QoS rule identifier, the "packFiltInfo" attribute and the modified QoS information within the "reqQos" attribute. The "packFiltInfo" attribute shall include one PacketFilterInfo instance which includes any packet filter identifier assigned by the PCF for the PCC rule within the "packFiltId" attribute.

– When the UE requests to "Delete existing QoS rule" the SMF shall include the "ruleOp" attribute set to "DELETE_PCC_RULE" for the QoS rule created as a result of the UE-initiated resource modification, the "pccRuleId" attribute including the PCC rule identifier corresponding the QoS rule identifier and the "packFiltInfo" attribute. The "packFiltInfo" attribute shall include one PacketFilterInfo instance which includes any packet filter identifier assigned by the PCF for the PCC rule within the "packFiltId" attribute. The PCF shall remove the PCC rule when the PCF receives the request according to the PCC rule identifier.

NOTE 1: The UE can only modify or delete the packet filters that the UE has introduced and associated resources. The packet filter identifiers contained in the FlowInformation data structure are only used for packet filters created by the UE.

The SMF shall calculate the requested GBR, for a GBR 5QI, as the sum of the previously authorized GBR for the affected PCC rule, corresponding to the QoS rule, adjusted with the difference between the requested GBR for the QoS flow and previously negotiated GBR for the QoS flow. For the UE request to create a new QoS Rule, the GBR as requested by the UE for the QoS rule shall be used.

If the request covers all the PCC rules with a QoS flow binding to the same QoS flow, then the SMF may request a change to the 5QI for existing PCC rules.

For the purpose of creating or modifying a QoS rule with adding, replacing and modifying packet filter, within the UeInitiatedResourceRequest instance, the SMF shall include the precedence information of the QoS rule within the "precedence" attribute, and within each PacketFilterInfo instance, the SMF shall include the "packFiltCont" attribute, "tosTrafficClass" attribute, "spi" attribute, "flowLabel" attribute and "flowDirection" attribute set to the value(s) describing the packet filter provided by the UE.

NOTE 2: The UE signalling with the network is governed by the applicable NAS signalling TS. The NAS 3GPP TS for a specific access may restrict the UE possibilities to make requests compared to what is stated above.

Upon receipt of the request from the SMF, the PCF shall check the set of services the user is allowed to access. If the user is not allowed to access AF session based services, the PCF shall check whether the user is allowed to request resources for services not known to the PCF and whether the requested QoS and/or packet filters can be authorized. If the user is not allowed to request resources for services not known to the PCF, the PCF shall reject the request with in an HTTP "403 Forbidden" response message including the "cause" attribute of the ProblemDetails data structure set to "POLICY_CONTEXT_DENIED".

If the PCF authorizes the request from the UE, the PCF shall construct a PCC rule(s) based on the UeInitiatedResourceRequest data structure. For the request to add the filter(s), the PCF shall within the FlowInformation data structure include the assigned packet filter identifier within the "packFiltId" attribute. When the SMF derives the QoS based on the PCC rule, the SMF shall assign a new packet filter identifier for each added packet filter within the QoS rule and keep the mapping between the packet filter identifier for the packet filter within the PCC rule and QoS rule.

The PCF shall perform the QoS authorization for the new created or modified PCC rules if requested by the UE as defined in clause 4.2.6.6.2.

If the PCF detects that the packet filters in the request for new PCC rules received from the SMF is covered by the packet filters of outstanding PCC rules that the PCF is provisioning to the SMF, the PCF may reject the request and indicate the cause for the rejection including the "cause" attribute of the ProblemDetails data structure set to "ERROR_CONFLICTING_REQUEST" in an HTTP "403 Forbidden" response message. If the SMF receives a response message with this code, the SMF shall ignore the PDU session modification that initiated the HTTP request as specified in 3GPP TS 24.501[20] clause 6.3.2.5.

If the PCF does not accept one or more of the traffic mapping filters provided by the SMF in an HTTP Request (e.g. because the PCF does not allow the UE to request enhanced QoS for services not known to the PCF), the PCF shall reject the request and indicate the cause for the rejection including the "cause" attribute of the ProblemDetails data structure set to "ERROR_TRAFFIC_MAPPING_INFO_REJECTED" in an HTTP "403 Forbidden" response message. If the SMF receives an HTTP response with this code, the SMF shall reject the PDU session modification that initiated the HTTP request.

The PCF shall not combine a rejection with provisioning of PCC rule operations in the same HTTP response.

4.2.4.18 Trace Control

When there is the requirement to activate tracing the SMF may provide trace control parameters within the "traceReq" attribute to the PCF via the Npcf_SMPolicyControl_Update service operation. The update service operation may also indicate the update or deactivation of the trace session to the PCF.

4.2.4.19 Negotiation of the QoS flow for IMS signalling

When UE initiates a resource modification request, if the SMF includes the "qosFlowUsage" attribute containing "IMS_SIG" within SmPolicyUpdateContextData data structure and the PCF accepts that a QoS flow dedicated to IMS signalling shall be used, the PCF shall return the "qosFlowUsage" containing "IMS_SIG" value within the SmPolicyDecision data structure. The provided PCC rules shall have the 5QI applicable for IMS signalling.

4.2.4.20 Notification about Service Data Flow QoS target enforcement

When the SMF gets the knowledge that for one or more QoS Flows:

– the GBR QoS targets cannot be guaranteed; or

– the GBR QoS targets can be guaranteed again;

the SMF shall inform the PCF that the GBR QoS targets cannot be guaranteed or can be guaranteed again for the PCC rules bound to the QoS flows.

The SMF gets the knowledge that the GBR QoS targets cannot be guaranteed or can be guaranteed again for the QoS flow(s) as follows:

– upon receiving a notification from the NG-RAN that the GFBR can no longer be guaranteed or can be guaranteed again as defined clause 5.2.2.3.1 of 3GPP TS 29.502 [22]; or

– during a handover, a QoS Flow which is listed as transferred QoS Flow received from the AMF as defined clause 5.2.2.3.1 of 3GPP TS 29.502 [22] can be interpreted as a notification that GFBR can be guaranteed again if the SMF has received a notification from the source NG-RAN that the GFBR can no longer be guaranteed but does not receive an explicit notification that the GFBR can no longer be guaranteed for that QoS Flow from the Target NG-RAN within a configured time as previous bullet.

The SMF shall send an HTTP POST request to the PCF with an SmPolicyUpdateContextData data structure, including the "QOS_NOTIF" within "repPolicyCtrlReqTriggers" attribute and the "qncReports" attribute. In each QosNotificationControlInfo data structure, the SMF shall include the indication that the GBR QoS targets cannot be guaranteed or the GBR QoS targets can be guaranteed again within the "notifType" attribute and affected PCC rule identifiers within the "refPccRuleIds" attribute.

If the "AuthorizationWithRequiredQoS" feature as defined in clause 5.8 is supported, the SMF shall also include the reference to the QosData data structure for the Alternative QoS parameter set corresponding to the reference to the matching alternative QoS profile within the "altQosParamId" attribute if the SMF additionally receives the reference to the matching Alternative QoS Profile which the NG-RAN can guarantee when the NG-RAN indicates the GBR QoS targets cannot be guaranteed. When the SMF additionally receives an indication that lowest priority Alternative QoS Profile cannot be fulfilled from the NG-RAN the SMF shall omit the "altQosParamId" attribute to indicate that that the lowest priority alternative QoS profile could not be fulfilled either. When the "DisableUENotification" feature is supported, if the corresponding PCC rule does not include the "disUeNotif" attribute set to true, the SMF shall also send the fulfilled QoS profile or Alternative QoS Profile to the UE as defined in clause 5.2.2.3.1.1 of 3GPP TS 29.518 [36], if applicable.

If the affected PCC rule was provisioned with a content version, the SMF shall include the "contVers" attribute defined in the QosNotificationControlInfo data structure for those corresponding PCC rules. The SMF may include more than one content version in the "contVers" attribute for the same PCC rule within the corresponding QosNotificationControlInfo instance included in the "qncReports" attribute (e.g. the SMF has combined multiple PCC rule versions enforcement into one QoS flow operation).

When the "AuthorizationWithRequiredQoS" and the "AltQoSProfilesSupportReport" features as defined in clause 5.8 are supported, and the PCF included during PCC rule provisioning the "refAltQosParams" attribute for the concerned PCC rule(s), if the SMF:

– receives the indication that the GBR QoS targets cannot be guaranteed, as specified in 3GPP TS 38.413 [54]; and

– does not receive a matching Alternative QoS Profile the NG-RAN can guarantee or the indication that the lowest priority Alternative QoS profile cannot be fulfilled, as specified in 3GPP TS 38.413 [54];

then the SMF may determine that Alternative QoS Profiles are not supported by the NG-RAN where the UE is currently located and include within the QosNotificationControlInfo data structure the "altQosNotSuppInd" attribute set to true. When Alternative QoS profiles are supported by the NG-RAN where the UE is currently located, the SMF may omit the "altQosNotSuppInd" attribute or set it to false.

When the PCF receives the HTTP POST request, it shall acknowledge the request by sending a "200 OK" response to the SMF and then notify the AF as defined in 3GPP TS 29.514 [17], clause 4.2.5.4.

4.2.4.21 Session Rule Error Report

If the "SessionRuleErrorHandling" feature is supported and if the installation of one or more session rules fails using the procedure as defined in clauses 4.2.2.1 or 4.2.4.1 or the PCF provisioned one or more session rules as defined in clause 4.2.3.1 but enforcement of the session Rule was unsuccessful (e.g. session-AMBR is rejected by the AMF in the roaming scenario, and the SMF determines that the PDU session is kept, the SMF shall include the "sessRuleReports" attribute for the affected session rules to report the failure within the SmPolicyUpdateContextData data structure. Within each SessionRuleReport instance, the SMF shall identify the failed session rule(s) by including the affected session rules within the "ruleIds" attribute, identify the failed reason code by including a "sessRuleFailureCode" attribute, and shall include rule status within the "ruleStatus" attribute with the value as described below.

If the installation of one or more new session rules fails, the SMF shall set the "ruleStatus" to INACTIVE.

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

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.

If a session rule was successfully installed, but can no longer be enforced by the SMF:

– If the "ImmediateTermination" feature is supported, and based on operator’s policy, the SMF shall evaluate whether the PDU session can be kept. If the SMF determines to terminate the PDU session immediately, the SMF shall trigger the deletion of the SM Policy Association as described in clauses 4.2.5, otherwise the SMF shall set the "ruleStatus" attribute to INACTIVE.

– If the the "ImmediateTermination" feature is not supported, the SMF shall set the "ruleStatus" attribute to INACTIVE.

NOTE: When the PCF receives "ruleStatus" set to INACTIVE, the PCF does not need to request the SMF to remove the inactive session rule.

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

4.2.4.22 Request the termination of SM Policy association

If "RespBasedSessionRel" feature is supported, PCF may request the PDU session termination upon receiving a POST message from the SMF (e.g. when usage quota reached). In this case, the PCF shall include the "relCause" attribute within the SmPolicyDecision data structure of the response to the POST message.

After the receipt of a successful HTTP POST response from the PCF containing the "relCause" attribute within the SmPolicyDecision data structure, the SMF 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].

4.2.4.23 Reporting of TSC user plane node management information and port management information

If the feature "TimeSensitiveNetworking" or "TimeSensitiveCommunication" is supported and the "TSN_BRIDGE_INFO" policy control request trigger is provisioned in the SMF, when new TSC user plane node information is available the SMF requests to update the SM Policy Association and provides to the PCF information on the conditions that have been met.

The Policy Control Request Trigger condition "TSN_BRIDGE_INFO" is met when:

a. the SMF detects new TSC user plane node ports which supports exchange of Port Management Information Containers. The SMF shall send to the PCF, if available:

– the DS-TT port number encoded in the "dsttPortNum" attribute allocated by the UPF;

– the TSC user plane node Id received from the UPF encoded in the "bridgeId" attribute;

– the MAC address of the DS-TT port received from the UE encoded in the "dsttAddr" attribute; and

– the UE-DS-TT residence time if received from the UE encoded in the "dsttResidTime" attribute,

within the SmPolicyUpdateContextData structure encoded in the "tsnBridgeInfo" attribute of the TsnBridgeInfo data type; and/or

b. when the SMF receives a UMIC from the TSC user plane node functionality of the UPF/NW-TT and/or a PMIC from the DS-TT port and/or one or more PMIC(s) in the corresponding one or more NW-TT ports. The SMF shall transparently forward to the PCF the UMIC encoded within the "tsnBridgeManCont" attribute and/or the DS-TT PMIC encoded within the "tsnPortManContDstt" attribute and/or the one or more NW-TT PMIC(s) encoded within the "tsnPortManContNwtts" attribute within the SmPolicyUpdateContextData structure.

For IP type of PDU sessions, the UE IP address of the PDU session received within the "ipv4Address" or "ipv6AddressPrefix" attribute, as described in clause 4.2.2.2 and 4.2.4.2 (reported with trigger "UE_IP_CH") is used as identifier of the PDU session related to the reported TSC user plane node information.

For Ethernet type of PDU sessions (IEEE TSN and other time sensitive communications than TSN) the MAC address of the DS-TT port received within the "dsttAddr" attribute is used as identifier of the PDU session related to the reported TSC user plane node information.

4.2.4.24 Notification about Service Data Flow QoS Monitoring

When the SMF gets the information about any one of the following items for one or more SDFs from the UPF:

– uplink packet delay(s);

– downlink packet delay(s); and/or

– round trip delay(s);

and the "QOS_MONITORING" policy control request trigger was provisioned, then SMF shall inform the PCF for the impacted PCC rules.

The SMF shall send an HTTP POST request to the PCF with an SmPolicyUpdateContextData data structure, including the "QOS_MONITORING" within "repPolicyCtrlReqTriggers" attribute and the "qosMonReports" attribute. In each QosMonitoringReport data structure, the PCF shall include:

– one or two uplink packet delays within the "ulDelays" attribute; and/or

– one or two downlink packet delays within the "dlDelays" attribute; and/or

– one or two round trip packet delays within the "rtDelays" attribute; and

– affected PCC rule identifiers within the "refPccRuleIds" attribute.

4.2.4.25 Access traffic steering, switching and splitting support

If "ATSSS" feature defined in clause 5.8 is supported and the PCF has previously provisioned the AC_TY_CH policy control request trigger, when the UE requests to:

– add an access to an already established MA PDU session (i.e. registers to another acess), the SMF shall, within the SmPolicyUpdateContextData data structure, include the "AC_TY_CH" within the "repPolicyCtrlReqTriggers" attribute and include the additional Access type and the additional RAT type if available within the "addAccessInfo" attribute.

– release an access from an already established MA PDU session (i.e. deregisters from one access but remains registered on the other access), the SMF shall, within the SmPolicyUpdateContextData data structure, include the "AC_TY_CH" within the "repPolicyCtrlReqTriggers" attribute and include the released access type and the released RAT type if available within the "relAccessInfo" attribute.

When the PCF receives the request from the SMF indicating the addition of Access Type or removal of Access Type, 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.4.26 Policy decision error handling

4.2.4.26.1 Policy decision types and condition data error handling

If the "PolicyDecisionErrorHandling" feature is supported and the "ExtPolicyDecisionErrorHandling" feature is not supported, and one or more policy decision types (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 PCC rules or session rule is provisioned using the procedure as defined in clauses 4.2.2.1, 4.2.3.1 or 4.2.4.1 but the storage was unsuccessful (e.g. the policy decision could not be successfully stored due to a limitation of resources at the SMF), or because there are semantical inconsistencies in the provided data, the SMF shall include the "policyDecFailureReports" attribute to indicate the type(s) of the failed policy decisions and/or condition data within the SmPolicyUpdateContextData data structure.When the PCF receives the above report, the PCF shall consider all the instances of the policy decisions and/or condition data which are not referred by any PCC rule and/or session stored at the SMF and indicated by the PolicyDecisionFailureCode data type are removed from the SMF.

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

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

If the "ExtPolicyDecisionErrorHandling" feature is supported and one or more policy decision types (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 PCC rules or session rules is provisioned using the procedure as defined in clauses 4.2.2.1, 4.2.3.1 or 4.2.4.1, and/or other SM policy decisions (e.g. the SMF receives policy control request triggers and applicable additional information) but the SMF detects the received policy decision cannot be enforced (e.g. because semantical inconsistencies in the provided data), and the SMF determines that the PDU session can be kept, the SMF shall within the SmPolicyUpdateContextData data structure include the "policyDecFailureReports" attribute to indicate a failure in the provided policy decision types and/or condition data not referred by any PCC rules or session rules and/or in other SM policy decisions, and may include the "invalidPolicyDecs" attribute to indicate the failed policy decision types and/or condition data not referred by any PCC rules or session rules and/or other SM policy decisions.

When the PCF receives the above report, the PCF shall consider:

– all the instances of the policy decisions and/or condition data which are not referred by any PCC rule and/or session stored at the SMF and indicated by the PolicyDecisionFailureCode data type are removed from the SMF; and

– for the other policy decisions:

a. All the new failed policy decisions provisioned are not installed in the SMF.

b. All the modified policy decisions shall remain unmodified in the SMF.

c. All the removed policy decisions provided in the request message are deleted in the SMF.

NOTE: 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.4.27 Policy Control for DDN Events

If the feature "DDNEventPolicyControl" or "DDNEventPolicyControl2" is supported, and if the PCF has previously provisioned "DDN_FAILURE" policy control request trigger, the SMF shall send the PCC rule request when it receives an event subscription for DDN Failure event including the traffic descriptors. The SMF shall send an HTTP POST request to the PCF with an SmPolicyUpdateContextData data structure, including the "DDN_FAILURE" within "repPolicyCtrlReqTriggers" attribute and include one or more traffic descriptor(s) in the "trafficDescriptors" attribute within the SmPolicyUpdateContextData structure for policy evaluation. Upon reception of the HTTP POST message:

– if the PCF determines that there is an existing PCC rule for the traffic detection of DDD Status event which has the same traffic descriptor(s) as the new request one, the PCF shall update the existing PCC rule for traffic detection of DDD Status event by including both the "DDN_FAILURE" and "DDD_STATUS" values within the "notifCtrlInds" attribute of the "ddNotifCtrl" attribute if the "DDNEventPolicyControl" feature is supported or of the "ddNotifCtrl2" attribute if the "DDNEventPolicyControl2" feature is supported to indicate both the DDN Failure and DDD Status event detection;

– otherwise the PCF shall make a new PCC rule by including the reported traffic descriptors within the "flowInfos" attribute, setting a lower value to the "precedence" attribute and including the downlink data notification control information within the "ddNotifCtrl" attribute if the "DDNEventPolicyControl" feature is supported or within the "ddNotifCtrl2" attribute if the "DDNEventPolicyControl2" feature is supported and setting the other PCC rule information to the same values as in an existing PCC rule that previously matched the traffic. Within the DownlinkDataNotificationControl or DownlinkDataNotificationControlRm data type, the PCF shall include the "DDN_FAILURE" value within the "notifCtrlInds" attribute to indicate the DDN Failure event detection. When the new PCC rule has to be bound to the default QoS flow, the PCF shall include the "defQosFlowIndication" attribute set to true within the QosData data structure to which the PCC rule refers. From now on, the PCF needs to keep new PCC rule for event detection fully synchronized with the existing PCC rule that previously matched the traffic for all other policy and charging control settings to ensure the same user experience and traffic treatment according to the operator policy.

If the feature "DDNEventPolicyControl" or the "DDNEventPolicyControl2" is supported, and if the PCF has previously provisioned "DDN_DELIVERY_STATUS" policy control request trigger, the SMF shall send the PCC rule request when it receives an event subscription for DDD Status event including the traffic descriptors. The SMF shall send an HTTP POST request to the PCF with an SmPolicyUpdateContextData data structure, including the "DDN_DELIVERY_STATUS" within "repPolicyCtrlReqTriggers" attribute, include one or more traffic descriptor(s) in the "trafficDescriptors" attribute and the type(s) of notification in the "typesOfNotif" attribute within the SmPolicyUpdateContextData structure for policy evaluation. Upon reception of the HTTP POST message:

– if the PCF determines that there is an existing PCC rule for traffic detection of DDN Failure event which has the same traffic descriptor(s) as the new request one, the PCF shall update the existing PCC rule for traffic detection of DDN Failure event by including both the "DDN_FAILURE" and "DDD_STATUS" values within the "notifCtrlInds" attribute and the type(s) of notifications within the "typesOfNotif" attribute of the "ddNotifCtrl" attribute if the "DDNEventPolicyControl" feature is supported or of the "ddNotifCtrl2" attribute if the "DDNEventPolicyControl2" feature is supported to indicate both the DDN Failure and DDD Status event detection;

– if the PCF determines that there is an existing PCC rule for the policy and charging control which has the same traffic descriptor(s) as the new request one, the PCF shall update the existing PCC rule by including the downlink data notification control information within the "ddNotifCtrl" attribute if the "DDNEventPolicyControl" feature is supported or within the "ddNotifCtrl2" attribute if the "DDNEventPolicyControl2" feature is supported to indicate the DDD Status event detection. Within the DownlinkDataNotificationControl or DownlinkDataNotificationControlRm data type, the PCF shall include the "DDD_STATUS" value within the "notifCtrlInds" attribute and the type(s) of notifications within the "typesOfNotif" attribute;otherwise the PCF shall make a PCC rule by including the reported traffic descriptors within the "flowInfos" attribute, setting a lower value to the "precedence" attribute and including the downlink data notification control information within the "ddNotifCtrl" attribute if the "DDNEventPolicyControl" feature is supported or within the "ddNotifCtrl2" attribute if the "DDNEventPolicyControl2" feature is supported to indicate the DDD Status event detection and setting the other PCC rule information to the same values as in an existing PCC rule that previously matched the traffic. Within the DownlinkDataNotificationControl or DownlinkDataNotificationControlRm data type, the PCF shall include the "DDD_STATUS" value within the "notifCtrlInds" attribute and the type(s) of notifications within the "typesOfNotif" attribute to indicate that DDN Status event detection is required. When the new PCC rule has to be bound to the default QoS flow, the PCF shall include the "defQosFlowIndication" attribute set to true within the QosData data structure to which the PCC rule refers. From now on, the PCF needs to keep new PCC rule for event detection fully synchronized with the existing PCC rule that previously matched the traffic for all other policy and charging control settings to ensure the same user experience and traffic treatment according to the operator policy.

If the feature "DDNEventPolicyControl2" is supported, when the SMF receives a request to cancel a subscription of the DDN Failure or DDD status event and if the PCF has previously provisioned "DDN_FAILURE_CANCELLATION" and "DDN_DELIVERY_STATUS_CANCELLATION policy control request trigger, the SMF shall send an HTTP POST request to the PCF with an SmPolicyUpdateContextData data structure, including the "DDN_FAILURE_CANCELLATION" or "DDN_DELIVERY_STATUS_CANCELLATION" within "repPolicyCtrlReqTriggers" attribute respectively and include the rule identifier of the PCC rule which is used for traffic detection of event within the "pccRuleId" attribute. Upon reception of the HTTP POST message:

– If the PCC rule corresponding to the received PCC rule identifier is only used for the traffic detection of DDN failure or DDD Status respectively, the PCF shall remove the PCC rule locally and request the SMF to remove it too.

– If the PCC rule corresponding to the received PCC identifier is used for the traffic detection of both DDN failure and DDD status events, the PCF shall update the PCC rule by removing the downlink data notification control information for DDN failure or DDD status respectively from the PCC rule. In order to do that, within the DownlinkDataNotificationControlRm data type of the "ddNotifCtrl2" attribute, the PCF shall omit the "DDN_FAILURE" or "DDD_STATUS" within the "notifCtrlInds" attribute respectively. If the data notification control information for the DDD status is omitted, the PCF shall aslo include the "typesOfNotif" attribute set to NULL.

– If the PCC rule corresponding to the receied PCC rule identifier is also used for the policy and charging control to the service data flow besides the traffic detection of the DDN failure or DDD status event, the PCF shall update the PCC rule by removing the downlink data notification control information from the PCC rule. In order to do that, the PCF shall include the "ddNotifCtrl2" attribute set to NULL.

NOTE: The "ddNotifCtrl" attribute is used to contain the downlink data notification control information if the "DDNEventPolicyControl" feature is supported; while the "ddNotifCtrl2" attribute is used to contain the downlink data notification control information if the "DDNEventPolicyControl2" feature is supported.

When the SMF receives the new or updated PCC rule within the response message from the PCF, SMF shall perform the DDD Status and/or DDN Failure event based on the downlink data notification control information within the PCC rue as follows:

– If the downlink data notification control information indicates that the detection of DDD Status event and buffered notification type is required, the SMF shall derive a PDR and a related FAR as defined in clause 5.28 of 3GPP TS 29.244 [13] to request the UPF to report an event of the first buffered downlink data packet identified by the PDR. When the SMF receives the corresponding report, the SMF shall send the notification to the NEF as defined in clause 4.2.2.2 of 3GPP TS 29.508 [12].

– If the downlink data notification control information indicates that the detection of DDD Status event and transmitted notification type is required, the SMF shall detect event and send the notification as defined in clause 4.2.2.2 of 3GPP TS 29.508 [12].

– If the downlink data notification control information indicates that the detection of DDN Failure event and/or DDD Status event and discarded notification type is required, the SMF shall derive a PDR and a related FAR as defined in clause 5.28 of 3GPP TS 29.244 [13] to request the UPF to report an event of the first discarded downlink data packet identified by the PDR. When the SMF receives the corresponding report, the SMF shall send the notification to the AMF as defined in clause 5.2.2.5.1 of 3GPP TS 29.502 [22] and/or send the notification to the NEF as defined in clause 4.2.2.2 of 3GPP TS 29.508 [12] respectively.

4.2.4.28 Network slice related data rate policy control

When an Npcf_SMPolicyControl_Update request that requires a change of the authorized Session-AMBR and/or MBR update(s) for PCC Rule(s) corresponding to GBR service data flow(s) is received, the PCF may check if the S-NSSAI to which the received request relates 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.