## 6 Results
### Reliability
According to Equation (4), the error rate for a non-fragmented packet is obtained for f equal to one. The tests done for reliability cover four different SNR: 1 dB, 1.5 dB, 2 dB and 2.5 dB. In Table 4 we report the corresponding application layer packet error rates. According to the number of fragments and the relative error rate, we calculate the average goodput of a data transfer. This value is calculated according to the goodput obtained in 100 consecutive transactions. Unlike the previous tests, the reliability evaluation does not take into account the HTTP/UDP solution. In fact, none of those protocols provide any reliability mechanism, the definition of which is beyond the scope of this paper. Errors are introduced by comparing the application layer error rates with a sequence of random numbers. Should the random number be less than or equal to the error rate, the CoAP or HTTP message received by the server is discarded at UDP layer. In this way, the application layer will consider that an error has occurred in the communication and will retransmit the packet. The same sequence of random numbers is used for each solution tested in order to ensure that in each experiment there are the same numbers of errors. Moreover, the errors will occur in the same order. \begin{table}
\begin{tabular}{c c c c c} \hline \hline
**f** &  
Figure 10 shows the goodput in bytes per second obtained for each SNR level. TinyCoAP surpasses the other solutions in all cases. CoapBlip has a goodput trend that is lower but close to that of TinyCoAP. In this case, the differences between the implementations of the retransmission mechanisms of TinyCoAP and CoapBlip are minimal and negligible. The different performances are therefore due exclusively to the differences in packet processing, as previously explained. Figure 10: Goodput evolution in a channel under the Rayleigh fading model. **(a)** Goodput with SNR of 1 dB; **(b)** Goodput with SNR of 1.5 dB; **(c)** Goodput with SNR of 1.5 dB; **(d)** Goodput with SNR of 2.5 dB. The reliability mechanism implemented in CoAP yields a good performance. In TCP, the initial retransmission timeout is resettled after closing each connection, providing a better performance in channels with low SNR. Once again, the solutions for which HTTP is adopted yield the worst performance. In channels having a high SNR, the HTTP persistent has a goodput trend higher than that of HTTP/TCP. However, when the SNR is lower and the consequent error rate increases, the HTTP/TCP trend exceeds that of HTTP persistent. This can be explained by considering the behavior of the algorithm for the calculation of the retransmission timeout (RTO) specified in [46]. In fact, HTTP persistent and HTTP/TCP cannot measure the round trip time (RTT) of communications affected by retransmissions. The RTT is used by the algorithm to calculate the RTO and should be relative only to communications unaffected by retransmissions. However, the RTT of a retransmitted communication that has been acknowledged can only be measured by using the timestamp option of TCP. In our experiments, we employ a TCP version that does not use this option. Consequently, the behavior of HTTP/TCP and HTTP/TCP can be explained by considering the behavior of HTTP/TCP and HTTP/TCP. Figure 10: Cont. HTTP persistent could differ significantly when the channel presents a low SNR and retransmissions are more frequent. Should two successive communications in HTTP persistent be affected by retransmissions, the RTO would not be recalculated but rather augmented exponentially until a valid RTT measure can be taken. Alternatively, HTTP/TCP would be able to measure the RTT and calculate the RTO each time it establishes a new connection. Thus, when there are successive communications affected by retransmissions, the HTTP persistent would undergo a latency greater than that of HTTP/TCP.