5.37.9.3 Use of connect-UDP

When the traffic is UDP and encrypted end-to-end, the UPF may be configured by the SMF establish a connection to an HTTP/3 AS proxy using connect-UDP according to IETF RFC 9298 [170], acting as an HTTP/3 client configured to use a UDP proxy. The AS then provides media related information within HTTP datagrams. The media related information in the HTTP datagrams is protected by the security of the QUIC connection established between the UPF and the AS proxy. The mechanism for exchanging HTTP Datagrams and the associated format is defined in IETF RFC 9298 [170] and IETF RFC 9297 [172].

The AF may provide via the NEF an indication of support of connect-UDP protocol to deliver media related information for encrypted traffic together with the corresponding AS proxy address and the corresponding QoS requirements. This is done using the AF session with QoS procedure (as defined in clause 4.15.6.6 of TS 23.502 [3]), Then:

• The PCF generates PCC rules including On-path N6 signalling information for Connect-UDP as defined in TS 23.503 [45].
• The SMF provides N4 rules to the UPF including the corresponding On-path N6 connection information.
• In the uplink direction, PDR rules are used to detect the UDP traffic flow subject to usage of connect-UDP and the associated FAR rules include the request to establish a connection to the AS proxy address using the connect-UDP protocol.
• In the downlink direction, PDR rules are used to detect the UDP traffic flows and QER rules are used to associate them with proper QoS related marking (e.g. including PDU set marking as defined in clause 5.37.5),

The connection is established by the UPF, at the latest at reception of an UL UDP packet matching an N4 rule with On-path N6 connection information, if not already established. UPF may use the same or different QUIC connections for different UEs depending on implementation. In order to reuse the connection, UPF sends CONNECT requests for different UEs over a single QUIC connection to the AS proxy, opening different QUIC streams to handle the traffic for the UEs.

If the traffic is carried over QUIC, UPF and AS proxy may agree on using the Forwarded Mode in IETF draft-ietf-masque-quic-proxy [200], which allows for forwarding of packets without requiring full re-encapsulation and re-encryption. In that case, the AS proxy provides the media related information within datagrams, together with the forwarded QUIC packets.

By default, UPF and AS proxy use Tunnelling Mode in IETF draft-ietf-masque-quic-proxy [200] to exchange XRM traffic. When Tunnelling Mode is used the AS provides media related information in HTTP Datagrams.

NOTE 1: During the QUIC connection establishment between the UE and the AS proxy, the UPF can learn the end-to-end QUIC Connection IDs that are used in the end-to-end flows from UE to AS and those used in the flows from AS to UE. Based on the learnt Connection ID(s), the UPF can negotiate with AS proxy according to IETF draft-ietf-masque-quic-proxy [200] to get Virtual Connection IDs (VCID(s)) corresponding to the end-to-end Connection IDs. These virtual CIDs can then be used by UPF and AS to support the Forwarded Mode.

When Forwarded Mode is active and possible for UL direction, the UPF sends UL QUIC packet towards the AS proxy using the Virtual Connection IDs negotiated via QUIC aware proxying with HTTP, IETF draft-ietf-masque-quic-proxy [200]; such UL traffic contains only the UDP payload received from the UE.

When Forwarded Mode is active and possible for DL direction, media related information is included by the AS into the forwarded UDP payload packets via a packet transform defined by 3GPP. The UPF uses a 3GPP defined packet transform (see TS 29.561 [132]) to retrieve the media related information and the content of the original end-to-end QUIC packet.

During the negotiation between UPF and AS proxy to activate the Forwarded Mode, the UPF and the AS proxy agree on the 3GPP packet transform to apply in the DL direction.

NOTE 2: The connect-UDP client in the UPF can only extract the full CIDs from e2e QUIC long-header packets to use these values in REGISTER_CLIENT_CID and REGISTER_TARGET_CID capsules defined in IETF draft-ietf-masque-quic-proxy [200]. Prior to forwarding QUIC packets with short header, the connect-UDP client (UL) and the AS proxy (DL) check whether for each direction the destination CID indicates same QUIC connection as the already registered CID, if not identical, the packets are sent in Tunnelling mode.

NOTE 3: The format of HTTP Datagrams and the format of Forwarded Mode Datagrams carrying media related information are defined in TS 29.561 [132].