Tech-invite  3GPPspace  IETF RFCs  SIP
index  21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 23.502  Word version:  18.1.1

Top   Top   Up   Prev   Next
1…   4.2.2.2.2   4.2.2.2.3…   4.2.3…   4.2.3.3   4.2.4…   4.2.6   4.2.7…   4.2.9…   4.3…   4.3.2.2.2   4.3.2.2.3…   4.3.3…   4.3.4…   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.2.2…   4.11.1.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.7…   4.15.7…   4.16…   4.16.4…   4.16.8…   4.16.11…   4.17…   4.17.9…   4.18…   4.19…   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.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.11 UE Policy Association Establishment  4.16.12 UE Policy Association Modification  4.16.12.1 UE Policy Association Modification initiated by the AMF  4.16.12.1.1 UE Policy Association Modification initiated by the AMF without AMF relocation  4.16.12.1.2 UE Policy Association Modification with old PCF during AMF relocation  4.16.12.2 UE Policy Association Modification initiated by the PCF  4.16.13 UE Policy Association Termination  4.16.13.1 AMF-initiated UE Policy Association Termination  4.16.13.2 PCF-initiated UE Policy Association Termination  4.16.14 Management of access and mobility related policy information depending on the application in use  4.16.14.1 General  4.16.14.2 Procedures for management of access and mobility related policy information  4.16.14.2.1 Management of access and mobility related policy information at start and stop of application traffic  4.16.14.2.2 Management of access and mobility related policy information at SM Policy Association establishment and termination with the notification sent by the BSF  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.11  UE Policy Association Establishment  p. 461

This procedure concerns the following scenarios:
  1. UE initial registration with the network.
  2. The AMF relocation with PCF change in handover procedure and registration procedure.
  3. UE registration with 5GS when the UE moves from EPS to 5GS and there is no existing UE Policy Association between AMF and PCF for this UE.
In Non-roaming case, the H-PCF may interact with the CHF in HPLMN to make a decision about UE Policies based on spending limits.
Reproduction of 3GPP TS 23.502, Fig. 4.16.11-1: UE Policy Association Establishment
Figure 4.16.11-1: UE Policy Association Establishment
Up
This procedure concerns both roaming and non-roaming scenarios.
In the non-roaming case the V-PCF is not involved and the role of the H-PCF is performed by the PCF. For the roaming scenarios, the V-PCF interacts with the AMF and the H-PCF interacts with the V-PCF:
Step 1.
The AMF establishes UE Policy Association with the (V-)PCF when a UE Policy Container is received from the UE. If a UE Policy Container is not received from the UE, the AMF may establish UE Policy Association with the (V-)PCF based on AMF local configuration.
Step 2.
The AMF sends a Npcf_UEPolicyControl Create Request with the following information: SUPI, may include Access Type and RAT, PEI, ULI, UE time zone, Serving Network (PLMN ID, or PLMN ID and NID, see clause 5.34 of TS 23.501), the Internal-Group-ID-list and UE Policy Container (the list of stored PSIs, operating system identifier, Indication of UE support for ANDSP, indication of UE capability of supporting to reporting URSP rule enforcement to network). In roaming scenario, based on operator policies, the AMF may provide to the V-PCF the PCF ID of the selected H-PCF. The V-PCF contacts the H-PCF. In roaming case, steps 3 and 4 are executed, otherwise step 5 follows.
If the AMF, based on configuration, is aware that the UE is accessing over a gNB using satellite backhaul, the AMF includes the Satellite Backhaul Category as described in clause 5.43.2 of TS 23.501.
Step 3.
The V-PCF forwards the information received from AMF in step 2 to the H-PCF. When a UE Policy Container is received at initial registration, the H-PCF may store the PEI, the OSId, indication of UE capability of supporting to reporting URSP rule enforcement to network or the indication of UE support for ANDSP in the UDR using Nudr_DM_Create including DataSet "Policy Data" and Data Subset "UE context policy control data".
The V-PCF may retrieve the Application guidance on URSP Rule for inbound roamers of the PLMN of the SUPI, if not available, using Nudr_DM_Query or Nudr_DM_Subscribe including the Data Set "Application Data" and Data Subset "Service Specific Information" and DataKey set to "PLMN ID(s) of inbound roamers".
The V-PCF may retrieve the Application guidance on URSP Rule for inbound roamers of the PLMN of the SUPI, if not available, using Nudr_DM_Query or Nudr_DM_Subscribe including the Data Set "Application Data".
Step 4.
The H-PCF sends a Npcf_UEPolicyControl Create Response to the V-PCF. The H-PCF may provide the Policy Control Request Trigger parameters in the Npcf_UEPolicyControl Create Response. Before sending the response, the H-PCF may determine that the decision about UE policy control depends on the status of the policy counters available at the CHF and if such reporting is not established for the subscriber, the H-PCF initiates an Initial Spending Limit Report Retrieval as defined in clause 4.16.8.2. If policy counter status reporting is already established for the subscriber and the H-PCF determines that the status of additional policy counters are required, the H-PCF initiates an Intermediate Spending Limit Report Retrieval as defined in clause 4.16.8.3.
The (H-)PCF in roaming and the PCF in non-roaming may register to the BSF as the PCF serving this UE, if not already registered at the AM Policy Association establishment. This is performed by using the Nbsf_Management_Register operation, providing as inputs the UE SUPI/GPSI and the PCF identity.
Step 5.
The (V-) PCF sends a Npcf_UEPolicyControl Create Response to the AMF. The (V-)PCF relays the Policy Control Request Trigger parameters in the Npcf_UEPolicyControl Create Response.
The (V-)PCF also subscribes to notification of N1 message delivery of policy information to the UE using Namf_Communication_N1N2MessageSubscribe service which is not shown in this figure.
Step 6.
The (H-)PCF gets policy subscription related information and the latest list of PSIs from the UDR using Nudr_DM_Query service operation (SUPI, Policy Data, UE context policy control data, Policy Set Entry) if either or both are not available and makes a policy decision. The (H-)PCF may get the PEI, the OSId, indication of UE capability of supporting to reporting URSP rule enforcement to network or the indication of UE support for ANDSP in the UDR using Nudr_DM_Query including DataSet "Policy Data" and Data Subset "UE context policy control data" if the AMF relocates and the PCF changes. In the roaming scenario, the H-PCF may provide the indication of UE support for ANDSP to the V-PCF, if the indication was not present in the Npcf_UEPolicyControl Create request from V-PCF and the H-PCF gets this information from the H-UDR. The (H-)PCF may get the 5G VN group data and 5G VN group membership for each Internal-Group-ID received from the AMF using Nudr_DM_Query (Internal-Group-Id, Subscription Data, 5G VN Group Configuration). The (H-)PCF may store the 5G VN group data and 5G VN group membership for later use for other SUPIs that belong to the same Internal-Group-ID. The (H-)PCF may request notifications from the UDR on changes in the subscription information by invoking Nudr_DM_Subscribe (Policy Data, SUPI, DNN, S-NSSAI, Notification Target Address (+ Notification Correlation Id), Event Reporting Information (continuous reporting), UE context policy control data) service. The (H-)PCF may request notifications from the UDR on changes in the 5G VN group data or 5G VN group membership associated to each of the Internal-Group-Id provided to the PCF by invoking Nudr_DM_Subscribe (Subscription Data, 5G VN Group Configuration, Internal Group ID, Notification Target Address (+ Notification Correlation Id), Event Reporting Information (continuous reporting)) service. The (H-)PCF creates the UE policy container including UE policy information as defined in clause 6.6 of TS 23.503 and in the case of roaming H-PCF provides the UE policy container in the Npcf_UEPolicyControl UpdateNotify Request. In the non-roaming case, the PCF may subscribe to Analytics from NWDAF as defined in clause 6.1.1.3 of TS 23.503.
Step 7.
The V-PCF sends a response to H-PCF using Npcf_UEPolicyControl UpdateNotify Response.
Step 8.
The (V-)PCF triggers UE Configuration Update Procedure in clause 4.2.4.3 to sends the UE policy container including UE policy information to the UE. The (V-)PCF checks the size limit as described in clause 6.1.2.2.2 of TS 23.503.
Step 9.
If the V-PCF received notification of the reception of the UE Policy container then the V-PCF forwards the notification response of the UE to the H-PCF using Npcf_UEPolicyControl_Update Request.
If the V-PCF is notified by the V-UDR about the Service Specific Information applicable to inbound roamers from the HPLMN of the UE as specified in clause 4.15.6.10, the V-PCF provides the Service Parameters to the H-PCF.
Step 10.
The H-PCF sends a response to the V-PCF. If the V-PCF received a UE Policy Container step 8 will follow.
Up

4.16.12  UE Policy Association Modification  p. 463

4.16.12.1  UE Policy Association Modification initiated by the AMF  p. 463

4.16.12.1.1  UE Policy Association Modification initiated by the AMF without AMF relocation  p. 463
This procedure addresses the scenario where a Policy Control Request Trigger condition is met.
Reproduction of 3GPP TS 23.502, Fig. 4.16.12.1.1-1: UE Policy Association Modification initiated by the AMF
Figure 4.16.12.1.1-1: UE Policy Association Modification initiated by the AMF
Up
This procedure concerns both roaming and non-roaming scenarios.
In the non-roaming case the V-PCF is not involved. In the roaming case, the AMF interacts with the V-PCF and the H-PCF interacts with the V-PCF.
Step 1.
When a Policy Control Request Trigger condition is met the AMF updates UE Policy Control Association and provides information on the conditions that have changed to the PCF. The AMF sends a Npcf_UEPolicyControl Update Request with the following information: UE Policy Association ID associated with the SUPI defined in TS 29.525 and the Policy Control Request Trigger met. In roaming scenario, based on operator policies, the AMF may provide to the V-PCF the PCF ID of the selected H-PCF. The V-PCF contacts the H-PCF.
See clause 4.2.3.2 of TS 29.525 for more details on Policy Control Request Trigger.
In the roaming case, steps 2 and 3 are executed, otherwise step 4 follows.
Step 2.
The V-PCF forwards the information received from AMF in step 1 to the (H-)PCF.
Step 3.
The H-PCF replies to the V-PCF. In the non-roaming case, the PCF may subscribe to Analytics from NWDAF as defined in clause 6.1.1.3 of TS 23.503.
Step 4.
The (V-) PCF sends a Npcf_UEPolicyControl Update Response to the AMF.
Step 5.
The (H-)PCF may create the UE policy container including UE policy information as defined in clause 6.6 of TS 23.503. In the case of roaming the H-PCF may include the UE policy container in the Npcf_UEPolicyControl UpdateNotify Request.
Step 6.
The (V-)PCF sends a response to H-PCF using Npcf_UEPolicyControl UpdateNotify Response.
Steps 7, 8 and 9 are the same as steps 8, 9 and 10 of procedure UE Policy Association Establishment in clause 4.16.11.
Steps 7, 8 and 9 are the same as steps 8, 9 and 10 of procedure UE Policy Association Establishment in clause 4.16.11.
Up
4.16.12.1.2  UE Policy Association Modification with old PCF during AMF relocation  p. 464
This procedure addresses the scenario where a UE Policy Association Modification with the old PCF during AMF relocation.
Reproduction of 3GPP TS 23.502, Fig. 4.16.12.1.2-1: Policy Association Modification with the old PCF during AMF relocation
Figure 4.16.12.1.2-1: Policy Association Modification with the old PCF during AMF relocation
Up
This procedure addresses both roaming and non-roaming scenarios.
In the non-roaming case the V-PCF is not involved. In the roaming case, the AMF interacts with the V-PCF and the V-PCF interacts with the H-PCF.
Step 1.
[Conditional] When the old AMF and the new AMF belong to the same PLMN, the old AMF transfers to the new AMF the UE Policy Association information including policy control request trigger(s) and the PCF ID(s). For the roaming case, the new AMF receives both V-PCF ID and H-PCF ID.
Step 2.
Based on local policies, the new AMF decides to re-use the UE policy association for the UE Context with the (V-)PCF and contacts the (V)-PCF identified by the PCF ID received in step 1.
Step 3.
The new AMF sends Npcf_UEPolicyControl_Update to the (V-)PCF to update the UE policy association with the (V-)PCF. If a Policy Control Request Trigger condition is met, the information matching the trigger condition may also be provided by the new AMF.
In the roaming case, step 4 and 5 are executed, otherwise step 6 follows.
Step 4.
The V-PCF forwards the information received from new AMF in step 3 to the (H-)PCF.
Step 5.
The H-PCF replies to the V-PCF. In non-roaming case, the PCF may subscribe to Analytics from NWDAF as defined in clause 6.1.1.3 of TS 23.503.
Step 6.
The (V-)PCF updates the stored information provided by the old AMF with the information provided by the new AMF. The (V-)PCF sends a Npcf_UEPolicyControl Update Response to the AMF.
Step 7.
The (H-)PCF may create the UE policy container including UE policy information as defined in clause 6.6 of TS 23.503. In the case of roaming the H-PCF may include the UE policy container in the Npcf_UEPolicyControl UpdateNotify Request.
Step 8.
The V-PCF sends a response to H-PCF using Npcf_UEPolicyControl UpdateNotify Response.
Steps 9, 10 and 11 are the same as steps 8, 9 and 10 of procedure UE Policy Association Establishment in clause 4.16.11.
Up

4.16.12.2  UE Policy Association Modification initiated by the PCF  p. 466

This procedure is used to update UE policy and/or UE policy triggers.
In the non-roaming case, the H-PCF may interact with the CHF in HPLMN to make a decision about UE Policies based on spending limits.
Reproduction of 3GPP TS 23.502, Fig. 4.16.12.2-1: UE Policy Association Modification initiated by the PCF
Figure 4.16.12.2-1: UE Policy Association Modification initiated by the PCF
Up
This procedure concerns both roaming and non-roaming scenarios.
In the non-roaming case the V-PCF is not involved and the role of the H-PCF is performed by the PCF. In the roaming case, the H-PCF provides UE policy decision and provides the policy to the AMF via V-PCF.
Step 1a and 1b.
If (H-)PCF subscribed to notification of subscriber's policy data change or 5G VN Group Configuration (5G VN group data, 5G VN group membership) change and a change is detected, the UDR notifies that the subscriber's policy data of a UE or 5G VN Group Configuration (5G VN group data, 5G VN group membership) has been changed.
The UDR notifies the (H-)PCF of the updated policy control subscription information profile via Nudr_DM_Notify (Notification correlation Id, Policy Data, either UE context policy control data or Policy Set Entry data or both, SUPI), or
The UDR notifies the (H-)PCF of the updated 5G VN Group Configuration (5G VN group data, 5G VN group membership) via Nudr_DM_Notify (Notification correlation Id, 5G VN Group Configuration, Internal-Group-Identifier), or
The (V-)UDR notifies the (V-)PCF of the updated policy control subscription information profile via Nudr_DM_Notify (Notification correlation Id, Policy Data, PolicySetEntry Data. PLMN ID).
The (V-)UDR notifies the (V-)PCF of the updated Service Parameters via Nudr_DM_Notify.
Step 1c and 1d.
PCF determines locally that UE policy information needs to be sent to the UE.
Step 1e.
The CHF notifies the (H-)PCF about the change of the status of the subscribed policy counters available at the CHF for that subscriber.
Step 2a and 2b.
The PCF makes the policy decision. If the group data is updated, the (H-) PCF checks the UE Policy Associations for those SUPIs within the Internal-Group-Id and may need to perform step 3 to step 9 for each UE Policy Association that needs to be updated with new UE Policies sent to each UE. In the non-roaming case, the PCF may subscribe to Analytics from NWDAF as defined in clause 6.1.1.3 of TS 23.503.
Step 2c and 2d.
In the roaming case, the V-PCF may provide the updated Service Parameters received from the V-UDR as specified in clause 4.15.6.10 to the H-PCF using the Npcf_UEPolicyControl_Update Request. The H-PCF sends a response to the V-PCF.
Step 3.
The (H-)PCF may create the UE policy container including UE policy information as defined in clause 6.1.2.2.2 of TS 23.503. In the case of roaming, the H-PCF may send the UE policy container in the Npcf_UEPolicyControl UpdateNotify Request. The H-PCF may provide updated policy control triggers for the UE policy association. If there is the received Service Parameters from the V-PCF in step 2, the H-PCF may take the Service Parameters obtained from V-PCF to generate URSP rules applicable in the VPLMN as specified in clause 4.15.6.10.
Step 4.
The V-PCF sends a response to H-PCF using Npcf_UEPolicyControl UpdateNotify Response.
Step 5.
The (V-)PCF provides the Policy Control Request Trigger parameters in the Npcf_UEPolicyControl UpdateNotify Request to the AMF. In the case of roaming, the V-PCF may also provide UE policy information to the UE. The V-PCF may also provide updated policy control triggers for the UE policy association to the AMF.
Step 6.
The AMF sends a response to (V-)PCF.
Steps 7, 8 and 9 are the same as steps 8, 9 and 10 of procedure UE Policy Association Establishment in clause 4.16.11.
Up

4.16.13  UE Policy Association Termination  p. 467

4.16.13.1  AMF-initiated UE Policy Association Termination  p. 467

The following case is considered for UE Policy Association Termination:
  1. UE Deregistration from the network.
  2. The mobility with change of AMF (e.g. new AMF is in different PLMN or new AMF in the same PLMN).
  3. [Optional] 5GS to EPS mobility with N26 if the UE is not connected to the 5GC over a non-3GPP access in the same PLMN.
In the non-roaming case, the H-PCF may interact with the CHF in HPLMN.
Reproduction of 3GPP TS 23.502, Fig. 4.16.13.1-1: AMF-initiated UE Policy Association Termination
Figure 4.16.13.1-1: AMF-initiated UE Policy Association Termination
Up
This procedure concerns both roaming and non-roaming scenarios.
In the non-roaming case, the V-PCF is not involved and the role of the H-PCF is performed by the PCF. For the roaming scenarios, the V PCF interacts with the AMF. The V PCF contacts the H-PCF to request removing UE Policy Association.
Step 1.
The AMF decides to terminate the UE Policy Association.
Step 2.
The AMF sends the Npcf_UEPolicyControl_Delete service operation including UE Policy Association ID to the (V-)PCF.
Step 3.
The (V-)PCF removes the policy context for the UE and replies to the AMF with an Acknowledgement including success or failure. The V-PCF may interact with the H-PCF. The (V-)PCF may unsubscribe to subscriber policy data changes with UDR by Nudr_DM_Unsubscribe (Subscription Correlation Id). The AMF removes the UE Policy Context.
If the PCF has previously registered to the BSF as the PCF that is serving this UE, the PCF shall deregister from the BSF if no AM Policy Association for this UE exists anymore. This is performed by using the Nbsf_Management_Deregister service operation, providing the Binding Identifier that was obtained earlier from the BSF when performing the Nbsf_Management_Register service operation.
Step 4 and Step 5 apply only to the roaming case.
Step 4.
The V-PCF sends the Npcf_UEPolicyControl_Delete service operation including UE Policy Association ID to the H-PCF.
Step 5.
The H-PCF removes the policy context for the UE and replies to the V-PCF with an Acknowledgement including success or failure. The H-PCF may unsubscribe to subscriber policy data changes with UDR by Nudr_DM_Unsubscribe (Subscription Correlation Id) for subscriber policy changes. In the non-roaming case, the PCF may unsubscribe to analytics from NWDAF.
The H-PCF may invoke the procedure defined in clause 4.16.8 to unsubscribe to policy counter status reporting or to modify the subscription to policy counter status reporting (if remaining Policy association for this subscriber (i.e. AM Policy association) requires policy counter status reporting).
Up

4.16.13.2  PCF-initiated UE Policy Association Termination  p. 469

Reproduction of 3GPP TS 23.502, Fig. 4.16.13.2-1: PCF-initiated UE Policy Association Termination
Figure 4.16.13.2-1: PCF-initiated UE Policy Association Termination
Up
This procedure concerns both roaming and non-roaming scenarios.
In the non-roaming case, the V-PCF is not involved and the role of the H-PCF is performed by the PCF. For the roaming scenarios, the H-PCF interacts with the V-PCF to request removing Policy Association.
The PCF is subscribed to notification of changes in Data Set "Policy Data" for a UE Policy Association ID.
Step 1.
The Policy data is removed, either the Data Set "Policy Data" or the Data Subset "UE context policy control".
Step 2.
The UDR sends the Nudr_DM_Notify_Request (Notification correlation Id, Policy Data, SUPI, UE Context Policy Control data, updated data) including the SUPI, the Data Set Identifier, the Data Subset Identifier and the Updated Data including empty "Policy Data" or empty "UE context policy control".
Step 3.
The PCF sends the Nudr_DM_Notify_Response to confirm reception and the result to UDR.
Step 4.
The PCF may notify the AMF of the removal of the UE Policy Association via Npcf_UEPolicyControl_UpdateNotify service operation. Alternatively, the PCF may decide to maintain the Policy Association if a default profile is applied, in this case steps 4, 5 and 6 are not executed.
In the non-roaming case, the PCF unsubscribes to analytics from NWDAF if any.
Step 5.
The AMF acknowledges the operation.
Step 6.
Steps 2-5 in clause 4.16.13.1 AMF-initiated UE Policy Association Termination are performed to remove the UE Policy Association for this UE and the subscription to Policy Control Request Triggers for that UE Policy Association.
Up

4.16.14  Management of access and mobility related policy information depending on the application in use |R17|  p. 470

4.16.14.1  General  p. 470

The procedure for management of access and mobility related policy information depending on the application in use enables modification of the access and mobility related policy information on detection of the start and stop of an application.
The content of this clause applies to non-roaming i.e. to cases where the involved entities (e.g. PCF, SMF and UPF) belong to the home PLMN. The PCF shall not apply a change of access and mobility related policy information for application traffic detected in PDU Sessions established in Home Routed mode.
If PCF for the UE and PCF for the PDU Session are the same PCF, then steps 3, 5, 6, 9 and 12 in Figure 4.16.14.2.1-1 are not performed.
If the PCF for the UE and the PCF for the PDU Session are different PCFs, then the PCF for the UE is informed when a SM Policy Association is established or released by either:
  • Subscription to the BSF:
    • see steps 2, 3, 4, 5a, 11 and 12a in Figure 4.16.14.2.1-1. The BSF notifies when a PCF is registered or deregistered for the PDU Session to a DNN, S-NSSAI.
    • see steps 2, 3, 5 and 8 in Figure 4.16.14.2.2-1. The BSF reports 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).
  • Request to the PCF for the PDU Session to a DNN, S-NSSAI via AMF and SMF. See steps 1, 4, 5b, 11 and 12b in Figure 4.16.14.2.1-1. The PCF for the PDU Session reports that the SM Policy Association is established as described in clause 4.16.4 and provides the UE address(es). The SM Policy Association Termination notifies the PCF for the UE as described in clause 4.16.6.
Up

4.16.14.2  Procedures for management of access and mobility related policy information  p. 470

4.16.14.2.1  Management of access and mobility related policy information at start and stop of application traffic  p. 470
This procedure applies when the AF provides a service coverage area or the indication of high throughput associated with the Application Identifer(s).
Reproduction of 3GPP TS 23.502, Fig. 4.16.14.2.1-1: Management of access and mobility related policy information at start and stop of application traffic
Figure 4.16.14.2.1-1: Management of access and mobility related policy information at start and stop of application traffic
Up
Step 1.
The AMF establishes an AM Policy Association for retrieving access and mobility related policy information, e.g. RFSP index value, as described in clause 4.16.1.2.
Step 2.
If the access and mobility related policy information depends on the application in use, then depending on operator policies in the PCF, the 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 DNN, S-NSSAI, then step 4 follows.
Step 3.
The PCF for the UE determines that access and mobility related policy information (e.g. RFSP index value) depends on the detection of one or more application(s) in use, the DNN, S-NSSAI used to access each Application Id is configured in the PCF or retrieved from the UDR as part of the Application Data Set, 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, list of (DNN, S-NSSAI)(s)). Steps 4 and 5 are repeated for each PCF registered for a PDU Session to a (DNN, S-NSSAI) included in the Nbsf_Management.
Step 4.
The 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 in TS 23.503.
Step 5a.
If the PCF for the UE subscribed to the BSF, then the BSF notifies that a PCF for the PDU Session is registered in the BSF, by invoking Nbsf_Management_Notify (DNN, S-NSSAI, UE address(es), PCF address, PCF instance id, PCF Set ID, level of binding). When there are multiple PDU Sessions to the same (DNN, S-NSSAI) the BSF provides multiple notification to the PCF.
Step 5b.
If the 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 PCF for the UE subscribes to notifications of event "start/stop of application traffic" as defined in clause 6.1.3.18 of TS 23.503, using Npcf_PolicyAuthorization_Subscribe (UE address, EventId, EventFilter set to "list of Application Identifiers") to the PCF for the PDU Session to the DNN, S-NSSAI. The PCF for the PDU Session then generates PCC Rules including the Application Identifier in the SDF template, if there are multiple Application Identifiers included in the Npcf_PolicyAuthorization, the PCF generates PCC Rules for each Application Identifier. The response includes the NotificationCorrelationId.
Step 7.
The PCF installs PCC Rules and the Policy Control Request Trigger to detect "start/stop of application traffic" in the SMF.
Step 8.
The SMF detects that the Policy Control Request Trigger is met, then reports the start/stop of application traffic to the PCF serving the PDU Session.
Step 9.
The PCF for the UE is notified on the start/stop of application traffic by Npcf_PolicyAuthorization_Notify (NotificationCorrelationId, EventId set to "start/stop of application traffic", EventInformation including the ApplicationId). When the reporting of start and stop of a list of Application(s) was requested, the PCF for the PDU Session provides multiple notification to the PCF for the UE.
Step 10.
The PCF checks operator policies and then may change access and mobility related policy information (e.g. RFSP index value) based on the reporting of start/stop of application traffic.
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 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 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).
Up
4.16.14.2.2  Management of access and mobility related policy information at SM Policy Association establishment and termination with the notification sent by the BSF  p. 473
Reproduction of 3GPP TS 23.502, Fig. 4.16.14.2.2-1: Management of access and mobility related policy information at SM Policy Association establishment and termination with the notification by the BSF
Figure 4.16.14.2.2-1: Management of access and mobility related policy information at SM Policy Association establishment and termination with the notification by the BSF
Up
Step 1.
The AMF establishes an AM Policy Association for retrieving access and mobility related policy information, e.g. RFSP index value, as described in clause 4.16.1.2.
Step 2.
If the access and mobility related policy information depend on the SM Policy Association establishment and termination for a DNN, S-NSSAI combination, then depending on operator policies in the PCF, the PCF may subscribe to BSF and then step 3 follows, or the PCF may provide its PCF binding information to the AMF with the indication to be notified about the PCF for the PDU Session for a DNN, S-NSSAI and then step 4 follows.
Step 3.
The PCF for the UE determines that access and mobility related policy information (e.g. RFSP index value) depend on the detection of SM Policy Association establishment associated with the (DNN, S-NSSAI) combinations configured in the PCF or retrieved from the UDR as part of the Application Data Set. The PCF for the UE then subscribes to the BSF to be notified when a PCF for the PDU Session is registered for the first SM Policy Association establishment and the PCF for the PDU Session is deregistered for the last SM Policy Association termination to the same (DNN, S-NSSAI) combination in the BSF, by invoking Nbsf_Management_Subscribe (SUPI, list of (DNN, S-NSSAI)(s), indication of registration/deregistration per (DNN, S-NSSAI)).
Step 4.
The 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 are registered in the BSF, as described in clause 6.1.1.2.2 of TS 23.503.
Step 5.
If the PCF for the UE subscribed to BSF, then the BSF notifies a PCF registration when the first SM Policy Association corresponding to the (DNN, S-NSSAI) combination is established, by invoking Nbsf_Management_Notify (DNN, S-NSSAI, notification of registration).
Step 6.
The PCF checks operator policies and then may change access and mobility related policy information (e.g. RFSP index value) based on the reporting of SM Policy Association establishment.
Step 7.
The SM Policy Association is terminated as described in clause 4.16.6 and the allocated UE address/prefix, SUPI, DNN, S-NSSAI and the PCF address are deregistered in the BSF.
Step 8.
If the PCF for the UE subscribed to BSF, then BSF notifies of a PCF deregistration when the last SM Policy Association corresponding to the (DNN, S-NSSAI) combination is terminated, by invoking Nbsf_Management_Notify (DNN, S-NSSAI, notification of deregistration).
Up

4.16.15  Negotiations for planned data transfer with QoS requirements |R18|  p. 474

4.16.15.1  General  p. 474

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 which include the respective Desired Time Windows, the optional Network Area Information, the Request for Notification if the AF accepts that the PDTQ policy can be re-negotiated using the PDTQ warning notification procedure.
The Network Performance analytics or DN Performance analytics for NWDAF as described in TS 23.288 will be subscribed by the PCF to assist its decision to derive the PDTQ policies for the selected time window(s).
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 to be applied to the AF session when requested by the AF. Prior to the start of the Desired Time Window for the planned application data transfer, the AF requests the PCF to apply the selected PDTQ policy to the selected target UEs' PDU sessions. The PCF will then determine the appropriate PCC rules according to the negotiated PDTQ policy for the corresponding PDU session.
Up

4.16.15.2  Procedures  p. 474

4.16.15.2.1  Procedures for negotiation of planned data transfer with QoS requirements  p. 474
This clause describes the PDTQ procedures to negotiate viable time window for the planned application data transfer via the support of the NEF.
Reproduction of 3GPP TS 23.502, Fig. 4.16.15.2.1-1: Negotiation for planned data transfer with QoS requirements
Figure 4.16.15.2.1-1: Negotiation for planned data transfer with QoS requirements
Up
Prior to the transport of the Application AI/ML data, the AF negotiates with the 5G Core for the PDTQ policies to provide assistance for its application data transfer. The AF discovers its serving NEF, if it has not done so, using the mechanism as described in clause 6.3.14 of TS 23.501.
Step 1a.
The AF invokes the Nnef_PDTQNegotiation_Create Request (ASP Identifier, Number of UEs, the list of Desired time windows, QoS reference or individual QoS parameters, and optionally the alternative QoS parameters, Network Area Information, Request for notification, Alternative Service Requirements). The Request for notification is an indication that PDTQ warning notification can be sent to the AF. Note that, only Network Area Information is to be used for the PDTQ negotiation.
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_PDTQNegotiation_Create Response with the failure result, and the following steps are skipped.
Step 2.
Based on an AF request, the NEF may translate the information provided by the AF (e.g. QoS reference or geographical information etc.) based on the local policy and invokes the Npcf_PDTQPolicyControl_Create (ASP Identifier, Number of UEs, the list of Desired time windows, the QoS parameters, and optionally the alternative QoS parameters, Network Area Information, Request for notification) 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.3 to notify the AF when the network performance in the area of interest goes below the criteria set by the operator as described in clause 6.1.2.7 of TS 23.503.
Step 3.
H-PCF queries the UDR to retrieve all existing PDTQ polices for the corresponding ASP using Nudr_DM_Query (Policy Data, Planned Data Transfer with QoS) 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 and in case of non-GBR traffic type, the DN Performance analytics can be requested as well.
When requesting the network performance or 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 resource.
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 session 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_PDTQNegotiation_Create response to the AF to provide one or more PDTQ policies together with the PDTQ Reference ID.
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_PDTQNegotiated_Update together with the PDTQ Reference ID. The AF stores the PDTQ Reference ID and the selected PDTQ policy for the future interaction with the PCF. If the NEF received only one PDTQ policy from the PCF, steps 10-11 are not executed and the flow proceeds to step 12. Otherwise, the flow proceeds to step 10.
Step 10-12.
The NEF notifies H-PCF for the selected PDTQ policy by the AF. The H-PCF acknowledges NEF. The NEF responds to the AF's request through the Nnef_PDTQNegotiation_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). The UDR sends a response to the H-PCF as its acknowledgement.
After the PDTQ policy negotiation, if the AF decides to select an alternative PDTQ policy (e.g. data rate reduction, relaxing delay constraints of planned and event driven traffic etc.), the AF may trigger this procedure to request the corresponding H-PCF via the support of NEF to revise the PDTQ policy. In such a case, in step 1 instead of invoking Nnef_PDTQNegotiation_Create Request the AF will invoke the Nnef_PDTQNegotiation_Update Request together with the PDTQ Reference ID. Consequently, instead of invoking Npcf_PDTQPolicyControl_Create Request the NEF will invoke Npcf_PDTQPolicyControl_Update Request together with the PDTQ Reference ID.
Up
4.16.15.2.2  Procedure for PDTQ warning notification  p. 477
Reproduction of 3GPP TS 23.502, Fig. 4.16.15.2.2-1: The procedure for PDTQ warning notification
Figure 4.16.15.2.2-1: The procedure for PDTQ warning notification
Up
Step 1.
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" and, if possible "DN Performance" in addition, from NWDAF for the area of interest and time window of a PDTQ policy following the procedure 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 and, if possible DN performance analytics in addition, in the area of interest from the NWDAF when the NWDAF determines that the network performance goes below the threshold as described for the Network Performance analytics in TS 23.288 and, if possible the NWDAF determines that the DN performance goes below the threshold as described for the DN Performance analytics in TS 23.288.
Step 3.
The H-PCF may request from the UDR the stored PDTQ policies using Nudr_DM_Query (Policy Data, PDTQ) service operation.
Step 4.
The UDR provides all the PDTQ Policies together with the relevant information received from the AF (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 by 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 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 - 16 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 sets the no longer valid PDTQ policy in the UDR as invalidated by invoking Nudr_DM_Update (PDTQ Reference ID, invalidation flag) service.
Step 8.
The UDR sends a response to the H-PCF as acknowledgement.
Step 9.
The PCF sends the notification to the NEF by invoking Npcf_PolicyControl_Notify (PDTQ Reference ID, list of candidate PDTQ policies) service operation.
Step 10.
The NEF sends the PDTQ warning notification to the AF by invoking Nnef_PDTQNegotiation_Notify (PDTQ Reference ID, list of candidate PDTQ policies) service operation.
Step 11.
The AF checks the new PDTQ policies included in the candidate list in the PDTQ warning notification.
Step 12.
If the AF selects any of the new PDTQ policies, the steps 9-14 from clause 4.16.7.X.2.1 are executed.
Step 13.
If the AF doesn't select any of the new PDTQ policies, the steps 9-12 from clause 4.16.7.X.2.1 are executed, with the AF indicating that none of the candidate PDTQ policies is acceptable.
Step 14.-15.
If the step 13 is executed, the PCF removes the no longer valid PDTQ policy from UDR for the corresponding PDTQ Reference ID.
The AF can send a Stop notification by invoking Nnef_PDTQNegotiation_Update service, when the AF requests not to receive the PDTQ warning notification anymore. Then, the NEF invokes Npcf_PDTQPolicyControl_Update service in order to provide this information for the H-PCF.
Up

Up   Top   ToC