# Gateway-Assisted Retransmission for Lightweight and Reliable IoT Communications
## 5 Results  
This section compares GaCoAP with MQTT-SN, CoAP, dynamic RTO in TCP (i.e., RFC 6298), and CoCoA under two different message loss rates (MLR): 0% and 10%. We introduce three output measures to investigate the performance. The first one is the average number of retransmissions in the device (denoted as \(\delta\)). The second is the average message delivery ratio of the device (denoted as \(\rho\)). The last one is the average latency (denoted as \(\lambda\)), which means the round-trip time between the device and the server. We also investigate the impact of the number of devices connected to a gateway on \(\delta\). Finally, we discuss the power consumption in our method. First of all, we introduce two functions to generate latency in our simulation. The latency is divided into two parts: one is the latency from device to gateway, and the other is the latency from the gateway to the server. The connection of the former is wireless while the latter is backbone. The latency varies with time, and the current one is related to the previous one. Based on the observation of RTT samples in [12; 13], we use a saw-like function to formulate the latency in our simulation, and the slope of RTT model is 0.12. We assume that the saw-like function of the latency between the device and the gateway is as follows:  
\[latency=(2\mu)\left[(\frac{0.12}{2}\mu)t-\left\lfloor(\frac{0.12}{2}\mu)t \right\rfloor\right]+(2\mu+0.05), \tag{10}\]  
where \(\mu\) is the average value of the saw-like function and \(t\) denotes time. In our experiments, we consider four different values of \(\mu\), which are 1, 2.5, 5, and 10. On the other hand, we assume the saw-like function of the latency between gateway and server is as follows:  
\[latency=\left[(\frac{0.12}{2}\mu)t-\left\lfloor(\frac{0.12}{2}\mu)t\right\rfloor \right]+1.5. \tag{11}\]  
Figure 5 compares the average number \(\delta\) of retransmissions. As we know, if the RTO configuration is appropriate, the number of retransmissions should be small. MQTT-SN and CoAP use fixed RTO, which results in worse performance than the other three methods using dynamic RTO in many cases. This figure shows that \(\delta\) in MQTT-SN significantly increases as \(\mu\) increases, while \(\delta\) in CoAP is insensitive to \(\mu\). This phenomenon is explained as follows. RTO in MQTT-SN is set to 10 s, so \(\delta\) is small when \(\mu\) is small. While \(\mu\) becomes large, \(\delta\) is getting worse. Take \(\mu=5\), for example, where the average one-way latency between device and gateway is 5.05 s. Obviously, RTO as 10 s is too small to be suitable for this situation. On the other hand, devices in CoAP choose RTO randomly from 2 to 3 s as their initial RTO. This RTO value is too small even though \(\mu\) is set to 1. However, RTO is updated with an exponential back-off mechanism, such that \(\delta\) becomes insensitive to \(\mu\) in the observed range. Compared to CoCoA and GaCoAP, RFC 6298 only takes RTT of first transmission into account and ignores the RTTs of retransmissions. This RTT information cannot reflect the entire network situation in real-time. As a result, the \(\delta\) performance in RFC 6298 is worse than that in CoCoA and GaCoAP. In GaCoAP, RTO is not only based on the calculation in CoCoA but also updated by shared ACK message. Device in GaCoAP can obtain an appropriate RTO earlier so GaCoAP outperforms other methods, especially in bad network conditions. In the case that MLR = 10% and \(\mu=10\), the devices adopting GaCoAP can save at most \((1.902-0.507)/1.902=97.3\%\) in terms of the number of retransmissions and \((0.998-0.507)/0.998=49.1\%\) at least. Figure 6 shows the effects of \(\mu\) and MLR on the average message delivery ratio \(\rho\) (which means the ratio of the messages received by the server and the messages sent by the device). In this figure, MQTT-SN has the best performance because it uses the persistent policy (while others adopt RRP policy).