Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 23.503  Word version:  18.5.0

Top   Top   Up   Prev   Next
0…   4…   5…   6…   6.1.2…   6.1.2.4…   6.1.3…   6.1.3.6…   6.1.3.18…   6.1.3.21…   6.1.4…   6.2…   6.2.2…   6.3…   6.4…   6.6…   A…   C   D…

 

6.1.3.21  QoS Monitoring control |R16|p. 88

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:
In addition, the following AF requested QoS requirements may trigger QoS monitoring for service data flow(s):
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).
Up

6.1.3.22  AF session with required QoS |R16|p. 90

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

6.1.3.23  Support of integration with Time Sensitive Networking |R16|p. 92

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

6.1.3.23a  Support of Time Sensitive Communication and Time Synchronization |R17|p. 93

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

6.1.3.23b  Support of IETF Deterministic Networking |R18|p. 94

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

6.1.3.24  Policy control for redundant PDU Sessions |R16|p. 95

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

6.1.3.25  User Plane Remote Provisioning of UE SNPN Credentials in Onboarding Network |R17|p. 95

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

6.1.3.26  Packet Delay Variation monitoring and reporting |R18|p. 96

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

6.1.3.27  Support of eXtended Reality and Interactive Media Services |R18|p. 96

6.1.3.27.1  Exposure of network informationp. 96
For support of real-time media codec/traffic adaptation to the network conditions, the AF may subscribe for exposure of 5GS network information.
The AF may provide the subscription to the following information (as described in clause 5.37.4 of TS 23.501): the UL and/or DL congestion level information, UL and/or DL packet delay, the round-trip delay over one or two service data flows, the UL and/or DL data rate for the target service data flow(s) or the QNC for a GBR QoS Flow using AF session with required QoS as described in clause 6.1.3.22. The PCF may generate a PCC rule with the QoS monitoring for the above network information as described in clause 5.45.4 of TS 23.501.
The AF may also provide the value for Averaging Window using AF session with required QoS as described in clause 6.1.3.22.
Up
6.1.3.27.2  UL/DL policy control based on round-trip latency requirementp. 97
The AF may provide a round-trip (RT) latency indication together with a single direction delay requirement between the UE and the PSA UPF expressed as the QoS Reference or the individual QoS parameters (as described in clause 6.1.3.22). The RT latency indication indicates the need to meet the RT latency requirement of the service data flow, i.e. doubling of the single direction delay requirement between the UE and the PSA UPF.
Based on the RT latency requirement received from the AF or locally configured in the PCF, the PCF authorizes the AF request and can split the RT latency requirement into two PDBs of two PCC rules, used for the UL QoS Flow and DL QoS Flow to carry the UL and DL traffics of the service respectively. The two PDBs can be unequal, but their sum shall not exceed the RT latency requirement.
Based on the RT latency requirements, the PCF shall generate UL and DL QoS monitoring policies in the PCC rules associated to the two correlated QoS Flows respectively to enable RT latency tracking. The uplink and downlink delay for the two QoS Flows shall be tracked by PCF independently.
When the QoS monitoring results are reported to PCF, the PCF can derive and track the RT latency by combining the QoS monitoring reports for the UL and the DL packet delay. Based on the QoS monitoring results, the PCF may adjust the PDBs of one or both PCC rules under the consideration of the RT latency requirement using SM Policy Association Modification procedure described in clause 4.16.5.2 of TS 23.502 to better fit the new situation.
If the UL and DL traffic of the service have different QoS requirements (e.g. different one-way delay), the AF may provide the QoS requirements with RT latency indication in the AF Session with required QoS request for UL and DL Flow Descriptions. The PCF then identifies the UL and DL service data flows with RT latency indicator for RT latency control. In this case, the RT latency requirement of the service is described by the sum of the UL and DL delay requirements.
Up
6.1.3.27.3  Support for delivery of multi-modal servicesp. 97
Enablers to support interactive media services that require high data rate and low latency communication, e.g. cloud gaming, AR/VR/XR services and tactile/multi-modal communication services are defined in clause 5.37.2 of TS 23.501.
For the delivery of multi-modal services, the AF may request to the NEF multiple data flows for a single UE or for multiple UEs via multiple PDU Sessions and separate request(s) per PDU Session, to be setup with specific QoS requirements, as described in clause 6.1.3.22. Following additional attributes are supported where the AF provides specific information for multi-modal service:
  • Multi-modal Service ID: an identifier that refers to the multi-modal communication service. Data flows belonging to the same multi-modal service share the same Multi-modal Service ID.
Multi-modal Service Requirements consisting of the following existing attributes are supported for the AF to provide specific information for a data flow of the multi-modal service and the AF can provide them multiple times, i.e. once per data flow:
  • QoS monitoring requirements for each data flow.
  • QoS information and service requirements for each data flow, that consist of: Flow description information of the data flow and QoS parameters/QoS Reference as described in clause 6.1.3.22.
The request to the PCF includes Multi-modal Service ID as well as service requirements for each data flow that belongs to the multi-modal service. The PCF determines whether the request from the NEF or AF is authorized, derives the required QoS parameters based on the information provided and provisions in the SMF the PCC rules with updated policy control information for the affected PDU session.
The AF may provide QoS monitoring requirements for each data flow associated with the same Multi-modal Service ID. If the PCF has received the QoS monitoring requirements from the AF, the PCF generates the QoS monitoring policy for the PCC rule corresponding to the data flow.
When PCF receives further AF request with the same Multi-modal Service ID and PCF authorization fails, the PCF rejects the AF rejects. Application may decide how to deal with the data `flows with already authorized AF request with the same Multi-modal Service ID (e.g. stop them, adjust the AF request).
Up
6.1.3.27.4  PDU Set QoS handlingp. 98
PDU Set QoS handling support is defined in clause 5.37.5 of TS 23.501. The PCF may, based on local configuration or on information received from the AF, generate PDU Set Control Information and the PCF includes the UL and/or DL Protocol Description (see clause 5.37.5 of TS 23.501 and TS 26.522) received from AF and the PDU Set Control Information in the PCC Rule. The PDU Set Control Information includes the PDU Set QoS Parameters (see clause 5.7.7 of TS 23.501). Based on the received the PCC rule or a pre-configured PCC rule, the SMF provides NG-RAN the PDU Set QoS Parameters (as described in clause 5.37.5 of TS 23.501). If the PCC rule includes the Protocol Description, it is used for PDU Set identification (as described in clause 5.37.5 of TS 23.501).
When the AF requests that a data session to a UE is set up with a specific QoS (as described in clause 6.1.3.22), the AF can also provide the individual QoS parameters Requested PDU Set Delay Budget (UL and/or DL), Requested PDU Set Error Rate (UL and/or DL) and Requested PDU Set Integrated Handling Information (UL and/or DL) to describe the requirements for the PDU Set QoS handling and the Protocol Description (UL and/or DL).
Up
6.1.3.27.5  Data Burst Based Handlingp. 98
The detection and marking of End of Data Burst is defined in clause 5.37.8.3 of TS 23.501. Based on the AF provided DL Protocol Description (see clause 5.37.5 of TS 23.501 and TS 26.522) and/or local configuration, the PCF generates the Data Burst End Marking Indication (see clause 5.37.8.3 of TS 23.501) and provide it and the DL Protocol Description in the PCC rule to the SMF.
Up
6.1.3.27.6  Traffic Parameter Information and Traffic Parameter Measurementp. 98
The Traffic Parameter Information and Traffic Parameter Measurement apply to the power saving as specified in clause 5.37.8 of TS 23.501.
The PCF may, based on the AF provided periodicity information, generate a PCC Rule with Traffic Parameter Information and Traffic Parameter Measurement, see clause 6.3.1.
The Traffic Parameter Information includes the UL and/or DL Periodicity and the Traffic Parameter Measurement indicates the Traffic Parameters to be measured and reporting conditions.
Up

6.1.3.28  AF requested QoS for a UE or group of UEs not identified by a UE address |R18|p. 98

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

6.1.3.29  Network Slice replacement for a PDU Session |R18|p. 99

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

Up   Top   ToC