4.2.2 Npcf_SMPolicyControl_Create Service Operation

29.5123GPP5G SystemRelease 18Session Management Policy Control ServiceStage 3TS

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

4.2.2.1 General

The Npcf_SMPolicyControl_Create service operation provides means for the SMF to request the creation of a corresponding SM Policy Association with PCF.

The Session Management procedures of the SMF and related policies are defined in 3GPP TS 23.501 [2], 3GPP TS 23.502 [3] and 3GPP TS 23.503 [6].

The following procedures using the Npcf_SMPolicyControl_Create service operation are supported:

– Request the creation of a corresponding SM Policy Association with the PCF.

– Provisioning of PCC rules.

– Provisioning of policy control request triggers.

– Provisioning of charging related information for a PDU session.

– Provisioning of revalidation time.

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

– Policy provisioning and enforcement of authorized default QoS.

– Provisioning of PCC rule for Application Detection and Control.

– 3GPP PS Data Off Support.

– IMS Emergency Session Support.

– Request Usage Monitoring Control.

– Access Network Charging Identifier report.

– Request for the successful resource allocation notification.

– Provisioning of IP Index Information.

– Negotiation of the QoS flow for IMS signalling.

– PCF resource cleanup.

– Access traffic steering, switching and splitting support.

– DNN Selection Mode Support.

– Detection of the SM Policy Association enabling Time Sensitive Communications and Time Synchronization.

– Support of Dual Connectivity end to end redundant User Plane paths.

– User Plane Remote Provisioning of UE SNPN Credentials in Onboarding Network.

– Network slice related data rate policy control.

– Request of Presence Reporting Area Change Report.

When the EMDBV feature defined in clause 5.8 is supported by both the PCF and the SMF, the PCF shall use the extMaxDataBurstVol attribute instead of the maxDataBurstVol attribute to signal maximum data burst volume values higher than 4095 Bytes.

When the EMDBV feature is supported by the PCF but not supported by the SMF and the PCF needs to signal maximum data burst volume values higher than 4095 Bytes, the PCF shall use the maxDataBurstVol attribute set to 4095 Bytes.

For values lower than or equal to 4095 Bytes, the PCF shall use the maxDataBurstVol attribute.

NOTE: Maximum data burst volume values are sent by the PCF in responses to the SMF or in an SM Policy Association Update request i.e. after feature negotiation, so the PCF knows whether the SMF supports the EMDBV feature.

4.2.2.2 SM Policy Association establishment

Figure 4.2.2.2-1: SM Policy Association establishment

When the NF service consumer receives the Nsmf_PDUSession_CreateSMContext Request as defined in clause 5.2.2.2 of 3GPP TS 29.502 [22], if the NF service consumer was requested not to interact with the PCF, the NF service consumer shall not interact with the PCF. Otherwise, the NF service consumer shall send an HTTP POST request to the PCF to create an "Individual SM Policy" resource as described in step 1 of figure 4.2.2.2-1.

NOTE 1: The decision to not interact with the PCF applies for the entire lifetime of the PDU session.

NOTE 2: The indicator to not interact with the PCF is configured in the UDM. It is delivered by the UDM to the NF service consumer within the Charging Characteristics using the Session Management Subscription Data Retrieval service operation as described in 3GPP TS 29.503 [34]. The indicator is operator specific, therefore it can only be used in non-roaming and home routed roaming cases.

The NF service consumer shall include the "SmPolicyContextData" data structure in the payload body of the HTTP POST request in order to request the creation of a representation of the "Individual SM Policy" resource as described below.

The NF service consumer shall include (if available) in the "SmPolicyContextData" data structure:

– SUPI of the user within the "supi" attribute;

– PDU Session Id within the "pduSessionId" attribute;

– DNN within the "dnn" attribute;

– DNN selection mode within the "dnnSelMode" attribute, if the "DNNSelectionMode" feature is supported;

– URL identifying the recipient of SM policies update notifications within the "notificationUri" attribute;

– PDU Session Type within the "pduSessionType" attribute;

– PEI within the "pei" attribute;

– Internal Group Id(s) within the "interGrpIds" attribute;

– type of access within the "accessType" attribute;

NOTE 3: In this Release, for SNPN-enabled UE registered in the SNPN, direct access to the SNPN is specified for 3GPP access only.

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

– the combination of additional access type and RAT type within the "addAccessInfo" attribute, if the ATSSS feature is supported;

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

– 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 4: 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 5: 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.

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

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

– the number of supported packet filters for signalled QoS rules within the "numOfPackFilter" attribute;

– the online charging status within the "online" attribute;

– the offline charging status within the "offline" attribute;

– the charging characteristics within the "chargingCharacteristics" attribute;

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

– the address of the network entity performing charging within the "chargEntityAddr" attribute;

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

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

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

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

– the S-NSSAI corresponding to the network slice to which the PDU session is allocated within the "sliceInfo" attribute;

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

– the MA PDU session indication within the "maPduInd" attribute, if the "ATSSS" feature is supported;

– the ATSSS capability within the "atsssCapab" attribute, if the "ATSSS" feature is supported;

– the identifier of the serving network (the PLMN Identifier or the SNPN Identifier) within the "servingNetwork" attribute;

NOTE 7: The SNPN Identifier consists of the PLMN Identifier and the NID.

– one or more framed routes within the "ipv4FrameRouteList" attribute for IPv4 and/or one or more framed routes within the "ipv6FrameRouteList" attribute;

NOTE 8: When both, the UDM subscribed framed routes and the DN-AAA authorized framed routes are available in the NF service consumer, the NF service consumer includes the DN-AAA authorized framed routes. If the UDM or DN-AAA updates the framed routes during the lifetime of the PDU Session, the NF service consumer releases the PDU Session as defined in clause 4.2.5.2.

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

– when the "PvsSupport" feature is supported, the onboarding indication within the "onboardInd" attribute and the Provisioning Server address(es) within the "pvsInfo" attribute;

– when the "SatBackhaulCategoryChg" feature is supported, the satellite backhaul category within the "satBackhaulCategory" attribute;

NOTE 9: When the "satBackhaulCategory" attribute is not present, non-satellite backhaul applies.

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

– trace control and configuration parameters information within the "traceReq" 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" consumed by the NF service consumer, included within the "nwdafDatas" attribute.

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

NOTE 10: The "ipDomain" attribute is helpful when within a network slice, there are several separate IP address domains, with SMF/UPF(s) that allocate Ipv4 IP addresses out of the same private address range to UE PDU Sessions. The same IP address can thus be allocated to UE PDU sessions served by SMF/UPFs in different IPv4 address domains. If one PCF controls several SMF/UPFs in different IP address domains, the UE IP address is thus not sufficient for the AF session binding procedure, as described in 3GPP TS 29.514 [17]. The SMF assists the PCF in the session binding supplying an "ipDomain" attribute denoting the IPv4 address domain identity of the allocated UE IPv4 address.

When the PCF receives the HTTP POST request from the NF service consumer, the PCF shall make a policy authorization based on the information received from the NF service consumer and, if available, information received from the AMF, the CHF, the AF, the UDR and/or the NWDAF and operator policies pre-configured at the PCF. If the policy authorization is successful, the PCF shall create a new resource, which represents a new "Individual SM Policy" instance, addressed by a URI as defined in clause 5.3.3.2 and containing a PCF created resource identifier. The PCF shall respond to the NF service consumer with an HTTP 201 Created response, including:

– a Location header field containing the URI of the created resource; and

– a response body providing the session management related policies, e.g. provisioning of PCC rules as defined in clause 4.2.6.2, provisioning of policy control request triggers as defined in clause 4.2.6.4.

The NF service consumer shall use the URI received in the Location header in subsequent requests to the PCF to refer to the created "Individual SM Policy" resource.

If the PCF received the 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 as described in 3GPP TS 29.513 [7].

It the PCF received a "traceReq" attribute in the HTTP POST request from the SMF, it shall perform trace procedures as defined in 3GPP TS 32.422 [24].

If errors occur when processing the HTTP POST request, the PCF shall apply the error handling procedures specified in clause 5.7.

If the user information received within the "supi" attribute is unknown, the PCF shall reject the request with an HTTP "400 Bad Request" response message including the "cause" attribute of the ProblemDetails data structure set to "USER_UNKNOWN".

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

If the NF service consumer receives an HTTP response with the above error codes, the NF service consumer shall reject the PDU session establishment procedure that initiated the HTTP POST Request.

If the PCF, based on local configuration and/or operator policies, denies the creation of the Individual SM Policy resource, the PCF may 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". At reception of this error code and based on configured failure actions, the NF service consumer may reject or allow, by applying local policies, the PDU session establishment.

If the "SamePcf" feature as defined in clause 5.8 is supported, when the PCF determines that the same PCF shall be selected for the SM Policy associations to the same UE ID, S-NSSAI and DNN combination in the non-roaming or home-routed scenario and there is no SM Policy association for the UE ID, S-NSSAI and DNN combination, the PCF, after determining whether the BSF supports the "SamePcf" or the "ExtendedSamePcf" feature as described in 3GPP TS 29.521 [39], shall request the BSF to check if there is an existing PCF binding information for the same UE ID, S-NSSAI and DNN combination registered by other PCF(s) as defined in clause 4.2.2.2 of 3GPP TS 29.521 [39]. If the PCF receives the from the BSF "403 Forbidden" status code with the "cause" attribute of the ProblemDetails data structure set to "EXISTING_BINDING_INFO_FOUND" and the FQDN or description of IP endpoints of the Npcf_SMPolicyControl service of the existing PCF (i.e. that handles SM Policy association(s) to the same UE ID, S-NSSAI and DNN combination) within the "pcfSmFqdn" attribute or the "pcfSmIpEndPoints" attribute of the BindingResp data structure respectively as defined in clause 4.2.2.2 of 3GPP TS 29.521 [39], the PCF shall reply to the SMF with an HTTP "308 Permanent Redirect" error response and the Location header containing a URI as defined in clause 5.3.2.2, with the FQDN or IP endpoint of this PCF’s Npcf_SMPolicyControl service as {apiRoot}. Upon reception of the response, the NF service consumer shall initiate a new HTTP POST request based on the returned URI.

The forwarding of the Origination Time Stamp parameter shall apply as described hereafter, if the NF service consumer supports the detection and handling of late arriving requests as specified in clause 5.2.3.3 of 3GPP TS 29.502 [22] and the procedure is enabled by the operator. If the NF service consumer receives a request to create an SM Context or a PDU session context, which includes the 3gpp-Sbi-Origination-Timestamp header as defined in clause 5.2.3.2, the NF service consumer shall forward this header to the PCF as HTTP custom header. See also clause 4.2.7 for the handling at the PCF, when the PCF receives the 3gpp-Sbi-Origination-Timestamp header.

4.2.2.3 Provisioning of charging related information for PDU session

4.2.2.3.1 Provisioning of Charging Addresses

The PCF may provide the SMF with the charging information, i.e. the CHF address(es), and if available, the associated CHF instance ID(s) and CHF set ID(s), during the initial interaction with the SMF defining the charging function respectively based on the operator policy. In this case, the PCF may retrieve the CHF addresses, and if available, the associated CHF instance ID(s) and CHF set ID(s) as follows:

– The PCF receives it from the UDR as part of the Policy Data Subscription information, as defined in clause 5.2.10 of 3GPP TS 29.519 [15].

– It is locally configured in the PCF based on operator policies.

– The PCF discovers it by interacting with the NRF, as described in clause 6.1 of 3GPP TS 32.290 [30].

In order to provision the CHF information to the SMF, the PCF shall include the "chargingInfo" attribute containing the charging information within the SmPolicyDecision data structure.

Within the ChargingInformation data structure, both the primary CHF address, within the "primaryChfAddress" attribute, and secondary CHF address, within the "secondaryChfAddress" attribute, shall be provided simultaneously when the feature "CHFsetSupport" is not supported. When the feature "CHFsetSupport" is supported, the PCF shall include the "secondaryChfAddress" attribute if available (i.e. if previously retrieved from the UDR, locally configured in the PCF or discovered from the NRF).

When the CHF supports redundancy based on NF Set concepts as described in 3GPP TS 29.500 [4], the required charging information consists of CHF address, encoded within the"primaryChfAddress" attribute, CHF instance, encoded within the "primaryChfInstanceId" attribute, and primary CHF set id, encoded within the "primaryChfSetId". The CHF set information may be also complemented by secondary CHF address, encoded within the "secondaryChfAddress", for backwards compatibility purposes with the primary/secondary redundancy mechanism.These shall overwrite any predefined CHF addresses and associated CHF instance ID and CHF set ID at the SMF.

NOTE: When the feature "CHFsetSupport" is supported by the NF service consumer, it indicates the NF service consumer supports CHF redundancy based on NF Set concepts as described in 3GPP TS 29.500 [4], clause 6.5.3.

Provisioning charging information without PCC rules for charged service data flows shall not be considered as an error, since such PCC rules may be provided later. If the PCF has provided the charging information within the SmPolicyDecision data structure during the initial interaction with the SMF, the PCF shall not modify the charging information in subsequent interactions.

If no charging information is provisioned by the PCF, the SMF shall use the charging information obtained via one of the following procedures, with the precedence order highest to lowest (see 3GPP TS 32.255 [35], clause 5.1.8):

1. UDM provided charging characteristics.

2. NRF based discovery.

3. SMF locally configured charging characteristics.

4.2.2.3.2 Provisioning of Default Charging Method

The default charging method indicates what charging method shall be used for every PCC rule within which the charging method is omitted, i.e. either both the "online" and the "offline" attributes are not provided or only one of them is provided and set to "false" within the ChargingData data structure to which the PCC rule refers. The SMF may have a pre-configured default charging method.

Upon the initial interaction with the PCF, the SMF shall provide the pre-configured default charging method, if available, within the "offline" attribute and/or the "online" attribute, and embedded directly within the SmPolicyContextData data structure of the HTTP POST message sent to the PCF.

The PCF may provide in the response to the received HTTP POST message the default charging method which applies to the PDU session. In order to do so, if offline charging applies, the PCF shall include the "offline" attribute set to "true" within the SmPolicyDecision data structure, or if online charging applies, the PCF shall include the "online" attribute set to "true" within the SmPolicyDecision data structure. The default charging method provided by the PCF shall overwrite any predefined default charging method available at the SMF. If the PCF has provided the default charging method during the initial interaction with the SMF, it shall not modify the default charging method in subsequent interactions.

When the "OfflineChOnly" feature is supported, the PCF may include the "PDU Session with offline charging only" indication as specified in clause 4.2.2.3.3.

NOTE: It is possible that there is no default charging method applied to a PDU session.

4.2.2.3.3 Provisioning of the "PDU Session with offline charging only" indication

If the "OfflineChOnly" feature, specified in clause 5.8, is supported, the PCF may provide in the response to the received HTTP POST message from the SMF the "PDU Session with offline charging only" indication, within the "offlineChOnly" attribute, to signal that the online charging method shall never be configured for any of the PCC Rules activated during the lifetime of the PDU Session, nor provided as the Default Charging Method, as specified in clause 6.4 of 3GPP TS 23.503.

If the "OfflineChOnly" feature, specified in clause 5.8, is supported and the PCF includes the "PDU Session with offline charging only" indication set to "true" in the "offlineChOnly" attribute within the SmPolicyDecision data structure, then the default charging method for the PDU session is offline charging, and the "online" attribute and the "offline" attribute shall not be provisioned by the PCF within the SmPolicyDecision data structure.

NOTE: If the PCF includes the "PDU Session with offline charging only" indication set to "true" in the "offlineChOnly" attribute within the SmPolicyDecision data structure, and the "online" attribute and the "offline" attribute are also provisioned by the PCF within the SmPolicyDecision data structure, then the SMF could ignore the values of the "online" attribute and the "offline" attribute.

4.2.2.4 Provisioning of revalidation time

The PCF may provide within the SmPolicyDecision data structure 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).

The SMF shall start the timer based on the revalidation time and shall trigger a PCC rule request towards the PCF before the indicated revalidation time.

4.2.2.5 Policy provisioning and enforcement of authorized AMBR per PDU session

The SMF shall, if available include either the UDM subscribed Session-AMBR or, if the "DN-Authorization" feature is supported, the DN-AAA authorized Session-AMBR per PDU session within the "subsSessAmbr" attribute in the SmPolicyContextData data structure, as defined in clause 4.2.2.2. When both the UDM subscribed Session-AMBR and the DN-AAA authorized Session-AMBR are available in the SMF, the DN-AAA authorized Session-AMBR shall take precedence over the UDM subscribed Session-AMBR.

In home routed roaming, and if the "VPLMN-QoS-Control" feature is supported, the SMF shall provide the Session-AMBR constraints received from the VPLMN, if available, within the "vplmnQos" attribute.

When the SMF provides the subscribed Session-AMBR to the PCF, the PCF shall authorize the Session-AMBR based on the operator’s policy and, in the home routed scenario, shall ensure that the authorized Session-AMBR value does not exceed the Session-AMBR value provided by the VPLMN, if available. For emergency PDU sessions, the PCF shall behave as specified in clause 4.2.2.9.

NOTE: If the SMF does not provide the Session-AMBR constraints in the VPLMN to the PCF, the PCF considers that no Session-AMBR constrains apply unless operator policies define any.

When network slice data rate policy control applies, the PCF shall authorize the Session-AMBR as described in clause 4.2.6.8.

The PCF shall provision the authorized Session-AMBR to the SMF in the response to the received HTTP POST message, as defined in clauses 4.2.6.3.1 and 4.2.6.3.2.

Upon reception of 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 Session-AMBR for the concerned PDU session.

4.2.2.6 Policy provisioning and enforcement of authorized default QoS

During PDU session establishment, as defined in clause 4.2.2.2, the SMF shall, if available, include the subscribed default QoS within the "subsDefQos" attribute.

In home routed roaming, and if the "VPLMN-QoS-Control" feature is supported, the SMF shall provide the default QoS constraints received from the VPLMN, if available, within the "vplmnQos" attribute.

When the SMF provides the subscribed default QoS to the PCF, the PCF shall authorize the default QoS based on the operator’s policy and, in the home routed scenario, shall ensure that the authorized default QoS contains a 5QI and ARP value, and MBR/GBR value, if applicable, supported by the VPLMN, if available. For emergency PDU sessions, the PCF shall behave as specified in clause 4.2.2.9.

NOTE 1: If the SMF does not provide the default QoS constraints in the VPLMN to the PCF, the PCF considers that no default QoS constrains apply unless operator policies define any.

The PCF shall provision the authorized default QoS to the SMF in the response to the received HTTP POST message, 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 this enforcement of the authorized default QoS for the concerned PDU session.

NOTE 2: If dynamic PCC is not deployed, the SMF can have a DNN based configuration to enable the establishment of a GBR resource type default QoS flow. This configuration contains a standardized GBR 5QI as well as GFBR and MFBR for UL and DL.

NOTE 3: GBR resource type is not applicable to the default QoS flow of a PDU session that is interworking with EPS.

4.2.2.7 Provisioning of PCC rule for Application Detection and Control

If the ADC feature is supported, and the user subscription indicates that application detection and control is required, the PCF may provision PCC rule(s) for application detection and control as defined in clause 4.2.6.2.11 in the response message to the received HTTP POST request from the SMF.

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

4.2.2.8 3GPP PS Data Off Support

When the 3GPP-PS-Data-Off feature, as defined in clause 5.8, is supported, and if the SMF is informed that the 3GPP PS Data Off status of the UE is set to active during the establishment of a PDU session over 3GPP access and/or non-3GPP access, it shall include the "3gppPsDataOffStatus" attribute set to true within the SmPolicyContextData data structure in the HTTP POST message that it sends to the PCF, as defined in clause 4.2.2.2.

If the PCF receives that HTTP POST message with a SmPolicyContextData data structure containing a "3gppPsDataOffStatus" attribute set to true as above and the "accessType" attribute indicating "3GPP_ACCESS", the PCF shall configure the SMF to block any downlink and optionally uplink IP flows that are not related to a service contained in the list of 3GPP PS Data Off Exempt Services, e.g. by not installing any related dynamic PCC rule(s) or by not activating the related predefined PCC rule(s) such as PCC rule(s) with wild-carded service data flow filters. The PCF may also, subject to its normal policies, provide the PCC rule(s) for the service(s) included in the list of 3GPP PS Data Off Exempt Services, as defined in clause 4.2.6.2.1.

The PCF shall subscribe to the "AC_TY_CH" policy control request trigger with the SMF, as defined in clause 4.2.6.4, in order to support this feature, if the PCF determines that the UE is allowed to access the network via non-3GPP access.

NOTE 1: The PCF can be configured with a list of 3GPP PS Data Off Exempt Services per DNN and S-NSSAI. The list of 3GPP PS Data Off Exempt Services for an DNN and S-NSSAI can also be empty, or can allow for any service within that DNN and S-NSSAI, according to operator policy.

NOTE 2: For the PDU session used for IMS services, the 3GPP Data Off Exempt Services are enforced in the IMS domain as specified in 3GPP TS 23.228 [16]. Policies configured in the PCF need to ensure that IMS services are allowed when the 3GPP Data Off status of the UE is set to active, e.g. by treating any service within a well-known IMS DNN as part of the 3GPP PS Data Off Exempt Services.

NOTE 3: The packets transferred over non-3GPP access are unaffected by the 3GPP PS Data Off functionality.

If the "ATSSS" feature, as defined in clause 5.8 is supported, and the PCF receives in the SmPolicyContextData data structure the "maPduInd" attribute, the "3gppPsDataOffStatus" attribute set to true and the"accessType" attribute or the "addAccInfo" attribute set to "3GPP_ACCESS", the PCF shall configure the SMF in such a way that:

– packets for services belonging to the 3GPP PS Data Off Exempt services are forwarded over 3GPP access and non-3GPP access as indicated by the policy for ATSSS Control, as specified in clause 4.2.6.2.17; and

– for downlink and optionally uplink flows not related to a service contained in the list of 3GPP PS Data Off Exempt services, the PCF may configure the SMF to handle the associated traffic only via non-3GPP access, if available, by providing the corresponding ATSSS policy within the related PCC rule, as specified in clause 4.2.6.2.17.

4.2.2.9 IMS Emergency Session Support

A SMF that requests PCC Rules at PDU Session Establishment for an IMS emergency session in a PLMN or an SNPN shall send an HTTP POST message to the PCF, as defined in clause 4.2.2.2, including the "dnn" attribute containing the Emergency DNN. The SMF may include the SUPI, within the "supi" attribute, and if the SUPI is not available or unauthenticated, the SMF shall include the PEI, within the "pei" attribute, the "invalidSupi" attribute set to "true" and an implementation specific value within the "supi" attribute. The SMF may include the rest of the attributes described in clause 4.2.2.2. The SMF may also include the GPSI, if available, within the "gpsi" attribute.

NOTE 1: The SMF will not provide subscribed information (e.g. subscribed default QoS or subscribed Session AMBR) to the PCF when the SUPI is not available, unauthenticated or based on local configuration.

NOTE 2: IMS Emergency services are not supported for SNPN when the UE accesses the SNPN over NWu via a PLMN.

The PCF shall detect that a PDU session is restricted to IMS Emergency services when the "dnn" attribute included in the HTTP POST message received from the SMF includes a data network identifier that matches one of the Emergency DNs from the configurable list. The PCF does not perform in this case subscription check procedures with UDR; it uses instead the locally configured operator policies to make authorization and policy decisions. The PCF:

– shall provision PCC Rules restricting the access to Emergency Services (e.g. P-CSCF(s), DHCP(s), DNS(s) and SUPL(s) addresses), as required by local operator policies, in a response message to the SMF according to the procedures described in clause 4.2.6;

– may provision the authorized QoS that applies to the default QoS flow in the response message to the SMF within the "authDefQos" attribute of a session rule according to the procedures described in clause 4.2.3.6, except for obtaining the authorized QoS upon interaction with the UDR. The value of the "priorityLevel" attribute included within the "arp" attribute shall be assigned 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 sessions). If the "accessType" attribute is set to "3GPP_ACCESS", the values of the "preemptCap" and the "preemptVuln" attributes included within the "arp" attribute shall be assigned as required by local operator policies,

– may provision the authorized Session-AMBR in the response message to the SMF, according to the procedures described in clause 4.2.3.5.

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

4.2.2.10 Request Usage Monitoring Control

If the UMC 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.

4.2.2.11 Access Network Charging Identifier report

During the PDU session establishment procedure, if the Access Network Charging Identifier is within the Uint32 value range, the SMF may provide the access network charging identifier information within the "accNetChId" attribute of the SmPolicyContextData data structure. Within the associated AccNetChId data structure, the SMF shall include the "accNetChaIdValue" attribute containing the Access Network Charging Identifier for the PDU session (i.e., for the default QoS flow) and the "sessionChScope" attribute set to true. The SMF may provide the address of the network entity performing the charging functionality within the "chargEntityAddr" attribute.

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 report of Access Network Charging Identifier(s) in 5GS and EPS interworking scenarios is described in clause B.3.2.3.

If the "AccNetChargId_String" feature is supported by the SMF, and the Access Network Charging Identifier value is longer than Uint32:

– if the SMF doesn’t know if the PCF supports the "AccNetChargId_String" feature, the SMF shall not provide the access network charging identifier information;

– if the SMF knows the PCF supports the feature "AccNetChargId_String", the SMF shall encode the access network charging identifier within "accNetChargIdString" attribute.

4.2.2.12 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.2.13 Request of Presence Reporting Area Change Report

If the PRA or ePRA feature, as 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.2.14 Provisioning of IP Index Information

If the PDU session type received within the "pduSessiontype" attribute is "IPV4" or "IPV6" or "IPV4V6", and no corresponding IP address/prefix is received, the PCF may include within the SmPolicyDecision data structure the IP index information within the "ipv4Index" attribute, for IPv4 address allocation, and/or the "ipv6Index" attribute, for IPv6 address allocation, based on the user’s subscription information retrieved from the UDR and operator’s policy.

The SMF may use this IP index information to assist in selecting how the IP address is to be allocated when multiple allocation methods or multiple instances of the same method are supported.

4.2.2.15 Negotiation of the QoS flow for IMS signalling

If the SMF includes the "qosFlowUsage" attribute required for the default QoS flow within the SmPolicyContextData data structure during the PDU session establishment procedure, the PCF shall provide the "qosFlowUsage" attribute back in the response with the authorized usage.

If during PDU session establishment procedure, the SMF includes the "IMS_SIG" value within the "qosFlowUsage" attribute and the PCF accepts that default QoS flow is dedicated to IMS signalling, the PCF shall within the SmPolicyDecision data structure include the "IMS_SIG" value within the "qosFlowUsage" attribute. In this case, the PCF shall restrict the QoS flow to only be used for IMS signalling as specified in 3GPP TS 23.228 [16] by applying the applicable 5QI for IMS signalling.

If the SMF include the "IMS_SIG" value within the "qosFlowUsage" attribute of the SmPolicyContextData data structure, but the PCF does not include the "IMS_SIG" within the "qosFlowUsage" attribute of SmPolicyDecision data structure, the PCC Rules provided by the PCF shall have a 5QI value different from the 5QI value for the IMS signalling.

4.2.2.16 PCF resource cleanup

In the Npcf_SMPolicyControl_Create service operation, the SMF as NF service consumer may provide SMF Id in "smfId" attribute and recovery timestamp in "recoveryTime" attribute. The PCF may use the "smfId" attribute to supervise the status of the SMF as described in clause 5.2 of 3GPP TS 29.510 [29] and perform necessary cleanup upon status change of the SMF later, and/or both the "smfId" attribute and the "recoveryTime" attribute in cleanup procedure as described in clause 6.4 of 3GPP TS 23.527 [33].

4.2.2.17 Access traffic steering, switching and splitting support

If the SMF supports the "ATSSS" feature defined in clause 5.8, the SMF shall within the SmPolicyContextData data structure include the ATSSS capability within the "atsssCapab" attribute and the MA PDU session Indication within the "maPduInd" attribute as defined in clause 4.2.2.2.

The SMF determines the ATSSS capability supported for the MA PDU Session based on the ATSSS capabilities provided by the UE and per DNN configuration on SMF, as follows:

– If the SMF receives the UE’s ATSSS capabilities "MPTCP functionality with any steering mode and ATSSS-LL functionality with only Active-Standby steering mode" and;

– if the DNN configuration allows both MPTCP and ATSSS-LL with any steering mode, including RTT measurement without using PMF protocol, the SMF shall set the "atsssCapab" attribute to the value "MPTCP_ATSSS_LL_WITH_ASMODE_UL", or;

– if the DNN configuration allows both MPTCP and ATSSS-LL with any steering mode, including RTT measurement without using PMF protocol, but the UPF does not support the RTT measurement without using PMF protocol, the SMF shall set the "atsssCapab" attribute to the value "MPTCP_ATSSS_LL_WITH_EXSDMODE_DL_ASMODE_UL".

– if the DNN configuration allows MPTCP with any steering mode and ATSSS-LL with only Active-Standby steering mode, the SMF shall set the "atsssCapab" attribute to the value "MPTCP_ATSSS_LL_WITH_ASMODE_DLUL".

– If the SMF receives the UE’s ATSSS capabilities "ATSSS-LL functionality with any steering mode" and the DNN configuration allows ATSSS-LL with any steering mode, the SMF shall set the "atsssCapab" attribute to the value "ATSSS_LL".

– If the SMF receives the UE’s ATSSS capabilities "MPTCP functionality with any steering mode and ATSSS-LL functionality with any steering mode", and the DNN configuration allows both MPTCP and ATSSS-LL with any steering mode, the SMF shall set the "atsssCapab" attribute to the value "MPTCP_ATSSS_LL".

If the SMF receives the MA PDU Request Indication from the UE and the SMF determines that the MA PDU session is allowed based on the Session Management subscription data retrieved from the UDM and the operator policy, the SMF shall include the "MA_PDU_REQUEST" within the "maPduInd" attribute; otherwise if the SMF receives the MA PDU Network-Upgrade Allowed indication from the UE and the SMF determines that the MA PDU session is allowed based on the Session Management subscription data retrieved from the UDM and the operator policy, the SMF shall include the "MA_PDU_NETWORK_UPGRADE_ALLOWED" within the "maPduInd" attribute.

If the PCF supports the "ATSSS" feature, the PCF may provide PCC rules and/or session rules of ATSSS policy for the MA PDU session as defined in clause 4.2.6.2.17 and clause 4.2.6.3.4; otherwise the PCF shall not provide any PCC rules and/or session rules of ATSSS policy.

4.2.2.18 DNN Selection Mode Support

If the SMF supports the "DNNSelectionMode" feature defined in clause 5.8, when the SMF receives from the AMF the DNN selection mode, the SMF shall send an HTTP POST message as defined in clause 4.2.2.2 and shall include the received information in the "dnnSelMode" attribute.

The "dnnSelMode" attribute indicates whether the DNN suplied in the "dnn" attribute is an explicitly subscribed DNN and thus verified by the network against UDM subscription (regardless of whether it was originally provided by the UE or replaced by the network), or if it is a non-subscribed DNN (and provided by the UE, or replaced by the network).

If the PCF supports the "DNNSelectionMode" feature, when the "dnnSelMode" attribute indicates:

– the DNN is not explicitly subscribed, the PCF may provision PCC rules and Session rules according to the PCF local configuration for the UE provided and/or network provided non-subscribed DNN;

– the DNN is explicitly subscribed and verified by the network against UDM subscription, the PCF proceeds according to existing specified procedures.

4.2.2.19 Detection of the SM Policy Association enabling Time Sensitive Communications and Time Synchronization

When the feature "TimeSensitiveNetworking" or "TimeSensitiveCommunication" is supported, the PCF detects if the Npcf_SMPolicyControl_Create request relates to SM Policy Association enabling Time Sensitive Communications and Time Synchronization based on the received DNN and S-NSSAI. The PCF then may provide within the SmPolicyDecision data structure the "TSN_BRIDGE_INFO" policy control request trigger within the "policyCtrlReqTriggers" attribute to instruct the SMF to trigger a PCF interaction when the trigger is met; i.e., new TSC user plane node information is available.

NOTE: Time sensitive communication and time synchronization are not supported in home-routed roaming scenarios.

4.2.2.20 Support of Dual Connectivity end to end redundant User Plane paths

Upon the initial interaction with the PCF, if the "Dual-Connectivity-redundant-UP-paths" feature is supported, the PCF shall determine, based on operator’s policy (e.g. when some of the allowed services require redundancy), whether the PDU session is a redundant one.

When the PCF determines that the PDU session is a redundant PDU session, the PCF shall provision the "redSessIndication" attribute set to true within the SmPolicyDecisionData returned in the response to the HTTP POST request.Upon receiving the indication from the PCF that the PDU session is a redundant PDU session, the SMF shall apply the corresponding procedures towards the access network and the UPF for the establishment of the redundant user plane paths as defined in clause 5.33.2.1 of 3GPP TS 23.501 [2].

The PCF shall not modify during the PDU session lifetime the indication of whether the redundant user plane paths are allowed for the PDU session.

4.2.2.21 User Plane Remote Provisioning of UE SNPN Credentials in Onboarding Network

User Plane Remote Provisioning of UEs SNPN Credentials when in Onboarding Network is provided through a DNN and S-NSSAI used for onboarding.

When the "PvsSupport" feature is supported, the PCF may make authorization and policy decisions to restrict the use of the PDU Session established to the DNN and S-NSSAI used for onboarding in a ON-SNPN, e.g., by restricting the traffic to/from Provisioning Server address(es) and DNS server address(es) only.

When the Onboarding Network is a ON-SNPN, during the PDU session establishment procedure related to a PDU session for used for User Plane Remote Provisioning, the SMF shall include the indication that the PDU session is used for onboarding with the "onboardInd" attribute set to true and provide within "pvsInfo" attribute, if available, the information related to the Provisioning Server(s) that provisions the UE with credentials and other data to enable SNPN access.

If the "onboardInd" attribute set to true is received during the SM policy association establishment and the combination of the received DNN within "dnn" attribute and the S-NSSAI within "sliceInfo" attribute corresponds to a PDU session used for User Plane Remote Provisioning, the PCF shall omit the subscription data check with UDR. Instead, the PCF shall use the locally stored Onboarding Configuration Data for this DNN and S-NSSAI combination to make authorization and policy decisions.

If the "pvsInfo" attribute with the Provisioning Server(s) information is received in the request, the PCF shall use the received information to create the service data flow template of the Provisioning Server(s) in the derived PCC Rule(s). If the "pvsInfo" attribute is not received, the PCF shall construct this service data flow template(s) based on the local configuration stored as part of the Onboarding Configuration Data. In addition, the PCF may create service data flow templates for the DNS server address(es) stored as part of the Onboarding Configuration Data. The "pvsInfo" attribute provided by the SMF may include, for each provided Provsioning Server, the Provisioning Server IP address(es) and/or FQDN(s).

NOTE 1: How the PCF resolves a Provisioning Server FQDN to an IP address or IP address range with other mechanism than local configuration in the Onboarding Configuration Data is not specified in this release of the specification

The PCF shall select the QoS information of the PCC rule(s) applicable to the User Plane Remote Provisioning service based on policies locally configured at the PCF as part of the Onboarding Configuration Data.

The PCF shall install the derived PCC Rule(s) in the response. The installed PCC Rule(s) shall take precedence over the locally stored PCC Rule(s) in the SMF.

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

NOTE 2: When the Onboarding Network is a PLMN or a SNPN, the SMF does not provide the "onboardInd" attribute and the "pvsInfo" attribute. The PCF retrieves policy control subscription profile for this SUPI, DNN, S-NSSAI from UDR, that includes the list of allowed services. If the list of allowed services includes both PVS and DNS services, then the PCF, based on local policies, determines the PVS and DNS address(es) to be used in the SDF template of the PCC Rule(s) and allows traffic to/from these destinations as per currently specified procedures.

4.2.2.22 Network slice related data rate policy control

When an Npcf_SMPolicyControl_Create request 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.