The procedures for PCF Discovery and Selection by the AMF and by the SMF are described in TS 23.501. The procedure to ensure that a consumer NF (e.g. an AF, NEF or PCF for a UE) reaches the PCF selected for a PDU Session is described in clause 6.1.1.2. The procedure to ensure that a consumer NF (e.g. an AF) reaches the PCF selected for a UE is described in clause 6.1.1.2a.

When multiple and separately addressable PCFs have been deployed, a network functionality is required in order to ensure that a consumer NF (e.g. AF, 5G DDNMF) reaches the PCF serving the UE. This network functionality is provided by the BSF (described in clause 6.1.1.2.2) and has the following characteristics:

• It has information about the user identity, and the selected PCF address for a certain UE.
• The functionality determines the PCF address and if available the associated PCF instance ID and PCF set ID, selected by the PCF discovery and selection function described in TS 23.501.

Policy decisions based on network analytics allow PCF to perform policy decisions taking into account analytics information defined for Analytics IDs listed in TS 23.288. The analytics information may be provided by NWDAF directly or via DCCF, depending on the deployment of NWDAF or DCCF. Local configuration in the PCF indicates if one or multiple or all Analytics ID(s) are retrieved either from NWDAF directly or using DCCF. The PCF uses the DCCF services and DCCF service operations to fetch, subscribe and unsubscribe to the Analytics IDs as described in clause 6.1.4 and clause 8 in TS 23.288. The PCF performs discovery and selection of NWDAF and DCCF as defined in TS 23.501 and subscribes/unsubscribes to Analytics information as defined in TS 23.288. In addition, the AMF and/or SMF may include, in the AM/SM Policy Association establishment or modification procedures, the list of NWDAF instance IDs used for the UE or the PDU Session and their associated Analytics ID(s) consumed by the AMF or SMF respectively. The PCF may select those NWDAF instances as the ones to subscribe for their associated Analytics ID(s) for the UE for which those AM/SM Policy Associations are related to or may perform NWDAF discovery if the NWDAF for an Analytics ID not provided by the AMF or SMF is needed. The following Analytics IDs are relevant for Policy decisions: "Load level information", "Service Experience", "Network Performance", "Abnormal behaviour", "UE Mobility", "UE Communication", "User Data Congestion", "Data Dispersion", "Session Management Congestion Control Experience", "DN Performance" and "WLAN performance". The PCF may subscribe to NWDAF as described below or alternatively, the PCF may use Ndccf_DataManagement_Subscribe including the "Analytics Specification" with the same information as provided in the Nnwdaf_AnalyticsSubscription_Subscribe, and optionally the PCF may include the NWDAF ID, e.g. if provided by AMF or SMF:

• The PCF may subscribe to notifications of network analytics related to "Load Level Information" using the Nnwdaf_AnalyticsSubscription_Subscribe service operation including the Analytics ID "Load level information", the Analytics Filter "S-NSSAI" and the Analytics Reporting Information set to a load level threshold value. The PCF is notified when the load level of the Network Slice Instance reaches the threshold.
  The NWDAF service to retrieve the Load Level Information is described in clause 6.3 of TS 23.288.
• The PCF may subscribe to notifications of network analytics related to "Service Experience" using the Nnwdaf_AnalyticsSubscription_Subscribe service operation including the Analytics ID "Service Experience", the Target of Analytics Reporting "SUPI", "Internal Group Id" or "any UE", the Analytics Filter including one or more Application Identifier(s), one or more or "any" RAT Type(s) or Frequency value(s), one or more value(s) of each RSC (e.g. S-NSSAI, DNN, PDU Session type, SSC Mode, Access Type), one or more combination(s) of RSCs and the Analytics Reporting Information set to service experience threshold value(s) for the RAT Type(s) and/or Frequency value(s). The PCF is notified on the Service Experience statistics or predictions including, for each Application Identifier, the list of SUPIs for which Service Experience is provided and the list of RAT Types and/or Frequency values for which the Service Experience applies. In addition, both spatial and time validity may be provided as well as the confidence of the prediction.
  The NWDAF service to retrieve the service experience (i.e. the average observed Service MoS) is described in clause 6.4 of TS 23.288.
• The PCF may subscribe to notifications of network analytics related to "Network Performance" using the Nnwdaf_AnalyticsSubscription_Subscribe service operation including the Analytics ID "Network Performance", the Target of Analytics Reporting "Internal Group Id" and the Analytics Filter including the Area of Interest. The PCF is notified on the Network Performance statistics or predictions including the Area of Interest. In addition, the confidence of the prediction may be provided.
  The NWDAF services to retrieve "Network Performance" as described in clause 6.6 of TS 23.288.
• The PCF may subscribe to notifications of network analytics related to "Abnormal behaviour" using the Nnwdaf_AnalyticsSubscription_Subscribe service operation including the Analytics ID "Abnormal behaviour", the Target of Analytics Reporting "SUPI", "Internal Group Id" or "any UE" and the Analytics Filter including the expected analytics type or the list of Exceptions IDs and per each Exception Id a possible threshold and other Analytics Filter Information if needed. The list of Exception IDs is specified in TS 23.288.
  The NWDAF services to retrieve "Abnormal behaviour" analytics are described in clause 6.7.5 of TS 23.288.
• The PCF may subscribe to notifications of network analytics related to "UE Mobility" using NWDAF_AnalyticsSubscription_Subscribe service operation including the Analytics ID "UE Mobility", the Target of Analytics Reporting "SUPI", "Internal Group Id" and the Analytics Filter may include one or more "Area(s) of Interest". The PCF is notified on the UE Mobility statistics or predictions as defined clause 6.7.2 of TS 23.288.
  The NWDAF services to retrieve "UE Mobility" analytics are described in clause 6.7.2 of TS 23.288.
• The PCF may subscribe to notifications of network analytics related to "UE Communication" using NWDAF_AnalyticsSubscription_Subscribe service operation including the Analytics ID "UE communication", the Target of Analytics Reporting "SUPI", "Internal Group Id" and the Analytics Filter may include one or more "Application Identifier(s)". The PCF is notified on the UE communication statistics or predictions including list of application(s) in use and corresponding characteristics, e.g. start time and duration time. In addition, the confidence of the prediction may be provided.
  The NWDAF services to retrieve "UE Communication" analytics are described in clause 6.7.3 of TS 23.288.
• The PCF may subscribe to notifications of network analytics related to "User Data Congestion" using NWDAF_AnalyticsSubscription_Subscribe service operation including the Analytics ID "User Data Congestion", the Target of Analytics Reporting containing a SUPI, indication requesting the identifiers of the applications that contribute the most to the traffic and the Analytics Filter may include Area of Interest, reporting threshold and maximum number of applications to be reported. The PCF is notified when the congestion level reaches the threshold. The notification can include the identifiers of the applications that contribute the most to the traffic.
  The NWDAF services to retrieve "User Data Congestion" analytics are described in clause 6.8 of TS 23.288.
• The PCF may subscribe to notifications of network analytics related to "Data Dispersion" using NWDAF_AnalyticsSubscription_Subscribe service operation including the Analytics ID "UE Dispersion Analytics" and the dispersion analytic (DA) type, i.e. Data or Transactions. The Target of Analytics Reporting containing "SUPI", "Internal Group Id" or "any UE", and the Analytics Filter may include a list of TA(s) or an Area of Interest, or a list of Cells, or an S-NSSAI or top heavy users. With the Data Volume Dispersion Analytics type, the PCF may calculate the average data rate in the network slice by subscribing to notifications of network analytics related to Data Volume Dispersion in the network slice for a duration of interest when it sets the Target of Analytics Reporting as "any UE" and the Analytics Filter as the S-NSSAI.
  The NWDAF services to retrieve "Data Dispersion" analytics are described in clause 6.10 of TS 23.288.
• The PCF may subscribe to notifications of network analytics related to "WLAN performance" using the Nnwdaf_AnalyticsSubscription_Subscribe service operation including the Analytics ID "WLAN performance", the Target of Analytics Reporting "SUPI", "Internal Group Id" or "any UE" and the Analytics Filter including the Area of Interest, SSID(s), or BSSID(s). The PCF is notified on the WLAN performance statistics or predictions. In addition, the confidence of the prediction may be provided.
  The NWDAF services to retrieve "WLAN performance" analytics are described in clause 6.11 of TS 23.288.
• The PCF may subscribe to notifications of network analytics related to "Session Management Congestion Control Experience" using the Nnwdaf_AnalyticsSubscription_Subscribe service operation including the Analytics ID "Session Management Congestion Control Experience", the Target of Analytics Reporting containing "SUPI" and the Analytics Filter may include DNN and/or S-NSSAI. The PCF is notified on the Session Management Congestion Control Experience statistics including the DNN and/or S-NSSAI.
  The NWDAF services to retrieve "Session Management Congestion Control Experience" analytics are described in clause 6.12 of TS 23.288.
• The PCF may subscribe to notifications of network analytics related to "DN Performance" using the Nnwdaf_AnalyticsSubscription_Subscribe service operation including the Analytics ID "DN Performance", the Target of Analytics Reporting containing "SUPI", "Internal Group Id" or "any UE", and the Analytics Filter may include Application ID(s). The PCF is notified on the DN Performance statistics or predictions including Application ID(s). In addition, the confidence of the prediction may be provided.
  The NWDAF services to retrieve "DN Performance" analytics are described in clause 6.14 of TS 23.288.

Possible triggers for the PCF to subscribe to analytics information from the NWDAF may include:

• Requests from AF/NEF;
• AM Policy Association establishment or modification request from the AMF;
• UE Policy Association establishment or modification;
• SM Policy Association establishment or modification request from the SMF;
• Notifications received from UDR or CHF on UE subscription change;
• Analytics information received.

The trigger conditions may depend on operator and implementation policy in the PCF. When a trigger condition happens, the PCF may check local configuration or evaluate operator policy to decide if any analytics information is needed and if so, initiate a subscription to the analytics information from the NWDAF directly or via DCCF, if deployed. The PCF may, upon a request from AF/NEF for negotiation for future background data transfer, subscribe to the network analytics related to "Network Performance" from the NWDAF directly or via DCCF, if deployed to assist in determination of BDT policies as described in clause 6.1.2.4. The PCF may, upon AM or UE or SM Policy Association establishment or modification request from the AMF or SMF, or based on notifications received from UDR or CHF on UE subscription change, decide that network analytics related to "Abnormal behaviour", "UE Mobility" or "UE Communication" of the UE, "Session Management Congestion Control Experience", "DN Performance", "User Data Congestion" is needed for policy decision and therefore subscribe to notifications of network analytics related to "Abnormal behaviour", "UE Mobility" or "UE Communication" of the UE from the NWDAF. The PCF may, upon reception of analytics information, subscribe to other analytics information from the NWDAF directly or via DCCF, if deployed. The PCF may use the network analytics information as input to its policy decision to apply operator defined actions for session management related policy control (as described in clauses 6.1.3), non-session management related policy control (as described in clause 6.1.2) and network slice related policy control (as described in clause 6.1.4. Examples of operator policies including network analytics information as inputs for policy decisions included below:

• Based on the notification of "Load Level Information" of the Network Slice Instance, the PCF may verify if the RFSP index value needs to be modified for a SUPI for which an AM Policy Association is created; this is based on operator policies in the PCF, as defined in clause 6.1.2.1.
• Based on the "Service Experience" statistics or predictions, the PCF may check the 5QI values assigned to the Application, and may use this as input to calculate and update the authorized QoS for a service data flow template.
• The PCF may use the network analytics related to "Network Performance" as input to calculate the background data transfer policies that are negotiated with the ASP, as defined in clause 6.1.2.4.
• Based on the UE mobility statistics or predictions, the PCF may adjust Service Area Restriction as defined in clause 6.1.2.1.
• The PCF may use the network analytics related to "Unexpected UE location" as input to determine the Service Area Restrictions defined in clause 6.1.2.1, "Suspicion of DDoS attack" or "Too frequent Service Access" to request the SMF to terminate the PDU Session as defined in clause 6.1.3.6, "Wrong destination address" to perform gating of a service data flow as defined in clause 6.1.3.6 and "Unexpected long-live/large rate flows" to perform QoS related policies such as gating or policing as defined in clause 6.2.1.1.
• Based on the WLAN performance statistics or predictions, the PCF may update WLANSP as defined in clause 6.1.2.2.1.
• Based on the "User Data Congestion" statistics or predictions including the list of applications contributing the most to the traffic the PCF may perform SM Policy Association modifications to update policies in the SMF for the PDU sessions handling traffic from those applications.
• The PCF may use the network analytics on "Service Experience" for an Application Identifier, "any RAT type" and/or "any Frequency value" to determine the RFSP Index value for running this application, as described in clause 6.1.2.1.
• The PCF may also use the network analytics as input to its policy decision to apply operator defined actions for example for the UE context(s) or PDU Session(s).
• Based on the notification of "Load Level Information" for network slice(s), the PCF may give priority to consider the one with lowest load for an application, and the PCF may update URSP on Network Slice Selection Policy.
• Based on the "UE communication" statistics or predictions, the PCF may consider the DNN in Traffic characterization and associated Traffic Volume, Spatial validity and inactivity time, and the PCF may update URSP on DNN Selection Policy for associated UEs.
• Based on the "Dispersion Analytics" statistics or predictions for Data Volume Dispersion in network slice(s), the PCF may calculate the average data rate in the network slice, and the PCF may update URSP on Network Slice Selection Policy for the associated UEs.
• Based on the "Session Management Congestion Control Experience" statistics or predictions for PDU Session(s) associated with corresponding S-NSSAI(s) or DNN for a UE, PCF may give priority to consider the S-NSSAI or the DNN that provides the lowest experience level of Session Management Congestion Control, and then the PCF may update URSP on Network Slice Selection Policy and/or DNN Selection Policy for the UE.
• Based on the "Network Performance" statistics or predictions on gNB status information, gNB resource usage, communication performance and mobility performance in an Area of Interest, the PCF may consider to offload the traffic to non-3GPP access for the number of UEs that are located in that Area of Interest, and the PCF may update URSP on Non-Seamless Offload Policy for associated UEs.
• Based on the "User Data Congestion" statistics or predictions including the list of applications contributing the most to the traffic, the PCF may consider to offload the traffic to non-3GPP access for those applications, and the PCF may update URSP on Non-Seamless Offload Policy for those applications.
• Based on the "DN Performance" statistics or predictions for user plane performance for an application, the PCF may consider the DNN with higher performance, and the PCF may update URSP on DNN Selection Policy for the application.

Examples of operator policies including combination of multiple network analytics as inputs for policy decisions are included below:

• Based on the notification of application(s) in use, provided by "UE Communication" analytics, the PCF may request the "Service Experience" analytics (optionally per RAT Type and/or per Frequency) for each application in use as defined in the list of examples of operator policies that may include network analytics as input for a policy decision.
• Based on the notification of "User Data Congestion", the PCF may further request the NWDAF directly or via DCCF, if deployed, to report the "Data Dispersion Analytics" of either a UE or just the Top Heavy UEs located at the congested area of interest. To mitigate the reported or predicted congestion at the area of interest, the PCF may perform:
  • AM Policy Association modification to update UE-AMBR, RFSP index and/or service area restriction, for those UEs reported as heavy users.
  • SM Policy Association modification to update the policies in the SMF for those UEs reported as heavy users.
  • UE Policy Association establishment/modification: Based on the "Load level information", "Service Experience", "Network Performance", "Abnormal behaviour", "UE Mobility", "UE Communication", "User Data Congestion", "Data Dispersion", "Session Management Congestion Control Experience", "DN Performance", "User Data Congestion" and "WLAN performance" statistics or predictions, the PCF uses analytics results from NWDAF to select proper values of URSP rules provided to UEs.
  • Based on the notification of Spatial validity for application(s) in use, provided by "UE Communication" analytics, the PCF may request the "WLAN performance" analytics for the Area of Interest derived from the Spatial validity of "UE Communication" analytics, and the PCF may update URSP on Non-Seamless Offload Policy for associated UEs.

The access and mobility related policy control encompasses the management of service area restrictions, the management of the RFSP Index, the management of the UE-AMBR, the management of the UE Slice-MBR and the management of the SMF selection. This clause defines the management of service area restrictions and RFSP Index for a UE registered over 3GPP access. The management of service area restrictions for a 5G-RG or a FN-CRG using W-5GAN are specified in TS 23.316. The management of service area restrictions enables the PCF of the serving PLMN (e.g. V-PCF in roaming case) to modify the service area restrictions used by AMF as described in clause 5.3.4 of TS 23.501. A UE's subscription may contain service area restrictions, which may be further modified by PCF based on operator defined policies at any time, either by expanding a list of allowed TAIs or by reducing a non-allowed TAIs or by increasing the maximum number of allowed TAIs. Operator defined policies in the PCF may depend on input data such as UE location, time of day, information provided by other NFs such as an AF request to change the service coverage, network analytics from NWDAF, etc. The AMF may report the subscribed service area restrictions received from UDM during Registration procedure or when the AMF changed, the conditions for reporting are that local policies in the AMF indicate that access and mobility related policy control is enabled. The AMF reports the subscribed service area restrictions to the PCF also when the policy control request trigger for service area restrictions changes, as described in clause 6.1.2.5, is met. The AMF receives the modified service area restrictions from the PCF. The AMF stores them and then uses it to determine mobility restriction for a UE. The PCF may indicate to the AMF that there is an unlimited service area. The service area restrictions consist of a list of allowed TAI(s) or a list of non-allowed TAI(s) and optionally the maximum number of allowed TAIs. The management of the RFSP Index enables the PCF to modify the RFSP Index used by the AMF to perform radio resource management functionality as described in clause 5.3.4 of TS 23.501. The PCF modifies the RFSP Index based on operator policies that take into consideration e.g. accumulated usage, load level information per network slice instance, the indication that high throughput is desired for a specific application traffic or independently of the application in use and other information described in clause 6.1.1.3. If the PCF determines to modify the RFSP index value to indicate a change in priority from 5G access to 4GEPC/E-UTRAN access for the UE, the PCF may, based on operator policy, includes a RFSP Index in Use Validity Time of the RFSP Index. The subscribed RFSP Index may be further adjusted by the PCF based on operator policies at any time. The determination of the RFSP Index value requires to configure the PCF with the mapping of RAT Type and/or Frequency value to the RFSP Index that will be sent to RAN. Operator policies in the PCF may determine that the access and mobility related policy information (e.g. RFSP index value or service area restrictions) can change at the start and stop of an application traffic detection, at the start and stop of a SM Policy Association to a DNN and S-NSSAI, or immediately. In the former case, the PCF subscribes to the SMF for application traffic detection as described in clause 6.2.2.5. In addition, when the PCF evaluates that the access and mobility related policy information need any changes, the PCF reports it to the AF if the AF has subscribed to the notification on outcome of service area coverage change as defined in clause 6.1.3.18. For radio resource management, the AMF may report the subscribed RFSP Index received from UDM during the Registration procedure or when the AMF changed. The conditions for reporting are that local policies in the AMF indicate that access and mobility related policy control is enabled. The AMF reports the subscribed RFSP Index to the PCF when the subscription to the RFSP Index change to the PCF is met. The AMF receives the modified RFSP Index from the PCF. Upon change of AMF, the source AMF informs the PCF that the UE context was removed in the AMF in the case of inter-PLMN mobility. The management of UE-AMBR enables the PCF to provide the UE-AMBR information to the AMF based on serving network policy. The AMF may report the subscribed UE-AMBR received from UDM. The conditions for reporting are that the PCF provided Policy Control Request Triggers the AMF to report subscribed UE-AMBR. The AMF receives the modified UE-AMBR from the PCF. The AMF provides a UE-AMBR value of the serving network to the RAN as specified in clause 5.7.2.6 of TS 23.501. The management of the SMF selection enables the PCF to instruct the AMF to contact the PCF during the PDU Session Establishment procedure to perform a DNN replacement, as specified in clause 5.6.1 of TS 23.501. To indicate the conditions to check whether to contact the PCF at PDU Session establishment (as specified in clause 6.1.2.5), the PCF provides the Policy Control Request Triggers SMF selection management and, if necessary Change of the Allowed NSSAI, together with SMF selection management related policy information (see clause 6.5) during UE Registration procedure and at establishment of the AM Policy Association. The PCF may update the SMF selection management information based on a PCF local decision or upon being informed about a new Allowed NSSAI. The AMF applies the updated SMF selection management information to new PDU Sessions only, i.e. already established PDU Sessions are not affected. The optional management of UE-Slice-MBR enables the PCF to modify the value in the list of Subscribed UE-Slice-MBR assigned to a SUPI based on serving network policies, if the HPLMN permits based on roaming agreement. The AMF reports the Subscribed UE-Slice-MBR for each S-NSSAI of the serving network. The S-NSSAI of the VPLMN is derived from the Subscribed S-NSSAI by the AMF and provided to the PCF. The AMF may provide the Subscribed S-NSSAI together with the S-NSSAI of the VPLMN. The conditions for reporting are defined in clause 6.1.2.5. The PCF returns the authorized UE-Slice-MBR for the S-NSSAI of the serving network. The AMF receives the authorized list of UE-Slice-MBR value for each S-NSSAI for which it has provided the Subscribed UE-Slice-MBR from the PCF. Then the AMF provides the authorized list of UE-Slice-MBR for the S-NSSAIs in the Allowed S-NSSAI to the RAN as specified in clause 5.7.1.10 of TS 23.501. The optional management of 5G access stratum time distribution enables the PCF for the UE to instruct the AMF about the 5G access stratum time distribution parameters, i.e., 5G access stratum time distribution indication (enable, disable). Optionally, when 5G access stratum time distribution or (g)PTP time synchronization is enabled, the PCF for the UE instructs the AMF about the Uu Time synchronization error budget. In the case that the PCF for the UE (providing the access and mobility related policy information) and the PCF for the PDU Session of this UE (providing the Session Management related policies) are separate PCF instances, the following applies:

• If the PCF for the UE determines that the access and mobility related policy information can change at the start and stop of an application traffic detection, the following applies:
  • The PCF for the UE may subscribes to be notified about the PCF binding information when a PCF for the PDU Session (of this UE) is registered in the BSF, including the SUPI, DNN, S-NSSAI. The DNN, S-NSSAI is either provided by the AF or locally configured in the PCF for certain Application Identifier(s). An alternative mechanism for the PCF for the UE to be notified of the PCF for the PDU Session of this UE is to request the AMF to send to the PCF for the PDU Session of the DNN, S-NSSAI, via SMF, the request for notification of SM Policy Association establishment. In this case, the PCF for the PDU Session should subscribe Request for notification on SM Policy Association establishment or termination Policy Control Request Trigger as described in clause 6.1.3.5 to get the binding information of PCF for the UE (as defined in clause 6.1.1.2.2).
  • When the PCF for the UE is notified that PCF for the PDU Session is registered, either via the BSF that provides the UE address, DNN and the PCF address, PCF instance Id and PCF set id if available or via PCF for the PDU Session when it received a request for notification from the SMF. The PCF for the UE may subscribe to the "start/stop of application traffic detection" event defined in clause 6.1.3.18 or trigger a policy decision if there is a SM Policy Association to the DNN, S-NSSAI.
  • The reporting of "start/stop of application traffic detection" to the PCF for the UE is used as input for a policy decision to change the access and mobility related policy information.
• If the PCF for the UE determines that the access and mobility related policy information can change at the establishment and termination of a SM Policy Association to a DNN and S-NSSAI base on the notification sent by the BSF, the PCF may indicate to the BSF to report the registration of a PCF for the PDU Session when the first SM Policy Association is established and the deregistration of the PCF for the PDU Session when the last SM Policy Association is terminated for a DNN, S-NSSAI.
• The PCF for the UE checks if an AF is subscribed to be notified on outcome of service area coverage change, using the related event defined in clause 6.1.3.18.

The AF may contact the PCF via the NEF (and Npcf_BDTPolicyControl_Create service operation) to request a time window and related conditions for future background data transfer (BDT). The AF request shall contain an ASP identifier, the volume of data to be transferred per UE, the expected amount of UEs, the desired time window, the External Group Identifier and optionally, Network Area Information, MAC address or IP 3-tuple to identify the Application server, request for notification. The AF provides as Network Area Information either a geographical area (e.g. a civic address or shapes), or an area of interest that includes a list of TAs or list of NG-RAN nodes and/or a list of cell identifiers. When the AF provides a geographical area, then the NEF maps it based on local configuration into of a short list of TAs and/or NG-RAN nodes and/or cells identifiers that is provided to the PCF. The NEF may map the ASP identifier based on local configuration to a DNN and S-NSSAI that is in addition provided to the PCF. The MAC address or IP 3-tuple to identify the Application server may be provided by the AF or may be locally configured at the PCF and it is used for the generation of a URSP rule for the application as well as a PCC rule for the application traffic. The request for notification is an indication that the ASP accepts that the BDT policy can be re-negotiated using the BDT warning notification procedure described in clause 4.16.7.3 of TS 23.502. The PCF shall first retrieve all existing BDT policies stored for any ASP from the UDR. The PCF may retrieve analytics on "Network Performance" from NWDAF following the procedure and services described in TS 23.288. Afterwards, the PCF shall determine, based on the information provided by the AF, the analytics on "Network Performance" if available and other available information (e.g. network policy and existing BDT policies) one or more BDT policies. The PCF may be configured to map the ASP identifier to a target DNN and S-NSSAI if the NEF did not provide the DNN, S-NSSAI to the PCF. A BDT policy consists of a recommended time window for the background data transfer, a reference to a charging rate for this time window and optionally a maximum aggregated bitrate (indicating that the charging according to the referenced charging rate is only applicable for the aggregated traffic of all involved UEs that stays below this value). Finally, the PCF shall provide the candidate list of BDT policies to the AF via NEF together with the Background Data Transfer Reference ID. If the AF received more than one BDT policy, the AF shall select one of them and inform the PCF about the selected BDT policy. The selected BDT policy together with the Background Data Transfer Reference ID, the network area information, the volume of data to be transferred per UE, the expected amount of UEs, ASP identifier, MAC address or IP 3-tuple to identify the Application server, the one or more route selection component (DNN, S-NSSAI), the desired time window and whether the AF accepts BDT policy re-negotiation or not is stored by the PCF in the UDR as Data Set "Policy Data" and Data Subset "Background Data Transfer data". The same or a different PCF can retrieve this BDT policy and the corresponding related information from the UDR and take them into account for future decisions about BDT policies related to the same or other ASPs. When the AF wants to apply the Background Data Transfer Policy to an existing session, then the AF will, at the time the BDT is about to start, provide, for each UE, the Background Data Transfer Reference ID together with the AF session information to the PCF (via the N5 interface). The PCF retrieves the corresponding BDT policy from Policy Data Set in the UDR and derives the PCC rule for the BDT according to this transfer policy. When the AF wants to apply the Background Data Transfer Policy to a future session, then the AF provides, to the NEF, the Background Data Transfer Reference ID together with the External Identifier (i.e. GPSI) or External Group Identifier of the UE(s) that are subject to the policy. The NEF translates the External Group Identifier into the Internal Group Identifier or the External Identifier into a SUPI. The NEF stores the Background Data Transfer Reference ID, in the UDR as Application Data Set and Background Data transfer data Subset for an Internal Group Identifier or a SUPI and the ASP identifier requesting to apply the Background Data transfer Policy to a future session for the UE(s). A PCF that serves the UE(s) (i.e. the PCF that serves the UE for UE Policies) may retrieve the Background Data Transfer Reference ID by retrieving the UE's Application Data from the UDR or by subscribing to notifications of changes to the UEs' Application Data in the UDR. Furthermore, the PCF retrieves the specific Background Data Transfer Policy and the corresponding network area information and the MAC address or IP 3-tuple to identify the Application server based on the received Background Data Transfer Reference ID stored as Policy Data Set from the UDR. When the PCF determines to send a URSP rule related to the Background Data Transfer Policy to the UE, the PCF creates the URSP rule using the MAC address or IP 3-tuple (to identify the Application server) as Traffic descriptor. The RSD part of the URSP rule is populated with the S-NSSAI and DNN associated with the ASP identifier. The Route Selection Validation Criteria of the URSP rule (see clause 6.6.2.1) is populated with the Time Window set to the recommended time window of the BDT policy and, if the BDT policy is not applicable for the whole network, the Location Criteria is set to the network area information of the BDT policy. The PCF will store the URSP rule in the UDR as part of the UE's Policy Set Entry. The PCF will use the associated S-NSSAI and DNN associated with the ASP identifier stored in the Application Data to store the Background Data Transfer Reference ID in the UE's PDU Session policy control subscription information (see clause 6.2.1.3). The PCF uses local policies to decide when the URSP rule related to the Background Data Transfer Policy is going to be sent to the UE. The PCF may, based on operator configuration, trigger the UE Configuration Update procedure when the AF request to apply the BDT policy to a future session is received, or the PCF may wait until receiving a notification from the AMF that the UE has entered the Tracking Area or Presence Area where the BDT policy applies, and/or the PCF may wait until the time window when the BDT policy applies is approaching. The UE uses the Route Selection Validation Criteria to determine whether or not a PDU Session should be established. The Time Window and Location Criteria are not required to be checked again during the lifetime of the PDU Session. The UE's support of the Validation Criteria in a URSP rule is optional. When the PDU Session is established, the PCF that serves the PDU Session will use the Background Data Transfer Reference ID in the UE's PDU Session policy control subscription information (see clause 6.2.1.3) to retrieve the corresponding BDT policy and the related information from the UDR and derives the PCC rule for the BDT according to this information. The PCF may reject the establishment of an SM Policy Association, (described in clause 4.16.4 of TS 23.502), if the S-NSSAI and DNN corresponding to a BDT policy and the Validation Criteria are not fulfilled. And based on this feedback, SMF will reject the PDU Session establishment. After successful PDU Session setup, PCF may trigger PDU Session release when Validation Criteria are no longer fulfilled. The PCF may subscribe to analytics on "Network Performance" from NWDAF for the area of interest and time window of a BDT policy following the procedure and services described in TS 23.288 indicating a Reporting Threshold in the Analytics Reporting information. The value for the Reporting Threshold is set by the PCF based on operator configuration. When the NWDAF determines that the network performance goes below the threshold, the NWDAF notifies the PCF with the network performance analytics in the area of interest and time window. When the PCF gets the notification from the NWDAF, the PCF may try to re-negotiate the affected BDT policies with AFs that accepted BDT policy re-negotiation. To do this, the PCF retrieves all the BDT policies together with their additionally stored AF provided information (e.g. their corresponding desired time window) from the UDR, identifies the BDT policies that are not desirable anymore due to the degradation of the network performance and tries to calculate new candidate BDT policies for the ASP(s) to select from. If the PCF does not find any new candidate BDT policy or the related AF did not accept BDT policy re-negotiation, the previously negotiated BDT policy shall be kept and no interaction with the ASP shall occur. If the PCF finds one or more new candidate BDT policies, the PCF notifies the related ASP(s) on both the BDT policy that is not valid any longer and the candidate BDT policies via NEF. The PCF invalidates the BDT policy stored in the UDR for the corresponding BDT reference ID while the BDT policy re-negotiation is ongoing. The PCF shall reject a PDU Session request corresponding to an invalid BDT policy. When the AF receives the notification, the AF may select one of the BDT policies included in the candidate list, and then inform the PCF about the selected BDT policy. The PCF stores the newly selected BDT policy into the UDR for the corresponding Background Data Transfer Reference ID and removes the BDT policy that is no longer valid. The PCF is also updating the URSP rule corresponding to the BDT policy with the new Validation Criteria in the Policy Set Entry of all UEs. As a consequence, the PCF identifies the UEs for which the BDT policy was already provided and updates the URSP rule corresponding to the BDT policy using the procedure described in clause 4.16.12.2 of TS 23.502. If the AF does not select one of the BDT policies included in the candidate list, the PCF removes the BDT policy stored in the UDR together with the corresponding Background Data Transfer Reference ID and all related information as well as the URSP rule corresponding to the BDT policy in the Policy Set Entry of all UEs. As a consequence, the PCF identifies the UEs for which the URSP rule corresponding to the BDT policy was already provided and removes the URSP rule corresponding to the BDT policy using the procedure described in clause 4.16.12.2 of TS 23.502.

The Policy Control Request Triggers relevant for AMF and 3GPP access type are listed in Table 6.1.2.5-1 and define the conditions when the AMF shall interact again with PCF after the AM Policy Association Establishment or UE Policy Association Establishment. The PCF provides Policy Control Request Triggers to the AMF indicating a specific UE (i.e. SUPI or PEI) in the Policy Association establishment and modification procedures defined in the TS 23.502. The Policy Control Request Triggers are transferred from the old AMF to the new AMF when the AMF changes. The Policy Control Request Triggers are not applicable any longer at termination of the AM Policy Association or termination of UE Policy Association.

If the Location change trigger are armed, the AMF shall activate the relevant procedure which reports any changes in location as explained in clause 5.6.11 of TS 23.501 by subscribing with the Npcf_AMPolicyAssociation service or Npcf_UEPolicyAssociation service. The reporting is requested to the level indicated by the trigger (i.e. Tracking Area). The AMF reports that the Location change trigger was met and the Tracking Area identifier. If the Change of UE presence in Presence Reporting Area trigger is armed, i.e. the PCF subscribed to reporting change of UE presence in a Presence Reporting Area, including a list of PRA ids. In addition, for "UE-dedicated Presence Reporting Area" a short list of TAs and/or NG-RAN nodes and/or cells identifiers is included. Then, the AMF shall activate the relevant procedure which reports any Change of UE presence in Area of Interest as explained in clause 5.6.11 of TS 23.501. The reporting is requested for the specific condition when target UE moved into a specified PRA. The AMF reports the PRA Identifier(s) and indication(s) whether the UE is inside or outside the Presence Reporting Area(s) to the PCF. The Service Area restriction change trigger and the RFSP index change trigger shall trigger the AMF to interact with the PCF for all changes in the Service Area restriction or RFSP index data received in AMF from UDM. The reporting includes that the trigger is met and the subscribed Service Area restriction or the subscribed RFSP index provided to AMF by UDM, as described in clause 6.1.2.1. The Change of the Allowed NSSAI trigger shall trigger the AMF to interact with the PCF if the Allowed NSSAI has been changed. The reporting includes that the trigger is met and the new Allowed NSSAI. The PCF may update RFSP index and/or SMF selection management related policy information (described in clause 6.5) in the AMF based on the Allowed NSSAI. The Generation of a Target NSSAI trigger shall trigger the AMF to interact with the PCF. The reporting includes that the trigger is met and the generated Target NSSAI. The PCF may generate RFSP index associated with the Target NSSAI. The UE-AMBR change trigger shall trigger the AMF to interact with the PCF for all changes in the subscribed UE-AMBR data received in AMF from UDM. The reporting includes that the trigger is met and the subscribed UE-AMBR provided to AMF by UDM, as described in clause 6.1.2.1. The Slice-UE-MBR change trigger shall trigger the AMF to interact with the PCF for all changes in the Subscribed UE-Slice-MBR for each subscribed S-NSSAI in the NSSAI with a Subscribed UE-Slice-MBR received at the AMF from UDM. The reporting includes that the trigger is met, as described in clause 6.1.2.1. If the PLMN change trigger is armed, the AMF shall report it to the PCF to trigger the update of V2X service authorization parameters to the UE as defined in clause 6.2.2 of TS 23.287 and to trigger the update of ProSe authorization parameters to the UE as defined in clause 6.2.2 of TS 23.304. The reporting includes the event with the serving PLMN ID. If the SMF selection management trigger is set, then the AMF shall contact the PCF when the AMF detects that the UE requested an unsupported DNN and the PCF indicated DNN replacement of unsupported DNNs in the Access and mobility related policy information (see clause 6.5). The PCF shall select a DNN and provide the selected DNN to the AMF. If the SMF selection management trigger is set, then the AMF shall contact the PCF when the UE requested a DNN within the list of DNN candidates for replacement for the S-NSSAI indicated in the Access and mobility related policy information (see clause 6.5). The PCF shall select the DNN and provide the selected DNN to the AMF. If the Connectivity state changes trigger is set, then the AMF shall notify the PCF when the UE connectivity state is changed e.g. from IDLE to CONNECTED. The AMF then reset the trigger. The NWDAF info change trigger shall trigger the AMF to interact with the PCF when the list of NWDAF Instance IDs used for the UE or associated Analytics IDs used for the UE at the AMF are changed in the AMF. If the Satellite backhaul category change trigger is armed, the AMF shall report the satellite backhaul category to the PCF. The PCF may take this into account to update UE Policy as defined in clause 6.1.2.2.

The AF may contact the PCF via the NEF (and Npcf_PDTQPolicyControl_Create service operation) to request a time window and related conditions for planned data transfer with QoS requirements (PDTQ). The AF request shall contain an ASP identifier, either a QoS Reference or individual QoS parameters and if the AF can adjust to different QoS parameter combinations, the AF may, in addition, provide Alternative Service Requirements in a prioritized order as defined in clause 6.1.3.22, the expected number of UE, the desired time window, and optionally, Network Area Information, and request for notification. The AF provides as Network Area Information either a geographical area (e.g. a civic address or shapes), or an area of interest that includes a list of TAs or list of NG-RAN nodes and/or a list of cell identifiers. When the AF provides a geographical area, then the NEF maps it based on local configuration into of a short list of TAs and/or NG-RAN nodes and/or cells identifiers that is provided to the PCF. The request for notification is an indication that the ASP accepts that the PDTQ policy can be re-negotiated using the PDTQ warning notification procedure described in clause 5.2.5.9 of TS 23.502. The PCF shall first retrieve all existing PDTQ policies stored for any ASP from the UDR. The PCF subscribes to Analytics ID from NWDAF following the procedure and services described in TS 23.288. Afterwards, the PCF shall determine, based on the information provided by the AF, the analytics and other available information (e.g. network policy and existing PDTQ policies) one or more PDTQ policies. An PDTQ policy consists of a recommended time window for the traffic transfer for each of the AF sessions for each of the UEs involved. Finally, the PCF shall provide the candidate list of PDTQ policies to the AF via NEF together with the PDTQ Reference ID. If the AF received more than one PDTQ policy, the AF shall select one of them and inform the PCF about the selected PDTQ policy. The selected PDTQ policy together with the PDTQ Reference ID, the network area information, ASP identifier, the desired time window and whether the AF accepts PDTQ policy re-negotiation or not is stored by the PCF in the UDR as Data Set "Policy Data" and Data Subset "PQDT data". The same or a different PCF can retrieve this PDTQ policy and the corresponding related information from the UDR and take them into account for future decisions about PDTQ policies related to the same or other ASPs. When the AF wants to apply the PDTQ to an existing session, then the AF will, at the time the traffic transfer is about to start, invoke, for each UE, the Nnef_AFsessionWithQoS/Npcf_PolicyAuthorization including the individual QoS that was previously negotiated.