5.7 QoS model
23.5013GPPRelease 18System architecture for the 5G System (5GS)TS
5.7.1 General Overview
5.7.1.1 QoS Flow
The 5G QoS model is based on QoS Flows. The 5G QoS model supports both QoS Flows that require guaranteed flow bit rate (GBR QoS Flows) and QoS Flows that do not require guaranteed flow bit rate (Non-GBR QoS Flows). The 5G QoS model also supports Reflective QoS (see clause 5.7.5).
The QoS Flow is the finest granularity of QoS differentiation in the PDU Session. A QoS Flow ID (QFI) is used to identify a QoS Flow in the 5G System. User Plane traffic with the same QFI within a PDU Session receives the same traffic forwarding treatment (e.g. scheduling, admission threshold). The QFI is carried in an encapsulation header on N3 (and N9) i.e. without any changes to the e2e packet header. QFI shall be used for all PDU Session Types. The QFI shall be unique within a PDU Session. The QFI may be dynamically assigned or may be equal to the 5QI (see clause 5.7.2.1).
Within the 5GS, a QoS Flow is controlled by the SMF and may be preconfigured, or established via the PDU Session Establishment procedure (see clause 4.3.2 of TS 23.502 [3]), or the PDU Session Modification procedure (see clause 4.3.3 of TS 23.502 [3].
Any QoS Flow is characterised by:
– A QoS profile provided by the SMF to the AN via the AMF over the N2 reference point or preconfigured in the AN;
– One or more QoS rule(s) and optionally QoS Flow level QoS parameters (as specified in TS 24.501 [47]) associated with these QoS rule(s) which can be provided by the SMF to the UE via the AMF over the N1 reference point and/or derived by the UE by applying Reflective QoS control; and
– One or more UL and DL PDR(s) provided by the SMF to the UPF.
Within the 5GS, a QoS Flow associated with the default QoS rule is required to be established for a PDU Session and remains established throughout the lifetime of the PDU Session. This QoS Flow should be a Non-GBR QoS Flow (further details are described in clause 5.7.2.7).
A QoS Flow is associated with QoS requirements as specified by QoS parameters and QoS characteristics.
NOTE: The QoS Flow associated with the default QoS rule provides the UE with connectivity throughout the lifetime of the PDU Session. Possible interworking with EPS motivates the recommendation for this QoS Flow to be of type Non-GBR.
5.7.1.2 QoS Profile
A QoS Flow may either be ‘GBR’ or ‘Non-GBR’ depending on its QoS profile. The QoS profile of a QoS Flow is sent to the (R)AN and it contains QoS parameters as described below (details of QoS parameters are described in clause 5.7.2):
– For each QoS Flow, the QoS profile shall include the QoS parameters:
– 5G QoS Identifier (5QI); and
– Allocation and Retention Priority (ARP).
– For each Non-GBR QoS Flow only, the QoS profile may also include the QoS parameter:
– Reflective QoS Attribute (RQA).
– For each GBR QoS Flow only, the QoS profile shall also include the QoS parameters:
– Guaranteed Flow Bit Rate (GFBR) – UL and DL; and
– Maximum Flow Bit Rate (MFBR) – UL and DL; and
– In the case of a GBR QoS Flow only, the QoS profile may also include one or more of the QoS parameters:
– Notification control;
– Maximum Packet Loss Rate – UL and DL.
NOTE: In this Release of the specification, the Maximum Packet Loss Rate (UL, DL) is only provided for a GBR QoS Flow belonging to voice media.
Each QoS profile has one corresponding QoS Flow identifier (QFI) which is not included in the QoS profile itself.
The usage of a dynamically assigned 5QI for a QoS Flow requires in addition the signalling of the complete 5G QoS characteristics (described in clause 5.7.3) as part of the QoS profile.
When a standardized or pre-configured 5QI is used for a QoS Flow, some of the 5G QoS characteristics may be signalled as part of the QoS profile (as described in clause 5.7.3).
5.7.1.2a Alternative QoS Profile
The Alternative QoS Profile(s) can be optionally provided for a GBR QoS Flow with Notification control enabled. If the corresponding PCC rule contains the related information (as described in TS 23.503 [45]), the SMF shall provide, in addition to the QoS profile, a prioritized list of Alternative QoS Profile(s) to the NG-RAN. If the SMF provides a new prioritized list of Alternative QoS Profile(s) to the NG-RAN (if the corresponding PCC rule information changes), the NG-RAN shall replace any previously stored list with it.
An Alternative QoS Profile represents a combination of QoS parameters PDB, PER and GFBR to which the application traffic is able to adapt.
NOTE 1: There is no requirement that the GFBR monotonically decreases, nor that the PDB or PER monotonically increase as the Alternative QoS Profiles become less preferred.
When the NG-RAN sends a notification to the SMF that the QoS profile is not fulfilled, the NG-RAN shall, if the currently fulfilled values match an Alternative QoS Profile, include also the reference to the Alternative QoS Profile to indicate the QoS that the NG-RAN currently fulfils (see clause 5.7.2.4). The NG-RAN shall enable the SMF to determine when an NG-RAN node supports the Alternative QoS feature but cannot fulfil even the least preferred Alternative QoS Profile.
NOTE 2: To reduce the risk that GBR QoS Flows are released in case of RAN resource limitations (and then experience difficulties in being re-established), Application Functions can set the least preferred Alternative Service Requirement to an undemanding level.
5.7.1.3 Control of QoS Flows
The following options are supported to control QoS Flows:
1) For Non-GBR QoS Flows, and when standardized 5QIs or pre-configured 5QIs are used and when the 5QI is within the range of the QFI (i.e. a value less than 64), the 5QI value may be used as the QFI of the QoS Flow.
(a) A default ARP shall be pre-configured in the AN; or
(b) The ARP and the QFI shall be sent to RAN over N2 at PDU Session Establishment or at PDU Session Modification and when NG-RAN is used every time the User Plane of the PDU Session is activated; and
2) For all other cases (including GBR and Non-GBR QoS Flows), a dynamically assigned QFI shall be used. The 5QI value may be a standardized, pre-configured or dynamically assigned. The QoS profile and the QFI of a QoS Flow shall be provided to the (R)AN over N2 at PDU Session Establishment/Modification and when NG-RAN is used every time the User Plane of the PDU Session is activated.
Only options 1b and 2 may apply to 3GPP ANs. Options 1a, 1b and 2 may apply to Non-3GPP access.
NOTE: Pre-configured 5QI values cannot be used when the UE is roaming.
5.7.1.4 QoS Rules
The UE performs the classification and marking of UL User plane traffic, i.e. the association of UL traffic to QoS Flows, based on QoS rules. These QoS rules may be explicitly provided to the UE (i.e. explicitly signalled QoS rules using the PDU Session Establishment/Modification procedure), pre-configured in the UE or implicitly derived by the UE by applying Reflective QoS (see clause 5.7.5). A QoS rule contains the QFI of the associated QoS Flow, a Packet Filter Set (see clause 5.7.6) and a precedence value (see clause 5.7.1.9). An explicitly signalled QoS rule contains a QoS rule identifier which is unique within the PDU Session and is generated by SMF.
There can be more than one QoS rule associated with the same QoS Flow (i.e. with the same QFI).
When the UE informs the network about the number of supported Packet Filters for signalled QoS rules for the PDU Session (during the PDU Session Establishment procedure or using the PDU Session Modification procedure as described in clause 5.17.2.2.2 after the first inter-system change from EPS to 5GS for a PDU Session established in EPS and transferred from EPS with N26 interface), the SMF shall ensure that the sum of the Packet Filters used by all signalled QoS rules for a PDU Session does not exceed the number indicated by the UE.
A default QoS rule is required to be sent to the UE for every PDU Session establishment and it is associated with a QoS Flow. For IP type PDU Session or Ethernet type PDU Session, the default QoS rule is the only QoS rule of a PDU Session which may contain a Packet Filter Set that allows all UL packets, and in this case, the highest precedence value shall be used for the QoS rule.
NOTE 2: How the UE evaluates UL packets against the Packet Filter Set in a QoS rule is described in clause 5.7.1.5.
NOTE 3: The QoS rule pre-configured in the UE is only used together with option 1a for control QoS Flows as described in clause 5.7.1.3. How to keep the consistency of QFI and Packet Filter Set between UE and network is out of scope in this release of the specification.
For Unstructured type PDU Session, the default QoS rule does not contain a Packet Filter Set, and in this case the default QoS rule defines the treatment of all packets in the PDU Session.
As long as the default QoS rule does not contain a Packet Filter Set or contains a Packet Filter Set that allows all UL packets, Reflective QoS should not be applied for the QoS Flow which the default QoS rule is associated with and the RQA should not be sent for this QoS Flow.
5.7.1.5 QoS Flow mapping
The SMF performs the binding of PCC rules to QoS Flows based on the QoS and service requirements (as defined in TS 23.503 [45]). The SMF assigns the QFI for a new QoS Flow and derives its QoS profile, corresponding UPF instructions and QoS Rule(s) from the PCC rule(s) bound to the QoS Flow and other information provided by the PCF.
When applicable, the SMF provides the following information for the QoS Flow to the (R)AN:
– QFI;
– QoS profile as described in clause 5.7.1.2.
– optionally, Alternative QoS Profile(s) as described in clause 5.7.1.2a;
For each PCC rule bound to a QoS Flow, the SMF provides the following information to the UPF enabling classification, bandwidth enforcement and marking of User Plane traffic (the details are described in clause 5.8):
– a DL PDR containing the DL part of the SDF template;
– an UL PDR containing the UL part of the SDF template;
NOTE 1: If a DL PDR for an bidirectional SDF is associated with a QoS Flow other than the one associated with the default QoS rule and the UE has not received any instruction to use this QoS Flow for the SDF in uplink direction (i.e. neither a corresponding QoS rule is sent to the UE nor the Reflective QoS Indication is set in the PCC rule), it means that the UL PDR for the same SDF has to be associated with the QoS Flow associated with the default QoS rule.
– the PDR precedence value (see clause 5.7.1.9) for both PDRs is set to the precedence value of the PCC rule;
– QoS related information (e.g. MBR for an SDF, GFBR and MFBR for a GBR QoS Flow) as described in clause 5.8.2;
– the corresponding packet marking information (e.g. the QFI, the transport level packet marking value (e.g. the DSCP value of the outer IP header);
– optionally, the Reflective QoS Indication is included in the QER associated with the DL PDR (as described in clause 5.7.5.3).
For each PCC rule bound to a QoS Flow, when applicable, the SMF generates an explicitly signalled QoS rule (see clause 5.7.1.4) according to the following principles and provides it to the UE together with an add operation:
– A unique (for the PDU Session) QoS rule identifier is assigned;
– The QFI in the QoS rule is set to the QFI of the QoS Flow to which the PCC rule is bound;
– The Packet Filter Set of the QoS rule is generated from the UL SDF filters and optionally the DL SDF filters of the PCC rule (but only from those SDF filters that have an indication for being signalled to the UE, as defined in TS 23.503 [45]);
– The QoS rule precedence value is set to the precedence value of the PCC rule for which the QoS rule is generated;
– for a dynamically assigned QFI, the QoS Flow level QoS parameters (e.g. 5QI, GFBR, MFBR, Averaging Window, see TS 24.501 [47]) are signalled to UE in addition to the QoS rule(s) associated to the QoS Flow. The QoS Flow level QoS parameters of an existing QoS Flow may be updated based on the MBR and GBR information received in the PCC rule (MBR and GBR per SDF are however not provided to UE over N1 in the case of more than one SDF) or, if the PCF has not indicated differently, when Notification control or handover related signalling indicates that the QoS parameter the NG-RAN is currently fulfilling for the QoS Flow have changed (see clause 5.7.2.4).
Changes in the binding of PCC rules to QoS Flows as well as changes in the PCC rules or other information provided by the PCF can require QoS Flow changes which the SMF has to provide to (R)AN, UPF and/or UE. In the case of changes in the explicitly signalled QoS rules associated to a QoS Flow, the SMF provides the explicitly signalled QoS rules and their operation (i.e. add/modify/delete) to the UE.
NOTE 2: The SMF cannot provide, update or remove pre-configured QoS rules or UE derived QoS rules.
The principle for classification and marking of User Plane traffic and mapping of QoS Flows to AN resources is illustrated in Figure 5.7.1.5-1.
Figure 5.7.1.5-1: The principle for classification and User Plane marking for QoS Flows and mapping to AN Resources
In DL, incoming data packets are classified by the UPF based on the Packet Filter Sets of the DL PDRs in the order of their precedence (without initiating additional N4 signalling). The UPF conveys the classification of the User Plane traffic belonging to a QoS Flow through an N3 (and N9) User Plane marking using a QFI. The AN binds QoS Flows to AN resources (i.e. Data Radio Bearers of in the case of 3GPP RAN). There is no strict 1:1 relation between QoS Flows and AN resources. It is up to the AN to establish the necessary AN resources that QoS Flows can be mapped to, and to release them. The AN shall indicate to the SMF when the AN resources onto which a QoS Flow is mapped are released.
If no matching DL PDR is found, the UPF shall discard the DL data packet.
In UL:
– For a PDU Session of Type IP or Ethernet, the UE evaluates UL packets against the UL Packet Filters in the Packet Filter Set in the QoS rules based on the precedence value of QoS rules in increasing order until a matching QoS rule (i.e. whose Packet Filter matches the UL packet) is found.
– If no matching QoS rule is found, the UE shall discard the UL data packet.
– For a PDU Session of Type Unstructured, the default QoS rule does not contain a Packet Filter Set and allows all UL packets.
NOTE 3: Only the default QoS rule exist for a PDU Session of Type Unstructured.
The UE uses the QFI in the corresponding matching QoS rule to bind the UL packet to a QoS Flow. The UE then binds QoS Flows to AN resources.
5.7.1.6 DL traffic
The following characteristics apply for processing of DL traffic:
– UPF maps User Plane traffic to QoS Flows based on the PDRs.
– UPF performs Session-AMBR enforcement as specified in clause 5.7.1.8 and performs counting of packets for charging.
– UPF transmits the PDUs of the PDU Session in a single tunnel between 5GC and (R)AN, the UPF includes the QFI in the encapsulation header. In addition, UPF may include an indication for Reflective QoS activation in the encapsulation header.
– UPF performs transport level packet marking in DL on a per QoS Flow basis. The UPF uses the transport level packet marking value provided by the SMF (as described in clause 5.8.2.7).
– (R)AN maps PDUs from QoS Flows to access-specific resources based on the QFI and the associated 5G QoS profile, also taking into account the N3 tunnel associated with the DL packet.
NOTE: Packet Filters are not used for the mapping of QoS Flows onto access-specific resources in (R)AN.
– If Reflective QoS applies, the UE creates a new derived QoS rule as defined in clause 5.7.5.2.
5.7.1.7 UL Traffic
Following characteristics apply for processing of UL traffic:
– UE uses the stored QoS rules to determine mapping between UL User Plane traffic and QoS Flows. UE marks the UL PDU with the QFI of the QoS rule containing the matching Packet Filter and transmits the UL PDUs using the corresponding access specific resource for the QoS Flow based on the mapping provided by (R)AN. For NG-RAN, the UL behaviour is specified in clause 10.5.2 of TS 38.300 [27].
– (R)AN transmits the PDUs over N3 tunnel towards UPF. When passing an UL packet from (R)AN to CN, the (R)AN includes the QFI value, in the encapsulation header of the UL PDU, and selects the N3 tunnel.
– (R)AN performs transport level packet marking in the UL on a per QoS Flow basis with a transport level packet marking value that is determined based on the 5QI, the Priority Level (if explicitly signalled) and the ARP priority level of the associated QoS Flow.
– UPF verifies whether QFIs in the UL PDUs are aligned with the QoS Rules provided to the UE or implicitly derived by the UE in the case of Reflective QoS).
– UPF and UE perform Session-AMBR enforcement as specified in clause 5.7.1.8 and the UPF performs counting of packets for charging.
5.7.1.8 AMBR/MFBR enforcement and rate limitation
UL and DL Session-AMBR (see clause 5.7.2.6) shall be enforced by the UPF, if the UPF receives the Session-AMBR values from the SMF as described in clause 5.8.2.7 and clause 5.8.2.11.4.
For UL Classifier PDU Sessions, UL and DL Session-AMBR (see clause 5.7.2.6) shall be enforced in the SMF selected UPF that supports the UL Classifier functionality. In addition, the DL Session-AMBR shall be enforced separately in every UPF that terminates the N6 interface (i.e. without requiring interaction between the UPFs) (see clause 5.6.4).
For multi-homed PDU Sessions, UL and DL Session-AMBR shall be enforced in the UPF that supports the Branching Point functionality. In addition, the DL Session-AMBR shall be enforced separately in every UPF that terminates the N6 interface (i.e. without requiring interaction between the UPFs) (see clause 5.6.4).
NOTE: The DL Session-AMBR is enforced in every UPF terminating the N6 interface to reduce unnecessary transport of traffic which may be discarded by the UPF performing the UL Classifier/Branching Point functionality due to the amount of the DL traffic for the PDU Session exceeding the DL Session-AMBR. Discarding DL packets in the UL Classifier/Branching Point could cause erroneous PDU counting for support of charging
The (R)AN shall enforce UE-AMBR (see clause 5.7.2.6) in UL and DL per UE for Non-GBR QoS Flows.
The UE shall perform UL rate limitation on PDU Session basis for Non-GBR traffic using Session-AMBR, if the UE receives a Session-AMBR.
MBR per SDF is mandatory for GBR QoS Flows but optional for Non-GBR QoS Flows. The MBR is enforced in the UPF.
The MFBR is enforced in the UPF in the Downlink for GBR QoS Flows. The MFBR is enforced in the (R)AN in the Downlink and Uplink for GBR QoS Flows. For non-3GPP access, the UE should enforce MFBR in the Uplink for GBR QoS Flows.
The QoS control for Unstructured PDUs is performed at the PDU Session level and in this Release of the specification there is only support for maximum of one 5G QoS Flow per PDU Session of Type Unstructured.
When a PDU Session is set up for transferring unstructured PDUs, SMF provides the QFI which will be applied to any packet of the PDU Session to the UPF and UE.
5.7.1.9 Precedence Value
The QoS rule precedence value and the PDR precedence value determine the order in which a QoS rule or a PDR, respectively, shall be evaluated. The evaluation of the QoS rules or PDRs is performed in increasing order of their precedence value.
5.7.1.10 UE-Slice-MBR enforcement and rate limitation
If a supporting RAN receives for a UE a UE-Slice-MBR (see clause 5.7.2.6) for an S-NSSAI from the AMF, the RAN shall apply this UE-Slice-MBR for all PDU Sessions of that UE corresponding to the S-NSSAI which have an active user plane if feasible. In particular, the RAN shall enforce this UE-Slice-MBR as follows:
1) Whenever a request for a GBR QoS Flow establishment or modification is received, the RAN admission control shall ensure that the sum of the GFBR values of the admitted GBR QoS Flows is not exceeding the UE-Slice-MBR and, if the QoS Flow cannot be admitted, the RAN shall reject the establishment/modification of the QoS Flow.
2) The RAN shall ensure that the aggregated bitrate across all GBR and Non-GBR QoS Flows belonging to those PDU Sessions is not exceeding the UE-Slice-MBR, while always guaranteeing the GFBR of every GBR QoS Flow of those PDU Sessions as described in clause 5.7.2.5.
5.7.1.11 QoS aspects of home-routed roaming
In the case of home-routed roaming, the V-SMF may apply VPLMN policies related with the SLA negotiated with the HPLMN or with QoS values supported by the VPLMN. Such policies may result in a situation that the V-SMF does not accept the PDU Session or does not accept some of the QoS Flows requested by the H-SMF.
QoS constraints represent the QoS that the VPLMN can accept for the QoS Flow associated with the default QoS rule and the PDU Session based on SLA or based on QoS values supported by the VPLMN. The QoS constraints may contain 5QI and ARP for the QoS Flow associated with the default QoS rule and highest Session-AMBR accepted by the VPLMN.
At PDU Session Establishment for home-routed roaming, to reduce the risk of PDU Session establishment failure due to QoS from the HPLMN not being compliant with SLA, the V-SMF may provide the VPLMN local policy in QoS constraints to the H-SMF as specified in clause 4.3.2.2.2 of TS 23.502 [3].
For intra-5GS mobility with V-SMF insertion or V-SMF change (e.g. inter-PLMN mobility), as specified in clause 4.23 of TS 23.502 [3], the new/target V-SMF may validate the currently applied QoS against the QoS constraints. The new/target V-SMF provides QoS constraints to the H-SMF during the mobility procedure. The new/target V-SMF may temporarily accept a higher QoS even if the currently applied QoS exceeds the QoS constraints. Alternatively, for the QoS parameters related with the QoS constraints, the V-SMF may locally downgrade these values before providing the corresponding QoS profiles to 5G AN. The V-SMF may decide to release the PDU Session if the HPLMN does not provide updated QoS compliant with the QoS constraints after the mobility procedure.
For IMS voice service (e.g., the IMS DNN defined by the GSMA), the V-SMF, based on local policy, may override the ARP received from HPLMN over N16 if the ARP indicates priority not in line with the local policy in VPLMN. The ARP override in the serving PLMN applies to both the QoS Flow associated with the default QoS rule and the QoS Flows for IMS voice, to apply the same allocation and retention priority for all users (i.e., roamers and non-roamers). For MPS (clause 5.16.5), the same allocation and retention priority is applied to all MPS service users (i.e. roamers and non-roamers), when roaming agreements are in place and where regulatory requirements apply.
5.7.2 5G QoS Parameters
5.7.2.1 5QI
A 5QI is a scalar that is used as a reference to 5G QoS characteristics defined in clause 5.7.4, i.e. access node-specific parameters that control QoS forwarding treatment for the QoS Flow (e.g. scheduling weights, admission thresholds, queue management thresholds, link layer protocol configuration, etc.).
Standardized 5QI values have one-to-one mapping to a standardized combination of 5G QoS characteristics as specified in Table 5.7.4-1.
The 5G QoS characteristics for pre-configured 5QI values are pre-configured in the AN.
Standardized or pre-configured 5G QoS characteristics, are indicated through the 5QI value, and are not signalled on any interface, unless certain 5G QoS characteristics are modified as specified in clauses 5.7.3.3, 5.7.3.4, 5.7.3.6, and 5.7.3.7.
The 5G QoS characteristics for QoS Flows with dynamically assigned 5QI are signalled as part of the QoS profile.
NOTE: On N3, each PDU (i.e. in the tunnel used for the PDU Session) is associated with one 5QI via the QFI carried in the encapsulation header.
5.7.2.2 ARP
The QoS parameter ARP contains information about the priority level, the pre-emption capability and the pre-emption vulnerability. This allows deciding whether a QoS Flow establishment/modification/handover may be accepted or needs to be rejected in the case of resource limitations (typically used for admission control of GBR traffic). It may also be used to decide which existing QoS Flow to pre-empt during resource limitations, i.e. which QoS Flow to release to free up resources.
The ARP priority level defines the relative importance of a QoS Flow. The range of the ARP priority level is 1 to 15 with 1 as the highest priority.
The ARP priority levels 1-8 should only be assigned to QoS Flows for services that are authorized to receive prioritized treatment within an operator domain (i.e. that are authorized by the serving network). The ARP priority levels 9-15 may be assigned to QoS Flows for services that are authorized by the home network and thus applicable when a UE is roaming.
NOTE: This ensures that future releases may use ARP priority level 1-8 to indicate e.g. emergency and other priority services within an operator domain in a backward compatible manner. This does not prevent the use of ARP priority level 1-8 in roaming situation in the case that appropriate roaming agreements exist that ensure a compatible use of these priority levels.
The ARP pre-emption capability defines whether a QoS Flow may get resources that were already assigned to another QoS Flow with a lower priority. The ARP pre-emption vulnerability defines whether a QoS Flow may lose the resources assigned to it in order to admit a QoS Flow with higher priority. The ARP pre-emption capability and the ARP pre-emption vulnerability shall be either set to ‘enabled’ or ‘disabled’.
The ARP pre-emption vulnerability of the QoS Flow which the default QoS rule is associated with should be set appropriately to minimize the risk of a release of this QoS Flow.
The details of how the SMF sets the ARP for a QoS Flow are further described in clause 5.7.2.7.
5.7.2.3 RQA
The Reflective QoS Attribute (RQA) is an optional parameter which indicates that certain traffic (not necessarily all) carried on this QoS Flow is subject to Reflective QoS. Only when the RQA is signalled for a QoS Flow, the (R)AN enables the transfer of the RQI for AN resource corresponding to this QoS Flow. The RQA may be signalled to NG-RAN via the N2 reference point at UE context establishment in NG-RAN and at QoS Flow establishment or modification.
5.7.2.4 Notification control
5.7.2.4.1 General
The QoS Parameter Notification control indicates whether notifications are requested from the NG-RAN when the "GFBR can no longer (or can again) be guaranteed" for a QoS Flow during the lifetime of the QoS Flow. Notification control may be used for a GBR QoS Flow if the application traffic is able to adapt to the change in the QoS (e.g. if the AF is capable to trigger rate adaptation).
The SMF shall only enable Notification control when the QoS Notification Control parameter is set in the PCC rule (received from the PCF) that is bound to the QoS Flow. The Notification control parameter is signalled to the NG-RAN as part of the QoS profile.
5.7.2.4.1a Notification Control without Alternative QoS Profiles
If, for a given GBR QoS Flow, Notification control is enabled and the NG-RAN determines that the GFBR, the PDB or the PER of the QoS profile cannot be fulfilled, NG-RAN shall send a notification towards SMF that the "GFBR can no longer be guaranteed". Furthermore, the NG-RAN shall keep the QoS Flow (i.e. while the NG-RAN is not fulfilling the requested QoS profile for this QoS Flow), unless specific conditions at the NG-RAN require the release of the NG-RAN resources for this GBR QoS Flow, e.g. due to Radio link failure or RAN internal congestion. The NG-RAN should try to fulfil the GFBR, the PDB and the PER of the QoS profile again.
NOTE 1: NG-RAN can decide that the "GFBR can no longer be guaranteed" based on, e.g. measurements like queuing delay or system load.
Upon receiving a notification from the NG-RAN that the "GFBR can no longer be guaranteed", the SMF may forward the notification to the PCF, see TS 23.503 [45].
When the NG-RAN determines that the GFBR, the PDB and the PER of the QoS profile can be fulfilled again for a QoS Flow (for which a notification that the "GFBR can no longer be guaranteed" has been sent), the NG-RAN shall send a notification, informing the SMF that the "GFBR can be guaranteed" again and the SMF may forward the notification to the PCF, see TS 23.503 [45]. The NG-RAN shall send a subsequent notification that the "GFBR can no longer be guaranteed" whenever necessary.
NOTE 2: It is assumed that NG-RAN implementation will apply some hysteresis before determining that the "GFBR can be guaranteed again" and therefore a frequent signalling of "GFBR can be guaranteed again" followed by "GFBR can no longer be guaranteed" is not expected.
NOTE 3: If the QoS Flow is modified, the NG-RAN restarts the check whether the "GFBR can no longer be guaranteed" according to the updated QoS profile. If the Notification control parameter is not included in the updated QoS profile, the Notification control is disabled.
During a handover, the Source NG-RAN does not inform the Target NG-RAN about whether the Source NG-RAN has sent a notification for a QoS Flow that the "GFBR can no longer be guaranteed". The Target NG-RAN performs admission control rejecting any QoS Flows for which resources cannot be permanently allocated. The accepted QoS Flows are included in the N2 Path Switch Request or N2 Handover Request Acknowledge message from the NG-RAN to the AMF. The SMF shall interpret the fact that a QoS Flow is listed as transferred QoS Flow in the Nsmf_PDUSession_UpdateSMContext Request received from the AMF as a notification that "GFBR can be guaranteed again" for this QoS Flow unless the SMF is also receiving a reference to an Alternative QoS Profile for this QoS Flow (which is described in clause 5.7.2.4.2). After the handover is successfully completed, the Target NG-RAN shall send a subsequent notification that the "GFBR can no longer be guaranteed" for such a QoS Flow whenever necessary. If the SMF has previously notified the PCF that the "GFBR can no longer be guaranteed" and the SMF does not receive an explicit notification that the "GFBR can no longer be guaranteed" for that QoS Flow from the Target NG-RAN within a configured time, the SMF shall notify the PCF that the "GFBR can be guaranteed again".
5.7.2.4.1b Notification control with Alternative QoS Profiles
If, for a given GBR QoS Flow, Notification control is enabled and the NG-RAN has received a list of Alternative QoS Profile(s) for this QoS Flow and supports the Alternative QoS Profile handling, the following shall apply:
1) If the NG-RAN determines that the GFBR, the PDB or the PER of the QoS profile cannot be fulfilled, NG-RAN shall send a notification towards SMF that the "GFBR can no longer be guaranteed". Before sending a notification that the "GFBR can no longer be guaranteed" towards the SMF, the NG-RAN shall check whether the GFBR, the PDB and the PER that the NG-RAN currently fulfils match any of the Alternative QoS Profile(s) in the indicated priority order. If there is a match, the NG-RAN shall indicate the reference to the matching Alternative QoS Profile with the highest priority together with the notification to the SMF.
If there is no match, the NG-RAN shall send a notification that the "GFBR can no longer be guaranteed" towards the SMF indicating that the lowest Alternative QoS Profile cannot be fulfilled (unless specific conditions at the NG-RAN require the release of the NG-RAN resources for this GBR QoS Flow, e.g. due to Radio link failure or RAN internal congestion).
2) If a notification that the "GFBR can no longer be guaranteed" has been sent to the SMF and the NG-RAN determines that the currently fulfilled GFBR, PDB or PER are different (better or worse) from the situation indicated in the last notification, the NG-RAN shall send a notification (i.e. "GFBR can no longer be guaranteed" or "GFBR can be guaranteed again") to the SMF and indicate the current situation (unless specific conditions at the NG-RAN require the release of the NG-RAN resources for this GBR QoS Flow, e.g. due to Radio link failure or RAN internal congestion).
NOTE 1: The current situation is either that the QoS Profile can be fulfilled (which is implicitly indicated by the "GFBR can be guaranteed again" notification itself), that a different Alternative QoS Profile can be fulfilled, or that the lowest priority Alternative QoS Profile cannot be fulfilled.
3)- The NG-RAN should always try to fulfil the QoS profile and, if this is not possible, any Alternative QoS Profile that has higher priority.
NOTE 2: In order to avoid a too frequent signalling to the SMF, it is assumed that NG-RAN implementation can apply hysteresis (e.g. via a configurable time interval) before notifying the SMF that the currently fulfilled values match the QoS Profile or a different Alternative QoS Profile of higher priority. It is also assumed that the PCF has ensured that the QoS values within the different Alternative QoS Profile(s) are not too close to each other.
4) Upon receiving a notification from the NG-RAN, the SMF may inform the PCF. If it does so, the SMF shall indicate the currently fulfilled situation to the PCF. See TS 23.503 [45].
5) If the PCF has not indicated differently, the SMF uses NAS signalling (that is sent transparently through the RAN) to inform the UE about changes in the QoS parameters (i.e. 5QI, GFBR, MFBR) that the NG-RAN is currently fulfilling for the QoS Flow after Notification control has occurred.
5.7.2.4.2 Usage of Notification control with Alternative QoS Profiles at handover
During handover, the prioritized list of Alternative QoS Profile(s) (if available) is provided to the Target NG-RAN per QoS Flow in addition to the QoS profile. If the Target NG-RAN is not able to guarantee the GFBR, the PDB and the PER included in the QoS profile and if Alternative QoS Profiles are provided to the Target NG-RAN and the Target NG-RAN supports Alternative QoS Profiles, the Target NG-RAN checks whether the GFBR, the PDB and the PER values that it can fulfil match any of the Alternative QoS Profile(s) taking the priority order into account. If there is a match between one of the Alternative QoS Profiles and the GFBR, the PDB and the PER values that Target NG-RAN can fulfil, the Target NG-RAN shall accept the QoS Flow and indicate the reference to that Alternative QoS Profile to the Source NG-RAN.
If there is no match to any Alternative QoS Profile, the Target NG-RAN rejects QoS Flows for which the Target NG-RAN is not able to guarantee the GFBR, the PDB and the PER included in the QoS profile.
After the handover is completed and a QoS Flow has been accepted by the Target NG-RAN based on an Alternative QoS Profile, the Target NG-RAN shall treat this QoS Flow in the same way as if it had sent a notification that the "GFBR can no longer be guaranteed" with a reference to that Alternative QoS Profile to the SMF (as described in clause 5.7.2.4.1b).
If a QoS Flow has been accepted by the Target NG-RAN based on an Alternative QoS Profile, the reference to the matching Alternative QoS Profile is provided from the Target NG-RAN to the AMF (which forwards the message to the SMF) during the Xn and N2 based handover procedures as described in TS 23.502 [3]. After the handover is completed successfully, the SMF shall send a notification to the PCF that the "GFBR can no longer be guaranteed" for a QoS Flow (see TS 23.503 [45] for details) if the SMF has received a reference to an Alternative QoS Profile and this reference indicates a change in the previously notified state of this QoS Flow. If the PCF has not indicated differently, the SMF shall also use NAS signalling (that is sent transparently through the RAN) to inform the UE about the QoS parameters (i.e. 5QI, GFBR, MFBR) corresponding to the new state of the QoS Flow.
NOTE: A state change for the QoS Flow comprises a change from QoS profile fulfilled to Alternative QoS Profile fulfilled as well as the state change between fulfilled Alternative QoS Profiles.
If a QoS Flow has been accepted by the Target NG-RAN based on the QoS Profile, the SMF shall interpret the fact that a QoS Flow is listed as transferred QoS Flow in the message received from the AMF as a notification that "GFBR can be guaranteed again" for this QoS Flow. After the handover is successfully completed, the Target NG-RAN performs as described in clause 5.7.2.4.1b. If the SMF has previously notified the PCF that the "GFBR can no longer be guaranteed" and the SMF does not receive an explicit notification that the "GFBR can no longer be guaranteed" for that QoS Flow from the Target NG-RAN within a configured time, the SMF shall notify the PCF that the "GFBR can be guaranteed again".
If a QoS Flow has been accepted by the Target NG-RAN and SMF did not receive from the Target NG-RAN a reference to any Alternative QoS Profile and the SMF has previously informed the UE about QoS parameters corresponding to any of the Alternative QoS Profile(s), the SMF shall use NAS signalling to inform the UE about the QoS parameters corresponding to the QoS Profile.
5.7.2.4.3 Usage of Notification control with Alternative QoS Profiles during QoS Flow establishment and modification
During QoS Flow establishment and modification, a prioritized list of Alternative QoS Profile(s) can be provided to the NG-RAN for the QoS Flow in addition to the QoS profile. If the NG-RAN is not able to guarantee the GFBR, the PDB and the PER included in the QoS profile and if Alternative QoS Profiles are provided to the NG-RAN and the NG-RAN supports Alternative QoS Profiles, the NG-RAN shall check whether the GFBR, the PDB and the PER values that it can fulfil match at least one of the Alternative QoS Profile(s) taking the priority order into account. If there is a match between one of the Alternative QoS Profiles and the GFBR, the PDB and the PER values that the NG-RAN can fulfil, the NG-RAN shall accept the QoS Flow and indicate the reference to that Alternative QoS Profile to the SMF. If there is no match to any Alternative QoS Profile, the NG-RAN shall reject the QoS Flow establishment or modification.
After a successful QoS Flow establishment or modification during which the NG-RAN indicated that the currently fulfilled QoS matches one of the Alternative QoS Profiles, the NG-RAN shall treat this QoS Flow in the same way as if it had sent a notification that the "GFBR can no longer be guaranteed" with a reference to that Alternative QoS Profile to the SMF (as described in clause 5.7.2.4.1b).
If the SMF has received a reference to an Alternative QoS Profile during QoS Flow establishment and modification the SMF may inform the PCF about it (as described in TS 23.503 [45]).
If the PCF has not indicated differently, the SMF shall use NAS signalling (that is sent transparently through the RAN) to inform the UE about the QoS parameters (i.e. 5QI, GFBR, MFBR) corresponding to the referenced Alternative QoS Profile.
5.7.2.5 Flow Bit Rates
For GBR QoS Flows only, the following additional QoS parameters exist:
– Guaranteed Flow Bit Rate (GFBR) – UL and DL;
– Maximum Flow Bit Rate (MFBR) — UL and DL.
The GFBR denotes the bit rate that is guaranteed to be provided by the network to the QoS Flow over the Averaging Time Window. The MFBR limits the bit rate to the highest bit rate that is expected by the QoS Flow (e.g. excess traffic may get discarded or delayed by a rate shaping or policing function at the UE, RAN, UPF). Bit rates above the GFBR value and up to the MFBR value, may be provided with relative priority determined by the Priority Level of the QoS Flows (see clause 5.7.3.3).
GFBR and MFBR are signalled to the (R)AN in the QoS Profile and signalled to the UE as QoS Flow level QoS parameter (as specified in TS 24.501 [47]) for each individual QoS Flow.
NOTE 1: The GFBR is recommended as the lowest acceptable service bitrate where the service will survive.
NOTE 2: For each QoS Flow of Delay-critical GBR resource type, the SMF can ensure that the GFBR of the QoS Flow can be achieved with the MDBV of the QoS Flow using the QoS Flow binding functionality described in clause 6.1.3.2.4 of TS 23.503 [45].
NOTE 3: The network can set MFBR larger than GFBR for a particular QoS Flow based on operator policy and the knowledge of the end point capability, i.e. support of rate adaptation at application / service level.
5.7.2.6 Aggregate Bit Rates
Each PDU Session of a UE is associated with the following aggregate rate limit QoS parameter:
– per Session Aggregate Maximum Bit Rate (Session-AMBR).
The Session-AMBR is signalled to the appropriate UPF entity/ies to the UE and to the (R)AN (to enable the calculation of the UE-AMBR). The Session-AMBR limits the aggregate bit rate that can be expected to be provided across all Non-GBR QoS Flows for a specific PDU Session. The Session-AMBR is measured over an AMBR averaging window which is a standardized value. The Session-AMBR is not applicable to GBR QoS Flows.
Each UE is associated with the following aggregate rate limit QoS parameter:
– per UE Aggregate Maximum Bit Rate (UE-AMBR).
The UE-AMBR limits the aggregate bit rate that can be expected to be provided across all Non-GBR QoS Flows of a UE. Each (R)AN shall set its UE-AMBR to the sum of the Session-AMBR of all PDU Sessions with active user plane to this (R)AN up to the value of the UE-AMBR received from AMF. The UE-AMBR is a parameter provided to the (R)AN by the AMF based on the value of the subscribed UE-AMBR retrieved from UDM or the dynamic serving network UE-AMBR retrieved from PCF (e.g. for roaming subscriber). The AMF provides the UE-AMBR provided by PCF to (R)AN if available. The UE-AMBR is measured over an AMBR averaging window which is a standardized value. The UE-AMBR is not applicable to GBR QoS Flows.
Each group of PDU Sessions of the UE for the same slice (S-NSSAI) may be associated with the following aggregate rate limit QoS parameter:
– per UE per Slice-Maximum Bit Rate (UE-Slice-MBR).
The UE-Slice-MBR limits the aggregate bit rate that can be expected to be provided across all GBR and Non-GBR QoS Flows corresponding to PDU Sessions of the UE for the same slice (S-NSSAI) which have an active user plane. Each supporting RAN shall set its UE-Slice-MBR to the sum of the Session-AMBR and MFBR for GBR QoS Flows of all PDU Sessions corresponding to the slice (S-NSSAI) with active user plane to this RAN up to the value of the UE-Slice-MBR corresponding to the slice (S-NSSAI) received from AMF. The UE-Slice-MBR is measured over an AMBR averaging window which is a standardized value. The UE-Slice-MBR is an optional parameter provided to the RAN by the AMF as described in clause 5.15.13.
NOTE: The AMBR averaging window is only applied to Session-AMBR, UE-AMBR and UE-Slice-MBR measurement and the AMBR averaging windows for Session-AMBR and UE-AMBR are standardised to the same value.
5.7.2.7 Default values
For each PDU Session Setup, the SMF retrieves the subscribed Session-AMBR values as well as the subscribed default values for the 5QI and the ARP and optionally, the 5QI Priority Level, from the UDM. The subscribed default 5QI value shall be a Non-GBR 5QI from the standardized value range.
NOTE 1: The 5QI Priority Level can be added to the subscription information to achieve an overwriting of the standardized or preconfigured 5QI Priority Level e.g. in scenarios where dynamic PCC is not deployed or the PCF is unavailable or unreachable.
The SMF may change the subscribed values for the default 5QI and the ARP and if received, the 5QI Priority Level, based on interaction with the PCF as described in TS 23.503 [45] or, if dynamic PCC is not deployed, based on local configuration, to set QoS parameters for the QoS Flow associated with the default QoS rule.
For QoS Flow(s) of the PDU Session other than the QoS Flow associated with the default QoS rule, the SMF shall set the ARP priority level, the ARP pre-emption capability and the ARP pre-emption vulnerability to the respective values in the PCC rule(s) bound to that QoS Flow (as described in TS 23.503 [45]). If dynamic PCC is not deployed, the SMF shall set the ARP priority level, the ARP pre-emption capability and the ARP pre-emption vulnerability based on local configuration.
NOTE 2: The local configuration in the SMF can e.g. make use of the subscribed value for the ARP priority level and apply locally configured values for the ARP pre-emption capability and ARP pre-emption vulnerability.
If dynamic PCC is not deployed, the SMF can have a DNN based configuration to enable the establishment of a GBR QoS Flow as the QoS Flow that is associated with the default QoS rule. This configuration contains a standardized GBR 5QI as well as GFBR and MFBR for UL and DL.
NOTE 3: Interworking with EPS is not possible for a PDU Session with a GBR QoS Flow as the QoS Flow that is associated with the default QoS rule.
The SMF may change the subscribed Session-AMBR values (for UL and/or DL), based on interaction with the PCF as described in TS 23.503 [45] or, if dynamic PCC is not deployed, based on local configuration, to set the Session-AMBR values for the PDU Session.
5.7.2.8 Maximum Packet Loss Rate
The Maximum Packet Loss Rate (UL, DL) indicates the maximum rate for lost packets of the QoS Flow that can be tolerated in the uplink and downlink direction. This is provided to the QoS Flow if it is compliant to the GFBR
NOTE: In this Release of the specification, the Maximum Packet Loss Rate (UL, DL) can only be provided for a GBR QoS Flow belonging to voice media.
5.7.2.9 Wireline access network specific 5G QoS parameters
QoS parameters that are applicable only for or wireline access networks (W-5GAN) are specified in TS 23.316 [84].
5.7.3 5G QoS characteristics
5.7.3.1 General
This clause specifies the 5G QoS characteristics associated with 5QI. The characteristics describe the packet forwarding treatment that a QoS Flow receives edge-to-edge between the UE and the UPF in terms of the following performance characteristics:
1 Resource type (Non-GBR, GBR, Delay-critical GBR);
2 Priority Level;
3 Packet Delay Budget (including Core Network Packet Delay Budget);
4 Packet Error Rate;
5 Averaging window (for GBR and Delay-critical GBR resource type only);
6 Maximum Data Burst Volume (for Delay-critical GBR resource type only).
The 5G QoS characteristics should be understood as guidelines for setting node specific parameters for each QoS Flow e.g. for 3GPP radio access link layer protocol configurations.
Standardized or pre-configured 5G QoS characteristics, are indicated through the 5QI value, and are not signalled on any interface, unless certain 5G QoS characteristics are modified as specified in clauses 5.7.3.3, 5.7.3.4, 5.7.3.6, and 5.7.3.7.
NOTE: As there are no default values specified, pre-configured 5G QoS characteristics have to include all of the characteristics listed above.
Signalled 5G QoS characteristics are provided as part of the QoS profile and shall include all of the characteristics listed above.
5.7.3.2 Resource Type
The resource type determines if dedicated network resources related to a QoS Flow-level Guaranteed Flow Bit Rate (GFBR) value are permanently allocated (e.g. by an admission control function in a radio base station).
GBR QoS Flows are therefore typically authorized "on demand" which requires dynamic policy and charging control. A GBR QoS Flow uses either the GBR resource type or the Delay-critical GBR resource type. The definition of PDB and PER are different for GBR and Delay-critical GBR resource types, and the MDBV parameter applies only to the Delay-critical GBR resource type.
A Non-GBR QoS Flow may be pre-authorized through static policy and charging control. A Non-GBR QoS Flow uses only the Non-GBR resource type.
5.7.3.3 Priority Level
The Priority Level associated with 5G QoS characteristics indicates a priority in scheduling resources among QoS Flows. The lowest Priority Level value corresponds to the highest priority.
The Priority Level shall be used to differentiate between QoS Flows of the same UE, and it shall also be used to differentiate between QoS Flows from different UEs.
In the case of congestion, when all QoS requirements cannot be fulfilled for one or more QoS Flows, the Priority Level shall be used to select for which QoS Flows the QoS requirements are prioritised such that a QoS Flow with Priority Level value N is priorized over QoS Flows with higher Priority Level values (i.e. N+1, N+2, etc).In the case of no congestion, the Priority Level should be used to define the resource distribution between QoS Flows. In addition, the scheduler may prioritize QoS Flows based on other parameters (e.g. resource type, radio condition) in order to optimize application performance and network capacity.
Every standardized 5QI is associated with a default value for the Priority Level -specified in QoS characteristics Table 5.7.4.1). Priority Level may also be signalled together with a standardized 5QI to the -R)AN, and if it is received, it shall be used instead of the default value.
Priority Level may also be signalled together with a pre-configured 5QI to the (R)AN, and if it is received, it shall be used instead of the pre-configured value.
5.7.3.4 Packet Delay Budget
The Packet Delay Budget (PDB) defines an upper bound for the time that a packet may be delayed between the UE and the N6 termination point at the UPF. The PDB applies to the DL packet received by the UPF over the N6 interface, and to the UL packet sent by the UE. For a certain 5QI the value of the PDB is the same in UL and DL. In the case of 3GPP access, the PDB is used to support the configuration of scheduling and link layer functions (e.g. the setting of scheduling priority weights and HARQ target operating points). For GBR QoS Flows using the Delay-critical resource type, a packet delayed more than PDB is counted as lost if the data burst is not exceeding the MDBV within the period of PDB and the QoS Flow is not exceeding the GFBR. For GBR QoS Flows with GBR resource type not exceeding GFBR, 98 percent of the packets shall not experience a delay exceeding the 5QI’s PDB.
The 5G Access Network Packet Delay Budget (5G-AN PDB) is determined by subtracting a static value for the Core Network Packet Delay Budget (CN PDB), which represents the delay between any N6 termination point at the UPF (for any UPF that may possibly be selected for the PDU Session) and the 5G-AN from a given PDB.
NOTE 1: For a standardized 5QI, the static value for the CN PDB is specified in the QoS characteristics Table 5.7.4-1.
NOTE 2: For a non-standardized 5QI, the static value for the CN PDB is homogeneously configured in the network.
For GBR QoS Flows using the Delay-critical resource type, in order to obtain a more accurate delay budget PDB available for the NG-RAN, a dynamic value for the CN PDB, which represents the delay between the UPF terminating N6 for the QoS Flow and the 5G-AN, can be used. If used for a QoS Flow, the NG-RAN shall apply the dynamic value for the CN PDB instead of the static value for the CN PDB (which is only related to the 5QI). Different dynamic value for CN PDB may be configured per uplink and downlink direction.
NOTE 3: The configuration of transport network on CN tunnel can be different per UL and DL, which can be different value for CN PDB per UL and DL.
NOTE 4: It is expected that the UPF deployment ensures that the dynamic value for the CN PDB is not larger than the static value for the CN PDB. This avoids that the functionality that is based on the 5G-AN PDB (e.g. MDBV, NG-RAN scheduler) has to handle an unexpected value.
The dynamic value for the CN PDB of a Delay-critical GBR 5QI may be configured in the network in two ways:
– Configured in each NG-RAN node, based on a variety of inputs such as different IP address(es) or TEID range of UPF terminating the N3 tunnel and based on different combinations of PSA UPF to NG-RAN under consideration of any potential I-UPF, etc;
– Configured in the SMF, based on different combinations of PSA UPF to NG-RAN under consideration of any potential I-UPF. The dynamic value for the CN PDB for a particular QoS Flow shall be signalled to NG-RAN (during PDU Session Establishment, PDU Session Modification, Xn/N2 handover and the Service Request procedures) when the QoS Flow is established or the dynamic value for the CN PDB of a QoS Flow changes, e.g. when an I-UPF is inserted by the SMF.
If the NG-RAN node is configured locally with a dynamic value for the CN PDB for a Delay-critical GBR 5QI, and receives a different value via N2 signalling for a QoS Flow with the same 5QI, local configuration in RAN node determines which value takes precedence.
Services using a GBR QoS Flow and sending at a rate smaller than or equal to the GFBR can in general assume that congestion related packet drops will not occur.
NOTE 5: Exceptions (e.g. transient link outages) can always occur in a radio access system which may then lead to congestion related packet drops. Packets surviving congestion related packet dropping may still be subject to non-congestion related packet losses (see PER below).
Services using Non-GBR QoS Flows should be prepared to experience congestion-related packet drops and delays. In uncongested scenarios, 98 percent of the packets should not experience a delay exceeding the 5QI’s PDB.
The PDB for Non-GBR and GBR resource types denotes a "soft upper bound" in the sense that an "expired" packet, e.g. a link layer SDU that has exceeded the PDB, does not need to be discarded and is not added to the PER. However, for a Delay-critical GBR resource type, packets delayed more than the PDB are added to the PER and can be discarded or delivered depending on local decision.
5.7.3.5 Packet Error Rate
The Packet Error Rate (PER) defines an upper bound for the rate of PDUs (e.g. IP packets) that have been processed by the sender of a link layer protocol (e.g. RLC in RAN of a 3GPP access) but that are not successfully delivered by the corresponding receiver to the upper layer (e.g. PDCP in RAN of a 3GPP access). Thus, the PER defines an upper bound for a rate of non-congestion related packet losses. The purpose of the PER is to allow for appropriate link layer protocol configurations (e.g. RLC and HARQ in RAN of a 3GPP access). For every 5QI the value of the PER is the same in UL and DL. For GBR QoS Flows with Delay-critical GBR resource type, a packet which is delayed more than PDB is counted as lost, and included in the PER unless the data burst is exceeding the MDBV within the period of PDB or the QoS Flow is exceeding the GFBR.
5.7.3.6 Averaging Window
Each GBR QoS Flow shall be associated with an Averaging window. The Averaging window represents the duration over which the GFBR and MFBR shall be calculated (e.g. in the (R)AN, UPF, UE).
Every standardized 5QI (of GBR and Delay-critical GBR resource type) is associated with a default value for the Averaging window (specified in QoS characteristics Table 5.7.4.1). The averaging window may also be signalled together with a standardized 5QI to the (R)AN and UPF, and if it is received, it shall be used instead of the default value.
The Averaging window may also be signalled together with a pre-configured 5QI to the (R)AN, and if it is received, it shall be used instead of the pre-configured value.
5.7.3.7 Maximum Data Burst Volume
Each GBR QoS Flow with Delay-critical resource type shall be associated with a Maximum Data Burst Volume (MDBV).
MDBV denotes the largest amount of data that the 5G-AN is required to serve within a period of 5G-AN PDB.
Every standardized 5QI (of Delay-critical GBR resource type) is associated with a default value for the MDBV (specified in QoS characteristics Table 5.7.4.1). The MDBV may also be signalled together with a standardized 5QI to the (R)AN, and if it is received, it shall be used instead of the default value.
The MDBV may also be signalled together with a pre-configured 5QI to the (R)AN, and if it is received, it shall be used instead of the pre-configured value.
5.7.4 Standardized 5QI to QoS characteristics mapping
Standardized 5QI values are specified for services that are assumed to be frequently used and thus benefit from optimized signalling by using standardized QoS characteristics. Dynamically assigned 5QI values (which require a signalling of QoS characteristics as part of the QoS profile) can be used for services for which standardized 5QI values are not defined. The one-to-one mapping of standardized 5QI values to 5G QoS characteristics is specified in table 5.7.4-1.
Table 5.7.4-1: Standardized 5QI to QoS characteristics mapping
|
5QI Value |
Resource Type |
Default Priority Level |
Packet Delay Budget (NOTE 3) |
Packet Error Rate |
Default Maximum Data Burst Volume (NOTE 2) |
Default Averaging Window |
Example Services |
|
1 |
GBR |
20 |
100 ms (NOTE 11, NOTE 13) |
10-2 |
N/A |
2000 ms |
Conversational Voice |
|
2 |
(NOTE 1) |
40 |
150 ms (NOTE 11, NOTE 13) |
10-3 |
N/A |
2000 ms |
Conversational Video (Live Streaming) |
|
3 |
30 |
50 ms (NOTE 11, NOTE 13) |
10-3 |
N/A |
2000 ms |
Real Time Gaming, V2X messages (see TS 23.287 [121]). Electricity distribution – medium voltage, Process automation monitoring |
|
|
4 |
50 |
300 ms (NOTE 11, NOTE 13) |
10-6 |
N/A |
2000 ms |
Non-Conversational Video (Buffered Streaming) |
|
|
65 (NOTE 9, NOTE 12) |
7 |
75 ms (NOTE 7, NOTE 8) |
10-2 |
N/A |
2000 ms |
Mission Critical user plane Push To Talk voice (e.g. MCPTT) |
|
|
66 (NOTE 12) |
20 |
100 ms (NOTE 10, NOTE 13) |
10-2 |
N/A |
2000 ms |
Non-Mission-Critical user plane Push To Talk voice |
|
|
67 (NOTE 12) |
15 |
100 ms (NOTE 10, NOTE 13) |
10-3 |
N/A |
2000 ms |
Mission Critical Video user plane |
|
|
75 (NOTE 14) |
|||||||
|
71 |
56 |
150 ms (NOTE 11, NOTE 13, NOTE 15) |
10-6 |
N/A |
2000 ms |
"Live" Uplink Streaming (e.g. TS 26.238 [76]) |
|
|
72 |
56 |
300 ms (NOTE 11, NOTE 13, NOTE 15) |
10-4 |
N/A |
2000 ms |
"Live" Uplink Streaming (e.g. TS 26.238 [76]) |
|
|
73 |
56 |
300 ms (NOTE 11, NOTE 13, NOTE 15) |
10-8 |
N/A |
2000 ms |
"Live" Uplink Streaming (e.g. TS 26.238 [76]) |
|
|
74 |
56 |
500 ms (NOTE 11, NOTE 15) |
10-8 |
N/A |
2000 ms |
"Live" Uplink Streaming (e.g. TS 26.238 [76]) |
|
|
76 |
56 |
500 ms (NOTE 11, NOTE 13, NOTE 15) |
10-4 |
N/A |
2000 ms |
"Live" Uplink Streaming (e.g. TS 26.238 [76]) |
|
|
5 |
Non-GBR |
10 |
100 ms NOTE 10, NOTE 13) |
10-6 |
N/A |
N/A |
IMS Signalling |
|
6 |
(NOTE 1) |
60 |
300 ms (NOTE 10, NOTE 13) |
10-6 |
N/A |
N/A |
Video (Buffered Streaming) TCP-based (e.g. www, e-mail, chat, ftp, p2p file sharing, progressive video, etc.) |
|
7 |
70 |
100 ms (NOTE 10, NOTE 13) |
10-3 |
N/A |
N/A |
Voice, Video (Live Streaming) Interactive Gaming |
|
|
8 |
80 |
300 ms (NOTE 13) |
10-6 |
N/A |
N/A |
Video (Buffered Streaming) TCP-based (e.g. www, e-mail, chat, ftp, p2p file sharing, progressive |
|
|
9 |
90 |
video, etc.) |
|||||
|
10 |
90 |
1100ms (NOTE 13) (NOTE 17) |
10-6 |
N/A |
N/A |
Video (Buffered Streaming) TCP-based (e.g. www, e-mail, chat, ftp, p2p file sharing, progressive video, etc.) and any service that can be used over satellite access type with these characteristics |
|
|
69 (NOTE 9, NOTE 12) |
5 |
60 ms (NOTE 7, NOTE 8) |
10-6 |
N/A |
N/A |
Mission Critical delay sensitive signalling (e.g. MC-PTT signalling) |
|
|
70 (NOTE 12) |
55 |
200 ms (NOTE 7, NOTE 10) |
10-6 |
N/A |
N/A |
Mission Critical Data (e.g. example services are the same as 5QI 6/8/9) |
|
|
79 |
65 |
50 ms (NOTE 10, NOTE 13) |
10-2 |
N/A |
N/A |
V2X messages (see TS 23.287 [121]) |
|
|
80 |
68 |
10 ms (NOTE 5, NOTE 10) |
10-6 |
N/A |
N/A |
Low Latency eMBB applications Augmented Reality |
|
|
82 |
Delay-critical GBR |
19 |
10 ms |
10-4 |
255 bytes |
2000 ms |
Discrete Automation (see TS 22.261 [2]) |
|
83 |
22 |
10 ms |
10-4 |
1354 bytes (NOTE 3) |
2000 ms |
Discrete Automation (see TS 22.261 [2]); V2X messages (UE – RSU Platooning, Advanced Driving: Cooperative Lane Change with low LoA. See TS 22.186 [111], TS 23.287 [121]) |
|
|
84 |
24 |
30 ms (NOTE 6) |
10-5 |
1354 bytes (NOTE 3) |
2000 ms |
Intelligent transport systems (see TS 22.261 [2]) |
|
|
85 |
21 |
5 ms (NOTE 5) |
10-5 |
255 bytes |
2000 ms |
Electricity Distribution- high voltage (see TS 22.261 [2]). V2X messages (Remote Driving. See TS 22.186 [111], NOTE 16, see TS 23.287 [121]) |
|
|
86 |
18 |
5 ms (NOTE 5) |
10-4 |
1354 bytes |
2000 ms |
V2X messages (Advanced Driving: Collision Avoidance, Platooning with high LoA. See TS 22.186 [111], TS 23.287 [121]) |
|
|
87 |
25 |
5 ms (NOTE 4) |
10-3 |
500 bytes |
2000 ms |
Interactive Service – Motion tracking data, (see TS 22.261 [2]) |
|
|
88 |
25 |
10 ms (NOTE 4) |
10-3 |
1125 bytes |
2000 ms |
Interactive Service – Motion tracking data, (see TS 22.261 [2]) |
|
|
89 |
25 |
15 ms (NOTE 4) |
10-4 |
17000 bytes |
2000 ms |
Visual content for cloud/edge/split rendering (see TS 22.261 [2]) |
|
|
90 |
25 |
20 ms (NOTE 4) |
10-4 |
63000 bytes |
2000 ms |
Visual content for cloud/edge/split rendering (see TS 22.261 [2]) |
|
|
NOTE 1: A packet which is delayed more than PDB is not counted as lost, thus not included in the PER. NOTE 2: It is required that default MDBV is supported by a PLMN supporting the related 5QIs. NOTE 3: The Maximum Transfer Unit (MTU) size considerations in clause 9.3 and Annex C of TS 23.060 [56] are also applicable. IP fragmentation may have impacts to CN PDB, and details are provided in clause 5.6.10. NOTE 4: A static value for the CN PDB of 1 ms for the delay between a UPF terminating N6 and a 5G-AN should be subtracted from a given PDB to derive the packet delay budget that applies to the radio interface. When a dynamic CN PDB is used, see clause 5.7.3.4. NOTE 5: A static value for the CN PDB of 2 ms for the delay between a UPF terminating N6 and a 5G-AN should be subtracted from a given PDB to derive the packet delay budget that applies to the radio interface. When a dynamic CN PDB is used, see clause 5.7.3.4. NOTE 6: A static value for the CN PDB of 5 ms for the delay between a UPF terminating N6 and a 5G-AN should be subtracted from a given PDB to derive the packet delay budget that applies to the radio interface. When a dynamic CN PDB is used, see clause 5.7.3.4. NOTE 7: For Mission Critical services, it may be assumed that the UPF terminating N6 is located "close" to the 5G_AN (roughly 10 ms) and is not normally used in a long distance, home routed roaming situation. Hence a static value for the CN PDB of 10 ms for the delay between a UPF terminating N6 and a 5G_AN should be subtracted from this PDB to derive the packet delay budget that applies to the radio interface. NOTE 8: In both RRC Idle and RRC Connected mode, the PDB requirement for these 5QIs can be relaxed (but not to a value greater than 320 ms) for the first packet(s) in a downlink data or signalling burst in order to permit reasonable battery saving (DRX) techniques. NOTE 9: It is expected that 5QI-65 and 5QI-69 are used together to provide Mission Critical Push to Talk service (e.g. 5QI-5 is not used for signalling). It is expected that the amount of traffic per UE will be similar or less compared to the IMS signalling. NOTE 10: In both RRC Idle and RRC Connected mode, the PDB requirement for these 5QIs can be relaxed for the first packet(s) in a downlink data or signalling burst in order to permit battery saving (DRX) techniques. NOTE 11: In RRC Idle mode, the PDB requirement for these 5QIs can be relaxed for the first packet(s) in a downlink data or signalling burst in order to permit battery saving (DRX) techniques. NOTE 12: This 5QI value can only be assigned upon request from the network side. The UE and any application running on the UE is not allowed to request this 5QI value. NOTE 13: A static value for the CN PDB of 20 ms for the delay between a UPF terminating N6 and a 5G-AN should be subtracted from a given PDB to derive the packet delay budget that applies to the radio interface. NOTE 14: This 5QI is not supported in this Release of the specification as it is only used for transmission of V2X messages over MBMS bearers as defined in TS 23.285 [72] but the value is reserved for future use. NOTE 15: For "live" uplink streaming (see TS 26.238 [76]), guidelines for PDB values of the different 5QIs correspond to the latency configurations defined in TR 26.939 [77]. In order to support higher latency reliable streaming services (above 500ms PDB), if different PDB and PER combinations are needed these configurations will have to use non-standardised 5QIs. NOTE 16: These services are expected to need much larger MDBV values to be signalled to the RAN. Support for such larger MDBV values with low latency and high reliability is likely to require a suitable RAN configuration, for which, the simulation scenarios in TR 38.824 [112] may contain some guidance. NOTE 17: The worst case one way propagation delay for GEO satellite is expected to be ~270ms, ,~ 21 ms for LEO at 1200km, and 13 ms for LEO at 600km. The UL scheduling delay that needs to be added is also typically two way propagation delay e.g. ~540ms for GEO, ~42ms for LEO at 1200km, and ~26 ms for LEO at 600km. Based on that, the 5G-AN Packet delay budget is not applicable for 5QIs that require 5G-AN PDB lower than the sum of these values when the specific types of satellite access are used (see TS 38.300 [27]). 5QI-10 can accommodate the worst case PDB for GEO satellite type. |
|||||||
NOTE: It is preferred that a value less than 64 is allocated for any new standardised 5QI of Non-GBR resource type. This is to allow for option 1 to be used as described in clause 5.7.1.3 (as the QFI is limited to less than 64).
5.7.5 Reflective QoS
5.7.5.1 General
Reflective QoS enables the UE to map UL User Plane traffic to QoS Flows without SMF provided QoS rules and it applies for IP PDU Session and Ethernet PDU Session. This is achieved by creating UE derived QoS rules in the UE based on the received DL traffic. It shall be possible to apply Reflective QoS and non-Reflective QoS concurrently within the same PDU Session.
For a UE supporting Reflective QoS functionality, the UE shall create a UE derived QoS rule for the uplink traffic based on the received DL traffic if Reflective QoS function is used by the 5GC for some traffic flows. The UE shall use the UE derived QoS rules to determine mapping of UL traffic to QoS Flows.
If the 3GPP UE supports Reflective QoS functionality, the UE should indicate support of Reflective QoS to the network (i.e. SMF) for every PDU Session. For PDU Sessions established in EPS and PDU Sessions transferred from EPS without N26 interface, the UE indicates Reflective QoS support using the PDU Session Establishment procedure. After the first inter-system change from EPS to 5GS for PDU Sessions established in EPS and transferred from EPS with N26 interface, the UE indicates Reflective QoS support using the PDU Session Modification procedure as described in clause 5.17.2.2.2. The UE as well as the network shall apply the information whether or not the UE indicated support of Reflective QoS throughout the lifetime of the PDU Session.
NOTE: The logic driving a supporting UE under exceptional circumstances to not indicate support of Reflective QoS for a PDU Session is implementation dependent.
Under exceptional circumstances, which are UE implementation dependent, the UE may decide to revoke previously indicated support for Reflective QoS using the PDU Session Modification procedure. In such a case, the UE shall delete all derived QoS rules for this PDU Session and the network shall stop any user plane enforcement actions related to Reflective QoS for this PDU Session. In addition, the network may provide signalled QoS rules for the SDFs for which Reflective QoS was used before. The UE shall not indicate support for Reflective QoS for this PDU Session for the remaining lifetime of the PDU Session.
If under the same exceptional circumstances mentioned above and while NAS level MM or SM congestion control timer is running, the UE needs to revoke a previously indicated support for Reflective QoS, the UE performs PDU Session Release procedure that is exempt from MM and SM congestion control as defined in clause 5.19.7.
5.7.5.2 UE Derived QoS Rule
The UE derived QoS rule contains following parameters:
– One UL Packet Filter (in the Packet Filter Set as defined in clause 5.7.6);
– QFI;
– Precedence value (see clause 5.7.1.9).
Upon receiving DL packet, one UL Packet Filter derived from the received DL packet as described in this clause is used to identify a UE derived QoS rule within a PDU Session.
For PDU Session of IP type, the UL Packet Filter is derived based on the received DL packet as follows:
– When Protocol ID / Next Header is set to TCP or UDP, by using the source and destination IP addresses, source and destination port numbers, and the Protocol ID / Next Header field itself.
– When Protocol ID / Next Header is set to UDP, if the received DL packet is UDP-encapsulated IPSec protected packet, by using the source and destination IP addresses, source and destination port numbers, the Security Parameter Index, and the Protocol ID / Next Header field itself. In this case, if an uplink IPSec SA corresponding to a downlink IPSec SA of the SPI in the DL packet exists and the SPI of the uplink IPSec SA is known to the NAS layer, then the UL Packet Filter contains an SPI of the uplink IPSec SA.
– When Protocol ID / Next Header is set to ESP, by using the source and destination IP addresses, the Security Parameter Index, and the Protocol ID / Next Header field itself. If the received DL packet is an IPSec protected packet, and an uplink IPSec SA corresponding to a downlink IPSec SA of the SPI in the DL packet exists and the SPI of the uplink IPSec SA is known to the NAS layer, then the UL Packet Filter contains an SPI of the uplink IPSec SA.
NOTE 1: In this Release of the specification for PDU Sessions of IP type the use of Reflective QoS is restricted to service data flows for which Protocol ID / Next Header is set to TCP, UDP or ESP.
NOTE 2: The UE does not verify whether the downlink packets with RQI indication match the restrictions on Reflective QoS.
NOTE 3: How to determine the received DL packet is UDP-encapsulated IPSec protected packet is defined in RFC 3948 [138]. UDP encapsulation for ESP is used when a NAT is detected, and there can be different Security Parameter Indexes within the same IP-tuples.
For PDU Session of Ethernet type the UL Packet Filter is derived based on the received DL packet by using the source and destination MAC addresses, the Ethertype on received DL packet is used as Ethertype for UL packet. In the case of presence of 802.1Q [98], the VID and PCP in IEEE Std 802.1Q [98] header(s) of the received DL packet is also used as the VID and PCP field for the UL Packet Filter. When double 802.1Q [98] tagging is used, only the outer (S-TAG) is taken into account for the UL Packet Filter derivation.
NOTE 4: In this Release of the specification for PDU Sessions of Ethernet type the use of Reflective QoS is restricted to service data flows for which 802.1Q [98] tagging is used.
The QFI of the UE derived QoS rule is set to the value received in the DL packet.
When Reflective QoS is activated the precedence value for all UE derived QoS rules is set to a standardised value.
5.7.5.3 Reflective QoS Control
Reflective QoS is controlled on per-packet basis by using the Reflective QoS Indication (RQI) in the encapsulation header on N3 (and N9) reference point together with the QFI and together with a Reflective QoS Timer (RQ Timer) value that is either signalled to the UE upon PDU Session Establishment (or upon PDU Session Modification as described in clause 5.17.2.2.2) or set to a default value. The RQ Timer value provided by the core network is at the granularity of PDU Session (the details are specified in TS 24.501 [47]).
When the 5GC determines that Reflective QoS has to be used for a specific SDF belonging to a QoS Flow, the SMF shall provide the RQA (Reflective QoS Attribute) within the QoS Flow’s QoS profile to the NG-RAN on N2 reference point unless it has been done so before. When the RQA has been provided to the NG-RAN for a QoS Flow and the 5GC determines that the QoS Flow carries no more SDF for which Reflective QoS has to be used, the SMF should signal the removal of the RQA (Reflective QoS Attribute) from the QoS Flow’s QoS profile to the NG-RAN on N2 reference point.
NOTE 1: The SMF could have a timer to delay the sending of the removal of the RQA. This would avoid signalling to the RAN in the case of new SDFs subject to Reflective QoS are bound to this QoS Flow in the meantime.
When the 5GC determines to use Reflective QoS for a specific SDF, the SMF shall ensure that the UPF applies the RQI marking (e.g. by setting the indication to use Reflective QoS in the QER associated with the DL PDR if not already set) for this SDF. The SMF shall also ensure that the uplink packets for this SDF can be received by the UPF from the QoS Flow to which the DL PDR of the SDF is associated with as specified in TS 29.244 [65], e.g. by generating a new UL PDR for this SDF for that QoS Flow and providing it to the UPF.
When the UPF is instructed by the SMF to apply RQI marking, the UPF shall set the RQI in the encapsulation header on the N3 (or N9) reference point for every DL packet corresponding to this SDF.
When an RQI is received by (R)AN in a DL packet on N3 reference point, the (R)AN shall indicate to the UE the QFI and the RQI of that DL packet.
Upon reception of a DL packet with RQI:
– if a UE derived QoS rule with a Packet Filter corresponding to the DL packet does not already exist,
– the UE shall create a new UE derived QoS rule with a Packet Filter corresponding to the DL packet (as described in clause 5.7.5.2); and
– the UE shall start, for this UE derived QoS rule, a timer set to the RQ Timer value.
– otherwise,
– the UE shall restart the timer associated to this UE derived QoS rule; and
– if the QFI associated with the downlink packet is different from the QFI associated with the UE derived QoS rule, the UE shall update this UE derived QoS rule with the new QFI.
NOTE 2: Non-3GPP ANs does not need N2 signalling to enable Reflective QoS. Non 3GPP accesses are expected to send transparently the QFI and RQI to the UE. If the UPF does not include the RQI, no UE derived QoS rule will be generated. If RQI is included to assist the UE to trigger an update of the UE derived QoS rule, the reception of PDU for a QFI restarts the RQ Timer.
Upon timer expiry associated with a UE derived QoS rule the UE deletes the corresponding UE derived QoS rule.
When the 5GC determines not to use Reflective QoS for a specific SDF any longer:
– The SMF shall ensure that the UPF stops applying RQI marking as specified in TS 29.244 [65] (e.g. by removing the indication to use Reflective QoS from the QER associated with the DL PDR) for this SDF.
– When the UPF receives this instruction to stop applying RQI marking, the UPF shall no longer set the RQI in the encapsulation header on the N3 (or N9) reference point DL packets corresponding to this SDF.
– The SMF shall also ensure that, after an operator configurable time, the uplink packets for this SDF will not be accepted by the UPF over the QoS Flow on which Reflective QoS was applied for this SDF as specified in TS 29.244 [65], e.g. by removing the UL PDR for this SDF from that QoS Flow.
NOTE 3: The operator configurable time has to be at least as long as the RQ Timer value to ensure that no UL packet would be dropped until the UE derived QoS rule is deleted by the UE.
When the 5GC determines to change the binding of the SDF while Reflective QoS is used for this SDF, the SMF shall ensure that the uplink packets for this SDF are accepted over the newly bound QoS Flow and, for an operator configurable time, over the previously bound QoS Flow.
5.7.6 Packet Filter Set
5.7.6.1 General
The Packet Filter Set is used in the QoS rule and the PDR to identify one or more packet (IP or Ethernet) flow(s).
NOTE 1: A QoS Flow is characterised by PDR(s) and QoS rule(s) as described in clause 5.7.1.1.
NOTE 2: DL Packet Filter in a Packet Filter Set of a QoS rule may be needed by the UE e.g. for the purpose of IMS precondition.
The Packet Filter Set may contain one or more Packet Filter(s). Every Packet Filter is applicable for the DL direction, the UL direction or both directions.
NOTE 3: The Packet Filter in the Packet Filter Set of the default QoS rule that allows all UL traffic (also known as match-all Packet Filter) is described in TS 24.501 [47].
There are two types of Packet Filter Set, i.e. IP Packet Filter Set, and Ethernet Packet Filter Set, corresponding to those PDU Session Types.
5.7.6.2 IP Packet Filter Set
For IP PDU Session Type, the Packet Filter Set shall support Packet Filters based on at least any combination of:
– Source/destination IP address or IPv6 prefix.
– Source / destination port number.
– Protocol ID of the protocol above IP/Next header type.
– Type of Service (TOS) (IPv4) / Traffic class (IPv6) and Mask.
– Flow Label (IPv6).
– Security parameter index.
– Packet Filter direction.
NOTE 1: A value left unspecified in a Packet Filter matches any value of the corresponding information in a packet.
NOTE 2: An IP address or Prefix may be combined with a prefix mask.
NOTE 3: Port numbers may be specified as port ranges.
5.7.6.3 Ethernet Packet Filter Set
For Ethernet PDU Session Type, the Packet Filter Set shall support Packet Filters based on at least any combination of:
– Source/destination MAC address.
– Ethertype as defined in IEEE 802.3 [131].
– Customer-VLAN tag (C-TAG) and/or Service-VLAN tag (S-TAG) VID fields as defined in IEEE Std 802.1Q [98].
– Customer-VLAN tag (C-TAG) and/or Service-VLAN tag (S-TAG) PCP/DEI fields as defined in IEEE Std 802.1Q [98].
– IP Packet Filter Set, in the case that Ethertype indicates IPv4/IPv6 payload.
– Packet Filter direction.
NOTE 1: The MAC address may be specified as address ranges.
NOTE 2: A value left unspecified in a Packet Filter matches any value of the corresponding information in a packet.