6.2.5.1.4 Reflective QoS

6.2.5.1.4.1 General

The UE may support reflective QoS.

If the UE supports the reflective QoS, the UE shall support the procedures in the following clauses.

The reflective QoS is applicable in a PDU session of IPv4, IPv6, IPv4v6 and Ethernet PDU session type. The reflective QoS is not applicable in a PDU session of Unstructured PDU session type. Reflective QoS is not applicable for a PDU session with control plane only indication.

The UE may request to revoke the usage of reflective QoS for an existing PDU session for which the UE had previously indicated support for reflective QoS.

6.2.5.1.4.2 Derivation of packet filter for UL direction from DL user data packet

If the UE needs to derive a packet filter for UL direction from the DL user data packet (see clause 6.2.5.1.4.3 and 6.2.5.1.4.4), the UE shall proceed as follows:

• if the received DL user data packet belongs to a PDU session of IPv4 or IPv4v6 PDU session type and is an IPv4 packet and:
• the protocol field of the received DL user data packet indicates TCP as specified in IETF RFC 793 [33];
• the protocol field of the received DL user data packet indicates UDP as specified in IETF RFC 768 [32]; or
• the protocol field of the received DL user data packet indicates ESP as specified in IETF RFC 4303 [38] and an uplink IPSec SA corresponding to a downlink IPSec SA indicated in the security parameters index field of the received DL user data packet exists;

then the packet filter for UL direction contains the following packet filter components:

• an IPv4 remote address component set to the value of the source address field of the received DL user data packet;
• an IPv4 local address component set to the value of the destination address field of the received DL user data packet;
• a protocol identifier/next header type component set to the value of the protocol field of the received DL user data packet;
• if the protocol field of the received DL user data packet indicates TCP as specified in IETF RFC 793 [33] or UDP as specified in IETF RFC 768 [32]:
• a single local port type component set to the value of the destination port field of the received DL user data packet; and
• a single remote port type component set to the value of the source port field of the received DL user data packet;
• if the protocol field of the received DL user data packet indicates ESP as specified in IETF RFC 4303 [38], an uplink IPSec SA corresponding to a downlink IPSec SA of the SPI in the DL user data packet exists and the SPI of the uplink IPSec SA is known to the NAS layer:
• a security parameter index type component set to the security parameters index of the uplink IPSec SA corresponding to the downlink IPSec SA indicated in the security parameters index field of the received DL user data packet; and
• if the protocol field of the received DL user data packet indicates UDP and the received DL user data packet contains a UDP-encapsulated ESP header as specified in IETF RFC 3948 [55], an uplink IPSec SA corresponding to a downlink IPSec SA of the SPI in the DL user data packet exists and the SPI of the uplink IPSec SA is known to the NAS layer:
• a security parameter index type component set to the security parameters index of the uplink IPSec SA corresponding to the downlink IPSec SA indicated in the security parameters index field of the ESP header field of the UDP-encapsulated ESP header as specified in IETF RFC 3948 [55] of the received DL user data packet;

otherwise it is not possible to derive a packet filter for UL direction from the DL user data packet;

• if the received DL user data packet belongs to a PDU session of IPv6 or IPv4v6 PDU session type and is an IPv6 packet and:
• the last next header field of the received DL user data packet indicates TCP as specified in IETF RFC 793 [33];
• the last next header field of the received DL user data packet indicates UDP as specified in IETF RFC 768 [32]; or
• the last next header field of the received DL user data packet indicates ESP as specified in IETF RFC 4303 [38] and an uplink IPSec SA corresponding to a downlink IPSec SA indicated in the security parameters index field of the received DL user data packet exists;

then the packet filter for UL direction contains the following packet filter components:

• an IPv6 remote address/prefix length component set to the value of the source address field of the received DL user data packet;
• an IPv6 local address/prefix length component set to the value of the destination address field of the received DL user data packet;
• a protocol identifier/next header type component set to the value of the last next header field of the received DL user data packet;
• if the last next header field of the received DL user data packet indicates TCP as specified in IETF RFC 793 [33] or UDP as specified in IETF RFC 768 [32]:
• a single local port type component set to the value of the destination port field of the received DL user data packet; and
• a single remote port type component set to the value of the source port field of the received DL user data packet;
• if the last next header field of the received DL user data packet indicates ESP as specified in IETF RFC 4303 [38], an uplink IPSec SA corresponding to a downlink IPSec SA of the SPI in the DL user data packet exists and the SPI of the uplink IPSec SA is known to the NAS layer:
• a security parameter index type component set to the security parameters index of the uplink IPSec SA corresponding to the downlink IPSec SA indicated in the security parameters index field of the received DL user data packet; and
• if the last next header field of the received DL user data packet indicates UDP, and the received DL user data packet contains a UDP-encapsulated ESP header as specified in IETF RFC 3948 [55], an uplink IPSec SA corresponding to a downlink IPSec SA of the SPI in the DL user data packet exists and the SPI of the uplink IPSec SA is known to the NAS layer:
• a security parameter index type component set to the security parameters index of the uplink IPSec SA corresponding to the downlink IPSec SA indicated in the security parameters index field of the ESP header field of the UDP-encapsulated ESP header as specified in IETF RFC 3948 [55] of the received DL user data packet;

otherwise it is not possible to derive a packet filter for UL direction from the DL user data packet;

• if the received DL user data packet belongs to a PDU session of Ethernet PDU session type, the packet filter for UL direction contains the following packet filter components:
• a destination MAC address component set to the source MAC address of the received DL user data packet;
• a source MAC address component set to the destination MAC address of the received DL user data packet;
• if one or more 802.1Q C-TAG is included in the received DL user data packet, an 802.1Q C-TAG VID component set to the outermost 802.1Q C-TAG VID of the received DL user data packet and an 802.1Q C-TAG PCP/DEI component set to the outermost 802.1Q C-TAG PCP/DEI of the received DL user data packet;
• if one or more 802.1Q S-TAG is included in the received DL user data packet, an 802.1Q S-TAG VID component set to the outermost 802.1Q S-TAG VID of the received DL user data packet and an 802.1Q S-TAG PCP/DEI component set to the outermost 802.1Q S-TAG PCP/DEI of the received DL user data packet;
• If the Ethertype field of the received DL user data packet is set to a value of 1536 or above, an Ethertype component set to the Ethertype of the received DL user data packet;
• if the Ethertype field of the Ethernet frame header indicates that the data carried in the Ethernet frame is IPv4 data, the UE shall also add to the packet filter for UL direction the IP-specific components based on the contents of the IP header of the received DL user data packet as described in bullet a) above; and
• if the Ethertype field of the Ethernet frame header indicates that the data carried in the Ethernet frame is IPv6 data, the UE shall also add to the packet filter for UL direction the IP-specific components based on the contents of the IP header of the received DL user data packet as described in bullet b) above; and
• if the received DL user data packet belongs to a PDU session of PDU session type other than Ethernet, IPv4, IPv6 and IPv4v6, it is not possible to derive a packet filter for UL direction from the DL user data packet.

6.2.5.1.4.3 Creating a derived QoS rule by reflective QoS in the UE

If the UE receives a DL user data packet marked with a QFI and an RQI, the DL user data packet belongs to a PDU session of IPv4, IPv6, IPv4v6 or Ethernet PDU session type, and the UE does not have a derived QoS rule with the same packet filter for UL direction as the packet filter for UL direction derived from the DL user data packet as specified in clause 6.2.5.1.4.2, then the UE shall create a new derived QoS rule as follows:

• the QFI of the derived QoS rule is set to the received QFI;
• the precedence value of the derived QoS rule is set to 80 (decimal); and
• the packet filter for UL direction of the derived QoS rule is set to the derived packet filter for UL direction;

and the UE shall start the timer T3583 associated with the derived QoS rule with the RQ timer value last received during the UE-requested PDU session establishment procedure of the PDU session (see clause 6.4.1) or the network-requested PDU session modification procedure of the PDU session (see clause 6.4.2). If the RQ timer value was received neither in the UE-requested PDU session establishment procedure of the PDU session nor in any network-requested PDU session modification procedure of the PDU session, the default standardized RQ timer value is used.

6.2.5.1.4.4 Updating a derived QoS rule by reflective QoS in the UE

If the UE receives a DL user data packet associated with a QFI and an RQI, the DL user data packet belongs to a PDU session of IPv4, IPv6, IPv4v6 or Ethernet PDU session type, and the UE has a derived QoS rule with the same packet filter for UL direction as the packet filter for UL direction derived from the DL user data packet as specified in clause 6.2.5.1.4.2:

• the UE shall re-start the timer T3583 associated with the derived QoS rule with the RQ timer value last received during the UE-requested PDU session establishment procedure of the PDU session (see clause 6.4.1) or the network-requested PDU session modification procedure of the PDU session (see clause 6.4.2). If the RQ timer value was received neither in the UE-requested PDU session establishment procedure of the PDU session nor in any network-requested PDU session modification procedure of the PDU session, the default standardized RQ timer value is used; and
• if the QFI value associated with the DL user data packet is different from the QFI value stored for the derived QoS rule, the UE shall replace the QFI value stored for the derived QoS rule with the new QFI value for the derived QoS rule.

6.2.5.1.4.5 Deleting a derived QoS rule in the UE

Upon expiry of timer T3583 associated with a derived QoS rule, the UE shall remove the derived QoS rule.

Upon release of the PDU session, the UE shall remove the derived QoS rule(s) associated with the PDU session.

If the network accepts the request from the UE to revoke the usage of reflective QoS and sets the value of the RQ timer to "deactivated" or zero, the UE shall remove the derived QoS rule(s) associated with the PDU session.

Upon inter-system mobility from WB-N1 mode to NB-N1 mode or from NR connected to 5GCN to NB-N1 mode, the UE shall remove the derived QoS rule(s) associated with the PDU session that is kept active.

When a derived QoS rule is deleted, the timer T3583 associated with the derived QoS rule shall be stopped.

6.2.5.1.4.6 Ignoring RQI in the UE

If the UE receives a DL user data packet marked with a QFI and an RQI and it is not possible to derive a packet filter for UL direction from the DL user data packet as specified in clause 6.2.5.1.4.2, the UE shall ignore the RQI and shall handle the received DL user data packet.