A Survey on Multipath Transport Protocols Towards 5G Access Traffic Steering, Switching and Splitting

The fifth generation (5G) cellular network aims at providing very high data rates, ultra reliable low latency communications, and a vast increase of connection density. As one of the design trends towards these objectives, 5G exploits multi-connectivity, i.e., the concurrent use of multiple access networks. The Access Traffic Steering, Switching, and Splitting (ATSSS) architecture has recently been proposed to enable 5G multi-connectivity, and multipath transport protocols have emerged as a key ATSSS technology enabler. Within this context, this survey presents a detailed review of multipath transport protocols, identifies their existing and potential exploitation in ATSSS, and suggests their applicability for enhanced Mobile Broadband (eMBB) and Ultra Reliable Low Latency Communications (URLLC) services. To this end, we first review 5G background and current standardization activities around multi-connectivity and the ATSSS architecture. We then provide an in-depth review of multipath transport protocols, covering four core functionalities, i.e., path management, scheduling, congestion control, and reliable transfer. Based on the reviewed literature, we further discuss the integration of multipath transport into ATSSS to achieve eMBB and URLLC service requirements. Finally, we also point out major open research issues and discuss possible future directions.


I. INTRODUCTION
The 5th generation of mobile communications (5G) raises the expectations towards connecting the whole society and exploits multiple technologies to be able to accommodate the requirements of a wide range of services. As defined by the International Telecommunication Union (ITU), three major performance aspects are central in 5G: very high data rates, ultra-reliable and low latency, and massive connectivity. As such, the ITU classifies 5G services into three main categories: enhanced Mobile Broadband (eMBB), Ultra-Reliable Low-Latency Communications (URLLC), and massive Machine Type Communications (mMTC). eMBB aims to meet the people's demand for an increasingly digitally connected lifestyle and focuses on services that have high bandwidth requirements such as high definition (HD) video streaming, and virtual/augmented reality (VR/AR) applications. URLLC aims to meet digital industry expectations and focuses on latency-sensitive and high-reliability services such as assisted and automated driving, remote robotics, and mission-critical applications. mMTC aims to meet demands for a fully-connected digital society, focusing on services that include high connection density requirements such as smart cities and smart agriculture [1]. Figure 1 illustrates some examples of envisioned use cases for these three categories, representing the topological relationship in a triangle.
To fulfill the requirements of these use cases, several enhancements have been proposed both in radio access and core networks [10]. Among others, millimeter wave (mmWave), Massive MIMO, Network Slicing, Software-VOLUME xx, 2021

Reference
Year Focus of the survey OSI layer 5G aspects [3] 2011 Generalized load distributing models in multipath scheduling N/A N/A [4] 2012 Multipath solutions over reordering problem in heterogeneous wireless networks Link, network, transport, application N/A [5] 2015 Multipath solutions at different layers Physical, link, network, transport, application N/A [6] 2015 Multipath solutions at network layer Network N/A [7] 2016 Multipath solutions at different layers Link, network, transport, application N/A [8] 2016 defined Networking (SDN), Network Function Virtualization (NFV), and Multi-access Edge Computing (MEC), significantly contribute to shaping the 5G architecture [11] [12]. Further, the 5G services highlight the need for multiconnectivity in order to meet the aforementioned requirements. By exploiting multiple Radio Access Technologies (RATs) simultaneously [11], multi-connectivity provides not only Quality of Service (QoS) improvements on the user side, but also better load balancing across available RATs on the network side. Over the years, many schemes and methods for enabling efficient and reliable multi-connectivity have been proposed, especially at the radio level. Transport layer approaches have recently gained significant attention due to the Technical Specification (TS) 23.501 (Release 16) [13] by 3 rd Generation Partnership Project (3GPP), which specifies how the 5G system can be extended to support Access Traffic Steering, Switching and Splitting (ATSSS) between 3GPP access (e.g., LTE and 5G New Radio (NR)) and non-3GPP access networks (e.g., WiFi). ATSSS leverages multipath transport protocols to deliver the functionalities by manipulating traffic at the flow or intra-flow level [13] [14]. By doing so, ATSSS can conform to eMBB requirements, delivering increased throughput through concurrent transmissions, and to URLLC requirements, delivering low latency and high reliability through path redundancy.
Motivated by the benefits that ATSSS and multipath transport protocols can bring to eMBB and URLLC services, this paper surveys the state-of-the-art research efforts on multipath transport protocols, identifies how they can be leveraged in ATSSS, and suggests which 5G requirements they help to meet.

A. RELATED SURVEYS
Putting our work in context, Table 1 lists related surveys on multipath transmission. In [3], a review of load distributing models for multipath networks is provided, with focus on the description of the models rather than the layers where such models can be adopted. The work in [4] provides a review of multipath solutions that specifically solve the reordering problem in heterogeneous wireless networks. Both [5] and [7] survey multipath solutions across different layers. Targeting network-layer multipath solutions, the work in [6] focuses on literature addressing control-plane problems (how to compute and select routes) and data plane problems (how to split flows on the computed paths). A specific aspect of multipath transport protocols, i.e., multipath congestion control, is surveyed in [8]. Nevertheless, none of the aforementioned surveys discuss the application of multipath solutions in 5G, along with the requirements and benefits of doing so.
The work in [9] surveys the multipath literature for solutions that can potentially enable URLLC across different layers, including those from 3GPP up to Release 15. Differently from [9], our work is based on 3GPP Release 16 1 , and it specifically surveys multipath literature 1 We base our work in this survey on ATSSS's Rel-16 [13] [15], which lay the foundations for multi-connectivity in 5G. Currently, 3GPP's ATSSS Rel-17 (Phase 2) [16] is ongoing work and expected to be concluded during 2022. Several proposals in this phase focus on the impact in the 5G and beyond architecture as well as extensions of ATSSS. While we briefly mention the ongoing standardization efforts in Section II-E, we opt to not heavily rely on them at this stage. focusing on transport layer solutions, due to their direct applicability in ATSSS. Secondly, to ease the link between multipath transport and 5G, we present the solutions from the multipath literature and position them in relation to the ATSSS steering modes, introduced in Section II-E. Thirdly, our work surveys the multipath literature addressing both eMBB and URLLC services.

B. CONTRIBUTIONS AND OUTLINE OF THIS SURVEY
The main contribution of this survey can be summarised as follows: • We provide an overview of 5G services and their requirements with a link to multi-connectivity approaches meant to address such requirements; • We focus on multi-connectivity solutions at the transport layer, and thus analyze the main functional blocks of multipath transport protocols, i.e., path management, scheduling, congestion control, and reliable transfer; • We describe the two main options for integrating multipath transport protocols in 5G systems, i.e., abovethe-core and core-centric. For the second case, we particularly analyze the ATSSS architecture, as the most recent multi-connectivity mechanism standardized by 3GPP; • We provide a comprehensive review of work related to multipath transport, and discuss how the main components of multipath transport protocols map to specific ATSSS functionalities and modes; • We identify and discuss open research issues in ATSSS and multipath transport in 5G.
To present our contributions, we outline the survey as reported in Figure 2: In Section II we review 5G background and current standardization targeting 5G multi-connectivity.

IMT-2020
IMT-advanced We then provide a bird's eye view of multipath transport protocols and their four core functionalities, i.e., path management, scheduling, congestion control, and reliable transfer in Section III. We present a comprehensive literature overview on multipath transport protocols and discuss how they fit in 5G in Section IV. Open research challenges are summarized in Section V. We conclude our work in Section VI.

II. 5G SERVICES AND MULTI-CONNECTIVITY
In this section, we present 5G requirements and specifications for eMBB and URLLC services, as first defined by ITU and then 3GPP, respectively. We then comment on the challenges for these services requirements to coexist in the network. Finally, we introduce multi-connectivity solutions in cellular systems and focus on the ATSSS architecture, which plays a key role in enabling 5G multi-connectivity and meeting eMBB and URLLC requirements. We, in particular, highlight the application of different multipath transport protocols in the standardization of ATSSS.

A. 5G REQUIREMENTS BY ITU
In early 2012, the ITU Radiocommunication sector (ITU-R) started a program to develop "International Mobile Telecommunications (IMT) for 2020 and beyond", preparing the stage for 5G research activities to emerge around the world. In 2015, the overall 5G requirements were settled in IMT-2020 and issued by ITU-R [2]. Therein, 5G envisages a broad variety of capabilities and applications, grouped into three main services, i.e., eMBB, URLLC, and mMTC, as defined in Section I. In these services, the enhanced key capabilities are captured by several parameters such as peak data rate (Gbit/s), latency (ms), connection density (number of devices per km 2 ), energy efficiency (bit/Joule), and spectrum efficiency (bit/s/Hz). More concretely, peak data rates are expected to reach 20 Gbit/s, which is nearly 20 times higher than IMT-Advanced (i.e., 4G systems). The energy consumption for the radio  access network should be also improved by a factor at least as great as the envisaged capacity increase. Also, 5G should be able to provide 1 ms over-the-air latency to support use cases with very low latency requirements. Finally, 5G is also expected to support a connection density of up to 10 6 /km 2 . A more comprehensive view of the expected enhancement of each key capability compared with IMT-Advanced is shown in Figure 3. Further, Figure 4 shows the comparison of each key capability for eMBB, URLLC and mMTC. In eMBB, user experienced data rate, area traffic capacity, peak data rate, mobility, energy efficiency, and spectrum efficiency all have high importance. In URLLC, low latency is of the highest priority in several industrial critical applications. This key capability would be likewise required in some high mobility use cases, e.g. transportation safety. In mMTC, high connection density is needed to support a large number of devices, e.g., Internet of Things (IoT), which may intermittently use the radio access network to transmit small to large data amounts under low mobility.

B. 5G SPECIFICATIONS BY 3GPP
While ITU-R sets up the general requirements of 5G, 3GPP makes the formal specifications based on those. In particular, adopting a concept referred to as network slicing, the 5G services proposed by ITU-R are formally mapped into a Public Land Mobile Network (PLMN) with different Slice Service Type (SST) numbers [13]. Hence, different SSTs operate within the network slicing architecture, which enables the multiplexing of virtualized and SST-dedicated logical networks on the same physical network infrastructure [17].
eMBB: 3GPP Technical Report (TR) 26.891 [18] defines eMBB as SST 1, which is suitable for handling 5G eMBB, however, not limited to consumer mobile broadband applications. As shown in [19], it is expected that SST 1 supports high data rates and high traffic density scenarios such as urban and rural wide-area (macro), indoor hotspots, dense urban, very dense crowded scenarios, high-speed trains, vehicles, and airplane connectivity.
URLLC: 3GPP TR 26.891 [18] also defines URLLC as SST 2 for use cases requiring very low latency and very high service availability, i.e. a reliability between 99.9% and 99.999%. As shown in [19], it is expected that the use cases and their respective performance requirements are derived from different industry segments and processes, e.g., industry manufacturing (industry automation), intelligent transport systems (connected cars), or electricity distribution (public critical infrastructure). mMTC: 3GPP TR 26.891 [18] also defines mMTC as SST 3, with typical use cases being urban coverage with large cells and continuous coverage providing very high connection density of mMTC devices (massive IoT). As shown in [20], besides high connection density, mMTC also needs to maintain low power consumption to extend battery life up to 10 years.
5G services' coexistence: eMBB, URLLC and mMTC can also coexist as part of the same 5G network through several mechanisms, where one might be often referred to a broader term, namely, slicing. One of the most challenging places in the network where coexistence must be efficiently implemented is the Radio Access Network (RAN). Indeed, in the RAN, scheduling decisions are taken in order to optimally multiplex traffic from different services. For example, it is likely that RAN scheduling decisions prioritize URLLC over eMBB traffic, since URLLC cannot be queued until the next slot to wait for eMBB traffic, due to its strict latency requirements. In this direction, there are three main approaches proposed by 3GPP [21], namely, Puncturing, Superposition, and Orthogonal scheduler. If URLLC traffic arrives during an ongoing eMBB transmission, it can be immediately scheduled on top of eMBB, i.e., each eMBB slot is divided into mini-slots that are meant for multiplexing eMBB and URLLC traffic. Then, the gNodeB may either allocate transmission resources to both eMBB and URLLC (superposition) or temporarily interrupt eMBB traffic (puncturing) [22]. While beneficial for URLLC requirements, these methods may negatively impact the reliability of eMBB traffic. Orthogonal scheduling, on the other hand, reserves in advance (semi-static or dynamic) a number of frequency channels for URLLC. In the semi-static scheme, the gNodeB broadcasts the frame structure configuration, e.g., the current frequency numerology. In the dynamic scheme, the frame structure is frequently updated using the control channel of scheduled users, thus, incurring in higher control-plane overhead. The main drawback of this approach is to assume that URLLC traffic is always present and to reserve resources for it. Several research works also try to address such coexistence challenges. In [23], the authors propose a risk-sensitive measure to allocate resources to URLLC traffic while minimizing the risk for the eMBB traffic of achieving low rates. Hence, they propose a problem formulation that protects eMBB from drastic rate reduction while ensuring URLLC reliability. Similarly, [24] formulates an optimization problem to maximize the eMBB Minimum Expected Achieved Rate (MEAR) while provisioning URLLC, thus, focused on eMBB puncturing.
In all aforementioned 5G services, key enhancing capabilities related to throughput, latency or reliability may partially depend on the 5G system, e.g., radio frequency bands to achieve higher throughput, the radio protocol stack itself e.g. guaranteeing that all services can coexist. Other aspects however may be tackled by improving the interconnection and intersection between the 5G system and other infrastructure services, e.g., allowing service hosting (caching) on the 5G system from services outside the Internet (mobile edge computing and communication), or allowing 5G systems to leverage existing distributed cloud infrastructures for their own operation. From a different angle, how UEs connect and use the 5G system can be further leveraged. Therefore, in this paper we focus on this latter aspect, pointing to how the proven benefits of multi-connectivity and, more specifically, of multipath transport [25] [26] [27], can aid 5G services to reach their key performance indicators. In more detail, we focus on aspects such as high throughput in eMBB, and low latency and high reliability in URLLC.

C. MULTI-CONNECTIVITY IN CELLULAR NETWORKS
Multi-connectivity is one of the paradigms in 5G that aim at satisfying the service requirements defined in Section II-A. We provide in this section a brief overview on existing multi-connectivity solutions for cellular networks, along with related standardization activities.
One of the first multi-connectivity solutions was introduced in 3GPP Rel-8 (2008) and referred to as Access Network Discovery and Selection Function (ANDSF) [28]. In particular, ANDSF targets interoperability between 3GPP and non-3GPP systems. Focusing on the cellular access, Coordinated Multi-Point (CoMP) was introduced in Rel- 11 (2012). In this case, multiple base stations can transmit (receive) in parallel the same data towards a UE, in order to improve the communication quality in poor coverage areas. While CoMP lies across physical and MAC layers, Dual Connectivity (DC) is performed in the above Packet Data Convergence Protocol (PDCP) layer. Standardized in Rel-12 (2015), DC allows a UE to exploit two not co-located LTE access nodes, e.g., two evolved Node Bs (eNBs). The Master eNB terminates the control plane in the LTE core and coordinates with the Secondary eNB to provide additional radio resources to the UE. Similar solutions are then introduced for non-3GPP access in Rel-13 (2016) and extended in Rel-14 (2017). They are referred to as LTE-WLAN Aggregation (LWA) and LTE-WLAN radio-level integration with IP security tunnel (LWIP). In both cases, the WiFi access point has a similar scope compared to a Secondary eNB in DC, and can be colocated or not with the primary access node. The user device reports WiFi-related measurements to the cellular network, which decides to activate or not the multi-connectivity option. The WiFi traffic is managed within the LTE system via specific adaptation protocols [29]. Mechanisms similar to LWA and LWIP can be envisioned for 5G [30]. However, initial proposals in Rel-15 (2018) were focused on cellular VOLUME xx, 2021 access, and have led to extending DC to support parallel use of LTE and 5G NR.
In the next section, we focus on two main approaches that aim at integrating multipath transport solutions to enable multi-connectivity in 5G systems. After introducing two main options, we detail the ATSSS architecture, which is one of the main multi-connectivity frameworks for 5G. Proposed in Rel-16, ATSSS proposes a direct integration and use of multipath transport protocols in 5G systems.

D. TRANSPORT LAYER MULTI-CONNECTIVITY IN 5G
Currently, two main approaches are highlighted to tackle 5G multi-connectivity via multipath transport solutions: Above-the-Core and Core-Centric. In the Above-the-Core integration, the multipath transport protocol is deployed at the client and the server sides, and the aggregation of different paths occurs in between, without impacting the network. In the Core-Centric integration, the multipath transport protocol is deployed at the client and in the 5G Core (i.e., through a multipath proxy), and single path transport is run between the core network and the server. A high-level view of both approaches is shown in Figure 5, with yellow and green dashed lines representing Above-the-Core and Core-Centric, respectively.
The Above-the-Core integration has been prevalent in academia and industry, with several contributions. For example, several early efforts show the benefits of multipath transport protocols in smartphones [31], [32], [33], [34], [35], which could be seen as predecessors of the ongoing standardization activities in 5G multi-connectivity. The goal of the first measurement studies was to evaluate whether the proven benefits of multipath transport in data center networks could be also leveraged by multi-homed devices, e.g., smartphones, and by network operators, e.g., to offload cellular network traffic to WLAN. The majority of these contributions use Multipath Transmission Control Protocol (MPTCP) as the base transport protocol, with exception of [36], that presents both MPTCP and Multipath QUIC (MPQUIC). Few others focus on developing tools to tune application and transport protocol interaction to improve performance and battery life [37], [38]. It is consistently demonstrated that multipath transport can mitigate the impact of handover in applications under mobility, e.g., when moving between WLAN and cellular coverage. Since early experiments in 2013, this aspect has been particularly supported by iPhone devices [39], and also more recently in 2020 by Alibaba and Apple and [40].
The Core-Centric integration, as highlighted by several use cases [41] [42], is a stronger candidate to be adopted in 5G systems, since it enables a more direct control of multi-connectivity within the cellular system. 3GPP has specified the ATSSS architecture in TS 23.501 Rel-16, as an instantiation of the Core-Centric approach.
The key concept being introduced is the Multi-Access Protocol Data Unit (MA PDU) session. The MA PDU session generalizes the single-access PDU session and allows an application to send/receive traffic over 3GPP access, non-3GPP access, or both simultaneously. The MA PDU session is enabled in the ATSSS architecture, which is depicted in Figure 5; it is established between the User Equipment (UE) and User Plane Function (UPF), with both 3GPP and non-3GPP access networks in the middle. Moreover, as shown in Figure 5, other 5G core network functions are involved in the ATSSS operation, i.e., Access and Mobility Management Function (AMF), Session Management Function (SMF), and Policy Control function (PCF). Once a MA PDU session is established, it handles the traffic over different networks via Steering, Switching, and Splitting functions, defined as follows: • Steering: It enables the selection and use of an access network for a data flow; • Switching: It allows to redirect all traffic of an ongoing data flow from one access network to another, while maintaining service continuity; • Splitting: It enables the splitting of the traffic of a data flow across multiple access networks, so that some traffic of the data flow is transferred via one access and some other traffic of the same data flow is transferred via another access.
As shown in Figure 5, the PCF controls ATSSS by delivering the policy rule to the SMF. The policy rule, shared by the SMF with the UE (uplink) or the UPF (downlink), contains the indication on which ATSSS steering function and steering mode to adopt. To simplify the terminology from TS 23.501, we refer in the following to only steering, when referring to Steering, Switching, or Splitting.
With the notion of MA PDU introduced by ATSSS, there are several options for fine grained control of data flows to be served over one or more access networks. For example, Steering selects, across several available access networks, the one that better fulfills a certain mode, e.g., smallest delay, etc. Switching, on the other hand, takes a hard decision to abandon one of the access networks and invariably use either one access network or another, e.g., enabling connection migration and handover mechanisms. Splitting allows for using (two or more) access networks simultaneously, transferring different parts of a data flow on each available access network. Finally, Splitting allows for selecting a particular access network to provide, e.g., redundancy, or both accesses to provide, e.g, aggregation. As further detailed below, multipath transport protocols plays a key role to realize such functionality.

E. APPLICATIONS OF MULTIPATH TRANSPORT PROTOCOLS IN 5G ATSSS
TS 23.501 defines two ways of implementing steering functionalities: a) the use of a multipath transport protocol, above the IP layer, and b) the use of a so-called ATSSS Lower Layer (ATSSS-LL), below the IP layer. In the case of multipath transport, as shown in Figure 5, the UE and UPF communicate through the Multipath Transport Function (in the UE) and the Multipath Transport Proxy Function (in the UPF). In the case of ATSSS-LL, the UE and UPF communicate with each other via the combination of ATSSS-LL Function of the UE and UPF. In addition, UPF supports Performance Measurement Functionality (PMF), that may be used by the MA PDU session to obtain access performance measurements over 3GPP and/or non-3GPP access networks.
While there is no recommendation on the method for ATSSS-LL yet in Rel-16, TS 23.501 Rel-16 identifies a specific multipath transport protocol for the multipath transport functionality, i.e., MPTCP. However, in the studies that lead up to 3GPP Rel-16 more protocols were analyzed for ATSSS support in the 5G System architecture. During these studies, recorded in TR 23.793 [15], the use of QUIC, MPQUIC, Stream Control Transmission Protocol (SCTP), and multipath User Datagram Protocol (UDP) were considered.
In terms of steering modes, TS 23.501 defines four different modes that can be used with ATSSS, as follows: • Active-Standby: The traffic of an MA-PDU session is sent to one access network only, referred to as "active" access. The other access network is in "standby" and takes traffic only when the active one is unavailable. The active access is defined when the MA-PDU session is established and can remain the same or change during the session lifetime; • Priority-based: Some priority weights are assigned to the available access networks either statically during the establishment of a MA-PDU session or dynamically during the lifetime of a MA-PDU session. The traffic is managed by the higher priority access; however, when it is congested or unavailable, the traffic is redirected onto the lower priority access; • Smallest Delay: The used access network is the one providing the shortest Round Trip Time (RTT). It conceptually belongs to the Priority-based mode but, in this case, the higher priority access is determined dynamically in the lifetime of an MA-PDU session, based on RTT measurements; • Load-balancing: Each access network receives a percentage of the data of the MA-PDU session, depending on the assigned weight factor. If one access becomes unavailable, all traffic is sent to the other. Moreover, two further modes were under discussion in TR 23.793, and can be foreseen as possible extensions for future ATSSS specifications: • Best-Access: It generalizes the Smallest Delay mode, making it possible to adopt other factors rather than RTT to decide the access network with the best performance to use. It also conceptually belongs to the Priority-based mode, but in this case, the higher priority access is also determined dynamically during the lifetime of an MA-PDU session, based on the performance of the access; • Redundant: All or some data flows are transmitted on both accesses in order to increase reliability. The above steering modes are all supported by MPTCP.
The standardization of 3GPP Rel-17 and ATSSS Phase 2 is at the time of writing of this article on-going work, expected to conclude in March 2022. Phase 2 is focused VOLUME xx, 2021 on defining several improvements of the steering modes, such as different ways of controlling the load balancing or determining when a path is congested for the priority-based steering mode. However, the studies preceding ATSSS Phase 2 [43] again considered additional steering functionalities based on both QUIC and MP-QUIC, as well as adding a QUIC-based proxy (with and without multipath capability). The latter still depends on work to be carried out at the IETF.
Further, the ATSSS Phase 2 study item hints to an ATSSS Phase 3, including features and scenarios that are out-ofscope in ATSSS Phase 2, e.g., a MA PDU session with more than two network paths. Discussions on what study items to include for Rel-18 are ongoing at the time of writing. QUIC and MP-QUIC are again under discussion and Multipath DCCP [44] has also been suggested as an option. As Rel-17 is still ongoing work and standardization of Rel-18 has not yet started, we opt to base the work in this survey on ATSSS Release 16 [13] [15], which already lay the foundation for the on-going work in the subsequent ATSSS phases.
The key role of multipath transport protocols in ATSSS motivates us to investigate multipath transport protocols more generally in the literature. We report our review and analysis in Sections III and IV, respectively, where we also highlight a) the connection to the ATSSS architecture and mapping with ATSSS steering modes considered for ATSSS Phase 1, and b) how the proposed multipath schemes may help towards satisfying the requirements of 5G eMBB and URLLC services.

III. BACKGROUND ON MULTIPATH TRANSPORT
Multipath transport protocols are designed to improve both communication throughput and resilience as they are able to leverage several network paths simultaneously and seamlessly support failover. We note that all three transport protocols considered in this survey, namely, SCTP, TCP and QUIC, have different multipath features supporting at least one of the multipath benefits (throughput and/or resilience). For example, SCTP is already able to leverage multiple paths, however, it uses one primary path while others are meant for failover, when the primary path fails. Thus, SCTP is able to natively improve resilience. Also, QUIC with its connection migration feature is able to move a connection across network accesses, thus, also improving failover. TCP, on the other hand, does not natively support failover as it ties IP addresses and ports to identify connections. None of the single-path implementations are able to improve throughput, which is, beyond improved resilience, one of the main promised benefits of their multipath counterparts, which we refer to in more detail in following. The realisation of the multipath connection depends on the protocol implementation specifics. Figure 6 depicts a high-level representation of the single path (left-hand side) and the multipath (righthand side) protocol stacks. Nowadays, three main multipath protocols exist, i.e., Concurrent Multipath Transfer SCTP (CMT-SCTP), MPTCP, and MPQUIC, which are the focuses of this survey. In addition, IETF recently has also initiated work on extending the Datagram Congestion Control Protocol (DCCP) [45] to support the multipath operation, aiming to deliver Multipath DCCP (MP-DCCP) [44].
As an extension of SCTP, CMT-SCTP [25] [46] is one of the first multipath transport protocols that considered the simultaneous data transfer over different paths. MPTCP [47] implements the multipath extension of the most widely used transport layer protocol, TCP. It is designed to be transparent to both higher and lower layers, in order to counteract the proliferation of middleboxes in the Internet that hinder the deployment of new transport protocols [48]. Recently, IETF QUIC 1 became an attractive alternative to TCP since it can combine the benefits of HTTP/2, Transport Layer Security (TLS) and TCP over UDP to reduce latency and improve security. QUIC encrypts all payload and most of the protocol headers to prevent interference from middleboxes [50]. Motivated by the success of MPTCP and the interest in QUIC by both industry and academia [51] [52], the multipath extension for QUIC (MPQUIC) is proposed in [53] [54], with similarities to MPTCP.
Note that, MPTCP plays a central role in ATSSS while MPQUIC has been discussed as an alternative. In this paper, as much as we would like to keep the discussions more general on multipath transport protocols, due to its maturity and adoption in the community we refer more often to MPTCP literature.
Despite different transport protocol design and implementations, all above mentioned multipath transport protocols share four common functionalities, which are of relevance in ATSSS: • The multipath path management, which is in charge of initiating and managing the connections, i.e., subflows, part of the same multipath connection. • The multipath scheduling, which is in charge of distributing packets over different paths following a certain policy, e.g., aggregated throughput (utilise all available capacity), reduce latency (prefer low latency paths) or improve reliability (duplicate packets). • The multipath congestion control, which aims to detect network congestion, adjust the sender rate accordingly (as in the single path case), and deal with other aspects of a multipath transmission, e.g., fairness towards single path traffic. • The reliable transfer, which is in charge of loss detection and loss recovery (as in the single path case) by having a mechanism at the sender that detects packet losses and an associate mechanism in charge of recovering these packets with retransmissions.
Next, we describe these main functionalities. In Section IV, we will review the state-of-the-art literature for these functionalities and provide a direct mapping of them to the ATSSS modes.

A. MULTIPATH PATH MANAGEMENT
The path manager component determines what path to use for connection establishment and when and how additional subflows are established, and it can also control the advertisement or acceptance of available IP addresses for new subflows. This logic generally depends on the application requirements, e.g., some applications use multipath only for handover while others use it for load sharing. In general, however, the combination of how and when subflows are established with how the subflows are used during the connection, e.g., how packets are distributed over them, is performed in conjunction with the multipath scheduler, described in next section. For instance, the path management algorithm can establish a subflow over each of two paths, and the scheduler, e.g., by means of measuring the RTT of the subflows, can prefer the subflow with the lowest RTT. This operation mode describes very closely the default path management and scheduling operations in MPTCP.
To better understand how a path manager operates in MPTCP, we provide an example, illustrated in Figure 7: Host A signals to Host B the support for MPTCP via a MP_CAPABLE TCP option during the initial handshake. Once the initial subflow is established, the MP_JOIN option is sent to associate a new subflow to the existing MPTCP connection. If Host A gets a new IP address during the connection, MP_ADD is signalled by MPTCP, telling Host B about the new address, where a new subflow can be established. For example, if Host A and Host B have initially two IP addresses each, and all possible subflows are established, the multipath connection results in a full-mesh of subflows, i.e., A1-B1, A1-B2, A2-B1, A2-B2. If Host A gets a new address, denoted A3, during the connection, it can signal this address to Host B, and additional subflows can be added to the multipath connection, i.e., A3-B1 and A3-B2. In MPTCP, there are currently three implementations for path management: • Default neither announces IP addresses nor initiates the creation of new subflows, as it only accepts their passive creation, e.g., a request from the remote host; • Fullmesh establishes the full-mesh of subflows according to the available IP addresses, similar to the previous example with Host A and Host B (see Figure 7); • Ndiffports uses the same pair of IP addresses, where each subflow has a different source TCP port.
The path management in MPQUIC is specified with a different approach [55], [56]: during the handshake, both hosts can negotiate the multipath capability via frames, and path management can be implemented via the PATH_STATUS frame. With this frame, the hosts can signal preference or claim the state for a subflow, e.g., set the subflow as available, standby, mark its priority or simply abandon it. To validate a path, i.e., probe it, PATH_CHALLENGE and PATH_RESPONSE frames can be used. As regards SCTP, during the association startup, a primary path is defined for each SCTP host and used for sending SCTP packets, where all other paths are used for failover or used for retransmissions. The IP addresses in a SCTP association are exchanged and verified during association setup, and each destination address is a different path towards the corresponding host. The path reachability is verified with heartbeat chunks sent periodically to all destinations. Dynamic Address Reconfiguration (DAR) is an SCTP extension for SCTP's multihoming, and enables to dynamically add or delete IP addresses, and to request a primary-path change during an active SCTP association.

B. MULTIPATH SCHEDULING
The multipath scheduler component is primarily in charge of distributing data over available paths according to the given policy. The available paths can be classified as homogeneous or heterogeneous, depending on how similar they are in terms of bandwidth, delay, loss rates, and other characteristics [57]. Prior to using the paths, they need to be established at the beginning or during the multipath connection by the path manager, see Section III-A.
To illustrate the challenges involved in scheduling, let us consider a basic Round-Robin (RR) scheduler. In MPTCP, RR cyclically sends packets over each path, as long as there is space in their Congestion Windows (CWND). While this is a very simple approach that may work reasonably for homogeneous paths, RR is not very useful in practice as it does not account for path heterogeneity. Since RR does not use any characteristics of the paths in the scheduling decision, the packets may arrive out-of-order, which causes receiver buffer blocking and head-of-line blocking when data can be only delivered to the application in-order, thus, VOLUME xx, 2021 decreasing overall performance [58] [59]. In general, as path heterogeneity increases, scheduling and making use of multiple paths gets more challenging.
There are different ways to tackle multipath scheduling performance challenges. For example, the scheduler can use transport layer information, e.g., RTT and CWND, to estimate the transfer time of each packet on each path. Based on the estimation, the scheduler tries to distribute packets so that they arrive in order [60] [61] [62]. Alternatively, the scheduler can duplicate packets to provide low latency or high reliability. The need depends on the current path status and the optimization goal (throughput or latency). More recently, machine learning approaches (e.g., reinforcement or supervised learning, etc.) are used as ways to enable latency and/or throughput optimization in the same algorithm. Here, machine learning features can be derived from transport layer information such as RTT, CWND, inflight packets [63] [64] [65], etc.

C. MULTIPATH CONGESTION CONTROL
Traditionally designed for single-path TCP scenarios, congestion control algorithms operate on packet-level characteristics such as loss and delay to detect network congestion and react accordingly, e.g., by adjusting the sending rate. Among other requirements, there is a fairness notion that guarantees the same resources for each TCP flow, e.g., the same bandwidth at the shared bottleneck [66].
However, the emergence of multipath transport protocols brought the need to revisit the fairness aspect. In the case of CMT-SCTP, the protocol treats all paths belonging to a multipath connection separately, applying single-path congestion control over each independently. In MPTCP, the fairness aspect is part of its three design goals, as discussed in [66] [67] [68]: 1) Improve Throughput: A multipath flow should perform at least as well as a single path flow would on the best available path; 2) Do Not Harm: On each path, a multipath flow should not take more resources than other single path flows; 3) Balance Congestion: A multipath flow should move as much traffic as possible off its most congested paths, subject to meeting the first two goals. Requirement 2) has driven specifically the design of several algorithms, and it is mentioned as "fairness in the broader, network sense" in RFC6356 [69]. When it comes to MPQUIC, it is still unclear which direction standardization will take. Initial research-oriented proposals [27] [70] suggest a design similar to MPTCP. More generally, multipath congestion control is categorised into uncoupled and coupled approaches. The uncoupled proposals treat each of the subflows of a single multipath connection as individual connections, i.e., their CWND is increased or reduced without considering other subflows. However, for the sake of standardization, the coupled proposals were adopted, as described in RFC6356, since it treats all subflows belonging to the multipath connection as a single connection. In MPTCP, the increase of all CWNDs of the subflows from the same multipath connection should not exceed that of a single TCP connection, thus not unfairly interacting with single path traffic. The CWND decrease, however, is handled individually, since if one of the paths is more congested than others, the subflow of the multipath connection should back-off as single-path traffic would do.

D. RELIABLE TRANSFER
Transport layer protocols are mainly distinguished by providing reliable or unreliable data transfer. For instance, all data sent over TCP is guaranteed to be delivered, i.e, TCP is fully-reliable. UDP, on the other hand, does not keep track of lost or corrupted packets, i.e., it does not provide guaranteed delivery and it is unreliable. 1 SCTP on the other hand also implements partial reliability, i.e., some level of packet loss can be tolerated. Multipath variants of these protocols implement reliability as in their single-path counterparts, however, with functionalities specifically meant for multipath. For example, in MPTCP, as long as packet loss is recovered by a fast retransmit, i.e., the receiver sends Duplicated ACKS (DupACKs) to signal missing packet(s) to the sender; these packets are recovered in the same subflow. Otherwise, if packet loss is detected by a Retransmission Timeout (RTO), they are also retransmitted on other subflow(s).
These loss detection and recovery mechanisms were designed with some assumptions about the underlying networks and they are known to perform suboptimally in some cases, especially when delay and loss rates are high [72]. Therefore, there is interest to apply approaches such as Forward Error Correction (FEC) and Network Coding (NC) [73] in transport protocols. In FEC, input data is encoded at the sender resulting in a combination of source and repair packets, where repair packets are used to recover lost packets at the receiver. On the other hand, NC can be performed at the sender and on intermediate nodes (all or a subset of them).
In the past, different FEC and NC algorithms have been proposed inside the transport layer, in particular for TCP, where the implementations were often in conflict with the congestion control operation and prohibitively complex [74]. For multipath, FEC and NC mechanisms are applied in the subflow level [75] [76], i.e., in the single path transport protocol connection (subflow) to alleviate the heterogeneity of the underlying paths, especially when these have different loss rates.

IV. REVIEW OF MULTIPATH TRANSPORT LITERATURE
This section provides a review of literature addressing main aspects of the functionalities of multipath transport protocols, i.e., path management, scheduling, congestion control, and reliable transfer, as introduced in Section III. In particular, the reviewed works are categorized in terms of ATSSS modes, in order to emphasize how they can be exploited in ATSSS to improve 5G multi-connectivity, ultimately contributing to achieving eMBB and URLLC service requirements.

A. MULTIPATH PATH MANAGEMENT
Besides path establishment provisioning, the path manager can support the implementation of the ATSSS modes. More specifically, the implementation of handover closely resembles the Active-Standby ATSSS steering mode, where a path manager tries to use the active network access and switch to the standby path after a certain number of retransmissions. This operation mode is very similar to MPTCP in Apple iPhones. Similarly, a path manager that establishes subflows over all paths combined with a packet scheduler that favors subflows with the lowest RTT resembles Smallest Delay ATSSS steering mode as well as MPTCP's Linux operation.
Exploring path management in handover scenarios, [33] performs a real-world study using WiFi/3G to show that MPTCP maintains application connectivity when moving between network connections. In addition, by sparing one bit as an echo bit in Remove Address and Add Address options, and [33] develops a scheme to tackle application degradation. Depending on the active states of paths during handover, [33] shows that MPTCP can decrease the application delay for VoIP up to 20 times than single path TCP. In [77] the authors summarize the points that should be considered on the radio access network when implementing data offloading with MPTCP covering complementary coverage, spectrum aggregation and utilization, radio planning, RF load balancing, channel holding time, deployment, backhaul capacity, and mobility. [78] investigates handover connection disruption and glitches with MPTCP. To improve service continuity during handovers, it uses a proactive cross-layer assisted mechanism with Signal-To-Noise (SNR) and Bandwidth-Delay Product (BDP) based CWND adjustments. During handover, mechanism proposed in [78] can reach 2 to 5 times throughput increase compared with the default MPTCP. [79] presents an analytical model for multipath WiFi/cellular handover, which derives the aggregate handover time, providing a tool for tuning the cellular bitrate to satisfy the users' transmission requirements while maximizing the network resource utilization efficiency.
In the path management implementations available in MPTCP, full-mesh might be more suitable for Internet scenarios, exploring all possible combinations between IP addresses of two hosts, thus, supporting applications that aim at load balancing or improving throughput. Similarly, Ndiffports was originally designed for datacenter networks to enable load-balanced paths with Equal Cost Multipath (ECMP) [80]. Default is implemented to passively accept the creation of new subflows. Finally, while not a path manager in the strict sense, binder [81] focuses on community networks to help applications to benefit from gateway aggregation using loose source routing. For the examined scenario of dramatic network changes in the period of 3 seconds, binder consistently outperforms TCP baseline with an improvement ranging from 20% to 60%.
In MPQUIC the design of path management is on-going work, where, so far, it is taking a different approach compared to MPTCP. To date, in MPQUIC, the proposal is that hosts can signal and negotiate via frames how to establish and use network paths during the connection lifetime, see Section III-A. In other words there are no path management implementations serving different scenarios such as it is the case in MPTCP.
Finally, leveraging SCTP for path handover, [82], [83], [84], [85] and several others surveyed in [86] cite the problems of spurious retransmissions, unnecessary CWND reductions and reordering caused by path handover. [87] evaluates the feasibility to combine both CMT and SCTP with dynamic address reconfiguration as a potential enhancement to the handover schemes.

B. MULTIPATH SCHEDULING
Multipath scheduling is in charge of distributing data onto different paths. This is a core function in a multipath transport protocol, since wrong scheduling decisions can lead to performance decrease, particularly due to out-oforder data delivery at the receiver. In [25] [59] show that Round-Robin (RR) is only effective when paths are homogeneous. Thus, to guarantee multipath transport performance enhancements with any combination of network paths, many scheduling approaches have been proposed. We categorize them into six categories resembling ATSSS steering modes introduced in Section II-E: 1) Smallest Delay, 2) Best-Access, 3) Priority-based, 4) Load-balancing, 5) Redundant, and 6) Active-Standby. Note that, while many multipath scheduler algorithms are applicable accross protocols, some algorithms may explore features of the transport protocols that may be available in one implementation but not in other, e.g., the notion of streams in CMT-SCTP and MPQUIC absent in MPTCP. In the following, we refer to stream-based multipath schedulers when applicable to each of the ATSSS categories.
We notice that minRTT is by definition the only scheduling algorithm mapping to Smallest Delay steering mode. It is the default algorithm in MPTCP [88], and prioritizes the path with the lowest estimated RTT, if it is not congested. As the congestion level increases, minRTT redirects traffic on the other paths.
In Best-Access steering mode, the definition of "best" is generally referred to as the best performance, but refers to the estimated latency of the paths in most of the literature. The estimated latency uses other features besides RTT as information, thus somehow extending the Smallest Delay steering mode. Out-of-order Transfer for Inorder Arrival (OTIAS) [89] is, in many aspects, similar to Earliest Completion First (ECF) [61]. They apply a proactive approach [62], i.e., the path with the shortest VOLUME xx, 2021 transfer time is prioritized regardless of the congestion level (CWND space). Therefore, the transfer time also includes the time of waiting for the space in the CWND, which is different from a reactive approach, e.g., minRTT. The work in [90] applies a similar approach but taking stream priority in MPQUIC into account. Blocking Estimationbased (BLEST) [60] reduces receiver buffer blocking by prioritizing the faster path using RTT, inflight packets, CWND, and send window size as estimates. Shortest Transmission Time First (STTF) [62] comes as a fine-grained shortest delay version of BLEST targeting short flows. Compared with the default scheduler minRTT, BLEST and STTF are particularly shown to reduce web object transmission times with up to 51% and provide 45% faster communication for interactive applications. In terms of cross-layer approaches, Quality Aware (QAware) [91] incorporates the local queue buffer occupancy information of the Network Interface Card (NIC), aiming at improving the estimation of end-to-end delay. QAware can provide an improvement with up to 37% over the minRTT scheduler. The work in [92] focuses on throughput in cloud networking, creating subflows over disjoint paths, and using cross-layer information from MPTCP and the Location Identifier Separation Protocol (LISP) to learn about paths' diversity. Furthermore, [93] proposes a cross-layer scheduler for video streaming, using both application and transport layer information. Different from the above approaches, [94] proposes the client-based multipath TCP (cMPTCP) that aims to be deployed over multiple LTE networks from different operators. cMPTCP utilizes the client to infer the bottleneck state of an endto-end MPTCP connection, aiming for a more accurate selection of the best-access. cMPTCP is shown to outperform the default minRTT with up to 18.5% and the other state-of-the-art multipath schedulers such as ECF with up to 11.7% for the download throughput. Applying machine learning to determine the best-access path is another set of approaches. Reles [63] uses offline reinforcement learning, i.e., a Deep Q-Network (DQN), to train a multipath scheduler with throughput as the reward, and delay and packet loss as penalties. A similar approach is applied in [64], where a penalty is given when the number of unacknowledged packets exceeds a limit. Applying online learning in MPQUIC, Peekaboo [65] proposes a multipath scheduler that is aware of the dynamics of the paths and can adapt its scheduling strategy accordingly. More recently, [95] proposes an enhancement to Peekaboo, i.e., M-Peekaboo, capable of handling high oscillations in terms of network path characteristics, i.e, delay, bandwidth and loss, observed in 5G millimeter wave network paths. These scheduling approaches based on machine learning in general outperform the selected scheduling approaches that are not based on machine learning. For example, M-Peekaboo is shown to outperform BLEST with up to 28.7% in the emulated 5G networks.
The Priority-based steering mode can include both the Smallest Delay mode and Best-Access mode. However, we try to assign the works from literature to the steering mode that is as specific as possible, thus only covering the works that are exclusive in the Priority-based steering mode here. The works belonging to this steering mode use pre-defined priority information to influence the scheduling decision. MP-DASH [96] proposes a scheduling framework for video streaming that is aware of network interface preferences from users, e.g., prioritizing WiFi over cellular links. The scheduling decision is deducted by solving an integer programming problem to minimize the usage of the unwanted path while trying to meet users' Quality of Experience (QoE) requirements. The results indicate that MP-DASH can reduce cellular usage by up to 99% and radio energy consumption by up to 85% with negligible degradation of QoE, compared with off-the-shelf MPTCP. The work in [97] adopts the purchased price of the path as the prior information. It is assumed that, under a guaranteed throughput, the users prefer to use the path having lower costs. Then, by applying Lyapunov optimization, the paper aims at maximizing the throughput while minimizing the price cost for users. Also adopting the path cost to derive the priority, [98] proposes a cost-based scheduling algorithm, which simultaneously reduces the cost of multipath use for network operators and also retains the QoE levels required by the end-users in case of bursty video-on-demand traffic. Both [97] and [98] present it is possible to maintain the performance metric as the default minRTT, while possibly decreasing the cost ranging from 20% to more than 50%.
The goal of Load-balancing steering mode is to assign a number of packets for each path, aiming at balancing the load over different paths. The main difference with the other steering modes is that it directly schedules a group of packets together, while the other steering modes schedule on a per-packet basis. When assigning packets to paths, the existing works usually take into account the capacity and latency of each path. Forward Prediction Scheduling (FPS) [99] predicts the packets' arrival time and sends packets in a manner that they are expected to be received. Delay Aware Packet Scheduling (DAPS) [100] assigns the number of packets over each path based on the ratio of RTT between the paths. [101] considers the RTT of different paths for load-balancing at the sender side to specifically rearrange the transmission order of packets. An approach for actively sensing the paths' status and quality is proposed in [102], aiming at addressing the inaccurate estimation of the path latency when assigning the load to each path, caused by the underlying wireless networks. [99], [100], [102], and [101] mainly compare with RR and show the throughput increase ranging from 10% to 40%. The mechanism proposed in [103] is tailored for lossy networks and takes loss rates into account to model and estimate latency and data amount to send on each path. According to the experimental results, [103] can increase the download throughput around 10% compared with FPS. [104] argues that although pre-allocating packets over different paths seem to ensure in-order-arrival, there often exists a mismatch between the estimated and the real transfer time, especially in wireless networks. To compensate for the inaccurate estimation, a gap composed of several packets that are not yet scheduled is left between the packets sent over different paths, and is self-adjusted based on ACKs which can reflect the out-of-order arrival degree. [104] shows that our scheduler can improve the throughput up to 30% when the in-network buffer is limited, 15% when the host buffer is limited, compared with ECF. In [105], PStream explores priority-based stream in MPQUIC making use of stream to alleviate head-of-line-blocking in heterogeneous environments. Evaluation shows that PStream can reduce up to 25.4% of page load time in high path heterogeneity, compared to minRTT. Focusing on video QoE [106] NineTails is a multipath MPQUIC scheduler that utilizes selective multipath redundancy to control tail loss and neartail loss latencies in heterogeneous wireless networks. With this design thought, NineTails is shown to decrease the tail application latency up to 18%.
In Redundant steering mode, some or all packets are duplicated to enhance the service reliability and obtain the lowest latency over different paths. ReMP [107] proposes duplication for all the packets to reduce latency and increase reliability. For a real world mobile scenario in a stressed dynamic environment, ReMP TCP can halve the average round-trip time and reduce its standard deviation by a factor of 19. However, this comes with a substantial bandwidth overhead. Hence, several multipath scheduling algorithms categorized under Redundant mode actually provide advanced solutions, which in essence combine Redundant with other ATSSS steering modes, ultimately paving the way towards ATSSS enhancements. For example, leveraging selective packet duplication, the work in [108] proposes an adaptive mechanism that duplicates packets only when a path degrades, estimated by observing one-way-delay fluctuations, and combines this with the Load-balancing mode. Targeting vehicle-type applications, Redundancy-Aided VEhicular Networking (RAVEN) [109] proposes a trade-off between data usage and duplication degree, introducing a confidence interval in the scheduling: If all packets are duplicated, 100% confidence interval is achieved. In its mechanisms, RAVEN jointly covers Redundant and Smallest delay steering modes. Nevertheless, although significant gains ranging from 24.5% to 53.2% are obtained, both [108] and [109] only compare with default minRTT. [110] REdundant Diversity scheduling (RED) prioritizes packet replication by uncorrelated paths, selecting paths and replicates packets based on the Spearman's correlation coefficient. Compared with pure redundant multipath scheduler, like ReMP, RED can achieve up to 30% higher throughput. Similarly, but targeting high loss networks, [111] proposes an adaptive duplication scheme based on the estimation of the per path loss rate, thus balancing Redundant and Bestaccess modes, the latter using RTT and loss rate in order to determine the path latency. While the proposed approach maintains mean delay at the same level of ReMP and up to 3 times smaller than minRTT, it can reach up to 2 times of throughput over ReMP and at the same level of minRTT.
The Active-Standby steering mode utilizes only one active path for transmission while other paths are used for backup. Thus, it focuses on the seamless handover applied in multipath, which is also studied in the literature [82] [33] [112]. Furthermore, several multipath proposals lie across multiple ATSSS steering modes. For example, the mechanism introduced in [58] initially tries all paths and suspend the path with a low score to ensure in-order packet delivery, ultimately combining Active-Standby with Smallest delay. Similarly, [113] decides if the scheduler should stop using a certain path when the RTT difference against the faster path is larger than a defined threshold. Both [58] and [113] presents the decrease of download completion times, ranging from 20% to 40% depending on the paths combinations. MPTCP-MA [114] uses MAC-layer information to estimate the path status of WiFi specifically and to possibly suspend its use during intermittent connectivity caused by the short signal range and susceptibility to interference. Experimental results show that MPTCP-MA can efficiently utilize an intermittently available path, with WiFi throughput improvements of up to 72%.
Finally, besides the scheduling algorithms reviewed above and categorized across different ATSSS steering modes, there are other works providing a multipath programming model or framework [93] [115] [116] [117] [118] [119]. In these references, the existing multipath scheduling algorithms exist as plugins and are called by the application via the provided Application Programming Interface (API).

C. MULTIPATH CONGESTION CONTROL
In line with its main design goals discussed in Section III-C, the multipath congestion control is in charge of a) avoiding harmful interaction with concurrent single-path traffic, and b) shifting traffic away from congested paths, thus load balancing and improving throughput. Therefore, among the different steering modes, congestion control can be considered partially as the Load-balancing steering mode in ATSSS.
The development of multipath congestion control algorithms, formally described in [69], dates back to 2005, when [120] explores the coupled CWND adjustment, in which all subflows belonging to the same multipath connection are adjusted simultaneously whether to increase or reduce their CWND. Then, Equally-Weighted TCP (EWTCP) [121] is proposed, which applies TCP NewReno on each MPTCP subflow independently, i.e., fairness to regular TCP is not the goal and each subflow is independent. To improve the performance of non-congested subflows, Linked-Increases Algorithm (LIA) [69] is a coupled congestion control more responsive in the sense that only the CWND of subflows experiencing congestion are reduced. However, it has been reported in [122], [123] that LIA could behave unfriendly towards regular TCP in some scenarios. Hence, Opportunistic Linked-Increases Algorithm (OLIA), which is also a coupled congestion control, is proposed in [122] [123], and explores the concept of Pareto optimality, i.e., the equilibrium of a resource allocation problem, where one flow cannot gain more resources without damaging the resources of other flows. From the experiments, OLIA is observed to let the single-path user to improve 2 times higher throughput than LIA. Meanwhile, OLIA significantly reduces the congestion level at the bottleneck, reaching up to 6 times lower compared than LIA.
Along the same coupled congestion control design, [124] proposes Path Associativity Congestion Control (PACC), requiring that MPTCP subflows do not take a greater aggregate bandwidth than a single-path TCP flow on a shared bottleneck. Then, [125] studies a rate control to improve multipath transmission by simultaneously keeping fairness to regular TCP. The subflow rate of the proposed congestion control can be obtained from an optimization problem having TCP-friendliness as a required constraint. A parameterized formula to generalize the CWND update is given in [126]. In this approach, the optimization goal lies within a design space comprising fairness and responsiveness, where fairness can be sacrificed for higher responsiveness, resulting in higher throughput. Later, on the basis of [126], the work in [127] shows that OLIA can be unresponsive to network changes and proposes Balanced Linked Adaptation (BALIA). By generalising existing multipath congestion control algorithms, BALIA is able to dynamically balance the trade-off between friendliness to regular TCP and responsiveness thus complying to the coupled congestion control approach. The results show that, under the condition of guaranteeing the fairness, BALIA can still reach up to 4 times faster convergence time than OLIA.
Evaluated in server farms, [128] proposes One-ended multipath TCP (OmTCP), which modifies TCP's Selective Acknowledgment (SACK) option and fast retransmit mechanisms to adjust the sender rate to be fair to regular TCP. A TCP-friendly congestion control algorithm is proposed in [129] for the multipath Host Identity Protocol (mHIP). The work designs a two-level mechanism, which applies single-path additive-increase/multiplicative-decrease (AIMD) and a global congestion control that adjusts the aggressiveness of each connection against regular TCP in a shared bottleneck. Built upon the delay-based congestion control rather than the loss-based ones, [130] proposes weighted Vegas (wVegas), which uses packet queuing delay to infer congestion instead of packet loss and adjusts the subflow's CWND. Compared with LIA, wVegas is shown to be more sensitive to changes of network congestion and thus achieves more timely traffic shifting and quicker convergence. The experimental result also shows the improvement of fairness for wVegas, e.g., when wVegas is 12.3% off from the optimal fair allocation among two paths, LIA is 54.7% off from the optimal fair allocation.
Recently, [131] proposes a reinforcement learning scheme in multipath congestion control, i.e., SmartCC which takes an ACK as a reward and applies Q-learning to manage the CWND. SmartCC improves the median throughput of OLIA with 32%. However, this approach does not consider fairness to the regular TCP, i.e., it is an uncoupled congestion control approach. Considering fairness to the regular TCP, [132] employs the online convex optimization of the online learning to design the congestion control algorithm for MPTCP, named MPCC. Repeatedly, MPCC first selects the per-subflow rates and then receives the performance implication quantified by the utility function. The online convex optimization approach derives the per-subflow rates by aggregating the value of the utility function. Results show that MPCC provides an improvement (both in the mean and the median) of around 2.3 times in terms of file download speed over MPTCP with OLIA.

D. RELIABLE TRANSFER
To benefit either throughput or reliability and latency in multipath transport, adding encoded packets to the application data of the multipath transfer is proposed in combination with multipath schedulers. Such reliable transfer mechanisms exploit redundancy, which can be considered as the Redundant steering mode in ATSSS. However, while the redundant steering mode in ATSSS may already guarantee enough reliability for the application, e.g. by simply duplicating packets on more than one network access, the transport layer may or may not introduce reliability as part of its scheduling, i.e., potentially adding a second reliability level. As example of [133] mentions the drawback of MPTCP in ATSSS when carrying unreliable traffic, e.g., UDP, as it retransmits every lost packet leading to increased delay. Originally, the goal of redundancy in the transport layer was to avoid data retransmission over higher latency paths. In ATSSS, an additional redundancy level introduced by the transport layer could be explicitly used to map different packets, e.g., data or redundancy, onto different network accesses. This is however implementation specific. In the following, we enlist relevant literature in reliability applied to multipath transport without considering ATSSS.
Applying the coding upon base protocol of SCTP, [134] proposes eCMT-SCTP as the version of CMT-SCTP with erasure codes. Three different types of erasure codes are considered, i.e. block, convolutional and on-the-fly erasure codes integrated within CMT-SCTP. The evaluation targets generic web applications using fully reliable CMT-SCTP and video streaming using an equivalent of partially reliable CMT-SCTP. To further improve the performance, a modification of the SCTP retransmission mechanism is also proposed, with a variable retransmission delay (aRTX) based on the type of error correction code. [134] shows that eCMT-SCTP can achieve from 10% to 80% improvements in application goodput than CMT-SCTP under lossy multipath network conditions with a minimal (10%) overhead due to the encoding-decoding process.
Applying the coding upon base protocol of TCP, [135] proposes Network Coding-based MPTCP (NC-MPTCP), which introduces NC to some of the subflows. The core idea is the mixed use of regular and network-coded subflows, where regular subflows deliver application data and network-coded subflows deliver linear combinations of application data. NC-MPTCP outperforms MPTCP with up to 26% upon lossy paths and performs similarly to MPTCP when the paths are homogeneous and at low loss rates. Multipath Loss-Tolerant (MPLOT) [136] exploits multipath diversity with erasure codes. MPLOT presents throughput aggregation in both homogeneous and heterogeneous multipath scenarios, outperforming the default MPTCP without erasure codes with up to 21.5%. Systematic Coding MPTCP (SC-MPTCP) [137] proposes to mitigate packet reordering for a constrained receive buffer, by proactively transmitting redundant packets. The redundant packets are continuously updated according to the estimated aggregate retransmission ratio. Across experiments over paths with different heterogeneities and loss rates, SC-MPTCP can reach 3-8 times of average throughpt than MPTCP. Coded TCP (C-TCP) [138] is implemented in user-space and only considers the case with two WLAN paths with systematic block codes. Further, C-TCP applies a modified version of congestion control, compared with what standard TCP applies, in two aspects: firstly, it takes both loss and delay as feedback signals instead of loss solely; secondly, it introduces a token to allow the sender to transmit a packet instead of CWND. Fountain code-based MPTCP (FMTCP) [139] exploits the random nature of the fountain code to flexibly transmit encoded symbols from the same or different data blocks over different subflows, which aims to mitigate the negative impact of the path heterogeneity. FMTCP demonstrates gains of more than 50% in aggregation over MPTCP are obtained in experiments with a non-shared bottleneck scenario. [140] focuses on the experimental study of using NC over MPTCP in a car with cellular and WiFi links. A comparison between MPTCP and MPTCP/NC is presented using both the empirical data and mean-field approximation. The results show that network coding can provide users in mobile environments a higher quality of service, e.g., transmitting 100 times of packets per second than that of MPTCP when the lossy connection presents. QuAlity-Driven MultIpath TCP (ADMIT) [141] focuses on real-time high definition H.264 video using a MPTCP-model with FEC. It focuses on goodput, end-to-end delay and Peak Signal-to-Noise Ratio (PSNR) and presents the improved performance in these three aspects compared with not only MPTCP but also the aforementioned MPLOT and FMTCP. Stochastic Earliest Delivery Path First (S-EDPF) [142] integrates a novel low delay FEC scheme to increase the robustness of each channel and thereby minimize the retransmission delay. Moreover, it models each path by considering the stochastic factor to increase the reliability of each decision. [142] also reuses the framework of C-TCP [138] as introduced earlier. [75] implements an XOR-based FEC within TCP, to aid multipath transport with heterogeneity with MPTCP. In such case, the advantages of an XOR-based FEC approach are low computational overhead and simple implementation, where TCP's original segment structure can be maintained. However, the obvious disadvantage is that it can only recover one segment per block, e.g., if two or more packets are lost within a block the FEC packet is wasted.
Applying the coding upon base protocol of UDP or the combination of UDP and TCP, Bandwidth-Efficient Multipath Streaming (BEMA) [143] is built for H.264 video over multiple paths, considering quality metrics including video Peak Signal-to-Noise Ratio (PSNR), end-to-end delay, and goodput. Compared with FMTCP, BEMA improves PSNR by up to 23.3%, reduces end-to-end delay by up to 27.2%, and improves the goodput by up to 12.9%. BEMA uses UDP and TCP with TCP-Friendly Rate Control (TFRC) [144] and applies systematic Raptor codes and FEC adaptivity. Targeting towards QUIC, [145] [146] apply the use of FEC in MPQUIC. The experimental results indicate the performance increase compared with MPQUIC without FEC, especially in lossy networks. Similar to regular TCP, this can alleviate the burden of the congestion control layer of QUIC, especially in lossy networks where it is difficult to differentiate whether a loss is caused by link layer or congestion drop. [147] targets multipath streaming protocols and builds upon its own multipath UDP. The work develops an analytical model and uses asymptotic analysis to derive a closed-form, optimal load splitting solution, based on the joint solution using FEC and multipath. [148] proposes Multipath Multimedia Transport Protocol (MPMTP) and is constructed over both TCP and UDP flows. The TCP flow is used to exchange the control packets while the UDP flows are used to exchange the data. The work adapts the Raptor encoding parameters during the transfer, considering time-varying wireless networks and Raptor codes complexity. [149] targets the design of a strict time-critical transmission system using trace data from multipath UDP. FEC is used to optimize latency and reliability of the fixed-rate application traffic over channels with time-varying capacity. With the employed FEC mechanism, the reliability can be increased by up to 21.8% than the one without, depending on the code rate.
Finally  [155], however, they mainly focus on the integration of NC in the TCP level, not profiting from improvements from multipath transport.

E. MULTIPATH TRANSPORT AND 5G REQUIREMENTS
Based on the multipath transport literature surveyed through Sections IV-A, IV-B, IV-C, IV-D, and considering the mapping proposed with the ATSSS modes defined in Section II-E, we now summarize how the references fit into 5G requirements and, more specifically, how they could bring benefits to eMBB and/or URLLC services. The overview of the mapping between multipath literature, ATSSS modes, and 5G services are summarised in Table 2.
The use of multipath transport in 5G ATSSS is a clear enabler of eMBB and URLLC requirements addressing both high throughput and high reliability as well as low la-VOLUME xx, 2021  tency requirements. Generally speaking, multipath transport primarily supports bandwidth aggregation from different network paths, thus supporting eMBB slices to achieve higher throughput. In URLLC, slices benefit from multipath transport when scheduling policies based on shortest delay can take advantage of path redundancy, using the best lowest delay path currently available. The multipath transport solutions in Table 2 implemented as path management, scheduling, congestion control or reliable transfer algorithms can, in combination with the ATSSS modes in Section II-E bring benefits to eMBB and URLLC slices. In the following, while we focus on examples of multipath scheduling solutions applied to each of the ATSSS modes, we also highlight how other multipath solutions map to them. Intuitively, Smallest Delay or Best-Access modes target 5G URLLC requirements. The Best-Access mode generalizes the Smallest Delay mode, since it targets the use of the access offering the best performance for a defined metric, which is still latency in many cases. However, by exploiting RTT together with other path characteristics, e.g., CWND, send window, RTT variation, etc., Best-Access can lead to enhanced scheduling policies, which can be beneficial for both eMBB and URLLC slices. On the other hand, assuming a multipath scheduler that takes a single metric into account, the goal of Best-Access might not be efficiently achieved. For example, disregarding path characteristics such as loss rates in combination with RTT, may not sufficiently address the requirements of URLLC or eMBB.
The Active-Standby mode foresees use cases combining this mode with others, e.g., Smallest Delay. As such, Active-Standby endows the Smallest Delay mode the ability to completely or periodically suspend the underperforming path, thus potentially leading to improved performance as compared to Smallest Delay alone. With the combination of Active-Standby and Smallest Delay modes, the goal of serving packets over the lowest latency path remains, which is beneficial for both eMBB and URLLC.
The Priority steering mode often foresees priority related to financial considerations at the user side, e.g., cost per bit sent on each path. Hence, a common approach is to set users' priority as the constraint for the optimization problem. The optimization goal can be however throughput-specific, which applies to eMBB, but also related to both latency and throughput, e.g., in deadline-aware video streaming applications, which thus maps to URLLC.
The Load-balancing mode balances traffic on the available accesses by sending a corresponding amount of packets or flows. An accurate load-balancing can maximize throughput and, in turn, improve eMBB performance. This applies not only to multipath scheduler solutions but also to the congestion control, which is mainly associated with eMBB in Table 2. The rationale is that one of main objectives of congestion control is to maximize throughput while behaving friendly to other parallel connections (see Sections III-C and IV-C). We note however that current ATSSS specifications do not target a specific mode for congestion control.
Finally, the Redundant mode and reliable transfer mechanisms can be primarily adopted to meet high reliability requirements by URLLC services. How redundancy is utilized, plays a key role for meeting latency and/or throughput expected performance. In this context, raw packet duplication over all paths may guarantee low latency while also enhancing reliability. However, this approach will result in significant overhead impacting the throughput. The overhead can be reduced by controlling the level of redundancy, i.e., duplication, which in turn will negatively affect reliability. In this view, FEC and NC approaches can deliver a better balance between throughput, latency and reliability by avoiding retransmissions and heavy redundancy overhead while still providing a certain degree of reliability. While most of the works in this category target throughput, some specifically control the redundancy degree to optimize for latency and reliability, see [136], [138], [139], [148] . Moreover, the combination of Redundant mode with other ATSSS modes can expand the applicability of the corresponding multipath solutions, i.e., Load-balancing combined with Redundant multipath schemes can be leveraged in both eMBB and URLLC.

V. OPEN RESEARCH ISSUES
The stringent requirements of 5G with high throughput, low latency and high reliability pose great challenges to research. Although incorporating multipath transport protocols in 5G is one of the solutions that targets and meets some of these requirements, we find some open research issues that deserve some attention. We summarize the key issues as follows.

A. EMERGING 5G APPLICATIONS
5G enables several new use cases compared to previous generations of cellular networks. While many works in the existing literature propose multipath transport solutions for improving traditional applications such as video streaming VOLUME xx, 2021 and web download, emerging 5G use cases, such as AR/VR, remote haptic control, autonomous driving and industrial remote control, have very different characteristics and requirements. For example, when interfacing with a robotic system, the requirements over each packet or flow could be different, e.g., packets could have distinct priorities due to different tasks and associated update frequency. Similar challenges are expected for other use cases, e.g., AR/VR, where traffic flows having different requirements, e.g., in terms of latency and reliability, are expected to be simultaneously exchanged in both downlink and uplink directions. Such complex systems are also often composed of a mixture of event-and time-driven tasks, where packet priorities and payload lengths can be less predictable. Therefore, how to exploit network access resources to address the requirements of these new applications while meeting critical system requirements, is a complex new challenge that needs further investigation.

B. TRANSPORT PROTOCOL FEATURES AND 5G MULTI-CONNECTIVITY
QUIC comes with connection migration, decoupling the transport layer connection from the underlying IP address, thus, seamlessly supporting the transition of a QUIC connection from one access network to another. Related to ATSSS, this feature natively supports Steering and Switching, i.e., a QUIC connection can be seamlessly moved from one network access to another. MPTCP can, on the other hand, support both ATSSS Splitting and Switching, delivering a smoother transition between network accesses, as a consequence of utilizing multiple paths simultaneously. Compared to QUIC, MPTCP can natively support more than a single ATSSS mode and serve use cases when more than a single network access is available and could be leveraged by the application. If MPQUIC is not adopted by ATSSS as envisioned, a QUIC-based solution is limited to Switching and Steering.
In the scenario where ATSSS supports Splitting, it is expected that the UE throughput increases. The underlying network access characteristics from frequency bands, e.g. mid-or high-bands, to transport layer characteristics, e.g. RTT, CWND, and packet loss rates, will determine how much higher the throughput can be. Due to the interaction of the radio with the environment or due to interference, it is not always the case that the promised high data rates can be guaranteed [95], and the support of additional paths can be crucial in such scenarios.
Apart from the recently adopted RFCs for QUIC at the IETF, there are several ongoing works around its future that are related to multi-connectivity. They include the multipath extension as well as an unreliable datagram extension [158], i.e., allowing traffic that does not need to be retransmitted. They also include evolving QUIC to be a generic tunnelling protocol for any type of traffic, i.e., not limited to a specific transport layer nor a specific protocol. We expect these developments to impact the future in ATSSS, from adoption of MPQUIC and thus supporting more than the basic modes and moving beyond the basic Steering, Splitting and Switching defined in Release 16 to enabling more flexible use cases and deployments.

C. POTENTIAL ADVANCES IN ATSSS
In the context of ATSSS Release 16, the modes discussed throughout this work largely focus on transport layer solutions using MPTCP. While ATSSS for Rel-17 (Phase 2) [16] and beyond (Phase 3) [43] are still ongoing work and having focus on QUIC and MPQUIC applied to ATSSS, we believe that there will be many opportunities to improve the performance and flexibility of ATSSS, once the proposed solutions are more settled and adopted. For example, it can be beneficial to consider the adoption of different multipath transport protocols based on their built-in features and upcoming extensions, specially in QUIC, for different scenarios. As specified in Release 16, ATSSS proposes the use of MPTCP to handle TCP traffic with a MPTCP proxy in the UPF, thus, excluding UDP and traffic from other layers such as IPsec and services such as Virtual Private Network (VPN). The ATSSS-LL (Lower Layer) function below IP is meant in this phase for this sort of traffic. In Release 17, ATSSS is meant to provide a more general transport solution to tunnel Ethernet frames over IP packets using QUIC, thus, including support for both TCP and UDP traffic. Here, if MPQUIC is adopted, it could support Splitting along with Steering and Switching. Tunneling non-TCP traffic over QUIC is possible, but as QUIC connections are fully encrypted and therefore cannot be intercepted, e.g., terminated at the UPF, a solution such as the ATSSS Release 16 with MPTCP is not possible. The added benefits and flexibility offered by QUIC, such as support for multi-streaming and more efficient loss recovery, motivate the interest in QUIC for a complementary generic and more flexible solution for ATSSS [14]. In this context, the above mentioned ongoing work at the IETF to design an unreliable datagram extension to QUIC for real-time data will be important, considering the large spectrum of new 5G applications and emerging URLLC use cases.
The current ATSSS modes are also very coarse-grained. For example, in the current conceptual description of steering modes, the smallest delay mode is logically included in the best-access mode. Additionally, FEC and NC are not considered part of the steering modes, even though it is shown they can provide great benefits towards low latency and reliability. Considering more fine-granular modes and extending the current modes to also cover congestion control and reliable transfer aspects will be of great importance moving forward. Finally, since ATSSS may have many different available plugins in terms of the transport protocol, scheduling, congestion control, FEC and NC, it will be important to consider how to integrate with or further develop the existing multipath programming models and frameworks introduced in Section IV-B.

D. MULTIPATH IN THE 5G NR ERA
Most of the existing multipath research is based on current cellular and local area networks and they tackle heterogeneous paths by looking at the mean value of path delay, loss rate, etc., while few others tackle the dynamicity of heterogeneous paths. However, 5G NR, specially at higher frequency bands, will inevitably bring higher dynamicity to the paths due to millimeter Wave (mmWave), line-ofsight requirements induced by beamforming or the handover between macro and small cells in more dense deployments. Therefore, future work needs to focus on such dynamicity by efficiently utilizing the statistical distribution of the path delay, loss, etc. To achieve this, we need to first better understand the path characteristic of 5G NR. To this end, experimental open-source 5G platforms such as mmFlex [159], and open source components such as openairinterface [160] that build on software-defined radio [161] will be crucial.

E. DATA-DRIVEN APPROACHES
Most of the existing multipath research apply mathematical modeling and optimization to design rule-based multipath algorithms. The advantage of these solutions is that they are often of low computation complexity, and the behavior of the algorithm they rely on is easily explainable. However, considering the dynamicity of the paths, especially in 5G as discussed above, such an approach might lack the ability to adapt to different path conditions.
Another approach is to unleash the power of data-driven algorithms in the multipath protocol design. The first trend towards this direction is to utilize the available labeled data from the transport layer itself to do classification and prediction. The second trend is, given the fact that real-world data are not labeled, to apply unsupervised learning (e.g., clustering) or reinforcement learning to derive appropriate policies. The advantage of data-driven solutions is that they have the potential to learn over different path conditions and accordingly adapt to them. However, they may lack of explainability, which might be even more severe in URLLC, where reliability is difficult to mathematically prove or measure, i.e., you have 100% reliability until the first packet loss happens. Therefore, we argue that future research in this direction should bear the explainability point in mind. Moreover, data-driven solutions are normally of higher computation complexity compared to the rule-based counterpart, but this can be alleviated nowadays by using specialized hardware used for data-driven tasks.

F. MULTIPATH CONGESTION CONTROL FOR 5G
Several multipath congestion control algorithms were proposed with the notion of end-to-end network fairness, i.e., flows sharing a bottleneck end-to-end must receive the same resource amount, e.g., bandwidth, from the network perspective. This has historically influenced the design and performance of multipath transport protocols such as MPTCP [162]. We argue that this particular fairness notion can be revisited for ATSSS for one main reason: The use of multiple access technologies, such as the combination of 3GPP and non-3GPP. ATSSS scenarios include in general different technologies, which often belong to distinct underlying network infrastructures, e.g., the non-3GPP access does not share the same radio base station as the 3GPP access.
Therefore, the strict assumption about shared bottlenecks may become here less relevant compared to when the focus was on end-to-end Internet scenarios. The difference in communication patterns can be recalled from Figure 5 in Section II-D, where the core-centric integration path depicts the flows from both radio access technologies from the UE, i.e., cellular and WLAN, being aggregated into a single flow before leaving the cellular core network to the Internet. From the point where the flow leaves the cellular network, the notion of network fairness is still valid. In contrast, the above-the-core integration path depicts when both flows are transparent to the cellular core network, running end-to-end as a multipath flow.

VI. CONCLUSION
On the road to 5G, one of the design trends is moving towards aggregating multiple access networks. Multipath transport protocols, which exploit multiple network paths at the transport layer, play an essential role in such a design trend. We have presented what we believe to be the first survey of multipath transport protocols for 5G, subjecting to the standardized ATSSS architecture. With respect to this survey, we have reviewed the research efforts by academia and industry and the standardization efforts by 3GPP and IETF. Also, we have studied the characteristics of these works and, based on which, we have proposed their integration based on the ATSSS functionalities and steering modes, as well as suggesting their applicable 5G services. In addition to the foreseen benefits of incorporating multipath transport protocols into 5G, we also point out major existing research issues. We believe that our survey will serve as a guideline for future research works in applying multipath transport protocols for 5G and beyond.