The purpose of this Technical Report is to enhance the ATSSS feature by investigating solutions that can support the following capabilities:

1. Support new steering functionalities that can steer/switch/split non-TCP traffic flows (e.g. UDP traffic flows and IP traffic flows). Two types of such steering functionalities are studied: (i) a steering functionality based on the QUIC protocol and its multipath extensions, and (ii) a steering functionality based on the DCCP protocol and its multipath extensions.
2. Support redundant traffic steering for both GBR and non-GBR traffic flows. With redundant traffic steering, a traffic flow (GBR or non-GBR) can be replicated on multiple access paths and, therefore, can improve transmission reliability and reduce packet latency.
3. Support traffic switching between one non-3GPP access path, from a UE to a N3IWF in a PLMN, and another non-3GPP access path, from the UE to a TNGF in the same PLMN.
4. Support the establishment of a MA PDU Session with one 3GPP access path via 5GC and one non-3GPP access path via ePDG/EPC. This is to complement the existing ATSSS capability that supports the establishment of a MA PDU Session with one non-3GPP access path via 5GC and one 3GPP access path via EPC.

For each of the above capabilities, the conclusions of the study identify whether a solution is required for the normative phase and, if required, which solution to consider in the normative phase.

The following documents contain provisions which, through reference in this text, constitute provisions of the present document.

• References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific.
• For a specific reference, subsequent revisions do not apply.
• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.

The study in this technical report is based on the following architectural requirements and assumptions:

• The study takes the Rel-17 ATSSS architecture (see TS 23.501) as a baseline.
• It is assumed that an MA PDU Session is required for supporting all ATSSS capabilities. Only ATSSS enhancements using an MA PDU Session are considered.
• The study may impact the core network (5GC and/or EPC) but it shall not impact the access network (e.g. NG-RAN, W-5GAN, etc.).
• All ATSSS steering functionalities (existing and new) shall reside in the UE and in an UPF. Steering functionalities outside either of the UE or the UPF are not considered.
• Any new steering functionality shall be based on the multipath extensions of the QUIC or DCCP protocols as defined in IETF.
• New ATSSS capabilities shall either be able to co-exist with the existing ATSSS capabilities or any dependencies between new and existing capabilities shall be explicitly defined.
• The study considers, not only ATSSS-capable UEs, but also ATSSS-capable 5G-RGs. The conclusions of the study identify which aspects / solutions are applicable only to ATSSS-capable UEs and which are applicable only to ATSSS-capable 5G-RGs.
• The solutions proposed to KI#5 will also be analysed whether addresses the scenario of UE simultaneously moving of both IPsec peers in the same RAT-type (i.e. UE local IP address and the anchor N3IWF/TNGF change), since according to RFC 4555 MOBIKE is not best suited.