4 UE Policy Control Service

29.5253GPP5G SystemStage 3TSUE Policy Control Service

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

4.1 Service Description

4.1.1 Overview

The UE Policy Control Service, as defined in 3GPP TS 23.502 [3] and 3GPP TS 23.503 [4], is provided by the Policy Control Function (PCF).

This service is used as part of the provisioning of UE policies (e.g. ANDSP, URSP, V2XP, ProSeP) determined by the PCF to the UE via the AMF and as part of the provisioning of N2 PC5 policy for V2X communications and/or 5G ProSe determined by the PCF to the NG-RAN via the AMF. This service hence offers the following functionalities:

– creation of a UE Policy Association as requested by the NF service consumer (e.g. AMF);

– provisioning of policy control request trigger(s) to the NF service consumer (e.g. AMF);

– provisioning of the UE policy (e.g. ANDSP, URSP, V2XP, ProSeP) to the V-PCF by the H-PCF in the roaming case;

– provisioning of the N2 PC5 policy for V2X communications and/or 5G ProSe to the V-PCF by the H-PCF in the roaming case;

– update of a UE Policy Association as requested by the NF service consumer (e.g. AMF);

– reporting of the met policy control request trigger(s) by the NF service consumer;

– update of policy control request trigger(s) by the PCF to the NF service consumer (e.g. AMF);

– deletion of a UE Policy Association as requested by the NF service consumer (e.g. AMF); and

– enable the PCF to request the termination of a UE Policy Association to the NF service consumer (e.g. AMF).

4.1.2 Service Architecture

The 5G System Architecture is defined in 3GPP TS 23.501 [2]. The Policy and Charging related 5G architecture is also described in 3GPP TS 29.513 [7].

The UE Policy Control Service (Npcf_UEPolicyControl) is part of the Npcf service-based interface exhibited by the Policy Control Function (PCF).

The known NF service consumers of the Npcf_UEPolicyControl service are the Access and Mobility Management Function (AMF) and the Visited Policy Control Function (V-PCF).

The AMF accesses the UE Policy Control Service at the PCF via the N15 Reference point. In the roaming scenario, the N15 reference point is located between the V-PCF in the visited network and the AMF. The V-PCF accesses the UE Policy Control Service at the Home Policy Control Function (H-PCF) via the N24 Reference point.

Figure 4.1.2-1: Reference Architecture for the Npcf_UEPolicyControl Service; SBI representation

Figure 4.1.2-2: Non-roaming Reference Architecture for the Npcf_UEPolicyControlService; reference point representation

Figure 4.1.3-2: Roaming reference Architecture for the Npcf_UEPolicyControlService; reference point representation

4.1.3 Network Functions

4.1.3.1 Policy Control Function (PCF)

For non-roaming scenarios, the Policy Control Function (PCF):

– supports unified policy framework to govern network behaviour;

– provides UE policy, including Access Network Discovery and Selection Policy (ANDSP), UE Route Selection Policy (URSP), V2XP (Vehicle-to-Everything Policy) and/or 5G ProSe Policy (ProSeP) via the AMF transparently to the UE;

– provides policy control request trigger(s) to the AMF; and

NOTE 1: The PCF invokes the Namf_Communication service specified in 3GPP TS 29.518 [14] to provide the UE Policy.

– provides N2 PC5 policy, containing the PC5 QoS parameters used by NG-RAN for V2X communications and/or 5G ProSe via the AMF to the NG-RAN.

NOTE 2: The PCF invokes the Namf_Communication service specified in 3GPP TS 29.518 [14] to provide the N2 PC5 Policy for V2X communications and/or 5G ProSe.

For roaming scenarios, the Visited Policy Control Function (V-PCF):

– provides policy control request trigger(s) to the AMF;

– provides the ANDSP of the VPLMN via the AMF transparently to the UE;

– forwards the ANDSP, URSP, V2XP and/or ProSeP received from the H-PCF via the AMF to the UE; and

NOTE 3: The V-PCF invokes the Namf_Communication service specified in 3GPP TS 29.518 [14] to provide the UE Policy.

– forwards the N2 PC5 policy for V2X communications and/or 5G ProSe received from the H-PCF via the AMF to the NG-RAN.

NOTE 4: The V-PCF invokes the Namf_Communication service specified in 3GPP TS 29.518 [14] to provide the N2 PC5 Policy for V2X communications and/or 5G ProSe.

For roaming scenarios, the Home Policy Control Function (H-PCF):

– provides policy control request trigger(s) to the V-PCF;

– provides the UE policy (e.g. ANDSP, URSP, V2XP, or ProSeP) of the HPLMN to the V-PCF for forwarding to the UE via the the AMF; and

– provides the N2 PC5 policy for V2X communications and/or 5G ProSe to the V-PCF for forwarding to the NG-RAN via the AMF.

4.1.3.2 NF Service Consumers

The known NF service consumers of the Npcf_UEPolicyControl are the AMF, and in the roaming case, the V-PCF.

The Access and Mobility Management function (AMF) performs:

– registration management;

– connection management;

– reachability management;

– mobility Management;

– forwarding of UE Policy towards the served UE;

– reporting of the UE state to the (V-)PCF;

– forwarding of the UE policy enforcement result received from the UE to the (V-)PCF; and

NOTE: The AMF invokes the Namf_Communication service specified in 3GPP TS 29.518 [14] to report the UE policy enforcement result.

– forwarding of the N2 PC5 policy for V2X communications and/or 5G ProSe towards the NG-RAN.

The Visited Policy Control Function (V-PCF) provides the functions described in clause 4.1.3.1 towards the visited network as NF service producer and acts as NF Service consumer toward the H-PCF, performing the following functions:

– receiving policy control request trigger(s) and/or UE policy (e.g. ANDSP, URSP, V2XP, ProSeP) from the H-PCF;

– receiving the N2 PC5 policy for V2X communications and/or 5G ProSe from the H-PCF; and

– reporting of the UE state and UE policy enforcement result to the H-PCF.

4.2 Service Operations

4.2.1 Introduction

Table 4.2.1-1: Operations of the Npcf_UEPolicyControl Service

Service operation name	Description	Initiated by
Npcf_UEPolicyControl_Create	Creates a UE Policy Association.	NF service consumer (e.g. AMF, V-PCF in roaming case)
Npcf_UEPolicyControl_Update	Updates a UE Policy Association and provides the corresponding policies to the NF service consumer when policy control request trigger(s) is/are met or the AMF is relocated due to the UE mobility and the old PCF is selected.	NF service consumer (e.g. AMF, V-PCF in roaming case)
Npcf_UEPolicyControl_UpdateNotify	– Provides the updated policy control request trigger(s) to the AMF by the (V-)PCF in the non-roaming or roaming case; – Provides the updated UE policy and/or policy control request trigger(s) to the V-PCF by the H-PCF; or – Initiates the UE Policy association termination towards the NF service consumer by the NF service producer.	PCF (H-PCF and V-PCF in roaming case)
Npcf_UEPolicyControl_Delete	Provides means for the NF service consumer to delete a UE Policy Association.	NF service consumer (e.g. AMF, V-PCF in roaming case)

4.2.2 Npcf_UEPolicyControl_Create Service Operation

4.2.2.1 General

The procedure in the present clause is applicable when the NF service consumer creates a UE policy association in the following cases:

– UE performs initial registration to the network, as defined in clause 5.5.1.2.2 of 3GPP TS 24.501 [15];

– UE performs a mobility registration, if the UE operating in single-registration mode performs inter-system change from S1 mode to N1 mode, as defined in clause 5.5.1.3.2 of 3GPP TS 24.501 [15], and there is no existing UE Policy Association between AMF and PCF for this UE; and

– the AMF is relocated (between the different AMF sets) and the new AMF selects a new PCF. The procedure for the case where the AMF is relocated and the new AMF selects the old PCF is defined in clause 4.2.3.1.

The creation of a UE policy association only applies for normally registered UEs, i.e. it does not apply for emergency-registered UEs.

Figure 4.2.2.1-1 illustrates the procedure used for the creation of a policy association.

Figure 4.2.2.1-1: Creation of a UE policy association

NOTE 1: For the roaming scenario, the PCF represents the V-PCF, if the NF service consumer is an AMF, and the PCF represents the H-PCF, if the NF service consumer is a V-PCF.

When a UE registers to the network and a UE context is being established, if the AMF obtains from the UE a UE policy delivery protocol message as defined in Annex D of 3GPP TS 24.501 [15] and/or the authorized PC5 capability for 5G ProSe, and/or the authorized PC5 capability for V2X communications, the AMF shall establish a UE policy association with the (V-)PCF, in case there is no existing UE policy association for the UE; otherwise, the AMF may establish a UE Policy Association with the (V-)PCF based on AMF local configuration.

NOTE 2: In the roaming scenario, the visited AMF’s local configuration can indicate whether UE Policy delivery is needed based on the roaming agreement with the home PLMN of the UE.

To establish a UE policy association with the PCF, the NF service consumer (e.g. AMF) shall send an HTTP POST request with "{apiRoot}/npcf-ue-policy-control/v1/policies" as Resource URI and the PolicyAssociationRequest data structure as request body, which shall include:

– the Notification URI encoded as "notificationUri" attribute;

– the SUPI encoded as "supi" attribute; and

– the features supported by the NF service consumer encoded as "suppFeat" attribute,

shall also include, when available:

– the GPSI encoded as "gpsi" attribute;

– the Access type encoded as "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.

– the Permanent Equipment Identifier (PEI) encoded as "pei" attribute;

– the User Location Information encoded as "userLoc" attribute;

– the UE Time Zone encoded as "timeZone" attribute;

– the identifier of the serving network (the PLMN Identifier or the SNPN Identifier), encoded as "servingPlmn" attribute;

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

– the RAT type encoded as "ratType" attribute;

– the received UE policy delivery protocol message defined in Annex D of 3GPP TS 24.501 [15] encoded as "uePolReq" attribute;

– for the roaming scenario, if the NF service consumer is an AMF, the H-PCF ID encoded as "hPcfId" attribute;

– the Internal Group Identifier(s) encoded as "groupIds" attribute;

– the PC5 capability for V2X encoded as "pc5Capab" attribute if the "V2X" feature defined in clause 5.8 is supported;

– the 5G ProSe capability within the "proSeCapab" attribute, if the "ProSe" feature defined in clause 5.8 is supported;

– if the NF service consumer is an AMF, the GUAMI encoded as "guami" attribute; and

– if the NF service consumer is an AMF, the serving AMF Id encoded as "servingNfId" attribute.

and may include:

– if the NF service consumer is an AMF, the name of a service produced by the AMF that expects to receive information via the Npcf_UEPolicyControl_UpdateNotify service operation encoded as "serviceName" attribute;

– if the NF service consumer is an AMF, the alternate or backup IPv4 Address(es) where to send Notifications encoded as "altNotifIpv4Addrs" attribute;

– if the NF service consumer is an AMF, the alternate or backup IPv6 Address(es) where to send Notifications encoded as "altNotifIpv6Addrs" attribute; and

– if the NF service consumer is an AMF, the alternate or backup FQDN(s) where to send Notifications encoded as "altNotifFqdns" attribute.

Upon the reception of the HTTP POST request,

– the (V-)(H-)PCF shall assign a UE policy association ID;

– for the roaming scenario and based on operator policy, the V-PCF (as the NF service consumer) should send to the H-PCF a request for the Creation of a UE policy association as described in the present clause;

– the (V-)(H-)PCF shall determine the applicable UE policy as detailed in clause 4.2.2.2. For the V-PCF, any policy received from the H-PCF in the reply to the possible request for the Creation of a policy association should be taken into consideration;

– if the (V-)PCF determines that UE policy needs to be provisioned, it shall use the Namf_Communication service specified in 3GPP TS 29.518 [14] to provision the UE policy according to clause 4.2.2.2 and as follows:

(i) the (V-)PCF shall subscribe to the AMF to notifications on N1 messages for UE Policy Delivery Results using the Namf_Communication_N1N2MessageSubscribe service operation;

(ii) the (V-)PCF shall send the determined UE policy (e.g. ANDSP, URSP, V2XP, ProSeP) using Namf_Communication_N1N2MessageTransfer service operation(s); and

(iii) the (V-)PCF shall be prepared to receive UE Policy Delivery Results from the AMF and/or subsequent UE policy requests (e.g. for V2XP and/or ProSeP) within the Namf_Communication_N1MessageNotify service operation. For the V-PCF, if the received UE Policy Delivery results relate to UE policy sections provided by the H-PCF, the V-PCF shall use the Npcf_UEPolicyControl_Update Service Operation defined in clause 4.2.3 to send those UE Policy Delivery results to the H-PCF;

– if the UE indicates the support of V2X communications over PC5 reference point and the "V2X" feature is supported, the (H-)PCF shall determine the applicable V2XP, as detailed in clause 4.2.2.2.1.2, and V2X N2 PC5 policy, as detailed in clause 4.2.2.3 and based on the operator’s policy;

– if the UE indicates the support of 5G ProSe and the "ProSe" feature is supported, the (H-)PCF shall determine the applicable ProSeP, as detailed in clause 4.2.2.2.1.3, and 5G ProSe N2 PC5 policy, as detailed in clause 4.2.2.4 and based on the operator’s policy;

– if the PCF determines that N2 PC5 policy (e.g. for V2X communications, for 5G ProSe) needs to be provisioned, including the case of the V-PCF when receiving the N2 PC5 policy from the H-PCF, the PCF shall use the Namf_Communication service specified in 3GPP TS 29.518 [14] to provision the N2 PC5 policy according to clause 4.2.2.3 and/or clause 4.2.2.4;

– for the successfull case, the (V-)(H-)PCF shall send a HTTP "201 Created" response with the URI for the created resource in the "Location" header field.

NOTE 5: The assigned policy association ID is part of the URI for the created resource and is thus associated with the SUPI.

and the PolicyAssociation data type as response body, including:

– mandatorilly, the negotiated supported features encoded as "suppFeat" attribute;

– optionally, the information provided by the NF service consumer when requesting the creation of this policy association encoded as "request" attribute;

– optionally, for the H-PCF as service producer communicating with the V-PCF, UE policy (see clause 4.2.2.2) encoded as "uePolicy" attribute;

– optionally, for the H-PCF as service producer communicating with the V-PCF, N2 PC5 policy (see clause 4.2.2.3 and/or clause 4.2.2.4) encoded as "n2Pc5Pol" attribute (for V2X communications) and/or "n2Pc5ProSePol" attribute (for 5G ProSe);

– optionally, one or several of the following Policy Control Request Trigger(s) encoded as "triggers" attribute (see clause 4.2.3.2):

a) Location change (tracking area);

b) Change of UE presence in PRA;

c) Change of PLMN, if the "PlmnChange" feature is supported; and

d) Change of UE connectivity state, if the "ConnectivityStateChange" feature is supported; and

– if the Policy Control Request Trigger "Change of UE presence in PRA" is provided, the presence reporting areas for which reporting is required encoded as "pras" attribute; and

NOTE 4: If the PCF uses a Presence Reporting Area identifier referring to a Set of Core Network predefined Presence Reporting Areas as defined in 3GPP TS 23.501 [2], the PCF includes the identifier of this Presence Reporting Area set within the "praId" attribute.

– if errors occur when processing the HTTP POST request, the (V-)(H-)PCF shall apply error handling procedures as specified in clause 5.7 and according to the following provisions:

– if the user information received within the "supi" attribute is unknown, the (V-)(H-)PCF shall reject the request and include in an HTTP "400 Bad Request" response message the "cause" attribute of the ProblemDetails data structure set to "USER_UNKNOWN"; and

– if the (V-)(H-)PCF is, due to incomplete, erroneous or missing information in the request, not able to provision a UE policy decision, the (V-)(H-)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_REQUEST_PARAMETERS".

If the (V-)PCF received a GUAMI, the (V-)PCF may subscribe to GUAMI changes using the AMFStatusChange service operation of the Namf_Communication service specified in 3GPP TS 29.518 [14], and it may use the Nnrf_NFDiscovery Service specified in 3GPP TS 29.510 [13] (using the obtained GUAMI and possibly service name) to query the other AMFs within the AMF (service) set.

4.2.2.2 UE Policy

4.2.2.2.1 Overview

4.2.2.2.1.0 General

The UE policy consists of

– UE Access Network discovery and selection policies (ANDSP). It is used by the UE for selecting non-3GPP accesses networks. The encoding of ANDSP is defined in 3GPP TS 24.526 [16];

– UE Route Selection Policy (URSP). This UE policy is used by the UE to determine how to route outgoing traffic. Traffic can be routed to an established PDU Session, offloaded to non-3GPP access outside a PDU Session, can be routed via a ProSe Layer-3 UE-to-Network Relay outside a PDU session or trigger the establishment of a new PDU Session. The encoding of URSP is defined in 3GPP TS 24.526 [16];

– UE Vehicle-to-Everything Policy (V2XP). This UE policy provides configuration information to the UE for V2X communications over PC5 reference point or over Uu reference point or both. The encoding of V2XP is defined in 3GPP TS 24.588 [25]; and

– UE 5G Proximity based Services Policy (ProSeP). This UE policy provides configuration information to the UE for 5G ProSe direct discovery, 5G ProSe direct communications, 5G ProSe UE-to-network relay and/or 5G ProSe usage reporting configuration and rules.

The UE Policy is transferred to the UE using the UE policy delivery protocol defined in Annex D of 3GPP TS 24.501 [15]. The (V-)(H-)PCF shall send UE policy using the "MANAGE UE POLICY COMMAND" message and will receive the "MANAGE UE POLICY COMPLETE"or the "MANAGE UE POLICY COMMAND REJECT" messages in the response. Those messages are transparently forwarded by the AMF.

The (V-)PCF shall use the Namf_Communication_N1N2MessageTransfer service operation defined in clause 5.2.2.3.1 of 3GPP TS 29.518 [14] to send "MANAGE UE POLICY COMMAND" messages to the UE and use the Namf_Communication_N1MessageNotify service operation defined in clause 5.2.2.3.5 of 3GPP TS 29.518 [14] to receive "MANAGE UE POLICY COMPLETE" and "MANAGE UE POLICY COMMAND REJECT" messages from the UE. The (V-)PCF shall only send "MANAGE UE POLICY COMMAND" messages below a predefined size limit.

The H-PCF shall use service operations as defined in the present specification to receive "MANAGE UE POLICY COMPLETE" and "MANAGE UE POLICY COMMAND REJECT" messages from the V-PCF and to send MANAGE UE POLICY COMMAND" messages to the V-PCF. The H-PCF shall encode the "MANAGE UE POLICY COMMAND" message in a "uePolicy" attribute. The H-PCF shall only send "MANAGE UE POLICY COMMAND" messages below a predefined size limit.

The (V-)(H-)PCF may deliver the UE policy to the UE in several "MANAGE UE POLICY COMMAND" messages.

For the purpose of such fragmented delivery and subsequent partial updates of UE policies, the UE policy is divided into policy sections. Such policy sections may be predefined in the (V-)(H-)PCF, may be retrieved by the (V-)(H-)PCF from the UDR as specified in 3GPP TS 29.519 [17], or may be dynamically generated by the (V-)(H-)PCF, but shall comply to the rules detailed below. The (V-)(H-)PCF may combine several policy sections into one "MANAGE UE POLICY COMMAND" message, if the predefined size limit is observed.

The following rules apply to policy sections:

– The size shall be below the predefined size limit.

– The policy section shall only contain complete URSP rule(s), WLANSP rule(s), N3AN node configuration information, V2XP and/or ProSeP info content, but no fractions of such rules, configuration information, or info contents.

– To ease a subsequent partial update of UE policies, policy sections should only contain a small number of policies, e.g. URSP rule(s), and/or WLANSP rule(s).

– The entire content of a policy section shall be provided by a single PLMN.

A PCF shall only determine policy sections of its own PLMN. However, a V-PCF may forward UE policy sections received from the H-PCF to the UE.

Each UE policy section is identified by a UE policy section identifier (UPSI). The UPSI is composed of two parts:

a) a PLMN ID part containing the PLMN ID of the PLMN or SNPN of the PCF which provides the UE policies; and

b) a UE policy section code (UPSC) containing a unique value within the PLMN or SNPN selected by the PCF.

NOTE 1: When the UE is operating in SNPN access operation mode, the UE associates the PLMN ID with the NID of the SNPN to differentiate between PLMN UPSI(s) and SNPN UPSI(s).

The (V-)(H-)PCF provides an UPSI when providing a new UE policy section and may then identify that policy section using that UPSI when requesting that that UE policy section is modified or deleted, as specified in Annex D of 3GPP TS 24.501 [15].

If the (V-)(H-)PCF determines that changes are required and/or the V-PCF receives possible new or modified policy sections determined by the H-PCF in the roaming case, it shall send the determined new, updated or deleted policy sections using one or several "MANAGE UE POLICY COMMAND" messages towards the NF service consumer. In the roaming case, the V-PCF may either combine policy sections received from the H-PCF and policy sections the V-PCF selected in the same "MANAGE UE POLICY COMMAND" (as long as the predefined size limit is observed), or use separate "MANAGE UE POLICY COMMAND" messages; however, the V-PCF shall not distribute the policy sections received in one "MANAGE UE POLICY COMMAND" from the H-PCF into several "MANAGE UE POLICY COMMAND" messages as long as the predefined size limit is observed for the policy sections received from the H-PCF. The V-PCF shall allocate a new PTI for the "MANAGE UE POLICY COMMAND" sent by the V-PCF and store the mapping between the new PTI and the PTI within the "MANAGE UE POLICY COMMAND" received from the H-PCF.

After sending a "MANAGE UE POLICY COMMAND" messages, the (V-)(H-)PCF shall wait for a related confirmation in a "MANAGE UE POLICY COMPLETE" messages or failure indication in a "MANAGE UE POLICY COMMAND REJECT" message. When receiving no such message until the expiry of a supervision timer specified in Annex D of 3GPP TS 24.501 [15], or when receiving a failure indication, the PCF should re-send related instructions for the policy sections. In the roaming case, the H-PCF and the V-PCF shall each be responsible for resending those policy sections that it originally supplied. In the case that the V-PCF combined policy sections received from the H-PCF and policy sections the V-PCF selected in the same "MANAGE UE POLICY COMMAND" described below, the V-PCF shall wait for the H-PCF to resend the policy sections of HPLMN, and then resend the combined policy sections. The (V-)(H-)PCF shall always include the initially supplied policy sections when resending the UE policy.

The (V-)(H-)PCF shall determine that a received "MANAGE UE POLICY COMPLETE" message or "MANAGE UE POLICY COMMAND REJECT" message is related to the result of a "MANAGE UE POLICY COMMAND" based on the PTI within that message. In the roaming case, the V-PCF shall determine that the received message is related to the result of the UE policy provided by the H-PCF if the PTI within the message belongs to one of the stored PTI mapping(s).

If the V-PCF combined policy sections received from the H-PCF and policy sections the V-PCF selected in the same "MANAGE UE POLICY COMMAND", upon reception of a "MANAGE UE POLICY COMPLETE" message or "MANAGE UE POLICY COMMAND REJECT" message the V-PCF shall:

– forward the corresponding "MANAGE UE POLICY COMPLETE" message to the H-PCF;

– if a "MANAGE UE POLICY COMMAND REJECT" message with UPSI(s) of the HPLMN is received, forward the parts of the "MANAGE UE POLICY COMMAND REJECT" message that relate to the UPSI(s) of the HPLMN to the H-PCF;

– if a "MANAGE UE POLICY COMMAND REJECT" message without UPSI(s) of the HPLMN is received, send a "MANAGE UE POLICY COMPLETE" message to the H-PCF; and

– provide the stored PTI received from the HPLMN in the corresponding "MANAGE UE POLICY COMMAND" within the "MANAGE UE POLICY COMPLETE" message or "MANAGE UE POLICY COMMAND REJECT" message towards the H-PCF.

If the V-PCF sent a separate "MANAGE UE POLICY COMMAND" containing only the policy sections received from the H-PCF, the V-PCF shall forward the corresponding "MANAGE UE POLICY COMPLETE" or "MANAGE UE POLICY COMMAND REJECT" message to the H-PCF and provide the stored PTI received from the HPLMN in the corresponding "MANAGE UE POLICY COMMAND" within the "MANAGE UE POLICY COMPLETE" message or "MANAGE UE POLICY COMMAND REJECT" message towards the H-PCF.If the V-PCF distributed the policy sections received in one "MANAGE UE POLICY COMMAND" from the H-PCF into several "MANAGE UE POLICY COMMAND" messages to the UE (because the predefined size limit of the VPLMN was exceeded), the V-PCF shall aggregate all corresponding "MANAGE UE POLICY COMPLETE" or "MANAGE UE POLICY COMMAND REJECT" messages received from the UE into one "MANAGE UE POLICY COMPLETE" or "MANAGE UE POLICY COMMAND REJECT" message towards the H-PCF.

When the (V-)PCF receives an Namf_Communication_N1N2MessageTransfer failure response as defined in clause 5.2.2.3.1.2 of 3GPP TS 29.518 [14], or an N1N2 Transfer Failure Notification as defined in clause 5.2.2.3.2 of 3GPP TS 29.518 [14], the (V-)PCF shall stop the supervision timer specified in Annex D of 3GPP TS 24.501 [15] corresponding to the affected PTIs. For the N1N2 Transfer Failure Notification case, the (V-)PCF determines the affected PTIs allocated by the V-PCF based on the resource URI within the "n1n2MsgDataUri" attribute of the N1N2MsgTxfrFailureNotification data structure as defined in clause 6.1.6.2.30 of 3GPP TS 29.518 [14].

NOTE 2: The (V-)PCF correlates the Namf_Communication_N1N2MessageTransfer request and the corresponding N1N2 Transfer Failure Notification based on the resource URI within the "Location" header included in the response HTTP status code "202 Accepted" of the Namf_Communication_N1N2MessageTransfer response and the resource URI within the "n1n2MsgDataUri" attribute of and N1N2 Transfer Failure Notification. And then the V-PCF determines the affected PTIs related with the resource URI.

For the roaming case and if the V-PCF determines that the affected UE policy is related with the UE policy delivered by the H-PCF, the V-PCF shall send a POST message as defined in clause 4.2.3.1 to notify the H-PCF of the failure of UE policy transfer by including the "uePolTransFailNotif" attribute within the PolicyAssociationUpdateRequest data structure. Within the UePolicyTransferFailureNotification data structure, the V-PCF shall include the cause of the UE Policy Transfer Failure within the "cause" attribute and the PTI(s) allocated by the H-PCF corresponding to the PTI(s) allocated by the V-PCF within the "ptis" attribute. The H-PCF shall stop the supervision timer corresponding to the affected PTIs.

In the failure case described above, the (H-)(V-)PCF may provision the policy control request trigger "CON_STATE_CH" if not provisioned yet. Upon receiving the notification of UE connectivity state change indicating that the UE enters the CM-Connected state, the (H-)(V-)PCF may retry to deliver the UE Policy.

When the (H-)PCF receives the "MANAGE UE POLICY COMPLETE" or the "MANAGE UE POLICY COMMAND REJECT" message and determines that this message indicates a UE Policy Delivery outcome to which an NF service consumer has subscribed via a request for service specific parameters, the (H-)PCF shall invoke the Npcf_EventExposure_Notify service operation as defined in clause 4.2.4.2 of 3GPP TS 29.523 [30].

4.2.2.2.1.1 Provisioning of the UE Access Network discovery and selection policies and UE Route Selection Policy

During Initial Registration and 5GS Registration during UE mobility from EPS to 5GS, and when the UE has one or more stored UE policy sections corresponding to the serving PLMN/SNPN or HPLMN, the UE includes the "UE STATE INDICATION" message as defined in clause D.5.4.1 of 3GPP TS 24.501 [15] , whichis transferred transparently by the AMF within the "uePolReq" attribute during the creation of a policy association, as described in clause 4.2.2.1.

The (H-)PCF, or the PCF of the SNPN for the UEs subscribed to the SNPN, may store in the UDR, as specified in 3GPP TS 29.519 [17]:

a) UPSCs and related UE policy sections of the own PLMN or SNPN it provided to a UE;

b) the PEI received from the NF service consumer (e.g. AMF), if available;

c) the OSId(s) received from the UE within the "UE STATE INDICATION" message as described in the Annex D of 3GPP TS 24.501 [15], if available; and

d) the indication of UE’s support for ANDSP included in the "UE STATE INDICATION" message as described in the Annex D of 3GPP TS 24.501 [15], if available.

The PCF shall retrieve from UDR the information previously stored in UDR, if not locally available, for URSP/ANDSP rule determination as specified in 3GPP TS 29.519 [17].

The V-PCF may retrieve UPSCs and related UE policy sections applicable for all UEs from a HPLMN from the V-UDR, using the HPLMN ID as key as specified in 3GPP TS 29.519 [17]. The PCF of the serving SNPN has locally configured the UPSCs and related UE policy sections applicable for all UEs other than the UEs subscribed to the SNPN.

When receiving the "UE STATE INDICATION" message, the (V-)(H-)PCF or the PCF of the serving SNPN, shall determine, based on the UPSIs, the ANDSP support indication and the OSId(s) indicated in that message, if available, the UE Policy Sections and UPSCs stored in the UDR, if available, the policy subscription data, if available, application data, if available, and local policy, as specified in clauses 4.2.2.2.2 and 4.2.2.2.3, whether any new UE policy section(s) need to be installed and whether any existing UE policy section(s) need to be updated or deleted.

4.2.2.2.1.2 Provisioning of Vehicle-to-Everything Policy

When the UE registers to the network, if the AMF receives from the UE the PC5 capability for V2X communications in the Registration Request message, the UE is authorized to use V2X service based on the UE’s subscription information and the "V2X" feature is supported, the AMF further reports to the PCF the PC5 capability for V2X communications within the "pc5Capab" attribute as defined in clause 4.2.2.1. The PCF may determine the V2XP over PC5 interface based on the received UE’s PC5 capability for V2X, the Service specific parameter information retrieved from UE’s Application Data in the UDR as defined in clause 6.2.15 of 3GPP TS 29.519 [17] and the operator’s policy.

After UE registration, if the UE supports V2X communication and it does not have valid V2XP, the UE includes the "UE POLICY PROVISIONING REQUEST" message as defined in 3GPP TS 24.587 [24] during the NAS transport procedure. The PCF may reject the request by sending back a "UE POLICY PROVISIONING REJECT" message as defined in clause 7.2.2 of 3GPP TS 24.587 [24] or provision the policy, as defined in clause 4.2.2.2.1, based on the service specific parameter information retrieved from UE’s Application Data in the UDR as defined in clause 6.2.15 of 3GPP TS 29.519 [17] and the operator’s policy.

For both scenarios mentioned above, in the roaming case, the H-PCF may include the V2XP within the "uePolicy" attribute in the policy association create or update response to the V-PCF and in the policy association update request initiated by the H-PCF.

In the roaming or non-roaming case, the (V-)PCF shall use the Namf_Communication_N1N2MessageTransfer service operation defined in clause 5.2.2.3.1 of 3GPP TS 29.518 [14] to send the V2XP to the UE.

4.2.2.2.1.3 Provisioning of ProSe Policy

When the UE registers to the network and the UE supports 5G ProSe, if the AMF receives from the UE the 5G ProSe Capability in the Registration Request message, the UE is authorized to use 5G ProSe service based on the UE’s subscription information and the "ProSe" feature defined in clause 5.8 is supported, the AMF further reports to the PCF this 5G ProSe Capability of the UE within the "proSeCapab" attribute, as per the procedures defined in clause 4.2.2.1. When the UE disables/enables a 5G ProSe capability, the AMF further reports to the PCF the updated 5G ProSe capabilities of the UE within the "proSeCapab" attribute, as per the procedures defined in clause 4.2.3.1. The PCF may determine the support of 5G ProSe based on the received UE’s 5G ProSe Capability, the service specific parameter information retrieved from the UE’s Application Data in the UDR as defined in clause 6.2.15 of 3GPP TS 29.519 [17] and the operator’s policy.

After UE registration, if the UE does not have valid ProSeP, the UE includes a "UE POLICY PROVISIONING REQUEST" message defined in clause 7.2.1.1 of 3GPP TS 24.554 [28] during theNAS transport procedure. The PCF may either reject the request by sending back a "UE POLICY PROVISIONING REJECT" message defined in clause 7.2.2.1 of 3GPP TS 24.587 [24] or provision the policy, as defined in clause 4.2.2.2.1, based on the service specific parameter information retrieved from the UE’s Application Data in the UDR as defined in clause 6.2.15 of 3GPP TS 29.519 [17] and the operator’s policy.

For both scenarios mentioned above, in the roaming case, the H-PCF may include the ProSeP within the "uePolicy" attribute in the policy association create and update response to the V-PCF and in the policy association update request initiated by the H-PCF.

In the roaming or non-roaming case, the (V-)PCF shall use the Namf_Communication_N1N2MessageTransfer service operation defined in clause 5.2.2.3.1 of 3GPP TS 29.518 [14] to send the ProSeP to the UE.

4.2.2.2.2 UE Access Network discovery and selection policies (ANDSP)

UE Access Network discovery and selection policies are used by the UE to select non-3GPP accesses and to decide how to route traffic between the selected 3GPP and non 3GPP accesses.

In this release of the specification, the Access Network Discovery & Selection policy shall contain only rules that aid the UE in selecting a WLAN access network. Rules for selecting other types of non-3GPP access networks are not specified.

The WLAN access network selected by the UE with the use of Access Network Discovery & Selection policy may be used for direct traffic offload (i.e. sending traffic to the WLAN outside of a PDU Session) and for registering to 5GC using the non-3GPP access network selection information.

The Access Network Discovery & Selection policy shall contain one or more WLAN Selection Policy (WLANSP) rules and and may contain Non-3GPP access network (N3AN) node selection information and configuration information.

N3AN node selection information and configuration information is used to control UE behaviour related to selection of either N3IWF or ePDG for accessing 5GC via non-3GPP access.

UE Access Network discovery and selection policies are encoded as defined in 3GPP TS 24.526 [16].

UE Access Network discovery and selection policies may be provided by a V-PCF and/or a H-PCF.

If the UE has indicated in the "UE STATE INDICATION" message it does not support ANDSP, i.e. the UE does not support non-3GPP access, the PCF shall not send any Access Network discovery and selection policies to the UE.

4.2.2.2.3 UE Route Selection Policy (URSP)

The UE Route Selection Policy is used by the UE to determine how to route outgoing traffic.

The UE Route Selection Policy shall consist of one or several URSP rules.

URSP rules are encoded as defined in 3GPP TS 24.526 [16].

UE Route Selection Policy may only be provided by a H-PCF or the PCF of the SNPN, but shall not be provided by a V-PCF. However, UE Route Selection Policy determined and provided by the H-PCF may be retrieved by a V-PCF from the H-PCF and forwarded to a UE.

The (H-)PCF shall use the UE policy subscription data stored in UDR as specified in 3GPP TS 29.519 [17] to ensure the values included in the Route Selection Descriptor of the generated URSP rules are always supported by subscription.

For the received list of internal group Ids, the (H-)PCF retrieves the corresponding 5G VN group configuration data stored from the UDR as specified in 3GPP TS 29.504[27] and 3GPP TS 29.505 [26], if available. For each available 5G VN group, the (H-)PCF may use the retrieved 5G VN group configuration values to encode the values for the Route Selection Descriptor and the values for the Traffic Descriptor of the generated URSP rules.

If the "EnhancedBackgroundDataTransfer" feature is supported, the (H-)PCF may retrieve the Background Data Transfer Reference ID(s) by retrieving the UE’s Application Data from the UDR as defined in clause 6.2.9 of 3GPP TS 29.519 [17]. In this case, the PCF shall retrieve the transfer policy corresponding to the Background Data Transfer Reference ID(s) as defined in clause 5.2.8 of 3GPP TS 29.519 [17] and then may create the URSP rules including the Route Selection Validation Criteria for the UE as defined in clause 6.6.2.1 of 3GPP TS 23.503 [4]. If the (H-)PCF provisions the URSP rules including the Route Selection Validation Criteria for the UE, it shall use the associated S-NSSAI and DNN to store in the UDR the Background Data Transfer Reference ID(s) in the UE’s session management policy data as specified in 3GPP TS 29.519 [17].

If the (H-)PCF retrieves the BDT policy and corresponding related information (e.g. network area information, the volume of data to be transferred per UE, etc.) within the BdtData data type, and the "bdtpStatus" attribute within the BdtData data type is set to value "INVALID", the (H-)PCF shall not provision the URSP rules based on the invalid BDT policy. When the BDT policy re-negotiation is completed the PCF may:

– if the new BDT Policy is determined, create or update the applicable URSP rules based on the new BDT policy; or

– if the invalid BDT policy is removed, remove applicable URSP rules.

If the "AfGuideURSP" feature is supported by the Nudr_DataRepository service, the (H-)PCF may receive Service specific parameter information that contains data for AF guidance information on the URSP determination as defined in clause 6.4.2.15 of 3GPP TS 29.519 [17]. In this case, the (H-)PCF may also use this AF guidance information as input to determine the URSP that will be provisioned to the UE. If the received AF guidance information is not consistent with the UE subscription data, or the local operator policy does not allow the specific S-NSSAI and DNN provided by the AF guidance information, the corresponding AF guidance information shall not be used to determine the URSP rules.

When the (H-)PCF decides to provide URSP rules based on the AF guidance information, it shall derive the information as follows:

– Application traffic descriptor within the "trafficDesc" attribute is used to set the Traffic Descriptor of URSP rule (defined in Figure 5.2.2 of 3GPP TS 24.526 [16]).

– Each route selection parameter set within the "routeSelParamSets" attribute of the UrspRuleRequest data type is used to determine a Route selection descriptor (defined in Figure 5.2.2 of 3GPP TS 24.526 [16]) as follows:

– DNN (within the "dnn" attribute of the RouteSelectionParameterSet data type) and S-NSSAI (within the "snssai" attribute of the RouteSelectionParameterSet data type) from the route selection parameter set are used to set the Route selection descriptor contents (defined in Figure 5.2.4 of 3GPP TS 24.526 [16]);

– Route selection precedence (within the "precedence" attribute of the RouteSelectionParameterSet data type) is used to set the Precedence value of route selection descriptor (defined in Figure 5.2.4 of 3GPP TS 24.526 [16]); and

– the spatial validity condition (within the "spatialValidityTais" attribute of the RouteSelectionParameterSet data type) is used to set the Location criteria of the route selection descriptor (defined in Figure 5.2.5 of 3GPP TS 24.526 [16]).

– The precedence for the generated URSP rule is determined by the (H-)PCF. The (H-)PCF may use the "relatPrecedence" attribute within the "UrspRuleRequest" data type to derive the relative precedence of the URSP rule for a request coming from the same AF.

URSP rules based on AF guidance should not be set as the URSP rules with the "match all" application traffic descriptor.

The (H-)PCF may obtain the information about the UE’s OS from the UE as described in the Annex D of 3GPP TS 24.501 [15] or it may derive the information about the UE’s OS from the PEI provided by the NF service consumer (e.g. AMF).

If the (H-)PCF is required to provide UE policies to the UE that includes application descriptors then:

a) If the (H-)PCF has been provided with one UE’s OS Id by the UE, the (H-)PCF shall use either the traffic descriptor "OS App Id type" or the traffic descriptor "OS Id + OS App Id type" as defined in 3GPP TS 24.526 [16].

NOTE 1: The (H-)PCF uses the traffic descriptor "OS Id + OS App Id type" when the (H-)PCF does not take the received UE’s OS Id into account.

b) If the (H-)PCF has been provided with more than one UE’s OS Id by the UE,

– the (H-)PCF shall use the traffic descriptor "OS Id + OS App Id type" for the UE’s OS Id provided by the UE as defined in 3GPP TS 24.526 [16]; and

– the (H-)PCF shall not use the traffic descriptor "OS App Id type" as defined in 3GPP TS 24.526 [16].

c) If the (H-)PCF has not been provided with the UE’s OS Id by the UE,

– the (H-)PCF shall use the traffic descriptor "OS Id + OS App Id type" as defined in 3GPP TS 24.526 [16]; and

– the (H-)PCF shall not use the traffic descriptor "OS App Id type" as defined in 3GPP TS 24.526 [16].

d) If the (H-)PCF has been provided with the UE’s OS Id by the UE and the (H-)PCF has derived the UE’s OS Id from the PEI and if there is an inconsistency between the OS Id provided by the UE and the OS Id derived from the PEI, the (H-)PCF shall use the OS Id provided by the UE for providing UE policies to the UE that include application descriptors.

URSP rules may be used to support end to end redundant user plane paths by establishing two redundant PDU sessions. PCF configuration based on e.g. deployment, terminal implementation or policies per group of UE(s) may be used by the PCF to determine whether the URSP Rules shall include PDU Session Pair ID and RSN to indicate that they refer to redundant PDU sessions or whether the UE will determine these values instead.

NOTE 2: The PCF can provide two distinct URSP rules to support end to end redundant user plane paths using Dual Connectivity for the duplicated traffic of an application. Duplicated traffic from the UE application is differentiated by two distinct traffic descriptors (different DNNs, and for IP traffic, different IP descriptors or non-IP descriptors), each one defined in a different URSP rule, so that the two redundant PDU sessions are matched to the specific Route Selection Descriptors of distinct URSP rules. These Route Selection Descriptors of distinct URSP rules may include corresponding RSNs and PDU Session Pair IDs as defined in 3GPP TS 24.526 [16]. The Route Selection Descriptors share the same PDU Session Pair ID, if included, to denote the two traffic are redundant with each other.

NOTE 3: For backward compatibility, PCF can provide a Route Selection Descriptor with PDU Session Pair ID and RSN and a Route Selection Descriptor without PDU Session Pair ID and RSN in the URSP rule. In this case, the Route Selection Descriptor with PDU Session Pair ID and RSN has a lower precedence value (i.e. higher prioritised) than the one without PDU Session Pair ID. It allows that if a non-supporting UE receives the Route Selection Descriptor containing PDU Session Pair ID, it ignores this Route Selection Descriptor.

4.2.2.2.4 Vehicle-to-Everything Policy (V2XP)

V2XP includes the V2XP over PC5 and over Uu interfaces.

The V2XP over PC5 are defined in clause 5.2.3 of 3GPP TS 24.587 [24] and the corresponding encoding is defined in clause 5.3.1 of 3GPP TS 24.588 [25].

The V2XP over Uu are defined in clause 5.2.4 of 3GPP TS 24.587 [24] and the corresponding encoding is defined in clause 5.3.2 of 3GPP TS 24.588 [25].

4.2.2.2.5 Proximity based Services Policy (ProSeP)

The ProSeP includes:

– ProSeP for 5G ProSe direct discovery defined in clause 5.3 of 3GPP TS 24.555 [29];

– ProSeP for 5G ProSe direct communications defined in clause 5.4 of 3GPP TS 24.555 [29];

– ProSeP for 5G ProSe UE-to-network relay, including:

– ProSeP for 5G ProSe UE-to-network relay UE defined in clause 5.5 of 3GPP TS 24.555 [29]; and/or

– ProSeP for 5G ProSe Remote UE defined in clause 5.6 of 3GPP TS 24.555 [29];

and/or

– ProSeP for 5G ProSe usage reporting configuration and rules defined in clause 5.7 of 3GPP TS 24.555 [29].

4.2.2.3 V2X N2 PC5 Policy

The V2X N2 PC5 policy consists of V2X PC5 QoS parameters used by the NG-RAN.

When the (H-)PCF derives the UE policy for V2X communications over PC5 reference point as defined in clause 4.2.2.2.4, the (H-)PCF shall derive the corresponding V2X PC5 QoS parameters used by the NG-RAN.

In the roaming case, the H-PCF:

– if PC5 UE capabilities and UE Policy Provisioning request messages are received, and V2X policies are derived, shall include the V2X N2 PC5 Policy within the "n2Pc5Pol" attribute in the policy association creation response towards the V-PCF; or

– shall include the V2X N2 PC5 Policy within the "n2Pc5Pol" attribute, if changes apply, in the policy association update response towards the V-PCF; or

– may include the V2X N2 PC5 Policy within the "n2Pc5Pol" attribute in the the policy association update request initiated by the H-PCF.

In the roaming or non-roaming case, the (V-)PCF shall use the Namf_Communication_N1N2MessageTransfer service operation defined in clause 5.2.2.3.1 of 3GPP TS 29.518 [14] to send V2X N2 PC5 policy to the NG-RAN.

4.2.2.4 5G ProSe N2 PC5 Policy

The 5G ProSe N2 PC5 policy consists of 5G ProSe PC5 QoS parameters used by the NG-RAN.

When the (H-)PCF derives the UE policy for 5G ProSe as defined in clause 4.2.2.2.5, the (H-)PCF shall derive the corresponding 5G ProSe N2 PC5 QoS parameters used by the NG-RAN.

In the roaming case, the H-PCF:

– if the 5G ProSe capabilities and the UE Policy Provisioning request message are received, and 5G ProSe policies are derived, shall include the N2 PC5 Policy for 5G ProSe within the "n2Pc5ProSePol" attribute in the of policy association creation response towards the V-PCF; or

– shall include the N2 PC5 Policy for 5G ProSe within the "n2Pc5ProSePol" attribute, if changes apply, in the response of the policy association update response towards the V-PCF; or

– may include the N2 PC5 Policy for 5G ProSe within the "n2Pc5ProSePol" attribute in the policy association update request initiated by the H-PCF.

4.2.3 Npcf_UEPolicyControl_Update Service Operation

4.2.3.1 General

The procedure in the present clause is applicable when the NF service consumer modifies an existing UE policy association (including the case where the AMF is relocated and the new AMF selects to maintain the policy association with the old PCF and to update the Notification URI).

Figure 4.2.3.1-1 illustrates the update of a policy association.

Figure 4.2.3.1-1: Update of a UE policy association

NOTE 1: For the roaming case, the PCF represents the V-PCF if the NF service consumer is an AMF and the PCF represents the H-PCF if the NF service consumer is a V-PCF.

The AMF, as NF service consumer, invokes this procedure when a subscribed policy control request trigger (see clause 4.2.3.2) occurs. When a policy control request trigger that requires the subscription as defined in table 5.6.3.3-1 (e.g. LOC_CH trigger) occurs, the NF service consumer (AMF) shall only invoke this procedure if the PCF has explicitly subscribed to that event trigger. When a policy control request trigger that does not require the subscription as defined in table 5.6.3.3-1 (e.g. GROUP_ID_LIST_CHG trigger) occurs, the NF service consumer (AMF) shall always invoke the procedure.

NOTE 2: The AMF uses the Namf_Communication_N1MessageNotify service operation specified in 3GPP TS 29.518 [14] to send to the V-PCF a "MANAGE UE POLICY COMPLETE" message or a "MANAGE UE POLICY COMMAND REJECT" message, as defined in Annex D.5 of 3GPP TS 24.501 [15] or a "UE POLICY PROVISIONING REQUEST" message as defined in clause 7.2.1.1 of 3GPP TS 24.587 [24].

If an AMF as NF service consumer knows by implementation specific means that the UE context has been transferred to an AMF with another GUAMI within the AMF set, it may also invoke this procedure to update the Notification URI.

NOTE 3: Either the old or the new AMF can invoke this procedure.

During the AMF relocation, if the new AMF received the resource URI of the individual UE Policy from the old AMF and selects the old PCF, the new AMF shall also invoke this procedure to update the Notification URI. The new AMF may also update the alternate or backup IP addresses.

The V-PCF, as NF service consumer, invokes this procedure when a policy control request trigger (see clause 4.2.3.2) occurs. When a policy control request trigger that does not require the subscription as defined in table 5.6.3.3-1 (e.g. UE_POLICY trigger) occurs, the V-PCF shall always invoke the procedure. When a policy control request trigger that requires the subscription as defined in table 5.6.3.3-1 (e.g. LOC_CH trigger) occurs, the V-PCF shall only invoke this procedure if the H‑PCF has subscribed to that event trigger.

To request policies (e.g. policy control request trigger(s) is/are met) from the PCF, to update the Notification URI, to update the trace control configuration or to request the termination of trace, the NF Service Consumer shall request the update of the associated UE Policy Association by providing the relevant parameters about the UE context in an HTTP POST request with "{apiRoot}/npcf-ue-policy-control/v1/policies/{polAssoId}/update" as Resource URI and the PolicyAssociationUpdateRequest data structure as request body that shall include:

– at least one of the following:

1. a new Notification URI encoded in the "notificationUri" attribute;

2. observed Policy Control Request Trigger(s) (see clause 4.2.3.2) encoded as "triggers" attribute;

3. if a UE location change occurred, the UE location encoded as "userLoc" attribute;

4. if a "MANAGE UE POLICY COMPLETE" message or a "MANAGE UE POLICY COMMAND REJECT" message of the UE policy delivery protocol defined in Annex D of 3GPP TS 24.501 [15] has been received by the V-PCF as NF service consumer, and at least parts of the contents relate to UPSIs of the HPLMN, the parts of that message that relate to UPSIs of the HPLMN encoded as "uePolDelResult" attribute;

5. if the Policy Control Request Trigger "Change of UE presence in PRA" is provided, the current presence status of the UE for the presence reporting areas for which reporting was requested, if not previously provided, or the presence reporting areas for which reporting was requested and the status has changed encoded as "praStatuses" attribute;

NOTE 4: If the PCF included the identifer of a Core Network predefined Presence Reporting Area Set within the "praId" attribute during the subscription to changes of UE presence in PRA, the AMF only provides the presence reporting area information corresponding to the concerned individual Presence Reporting Area Identifier(s) within the Set. The "praId" attribute within each returned "PresenceInfo" data type hence includes the identifier of the concerned individual Presence Reporting Area.

6. if the NF service consumer is an AMF, for AMF relocation scenarios, if available, alternate or backup IPv4 Address(es) where to send Notifications encoded as "altNotifIpv4Addrs" attribute;

7. if the NF service consumer is an AMF, for AMF relocation scenarios, if available, alternate or backup IPv6 Address(es) where to send Notifications encoded as "altNotifIpv6Addrs" attribute;

8. if the NF service consumer is an AMF, for AMF relocation scenarios, if available, alternate or backup FQDN(s) where to send Notifications encoded as "altNotifFqdns" attribute;

9. for AMF relocation scenarios, the GUAMI encoded as "guami" attribute;

NOTE 5: An alternate NF service consumer than the one that requested the generation of the subscription resource can send the request. For instance, an AMF as service consumer can change.

10. if the NF service consumer is an AMF, for AMF relocation scenarios, the new serving AMF Id encoded in the "servingNfId" attribute;

11. if a UE PLMN change occurred and the "PlmnChange" feature defined in clause 5.8 is supported, the PLMN Identifier or the SNPN Identifier of the new serving network encoded as "plmnId" attribute;

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

NOTE 7: When the UE moves between PLMNs, the trigger reports changes of equivalent PLMNs.

12. if a "UE POLICY PROVISIONING REQUEST" message defined in clause 7.2.1.1 of 3GPP TS 24.587 [24] has been received by the V-PCF as NF service consumer and respectively the "V2X" feature and/or the "ProSe" feature defined in clause 5.8 is/are supported, the message encoded as "uePolReq" attribute;

13. if a UE Internal Group Identifier(s) change occurred and the "GroupIdListChange" feature defined in clause 5.8 is supported, the Internal Group Identifier(s) of the served UE encoded as "groupIds" attribute; and/or

14. if a change of PC5 capablity for 5G ProSe occurred and the "ProSe" feature defined in clause 5.8 is supported, the PC5 capability for 5G ProSe encoded as "proSeCapab" attribute.

15. if a change of the connectivity state of the UE occurred and the "ConnectivityStateChange" feature defined in clause 5.8 is supported, the connectivity state of the served UE encoded as "connectState" attribute; and/or

16. when a response with HTTP status code 4xx or 5xx as defined in clause 5.2.2.3.1.2 of 3GPP TS 29.518 [14] or a N1N2 Transfer Failure Notification as defined in clause 5.2.2.3.2 of 3GPP TS 29.518 [14] is received by the V-PCF after provisioning the UE policy by invoking the Namf_Communication_N1N2MessageTransfer service operation to the AMF, this UE policy transfer failure notification encoded as "uePolTransFailNotif" attribute.

Upon the reception of the HTTP POST request:

– if the PCF is a V-PCF and the V-PCF has an established policy association with the H-PCF, the V-PCF shall determine based on the contents of a potentially "uePolDelResult" attribute to be sent to the H-PCF (see above) and requested event triggers of the H-PCF whether to send as the NF service consumer towards the H-PCF a request for the update of the policy association as described in the present clause;

– the (V-)(H-)PCF shall determine the applicable UE policy based on the UE Policy Sections stored in UDR, UE local policy and, for the H-PCF, taking into consideration the information received within the UE policy delivery protocol encoded in the "uePolReq" attribute, if available, and for the V-PCF, taking into consideration any policy received from the H-PCF encoded in the "uePolicy" attribute in the reply to the possible request for the update of the associated policy association. When the "ProSe" feature is supported, the H-PCF shall determine the applicable ProSeP based on the received PC5 capability for 5G ProSe. When the UE disables a 5G ProSe capability the PCF may stop updating the corresponding ProSeP, and when the UE enables a 5G ProSe capability the PCF may update the corresponding ProSeP;

– if the UE indicates the support of 5G ProSe communications over PC5 reference point, the "ProSe" feature is supported, and for the H-PCF, if the UE POLICY PROVISIONING REQUEST message with the requested 5G ProSe policies was included in the "uePolReq" attribute, the (H-)PCF shall determine the applicable ProSeP and 5G ProSe N2 PC5 policy, as detailed in clauses 4.2.2.2.1.3 and 4.2.2.4, based on the operator’s policy;

– if the UE indicated the support of V2X communications over PC5 reference point, "V2X" feature is supported, and for the H-PCF, if the UE POLICY PROVISIONING REQUEST message was included in the "uePolReq" attribute, the (H-)PCF shall determine the applicable V2XP and V2X N2 PC5 policy as detailed in clauses 4.2.2.2.1.2 and 4.2.2.3, based on the operator’s policy;

– for the succesfull case, the (V-)(H-)PCF shall send a HTTP "200 OK" response with the PolicyUpdate data type as response body with the possibly updated of UE policy (for the H-PCF), and/or ProSe N2 PC5 policy (for the H-PCF) as specified in clause 4.2.2.4, N2 PC5 policy for V2X communications and/or 5G ProSe (for the H-PCF) as specified in clause 4.2.2.3 and/or Policy Control Request Trigger(s) encoded as described in clause 4.2.3.3;

– if the (V-)PCF determines that UE policy needs to be updated, it shall use the Namf_Communication service specified in 3GPP TS 29.518 [14] to provision the UE policy according to clause 4.2.2.2 and as follows:

(i) the (V-)PCF shall send the determined UE policy using Namf_Communication_N1N2MessageTransfer service operation(s); and

(ii) the (V-)PCF shall be prepared to receive UE Policy Delivery Results from the AMF within the Namf_Communication_N1MessageNotify service operation, and for the V-PCF, if the received UE Policy Delivery results relate to UE policy sections provided by the H-PCF, the V-PCF shall use the Npcf_UEPolicyControl_Update Service Operation to send those UE Policy Delivery results to the H-PCF; and

NOTE 8: A PolicyUpdate data structure with only mandatory attribute(s) is included in the "200 OK" response when the PCF decides not to update the policies.

– if the PCF determines that the V2XP and N2 PC5 policy (e.g. for V2X communications, for 5G ProSe) for V2X communications need to be updated, and for the V-PCF when receiving the updated V2XP and N2 PC5 policy for V2X communications from the H-PCF, it shall use the Namf_Communication service specified in 3GPP TS 29.518 [14] to provision the V2XP to the UE and the V2X N2 PC5 policy to NG-RAN according to clauses 4.2.2.2.1.2 and 4.2.2.3;

– if the PCF determines that ProSeP and 5G ProSe N2 PC5 policy needs to be updated, and for the V-PCF when receiving the updated ProSeP and 5G ProSe N2 PC5 policy from the H-PCF, it shall use the Namf_Communication service specified in 3GPP TS 29.518 [14] to provision the ProSeP to the UE and 5G ProSe N2 PC5 policy to NG-RAN according to clauses 4.2.2.2.1.3 and 4.2.2.4;

– if errors occur when processing the HTTP POST request, the (V-)(H-)PCF shall:

– send an HTTP error response as specified in clause 5.7; or

– if the feature "ES3XX" is supported, and the (V-)(H-)PCF determines the received HTTP POST request needs to be redirected, send an HTTP redirect response as specified in clause 6.10.9 of 3GPP TS 29.500 [5];

according to the following provisions:

– if the (V-)(H-)PCF is, due to incomplete, erroneous or missing information in the request not able to provision a UE policy decision, 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_REQUEST_PARAMETERS".

If the PCF received a new GUAMI, the PCF may subscribe to GUAMI changes using the AMFStatusChange service operation of the Namf_Communication service specified in 3GPP TS 29.518 [14], and it may use the Nnrf_NFDiscovery Service specified in 3GPP TS 29.510 [13] (using the obtained GUAMI and possibly service name) to query the other AMFs within the AMF set.

4.2.3.2 Policy Control Request Triggers

The following Policy Control Request Triggers are defined (see clause 6.1.2.5 of 3GPP TS 23.503 [4]):

– "LOC_CH", i.e. location change (tracking area): the tracking area of the UE has changed;

– "PRA_CH", i.e. change of UE presence in PRA: the UE is entering/leaving a Presence Reporting Area. This includes reporting the initial status at the time the request for this reporting is initiated;

– "UE_POLICY", i.e. a "MANAGE UE POLICY COMPLETE" message or a "MANAGE UE POLICY COMMAND REJECT" message, as defined in Annex D.5 of 3GPP TS 24.501 [15] has been received by the V-PCF and is being forwarded to the H-PCF, or a "UE POLICY PROVISIONING REQUEST" message, as defined in clause 7.2.1.1 of 3GPP TS 24.587 [24] has been received by the V-PCF and is being forwarded to the H-PCF;

– "PLMN_CH", i.e. PLMN change: the serving network (PLMN or SNPN) of the UE has changed;

NOTE 1: The "PLMN_CH" trigger only applies if the "PlmnChange" feature is supported.

NOTE 2: When the UE is moving between PLMNs, the trigger reports changes of equivalent PLMNs.

– "CON_STATE_CH", i.e. connectivity state change: the connectivity state of the UE has changed;

NOTE 3: The "CON_STATE_CH" trigger only applies if the "ConnectivityStateChange" feature is supported.

– "GROUP_ID_LIST_CHG", i.e. UE Internal Group Identifier(s) change: the UDM provided list of group Ids has changed; and

NOTE 4: The "GROUP_ID_LIST_CHG" trigger only applies if the "GroupIdListChange" feature is supported. This Policy Control Request Trigger does not require an explicit subscription from the PCF.

– "UE_CAP_CH", i.e. UE Capabilities change: the UE provided 5G ProSe capabilities have changed.

NOTE 5: The "UE_CAP_CH" trigger only applies if the "ProSe" feature is supported. This Policy Control Request Trigger does not require a subscription.

4.2.3.3 Encoding of updated policy

Updated policies shall be encoded within the PolicyUpdate data type that may include:

– only when the updated policy is supplied by the H-PCF in the roaming scenario, UE policy (see clause 4.2.2.2) encoded as "uePolicy" attribute, and N2 PC5 policy for V2X communications (see clause 4.2.2.3) encoded as "n2Pc5Pol" attribute and/or the N2 PC5 policy for 5G ProSe (see clause 4.2.2.4) encoded as "n2Pc5ProSePo" attribute;

– updated Policy Control Request Trigger(s) (see clause 4.2.3.2) encoded as "triggers" attribute, i.e.:

1) either a new complete list of applicable Policy Control Request Trigger(s) including one or several of the following:

a) Location change (tracking area); or

b) Change of UE presence in PRA;

c) Change of PLMN, if the "PlmnChange" feature is supported; or

d) Change of UE connectivity state, if the "ConnectivityStateChange" feature is supported; or

2) a "NULL" value to request the removal of all previously installed Policy Control Request Trigger(s); and

– if the Policy Control Request Trigger "Change of UE presence in PRA" is provided or if that trigger was already set but the requested presence reporting areas need to be changed, the presence reporting areas for which reporting is required encoded as "pras" attribute encoded as follows:

a) A new entry shall be added by supplying a new identifier as key and the corresponding PresenceInfo data type instance with complete contents as value as an entry within the map.

b) An existing entry shall be modified by supplying the existing identifier as key and the PresenceInfo data type instance with complete contents as value as an entry within the map.

c) An existing entry shall be deleted by supplying the existing identifier as key and "NULL" as value as an entry within the map.

d) For an unmodified entry, no entry needs to be provided within the map.

4.2.4 Npcf_UEPolicyControl_UpdateNotify Service Operation

4.2.4.1 General

The (V-)(H)-PCF may decide to update policy control request triggers, and in the roaming case, the H-PCF may decide to update the UE Policy, the V2X N2 PC5 policy, if the "V2X" feature is supported, and/or the 5G ProSe N2 PC5 policy, if the "ProSe" feature is supported. The PCF (H-PCF in the roaming case) may decide to request the termination of the policy association. The(V-)(H-)PCF shall then use an Npcf_UEPolicyControl_UpdateNotify service operation.

The following procedures using the Npcf_UEPolicyControl_UpdateNotify service operation are supported:

– Policy update notification.

– Request the termination of the UE policy association.

– URSP provisioning for background Data Transfer policy.

– UE policy provisioning for V2X communications over PC5 and Uu reference points.

– UE policy provisioning for 5G ProSe.

– N2 PC5 Policy (e.g. for V2X communications, for 5G ProSe) provisioning.

NOTE: The PCF derives the URSP and invokes the Namf_Communication_N1N2MessageTransfer service operation to provision it to the UE.

4.2.4.2 Policy update notification

Figure 4.2.4.2-1 illustrates the policy update notification.

Figure 4.2.4.2-1: policy update notification

NOTE: For the roaming case, the PCF represents the V-PCF if the NF service consumer is an AMF and the PCF represents the H-PCF if the NF service consumer is a V-PCF.

The (V-)(H)-PCF may decide to update policy control request trigger(s) and in the roaming case, the H-PCF may also decide to update the UE Policy, the N2 PC5 policy for V2X communications if the "V2X" feature is supported and/or the N2 PC5 policy for 5G ProSe if the "ProSe" feature is supported. The (V-)(H-)PCF shall then send an HTTP POST request with "{notificationUri}/update" as URI (where the Notification URI was previously supplied by the NF service consumer) to the NF service consumer and the PolicyUpdate data structure as request body encoded as described in clause 4.2.3.3.

Upon the reception of the HTTP POST request, the NF service consumer:

– if the V-PCF is the NF service consumer, shall use the Namf_Communication Service defined in 3GPP TS 29.518 [14] to send "MANAGE UE POLICY COMMAND" message(s) with the received UE policy to the UE via the AMF and/or with the received N2 PC5 policy for V2X communications and/or 5G ProSe to the NG-RAN via the AMF;

– if the V-PCF is the NF service consumer, shall provision the received policy control requested trigger(s) to the AMF using the Npcf_UEPolicyControl_UpdateNotify service operation according to the present clause;

– if the AMF is the NF service consumer, shall enforce the received policy control request trigger(s);

– shall either send a successful response indicating the success of the enforcement or an appropriate failure response, for the V-PCF as the NF service consumer taking into consideration a reply received from the possible Namf_Communication Service service operation and from the possible Npcf_UEPolicyControl_UpdateNotify service operation according to the previous bullets. In case of a successful response:

– if the feature "ImmediateReport" is supported and the PCF provisioned the policy control request triggers related to PLMN change, PRA change, connectivity state change or location change, a "200 OK" response code and a response body with the corresponding available information in the "UeRequestedValueRep" data structure shall be returned in the response;

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

– if errors occur when processing the HTTP POST request, shall send an HTTP error response as specified in clause 5.7; or

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

If the feature "ErrorResponse" is supported and if the AMF as NF service consumer is not able to handle the notification but another unknown AMF could possibly handle the notification, it shall reply with an HTTP "404 Not found" error response.

If the (V-)PCF receives a "307 Temporary Redirect" response, the (V-)PCF shall resend the failed policy update notification request using the received URI in the Location header field as Notification URI. Subsequent policy update notifications, triggered after the failed one, shall be sent to the Notification URI provided by the NF service consumer during the corresponding policy association creation/update.

If the (V-)PCF becomes aware that a new AMF is requiring notifications (e.g. via the "404 Not found" response or via Namf_Communication service AMFStatusChange Notifications, see 3GPP TS 29.518 [14], or via link level failures), and the (V-)PCF knows alternate or backup IPv4, Ipv6 Addess(es) or FQDN(s) where to send Notifications (e.g. via "altNotifIpv4Addrs", "altNotifIpv6Addrs" or "altNotifFqdns" attributes received when the policy association was created or via AMFStatusChange Notifications, or via the Nnrf_NFDiscovery Service specified in 3GPP TS 29.510 [13] (using the service name and GUAMI obtained during the creation of the subscription) to query the other AMFs within the AMF set), the (V-)PCF shall exchange the authority part of the corresponding Notification URI with one of those addresses and shall use that URI in any subsequent communication.

If the (V-)PCF received a "404 Not found" response, the (V-)PCF should resend the failed policy update notification request to that URI.

4.2.4.3 Request for termination of the policy association

Figure 4.2.4.3-1 illustrates the request for a termination of the policy association.

Figure 4.2.4.3-1: request for a termination of theUE policy association

NOTE: For the roaming case, the PCF represents the V-PCF if the NF service consumer is an AMF and the PCF represents the H-PCF if the NF service consumer is a V-PCF.

The (V-)(H-)PCF may request the termination of the UE policy association and shall then send an HTTP POST request with "{notificationUri}/terminate" as URI (where the Notification URI was previously supplied by the NF service consumer) and the TerminationNotification data structure as request body that shall include:

– the resource URI of the concerned individual UE policy association (including the policy association ID) encoded as "resourceUri" attribute; and

– the cause why the (V-)(H-)PCF requests the termination of the policy association encoded as "cause" attribute.

Upon the reception of the HTTP POST request, the NF service consumer:

– if the V-PCF is the NF service consumer, shall send as NF service producer for the corresponding policy association (towards the AMF as NF service consumer) a request for a termination of the policy association according to the present clause;

– shall either send an HTTP "204 No Content" response for the succesfull processing of the HTTP POST request or an appropriate failure response, for the V-PCF as the NF service consumer taking into consideration a reply received for the possible corresponding policy association termination request according to the previous bullet; and

– if errors occur when processing the HTTP POST request, shall send an HTTP error response as specified in clause 5.7; or

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

After the succesfull processing of the HTTP POST request, any NF service consumer except for the V-PCF shall invoke the Npcf_UEPolicyControl_Delete Service Operation defined in clause 4.2.5 to terminate the policy association.

If the AMF as NF service consumer is not able to handle the notification but knows by implementation specific means that another AMF is able to handle the notification, it shall reply with an HTTP "307 Temporary Redirect" response pointing to the URI of the new AMF. If the AMF as NF service consumer is not able to handle the notification but another unknown AMF could possibly handle the notification, it shall reply with an HTTP "404 Not found" error response.

If the (V-)PCF receives a "307 Temporary Redirect" response, the PCF shall resend the failed request for termination of the policy association using the received URI in the Location header field as Notification URI.

If the (V-)PCF becomes aware that a new NF service consumer (AMF) is requiring notifications (e.g. via the "404 Not found" response or via Namf_Communication service AMFStatusChange Notifications, see 3GPP TS TS 29.518 [14], or via link level failures), and the (V-)PCF knows alternate or backup Ipv4, Ipv6 Addess(es) or FQDN(s) where to send Notifications (e.g. via "altNotifIpv4Addrs", "altNotifIpv6Addrs" or "altNotifFqdns" attributes received when the policy association was created or via AMFStatusChange Notifications, or via the Nnrf_NFDiscovery Service specified in 3GPP TS 29.510 [13] (using the service name and GUAMI obtained during the creation of the subscription) to query the other AMFs within the AMF set), the (V-)PCF shall exchange the authority part of the corresponding Notification URI with one of those addresses and shall resend the failed request for termination of the policy association to that URI.

If the (V-)PCF received a "404 Not found" response, the (V-)PCF should resend the failed request for termination of the policy association to that URI.

4.2.4.4 URSP provisioning for Background Data Transfer policy

If the "EnhancedBackgroundDataTransfer" feature is supported, after the UE policy association establishment, the (H‑)PCF may receive the Background Data Transfer Reference ID(s) notified by the UDR for the change of UE’s Application Data as defined in clause 6.3.4 of 3GPP TS 29.519 [17]. In this case, the (H-)PCF shall retrieve the transfer policy corresponding to the Background Data Transfer Reference ID(s) as defined in clause 5.2.8 of 3GPP TS 29.519 [17] and derive the URSP including the Route Selection Validation Criteria for the UE as defined in clause 6.2.2.1 of 3GPP TS 23.503 [40]. The H-PCF shall provision the URSP to the V-PCF as defined in clause 4.2.4.2 and then the V-PCF shall invoke the Namf_Communication_N1N2MessageTransfer service operation to provision it to the UE. The (H-)PCF shall use the associated S-NSSAI and DNN to store in the UDR the Background Data Transfer Reference ID(s) in the UE’s session management policy data as specified in 3GPP TS 29.519 [17].

4.2.4.5 UE policy provisioning for V2X communication over PC5 and Uu reference points

After the UE policy association establishment and if the "V2X" feature is supported, the (H-)PCF may receive the service specific parameter information notified by the UDR for the change of UE’s Application Data as defined in clause 6.3.4 of 3GPP TS 29.519 [17]. In this case:

– for the roaming case, the H-PCF shall derive the V2XP and provision it to the V-PCF as defined in clause 4.2.4.2; and/or

– for the roaming and non-roaming case, the (V-)PCF shall use the Namf_Communication Service defined in 3GPP TS 29.518 [14] to send "MANAGE UE POLICY COMMAND" message(s) with the V2XP to the UE via the AMF.

4.2.4.6 UE policy provisioning for 5G ProSe

After the UE policy association establishment and if the "ProSe" feature is supported, the (H-)PCF may receive the service specific parameter information via a notification on the change of UE’s Application Data from the UDR, as defined in clause 6.3.4 of 3GPP TS 29.519 [17]. In this case:

– for the roaming case, the H-PCF shall derive the ProSeP and provision it to the V-PCF as defined in clause 4.2.4.2; and/or

– for the roaming and non-roaming case, the (H-)PCF shall derive the ProSeP and the (V-)PCF shall use the Namf_Communication Service defined in 3GPP TS 29.518 [14] to convey it to the UE via the AMF by sending "MANAGE UE POLICY COMMAND" message(s) as defined in 3GPP TS 24.554 [28].

4.2.4.7 UE policy provisioning for AF-influenced URSP

If the "AfGuideURSP" feature is supported by the Nudr_DataRepository service, after the UE policy association establishment, the (H-)PCF may be informed that service specific parameter information that contains data for AF guidance on the URSP determination has been created, modified or removed via a notification by the UDR for the change or removal of UE’s Application Data as defined in clause 6.3.4 of 3GPP TS 29.519 [17]. In this case, the H-PCF may derive new URSP(s), modify existing URSP(s) or remove existing URSP(s) by using the information received from the UDR (see clause 4.2.2.2.1.1 and 4.2.2.2.3 for the description of how the (H-)PCF may use this information, stored UPSC(s), policy subscription information and local operator policy to determine the URSP that will be provisioned to the UE), and it shall:

– for the roaming case, provision the derived new UE Policy Sections, and/or update and/or remove existing UE Policy Sections to the V-PCF as defined in clause 4.2.4.2 and then the V-PCF shall invoke the Namf_Communication_N1N2MessageTransfer service operation to provision the received UE Policy Sections to the UE; or

– for the non-roaming case, use the Namf_Communication Service defined in 3GPP TS 29.518 [14] to convey the derived new UE Policy Sections and/or to update and/or remove existing UE Policy Sections to the UE via the AMF within "MANAGE UE POLICY COMMAND" message(s).

4.2.5 Npcf_UEPolicyControl_Delete Service Operation

Figure 4.2.5-1 illustrates the deletion of a policy association.

Figure 4.2.5-1: Deletion of a policy association

NOTE: For the roaming case, the PCF represents the V-PCF if the NF service consumer is an AMF and the PCF represents the H-PCF if the NF service consumer is a V-PCF.

The AMF as NF service consumer requests that the policy association is deleted when the corresponding UE context is terminated, e.g. during UE de-registration from the network.

During the AMF relocation, the old AMF shall invoke this procedure when:

– the resource URI of the individual UE Policy Association resource is not transferred to the new AMF; or

– the new AMF informs the old AMF that the individual UE Policy Association resource is not being reused.

To request that the UE policy association is deleted, the NF service consumer (e.g. AMF) shall send an HTTP DELETE request with "{apiRoot}/npcf-ue-policy-control/v1/policies/{polAssoId}" as Resource URI.

Upon the reception of the HTTP DELETE request,

– the (V-)(H-)PCF shall delete the policy association;

– if the PCF is a V-PCF and has an established corresponding policy association towards the H-PCF, the V-PCF shall send as the NF service consumer towards the H-PCF a request for the deletion of that policy association as described in the present clause;

– the (V-)(H-)PCF shall send either an HTTP "204 No Content" response indicating the success of the deletion or an appropriate failure response, for the V-PCF as PCF taking into consideration a reply received for the possible policy association deletion request according to the previous bullet; and

– the (V-)(H-)PCF shall if errors occur when processing the HTTP DELETE request, send an HTTP error response as specified in clause 5.7; or

– if the feature ES3XX is supported, and the (V-)(H-)PCF determines the received HTTP DELETE request needs to be redirected, the (V-)(H-)PCF shall send an HTTP redirect response as specified in clause 6.10.9 of 3GPP TS 29.500 [5].