6.1 Overall description

23.5033GPPPolicy and charging control framework for the 5G System (5GS)Release 18Stage 2TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

6.1.1 General

6.1.1.1 PCF Discovery and Selection

The procedures for PCF Discovery and Selection by the AMF and by the SMF are described in TS 23.501 [2].

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.

6.1.1.2 Binding an AF request targeting an UE address to the relevant PCF

6.1.1.2.1 General

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 [2]), 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 [2]). 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 [2]).

– 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 [2].

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.

6.1.1.2.2 The Binding Support Function (BSF)

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 [2]).

– 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 [2]).

NOTE 1: Only NF instance or NF set Level of Binding indication are supported at the BSF.

– The PCF registers, updates and removes the stored information in the BSF using the Nbsf management service operations defined in TS 23.502 [3]:

– 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, S-NSSAI and DNN combination in the non-roaming or home-routed scenario.

NOTE 2: This applies to usage monitoring.

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

NOTE 3: This applies to network slice related policy control.

– 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 [3]. 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.

NOTE 4: The assumption is that for DNN, S-NSSAI combinations where usage monitoring be applied, the same BSF instance or the same BSF SET is selected for all UE PDU Sessions to the same DNN, S-NNSAI.

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

NOTE 5: It is up to stage3 to ensure an unambiguous error proof way for the BSF to differentiate between PCF for a PDU Session and PCF for a UE. This might or might not require providing the BSF additional parameter(s) when a PCF registers itself with the BSF and/or when a consumer attempts to discover a PCF via discovery or subscription.

– 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 [2]) 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 [3].

– 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 [32], 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 [2] 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 [2]). 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.

NOTE 6: Collocation allows combined implementation.

6.1.1.2a Binding an NF request targeting a UE to the relevant PCF for a UE

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 [2].

NOTE: The above is required e.g. for dynamic control of access and mobility related policy control functionality or for reporting events for a UE to a consumer such as 5G DDNMF.

6.1.1.3 Policy decisions based on network analytics

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 [24]. 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 [24].

The PCF performs discovery and selection of NWDAF and DCCF as defined in TS 23.501 [2] and subscribes/unsubscribes to Analytics information as defined in TS 23.288 [24]. 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", "Session Management Congestion Control Experience", "DN Performance" 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 [24].

– 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), one or more value(s) of each RSC (e.g. S-NSSAI, DNN, PDU Session type, SSC Mode, Access Type), one or more combination(s) of RSCs 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 [24].

– 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 [24].

– 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 [24].

The NWDAF services to retrieve "Abnormal behaviour" analytics are described in clause 6.7.5 of TS 23.288 [24].

– 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 [24].

The NWDAF services to retrieve "UE Mobility" analytics are described in clause 6.7.2 of TS 23.288 [24].

– 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 [24].

– 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 [24].

– 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 [24].

– 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 [24].

Editor’s note: Whether the PCF needs to subscribe to any new AnalyticsID for the purpose of negotiation of the planned data transfer with QoS request is FFS.

– The PCF may subscribe to notifications of network analytics related to "Session Management Congestion Control Experience" using the Nnwdaf_AnalyticsSubscription_Subscribe service operation including the Analytics ID "Session Management Congestion Control Experience", the Target of Analytics Reporting containing "SUPI" and the Analytics Filter may include DNN and/or S-NSSAI. The PCF is notified on the Session Management Congestion Control Experience statistics including the DNN and/or S-NSSAI.

The NWDAF services to retrieve "Session Management Congestion Control Experience" analytics are described in clause 6.12 of TS 23.288 [24].

– The PCF may subscribe to notifications of network analytics related to "DN Performance" using the Nnwdaf_AnalyticsSubscription_Subscribe service operation including the Analytics ID "DN Performance", the Target of Analytics Reporting containing "SUPI", "Internal Group Id" or "any UE", and the Analytics Filter may include Application ID(s). The PCF is notified on the DN Performance statistics or predictions including Application ID(s). In addition, the confidence of the prediction may be provided.

The NWDAF services to retrieve "DN Performance" analytics are described in clause 6.14 of TS 23.288 [24].

Editor’s note: How to PCF consume analytic of Redundant Transmission Experience from NWDAF is FFS.

Editor’s note: It is FFS how to extend Service Experience Analytics to request analytics for the different combinations of RSC values and which RSC combinations are applicable.

NOTE: Care needs to be taken with regards to signalling and processing load caused when requesting analytics targeting "Any UE". A PCF preferably limits the analytics requests to a smaller UE set to reduce the load.

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;

– UE Policy Association establishment or modification;

– 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 UE 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, "Session Management Congestion Control Experience", "DN Performance", "User Data Congestion" 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).

Editor’s note: Which AnalyticsID the PCF subscribes to for the purpose to determine the recommended time window for the planned data transfer with QoS request is FFS.

– Based on the notification of "Load Level Information" for network slice(s), the PCF may give priority to consider the one with lowest load for an application, and the PCF may update URSP on Network Slice Selection Policy.

– Based on the "UE communication" statistics or predictions, the PCF may consider the DNN in Traffic characterization and associated Traffic Volume, Spatial validity and inactivity time, and the PCF may update URSP on DNN Selection Policy for associated UEs.

– Based on the "Dispersion Analytics" statistics or predictions for Data Volume Dispersion in network slice(s), the PCF may calculate the average data rate in the network slice, and the PCF may update URSP on Network Slice Selection Policy for the associated UEs.

– Based on the "Session Management Congestion Control Experience" statistics or predictions for PDU Session(s) associated with corresponding S-NSSAI(s) or DNN for a UE, PCF may give priority to consider the S-NSSAI or the DNN that provides the lowest experience level of Session Management Congestion Control, and then the PCF may update URSP on Network Slice Selection Policy and/or DNN Selection Policy for the UE.

– Based on the "Network Performance" statistics or predictions on gNB status information, gNB resource usage, communication performance and mobility performance in an Area of Interest, the PCF may consider to offload the traffic to non-3GPP access for the number of UEs that are located in that Area of Interest, and the PCF may update URSP on Non-Seamless Offload Policy for associated UEs.

– Based on the "User Data Congestion" statistics or predictions including the list of applications contributing the most to the traffic, the PCF may consider to offload the traffic to non-3GPP access for those applications, and the PCF may update URSP on Non-Seamless Offload Policy for those applications.

– Based on the "DN Performance" statistics or predictions for user plane performance for an application, the PCF may consider the DNN with higher performance, and the PCF may update URSP on DNN Selection Policy for the application.

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.

– UE Policy Association establishment/modification: Based on the Load level information", "Service Experience", "Network Performance", "Abnormal behaviour", "UE Mobility", "UE Communication", "User Data Congestion", "Data Dispersion", "Session Management Congestion Control Experience", "DN Performance", "User Data Congestion" and "WLAN performance" statistics or predictions, the PCF uses analytics results from NWDAF to select proper values of URSP rules provided to UEs.

– Based on the notification of Spatial validity for application(s) in use, provided by "UE Communication" analytics, the PCF may request the "WLAN performance" analytics for the Area of Interest derived from the Spatial validity of "UE Communication" analytics, and the PCF may update URSP on Non-Seamless Offload Policy for associated UEs.

6.1.2 Non-session management related policy control

6.1.2.1 Access and mobility related policy control

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 [27].

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 [2].

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.

NOTE 1: The enforcement of the service area restrictions is performed by the UE, when the UE is in CM-IDLE state or in CM-CONNECTED state when in RRC Inactive, and in the RAN/AMF when the UE is in CM-CONNECTED state.

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 [2]. 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. If the PCF determines to modify the RFSP index value to indicate a change in priority from 5G access to 4GEPC/E-UTRAN access for the UE, the PCF may, based on operator policy, includes a RFSP Index in Use Validity Time of the RFSP Index. The subscribed RFSP Index may be further adjusted by the PCF based on operator policies at any time.

Editor’s note: Whether PCF needs to be aware the modified RFSP index indicates a change of priority from 5GC to EPC is FFS.

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.

NOTE 2: The enforcement of the RFSP Index is performed in the RAN.

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 [2].

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 [2]. 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 [2].

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.

NOTE 3: The PCF for the UE may subscribe to the notifications of newly registered PCF for the PDU Session and subscribe to the "start/stop of application traffic detection" events for multiple applications with different application identifiers. When PCF receives the notifications for multiple applications, the PCF for the UE can determine which access and mobility related policy information to apply based on local configuration and operator policy.

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

6.1.2.2 UE policy control

6.1.2.2.1 General

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:

2a) SSC Mode Selection Policy (SSCMSP): This is used by the UE to associate the matching application with SSC modes.

2b) Network Slice Selection Policy (NSSP): This is used by the UE to associate the matching application with S-NSSAI.

2c) DNN Selection Policy: This is used by the UE to associate the matching application with DNN.

2d) PDU Session Type Policy: This is used by the UE to associate the matching application with a PDU Session Type.

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

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

NOTE 1: The Access Type of 3GPP also includes the use of ProSe UE-to-Network Relay access as defined in TS 23.304 [34].

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

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

2i) 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 [28].

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 [34].

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 [28].

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 [34].

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

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 [3]. 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 [3]. 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.

NOTE 2: For backward compatibility the PCF may subscribe the "Connectivity state changes (IDLE or CONNECTED)" event in Rel-15 AMF as defined in clause 5.2.2.3 of TS 23.502 [3].

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,

NOTE 3: It is assumed that the S-NSSAI(s) in the UE Local Configurations are operator-provided S-NSSAI(s). The provision of the S-NSSAI(s) is not specified.

NOTE 4: The application layer is not allowed to set the S-NSSAI when the UE establishes a PDU Session based on the UE Local Configurations.

NOTE 5: Any missing information in the UE Local Configurations needed to build the PDU Session Establishment request can be the appropriate corresponding component from the URSP rule with the "match all" Traffic descriptor.

– 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 in TS 23.501 [2], on the UE shall be used to select which IPv6 prefix to route the traffic of the application.

NOTE 5: For the case that an application cannot be associated to any PDU Session, the UE can inform the application that association of the application to PDU Session fails.

The PCF may subscribe to analytics on "WLAN performance" from NWDAF following the procedures and services described in TS 23.288 [24]. When the PCF gets a notification from the NWDAF, the PCF may try to update WLANSP rules.

6.1.2.2.2 Distribution of the policies to UE

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 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 [3].

NOTE 1: The PCF can install a PCC Rule and activate start and stop of application detection in the SMF. When the same PCF is selected for SM policy association control and UE policy association control, the reporting of start and stop of an application can trigger the installation or update of a URSP rule in the UE to send the application traffic to the PDU Session as defined in the URSP rule.

NOTE 2: The PCF can subscribe to the UDR on service specific information change, which will be taken into consideration by the PCF to determine the updated V2XP and ProSeP as defined in clause 4.15.6.7 of TS 23.502 [3].

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.

NOTE 3: The size limit to allow the policy information to be delivered using NAS transport is specified in TS 29.507 [13]. The size limit is configured in 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.

NOTE 4: The Policy Section list can be different per user. One PSI and its corresponding content can be the same for one or more users.

NOTE 5: The PCF may, for example, assign the URSP as one whole Policy Section, or it may subdivide the information in the URSP into multiple Policy Sections by assigning one or several URSP rules to each Policy Section.

The PLMN ID is provided to the UE together with UE 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 [3].

NOTE 6: The AMF does not need to understand the content of the UE policy, rather send them to the UE for storage.

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 [22]):

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

NOTE 7: For aspects related to URSP rules for an SNPN-enabled UE, please refer to clause 6.6.2.2.2.

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 [3], 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.

NOTE 8: In the roaming scenario, during AMF relocation with V-PCF change, if the H-PCF does not provide the Indication of UE support for ANDSP, then the behaviour of V-PCF to determine whether to provide ANDSP rules to the UE is implementation specific.

– 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 [28].

– 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 [34]. 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 [34].

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

NOTE 9: The PSI list and content stored/configured for a PLMN ID can be structured according to e.g. location areas (e.g. TAs, PRAs). The V-PCF can then provide PSIs and its content only if they correspond to the current UE location.

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

NOTE 10: If the PCF does not take into account the received PEI and/or OSId then the PCF can send URSP rules containing application traffic descriptors associated to multiple operating systems.

6.1.2.3 Management of packet flow descriptions

6.1.2.3.1 PFD management

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 [2] if the removed/modified PFD in SMF/UPF results in that the stop of the application instance is not being able to be detected.

NOTE 1: PFD management is optionally supported in the NEF and the SMF.

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.

NOTE 2: The Allowed Delay is an optional parameter. If the Allowed Delay is included, it indicates that the requested PFD(s) should be deployed within the time interval indicated by the Allowed Delay.

The NEF (PFDF) may retrieve analytics of "PFD Determination" from NWDAF for the application identifier(s) as specified in TS 23.288 [24] to determine one or more new PFD(s), and store the PFD(s) in 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:

a) 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);

b) Selective push of an ASP change in the PFD set (i.e. ASP changes the PFD set while operator configuration defines when to push);

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

NOTE 3: It is assumed that all SMF(s) and PFD (s) in an operator network are configured with the same default caching time value to be applied for all application identifiers.

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.

NOTE 4: The configuration of a caching time value per application identifier in NEF (PFDF) is based on the SLA between the operator and the ASP.

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.

NOTE 5: SMF should assure not to overload N4 signalling while managing PFD(s) to the UPF, e.g. forwarding the PFD(s) to the right UPF where the PFD(s) is enforced.

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 [2]. 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.

6.1.2.3.2 Packet Flow Description

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 [17]. 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).

NOTE 1: Based on the agreement between AF and mobile operator, the PFD can be designed to convey proprietary extension for proprietary application traffic detection mechanisms.

NOTE 2: How the PFD(s) are used in service flow detection is specified in clause 6.2.2.2.

6.1.2.4 Negotiation for future background data transfer

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

NOTE 1: The NEF may contact any PCF in the operator network.

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 [3].

NOTE 2: A 3rd party application server is typically not able to provide any specific network area information and if so, the AF request is for the whole operator network.

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 [24]. 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.

NOTE 3: The maximum aggregated bitrate (optionally provided in a BDT policy) is not enforced in the network. The operator may apply offline CDRs processing (e.g. combining the accounted volume of the involved UEs for the time window) to determine whether the maximum aggregated bitrate for the set of UEs was exceeded by the ASP and charge the excess traffic differently.

NOTE 4: It is assumed that the 3rd party application server is configured to understand the reference to a charging rate based on the agreement with the operator.

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.

NOTE 5: If a non-supporting UE receives Validation Criteria, it ignores the URSP rule.

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.

NOTE 6: The AF will typically contact the PCF for the individual UEs to request sponsored connectivity for the BDT.

NOTE 7: A transfer policy is only valid until the end of its time window. The removal of outdated transfer policies from the UDR is up to implementation.

The PCF may reject the establishment of an SM Policy Association, (described in clause 4.16.4 of TS 23.502 [3]), 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 [24] 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 [3].

NOTE 8: A PCF can subscribe to notifications on changes in BDT policy in UDR.

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 [3].

NOTE 9: The PCF can also remove the no longer valid BDT policy after an operator configurable time for the case that the AF does not respond.

6.1.2.5 Policy Control Request Triggers relevant for AMF

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 [3]. 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.

Table 6.1.2.5-1: Policy Control Request Triggers relevant for AMF and 3GPP access type

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 Area	The UE is entering/leaving a Presence Reporting Area.	PCF (AM Policy Association, UE Policy Association)
Service Area restriction change	The subscribed service area restriction information has changed.	PCF (AM Policy Association)
RFSP index change	The subscribed RFSP index has changed.	PCF (AM Policy Association)
Change of the Allowed NSSAI	The Allowed NSSAI has changed.	PCF (AM Policy Association)
Generation of Target NSSAI	The Target NSSAI has been generated.	PCF (AM Policy Association)
UE-AMBR change	The subscribed UE-AMBR has changed.	PCF (AM Policy Association)
UE-Slice-MBR change	The subscribed UE-Slice-MBR has changed.	PCF (AM Policy Association)
PLMN change	The UE has moved to another operators’ domain.	PCF (UE Policy Association)
SMF selection management	UE 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 changes	The connectivity state of UE is changed.	PCF (UE Policy Association)
NWDAF info change	The 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)
Satellite backhaul category change	Satellite backhaul category changes between any satellite categories.	PCF (AM Policy Association)

NOTE: In the following description of the Policy Control Request Triggers relevant for AMF and 3GPP access type, the term trigger is used instead of Policy Control Request Trigger where appropriate.

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 [2] 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 [2]. 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 [28] and to trigger the update of ProSe authorization parameters to the UE as defined in clause 6.2.2 of TS 23.304 [34]. 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.

If the Satellite backhaul category change trigger is armed, the AMF shall report the satellite backhaul category to the PCF. The PCF may take this into account to update UE Policy as defined in clause 6.1.2.2.

6.1.2.6 AF influence on Access and Mobility related policy control

6.1.2.6.0 General

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.

6.1.2.6.1 AF request Access and Mobility related Policy Control for a UE

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.

NOTE: The assumption is that the AF also removes the context at the time the AF request expires.

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.

6.1.2.6.2 AF request to influence on Access and Mobility related Policy Control

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.

6.1.2.7 Negotiation for planned data transfer with QoS requirements

The AF may contact the PCF via the NEF (and Npcf_PDTQPolicyControl_Create service operation) to request a time window and related conditions for planned data transfer with QoS requirements (PDTQ).

NOTE 1: The NEF may contact any PCF in the operator network.

The AF request shall contain an ASP identifier, either a QoS Reference or individual QoS parameters and if the AF can adjust to different QoS parameter combinations, the AF may, in addition, provide Alternative Service Requirements in a prioritized order as defined in clause 6.1.3.22, the expected number of UE, the desired time window, and optionally, Network Area Information, and 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 request for notification is an indication that the ASP accepts that the PDTQ policy can be re-negotiated using the PDTQ warning notification procedure described in clause 5.2.5.9 of TS 23.502 [3].

NOTE 2: A third party application server is typically not able to provide any specific network area information and if so, the AF request is for the whole operator network.

The PCF shall first retrieve all existing PDTQ policies stored for any ASP from the UDR. The PCF subscribes to Analytics ID from NWDAF following the procedure and services described in TS 23.288 [24]. Afterwards, the PCF shall determine, based on the information provided by the AF, the analytics and other available information (e.g. network policy and existing PDTQ policies) one or more PDTQ policies.

Editor’s note: Which AnalyticsID the PCF subscribes to for the purpose to determine the recommended time window for the planned data transfer with QoS request is FFS.

An PDTQ policy consists of a recommended time window for the traffic transfer for each of the AF sessions for each of the UEs involved.

Editor´s note: The content of the PDTQ policy needs to be completed.

Finally, the PCF shall provide the candidate list of PDTQ policies to the AF via NEF together with the PDTQ Reference ID. If the AF received more than one PDTQ policy, the AF shall select one of them and inform the PCF about the selected PDTQ policy. The selected PDTQ policy together with the PDTQ Reference ID, the network area information, ASP identifier, the desired time window and whether the AF accepts PDTQ policy re-negotiation or not is stored by the PCF in the UDR as Data Set "Policy Data" and Data Subset "PQDT data". The same or a different PCF can retrieve this PDTQ policy and the corresponding related information from the UDR and take them into account for future decisions about PDTQ policies related to the same or other ASPs.

When the AF wants to apply the PDTQ to an existing session, then the AF will, at the time the traffic transfer is about to start, invoke, for each UE, the Nnef_AFsessionWithQoS/Npcf_PolicyAuthorization including the individual QoS that was previously negotiated.

Editor’s note: The procedure to renegotiate the time window for the planned transfer with QoS request to e.g., recommend a different time window is FFS.

6.1.3 Session management related policy control

6.1.3.1 General

The session management related policy control functionality of the Policy and Charging control framework for the 5G system provides the functions for policy and charging control as well as event reporting for service data flows.

The PCF evaluates operator policies that are triggered by events received from the AF directly or indirectly via an NEF, from the SMF, from the AMF and from the CHF as well as changes in User subscription Profile.

NOTE 1: The details for credit management and reporting are defined in SA WG5 specification.

NOTE 2: In single PCF deployment, the PCF will provide all mobility, access and session related policies that it is responsible for. In deployments where different PCFs support N15 and N7 respectively, no standardized interface between them is required in this release to support policy alignment.

NOTE 3: Policy control in multiple administrative areas is not defined in this release.

NOTE 4: Events received from the AF include changes in global policy related instructions (as described in clause 5.6.7 of TS 23.501 [2]).

The following clauses describe the most relevant session management related functionality in detail.

6.1.3.2 Binding mechanism

6.1.3.2.1 General

The binding mechanism is the procedure that associates a service data flow (defined in a PCC rule by means of the SDF template), to the QoS Flow deemed to transport the service data flow. For service data flows belonging to AF sessions, the binding mechanism shall also associate the AF session information with the QoS Flow that is selected to carry the service data flow.

NOTE 1: The relation between AF sessions and rules depends only on the operator configuration. An AF session can be covered by one or more PCC rules, if applicable (e.g. one rule per media component of an IMS session).

NOTE 2: The PCF may authorize dynamic PCC rules for service data flows without a corresponding AF session.

The binding mechanism includes three steps:

1. Session binding;

2. PCC rule authorization; and

3. QoS Flow binding.

6.1.3.2.2 Session binding

Session binding is the association of the AF session information to one and only one PDU Session. The PCF shall perform the session binding, which may take the following PDU Session parameters into account:

a) For an IP type PDU Session, the UE IPv4 address and/or IPv6 network prefix, in addition when using W-5GAN the description in TS 23.316 [27] applies, or when using 5G ProSe Layer-3 UE-to-Network Relay the description in TS 23.304 [34] applies;

For an Ethernet type PDU Session, the UE MAC address(es);

b) The UE identity (e.g. SUPI), if present;

c) The information about the Data Network (DN) the user is accessing, i.e. DNN, if present.

Once it has determined the impacted PDU Session, the PCF shall identify the PCC rules affected by the AF session information, including new PCC rules to be installed and existing PCC rules to be modified or removed.

Session Binding applies for PDU Sessions of IP type. It may also apply to Ethernet PDU Session type but only when especially allowed by PCC related Policy Control Request triggers.

6.1.3.2.3 PCC rule authorization

PCC Rule authorization is the selection of the 5G QoS parameters, described in clause 5.7.2 of TS 23.501 [2], for the PCC rules.

The PCF shall perform the PCC rule authorization for dynamic PCC rules belonging to AF sessions that have been selected in step 1, as described in clause 6.1.3.2.2, as well as for PCC rules without corresponding AF sessions.

For the authorization of a PCC rule the PCF shall consider any 5GC specific restrictions, subscription information and other information available to the PCF. Each PCC rule receives a set of QoS parameters that are supported by the specific Access Network.

The authorization of a PCC rule associated with an emergency service shall be supported without subscription information. The PCF shall apply local policies configured for the emergency service.

The authorization of a PCC rule used for provisioning the UE SNPN credentials via User Plane Remote Provisioning shall be supported without subscription information in the case of Onboarding SNPN (or shall be supported with subscription information in the cases other than Onboarding SNPN). The PCF shall apply policies for support of User Plane Remote Provisioning of UE SNPN Credentials as described in clause 6.1.3.25.

6.1.3.2.4 QoS Flow binding

QoS Flow binding is the association of a PCC rule to a QoS Flow within a PDU Session. The binding is performed using the following binding parameters:

– 5QI;

– ARP;

– QNC (if available in the PCC rule);

– Priority Level (if available in the PCC rule);

– Averaging Window (if available in the PCC rule);

– Maximum Data Burst Volume (if available in the PCC rule).

When the PCF provisions a PCC Rule, the SMF shall evaluate whether a QoS Flow with QoS parameters identical to the binding parameters exists unless the PCF requests to bind the PCC rule to the QoS Flow associated with the default QoS rule. If no such QoS Flow exists, the SMF derives the QoS parameters, using the parameters in the PCC Rule, for a new QoS Flow, binds the PCC Rule to the QoS Flow and then proceeds as described in clause 5.7.1.5 of TS 23.501 [2] to establish the new QoS Flow. If a QoS Flow with QoS parameters identical to the binding parameters exists, the SMF binds the PCC Rule to this QoS Flow and proceeds as described in clause 5.7.1.5 of TS 23.501 [2] to modify the QoS Flow unless local policies or the below mentioned conditions (which QoS Flow binding shall ensure), require the establishment of a new QoS Flow following the actions described above.

NOTE 1: For PCC rules containing a delay critical GBR 5QI value, the SMF can bind PCC Rules with the same binding parameters to different QoS Flows to ensure that the GFBR of the QoS Flow can be achieved with the Maximum Data Burst Volume of the QoS Flow.

The SMF shall identify the QoS Flow associated with the default QoS rule based on the fact that the PCC rule(s) bound to this QoS Flow contain:

– 5QI and ARP values that are identical to the PDU Session related information Authorized default 5QI/ARP; or

– a Bind to QoS Flow associated with the default QoS rule and apply PCC rule parameters Indication.

NOTE 2: The Bind to QoS Flow associated with the default QoS rule and apply PCC rule parameters Indication has to be used whenever the PDU Session related information Authorized default 5QI/ARP (as described in clause 6.3.1) cannot be directly used as the QoS parameters of the QoS Flow associated with the default QoS rule, for example when a GBR 5QI is used or the 5QI priority level has to be changed.

When a QoS Flow associated with the default QoS rule exists, the PCF can request that a PCC rule is bound to this QoS Flow by including the Bind to QoS Flow associated with the default QoS rule Indication in a dynamic PCC rule. In this case, the SMF shall bind the dynamic PCC rule to the QoS Flow associated with the default QoS rule (i.e. ignoring the binding parameters) and keep the binding as long as this indication remains set. When the PCF removes the association of a PCC rule to the QoS Flow associated with the default QoS rule, a new binding may need to be created between this PCC rule and a QoS Flow based on the binding mechanism described above.

The binding created between a PCC Rule and a QoS Flow causes the downlink part of the service data flow to be directed to the associated QoS Flow at the UPF (as described in clause 5.7.1 of TS 23.501 [2]). In the UE, the QoS rule associated with the QoS Flow (which is generated by the SMF and explicitly signalled to the UE as described in clause 5.7.1 of TS 23.501 [2]) instructs the UE to direct the uplink part of the service data flow to the QoS Flow in the binding.

Whenever the binding parameters of a PCC rule changes, the binding of this PCC rule shall be re-evaluated, i.e. the binding mechanism described above is performed again. The re-evaluation may, for a PCC rule, result in a new binding with another QoS Flow. If the PCF requests the same change of the binding parameter value(s) for all PCC rules that are bound to the same QoS Flow, the SMF should not re-evaluate the binding of these PCC rules and instead, modify the QoS parameter value(s) of the QoS Flow accordingly.

NOTE 3: A QoS change of the PDU Session related information Authorized default 5QI/ARP values doesn’t cause the QoS Flow rebinding for PCC rules with the Bind to QoS Flow associated with the default QoS rule Indication set.

When the PCF removes a PCC Rule, the SMF shall remove the association of the PCC Rule to the QoS Flow. If the last PCC rule that is bound to a QoS Flow is removed, the SMF shall delete the QoS Flow.

When a QoS Flow is removed, the SMF shall remove the PCC rules bound to this QoS Flow and report to the PCF that the PCC Rules bound to a QoS Flow are removed.

The QoS Flow binding shall also ensure that:

– when the PCF provisions a PCC rule, and if the PCC rule contains a TSC Assistance Container, the PCC rule is bound to a new QoS Flow and no other PCC rule is bound to this QoS Flow. Whenever the TSC Assistance Container of an existing PCC rule is changed, the binding of this PCC rule shall not be re-evaluated.

– if a dynamic value for the Core Network Packet Delay Budget (defined in clause 5.7.3.4 of TS 23.501 [2]) is used, PCC rules with the same above binding parameters but different PDU Session anchors (i.e. the corresponding service data flows which have different CN PDBs) are not bound to the same QoS Flow.

NOTE 4: Different PDU Session anchors can exist if the DNAI parameter of PCC rules contains multiple DNAIs.

– For MA PDU Session, PCC rules for GBR or delay critical GBR service data flows allowed on different access are not bound to the same QoS Flow even if the PCC rules contain the same binding parameters.

NOTE 5: For MA PDU Session, the GBR or delay critical GBR resource for a service data flow is allocated only in one access (as described in clause 5.32.4 of TS 23.501 [2]).

– When the PCF provisions a PCC rule with Alternative QoS parameter Set(s), the PCC rule is bound to a new QoS Flow and no other PCC rule is bound to this QoS Flow.

– When the PCF provisions a PCC rule with QoS Monitoring Policy, the PCC rule is bound to a new QoS Flow and no other PCC rules is bound to this QoS Flow.

NOTE 6: The binding of PCC rule with QoS Monitoring policy to a new QoS flow is only applicable to the Per QoS Flow per UE QoS Monitoring (as described in clause 5.33.3.2 of TS 23.501 [2]).

6.1.3.3 Reporting

Reporting refers to the differentiated PDU Session resource usage information (measured at the UPF) being reported by the SMF to the CHF.

NOTE 1: Reporting usage information to the CHF is distinct from credit management. Hence multiple PCC rules may share the same charging key for which one credit is assigned whereas reporting may be at higher granularity if serviced identifier level reporting is used.

The SMF shall report usage information for online and offline charging.

The SMF shall report usage information for each charging key value.

For service data flow charging, for the case of sponsored data connectivity, the reports for offline charging shall report usage for each charging key, Sponsor Identity and Application Service Provider Identity combination if Sponsor Identity and Application Service Provider Identifier have been provided in the PCC rules.

NOTE 2: Usage reports for online charging that include Sponsor Identity and Application Service Provider Identity is not within scope of the specification in this release. Online charging for sponsored data connectivity can be based on charging key as described in Annex X.

The SMF shall report usage information for each charging key/service identifier combination if service identifier level reporting is requested in the PCC rule.

NOTE 3: For reporting purposes when charging is performed by the SMF:

a) the charging key value identifies a service data flow if the charging key value is unique for that particular service data flow, and

b) if the service identifier level reporting is present then the service identifier value of the PCC rule together with the charging key identify the service data flow.

Charging information shall be reported based on the result from the service data flow detection and measurement on a per PDU Session basis.

A report may contain multiple containers, each container associated with a charging key, charging key and Sponsor Identity (in the case of sponsored connectivity) or charging key/service identifier.

6.1.3.4 Credit management

The credit management applies only for service data flow with online charging method and shall operate on a per charging key basis. The SMF should initiate one charging session with the CHF for each PDU Session subject to charging, in order to perform credit management within the charging session.

NOTE 1: Independent credit control for an individual service/application may be achieved by assigning a unique charging key value in the corresponding PCC rule.

The SMF shall request a credit for each charging key occurring in a PCC rule. It shall be up to operator configuration whether the SMF shall request credit in conjunction with the PCC rule being activated or when the first packet corresponding to the service is detected. The CHF may either grant or deny the request for credit. The CHF shall strictly control the rating decisions.

NOTE 2: The term ‘credit’ as used here does not imply actual monetary credit, but an abstract measure of resources available to the user. The relationship between this abstract measure, actual money, and actual network resources or data transfer, is controlled by the CHF.

During PDU Session establishment and modification, the SMF shall request credit using the information after applying policy enforcement action (e.g. upgraded or downgraded QoS information), if applicable, even though the SMF has not signalled this information to the AMF or RAN.

The events trigger information which may be received from the CHF, causing the SMF to perform a usage reporting and credit request to CHF when the event occurs are specified in TS 32.255 [21].

The CHF may subscribe to Change of UE presence in Presence Reporting Area at any time during the life time of the charging session as described in TS 32.255 [21].

If the PCF set the Out of credit event trigger (see clause 6.1.3.5), the SMF shall inform the PCF about the PCC rules for which credit is no longer available together with the applied termination action.

6.1.3.5 Policy Control Request Triggers relevant for SMF

The Policy Control Request Triggers relevant for SMF define the conditions when the SMF shall interact again with PCF after a PDU Session establishment as defined in the Session Management Policy Establishment and Session Management Policy Modification procedure as defined in TS 23.502 [3].

The PCR triggers are not applicable any longer at termination of the SM Policy Association.

The access independent Policy Control Request Triggers relevant for SMF are listed in table 6.1.3.5-1.

The differences with table 6.2 and table A.4.3-2 in TS 23.203 [4] are shown, either "none" means that the parameter applies in 5GS or "removed" meaning that the parameter does not apply in 5GS, this is due to the lack of support in the 5GS for this feature or "modified" meaning that the parameter applies with some modifications defined in the parameter.

Table 6.1.3.5-1: Access independent Policy Control Request Triggers relevant for SMF

Policy Control Request Trigger	Description	Difference compared with table 6.2 and table A.4.3-2 in TS 23.203 [4]	Conditions for reporting	Motivation
PLMN change	The UE has moved to another operators’ domain.	None	PCF
QoS change	The QoS parameters of the QoS Flow has changed.	Removed		Only applicable when binding of bearers was done in PCRF.
QoS change exceeding authorization	The QoS parameters of the QoS Flow has changed and exceeds the authorized QoS.	Removed		Only applicable when binding of bearers was done in PCRF.
Traffic mapping information change	The traffic mapping information of the QoS profile has changed.	Removed		Only applicable when binding of bearers was done in PCRF.
Resource modification request	A request for resource modification has been received by the SMF.	None	SMF always reports to PCF
Routing information change	The IP flow mobility routing information has changed (when IP flow mobility as specified in TS 23.261 [11] applies) or the PCEF has received Routing Rules from the UE (when NBIFOM as specified in TS 23.161 [10] applies).	Removed		Not in 5GS yet.
Change in Access Type (NOTE 8)	The Access Type and, if applicable, the RAT Type of the PDU Session has changed.	None	PCF
EPS Fallback	EPS fallback is initiated	Added	PCF
Loss/recovery of transmission resources	The Access type transmission resources are no longer usable/again usable.	Removed		Not in 5GS yet.
Location change (serving cell) (NOTE 6)	The serving cell of the UE has changed.	None	PCF
Location change (serving area) (NOTE 2)	The serving area of the UE has changed.	None	PCF
Location change (serving CN node) (NOTE 3)	The serving core network node of the UE has changed.	None	PCF
Change of UE presence in Presence Reporting Area (see NOTE 1)	The UE is entering/leaving a Presence Reporting Area.	None	PCF	Only applicable to PCF
Out of credit	Credit is no longer available.	None	PCF
Reallocation of credit	Credit has been reallocated after the former Out of credit indication.	Added	PCF
Enforced PCC rule request	SMF is performing a PCC rules request as instructed by the PCF.	None	PCF
Enforced ADC rule request	TDF is performing an ADC rules request as instructed by the PCRF.	Removed		ADC Rules are not applicable.
UE IP address change	A UE IP address has been allocated/released.	None	SMF always reports allocated or released UE IP addresses
UE MAC address change	A new UE MAC address is detected or a used UE MAC address is inactive for a specific period.	New	PCF
Access Network Charging Correlation Information	Access Network Charging Correlation Information has been assigned.	None	PCF
Usage report (NOTE 4)	The PDU Session or the Monitoring key specific resources consumed by a UE either reached the threshold or needs to be reported for other reasons.	None	PCF
Start of application traffic detection and Stop of application traffic detection (NOTE 5)	The start or the stop of application traffic has been detected.	None	PCF
SRVCC CS to PS handover	A CS to PS handover has been detected.	Removed		No support in 5GS yet
Access Network Information report	Access information as specified in the Access Network Information Reporting part of a PCC rule.	None	PCF
Credit management session failure	Transient/Permanent failure as specified by the CHF.	None	PCF
Addition / removal of an access to an IP-CAN session	The PCEF reports when an access is added or removed.	Removed		No support in 5GS yet
Change of usability of an access	The PCEF reports that an access becomes unusable or usable again.	Removed		No support in 5GS yet
3GPP PS Data Off status change	The SMF reports when the 3GPP PS Data Off status changes.	None	SMF always reports to PCF
Session AMBR change	The Session-AMBR has changed.	Added	SMF always reports to PCF
Default QoS change	The subscribed QoS has changed.	Added	SMF always reports to PCF
Removal of PCC rule	The SMF reports when the PCC rule is removed.	Added	SMF always reports to PCF
Successful resource allocation	The SMF reports to the PCF that the resources for a PCC rule have been successfully allocated.	Added	PCF
GFBR of the QoS Flow can no longer (or can again) be guaranteed	The SMF notifies the PCF when receiving notifications from RAN that GFBR of the QoS Flow can no longer (or can again) be guaranteed.	Added
UE resumed from suspend state	The SMF reports to the PCF when it detects that the UE is resumed from suspend state.	None	PCF	Only applicable to EPC IWK
Change of DN Authorization Profile Index	The DN Authorization Profile Index received from DN-AAA has changed.	Added	SMF always reports to PCF
5GS Bridge information available	SMF has detected new 5GS Bridge information, which may contain, user-plane Node ID, UE-DS-TT residence time and Ethernet port (port number and MAC address) or IP address for the PDU Session and/or PMIC and/or UMIC.	Added	PCF
QoS Monitoring for URLLC	The SMF notifies the PCF of the QoS Monitoring reports (e.g. UL packet delay, DL packet delay or round trip packet delay).	Added	PCF
DDN Failure event Subscription with Traffic Descriptor	The SMF requests PCF to provide or remove policies if it received an event subscription or cancellation for DDN Failure event including traffic descriptors. The SMF provides the traffic descriptors to the PCF for policy evaluation.	Added	PCF
DDD Status event Subscription with Traffic Descriptor	The SMF requests PCF to provide or remove policies if it received an event subscription or cancellation for DDD Status event including traffic descriptors. The SMF provides the traffic descriptors and the requested type(s) of notifications (notifications about downlink packets being buffered, and/or discarded) to the PCF for policy evaluation.	Added	PCF
QoS constraints change	The QoS constraints in the VPLMN have been provided or changed.	Added	SMF always reports to PCF
Satellite backhaul category change	The backhaul is changed between different satellite backhaul categories, or between satellite backhaul and non-satellite backhaul.	Added	PCF
NWDAF info change	The NWDAF instance IDs used for the PDU session or associated Analytics IDs used for the PDU session and available in the SMF have changed.	Added	PCF
Request for notification on SM Policy Association establishment or termination (NOTE 9)	The SMF reports to the PCF the request to notify on the established or terminated SM Policy Association,	Added	PCF
NOTE 1: The maximum number of PRA(s) per UE per PDU Session is configured in the PCF. The PCF may have independent configuration of the maximum number for Core Network pre-configured PRAs and UE-dedicated PRAs. The exact number(s) should be determined by operator in deployment. NOTE 2: This trigger reports change of Tracking Area in both 5GS and EPC interworking, or reports change of Routing Area for GERAN/UTRAN access (see Annex G of TS 23.502 [3]). NOTE 3: This trigger reports change of AMF in 5GC, change between ePDG and Serving GW in EPC, change between Serving GWs in EPC, change between EPC and 5GC, change between Serving Gateway and SGSN in GERAN/UTRAN from/to E-UTRAN mobility, or change between SGSNs in the case of GERAN/UTRAN access. In HR roaming case, if the AMF change is unknown by the H-SMF, then the AMF change is not reported. NOTE 4: Usage is defined as either volume or time of user plane traffic. NOTE 5: The start and stop of application traffic detection are separate event triggers, but received under the same subscription from the PCF. NOTE 6: Location change of serving cell can increase signalling load on multiple interfaces. Hence it is recommended that any such serving cell changes only applied for a limited number of subscribers avoiding extra signalling load. It also is applicable for GERAN/UTRAN access. NOTE 7: Void. NOTE 8: For 3GPP access the RAT type may refer to NR, E-UTRAN, and, when the SMF+PGW-C enhancements to support GERAN/UTRAN access via Gn/Gp interface as specified in Annex L of TS 23.501 [2] apply, to UTRAN or GERAN. For MA PDU Session this trigger reports the current used Access Type(s) and RAT type(s) upon any change of Access Type and RAT type. NOTE 9: The PCF for the PDU Session knows the change of the PCF for the UE by this Policy Control Request Trigger based on the associated binding information of and notifies the PCF for the UE as described in clause 6.1.3.18.

NOTE 1: In the following description of the access independent Policy Control Request Triggers relevant for SMF, the term trigger is used instead of Policy Control Request Trigger where appropriate.

When the EPS Fallback trigger is armed by the PCF, the SMF shall report the event to the PCF when a QoS Flow with 5QI=1 is rejected due to EPS Fallback.

When the Location change trigger is armed, the SMF shall subscribe to the AMF for reports on changes in location to the level indicated by the trigger. If credit-authorization triggers and Policy Control Request Triggers require different levels of reporting of location change for a single UE, the location to be reported should be changed to the highest level of detail required. However, there should be no request being triggered for PCC rules update to the PCF if the report received is more detailed than requested by the PCF.

NOTE 2: The access network may be configured to report location changes only when transmission resources are established in the radio access network.

The Resource modification request trigger shall trigger the PCF interaction for all resource modification requests not tied to a specific QoS Flow received by SMF. The resource modification request received by SMF may include request for guaranteed bit rate changes for a traffic aggregate and/or the association/disassociation of the traffic aggregate with a 5QI and/or a modification of the traffic aggregate.

The enforced PCC rule request trigger shall trigger a SMF interaction to request PCC rules from the PCF for an established PDU Session. This SMF interaction shall take place within the Revalidation time limit set by the PCF in the PDU Session related policy information. The SMF reports that the enforced PCC rule request trigger was met and the enforced PCC Rules.

NOTE 3: The enforced PCC rule request trigger can be used to avoid signalling overload situations e.g. due to time of day based PCC rule changes.

The UE IP address change trigger shall trigger a SMF interaction with the PCF if a UE IP address is allocated or released during the lifetime of the PDU Session. The SMF reports that the UE IP address change trigger was met and the new or released UE IP address.

The UE MAC address change trigger shall trigger a SMF interaction with the PCF if a new UE MAC address is detected or a used UE MAC address is inactive for a specific period during the lifetime of the Ethernet type PDU Session. The SMF reports that the UE MAC address change trigger was met and the new or released UE MAC address.

NOTE 4: The SMF instructs the UPF to detect new UE MAC addresses or used UE MAC address is inactive for a specific period as described in TS 23.501 [2].

The Access Network Charging Correlation Information trigger shall trigger the SMF to report the assigned access network charging identifier for the PCC rules that are accompanied with a request for this trigger at activation. The SMF reports that the Access Network Charging Correlation Information trigger was met and the Access Network Charging Correlation Information.

If the Usage report trigger is set and the volume or the time thresholds, earlier provided by the PCF, are reached, the SMF shall report this situation to the PCF. If both volume and time thresholds were provided and the thresholds, for one of the measurements, are reached, the SMF shall report this situation to the PCF and the accumulated usage since last report shall be reported for both measurements.

The management of the Presence Reporting Area (PRA) functionality enables the PCF to subscribe to reporting change of UE presence in a particular Presence Reporting Area.

NOTE 5: PCF decides whether to subscribe to AMF or to SMF for those triggers that are present in both tables 6.1.2.5-2 and 6.1.3.5-1. If the Change of UE presence in Presence Reporting Area trigger is available on both AMF and SMF, PCF should not subscribe to both AMF and SMF simultaneously.

Upon every interaction with the SMF, the PCF may activate / deactivate reporting changes of UE presence in Presence Reporting Area by setting / unsetting the corresponding trigger by providing the PRA Identifier(s) and additionally the list(s) of elements comprising the Presence Reporting Area for UE-dedicated Presence Reporting Area(s).

The SMF shall subscribe to the UE Location Change notification from the AMF by providing an area of interest containing the PRA Identifier(s) and additionally the list(s) of elements provided by the PCF as specified in clause 5.6.11 of TS 23.501 [2] and in clause 5.2.2.3.1 of TS 23.502 [3].

When the Change of UE presence in Presence Reporting Area trigger is armed, i.e. when the PCF subscribes to reporting change of UE presence in a particular Presence Reporting Area and the reporting change of UE presence in this Presence Reporting Area was not activated before, the SMF subscribes to the UE mobility event notification service provided by the AMF for reporting of UE presence in Area of Interest which reports when the UE enters or leaves a Presence Reporting Area (an initial report is received when the PDU Session specific procedure is activated). The SMF reports the PRA Identifier(s) and indication(s) whether the UE is inside or outside the Presence Reporting Area(s), and indication(s) if the corresponding Presence Reporting Area(s) is set to inactive by the AMF to the PCF.

NOTE 6: The serving node (i.e. AMF in 5GC or MME in EPC/EUTRAN) can activate the reporting for the PRAs which are inactive as described in the TS 23.501 [2].

When PCF modifies the list of PRA id(s) to change of UE presence in Presence Reporting Area for a particular Presence Reporting Area(s), the SMF removes or adds the PRA id(s) provided in the UE mobility event notification service provided by AMF for reporting of UE presence in Area Of Interest. When the PCF unsubscribes to reporting change of UE presence in Presence reporting Area, the SMF unsubscribes to the UE mobility event notification service provided by AMF for reporting of UE presence in Area Of Interest, unless subscriptions to AMF remains due to other triggers.

The SMF stores PCF subscription to reporting for changes of UE presence in Presence Reporting Area and notifies the PCF with the PRA Identifier(s) and indication(s) whether the UE is inside or outside the Presence Reporting Area(s) based on UE location change notification in area of interest received from the serving node according to the corresponding subscription.

NOTE 7: The SMF can also be triggered by the CHF to subscribe to notification of UE presence in PRA from the AMF, and notifies the CHF when receiving reporting of UE presence in PRA from the AMF, referring to TS 32.291 [20].

If PCF is configured with a PRA identifier referring to the list of PRA Identifier(s) within a Set of Core Network predefined Presence Reporting Areas as defined in TS 23.501 [2], it activates the reporting of UE entering/leaving each individual PRA in the Set of Core Network predefined Presence Reporting Areas, without providing the complete set of individual PRAs.

When a PRA set identified by a PRA Identifier was subscribed to report changes of UE presence in Presence Reporting Area by the PCF, the SMF additionally receives the PRA Identifier of the PRA set from the AMF, along with the individual PRA Identifier(s) belonging to the PRA set and indication(s) of whether the UE is inside or outside the individual Presence Reporting Area(s), as described in TS 23.501 [2].

When the Out of credit detection trigger is set, the SMF shall inform the PCF about the PCC rules for which credit is no longer available together with the applied termination action.

When the Reallocation of credit detection trigger is set, the SMF shall inform the PCF about the PCC rules for which credit has been reallocated after credit was no longer available and the termination action was applied.

The Start of application traffic detection and Stop of application traffic detection triggers shall trigger an interaction with PCF once the requested application traffic is detected (i.e. Start of application traffic detection) or the end of the requested application traffic is detected (i.e. Stop of application traffic detection) unless it is requested within a specific PCC Rule to mute such interaction for solicited application reporting or unconditionally in the case of unsolicited application reporting. The application identifier and service data flow descriptions, if deducible, shall also be included in the report. An application instance identifier shall be included in the report both for Start and for Stop of application traffic detection when service data flow descriptions are deducible. This is done to unambiguously match the Start and the Stop events.

At PCC rule activation, modification and deactivation the SMF shall send, as specified in the PCC rule, the User Location Report and/or UE Timezone Report to the PCF.

NOTE 8: At PCC rule deactivation the User Location Report includes information on when the UE was last known to be in that location.

If the trigger for Access Network Information reporting is set, the SMF shall check the need for access network information reporting after successful installation/modification or removal of a PCC rule or upon termination of the PDU Session. The SMF shall check the Access Network Information report parameters (User Location Report, UE Timezone Report) of the PCC rules and report the access network information to the PCF. The SMF shall not report any subsequent access network information updates received from the PDU Session without any previous updates of related PCC rule unless the associated QoS Flow or PDU Session has been released.

If the SMF receives a request to install/modify or remove a PCC rule with Access Network Information report parameters (User Location Report, UE Timezone Report) set the SMF shall initiate a PDU Session modification to retrieve the current access network information of the UE and forward it to the PCF afterwards.

If the Access Network Information report parameter for the User Location Report is set and the user location (e.g. cell) is not available to the SMF, the SMF shall provide the serving PLMN identifier to the PCF.

The Credit management session failure trigger shall trigger a SMF interaction with the PCF to inform about a credit management session failure and to indicate the failure reason, and the affected PCC rules.

NOTE 9: As a result, the PCF may decide about e.g. PDU Session termination, perform gating of services, switch to offline charging, change rating group, etc.

NOTE 10: The Credit management session failure trigger applies to situations wherein the PDU Session is not terminated by the SMF due to the credit management session failure.

The default QoS change triggers shall trigger the PCF interaction for all changes in the default QoS data received in SMF from the UDM.

The Session AMBR change trigger shall trigger the SMF to provide the Session-AMBR to the PCF containing the DN authorised Session AMBR if received from the DN-AAA, or the Subscribed Session-AMBR received from the UDM as described in clause 5.6.6 of TS 23.501 [2].

The default QoS change trigger reports a change in the default 5QI/ARP retrieved by SMF from UDM, as explained in clause 5.7.2.7 of TS 23.501 [2].

If the PCC Rules bound to a QoS Flow are removed when the corresponding QoS Flow is removed or the PCC rules are failed to be enforced, the SMF shall report this situation to the PCF. The PCF may then provide the same or updated PCC rules for the established PDU Session.

If the trigger for successful resource allocation is set and the PCF has also provided an indication that a specific PCC rule is subject to this trigger, the SMF shall report to the PCF when the resources associated to this PCC rule have been successfully allocated. The SMF shall report resource allocation failure always to the PCF, independently of this trigger.

If the GFBR of the QoS Flow can no longer (or can again) be guaranteed trigger is armed, the SMF shall check the need for reporting to the PCF when the SMF receives an explicit notification from (R)AN indicating that GFBR of the QoS Flow can no longer (or can again) be guaranteed or when the condition described in clause 5.7.2.4 of TS 23.501 [2] is met during the handover. The SMF shall report that GFBR of the QoS Flow can no longer (or can again) be guaranteed accordingly to the PCF for those PCC rules which are bound to the affected QoS Flow and have the QoS Notification Control (QNC) parameter set. If additional information is received with the notification from NG-RAN (see clause 5.7.2.4 of TS 23.501 [2]), the SMF shall also provide to the PCF the reference to the Alternative QoS parameter set corresponding to the Alternative QoS Profile referenced by NG-RAN. If NG-RAN has indicated that the lowest priority Alternative QoS Profile cannot be fulfilled, the SMF shall indicate to the PCF that the lowest priority Alternative QoS parameter set cannot be fulfilled.

In an interworking scenario between 5GS and EPC/E-UTRAN, as explained in clause 4.3 of TS 23.501 [2], the PCF may subscribe via the SMF also to the Policy Control Request Triggers described in clause 6.1.2.5 when the UE is served by the EPC/E-UTRAN.

The change of DN Authorization Profile Index shall trigger a SMF interaction to send DN Authorization Profile Index to retrieve a list of PCC Rules (as defined in clause 6.3) and/or PDU Session related policy (as defined in clause 6.4) for an established PDU Session.

If the trigger for 5GS Bridge information available is armed, the SMF shall report the 5GS Bridge information when the SMF has determined or updated the 5GS Bridge information, e.g. when SMF has detected an Ethernet port which supports exchange of Ethernet Port Management Information Containers or received User plane node Management Information Container or Port Management Information Container. If a new manageable Ethernet DS-TT port is detected, the SMF provides User plane node ID, the port number and optionally MAC address of the related port of the related PDU Session to the PCF. If the SMF has received UE-DS-TT Residence Time then the SMF also provides UE-DS-TT Residence Time to the PCF. If the SMF has received the User plane node Management Information Container from NW-TT or Port Management Information Container from NW-TT or DS-TT, the SMF also provides User plane node Management Information Container or Port Management Information Container and related port number to the PCF.

When the QoS Monitoring for URLLC trigger is set, the SMF shall, upon receiving the QoS Monitoring report from the UPF, send the measurement report to the PCF.

If the Policy Control Request Trigger "DDN Failure event subscription with Traffic Descriptor" or "DDD Status event subscription with Traffic Descriptor" is set, the SMF shall request policies if it received a subscription or cancellation of notifications for availability after DDN Failure event with traffic descriptor or DDD Status event with traffic descriptor, respectively. The SMF indicates whether it is a subscription or cancellation event and provides the received Traffic Descriptor as well as the requested type(s) of notifications (notifications about downlink packets being buffered, and/or discarded) to the PCF. When the SMF indicates a subscription event, the PCF checks whether an installed PCC rule exists for the received Traffic Descriptor and if so, the PCF sets the Downlink Data Notification Control information of that PCC rule according to the requested type(s) of notifications. Otherwise, the PCF provides a new PCC Rule with the received Traffic Descriptor in the SDF Template, the Downlink Data Notification Control information set according to the requested type(s) of notifications and other PCC Rule information set to the same values as in the existing PCC rule that previously matched the traffic. When the new PCC has to be bound to the QoS Flow associated with the default QoS rules, the PCF sets the "Bind to QoS Flow associated with the default QoS rule" parameter. From now on, the PCF needs to keep the PCC rule for the DDD event detection fully synchronized with the existing PCC rule that previously matched the traffic for all other policy and charging control settings to ensure the same user experience and traffic treatment according to the operator policy. When the SMF indicates a cancellation event, the PCF removes the Downlink Data Notification Control information in the installed PCC Rule or removes the PCC Rule if a new PCC rule has been provided during the subscription event and this PCC rule is no longer necessary for any other policy enforcement.

NOTE 11: Downlink Data Delivery (DDD) status event and DDN Failure event are specified in clause 4.15.3 of TS 23.502 [3].

The QoS constraints change trigger shall trigger a SMF interaction with the PCF if QoS constraints are received by the SMF during the lifetime of the PDU Session. The SMF reports that the QoS constraints change trigger was met and the new QoS constraints.

When the Satellite backhaul category change trigger is armed, the SMF reports to the PCF that the Satellite backhaul category change was met and the new satellite backhaul category (or that satellite backhaul is no longer used) when it becomes aware that there is a change of the backhaul which is used for the PDU Session between satellite backhaul categories, or between satellite backhaul and a non-satellite backhaul. The SMF determines whether or not a satellite backhaul is used and whether there is a change of backhaul based on signalling from the AMF as specified in TS 23.501 [2].

NOTE 12: As specified in clause 5.8.2.15 in TS 23.501 [2], satellite backhaul category refers to the type (i.e. GEO, MEO, LEO or OTHERSAT) of the satellite used in the backhaul. Only a single backhaul category can be indicated.

The NWDAF info change trigger shall trigger the SMF to interact with the PCF when the list of NWDAF Instance IDs used for the PDU Session or associated Analytics IDs used for the PDU Session are changed in the SMF.

The Request for notification on SM Policy Association establishment or termination indicates to the SMF that the request from the AMF to notify on the established or terminated SM Policy Association should be sent to the PCF together with the received PCF binding information.

6.1.3.6 Policy control

QoS control refers to the authorization and enforcement of the maximum QoS that is authorized for a service data flow, for a QoS Flow or for the PDU Session. A service data flow may be either of IP type or of Ethernet type. PDU Sessions may be of IP type or Ethernet type or unstructured.

The PCF, in a dynamic PCC Rule, associates a service data flow template to an authorized QoS that is provided in a PCC Rule to the SMF. The PCF may also activate a pre-defined PCC Rule that contains that association.

The authorized QoS for a service data flow template shall include a 5QI and the ARP. For a 5QI of GBR or Delay-critical GBR resource type, the authorized QoS shall also include the MBR, GBR and may include the QoS Notification Control parameter (for notifications when authorized GFBR can no longer ( or can again) be fulfilled). For 5QI of Non-GBR resource type, the authorized QoS may include the MBR and the Reflective QoS Control parameter. The 5QI value can be standardized (i.e. referring to QoS characteristics as defined in clause 5.7.3 of TS 23.501 [2]), pre-configured (i.e. referring to QoS characteristics configured in the RAN) or dynamically assigned (i.e. referring to QoS characteristics provided by the PCF as Explicitly signalled QoS Characteristics in the PDU Session related policy information described in clause 6.4).

NOTE 1: Further details, special cases and additional parameters are described in clause 6.3.1.

QoS control also refers to the authorization and enforcement of the Session-AMBR and default 5QI/ARP combination. The PCF may provide the Authorized Session-AMBR and the Authorized default 5QI and ARP combination as part of the PDU Session information for the PDU Session to the SMF. The Authorized Session-AMBR and Authorized default 5QI/ARP values takes precedence over other values locally configured or received at the SMF.

In home routed roaming, the H-SMF may provide the QoS constraints received from the VPLMN (defined in clause 4.3.2.2.2 of TS 23.502 [3]) to the H-PCF. The H-PCF ensures that the Authorized Session-AMBR value does not exceed the Session-AMBR value provided by the VPLMN and the Authorized default 5QI/ARP contains a 5QI and ARP value supported by the VPLMN. If no QoS constraints are provided the H-PCF considers that no QoS constraints apply unless operator policies define any. The PCF shall also consider the QoS constraints for the setting of the Subsequent Authorized default 5QI/ARP and Subsequent Authorized Session-AMBR.

For policy control, the AF interacts with the PCF and the PCF interacts with the SMF as instructed by the AF. For certain events related to policy control, the AF shall be able to give instructions to the PCF to act on its own, i.e. based on the service information currently available. The following events are subject to instructions from the AF:

– The authorization of the service based on incomplete service information;

NOTE 2: The QoS authorization based on incomplete service information is required for e.g. IMS session setup scenarios with available resources on originating side and a need for resource reservation on terminating side.

– The immediate authorization of the service;

– The gate control (i.e. whether there is a common gate handling per AF session or an individual gate handling per AF session component required);

– The forwarding of QoS Flow level information or events (see clause 6.1.3.18).

The UE and the AF shall provide all available flow description information (e.g. source and destination IP address and port numbers and the protocol information) to enable the binding functionality and the generation or selection of the service data flow filter(s) in the PCC rules. The AF may also provide a ToS (IPv4) or TC (IPv6) value that is set by the application as part of the flow description information. The PCF generates a PCC Rule with service data flow filter(s) (either as IP Packet Filter set as defined in clause 5.7.6.2 of TS 23.501 [2] or as Ethernet Packet Filter set as defined in clause 5.7.6.3 of TS 23.501 [2]) derived from the flow description information.

NOTE 3: A ToS/TC value can be useful when another packet filter attribute is needed to differentiate between packet flows. For example, packet flows encapsulated and encrypted by a tunnelling protocol can be differentiated by the ToS/TC value of the outer header if appropriately set by the application. To use ToS/TC for service data flow detection, network configuration by the operator (and additionally by the 3rd party Service Provider when the transport network is not fully within the operator control) needs to ensure there is no ToS/TC re-marking applied along the path from the application to the PSA UPF and the specific ToS/TC values are managed properly to avoid potential collision with other usage (e.g., paging policy differentiation). An example that the transport network is not fully within operator control is the Edge Hosting Environment according to TS 23.548 [33].

If SMF indicates that a PDU session is carried over NR satellite access or satellite backhaul, the PCF may take this information into account for the policy decision, e.g. together with any delay requirements provided by the AF.

When SMF indicates that the dynamic satellite backhaul is used to serve the PDU session, the PCF may request the SMF to trigger QoS monitoring and to report the packet delay and take the packet delay into account for the policy decision.

Editor’s note: Whether PCF can request QoS monitoring for the backhaul only, i.e. without receiving delay values including RAN part delay, is FFS.

6.1.3.7 Service (data flow) prioritization and conflict handling

Service pre-emption priority enables the PCF to resolve conflicts where the activation of all requested active PCC rules for services would result in a cumulative authorized QoS which exceeds the Subscribed Guaranteed bandwidth QoS.

NOTE 1: For example, the PCF may use the pre-emption priority of a service, the activation of which would cause the subscriber’s authorized QoS to be exceeded. If this pre-emption priority is greater than that of any one or more active PCC rules, the PCF can determine whether the deactivation of any one or more such rules would allow the higher pre-emption priority PCC rule to be activated whilst ensuring the resulting cumulative QoS does not exceed a subscriber’s Subscribed Guaranteed Bandwidth QoS.

If such a determination can be made, the PCF may resolve the conflict by deactivating those selected PCC rules with lower pre-emption priorities and accepting the higher priority service information from the AF. If such a determination cannot be made, the PCF may reject the service information from the AF.

NOTE 2: Normative PCF requirements for conflict handling are not defined. Alternative procedures may use a combination of pre-emption priority and AF provided priority indicator.

6.1.3.8 Termination action

The termination action indicates the action which the SMF instructs the UPF to perform for all PCC rules of a Charging key for which credit is no longer available. The functional description for termination actions is described in TS 32.255 [21].

The SMF shall revert the termination action related instructions for the UPF for all PCC rules of a Charging key when credit is available again.

6.1.3.9 Handling of packet filters provided to the UE by SMF

Traffic mapping information is signalled to the UE by the SMF in the Packet Filter Sets of QoS rules as defined in TS 23.501 [2].

The network shall ensure that the traffic mapping information signalled to UE reflects the QoS Flow binding of PCC rules, except for those extending the inspection beyond what can be signalled to the UE. The PCC rules may restrict what traffic is allowed compared to what is explicitly signalled to the UE. The PCF may, per service data flow filter, indicate that the SMF is required to explicitly signal the corresponding traffic mapping information to the UE, e.g. for the purpose of IMS precondition handling at the UE. In absence of that indication, it is an SMF decision whether to signal the traffic mapping information that is redundant from a traffic mapping point of view.

For QoS Flow for services with no uplink IP flows, there is no need to provide any UL filter to the UE that effectively disallows any useful packet flows in uplink direction.

The default QoS rule will either contain a Packet Filter Set that allows all UL packets or a Packet Filter Set that is generated from the UL SDF filters (and from the DL SDF filters if they are available) which have an indication to signal corresponding traffic mapping information to the UE.

NOTE: If multiple PCC rules with an indication to signal corresponding traffic mapping information to the UE are bound to the QoS Flow associated with the default QoS rule, it is up to SMF implementation which one will be chosen to generate the default QoS rule. If the PCC rule that is chosen to generate the default QoS rule is removed/deactivated, another PCC rule bound to the QoS Flow associated with the default QoS rule will be used instead and the default QoS rule would be updated accordingly.

In the case of interworking with E-UTRAN connected to EPC, the specific aspects of the handling of packet filters at the SMF are described in clause 4.11.1 of TS 23.502 [3].

6.1.3.10 IMS emergency session support

PDU Sessions for IMS Emergency services are provided by the serving network to support IMS emergency when the serving network is configured to support emergency services. The serving network may be either a PLMN or a SNPN. Emergency services are network services provided through an Emergency DNN and may not require a subscription depending on operator policies and local regulatory requirements. For emergency services, the architecture for the non-roaming case is the only applicable architecture model.

For emergency services, the N36 reference point does not apply. Emergency services are handled locally in the serving network.

For a PDU Session serving an IMS emergency session, the PCF makes authorization and policy decisions that restrict the traffic to emergency destinations, IMS signalling and the traffic to retrieve user location information (in the user plane) for emergency services. A PDU Session serving an IMS emergency session shall not serve any other service and shall not be converted to/from any PDU Session serving other services. The PCF shall determine based on the DNN if a PDU Session concerns an IMS emergency session.

The PCC Rule Authorization function selects QoS parameters that allow prioritization of IMS Emergency sessions. If an IMS Emergency session is prioritized the QoS parameters in the PCC Rule shall contain an ARP value that is reserved for intra-operator use of IMS Emergency services. The PCF does not perform subscription check; instead it utilizes the locally configured operator policies to make authorization and policy decisions.

NOTE 1: Reserved value range for intra-operator use is defined in TS 23.501 [2].

For an emergency DNN, the PCF does not perform subscription check; instead it utilizes the locally configured operator policies to make authorization and policy decisions.

It shall be possible for the PCF to verify that the IMS service information is associated with a UE IP address belonging to an emergency DNN. If the IMS service information does not contain an emergency related indication and the UE IP address is associated with an emergency DNN, the PCF shall reject the IMS service information provided by the P‑CSCF (and thus to trigger the release of the associated IMS session), see TS 23.167 [12].

In addition, the PCF shall provide the PEI and the subscriber identifiers (SUPI, GPSI) (if available), received from the SMF at PDU Session establishment, if so requested by the P-CSCF. The SUPI contains an IMSI or a network-specific identifier in the form of a NAI as defined in clauses 5.9.2 and 5.30.2.3 of TS 23.501 [2]. If the PCF removes all PCC Rules with a 5QI other than the default 5QI and the 5QI used for IMS signalling, the SMF shall start a configurable inactivity timer (e.g. to enable PSAP Callback session). When the configured period of time expires the SMF shall terminate the PDU Session serving the IMS Emergency session as defined in TS 23.502 [3]. If the SMF receives new PCC rule(s) with a 5QI other than the default 5QI and the 5QI used for IMS signalling for the PDU Session serving the IMS Emergency session, the SMF shall cancel the inactivity timer.

6.1.3.11 Multimedia Priority Service support

Multimedia Priority Services (MPS) is defined in TS 23.501 [2], TS 23.502 [3] and in TS 23.228 [5], utilising the architecture defined for 5GS.

Subscription data for MPS is provided to PCF through the N36/Nudr. To support MPS service, the PCF shall subscribe to changes in the MPS subscription data for Priority PDU connectivity service. Dynamic invocation for MPS provided from an AF using the Priority indicator over N5/Npcf takes precedence over the MPS subscription.

ARP and/or 5QI may be modified. It shall be possible to override the default Priority Level associated with the standardized 5QI.

For dynamic invocation of MPS service, the PCF shall generate the corresponding PCC rule(s) with the ARP and 5QI parameters as appropriate for the prioritized service, as defined in TS 23.501 [2].

Whenever one or more AF sessions of an MPS service are active within the same PDU Session, the PCF shall ensure that the ARP priority level of the QoS Flow for signalling as well as the QoS Flow associated with the default QoS rule is at least as high as the highest ARP priority level used by any authorized PCC rule belonging to an MPS service. If the ARP pre-emption capability is enabled for any of the authorized PCC rules belonging to an MPS service, the PCF shall also enable the ARP pre-emption capability for the QoS Flow for signalling as well as the QoS Flow associated with the default QoS rule.

In the case of IMS MPS, in addition to the above, the following QoS Flow handling applies:

– At reception of the indication from subscription information that the IMS Signalling Priority is set for the PDU Session or at reception of service authorization from the P-CSCF (AF) including an MPS session indication and the service priority level as defined in TS 23.228 [5], the PCF shall (under consideration of the requirement described in clauses 5.16.5 and 5.22.3 in TS 23.501 [2]) modify the ARP in all the PCC rules that describe the IMS signalling traffic to the value appropriate for IMS Multimedia Priority Services, if upgrade of the QoS Flow carrying IMS Signalling is required. To modify the ARP of the QoS Flow associated with the default QoS rule the PCF shall modify the Authorized default 5QI/ARP.

– When the PCF detects that the P-CSCF (AF) released all the MPS sessions and the IMS Signalling Priority is not set for the PDU Session the PCF shall consider changes of the requirement described in clauses 5.16.5 and 5.22.3 in TS 23.501 [2] and modify the ARP in all PCC rules that describe the IMS signalling traffic to an appropriate value according to PCF decision. The PCC rules bound to the QoS Flow associated with the default QoS rule have to be changed accordingly.

NOTE 1: To keep the PCC rules bound to this QoS Flow, the PCF can either modify the ARP of these PCC rules accordingly or set the Bind to QoS Flow associated with the default QoS rule.

The Priority PDU connectivity service targets the ARP and/or 5QI of the QoS Flows, enabling the prioritization of all traffic on the same QoS Flow.

For non-MPS service, the PCF shall generate the corresponding PCC rule(s) as per normal procedures (i.e. without consideration whether the MPS Priority PDU connectivity service is active or not), and shall upgrade the ARP/5QI values suitable for MPS when the Priority PDU connectivity service is invoked. When the Priority PDU connectivity service is revoked, the PCF shall change the ARP/5QI values modified for the Priority PDU connectivity service to appropriate values according to PCF decision.

The PCF shall, at the activation of the Priority PDU connectivity service:

– modify the ARP of PCC rules installed before the activation of the Priority PDU connectivity service to the ARP as appropriate for the Priority PDU connectivity service under consideration of the requirement described in clause 5.16.5 of TS 23.501 [2]; and

– if modification of the 5QI of the PCC rule(s) is required, modify the 5QI of the PCC rules installed before the activation of the Priority PDU connectivity service to the 5QI as appropriate for this service.

The PCF shall, at the deactivation of the Priority PDU connectivity service modify any 5QI and ARP value to the value according to the PCF policy decision.

For PCC rules modified due to the activation of Priority PDU connectivity service:

– modify the ARP to an appropriate value according to PCF decision under consideration of the requirement described in clauses 5.16.5 and 5.22.3 in TS 23.501 [2]; and

– if modification of the 5QI of PCC rule(s) is required, modify the 5QI to an appropriate value according to PCF decision.

MPS for Data Transport Service enables the prioritization of all traffic on the QoS Flow associated with the default QoS rule and other QoS Flows upon AF request. The QoS modification to the QoS Flow associated with the default QoS rule and other QoS Flows is done based on operator policy and regulatory rules by means of local PCF configuration.

NOTE 2: If no configuration is provided, MPS for Data Transport Service applies only to the QoS Flow associated with the default QoS rule.

Upon receipt of an MPS for Data Transport Service invocation/revocation request from the UE, the AF or the PCF authorizes the request. If the UE has an MPS subscription, MPS for Data Transport Service is authorized by the AF or the PCF, based on AF decision. If the Service User is using a UE that does not have an MPS subscription, the AF authorizes MPS for Data Transport Service:

– In the case that the AF authorizes the MPS for Data Transport Service request, after successful authorization, the AF sends the MPS for Data Transport Service request to the PCF over N5/Npcf for QoS Flow modifications, including an indication that PCF authorization is not needed. In this case, the PCF shall not perform any MPS subscription check for the MPS for Data Transport Service request. The AF also indicates to the PCF whether the request is for invoking or revoking MPS for Data Transport Service.

– In the case that the AF does not authorize the MPS for Data Transport Service request, the AF sends the request to the PCF over N5/Npcf for authorization and QoS Flow modifications, including an indication that PCF authorization is needed. In this case, the PCF shall perform an MPS subscription check for the MPS for Data Transport Service request. The AF also indicates whether the request is for invoking or revoking MPS for Data Transport Service. The PCF will inform the AF when the UE does not have an MPS subscription associated with the request.

After successful authorization by either AF or PCF as described above, the PCF shall, at the invocation/revocation of MPS for Data Transport Service, perform the same steps for QoS modifications as described above for the activation/deactivation of the Priority PDU connectivity service.

NOTE 3: To keep the PCC rules bound to the QoS Flow associated with the default QoS Rule, the PCF can either modify the ARP/QCI of these PCC rules accordingly or set the PCC rule attribute Bind to QoS Flow associated with the default QoS rule.

The PCF shall inform the AF of the success or failure of the MPS for Data Transport Service invocation/revocation request. If the PDU Session is deactivated for other reasons that an AF request, the PCF shall notify the AF by deleting the N5 session context.

For MPS for Data Transport Service, the AF may also request an SDF for priority signalling between the UE and the AF, where the AF includes the Priority indicator over N5/Npcf, in order to enable the PCF to set appropriate QoS values for the QoS Flow.

6.1.3.12 Redirection

Redirection of uplink application traffic is an option applicable in SMF or in UPF.

PCF may control redirection by provisioning and modifying dynamic PCC rules over the N7 interface, or activate/deactivate the predefined redirection policies in SMF. The PCF may enable/disable redirection and set a redirect destination for every dynamic PCC rule. Redirect information (redirection enabled/disabled and redirect destination) within a PCC Rule instructs the SMF whether or not to perform redirection towards a specific redirect destination. The redirect destination may be provided as part of the dynamic PCC Rule, or may be preconfigured in the SMF or UPF. A redirect destination provided in a dynamic PCC Rule overrides the redirect destination preconfigured in the SMF or UPF for this PCC Rule.

6.1.3.13 Resource sharing for different AF sessions

The P-CSCF (i.e. AF) may indicate to the PCF that media of an AF session may share resources with media belonging to other AF sessions according to TS 23.228 [5]. For every media flow, the P-CSCF may indicate that the media flow may share resources in both directions or in one direction only (UL or DL).

The PCF makes authorization and policy decisions for the affected AF sessions individually and generates a PCC rule for every media flow in any AF session.

If the PCF received identical indication(s) for resource sharing for multiple AF sessions, the PCF may request the SMF to realize resource sharing for the corresponding set of PCC rules. The PCF provides a DL and/or UL sharing indication with the same value for those PCC rules that are candidate to share resources according to the direction of resource sharing indicated by the AF.

For each direction, the SMF shall take the highest GBR value from each set of PCC rules related with the same sharing indication for this direction and bound to the same QoS Flow and uses that value as input for calculating the GFBR of the QoS Flow. For each direction, the SMF may take the MBR value of the most demanding PCC rule included in each set of PCC rules related with the same sharing indication for this direction and bound to the same QoS Flow and uses that as input for calculating the MFBR of the QoS Flow.

The AF session termination or modification procedure that removes media flows triggers the removal of the corresponding PCC rules from the SMF. The SMF shall recalculate the GFBR (and MFBR) value of the QoS Flow whenever a set of PCC rules with the same sharing indication changes.

Resource sharing is applied as long as there are at least two active PCC rules with the same sharing indication bound to the same QoS Flow.

Resource sharing for different AF sessions is possible only if the P-CSCF, the PCF and the SMF support it.

NOTE: This procedure assumes that applications/service logic must do the necessary coordination, e.g. pause sending or employ gating, to avoid service data flows interfering and to ensure that multiple flows comply with the combined QoS parameters.

6.1.3.14 Traffic steering control

Traffic steering control is triggered by the PCF initiated request and consists of steering the detected service data flows matching application detection filters or service data flow filter(s) in PCC Rules. The traffic steering control consists in one of the following:

– AF influenced Traffic Steering: diverting (at DNAI(s) provided in PCC rules) traffic matching traffic filters provided by the PCF, as described in clause 5.6.7 of TS 23.501 [2].

– N6-LAN Traffic Steering: applying a specific N6 traffic steering policy for the purpose of steering the subscriber’s traffic to appropriated N6 service functions deployed by the operator or a 3rd party service provider.

The PCF uses one or more pieces of information such as network operator’s policies, user subscription, user’s current RAT, network load status, application identifier, time of day, UE location, DNN, related to the subscriber session and the application traffic as input for selecting a traffic steering policy.

The PCF controls traffic steering by provisioning and modifying traffic steering control information in PCC rules. Traffic steering control information consists of a traffic description and in the case of N6-LAN Traffic Steering, a reference to a traffic steering policy that is configured in the SMF or, in the case of AF influenced Traffic Steering, per DNAI a reference to a traffic steering policy and/or N6 traffic routing information as well as other parameters described in clause 6.3.1 a reference to a traffic steering policy that is configured in the SMF.

The SMF instructs the UPF to perform necessary actions to enforce the traffic steering policy referenced by the PCF. The actual traffic steering applies at the UPF. For enforcing the traffic steering policy, the UPF may support traffic steering related functions as defined by other standard organizations. The mechanism used for routing the traffic over N6 is out of 3GPP scope.

6.1.3.15 Resource reservation for services sharing priority

An AF may indicate to the PCF that a media flow of an AF session is allowed to use the same priority as media flows belonging to other AF sessions (instead of the service priority provided for this media flow). In this case, the AF will provide a priority sharing indicator in addition to the application identifier and the service priority. For MCPTT, the service priority and the priority sharing indicator are defined in TS 23.179 [6]. The priority sharing indicator is used to indicate what media flows are allowed to share priority.

The PCF makes authorization and policy decisions for the affected AF sessions individually and generates a PCC rule for every media flow as specified in clause 6.1.1.3. The application identifier and the service priority are used to calculate the ARP priority. The AF may also provide suggested pre-emption capability and vulnerability values per media flow to the PCF. The ARP pre-emption capability and the ARP pre-emption vulnerability are set according to operator policies and regulatory requirements, also taking into consideration the application identifier and suggested values, when provided by the AF. The priority sharing indicator is stored for later use.

For PCC rules with the same 5QI assigned and having an associated priority sharing indicator, the PCF shall try to make authorization and policy decisions taking the priority sharing indicator into account and modify the ARP of these PCC rules as follows, (the original ARP values are stored for later use):

– The modified ARP priority is set to the highest of the original priority among all the PCC rules that include the priority sharing indicator;

– The modified ARP pre-emption capability is set if any of the original PCC rules have the ARP pre-emption capability set;

– The modified ARP pre-emption vulnerability is set if all the original PCC rules have the ARP pre-emption vulnerability set.

If the PCF receives an indication that a PCC rule provisioning or modification failed (due to resource reservation failure) then, the PCF may apply pre-emption and remove active PCC rules from the SMF and then retry the PCC rule provisioning or modification. If the PCF does not apply pre-emption, the AF is notified using existing procedures that the resource reservation for the new media flow failed.

The AF may optionally provide pre-emption control information, including pre-emption capability and vulnerability values, in addition to the priority sharing indicator to the PCF. If so, the PCF shall apply pre-emption and remove active PCC rules according to this information when receiving an indication that a PCC rule provisioning or modification failed. The pre-emption control information indicates:

– whether media flows sharing priority are candidates to being pre-empted taking into account pre-emption capability and vulnerability values;

– how to perform pre-emption among multiple potential media flow candidates of same priority: most recently added media flow, least recently added media flow, media flow with highest requested bandwidth in the AF request.

6.1.3.16 3GPP PS Data Off

This feature, when activated by the user, prevents traffics via 3GPP access except for 3GPP PS Data Off Exempt Services. The 3GPP PS Data Off Exempt Services are a set of operator services, defined in TS 22.011 [15] and TS 23.221 [16], that are the only allowed services in both downlink and uplink direction when the 3GPP PS Data Off feature has been activated by the user.

When PCF is deployed, it shall be able to configure the list(s) of 3GPP PS Data Off Exempt Services for 3GPP access, and the Policy Control Request Trigger of 3GPP PS Data Off status change used to inform the PCF from SMF about every change of the 3GPP PS Data Off status.

NOTE 1: The PCF can be configured with a list(s) of 3GPP PS Data Off Exempt Services per DNN. The list(s) of 3GPP PS Data Off Exempt Services for an DNN can also be empty, or can allow for any service within that DNN, according to operator policy.

NOTE 2: For the PDU Session used for IMS services, the 3GPP Data Off Exempt Services are enforced in the IMS domain as specified TS 23.228 [5]. Policies configured in the PCF need to ensure that IMS services are allowed when the 3GPP Data Off status of the UE is set to "activated", e.g. by treating any service within a well-known IMS DNN as 3GPP PS Data Off Exempt Services.

When the PCF is informed about the activation of 3GPP PS Data Off, it shall update the PCC rules in such a way that for 3GPP access only packets for services belonging to the list(s) of 3GPP PS Data Off Exempt Services are forwarded while all other packets are discarded. Packets sent over non-3GPP access are not affected, and in the case of MA PDU Session, this is ensured by the MA PDU Session Control policy, e.g. for packets not belonging to the 3GPP Data Off Exempt Services, PCF provides PCC rule containing Steering Mode "Active-Standby" with active access as non-3GPP access and no standby access for downlink and uplink direction.

NOTE 3: For non MA PDU Sessions, in order for the SMF/UPF to prevent the services that do not belong to the list(s) of 3GPP PS Data Off Exempted Services, if the services are controlled by dynamic PCC rules, the PCF could modify the PCC rules by setting the gate status to "closed" for downlink and optionally uplink direction in all active dynamic PCC rules or remove those dynamic PCC rules. If the services are controlled by predefined PCC rules, the PCF can deactivate those predefined PCC rules. PCC rule with wild-carded service data flow filters can be among the PCC rules that are modified, removed or deactivated in that manner. In this case, it can be necessary that the PCF at the same time installs or activates PCC rules for data-off exempt services.

NOTE 4: For example, for non MA PDU Sessions, four PCC rules (A, B, C, D) are active for a PDU Session with PCC rule A representing a 3GPP PS Data Off Exempt Service. When 3GPP PS Data Off is activated, the PCF could either modify PCC rules B, C and D if they are dynamic PCC rules by closing the gate in downlink and optionally uplink direction or remove/deactivate PCC rules B, C and D if they are predefined PCC rules. PCC rule A does not need to be changed as it represents 3GPP PS Data Off Exempt Service. Assuming that PCC rule B contained wild-carded service data flow filters which has enabled some 3GPP PS Data Off Exempt Service is removed or deactivated, an additional PCC rule E can be installed or activated as well to enable downlink and optionally uplink traffic for that 3GPP PS Data Off Exempt Service.

NOTE 5: The network configuration can ensure that at least one PCC Rule is activated for the PDU Session when Data Off is activated in order to avoid deletion of an existing PDU Session or in order not to fail a PDU Session establishment.

When the PCF receives service information from the AF, in addition to what is specified in clause 6.2.1, PCF shall check if the requested service information belongs to the 3GPP PS Data Off Exempt Services. If the requested service belongs to 3GPP PS Data Off Exempt Services or if the service traffic can be sent over non-3GPP access, PCF shall continue as specified in clause 6.2.1. If the requested service doesn’t belong to the 3GPP PS Data Off Exempt Services and the PDU Session is established only over 3GPP access, PCF shall reject the service request.

When the PCF is informed about the deactivation of 3GPP PS Data Off, it shall perform policy control decision as specified in clause 6.2.1 and perform PCC rule operations as specified in clause 6.3.2 to make sure that the services are allowed according to user’s subscription and operator policy (irrespective of whether they belong to the list(s) of 3GPP PS Data Off Exempt Services).

When PCF is not deployed, predefined PCC rules, can be configured in the SMF, on a per DNN basis, to ensure the following:

– when the SMF is informed about activation of 3GPP PS Data Off, the SMF shall update the predefined PCC rule in a way that for 3GPP access only downlink and optionally uplink packets for services belonging to the list(s) of 3GPP PS Data Off Exempt Services are forwarded while all other downlink and uplink packets are discarded. Packets sent over non-3GPP access are not affected, and in the case of MA PDU Session, this is ensured by the MA PDU Session Control policy, e.g. for packets not belonging to the 3GPP Data Off Exempt Services, the SMF applies predefined PCC rule containing Steering Mode "Active-Standby" with active access as non-3GPP access and no standby access for downlink and uplink direction; and

– When SMF is informed about deactivation of 3GPP PS Data Off, the SMF ensures in UPF downlink and uplink packets are forwarded according to the operator policy for the subscriber.

NOTE 6: For example, for non MA PDU Sessions the SMF can be configured with two sets of predefined PCC rules: one set for UE 3GPP PS Data Off status "inactive" and another set for UE 3GPP PS Data Off status "active". The set of predefined PCC rules for UE 3GPP PS Data Off status "active" can be equivalent to the set of predefined PCC rules for UE with 3GPP PS Data Off status "inactive" with the following two differences: All services belonging to the list(s) of 3GPP PS Data Off Exempt Services can be represented by PCC rule(s) which allows the traffic to pass while in all other PCC rules (not belonging to the list(s) of 3GPP PS Data Off Exempt Services) the gate status can be "closed" for downlink and optionally uplink direction. When the SMF is informed about the change of UE 3GPP PS Data Off status, it can replace the currently active set of predefined PCC rules with the other set of predefined PCC rules.

When the UE 3GPP PS Data Off status is "active" and a handover from one access-system to another occurs, the PCF or the SMF when PCF is not deployed performs the above operations so that the downlink and optionally uplink traffic for services not belonging to the list(s) of 3GPP PS Data Off Exempt Services is only prevented via the 3GPP access.

6.1.3.17 Policy decisions based on spending limits

Policy decisions based on spending limits is a function that allows PCF taking actions related to the status of policy counters that are maintained in the CHF.

The PCF uses the CHF selection mechanism defined in TS 23.501 [2] to select the CHF that provides policy counters for spending limits for a PDU Session. The PCF shall also provide the selected CHF address(es) to the SMF in the PDU Session related policy information.

The identifiers of the policy counters that are relevant for a policy decision in the PCF may be stored in the PCF or possibly in UDR. The PCF is configured with the actions associated with the policy counter status that is received from CHF.

The PCF may retrieve the status of policy counters in the CHF using the Initial or Intermediate Spending Limit Report Retrieval Procedure. The CHF provides the current status of the policy counters to the PCF. The CHF may in addition provide one or more pending statuses for a policy counter together with the time they have to be applied. The PCF shall immediately apply the current status of a policy counter. A pending status of a policy counter shall autonomously become the current status of a policy counter at the PCF when the indicated corresponding time is reached. Subsequently provided information for pending statuses of a policy counter shall overwrite the previously received information.

The PCF may subscribe to spending limit reporting for policy counters from the CHF using the Initial or Intermediate Spending Limit Report Retrieval procedure. If spending limit reporting for a policy counter is enabled, the CHF shall notify the PCF of changes in the status of this policy counter (e.g. daily spending limit of $2 reached) and optionally pending statuses of this policy counter together with their activation time (e.g. due to a billing period that will expire at midnight). The PCF may cancel spending limit reporting for specific policy counter(s) using the Intermediate Spending Limit Report Retrieval procedure, or for all policy counter(s) using the Final Spending Limit Report Retrieval procedure.

The PCF uses the status of each relevant policy counter, and optional pending policy counter statuses if known, as input to its policy decision to apply operator defined actions, e.g. change the QoS (e.g. downgrade Session-AMBR), modify the PCC Rules to apply gating or change charging conditions.

The CHF may report to the PCF the removal of the subscriber from the CHF system, and the PCF shall remove all the policy counters of the subscriber accordingly.

6.1.3.18 Event reporting from the PCF

The AF may subscribe/unsubscribe to notifications of events from the PCF for the PDU Session to which the AF session is bound. The AF can either subscribe/unsubscribe directly at the PCF or indirectly via an NEF or a TSCTSF.

The PCF for the UE may subscribe/unsubscribe to notifications of events from the PCF for the PDU Session of a UE. Other NFs may subscribe/unsubscribe to notifications of events from the PCF for a PDU Session or for a UE.

The events that can be subscribed by the AF and by other NFs are listed in Table 6.1.3.18-1.

Table 6.1.3.18-1: Events relevant for reporting from the PCF

Event	Description	NF that can subscribe for reporting	Availability for Rx PDU Session (NOTE 2)	Availability for N5 per PDU Session	Availability for Bulk Subscription (NOTE 1)	Availability for N43 per SUPI, DNN, S-NSSAI	Availability for N5 per UE (NOTE 6)
PLMN Identifier Notification (NOTE 5)	The PLMN identifier or SNPN identifier where the UE is currently located.	AF	Yes	Yes	Yes	No	No
Change of Access Type	The Access Type and, if applicable, the RAT Type of the PDU Session has changed.	AF	Yes	Yes	Yes	No	No
EPS fallback	EPS fallback is initiated	AF	Yes	Yes	No	No	No
Signalling path status	The status of the resources related to the signalling traffic of the AF session.	AF	Yes	Yes	No	No	No
Access Network Charging Correlation Information	The Access Network Charging Correlation Information of the resources allocated for the AF session.	AF	Yes	Yes	No	No	No
Access Network Information Notification	The user location and/or timezone when the PDU Session has changed in relation to the AF session.	AF	Yes	Yes	No	No	No
Reporting Usage for Sponsored Data Connectivity	The usage threshold provided by the AF has been reached; or the AF session is terminated.	AF	Yes	Yes	No	No	No
Service Data Flow deactivation	The resources related to the AF session are released.	AF	Yes	Yes	No	No	No
Resource allocation outcome	The outcome of the resource allocation related to the AF session.	AF	Yes	Yes	No	No	No
QoS targets can no longer (or can again) be fulfilled	The QoS targets can no longer (or can again) be fulfilled by the network for (a part of) the AF session.	AF	No	Yes	No	No	No
QoS Monitoring parameters	The QoS Monitoring parameter(s) (e.g. UL packet delay, DL packet delay or round trip packet delay) are reported to the AF according to the QoS Monitoring reports received from the SMF.	AF	No	Yes	No	No	No
Out of credit	Credit is no longer available.	AF	Yes	Yes	No	No	No
Reallocation of credit	Credit has been reallocated after the former Out of credit indication.	AF	Yes	Yes	No	No	No
5GS Bridge information Notification (NOTE 3)	5GS Bridge information that has been received by PCF from SMF.	TSN AF, TSCTSF	No	Yes	No	No	No
Notification on outcome of service area coverage change	The outcome of the request of service area coverage change.	AF	No	No	Yes	No	Yes
Notification on outcome of UE Policies delivery	The outcome of the request for UE policies delivery due to service specific parameter provisioning procedure.	AF	No	No	No	No	No
Start of application traffic detection and Stop of application traffic detection	The start or the stop of application traffic has been detected.	PCF	No	No	No	Yes (NOTE 4)	No
Satellite backhaul category change	The backhaul has changed between different satellite backhaul categories (i.e. GEO, MEO, LEO, OTHERSAT), or the backhaul has changed between satellite backhaul and non-satellite backhaul.	AF	No	Yes	Yes	No	No
Change of PDUID	The PDUID assigned to a UE has changed.	5G DDNMF	No	No	No	No	Yes
SM Policy Association established or terminated	The establishment or termination of a SM Policy Association is reported	PCF	No	No	No	Yes (NOTE 7)	No
NOTE 1: Additional parameters for the subscription as well as reporting related to these events are described in TS 23.502 [3]. NOTE 2: Applicability of Rx is described in Annex C. NOTE 3: 5GS Bridge information is described in clause 6.1.3.5. NOTE 4: Bulk subscription is implicit. NOTE 1 does not apply. NOTE 5: For a PDU Session established over a SNPN, the combination of the PLMN id and the NID identifies the SNPN. NOTE 6: This column contains also UE context related events that are reported to other consumers such as 5G DDNMF via other reference points than N5. The Conditions for reporting column indicates the respective consumer. NOTE 7: This PCF for the UE subscribes to this Event via AMF and SMF.

If an AF requests the PCF to report the PLMN identifier where the UE is currently located, then the PCF shall provide the PLMN identifier or the SNPN identifier to the AF if available. Otherwise, the PCF shall provision the corresponding PCC rules, and the Policy Control Request Trigger to report PLMN change to the SMF. The PCF shall, upon receiving the PLMN identifier or the SNPN identifier from the SMF forward this information to the AF, including the PLMN Id and if available the NID.

If an AF requests the PCF to report on the change of Access Type, the PCF shall provide the corresponding Policy Control Request Trigger to the SMF to enable the report of the Change in Access Type to the PCF. The PCF shall, upon reception of information about the Access Type the user is currently using and upon indication of change of Access Type, notify the AF on changes of the Access Type and forward the information received from the SMF to the AF. The change of the RAT Type shall also be reported to the AF, even if the Access Type is unchanged. For MA PDU Session the Access Type information may include two Access Type information that the user is currently using.

If an AF requests the PCF to report on the signalling path status, for the AF session, the PCF shall, upon indication of removal of PCC Rules identifying signalling traffic from the SMF report it to the AF.

If an AF requests the PCF to report Access Network Charging Correlation Information, the PCF shall provide to the AF the Access Network Charging Correlation Information, which allows to identify the usage reports that include measurements for the Service Data Flow(s), once the Access Network Charging Correlation Information is known at the PCF.

If an AF requests the PCF to report Access Network Information (i.e. the User Location Report and/or the UE Timezone Report) at AF session establishment, modification or termination, the PCF shall set the Access Network Information report parameters in the corresponding PCC rule(s) and provision them together with the corresponding Policy Control Request Trigger to the SMF. For those PCC rule(s) based on preliminary service information the PCF may assign the 5QI and ARP of the QoS Flow associated with the default QoS rule to avoid signalling to the UE.

NOTE 1: The PCF can also use the dynamic or pre-defined PCC Rules related to the IMS signalling to request Access Network Information reporting. This can be used to support e.g., regulatory requirements for SMS over IP, where the IMS network (i.e. P‑CSCF) needs to retrieve the user location and/or UE Time Zone information. Note that due to regulatory requirements, the Access Network Information can be requested for SMS over IP, impacting a large number of PDU Sessions, that can lead to significant increase in signalling load when the Access Network Information is requested from AMF.

The PCF shall, upon receiving an Access Network Information report corresponding to the AF session from the SMF, forward the Access Network Information as requested by the AF (if the SMF only reported the serving PLMN identifier or the SNPN identifier to the PCF, as described in clause 6.1.3.5, the PCF shall forward it to the AF). For AF session termination the communication between the AF and the PCF shall be kept alive until the PCF report is received.

If an AF requests the PCF to report the Usage for Sponsored Data Connectivity, the PCF shall provision the corresponding PCC rules, and the Policy Control Request Trigger to the SMF. If the usage threshold provided by the AF has been reached or the AF session is terminated, the PCF forwards such information to the AF.

If an AF requests the PCF to report the Service Data Flow deactivation, the PCF shall report the release of resources corresponding to the AF session. The PCF shall, upon being notified of the removal of PCC Rules corresponding to the AF session from the SMF, forward this information to the AF. The PCF shall also forward, if available, the reason why the resources are released, the user location information and the UE Timezone.

If an AF requests the PCF to report the Resource allocation outcome, the PCF shall report the outcome of the resource allocation of the Service Data Flow(s) related to the AF session. The AF may request to be notified about successful or failed resource allocation. In this case, the PCF shall instruct the SMF to report the successful resource allocation trigger (see clause 6.1.3.5). If the SMF has notified the PCF that the resource allocation of a Service Data Flow is successful and the currently fulfilled QoS matches an Alternative QoS parameter set (as described in clause 6.2.2.1), the PCF shall also provide to the AF the QoS Reference parameter or the Requested Alternative QoS Parameter Set which corresponds to the Alternative QoS parameter set referenced by the SMF.

If an AF requests the PCF to report when the QoS targets can no longer (or can again) be fulfilled for a particular media flow, the PCF shall set the QNC indication in the corresponding PCC rule(s) that includes a GBR or delay critical GBR 5QI value and provision them together with the corresponding Policy Control Request Trigger to the SMF. At the time, the SMF notifies that GFBR can no longer (or can again) be guaranteed for a QoS Flow to which those PCC Rule(s) are bound, the PCF shall report to the AF the affected media flow and provides the indication that QoS targets can no longer (or can again) be fulfilled. If additional information is received with the notification from SMF (see clause 5.7.2.4 of TS 23.501 [2]), the PCF shall also provide to the AF the QoS Reference parameter or the Requested Alternative QoS Parameter Set which corresponds to the Alternative QoS parameter set referenced by the SMF. If the SMF has indicated that the lowest priority Alternative QoS parameter set cannot be fulfilled, the PCF shall indicate to the AF that the lowest priority QoS Reference or the lowest priority set of Requested Alternative QoS Parameters of the Alternative Service Requirements cannot be fulfilled.

If the AF subscribes to be notified of the QoS Monitoring reports, the PCF decides about the path for the QoS Monitoring reports and sets the QoS Monitoring for URLLC Policy Control Request Trigger accordingly, as described in clause 6.1.3.21. The PCF shall further send the QoS Monitoring reports it receives from the SMF to the AF, unless the AF has provided an indication of direct event notification (i.e. in this case, the AF will receive the QoS Monitoring reports directly from the UPF).

NOTE 2: This event can only be subscribed as part of an AF session with required QoS (described in clause 6.1.3.22).

If an AF requests the PCF to report on the Out of credit event for the associated service data flow(s), the PCF shall inform the AF (when it gets informed by the SMF) that credit is no longer available for the services data flow(s) related to the AF session together with the applied termination action.

If an AF requests the PCF to report on the Reallocation of credit event for the associated service data flow(s), the PCF shall inform the AF (when it gets informed by the SMF) that credit has been reallocated after credit was no longer available and the termination action was applied for the service data flow(s) related to the AF session.

The PCF can arm the trigger of 5GS Bridge information available to SMF based on local policy (i.e. without an AF request) or based on subscription request from TSCTSF. The PCF shall, upon reception of the 5GS Bridge information (refer to clause 6.1.3.23) from the SMF, forward this information to the TSN AF or the TSCTSF. When the PCF has received the User plane node Management Information Container or Port Management Information Container and related port number from SMF, the PCF also provides User plane node Management Information Container or Port Management Information Container and related port number to the TSN AF or TSCTSF. When SMF has reported the 5GS Bridge information and no AF session exists, the PCF forward this information to a pre-configured TSN AF, or to a pre-configured TSCTSF or a TSCTSF discovered and selected via NRF. In the case of private IPv4 address being used for IP type PDU Session, the PCF shall additionally report DNN and S-NSSAI of the PDU Session to TSCTSF.

If the AF requests the PCF to report on the outcome of the service area coverage change, the PCF reports the outcome of the service area coverage change to the AF and notifies the current service area coverage to the AF. The outcome is the result of the execution of the request of service coverage change at the PCF; the outcome is successful if the request was executed, and includes the current service area coverage that may be the same or different from the service area coverage provided by the AF. The subscription may also be implicit. In this case there may be bulk subscription, either for an Internal-Group-Id or for any UE. In order to prevent massive notifications to the AF, the request for any UE is associated to a specific Application Identifier or DNN, S-NSSAI. For bulk subscription, when the AF request includes an expiration time, the PCF stops reporting to the AF when the expiration time is reached.

If the AF requests the PCF to report on the outcome of the UE Policies delivery due to service specific parameter provisioning procedure targeting a single UE, the PCF reports the outcome of the related UE Policies provisioning procedure for the related traffic descriptor for the UE. The outcome of the UE Policies provisioning procedure includes the success, the failure with an appropriate cause or the interim status report such as UE is temporarily unreachable. (See clauses 4.15.6.7 and 5.2.5.7 of TS 23.502 [3])

A request to report Start of application traffic detection and Stop of application traffic detection triggers the reporting when the PCF receives start of application traffic detection event or stop of application traffic detection event from SMF. The reception of a subscription to this event triggers the setting of the corresponding Policy Control Request Trigger to SMF, if not already subscribed.

If an AF requests the PCF to report on the change between different satellite backhaul categories (i.e. GEO, MEO, LEO, OTHERSAT) or the change between satellite backhaul and non-satellite backhaul, the PCF shall provide the corresponding Policy Control Request Trigger to the SMF to enable the report of satellite backhaul category change (see clause 6.1.3.5) to the PCF. The PCF shall, upon reception of information about the change between satellite backhaul categories or change between satellite backhaul and non-satellite backhaul, notify the AF on the satellite backhaul category change event was met and forward the current satellite backhaul category information received from the SMF to the AF, or indicate that a satellite backhaul is no longer used.

If 5G DDNMF requests the PCF to report on the Change of PDUID, the PCF shall notify whenever a new PDUID is allocated. Further details on how the 5G DDNMF retrieves and subscribes to notifications on Change of PDUID are defined in TS 23.304 [34].

A request to report SM Policy Association established or terminated triggers the reporting when the PCF receives the request for notification on the SM Policy Association from SMF. The PCF notifies on the EventID "SM Policy Association established/terminated", includes the PCF binding information of the PCF for the PDU Session of the UE, as described in clause 6.1.1.2.2.

6.1.3.19 Mission Critical Services support

Mission Critical Services are defined in TS 23.501 [2], TS 23.502 [3] and in TS 23.280 [23], utilising the architecture defined for 5GS.

Subscription data for MCX services are provided to PCF through the N36/Nudr. To support MCX services, the PCF shall subscribe to changes in the MCX services subscription data for Priority PDU connectivity service. Dynamic invocation for MCX services provided from an AF using the Priority indicator over N5/Npcf takes precedence over the MCX services subscription.

For MCX services the session management relate policy control functionality of the Policy and Charging control framework for the 5G system is as defined in clause 6.1.3.11 for Multimedia Priority Service.

6.1.3.20 Access Traffic Steering, Switching and Splitting

As specified in TS 23.501 [2], the Access Traffic Steering, Switching and Splitting (ATSSS) feature is an optional feature that may be supported by the UE and the 5GC network.

The ATSSS feature enables a multi-access PDU Connectivity Service, which can exchange PDUs between the UE and a data network by simultaneously using one 3GPP access network and one non-3GPP access network (both connected to 5GC) when both accesses are allowed for the same S-NSSAI. The multi-access PDU Connectivity Service also supports the exchange of PDUs between the UE and a data network by simultaneously using one 3GPP access network in EPC and one non-3GPP access network in 5GC, as described in TS 23.501 [2]. This enables a scenario where a MA PDU Session can simultaneously be associated with user-plane resources on 3GPP access network connected to 5GC or EPC and non-3GPP access connected to 5GC.

The PCF is informed of the ATSSS capabilities of a MA PDU Session by the SMF, as defined in clause 5.32.2 of TS 23.501 [2]. The ATSSS capabilities are both the Steering Mode and the Steering Functionality.

The PCF control of Access Traffic Steering, Switching and Splitting for a detected service data flow (SDF) is enabled by including Multi-Access PDU (MA PDU) Session Control information in the PCC rule. This allows the PCF to control:

– The Steering Mode that is used to steer/switch/split the detected SDF. The available Steering Modes are defined in TS 23.501 [2].

– The Steering Functionality that is used for the detected SDF, e.g. the MPTCP functionality or the ATSSS-LL functionality defined in TS 23.501 [2].

– The Steering Mode Indicator authorized for the detected SDF.

– The Threshold values for RTT and Packet Loss Rate authorized for the detected SDF.

– The Charging information depending on what Access Type is used for a detected SDF.

– The Usage Monitoring information depending on what Access Type is used for a detected SDF.

The rest of the information in the PCC Rule apply to the SDF as such and are not dependent on what Access Type is used for a packet.

The MA PDU Session Control information in the PCC rules is used by the SMF in order to create applicable N4 rules for the UPF and ATSSS rules for the UE, as described in TS 23.501 [2]. The ATSSS rules are sent to UE via NAS when the MA PDU Session is created or updated by the SMF/PCF, as described in TS 23.501 [2] and TS 23.502 [3].

When MA PDU Session Control Information is provided to the SMF within a PCC Rule, the (H-)PCF provides both the Service Data Flow templates to identify a Service Data Flow in the UPF and if the Service Data Flow template includes an application identifier, then the corresponding Application descriptors to identify the application traffic in the UE is also included.

The (H-) PCF may use the OSid stored in the UDR as DataSet "Policy Data" and Data Subset "UE context policy control data" to determine the OSAppId supported by the OSid. The (H-)PCF may also provide multiple Application descriptors to identify application traffic in the UE, this is determined by the (H-)PCF local policies that indicates e.g. the operating system supported by the UE. If no OSid is available in the UDR, the (H-)PCF may use the PEI to determine the OSid supported by the UE.

NOTE 1: If the (H-)PCF does not take into account the received PEI and/or OSId then the (H-)PCF can send PCC rules containing application traffic descriptors associated to multiple operating systems.

The Traffic Descriptor in the ATSSS rule is generated by the SMF from the SDF template of the PCC rule. If the SDF template contains SDF filters, the SMF uses the UL SDF filters for the generation of the IP descriptors or Non-IP descriptors, respectively. If the SDF template contains an application identifier, the SMF includes the Application descriptors received from the PCF as part of the MA PDU Session information in the PCC Rule within the Traffic Descriptors in the ATSSS rule.

For the Load-Balancing steering mode with fixed split percentages (i.e. without the Autonomous load-balance indicator or UE-assistance indicator), the PCF may provide one or more threshold values together with the split percentages. For the Priority-based steering mode, the PCF may provide one or more threshold values together with the priority of the accesses. One threshold value for the Round Trip Time (RTT) and/or one threshold value for the Packet Loss Rate (PLR) may be included in a PCC Rule. The threshold values are not dependent on what Access Type is used for a packet, i.e. a given threshold value is applicable to both accesses. The threshold values are applied by the UE and UPF as described in TS 23.501 [2].

NOTE 2: The Round Trip Time (RTT) threshold value can be determined based on the PDB of the 5QI authorized for the SDF, and the Packet Loss Rate (PLR) threshold value can be determined based on the PER of the 5QI authorized for the SDF.

The MA PDU Session Control information in a PCC rule may contain only one of the following Steering Mode Indicators:

– Autonomous load-balance indicator: This indicator may be included only when the Steering Mode is Load-Balancing and indicates whether autonomous load-balance operation is allowed. Further details are specified in clause 5.32.8 of TS 23.501 [2].

– UE-assistance indicator: It indicates that the UE can decide how to distribute the UL traffic based on its internal state (e.g. battery level), and that the UE can request from UPF to apply the same distribution for the DL traffic. Further details are specified in clause 5.32.8 of TS 23.501 [2].

The PCF may also provide URSP rules to the UE for instructing the UE to establish a MA PDU Session, as described in clause 6.6.2.

The PCF control of PDU Session level Usage Monitoring depending on what access type is used to carry the traffic is enabled by providing Usage Monitoring control related information per access in the PDU Session related policy control information (as described in clause 6.4).

If the MA PDU Session is capable of MPTCP and ATSSS-LL with any Steering Mode in the downlink and MPTCP and ATSSS-LL with Active-Standby in the uplink, then the PCF shall provide a PCC Rule for non-MPTCP traffic. This PCC Rule contains a "match all" SDF template, the lowest precedence, the Steering Functionality set to "ATSSS-LL" and the Steering Mode set to "Active-Standby" for the uplink direction, and the Steering Functionality set to "ATSSS-LL" and the Steering Mode set to any supported steering mode for the downlink direction.

If the MA PDU Session is capable of MPTCP with any Steering Mode in the downlink, ATSSS-LL with any steering mode except Smallest Delay steering mode in the downlink, and MPTCP and ATSSS-LL with Active-Standby in the uplink, then the PCF shall provide a PCC Rule for non-MPTCP traffic. This PCC Rule contains a "match all" SDF template, the lowest precedence, the Steering Functionality set to "ATSSS-LL" and the Steering Mode set to "Active-Standby" for the uplink direction, and the Steering Functionality set to "ATSSS-LL" and the Steering Mode set to any supported steering mode except Smallest Delay steering mode for the downlink direction.

If the MA PDU Session is capable of MPTCP and ATSSS-LL with Active-Standby in the uplink and downlink, then the PCF shall provide a PCC Rule for non-MPTCP traffic. This PCC Rule contains a "match all" SDF template, the lowest precedence, the Steering Functionality set to "ATSSS-LL" and the Steering Mode set to "Active-Standby" for the uplink direction and the downlink direction.

If the MA PDU Session is capable of MPTCP and ATSSS-LL with any Steering Mode in the uplink and downlink, then the PCF shall provide a PCC Rule for non-MPTCP traffic. This PCC Rule may contain a "match all" SDF template, the lowest precedence, the Steering Functionality set to "ATSSS-LL" and the Steering Mode set to any supported steering mode for the uplink direction and for the downlink direction.

These PCC Rules are used by the SMF to generate an ATSSS rule for the UE and an N4 rule for the UPF to route the non-MPTCP traffic of the MA PDU Session in the uplink and downlink direction respectively.

NOTE 3: The PCF can also use the ATSSS capability of the MA PDU Session to provide PCC Rules containing SDF template for some specific non-MPTCP traffic other than the PCC Rule containing a "match all" SDF template. This allows the operator to apply different policies e.g. charging key to non-MPTCP traffic other than the non-MPTCP traffic matching the "match all" PCC Rule.

6.1.3.21 QoS Monitoring to assist URLLC Service

The QoS Monitoring for URLLC refers to the real time packet delay measurement between the UE and the UPF for a QoS Flow corresponding to an URLLC service.

The PCF generates the authorized QoS Monitoring policy for the service data flow based on the QoS Monitoring request if received from the AF (as specified in TS 23.502 [3]). The QoS Monitoring policy includes the following:

– QoS parameters to be measured (DL, UL or round trip packet delay);

– frequency of reporting (event triggered, periodic, or when the PDU Session is released):

– if the reporting frequency is event triggered:

– the corresponding reporting threshold to each QoS parameter;

– minimum waiting time between subsequent reports;

– the reporting period;

– optionally, Target of reporting (i.e. the NEF, the AF or the Local NEF, indicated as Notification Target Address + Notification Correlation ID);

– optionally, an indication of direct event notification (to request the UPF to directly send QoS Monitoring reports to the Local NEF or the AF as described in clause 6.4 of TS 23.548 [33]).

If the AF did not provide an indication of direct event notification in the request and the PCF decides that it does not want to receive the QoS Monitoring reports, the PCF forwards the Target of reporting parameter in the QoS Monitoring policy and the SMF shall then send the QoS Monitoring reports directly to the NF indicated by the Target of reporting parameter. If the PCF decides that it wants to receive the QoS Monitoring reports, the PCF shall not forward the Target of reporting parameter in the QoS Monitoring policy and instead subscribe to receive QoS Monitoring reports from SMF by setting the QoS Monitoring for URLLC Policy Control Request Trigger.

If the AF provided an indication of direct event notification in the request, the PCF forwards the Target of reporting parameter in the QoS Monitoring policy and sets the indication of direct event notification to indicate that QoS Monitoring reports have to be sent by the UPF directly to the NF indicated by the Target of reporting. The PCF may also subscribe to receive QoS Monitoring reports by setting the QoS Monitoring for URLLC Policy Control Request Trigger. In that case, the UPF is asked to duplicate the reports and the QoS Monitoring reports will be sent by the UPF to both, the NF indicated by the Target of reporting and to the SMF (which then forwards the report to the PCF).

NOTE: If there are multiple QoS rules containing a QoS monitoring policy, the PCF will receive the QoS Monitoring reports for all of them when the QoS Monitoring for URLLC Policy Control Request Trigger is set.

The PCF includes the authorized QoS Monitoring policy in the PCC rule and provides it to the SMF. The SMF determines the configuration for the UL/DL packet delay measurement between UE and PSA UPF from the QoS Monitoring policy in the PCC rule. The SMF indicates the RAN and the UPF to perform the measurement of the QoS parameters as defined in clause 5.33.3 of TS 23.501 [2] and in clause 4.3.3.2 of TS 23.502 [3].

6.1.3.22 AF session with required QoS

The AF may request that a data session to a UE is set up with a specific QoS (e.g. low latency or jitter) and priority handling. The AF can request the network to provide QoS for the AF session based on the service requirements with the help of a QoS Reference parameter that refers to pre-defined QoS information. Instead of the QoS Reference, the AF may provide individual QoS parameters associated to the Flow Description.

a) When the AF provides only a QoS Reference to determine the QoS parameters but no individual QoS parameters:

– When the PCF authorizes the service information from the AF, it derives the QoS parameters of the PCC rule based on the service information and the indicated QoS Reference.

NOTE 1: A SLA has to be in place between the operator and the ASP defining the possible QoS levels and their charging rates. For each of the possible pre-defined QoS information sets, the PCF needs to be configured with the corresponding QoS parameters and their values as well as the appropriate Charging key (or receive this information from the UDR).

– The AF may change the QoS by providing a different QoS Reference while the AF session is ongoing. If this happens, the PCF shall update the related QoS parameter sets in the PCC rule accordingly.

b) When the AF provides individual QoS parameters instead of a QoS Reference:

– The AF provides one or more of the following individual QoS parameters, i.e. Requested Priority, Maximum Burst Size, Requested 5GS Delay, Requested Maximum Bitrate, Requested Guaranteed Bitrate and Requested Packet Error Rate.

NOTE 2: Different combinations of individual QoS parameters with specific parameter names exist and they are described in TS 23.501 [2] (for Time Sensitive Communication), in clause 6.1.3.23 (for integration with Time Sensitive Networking) and in TS 29.514 [36].

– If the AF request for QoS is sent via the TSCTSF and the request contains a Requested 5GS Delay, the TSCTSF determines a Requested PDB considering the UE-DS-TT Residence Time (either provided by the PCF or pre-configured).

– When the PCF authorizes the service information from the AF, it derives the QoS parameters of the PCC rule based on the service information and the individual QoS parameters received from the AF and TSCTSF. The PCF should select a standardized, pre-configured or existing dynamically assigned 5QI that matches the individual QoS parameters. If no 5QI exists that matches the individual QoS parameters, the PCF generates a new dynamically assigned 5QI based on the individual QoS parameters.

– The AF may change the QoS by providing different values for the individual QoS parameters while the AF session is ongoing. If this happens, the PCF shall update the related QoS parameter sets in the PCC rule accordingly.

– The PCF may reject the individual QoS parameters received from the AF based on operator policy or impossibility to support the requested values of the individual QoS parameters. If this happens, the PCF may provide in the response to the AF one or more combinations of individual QoS parameters that can be supported.

In addition to the QoS Reference or the individual QoS parameters described above, the AF may provide further parameters associated with the Flow Description, e.g. parameters that describe traffic characteristics as described in clause 6.1.3.23 or 6.1.3.23a.

The PCF generates a PCC Rule with service data flow filter (including IP Packet Filter set as in clause 5.7.6.2 of TS 23.501 [2]) or Ethernet Packet Filter set as in clause 5.7.6.3 of TS 23.501 [2]) derived from the Flow Descriptions provided by the AF, the derived PCC rule QoS parameters such a 5QI, ARP, GBR and MBR (see clause 6.3.1 for all possible PCC rule QoS parameters) and the associated TSC Assistance Container as received from the TSN AF or TSCTSF.

For TSC QoS, the PCF derives the 5QI value as defined in clause 5.27.3 of TS 23.501 [2], the PCF derives the MBR using the Requested Maximum Bitrate provided by the AF and sets the GBR equal to the MBR unless the AF provides a Requested Guaranteed Bitrate, in which case the MBR and GBR are set separately.

If the PCF gets informed about Policy Control Request Triggers relevant for the AF session, the PCF shall inform the AF about it as defined in clause 6.1.3.18.

If an AF session can adjust to different QoS parameter combinations, the AF may provide Alternative Service Requirements in a prioritized order (indicating the preference of the QoS requirements with which the service can operate) in addition to the QoS Reference or individual QoS parameters. Alternative Service Requirements contain:

– When the AF requests the network to provide QoS with a QoS Reference, one or more QoS Reference parameters in a prioritized order.

– When the AF requests the network to provide QoS with individual QoS parameters, one or more Requested Alternative QoS Parameter Set(s) in a prioritized order. Each Requested Alternative QoS Parameter Set is comprised of the following individual parameters: Requested 5GS Delay, Requested Guaranteed Flow Bitrate and Requested Packet Error Rate.

If the AF request is sent via the TSCTSF, the TSCTSF determines a Requested PDB considering the Requested 5GS Delay and the UE-DS-TT Residence Time.

An AF that provides Alternative Service Requirements shall also subscribe to receive notifications from the PCF for successful resource allocation and when the QoS targets can no longer (or can again) be fulfilled as described in clause 6.1.3.18.

When the PCF authorizes the service information from the AF and generates a PCC rule, it shall also derive Alternative QoS Parameter Sets for this PCC rule based on the QoS Reference parameters or the Requested Alternative QoS Parameter Sets in the Alternative Service Requirements. If the AF provided Requested Alternative QoS Parameter Sets in the request, the PCF may reject any of the Requested Alternative QoS Parameter Sets it has received based on operator policy or impossibility to support the requested values of the individual parameters. If this happens, the PCF may provide in the response to the AF one or more Requested Alternative QoS Parameters Sets that can be supported.

The PCF shall enable QoS Notification Control and include the derived Alternative QoS parameter sets (in the same prioritized order indicated by the AF) in the PCC rule sent to the SMF. When the PCF notifies the AF that QoS targets can no longer be fulfilled, the PCF shall include the QoS Reference parameter or the set of Requested Alternative QoS Parameters corresponding to the Alternative QoS parameter set referenced by the SMF, or an indication that the lowest priority QoS Reference or the lowest priority set of Requested Alternative QoS Parameters of the Alternative Service Requirements cannot be fulfilled (as described in clause 6.1.3.18).

NOTE 3: The AF behaviour is out of the scope of this TS but can include adaptation to the change of QoS (e.g. rate adaptation) as well as application layer signalling with the UE.

The AF may change the Alternative Service Requirements while the AF session is ongoing. If this happens, the PCF shall update the Alternative QoS parameter sets in the PCC rule accordingly.

The AF may indicate to the PCF that the UE does not need to be informed about changes related to Alternative QoS Profiles. With this indication received from the AF, the PCF decides whether to disable the notifications to the UE when changes related to the Alternative QoS Profiles occur and sets the Disable UE notifications at changes related to Alternative QoS Profiles parameter in the PCC rule accordingly.

6.1.3.23 Support of integration with Time Sensitive Networking

Time Sensitive Networking (TSN) support is defined in TS 23.501 [2], where the 5GS represents logical TSN bridge(s) based on the defined granularity model. The TSN AF and PCF interact to perform QoS mapping as described in clause 5.28.4 of TS 23.501 [2].

The PCF provides the following parameters to the TSN AF:

– 5GS user-plane Node information:

– 5GS Bridge ID;

– UE-DS-TT Residence time;

– port number of the Ethernet port of DS-TT;

– MAC address of the Ethernet port of DS-TT (i.e. DS-TT port MAC address).

– Port Management Information Container and the related port number.

– User plane node Management Information Container.

The TSN AF may use this information to construct IEEE 802.1 managed objects, to interwork with IEEE 802.1 TSN networks, as described in TS 23.501 [2] and TS 23.502 [3].

The TSN AF may use the PTP Port state of NW-TT and DS-TT in the Port/User plane node Management Information Container to determine the Port Pairs that will be used for (g)PTP delivery. Based on this the TSN AF may request appropriate QoS treatment for the (g)PTP flows from PCF.

The TSN AF request related to TSN configuration or gPTP flow delay requirement is sent on the AF session associated with the DS-TT port MAC address. The TSN AF decides the TSN QoS information (i.e. priority, delay, maximum TSC Burst Size and Maximum Flow Bitrate) and TSC Assistance Container based on the received configuration information of 5GS Bridge from the CNC as defined in clause 5.28.2 of TS 23.501 [2], the bridge delay information at the TSN AF and the UE-DS-TT Residence time.

NOTE: TSC burst size can represent the maximum burst size of the TSN streams that have been aggregated.

The TSN AF provides the Flow Descriptions (including Ethernet Packet Filters), TSC Assistance Container (as described in clause 5.27.2.2 of TS 23.501 [2]), and the related QoS information to the PCF by setting up an AF session with required QoS as described in clause 6.1.3.22. In addition, the TSN AF may provide the following parameters to the PCF:

– Port Management Information Container and related Port number as applicable;

– User plane node Management Information Container.

The PCF assigns the ARP to a value preconfigured for TSN services.

6.1.3.23a Support of Time Sensitive Communication and Time Synchronization

Enablers for Time Sensitive Communication and Time Synchronization are defined in TS 23.501 [2] clause 5.27.

In the case of integration with IEEE TSN network, the TSN AF interacts with the PCF as described in clause 6.1.3.23.

When the PCF has the 5GS Bridge information for the PDU Session received from SMF and has a subscription for the 5GS Bridge information Notification from the TSCTSF or the PCF determines that the PDU Session is potentially impacted by (g)PTP based time synchronization service based on a local policy, if integration with IEEE TSN does not apply, the PCF provides the following parameters to the TSCTSF:

– 5GS user-plane Node information:

– 5GS Bridge ID;

– UE-DS-TT Residence time;

– port number of the DS-TT;

– MAC address of the Ethernet port of DS-TT (i.e. DS-TT port MAC address) (for Ethernet type PDU Session), or IP address of the UE (for IP type PDU Session, additionally DNN and S-NSSAI of IP type PDU Session in the case of private IPv4 address being used for the PDU Session);

– Port Management Information Container and the related port number;

– User plane node Management Information Container.

Upon reception of the above information, if the TSCTSF does not have a corresponding AF session, the TSCTSF shall create an AF session with the PCF.

The TSCTSF may receive a request from an AF that a data session to a UE is to be set up for Time Sensitive Communication with a specific QoS and parameters that describe the traffic characteristics. If so, the TSCTSF provides the Flow Descriptions, the TSC Assistance Container (as described in clause 5.27.2.3 of TS 23.501 [2]), and the related QoS information to the PCF by setting up an AF session with required QoS as described in clause 6.1.3.22. In addition, the TSCTSF may provide the following parameters to the PCF:

– Port Management Information Container and related Port number as applicable.

– User plane node Management Information Container.

The TSCTSF may use the PTP Port state of NW-TT and DS-TT in the Port/User plane node Management Information Container to determine the Port Pairs that will be used for (g)PTP delivery. Based on this the TSCTSF may request appropriate QoS treatment for the (g)PTP flows from PCF.

The AF may include the Capability for BAT adaptation or a BAT Window in the request (as described in clause 5.27.2.3 of TS 23.501 [2]).The PCF sends the BAT offset received from the SMF to the AF and the AF adjusts the burst sending time according to the indicated BAT offset.

6.1.3.24 Policy control for redundant PDU Sessions

As specified in clause 5.33.2.1 of TS 23.501 [2], in order to support highly reliable URLLC services, two redundant PDU Sessions over the 5G network may be established such that the 5GS sets up the user plane paths of the two redundant PDU Sessions to be disjoint. The Policy control for redundant PDU Session specifies that the PCF may request traffic redundancy for the PDU Session (e.g. when some of the allowed services require redundancy).

The PCF provides to the SMF the indication on whether the PDU Session is a redundant PDU Session or not based on operator policies. The SMF follows the procedure defined in TS 23.501 [2] to establish redundant PDU Sessions depending on the indication from the PCF.

6.1.3.25 User Plane Remote Provisioning of UE SNPN Credentials in Onboarding Network

User Plane Remote Provisioning of UE SNPN Credentials in Onboarding Network is specified in clause 5.30.2.10.4 of TS 23.501 [2].

User Plane Remote Provisioning of UE SNPN Credentials is provided through a DNN and S-NSSAI used for onboarding.

For a PDU Session with a DNN and S-NSSAI used for onboarding, the PCF may make authorization and policy decisions that restrict the use of the PDU Session, e.g. by restricting the traffic to/from Provisioning Server address(es) and DNS server address(es) only.

For a PDU Session established to the DNN and S-NSSAI used for onboarding, the SMF provides the Onboarding Indication to the PCF if the Onboarding Network is an ON-SNPN or the SMF does not provide any Onboarding Indication to the PCF if the Onboarding Network is a PLMN or an SNPN. When the Onboarding Indication is provided, the PCF does not perform a subscription check. Instead, the PCF uses the locally stored Onboarding Configuration Data for this DNN and S-NSSAI combination to make authorization and policy decisions. When the Onboarding Indication is not provided, the PCF retrieves policy control subscription profile for this SUPI, DNN, S-NSSAI from UDR that includes the list of allowed services. If the list of allowed services includes both PVS and DNS services, then the PCF has local policies that define the PVS and DNS addresses(es) to be used in the SDF template of the PCC Rule(s) and allow traffic to/from these destinations.

If the Onboarding Indication is provided by the SMF, the PCF sets the SDF template of the PCC rule(s) according to the Onboarding Configuration Data for this DNN and S-NSSAI combination that may include the Provisioning Server address(es) and DNS server address(es). If the PCF receives Provisioning Server address(es) from SMF, then PCF creates the SDF templates in the PCC rule using the received Provisioning Server address(es) instead of using the Provisioning Server address(es) stored locally as part of the Onboarding Configuration Data. The Provisioning Server address(es) provided by SMF may include IP address(es) and FQDN(s).

NOTE: How the PCF can resolve a PVS FQDN to an IP address or IP address range other than using local configuration is not specified in this release of the specification.

The PCC Rule Authorization function selects QoS parameters applicable to the User Plane Remote Provisioning. Then, the PCF installs these PCC Rules at the SMF to enable traffic to/from the dedicated IP addresses (i.e. Provisioning Server address(es) and DNS server address(es)) with the associated QoS. The DNS server address(es) are locally configured at the PCF.

The PCC Rules provided by the PCF take precedence over the locally stored policy used for the PDU Session used for User Plane Remote Provisioning at the SMF.

6.1.4 Network slice related policy control

6.1.4.1 General

Network slice related policy control supports limitation of the data rate per network slice.

A Maximum Slice Data Rate can be configured for an S-NSSAI (indicating the network slice subject to network slice data rate limitation control) by the operator (e.g. based on an SLA related to the network slice). The Maximum Slice Data Rate has an UL and a DL value.

The Maximum Slice Data Rate defines the maximum allowed aggregate data rate across all GBR and Non-GBR QoS Flows within the network slice identified by an S-NSSAI.

NOTE 1: The maximum data rate of the Non-GBR QoS Flows is controlled via the authorized Session-AMBR while the maximum data rate of the GBR QoS Flows is controlled via the authorized MBR value in the PCC rules of GBR service data flows.

The PCF monitors the data rate of the network slice and ensures that it does not exceed the Maximum Slice Data Rate for that network slice by e.g. rejecting new SM Policy Associations, rejecting new GBR service data flows with high GBR requirements, changing the Authorized Session-AMBR values (if allowed by the HPLMN), changing the MBR values in PCC rules belonging to GBR service data flows or other actions depending on operator policies. When the PCF rejects the SM Policy Association Establishment procedure to the SMF due to the Maximum Slice Data Rate for that network slice is exceeded, then the SMF rejects the establishment of the PDU Session.

NOTE 2: It is recommended to avoid frequent policy decisions which trigger a signalling with the UE (like change of Authorized Session-AMBR or change of MBR in a PCC rule belonging to a GBR service data flow).

NOTE 3: Based on operator policy it is also possible to accept the exceeding of the Maximum Slice Data Rate by new PDU Sessions or PCC rules belonging to GBR service data flows and to apply a different charging for them.

NOTE 4: Subject to operator policy and national/regional regulations, prioritised services and emergency services may be exempted from the limitation of data rate per network slice.

NOTE 5: A single PCF can be used for the monitoring and limitation of the data rate per network slice. To enable this, the SMF has to select the same PCF instance for all PDU Sessions of the UE to the S-NSSAI. This is achieved as described in clause 6.3.7.1 of TS 23.501 [2], for example by using local operator policies in the SMF, SUPI ranges, explicit indication (i.e. Same PCF Selection Indication) from the AMF to select the PCF selected for the UE, or the PCF redirects to a PCF service provided by another PCF.

6.1.4.2 Limitation of data rate per network slice with assistance of the NWDAF

If the NWDAF is used for network slice data rate analysis, the PCF consumes the analytics from the NWDAF and receives the Data Volume Dispersion Analytics statistics outputs for all UEs of the network slice as defined in TS 23.288 [24]. The PCF subscribes to the NWDAF for periodic reporting when it becomes responsible for the first PDU Session of a slice (subject to limitation of data rate per network slice) and cancels the subscription when it stops to handle the last PDU Session of that slice.

NOTE 1: It is recommended to configure the NWDAF in such a way that a too frequent notification is avoided.

The NWDAF periodically provides the analytics output to the PCF. The PCF calculates the utilized data rate of the network slice by using the statistics output Data volume dispersed and Duration. When the utilized data rate of the network slice is getting close to or is exceeding the Maximum Slice Data Rate for this S-NSSAI obtained from the UDR, based on operator policy, the PCF may apply a policy decision to strengthen the traffic restrictions for individual PDU Sessions or PCC rules (see clause 6.1.4.1). When the utilized data rate of the network slice falls below the Maximum Slice Data Rate, the PCF may relax the traffic restrictions for individual PDU Sessions or PCC rules.

When multiple PCFs for the same S-NSSAI are deployed, each PCF subscribes to the analytics from the NWDAF separately.

NOTE 2: When multiple PCFs are active for the slice, the NWDAF notification will trigger all of them but their policy decisions can be different.

6.1.4.3 Limitation of data rate per network slice with PCF based monitoring

If the NWDAF is not deployed or is not to be used for network slice data rate analysis, the UDR maintains the Remaining Maximum Slice Data Rate per S-NSSAI and the PCF interacts with the UDR to deduct the value of the authorized Session-AMBR and the MBR of every GBR SDF from the Remaining Maximum Slice Data Rate per S-NSSAI for every PDU Session of this slice. When the remaining data rate for that S-NSSAI is close to zero, the PCF may, based on operator policies, apply a policy decision to strengthen the traffic restrictions for individual PDU Sessions or PCC rules (see clause 6.1.4.1). When the Remaining Maximum Slice Data Rate for that S-NSSAI increases again, the PCF may relax the traffic restrictions for individual PDU Sessions or PCC rules.

NOTE 1: Multiple PCFs responsible for PDU Sessions of UEs to the same S-NSSAI can read and update the Remaining Maximum Slice Data Rate for the S-NSSAI in the UDR using the conditional requests with preconditions for the update of the Remaining Maximum Slice Data Rate, this mechanism using Etags is defined in Table 5.2.2.2-2 of TS 29.500 [35] to ensure a proper update of UDR data in case of simultaneous access from different PCFs.

The details on monitoring the data rate per network slice by the PCF are described in clause 6.2.1.10.

NOTE 2: While the remaining data rate is relatively high, the PCF can be configured to maintain a local Remaining Maximum Slice Data Rate and to only interact with the UDR to update the Remaining Maximum Slice Data Rate when a certain threshold is reached, or a certain time window has passed. The higher the configured values are the lower the chances for an accurate limitation of the slice data rate becomes. When multiple PCFs s for the same S-NSSAI are deployed, each PCF can also subscribe to the change of the Network slice specific policy control information in the UDR. The UDR will then send a notification to each subscribed PCF on the change of the Remaining Data Rate per S-NSSAI.