5 Supporting QoS

24.1393GPP3GPP system - fixed broadband access network interworkingRelease 17Stage 3TS

5.1 General

When interworking with a fixed broadband access network, DSCP marking is used for setting QoS as specified in IETF RFC 2474 [5].

For downlink traffic, the 3GPP network sets the DSCP value on the outer header of each IP packet on a per-flow basis. When tunnelling the IP packet to the UE, the network copies the DSCP value from the inner IP header to the new outer IP header.

For uplink traffic, the reflective QoS on uplink traffic is optionally supported by the UE when accessing a fixed broadband access network. The reflective QoS is achieved by creating a DSCP marking rule based on the received downlink traffic.

The BBF network performs QoS treatment and QoS remapping based on DSCP value of the outer IP header.

5.2 UE reflective QoS procedures

5.2.1 General

A UE may support the UE reflective QoS function for uplink traffic.

For a UE supporting UE reflective QoS function, and if UE reflective QoS function is enabled by the network, the UE shall create uplink DSCP marking rules based on the received downlink traffic. Each uplink DSCP marking rule contains a n-tuple rule which is created based on the corresponding n-tuple of the received downlink traffic. The UE shall use the uplink DSCP marking rules to set the DSCP field of the outer IP header of the outgoing IP packets.

The UE reflective QoS function is enabled by the network as specified in subclause 5.4.

5.2.2 DSCP marking rule

The DSCP marking rules contains following parameter values:

– Source IP address;

– Destination IP address;

– Source port number;

– Destination port number;

– Protocol type;

– DSCP marking value; and

– Timestamp.

The source IP address refers to the IP address used by the UE as source IP address when generating IP traffic.

The destination IP address refers to the IP address of the data packets destined for the UE.

The source port number refers to the port number used by the UE as source port number when generating IP traffic.

The destination port number refers to the port number of the data packets destined for the UE.

The protocol type is a value among the internet protocol numbers as defined in IANA. In case of IPv4, the protocol type value is the value of the outer IP header protocol type field. In case of IPv6, the protocol type value is the value of the last next header field.

The timestamp is the time that the DSCP marking rule was created or the last time the DSCP marking rule was applied.

5.2.3 Maintaining DSCP marking rules

The DSCP marking table is created when the first DSCP marking rule is created based on the received downlink IP packet.

Depending on the protocol type, the n-tuple is either a 5-tuple (including: source IP address, destination IP address, source port number, destination port number, and protocol type) or a 3-tuple (including source IP address, destination IP address, and protocol type).

The lifetime of the DSCP marking table is same as the associated PDN connection.

A UE may remove the expired entries from the table based on the timestamp. How long the entry shall be maintained in the table is an implementation specific value.

5.2.4 Receiving an IP packet

When receiving an IP packet, the UE shall perform a lookup in the DSCP marking table based on the n-tuple of the IP header. If tunnel is established between the UE and the network, the lookup is performed after the tunnel de-capsulation.

If no matching entry is found, a new entry shall be created as follows:

– The source IP address of the new entry is the destination IP address of the received packets;

– The source port number of the new entry is the destination port number of the received packets;

– The destination IP address of the new entry is the source IP address of the received packets;

– The destination port number of the new entry is the source port number of the received packets;

– The protocol type value is either the value of the last protocol type field in IPv4 case, or the value of the last next header field in case of IPv6;

– The DSCP field is set as same as the DSCP field of the received outer IP header; and

– The timestamp is set.

If a matching entry is found, the timestamp shall be set.

5.2.5 Sending an IP packet

When sending an IP packet, the UE shall perform a lookup in the DSCP marking table based on the n-tuple of the IP header. If a tunnel is established between the UE and the network, the lookup is performed before the tunnel encapsulation.

If a matching entry is found, the UE shall set the DSCP marking value of the IP header of the packet according to the matched DSCP marking rule and set the timestamp of the entry. If there is already a value of the DSCP field in the IP header of the packet set by the UE application, it shall be overwritten by the DSCP marking value from the DSCP marking rule.

If no matching entry is found, the UE shall not modify the DSCP field of the IP header of the packet.

If a tunnel is established between the UE and the network, the UE shall copy the DSCP value from the IP header of the original packet into the new outer header at the tunnel encapsulation before forwarding it to the network.

5.3 Network procedures for supporting QoS

The 3GPP network shall create DSCP marking rules per QoS flow based on policies as defined in 3GPP TS 23.139 [2].

When tunnelling the UE downlink traffic, the network shall copy the DSCP value from the received IP header into the new outer header before forwarding to the UE.

Optionally, the network may perform DSCP marking remapping based on the operator’s policy.

5.4 Enabling UE reflective QoS function

5.4.1 General

The UE indicates its support of UE reflective QoS function to the network. When the UE explicit indication is received, the network provides the reflective QoS Indication to the UE which indicates that the UE reflective QoS function shall be enabled or disabled.

For trusted fixed broadband access network, the indication is provided at 3GPP based access authentication before an IP address is allocated to the UE. For un-trusted fixed broadband access network, if the 3GPP based access authentication is performed the indication is provided at 3GPP based access authentication before an IP address is allocated to the UE, or it is provided during IKEv2 signalling for IPsec tunnel establishment with the ePDG. For DSMIPv6 based access procedure, the indication is provided during IKEv2 signalling for IPsec tunnel establishment with the PDN-GW/HA.

5.4.2 UE procedure

5.4.2.1 Sending Reflective QoS Indication (RQSI) to 3GPP AAA server

During EAP-AKA and EAP-AKA’ based authentication, UE may provide an explicit indication to the 3GPP AAA server about the supporting of UE reflective QoS function. The explicit indication is sent using an attribute in the EAP-AKA and EAP-AKA’ protocols, which extends these protocols as specified in subclause 8.2 of IETF RFC 4187 [6]. This attribute is provided in EAP-Response/AKA-Challenge and the corresponding EAP-AKA’ message payload.

If the UE reflective QoS function is supported, the UE shall provide the RQSI using AT_RQSI_IND attribute in EAP-AKA or EAP-AKA’. This indication is provided if the UE receives the AT_RESULT_IND attribute within the EAP-Request/AKA-Challenge message, or the EAP-Request’/AKA-Challenge’ message when EAP-AKA’ is used. If the UE provides the AT_RQSI_IND attribute within the EAP-Response/AKA-Challenge message payload, or the EAP-Response’/AKA-Challenge’ message payload when EAP-AKA’ is used, the UE shall also provide the AT_RESULT_IND attribute within the message.

The detailed coding of this attribute is described in subclause 8.1.1.

5.4.2.2 Receiving the RQSI from 3GPP AAA server

The UE shall only enable the UE reflective QoS function if enabled by the network.

If the Reflective QoS Indication is received at 3GPP based access authentication which indicates the UE reflective QoS function is enabled, the UE may:

– perform the UE reflective QoS function on all traffic for the attached fixed broadband access network that enabled the UE reflective QoS function; and

– disable the UE reflective QoS function, when:

a) the UE/network initiated detachment from the attached fixed broadband access network; or

b) the UE moves away from the attached fixed broadband access network coverage.

If the Reflective QoS Indication is received at 3GPP based access authentication during the attachment of the fixed broadband access network:

– the UE need not provide an explicit indication during IKEv2 signalling for IPsec tunnel establishment with ePDG or DSMIPv6 bootstrapping with PDN-GW/HA; and

– the UE shall ignore the Reflective QoS Indication if it is received during IKEv2 signalling for IPsec tunnel establishment with ePDG or DSMIPv6bootstrapping with PDN-GW/HA .

If the Reflective QoS Indication is received during IKEv2 signalling for IPsec tunnel establishment with ePDG which indicates that the UE reflective QoS function is enabled, the UE shall:

– perform the UE reflective QoS function on all tunneled traffic for the attached ePDG that enabled the UE reflective QoS function; and

– disable the UE reflective QoS function, when:

a) the PDN connection over the attached ePDG is released or handover to another access network occurs;

b) the UE/network initiated detachment from the attached fixed broadband access network; or

c) the UE moves away from the attached fixed broadband access network coverage;

If the Reflective QoS Indication is received during IKEv2 signalling for IPsec tunnel establishment with ePDG and DSMIPv6 is used as selected mobility protocol (see subclause 6.3.3 of 3GPP TS 24.302 [3]):

– the UE need not provide an explicit indication during DSMIPv6 bootstrapping with PDN-GW/HA; and

– the UE shall ignore the Reflective QoS Indication if it is received during DSMIPv6 bootstrapping with PDN-GW/HA.

For DSMIPv6 over a fixed broadband access network, if the Reflective QoS Indication is received during DSMIPv6 bootstrapping with PDN-GW/HA which indicates that the UE reflective QoS function is enabled, the UE shall:

– perform the UE reflective QoS function for all DSMIPv6 traffic for the attached PDN-GW/HA that enabled the UE reflective QoS function; and

– disable the UE reflective QoS function, when:

a) the PDN connection with the attached PDN-GW/HA is released or handover to another access;

b) the UE/network initiated detachment from the attached fixed broadband access network; or

c) the UE moves away from the attached fixed broadband access network coverage;

The UE shall not enable the UE reflective QoS function, if:

– the received Reflective QoS Indication indicates that the UE reflective QoS function is disabled; or

– the Reflective QoS Indication is not received from the 3GPP AAA.

If the UE reflective QoS function is not enabled, the DSCP marking value of the outer IP header performed by the UE is implementation specific.

5.4.3 Network procedure

5.4.3.1 RQSI from 3GPP AAA server to UE

A 3GPP AAA server supporting RQSI, shall include the AT_RESULT_IND attribute within the EAP-Request/AKA-Challenge and corresponding EAP-AKA’ message payload.

If the UE provided an explicit indication as described in subclause 5.4.2.1, the 3GPP AAA server shall inform the UE of its decision of the UE reflective QoS function by invoking an EAP-Request/AKA-Notification dialogue when EAP-AKA is used or an EAP-Request’/AKA-Notification’ dialogue when EAP-AKA’ is used. The UE reflective QoS function decision is sent to the UE by using the AT_ RQSI_RES attribute.

The UE reflective QoS function decision is made by the 3GPP AAA server based on the capabilities of the UE, the type of access, the access identity and local policies.

The detailed coding of this attribute is described in subclause 8.1.1.