Keywords

1 Introduction

Wireless sensor networks [1] can be described in terms of thousands of small devices responsible of computation, communication, and sensing. These small devices are called MOTE [2]. The MOTEs are deployable in real-time application to protect large area. The sensor attached with the MOTE senses the environmental signals, processor/microcontroller perform computing to identify the events. The communication devices are transceivers, which receive and transmit event information to the base station through multihoping [3]. The packets of event information transmitted in network required certain protocols to reach the destination. There are several routing protocols that exist for WSN. Static routing [4] is preferable in the case of multihop transmission.

The other required protocol is MAC [5] protocol. Energy of MOTE to sense and transmit the information in WSN is a major issue. Various protocols exist for MAC, but till now none of the MAC protocols is suitable for WSN. Still development and research are going on. Other than energy saving protocol, few media access protocol with collision detection and avoidance are used for WSN.

After MAC protocol, the most important protocol is TCP [6], which is required for reliable packet transmission. The successful packet transmission to the base station is very essential. Any serious event can take place, if packet transmission fails. There are many nodes which can transmit event information at the same time. It may cause congestion in network. There are various variants that have been proposed to reduce congestion effects, TCP Tahoe [7–9], TCP Reno [8], TCP Reno with Selective Acknowledgement (SACK) [7, 8], TCP NewReno [10, 11], TCP Westwood [11] TCP Vegas [12], and TCP FACK [13] are examples of proposed end-to-end solutions. These variants are proposed to improve network performance, but still we are facing problems of packet drop and packet loss.

This paper presents a new variant of TCP for wireless sensor network to reduce the effect of congestion in network. The proposed technique is based on utilizing waiting time for packet transmission and adjustment of sending window size according to the packet drop ratio.

There are various researches going on to reduce the effect of congestion and to make reliable communication by implementing transmission control protocol. Few of the research are as follows.

Kumar et al. [14] has proposed a congestion control mechanism for MANET. The author has calculated various parameters to monitor the congestion status and developed routing protocol. The proposed routing protocol with conventional TCP has been implemented and compared by the author. As results shows proposed technique is better.

Sharma et al. [15] has implemented various parameters to identify the non-congestion losses of TCP in MANET. Author has implemented parameters in NS-3 simulator, simulate the communication, and then observe the performance of MANET in different scenarios.

Above literatures shows development of TCP variants for various purposes. This paper presents implementation of protocol to reduce the packet drops in congested network.

Organization of paper: Sect. 2 transmission control protocol, Sect. 3 presents the proposed mechanism, and Sect. 4 presents results of simulation.

2 Transmission Control Protocol

Transmission control protocol (TCP) is known for reliable communication. It is a protocol of transport layer in TCP/IP layers [16]. The size of congestion window either increases or decreases according to the network capacity.

Slow Start: The first step in TCP is slow start. The size of congestion window starts from either 4380 byte or maximum of segment size. The congestion window grows exponentially. After a certain period network get congested and at that time size of congestion window becomes half. At the same time congestion avoidance phase starts.

Congestion avoidance phase: In this phase size of congestion window becomes half and congestion avoidance algorithm executes.

Fast retransmission: In this phase TCP transmits all those packets which are dropped or not acknowledged. After fast retransmission phase again slow start phase starts.

There are various improvements has been done for better performance. The improvements are based on avoiding the congestion and retransmit the packets. There are two demerits of TCP which are not covered by other variants.

The first demerit is waiting of acknowledgement. TCP does not transmit new packet until it gets acknowledgement of previous packet or timeout occurs. There is wastage of time. The second demerit is calculation of congestion window in congestion avoidance phase.

Proposed mechanism of TCP is trying to solve these both issues, described in next section.

3 Proposed Mechanism

The proposed mechanism is divided into two segments. The first segment is based on calculation of retransmission timeout. Sender has to wait until it gets acknowledgement for sent packet. Sender has no option to send packet even it has to send any important information. TCP start a timeout timer when it transmit a packet, and wait for acknowledgement. In the case of loss of acknowledgement in the network, TCP retransmits the packet and double the timeout timer. Reliability of packet transmission is costing enough time waste during communication. The enhance mechanism for data transmission calculates retransmission timeout, so that it can reduce time wastage during retransmission of packets. The round trip time (RTT) and retransmission timer overtime (RTO) can be calculated with following formula:

$$ \begin{aligned} {\texttt{Retrans}}_{{{\texttt{new}}}} & = {\texttt{1}} + ({\texttt{rtt}} - {\texttt{min}}\_{\texttt{rtt}})\,{\texttt{/}} \, ({\texttt{max}}\_{\texttt{rtt}} - {\texttt{min}}\_{\texttt{rtt}}) \\ {\texttt{Reset}}\_{\texttt{RTO}} & = {\texttt{Retrans}}_{{{\texttt{new}}}} * {\texttt{RTO}}_{{{\texttt{old}}}} \\ \end{aligned} $$

The second segment is based on calculation of congestion window according to packet loss in network. Packet loss rate is defined as ratio of total packet sent and total packet received. It can be denoted by P L.

$$ {\texttt{P}}_{{\texttt{L}}} \,{\texttt{ =}}\, {\texttt{total}}\;{\texttt{packet}}\;{\texttt{send}}\,{\texttt{/}}\,{\texttt{total}}\;{\texttt{packet}}\;{\texttt{received}} $$
(1)

The packet loss rate also can be decided by the bit error rate (BER) of wireless link layer and the length (Length) of data frame:

$$ {\texttt{P}}_{{\texttt{L}}} \,{\texttt{=}}\, {\texttt{1}} \,{\texttt{-}}\, ({\texttt{1}} \,{\texttt{-}} \,{\texttt{Bit}}\;{\texttt{Error}}\;{\texttt{Rate}})\;{\texttt{Length}} $$
(2)

Avoidable BER (P loss_min) is 0.4. If BER is greater than P loss_min the size of sending window should be decreased otherwise sending window size can increase. The algorithm is as follows.

4 Results

The implementation and simulation had been done in QualNet 5.0 [17] network simulator with variation in number of nodes and pause time. Following graphs show the output of simulation after implementation of proposed protocol. The new algorithm is named as RTCP. The result of RTCP is compared with result of TCP RENO, TCP SACK, and TCP TAHOE.

Figure 1a shows the throughput of TCP variants (y-axis) with variation in number of nodes (x-axis) in network. Number of nodes indicates the traffic in network. It can be observed that throughput of RTCP (proposed routing protocol) is similar to TCP Tahoe, but it is better when number of nodes are 10.

Fig. 1
figure 1

Variation in number of nodes

Full size image

Figure 1b shows the signal received with error by receiver (y-axis) with variation in number of nodes (x-axis) in network. It can be observed that RTCP (proposed routing protocol) is having less number of signals with error than other variants.

Figure 1c shows the total packet loss by receiver (y-axis) with variation in number of nodes (x-axis) in network. It can be observed that RTCP (proposed routing protocol) has lost less number of packets than other TCP variants, even in the case of heavy traffic.

Figure 1d shows the total byte received by receiver (y-axis) with variation in number of nodes (x-axis) in network. It can be observed that RTCP (proposed routing protocol) has received maximum bytes. The performance of RTCP is similar to TCP Tahoe.

Figure 2a shows the throughput analysis (y-axis) with variation in pause time (x-axis) in network. It can be observed that throughput of RTCP (proposed routing protocol) is better than other TCP variants.

Fig. 2
figure 2

Variation in pause time

Full size image

Figure 2b shows total byte received by receiver (y-axis) with variation in pause time (x-axis) in network. It can be observed that RTCP (proposed routing protocol) has received more number of bytes than other TCP variants.

Figure 2c shows total packet loss by receiver (y-axis) with variation in pause time (x-axis) in network. It can be observed that RTCP (proposed routing protocol) has dropped less numbers of packets than other TCP variants.

Figure 2d shows total signals received with error by receiver (y-axis) with variation in pause time (x-axis) in network. It can be observed that RTCP (proposed routing protocol) has received less numbers signal with error than other TCP variants.

According to results, it can be observed that in most of the cases either in dense network or variation in pause time, the performance of RTCP is better than other TCP variants. The simulation result shows that RTCP is more reliable and can be used in sensitive networks.

5 Conclusion

Communication in large network is very complex, due to congestion in network. For a reliable and fast packet transmission, this paper presents a transmission algorithm. The proposed algorithm is based on utilizing time of packet retransmission and also on resizing the sending window according to the network capacity. The network capacity has been measured according to the number of packet drops. The mechanism was implemented on QualNet 5.0. According to the simulation results the proposed algorithm (RTCP) is performing better than other TCP variants. RTCP is more reliable, so it can be used in most sensitive places, where real time event monitoring is required.