## 3 Dual-Stack Single-Radio Communication Architecture (DSSRCA)
### UAV-to-Sink Communication  
DSSRCA provides a partition for performing a reliable communication between the UAV and the Sink. This layer makes use of 6 LoWPAN [28] in conjunction with our customized transport layer, which aims at improving the reliability in terms of message transmissions. The proposed protocol also allows to distinguish messages among three different classes of priorities: (i) low; (ii) normal; and (iii) high. The messages are stored in a priority queue implemented using binary heaps. For each priority class there is a maximum number of re-transmission attempts associated. High priority messages have an unlimited number of re-transmission attempts. Messages with medium priority have \(n\) attempts (typically 5), and messages with low priority have no re-transmissions. To improve reliability, the proposed approach provides basic mechanisms for message re-transmission, duplicated packet detection, and error-checked delivery of a stream of octets between applications running on both the UAV and the Sink. It follows the philosophy of connection-oriented protocols, meaning that applications must first establish a connection with each other before they send data in full-duplex mode. In order to guarantee proper data delivery, the protocol uses a technique known as positive acknowledgment, in which the sender transmits the message with its own sequence number, and waits for the receiver to acknowledge the message reception by sending an ACK message with the sequence number received. At the moment the sender transmits the data, a timeout mechanism is initiated to wait for the acknowledgment. If the timer expires before the message has been acknowledged, the sender re-transmits the message. A very important point to ensure the data transmission efficiency, is the tuning of the re-transmission timer (RTO). If the value is too high, the protocol will be slow in reacting to a segment loss, thus reducing the throughput. On the other hand, if the value is too small, it will result in unnecessary re-transmissions that lead to exaggerated consumption of network resources. The goal is to find an RTO value that balances throughput degradation between both cases. The proposed solution uses a dynamic algorithm to continuously adjust the timeout value based on monitoring the packet transmission delay. The round trip time variance estimation algorithm introduced by [29] was chosen and frequently applied in the TCP congestion control. The algorithm maintains a _SmoothedRTT_ variable to represent the best estimated timeout for the packet round-trip time. When a message is sent, a timer is triggered to measure how long it takes to get the confirmation and stores the value in the _MeasuredRTT_ variable. Then, the algorithm updates _SmoothedRTT_ as shown in Equation (1). \[SmoothedRTT=\alpha.SmoothedRTT+(1-\alpha).MeasuredRTT \tag{1}\]  
where \(\alpha\) is a smoothing factor with a recommended value of 0.9: in each measure, _SmoothedRTT_ is updated using 10% from the new estimate and 90% from the previous one. In order to respond to large fluctuations in the round-trip times, RFC793 recommends using the re-transmission timeout value (RTO), as defined in Equation (2):  
\[RTO=min[UBOUND,max[LBOUND,\beta.SmoothedRT]] \tag{2}\]  
where \(\beta\) is a delay variance factor with a value of 1.3. The constant UBOUND is an upper bound on the timeout with a minimum value of 100 ms. The LBOUND is a lower bound on the timeout with a value of 30 ms. The values of \(\beta\), LBOUND and UBOUND were obtained by conducting empirical tests on the UAV-to-BS communication. This mechanism can lead to a poor performance since the sender does not transmit any message until the acknowledgment of the last message is received. To solve this problem, a new solution based in the TCP sliding window concept [30] is proposed in this work. Sliding window is the number of messages the sender transmits before waiting for an acknowledgment signal from the receiver.