Analysis and Solutions to 3G Gateway Issues in Agriculture WSNs

Abstract

Wireless sensor networks (WSN) are used extensively in various important areas of agriculture. Many of the associated activities involve the transmission of data or control commands through gateways that connect the servers to 3G networks. In this paper, we investigate the issues caused by Radio Resource Control (RRC) state transitions, which introduce high sudden delays in TCP packets. The packets that are subjected to these delays are then usually retransmitted because of timeouts. Further, the recently recommended TCP retransmission timer settings (RFC6298) reduce the initial retransmission timeout (RTO) from the previous three seconds to one second, further exacerbating the phenomenon of SYN packet retransmission, because a SYN packet is always the first packet to trigger the RRC state to change. We conduct a number of tests to examine the phenomenon and analyze the effect of this spurious retransmission timeout. Consequently, we propose recommendations for improvement.

1. Introduction

Wireless sensor networks (WSNs) are one of the most significant technologies developed in recent years and have been applied extensively in various areas of agriculture. Compared with wired networks, WSNs can be installed in a wide range of environments and provide benefits in terms of cost, size, power, flexibility, and distributed intelligence [1]. WSNs have been utilized in tasks such as remote monitoring, management of the agricultural environment [2], precise irrigation [3], and greenhouses [4]. Most of the research associated with WSNs focus on areas such as design of the sensors, energy cost, and applications to new scenarios. In this paper, we focus on the issues faced by WSN gateways in 3G networks.

As illustrated in Figure 1, a WSN system for agriculture generally consists of the following components: sensor nodes, sink nodes, actuators, gateway, server, and the farmer's phone or computer. The sensor nodes deployed in the farmland can autonomously connect with each other. Data such as soil moisture and air temperature/humidity are collected by the sensor nodes and transmitted to the server. According to the data received, the server then sends back data/control commands to the sensor nodes or the actuators. The gateway is designed to connect to the Internet to relay the data or the control commands among the sensor nodes, the actuators, the farmer's phone, and the server. Networks such as 3G networks can be used as the gateway's access network. Therefore, it is important to ensure that the performance of data transmission in this 3G gateway is precise and real-time to support the agriculture WSN.

Figure 1

Typical architecture of a WSN for agriculture.

However, Radio Resource Control (RRC) state transitions have a negative effect on the transmission in 3G networks. RRC is in charge of all things related with wireless resource allocation, effectively implementing the lower part of the protocol stack [5]. RRC can change to different states to conserve power while ensuring good performance on resource constrained mobile devices [6]. During the RRC state transitions, no data can be transmitted. Consequently packets transmitted during the transitions suffer from delays.

Most of these delays can be for durations of 2 s in 3G networks, which obviously does not meet the requirement of real-time transmission. Further, when the gateway uses TCP as the transmission protocol in 3G networks, it may face a high retransmission rate. TCP is implemented as a reliable data transfer protocol in wired networks. It uses a retransmission timer with a duration known as the retransmission timeout (RTO) to decide when TCP retransmits. When a retransmission occurs, the sender assumes that the packet is lost as a result of network congestion. Consequently, the sender immediately retransmits the outstanding packet, sets the size of the congestion window (cwnd) to one, and reduces the slow start threshold (ssthresh). However, the TCP transmission is no longer reliable in 3G networks because the RRC state transits among different states in 3G networks. In addition, even when there is no congestion, these transitions cause TCP packets to have high sudden delays of 0.5–2.7 s, resulting in a large number of packet retransmissions, which degrade the performance of TCP. The latest document for RTO (RFC6298) [7] has no strategy to deal with RRC state transition delays. Furthermore, it reduces the initial RTO from the previous 3 s [8] to 1 s. This modification is mainly based on the current prevalence of high-speed networks with increasingly smaller RTTs. However, the reduced RTO is not appropriate for 3G networks. The reduction in the initial RTO results in the SYN packet—the first packet in a connection and, thus, always the first packet to trigger state transitions—going through unnecessary retransmission timeouts.

To facilitate understanding of this phenomenon, this paper first presents background knowledge on TCP's retransmission timer. Then, considerations for the initial RTO and reasons for RFC6298 setting the initial RTO to 1 s are discussed. Next, state transitions by RRC in 3G networks are examined and several tests are conducted to verify that TCP packets are retransmitted spuriously by timeout when they go through the RRC state transitions, especially the retransmission timeout of SYN because of the initial RTO being set to 1 s.

Next, we analyze the serious consequences of this spurious retransmission timeout. First, it results in unnecessary data being injected into the network and an increase in user traffic. Second, it degrades TCP's performance. Spurious retransmission timeouts make the calculation of RTOs deviate from the proper values and cwnd becomes one, leading to an increase in the time and energy needed to complete the TCP flow.

This paper presents our strategies for improvements in both ideal and actual cases. In the ideal case, we assume that we can obtain accurate RRC states and their related parameters by simply freezing the retransmission timer during the RRC state transitions. However, in reality, accurate RRC states cannot be obtained in time, and the intervals of the RRC states from different carriers have large ranges. Most of the TCP packets that trigger the RRC state transitions are SYN packets and most of the RRC state transitions are $\text{IDLE}\to \text{DCH}$ . Taking these factors into account, we focus on the RTO of SYN and the transition $\text{IDLE}\to \text{DCH}$ in real cases.

The remainder of this paper is organized as follows. We first present related work on the application of 3G gateways to agriculture WSNs and spurious retransmissions in Section 2. We discuss TCP's retransmission timer, the sudden delays caused by RRC state transitions, and tests conducted to examine the retransmission timeout TCP packets undergo when they are affected by the RRC state transitions in Section 3. We then analyze the effect of this spurious retransmission timeout in Section 4 and propose and implement solutions to the problem in Section 5. Finally, this paper is concluded in Section 6.

2. Related Work

Many WSN gateways utilized in agriculture connect to the server via 3G networks. Lao and Teng [9] designed and implemented a seamless 3G access system to facilitate remote video monitoring and remote equipment control in facility agriculture without a wired connection to the Internet. The system consisted of a wireless communication module comprising a 3G SIM card, wireless router, and a virtual private network (VPN) module and used layer 2 tunneling protocol (L2TP) and IP security to borrow lines from the VPN server and solve the problem of determining a private 3G network address transaction (NAT) address. It provided sufficient video bandwidth and cheap wireless network access solutions, was low cost with high universality and good extensibility, and could be easily implemented.

Paventhan et al. [10] compared SNMP and CoAP-based WSN monitoring approaches in agricultural field deployments connecting with the ERNET IPv6 backbone network. They used 3G dongles to establish IPv6 network connectivity to the nodes deployed in the remote field, where the PAN coordinator node was to be connected to the gateway. Currently, support for IPv6 is not available from 3G service providers. Thus, in order to achieve an end-to-end IPv6 connectivity, they used a dual stack host running OpenVPN server and the 3G/6LoWPAN gateway running the OpenVPN client.

Ko et al. [11] used WSN to implement a real-time traceability and monitoring system for agriculture. They designed hubs as gateways, with each hub having a cellular phone number associated with its WCDMA module. They defined the communication protocol between the server and the hub as follows: a sleeping hub is awoken by the server via an SMS message to the hub. Then, the hub sends a connection request to the server. After the connection between the server and the hub is established, the server sends configuration information, such as transmission period, to the hub. The hub then sends location data and collected sensor data to the server periodically. Although no explanation was given as to why SMS was used to wake up the hub, the system solved the problem of the server not being able to actively start the connection to the gateway with NAT policy.

Much research has also been conducted on the detection of spurious retransmissions. The Eifel algorithm [12] uses the TCP timestamp option to detect spurious retransmission. When sending packets, the sender adds a timestamp to each outgoing packet. Upon receiving that packet, the receiver reflects back the timestamp value in the corresponding ACK. Once a retransmission timeout occurs, the sender stores the timestamp of the retransmitted packet. Then, if the timestamp in the first received ACK is smaller than the stored value, the sender assumes that that was a spurious retransmission. The disadvantage of Eifel is its use of the timestamp option, which adds 12 B to every TCP packet's header.

“Duplicate SACK” (DSACK) [13], an extension to the Selective Acknowledgment (SACK) protocol, uses the first SACK block to specify the segment that triggers a duplicate acknowledgment (Dup-ACK) at the receiver. Unlike Eifel, which introduces much traffic, a DSACK block is only used to report a duplicate contiguous sequence of data received by the receiver in the most recent packet [13].

F-RTO [14], which is only deployed at the sender, can detect spurious retransmissions without any TCP option. It operates as follows: when a timeout occurs, the sender retransmits one outstanding packet, as usual. If the first ACK after the retransmission advances the cwnd, the sender sends two new packets instead of retransmitting the next two packets. If these two packets cause Dup-ACKs, the retransmission is not a spurious one. Otherwise, if the consequent ACK advances cwnd, the sender considers the retransmission to be spurious. Compared to other algorithms, F-RTO requires more time to detect spurious retransmission.

The studies cited above assume that the sudden delays occur irregularly, and so they detect the spurious retransmissions after the retransmissions. However, in 3G networks, the sudden delays caused by RRC state transitions are related to certain parameters that determine when RRC state transitions occur. These delays occur in a particular range. Consequently, we can adjust the retransmission timer at the right time to avoid some of the spurious retransmissions caused by RRC state transitions. In contrast, these studies only recover the cwnd, ssthresh, and the slow start after detection of the spurious retransmission. They do not consider how the spurious retransmissions affect the RTO value and how to deal with them.

3. Verifying the Spurious Retransmissions Phenomenon

3.1. Background Knowledge

3.1.1. TCP Retransmission Timer

TCP uses a retransmission timer to ensure data delivery in the absence of any feedback from the remote data receiver [7]. The duration of this timer is referred to as the retransmission timeout (RTO). The RTO needs to be set before a connection is established and subsequently updated based on the smoothed round-trip time (SRTT) and the round-trip time variation (RTTVAR). The initial RTO is used for the first packet, which is known as SYN. SRTT and RTTVAR are computed with round-trip time (RTT).

Choosing a reasonable initial RTO and calculating the following RTOs require balancing of two competing considerations [7].

• (1)

The RTO should be sufficiently large to cover most of the end-to-end paths in order to avoid spurious retransmissions and their associated negative performance impacts.

(2)

The RTO should be small enough to ensure a timely recovery from packet losses.

In fact, all the RTOs should be set to not only larger than but also as close as possible to the RTT. This is also the goal of the studies on RTO. In studies conducted on the initial RTO, Chu [15] showed that roughly 2.5% of the connections have an RTT longer than 1 s, and the retransmission rate of SYN is approximately 1.42%. Thus, a gain can be expected from reduction of the three-way handshake time by changing the initial RTO from 3 s to 1 s. This change was expected to benefit the short flows because the proportion of the three-way handshake is large compared to the duration of the short flows. Thus, if the packet dropping probability is X%, the average of the three-way handshake completion time improves by 2 × 2000 ms ×  X%. For example, a user accessing a website 10 ms away with a packet drop rate of 1% would enjoy a 40 ms reduction in average latency [15].

The latest IETF recommendation for setting the retransmission timer, given in RFC6298 [7], reduces the initial RTO setting from 3 s to 1 s. At the same time, if the timer expires while awaiting the ACK of a SYN segment and the TCP implementation is using an RTO less than 3 s, the RTO must be reinitialized to 3 s when data transmission resumes (i.e., after the three-way handshake is complete) [7]. According to RFC5681 [16], the initial cwnd is limited to one segment after an extra SYN packet is transmitted into the network.

There are two reasons for the changes: on the one hand, reference is made to Chu's [15] work, whereas on the other hand, analysis of the RFC5681 datasets find the prevalence of retransmitted SYN packets to be from 0.03% to roughly 2%. However, none of the datasets referenced are from 3G networks. Therefore, no consideration was given to the possibility that the sudden delays caused by RRC state transitions could be more than 1 s.

Although TCP's retransmission timer algorithm has been examined in many studies, it still fails to cope well with sudden delays in 3G networks. Scharf et al. [17] concluded that sudden delays are critical when they are in the order of seconds, for example, the sudden delays caused by RRC state transitions in Section 3.1.2. Sudden delays lead to unnecessary spurious retransmissions and misjudgment of the congestion.

3.1.2. RRC State Transitions

As shown in Figure 2, there are different RRC states for the User Equipment (UE) in a 3G network. Their related parameters are listed in Table 1. RRC has three major states: IDLE, DCH, and FACH. Data can only be transmitted in DCH and FACH. When it is in FACH, transmission uses the shared channel. When it is in DCH, transmission uses the dedicated channel, which has a higher speed and energy consumption than the shared channel. When RRC is in IDLE and there are data to be transmitted, $\text{IDLE}\to \text{DCH}$ occurs immediately. After the transmission is complete and the threshold of the DCH release timer ( $T_{\text{I}\_\text{DCH}\to \text{FACH}}$ ) is exceeded, $\text{DCH}\to \text{FACH}$ takes place. The transition back to DCH is carried out if there is data, waiting to be transmitted, which results in the Buffer Occupancy (BO) level at the Radio Link Control layer exceeding the threshold value for a set time [18]. Moreover, if the inactivity time in FACH is long enough (over $T_{\text{I}\_\text{FACH}\to \text{IDLE}}$ ), the RRC will change back to IDLE.

Table 1

RRC related parameters.

Symbol	Full name	Description
$$T_{\text{I}\_\text{DCH}\to \text{FACH}}$$	Inactivity time for DCH to FACH	When the channel is inactive, RRC stays in DCH for $$T_{\text{I}\_\text{DCH}\to \text{FACH}}$$ before changing into FACH
$$T_{\text{I}\_\text{FACH}\to \text{IDLE}}$$	Inactivity time for FACH to IDLE	When the channel is inactive, RRC stays in FACH for $$T_{\text{I}\_\text{FACH}\to \text{IDLE}}$$ before changing into IDLE
$$T_{\text{I}\_\text{DCH}\to \text{IDLE}}$$	Inactivity time for DCH to IDLE	After the data have been transmitted in DCH, RRC requires $$T_{\text{I}\_\text{DCH}\to \text{IDLE}}$$ to change to IDLE ( $$T_{\text{I}\_\text{DCH}\to \text{FACH}}$$ + $$T_{\text{DCH}\to \text{FACH}}$$ + $$T_{\text{I}\_\text{FACH}\to \text{IDLE}}$$ )
$$T_{\text{IDLE}\to \text{DCH}\hspace{0.17em}(\text{UL/DL})}$$	Duration time from IDLE to DCH (uplink/downlink)	The RRC needs $$T_{\text{IDLE}\to \text{DCH}}$$ to change from IDLE to DCH
$$T_{\text{DCH}\to \text{FACH}}$$	Duration time from DCH to FACH	The RRC needs $$T_{\text{DCH}\to \text{FACH}}$$ to change from DCH to FACH
$$T_{\text{FACH}\to \text{DCH}}$$	Duration time from FACH to DCH	The RRC needs $$T_{\text{FACH}\to \text{DCH}}$$ to change from FACH to DCH

Figure 2

RRC state transitions for 3G network.

The RRC related parameters, typically, $T_{\text{I}\_\text{DCH}\to \text{FACH}}$ , $T_{\text{I}\_\text{FACH}\to \text{IDLE}}$ , are different in different carriers. Qian et al. [19] and Perälä et al. [18] tested five commercial 3G networks and presented the intervals of the transitions and the duration of $\text{IDLE}\to \text{DCH}$ for uplinks and downlinks. Table 2 shows the datasets for NET1, NET2, and NET3, from Perälä et al. [18], and NET4 and NET5 from Qian et al. [19]. As Table 3 shows, Perälä et al. [18] also tested the one-way delays in various RRC states.

Table 2

Parameters of various carriers.

	Net#1 (s)	Net#2 (s)	Net#3 (s)	Net#4 (s)	Net#5 (s)
$$T_{\text{I}\_\text{DCH}\to \text{FACH}}$$	2.66–2.99	2.74–2.91	1.20–1.80	5	6
$$T_{\text{I}\_\text{DCH}\to \text{IDLE}}$$	62.9–63.6	29.1–30.2	20.4–1.3	17	10
$$T_{\text{IDLE}\to \text{DCH\hspace{0.17em}(DL)}}$$	2.67 ± 0.05	2.63 ± 0.033	2.45 ± 0.019	2	N/A
$$T_{\text{IDLE}\to \text{DCH\hspace{0.17em}(UL)}}$$	1.87 ± 0.01	1.88 ± 0.033	1.73 ± 0.058
$$T_{\text{FACH}\to \text{DCH}}$$	No measurement	No measurement	No measurement	1.5	1.3

Table 3

One-way delays in various RRC states.

	DCH, DL (ms)	DCH, UP (ms)	FACH (ms)	IDLE, DL (s)	IDLE, UP (s)
Net#1	43.6 ± 2.8	129 ± 8.2	138 ± 1.10	2.71 ± 0.05	2.0 ± 0.01
Net#2	33.7 ± 0.23	147 ± 2.5	136 ± 0.47	2.67± 0.033	2.03 ± 0.0047
Net#3	46.0 ± 1.26	93.9 ± 1.3	152 ± 0.58	2.50 ± 0.019	1.82 ± 0.058

These transitions are the reason why packets go through sudden delays. These sudden delays are called “first packet delays” by Han et al. [20]. A large part of the “first packet” comprises SYN packets. Most of the RRC state transitions are triggered by the first packet of a TCP connection. Contrasting Table 2 with Table 3, the one-way delays and the durations of RRC state transitions are proportional. From these two tables, the ranges of the durations of $\text{IDLE}\to \text{DCH}$ and $\text{FACH}\to \text{DCH}$ are 1.73 s to 2.71 s and 1.3 s to 1.5 s, respectively. They are larger than the initial RTO value of 1 s modified by RFC6298.

3.2. Verification Tests and Results

We used an Android smartphone with a 3G module as a gateway and modified the kernel to operate according to RFC6298, with initial RTO 1 s, but its min-RTO was kept at 200 ms. The network topology is shown in Figure 3. We conducted the test in a commercial TD-SCDMA network environment. The data were collected via the tcpdump tool.

Figure 3

Test network topology.

For the following two reasons, we only tested the transition from IDLE to DCH: (1) the delay caused by $\text{IDLE}\to \text{DCH}$ is higher and more common; it makes TCP's performance worse; (2) it is easier to control the transitions between IDLE and DCH, and we can maintain the inactivity period long enough to ensure that the RRC has changed into IDLE. Further, $\text{IDLE}\to \text{DCH}$ occurs once there are data to be transmitted. Relatively, the transitions between FACH and DCH are more complicated.

Test 1. We set up a UDP connection and a long-lived TCP connection. Then, we used the following algorithm to infer $T_{\text{I}\_\text{DCH}\to \text{IDLE}}$ and $T_{\text{IDLE}\to \text{DCH}}$ in our 3G network.

Algorithm

•  

(1) gateway sleeps for 50 s.

 

(2) for $n=0$ to 60 do.

 

(3) gateway sends a UDP packet.

 

(4) gateway sleeps for n s.

 

(5) gateway sends a TCP packet with 3 B of data.

 

(6) gateway records the RTT for Step (5).

 

(7) gateway sleeps for 50 s.

 

(8) end for.

In the algorithm, the purpose of Steps (1) and (7) is to change the RRC to IDLE. The UDP packets sent by Step (3) try to trigger $\text{IDLE}\to \text{DCH}$ . In Step (5), we only send one TCP packet. Thus, we can differentiate whether the packet lost occurs by the number of the ACK packet. If retransmission occurs, the RTT recorded in Step (6) is the interval between the original packet and the first ACK packet. If the RTT is greater than 2 s, the corresponding n s in Step (4) is equal to or greater than $T_{\text{I}\_\text{DCH}\to \text{IDLE}}$ .

The results are shown in Figure 4. When $0\le n\le 2$ , the first three RTTs are 2.458 s, 1.482 s, and 0.621 s, respectively. Because their corresponding TCP packets are so close to the UDP that the RRC is still changing, when $3\le n\le 18$ , their corresponding TCP packets are transmitted in the DCH or FACH state, and the average of their RTTs is 0.286 s. When n is 57, its related TCP packet is lost in the first transmission. When n is greater than 18 but not equal to 57, the average of their corresponding RTTs is 2.563 s. Consequently, we can infer that $T_{\text{IDLE}\to \text{DCH}}=2.563-0.286=2.277$  s; $T_{\text{I}\_\text{FACH}\to \text{IDLE}}=19-2.277=16.623$  s. In the following tests, if we want the RRC to change into IDLE, we can let the channel be inactive over 20 s. According to the reference papers and our measured value, we use 2 s as $T_{\text{IDLE}\to \text{DCH}}$ in Section 5.

Figure 4

RRC state transition inference results.

Test 2. In this test, we confirmed that the 1 s initial RTO has problem when TCP encounters RRC state transitions. We set up a TCP connection from the gateway to the server every 30 s and then terminated it after 10 s, surpassing the $T_{\text{I}\_\text{DCH}\to \text{IDLE}}$ to ensure that the previous connection is complete. This 30 s makes RRC change to the IDLE state. We observed the SYN packets in these TCP connections. A total of 10 TCP connections were completed in this work.

The results show that all the SYN packets are retransmitted only once. Further, the interval between the original SYN packet and its retransmission is approximately 1 s, which is equal to the initial RTO. Figures 5 and 6 illustrate the retransmission process. The server returns two SYN + ACKs for every connection.

Figure 5

SYN retransmission in Test 2.

Figure 6

SYN retransmission process.

Test 3. In this test, we examined how the RRC state transitions affect the TCP flow.

Case 1.

Following the establishment of a TCP connection without retransmission, the gateway slept for 30 s to facilitate the RRC changing to IDLE. Then, the gateway sent a UDP to trigger the RRC state transition. In another 3 s after completion of the RRC state transition, the gateway sent 10 TCP packets to the server.

Case 2.

Following the establishment of a TCP connection without retransmission, the gateway slept for 30 s to facilitate the RRC changing to IDLE. Then, the gateway sent 10 TCP packets to the server when the RRC was in the IDLE state.

We repeated these tests four times. In Case 1, TCP delivered the data smoothly after the UDP packet transitioned the RRC to the DCH state. In contrast, in Case 2, the TCP had to spend a lot of time with RRC state transition. The retransmission also degraded TCP's performance. Figures 7 and 8 show details of the typical TCP flows in both cases. As shown in Table 4, the average completion time for the data transmission is larger in Case 2, and even $T_{\text{IDLE}\to \text{DCH}}$ is added to the average completion time in Case 1. The average traffic in Case 2 is twice that of Case 1.

Table 4

Completion time and traffic in the two cases.

	Avg. completion time(excluding three-way handshake)	Avg. traffic(only TCP level, excluding three-way handshake)
Case 1	464 ms	14040 B
Case 2	3155 ms	28140 B

Figure 7

Details of typical TCP flows in Case 1.

Figure 8

Details of typical TCP flows in Case 2.

4. Analysis of the Adverse Effects

4.1. Unnecessary Traffic

When spurious timeout occurs, the sender retransmits extra packets into the network. The receiver then responds with a DUP-ACK, which is also unnecessary. If the SYN packet triggers the RRC state transitions and spurious retransmission timeouts occur, the traffic is doubled in three-way handshake.

4.2. RTO Related Effect

According to RFC6298, if the timer expires while awaiting the ACK of a SYN packet and the TCP implementation is using an RTO less than 3 s, the RTO must be reinitialized to 3 s when data transmission recommences (i.e., after the three-way handshake has completed) [7]. If the TCP connection uses the timestamp option and this retransmission occurs after a three-way handshake, the bad RTT samples with the delays caused by RRC state transitions can be acquired and used to calculate the next RTO.

4.3. Effect on cwnd and ssthresh

TCP's initial cwnd is 10 [21] and the initial ssthresh is set arbitrarily high [16]. However, if retransmission timeout occurs in the three-way handshake phase, the initial cwnd is limited to one segment and the ssthresh is reduced to either one or two segments [15]. We assumed that 10 consecutive segments are transmitted successfully after a three-way handshake, with RTT 200 ms. In the normal case, the completion time of the ten segments is only one RTT. However, when SYN retransmission timeout occurs, it costs four RTTs. The cwnd then takes on the values 1, 2, 3, and 4. In the data phase, if retransmission timeout occurs, one-half of the current window size is saved in ssthresh, and then cwnd is set to one segment.

In summary, a spurious retransmission timeout due to RRC state transitions is equivalent to making a wrong judgment on the congestion. The disadvantages of spurious retransmission timeout caused by RRC state transitions are summarized in Figure 9.

Figure 9

Disadvantages of spurious retransmission timeout.

5. Recommendations for Improvement

In this section, we first propose strategies for 3G networks in the ideal and actual cases and then present related considerations.

The Ideal Case. For the gateway, we assume that we can acquire the RRC states and related parameters. When TCP packets trigger a transition or they are in transition, we can simply freeze their retransmission timers until the transition is complete. If the timestamp option is used, the remainder of the transition duration should then be added to the timestamp. For the server, its strategies are the same in the actual case.

The Actual Case. To the best of our knowledge, there is no public API in the Linux kernel to acquire the RRC states. Further, the parameters of the RRC states in different carriers have large ranges. The ranges of $T_{\text{I}\_\text{DCH}\to \text{FACH}}$ , $T_{\text{I}\_\text{FACH}\to \text{IDLE}}$ , $T_{\text{IDLE}\to \text{DCH}(\text{DL})}$ , $T_{\text{IDLE}\to \text{DCH}(\text{UL})}$ , $T_{\text{FACH}\to \text{DCH}}$ , and RLC buffer thresholds are 1.2–6 s, 4–61 s, 2–2.67 s, 1.73–2.7 s, 1.3–1.5 s, and 64–1024 B, respectively. Thus, we propose general strategies that can be deployed in the different carrier networks.

For SYN Packets. The RTO of SYN should be set to 3 s. If the RTO timer expires while awaiting the ACK of the first SYN packet, the next RTO of SYN should be set to 2 s. The initial RTO of SYN + ACK should still be 1 s. If the SYN + ACK returns after 2 s, the RTO should be set to 1 s after three-way handshake.

For Non-SYN Packets

•  

(1) When there is a packet to be transmitted after the phone accesses the 3G network, perform Setup 2. When the transmission queue is empty, go to Step (2-0).

 

(2-0) Start the $T_{\text{I}\_\text{DCH}\to \text{IDLE}}$ timer. While the timer is in the 0–1.2 s range, if there are packets to be transmitted, stop the timer and transmit as per usual. Following completion of the transmission queue, go to Step (2-0).

 

(2-1) While timer $T_{\text{I}\_\text{DCH}\to \text{IDLE}}$ is in the range 1.2–10 s, if there is a packet to be transmitted, stop $T_{\text{I}\_\text{DCH}\to \text{IDLE}}$ and perform Setup 1.

 

(2-2) While timer $T_{\text{I}\_\text{DCH}\to \text{IDLE}}$ is in the range 10–63.6 s, if there is a packet to be transmitted, stop $T_{\text{I}\_\text{DCH}\to \text{IDLE}}$ and perform Setup 2.

 

(2-3) After timer $T_{\text{I}\_\text{DCH}\to \text{IDLE}}$ increases beyond 63.6 s, if there is a packet to be transmitted, stop $T_{\text{I}\_\text{DCH}\to \text{IDLE}}$ and perform Setup 3.

 

(3-1) Start the $T_{\text{I}\_\text{FACH}\to \text{IDLE}}$ timer. While the timer is in the range 0–4 s, if there is a packet to be transmitted, stop $T_{\text{I}\_\text{FACH}\to \text{IDLE}}$ and perform Setup 1.

 

(3-2) While timer $T_{\text{I}\_\text{FACH}\to \text{IDLE}}$ is in the range 4–61 s, if there is a packet to be transmitted, stop $T_{\text{I}\_\text{FACH}\to \text{IDLE}}$ and perform Setup 2.

 

(3-3) After timer $T_{\text{I}\_\text{FACH}\to \text{IDLE}}$ increases beyond 61 s, if there is a packet to be transmitted, stop $T_{\text{I}\_\text{FACH}\to \text{IDLE}}$ and perform Setup 3.

Setup 1.

If the packet being sent is a TCP data packet, wait for its related ACK (include the ACK for the packets in the same congestion windows). If the timeout occurs and the DUB-ACKs come after the first TCP packet within 1.3–1.6 s, then go to Step (2-0); otherwise, go to Step (3-1). If the packet is received and its retransmission is received in the following 200 ms, then go to Step (2-0); otherwise, go to Step (3-1). In other cases, go to Step (3-1).

Setup 2.

If the packet being sent is a TCP packet, perform Setup 4. If the $T_{\text{IDLE}\_\text{DCH}}$ returned from Setup 4 is greater than 1.3 s, then go to Step (2-0); otherwise, go to Step (3-1). If a non-TCP packet is being sent, go to Step (3-1) directly. If the packet is received and its retransmission is received in the following 200 ms, then go to Step (2-0); otherwise, go to Step (3-1).

Setup 3.

If a packet is being sent, perform Setup 4, and then go to Step (2-0). If the packet is received, go to Step (2-0) directly.

Setup 4.

Start the $T_{\text{IDLE}\_\text{DCH}}$ timer, which lasts for 2 s (on the server side, it lasts 3 s). During this period, if there are TCP packets (including the TCP packet that triggered this setup) to be transmitted, freeze their retransmission timer until $T_{\text{FACH}\_\text{DCH}}$ has stopped. During the period, if any packet is received, stop $T_{\text{IDLE}\_\text{DCH}}$ early and return $T_{\text{IDLE}\_\text{DCH}}$ .

Note. (1) In Step (x-y), we have x 2 or 3 representing that the timer ${\text{T}}_{\text{I}\_\text{DCH}\to \text{IDLE}}$ or ${\text{T}}_{\text{I}\_\text{FACH}\to \text{IDLE}}$ is being used, respectively. We have y 0, 1, 2 or 3 representing that the estimated RRC state is DCH, $\text{FACH}(\text{DCH})$ , $\text{IDLE}(\text{FACH})$ , or IDLE, respectively. (2) The RTT samples that not only come from the first SYN packet but also are greater than 2 s and the samples from the TCP packets transmitted in the $T_{\text{IDLE}\_\text{DCH}}$ period will not be used to calculate the RTOs. (3) “Go to step” should be sent after the transmission queue is complete. Every TCP packet should be acknowledged.

Considerations. We developed the strategies for SYN separately to avoid all the RRC state transitions because three-way handshake is very important for the ensuing data transmission, especially for the short flows, which constitute the majority of the TCP flows in smartphone traffic. Another reason why we focus on the SYN is that a SYN packet is always the first packet that triggers the RRC state transitions. For 3G carriers’ NAT policies, we only consider cases in which the connection is set up from the gateway. The largest RRC state transitions delay in uplink mentioned in this paper is about 2 s. After adding the 1 s from the RFC6298's initial RTO value, we set the initial RTO to 3 s. We do not need to consider the RTO of SYN + ACK packets because after the server receives the SYN packet, the RRC state transition is complete.

Figure 10 shows the activity flow of the strategies for non-SYN. Steps and related RRC states are marked in the circles. Two RRC states in one circle imply that the RRC might be in one of those states. In the transitions from FACH(IDLE) to DCH, FACH(IDLE) to FACH, and IDLE to DCH, Setup 4, which freezes the RTO, is used to solve the delays caused by the RRC state transitions. In the period of Step (2-1) and Step (3-1), there is no strategy for the RTO because it is difficult to determine whether RRC changes from FACH to DCH or not by the RLC buffer surpassing the threshold. Passive detection is used to detect the RRC state transitions. However, the detection may not be completely accurate. For instance, a UDP can be large enough to trigger the transition from FACH to DCH. Thus, if no RRC transition is detected, we consider that the RRC is still in the FACH state and is missing the time point that RRC changes to IDLE. Our strategies mainly focus on the transition from IDLE to DCH base for the following three reasons. (1) $T_{\text{IDLE}\_\text{DCH}}$ lasts longer and has a more damaging effect on the TCP packet. (2) The $\text{IDLE}\to \text{DCH}$ durations are far larger than $\text{FACH}\to \text{DCH}$ . The duration of the transitions from IDLE to DCH and from FACH to DCH account for $P_{\text{IDLE}\to \text{DCH}}$ and $P_{\text{FACH}\to \text{DCH}}$ transition time of all sessions. The $P_{\text{IDLE}\to \text{DCH}}$ is much greater than $P_{\text{FACH}\to \text{DCH}}$ . In [19], $P_{\text{IDLE}\to \text{DCH}}=6.8$ %, $P_{\text{FACH}\to \text{DCH}}=0.7$ %. As mentioned above, determining whether $\text{FACH}\to \text{DCH}$ occurs or not is difficult. In all the steps, the RRC changes into FACH or DCH once a packet is received. We determined whether the received packet causes the RRC state transition or not by receiving its retransmission in 200 ms. That is, because the min-RTO in Linux is 200 ms and before we go to the next stage, the transmission queue has to be complete. This ensures that we will not receive the DUP-ACKs for the packet in the previous stage in Steps (2-1) and (3-1), when we receive two DUP-ACKs in the following 1.3–0.16 s after the retransmission. This is based on characterizing of the retransmission caused by $\text{FACH}\to \text{DCH}$ , and we assume that normal RTT is less than 1 s.

Figure 10

Activity flow of the strategies for non-SYN.

The expected gains from our strategies are as follows:

• (1)

reduction of unnecessary traffic,

(2)

reduction in the harmful effects of calculating the RTO,

(3)

avoidance of unnecessary reduction of cwnd and ssthresh,

(4)

reduction in unnecessary transmission times.

Cost. Timely recovery from the occurrence of packet loss cannot be ensured.

Implementation and Results. To verify our strategies, we implemented them in the kernel. From traffic, completion time, deviation of RTO, and retransmission rate aspects, we conducted four tests to compare with original RFC6298 in the real environment.

Test 1. The 3G gateway established short-lived TCP connections to send data to the server. The size of the data ranged from 1300 B to 27300 B, which generated 1 to 20 TCP packets. We recorded the entire transmission and the RTOs when the TCP connections started with the RRC state transitions.

As Figure 11 shows, regardless of how much data the 3G gate sents, the traffic between RFC6298 and our strategies was virtually the same because only the SYN packets trigger RRC state transitions. However, at the three-way handshake stage, every connection with RFC6298 produced 268 B, which is higher than the traffic of 140 B with our strategies because of the retransmission of SYN and SYN/ACK. After the three-way handshake, the RTO with RFC6298 is set to 3 s, and the RTO with our strategies is only 1 s. Further, Figure 12 shows the completion time of the connections. All the completion times with RFC6298 are larger than the times with our strategies. Further, as the data being sent increase, the gap between them grows from 44 ms to 885 ms. This is due to the fact that the initial cwnd becomes one after the three-way hand shake with RFC6298.

Figure 11

Traffic for RFC6298 and our strategies in Test 1.

Figure 12

Completion time for RFC6298 and our strategies in Test 1.

Test 2. The 3G gateway established long-lived TCP connections. We only recorded the middle term of the connections from the connections in the IDLE state and sent differently sized data so that these data are transmitted.

As Figure 13 shows, when we use RFC6298, the traffic is always twice as much as the traffic with our strategies. As Figure 14 shows, the completion time of the connections with RFC6298 is about one or two RTT (200–400 ms) higher than the time with our strategies. After those data have been transmitted, with RFC6298 if the RTOs are less than 700 ms, the RTOs will be four times as the previous value, and if they are over 700 ms they will double as before. However, with our strategies the RTOs remain because the retransmission timers stop for 2 s and these RTT samples are not used to renew the RTO.

Figure 13

Traffic for RFC6298 and our strategies in Test 2.

Figure 14

Completion time for RFC6298 and our strategies in Test 2.

Test 3. We enabled the timestamp option and recorded the RTT and the change in RTOs in the case where one packet goes through RRC state transition; then the following packets are transmitted normally. The interval time between the first packet and the second packet was 30 s, which made the second packet trigger the RRC state transition. The interval time between the second packet and the third packet was 3 s, which made RRC state transition be done. The interval time between packets after the third packet was 500 ms to make sure that each packet generated an RTT sample.

As Figure 15 shows, with RFC6298, the second packet is retransmitted and receives a high RTT sample, including the duration of RRC transition. Conversely, with our strategies the second packet's RTT sample is not used for the calculation of RTO. Therefore, with RFC6298 the RTOs that are calculated with the high RTT samples deviate far from the RTO with our strategies. This deviation lasts after another 20 normal RTT samples and is just getting small.

Figure 15

RTT and its related RTO in Test 3.

Test 4. During a period of one hour, the 3G gateway established one long-lived TCP connection. On this connection, one packet was sent from the gateway to the server every 5 min. In addition, the 3G gateway also randomly set up 10 short-lived TCP connections from the gateway to the server. Each connection sent 10 packets to the server. The results are shown in Table 5. With our strategies the retransmission rate fell noticeably, especially the SYN/SYN + ACK's retransmission rate.

Table 5

Results of the tests.

	TCP with our strategies	TCP with RFC6298
SYN/SYN + ACK's retransmission rate	16%	43.75%
Long-lived TCP retransmission rate	0%	9.01%
Short-lived TCP retransmission rate	2.05%	5.5%

In summary, a 3G gateway that deploys our strategies for TCP can enhance its transmission. Unnecessary retransmission packets can be avoided and so reduce the traffic during the stages of the three-way handshake and middle term of the connections. cwnd can be maintained to shorten the completion time. The calculation of RTO can be more proper. Overall, our strategies reduce the retransmission rate.

6. Conclusion

In this paper, we first discussed the problems facing 3G gateways in agriculture WSNs. In 3G networks, TCP packets that go through the sudden high delays caused by the RRC state transitions may have to be retransmitted because of timeouts. Following our introduction of necessary background knowledge on retransmission timer and RRC state transitions, we verified the phenomenon of spurious retransmission in 3G networks and presented strategies to solve the problem. The experiments conducted showed that our strategies can improve the performance by reducing the traffic, shortening the completion time, and lowering the retransmission rate.

In future work, we plan to implement our ideal strategies for reducing the high retransmission rate. In addition, we also plan to conduct further research on how to make the WSNs used in agriculture more precise and real-time.