Patent Description:
Transport layer protocols, such as the Transmission Control Protocol (TCP), have traditionally enabled a pair of peers to establish a connection and to exchange data via the connection using a single path between the peers. Certain transport layer protocols are being adapted to support use of multiple paths between peers. For example, Multipath TCP (MPTCP), which provides the ability to simultaneously use multiple paths between peers, enables data to be exchanged between the peers using multiple TCP flows that traverse multiple, potentially disjoint, paths.

United States patent application publication number <CIT> discloses that a multipath transport protocol such as multipath TCP can utilize metrics such as a wireless link condition corresponding to one or more paths as a parameter for controlling a dynamic allocation of data and control signaling over respective paths.

United States patent application publication number <CIT> relates to data transfer between communication nodes via multiple heterogeneous paths. In various embodiments, network coding may he used to improve data flow and reliability in a multiple path scenario. Transmission control protocol (TCP) may also be used within different paths to further enhance data transfer reliability. In some embodiments, multiple levels of network coding may be provided within a transmitter in a multiple path scenario, with one level being applied across ail paths and another being applied within individual path.

United States patent application publication number <CIT>) relates to a relay module comprising a capturing module for intercepting a first connection establishment request sent by a first host; a communication module configured for sending a second connection establishment request to establish an initial auxiliary connection between the relay module and a second host and for receiving, from said second host, a first acknowledgment response and a context discovery unit configured for activating: a forward mode to handle the traffic carried by the established main connection, in case the first connection establishment request and the first acknowledgment response present the same multipath property; a relay mode to handle the traffic carried by: an additional auxiliary connection established between the first host and the relay module; and the initial auxiliary connection established between the relay module and the second host, in case the first connection establishment request and the first acknowledgment response present different multipath properties.

The present disclosure generally discloses improvements in computer performance for supporting a multipath transport protocol in a communication network, including use of a multipath transport throughput capability in order to improve throughout of a multipath transport connection that is based on a multipath transport protocol. The multipath transport throughput capability is configured to improve the throughput of the multipath transport connection by improving the delivery of acknowledgment packets from the data receiving side to the data transmitting side to acknowledge successful receipt of data packets sent from the data transmitting side to the data receiving side. The multipath transport throughput capability may be configured to improve the delivery of acknowledgment packets from the data receiving side to the data transmitting side by, for a given data packet that is successfully received at the data receiving side from the data transmitting side, sending multiple acknowledgment packets from the data receiving side to the data transmitting side where the multiple acknowledgment packets associated with the received data packet may be sent over multiple transport connections of the multipath transport connection. The use of multiple acknowledgment packets, sent over multiple transport connections of the multipath transport connection, to acknowledge delivery of a data packet sent over the multipath transport connection may be based on use of channel identifiers associated with the multiple transport connections of the multipath transport connection (e.g., a combination of a <NUM>-tuple, sequence number, and channel identifier may be used to ensure that the correct data packet is being acknowledged, given that the acknowledgment packet that acknowledges the data packet may arrive at the data transmitting side via a channel that is different than the channel on which the data packet was transmitted). The use of multiple acknowledgment packets, sent over multiple transport connections of the multipath transport connection, to acknowledge delivery of a data packet sent over the multipath transport connection improves the probability that a successfully delivered data packet will be successfully acknowledged and the speed with which a successfully delivered data packet will be successfully acknowledged (even if the channel over which the data packet was delivered is experiencing problems) such that a next data packet of the multipath transport connection may be sent as soon as possible, thereby increasing the throughput of the multipath transport connection. It is noted that additional bandwidth that may be consumed in sending redundant acknowledgment packets is expected to be outpaced by the bandwidth savings due to reductions in retransmissions that result from increased reliability of acknowledgment delivery. It is noted that, although primarily presented herein with respect to embodiments in which improved throughput is enabled within the context of a particular type of multipath communication (namely, multipath communication that is based on the Multipath Transmission Control Protocol (MPTCP)), various embodiments presented herein may be adapted to support improved throughput within the context of various other types of multipath communication mechanisms (e.g., multipath communications based on other multipath protocols). It is noted that, although primarily presented herein with respect to embodiments in which improved throughput is supported within the context of a particular type of communication network (namely, a wireless network), various embodiments presented herein may be adapted to support improved throughput within the context of various other types of communication networks (e.g., a wireline network, a combination of wireless and wireline networks, or the like). It will be appreciated that these and various other embodiments and potential advantages of the multipath transport throughput capability may be further understood by way of reference to the example communication network of <FIG>.

<FIG> depicts an example communication network configured to use a multipath transport throughput capability to improve throughout of a multipath connection that is based on a multipath transport protocol.

The communication network <NUM> includes a pair of data communication devices (DCDs) <NUM>-S and <NUM>-C (collectively, DCDs <NUM>) and a set of communication networks (CNs) <NUM>-<NUM> - <NUM>-N (collectively, CNs <NUM>).

The DCDs <NUM> are configured to operate as endpoints of a multipath transport connection provided using a multipath transport protocol (which, within the context of <FIG>, is MPTCP). The DCDs <NUM> support a data application (DA) <NUM> where, illustratively, an instance of the DA <NUM> (DA <NUM>-S) is running on DCD <NUM>-S and an instance of the DA <NUM> (DA <NUM> -C) is running on DCD <NUM>-C. The DCDs <NUM> exchange data packets between the DA <NUM>-S running on DCD <NUM>-S and the DA <NUM>-C running on DCD <NUM>-C using the multipath transport connection. The data packets may transport various types of data which may be exchanged between the DCDs <NUM> (e.g., text, audio, video, multimedia, or the like, as well as combinations thereof). The DCDs <NUM> may include any suitable devices which may operate as endpoints of a multipath transport connection, such as end user devices (e.g., a desktop computer, a laptop computer, a tablet computer, a smartphone, a set-top box, a smart television, or the like), machine-type communication (MTC) devices (e.g., machine-to-machine (M2M) communication devices, Internet-of-Things (loT) devices, or the like), datacenter communication devices (e.g., physical switches, virtual switches, virtual machines (VMs), or the like), network devices (e.g., such as where multipath transport is supported within a network, between networks, within the network portion of an end-to-end path, or the like), or the like, as well as various combinations thereof.

The DCDs <NUM> are configured to exchange data packets between the DA <NUM> -S running on DCD <NUM>-S and the DA <NUM>-C running on DCD <NUM>-C using an MPTCP connection. The DCDs <NUM> include MPTCP elements <NUM> configured to support transmission of data between the DAs <NUM> using MPTCP (illustratively, DCD <NUM>-S includes an MPTCP element <NUM>-S supporting communications of DA <NUM>-S and DCD <NUM>-C includes an MPTCP element <NUM>-C supporting communications of DA <NUM>-C). The MPTCP elements <NUM> are configured to support the MPTCP connection, with the MPTCP connection being established between the MPTCP elements <NUM>. The MPTCP connection supported by MPTCP elements <NUM> is composed of a set of multiple TCP connections <NUM>-<NUM> - <NUM>-N (collectively, TCP connections <NUM>). The MPTCP elements <NUM> are configured to support communication via the MPTCP connection, for transporting data between the DA <NUM>-S running on the DCD <NUM>-S and the DA <NUM> -C running on the DCD <NUM>-C, using TCP connections <NUM> of the MPTCP connection. The MPTCP element <NUM>-S of the DCD <NUM>-S is configured to map data packets of the data flow of DA <NUM>-C into one or more TCP connections <NUM> for transport to DCD <NUM>-C and, similarly, the MPTCP element <NUM>-C of the DCD <NUM>-C is configured to receive data packets from DCD <NUM>-S via one or more TCP connections <NUM> and map the data packets into a data flow for DA <NUM>-C of DCD <NUM>-C. The TCP connections <NUM> of the MPTCP connection may be configured to support the functionality of traditional TCP mechanisms. The MPTCP elements <NUM> may be configured to operate in various operational modes (e.g., a steering mode, a smearing mode, or the like) which, as discussed further below, may dictate whether multipath transport of data is applied at the per-flow level or at a higher level (e.g., per application, per device, or the like, as well as various combinations thereof). The TCP connections <NUM> of the MPTCP connection may traverse multiple communication paths available from the multiple CNs <NUM>.

The CNs <NUM> may include communication networks configured to support communication between the DCDs <NUM> using the TCP connections <NUM> of the MPTCP connection. For example, the CNs <NUM> may include wireless networks (e.g., cellular wireless networks (e.g., Third Generation (<NUM>) wireless networks such as Universal Mobile for Telecommunications System (UMTS) networks, Fourth Generation (<NUM>) wireless networks such as Long Term Evolution (LTE) networks, Fifth Generation (<NUM>) wireless networks, or the like, as well as various combinations thereof), WiFi networks, millimeter wave (mmW) networks, or the like, as well as various combinations thereof), wireline communication networks (e.g., Ethernet-based networks, optical networks, or the like, as well as various combinations thereof), or the like, as well as various combinations thereof. For example, where DCD <NUM>-C and DCD <NUM>-S are a dual-mode smartphone and an application server, respectively, the CNs <NUM> may include a cellular wireless network and a WiFi access network available to the DCD <NUM>-C that provide two at least partially disjoint paths between DCD <NUM>-C and DCD <NUM>-S. For example, where DCD <NUM>-C is a customer premises router and DCD <NUM>-S is a network server, the CNs <NUM> may include multiple wireline networks such that there are two at least partially disjoint paths between DCD <NUM>-C and DCD <NUM>-S. For example, where DCD <NUM>-C is wireless access node (e.g., an LTE Evolved Node B (eNodeB)) and DCD <NUM>-S is a network element of a core wireless network (e.g., a Packet Data Network (PDN) gateway (PGW) of an LTE Evolved Packet Core (EPC) network), the CNs <NUM> may include portions of the wireless access network and portions of the wireless core network as well as a backhaul network therebetween where the backhaul network supports two at least partially disjoint paths between DCD <NUM>-C and DCD <NUM>-S. It is noted that MPTCP may be used within various other contexts and, thus, that the CNs <NUM> may include various other types, numbers, or arrangements of communication networks configured to support multipath communications between various combinations of devices. It will be appreciated that, although primarily presented with respect to use of multiple different CNs, <NUM> to support the TCP connections <NUM> of the MPTCP connection, the TCP connections <NUM> of the MPTCP connection may be supported using multiple different oaths (e.g., fully or partially disjoint paths) of a single communication network.

The MPTCP elements <NUM> are configured to support transmission of data packets via the MPTCP connection which, as noted above, includes multiple TCP connections <NUM> which may traverse multiple communication paths via multiple CNs <NUM>. The type and location of the device in which an MPTCP element <NUM> is disposed may dictate the manner in which the MPTCP element <NUM> directs data packets of the MPTCP connection. In the case of a multi-mode wireless end device (e.g., a smartphone, a tablet computer, or the like), for example, the TCP connections <NUM> of the MPTCP connection may traverse different wireless access networks which may be accessed by the MPTCP element <NUM> via different wireless interfaces of the multi-mode wireless end device (e.g., a first TCP connection <NUM> of the MPTCP connection running over a cellular interface of the multi-mode wireless end device and a second TCP connection <NUM> of the MPTCP connection running over a WiFi interface of the multi-mode wireless end device). In other words, MPTCP may be used to aggregate multiple air interfaces to deliver peak downlink throughputs by using various capacities of existing air interfaces in operator networks. In the case of a network device (e.g., a router, a switch, or the like), for example, the TCP connections <NUM> of the MPTCP connection may traverse different backhaul networks or core networks which may be accessed by the MPTCP element <NUM> via different communication interfaces of the network device (e.g., a first TCP connection <NUM> of the MPTCP connection running over an Ethernet network and a second TCP connection <NUM> of the MPTCP connection running over an optical network). It will be appreciated that the interfaces and networks with which MPTCP elements <NUM> may interact for sending data over various TCP connections <NUM> of the MPTCP connection may vary for different types of devices, networks, or the like.

The MPTCP elements <NUM> are configured to support transmission of data packets via the MPTCP connection. The MPTCP elements <NUM> may be configured to support MPTCP scheduling functions and MPTCP congestion control functions. The MPTCP scheduling functions supported by the MPTCP elements <NUM> may include scheduling functions typically supported for MPTCP connections (e.g., assigning data packets of the MPTCP connection to TCP connections <NUM>), retransmission of data packets of the MPTCP connection, or the like). The MPTCP congestion control functions supported by the MPTCP elements <NUM> may include any suitable congestion control mechanisms which may be used with the MPTCP connection (e.g., use of dynamic congestion control window sizes, use of the Linked-Increases Algorithm (LIA), use of the Opporturiistic Linked-Increases Algorithm (OLIA), use of the Balanced Link Adaptation Algorithm (BALIA), or the like). The MPTCP elements <NUM> may be configured to support various other functions supporting transport of data packets via the MPTCP connection.

The MPTCP elements <NUM> are configured to support transmission of data packets via the MPTCP connection as discussed further below.

The MPTCP element <NUM>-S of the DCD <NUM>-S is configured to support transport of data packets of the DA <NUM> from DCD <NUM>-S to DCD <NUM>-C via the MPTCP connection. The MPTCP element <NUM>-S controls transmission of the data packets of the MPTCP connection via the TCP connections <NUM> of the MPTCP connection. The MPTCP element <NUM>-S of the DCD <NUM>-S maintains a send packets queue <NUM>-S and an unacknowledged packets queue <NUM>-S. The MPTCP element <NUM>-S receives data packets from the DA <NUM> -S and stores the data packets in the send packets queue <NUM>-S while the data packets are awaiting transmission by the MPTCP element <NUM>-S via the MPTCP connection. The MPTCP element <NUM>-S, when sending a data packet via the MPTCP connection, selects one of the TCP connections <NUM> via which the data packet is to be transmitted, removes the data packet from the send packets queue <NUM>-S, transmits the data packet via the selected TCP connection <NUM>, and adds the data packet to the unacknowledged packets queue <NUM>-S. The unacknowledged packets queue <NUM>-S represents data packets of the MPTCP connection which have been transmitted from DCD <NUM>-S toward DCD <NUM>-C, but for which the DCD <NUM>-S has not yet received an acknowledgement from the DCD <NUM>-C indicating that the data packet was successfully received by the DCD <NUM>-C. The MPTCP element <NUM>-S, upon receiving from the MPTCP element <NUM>-C an acknowledgement indicating that a data packet transmitted by the MPTCP element <NUM>-S via one of the TCP connections <NUM> was successfully received by the MPTCP element <NUM>-C, removes that data packet from the unacknowledged packets queue <NUM>-C.

The MPTCP element <NUM>-C of the DCD <NUM>-C is configured to support transport of data packets of the DA <NUM> from DCD <NUM>-S to DCD <NUM>-C via the MPTCP connection. The MPTCP element <NUM>-C controls reception of the data packets of the MPTCP connection via the TCP connections <NUM> of the MPTCP connection. The MPTCP element <NUM>-C of the DCD <NUM>-C maintains a received packets queue <NUM>-C. The MPTCP element <NUM>-C receives data packets of the MPTCP connection via the TCP connections <NUM> of the MPTCP connection. The MPTCP element <NUM>-C stores the received data packets in the received packets queue <NUM>-C. The MPTCP element <NUM>-C stores the received data packets in the received packets queue <NUM>-C such that the data packets are in-order with respect to the MPTCP connection. The MPTCP element <NUM>-C supports in-order delivery of data packets of the received packets queue <NUM>-C to the DA <NUM>-C. The MPTCP element <NUM>-C continues to maintain out-of-order data packets in the received packets queue <NUM>-C until the out-of-order data packets become in-order data packets. For example, where four data packets are transmitted from MPTCP element <NUM> to MPTCP element <NUM>-C via the MPTCP connection, but the third data packet is not successful received by the MPTCP element <NUM>-C, the MPTCP element <NUM>-C may provide the first and second packets from the received packets queue <NUM>-C to the DA <NUM>-C and may hold the fourth packets in the received packets queue <NUM>-C pending receipt of the third packet (at which time MPTCP element <NUM>-C may provide the third and fourth packets from the received packets queue <NUM>-C to the DA <NUM>-C in order). The MPTCP element <NUM>-C, upon successfully receiving a data packet from the MPTCP element <NUM>-S, acknowledges successful receipt of the data packet to the MPTCP element <NUM>-S.

The MPTCP elements <NUM> of the DCDs <NUM>, as noted above, may be configured to operate in various modes of operation, including a steering mode, a smearing mode, or the like. In the steering mode of operation, the data packets of a given flow are sent over one of the TCP connections <NUM> of the MPTCP connection. In the steering mode of operation, the MPTCP connection may be used to support multipath communications at a layer above the flow level (e.g., different data flows may be communicated over different ones of the TCP connections <NUM> of the MPTCP connection such that multipath communications are supported at the application layer (e.g., multiple flows of a given application (e.g., DA <NUM>) are sent over multiple different TCP connections <NUM> of the MPTCP connection), at the device layer (e.g., multiple flows of multiple applications are sent over multiple different TCP connections <NUM> of the MPTCP connection), or the like, as well as various combinations thereof. In the smearing mode of operation, the data packets of a given flow are sent over multiple TCP connections <NUM> of the MPTCP connection (e.g., distributed across all of the TCP connections <NUM> of the MPTCP connection, distributed across a subset of the TCP connections <NUM> of the MPTCP connection, or the like).

The MPTCP elements <NUM> of the DCDs <NUM> are configured to support a multipath transport throughput capability in order to improve the throughput of the MPTCP connection. The multipath transport throughput capability is configured to improve the throughput of the MPTCP connection by improving the delivery of acknowledgment packets from MPTCP element <NUM>-C of DCD <NUM>-C to MPTCP element <NUM>-S of DCD <NUM>-S for data packets sent from MPTCP element <NUM>-S of DCD <NUM>-S to MPTCP element <NUM>-C of DCD <NUM>-C using the MPTCP connection. The MPTCP element <NUM>-S of DCD <NUM>-S selects a data packet for transmission via the MPTCP connection. The MPTCP element <NUM>-S of DCD <NUM>-S transmits the data packet via the MPTCP connection by transmitting the data packet over one of the TCP connections <NUM> of the MPTCP connection (for purposes of clarity, assume that the data packet is sent over the TCP connection <NUM>-<NUM> of the MPTCP connection). The MPTCP element <NUM>-C of DCD <NUM>-C receives the data packet over the TCP connection <NUM>-<NUM> and, rather than merely sending an associated acknowledgment packet to the MPTCP element <NUM>-S of DCD <NUM>-S via the TCP connection <NUM>-<NUM>, sends multiple acknowledgment packets to the MPTCP element <NUM>-S of DCD <NUM>-S via multiple TCP connections <NUM> of the MPTCP connection. The multiple TCP connections <NUM> of the MPTCP connection via which the acknowledgment packets are sent may include all of the TCP connections <NUM> of the MPTCP connection or a subset of the TCP connections <NUM> of the MPTCP connection. The multiple TCP connections <NUM> of the MPTCP connection via which the acknowledgment packets are sent may include the TCP connection <NUM> via which the data packet was received (namely, TCP connection <NUM>-<NUM>) and one or more other TCP connections <NUM> of the MPTCP connection. The MPTCP element <NUM>-C of DCD <NUM>-C may send the multiple acknowledgment packets by generating a single acknowledgement packet and replicating that acknowledgement packet to provide the multiple acknowledgement packets or by generating the multiple acknowledgement packets individually. The MPTCP element <NUM>-S of DCD <NUM>-S receives the multiple acknowledgement packets from MPTCP element <NUM>-C of DCD <NUM>-C via the multiple TCP connections <NUM> of the MPTCP connection (assuming that none are lost), accepts the first received acknowledgment packet as being an acknowledgment by the MPTCP element <NUM>-C of DCD <NUM>-C of successful receipt of the data packet, and discards any subsequently received acknowledgment packets. In this manner, the multipath transport throughput capability generally enables receipt of data packets to be acknowledged more quickly, since there may be situations in which acknowledgment packets may be delayed (e.g., due to congestion, poor channel conditions, or the like) or even lost in transit, and, thus, provides improvements in throughput of the TCP connections <NUM> and, therefore, also the MPTCP connection.

The MPTCP elements <NUM> of the DCDs <NUM> are configured to support the multipath transport throughput capability based on use of an identifier to enable unique mapping of the multiple acknowledgment packets received for a data packet to the data packet for which those multiple acknowledgment packets are sent. This identifier is primarily referred to herein as a channel identifier, which identifies the TCP connection <NUM> of the MPTCP connection on which the data packet was sent. The MPTCP elements <NUM> of the DCDs <NUM> may agree on the channel identifiers of the TCP connections <NUM> of the MPTCP connection in any suitable manner (e.g., negotiated in conjunction with establishment of the TCP connections <NUM> of the MPTCP connection, negotiated after establishment of the TCP connections <NUM> of the MPTCP connection, or the like). The MPTCP element <NUM>-C of DCD <NUM>-C, upon receiving a data packet from the MPTCP element <NUM>-S of DCD <NUM>-S (for purposes of clarity, again assume that the data packet is received over the TCP connection <NUM>-<NUM>), generates the multiple acknowledgment packets and sends the multiple acknowledgment packets to the MPTCP element <NUM>-S of DCD <NUM>-S (assume that acknowledgment packets are sent over all of the TCP connections <NUM>). The MPTCP element <NUM>-C of DCD <NUM>-C configures the acknowledgment packets by including information that may be used by the MPTCP element <NUM>-S of DCD <NUM>-S to determine the data packet being acknowledged. The MPTCP element <NUM>-S of DCD <NUM>-S, upon receiving one of the acknowledgment packets from the MPTCP element <NUM>-C of DCD <NUM>-C, determines the data packet that is being acknowledged based on the information included within the acknowledgment packet. The information of the acknowledgment packet that may be used (by MPTCP element <NUM>-C of DCD <NUM>-C) to indicate the data packet being acknowledged and that may be used (by MPTCP element <NUM>-S of DCD <NUM>-S) to identify the data packet being acknowledged may include a tuple that identifies the data flow with which the data packet is associated (e.g., a <NUM>-tuple including source and destination Internet Protocol (IP) addresses, source and destination port information, and protocol information), a sequence number identifying the portion of the data flow transported by the data packet (where the sequence number may be unique to a particular TCP connection <NUM>), and the channel identifier of the TCP connection <NUM>-<NUM> over which the data packet was sent. The channel identifier may be inserted into an unused header field of the acknowledgment packet or transported within the acknowledgment packet in other ways. It will be appreciated that the data packet being acknowledged may be indicated and identified in other ways (e.g., also or alternatively using other types of information which may be included within the acknowledgment packets).

The operation of the MPTCP elements <NUM> in supporting embodiments of the multipath transport throughput capability may be further understood by way of reference to <FIG> (which provides an example illustrating of use of embodiments of the multipath transport throughput capability in a steering mode of operation) and <FIG> (which provides an example illustrating of use of embodiments of the multipath transport throughput capability in a smearing mode of operation).

<FIG> depicts an example of use of multipath transport throughput capability to improve throughout of a multipath transport connection that is operating in a steering mode. The example <NUM> illustrates an MPTCP proxy <NUM> and a UE MPTCP client <NUM> supporting an MPTCP connection that includes three TCP connections <NUM> running over three communication paths associated with three different wireless access technologies (illustratively, a first TCP connection <NUM>-<NUM> running over an LTE interface/path, a second TCP connection <NUM>-<NUM> running over a WiFi interface/path, and a third TCP connection <NUM>-<NUM> running over a mmW interface/path). In the example <NUM>, three user flows are supported between the MPTCP proxy <NUM> and the UE MPTCP client <NUM> (denoted as user flow <NUM>, user flow <NUM>, and user flow <NUM>). In the steering mode of operation, the MPTCP layer of the MPTCP proxy <NUM> sends one user flow over one TCP connection and, thus, in this arrangement, over one air interface and one associated path. The MPTCP proxy <NUM>, for each user flow, chooses the TCP connection <NUM> on which to send the user flow (e.g., based on a set of criteria) and sends all of the data packets of the user flow over the selected TCP connection. As such, in this example <NUM> of <FIG>, there is a first user flow (user flow <NUM>) being delivered via the first TCP connection <NUM>-<NUM> associated with the LTE interface/path, a second user flow (user flow <NUM>) being delivered via the second TCP connection <NUM>-<NUM> associated with the WiFi interface/path, and a third user flow (user flow <NUM>) being delivered via the third TCP connection <NUM>-<NUM> associated with the mmW interface/path. As illustrated in the example <NUM> of <FIG>, for a given data packet of the first user flow that is successfully delivered from the MPTCP proxy <NUM> to the UE MPTCP client <NUM> over the first TCP connection <NUM>-<NUM> associated with the LTE interface/path, the UE MPTCP client <NUM> sends redundant acknowledgment packets over each of the three TCP connections <NUM> associated with the three wireless interfaces/path (even though different user flows are being delivered over the TCP connections <NUM>-<NUM> and <NUM>-<NUM> associated with the WiFi and mmW interfaces/paths, respectively). The MPTCP proxy <NUM>, based on receipt of one of the acknowledgments packets, irrespective of whether received over the first TCP connection <NUM>-<NUM> via which the data packet was sent or via one of the other TCP connections <NUM> of the MPTCP connection (namely, second TCP connection <NUM>-<NUM> or third TCP connection <NUM>-<NUM>), determines that the data packet was successfully received by the UE MPTCP client <NUM>. The MPTCP proxy <NUM> discards the other acknowledgment packets since successful delivery of the data packet has already been confirmed. It is noted that the acknowledgment packets for the second and third user flows also may be sent over each of the three TCP connections <NUM> via the three wireless interfaces/paths, respectively, although this is omitted from <FIG> for purposes of clarity.

<FIG> depicts an example of use of multipath transport throughput capability to improve throughout of a multipath transport connection that is operating in a smearing mode. The example <NUM> illustrates an MPTCP proxy <NUM> and a UE MPTCP client <NUM> supporting an MPTCP connection that includes three TCP connections <NUM> running over three communication paths associated with three different wireless access technologies (illustratively, a first TCP connection <NUM>-<NUM> running over an LTE interface/path, a second TCP connection <NUM>-<NUM> running over a WiFi interface/path, and a third TCP connection <NUM>-<NUM> running over a mmW interface/path). In the example <NUM>, a single user flow (denoted as user flow <NUM>) is supported between the MPTCP proxy <NUM> and the UE MPTCP client <NUM>. In the smearing mode of operation, the MPTCP layer of the MPTCP proxy <NUM> splits packets of the single user flow across the TCP connections <NUM> and, thus, in this arrangement, across the air interfaces/paths. The MPTCP proxy <NUM>, for each packet of the user flow, chooses the TCP connection <NUM> on which to send the packet (e.g., based on a set of criteria) and sends the data packets of the user flow over the TCP connections <NUM> selected for the data packets. As such, in this example <NUM> of <FIG>, a first set of packets of the user flow (illustratively, packets <NUM> - <NUM> of the user flow) are sent via the first TCP connection <NUM>-<NUM> associated with the LTE interface/path, a second set of packets of the user flow (illustratively, packets <NUM> - <NUM> of the user flow) are sent via the second TCP connection <NUM>-<NUM> associated with the WiFi interface/path, and a third set of packets of the user flow (illustratively, packets <NUM> - <NUM> of the user flow) are sent via the third TCP connection <NUM>-<NUM> associated with the mmW interface/path. As illustrated in the example <NUM> of <FIG>, for a given data packet of the user flow that is successfully delivered from the MPTCP proxy <NUM> to the UE MPTCP client <NUM> over the first TCP connection <NUM>-<NUM> associated with the LTE interface/path, the UE MPTCP client <NUM> sends redundant acknowledgment packets over each of the three TCP connections <NUM> associated with the three wireless interfaces/paths (even though other sets of packets of the user flow are being delivered over the TCP connections <NUM>-<NUM> and <NUM>-<NUM> associated with the WiFi and mmW interfaces/paths, respectively). The MPTCP proxy <NUM>, based on receipt of one of the acknowledgments packets, irrespective of whether received over the first TCP connection <NUM>-<NUM> via which the data packet was sent or via one of the other TCP connections <NUM> of the MPTCP connection (namely, second TCP connection <NUM>-<NUM> or third TCP connection <NUM>-<NUM>), determines that the data packet was successfully received by the UE MPTCP client <NUM>. The MPTCP proxy <NUM> discards the other acknowledgment packets since successful delivery of the data packet has already been confirmed. It is noted that the acknowledgment packets for the second and third sets of packets of the user flow also may be sent over each of the three TCP connections <NUM> via the wireless interfaces/paths, respectively, although this is omitted from <FIG> for purposes of clarity.

<FIG> depicts an embodiment of a method for use by a data transmitting device to handle acknowledgment of a data packet based on the multipath transport throughput capability. The data packet is communicated via a multipath transport connection including a set of transport connections. It will be appreciated that the functions of method <NUM>, although presented in <FIG> as being performed serially, may be performed contemporaneously or in a different order than as presented in <FIG>. At block <NUM>, method <NUM> begins. At block <NUM>, a data packet is sent toward a device via a first transport connection of the set of transport connections of the multipath transport connection. At block <NUM>, an acknowledgment packet, acknowledging receipt of the data packet by the device via the first transport connection, is received via a second transport connection of the set of transport connections. At block <NUM>, method <NUM> ends. It will be appreciated that method <NUM> of <FIG> may be adapted to perform various other functions presented herein as being supported by a data transmitting device to handle acknowledgment of a data packet based on the multipath transport throughput capability (e.g., monitoring multiple transport connections of the set of transport connections for an acknowledgment associated with the data packet, discarding subsequently received acknowledgment packets that are acknowledging receipt of the data packet by the device, or the like, as well as various combinations thereof).

<FIG> depicts an embodiment of a method for use by a data receiving device to handle acknowledgment of a data packet based on the multipath transport throughput capability. The data packet is communicated via a multipath transport connection including a set of transport connections. It will be appreciated that the functions of method <NUM>, although presented in <FIG> as being performed serially, may be performed contemporaneously or in a different order than as presented in <FIG>. At block <NUM>, method <NUM> begins. At block <NUM>, a data packet is received via a first transport connection of the set of transport connections. At block <NUM>, a first acknowledgment packet acknowledging receipt of the data packet via the first transport connection is sent via the first transport connection. At block <NUM>, a second acknowledgment packet acknowledging receipt of the data packet via the first transport connection is sent via a second transport connection of the set of transport connections. At block <NUM>, method <NUM> ends. It will be appreciated that method <NUM> of <FIG> may be adapted to perform various other functions presented herein as being supported by a data receiving device to handle acknowledgment of a data packet based on the multipath transport throughput capability (e.g., sending additional acknowledgment packets for the data packet via other transport connections of the set of transport connections or the like).

It will be appreciated that various embodiments of the multipath transport throughput capability may provide various advantages or potential advantages. For example, various embodiment of the multipath transport throughput capability may be particularly useful within the context of wireless networks in which wireless end devices have multiple wireless interfaces (e.g., multimode wireless end devices supporting cellular and WiFi interfaces) available for downlink and uplink communications. Various embodiment of the multipath transport throughput capability may significantly enhance TCP throughput by leveraging the multiple air interfaces to deliver uplink acknowledgments with higher reliability in less time and, thus, provide higher downlink throughput. The use of multiple air interfaces to deliver uplink acknowledgments enables improved delivery of uplink acknowledgments, especially where the wireless channel via which the associated data packet that is being acknowledged degrades between the time when the data packet is delivered in the downlink direction and the time when the acknowledgment packet is sent in the uplink direction. In this scenario, and other scenarios which might otherwise negatively impact delivery of acknowledgements, use of other wireless links to transport the acknowledgments toward the source will permit the source to continue to send data packets in the downlink direction, thereby maintaining high downlink throughput rates. It is noted that the use of multipath transport throughput capability within this context may be particularly useful given that TCP connections are often used to transport data for various bandwidth-intensive applications (e.g., File Transfer Protocol (FTP), Hypertext Transfer Protocol (HTTP) Adaptive Streaming (HAS) for video flows, or the like) over the downlink. It will be appreciated that various embodiments of the multipath transport throughput capability may provide various other advantages or potential advantages.

<FIG> depicts a high-level block diagram of a computer suitable for use in performing various functions described herein.

The computer <NUM> includes a processor <NUM> (e.g., a central processing unit (CPU), a processor having a set of processor cores, a processor core of a processor, or the like) and a memory <NUM> (e.g., a random access memory (RAM), a read only memory (ROM), or the like). The processor <NUM> and the memory <NUM> are communicatively connected.

The computer <NUM> also may include a cooperating element <NUM>. The cooperating element <NUM> may be a hardware device. The cooperating element <NUM> may be a process that can be loaded into the memory <NUM> and executed by the processor <NUM> to implement functions as discussed herein (in which case, for example, the cooperating element <NUM> (including associated data structures) can be stored on a non-transitory computer-readable storage medium, such as a storage device or other storage element (e.g., a magnetic drive, an optical drive, or the like)).

It will be appreciated that computer <NUM> of <FIG> may represent a general architecture and functionality suitable for implementing functional elements described herein, portions of functional elements described herein, or the like, as well as various combinations thereof. For example, computer <NUM> may provide a general architecture and functionality that is suitable for implementing one or more of a DCD <NUM> or a portion of an DCD <NUM>, an element of a CN <NUM>, or the like.

It will be appreciated that the functions depicted and described herein may be implemented in software (e.g., via implementation of software on one or more processors, for executing on a general purpose computer (e.g., via execution by one or more processors) so as to provide a special purpose computer, and the like) and/or may be implemented in hardware (e.g., using a general purpose computer, one or more application specific integrated circuits (ASIC), and/or any other hardware equivalents).

It will be appreciated that at least some of the functions discussed herein as software methods may be implemented within hardware, for example, as circuitry that cooperates with the processor to perform various functions. Portions of the functions/elements described herein may be implemented as a computer program product wherein computer instructions, when processed by a computer, adapt the operation of the computer such that the methods and/or techniques described herein are invoked or otherwise provided. Instructions for invoking the various methods may be stored in fixed or removable media (e.g., non-transitory computer-readable media), transmitted via a data stream in a broadcast or other signal bearing medium, and/or stored within a memory within a computing device operating according to the instructions.

Claim 1:
An apparatus (<NUM>-C) configured to support a multipath transport connection including a set of transport connections, the apparatus comprising:
a processor and a memory communicatively connected to the processor, the processor configured to:
receive (<NUM>) a data packet via a first transport connection of the set of transport connections, wherein the data packet is a user data packet belonging to a first user data flow;
and configured to:
send (<NUM>), via the first transport connection, a first acknowledgment packet acknowledging receipt of the data packet via the first transport connection; and characterized by being configured to
send (<NUM>), via a second transport connection of the set of transport connections, a second acknowledgment packet acknowledging receipt of the data packet via the first transport connection, wherein the first acknowledgment packet and the second acknowledgment packet each include an identifier associated with the first transport connection, and wherein the identifier associated with the first transport connection is included in an unused header field of the first acknowledgment packet and is included in an unused header field of the second acknowledgment packet.