Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TS 23.502  Word version:  17.1.0

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…   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.4…   4.16…   4.16.4…   4.16.8…   4.17…   4.17.9…   4.18…   4.19…   4.23…   4.23.7…   4.23.9…   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…   A…   E…   F…

 

4.16.4  SM Policy Association EstablishmentWord‑p. 384

Reproduction of 3GPP TS 23.502, Figure 4.16.4-1: SM Policy Association Establishment
Up
This procedure concerns both roaming and non-roaming scenarios.
In the non-roaming case the V-PCF is not involved. In the local breakout roaming case, the H-PCF is not involved. In the home routed roaming case, the V-PCF is not involved and the H-PCF interacts with the H-SMF.
This procedure is used in UE requests a PDU Session Establishment as explained in clause 4.3.2.2.1, for non-roaming and local breakout roaming. For home-routed roaming, as explained in clause 4.3.2.2.2.
For local breakout roaming, the interaction with HPLMN (e.g. step 3) is not used. In local breakout roaming, the V-PCF interacts with the UDR of the VPLMN.
Step 1.
The SMF determines that the PCC authorization is required and requests to establish an SM Policy Association with the PCF by invoking Npcf_SMPolicyControl_Create operation, including information about the PDU Session as specified in clause 5.2.5.4.2.
The SMF provides Trace Requirements to the PCF when it has received Trace Requirements and it has selected a different PCF than the one received from the AMF.
If the DNN Selection Mode indicates that the DNN is not explicitly subscribed, the PCF may use the local configuration instead of PDU Session policy control data in UDR.
The QoS constraints from the VPLMN are provided by the H-SMF to the H-PCF in the home routed roaming scenario as defined in clause 4.3.2.2.2.
If the SMF utilizes an NWDAF or in case the SMF has received information from AMF or UPF that are consumer of analytic services, the SMF includes the IDs of each of these NWDAFs serving the UE (for SMF, AMF, and UPF), identified by the NWDAF instance Id. The Analytics ID(s) are also included per NWDAF service instance.
Step 2.
If the PCF does not have the subscriber's subscription related information, it sends a request to the UDR by invoking Nudr_DM_Query (SUPI, DNN, S-NSSAI, Policy Data, PDU Session policy control data, Remaining allowed Usage data) service in order to receive the information related to the PDU Session. The 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), PDU Session policy control data, Remaining allowed Usage data) service.
Step 3.
If the PCF determines that the policy decision depends on the status of the policy counters available at the CHF and such reporting is not established for the subscriber, the 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 PCF determines that the status of additional policy counters are required, the PCF initiates an Intermediate Spending Limit Report Retrieval as defined in clause 4.16.8.3.
Step 4.
The PCF makes the authorization and the policy decision. The PCF may reject Npcf_SMPolicyControl_Create request when Validation condition is not satisfied. (see clause 6.1.2.4 of TS 23.503).
PCF may invoke Nbsf_Management_Register service operation to create the binding information in BSF.
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.
In the home-routed roaming scenario, the H-PCF ensures that the QoS constraints provided by the VPLMN are taken into account as described in TS 23.503.
Step 5.
The PCF answers with a Npcf_SMPolicyControl_Create response; in its response the PCF may provide policy information defined in clause 5.2.5.4 (and in TS 23.503). The SMF enforces the decision. The SMF implicitly subscribes to changes in the policy decisions.
Up

4.16.5  SM Policy Association ModificationWord‑p. 385

4.16.5.0  General

The following SM Policy Association Modification procedures concern both roaming and non-roaming scenarios.
In the non-roaming case the V-PCF is not involved. In the local breakout roaming case, the H-PCF is not involved. In the home routed roaming case, the V-PCF is not involved and the H-PCF interacts with the H-SMF.
The SM Policy Association Modification procedure may be initiated either by the SMF or by the PCF.

4.16.5.1  SMF initiated SM Policy Association Modification

The SMF may initiate the SM Policy Association Modification procedure if a Policy Control Request Trigger is met.
Reproduction of 3GPP TS 23.502, Figure 4.16.5.1-1: SMF initiated SM Policy Association Modification
Up
For local breakout roaming, the interaction with HPLMN (e.g. step 2) is not used. In local breakout roaming, the V-PCF interacts with the UDR of the VPLMN.
Step 1.
When a Policy Control Request Trigger condition is met the SMF requests to update (Npcf_SMPolicyControl_Update) the SM Policy Association and provides information on the conditions that have been met as specified in clause 5.2.5.4.5.
If the SMF is notified by NRF that the stored PCF instance is not reachable, it should query the NRF for PCF instances within the PCF set and select another instance (see clause 6.3.1.0 of TS 23.501).
The QoS constraints from the VPLMN are provided by the H-SMF to the H-PCF in the home routed roaming scenario as defined in clause 4.3.2.2.2.
Step 2.
When an AF has subscribed to an event that is met due to the report from the SMF, the PCF reports the event to the AF by invoking the Npcf_PolicyAuthorization_Notify service operation.
If the SMF has reported that a manageable DS-TT port has been detected and no subscription for "5GS bridge information available" event exists for this PDU session yet.
When integration with TSN applies (see clause 5.28 of TS 23.501), then the PCF informs a pre-configured TSN AF using the Npcf_PolicyAuthorization_Notify (5GS Bridge ID, the port number of the DS-TT port, and MAC address of the DS-TT Ethernet port for the PDU Session) service operation for the event of "5GS bridge information available" as described in clause 6.1.3.18 of TS 23.503.
  • Otherwise, i.e. if the integration with TSN does not apply, the PCF retrieves the Data Subset "Time-Sync data" under the Application Data from the UDR for the corresponding DNN/S-NSSAI and SUPI, and subscribes for the Time-Sync data changes in the UDR. If the "Time-Sync data" contains a TSCTSF Notification Target Address, the PCF informs the TSCTSF using the Npcf_PolicyAuthorization_Notify (User Plane Node ID, the port number of the DS-TT port, and MAC address of the DS-TT Ethernet port or IP address for the PDU Session) service operation for the event of "5GS bridge information available" as described in clause 6.1.3.18 of TS 23.503. If the "Time-Sync data" does not contain a TSCTSF Notification Target Address, the PCF stores the User Plane Node ID, the port number of the DS-TT port, and MAC address of the DS-TT Ethernet port or IP address for the PDU Session.
When the TSN AF or TSCTSF receives the Npcf_PolicyAuthorization_Notify message and no AF session exists for this PDU Session, the TSN AF or TSCTSF shall use the Npcf_PolicyAuthorization service described in clause 5.2.5.3 to request creation of a new AF session specific to the received MAC address of the DS-TT Ethernet port or IP address of the PDU Session. The TSN AF or TSCTSF shall then use the Npcf_PolicyAuthorization service to subscribe for notifications for port and user plane node management related events over the newly established AF session. If the PCF has stored the 5GS bridge information and has not reported the event to the TSN AF or TSCTSF, the PCF notifies the TSCTSF for the event of "5GS bridge information available" as described in clause 6.1.3.18 of TS 23.503. The TSN AF or TSCTSF may provide a Port or User-Plane Management Information Container for the PDU Session and related port number in the Npcf_PolicyAuthorization creation request.
When integration with TSN applies (see clause 5.28 of TS 23.501), the TSN AF calculates the bridge delay for each port pair, using the UE-DS-TT Residence Time of the DS-TT Ethernet port(s) for the 5GS bridge indicated by the 5GS user-plane Node ID.
Step 3.
If the PCF determines a change to policy counter status reporting is required, it may alter the subscribed list of policy counters using the Initial, Intermediate or Final Spending Limit Report Retrieval procedures as defined in clause 4.16.8.
Step 4.
The PCF makes a policy decision as described in TS 23.503. The PCF may determine that updated or new policy information needs to be sent to the SMF.
If the SMF reported accumulated usage for the PDU session in step 1 the PCF deducts the value from the remaining allowed usage for the subscriber, DNN, and S-NSSAI in the UDR by invoking Nudr_DM_Update (SUPI, DNN, S-NSSAI, Policy Data, Remaining allowed Usage data, updated data) service operation.
If the SMF reported accumulated usage for a MK(s) in step 1 the PCF deducts the value from the remaining allowed usage for the MK in the UDR by invoking Nudr_DM_Update (SUPI, DNN, S-NSSAI, Policy Data, Remaining allowed Usage data, updated data (including MK(s))) service operation.
When new PCF instance is selected in step 1, the new PCF should invoke Nbsf_Management_Update service operation to update the binding information in BSF.
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.
In the home-routed roaming scenario, the H-PCF ensures that the QoS constraints provided by the VPLMN are taken into account as described in TS 23.503.
Step 5.
The PCF answers with a Npcf_SMPolicyControl_Update response with updated policy information about the PDU Session determined in step 4.
Up

4.16.5.2  PCF initiated SM Policy Association ModificationWord‑p. 387

The PCF may initiate SM Policy Association Modification procedure based on internal PCF event or triggered by other peers of the PCF (AF, NWDAF, CHF, UDR).
Reproduction of 3GPP TS 23.502, Figure 4.16.5.2-1: PCF initiated SM Policy Association Modification
Up
This procedure may be triggered by a local decision of the PCF or based on triggers from other peers of the PCF (AF, NWDAF, CHF, UDR):
An SM Policy Association is established, with the PCF as described in clause 4.16.4 before this procedure is triggered.
For local breakout roaming, the interaction with HPLMN (e.g. step 1b and step 2) is not used. In local breakout roaming, the V-PCF interacts with the UDR of the VPLMN.
Step 1a.
Alternatively, optionally, the AF or NEF provides/revokes service information to the PCF e.g. due to AF session signalling, by invoking Npcf_PolicyAuthorization_Create Request or Npcf_PolicyAuthorization_Update Request service operation. The PCF responds to the AF or NEF.
Step 1b.
Alternatively, optionally, the CHF provides a Spending Limit Report to the PCF as described in clause 4.16.8. and responds to the CHF.
Step 1c.
Alternatively, optionally, the UDR notifies the PCF about a policy subscription change by invoking Nudr_DM_Notify (Notification correlation Id, Policy Data, SUPI, updated data, "PDU Session Policy Control Data" | "Remaining allowed Usage data"); The PCF responds to the UDR.
Step 1d.
Alternatively, optionally, some internal event (e.g. timer, or local decision based on analytics information requested and received from NWDAF) occurs at the PCF. The analytics (i.e. Analytics ID) which can be requested from NWDAF are described in clause 6.1.1.3 of TS 23.503.
Step 2.
If the PCF determines a change to policy counter status reporting is required, it may alter the subscribed list of policy counters using the Initial, Intermediate or Final Spending Limit Report Retrieval procedures as defined in clause 4.16.8.
Step 3.
The PCF makes a policy decision. The PCF may determine that updated or new policy information need to be sent to the SMF. In the non-roaming case, the PCF may also decide to subscribe to a new Analytics ID from NWDAF as described in clause 6.1.1.3 of TS 23.503.
If the AF provided a Background Data Transfer Reference ID in step 1a, the PCF may retrieve it from the UDR by invoking the Nudr_DM_Query (BDT Reference Id, Policy Data, Background Data Transfer) service.
Step 4.
If the PCF has determined that SMF needs updated policy information in step 3 or if the PCF has received a Port Management Information Container for the PDU Session and related port number from the AF or NEF in Step 1a, the PCF issues a Npcf_SMPolicyControl_UpdateNotify request with possibly updated policy information about the PDU Session.
Step 5.
The SMF acknowledges the PCF request with a Npcf_SMPolicyControl_UpdateNotify response.
If the Npcf_SMPolicyControl_UpdateNotify request is received from new PCF instance in the PCF Set, the SMF store the SM policy association towards the new PCF instance.
Up

4.16.6  SM Policy Association TerminationWord‑p. 389

Reproduction of 3GPP TS 23.502, Figure 4.16.6-1: SM Policy Association Termination
Up
This procedure concerns both roaming and non-roaming scenarios.
In the non-roaming case the V-PCF is not involved. In the local breakout roaming case, the H-PCF is not involved. In the home routed roaming case, the V-PCF is not involved and the H-PCF interacts only with the H-SMF.
The procedure for Session Management Policy Termination may be initiated by:
  • (Case A) the PCF.
  • (Case B) the SMF.
For local breakout roaming, the interaction with HPLMN (e.g. step 6) is not used. In local breakout roaming, the V-PCF interacts with the UDR of the VPLMN.
Step 1.
(Case A) The PCF may invoke the Npcf_SMPolicyControl_UpdateNotify service operation to request the release of a PDU Session. The SMF acknowledges the request.
The rest of the procedure corresponds to both Case A &B.
Step 2.
The SMF may invoke the Npcf_SMPolicyControl_Delete service operation to request the deletion of the SM Policy Association with the PCF. The SMF provides relevant information to the PCF.
Step 3.
When receiving the request from step2, the PCF finds the PCC Rules that require an AF to be notified and removes PCC Rules for the PDU Session.
If the SMF reported accumulated usage for the PDU session in step 1 the PCF deducts the value from the remaining allowed usage for the subscriber, DNN, and S-NSSAI in the UDR by invoking Nudr_DM_Update (SUPI, DNN, S-NSSAI, Policy Data, Remaining allowed Usage data, updated data) service operation.
If the SMF reported accumulated usage for a MK(s) in step 1 the PCF deducts the value from the remaining allowed usage for the MK in the UDR by invoking Nudr_DM_Update (SUPI, DNN, S-NSSAI, Policy Data, Remaining allowed Usage data, updated data (including MK(s))) service operation.
Step 4.
The SMF removes all policy information about the PDU Session associated with the PDU Session.
Step 5.
The PCF notifies the AF as explained in clause 7.3.1 steps 6-7 of TS 23.203.
PCF may invoke Nbsf_Management_Deregister service operation to delete the binding created in BSF.
In the non-roaming case, the PCF may unsubscribe to analytics from NWDAF.
Step 6.
The PCF may invoke the procedure defined in clause 4.16.8 to unsubscribe to policy counter status reporting (If this is the last PDU Session for this subscriber requiring policy counter status reporting) or to modify the subscription to policy counter status reporting, (if any remaining existing PDU Sessions for this subscriber requires policy counter status reporting).
Step 7.
The PCF removes the information related to the terminated PDU Session and acknowledges to the SMF that the PCF handling of the PDU Session has terminated. This interaction is the response to the SMF request in step 2.
Step 8.
The PCF may (e.g. if it is the last PDU Session on the (DNN, S-NSSAI) couple) unsubscribe to the notification of the PDU Session related data modification from the UDR by invoking Nudr_DM_Unsubscribe (Subscription Correlation Id) if it had subscribed such notification.
Up

4.16.7  Negotiations for future background data transferWord‑p. 390

4.16.7.1  General

The procedure for future background data transfer as specified in clause 4.16.7.2 enables the negotiation between the NEF and the H-PCF about the transfer policies for the future background data transfer (as described in clause 6.1.2.4 of TS 23.503). The transfer policies consist of a desired time window for the background data transfer, a reference to a charging rate for the time window, network area information, and optionally a maximum aggregated bitrate, as described in clause 6.1.2.4 of TS 23.503.
This negotiation is preliminarily conducted (when AF initiates a procedure to NEF) before the UE's PDU Session establishment. When the AF wants to apply the Background Data Transfer Policy to an existing PDU Session, then at the time the background data transfer is about to start the AF invokes the Npcf_PolicyAuthorization_Create service directly with PCF, or via the NEF, to apply the background data transfer policy for an individual UE. When the AF wants to apply the Background Data Transfer Policy to a future PDU Session, then the AF invokes Nnef_ApplyPolicy_Create service to provide, to the NEF, the Background Data Transfer Reference ID together with the External Identifier or External Group Identifier of the UE(s) that are subject to the policy.
The procedure for BDT warning notification as specified in clause 4.16.7.3 enables the PCF to notify the AF that the network performance in the area of interest goes below the criteria set by the operator as described in clause 6.1.2.4 of TS 23.503.
Up

4.16.7.2  Procedures for future background data transferWord‑p. 391

Reproduction of 3GPP TS 23.502, Figure 4.16.7.2-1: Negotiation for future background data transfer
Up
Step 1.
The AF invokes the Nnef_BDTPNegotiation_Create (ASP id, Number of UEs, Volume per UE, Desired time window, and optionally External Group Identifier, Network Area Information, Request for notification, MAC address or IP 3-tuple of Application server). The Request for notification is an indication that BDT warning notification should be sent to the AF.
Step 2a.
Based on an AF request, the NEF requests to translate the External Group Identifier into the Internal Group Identifier using Nudm_SDM_Get (Group Identifier Translation, External Group Identifier).
Step 2b.
The NEF invokes the Npcf_BDTPolicyControl_Create (ASP id, Number of UEs, Volume per UE, Desired time window and optionally Internal Group Identifier, the Network Area Information, Request for notification, MAC address or IP 3-tuple of Application server) with the H-PCF to authorize the creation of the policy regarding the background data transfer. If the PCF was provided with Request for notification, then PCF may send BDT warning notification to the AF as described in clause 4.16.7.3.
Step 3.
The H-PCF may request from the UDR the stored Background Data Transfer policies for all the ASPs using Nudr_DM_Query (Policy Data, Background Data Transfer) service operation.
Step 4.
The UDR provides all the stored Background Data Transfer policies and corresponding related information (i.e. volume of data to be transferred per UE, the expected amount of UEs) to the H-PCF.
Step 5.
The H-PCF determines, based on information provided by the AF and other available information one or more Background Data Transfer policies. The PCF may interact with the NWDAF and request the Network Performance analytics information for the Desired time window and the Network Area Information as defined in TS 23.288.
Step 6.
The H-PCF send the acknowledge message to the NEF with the acceptable Background Data T Transfer policies and a Background Data Transfer Reference ID.
Step 7.
The NEF sends a Nnef_BDTPNegotiation_Create response to the AF to provide one or more background data transfer policies and the Background Data Transfer Reference ID to the AF. The AF stores the Background Data Transfer Reference ID for the future interaction with the PCF. If the NEF received only one background data transfer policy from the PCF, steps 8-11 are not executed and the flow proceeds to step 12. Otherwise, the flow proceeds to step 8.
Step 8.
The AF invokes the Nnef_BDTPNegotiation_Update service to provide the NEF with Background Data Transfer Reference ID and the selected background data transfer policy.
Step 9.
The NEF invokes the Npcf_BDTPolicyControl_Update service to provide the H-PCF with the selected background data transfer policy and the associated Background Data Transfer Reference ID.
Step 10.
The H-PCF sends the acknowledge message to the NEF.
Step 11.
The NEF sends the acknowledge message to the AF.
Step 12.
The H-PCF stores the Background Data Transfer Reference ID together with the new Background Data T Transfer policy, the corresponding related information (i.e. volume of data to be transferred per UE, the expected amount of UEs), optionally MAC address or IP 3-tuple of Application server the information of request for notification, together with the relevant information received from the AF (as defined in clause 6.1.2.4 of TS 23.503) in the UDR by invoking Nudr_DM_Update (BDT Reference id, Policy Data, Background Data Transfer). This step is not executed, when the PCF decides to locally store the Background Data Transfer policy.
Step 13.
The UDR sends a response to the H-PCF as its acknowledgement.
Up

4.16.7.3  Procedure for BDT warning notification |R16|Word‑p. 393

Reproduction of 3GPP TS 23.502, Figure 4.16.7.3-1: The procedure for BDT warning notification
Up
Step 1.
The negotiation for Background Data Transfer (BDT) described in clause 4.16.7.2 is completed. In addition, the PCF has subscribed to analytics on "Network Performance" from NWDAF for the area of interest and time window of a background data transfer 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 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.
Step 3.
The H-PCF may request from the UDR the stored BDT policies using Nudr_DM_Query (Policy Data, Background Data Transfer) service operation.
Step 4.
The UDR provides all the Background Transfer Policies together with the relevant information received from the AF (as defined in clause 6.1.2.4 of TS 23.503) to the H-PCF.
Step 5.
The H-PCF identifies the BDT policies affected by the notification received from NWDAF. For each of them, the H-PCF determines the ASP of which the background 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 Background Data Transfer policies can be calculated for the ASP. If the PCF does not find any new candidate BDT policy, the previously negotiated BDT policy shall be kept, no interaction with that ASP shall occur and the procedure stops for that BDT policy.
Step 7.
The PCF sets the no longer valid BDT policy in the UDR as invalidated by invoking Nudr_DM_Update (Background Data Transfer 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 (Background Data Transfer Reference ID, list of candidate Background Data Transfer policies) service operation.
Step 10.
The NEF sends the BDT warning notification to the AF by invoking Nnef_BDTPNegotiation_Notify (Background Data Transfer Reference ID, list of candidate Background Data Transfer policies) service operation.
Step 11.
The AF checks the new Background Data Transfer policies included in the candidate list in the BDT warning notification.
Step 12.
If the AF selects any of the new Background Data Transfer policies, the steps 8-13 from clause 4.16.7.2 are executed.
Step 13.
If the AF doesn't select any of the new Background Data Transfer policies, the steps 8-11 from clause 4.16.7.2 are executed, with the AF indicating that none of the candidate Background Data Transfer policies is acceptable.
Step 14.-15.
If the step 13 is executed, the PCF removes the no longer valid BDT policy from UDR for the corresponding Background Data Transfer Reference ID.
Step 16.
If there is a new Background Data Transfer policy stored in the UDR or a BDT policy removed from the UDR, the PCFs are notified by the UDR accordingly. The PCFs check if the corresponding URSP rules need to be updated or removed and if so, use the procedure defined in clause 4.16.12.2 to update URSP rules for the relevant UEs.
The AF can send a Stop notification by invoking Nnef_BDTPNegotiation_Update service, when the AF requests not to receive the BDT warning notification anymore. Then, the NEF invokes Npcf_BDTPolicyControl_Update service in order to provide this information for the H-PCF.
Up

Up   Top   ToC