Reliable Transport with Memory Consideration in Wireless Sensor Networks

Transcription

1 Reliable Transport with Memory Consideration in Wireless Sensor Networks Hongchao Zhou 1, Xiaohong Guan 1,2, Chengjie Wu 1 1 Department of Automation and TNLIST Lab, Tsinghua University, Beijing, China. zhouhc06@mails.thu.edu.cn 2 SKLMS Lab and MOE KLINNS Lab, Systems Engineering Institute, Xian Jiaotong University, Xian, China. xhguan@mail.thu.edu.cn Abstract Wireless sensor networks are often composed of resource-constrained sensor nodes with limited memory space, computational capacity and communication range. The links in WSN are often lossy and unreliable. In order to make fluent and reliable data transport on memory-constrained sensor nodes, we propose a new transport layer protocol Reliable Transport with Memory Consideration(RTMC), which provides both hop-by-hop retransmission and congestion control. We have implemented RTMC on MICA2 with only 4K bytes RAM. Experiment, analysis and simulation results show that RTMC can use channel resource effectively and enable all of the segments to be received by the sink with low transport time and low memory cost. I. INTRODUCTION Wireless sensor networks (WSN) consist of many resourceconstrained sensor nodes with limited computational ability, communication distance and memory space. Recently, the availability of low-cost hardware such as CMOS cameras and microphones enables sensor nodes to capture images or audio from environment, and increases the requirement of reliable file transport in these resource-constrained networks [2]. The files transmitted should be divided into multiple segments since long packet length causes high packet error rate. To make reliable transport with high speed in WSN is still a challenging task. First, the links in WSN are unreliable and the transmissions from different nodes may also collide with each other, causing packets loss in transmission in an unpredictable manner. Second, the memory of sensor nodes are limited so that it is very easy to overflow and cause more packets loss. TCP is widely used to provide end-to-end reliability and congestion control in Internet. However, it cannot be directly used in multi-segment transport in WSN. There are two major techniques used in TCP: One is end-to-end retransmission, which is used to reduce packet loss. But it is not appropriate in wireless systems with high packet-loss rate, where hop-byhop retransmission is a better choice to use wireless channel more effectively [7]. Another is end-to-end congestion control, which may have a tardy response and cannot adapt to the rapid change of channel capacity in WSN. Currently, several transport layer protocols are proposed for WSN. Reliable Multi-Segment Transport (RMST) [3] has shown the importance of hop-by-hop packet recovery in sensor networks. RMST works on two modes of operation: caching and non-caching. In caching mode, each caching node on the path detects loss based on a watchdog timer. Reliable Bursty Convergecast (RBC) [5] designs a window-less block acknowledgement scheme that guarantees continuous packet forwarding and replicates the acknowledgement for a packet. Although both RMST and RBC provide hop-by-hop retransmission in WSN, they cannot work well on memoryconstrained sensor nodes due to buffer overflow, which may cause more packets loss. As an addition, several congestion control mechanisms can work together with these these transport layer protocols. However, most of the congestion control mechanisms overlook the possibility that the control messages may be lost due to unreliable links or congestions, therefore their function are weakened. In order to make reliable and rapid transport on memoryconstrained sensor nodes, we propose a new transport layer protocol Reliable Transport with Memory Consideration (RTMC), inspired from pipe-flow. First of all, RMTC provides hop-by-hop retransmission to make sure all of the segments can be received by the sink with 100% reliability. Second, RTMC does not use rate adjustment to control congestion although it is widely used in most of the congestion control protocols. In the wireless sensor networks with lossy links and rapid changing traffics, the method of rate adjustment cannot adapt of the rapid change of the traffic and it may also be affected by the loss of the control messages. In RTMC, memory information is included in the head of the packers and exchanged between neighbors, by this way it can prevent memory overflow and enable it to work well on memoryconstrained sensor nodes. We have implemented RTMC on MICA2, the experiment results show that it can obtain 100% reliability for each segment if the links are not broken. Moreover, it can make good use of channel capacity to maximize the throughput and reduce the transport time. We also have a simulation to compare the performance of RTMC and another transport layer protocol SEA which is also based on hop-by-hop retransmission [5]. Comparing with SEA, RTMC is more energy-effective, and has less memory cost and less transport time. The remainder of this paper is organized as follows. In Section II, we present the detailed design of RTMC. We /08/$ IEEE 2819

2 Fig. 1. An illustration of pipe-flow WHILE node_state==busy IF haven t received any response from next hop send Initiation Packet; ELSE IF local_free==bl send Requiring Packet; ELSE IF there are some unmarked segments s=the unmarked segment with minimal id; IF next_free>0 send Data Packet for s; mark s; next_free=next_free-1; delay(); present the experiment results in Section III. Section IV gives some analysis and simulation results about the performance of RTMC, followed by the concluding remarks. II. RELIABLE TRANSPORT WITH MEMORY CONSIDERATION We consider sensor networks in which each node has low computational ability, limited memory space and short communication distance. All of the nodes are pre-configured with an unique id. The sensor nodes and base station communicate on the same frequency and employ either a TDMA or CSMA/CA Medium Access Control (MAC) protocol. Multisegment data is transmitted from the source to the base station via bidirectional multi-hop wireless links. RTMC is proposed to make fluent and reliable data transport on the sensor nodes with limited memory, which is inspired from the pipe-flow as illustrated in Fig. 1. In this figure, liquid can flow as long as the lower container is not full, by which the flux can be maximized. We can also import this idea into reliable multi-segment transport, where we treat the highest big container as the source, the lowest big container as the base station, small containers as the relay nodes whose capacities can be treated as the memory space. Similar to pipe-flow, in RTMC each node tries to send packets to its next relay node unless the memory of its next relay node is full. In this way, the source can dynamically adjust the transmission rate and maximize the throughput. In this section, we mainly discuss the implement of RTMC on the relay nodes. A. Local Variables and Packets In order to implement hop-by-hop retransmission in RTMC, each node is allocated some memory (buffer) to store a few segments, where the total number of the segments can be stored is Buffer Length (BL). The segments stored in the buffer are the ones which is received but not confirmed by the next relay node. There are several local variables in the current node: Fig. 2. Pseudo-code of of sending packets of RTMC node state indicates whether the current node is transporting files local free indicates how many more segments can be stored in the current node next free indicates how many segments can be send out without receiving any acknowledge from the next relay node received list a queue with length BL, records the id of the recent received segments There are four kinds of packets in RTMC, including Initiation Packet, Data Packet, Requiring Packet, and End Packet. Initiation Packet is used to ask the next hop node to join into the transport. Data Packet contains one segment in each packet, is the biggest packet of all. Requiring Packet is used to ask its previous-hop node to send packets when the current node s memory is empty. When all the segments are sent out, the source uses End Packet to tell all the intermediate nodes that this transport is finished. All of the four kinds of packets include the variables next free and received list about the sender. B. Algorithm Description In RTMC, there are three steps to transmit multi-segment data from the source to the base station, including create pipe, pipe transport, and remove pipe. In the first step create pipe, Initiation Packet is used to ask nodes to join into this transport (creating a virtual pipe). If one node joins into this transport, it allocates some memory to store received segments (as mentioned above). After this process, a virtual pipe is created and multi-segment data can be transmitted through this pipe. In the last step remove pipe, End Packet is used to tell the next hope that the transport is finished. If one node receives End Packet and its buffer is empty, it can release the memory and initialize all the parameters. Then the virtual pipe is removed and the transport is finished for the current node. 2820

3 IF node_state==free IF P is Initiation Packet from previous hop node_state=busy; allocate memory; initial parameters; IF P is Requesting Packet from next hop send End Packet back; ELSE IF P is Data Packet from previous hop IF P is received for the first time Fig. 4. store the segment; local_free=local_free-1; segment.id -> receive_list; IF P is a Packet from next hope release the packets received by the next hop; local_free=bl-number of stored segments; next_free=local_free in the packet; IF the current node has received End Packet IF local_free==bl node_state=free; Fig. 5. Traffic model based on random competition for different segments Traffic model based on random competition for different streams Fig. 3. Pseudo-code of RTMC when receiving packets About the second step pipe transport, we mainly discuss the process of sending packets and receiving packets. Fig.2 is the pseudo-code of sending packets. In order to make fluent data delivery, every node can transmit at most next free different Data Packets to its next-hop node continuously without any acknowledgements, by this way the number of the stored packets in its next-hop node will never go more than BL(overflow). In each period, if there are some unmarked segments stored in the buffer, the current node selects the unmarked segment with the minimal id to send (the marked segments are the ones which is send out but not confirmed by the next-hop node). After sending out a Data Packet, the current node should set next free as next free 1 and mark the segment sent out. If next free =0, the current node should not send out Data Packets. Fig.3 is the pseudo-code of receiving a packet. Here, we denote the coming packet as P. When one node receives a packet, it has two tasks to do. First, if the coming packet is a data packet from its previous hop node, it should check whether this packet has been received before. If this packet has not been received before, it stores this packet in its buffer, and update the variables local free and received list. Second, if the coming packet is a packet from its next hop (snoop the channel), it should release the stored packets corresponding to the received list in the packet and remove all the marks. It should also set the local next free as the local free in the coming packet, and update the local local free at the same time. Since it is impossible for the current node to send more than BL nodes to its next-hop node without any acknowledgements, the length BL is enough for received list. We notice that every packet is possible to be lost in communication due to collisions or lossy links, no matter which kind it is. It is possible to happen that the next free of the current node is zero while its next-hop node s buffer is empty. In this case, its next-hop node sends out Requiring Packets periodically until receiving packets from it. Following the process above, RTMC can make fluent packet delivery. Comparing with transmission rate adjustment, the congestion control mechanism in RMTC will not influenced by the loss of the control messages and can use the channel resources more effectively. C. Traffic Models In the most of existing works of wireless sensor network, the segments from different streams always compete to occupy the limited channel resource randomly, as illustrated in Fig.4 in which there are two sources start to send multi-segment files at the same time and segments from different sources always occupy the limited channel resource alternately. However, it is not effective for file transport since the channel capacity around the base station is always limited. If both of the streams as illustrated in Fig.4 share the limited channel resource at the same time, the time delay for both of the files will be double. But if one of them waits until another file finishes its delivery, the situation will be better, that only one file s delay time is double while another s delay time keeps changeless, as illustrated in Fig.5. Both of the traffic models can work with our proposed RTMC protocol. However, the former one costs 2821

4 Time (s) BL=1 BL=2 40 BL= Sequence Number Fig. 6. Experiment Scenario Fig. 7. Receiving time for each segment. * is for the Initiation Packets and End Packets and. is for the Data Packets. 120 more memory space and higher time delay with RTMC, we suggest to use the latter model for file delivery. III. EXPERIMENT In our experiment, we use MICA2 as our testbed. MICA2 [9] is a kind of sensor node produced by Crossbow. The processor of MICA2 is based on the Atmel ATmega 128L, which is a low-power microcontroller with 4K bytes RAM. The default length of packets for MICA2 is bytes, where the former 20 bytes are for preamble and sync bytes, the latter 36 bytes are data bytes. Here, we extend these 36 bytes to 120 bytes, in which 20 bytes are used for header and 100 bytes are used for data. The Effective Data Rate of MICA2 is 19.2Kbaud. Fig.6 is the experiment scenario. Nodes A,B,C,D,E,F are MICA2 nodes, deployed in a line, and the distance between two neighbor nodes is 4 meters. Assuming node A is the source node and node F is the base station. In order to better monitor the behavior of transmission, both A and F is connected to computers. In the experiment, we transmitted an image with 10K bytes from A to F. We have divided the image into 100 segments with 100 bytes for each segment. All of the segments needs to be transmitted from the source A to the sink F via multiple hops that retransmitted by B,C,D,E. In the experiment, after the sending of one Data Packet, there is a 200ms delay to send another Data Packet. In our experiments, all of the segments in an image can be received by the base station. In Fig.7, we set the Buffer Length (BL) for each node as 1, 2, or 5. When BL equals to 1, the time to transport the image is the longest of all. However, the difference between BL equals to 2 and 5 is not large, perhaps that because the packet loss rate is not high in our scenario. Another phenomena is that, when BL is larger than 1, the received segment order may change a little. But, this small disarrangement has little influence on the image transport and the decoding process. Time (s) Received by Base Station Sended from Source Sequence Number Fig. 8. An illustration of Congestion Control.The green points are for the Data Packets sent by the source, and the red points are for the DATA Packets received by the base station. In Fig.8, we still use the experiment scenario described above and set BL as 4, but 20 seconds later we turn on a new node which is close to node E and sends out packets continuously. In this case, we can treat it as a kind of congestion. Fig.8 shows the source can dynamically change the transmission rate and adapt to the traffic change in the network as well as congestion. Although some packets are lost due to the collisions, all of the segments can be received by the sink, even the congestion happened. IV. SIMULATION AND COMPARISON A. Impact of Buffer Length Buffer Length (BL) is an important parameter in RTMC. As our experiment shows, if BL is very small, there are will be many Requesting Packets sent out in the network, and the time to transmit a file will also be prolonged. If BL is too large, there will be more redundancy in the header of the packets and therefore increase the overhead to transmit a file. However, BL should be selected according to the quality of the links. If the 2822

5 p=0.5 p=0.6 p=0.7 p= RTMC SEA Transport time (T) 1500 Transport time (T) Path length packet success rate p Fig. 9. Relations between the transport time of all the segments and the path length, where BL=4 Fig. 11. The transport time for different packet success rate. Transport time (T) BL=4 BL=5 BL=6 BL=7 packets transmitted RTMC SEA Path length Fig. 10. Relations between the transport time of all the segments and the path length, where p=0.5 Fig. 12. rate packet success rate p The number of the transmitted packets for different packet success quality of the links is good and just a few packets are lost, the value BL can be a smaller integer. But, if the quality of the links is not reliable, the value of BL should be a larger integer. In Fig.9, we simulated RTMC with different path length and different packet success rate under TDMA. There are n nodes deployed one by one in a line (path length= n 1), the first node is the source and the last node is the base station. In each period T, every node can send out at most one packet. The source tries to transmit a file with 100 segments to the base station. Assuming the packet success rate between each two neighbors is constant p. We found that when BL matches the packet success rate(such as p=0.8), the transport time changes just a little as the path length increases. From this aspect, RTMC can make uniform use of channel resources and reduce the transport time. But when BL does not match the packet success rate(such as p=0.5), the transport time may change greatly as the path length increases. At this time, we should increase the value of BL as illustrated in Fig.10. This figure shows that the value of BL should increase as the packet success rate decreases. B. Comparison There are two hop-by-hop packet recovery mechanisms in sensor networks: synchronous explicit ack and stop-and-wait implicit ack [5]. In synchronous explicit ack (SEA), a receiver switches to transmit-mode after receiving a packet, and sends back the acknowledge. If the sender does not receive the corresponding ack in a constant time, it retransmits the packet immediately. In stop-and-wait implicit ack (SWIA), the packets forwarded by the receiver can act as the acknowledgement to the sender. So, the sender should snoops the channel to check whether the packet is forwarded within a certain time, otherwise, the sender retransmits the packet to the next hop. In both SEA and SWIA, if the acknowledgement is not successfully received by the sender or the acknowledgement is received after the threshold time is expired, the sender retransmits the packet. So, the retransmission probability is about 1 P data P ack where P data is the probability of successful transmission of a data packet, and P ack is the probability of receiving an acknowledgement. 2823

6 packets transmitted RTMC data packet loss rate near the sink p Fig. 13. The number of the transmitted packets for different packet success rate near the sink. In RTMC, if one data packet is successful received by the receiver, the sender will retransmit the packet in a much smaller probability, so the retransmission probability in RTMC is about 1 P data which is smaller than that in SEA or SWIA. We have a simulation to compare RTMC with SEA under TDMA. In our simulation 5 nodes are deployed one by one in a line, and packet success rate p is a constant. In RTMC, each node can send out at most one packet in each period T, and BL =5.InSEA,inaperiodT each node can send one packet and one acknowledgement. Assuming the memory of each relay node can store no more than 10 segments and the packet success rate of acknowledgements is also p in SEA. Fig.11 shows that the transport time in RTMC is less than that in SEA if the packet success rate is not closed to 1. Fig.12 shows that the number of the transmitted packets in RTMC is lower than that in SEA (acknowledgements are not accounted), which indicates that RTMC can effectively reduce the redundant communications. This conclusion is also consistent with our theoretical analysis. From these figures, we find that the RTMC has significant advantage if the packet success rate is not high enough. In Fig.13, the packet success rate of the link near the sink p varies from 0.9 to 0.1, and one of the others keeps unchanged, as p =0.9. Congestions must be happened when p is lower than a certain value. Fig.13 shows that in SEA there are more packets lost if congestions happened so that more packets need to be transmitted. Comparing with SEA, RTMC works better in this situation due to its congestion control mechanism. V. CONCLUSION Wireless sensor networks (WSN) consist of many memoryconstrained sensor nodes, and the links in WSN are unreliable. Both hop-by-hop retransmission and congestion control mechanism are necessary for multi-segment data transport in WSN with lossy links and limited memory. However, there are few protocols provide both of the mechanisms. Inspired from pipe-flow, we propose a transport layer protocol Reliable Transport with Memory Consideration (RTMC), aim to deliver multi-segment data to the sink with high reliability and low memory cost. Different from existing protocols, RTMC provides both hop-by-hop retransmission and congestion control mechanism. Based on them, we address to make good use of channel resource and reduce transport time. We have implemented RTMC on MICA2 which has only 4K bytes RAM, the experimental results show that RTMC can work well on low-memory sensor nodes, it can provide 100% reliability and effective channel utilization. Comparing with SEA, RTMC has better performance in many aspects, including energy cost, transport time, memory cost, etc. ACKNOWLEDGMENT The research presented in this paper is supported in part by the National Natural Science Foundation ( , ), 863 High Tech Development Plan (2007AA01Z475, 2007AA04Z154, 2007AA01Z480, 2007AA01Z464) and 111 International Collaboration Program, of China. REFERENCES [1] G. Anastasi, E. Borgia, M. Conti, E. Gregori, A. Passarella Understanding the real behavior of Mote and ad hoc networks: an experimental approach. Pervasive and Mobile Computing, volume 1, pages , July, [2] I.F. Akyildiz, T. Melodia, K.R. Chowdhury A survey on wireless multimedia sensor networks. Computer Networks, volume 51, pages , March, [3] F. Stann, J. Heidemann. RMST: Reliable Data Transport in Sensor Networks. IEEE International Workshop on Sensor Net Protocols and Applications (SNPA), pages , [4] Y. Sankarasubramaniam, O.B. Akan, I.F. Akyildiz. ESRT: Event-tosink reliable transport in wireless sensor networks. Proceedings of the International Symposium on Mobile Ad Hoc Networking and Computing (MobiHoc), pages , [5] H. Zhang, A. Arora, Y. Choi, M.G. Gouda. Reliable bursty convergecast in wireless sensor networks. Proceedings of the International Symposium on Mobile Ad Hoc Networking and Computing (MobiHoc), pages , [6] Y.G. Iyer, S. Gandham, S. Venkatesan A generic transport layer protocol for wireless sensor networks. International Conference on Computer Communications and Networks, ICCCN, pages , [7] S. Kim, R. Fonseca, D. Culler. Reliable transfer on wireless sensor networks. IEEE SECON 2004, pages , [8] C. Wang, K. Sohraby, B. Li, M. Daneshmand, Y. Hu A survey of transport protocols for wireless sensor networks. Computer Networks, volume 20, pages 34-40, May/June, [9] Crossbow MICA2 Mote Specifications ( xbow.com). [10] C. Wan, S.B. Eisenman, A.T. Campbell. CODA: Congestion detection and avoidance in sensor networks. Proceedings of the First International Conference on Embedded Networked Sensor Systems, SenSys 03, pages , [11] B. Hull, K. Jamieson, H. Balakrishnan. Mitigating congestion in wireless sensor networks Proceedings of the Second International Conference on Embedded Networked Sensor Systems, SenSys 04, pages , [12] C.T. Ee, R. Bajcsy Congestion control and fairness for many-to-one routing in sensor networks. Proceedings of the Second International Conference on Embedded Networked Sensor Systems, SenSys 04, pages , [13] C. Wang, K. Sohraby, V. Lawrence, B. Li and Y. Hu Priority-based congestion control in wireless sensor networks. IEEE International Conference on Sensor Networks, Ubiquitous, and Trustworthy Computing, pages 22-29, [14] I.F. Akyildiz, W. Su, Y. Sankarasubramaniam, and Erdal A Survey on Sensor Networks. IEEE Communications Magazine, pages , August