Content for  TS 23.503  Word version:  19.1.0

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 are listed in the tables below 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 Change of the Partially Allowed NSSAI trigger shall trigger the AMF to interact with the PCF if the Partially Allowed NSSAI has been changed. The reporting includes that the trigger is met and the new Partially Allowed NSSAI. The PCF may update RFSP index related policy information (described in clause 6.5) in the AMF based on the Partially Allowed NSSAI. The Change of the S-NSSAI(s) rejected partially in the RA shall trigger the AMF to interact with the PCF if the S-NSSAI(s) rejected partially in the RA has been changed. The reporting includes that the trigger is met and the new S-NSSAI(s) rejected partially in the RA. The PCF may update RFSP index related policy information (described in clause 6.5) in the AMF based on the S-NSSAI(s) rejected partially in the RA. The Change of the rejected S-NSSAI(s) for the RA shall trigger the AMF to interact with the PCF if the rejected S-NSSAI(s) for the RA has been changed. The reporting includes that the trigger is met and the new rejected S-NSSAI(s) in the RA. The PCF may update RFSP index related policy information (described in clause 6.5) in the AMF based on the rejected S-NSSAI(s) for the RA. The Change of the Pending NSSAI trigger shall trigger the AMF to interact with the PCF if the Pending NSSAI has been changed. The reporting includes that the trigger is met and the new Pending NSSAI. The PCF may update RFSP index related policy information (described in clause 6.5) in the AMF based on the Pending NSSAI. If the Configured NSSAI change trigger is armed, the AMF shall report the Configured NSSAI and mapping of each S-NSSAI of the Configured NSSAI to corresponding HPLMN S-NSSAI values as defined in clause 5.15.4.1.1 of TS 23.501 to the PCF. The V-PCF sends the HPLMN S-NSSAI to the H-PCF after mapping the S-NSSAI of the VPLMN into the S-NSSAI of the HPLMN as described in clause 4.15.6.7 of TS 23.502. The H-PCF may take this into account to update UE Policy as defined in clause 6.1.2.2. When the UE is connected to a non-3GPP access, the PCF may take this into account to update UE Policy e.g. ANDSP as defined in clause 6.1.2.2. 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, to trigger the update of ProSe authorization parameters to the UE as defined in clause 6.2.2 of TS 23.304, to trigger the update of A2X service authorization parameters to the UE as defined in clause 6.3.2.2 of TS 23.256 and to trigger the update of Ranging/Sidelink Positioning authorization parameters to the UE as defined in clause 6.2.2 of TS 23.586. 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 slice replacement management trigger is set, the AMF shall contact the PCF:

• in Case i) when AMF cannot determine the Alternative S-NSSAI for the S-NSSAI(s), e.g. NSSF doesn't provide Alternative S-NSSAI and there is no Alternative S-NSSAI in the AMF local configuration. The reporting includes that the trigger is met, the S-NSSAI(s) that requires slice replacement, as described in clause 6.1.2.1.
• in Case ii) if the AMF can determine the Alternative S-NSSAI for the S-NSSAI(s) when network slice replacement applies for some S-NSSAIs, or if the AMF determines to stop the network slice replacement for some S-NSSAI(s) after receiving the Alternative S-NSSAI from OAM or network slice availability notification from NSSF. The reporting includes the trigger is met and S-NSSAI(s) that requires slice replacement and the corresponding Alternative S-NSSAI. If no corresponding Alternative S-NSSAI is provided, the PCF is informed no Alternative S-NSSAI is mapped to the replaced S-NSSAI(s) any longer.

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 indicate the change between different types of satellite backhaul, or the change between satellite backhaul and non-satellite backhaul (as specified in clause 5.43.4 of TS 23.501) to the PCF. The PCF may take this into account to update UE Policy as defined in clause 6.1.2.2. The AMF indicates a PCRT corresponding to wrong non-3GPP access when the UE has connected to a non-3GPP access that is not supporting the configured NSSAI. The AMF also indicates whether it is for untrusted or trusted non-3GPP access. This triggers the PCF to update the relevant policies on the UE e.g. WLANSP or Non-3GPP access network selection information. If the LBO Information change is armed, the AMF shall report the LBO Information (i.e. DNN(s) and/or S-NSSAI(s) that are allowed in VPLMN for LBO roaming in SMF Selection Data) to the PCF when there is change in the LBO Information. If the Access Type change trigger is met, the AMF reports the changed, the added or the removed Access Type and/or the changed RAT Type to the PCF.

The AF may contact the PCF via the NEF by invoking Npcf_PDTQPolicyControl_Create service operation to request a time window for planned data transfer with QoS requirements (PDTQ). The AF request shall contain an ASP identifier, either a QoS Reference or individual QoS parameters, the Number of UEs, the list of Desired time windows 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, Network Area Information, and Request for notification. As Network Area Information, the AF may provide either a geographical area (e.g. a civic address or shapes), or an area of interest that includes a list of TAs and/or a list of NG-RAN nodes or a list of cell identifiers. When the AF provides a geographical area, the NEF maps it, based on local configuration, into an area of interest (i.e. a list of TAs or NG-RAN nodes list or cells identifiers list) and provides it to the PCF. The Request for notification can be included in the AF request to indicate that the ASP accepts that the PDTQ policy can be re-negotiated using the PDTQ warning notification procedures described in clause 4.16.15.2 of TS 23.502. The PCF shall firstly retrieve all existing PDTQ policies stored for any ASP from the UDR. Then the PCF subscribes to "Network Performance" analytics or "DN Performance" analytics from NWDAF following the procedures and services described in TS 23.288. The PCF may request threshold reporting or periodic reporting. Afterwards, the PCF shall determine one or more PDTQ policies, based on the information provided by the AF, the analytics on "Network Performance" or "DN Performance" and other available information (e.g. network policy and existing PDTQ policies). A 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 and corresponding PDTQ Reference ID. The selected PDTQ policy together with the PDTQ Reference ID, the Network Area Information (if provided by the AF), ASP identifier, the list of desired time windows, the QoS Reference or individual QoS parameters, the Alternative Service Requirements in a prioritized order (if provided by the AF), the Number of UEs and the Request for notification of PDTQ policy re-negotiation (if provided by the AF) are stored by the PCF in the UDR as Data Set "Policy Data" and Data Subset "Planned Data Transfer with QoS requirements 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 recommended time window in the selected PDTQ policy is about to start, and the AF needs to make use of the PDTQ policy for existing or new sessions, the AF invokes the Nnef_AFsessionWithQoS_Create/Npcf_PolicyAuthorization_Create in order to set up the AF session with the required QoS. The PCF may subscribe to analytics on "Network Performance" or "DN Performance" from NWDAF for the area of interest and time window of a PDTQ policy following the procedure and services described in TS 23.288 indicating a Reporting Threshold or periodic reporting 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 or DN Performance reaches the Reporting Threshold, the NWDAF notifies the PCF with the Network Performance analytics or DN Performance analytics for the requested area of interest and time window. When the PCF gets the notification from the NWDAF, the PCF may try to re-negotiate the affected PDTQ policies with AFs that accept PDTQ policy re-negotiation. If periodic reporting is received, the PCF shall determine, based on the latest analytics information and previously selected PDTQ policy, whether the PDTQ policy should be updated or not. If the PCF determines to update the PDTQ policy, the PCF may try to re-negotiate the affected PDTQ policies with AFs that accepted PDTQ policy re-negotiation. To do this, the PCF retrieves all the PDTQ policies together with the corresponding AF provided information (e.g. the corresponding list of Desired time windows) from the UDR, identifies the PDTQ policies that are not desirable anymore due to the degradation of the Network Performance or DN Performance and calculates new candidate PDTQ policies for the ASP(s). If the PCF cannot determine any new candidate PDTQ policy or the related AF has indicated it does not accept PDTQ policy re-negotiation, the previously negotiated PDTQ policy shall be kept and no interaction with the ASP shall occur. If the PCF determines one or more new candidate PDTQ policies, the PCF notifies the related ASP(s) of the candidate PDTQ policies and corresponding PDTQ reference ID via NEF. When the AF receives the notification, the AF may select one of the PDTQ policies included in the candidate list, and then inform the PCF about the selected PDTQ policy and corresponding PDTQ Reference ID. The PCF stores the newly selected PDTQ policy into the UDR for the corresponding PDTQ Reference ID and removes the PDTQ policy that is no longer valid. If the AF does not select any of the PDTQ policies included in the candidate list, the previously negotiated PDTQ policy shall be kept.