Tech-invite  3GPPspecsRELsGlossariesSIP
Info21222324252627282931323334353637384‑5x

full Contents for  TS 23.502  Word version:   16.4.0

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. 325
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.
NOTE:
After this step the PCF can subscribe to SMF events associated with the PDU Session.
Up
4.16.5  SM Policy Association ModificationWord-p. 326
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.
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 (if available) of the DS-TT Ethernet port for the PDU 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. 327
The PCF may initiate SM Policy Association Modification procedure based on local decision or triggered by other peers of the PCF (AF, CHF, UDR).
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.
NOTE:
The PCF ensures that information received in step 1 and 2 can be used by later policy decisions.
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. 329
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. 330
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. 331
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, Reset request for notification). The Reset 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, Reset 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 Reset 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 transfer policies for all the ASPs using Nudr_DM_Query (Policy Data, Background Data Transfer) service operation.
NOTE 1:
If only one PCF is deployed in the PLMN, the transfer policy can be locally stored and no interaction with UDR is required.
Step 4.
The UDR provides all the stored 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 transfer policies. The PCF may interact with the NWDAF and request analytics information on the number of UEs and the Load in the area of interest including one or multiple time periods, as defined in TS 23.288.
NOTE 2:
When the External Group Identifier was provided and the Network Area Information was not provided by the AF at step 1, the NWDAF derives the Network Area Information from the Internal Group ID as defined in clause 6.6 of TS 23.288.
NOTE 3:
The maximum aggregated bitrate is not enforced in the network.
Step 6.
The H-PCF send the acknowledge message to the NEF with the acceptable 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.
NOTE 4:
If the NEF receives only one transfer policy, the AF is not required to confirm.
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 transfer policy, the corresponding network area information, optionally the information of request for notification 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 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. 333
Up
Step 1.
The negotiation for Background Data Transfer (BDT) described in clause 4.16.7.2 is completed.
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 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 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 has to be calculated.
NOTE 1:
The BDT Policies that are applicable for future sessions are checked by the PCF in step 4.
Step 5-6.
The PCF removes the BDT policy from UDR.
NOTE 1:
The BDT Policies that are applicable for future sessions are checked by the PCF in step 4.
Step 7.
The PCF sends the notification to the NEF by invoking Npcf_PolicyControl_Notify (Background Data Transfer Reference ID, optionally Network Area Information, Time window, 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, optionally Network Area Information, Time window, 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.
NOTE 2:
If the AF doesn't select any of the new Background Data Transfer policies next steps are not executed, the previously negotiated Background Data Transfer policy becomes obsolete and not applicable any longer.
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 PCF is notified by UDR and then the PCF identifies if the URSP rules to UE needs to be updated using the procedure defined in clause 4.16.12.2.
The AF can send Reset for 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