## 5 Multi-Connectivity over IEEE 802.11 ay Links  
Based on our requirement analysis in Section 3.2 and MAB solution in Section 4, we design a Low Delay Multipath Scheduling Protocol (_LD-MPSP_) in this section. LD-MPSP algorithm design is driven by an intelligent controller, which depends on the difference between the target delay \(\tau\) and the estimated one-way delay, \(q(t)\). As noted earlier, thevalues of \(\tau\) and \(q(t)\) for a link are obtained from the federated MAB modules. The goal is to search for an appropriate integer, either \(\lceil w_{t}\rceil\) or \(\lfloor w_{t}\rfloor\) and maintain a small non-zero target queuing delay parameter, \(\tau\), equal for all links (\(\tau\) can be evaluated at the multi-path scheduling source by using the distributed learning agent discussed in Section 3.2). Each multipath scheduling from a source has a set of links, and each link \(\iota\) maintains a congestion window \(w_{t}\) and measures its delay, \(q_{t}\) (the overall delay perceived by \(w_{t}\) packets). Motivated by the findings in [32], observe in Algorithm 3 that we proposed congestion window adaptation as follows (Cf. MPTCP LIA, OLIA, BALIA versions in [7]):  
* For each Ack on link \(\iota\), \(w_{t}\gets w_{t}+\alpha/w_{t}\), and
* For each packet loss on link \(\iota\), \(w_{t}\gets w_{t}/2\)  
where \(\alpha=(\tau-q_{t})/\tau\).  
```
1:procedureInitialize
2:Target Delay (\(\tau\)), One-way Delay (\(q\)), Window (\(\mathbf{w}\))
3:endprocedure
4:procedureCONGESTOAVOIDANCE
5:while (window Adapt)do
6:if (ACK on link \(\iota\)) then update \(q_{t}\)
7:\(w_{t}\gets w_{t}+(\tau-q_{t})/\tau w_{t}\)
8:else\(w_{t}\gets w_{t}/2\)
9:endif
10:endwhile
11:endprocedure
12:procedureQuantization
13:\(\mathbf{w}\leftarrow\) integer vector (\(\mathbf{w}\)) s.t. min \(T\)
14:Evaluate \(\tau\)
15:endprocedure
```  
**Algorithm 3** LD-MPSP Algorithm  
Observe from the window adaptation process in Algorithm 3 that, once the target delay is attained, LD-MPSP persists in the state unless packet loss or other traffic perturbs the \(q(t)\). Furthermore, steps (10, 11) of Algorithm 3 mandate that LD-MPSP absorbs the uncertain delay variation by updating \(\tau\) at the multipath scheduling sources dynamically (thus solving the above-derived equations approximately). Our _LD-MPSP_ algorithm shares some design aspects with other _lower-than-best-effort_ data transfer service algorithms, such as competitive and considerate congestion avoidance (4 CP) and low extra delay background transfer (LEDBAT).  
_LD-MPSP_ necessitates the inclusion of a timestamp field from the source in each packet, which the receiver uses to determine the one-way delay from the multipath scheduling source and transmits this calculated value back to the source in the Ack packet. This feature makes it befitted for practice in time-varying \(802.11 ay\) networks since it can continuously examine its one-way latency and backoff its window if it surpasses a (customizable) outset.  
Figure 5 shows our early findings. The time-varying evolution of 10 TCP Reno vs. 10 multipath (_LIA and LD-MPSP_) devices over \(802.11 ay\) throughputs obtained from 0 s to 200 s under erroneous channel (40% lossy channel) with two different experiments. In Experiment 1, we observe that LIA cannot compete well with TCP (see tcplia) and, in Experiment 2, we can see that our algorithm (LD-MPSP) performs better than LIA when competing with TCP (see tcpour) flows over \(802.11 ay\) networks.