5.32.6.2.2 MPQUIC Functionalities

MPQUIC functionalities are supported as follows:

• The MPQUIC functionalities enable steering, switching and splitting of data traffic between the UE and UPF, in accordance with the ATSSS policy created by the network.
• The operation of the MPQUIC-UDP functionality is based on IETF RFC 9298 [170] "proxying UDP in HTTP", which specifies how UDP traffic can be transferred between a client (UE) and a proxy (UPF) using the IETF RFC 9114 [171] HTTP/3 protocol.

The MPQUIC-UDP functionality may be enabled for an MA PDU Session with type IPv4, IPv6 or IPv4v6, when both the UE and the network support this functionality. The MPQUIC-UDP functionality shall not be enabled when the type of the MA PDU Session is Ethernet.

• The operation of the MPQUIC-IP functionality is based on RFC 9484 [214] "Proxying IP in HTTP", which specifies how IP traffic can be transferred between a client (UE) and a proxy (UPF) using the IETF RFC 9114 [171] HTTP/3 protocol.

The MPQUIC-IP functionality may be enabled for a MA PDU Session with type IPv4, IPv6 or IPv4v6, when both the UE and the network support this functionality. The MPQUIC-IP functionality shall not be enabled when the type of the MA PDU Session is Ethernet.

• The operation of the MPQUIC-E functionality is based on IETF draft-ietf-masque-connect-ethernet [215] "Proxying Ethernet in HTTP", which specifies how Ethernet traffic can be transferred between a client (UE) and a proxy (UPF) using the IETF RFC 9114 [171] HTTP/3 protocol.

The MPQUIC-E functionality may be enabled when the type of the MA PDU Session is Ethernet. In case MPQUIC-E functionality is enabled for an Ethernet type PDU Session, the UPF should provide both IPv4 and IPv6 addresses in the MPQUIC proxy information and "MPQUIC link-specific multipath" addresses/prefixes to the SMF. Depending on the IP version of the allocated MPQUIC proxy information and "MPQUIC link-specific multipath" addresses/prefixes, the SMF indicates PDU Session type as IPv4, IPv6 or IPv4v6 in the N2 SM information to 5G-AN, as described in clause 4.22.2.1 of TS 23.502 [3].

NOTE 1: If the network provides MPQUIC proxy information and "MPQUIC link-specific multipath" addresses/prefixes for both IP versions (IPv4, IPv6), the UE can select any version of IP addresses based on its capabilities.

The HTTP/3 protocol operates on top of the QUIC protocol (IETF RFC 9000 [166], IETF RFC 9001 [167], IETF RFC 9002 [168]), which supports simultaneous communication over multiple paths, as defined in draft-ietf-quic-multipath [174].

The MPQUIC functionality(ies) in the UE communicates with the associated MPQUIC Proxy functionality(ies) in the UPF (see Figure 4.2.10-1) using the user plane of the 3GPP access, or the non-3GPP access, or both.

The MPQUIC-UDP, MPQUIC-IP and MPQUIC-E functionality(ies) are composed of three components:

• QoS flow selection & Steering mode selection: This component in the UE initiates the establishment of one or more multipath QUIC connections, after the establishment of the MA PDU Session and, for each uplink UDP flow for MPQUIC-UDP functionality), IP flow (for MPQUIC-IP functionality) and Ethernet flow (for MPQUIC-E functionality), it selects a QoS flow (based on the QoS rules), a steering mode and a transport mode (based on the ATSSS rules). This component in the UPF selects, for each downlink traffic flow of respective type, a QoS flow (based on the N4 rules), a steering mode and a transport mode (based on the N4 rules). The supported transport modes are defined below.

In the UE, this component is only used in the uplink direction, while, in the UPF, this component is only used in the downlink direction.

• HTTP/3 layer: Supports the HTTP/3 protocol defined in RFC 9114 [171] and the extensions defined in:
• IETF RFC 9298 [170] for supporting UDP proxying over HTTP;
• IETF RFC 9484 [214] for supporting IP proxying over HTTP;
• IETF draft-ietf-masque-connect-ethernet: [215] for supporting Ethernet proxying over HTTP;
• IETF RFC 9297 [172] for supporting HTTP datagrams; and
• IETF RFC 9220 [173] for supporting Extended CONNECT.

The HTTP/3 layer selects a multipath QUIC connection to be used for each traffic flow and allocates a new QUIC stream on this connection that is associated with the traffic flow. It also configures this QUIC stream to apply a specific steering mode.

In the UE, the HTTP/3 layer implements an HTTP/3 client, while, in the UPF, it implements an HTTP/3 proxy.

• QUIC layer: Supports the QUIC protocol as defined in the applicable IETF specifications (IETF RFC 9000 [166], IETF RFC 9001 [167], IETF RFC 9002 [168]) and the extensions defined in:
• IETF RFC 9221 [169] for supporting unreliable datagram transport with QUIC; and
• draft-ietf-quic-multipath [174] for supporting QUIC connections using multiple paths simultaneously.

When any one of the MPQUIC functionalities is applied, the protocol stack of the user plane is depicted in figure below.

If the UE indicates that it is capable of supporting any one of the MPQUIC-UDP, MPQUIC-IP or MPQUIC-E functionalities, as described in clause 5.32.2 and the network agrees to enable the corresponding MPQUIC Proxy functionality(ies) for the MA PDU Session then:

• An associated MPQUIC Proxy functionality is enabled in the UPF for the MA PDU Session.
• The network allocates two IP addresses/prefixes, called "MPQUIC link-specific multipath" addresses/prefixes; one associated with 3GPP access and another associated with the non-3GPP access (in the case of IP based PDU Session Types, the MPQUIC link-specific multipath addresses/prefixes are allocated in addition to the UE IP address/prefix for the MA PDU Session). In the UE, these two link-specific multipath IP addresses/prefixes are used only by the associated MPQUIC functionality. If PDU Session is of type IPv4v6, both IPv4 and IPv6 "MPQUIC link-specific multipath" addresses/prefixes are allocated for each access, i.e. four IP addresses/prefixes may be allocated to the UE. In the case of MPQUIC-E (i.e. PDU Session is of type Ethernet), the network should allocate both IPv4 address and IPv6 prefix of "MPQUIC link-specific multipath" in each access, i.e. four IP addresses/prefixes may be allocated to the UE. Each "MPQUIC link-specific multipath" address/prefix assigned to UE may not be routable via N6. The MPQUIC functionality in the UE and the associated MPQUIC Proxy functionality in the UPF shall use the "MPQUIC link-specific multipath" addresses/prefixes for transmitting traffic flows over non-3GPP access and over 3GPP access. In the case of IP based PDU session type, the MPQUIC Proxy functionality shall use the IP address/prefix of the MA PDU session for the communication with the final destination. In Figure 5.32.6.1-1, the IP@3 corresponds to the IP address of the MA PDU Session and the IP@4 and IP@5 correspond to the "MPQUIC link-specific multipath" addresses. In the case of Ethernet based PDU session type, the MAC addresses in the Ethernet frame received from UE, as described in clause 5.6.10.2, shall be used by the MPQUIC Proxy functionality for the communication with the final destination. The following UE IP address management applies:
• The MA PDU IP address/prefix shall be provided to the UE via mechanisms defined in clause 5.8.2.2.
• The "MPQUIC link-specific multipath" IP addresses/prefixes shall be allocated by the UPF and shall be provided to the UE via SM NAS signalling.

NOTE 2: After the MA PDU Session is released, the same UE IP addresses/prefixes are not allocated to another UE for MA PDU Session in a short time.

NOTE 3: When both MPQUIC-UDP and MPQUIC-IP functionalities are enabled for a single MA PDU Session, the network allocates a common single pair of "MPQUIC link-specific multipath" addresses/prefixes to be used for both MPQUIC-UDP and MPQUIC-IP functionalities.

iii) The network shall send MPQUIC proxy information to UE, i.e. one or more IP address(es) of UPF and UDP port number and the proxy type (e.g. "connect-udp"). In the case of MPQUIC-E, the network should send both IPv4 and IPv6 addresses of UPF. This information is used by the UE for establishing multipath QUIC connections with the UPF, which implements the MPQUIC Proxy functionality.

When both MPQUIC-UDP and MPQUIC-IP functionalities are enabled for a single MA PDU Session, if the MPQUIC proxy information is common for MPQUIC-UDP and MPQUIC-IP, the network sends a single MPQUIC proxy information (i.e. one IP address of MPQUIC proxy and one UDP port number) to the UE, to be used for both MPQUIC-UDP and MPQUIC-IP functionalities.

• After the MA PDU Session is established, the UE determines the number of multipath QUIC connections to be established with the UPF. The UE determines to establish at least as many multipath QUIC connections as the number of QoS flows of the MA PDU Session, i.e. one multipath QUIC connection per QoS flow. Each multipath QUIC connection carries the traffic mapped to a single QoS flow.

Security aspects are defined in TS 33.501 [29].

For the downlink traffic to which the MPQUIC functionality is to be applied, the QoS rules provided to UE include downlink QoS information and the UE applies the downlink QoS information to establish multipath QUIC connections for the QoS flows used for the downlink traffic only.

• During a QUIC connection establishment, the UE and UPF negotiate QUIC transport parameters and indicate (a) support of QUIC Datagram frames and (b) support of multipath. They indicate support of QUIC Datagram frames by providing the "max_datagram_frame_size" transport parameter with a non-zero value (see RFC 9221 [169]) and they indicate support of multipath by providing the "enable_multipath" transport parameter (see draft-ietf-quic-multipath [174]).

In addition, during a QUIC connection establishment the QoS flow associated with this connection is determined. The UE sends all traffic of a QUIC connection over the QoS flow associated with this QUIC connection. This enables the UPF to determine the QoS flow associated with a QUIC connection and to select a QUIC connection for sending the downlink traffic of a QoS flow.

• After a QUIC connection establishment, the HTTP/3 client in the UE and the HTTP/3 proxy in the UPF negotiate HTTP settings and indicate support of HTTP Datagrams (see RFC 9297 [172]) and support of Extended CONNECT (see RFC 9220 [173]). To use MPQUIC-UDP for a UDP traffic flow, the UE then sends a HTTP/3 CONNECT-UDP request (see RFC 9298 [170]) to the HTTP/3 proxy in the UPF. To use MPQUIC-IP for an IP traffic flow, the UE then sends a HTTP/3 CONNECT-IP request (see IETF RFC 9484 [214]) to the HTTP/3 proxy in the UPF. To use MPQUIC-E for an Ethernet traffic flow, the UE then sends a HTTP/3 CONNECT-Ethernet request (see IETF draft-ietf-masque-connect-ethernet [215]) to the HTTP/3 proxy in the UPF.

vii) The network may indicate to UE the list of applications for which the MPQUIC-UDP, MPQUIC-IP or MPQUIC-E functionality should be applied. This is achieved by using the Steering Functionality component of an ATSSS rule (see clause 5.32.8).

5.32.6.2.2.1 Supported Transport Modes

The MPQUIC-UDP, MPQUIC-IP and MPQUIC-E functionalities support the following transport modes for transmitting a traffic flow between UE and UPF. The PCF selects which of these transport modes shall be applied for a traffic flow (SDF). The selected transport mode is provided to UE and UPF within the ATSSS rules and N4/MAR rules respectively.

• Datagram mode 2: This transport mode encapsulates UDP packets, IP packets and Ethernet frames, as applicable, within QUIC Datagram frames and provides unreliable transport with no sequence numbering and no packet reordering / deduplication. The transport mode is defined in RFC 9298 [170] for MPQUIC-UDP functionality, in IETF RFC 9484 [214] for MPQUIC-IP functionality and in draft-ietf-masque-connect-ethernet [215] for MPQUIC-E functionality.
• Datagram mode 1: This transport mode is an extension of the mode defined in IETF RFC 9298 [170], IETF RFC 9484 [214] and draft-ietf-masque-connect-ethernet [215]. It encapsulates packets within QUIC Datagram frames and provides unreliable transport but with sequence numbering and with packet reordering / deduplication. It can be applied for any traffic flow. The details of the datagram mode 1 are defined in TS 24.193 [109].
• Stream mode: This transport mode is readily supported by the QUIC protocol. It encapsulates packets within QUIC Stream frames and provides reliable transport with sequence numbering and with packet reordering / deduplication. It can be applied for traffic flows where it is known that the application does not perform retransmissions.

NOTE 1: The Stream mode provides strict reliability and in-order delivery with re-transmissions and therefore can lead to melt down phenomena when reliable traffic (e.g. QUIC) is carried, or counteracts application decisions when UDP is selected to avoid reliability and/or in-order delivery. Therefore, it can be avoided for applications which perform their own reliability mechanisms.

NOTE 2: When a steering mode is supported by ATSSS-LL for a traffic flow (e.g. Active-Standby), one of the MPQUIC-UDP, MPQUIC-IP or MPQUIC-E functionalities can be selected if additional features, which are not supported by the ATSSS-LL functionality and PMF, are required for the traffic steering/switching/splitting of the traffic flow.