Content for TS 23.502 Word version: 19.1.0
1…
4.2.2.2.2
4.2.2.2.3…
4.2.2.3…
4.2.3…
4.2.3.3
4.2.4…
4.2.6
4.2.7…
4.2.9…
4.2.11…
4.2.11.5…
4.3…
4.3.2.2.2
4.3.2.2.3…
4.3.3…
4.3.3.3
4.3.4…
4.3.4.3
4.3.5…
4.3.5.2…
4.3.5.4…
4.3.5.6…
4.3.6…
4.4…
4.5…
4.9…
4.9.1.3…
4.9.2…
4.11…
4.11.1…
4.11.1.2.2
4.11.1.2.3
4.11.1.3…
4.11.1.3.3…
4.11.1.4…
4.11.1.5…
4.11.2…
4.11.3…
4.12…
4.12.6…
4.12a…
4.12b…
4.13…
4.13.4…
4.13.6…
4.14…
4.15…
4.15.3.2.5…
4.15.4…
4.15.6…
4.15.6.7…
4.15.6.13…
4.15.6.14…
4.15.9…
4.15.9.4…
4.15.13…
4.15.13.4…
4.16…
4.16.4…
4.16.8…
4.16.11…
4.16.14…
4.16.15…
4.17…
4.17.9…
4.18…
4.19…
4.22…
4.23…
4.23.7…
4.23.7.3.3
4.23.7.3.4…
4.23.9…
4.23.9.4…
4.23.11…
4.24…
4.25…
4.25.6…
4.26…
5…
5.2.3…
5.2.5…
5.2.6…
5.2.7…
5.2.8…
5.2.9…
5.2.12…
5.2.18…
A…
E…
F…
G
H…
4.16.15 Negotiations for planned data transfer with QoS requirements
4.16.15.1 General
4.16.15.2 Procedures
4.16.15.2.1 Procedures for negotiation of planned data transfer with QoS requirements
4.16.15.2.2 Procedure for PDTQ warning notification
4.16.16 Awareness of URSP Rule Enforcement
4.16.16.1 General
4.16.16.2 Forwarding of URSP Rule Enforcement Information (for non-roaming and HR roaming)
4.16.16.3 Forwarding of URSP Rule Enforcement Information (for LBO roaming)
...
...
4.16.15 Negotiations for planned data transfer with QoS requirements |R18| p. 547
4.16.15.1 General p. 547
The intent of this clause is to specify generic service procedures to enable the AF to negotiate viable time window for the planned application data transfer with specific QoS requirements and operational conditions via the support of the NEF.
The PDTQ policies are defined for a specific ASP and each PDTQ policy includes a recommended time window for the traffic transfer for each of the AF sessions involved.
The Network Performance analytics or DN Performance analytics for NWDAF as described in TS 23.288 will be subscribed by the PCF in order to assist its decision to derive the PDTQ policies.
One or more negotiated PDTQ policies could be provided by PCF to AF via NEF together with the PDTQ Reference ID. If the AF receives more than one PDTQ policies from the PCF, the AF will select one of them and inform the PCF about the selected PDTQ policy which will then be stored in the UDR. The selected PDTQ policy might be renegotiated, i.e. due to the degradation of the network performance. In this case, the PCF may determine a new list of candidate PDTQ policies and notify the AF via NEF. The AF may select one of the new PDTQ polices or not accept any of the PDTQ policies, it then notifies the PCF of the corresponding decision. Prior to the start of the selected time window for the planned data transfer, the AF requests the PCF to set up the AF session with required QoS. The PCF will then determine the appropriate PCC rules according to the AF request.
4.16.15.2 Procedures p. 547
4.16.15.2.1 Procedures for negotiation of planned data transfer with QoS requirements p. 547
This clause describes the PDTQ procedures to negotiate viable time window for the planned application data transfer via the support of the NEF.
Prior to the transmission of the Application AI/ML data, the AF negotiates with the 5G Core for the PDTQ policies that provide assistance for the application data transfer. The AF discovers its serving NEF, if it has not done so before, by using the mechanism described in clause 6.3.14 of TS 23.501.
Step 1a.
The AF invokes the Nnef_PDTQPolicyNegotiation_Create Request (ASP Identifier, Number of UEs, list of Desired time windows, QoS Reference or individual QoS parameters, Alternative Service Requirements (optional), Network Area Information, Request for notification, Application Identifier). The Request for notification is an indication that PDTQ warning notification can be sent to the AF.
Step 1b-1c.
The NEF may authenticate the AF and authorize the PDTQ request from the AF. If the authentication/authorization of the AF's request has failed, the NEF will respond to the AF's request through the Nnef_PDTQPolicyNegotiation_Create Response with a failure result and the following steps are skipped.
The NEF may map the ASP ID into DNN and S-NSSAI to be used in step 2.
Step 2.
Based on an AF request, the NEF may translate the information provided by the AF (e.g. Network Area Information, etc.) based on the local policy and invokes the Npcf_PDTQPolicyControl_Create (ASP Identifier, Number of UEs, list of Desired time windows, QoS Reference or individual QoS parameters, Alternative Service Requirements (optional), Network Area Information, Request for notification, Application Identifier) with the H-PCF to authorize the creation of the policy regarding the PDTQ. If the PCF was provided with Request for notification, then PCF will send PDTQ warning notification to the AF as specified in clause 4.16.15.2.2 to notify the AF when the network performance or DN Performance in the area of interest reaches the Reporting Threshold set by the PCF based on operator configuration or the PCF determines to update the previously selected PDTQ policy based on the latest periodic reported network performance or DN Performance analytics as described in clause 6.1.2.7 of TS 23.503.
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.
Step 3.
H-PCF queries the UDR to retrieve all existing PDTQ polices for all the ASPs using Nudr_DM_Query (Policy Data, Planned Data Transfer with QoS requirements) service operation.
Step 4.
The UDR provides all the stored PDTQ policies and corresponding related information (e.g. the Number of UEs, the list of Desired time windows) to the H-PCF.
Step 5.
Based on information provided by the AF and other available information, the H-PCF queries or/and subscribes to the NWDAF as defined in clause 6.6.4 or clause 6.14.4 of TS 23.288 to request the Network Performance analytics or the DN Performance analytics.
When requesting the Network Performance analytics or the DN performance analytics, if "any UE" is used, then the AoI information is used to identify the target gNB(s) for the prediction of the availability of the network resources.
The DNN, S-NSSAI and Application ID may be provided by H-PCF as Analytics Filter Information when requesting or subscribing to the relevant Analytic ID.
Step 6.
By referring to the outcome of the analytics report as described in clause 6.1.2.7 of TS 23.503, H-PCF determines one or more PDTQ policies. Each PDTQ policy includes a recommended time window for the traffic transfer for each of the AF sessions for each of the UEs involved.
Step 7.
The PCF sends one or more PDTQ policies to NEF in Npcf_PDTQPolicyControl_Create Response including the PDTQ Reference ID.
Step 8.
The NEF sends a Nnef_PDTQPolicyNegotiation_Create response to the AF to provide one or more PDTQ policies together with the PDTQ Reference ID. If the NEF received only one PDTQ policy from the PCF, steps 9-12 are not executed and the flow proceeds to step 13. Otherwise, the flow proceeds to step 9.
Step 9.
If more than one PDTQ policies were provided to the AF, the AF selects one of the PDTQ policies and notifies NEF for the selected PDTQ policy via Nnef_PDTQPolicyNegotiation_Update request together with the PDTQ Reference ID. The AF stores the PDTQ Reference ID for the future interaction with the PCF.
Step 10-12.
The NEF notifies H-PCF about the selected PDTQ policy by the AF. The H-PCF acknowledges NEF. The NEF responds to the AF request with a Nnef_PDTQPolicyNegotiation_Update Response.
Step 13-14.
The H-PCF stores the PDTQ Reference ID together with the new PDTQ policy in the UDR by invoking Nudr_DM_Update (PDTQ Reference ID, Policy Data, Planned Data Transfer with QoS requirements). The UDR sends a response to the H-PCF as acknowledgement.
4.16.15.2.2 Procedure for PDTQ warning notification p. 550
Step 1.
The AF can send a Stop notification by invoking Nnef_
The negotiation for PDTQ policy as described in clause 4.16.15.2.1 is completed. In addition, the PCF has subscribed to analytics on "Network Performance" or "DN Performance" from NWDAF for the area of interest and time window of a PDTQ policy following the procedures and services described in TS 23.288, including a Reporting Threshold in the Analytics Reporting information. The value for Reporting Threshold is set by the PCF based on operator configuration.
Step 2.
The PCF is notified with the Network Performance analytics or DN Performance analytics in the area of interest from the NWDAF when the NWDAF determines that the Network Performance or DN Performance reaches the Reporting Threshold as described for the Network Performance analytics or DN Performance analytics in TS 23.288.
Step 3.
The H-PCF requests from the UDR the stored PDTQ policies using Nudr_DM_Query (Policy Data, Planned Data Transfer with QoS requirements) service operation.
Step 4.
The UDR provides all the PDTQ Policies together with the relevant information received from the AFs (as defined in clause 6.1.2.7 of TS 23.503) to the H-PCF.
Step 5.
The H-PCF identifies the PDTQ Policies affected based on the notification received from NWDAF. For each of them, the H-PCF determines the ASP of which the PDTQ traffic will be influenced by the degradation of network Performance or DN Performance and which requested the H-PCF to send the notification. The PCF then performs the following steps for each of the determined ASPs, i.e. Steps 6 - 11 can occur multiple times (i.e. once per ASP).
Step 6.
The PCF decides based on operator policies, whether a new list of candidate PDTQ policies can be calculated for the ASP. If the PCF does not find any new candidate PDTQ policy, the previously negotiated PDTQ policy shall be kept, no interaction with that ASP shall occur and the procedure stops for that PDTQ policy.
Step 7.
The PCF sends the notification to the NEF by invoking Npcf_PDTQPolicyControl_Notify (PDTQ Reference ID, list of candidate PDTQ policies) service operation.
Step 8.
The NEF sends the PDTQ warning notification to the AF by invoking Nnef_PDTQPolicyNegotiation_Notify (PDTQ Reference ID, list of candidate PDTQ policies) service operation.
Step 9.
The AF checks the new PDTQ policies included in the candidate list in the PDTQ warning notification.
Step 10.
If the AF selects any of the new PDTQ policies, the steps 9-14 from clause 4.16.15.2.1 are executed with the difference that the AF has to respond as well when only one PDTQ policy was provided by the PCF and the PCF removes the no longer valid PDTQ policy from the UDR for the corresponding PDTQ Reference ID.
Step 11.
If the AF doesn't select any of the new PDTQ policies, the steps 9-12 from clause 4.16.15.2.1 are executed, with the AF indicating that none of the candidate PDTQ policies is acceptable. In this case, the AF response only includes PDTQ reference ID, but no PDTQ policy and the previously negotiated PDTQ policy shall be kept.
4.16.16 Awareness of URSP Rule Enforcement |R18| p. 551
4.16.16.1 General p. 551
Awareness of URSP rule enforcement is specified in clause 6.6.2.4 of TS 23.503.
The content of this clause describes the PCF procedures necessary to realize this functionality.
4.16.16.2 Forwarding of URSP Rule Enforcement Information (for non-roaming and HR roaming) p. 551
This procedure applies when the PCF serving the PDU session receives URSP rule enforcement information from the SMF and forwards this information to the (H-)PCF serving the UE (see clause 6.1.3.18 of TS 23.503 for non-roaming and HR roaming).
Step 1.
The UE Policy Association is established, as described in clause 4.16.11.
Step 2.
If the (H-)PCF indicates the UE to send reporting of URSP rule enforcement as described in clause 6.6.2.4 of TS 23.503, then depending on operator policies in the (H-)PCF, the (H-)PCF may subscribe to the BSF, then step 3 follows, or provides its PCF binding information to the AMF in step 1 with the indication to be notified about the PCF for the PDU Session for a UE, then step 4 follows.
Step 3.
The (H-)PCF for the UE determines that URSP rules depend on the UE reporting of URSP rule enforcement, it then subscribes to the BSF to be notified when a PCF for the PDU Session for this SUPI is registered in the BSF, by invoking Nbsf_Management_Subscribe (SUPI; DNN). Steps 4 and 5 are repeated for each PCF registered for a PDU Session to a SUPI included in the Nbsf_Management .
Step 4.
The (H-)SMF establishes a SM Policy Association as described in clause 4.16.4. The allocated UE address/prefix, SUPI, DNN, S-NSSAI and the PCF address is registered in the BSF, as described in clause 6.1.1.2.2 of TS 23.503. The SMF may provide the PCF binding information (address(es) of PCF for UE, instance id of PCF for UE) which receives from AMF to the PCF for session during SM Policy Association establishment procedure. If the (H-)SMF has received UE report of URSP rule enforcement via PDU session establishment as described in clause 4.3.2 (step 4), it includes the received traffic information in the SM Policy Association establishment request.
Step 5a.
If the (H-)PCF for the UE subscribed to the BSF in step 3, then the BSF notifies that a PCF for the PDU Session is registered in the BSF, by invoking Nbsf_Management_Notify (UE address(es), PCF address, PCF instance id, PCF Set ID, level of binding). When there are multiple PDU Sessions to the same UE the BSF provides multiple notification to the PCF.
Step 5b.
If the (H-)PCF for the UE sent the request to notify that a PCF for the PDU Session is available to the AMF in step 1, then the PCF for the PDU Sessions sends Npcf_PolicyAuthorization_Notify (EventID set to SM Policy Association established, UE address, PCF address, PCF instance is, PCF Set ID) to the PCF indicated in the PCF binding information provided by the SMF.
Step 6.
The (H-)PCF for the UE subscribes to notifications of event "UE reporting Connection Capabilities from associated URSP rule" as defined in clause 6.1.3.18 of TS 23.503, using Npcf_PolicyAuthorization_Subscribe (EventId set to "UE reporting Connection Capabilities from associated URSP rule", EventFilter set to at least "list of Connection Capabilities") and immediate reporting flag set to the PCF for the PDU Session. The response includes the NotificationCorrelationId and any Connection Capabilities if already available at the PCF for the PDU Session.
Step 7.
If not already installed, the PCF installs the Policy Control Request Trigger to detect "UE reporting Connection Capabilities from associated URSP rule" in the SMF.
Step 8.
When the (H-)SMF receives a UE report of URSP rule enforcement via PDU session modification as described in clause 4.3.3 (step 8a) and the Policy Control Request Trigger is met, it then reports the received traffic information to the PCF serving the PDU Session, by invoking Npcf_SMPolicyControl_Update as defined in clause 6.1.3.5 of TS 23.503 (step 8b).
Step 9.
The (H-)PCF for the UE is notified on the "UE reporting Connection Capabilities from associated URSP rule" by Npcf_PolicyAuthorization_Notify (NotificationCorrelationId, EventId set to "UE reporting Connection Capabilities from associated URSP rule", EventInformation including the Connection Capabilities) as defined in clause 6.1.3.18 of TS 23.503.
Step 10.
The (H-)PCF for the UE checks operator policies and then may make policy control decisions based on awareness of URSP rule enforcement as described in clause 6.1.1.5 of TS 23.503.
Step 11.
The SM Policy Association is terminated as described in clause 4.16.6. The allocated UE address/prefix, SUPI, DNN, S-NSSAI and the PCF address are deregistered in the BSF.
Step 12a.
If the (H-)PCF for the UE subscribed to the BSF, then the BSF notifies that the PCF serving a PDU Session is deregistered in the BSF, by invoking Nbsf_Management_Notify (Binding Identifier for the PDU Session).
Step 12b.
If the (H-)PCF for the UE sent the request to notify that a PCF for the PDU Session is available to the AMF in step 1, then the PCF for the PDU Session sends Npcf_PolicyAuthoritation_Notify (EventID set to SM Policy Association termination, Notification Correlation Id).
4.16.16.3 Forwarding of URSP Rule Enforcement Information (for LBO roaming) p. 553
This procedure applies when the PCF serving the PDU session in VPLMN receives URSP rule enforcement information from the SMF and forwards this information to the V-PCF serving the UE in VPLMN and V-PCF forwards the information to the H-PCF serving the UE in HPLMN.
Step 1.
The UE Policy Association is established among the AMF, V-PCF and H-PCF, as described in clause 4.16.11. During this procedure, if the UE indicated support for URSP Rule enforcement report, the H-PCF for the UE may request to forward the UE reporting Connection Capabilities from an associated URSP rule, the H-PCF sends the PCRT to report the Connection Capabilities of the associated URSP rule to the V-PCF.
Step 2.
If the H-PCF for the UE indicates the UE to send reporting of URSP rule enforcement as described in clause 6.6.2.4 of TS 23.503 and H-PCF for the UE has requested to forward the UE reporting Connection Capabilities from an associated URSP rule to the V-PCF as in the step 1, then depending on operator policies in the V-PCF, the V-PCF may subscribe to the BSF in VPLMN, then step 3 follows, or provides its PCF binding information to the AMF in step 1 with the indication to be notified about the PCF for the PDU Session for a UE, then step 4 follows.
Step 3 to 7.
The same as the steps 3 to 7 of Figure 4.16.16.2-1 with replacing PCF with V-PCF. The SMF in this Figure is located in VPLMN while the H-PCF for the UE is located in HPLMN.
Step 8.
If the UE supports the UE capability of reporting URSP enforcement and sends the indication to the H-PCF for the UE at the step 1, and detects the application matching a URSP rule including the Connection Capabilities, the UE reports the Connection Capabilities to the SMF during the PDU Session Establishment/Modification request to the SMF.
When the SMF receives a UE report of URSP rule enforcement via PDU Session Modification and the Policy Control Request Trigger is met, it then reports the received traffic information to the PCF serving the PDU Session, by invoking Npcf_SMPolicyControl_Update as defined in clause 6.1.3.5 of TS 23.503 (step 8b).
Step 9.
The same step as the step 9 of Figure 4.16.16.2-1 with replacing PCF with V-PCF.
Step 10 to 11.
The same steps as the steps 11 to 12 of Figure 4.16.16.2-1 with replacing PCF with V-PCF. The SMF in this Figure is located in VPLMN.
Step 12.
If the V-PCF has received the request to forward the UE reporting Connection Capabilities from an associated URSP rule from the H-PCF in the step 1 and the V-PCF for the UE is either notified on the "UE reporting Connection Capabilities from associated URSP rule" by Npcf_PolicyAuthorization_Notify in step 9 or receives "UE reporting Connection Capabilities from associated URSP rule" by Npcf_PolicyAuthorization_Subscribe response in steps 3-7, the V-PCF reports the received the information from the PCF for the PDU Session to the H-PCF.
Step 13.
The (H-)PCF for the UE checks operator policies and then may make policy control decisions based on awareness of URSP rule enforcement as described in clause 6.1.1.5 of TS 23.503, and also the H-PCF may take an appropriate action as described in clause 6.6.2.4 of TS 23.503.
