Tech-invite  3GPPspecsRELsGlossariesSIP
Info21222324252627282931323334353637384‑5x

full Contents for  TS 23.501  Word version:   16.4.0

Top   Up   Prev   Next
1…   3…   4…   4.2.4   4.2.5…   4.2.8…   4.2.8.2.2   4.2.8.2.3…   4.2.8.4…   4.2.9…   4.3…   4.3.3   4.3.4   4.3.5   4.4…   4.4.6…   4.4.8   5…   5.3…   5.3.3…   5.4…   5.5…   5.6…   5.6.7…   5.7…   5.7.2…   5.7.3…   5.7.4   5.7.5…   5.8…   5.8.2.11…   5.9…   5.10…   5.11…   5.15…   5.16…   5.17…   5.18…   5.19…   5.21…   5.22…   5.27…   5.28…   5.29…   5.30…   5.31…   5.32…   5.33…   5.34…   5.35…   6…   6.3…   7…   7.2…   8…   8.2.4   8.2.5…   8.3…   A…   D…   E…   F   G…   G.3   G.4…   J…

 

5.7.5  Reflective QoSWord-p. 147
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.
Up
5.7.5.2  UE Derived QoS RuleWord-p. 148
The UE derived QoS rule contains following parameters:
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 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, 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.
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 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 3:
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.
Up
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, 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).
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 include an indication to use Reflective QoS for this SDF in the corresponding SDF information provided to the UPF via N4 interface.
When the UPF receives this indication for an SDF, the UPF shall set the RQI in the encapsulation header on the N3 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; 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 the UE derived QoS rule identified by the UL packet filter derived from the DL packet as described in clause 5.7.5.2 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 to no longer use Reflective QoS for a specific SDF, the SMF shall remove the indication to use Reflective QoS in the corresponding SDF information provided to the UPF via N4 interface.
When the UPF receives this instruction for this SDF, the UPF shall no longer set the RQI in the encapsulation header on the N3 reference point.
The UPF shall continue to accept the UL traffic of the SDF for the originally authorized QoS Flow for an operator configurable time.
NOTE 3:
This means that the detection and QoS enforcement instructions which were applied before the SMF removed the indication to use Reflective QoS remain active in UL direction while the accounting of the UL traffic is done according to the new instructions.
NOTE 4:
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.
Up
5.7.6  Packet Filter SetWord-p. 149
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.
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.
Up
5.7.6.2  IP Packet Filter SetWord-p. 150
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.
Up
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.
  • Customer-VLAN tag (C-TAG) and/or Service-VLAN tag (S-TAG) VID fields as defined in IEEE 802.1Q [98].
  • Customer-VLAN tag (C-TAG) and/or Service-VLAN tag (S-TAG) PCP/DEI fields as defined in IEEE 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.
Up

Up   Top   ToC