On Ultra-Reliable Low Latency Multipath TCP For Connected Autonomous Vehicles

—Connected Autonomous Vehicles (CAVs) are Not-So- Futuristic. CAVs will be highly dynamic by intelligently exploiting multipath communication over several radio technologies, such as high-speed WiFi and 5G and beyond networks. Yet, the likelihood of data communication loss can be very high and/, or packets arrive at the destination not in correct working order due to erratic and mixed time-varying wireless links. Furthermore, the vehicular data trafﬁc is susceptible to loss and delay variation, which recommends the need to investigate new multipath TCP (MPTCP) protocols for ultra-reliable low latency communication (URLLC) over such heterogeneous networks while reassuring CAVs’ needs. We undertake the challenge by jointly considering network coding and balanced linked adaptation for perform- ing coupled congestion control across multiple wireless paths. Consequently, the proposed low delay MPTCP framework for connecting autonomous vehicles is efﬁcient and intelligent by design. We conduct a rigorous convergence analysis of the MPTCP design framework. In summation, we provide a detailed mathematical study and demonstrate that the latency penalty for the URLLC-MPTCP developed over these networks becomes negligible when considering the possible beneﬁts that multiple network convergence could offer. Our extensive emulation results demonstrate all these lucrative features of URLLC-MPTCP (see [1]).

. CAVs are communicating with a Cloud Server on the Internet via 5G and WiFi links. CAVs also form an adhoc network using WiFi like dedicated short-range communications (DSRC). Each of the wireless links uses its own code rate R i to combat lossy links. Links have their own packet loss characteristics (say on an average with loss probability e i ) and effective latency of d i seconds per packet. As a result, the perceived information rate via link i is R i /d i packets per seconds.
CAVs will appear very soon by simultaneously using 5G, high-speed WiFi and multiple other connections. A multipath transmission control protocol (MPTCP) has already been standardized as a tool for harnessing bandwidth by IETF [6]. It shed light on the possibility of i) aggregating multiple radio technologies (WiFi/5G) for enhancing CAVs' performance, ii) allowing improved and seamless handoffs, and iii) facilitating robust connectivity at all times [7], as illustrated in Fig. 1. For example, with MPTCP, one can theoretically simplify driver experience by improved network loss tolerance as well as better network performance. Clearly, MPTCP facilitates some major advantages for reliable and stable vehicular connections, but it [8] has a range of challenges to be resolved in order to realize its practicability over CAVs.
Although integration of existing wireless standards (WiFi/3G/4G network convergence) and 5G has the potential to dramatically improve efficiency for CAVs' data communications, frequent packet failures due to channel losses and mobility, highly changing topology of networks, frequent handovers, unstable connections, etc. have serious implications for meeting CAVs'-ultra reliable low latency communication (URLLC)-requirements in real time [9], [10]. A crucial issue of MPTCP concerns data transmissions and their responses (acknowledgments) for stable communication, in particular for connectivity along with multiple links, including such wireless routes, which often have separately differing link quality and sporadic delays.
When available, CAV could use multiple network interfaces and wireless links dynamically with MPTCP. Experimental research works have already shown that, for bulk transfers of files over links of similar quality, MPTCP allows remarkable gains over traditional TCP and that data transport during handoffs also occurs fairly smoothly [11]- [13]. Nevertheless, MPTCP has been inheriting the following major drawbacks from single-path TCP [4], [14], [15]: 1. Retransmission of lost packets: A missing packet must be identified and re-transmitted by the sender (which requires long delays, RTTs involved in loss discovery and selective repeat process). 2. Need for in-order delivery of packets: Reordering of packets at the receiver end severely affects the efficiency of MPTCP where links are of a significantly different nature (e.g., WiFi vs 5G) [13], [16], [17].
If the link carrying the data and/or ack packets fails due to a fading in the wireless channel, the transmission and load balancing mechanism of MPTCP data transport will be largely disrupted. Furthermore, if a packet transmission fails on one of the routes, another (good) link will get starved, resulting in CAVs output being compromised and deteriorating drivers' experience. But, emergency and safety-critical CAVs data traffic are susceptible to such high and oscillating latencies. Also, the likelihood that packets will experience failure or reach unordered at the destination via heterogeneous, time-varying and ergodic wireless links, is quite high. Therefore, all missing and unordered packets must be retransmitted or buffered at the receiver for resequencing before they can be sent in sequence to the CAV applications.
In contrast to our earlier works [4], [15], in this paper, we study and exploit to ameliorate the aforementioned two impending issues of MPTCP over CAVs as follows. Specifically, the ultra-reliable low latency communication URLLC requirements [18] for stable CAVs traffic in such heterogeneous (convergent) networks could be minimized significantly as follows: 1. reducing the resequencing latency with load-balanced link adaptation across multiple links; and 2. using streaming code that performs encoding to counter packet losses and reduces not only the retransmission but also resequencing latency of packets [4], [19], [20].
By jointly exploiting load balanced link adaptation and Stream Coding, it is plausible to optimally assign coded and information packets over the respective links timely [8], with guaranteeable delay. Load balanced link adaptation aims to optimize network resource use, maximize throughput, minimize response time, and avoid overload of any single link. 2 Overall, in this work, we design to mitigate the adverse impact of erratic wireless losses and unordered delivery to attain guaranteeable delay and high reliability. Retransmissions required for packets over erroneous links are substantially 2 Stream code is based on fountain or rateless codes [21, pp 589-594] and also due to the potential benefits that these codes deliver, for example, they do not exhibit a fixed code rate. It is known in information and coding theory [21] that the code rate is a proportion of the data stream that is non-redundant (useful). minimized and/or the latency incurred for ordering packets at the receiver end is completely solved.

A. Novelty and Contributions
Development of reliable and efficient MPTCP for CAVs: We design a new ultra-reliable low latency MPTCP for the CAVs, refer to as 'URLLC-MPTCP', that performs coding and transfers packets to dynamically changing multiple wireless network links in a way that manages the resource utilization and increases the performance (throughput). With this new approach MPTCP seldom goes for the undesirable retransmit, timeouts and recovery phases at the transport layer.
Two main contributions are to this end are: 1. We evaluate the URLLC-MPTCP protocol extensively for the validity of the presumptions made during its development. 2. We develop the convergence and consistency conditions of our URLLC-MPTCP protocol to investigate its impact over the network dynamics. Mathematical modelling of URLLC-MPTCP: We develop a rigorous mathematical analysis for the URLLC-MPTCP protocol to analyze the packet re-sequencing delay at the receiver due to path heterogeneity [4].

B. MPTCP over CAVs: Problems
To completely leverage the capacity of bulk MPTCP connections over CAVs, we have discovered the following key challenges to be tackled. It is important to understand in this regard that the 3G/5G and WiFi networks have completely different channel dynamics for data transmission. In a 3G/5G network, each MPTCP connection is assigned specifically to a different (dedicated) channel and has a wide geographical coverage. In contrast, the coverage is not only limited to WiFi networks, but also all (shared) connections must use the same wireless platform. Such sharing and small coverage in WiFi always contributes to repeated handoffs, over-access contention and packet collisions for the CAVs. On the other hand, the (cellular) route in 3G/5G networks requires typically large buffering memory; consequently, in long-oscillating latencies in combination with small loss rates, whereas the WiFi link corresponds to short-steady latencies but a relatively higher rate of packet loss [28].
There is a highly ergodic and time-variable probability of packet loss and delays while transporting data over such wireless links. It is influenced by several network variables, such as handoffs, resource buffering memory sizes, queuing policy, other connections and users competing in the links, wireless errors, retry limits, etc. Hence, as packets are sent through different WiFi and cellular routes, they may easily be lost or reach unordered at the destination. Therefore, the misplaced (lost) packets must be retry (resequencing) until the CAVs' applications receive them. This requires a large recipient buffering memory and corresponding high retransmissions at both link and TCP layers, thus undermining the performance of MPTCP.

II. DESIGN THEORY OF URLLC-MPTCP
Our MPTCP design idea consists of the following three main advancements in knowledge.
1. STREAMING CODE. We exploit streaming code to combat link errors and reordering delays; as a result, MPTCP senders with increased redundancy in packet transmission could quickly suck up erratic delays and losses over the wireless links [4], [20].
2. BALANCED LINK ADAPTATION. In contrast to seminal MPTCP design approaches, we adopt a balanced link adaptation in our approach, incorporating instantaneous throughputs, losses and delays experienced by the preceding packets on the links. URLLC-MPTCP is capable of changing its action in response to varying link situations and past experience. For an efficient and experience-driven MPTCP design, we need to predict the characteristics of the wireless links, but existing MPTCP congestion control protocols [6], [8], [25], [26] do not account for the instantaneous network variation and wireless impairments across multiple paths. As a result, earlier works [6], [8], [25], [26] are not capable of exploiting time-varying topology and link diversity of the CAVs networking.
With the aim of tackling delay variation in wireless networks, each MPTCP data packet from the sender records its originating timestamp, which is then used by the MPTCP sink upon reception of the packet to compute one-way delay. The computed value of the one-way delay is then feedbacked to the sender, piggybacked in the acknowledgment packet. This new idea develops a mechanism for the proposed URLLC-MPTCP to simultaneously exploit and respond to dynamic topology, channel impairments, and link diversity of the CAVs networking.
3. GUARANTEEABLE DELAY. With relevant insights from [29], we adopt the notion of guaranteeable delay (D 3σ ), which is the expected mean delay (E[D]) plus three standard deviations (3 × σ) of the mean. This is motivated by the celebrated three-sigma rule of thumb, which expresses a conventional heuristic that nearly all delay values are taken to lie within three standard deviations of the mean, and thus it is empirically useful to treat 99.7% probability (as near certainty) that This novel idea develops a mechanism for the proposed URLLC-MPTCP to exploit and respond to dynamic topology, channel impairments, and link diversity of the CAVs networking simultaneously with guaranteed permissible delay.

A. Proposed URLLC-MPTCP
Each URLLC-MPTCP sender takes latency D (in seconds) as a delay constraint from the application layer and has a set of links. Every single link manages a separate congestion window ω i and measures its (running averages) instantaneous one-way delay and round trip time, τ i seconds. Letd i be the running average delay in seconds per packet from the sender to the road user on link i. Then the window adaptation algorithm is designed as follows.

Algorithm 1 Proposed URLLC-MPTCP protocol
If (packet loss signal on link i)

3:
Update Transmit ω i /R i coded packets 5: Transmit ω i /R i coded packets 8: As shown in Algorithm 1, for every effective packet loss indication over link i, we perform multiplicative decrease and update the congestion window ω i as ω i ← ω i /2. Thereafter, to combat with channel errors opportunistically, we perform coding with rate R i and send ω i /R i coded data packets on the link i. In contrast to the multiplicative decrease for a packet loss, we perform continuous increase in the congestion window ω i for every successfully transmitted packets over link i as ω i ← ω i + min{1/ω i , α(ω i )}. Then, we perform coding to generate ω i /R i coded packets, with parameter where β i is the load balancer defined as Complexity of Algorithm 1: Consider a situation when α(ω i ) > 1/ω i , then the window update Eqn. (1) coincides with that of conventional single-path TCP. It is worth noting that the continuous increment phase is not strictly linear as in seminal TCP and MPTCP protocol; rather, it is adaptive and performs load balancing in flight by observing other sub-flows. Furthermore, whend i is the same along with all links, then (β i becomes 1), as a result, the window update Eqn. (1) coincides with MPTCP LIA enhanced with stream code (i.e. LIA plus coding). Our adaptive load balancing idea with an inclusion of a load balancer, β i , (see Eqn. (2)) during window evolution, tackles the transient bandwidth variation over CAVs network in real-time and guarantee low latency (min operator in Equation (2) guaranteed i < D 3σ ) for satisfying latency requirements of higher layer real-time applications. The complexity of finding the minimum in step 6 (Algorithm 1) is linear in the number of paths (see Appendix for details).

B. Streaming Code Policy
Motivated by the analyses in [4], [20], we consider a CAV link i has a likelihood of packet loss e i and delay d i (seconds per packet). With a code rate R i for the link, we have the following inequality that the code rate, R i , satisfies for all links Observe in Eqn. (3) that the code rate must satisfy (0 < R i < 1) and (1 − e i ) > R i , (as e i can be perceived a form of packet erasure probability [21]).

III. DELAY MODELING OF URLLC-MPTCP
We have the following two assumptions for pragmatic modelling. ASSUMP1: Coded packets are transmitted only over one link, say i, thus the streaming code rate R i always satisfies the following condition: Eqn. (4) is motivated by the analysis reported in [4], [20]. One condition which assumes a network scenario where URLLC-MPTCP user suffers from severe link fading impairments along with one of the links when all other links are in perfect condition, where it might be easier to transfer coded packets only over a single link (thus effectively utilizing all links) i, which contributes to the Eqn. (4), providing us all with a unique coding probability formula. When the packets are sent over two separate internet connections with d i and d j (d i > d j ) delays. Packets sent over the line j should wait for a further latency of (d i −d j ) seconds.
ASSUMP2: Packets sent through the high-speed links are still waiting for the packets arriving from the slower links to be sent to the client application (in a higher layer) in time, for sequential delivery of packets to the application in order.
ASSUMP2 impacts the study as there is a (very small) probability that packets sent from the high-speed connections will be distributed in order, and that there is no waiting for the packets from the slow connection.
We make use of the following recursive reward theoretical approach. Using the results of renewal-reward approach, the delay for in-order delivery of packets by the URLLC-MPTCP can be computed by estimating the expected number of packets sent over the coded link. 4 Using the T n lifetime renewal period and the mutually exclusive U n bonuses, n ≥ 1 (U n will rely on T n ). When we pair a rewarding utility with a renewal time period, in this replacement incentive system, U (t) is the cumulative incentive utility up to t, the rate of reward amount is then given by 5 Let time sequences T 1 , T 2 , . . . , where T m = 0, 1, 2, . . . timeslots, be the iid (inter)arrival time points between succeeding decoding events with first moment E[T ] and second moment E[T 2 ] respectively. The arrival can be viewed as a random variables process (arrival epochs For tractability of our analysis, we have the following simplifying approximation: APPROX1: The distribution is Poisson for z n,i = 0, 1, 2, . . . where the fraction x i /x c denotes the approximate rate of information packets per link per coded packet. The volume of lost packets in a time slot is given by Eqn. (6) following an iid process. The timings between decoding events and satisfy Eqn. (4) (recall ASSUMP1) for all e i and d i of all active links: Therefore, along the lines of [4] for one or two links, i.e., The E[T ] < ∞ and E[T 2 ] < ∞, the packet loss rate over all available links should satisfy λ < 1. It not only mandates Eqn. (4) but also holds true for all other active links

A. Estimating Mean Delay
Using Eqn. (5), the delay can be predicted as To approximate the E[U 2] < ∞ and simplify our analysis, we adopt the following approach. We find a part of the cycle where T 2 = max(2, T n ), i.e., T 2 ∈ 2, 3, . . . , is the slot between new process arrivals. The compensation feature for evaluating the latency faced by information packets transmitted on the link u is very close to the approximated process's residual existence. Therefore, where I u (i) indicating coded or uncoded link. Fig. 2. Two-state wireless channel modelling.

B. Modelling Guaranteeable Delay
With relevant insights from [8], [29], we consider twochannel states: good state (G) and bad state (B). We develop expressions for the probability distributions of the channel state as follows. Considering discrete time-slots, where the duration of each time slot is the transmission time for an MPTCP packet from the base station. The channel state switches from a good state (all transmissions are successful) to a bad state (all transmissions are unsuccessful) and vice-versa.
Let c denote the maximum rate in packets/sec at which the base station can transmit, i.e., the bit rate ratio to the packet size in bits. With v as the velocity of the CAV, and f c is the used carrier frequency, the Doppler frequency is With F as the fading margin of the channel, if the received signal < E[SINR]/F , the channel is in the bad (B) state; else, it is in the good (G) state; here, E[SINR] is the expected value of the received signal to interference noise ratio SINR. The transmission error probability due to a wireless channel error is f i = 1 − e −1/F , cf. [8]. Using [8] where (i) is the Gaussian correlation coefficient of a fading channel with frequency (Doppler) f d , sampled t seconds away, and (ii) J 0 (.) is the Bessel function of the first kind. The stationary channel state transition probabilities as shown in Fig.  2 can be computed as (see Q(., .) the Marcum-Q-function [8], [30]) Let n denote the probability that at least one out of n link layer transmission frames is unsuccessful, given that the initial state is G. Here, R is the maximum number of retransmissions allowed, and L is the number of link layer frames in an MPTCP packet (TCP Acks fits into one link layer frame). Denoting m (r) n as the probability that at least one out of n transmission frames is unsuccessful, given that the first link layer frame has already had r (with r < R) unsuccessful transmission attempts and the initial state is B. With the boundary conditions , the recurrence relationships for these probabilities are where the values of n , 1 ≤ n ≤ L and m (r) n , 0 ≤ r ≤ R are obtained. Therefore, the probability of an MPTCP packet is loss over link i is given by Using u n as the mean number of link-layer frames required to be transmitted for an MPTCP data packet consisting of n link frames, given that the initial channel state is G. If s (r) n is the mean number of link-layer frames required to be transmitted for an MPTCP data packet consisting of n link frames, the first link-layer frame has already had r (with r < R) unsuccessful transmission attempts and the initial state is B; by using boundary conditions u 1 = 1 and s (R) 1 = 1, the mathematical interpretation of the recurrence relations [8] s (r) Finally, the expected delay for the transmission of an MPTCP data packet consisting of L link frames is Observe from the above analysis that given the distribution of transmission time, the throughput of the memoryless channel can be computed along the lines of that [29]. Given the distribution of the delay, the average delay can be found by evaluating the first derivative as shown earlier (see [29] for details). Remark III.1. In reality, the feedback over time-varying wireless channels is lossy and delayed, burst errors occur, and the round trip transmission time fluctuations can cause a high variability in the delay. To capture and quantify these effects, we explore and exploit the three-sigma rule, which has been known to be justifiable when the distribution of the delay can be approximated as sub-Gaussian. Given constants a 1 > 0, a 2 > 0, P r(D > d) < a 1 e −a2d 2 ∀d > 0, the distribution of D as a random variable is sub Gaussian. Such sub-Gaussian distribution has strong tail decay (at least as fast as the tails of a Gaussian). Therefore, the guaranteeable delay D 3σ of URLLC-MPTCP is upper bounded by the guaranteeable delay of a Gaussian process with the same mean and deviations of D. It has been demonstrated [29] that the tails of the Gaussian dominate the tails of the delay distribution.
Considering that the delay distribution φ D (z) is sub-Gaussian, the guaranteeable delay of the URLLC-MPTCP, given the expected delay E[D], can be computed as where σ 2 is the variance of the delay given by (see [29] for details)

IV. RESULTS AND DISCUSSIONS
We performed comprehensive experiments to evaluate URLLC-MPTCP under several different network scenarios. Using network settings in our testbed, we have CAVs usecase scenario and settings, and then explain our observations based on findings and results. We evaluated URLLC-MPTCP by benchmarking it with established MPTCP protocols: BALIA [26], OLIA [25] and LIA [6], the celebrated multipath congestion control protocols. With relevant insights from [4], we have enhanced Paasch et al. Linux implementation 6 . The network setup consists of five laptops, one of them is a server, and four others are the user devices using Linux 16.04. All user machines are interconnected using a gigabit switch to the server using two gigabit Ethernet interfaces and links for our experiments.
The MPTCP connection from users to the server includes two different subflows in our experiments. We have used NetEm for bandwidth control, channel loss and latency for wireless links emulations. 7 The experimental traces are evaluated by using tcpdump 8 and quantified with wireshark. 9 For generating the data traffic, we are using different size files from the server ranging from 2 Mega-Byte to 20 Mega-Byte; the data points in the plots are computed by extracting tcpdumps.

A. Delay Analysis and Accuracy
The predicted E[D] resequencing period obtained in Eqn. (8) offers a valuable estimate that can be used to evaluate the coding efficiency across several parallel wireless links. The assumption created in our study for coding and arrivals have been explained to be accurate with the tests. For a URLLC-MPTCP connection using two links, a comparison of the reordering delay obtained from the model with experimental results for the coding scheme is given in Figures 3-4. Figure 3 reveals that the previously established estimate is a reasonably accurate measure of the true delay incur due to resequencing over a variety of code levels and packet losses (see [4] for other details). Comparing the latency for communication with several concurrent links, the penalty for utilising multiple links is simply not very important. Nevertheless, we can observe that the future advantages of communication diversification through URLLC-MPTCP connections may be significant and invaluable. In Figure 3 the delay ratio for each connection is d1/d2= 50/20, while in Figure 4 that ratio is d1/d2= 30/50 Figure 4 also contains details about the variability of the delay due to the resequencing of packets and its variance.
For examples, the overall communication capacity using two links is approximately double that of communication using a single link only. Furthermore, each extra link increases the connection's reliability. It will help ensure low latency when CAVs networking is extremely intermittent or unstable network connections. As discussed in [4], Figure 4 suggests that the delay is always primarily caused by the relation with the greater likelihood of packet loss magnitude. In fact, the delay isn't very prone to change in bandwidths (compare Figure 3 to Figure 4). Similar insights regarding reordering delay have already been reported in [4]. With relevant insights from [29], we analyze our experimental results and observe in Figure 5 that both the mean and guaranteeable delay of the coded and uncoded (set R i = 1) URLLC-MPTCP increases with an increase in the loss rate e i . Although the Coded MPTCP has a higher average delay than the uncoded MPTCP, the guaranteeable delay for Coded MPTCP is lower than the one for uncoded MPTCP. Furthermore, we observe that by increasing the timeout period, the separation between the guaranteeable delays can be reduced further.

B. Real WiFi Testbed Experiment
In actual WiFi networks, we performed an experiment with setting identical to previous studies but using two network interfaces (WiFi), where the measured two connection bandwidths were 54 Mega-bits per second and 10 Mega-bits per second. We have five MPTCP flows, and we calculate the expected output of each link. We perform the same experiment in the same way with all other multiple MPTCP protocols (different executions with Ours, BALIA, LIA, OLIA). Figure 6 shows the results and contrasts various MPTCP links perceived performance. Under this situation (see caption of Figure 6), both the likelihood of packet failure and the latency are small (as opposed to previous test cases), the differences between our URLLC-MPTCP protocol and established MPTCP protocols are relatively limited (but noticeable).

C. Extensive Evaluation of URLLC-MPTCP and Findings
First, we set a capacity of 15 Mega bits per sec and delay 160 milli-seconds with a random loss of 2%, same for all links. Then we observe the throughputs and fairness using various sizes ranging from 4M ega − Byte ≤ size ≤ 8M ega − Byte using sever other MPTCP protocols for benchmarking our URLLC-MPTCP under the exact same network environment. Figures 7-8 illustrate the comparison results on throughputs and fairness. We observed that our URLLC-MPTCP protocol not only outperforms all existing MPTCP protocols in terms of throughputs but also achieve comparable fairness. We can see in Figure 7 when the size of the file is 4 Mega-Byte, proposed URLLC-MPTCP significantly outperforms BALIA, LIA, OLIA. Furthermore, observe that the decrease in throughputs with increasing file size is very small (due to stream coding) for 2% of packet transmission failures due to wireless errors. We have shown in Figure 8, that Jain's fairness indices of all MPTCPs, including URLLC-MPTCP, are quite close to unity (1) but the throughput with URLLC-MPTCP is significantly improved (without any loss on fairness). The explanation for this is the close coupling in implementing the proposed MPTCP to minimize irregular channel errors jointly (using stream coding) and reorder delay (using a load balancer, recall Eqn. (1)) For the next experiment, we use delay (160 milli-seconds) with (4%) likelihood of packet loss, same for all links and vary bandwidths of only one of the links (fixed another link bandwidth to 20 Mega bits per sec). We discovered the impact on expected throughputs using the same file of 10 Mega-Byte with several runs of other MPTCP protocols. This compares the proposed URLLC-MPTCP with others under the same network environment. Figure 9 illustrates the impact on throughputs.
The newly designed URLLC-MPTCP outperforms all other existing MPTCP protocols in terms of responsiveness and efficient utilization of asymmetric wireless links. The throughputs shown in Figure 9 perceived by seminal MPTCP protocols are relatively low and remains the same even with increasing bandwidths. Our new protocol shows improvements in resource pooling for the same time-varying network settings-the reason being that under erratic channel errors, traditional MPTCP protocols suffer a lot. However, due to inbuilt forward error correction with streaming code, URLLC-MPTCP combats pretty well even with significantly high packet loss due to wireless errors. The balanced link adaptation feature of URLLC-MPTCP protocol discovers asymmetric links shortly and performs balanced scheduling of packets across the links intelligently.
In another network scenario, we conduct an experiment and vary the delay of one of the links from 30 milli-seconds to 60 milli-seconds (with a setting for other link delays to 20 milli-seconds) and set the same capacities and random (4%) likelihood of packet loss for both links so as to observe the impact on expected throughputs while downloading the same size (15 Mega-Byte ) file using several MPTCP protocols (namely, BALIA, URLLC-MPTCP, LIA, OLIA) using the exact same network environment. Figure 10 shows how throughput varies. The performance throughput obtained across all protocols (including Ours) decreases as predicted with increasing delay. But, for URLLC-MPTCP and others, the rate of decrease in the throughput is different. In other MPTCP protocols, the slope is very high, and for the current URLLC-MPTCP, it is fairly low. The explanation for this is the time spent discovering the delay spend by the other MPTCP protocols for the retransmission of missing packets and the resequencing of received packets at the user end (all transmitted packets must be received in order by MPTCP sinks). Our two new ideas which make URLLC-MPTCP adaptive and highly effective in severe the lossy environment is the decoupling of dependence (ordered delivery) by using streaming coded packets: When any of ωi (out of ωi + δi packets transmitted from sender) packets are received, why the need to wait for the missing packets in flight.
Next, we set the equal delay of 160 milli-seconds and capacity of 18 Mega bits per sec for both links but the time-varying likelihood of loss for one of the links (fixing other channel loss to 3%). We plot the impact on the expected throughputs while downloading the 10 Mega-Byte file while using all MPTCP protocols (several runs with BALIA, URLLC-MPTCP, LIA, OLIA) in the same network setting. Notice the effect on throughputs in the figure 11 -the URLLC-MPTCP is resilient and performs resource pooling even under unfavourable channel conditions as shown in Figure  11.
With increasing channel error likelihood in Figure 11 the expected throughputs from the established MPTCP protocols (BALIA, LIA, OLIA) is decreasing in nature. URLLC-MPTCP provides reliable performance, even in this state, with increasing channel errors and the rate of decrease is slower. This is because all established protocols obey a predetermined fixed congestion control policy. In particular, the existing solutions are quite conservative and substantially reduce their congestion windows only after identifying packet losses. This phenomenon incurs long delays (round trip time where many hundreds of packets in flight often suffer).
Nevertheless, our URLLC-MPTCP has the potential to absorb certain degrees of variance or channel fluctuations (using stream coding) and takes a few rapid attempts to learn the best way to adjust the congestion windows (using the load balancer).
One more possibility is known where a channel is dropped unexpectedly and became unavailable (for example, WiFi communication (small coverage area) often fails after 50 seconds when 5G is still on sale in freeways). The findings are illustrated in Figure 12, where the understanding of the output of irregular subflows from various MPTCP flows is contrasted with URLLC-MPTCP.
In response to the variation in the number of subflows, our URLLC-MPTCP functions relatively better, overflowing with the current MPTCP protocols, BALIA, LIA, OLIA. Nonetheless, unlike all other MPTCP protocols, our URLLC-MPTCP protocol discovers a drastic decrease in the performance of any subflow over time, owing to the shift in the practical resource utilization scenario. The underlying mechanism induces the lack of flows very easily to initiate our congestion management mechanism (notice that Eqn. (1)'s equilibrium factor with di = 0 is zero, so MPTCP sender can easily locate the missing flow) and removes the subflow window. This process enables our protocol to be more sensitive than existing MPTCP protocols to changes in network links.
V. URLLC-MPTCP: CONVERGENCE AND STABILITY The scientific theory of fluid movement has been praised for designing and analysing the protocols TCP and MPTCP [26]. This method combines short-term ergodic variations in value quantities such as delays and congestion times and also supports conventional differential equations to describe the complexities of packet transmission.
With applicable observations from the Peng et al. [26] multipath formulations, k i (x) is a vector of benefits (say) evaluating the functional properties of URLLC-MPTCP and φi(x) evaluating its equilibrium conditions. The required fluid model for the proposed URLLC-MPTCP for a given packet sending rate x i = ωi/Ri τi can be expressed as (see Section II.B and Eqn. (1)) [4] x for investigating the uniqueness, convergence and existence of the developed MPTCP protocol. The packet sending rates x = (x 1 (t), . . . x n (t)), link loss e = (e 1 (t), . . . e n (t)), subscripts, 1, . . . n, represent the number of links respectively, and z + y = z, y > 0 max(z, 0), y = 0.
Then the two links network dynamics under the URLLC-MPTCP protocol and Eqn. (1) can be modeled by Eqn. (13) where i ∈ {1, . . . , n} Next, it is essential to study the stability of the data flow dynamic system under our URLLC-MPTCP protocol k and φ and their dynamic properties (recall Eqn. (1)). We use the following four conditions for the tractability [4], [8], [26].
•  13) has a maximum of one equilibrium. In essence, for the three conditions: COND.2, COND.3 and COND.4 to hold, Eqn. (13) has only one unique equilibrium (x , e ). Further details on the convergence analysis is provided in the appendix.

VI. CONCLUSION
We have extended the multipath TCP protocol for URLLC and evaluated the new URLLC-MPTCP for low latency applications such as connected autonomous vehicles. The newly developed MPTCP algorithm has adopted the stream coding policy, which allows efficient use of wireless connection through several heterogeneous parallel networks, thus meeting the guaranteeable latency constraints of the vehicles. Our experimental results show that this novel URLLC-MPTCP learns evolving network constraints and adapts to the time-varying system dynamics. We developed an approximation for guaranteeable delay and resequencing delay of URLLC-MPTCP protocol at the receiver end and demonstrate that URLLC-MPTCP effectively supports latency-sensitive applications. In conclusion, the development towards URLLC-MPTCP has been able to harness bandwidth from heterogeneous networks and facilitates seamless experience over CAVs network, which requires further enhancements.

A. Complexity of URLLC-MPTCP
Our analysis in this section involves identifying the order in which paths become bottlenecked. Let and the fractions, when kept in order, are √ ω 1 It is worth observing that with this ordering in (18), the equilibrium window increase of (1) (in Step 6 Algorithm 1) can be computed as [17]  i.e., it can be computed with a linear search.

B. Convergence of URLLC-MPTCP
The following derivation and mathematical analysis characterize the stability and convergence of network data flow dynamics under our URLLC-MPTCP (see Eqn. (1)). The conditional existence and uniqueness of (x , e ) is provided in the following, where conditions COND.2, COND.3 and COND.4 are given. With relevant insights from [4], [26], we construct the following lemma.
Using ∂x := x − x and ∂e := e − e we construct the Lyapunov function V(x, e) = i∈{1,...,n} The proof of Lemma VI.1 follows along the lines of that of [8, Thm. 5.4.2 p.
Using Lasalle's invariance, (x , e ) is a stable global equilibrium. The reason being that the only path in vector P := (x(t), e(t)) is the path (x, e) ≡ (x , e ); because this is only the path vector P on whichV(x(t), e(t)) = 0 for all t ≥ 0.