Content for  TS 23.503  Word version:  18.5.0

The QoS Monitoring control refers to the enabling of real-time measurements of QoS Monitoring parameters for a service data flow. An AF may request measurements for one or more of the QoS Monitoring parameters defined in clause 5.45 of TS 23.501. The AF may also request measurements for the following QoS Monitoring parameters (see clause 6.1.3.18)that are derived by PCF:

• Packet Delay Variation, as described in clause 6.1.3.26.
• Round-trip delay for two service data flows, as described in clause 5.37.4 of TS 23.501.

In addition, the following AF requested QoS requirements may trigger QoS monitoring for service data flow(s):

• Round-trip latency requirement, see clause 5.37.6 of TS 23.501.

The PCF generates the authorized QoS Monitoring policy for the service data flow based on local policy and AF request, including the QoS Monitoring request if received from the AF (as specified in clause 6.1.3.22 and in TS 23.502) and AF subscription requests for other QoS Monitoring parameter measurements as listed above. The QoS Monitoring policy includes the following:

• QoS Monitoring parameters as defined in clause 5.45 of TS 23.501;
• Reporting frequency (event triggered, periodic):
  • if the reporting frequency is event triggered:
    • the corresponding reporting threshold to each QoS Monitoring 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 5.8.2.18 of TS 23.501).

When multiple QoS Monitoring parameters are required to be measured for a given service data flow, multiple QoS Monitoring policies may be included within one PCC rule. At a given time, the PCC Rule only has one authorized QoS Monitoring policy enabling the measurement of each QoS Monitoring parameter. If the AF did not provide an indication of direct event notification in the request and the PCF may decide that it does not want to receive the QoS Monitoring reports. If so, 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, e.g. when the AF request includes measurements that are derived by PCF, 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 Policy Control Request Trigger. If the AF provided an indication of direct event notification in the request and PCF determines that the QoS Monitoring reports can be notified directly (i.e. the AF request does not include QoS Monitoring parameter measurements that are derived by PCF), 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 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). If the AF provided an indication of direct event notification and PCF determines that the QoS Monitoring reports can not be notified directly (i.e. the AF request includes QoS Monitoring parameter measurements that are derived by PCF), the PCF generates a successful response to AF and indicates that direct event notification is not possible. The PCF shall neither forward the Target of reporting parameter nor the indication of direct event notification in the QoS Monitoring policy and instead subscribe to receive QoS Monitoring reports from SMF by setting the QoS Monitoring Policy Control Request Trigger. 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 measurement of the QoS Monitoring parameters (e.g. the QoS Monitoring parameter(s) requested) from the QoS Monitoring policy in the PCC rule and requests the RAN (if necessary) and the UPF to perform the measurement of the QoS Monitoring parameters defined in clause 5.45 of TS 23.501 as needed and as defined in clause 5.8.2.18 of TS 23.501 and in clause 4.3.3.2 of TS 23.502. The PCF can be configured to include in the QoS monitoring policy of the PCC rule a DataCollection_ApplicationIdentifier determined based on the AF request or local configuration. The DataCollection_ApplicationIdentifier is provided to assist the SMF when it needs to decide whether this PCC Rule corresponds to an event exposure subscription (see clause 4.15.4.4 of TS 23.502).

The AF may request that a data session to a UE is set up with a specific QoS (e.g. low latency or PDV) 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.

1. 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.
   • 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.
2. 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.
   • 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 and Indication of ECN marking for L4S.
     The AF may also provide the PCF with QoS duration and QoS inactivity interval. The requested QoS is applied to each QoS duration interval. Once the PCF receives the request from the AF, the PCF provides a PCC Rule with the QoS parameters to SMF to allocate resources. The PCF may allocate resources at the beginning of each QoS duration interval and release the resources at the end of the corresponding QoS duration interval. This process is repeated until the AF session is revoked. If the AF has subscribed to the PCF and resource allocation for any of the QoS duration interval fails, the PCF informs the AF of the resource allocation failure.

If the AF provides an explicit indication (i.e. Indication of ECN marking for L4S) that the UL and/or DL of the service data flow supports ECN marking for L4S or the PCF decides, based on local configuration, that the service data flow supports ECN marking for L4S, then the PCF may explicitly, or implicitly (based on PCF/SMF local configuration), indicate to the SMF to enable for ECN marking for L4S. The PCF decision may be taken, based on local configuration in PCF and SMF and L4S traffic detection result. If L4S support is detected on the UL and/or DL traffic of the service data flow, the QoS flow is enabled with ECN marking for L4S, see clause 5.37.3 of TS 23.501. 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) or Ethernet Packet Filter set as in clause 5.7.6.3 of TS 23.501) 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. 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) or Ethernet Packet Filter set as in clause 5.7.6.3 of TS 23.501) 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, 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. Each requested Alternative QoS Parameter Set may also include a Maximum Burst Size parameter.
  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). The PCF may generate policies to request to monitor the Traffic Parameter (i.e. N6 jitter range associated with DL Periodicity) and include it into a PCC rule based local policy. Based on the received PCC rule or local configuration, the SMF indicates UPF to monitor and report the requested traffic characteristics as described in clause 5.37.8.2 in TS 23.501. 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.

Time Sensitive Networking (TSN) support is defined in TS 23.501, 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. 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 and TS 23.502. 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, the bridge delay information at the TSN AF and the UE-DS-TT Residence time. 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), 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;
• optionally, Notification Target Address for PMIC/UMIC UPF event and Correlation ID for PMIC/UMIC UPF event.

The PCF provides the SMF the parameters received from the TSN AF (as specified in TS 23.502). The SMF indicates the UPF to report the TSC management information as defined in clause 5.8.5.14 of TS 23.501 if the PCF forwards the Target of reporting parameter. The PCF assigns the ARP to a value preconfigured for TSN services.

Enablers for Time Sensitive Communication and Time Synchronization are defined in clause 5.27 of TS 23.501. When the PCF has the 5GS Bridge/Router information for the PDU Session received from SMF and has a subscription for the 5GS Bridge/Router 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:
  • User-plane Node 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.
• optionally, Notification Target Address for PMIC/UMIC UPF event and Correlation ID for PMIC/UMIC UPF event.

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), 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 or Periodicity Range in the request (as described in clause 5.27.2.3 of TS 23.501), if so the TSCTSF subscribes to Notification on BAT offset defined in clause 6.1.3.18. 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. If the PCF additionally sends the adjusted periodicity received from the SMF to the AF, the AF adjusts the periodicity in addition to the burst sending time according to the indicated adjusted periodicity. The AF may subscribe to requested 5G access stratum time synchronization service or (g)PTP time synchronization service status update notifications for target UE(s) from TSCTSF. The TSCTSF may determine whether the clock quality acceptance criteria requested by AF can be met or not, and performs behaviours per acceptance criteria result as described in clause 5.27.1.12 of TS 23.501.

Enablers for the support of IETF Deterministic Networking are defined in clauses 4.4.8.4 and 5.28.5 of TS 23.501. When the PCF has received the 5GS Bridge/Router information for the PDU Session from SMF and has a subscription for the 5GS Bridge/Router information Notification from the TSCTSF or based on a local policy, if integration with IETF Deterministic Networking applies, the PCF provides the following information to the TSCTSF for device side ports:

• user-plane node ID;
• port number;
• IP address or IPv6 prefix allocated to the PDU Session;
• MTU size for IPv4 or MTU size for IPv6 (optional).

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 shall subscribe for notifications from the PCF for reporting of extra UE addresses for the same PDU Session. As a result, the TSCTSF shall be notified of any extra address or address range that is allocated for the given PDU Session as a result of Framed Routes or IPv6 Prefix delegation. When the TSCTSF is first notified about a 5GS DetNet router identified by the user-plane node ID, the TSCTSF may subscribe with the NW-TT for receiving user plane node management information changes for the 5GS router, as described in clause 5.28.3.1 of TS 23.501. After receiving a User plane node Management Information Container (UMIC) containing the NW-TT port numbers, the TSCTSF may subscribe with the NW-TT for receiving NW-TT port management information changes for the NW-TT port indicated by each of the NW-TT port numbers as described in clause 5.28.3.1 of TS 23.501. For network side ports, the Port Management Information Container may contain information to be exposed to the DetNet controller (see Information for deterministic networking in Table K.1-1 of TS 23.501). The TSCTSF may receive DetNet YANG configuration as described in IETF draft-ietf-detnet-yang [37] from a DetNet Controller that describe the traffic characteristics and requirements. When both the TSCTSF and the DetNet controller support 3GPP extensions to the IETF draft-ietf-detnet-yang [37], the DetNet controller may provide the 5GS-node-max-latency and 5GS-node-max-loss specific to the 5GS system. The TSCTSF provides the Flow Descriptions, the TSC Assistance Container (as described in clause 5.27.2.3 of TS 23.501), and the related QoS information to the PCF as specified in the AF session with required QoS procedure for the signalling between the TSCTSF and the PCF described in clause 4.15.6.6 of TS 23.502. The TSCTSF can set up an AF session on behalf of DetNet controller with required QoS as described in clause 6.1.3.22. The TSCTSF maps the DetNet configuration as follows before interacting with the PCF.

• 5GS-node-max-latency to Requested 5GS Delay.
• Min-bandwidth to Requested Guaranteed Bitrate.
• 5GS-node-max-loss to Requested Packet Error Rate.
• Max-consecutive-loss-tolerance to Survival time (see clause 5.27.2.1 of TS 23.501) - when such mapping is possible, such as when there is only a single packet per interval.
• Interval to Periodicity.
• max-pkts-per-interval * (max-payload-size + protocol header size) to Maximum Burst Size.
• max-pkts-per-interval * (max-payload-size + protocol header size)/ Interval to Requested Maximum Bitrate.
• DetNet flow specification is mapped to the Flow Description information. The DetNet flow specification is based on the following header fields: IP source and destination address, IPv4 protocol or IPv6 next header, IPv4 type of service or IPv6 traffic class, IPv6 flow label, TCP or UDP source or destination ports, IPsec SPI as defined in clause 5.1 of IETF RFC 8939 [42], which are mapped to the corresponding fields in the Flow Description information.

If the DetNet YANG configuration includes the Max-latency and Max-loss only for the end-to-end flow and not the 5GS specific requirement, the TSCTSF determines the requirements applicable to 5GS (5GS-node-max-latency and 5GS-node-max-loss) based on a pre-configured mapping for the given deployment. Based on the mapping, the TSCTSF provides the Flow Descriptions, the TSC Assistance Container (as described in clause 5.27.2.3 of TS 23.501), 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. The TSCTSF shall subscribe to the Resource allocation outcome and Service Data Flow deactivation events at the PCF, so that TSCTSF gets notified when the DetNet requirements are not satisfied. In that case, the DetNet controller shall be notified.

As specified in clause 5.33.2.1 of TS 23.501, 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 to establish redundant PDU Sessions depending on the indication from the PCF.

User Plane Remote Provisioning of UE SNPN Credentials in Onboarding Network is specified in clause 5.30.2.10.4 of TS 23.501. 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). 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.

The AF may send a request to PCF for Packet Delay Variation (i.e. between UE to PSA UPF) monitoring and reporting, together with the request for packet delay monitoring and reporting. The PCF may generate the authorized QoS Monitoring policy for the service data flow based on both, Packet Delay Variation monitoring request and the QoS Monitoring request for packet delay. The Packet Delay Variation monitoring request includes the following:

• Packet Delay Variation (UL, DL or RT packet delay variation);
• frequency of reporting (event triggered or periodic):
  • if the reporting frequency is event triggered:
    • the corresponding reporting thresholds;
    • minimum waiting time between subsequent reports.

Based on the above Packet Delay Variation monitoring request, the QoS Monitoring request for packet delay received from the AF and any other AF requirements related to QoS monitoring, the PCF generates the authorized QoS monitoring policy for packet delay monitoring. The PCF shall subscribe to receive QoS Monitoring reports from SMF by setting the QoS Monitoring Policy Control Request Trigger. Then, the SMF reports the measured packet delay values to the PCF, the PCF derives the Packet Delay Variation and reports to the AF both, the packet delay measurements and Packet Delay Variation results under consideration of the respective thresholds and minimum waiting times (if they are applicable). If the Reporting frequency indicates "event triggered", PCF shall send a report when the measurement result matches or exceeds the indicated Reporting threshold. Subsequent reports shall not be sent during the Minimum waiting time. After the Minimum waiting time is over, the PCF shall report if measurement results are produced that match or exceed the indicated Reporting threshold.

The AF may request that the data session(s) for a UE (identified by a GPSI) or a group of UEs (identified by an External Group ID) for a specific DNN and S-NSSAI are set up with a specific QoS (e.g. low latency or PDV) and priority handling. The request from the AF may also include parameters for QoS monitoring and parameters that describe the traffic characteristics. According to the QoS parameters for AF session with QoS as described in clause 6.1.3.22, the parameters that describe the traffic characteristics for AF session with QoS as described in clause 6.1.3.23a, and the parameters to subscribe to be notified of the QoS Monitoring reports as described in clause 6.1.3.21, the AF request information may include:

• DNN and S-NSSAI;
• Information about target UEs: External Group Identifier or GPSI;
• Flow Descriptions as described in clause 6.1.3.6;
• Traffic characteristics as described in clause 6.1.3.23 or clause 6.1.3.23a;
• QoS parameters (e.g. QoS Reference or individual QoS parameters or Alternative QoS Parameter Set) as defined in clause 6.1.3.22;
• QoS parameters for monitoring as defined in clause 6.1.3.21;
• Temporal invalidity condition (start-time, end-time), indicate the time period when there will be no user payload for the DNN/S-NSSAI and Flow Descriptions provided with the request (e.g. at night or on weekends);
• Subscription to events as defined in clause 6.1.3.18.

The NEF determines whether or not to invoke the TSCTSF in the same way as for AF session with required QoS procedure, as described in step 2 of clause 4.15.6.6 in TS 23.502. In case the TSCTSF is not used, the NEF stores the AF request on UDR. The PCF receives the AF requested QoS information from the UDR as described in clause 4.15.6.14 of TS 23.502. If the AF requested QoS information contains temporal invalidity condition, the PCF activates, modifies, or removes PCC rules corresponding to the QoS information as needed based on the invalidity conditions. In the case that the TSCTSF is used, the TSCTSF receives the AF requested QoS information from the NEF. The TSCTSF applies the AF requested QoS information as described in clause 5.20c of TS 23.501 and clause 4.15.6.14 of TS 23.502.

The Network Slice Replacement is specified in clause 5.15.19 of TS 23.501. The PCF may set the Network Slice Replacement trigger event in the SMF as defined in clause 6.1.3.5. When a new PDU Session is established and the SMF receives both an S-NSSAI and an Alternative S-NSSAI, the SMF includes both the replaced S-NSSAI and the Alternative S-NSSAI in SM Policy Association establishment request to PCF. The PCF may retrieve PDU Session policy control subscription information using both the replaced S-NSSAI and the Alternative S-NSSAI. The PCF makes policy decision by combining subscription information of the replaced NSSAI and the Alternative S-NSSAI based on the principle that if there is common information present for both S-NSSAIs, the PCF choses the data of the replaced S-NSSAI. The PCF maintains both the S-NSSAI and the Alternative S-NSSAI in the Session Management context. The PCF registers the replaced S-NSSAI in the BSF. When the existing PDU Session is transferred from S-NSSAI to Alternative S-NSSAI, if the SMF determines that the existing PDU Session and existing SM Policy Association can be retained (e.g. if the SMF determines that same PCF can be used for the Alternative S-NSSAI) and the PCF set the Network Slice Replacement PCRT to request the SMF to report as defined in clause 6.1.3.5, then the SMF includes the Alternative S-NSSAI in SM Policy Association modification request to PCF to update the S-NSSAI of the PDU Session. The PCF may request subscription information associated with the Alternative S-NSSAI from the UDR. Then the PCF makes policy decision by combining subscription information of the replaced NSSAI and the Alternative S-NSSAI based on the principle that if there is common information present for both S-NSSAIs, the PCF choses the data of the replaced S-NSSAI and may provide updated PCC rules to SMF. The PCF does not update the binding information in the BSF. When the existing PDU Session is transferred from Alternative S-NSSAI to the replaced S-NSSAI, if the SMF determines that the existing PDU Session and existing SM Policy Association can be retained (e.g. if the SMF determines that same PCF can be used for the Alternative S-NSSAI) and the PCF set the Network Slice Replacement PCRT to request the SMF to report as defined in clause 6.1.3.5, then the SMF removes the Alternative S-NSSAI in SM Policy Association modification request to PCF to update the S-NSSAI of the PDU Session. The PCF requests subscription information associated with the replaced S-NSSAI from the UDR, if not already available. Then the PCF makes policy decision based on the replaced S-NSSAI and may provide updated PCC rules to SMF. The PCF does not update the binding information in the BSF. If the SMF determines that the existing PDU Session and existing SM Policy Association is not retained (e.g. if the SMF determines that PCF discovery and selection for the Alternative S-NSSAI is to be performed), then the SMF terminates the existing SM Policy Association, and the PCF removes the SUPI to S-NSSAI association from the BSF. Then the SMF establishes a new SM Policy association. When existing PDU Session is transferred back to the replaced S-NSSAI, the SMF sends SM Policy Association modification request to PCF to update the S-NSSAI of the PDU Session. Then the PCF makes policy decision based on the replaced S-NSSAI and may provide updated PCC rules to the SMF. When the PCF receives the SM policy association establishment (or modification) request message including the S-NSSAI and the Alternative S-NSSAI, the PCF checks if the PDU Session of a SUPI for a DNN and a S-NSSAI that has been replaced by an Alternative S-NSSAI is subject of usage monitoring control, as defined in clause 6.2.1.7, if so, the PCF retrieves usage monitoring related information per DNN and Alternative S-NSSAI combination for a SUPI from the UDR if available, then performs usage monitoring control as described in clause 6.2.1.6 based on the SUPI for a DNN and Alternative S-NSSAI combination or the SUPI for a DNN and replaced S-NSSAI combination, until the Alternative S-NSSAI is not applicable any longer. The PCF shall stop monitoring control for the DNN and Alternative S-NSSAI combination and start doing usage monitoring control for the DNN and replaced S-NSSAI combination when the replaced S-NSSAI is available again. The PCRTs provided to the SMF are still reported to the PCF, when the PDU Session is established or has been replaced by an Alternative S-NSSAI.