Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TS 23.503  Word version:  17.6.0

Top   Top   Up   Prev   Next
0…   4…   5…   6…   6.1.3…   6.1.3.6…   6.2…   6.2.2…   6.3…   6.4…   6.6…   A…

 

6  Functional descriptionp. 26

6.1  Overall descriptionp. 26

6.1.1  Generalp. 26

6.1.1.1  PCF Discovery and Selectionp. 26

The procedures for PCF Discovery and Selection by the AMF and by the SMF are described in TS 23.501.
The procedure to ensure that a consumer NF (e.g. an AF, NEF or PCF for a UE) reaches the PCF selected for a PDU Session is described in clause 6.1.1.2.
The procedure to ensure that a consumer NF (e.g. an AF) reaches the PCF selected for a UE is described in clause 6.1.1.2a.
Up

6.1.1.2  Binding an AF request targeting an UE address to the relevant PCFp. 26

6.1.1.2.1  Generalp. 26
When multiple and separately addressable PCFs have been deployed, a network functionality is required in order to ensure that a consumer NF (e.g. AF) needing to send policies about UE traffic identified by an UE address can reach over N5 the PCF holding the corresponding PDU Session information. This network functionality has the following characteristics:
  • It has information about the user identity, the DNN, the UE (IP or MAC) address(es), the S-NSSAI and the selected PCF address for a certain PDU Session.
    • For IP PDU Session type, it shall receive information when an IP address is allocated or released for a PDU Session.
    • If integration with TSN applies (see clause 5.28 of TS 23.501), it shall receive the DS-TT port MAC address.
    • For Ethernet PDU Sessions supporting binding of AF request based on MAC address, it shall receive information when a MAC address is detected as being used by the UE over the PDU Session (this detection takes place at the UPF under control of SMF and is defined in clause 5.8.2 of TS 23.501). In addition, it receives the DS-TT port MAC address in the case of support of time sensitive communication and time synchronization (as described in clause 5.28.3.2 of TS 23.501).
  • The functionality determines the PCF address and if available the associated PCF instance ID and PCF set ID, selected by the PCF discovery and selection function described in TS 23.501.
A private IPv4 address may be allocated to different PDU Sessions, e.g.:
  • The same UE IPv4 address is allocated to different PDU Sessions to the same DNN and different S-NSSAI;
  • The same UE IPv4 address is allocated to different PDU Sessions to the same S-NSSAI and different DNN.
In the case of private IPv4 address being used for the UE, the AF or the NEF may send DNN S-NSSAI, in addition, in Npcf_PolicyAuthorization_Create request and Nbsf_Management_Discovery request. The DNN and S-NSSAI can be used by the PCF for session binding, and they can be also used to help selecting the correct PCF.
Up
6.1.1.2.2  The Binding Support Function (BSF)p. 27
The BSF has the following characteristics:
  • The BSF stores internally information about the corresponding selected PCF:
    • For a certain PDU Session, the BSF stores internally information about the user identity, the DNN, the UE (IP or MAC) address(es), the S-NSSAI, the selected PCF address and if available the associated PCF instance ID, PCF set ID and the level of binding (see clause 6.3.1.0 of TS 23.501).
    • For a certain UE, the BSF stores internally information about the user identity, the selected PCF address and if available the associated PCF instance ID, PCF set ID and the level of binding (see clause 6.3.1.0 of TS 23.501).
  • The PCF registers, updates and removes the stored information in the BSF using the Nbsf management service operations defined in TS 23.502:
    • For a PDU Session, the PCF ensures that it is updated each time an IP address is allocated or de-allocated to the PDU Session or, for Ethernet PDU Sessions supporting binding of AF request based on MAC address, each time it has been detected that a MAC address is used or no more used by the UE in the PDU Session.
    • For a UE, the PCF ensures that it is updated each time the AMF selects a new PCF.
    • Based on operator's policies and configuration, the PCF determines whether the same PCF shall be selected for the SM Policy Associations to the same UE ID and S-NSSAI combination in the non-roaming or home-routed scenario.
  • Based on operator's policies and configuration, the PCF determines whether the same PCF shall be selected for the SM Policy Associations to the same UE ID and S-NSSAI combination in the non-roaming or home-routed scenario.
  • The selected PCF (if needed) downloads the user profile from the UDR as described in clause 4.16.4 step 2 of TS 23.502. If usage monitoring is enabled for the user, and based on operator's policies, the PCF checks if the BSF has already existing PCF serving the combination of SUPI, S-NSSAI and DNN:
    • If no such PCF is found the PCF shall register itself to the BSF as described above in this clause.
    • Else if an existing PCF is found for the above combination, the PCF shall return to the SMF the available information about the existing PCF and a redirection indication.
  • The BSF verifies whether to provide the address of a PCF for a PDU Session or a PCF for a UE according to the information provided by the consumer NF (e.g. the AF, the NEF, or the PCF for a UE). If the consumer NF provides the user identity and neither a UE address nor a (DNN, S-NSSAI) tuple, the BSF shall provide the address of the PCF for a UE. If the consumer NF (e.g. the PCF for a UE) provides the user identity (e.g. SUPI or GPSI) and the tuple (DNN, S-NSSAI), the BSF shall provide the address of a PCF for a PDU Session for this UE. If the consumer NF (e.g. the AF or the NEF) provides the UE address, the BSF shall provide the address of a PCF for a PDU Session.
  • For retrieval binding information, any NF, such as NEF or AF, that needs to discover the selected PCF address(es), and if available, the associated PCF instance ID, PCF set ID and level of binding (see clause 6.3.1.0 of TS 23.501) for the tuple (UE address, DNN, S-NSSAI, SUPI, GPSI) (or for a subset of this Tuple) uses the Nbsf management service discovery service operation defined in TS 23.502.
  • The NF may discover the BSF via NRF or based on local configuration. When registering the NF profile in NRF, the Range(s) of UE IPv4 addresses, Range(s) of UE IPv6 prefixes supported by the BSF and optionally, the DNN list, S-NSSAI(s) or IP domain list as described in TS 29.510, may be provided to NRF.
  • If the NF received a PCF set ID or a PCF instance ID with an indication of level of binding as result of the Nbsf management service discovery service operation, it should use that information as NF set level or NF instance level Binding Indication to route requests to the PCF as defined in clause 6.3.1.0 of TS 23.501 and according to the following provisions:
    • For the NF set level of binding, the NF will receive a PCF set ID but no PCF instance ID. If an NF is not able to reach the received PCF address(es) and applies direct discovery, it should query the NRF for PCF instances within the PCF set and select another instance.
    • For the NF instance level of binding, the NF will receive a PCF set ID and a PCF instance ID. If an NF is not able to reach the received PCF address(es) and applies direct discovery, it should query the NRF for PCF service instances within the PCF and select another instance.
    • The NF should provide a Routing Binding Indication based on the received PCF set ID, level of binding and possible PCF instance ID in requests it sends to the PCF.
  • For an ongoing NF service session, the PCF may provide Binding indication to the NF (see clause 6.3.1.0 of TS 23.501). This Binding indication shall then be used instead of any PCF information received from the BSF.
  • If a new PCF instance is selected, the new PCF should invoke Nbsf_Management_Update service operation to update the binding information in BSF.
The BSF may be deployed standalone or may be collocated with other network functions, such as PCF, UDR, NRF and SMF.
Up

6.1.1.2a  Binding an NF request targeting a UE to the relevant PCF for a UE |R17|p. 29

When multiple and separately addressable PCFs have been deployed, a network functionality is required in order to ensure that a consumer NF (e.g. AF, 5G DDNMF) reaches the PCF serving the UE. This network functionality is provided by the BSF (described in clause 6.1.1.2.2) and has the following characteristics:
  • It has information about the user identity, and the selected PCF address for a certain UE.
  • The functionality determines the PCF address and if available the associated PCF instance ID and PCF set ID, selected by the PCF discovery and selection function described in TS 23.501.
Up

6.1.1.3  Policy decisions based on network analyticsp. 29

Policy decisions based on network analytics allow PCF to perform policy decisions taking into account analytics information defined for Analytics IDs listed in TS 23.288. The analytics information may be provided by NWDAF directly or via DCCF, depending on the deployment of NWDAF or DCCF. Local configuration in the PCF indicates if one or multiple or all Analytics ID(s) are retrieved either from NWDAF directly or using DCCF. The PCF uses the DCCF services and DCCF service operations to fetch, subscribe and unsubscribe to the Analytics IDs as described in clause 6.1.4 and clause 8 in TS 23.288.
The PCF performs discovery and selection of NWDAF and DCCF as defined in TS 23.501 and subscribes/unsubscribes to Analytics information as defined in TS 23.288. In addition, the AMF and/or SMF may include, in the AM/SM Policy Association establishment or modification procedures, the list of NWDAF instance IDs used for the UE or the PDU Session and their associated Analytics ID(s) consumed by the AMF or SMF respectively. The PCF may select those NWDAF instances as the ones to subscribe for their associated Analytics ID(s) for the UE for which those AM/SM Policy Associations are related to or may perform NWDAF discovery if the NWDAF for an Analytics ID not provided by the AMF or SMF is needed.
The following Analytics IDs are relevant for Policy decisions: "Load level information", "Service Experience", "Network Performance", "Abnormal behaviour", "UE Mobility", "UE Communication", "User Data Congestion", "Data Dispersion" and "WLAN performance". The PCF may subscribe to NWDAF as described below or alternatively, the PCF may use Ndccf_DataManagement_Subscribe including the "Analytics Specification" with the same information as provided in the Nnwdaf_AnalyticsSubscription_Subscribe, and optionally the PCF may include the NWDAF ID, e.g. if provided by AMF or SMF:
  • The PCF may subscribe to notifications of network analytics related to "Load Level Information" using the Nnwdaf_AnalyticsSubscription_Subscribe service operation including the Analytics ID "Load level information", the Analytics Filter "S-NSSAI" and the Analytics Reporting Information set to a load level threshold value. The PCF is notified when the load level of the Network Slice Instance reaches the threshold.
    The NWDAF service to retrieve the Load Level Information is described in clause 6.3 of TS 23.288.
  • The PCF may subscribe to notifications of network analytics related to "Service Experience" using the Nnwdaf_AnalyticsSubscription_Subscribe service operation including the Analytics ID "Service Experience", the Target of Analytics Reporting "SUPI", "Internal Group Id" or "any UE", the Analytics Filter including one or more Application Identifier(s), one or more or "any" RAT Type(s) or Frequency value(s) and the Analytics Reporting Information set to service experience threshold value(s) for the RAT Type(s) and/or Frequency value(s). The PCF is notified on the Service Experience statistics or predictions including, for each Application Identifier, the list of SUPIs for which Service Experience is provided and the list of RAT Types and/or Frequency values for which the Service Experience applies. In addition, both spatial and time validity may be provided as well as the confidence of the prediction.
    The NWDAF service to retrieve the service experience (i.e. the average observed Service MoS) is described in clause 6.4 of TS 23.288.
  • The PCF may subscribe to notifications of network analytics related to "Network Performance" using the Nnwdaf_AnalyticsSubscription_Subscribe service operation including the Analytics ID "Network Performance", the Target of Analytics Reporting "Internal Group Id" and the Analytics Filter including the Area of Interest. The PCF is notified on the Network Performance statistics or predictions including the Area of Interest. In addition, the confidence of the prediction may be provided.
    The NWDAF services to retrieve "Network Performance" as described in clause 6.6 of TS 23.288.
  • The PCF may subscribe to notifications of network analytics related to "Abnormal behaviour" using the Nnwdaf_AnalyticsSubscription_Subscribe service operation including the Analytics ID "Abnormal behaviour", the Target of Analytics Reporting "SUPI", "Internal Group Id" or "any UE" and the Analytics Filter including the expected analytics type or the list of Exceptions IDs and per each Exception Id a possible threshold and other Analytics Filter Information if needed. The list of Exception IDs is specified in TS 23.288.
    The NWDAF services to retrieve "Abnormal behaviour" analytics are described in clause 6.7.5 of TS 23.288.
  • The PCF may subscribe to notifications of network analytics related to "UE Mobility" using NWDAF_AnalyticsSubscription_Subscribe service operation including the Analytics ID "UE Mobility", the Target of Analytics Reporting "SUPI", "Internal Group Id" and the Analytics Filter may include one or more "Area(s) of Interest". The PCF is notified on the UE Mobility statistics or predictions as defined clause 6.7.2 of TS 23.288.
    The NWDAF services to retrieve "UE Mobility" analytics are described in clause 6.7.2 of TS 23.288.
  • The PCF may subscribe to notifications of network analytics related to "UE Communication" using NWDAF_AnalyticsSubscription_Subscribe service operation including the Analytics ID "UE communication", the Target of Analytics Reporting "SUPI", "Internal Group Id" and the Analytics Filter may include one or more "Application Identifier(s)". The PCF is notified on the UE communication statistics or predictions including list of application(s) in use and corresponding characteristics, e.g. start time and duration time. In addition, the confidence of the prediction may be provided.
    The NWDAF services to retrieve "UE Communication" analytics are described in clause 6.7.3 of TS 23.288.
  • The PCF may subscribe to notifications of network analytics related to "User Data Congestion" using NWDAF_AnalyticsSubscription_Subscribe service operation including the Analytics ID "User Data Congestion", the Target of Analytics Reporting containing a SUPI, indication requesting the identifiers of the applications that contribute the most to the traffic and the Analytics Filter may include Area of Interest, reporting threshold and maximum number of applications to be reported. The PCF is notified when the congestion level reaches the threshold. The notification can include the identifiers of the applications that contribute the most to the traffic.
    The NWDAF services to retrieve "User Data Congestion" analytics are described in clause 6.8 of TS 23.288.
  • The PCF may subscribe to notifications of network analytics related to "Data Dispersion" using NWDAF_AnalyticsSubscription_Subscribe service operation including the Analytics ID "UE Dispersion Analytics" and the dispersion analytic (DA) type, i.e. Data or Transactions. The Target of Analytics Reporting containing "SUPI", "Internal Group Id" or "any UE", and the Analytics Filter may include a list of TA(s) or an Area of Interest, or a list of Cells, or an S-NSSAI or top heavy users. With the Data Volume Dispersion Analytics type, the PCF may calculate the average data rate in the network slice by subscribing to notifications of network analytics related to Data Volume Dispersion in the network slice for a duration of interest when it sets the Target of Analytics Reporting as "any UE" and the Analytics Filter as the S-NSSAI.
    The NWDAF services to retrieve "Data Dispersion" analytics are described in clause 6.10 of TS 23.288.
  • The PCF may subscribe to notifications of network analytics related to "WLAN performance" using the Nnwdaf_AnalyticsSubscription_Subscribe service operation including the Analytics ID "WLAN performance", the Target of Analytics Reporting "SUPI", "Internal Group Id" or "any UE" and the Analytics Filter including the Area of Interest, SSID(s), or BSSID(s). The PCF is notified on the WLAN performance statistics or predictions. In addition, the confidence of the prediction may be provided.
    The NWDAF services to retrieve "WLAN performance" analytics are described in clause 6.11 of TS 23.288.
Possible triggers for the PCF to subscribe to analytics information from the NWDAF may include:
  • Requests from AF/NEF;
  • AM Policy Association establishment or modification request from the AMF;
  • SM Policy Association establishment or modification request from the SMF;
  • Notifications received from UDR or CHF on UE subscription change;
  • Analytics information received.
The trigger conditions may depend on operator and implementation policy in the PCF. When a trigger condition happens, the PCF may check local configuration or evaluate operator policy to decide if any analytics information is needed and if so, initiate a subscription to the analytics information from the NWDAF directly or via DCCF, if deployed.
The PCF may, upon a request from AF/NEF for negotiation for future background data transfer, subscribe to the network analytics related to "Network Performance" from the NWDAF directly or via DCCF, if deployed to assist in determination of BDT policies as described in clause 6.1.2.4.
The PCF may, upon AM or SM Policy Association establishment or modification request from the AMF or SMF, or based on notifications received from UDR or CHF on UE subscription change, decide that network analytics related to "Abnormal behaviour", "UE Mobility" or "UE Communication" of the UE is needed for policy decision and therefore subscribe to notifications of network analytics related to "Abnormal behaviour", "UE Mobility" or "UE Communication" of the UE from the NWDAF.
The PCF may, upon reception of analytics information, subscribe to other analytics information from the NWDAF directly or via DCCF, if deployed.
The PCF may use the network analytics information as input to its policy decision to apply operator defined actions for session management related policy control (as described in clauses 6.1.3), non-session management related policy control (as described in clause 6.1.2) and network slice related policy control (as described in clause 6.1.4.
Examples of operator policies including network analytics information as inputs for policy decisions included below:
  • Based on the notification of "Load Level Information" of the Network Slice Instance, the PCF may verify if the RFSP index value needs to be modified for a SUPI for which an AM Policy Association is created; this is based on operator policies in the PCF, as defined in clause 6.1.2.1.
  • Based on the "Service Experience" statistics or predictions, the PCF may check the 5QI values assigned to the Application, and may use this as input to calculate and update the authorized QoS for a service data flow template.
  • The PCF may use the network analytics related to "Network Performance" as input to calculate the background data transfer policies that are negotiated with the ASP, as defined in clause 6.1.2.4.
  • Based on the UE mobility statistics or predictions, the PCF may adjust Service Area Restriction as defined in clause 6.1.2.1.
  • The PCF may use the network analytics related to "Unexpected UE location" as input to determine the Service Area Restrictions defined in clause 6.1.2.1, "Suspicion of DDoS attack" or "Too frequent Service Access" to request the SMF to terminate the PDU Session as defined in clause 6.1.3.6, "Wrong destination address" to perform gating of a service data flow as defined in clause 6.1.3.6 and "Unexpected long-live/large rate flows" to perform QoS related policies such as gating or policing as defined in clause 6.2.1.1.
  • Based on the WLAN performance statistics or predictions, the PCF may update WLANSP as defined in clause 6.1.2.2.1.
  • Based on the "User Data Congestion" statistics or predictions including the list of applications contributing the most to the traffic the PCF may perform SM Policy Association modifications to update policies in the SMF for the PDU sessions handling traffic from those applications.
  • The PCF may use the network analytics on "Service Experience" for an Application Identifier, "any RAT type" and/or "any Frequency value" to determine the RFSP Index value for running this application, as described in clause 6.1.2.1.
  • The PCF may also use the network analytics as input to its policy decision to apply operator defined actions for example for the UE context(s) or PDU Session(s).
Examples of operator policies including combination of multiple network analytics as inputs for policy decisions are included below:
  • Based on the notification of application(s) in use, provided by "UE Communication" analytics, the PCF may request the "Service Experience" analytics (optionally per RAT Type and/or per Frequency) for each application in use as defined in the list of examples of operator policies that may include network analytics as input for a policy decision.
  • Based on the notification of "User Data Congestion", the PCF may further request the NWDAF directly or via DCCF, if deployed, to report the "Data Dispersion Analytics" of either a UE or just the Top Heavy UEs located at the congested area of interest. To mitigate the reported or predicted congestion at the area of interest, the PCF may perform:
    • AM Policy Association modification to update UE-AMBR, RFSP index and/or service area restriction, for those UEs reported as heavy users.
    • SM Policy Association modification to update the policies in the SMF for those UEs reported as heavy users.
Up

6.1.2  Non-session management related policy controlp. 32

6.1.2.1  Access and mobility related policy controlp. 32

The access and mobility related policy control encompasses the management of service area restrictions, the management of the RFSP Index, the management of the UE-AMBR, the management of the UE Slice-MBR and the management of the SMF selection. This clause defines the management of service area restrictions and RFSP Index for a UE registered over 3GPP access. The management of service area restrictions for a 5G-RG or a FN-CRG using W-5GAN are specified in TS 23.316.
The management of service area restrictions enables the PCF of the serving PLMN (e.g. V-PCF in roaming case) to modify the service area restrictions used by AMF as described in clause 5.3.4 of TS 23.501.
A UE's subscription may contain service area restrictions, which may be further modified by PCF based on operator defined policies at any time, either by expanding a list of allowed TAIs or by reducing a non-allowed TAIs or by increasing the maximum number of allowed TAIs. Operator defined policies in the PCF may depend on input data such as UE location, time of day, information provided by other NFs such as an AF request to change the service coverage, network analytics from NWDAF, etc.
The AMF may report the subscribed service area restrictions received from UDM during Registration procedure or when the AMF changed, the conditions for reporting are that local policies in the AMF indicate that access and mobility related policy control is enabled. The AMF reports the subscribed service area restrictions to the PCF also when the policy control request trigger for service area restrictions changes, as described in clause 6.1.2.5, is met. The AMF receives the modified service area restrictions from the PCF. The AMF stores them and then uses it to determine mobility restriction for a UE. The PCF may indicate to the AMF that there is an unlimited service area.
The service area restrictions consist of a list of allowed TAI(s) or a list of non-allowed TAI(s) and optionally the maximum number of allowed TAIs.
The management of the RFSP Index enables the PCF to modify the RFSP Index used by the AMF to perform radio resource management functionality as described in clause 5.3.4 of TS 23.501. The PCF modifies the RFSP Index based on operator policies that take into consideration e.g. accumulated usage, load level information per network slice instance, the indication that high throughput is desired for a specific application traffic or independently of the application in use and other information described in clause 6.1.1.3. The subscribed RFSP Index may be further adjusted by the PCF based on operator policies at any time.
The determination of the RFSP Index value requires to configure the PCF with the mapping of RAT Type and/or Frequency value to the RFSP Index that will be sent to RAN.
Operator policies in the PCF may determine that the access and mobility related policy information (e.g. RFSP index value or service area restrictions) can change at the start and stop of an application traffic detection, at the start and stop of a SM Policy Association to a DNN and S-NSSAI, or immediately. In the former case, the PCF subscribes to the SMF for application traffic detection as described in clause 6.2.2.5. In addition, when the PCF evaluates that the access and mobility related policy information need any changes, the PCF reports it to the AF if the AF has subscribed to the notification on outcome of service area coverage change as defined in clause 6.1.3.18.
For radio resource management, the AMF may report the subscribed RFSP Index received from UDM during the Registration procedure or when the AMF changed. The conditions for reporting are that local policies in the AMF indicate that access and mobility related policy control is enabled. The AMF reports the subscribed RFSP Index to the PCF when the subscription to the RFSP Index change to the PCF is met. The AMF receives the modified RFSP Index from the PCF.
Upon change of AMF, the source AMF informs the PCF that the UE context was removed in the AMF in the case of inter-PLMN mobility.
The management of UE-AMBR enables the PCF to provide the UE-AMBR information to the AMF based on serving network policy. The AMF may report the subscribed UE-AMBR received from UDM. The conditions for reporting are that the PCF provided Policy Control Request Triggers the AMF to report subscribed UE-AMBR. The AMF receives the modified UE-AMBR from the PCF. The AMF provides a UE-AMBR value of the serving network to the RAN as specified in clause 5.7.2.6 of TS 23.501.
The management of the SMF selection enables the PCF to instruct the AMF to contact the PCF during the PDU Session Establishment procedure to perform a DNN replacement, as specified in clause 5.6.1 of TS 23.501. To indicate the conditions to check whether to contact the PCF at PDU Session establishment (as specified in clause 6.1.2.5), the PCF provides the Policy Control Request Triggers SMF selection management and, if necessary Change of the Allowed NSSAI, together with SMF selection management related policy information (see clause 6.5) during UE Registration procedure and at establishment of the AM Policy Association.
The PCF may update the SMF selection management information based on a PCF local decision or upon being informed about a new Allowed NSSAI. The AMF applies the updated SMF selection management information to new PDU Sessions only, i.e. already established PDU Sessions are not affected.
The optional management of UE-Slice-MBR enables the PCF to modify the value in the list of Subscribed UE-Slice-MBR assigned to a SUPI based on serving network policies, if the HPLMN permits based on roaming agreement. The AMF reports the Subscribed UE-Slice-MBR for each S-NSSAI of the serving network . The S-NSSAI of the VPLMN is derived from the Subscribed S-NSSAI by the AMF and provided to the PCF. The AMF may provide the Subscribed S-NSSAI together with the S-NSSAI of the VPLMN. The conditions for reporting are defined in clause 6.1.2.5. The PCF returns the authorized UE-Slice-MBR for the S-NSSAI of the serving network. The AMF receives the authorized list of UE-Slice-MBR value for each S-NSSAI for which it has provided the Subscribed UE-Slice-MBR from the PCF. Then the AMF provides the authorized list of UE-Slice-MBR for the S-NSSAIs in the Allowed S-NSSAI to the RAN as specified in clause 5.7.1.10 of TS 23.501.
The optional management of 5G access stratum time distribution enables the PCF for the UE to instruct the AMF about the 5G access stratum time distribution parameters, i.e., 5G access stratum time distribution indication (enable, disable). Optionally, when 5G access stratum time distribution or (g)PTP time synchronization is enabled, the PCF for the UE instructs the AMF about the Uu Time synchronization error budget.
In the case that the PCF for the UE (providing the access and mobility related policy information) and the PCF for the PDU Session of this UE (providing the Session Management related policies) are separate PCF instances, the following applies:
  • If the PCF for the UE determines that the access and mobility related policy information can change at the start and stop of an application traffic detection, the following applies:
    • The PCF for the UE may subscribes to be notified about the PCF binding information when a PCF for the PDU Session (of this UE) is registered in the BSF, including the SUPI, DNN, S-NSSAI. The DNN, S-NSSAI is either provided by the AF or locally configured in the PCF for certain Application Identifier(s). An alternative mechanism for the PCF for the UE to be notified of the PCF for the PDU Session of this UE is to request the AMF to send to the PCF for the PDU Session of the DNN, S-NSSAI, via SMF, the request for notification of SM Policy Association establishment. In this case, the PCF for the PDU Session should subscribe Request for notification on SM Policy Association establishment or termination Policy Control Request Trigger as described in clause 6.1.3.5 to get the binding information of PCF for the UE (as defined in clause 6.1.1.2.2).
    • When the PCF for the UE is notified that PCF for the PDU Session is registered, either via the BSF that provides the UE address, DNN and the PCF address, PCF instance Id and PCF set id if available or via PCF for the PDU Session when it received a request for notification from the SMF. The PCF for the UE may subscribe to the "start/stop of application traffic detection" event defined in clause 6.1.3.18 or trigger a policy decision if there is a SM Policy Association to the DNN, S-NSSAI.
    • The reporting of "start/stop of application traffic detection" to the PCF for the UE is used as input for a policy decision to change the access and mobility related policy information.
  • If the PCF for the UE determines that the access and mobility related policy information can change at the establishment and termination of a SM Policy Association to a DNN and S-NSSAI base on the notification sent by the BSF, the PCF may indicate to the BSF to report 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.
  • The PCF for the UE checks if an AF is subscribed to be notified on outcome of service area coverage change, using the related event defined in clause 6.1.3.18.
Up

6.1.2.2  UE policy controlp. 34

6.1.2.2.1  Generalp. 34
The 5GC shall be able to provide policy information from the PCF to the UE. Such UE policy information includes:
  1. Access Network Discovery & Selection Policy (ANDSP): It is used by the UE for selecting non-3GPP accesses and for selection of the N3IWF in the PLMN. The structure and the content of this policy are specified in clause 6.6.1.
  2. UE Route Selection Policy (URSP): This policy is used by the UE to determine if a detected application can be associated to an established PDU Session, can be offloaded to non-3GPP access outside a PDU Session, can be routed via a ProSe Layer-3 UE-to-Network Relay outside a PDU session, or can trigger the establishment of a new PDU Session. The structure and the content of this policy are specified in clause 6.6.2. A URSP rule includes one Traffic descriptor that specifies the matching criteria and one or more of the following components:
    1. SSC Mode Selection Policy (SSCMSP): This is used by the UE to associate the matching application with SSC modes.
    2. Network Slice Selection Policy (NSSP): This is used by the UE to associate the matching application with S-NSSAI.
    3. DNN Selection Policy: This is used by the UE to associate the matching application with DNN.
    4. PDU Session Type Policy: This is used by the UE to associate the matching application with a PDU Session Type.
    5. Non-Seamless Offload Policy: This is used by the UE to determine that the matching application should be non-seamlessly offloaded to non-3GPP access (i.e. outside of a PDU Session).
    6. Access Type preference: If the UE needs to establish a PDU Session for the matching application, this indicates the preferred Access Type (3GPP or non-3GPP or Multi-Access).
    7. ProSe Layer-3 UE-to-Network Relay Offload Policy: This is used by the UE to determine if the matching application should be routed via a ProSe Layer-3 UE-to-Network Relay outside of a PDU Session. If this indication is not present the traffic shall not be routed via a ProSe Layer-3 UE-to-Network Relay outside of a PDU Session.
    8. PDU Session Pair ID: If the UE needs to establish a PDU Session for the matching application, this indicates PDU Sessions with same PDU Session Pair ID are paired for redundant transmission.
    9. RSN: If the UE needs to establish a PDU Session for the matching application, this indicates RSN for redundant transmission.
  3. V2X Policy (V2XP): This policy provides configuration parameters to the UE for V2X communication over PC5 reference point or over Uu reference point or both. V2X Policies are defined in clause 5.1.2.1 and clause 5.1.3.1 of TS 23.287.
  4. ProSe Policy (ProSeP): This policy provides configuration parameters to the UE for ProSe Direct Discovery, ProSe Direct Communication, ProSe UE-to-Network Relay and Remote UE. ProSe Policies are defined in clauses 5.1.2.1, 5.1.3.1 and 5.1.4.1 of TS 23.304.
The ANDSP and URSP may be pre-configured in the UE or may be provisioned to UE from PCF. The pre-configured policy shall be applied by the UE only when it has not received the same type of policy from PCF.
The methods of configuring V2XP to the UE, including (pre-) configuration and provisioning, and the priority of the same type of parameters acquired from different sources are defined in clause 5.1.1 of TS 23.287.
The methods of configuring ProSeP to the UE, including (pre-)configuration and provisioning, and the priority of the same type of parameters acquired from different sources are defined in clause 5.1.1 of TS 23.304.
The PCF selects the ANDSP and URSP applicable for each UE based on local configuration, and operator policies taking into consideration the information defined in clause 6.2.1.2.
In the case of a roaming UE, the V-PCF may retrieve UE policy information from the H-PCF over N24/Npcf. When the UE is roaming and the UE has valid rules from both HPLMN and VPLMN the UE gives priority to the valid ANDSP rules from the VPLMN.
The UE policy information shall be provided from the PCF to the AMF via N15/Namf interface and then from AMF to the UE via the N1 interface as described in clause 4.2.4.3 of TS 23.502. The AMF shall not change the UE policy information provided by PCF.
The PCF is responsible for delivery of UE policy. If the PCF is notified about UE policy information delivery failure (e.g. because of UE unreachable), the PCF may provide a new trigger "Connectivity state changes" in Policy Control Request Trigger of UE Policy Association to AMF as defined in clause 4.16.12.2 of TS 23.502. After reception of the Notify message indicating that the UE enters the CM-Connected state, the PCF may retry to deliver the UE policy information.
If due to UE Local Configurations, a UE application requests a network connection using Non-Seamless Offload or ProSe Layer-3 UE-to-Network Relay Offload, the UE shall use Non-Seamless Offload for this application without evaluating the URSP rules. Otherwise, the UE shall select the PDU Session or Non-Seamless Offload in the following order:
  • If the UE has an URSP rule (except the URSP rule with the "match all" Traffic descriptor) that matches the application as defined in clause 6.6.2.3, the UE shall perform the association of the application to the corresponding PDU Session or to Non-Seamless Offload or ProSe Layer-3 UE-to-Network Relay Offload according to this rule; Otherwise,
  • If no URSP rule is applicable for the application (except the URSP rule with the "match all" Traffic descriptor), the UE shall perform the association of the application to a PDU Session according to the applicable UE Local Configurations, if any. If the UE attempts to establish a new PDU Session according to the UE Local Configurations and this PDU Session Establishment request is rejected by the network, then the UE shall perform the association of the application to a PDU Session or to Non-Seamless Offload or ProSe Layer-3 UE-to-Network Relay Offload according to the URSP rule with the "match all" Traffic descriptor; Otherwise,
  • If neither the UE Local Configurations nor the URSP rules are applicable for the application (except the URSP rule with the "match all" Traffic descriptor), the UE shall perform the association of the application to a PDU Session or to Non-Seamless Offload or ProSe Layer-3 UE-to-Network Relay Offload according to the URSP rule with the "match all" Traffic descriptor.
For the existing PDU Session(s), the UE shall examine the URSP rules within the UE policy information in order to determine whether the existing PDU Session(s) (if any) are maintained or not. If not, then the UE may initiate a PDU Session release procedure for the PDU Session(s) that cannot be maintained.
If there are multiple IPv6 prefixes within the PDU Session, then the IPv6 multi-homed routing rules, described in clause 5.8.2.2.2 of TS 23.501, on the UE shall be used to select which IPv6 prefix to route the traffic of the application.
The PCF may subscribe to analytics on "WLAN performance" from NWDAF following the procedures and services described in TS 23.288. When the PCF gets a notification from the NWDAF, the PCF may try to update WLANSP rules.
Up
6.1.2.2.2  Distribution of the policies to UEp. 36
The UE policy control enables the PCF to provide UE access selection related policy information, PDU Session related policy information and V2X Policy information to the UE, i.e. UE policies, that includes Access network discovery & selection policy (ANDSP) or UE Route Selection Policy (URSP) or V2X Policy (V2XP) or ProSe Policy (ProSeP) or their combinations using Npcf and Namf service operations.
The PCF may be triggered to provide the UE access selection and PDU Session related policy information during UE Policy Association Establishment and UE Policy Association Modification procedures as defined in clause 4.16.11 and clause 4.16.12 of TS 23.502.
Operator defined policies in the PCF may depend on input data such as UE location, time of day, information provided by other NFs, etc. as defined in clause 6.2.1.2.
The PCF includes the UE policy information delivered to the UE into a Policy Section identified by a Policy Section Identifier (PSI). The PCF may divide the UE policy information into different Policy Sections, each one identified by a PSI. Each Policy Section provides a list of self-contained UE policy information to the UE, via AMF. The PCF ensures that a Policy Section is under a predefined size limit, known by the PCF.
A list of self-contained UE policy information implies that:
  • when the PCF delivers URSP rules to the UE, the PCF provides the list of URSP rules in the order of precedence and without splitting a URSP rule across Policy Sections;
  • when the PCF delivers V2XP to the UE, the PCF provides the list of V2XP in the order of precedence and without splitting a V2XP across Policy Sections;
  • when the PCF delivers ProSeP to the UE, the PCF provides the list of ProSeP in the order of precedence and without splitting a ProSeP across Policy Sections;
  • when the PCF delivers WLANSP rules, the list of WLANSP rules are provided in the order of priority and without splitting a WLANSP rule across Policy Sections;
  • when the PCF delivers the non-3GPP access network selection information, the whole list of non-3GPP access network selection information (as defined in clause 6.6.1.1) is provided in one Policy Section.
It is up to PCF decision how to divide the UE policy information into Policy Sections as long as the requirements for the predefined size limit and the self-contained content (described above) are fulfilled.
The PLMN ID is provided to the UE together with UE access selection or PDU Session related policy information and it is used to indicate which PLMN a Policy Section list belongs to.
The AMF forwards the UE policy information transparently to the UE. If the (H-)PCF decides to split the UE policies to be sent to the UE, the PCF provides multiple Policy Sections separately to the AMF and then AMF uses UE configuration Update procedure for transparent UE policies delivery procedure to deliver the policies to the UE, this is defined in clauses 4.2.4.3 and 4.16 of TS 23.502.
The UE shall update the stored UE policy information with the one provided by the PCF as follows (details are specified in TS 24.501):
  • If the UE has no Policy Sections with the same PSI, the UE stores the Policy Section;
  • If the UE has an existing Policy Section with the same PSI, the UE replaces the stored Policy Section with the received information;
  • The UE removes the stored Policy Section if the received information contains only the PSI.
The UE keeps the received UE policies stored even when registering in another PLMN. The number of UE policies to be kept stored in the UE for PLMNs other than the HPLMN is up to UE implementation. If necessary, e.g. the number of UE policies stored in UE for PLMNs exceeds the maximum value, the UE may remove earlier stored UE policy in UE.
The ANDSP for VPLMN, if provided within the UE policy in the UE Configuration Update procedure described in clause 4.2.4.3 of TS 23.502, applies to the equivalent PLMN(s) indicated in the last received list of equivalent PLMNs in Registration Accept.
At Initial Registration or the Registration to 5GS when the UE moves from EPS to 5GS:
  • The UE provides the list of stored PSIs which identify the Policy Sections associated to the home PLMN and the visited PLMN (if the UE is roaming) that are currently stored in the UE. If USIM is changed, the UE does not provide any PSI. If no policies are stored in the UE for the home PLMN, the UE does not provide any PSI associated to the home PLMN. If the UE is roaming and has policies for the home PLMN but no associated policies for the visited PLMN the UE includes only the list of PSIs associated to the home PLMN.
  • UE may indicate its ANDSP support to the PCF. If it is received, the PCF shall take it into account for the determination on whether to provide the ANDSP to the UE. The PCF does not provide ANDSP rules to the UE if the UE does not indicate support for ANDSP.
  • UE may indicate the V2X Policy Provisioning Request in the UE Policy Container. If this indication is received, the PCF includes V2XP in the UE policy information as defined in clause 6.2.2 of TS 23.287.
  • UE may indicate the 5G ProSe Policy and Parameter Provisioning Request in the UE Policy Container. If this indication is received, the PCF includes ProSeP in the UE policy information as defined in clause 6.2.2 of TS 23.304. PCF determines contents of ProSeP based on the information contained in the 5G ProSe Policy and Parameter Provisioning Request as defined in clause 4.3.1 of TS 23.304.
  • The UE may also provide the OSId.
The UE may trigger an Initial registration with the list of stored PSIs to request a synchronization for example if the UE powers up without USIM being changed.
During Initial Registration, the (H-)PCF retrieves the list of PSIs and its content stored in the (H-)UDR for this SUPI while the V-PCF (in the roaming scenario) retrieves the list of PSIs and its content stored in the V-UDR for the PLMN ID of this UE (alternatively, the V-PCF can have this information configured locally).
In the roaming scenario, the V-PCF shall also forward any UE provided PSIs that are associated to the home PLMN to the H-PCF.
When the PCF (i.e. the (H-)PCF as well as the V-PCF) receives a list of PSIs associated to the PLMN of the PCF from the UE, the PCF compares the list of PSIs provided by the UE and the list of PSIs retrieved from the UDR. In addition, the PCF checks whether the list of PSIs provided by the UE or its content needs to be updated according to operator policies, e.g. change of Location and/or time. If the two lists of PSIs are different or an update is necessary according to operator policies (which includes the case that the UE did not provide a list of PSIs associated to the PLMN of the PCF), the PCF provides the changes in the list of PSIs or the corresponding content to the AMF which forwards them to the UE.
The (H-)PCF maintains the latest list of PSIs delivered to each UE as part of the information related to the Policy Association until the UE policy association termination request is received from the AMF. Then the (H-)PCF stores the latest list of PSIs and its contents in the (H-)UDR using the Nudr_DM_Update including DataSet "Policy Data" and Data Subset "Policy Set Entry".
The (H-)PCF may use the PEI provided by the AMF and/or the OSId provided by the UE, to determine the operating system of the UE.
If the PEI, the OSId or the indication of UE support for ANDSP is available to the PCF, the PCF stores them in the UDR using Nudr_DM_Create including DataSet "Policy Data" and Data Subset "UE context policy control data" when such information is received from the UE in the UE Policy Container.
If the (H-)PCF is not able to determine the operating system of the UE, and if the (H-)PCF requires to deliver URSP rules that contain Application descriptors as Traffic Descriptors, then the Traffic Descriptors of such URSP rules include multiple instances of Application descriptors each associated to supported UE operating systems by the network operator implementation.
If the (H-)PCF determines the operating system of the UE and if the (H-)PCF requires to deliver URSP rules that contain Application descriptors as Traffic Descriptors, then the Traffic Descriptors of such URSP rules include the Application descriptors associated with the operating system determined by the PCF.
Up

6.1.2.3  Management of packet flow descriptionsp. 38

6.1.2.3.1  PFD managementp. 38
The Management of Packet Flow Descriptions enables the UPF to perform accurate application detection when PFD(s) are provided by an ASP and then to apply enforcement actions as instructed in the PCC Rule.
The operator is able to configure pre-defined PCC Rules in the SMF or dynamic PCC Rules in the PCF that include at least an application identifier for service data flow detection, charging control information, i.e. charging key and optionally the Sponsor identifier or the ASP identifier or both. Depending on the service level agreements between the operator and the Application Server Provider, it may be possible for the ASP to provide individual PFDs or the full set of PFDs for each application identifier maintained by the ASP to the SMF via the PFD Management service in the NEF (PFDF). The PFDs become part of the application detection filters in the SMF/UPF and therefore are used as part of the logic to detect traffic generated by an application. The ASP may remove or modify some or all of the PFDs which have been provided previously for one or more application identifiers. The SMF may report the application stop to the PCF for an application instance identifier as defined in clause 5.8.2.8.4 of TS 23.501 if the removed/modified PFD in SMF/UPF results in that the stop of the application instance is not being able to be detected.
The ASP manages (provision, update, delete) the PFDs through the NEF (PFDF). The PFD(s) are transferred to the SMF through the NEF (PFDF). The PFDF is a logical functionality in the NEF which receives PFD(s) from the ASP through the NEF, stores the PFD(s) in the UDR and provides the PFD(s) to the SMF(s) either on the request from ASP PFD management through NEF (PFDF) (push mode) or on the request from SMF (pull mode). The PFDF functionality is a service provided by the NEF.
The ASP may provide/update/remove PFDs with an allowed delay to the NEF (PFDF). Upon reception of the request from the ASP, the NEF (PFDF) shall check if the ASP is authorized to provide/update/remove those PFD(s) and request the allowed delay. The NEF (PFDF) may be configured with a minimum allowed delay based on SLA to authorize the allowed delay provided by the ASP. When ASP and requested allowed delay are successfully authorized, the NEF (PFDF) shall translate each external application identifier to the corresponding application identifier known in the core network. The NEF (PFDF) stores the PDF(s) into the UDR.
The PFDs may be retrieved by SMF from NEF (PFDF) in "pull" mode or may be provisioned from NEF (PFDF) to the SMF in "push" mode.
When the "push" mode is used, the NEF (PFDF) retrieves from the UDR the PFDs for each application identifier and distributes them to those SMFs that enable access to those applications. There are three methods to provision PFD(s) from the NEF (PFDF) to the SMF:
  1. Push of whole PFD(s) that can be accessed by the NEF (PFDF) according to operator configuration in NEF (PFDF) (e.g. provision per day according to operator configuration);
  2. Selective push of an ASP change in the PFD set (i.e. ASP changes the PFD set while operator configuration defines when to push);
  3. Selective push of an ASP change in the PFD set according to ASP request (i.e. ASP indicates to push changes in a PFD set within the time interval indicated by the Allowed Delay).
When the "pull" mode is used, at the time a PCC Rule with an application identifier for which PFDs are not available is activated or provisioned, the SMF requests all PFDs for that application identifier from the NEF (PFDF), and NEF (PFDF) retrieves them from the UDR. The PFD(s) retrieved for an application identifier from the NEF (PFDF) are cached in the SMF, and the SMF maintains a caching timer associated to the PFD(s) to control how long the PFD(s) are valid. When the caching timer expires:
  • If there are still active PCC rules that refer to the corresponding application identifier, the SMF reloads the PFD(s) from the NEF (PFDF) and provides it to the UPF over N4;
  • If there's no active PCC rule that refers to the corresponding application identifier or the SMF removes the last PCC rule that refers to the corresponding application identifier, the SMF removes the PFD(s) identified by the application identifier and informs the UPF to remove the PFD(s) identified by the application identifier over N4.
When the "pull" mode is used, the NEF (PFDF) may provide to the SMF a caching time value per application identifier. The SMF receives the caching time value together with the PFD(s) from the NEF (PFDF) over N29 and applies this value for the application identifier instead of the configured default caching time value. If no caching time value is received from NEF (PFDF), the SMF uses the configured default caching time value.
When only "pull" mode is used in one PLMN for an application identifier, if the Allowed Delay is shorter than the caching time value stored for this application identifier, or shorter than the default caching time if no application-specific caching time is stored, the NEF (PFDF) may still store the PFD(s) to the UDR. The NEF (PFDF) shall provide an indication that the PFD(s) were stored and the caching time value to the ASP when informing that the Allowed Delay could not be met.
When either "pull" mode or "push" mode is used, if there's any update of the PFD(s) received and there are still active application detection rules in the UPF for the application identifier, the SMF shall provision the updated PFD set corresponding to the application identifier to the UPF.
When the UPF receives the updated PFD(s) from either the same or different SMF for the same application identifier, the latest received PFD(s) shall overwrite any existing PFD(s) stored in the UPF.
If the PFDs are managed by local O&M procedures, PFD retrieval is not used; otherwise, the PFDs retrieved from NEF (PFDF) overrides any PFDs pre-configured in the SMF. The SMF shall manage the pre-configured PFDs and PFDs provided by the NEF (PFDF) at the UPF as defined in clause 5.8.2.8.4 of TS 23.501. The SMF may differentiate the need for PFD retrieval based on operator configuration in the SMF.
The AF requests including an application identifier may trigger the activation or provisioning of a PCC Rule in the SMF by the PCF based on operator policies.
Up
6.1.2.3.2  Packet Flow Descriptionp. 40
PFD (Packet Flow Description) is a set of information enabling the detection of application traffic.
Each PFD may be identified by a PFD id. A PFD id is unique in the scope of a particular application identifier. Conditions for when PFD ID is included in the PFD is described in TS 29.551. There may be different PFD types associated to an application identifier.
A PFD include the following information:
  • PFD id; and
  • one or more of the following:
    • 3-tuple(s) including protocol, server side IP address and port number;
    • the significant parts of the URL to be matched, e.g. host name;
    • a Domain name matching criteria and information about applicable protocol(s).
Up

6.1.2.4  Negotiation for future background data transferp. 40

The AF may contact the PCF via the NEF (and Npcf_BDTPolicyControl_Create service operation) to request a time window and related conditions for future background data transfer (BDT).
The AF request shall contain an ASP identifier, the volume of data to be transferred per UE, the expected amount of UEs, the desired time window, the External Group Identifier and optionally, Network Area Information, MAC address or IP 3-tuple to identify the Application server, request for notification. The AF provides as Network Area Information either a geographical area (e.g. a civic address or shapes), or an area of interest that includes a list of TAs or list of NG-RAN nodes and/or a list of cell identifiers. When the AF provides a geographical area, then the NEF maps it based on local configuration into of a short list of TAs and/or NG-RAN nodes and/or cells identifiers that is provided to the PCF. The NEF may map the ASP identifier based on local configuration to a DNN and S-NSSAI that is in addition provided to the PCF. The MAC address or IP 3-tuple to identify the Application server may be provided by the AF or may be locally configured at the PCF and it is used for the generation of a URSP rule for the application as well as a PCC rule for the application traffic. The request for notification is an indication that the ASP accepts that the BDT policy can be re-negotiated using the BDT warning notification procedure described in clause 4.16.7.3 of TS 23.502.
The PCF shall first retrieve all existing BDT policies stored for any ASP from the UDR. The PCF may retrieve analytics on "Network Performance" from NWDAF following the procedure and services described in TS 23.288. Afterwards, the PCF shall determine, based on the information provided by the AF, the analytics on "Network Performance" if available and other available information (e.g. network policy and existing BDT policies) one or more BDT policies. The PCF may be configured to map the ASP identifier to a target DNN and S-NSSAI if the NEF did not provide the DNN, S-NSSAI to the PCF.
A BDT policy consists of a recommended time window for the background data transfer, a reference to a charging rate for this time window and optionally a maximum aggregated bitrate (indicating that the charging according to the referenced charging rate is only applicable for the aggregated traffic of all involved UEs that stays below this value). Finally, the PCF shall provide the candidate list of BDT policies to the AF via NEF together with the Background Data Transfer Reference ID. If the AF received more than one BDT policy, the AF shall select one of them and inform the PCF about the selected BDT policy.
The selected BDT policy together with the Background Data Transfer Reference ID, the network area information, the volume of data to be transferred per UE, the expected amount of UEs, ASP identifier, MAC address or IP 3-tuple to identify the Application server, the one or more route selection component (DNN, S-NSSAI), the desired time window and whether the AF accepts BDT policy re-negotiation or not is stored by the PCF in the UDR as Data Set "Policy Data" and Data Subset "Background Data Transfer data". The same or a different PCF can retrieve this BDT policy and the corresponding related information from the UDR and take them into account for future decisions about BDT policies related to the same or other ASPs.
When the AF wants to apply the Background Data Transfer Policy to an existing session, then the AF will, at the time the BDT is about to start, provide, for each UE, the Background Data Transfer Reference ID together with the AF session information to the PCF (via the N5 interface). The PCF retrieves the corresponding BDT policy from Policy Data Set in the UDR and derives the PCC rule for the BDT according to this transfer policy.
When the AF wants to apply the Background Data Transfer Policy to a future session, then the AF provides, to the NEF, the Background Data Transfer Reference ID together with the External Identifier (i.e. GPSI) or External Group Identifier of the UE(s) that are subject to the policy. The NEF translates the External Group Identifier into the Internal Group Identifier or the External Identifier into a SUPI. The NEF stores the Background Data Transfer Reference ID, in the UDR as Application Data Set and Background Data transfer data Subset for an Internal Group Identifier or a SUPI and the ASP identifier requesting to apply the Background Data transfer Policy to a future session for the UE(s). A PCF that serves the UE(s) (i.e. the PCF that serves the UE for UE Policies) may retrieve the Background Data Transfer Reference ID by retrieving the UE's Application Data from the UDR or by subscribing to notifications of changes to the UEs' Application Data in the UDR. Furthermore, the PCF retrieves the specific Background Data Transfer Policy and the corresponding network area information and the MAC address or IP 3-tuple to identify the Application server based on the received Background Data Transfer Reference ID stored as Policy Data Set from the UDR.
When the PCF determines to send a URSP rule related to the Background Data Transfer Policy to the UE, the PCF creates the URSP rule using the MAC address or IP 3-tuple (to identify the Application server) as Traffic descriptor. The RSD part of the URSP rule is populated with the S-NSSAI and DNN associated with the ASP identifier. The Route Selection Validation Criteria of the URSP rule (see clause 6.6.2.1) is populated with the Time Window set to the recommended time window of the BDT policy and, if the BDT policy is not applicable for the whole network, the Location Criteria is set to the network area information of the BDT policy. The PCF will store the URSP rule in the UDR as part of the UE's Policy Set Entry. The PCF will use the associated S-NSSAI and DNN associated with the ASP identifier stored in the Application Data to store the Background Data Transfer Reference ID in the UE's PDU Session policy control subscription information (see clause 6.2.1.3).
The PCF uses local policies to decide when the URSP rule related to the Background Data Transfer Policy is going to be sent to the UE. The PCF may, based on operator configuration, trigger the UE Configuration Update procedure when the AF request to apply the BDT policy to a future session is received, or the PCF may wait until receiving a notification from the AMF that the UE has entered the Tracking Area or Presence Area where the BDT policy applies, and/or the PCF may wait until the time window when the BDT policy applies is approaching.
The UE uses the Route Selection Validation Criteria to determine whether or not a PDU Session should be established. The Time Window and Location Criteria are not required to be checked again during the lifetime of the PDU Session. The UE's support of the Validation Criteria in a URSP rule is optional.
When the PDU Session is established, the PCF that serves the PDU Session will use the Background Data Transfer Reference ID in the UE's PDU Session policy control subscription information (see clause 6.2.1.3) to retrieve the corresponding BDT policy and the related information from the UDR and derives the PCC rule for the BDT according to this information.
The PCF may reject the establishment of an SM Policy Association, (described in clause 4.16.4 of TS 23.502), if the S-NSSAI and DNN corresponding to a BDT policy and the Validation Criteria are not fulfilled. And based on this feedback, SMF will reject the PDU Session establishment.
After successful PDU Session setup, PCF may trigger PDU Session release when Validation Criteria are no longer fulfilled.
The PCF may subscribe to analytics on "Network Performance" from NWDAF for the area of interest and time window of a BDT policy following the procedure and services described in TS 23.288 indicating a Reporting Threshold in the Analytics Reporting information. The value for the Reporting Threshold is set by the PCF based on operator configuration. When the NWDAF determines that the network performance goes below the threshold, the NWDAF notifies the PCF with the network performance analytics in the area of interest and time window. When the PCF gets the notification from the NWDAF, the PCF may try to re-negotiate the affected BDT policies with AFs that accepted BDT policy re-negotiation. To do this, the PCF retrieves all the BDT policies together with their additionally stored AF provided information (e.g. their corresponding desired time window) from the UDR, identifies the BDT policies that are not desirable anymore due to the degradation of the network performance and tries to calculate new candidate BDT policies for the ASP(s) to select from. If the PCF does not find any new candidate BDT policy or the related AF did not accept BDT policy re-negotiation, the previously negotiated BDT policy shall be kept and no interaction with the ASP shall occur. If the PCF finds one or more new candidate BDT policies, the PCF notifies the related ASP(s) on both the BDT policy that is not valid any longer and the candidate BDT policies via NEF.
The PCF invalidates the BDT policy stored in the UDR for the corresponding BDT reference ID while the BDT policy re-negotiation is ongoing. The PCF shall reject a PDU Session request corresponding to an invalid BDT policy.
When the AF receives the notification, the AF may select one of the BDT policies included in the candidate list, and then inform the PCF about the selected BDT policy. The PCF stores the newly selected BDT policy into the UDR for the corresponding Background Data Transfer Reference ID and removes the BDT policy that is no longer valid. The PCF is also updating the URSP rule corresponding to the BDT policy with the new Validation Criteria in the Policy Set Entry of all UEs. As a consequence, the PCF identifies the UEs for which the BDT policy was already provided and updates the URSP rule corresponding to the BDT policy using the procedure described in clause 4.16.12.2 of TS 23.502.
If the AF does not select one of the BDT policies included in the candidate list, the PCF removes the BDT policy stored in the UDR together with the corresponding Background Data Transfer Reference ID and all related information as well as the URSP rule corresponding to the BDT policy in the Policy Set Entry of all UEs. As a consequence, the PCF identifies the UEs for which the URSP rule corresponding to the BDT policy was already provided and removes the URSP rule corresponding to the BDT policy using the procedure described in clause 4.16.12.2 of TS 23.502.
Up

6.1.2.5  Policy Control Request Triggers relevant for AMFp. 43

The Policy Control Request Triggers relevant for AMF and 3GPP access type are listed in Table 6.1.2.5-1 and define the conditions when the AMF shall interact again with PCF after the AM Policy Association Establishment or UE Policy Association Establishment.
The PCF provides Policy Control Request Triggers to the AMF indicating a specific UE (i.e. SUPI or PEI) in the Policy Association establishment and modification procedures defined in the TS 23.502. The Policy Control Request Triggers are transferred from the old AMF to the new AMF when the AMF changes.
The Policy Control Request Triggers are not applicable any longer at termination of the AM Policy Association or termination of UE Policy Association.
Policy Control Request Trigger Description Condition for reporting
Location change (tracking area)The tracking area of the UE has changed.PCF (AM Policy Association, UE Policy Association)
Change of UE presence in Presence Reporting AreaThe UE is entering/leaving a Presence Reporting Area.PCF (AM Policy Association, UE Policy Association)
Service Area restriction changeThe subscribed service area restriction information has changed.PCF (AM Policy Association)
RFSP index changeThe subscribed RFSP index has changed.PCF (AM Policy Association)
Change of the Allowed NSSAIThe Allowed NSSAI has changed.PCF (AM Policy Association)
Generation of Target NSSAIThe Target NSSAI has been generated.PCF (AM Policy Association)
UE-AMBR changeThe subscribed UE-AMBR has changed.PCF (AM Policy Association)
UE-Slice-MBR changeThe subscribed UE-Slice-MBR has changed.PCF (AM Policy Association)
PLMN changeThe UE has moved to another operators' domain.PCF (UE Policy Association)
SMF selection managementUE request for an unsupported DNN or UE request for a DNN within the list of DNN candidates for replacement per S-NSSAI.PCF (AM Policy Association)
Connectivity state changesThe connectivity state of UE is changed.PCF (UE Policy Association)
NWDAF info changeThe NWDAF instance IDs used for the UE or associated Analytics IDs used for the UE and available in the AMF have changed.PCF (AM Policy Association)
If the Location change trigger are armed, the AMF shall activate the relevant procedure which reports any changes in location as explained in clause 5.6.11 of TS 23.501 by subscribing with the Npcf_AMPolicyAssociation service or Npcf_UEPolicyAssociation service. The reporting is requested to the level indicated by the trigger (i.e. Tracking Area). The AMF reports that the Location change trigger was met and the Tracking Area identifier.
If the Change of UE presence in Presence Reporting Area trigger is armed, i.e. the PCF subscribed to reporting change of UE presence in a Presence Reporting Area, including a list of PRA ids. In addition, for "UE-dedicated Presence Reporting Area" a short list of TAs and/or NG-RAN nodes and/or cells identifiers is included. Then, the AMF shall activate the relevant procedure which reports any Change of UE presence in Area of Interest as explained in clause 5.6.11 of TS 23.501. The reporting is requested for the specific condition when target UE moved into a specified PRA. The AMF reports the PRA Identifier(s) and indication(s) whether the UE is inside or outside the Presence Reporting Area(s) to the PCF.
The Service Area restriction change trigger and the RFSP index change trigger shall trigger the AMF to interact with the PCF for all changes in the Service Area restriction or RFSP index data received in AMF from UDM. The reporting includes that the trigger is met and the subscribed Service Area restriction or the subscribed RFSP index provided to AMF by UDM, as described in clause 6.1.2.1.
The Change of the Allowed NSSAI trigger shall trigger the AMF to interact with the PCF if the Allowed NSSAI has been changed. The reporting includes that the trigger is met and the new Allowed NSSAI. The PCF may update RFSP index and/or SMF selection management related policy information (described in clause 6.5) in the AMF based on the Allowed NSSAI.
The Generation of a Target NSSAI trigger shall trigger the AMF to interact with the PCF. The reporting includes that the trigger is met and the generated Target NSSAI. The PCF may generate RFSP index associated with the Target NSSAI.
The UE-AMBR change trigger shall trigger the AMF to interact with the PCF for all changes in the subscribed UE-AMBR data received in AMF from UDM. The reporting includes that the trigger is met and the subscribed UE-AMBR provided to AMF by UDM, as described in clause 6.1.2.1.
The Slice-UE-MBR change trigger shall trigger the AMF to interact with the PCF for all changes in the Subscribed UE-Slice-MBR for each subscribed S-NSSAI in the NSSAI with a Subscribed UE-Slice-MBR received at the AMF from UDM. The reporting includes that the trigger is met, as described in clause 6.1.2.1.
If the PLMN change trigger is armed, the AMF shall report it to the PCF to trigger the update of V2X service authorization parameters to the UE as defined in clause 6.2.2 of TS 23.287 and to trigger the update of ProSe authorization parameters to the UE as defined in clause 6.2.2 of TS 23.304. The reporting includes the event with the serving PLMN ID.
If the SMF selection management trigger is set, then the AMF shall contact the PCF when the AMF detects that the UE requested an unsupported DNN and the PCF indicated DNN replacement of unsupported DNNs in the Access and mobility related policy information (see clause 6.5). The PCF shall select a DNN and provide the selected DNN to the AMF.
If the SMF selection management trigger is set, then the AMF shall contact the PCF when the UE requested a DNN within the list of DNN candidates for replacement for the S-NSSAI indicated in the Access and mobility related policy information (see clause 6.5). The PCF shall select the DNN and provide the selected DNN to the AMF.
If the Connectivity state changes trigger is set, then the AMF shall notify the PCF when the UE connectivity state is changed e.g. from IDLE to CONNECTED. The AMF then reset the trigger.
The NWDAF info change trigger shall trigger the AMF to interact with the PCF when the list of NWDAF Instance IDs used for the UE or associated Analytics IDs used for the UE at the AMF are changed in the AMF.
Up

6.1.2.6  AF influence on Access and Mobility related policy control |R17|p. 44

6.1.2.6.0  Generalp. 44
The AF influence on Access and Mobility related policy control refers to the AF capability to request a service area coverage or the indication that high throughput is desired for a UE.
Two methods enable the AF to influence Access and Mobility related policy control:
  • The AF requests a service area coverage for the UE and/or indicates that high throughput is desired, knowing that certain conditions are met, i.e. the application traffic needs a change of service area coverage or high throughput, as defined in clause 6.1.2.6.1.
  • The AF provides the service area coverage and/or the indication that high throughput is desired for one or multiple UEs that may or may not already be registered or fulfil certain conditions related to application traffic. This is considered when the AM Policy Association is established or via a modification of an AM Policy Association, as defined in clause 6.1.2.6.2.
The content of this clause applies to non-roaming, i.e. to cases where the PCF, AF, AMF and SMF belong to the Serving PLMN or AF belongs to a third party with which the Serving PLMN has an agreement. AF influence on Access and Mobility related policy control does not apply in the case of Home Routed or Local breakout roaming cases.
Up
6.1.2.6.1  AF request Access and Mobility related Policy Control for a UEp. 44
The AF may subscribe to notifications when a PCF for the UE is registered in the BSF for a certain SUPI or GPSI.
The AF may contact, either directly or via NEF, the PCF for the UE to request notifications on the outcome of a service area coverage change (represented as a geographical area or a list of TA(s)) or the indication that high throughput is desired for UE traffic or both, for a SUPI or a GPSI. The request applies until the AF requests to terminate the request, or the AF request expires (according to relevant input provided by the AF), or the AM Policy Association is terminated. The AF may subscribe to notifications on the outcome of the service area coverage change to the PCF, according to the events described in clause 6.1.3.18. At the time the AF request expires, the PCF removes the context provided by the AF and then checks if the Access and Mobility related policy information needs to be updated at the AMF.
When the AF contacts the NEF then the following mappings are performed by the NEF:
  1. The geographical area (e.g. a civic address or shapes) is mapped into a list of TAs determined by local configuration.
  2. The GPSI, if provided, is mapped to a SUPI according to the subscription information received from UDM.
The PCF takes the list of TAs as input for policy decisions, considering the list of TAs provided by the AF as allowed TAIs for the UE when calculating the service area restrictions, then checking operator policies to determine whether the service area restrictions need to be updated.
The PCF reports the outcome of a service area coverage change, including the list of allowed TAIs (that is mapped to a geographical area if the requests goes via NEF) and any changes to the AF, according to the events described in clause 6.1.3.18.
The PCF checks if the RFSP value index for a UE needs to be changed, as described in clause 6.1.2.1, using the indication that high throughput is desired. The PCF reports to the AF that the request was executed, but without reporting anything related to actually applied RFSP or throughput changes.
Up
6.1.2.6.2  AF request to influence on Access and Mobility related Policy Controlp. 45
The PCF for the UE may subscribe at UDR to notifications on change of "Application Data" and "AM influence information", e.g. when the AM Policy Association is established.
The AF may request notifications on outcome of service area coverage change, represented by a geographical area, may indicate that high throughput is desired for one or multiple target UEs, which may be associated to an Application Identifier(s) or to a (DNN,S-NSSAI) combination (if no Application Identifier(s) or (DNN,S-NSSAI) combination is provided, the request applies independently of the application traffic), the AF transaction identifier (allowing the AF to update or remove the AM influence data), a policy expiration time, and the Notification Correlation Id, then the NEF performs the following mappings where needed:
  1. The geographical area(s) are mapped into a list of TAs determined by local configuration.
  2. The GPSI, if provided, is mapped to a SUPI according to the subscription information received from UDM.
  3. External Group Identifier(s) are mapped to Internal Group Identifier(s).
The NEF stores the AF request in the UDR as Data Set "Application Data" and Data Subset "AM influence information".
The PCF calculates the service area restrictions as defined in clause 6.1.2.6.1, including the notification to the AF on the service area coverage as described in clause 6.1.3.18, in this case it is implicit subscription, to the AF using the Notification Correlation Id.
The PCF calculates the RFSP index value as defined in clause 6.1.2.6.1.
When the expiration time of the policy is reached or when the PCF receives a notification from the UDR that the policy has been deleted, the PCF re-evaluates the policies without consideration of the AM influence data of the expired policy and applies policies as defined in clause 6.1.2.1.
Up

Up   Top   ToC