Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 23.502  Word version:  16.5.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…   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. 326
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 (see clause 5.2.5.4.2). The SMF includes the following information: SUPI, PDU Session id, PDU Session Type, S-NSSAI, NSI ID (if available), DNN, DNN Selection Mode, GPSI (if available), Access Type, RAT Type, AMF instance identifier and if available, the IPv4 address and/or IPv6 network prefix, PEI, User Location Information, UE Time Zone, Serving Network (PLMN ID, or PLMN ID and NID, see clause 5.34 of TS 23.501), Charging Characteristics, Session AMBR, default QoS information, Trace Requirements, Internal Group Identifier (see TS 23.501, clause 5.9.7).
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.
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 TS 23.503, clause 6.1.2.4).
PCF may invoke Nbsf_Management_Register service operation to create the binding information in BSF.
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. 327

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.
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).
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.
When integration with TSN applies (see clause 5.28 of TS 23.501), the AF may provide a Port Management Information Container, MAC address reported for the PDU Session and related port number in response. If the SMF has reported that a manageable Ethernet port has been detected and no AF session exists for this PDU session yet, then the PCF informs a pre-configured AF using the Npcf_PolicyAuthorization_Notify service operation of 5GS Bridge ID, the port number of the DS-TT Ethernet port, and MAC address of the DS-TT Ethernet port for the PDU Session.
When the AF receives the Npcf_PolicyAuthorization_Notify message over the pre-configured AF session, the AF 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. The AF shall then use the Npcf_PolicyAuthorization service to subscribe for notifications for TSN related events over the newly established AF session.
If the SMF has reported UE-DS-TT Residence Time and/or port numbers of the serving NW-TT Ethernet port(s), then the PCF also provides the UE-DS-TT Residence Time and/or port numbers of the serving NW-TT Ethernet port(s) to the AF, the AF calculates the bridge delay for each port pair, i.e. composed of (DS-TT Ethernet port, NW-TT Ethernet port), using the UE-DS-TT Residence Time for all NW-TT Ethernet ports serving the PDU session.
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.
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. 328
The PCF may initiate SM Policy Association Modification procedure based on local decision or triggered by other peers of the PCF (AF, 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, CHF, UDR):
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 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.
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 information received from NWDAF) occurs at the PCF.
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.
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, MAC address reported for the PDU Session and related port number from the AF 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. 330
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.
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. 331

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. 332
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, Non-IP information 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) 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 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 Non-IP information 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, TS 23.503) in the UDR by invoking Nudr_DM_Update (BDT Reference id, Policy Data, Background Data Transfer, updated data). 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. 334
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.
Step 2.
The PCF is notified when the network performance in the area of interest goes below the criteria set by the operator from the NWDAF 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, TS 23.503) to the H-PCF. 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 decides based on operator policies, whether a new list of candidate Background Data Transfer policies can be calculated. If the PCF does not find any new candidate BDT policy, the previously negotiated BDT policy shall be kept and no interaction with the ASP shall occur.
Step 5-6.
The PCF removes the BDT policy from UDR.
Step 7.
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 8.
The NEF notifies the AF by invoking Nnef_BDTPNegotiation_Notify (Background Data Transfer Reference ID, list of candidate Background Data Transfer policies) service operation.
Step 9.
The AF selects one of the new Background Data Transfer policies included in the candidate list in the BDT warning notification.
Step 10.
The steps 8-13 from clause 4.16.7.2 are executed.
Step 11.
If there is a new Background Data Transfer policy stored in the UDR, the PCFs are notified by the UDR about the storage of the new Background Data Transfer Policy. The PCFs check if the corresponding URSP rules need to be updated 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 notification anymore. Then, the NEF invokes Npcf_BDTPolicyControl_Update service in order to provide this information for the H-PCF.
Up


Up   Top   ToC