The policy framework shall provide following functionality for the access and mobility enforcement:

• Policy Control Function (PCF) shall support interactions with the access and mobility policy enforcement in the AMF, through service-based interfaces.
• The PCF shall be able to provide Access and Mobility Management related policies to the AMF.
• The PCF shall be able to evaluate operator policies that are triggered by events.
• The AF may influence Access and Mobility related policy control performed by the PCF.

The 5GC shall be able to provide policy information from the PCF to the UE. Such UE policy information includes:

• Access Network Discovery & Selection Policy (ANDSP): It is used by the UE for selecting non-3GPP accesses network.
• UE Route Selection Policy (URSP): This policy is used by the UE to determine how to route outgoing traffic. Traffic can be routed 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.
• V2X Policy (V2XP): This policy provides configuration parameters to the UE for V2X communication over Uu reference point or over PC5 reference point or both. V2X Policies are defined in TS 23.287.
• ProSe Policy (ProSeP): This policy provides configuration parameters to the UE for ProSe features as defined in clause 5.1 of TS 23.304.
• Ranging/Sidelink Positioning Policy (RSLPP): This policy provides configuration parameters to the UE for Ranging/Sidelink Positioning control. Ranging/Sidelink Positioning Policies are defined in TS 23.586.
• A2X Policy (A2XP): This policy provides configuration parameters to the UE for A2X communication over PC5 reference point or over Uu reference point or both. A2X Policies are defined in TS 23.256.

The PCF shall be able to collect network analytic information from the NWDAF directly or via DCCF, if deployed. The NWDAF provides network data analytics (e.g. load level information on a network slice level) to PCF. The PCF shall be able to use those data in its policy decisions. The details are defined in clause 6.1.1.3.

Management of Packet Flow Descriptions (PFDs) refers to the capability to create, update or remove PFDs in the NEF (PFDF) and the distribution from the NEF (PFDF) to the SMF and finally to the UPF. This feature may be used when the UPF is configured to detect a particular application provided by an ASP. The management of PFDs is supported in non-roaming and home-routed scenarios for those ASPs that have a business relation with the home operator.

The policy framework may provide following functionality for the SMF selection management for a PDU Session:

• The Policy Control Function (PCF) may support interactions with the SMF selection functionality in the AMF and the PCF may provide SMF selection management related policies to the AMF;
• The PCF may provide a policy to the AMF to contact PCF for performing DNN replacement of specific DNNs;
• The PCF may provide a policy to the AMF to contact PCF for performing DNN replacement for an unsupported DNN.

Support for network capability exposure enables an AF (e.g. an external ASP) to request the following non-session management related policy control functionality from the NEF:

• Management of PFDs as defined in clause 6.1.2.3 and in clause 4.18 of TS 23.502;
• Negotiations for future background data transfer as defined in clause 6.1.2.4 and in clause 4.16.7 of TS 23.502;
• Applying a previously negotiated background data transfer policy to a UE or group of UEs as defined in clause 6.1.2.4 and in clause 4.15.6.8 of TS 23.502;
• Service specific parameter provisioning for V2X communication (see clause 5.20 of TS 23.501 and clause 4.15.6.7 of TS 23.502);
• 5G VN group management (see clause 5.29 of TS 23.501 and clause 4.15.6 of TS 23.502);
• Service specific parameter provisioning for ProSe Direct Discovery, ProSe Direct Communication, ProSe Relay Discovery and ProSe Relay Communications (see clause 5.20 of TS 23.501 and clause 4.15.6.7 of TS 23.502);
• Service specific parameter provisioning for Ranging/Sidelink Positioning control (see clause 5.20 of TS 23.501 and clause 4.15.6.7 of TS 23.502);
• Service specific parameter provisioning for time synchronization service (see clause 5.27.1.8 of TS 23.501 and clause 4.15.9 of TS 23.502);
• Negotiations for planned data transfer with QoS requirements as defined in clause 6.1.2.7 and in clause 5.2.5.9 of TS 23.502;
• Service specific parameter provisioning for A2X communication (see clause 5.20 of TS 23.501 and clause 4.15.6.7 of TS 23.502).

The policy framework may provide following functionality for the slice replacement:

• The Policy Control Function (PCF) may support interactions with the slice replacement functionality in the AMF and the PCF may provide slice replacement related policies to the AMF.

It shall be possible for the PCC framework to base decisions upon subscription information, Access Type and the RAT Type. The PCC framework shall perform Gating Control and discard packets that don't match any service data flow of the active PCC rules. It shall also be possible for the operator to define PCC rules, with wild-carded service data flow filters, to allow sending or receiving packets that do not match any service data flow template of any other active PCC rules. The PCC framework shall allow the charging control to be applied on a per service data flow and on a per application basis, independent of the policy control. The PCC framework shall have a binding method that allows the unique association between service data flows and specific QoS Flow. A single service data flow detection shall suffice for the purpose of both policy control and flow based charging. A PCC rule may be predefined or dynamically provisioned at establishment and during the lifetime of a PDU Session. The latter is referred to as a dynamic PCC rule. It shall be possible to take a PCC rule into service, and out of service, at a specific time of day, without any PCC interaction at that point in time. It shall be possible to take DNN-related policy information into service, and out of service, once validity conditions specified as part of the DNN-related policy information are fulfilled or not fulfilled anymore, respectively, without any PCC interaction at that point in time. PCC shall be enabled on a per DNN basis at the SMF. It shall be possible for the operator to configure the PCC framework to perform charging control, policy control or both for a DNN access. The PCC framework shall allow the resolution of conflicts which would otherwise cause a subscriber's Subscribed Guaranteed Bandwidth QoS to be exceeded. It should be possible to use PCC framework for handling IMS-based emergency service. It shall be possible with the PCC framework, in real-time, to monitor the overall amount of resources that are consumed by a user and to control usage independently from charging mechanisms, the so-called usage monitoring control. It shall be possible for the PCC framework to provide application awareness even when there is no explicit service level signalling. The PCC framework shall support making policy decisions based on subscriber spending limits. The PCC framework shall support making policy decisions for N6 traffic steering.

The requirements to monitor, both volume and time usage, and report the accumulated usage of network resources apply for PDU Sessions of type IP and Ethernet. It shall be possible to apply usage monitoring for the accumulated usage of network resources on a per Session and user basis. This capability is required for enforcing dynamic policy decisions based on the total network usage in real-time. The PCF that uses usage monitoring for making dynamic policy decisions shall set and send the applicable thresholds to the SMF for monitoring. The usage monitoring thresholds shall be based either on time, or on volume. The PCF may send both thresholds to the SMF. The SMF shall notify the PCF when a threshold is reached and report the accumulated usage since the last report for usage monitoring. If both time and volume thresholds were provided to the SMF, the accumulated usage since last report shall be reported when either the time or the volume thresholds are reached. The usage monitoring capability shall be possible for an individual or a group of service data flow(s), or for all traffic of a PDU Session in the SMF. When usage monitoring for all traffic of a PDU Session is enabled, it shall be possible to exclude an individual SDF or a group of service data flow(s) from the usage monitoring for all traffic of this PDU Session. It shall be possible to activate usage monitoring both to service data flows associated with predefined PCC rules and dynamic PCC rules, including rules with deferred activation and/or deactivation times while those rules are active. If service data flow(s) need to be excluded from PDU Session level usage monitoring and PDU Session level usage monitoring is enabled, the PCF shall be able to provide the indication of exclusion from session level monitoring associated with the respective PCC rule(s). It shall be possible to apply different usage monitoring depending on the access used to carry a Service Data Flow.

The application detection and control feature comprise the request to detect the specified application traffic, report to the PCF on the start or stop of application traffic and to apply the specified enforcement and charging actions. The PCF shall instruct the SMF on which applications to detect and whether to report start or stop event to the PCF by activating the appropriate PCC rules in the SMF. Reporting notifications of start and stop of application detection to the PCF may be muted. The report to the PCF shall include the report is for start or stop, the detected application identifier and, if deducible, the service data flow descriptions for the detected application traffic. Upon receiving the report from SMF, the PCF may make policy decisions based on the information received and may send the corresponding updated or new PCC rules to the SMF. The PCF may have to further notify the AF on the detection of application start or stop event if the AF, may be via NEF, has subscribed this event from the PCF. In this Release of the specification Application Detection and Control applies only to the IP PDU Session types.

Support for network capability exposure enables an AF (e.g. an external ASP) to request the following session management related policy control functionality from the NEF:

• Set or change a chargeable party at AF session setup (see clause 4.15.6.4 and 4.15.6.5 of TS 23.502);
• Set up an AF session with required QoS (see clause 4.15.6.6 of TS 23.502 and clause 6.1.3.22);
• Request QoS, traffic characteristics provisioning and performance monitoring for an individual UE or a group of UEs (see clause 4.15.6.14 of TS 23.502);
• Transfer of traffic characteristics of Time Sensitive Communication from the TSN AF (see clause 6.1.3.23) or from the TSCTSF (see clause 6.1.3.23a);
• Set up a time synchronization service from the TSCTSF (see clause 5.27.1.8 of TS 23.501, clause 4.15.9 of TS 23.502 and clause 6.1.3.23a);
• Application Function influence on traffic routing, as defined in clauses 4.3.7 and 6.1.3.14, as well as in clause 5.6.7 of TS 23.501;
• Application Function influence on Service Function Chaining, as defined in clauses 4.3.7 and 6.1.3.14, as well as in clause 5.6.16 of TS 23.501.

Traffic Steering Control refers to the capability to activate/deactivate traffic steering policies from the PCF in the SMF for the purpose of:

• steering the subscriber's traffic to appropriate operator or 3rd party service functions (e.g. NAT, antimalware, parental control, DDoS protection) in the N6-LAN or 5G-LAN type of services according to operator policy, or Application Function influence on Service Function Chaining as described in clause 5.6.16 of TS 23.501. This is supported in non-roaming and home-routed scenarios only.
• Application Function influence on traffic routing which enables the routing of the user traffic matching the traffic filters provided in the PCC rule to a local Data Network identified by the DNAI per AF request. This is supported in non-roaming, LBO and HR-SBO scenarios only, as described in clause 5.6.7 of TS 23.501.