5.32.6.2.1 MPTCP Functionality

As mentioned in clause 5.32.6.1, the MPTCP functionality in the UE applies the MPTCP protocol (IETF RFC 8684 [81]) and the provisioned ATSSS rules for performing access traffic steering, switching and splitting. The MPTCP functionality in the UE may communicate with the MPTCP Proxy functionality in the UPF using the user plane of the 3GPP access, or the non-3GPP access, or both.

The MPTCP functionality may be enabled in the UE when the UE provides an "MPTCP capability" during PDU Session Establishment procedure.

The network shall not enable the MPTCP functionality when the type of the MA PDU Session is Ethernet.

If the UE indicates it is capable of supporting the MPTCP functionality, as described in clause 5.32.2 and the network agrees to enable the MPTCP functionality for the MA PDU Session then:

• An associated MPTCP Proxy functionality is enabled in the UPF for the MA PDU Session by MPTCP functionality indication received in the Multi-Access Rules (MAR).
• The network allocates to UE one IP address/prefix for the MA PDU Session and two additional IP addresses/prefixes, called "MPTCP link-specific multipath" addresses/prefixes; one associated with 3GPP access and another associated with the non-3GPP access. In the UE, these two IP addresses/prefixes are used only by the MPTCP functionality. Each "MPTCP link-specific multipath" address/prefix assigned to UE may not be routable via N6. The MPTCP functionality in the UE and the MPTCP Proxy functionality in the UPF shall use the "MPTCP link-specific multipath" addresses/prefixes for subflows over non-3GPP access and over 3GPP access and MPTCP 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@1 and IP@2 correspond to the "MPTCP link-specific multipath" IP addresses. 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 "MPTCP link-specific multipath" IP addresses/prefixes shall be allocated by the UPF and shall be provided to the UE via SM NAS signalling.

NOTE 1: 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 2: The act of the UPF performing translation on traffic associated with the "MPTCP link-specific multipath" addresses to/from the MA PDU session IP address can lead to TCP port collision and exhaustion. The port collision can potentially occur because the UE also uses the MA PDU session IP address for non-MPTCP traffic and this causes the port namespace of such address to be owned simultaneously by the UE and UPF. In addition, the port exhaustion can potentially occur when the UE creates a large number of flows, because multiple IP addresses used by the UE are mapped to a single MA PDU session IP address on the UPF. The UPF needs to consider these problems based on the UPF implementation and avoid them by, for example, using additional N6-routable IP addresses for traffic associated to the link-specific multipath addresses/prefixes. How this is done is left to the implementation.

iii) The network shall send MPTCP proxy information to UE, i.e. the IP address, a port number and the type of the MPTCP proxy. The following type of MPTCP proxy shall be supported in this release:

• Type 1: Transport Converter, as defined in IETF RFC 8803 [82].

The MPTCP proxy information is retrieved by the SMF from the UPF during N4 session establishment.

The UE shall support the client extensions specified in IETF RFC 8803 [82].

• The network may indicate to UE the list of applications for which the MPTCP functionality should be applied. This is achieved by using the Steering Functionality component of an ATSSS rule (see clause 5.32.8).

NOTE 3: To protect the MPTCP proxy function (e.g. to block DDOS to the MPTCP proxy function), the IP addresses of the MPTCP Proxy Function are only accessible from the two "MPTCP link-specific multipath" IP addresses of the UE via the N3/N9 interface.

• When the UE indicates it is capable of supporting the MPTCP functionality with any steering mode and the ATSSS-LL functionality with only the Active-Standby steering mode (as specified in clause 5.32.6.1) and these functionalities are enabled for the MA PDU Session, then the UE shall route via the MA PDU Session the TCP traffic of applications for which the MPTCP functionality should be applied (i.e. the MPTCP traffic), as defined in bullet iv. The UE may route all other traffic (i.e. the non-MPTCP traffic) via the MA PDU Session, but this type of traffic shall be routed on one of 3GPP access or non-3GPP access, based on the received ATSSS rule for non-MPTCP traffic (see clause 5.32.2). The UPF shall route all other traffic (i.e. non-MPTCP traffic) based on the N4 rules provided by the SMF. This may include N4 rules for ATSSS-LL, using any steering mode as instructed by the N4 rules.