# Gateway-Assisted Retransmission for Lightweight and Reliable IoT Communications
## 2 Related Works  
In this section, we first introduce two popular lightweight publish/subscribe protocols that can be used in IoT. To minimize power consumption, both protocols adopt fixed RTO as retransmission criteria. We then describe two mechanisms using dynamic RTO. Message Queuing Telemetry Transport (MQTT) is a machine-to-machine connectivity protocol that runs over Transmission Control Protocol (TCP) [7]. It is designed for short length packets. MQTT-SN is a modified version of MQTT for sensor networks. Instead of TCP, MQTT-SN runs over UDP for lightweight purposes [4]. Figure 2 shows the architecture of MQTT-SN. Although IoT devices use the MQTT-SN protocol, they need a gateway to connect to the MQTT server while the connection between the gateway and the server is still the MQTT protocol. There are two types of MQTT-SN gateways: transparent gateways and aggregating gateways. Transparent gateways maintain each connection from the devices to the server but aggregating gateways only maintain one MQTT connection to each server. There are three levels of Quality of Service (QoS) that can be used when the data are delivered. Level 0 is called at-most-once delivery. This is best-effort delivery without any retransmission service so the data are always transmitted at most once. Level 1 is called at-least-once delivery. The data are delivered at least once. The device stores the data until it receives an ACK (called PUBACK) from the receiver. Level 2 is called exactly-once delivery, which guarantees that the data are received only once [4]. For QoS levels 1 and 2, a retransmission mechanism is required. MQTT-SN  
Figure 1: Publish/subscribe model. specification provides two parameters for retransmission: \(T_{retry}\) and \(N_{retry}\). The first one indicates a fixed RTO value recommended between 10 and 15 s. The second one represents the maximum number of retransmissions recommended from three to five times. CoAP is proposed by the Internet Engineering Task Force (IETF) for constrained devices to connect to the Internet. Based on UDP, CoAP supports both reliable (called Confirmable or CON) and unreliable (called Non-Confirmable or NON) transmission. By using NON, there is no need to return ACK and no retransmissions occur. On the other hand, when the RTO of a device expires, the publication data will be retransmitted by using CON. _Initial RTO_ is defined as the RTO used for the first transmission of a message. In CoAP, the default maximum number of retransmissions is four, and the initial RTO is randomly chosen from 2 to 3 s. Once the RTO expires before ACK reception, the next RTO is updated with exponential back-off mechanism. (i.e., if the initial RTO is two, the next RTO is updated to four and the third time will be to eight.) [5] Note that configuration of these parameters is application-specific. Without loss of generality, we only consider the default values proposed by RFC 7252 in this paper. MQTT-SN and CoAP use fixed RTO, which is simple but may not work well in wireless networks. The dynamic RTO in TCP is defined in RFC 6298 [8]. The notations used in calculating dynamic RTO are shown in Table 1.  
The following five rules of RTO are defined in RFC 6298:  
1. When there is no RTT sample, the RTO is set to 1 (i.e., \(\Omega=1\)); otherwise, the RTO is set based on smoothed round-trip time (SRTT, denoted as \(\gamma^{*}\)) and RTT variation (RTTVAR, denoted as \(V_{\gamma}\)). 2. When the first RTT sample \(\gamma\) is obtained, \[\gamma^{*}=\gamma,\] (1) \[V_{\gamma}=\frac{\gamma}{2}.\] (2)
3. When a new RTT is sampled, then \[V_{\gamma}=(1-\beta)V_{\gamma}+\beta|\gamma^{*}-\gamma|,\] (3) \[\gamma^{*}=(1-\alpha)\gamma^{*}+\alpha\gamma,\] (4) \begin{table}
\begin{tabular}{c c} \hline \(\gamma\) & round-trip time (RTT) \\ \(\gamma^{*}\) & smoothed round-trip time (SRTT) \\ \(V_{\gamma}\) & round-trip time variation (RTTVAR) \\ \(\Omega\) & retransmission timeout (RTO) \\ \hline \end{tabular}
\end{table} 
Table 1: Notations of Dynamic RTO in RFC 6298. Figure 2: MQTT-SN architecture.