Content for  TS 23.503  Word version:  19.1.0

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, the slice replacement management 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 may determine to modify the RFSP Index at any time 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. If the modified RFSP index value indicates that EPC/E-UTRAN access is prioritized over the 5G access for the UE, the PCF may, based on operator policy, include a RFSP Index in Use Validity Time of the RFSP Index. 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 modify the RFSP index based on the Allowed NSSAI, Target NSSAI, Partially Allowed NSSAI, S-NSSAI(s) rejected partially in the RA, rejected S-NSSAI(s) for the RA, Alternative S-NSSAI(s) mapped to some Replaced S-NSSAI(s) or Pending NSSAI as defined in clause 5.15 of TS 23.501. 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. 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 based on the Spending Limits information from CHF as defined in clause 6.1.1.4. 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 management of the slice replacement enables the PCF to instruct the AMF to contact the PCF to provide the Alternative S-NSSAI for each S-NSSAI that requires slice replacement as specified in clause 5.15.19 of TS 23.501. The AMF reports S-NSSAI(s) of the serving network that requires slice replacement. The conditions for reporting are defined in clause 6.1.2.5. The PCF returns the Alternative S-NSSAI for the S-NSSAI of the serving network received from the AMF. The AMF receives the Alternative S-NSSAI for each S-NSSAI that requires slice replacement for which it has provided to the PCF. If the AMF has indicated support of the Network Slice Replacement for the UE and the PCF detects the change in the availability of the S-NSSAI in the Allowed NSSAI (i.e. the S-NSSAI becomes unavailable or available) based on a PCF local decision (e.g. based on OAM or NWDAF analytics output), the PCF notifies the S-NSSAI availability information (see clause 6.5) based on the implicit subscription from the AMF. The AMF may also interact with the PCF to determine the Alternative S-NSSAI for S-NSSAI to be replaced based on Policy Control Request Triggers as defined in clause 6.1.2.5. 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. Optionally, when 5G access stratum time distribution is enabled, the PCF for UE instructs the AMF about the clock quality reporting control information (clock quality detail level, clock quality acceptance criteria). 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.

In the non-roaming scenario, the establishment of the AM Policy Association is determined as follows. First, the AMF checks the AM Policy Association indicator received from UDM and establishes the AM Policy Association if its value is "enabled" and do not establish the AM Policy Association if its value is "disabled". If no AM Policy Association indicator is received from the UDM then the AMF determines whether to establish the AM Policy Association or not according to local configuration. In the roaming scenario, only the AMF local configuration is considered for the determination of the establishment of the AM Policy Association. The AM Policy Association indicator for a SUPI is part of Access and Mobility Subscription data in UDM as described in clause 5.2.3.3.1 of TS 23.502 and can be set by the operator to "enabled" or "disabled".

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 or a PIN:
   • can be associated to an established PDU Session; or
   • can be offloaded to non-3GPP access outside a PDU Session; or
   • can be routed via a ProSe Layer-3 UE-to-Network Relay outside a PDU session; or
   • multi-path communication via 5G ProSe Layer-3 UE-to-Network Relay outside of a PDU session and over Uu reference point or either path; 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/PIN with SSC modes.
   2. Network Slice Selection Policy (NSSP): This is used by the UE to associate the matching application/PIN with S-NSSAI.
   3. DNN Selection Policy: DNN Selection Policy: This is used by the UE to associate the matching application/PIN with DNN.
   4. PDU Session Type Policy: PDU Session Type Policy: This is used by the UE to associate the matching application/PIN with a PDU Session Type.
   5. Non-Seamless Offload Policy: This is used by the UE to determine that the matching application/ Connectivity Group 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/PIN, 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.
   10. ProSe Multi-path Preference: It indicates to UE whether a matching application is preferred to be routed via multipath (i.e. via a PDU Session over Uu reference point and via ProSe Layer-3 UE-to-Network Relay outside of a PDU Session).
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 features as defined in clauses 5.1 of TS 23.304.
5. Ranging/Sidelink Positioning Policy (RSLPP): This policy provides configuration parameters to the UE for Ranging/Sidelink Positioning control. Ranging/Sidelink Positioning Policies are defined in clause 5.1 of TS 23.586.
6. A2X Policy (A2XP): This policy provides configuration parameters to the UE for A2X communication over PC5 reference point or over Uu reference point or both. A2X Policies are defined in clauses 6.2.1.2.1 and 6.2.1.3.1 of TS 23.256.

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 methods of configuring A2XP 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 4.2.1.2.2 of TS 23.256. The methods of configuring RSLPP 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.586. The ANDSP policy, V2X Policy, ProSe Policy (ProSeP), A2X Policy (A2XP) and Ranging/Sidelink Positioning Policy (RSLPP) are not applicable to any of 5G-RG, FN-RG and AUN3 devices. The ProSe Layer-3 UE-to-Network Relay Offload Policy, PDU Session Pair ID, RSN and ProSe Multi-path Preference components of the Route Selection descriptor are not applicable to 5G-RG, FN-RG and AUN3 devices. The PCF selects the UE policy information applicable for each UE based on local configuration, operator policies taking into consideration the information defined in clause 6.2.1.2 and the PCF determines the URSP Rules for the UE using input from NWDAF as one of the inputs. 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. In the case of a roaming UE, the V-PCF or UDR may provide the application guidance on VPLMN specific URSP determination to the H-PCF as defined in clause 4.15.6.10 of TS 23.502 and clause 6.1.2.2.4. The H-PCF is required to generate VPLMN specific URSP rule(s) and provide the URSP rules to the UE. This can be triggered by the UE's registration in the VPLMN or it can happen before UE roams into the VPLMN. The URSP Rules received by UE for a VPLMN are only applicable when the UE is registered in that VPLMN or its equivalent VPLMNs. If a UE does not indicate support for VPLMN specific URSP rules, the H-PCF may still trigger an update of the UE's URSP Rules, which may be based on the application guidance from the VPLMN or HPLMN, upon receiving a notification that the UE has registered in 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. The PCF may use Spending Limits information from the CHF to decide whether to install, update or delete URSP rules, as defined in clause 6.1.1.4. The definition of UE policy control for 5G-RG, FN-RG and AUN3 devices is specified in TS 23.316.

The UE policy control enables the PCF to provide UE access selection related policy information, PDU Session related policy information, V2X Policy information, ProSe Policy information, A2X Policy information and Ranging/Sidelink Positioning 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 A2X Policy (A2XP) or Ranging/Sidelink Positioning Policy (RSLPP) 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 A2XP to the UE, the PCF provides the list of A2XP in the order of precedence and without splitting a A2XP across Policy Sections;
• when the PCF delivers RSLPP to the UE, the PCF provides the list of RSLPP in the order of precedence and without splitting a RSLPP 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 UE Policy Container including one or more of the following information:

• 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.
• The UE may also provide the OSId.
• The UE may indicate whether it supports the URSP Provisioning when attached in EPS. The PCF for the UE stores it at the UDR, see clause 6.2.1.3.
• UE may indicate its capability of reporting URSP rule enforcement to network to the PCF. If it is received, the PCF shall take it into account as described in clause 6.6.2.4.
• The UE may indicate whether it supports VPLMN specific URSP rules.

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 UE 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 (H-)PCF, the (H-)PCF stores them in the (H-)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. When the PCF determines to provision VPLMN specific URSP rules to the UE (as described in clause 6.1.2.2.4) the PCF provides the URSP rules to be applied in VPLMN in specific Policy Section(s) identified by corresponding PSIs. Such Policy Section(s) do not include any non-VPLMN specific URSP rules. The PCF also provides to the UE the tuple (PLMN ID, list of PSIs of the Policy Sections containing URSP rules to be applied at specific VPLMN). The PCF may indicate the UE to add a new tuple(s), to update a stored tuple(s) or to remove a stored tuple(s), then the UE stores, updates, or removes the tuples as requested by the PCF (details are specified in TS 24.501). In roaming scenarios, the H-PCF provides this information via V-PCF. The PCF may provide, at any time, the full list of tuples (VPLMN ID(s), list of PSIs associated with the VPLMN ID) to the UE, and then the UE replaces any stored list of tuples with the new list of tuples provided by the PCF. After Registration procedure, the UE may perform UE triggered V2X Policy Provisioning procedure to request V2XP from the PCF as specified in clause 6.2.4 of TS 23.287. After Registration procedure, the UE may perform UE triggered 5G ProSe Policy Provisioning procedure to request ProSeP from the PCF as specified in clause 6.2.4 of TS 23.304. After Registration procedure, the UE may perform UE triggered A2X Policy Provisioning procedure to request A2XP from the PCF as specified in clause 6.3.2.3 of TS 23.256. After Registration procedure, the UE may perform UE triggered Ranging/Sidelink Positioning Policy Provisioning procedure to request RSLPP from the PCF as specified in clause 6.2.4 of TS 23.586.

When a UE attaches initially in EPS and PDN connectivity request message is sent together with initial attach request, or the UE requested PDN connectivity procedure is performed for the first PDN connection or when the UE handovers from 5GS to EPS, PCF for the UE may need to update the URSP rules in the UE:

• During Initial attach procedure in EPS due to for example:
  • New application guidance on URSP determination request applicable to the UE was sent by an AF (see clause 4.15.6.10 of TS 23.502) while the UE is deregistered and prior to the EPC attach procedure, so the corresponding URSP rules were not delivered yet to the UE.
  • Operator policies configured with time, location or any other condition are met when the UE attaches to EPC, implying new or updated URSP rules apply under those conditions.
  • Operator policies for determining URSP rules were updated by the operator while the UE is deregistered and prior to the EPC attach procedure, so the corresponding URSP rules were not delivered yet to the UE.
• At any time a URSP rule is changed while the UE is registered in EPC (coming from EPS initial attachment or after handover from 5GS) due to for example:
  • New application guidance on URSP determination request applicable to the UE is sent by an AF (see clause 4.15.6.10 of TS 23.502).
  • Due to time, location change or other network condition the PCF for the UE determines that an operator policy configured for the operator for URSP determination applies in the new network conditions, implying new or updated URSP rules apply to the UE.

How the UE associates application traffic to PDN Connections is described in clause 4.4.2 of TS 24.526. When the UE is attached to EPS, only the non-VPLMN specific URSP Rules are used to associate applications to PDN Connections at the UE.

The H-PCF may provision VPLMN specific URSP Rules to UE for the purpose of routing traffic to the VPLMN. The H-PCF provides VPLMN specific URSP Rules. The Network Slice Selection Policies of the VPLMN specific URSP Rules contain values that are associated with the HPLMN. The DNN Selection Policies of the VPLMN specific URSP Rules contain DNN values from the list of subscribed DNNs that have LBO Roaming set to allowed in the UE Policy Context Subscription Data in the UDR. When Time and Location criteria are included in the RSD(s), the Time and Location criteria contain values that are based on agreements with the VPLMN or service parameters that were received from the VPLMN. The H-PCF may use application guidance on URSP determination, received from the V-PCF or retrieved from UDR at the HPLMN, as input to generate new or update existing VPLMN specific URSP Rules, as well as other input data as described in clause 6.2.1.1. The list of parameters provided for application guidance on URSP Rule determination is defined in clause 4.15.6.10 of TS 23.502 and the procedures are specified in clause 4.15.6.7 of TS 23.502. The AF may provide application guidance on URSP Rule determination to the VPLMN or to the HPLMN. When the AF provides application guidance on URSP Rule determination to the VPLMN, it will target "PLMN ID(s) of inbound roamers", the NEF in the VPLMN authorizes requests based on local configuration using e.g. the AF identifier before storing them in UDR, as defined in in clause 4.15.6.7 of TS 23.502. The NEF in the VPLMN rejects any request for a GPSI or an External-Group-ID of a different PLMN. The UDR in the VPLMN notifies the V-PCF(s) that has subscribed to the reception of application guidance on URSP determination. When the AF provides application guidance on URSP Rule determination to the HPLMN, it will target either a GPSI or an External-Group-ID or "any UE" of the HPLMN. The NEF in the HPLMN, may, based on the HPLMN operator local policy, authorize any request for a GPSI or an External-Group-ID and maps it into a SUPI or an Internal-Group-ID via UDM, before storing them in UDR as Application Data. The UDR notifies the H-PCF(s) that has subscribed to the reception of application guidance on URSP determination. The Application guidance on traffic routing may contain the VPLMN ID(s) where the Service Parameters apply. When the UE Policy Association is established or the V-PCF receives updates on application guidance on URSP determination with target PLMN ID(s) containing the HPLMN ID of a SUPI that has a UE Policy Association established, the V-PCF checks whether application guidance on URSP determination exists and applies for HPLMN ID of the SUPI. If yes, then the V-PCF:

• maps the S-NSSAI of the VPLMN into the S-NSSAI of the HPLMN, using the Configured NSSAI for the Serving PLMN and mapping of each S-NSSAI of the Configured NSSAI to corresponding HPLMN S-NSSAI values provided by the AMF and stored in PCF. Then the V-PCF sends the mapped application guidance on URSP determination including the HPLMN S-NSSAI values to the H-PCF;
• subscribes to the result of the delivery of UE Policies if it was requested by the AF to the H-PCF, using the event reporting on "Notification on outcome of UE Policies delivery" described in clause 6.1.3.18; and
• checks whether the requested application guidance are included in HPLMN subscription by checking the LBO Information (i.e. DNN(s) and/or S-NSSAI(s) that are allowed for LBO Session in VPLMN, which is part of SMF Selection Data) if the V-PCF received the LBO Information from the AMF. If LBO Information is not available at V-PCF in VPLMN or if the V-PCF needs to be made aware of any changes in the LBO Information, the V-PCF may send the PCRT for reporting the LBO Information.

The H-PCF generates new or updated URSP Rules using the application guidance on URSP Rule determination. The VPLMN ID included in the Service Parameters of the application guidance from the AF to indicates that this URSP Rule applies when the UE is registered in the VPLMN. The H-PCF provides RSD values in the URSP Rules that are within the subscribed values defined in the S-NSSAI subscription information defined in Table 6.2.1.3-1. The H-PCF provides the list of PSIs applicable per VPLMN ID(s) to the UE. The VPLMN ID(s) corresponds to the VPLMN ID(s) included in the Service Parameters provided by the AF in application guidance. The VPLMN ID provided by the H-PCF may contain one or more specific values for the MCC and MNC and/or one or more wildcarded values for MCC and/or MNC. The H-PCF should set the precedence in the URSP Rules to ensure that the UE checks the VPLMN ID(s) that contain one or more specific values for the MCC and MNC before any URSP Rule related the VPLMN ID(s) that contain wildcarded values for MCC and/or MNC. The H-PCF should also set the precedence in the URSP Rules to ensure that the UE checks any URSP Rule related to VPLMN ID(s) that contain wildcarded values for MCC and/or MNC before any non-VPLMN specific URSP Rules. How the UE associates applications to PDU Sessions based on URSP Rules follows the same procedure as described in clause 6.6.2.3.

In the non-roaming scenario, the establishment of the UE Policy Association is determined as follows. First, the AMF checks the UE Policy Association indicator received from UDM and establishes the UE Policy Association if its value is "enabled" and do not establish the UE Policy Association if its value is "disabled". If no UE Policy Association indicator is received from the UDM then the AMF establishes the UE Policy Association when the UE Policy Container is received from the UE. If no UE Policy Association indicator is received from the UDM and no UE Policy Container is received from the UE, then the AMF determines whether to establish the UE Policy Association or not as indicated by the local configuration. In the roaming scenario, the AMF local configuration is considered first for the determination of the establishment of the UE Policy Association then the remaining parameters described above are applied. The UE Policy Association indicator for a SUPI is part of Access and Mobility Subscription data in UDM as described in clause 5.2.3.3.1 of TS 23.502 and can be set by the operator to "enabled" or "disabled".

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 PFD(s) into the UDR setting "AF" as the source NF type (which is defined in clause 5.2.12.2.1 of TS 23.502). 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. The NEF (PFDF) may subscribe to "PFD Determination" analytics from the NWDAF for an application identifier to assist determination of PFDs for known application identifiers as specified in TS 23.288. Based on the "PFD Determination" analytics received from the NWDAF, the NEF (PFDF) may determine to create PFD(s) for that application identifier, and then stores these PFD(s) in the UDR setting "NWDAF" as the source NF type (which is defined in clause 5.2.12.2.1 of TS 23.502). The NEF (PFDF) may also determine to modify or delete PFD(s) for that application identifier. The NEF(PFDF) shall only modify or delete PFD(s) if they contain "NWDAF" as the source NF type (i.e. they have been previously created based on "PFD Determination" analytics from the NWDAF) unless it has been agreed with the service provider owning the AF that changes to the PFDs provided by the AF are also permitted. The NEF (PFDF) then interacts with the UDR to modify or delete the corresponding PFD(s). If the NEF (PFDF) unsubscribes from "PFD Determination" analytics, the NEF (PFDF) should identify all PFDs for that application identifier which contain "NWDAF" as the source NF type (i.e. they have been previously created based on "PFD Determination" analytics from the NWDAF) and interact with the UDR to delete these PFD(s). The distribution of PFD updates triggered by NWDAF analytics shall be performed in the same way as PFD updates triggered by ASP requests, i.e. using the "push" and "pull" methods described above.

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).