Ad Hoc Networks 67 (2017) 40 52 Contents lists available at ScienceDirect Ad Hoc Networks journal homepage: www.elsevier.com/locate/adhoc WA-MAC: A weather adaptive MAC protocol in survivability-heterogeneous wireless sensor networks Jie Tian a, Yi Wang b, Xiaoyuan Liang a,, Guiling Wang a, Yujun Zhang b a Department of Computer Science, New Jersey Institute of Technology, Newark, USA b Institute of Computing Technology, Chinese Academy of Sciences, Beijing, PR China a r t i c l e i n f o a b s t r a c t Article history: Received 14 November 2016 Revised 23 September 2017 Accepted 4 October 2017 Available online 5 October 2017 Keywords: Survivability-heterogeneous wireless sensor networks Medium access control Weather adaptivity Relative delay bound Nowadays, sensor nodes are deployed to different environments to perform applications. Harsh environments such as rain or snow could damage the sensor nodes permanently. In this paper, a novel survivability-heterogeneous wireless sensor network composed of sensor nodes that is resistant to environmental detriments is designed. We for the first time study the medium access control protocol in such heterogeneous wireless sensor networks for data transmission under different weather conditions. We present a new Weather Adaptive receiver-initiated MAC protocol, called WA-MAC. WA-MAC can largely reduce idle listening time to save energy consumption for sensors during data transmission and provide a relative delay bound data delivery service by establishing appropriate rendezvous time between senders and receivers. Besides, by adopting weather forecast information, WA-MAC adjusts the data transmission process between different types of sensors to avoid packets being lost or delayed. Simulation results in ns-2 simulator show that WA-MAC can achieve the required relative delay bound, a low duty cycle and a high packet delivery ratio in the network, which outperforms other existing MAC protocols. 2017 Elsevier B.V. All rights reserved. 1. Introduction Wireless sensor networks are expected to applied to many outdoor applications, such as habitat monitoring [1], environment control [2] and solar radiation monitoring [3]. Outdoor environments are often harsh and detrimental to unprotected tiny lowcost electronic devices, such as sensor nodes. For example, after rain, sensor nodes could stop working and the precious generated data could be lost [4,5]. The environmental detriments could have a huge negative impact on the dependability of sensor networks and cause the failure of the entire network [6,7]. However, currently, there is few research works addressing such a problem in the community. To address the above problem, a new kind of heterogeneous wireless sensor networks was proposed in [8,9], called Survivability-Heterogeneous Wireless Sensor Networks (SHWSN). A SHWSN is composed of two types of sensor nodes: One type of sensor nodes are equipped with additional protections to make them for example water-proof [10]. Such sensor nodes are called robust sensors. Another type of sensor nodes don t have such ro- This work is supported by the National Science Foundation grants NSF-1128369. Corresponding author. E-mail addresses: jt66@njit.edu (J. Tian), wangyi2012@ict.ac.cn (Y. Wang), xl367@njit.edu (X. Liang), gwang@njit.edu (G. Wang), zhmj@ict.ac.cn (Y. Zhang). bust features and are called regular sensors. By deploying both robust sensors and regular sensors, a network would be able to sustain in harsh environments, like rain, snow or high temperature, and provide better performance than a network just composed of regular sensors in many applications [8,9]. Meanwhile, the network cost is maintained at a reasonable level by deploying both kinds of sensors, considering robust sensors are more expensive than regular sensors. The robust feature to the environments provided by robust sensors is a new kind of heterogeneities in wireless sensor networks. In the applications, sensors have to work under both normal weather and harsh weather. Considering robust sensors are usually much pricier than regular sensors [11], The network cost became very high if all sensors were robust sensors. Thus we propose a network composed of both regular and robust sensors to balance the tradeoff between cost and field coverage. Under harsh weather, robust sensors can work to provide basic sensing, which is enough to provide uninterrupted sensing in outdoor applications. It is significantly different from the heterogeneity being studied in the existing works [12 15] in terms of computing capacity, energy, communication range, and sensing range. None of them considers the heterogeneity in the capabilities to withstand environmental detriments, which cannot be neglected in outdoor wireless sensor networks. This paper focuses on designing a new Weather Adaptive MAC protocol for such kind of heterogeneous sensor networks. Many https://doi.org/10.1016/j.adhoc.2017.10.005 1570-8705/ 2017 Elsevier B.V. All rights reserved.
J. Tian et al. / Ad Hoc Networks 67 (2017) 40 52 41 MAC protocols aim to reduce the idle listening time of sensors to conserve energy. Among them, receiver-initiated MAC protocols gain popularity recently, such as A-MAC [16], RI-MAC [17], PW- MAC [18] and CyMAC [19], since they are more energy efficient than sender-initiated MAC protocols [20]. In a receiver-initiated MAC protocol, both sender and receiver agree on a wake-up time; at the wake-up time, the receiver notifies the sender that it is ready to receive; the sender then starts data transmission. At all the other time, they can be off-duty. However, no previous work considers environmental detriments that will disable regular sensors from working when there is rain. Rain will be used to represent the harsh weather in the remainder of the paper. The rain could damage a sensor and cause cached data in it to be lost. Moreover, the harsh weather can also cause the data delayed for a long time, since data cannot be sent out immediately. This additional dimension of complexity incurred by weather prevents previous works from being directly applied to our scenario. In this paper, we propose a novel Weather Adaptive receiverinitiated MAC protocol, WA-MAC. We leverage the widely available weather forecast information to schedule sensors to avoid data loss and delayed. It provides rain information in coming time slots. Previous work [21] shows that even by simply adopting an inaccurate weather forecast in the scheduling, the network performance can be improved significantly. WA-MAC can work effectively and efficiently under different weather conditions, including sunny weather and rainy weather. Moreover, WA-MAC targets on providing relative delay bound services for data delivery [19,22], which is a more meaningful evaluation metric in the proposed scenario and has been widely employed recently in optimizing MAC protocols. The relative delay ratio is defined as the data delivery delay to the average data arrival interval. To achieve the goal, we design a relative delay bound scheduling algorithm to calculate the rendezvous time between senders and receivers. We formally prove that the scheduling algorithm can achieve the required relative delay bound on average statistically. During the sunny weather, the algorithm directs each node to send and receive packets. Furthermore, WA-MAC can also avoid packets being lost and delayed by adjusting wake-up time between regular sensor nodes and robust sensor nodes before and after the rain. Extensive simulations have demonstrated that WA-MAC works effectively and efficiently under both sunny weather and rainy weather. To summarize, our contributions in this paper are: We for the first time study the medium access control problem in the survivability-heterogeneous WSN composed of sensors having different capabilities in withstanding harsh environment. We design a novel weather adaptive receiver-initiated MAC protocol, WA-MAC, for the proposed survivability-heterogeneous WSN. WA-MAC can simultaneously achieve a low duty cycle, a high packet delivery ratio and a relative delay bound. We formally prove that our designed scheduling algorithm can achieve the required relative delay bound on average statistically under different weather conditions. The scheduling algorithm and the theoretical result can also be borrowed in other types of sensor networks. The remainder of the paper is organized as follows. We present the assumptions and background in Section 2 and Section 3, respectively. Section 4 describes the design of WA-MAC. Section 5 reports simulation results. Related work is discussed in Section 6. Finally, we conclude the paper in Section 7. 2. Assumptions We make the following assumptions in the paper: Fig. 1. WA-MAC general procedure. The network we study is composed of two types of sensor nodes: robust sensors and regular sensors. Robust sensors can work under both sunny period and rainy period. Regular sensors can only function well under sunny period. When there is rain, the regular sensors will be damaged and the data in it will be lost. But regular sensors have a probability to survive after rain [23,24], get dried and come back to work if they are not on under rain and thus not damaged permanently [25]. Future weather information is assumed to be available to the network. Current weather forecast techniques are mature and can provide accurate weather forecast information of a given area [26,27] in the near short future. Specifically, a Minitab s report shows that the p-value for the weather accuracy in the next-day prediction is 0.00 [28], which means it is very reliable. The information can be broadcast from a station [29]. The station obtains the latest weather information and simply broadcasts it to the network by flooding at a certain time interval, which can be integrated within any dissemination protocol [30]. All sensors wake up at the broadcasting time to receive the weather forecast. Since the proposed MAC protocol needs only reliable weather information of the coming hundreds of seconds, the weather forecast is assumed to be 100% accurate [8]. In the network, any two neighboring nodes which can be MAC layer sender and receiver are assumed to be synchronized. The synchronization can be achieved by many mature techniques with low overheads [31 33]. Each sensor generates data packets independently when it is sensing. The generation process follows a Poisson process [34 36]. This is a widely adopted data generation process in WSN. The data packets will be transferred to the sink or other sensor nodes depending on the application running in the network. 3. Background on receiver-initiated MAC protocol and relative delay ratio In a receiver-initiated MAC protocol, any sender and receiver pair has a mutual agreement on a wake-up time. The receiver is in sleep mode until that wake-up time. When the receiver wakes up, the sender must already be awake. The receiver then sends a beacon message to notify the sender that it is ready to receive the packet. The sender sends the data packet to the receiver if there is any cached in the sender. The packets cached in the sender can be self-generated or received from other sensor nodes. After the receiver receives a packet, it sends an ACK message back to the sender. Fig. 1 illustrates the receiver-initiated MAC protocols: Sender A receives a packet at time t 1 and needs to send it to receiver B. t 2 is their mutually-agreed wake-up time. At time t 2, B
42 J. Tian et al. / Ad Hoc Networks 67 (2017) 40 52 wakes up and sends a beacon message to notify A that it is ready. Then sender A transmits the data immediately. When receiver B successfully receives the data, it sends an ACK message back to A. Note that the key issue in receiver-based MAC protocols is how the sender and receiver pair determines their mutually-agreed wakeup time, which is generally called rendezvous time. Relative delay bound guarantee is a data delivery service [19,22]. It is an important evaluation metric for many receiverinitiated MAC protocols. The relative delay ratio is defined as the data delivery delay to the average data arrival interval in each sensor node. For example, if on average, a sensor node receives a data packet every 10 s and the delivery delay of each data packet is 2 s on average, then the relative delivery delay ratio is 20%. The relative delay bound is more meaningful than an absolute delay bound in the proposed heterogeneous wireless sensor networks, since the absolute delay is largely affected by duration of rainy period and cannot be always satisfied. If the rain period is very long, the delivery delay is very close to the rain duration, which cannot be optimized by MAC scheduling. In this paper, our MAC protocol is proposed to optimize the relative delay ratio. It can also improve the performance regarding to other metrics, such as delivery delay, duty cycle and packet delivery ratio, which is shown in the evaluation. Providing relative delay bound is the key objective of this paper. 4. Weather adaptive MAC protocol In this paper, we propose a Weather Adaptive MAC protocol, WA-MAC, which is designed for survivability-heterogeneous wireless sensor networks to provide relative delay bound guaranteed packet delivery service. WA-MAC is a receiver-initiated MAC protocol and follows the general procedure presented in Fig. 1. Different with other receiver-initiated MAC protocols, the senders in WA-MAC dynamically calculate a rendezvous interval based on the incoming traffic and weather forecast. As shown in Fig. 1, the interval is added to the current wake-up time to render the next wake-up time. The calculated rendezvous interval is piggybacked in the data packet transmitted from the sender to the receiver. When there is no data to send, the rendezvous interval remains the same and the receiver goes to sleep after a short interval. In this way, the sender and the receiver have an agreement on when to wake up. The rendezvous interval is calculated such that the required relative delay is guaranteed on average for packet delivery considering the traffic condition. When the traffic becomes light, the rendezvous interval is enlarged, such that both sender and receiver can be off-duty for a longer time to reduce energy consumption. When the traffic turns heavier, they wake up more often to perform data transmission with a shorter rendezvous interval. Another unique feature of WA-MAC is that it provides an adaptive packet delivery service to weather conditions. It checks the incoming weather to adjust the transmission strategy to achieve the required relative delay and avoid packets being lost considering under rain, regular sensors cannot work properly. Generally, when rain is expected to come, WA-MAC adjusts rendezvous interval time so all packets in regular sensors can be transmitted to robust sensors before the rain to avoid packets delay and loss. When it rains, robust sensors are only scheduled to perform data transmission. When rain stops, WA-MAC adjusts the rendezvous interval again to ensure that enough time is reserved for data cached in robust sensors to be transmitted to regular sensors. In the following, we first present how the rendezvous interval is calculated such that relative delay bound is guaranteed. Then we discuss the weather adaptive feature of WA-MAC. After that, we discuss how to deal with transmission failure and collision. 4.1. Calculating rendezvous time and relative delay bound guarantee The objective of WA-MAC is to simultaneously conserve energy consumption and provide relative delay guarantee. To save energy, the rendezvous interval should be prolonged as much as possible, but to provide relative delay guarantee, it cannot be too long. Considering packets arrive randomly, and providing 100% delay guarantee is very energy-consuming, WA-MAC focuses on providing the required relative delay on average in each sensor node. Thus, WA- MAC calculates a longest rendezvous interval between two data transmissions for the sender and the receiver based on the packet arrival process and historical packet arrival observations such that the expected value of relative delay for all packets arriving in this interval satisfies the required bound. It means that only a few of packets incur high delay with a small probability and most of packets experience low delay with a high probability. Thus the mean value of the delivery delay can be bounded under the requirement. In the following, the calculation of rendezvous time is discussed in details. 4.1.1. Rendezvous time calculation In WA-MAC, a sender calculates the rendezvous time for next time packet transmission between it and a receiver. Considering the packet generation process at each sensor follows a Poisson process, it can be proved that the packet arrival process at each sensor node always follows a Poisson process [35,36]. Then the rendezvous interval is calculated by Eq. (1), where is the rate of the packet arrival process at the sender and r is the relative delay ratio. In this way, the expected mean relative delivery delay is bounded by the required value. Lemma 4.1 formally states the conclusion and the proof is followed. Lemma 4.1. By setting the rendezvous interval 2 r 2 ln (r + 1) + ln (r + 1) x r =, (1) the required average relative delivery delay bound can be satisfied. Proof of Lemma 4.1. Suppose x r is the rendezvous interval. The packet arrival process at each node follows a Poisson process with parameter as mentioned before. Then with a given x r, the probability that a packet arriving between (0, x r ] in a node is p = 1 e x r, (2) which follows an exponential distribution. Then the probability that a packet X arrives between (0, x ], where x (0, x r ], on conditioning X x r is: P r(0 < X x X x r ) = P r(0 < X x, X x r ) P r(x x r ) = P r(0 < X x ) P r(x x r ) = 1 e x. (3) 1 e x r Let F ( x ) denote the new CDF with x (0, x r ], then we have F (x) = 1 e x, (4) 1 e x r and the corresponding pdf is x e f (x) =. (5) 1 e x r Then we calculate the expected delay of packet X when it is transmitted at time x r, which is E[ x r x ]. We need to show that E[ x r x ] r 1. (6) It means the average delay that a packet waits for its transmission needs to be less than or equal to the relative delay, which is calculated by relative delay ratio and packet arrival interval. It is also the relative delay requirement in our MAC protocol.
We calculate the expected value E[ x r x ], and then we have E[ x r x ] = x r x r 0 xf(x ) dx = Then we need to show that x r 1 e 1 x. (7) r x r 1 e 1 x r 1, (8) r which is also the relative delay bound. Since > 0 and 1 e x r > 0, we can establish the following equation, which is equivalent to Eq. (8) : x r + (r + 1)(e x r 1) 0. (9) A new function is defined as: g(y ) = y + (r + 1)(e y 1), y (0, + ), (10) in which y substitutes x r in Eq. (9). Then our objective becomes to find a maximized y with the constraint g ( y ) 0. We do the first derivative test on g ( y ) and obtain: ln (r + 1) < 0 if y <, g ln (r + (y) 1) = 0 if y =, (11) ln (r + 1) > 0 if y <. It is obvious that the function g ( y ) has a minimum value at y min = ln (r+1). To satisfy g ( y ) 0 for some y, the minimum value g(y min ) must be less than or equal to 0. Otherwise, such y doesn t exist. To put y min into g ( y ), we can obtain: g(y min ) = ln (r + 1) r. (12) Let us further define h (r) = ln (r + 1) r. We also run first derivative test on h ( r ) and then obtain: h (r) = 1 r + 1 1. (13) Since 0 r 1 according to realistic settings (if r > 1, the relative delay will be meaningless), then h ( r ) is always less than or equal to 0. Also because h (0) = 0, we can simply prove that h ( r ) 0 when 0 r 1. Therefore, we prove that the minimum value of g ( y ) is a non-positive value. There are always some y satisfying g ( y ) 0. To find such y, we solve the equation g(y ) = 0. It is obvious that there are two roots in the equation according to our previous analysis and one root is 0. Then our purpose is to find another root, which is also the maximized value to satisfy the equation. Since the above equation is a transcendental equation, it cannot be solved for one factor in terms of another. Hence, we adopt numerical methods to solve it and find the other root. Taylor series is adopted to calculate the maximized approximation root. The equation e y in g ( y ) is extended on the position y = ln (r+1) in the second order Taylor polynomial. Then we have: g(y ) = g (y) + R (y), (14) where ( 1 g (y) = y (r + 1) + (r + 1) + ( 2 y 2(r + 1) ln (r + 1) r + 1 ) 2 ) ( y r + 1 J. Tian et al. / Ad Hoc Networks 67 (2017) 40 52 43 ) ln (r + 1), (15) y ( ) ln (r + 1), y. (16) It can be observed that R ( y ) 0. To find the maximized y satisfying g ( y ) 0, we only need to set g (y) = 0. We solve the equation and obtain one maximized root: y r = 2 r 2 ln (r + 1) + ln (r + 1), (17) which is also the value of x r. Thus we prove the lemma. Note that in Eq. (1), a parameter is required for each sensor node, but cannot be known beforehand. We propose a traffic estimation algorithm to calculate an estimated parameter, ˆ which is used in the calculation of Eq. (1) to represent the ideal parameter. Upon arrival of a data packet, the sender updates ˆ of the packet s receiver as: ˆ = β ˆ + (1 β), (18) where ˆ is the old parameter before the packet is received, is the maximum likelihood estimate from recent samples, and β is the weight, which is a system parameter. After a packet arrives at a sensor node, it calculates the based on recent samples in a certain range, such as 10 time units. Then it sets old ˆ to be ˆ and calculates a new ˆ based on Eq. (18). The reason to establish the above equation to estimate is that ˆ needs to reflect the most recent traffic conditions by carefully choosing β, since the weather conditions are unpredictable and may cause very dynamic traffic in the network. 4.1.2. Rendezvous time calculation when no packets arrive After the sender calculates a rendezvous interval, it informs the receiver. Then they both sleep till the scheduled wake-up time. During the interval, if the sender receives packets from other sensor nodes or generates packets itself, the packets can be transmitted to the receiver at the scheduled wake-up time. If the sender doesn t have any packet during the interval, a new rendezvous time needs to be calculated to schedule next wake-up time. The new rendezvous time also needs to meet the relative delay bound. When a sender doesn t have any packet to send in the coming rendezvous interval, it means the packet must arrive at the time that is greater than the rendezvous time. As shown in Fig. 2, after sender A and receiver B finish the last packet transmission at time t 2, they set time t 3 as the rendezvous time for next transmission. If there is no packet arriving at sender A between time t 2 and t 3, packets must arrive at the time greater than time t 3 if there is any. Then the problem lying here is how to determine the next rendezvous interval such that the required relative delay can still be guaranteed on average in the sensor node. In the following, we prove that the next rendezvous interval is the same as the old one. Lemma 4.2. For a sender that doesn t have any packet to send, the rendezvous interval with the receiver is: x r = 2 r 2 ln (r + 1) + ln (r + 1), (19) such that the required relative delay can be satisfied. and ( R (y) = (r + 1) 3 e y y 3! ) 3 ln (r + 1), Proof of Lemma 4.2. Similar as the proof of Lemma 4.1, we assume a packet X arrives at the receiver between (x r, x r + x r ], at which x r is the next rendezvous interval. Then the probability that packet X arrives between ( x r, x ], where x (x r, x r + x r ], on condi-
44 J. Tian et al. / Ad Hoc Networks 67 (2017) 40 52 Fig. 2. Next rendezvous time when no packets arrival. tioning x r < X x r + x r is: P r(x r < X x x r < X x r + x r ) = P r(x r < X x, x r < X x r + x P r(x r < X x r + x = = P r(x r < X x ) P r(x r < X x r + x r ) r ) 1 e x (1 e x r ) = 1 e (x r + x r ) (1 e x r ) r ) 1 e (x x r ) 1 e x r. (20) We substitute x x r with y and x r with y r. Then we have y (0, y r ] and y r becomes the next rendezvous interval. A new CDF 1 e y F (y) = with y (0, y 1 e y r r ] can also be obtained from the above function. It can be observed that F ( y ) is exactly the same as F ( x ) in Lemma 4.1. Then the calculation results of y r is the same as x r. It also means x r is same as x r. Thus, the lemma is proved. From the above analysis, it can be further induced that if a sender has no packets arrived during the second rendezvous interval, it can keep the same rendezvous interval to make the appointment with receiver. In the following, we prove the statement. Lemma 4.3. For a sender that doesn t have any packet arrived, the rendezvous interval with the receiver always keeps: 2 r 2 ln (r + 1) + ln (r + 1) x r =, (21) such that the required relative delay can be satisfied. Proof of Lemma 4.3. We use mathematical induction to prove the lemma. Similar as the proof of previous lemmas, we assume a packet X arrives at the receiver between (0, x ]. When x x r, packet X must be transmitted at x r and thus the required relative delay can be satisfied according to Lemma 4.1. When x > x r, assume all the previous rendezvous interval is the same, which is x r. Then there must exist some k, which satisfies kx r < x (k + 1) x r. Let s assume x r is the next rendezvous interval to transmit packet X. Then the probability that packet X arrives between ( kx r, x ], where x (kx r, kx r + x r ], on conditioning kx r < X kx r + x r is: P r(kx r < X x kx r < X kx r + x = = = P r(kx r < X x ) P r(kx r < X kx r + x r ) 1 e x (1 e kx r ) 1 e (kx r + x r ) (1 e kx r ) (x kx r 1 e ) 1 e x r r ). (22) Same as Lemmas 4.2, we substitute x kx r with y and x r with y r. Then we have y (0, y r ] and y r becomes the next rendezvous interval. A new CDF F (y ) = 1 e y 1 e y r with y (0, y r ] can also be ob- tained from the above function. It can be observed that F ( y ) is exactly the same as F ( x ) in Lemma 4.1. Then the calculation results of y r is the same as x r. It also means x r is same as x r. Thus, the lemma is proved. To achieve continuous appointment between a sender and a receiver when no packets need to be transmitted, after the sender receives the beacon message, it just ignores it and replies nothing as shown in Fig. 2 at time t 3. Then after a short time, the receiver knows that no packet will arrive. It uses the previous rendezvous interval to calculate next rendezvous time and goes to sleep. Note that keeping x r the rendezvous interval is the sufficient condition to achieve the required relative delay. 4.2. Weather adaptivity During the rain, regular sensors are in sleep mode; however, the data stored in regular sensors may still be lost. Therefore, to be adaptive to the weather, we propose pre-rain rendezvous time adjustment, which helps regular sensors to transmit as much as possible data to robust sensors before raining, and post-rain rendezvous time adjustment, which aims to avoid transmission collision when robust sensors have a large amount of data to transmit to regular sensors after rain stops. 4.2.1. Pre-rain rendezvous adjustment The objective of pre-rain rendezvous adjustment is to reduce packet loss and delay at regular sensors because of the rain. To achieve this goal, regular sensors and robust sensors take different strategies. Before rain comes, regular sensors reduce the rendezvous interval and try to transmit all their packets to robust sensors. Robust sensors cache the packets if the next-hop receivers are regular sensors. For regular sensors to determine how to reduce the rendezvous interval, we first examine the average frequency of packet receiving and sending in regular sensors. The average frequency of sending packets is calculated based on rendezvous interval. Then the following equation must be satisfied: 1. x ˆ (23) r It means that regular sensor can always send its packets to other sensors faster than receive a new packet on average. Then we have: 2 r 2 ln (r + 1) + ln (r + 1) 1. (24) If the system parameter r doesn t satisfy the above equation, we can solve the equation to find a new r. Obviously, r is always less than or equal to r, which means a smaller r can still achieve the required relative delay bound. If r does satisfy the equation, the
J. Tian et al. / Ad Hoc Networks 67 (2017) 40 52 45 fore, there is a high probability that the packets are delayed and thus the required delay is not satisfied because of the long data transmission time. To prevent the above from happening, we propose to set the first rendezvous time after rainy weather between robust senders and regular receivers to be ahead of the scheduled time. Since after the rain, there are very few packets needed to be transmitted between regular sensors and between robust sensors, such early scheduling does not potentially increase the probability of transmission failure. The ideal is to calculate a transmission window, which is the length of time that the rendezvous time should be moved ahead. The transmission window is an estimation of how long it takes to transmit packets cached in a robust sensor to its neighbor regular sensors on average. Since all sensors are deployed in a field for the same application, we assume packet generation rate is the same in every sensor node. Let 0 denote the packet generation rate in a robust sensor, n b denote the number of robust sensors, and T r denote the duration of a rainy period. n b 0 T r is the total number of packets generated in all robust sensors during the rainy period. Then such amount of packets need to be transmitted to neighbor regular sensors. Let n g denote the total number of regular sensors, T t denote the transmission time to transmit a packet entirely including data message, beacon message and ACK message, and c denote transmission time, which is a system parameter. Then the required length of time, which is also the transmission window T w, can be calculated as follows: Fig. 3. Pre-rain rendezvous adjustment. following method is used to further reduce the probability that a regular sensor cannot dump all its packets before the rain. In the pre-rain rendezvous adjustment, a robust sensor checks whether or not a current packet s next receiver is a regular sensor. If the receiver is a regular sensor, then the regular sensor further checks whether or not its next rendezvous time to send such packet is in the rainy period. If the regular sensor s rendezvous time is in the rainy period, then the regular sensor notifies the robust sensor that the previous transmitted packet needs to be cancelled as shown in Fig. 3 (a) and the robust sensor keeps the packet for transmitting it later. One bit can be set in the ACK message to notify the transmission is cancelled. If the next rendezvous time is before the rainy period, the regular sensor node keeps the packet and tries to transmit it at its next rendezvous time as shown in Fig. 3 (b). In the pre-rain rendezvous adjustment, only the receiver s information within 2 hops can be used to decide whether or not to cache a packet in the current robust sensor node. If a regular sensor becomes the packet s receiver more than 2 hops away, the robust sensor cannot know it and then the packet may be lost during the rain. For example, in Fig. 3 (b), if a regular sensor node D receives data from regular sensor node C and the regular sensor node D s next rendezvous time is in the rainy period, then the packet will be lost in node D. To avoid such packet loss, additional routing information is required. In the paper, we only consider to avoid the packet loss in the data communication layer. 4.2.2. Post-rain rendezvous adjustment After rainy weather passes, most of regular sensors come back to work again. Since robust sensors work under the rainy weather, they cache a lot of packets, whose next hops could be regular sensors. The packets need to be transmitted to the next hop immediately such that they are not delayed. Note that, during every data transmission in WA-MAC, a sender tries to send all packets to a receiver at once. Then after the rain is over, the first time of data transmission from robust sensors to regular sensors takes longer than usual. If the rendezvous time is still scheduled as be- T w = c T t n b 0 T r n g, (25) The window is, in the worst case, the time needed to dump the packets generated by robust sensors during rainy periods to regular sensors. Here the worst case means packets are transmitted for c times to be successfully delivered. Next, we present how a regular sensor receiver calculates the first rendezvous time after rain. Before rain comes, every regular sensor has its own rendezvous time. When the rain is approaching, one rendezvous time must fall in the rainy periods as shown in Fig. 3 (a). Since the regular sensors don t work under the rain, such rendezvous time is postponed till rain passes. The duration of rainy periods is added to obtain a rescheduled rendezvous time after the rain. Then we further put the transmission window ahead to calculate a new rendezvous time. It considers leaving enough time for packet transmitting cached in robust sensors. The calculation process is illustrated in Fig. 4 (a). If the new rendezvous time falls in the rainy periods, then the new rendezvous time is set to be the ending time of the rainy periods as illustrated in Fig. 4 (b). After the rain, the regular sensors follow the new rendezvous time to wake up and transmit the packets only once. After this one time transmission, all sensors still use the algorithm in Section 4.1 to calculate its next rendezvous time. Since all information can be obtained ahead of rainy periods, the post-rain rendezvous adjustment can always be performed successfully. If the new rendezvous time falls into the rainy period because of long rainy period, the sensors will wake up to receive the latest weather forecast and then go back to sleep till the sunny period comes. 4.3. Transmission collision After pre-rain and post-rain rendezvous adjustment, the traffic could become heavy. Then there is a probability that transmission collisions happen in a sensor node since its rendezvous interval is small. The transmission collision happens in a sensor node when it either acts as a sender or a receiver during the data transmission. The collision happens in a sender when it hasn t finished the data sending but its next rendezvoused sending time comes as shown in Fig. 5 (a). Then the sender cannot transmit next data at
46 J. Tian et al. / Ad Hoc Networks 67 (2017) 40 52 Fig. 4. Post-rain rendezvous adjustment. Fig. 5. Transmission collision. the scheduled time. For example, in Fig. 5 (a), sender A sends data to receiver B at time t 1. t 2 is the rendezvous time between sender A and receiver C. Let T t denote the transmission time to transmit a large packet, which is greater than t 2 t 1. Then the collision happens in sender A at time t 2. Since the data transmission from sender A to receiver B is not finished at t 2, the data transmissions from sender A to receiver C is delayed. To deal with the collision at the sender side, in WA-MAC, after a receiver wakes up, it first checks whether or not the channel is busy. If it is, then it waits and checks the channel with interval T t for c times. When it senses the channel is not busy anymore, it sends a beacon. Otherwise, it stops sending the beacon. As shown in Fig. 5 (a), when receiver C notifies that the channel is not busy at time t 2 + T t, it sends a beacon out and prepares the data transmission. Moreover, since the sender has all receivers rendezvous time, it processes packet transmission as the rendezvoused sequence. The collision happens in a receiver when it needs to frequently receive packets from different senders as shown in Fig. 5 (b). The collision at a receiver is very similar as that at a sender. It happens when its next rendezvous receiving time comes but it has unfinished receiving packets. To deal with the collision at the receiver side, its senders are scheduled to wait with the interval T t for c times. Once the receiver finishes the packet transmission, it calculates the rescheduled time for the conflicting sender and sends a beacon message at that time. As shown in Fig. 5 (b), at t 2, the conflicting sender is sender C. Then both receiver A and sender C wake up at rescheduled time t 2 + T t and then receiver A sends a beacon message to notify sender C to transmit the packet. If there are more than 1 sender wait for transmission, the receiver contains the information that which sender is going to be the next sender in the beacon message and then every sender is aware of its turn. In this way, the sender can begin the next packet transmission with a short delay. The pseduo-code at the sender and the receiver is show in Algorithms 1 and 2 respectively. 4.4. Transmission failure Transmission failure happens in the network due to collisions or weak signals or other factors. Specifically, there are three failure scenarios: (1) The beacon message is lost during the transmission from receiver to sender, as illustrated in Fig. 6 (a). In the scenario, the receiver cannot know if there is no data to transmit or the beacon message is lost. To deal with the problem, the receiver tries to continuously send a beacon message for c times with the interval T t to the sender to confirm no packet to arrive, where T t is the transmission time to transmit a packet. Similarly, the sender continuously wakes up for c times with the interval T t to try to receive the beacon message. After the c times retrying, if the beacon message is still lost, both sender and receiver use the same rendezvous interval to calculate the next rendezvous time. Note the probability of beacon message loss is low because a beacon message is short and has higher priority. (2) The data message is lost during the transmission from sender to receiver as show in Fig. 6 (b). In this scenario, the receiver does not receive the piggybacked updated rendezvous interval, and thus will use the old rendezvous interval. The sender cannot receive the ACK message since the data packet is lost. However, the sender does not know whether the ACK is lost or the data is lost. Therefore, the sender will calculate two rendezvous times based on both the new and old rendezvous interval. (3) The ACK message is lost during the transmission from receiver to sender. In this case, the receiver receives the updated rendezvous interval and calculates the new rendezvous time. As for the sender, same as scenario (2), the sender does not know whether it is the data which is lost or the ACK which is lost. Therefore, the sender will wake up twice. Please note that if the sender does not receive the ACK in scenarios (2) and (3), it will retransmit the packet for c times with the interval T t. If after the c times attempts, either the ACK or the data is still lost, we follow the above strategy to deal with the transmission failure. 5. Evaluation In this section, we evaluate the proposed WA-MAC protocol. Our objective in conducting the evaluation study is four-fold: (1) Evaluating WA-MAC protocol in minimizing energy consumption for packet transmission in the network; (2) Evaluating WA-MAC protocol in achieving a required relative delivery delay in the net-
J. Tian et al. / Ad Hoc Networks 67 (2017) 40 52 47 Algorithm 1 Collision handling algorithm at a sender. Notations: T t : the transimmision time for a packet. T : SIFS + maximized propagation delay. l t r : 0, the current try times. c: the max try times. t: the rendezvous time. Algorithm 2 Collision handling algorithm at a receiver. Notations: T t : the transimmision time for a packet. T l : 2 * SIFS + maximized propagation delay. t r : 0, the current try time. c: try limits. t: the rendezvous time. (1) Upon t arriving Sender wakes up and waits for the beacon message. if No beacon message is received in T l then It schedules itself to wake up at a T t interval. t r t r + 1. if t r > c then It drops the data and wakes up at a new rendezvous time. else if the beacon message is disturbed then It schedules itself to wake up at a T t + T l interval. else Sender sends data and waits for the ACK. if No ACK arrives in T l then t r t r + 1. if t r > c then It drops the data and wakes up at a new rendezvous time. It sends data again and waits for the ACK. (2) Upon an ACK arriving after sending the data in T l The process finishes and sender goes to sleep. t r 0. work; (3) Evaluating WA-MAC protocol in achieving a high packet delivery ratio in the network; and (4) Evaluating whether WA-MAC protocol work effectively under both sunny and rainy weather. To evaluate WA-MAC, four metrics are employed: (1) duty cycle on each sensor, (2) packet delivery delay, (3) relative packet delivery delay ratio, and (4) packet delivery ratio. The duty cycle is the working time of sending and receiving packets to the network running time averaged on each sensor. The packet delivery delay is the average delay of each packet between the time that it is generated and the time that it arrives at the destination. The relative packet delivery delay is the packet delivery delay divided by average packet arrival interval. The packet delivery ratio is the ratio of the number of total packets arrived at destination to the number of total packets generated in the network. We compare WA-MAC protocol with several representative receiver-initiated MAC protocols, which are RI-MAC [17], PW-MAC [18] and CyMAC [19]. RI-MAC is one of the first several receiverinitiated MAC protocols. To further reduce the energy consumption of sender in RI-MAC, PW-MAC adopts a pseudo-random number generator to calculate each appointment time for a pair of sender and receiver. CyMac aims to achieve a relative delay bound for packet transmission as well as a low working duty-cycle for each sensor. Since none of the above three MAC protocols considers weather information, in the evaluation, all the three algorithms are assumed to be aware of weather forecast to avoid regular sensors damage and only the robust sensors are scheduled to be working under the rainy weather. We implement WA-MAC in network simulator ns-2 and evaluate its performance through simulations. By default, in the sim- (1) Upon t arriving Receiver senses the channel. t r t r + 1. if t r > c then It drops the beacon and wakes up at a new rendezvous time. if the channel is busy then It schedules itself to wake up at a T t interval. else It sends a beacon message and waits for the data. if There is no data arriving in T l then It schedules itself to wake up at a T t interval. (2) Upon the data arriving It receives the data. if The data transmission is disturbed then It drops the data after the data transmission. It schedules itself to wake up at a T t interval. t r t r + 1. if t r > c then It drops the beacon and wakes up at a new rendezvous time. else It sends an ACK back after transmission. t r 0. ulations, the area is 1800 m 1800 m. There are n g = 36 regular sensors and n b = 13 robust sensors deployed in the field. The deployment of both regular sensors and robust sensors follows a two dimensional Poisson process. The sensing range and communication range of each sensor is 200 m and 400 m, respectively. The propagation conditions are partially affected by the rain factor, which is below 5 db/km in propagation attenuation when the rain rate is 100 mm/hr [37]. The communication range can be simply guaranteed without affecting the simulation results by increasing the transmission power under those extremely harsh weather [38]. The time span is divided into slots of 100 s. Each node independently generates packets in the network at each second. The packet generation process in each sensor follows a Poisson process. In the simulations, the average packets generation intervals are set to be 6 s, 8 s, 10 s, 12 s, 14 s, 16 s, 18 s, and 20 s. After a packet is generated in each sensor, it is randomly sent to one sensor node following some established routing path. Hence, there are multiple transmissions occurring concurrently, which is similar to the traffic in real applications. In both WA-MAC and CyMac, the relative delay ratio r is set to 0.2 and the weight β is set to 0.9. WA-MAC uses the packets information in the recent 5 time slots to update. ˆ The retrying times of transmission are set to 4 in all four MAC protocols. In PW-MAC, the parameter a and c are randomly chosen from the range (0, 100), and m is set to 100. To obtain a short delay in RI-MAC and PW-MAC, the wakeup interval is set to 1000 ms in RI-MAC, and the wakeup interval is computed as a pseudo-random number between 0 and 1000 ms in PW-MAC. Other than these, all
48 J. Tian et al. / Ad Hoc Networks 67 (2017) 40 52 Fig. 6. Transmission failure. other parameters in RI-MAC, PW-MAC and CyMac are set to be the same as in [17,19], respectively. We evaluate our algorithm under 6 slots of sunny weather and 11 slots of both sunny and rainy weather. In the 11 slots of both sunny and rainy weather, the weather condition in the network is that the first 5 slots are sunny, then the next 1 slot is rainy and the remaining 5 slots are sunny again. During the 1 slot rainy period, one regular sensor has a probability of 10% to be damaged. The weather information is given to every node before the simulations. Since all four MAC protocols need to receive the weather forecast, the overhead of broadcasting is ignored in the simulation. All simulation results are the average of 100 times simulations. The network topology is different in each simulation by redeploying all sensor nodes in the network. The setting of the simulation is listed in Table 1. 5.1. Evaluation of packet delivery delay and relative delay ratio In this section, the average packet delivery delay are evaluated. To achieve a short delay in PW-MAC and RI-MAC, their wakeup intervals are set to be short, which is 1 s. Fig. 7 (a) shows the average delay in all the four MAC protocols under sunny weather. It can be observed that as the packet generation interval becomes large, the delivery delay increases in both WA-MAC and CyMAC. The reason is that both PW-MAC and WA-MAC are designed to achieve a relative delay bound during the transmission. When the packet interval becomes large, the allowable delay in each sensor becomes large and thus the total delay increases. When the packet generation frequency is high, WA-MAC performs better than the other three MAC protocols, even if the wakeup interval in PW-MAC and Table 1 Simulation configuration. Parameter Value Sensing range ( m ) 200 Communication range ( m ) 400 Number of regular sensors 36 Number of robust sensors 13 Failure probability of a regular sensor 10% Packet generation interval ( s ) 6 20 Retrying times 4 Relative delay ratio in WA-MAC and CyMac 0.2 β in WA-MAC 0.9 Wakeup interval in RI-MAC (ms) 1000 Wakeup interval in PW-MAC (ms) (0, 1000) a and c in PW-MAC (0, 100) m in PW-MAC 100 RI-MAC is short. For example, when packet generation interval is 6s, WA-MAC achieves a delivery delay of 4.7 s that is 29.8% less than CyMAC, 185.1% less than RI-MAC, and 459.6% less than PW- MAC. Their delivery delays are 6.1 s, 13.4 s, and 26.3 s, respectively. Fig. 7 (b) shows the delivery delay of all the four MAC protocols under rainy weather. The results in Fig. 7 (b) are similar to those in Fig. 7 (a), because of the same reason. It can also be observed that the delivery delays of all the four MAC protocols increase because of the rainy weather compared to the results in Fig. 7 (a). 5.2. Evaluation of duty cycle We evaluate the average duty cycle in each sensor under both sunny and rainy weather. Fig. 8 (a) shows the results under sunny
J. Tian et al. / Ad Hoc Networks 67 (2017) 40 52 49 Fig. 7. Packet delivery delay. Fig. 8. Duty cycle. weather. From the results, it can be observed that WA-MAC protocol outperforms the other three MAC protocols. For example, when the interval is 6 s, WA-MAC can achieve 4.3% duty cycle on average, which is 277% less than CyMAC, 398% less than PW-MAC, and 440% less than RI-MAC. Their duty cycles are 16.2%, 21.4% and 23.2%, respectively. It can also be observed that the high duty cycle of RI- MAC and PW-MAC is the result of the short wakeup interval to achieve low delivery delay. Fig. 8 (b) shows the performance of the four MAC protocols under both sunny and rainy weather. It can be observed that WA- MAC always performs better than the other three. For example, when the interval is 6 s, WA-MAC protocol can achieve 4.4% duty cycle that is 259% less than CyMAC, 432% less than PW-MAC, and 452% less than RI-MAC. Their duty cycles are 15.7%, 23.4% and 24.3%, respectively. The results also prove that WA-MAC protocol works more efficiently than the other MAC protocols under both sunny and rainy weathers. 5.3. Evaluation of relative delay ratio Since only CyMAC and WA-MAC protocols support the relative delay bound, we further evaluate the relative delay ratio of each sensor node in CyMAC and WA-MAC. In the evaluation, the relative delay ratio is 0.2 for both WA-MAC and CyMAC. As shown in Fig. 9 (a), under sunny weather, WA-MAC can achieve a relative delay ratio very close to 0.2, which is the default setting in the network, except when the packet generation interval is really small. For example, when packet generation interval is 20 s, WA- MAC achieves a ratio of 0.202 during packet transmission, while CyMAC achieves a ratio of 0.244. The reason of WA-MAC achieving a high relative delay ratio when the packets are generated frequently in the network under sunny weather is that there is a high probability that transmission collisions happen. WA-MAC provides the solution to deal with such situations, but increases the relative delay during the transmission. Instead, CyMAC just simply drops the packets. It has lots of packets missing, which can be shown in the evaluation of Section 5.4. Fig. 9 (b) shows the relative delivery delay ratio achieved by both CyMAC and WA-MAC under both sunny and rainy weathers. It can be observed that WA-MAC always achieves a relative delay ratio closer to 0.2 than CyMAC. For example, when packet generation interval is 20 s, the relative delay ratio under WA-MAC is 0.210, which is much closer to 0.2 than that under CyMAC, which is 0.243. It proves that WA-MAC works effectively under rainy weather as well to provide the required relative delay. 5.4. Evaluation of packet delivery ratio Packet delivery ratio is evaluated for all the four MAC protocols under both sunny and rainy weather. Fig. 10 (a) shows the packet delivery ratio under sunny weather. It can be observed that WA- MAC can always maintain an almost 100% packet delivery ratio under different packet generation interval while the other three cannot under either short packet generation interval or long packet generation interval. It shows that WA-MAC deals with the transmission collision more effectively than the other three MAC protocols. For example, when packet generation interval is 6 s, WA-MAC achieves 99.4% packet delivery ratio, but CyMAC, PW-MAC, and RI- MAC can only achieve 96.9%, 79.9%, and 92.5% packet delivery ratio, respectively. Fig. 10 (b) shows the packet delivery ratio under both sunny weather and rainy weather. It can be observed that the rainy weather has a higher impact on RI-MAC than the other three MAC protocols. Compared to Fig. 10 (b), the packet delivery ratio drops in RI-MAC, almost maintains the same in PW-MAC, and increases in CyMAC. Since WA-MAC caches the data in the robust sensors
50 J. Tian et al. / Ad Hoc Networks 67 (2017) 40 52 Fig. 9. Packet relative delivery delay ratio. Fig. 10. Packet delivery ratio. during pre-rain rendezvous adjustment, thus WA-MAC can keep an almost 100% packet delivery ratio and performs much better than all the other three MAC protocols. 6. Related works Recently, a significant number of works have already been done in the design of receiver-initiated MAC protocols in wireless sensor networks. Sun et al. first applies the concept of receiver-initiated data transmission to duty cycle MAC protocols in WSN in [17]. They also design a Receiver-Initiated MAC, called RI-MAC, to implement the concept. To further reduce the idle listening time, PW- MAC (Predictive-Wakeup MAC) is proposed by Tang et al. in [18]. It introduces a method to predict the target receivers wake-up time so that a sender only needs to wake up slightly before the target receiver. Boulfekhar et al. propose SRI-MAC (Synchronous Receiver Initiated MAC) protocol in [39], which is designed on the basis of synchronized duty cycled MAC protocol. It employs an adaptive beacon and a series of RTS/CTS packets to reduce duty cycle and minimize idle listening. SARI-MAC (Self Adapting Receiver Initiated MAC protocol) is proposed in [40] by Lampin et al. It dynamically adjusts the on-duty and off-duty according to the traffic load. Cy- MAC is proposed by Peng et al. in [19]. It provides a desired relative delay bound guarantee for data delivery services via planning the rendezvous schedules carefully between neighbors and also adjusts the sensor nodes duty cycles dynamically according to the varying traffic condition. RWB, a single-hop broadcast protocol for asynchronous receiver-initiated MAC in WSN, is proposed in [41]. It reduces energy consumption by predicting the receivers wakeup time and cutting the long back-to-back broadcast into several unicast packets. Dutta et al. propose A-MAC in [16], which is a receiver-initiated link layer protocol for low-power wireless networks that supports unicast, broadcast, wake-up and pollcast services under a unified architecture. HKMAC protocol is proposed in [42]. It achieves a low end-to-end packet delivery latency and high energy efficiency under burst traffic by adaptively adjusting beacon time of the receiver and scheduling the sender s listening time during scheduled period. Fafoutis et al. study collision avoidance mechanism in receiver-initiated MAC protocols in [43]. A new collision avoidance mechanism named altruistic backoff (AB) is designed to avoid collisions before the transmission of a beacon. In [44], Date et al. study the effects of receiver-initiated MAC protocol for power saving in WSN. It shows that the receiver-initiated MAC protocol can improve power consumption characteristics by reducing packet collisions and reducing transmission power consumption. MR-MAC, a receiver-initiated MAC protocol for underwater acoustic sensor networks, is proposed in [45]. It increases of the throughput and reduces of the transmission of control packet for handshaking by sending the data packet in a packet train manner. DRMAC, a double-loop receiver-initiated MAC protocol is proposed in [46] for data dissemination in delay tolerant networks (DTNs) via roadside wireless local area networks (RS-WLANs). However, none of the existing works focuses on designing a MAC protocol in the heterogeneous networks with sensors having different environmental survivability. Moreover, none of them considers environmental attributes, such as weather, which is an important factor that may cause packet to be delayed and lost in the network. Without such consideration, above protocols cannot work effectively to cope with different weathers and thus cannot be directly applied to solve the problem in this paper. 7. Conclusion In this paper, we propose a new Weather Adaptive receiverinitiated MAC protocol called WA-MAC in the survivabilityheterogeneous wireless sensor networks. We theoretically analyze WA-MAC and prove that it can achieve a relative delay bound data delivery service. We also demonstrate that WA-MAC can be adap-
J. Tian et al. / Ad Hoc Networks 67 (2017) 40 52 51 tive to different weather conditions. The performance evaluation of WA-MAC shows that it works effectively and efficiently under different weather conditions and outperforms other existing works. References [1] R. Szewczyk, A. Mainwaring, J. Polastre, J. Anderson, D. Culler, An analysis of a large scale habitat monitoring application, in: Proceedings of the 2nd International Conference on Embedded Networked Sensor Systems, ACM, 2004, pp. 214 226. [2] M. Zink, D. Westbrook, S. Abdallah, B. Horling, V. Lakamraju, E. Lyons, V. Manfredi, J. Kurose, K. Hondl, Meteorological command and control: An end-to-end architecture for a hazardous weather detection sensor network, in: Proceedings of the 2005 Workshop on End-to-End, Sense-and-Respond Systems, Applications and Services, USENIX Association, 2005, pp. 37 42. [3] G. Tolle, J. Polastre, R. Szewczyk, D. Culler, N. Turner, K. Tu, S. Burgess, T. Dawson, P. Buonadonna, D. Gay, et al., A macroscope in the redwoods, in: Proceedings of the 3rd International Conference on Embedded Networked Sensor Systems, ACM, 2005, pp. 51 63. [4] A. Markham, N. Trigoni, S. Ellwood, Effect of rainfall on link quality in an outdoor forest deployment, in: Wireless Information Networks and Systems (WIN- SYS), Proceedings of the 2010 International Conference on, 2010, pp. 1 6. [5] J. Tian, X. Liang, G. Wang, Deployment and reallocation in mobile survivability-heterogeneous wireless sensor networks for barrier coverage, Ad Hoc Netw. 36 (2016) 321 331. [6] J. Panchard, S. Rao, M.S. Sheshshayee, P. Papadimitratos, S. Kumar, J.-P. Hubaux, Wireless sensor networking for rain-fed farming decision support, in: Proceedings of the Second ACM SIGCOMM Workshop on Networked Systems for Developing Regions, 2008, pp. 31 36. [7] J. Suhonen, M. Kohvakka, M. Hännikäinen, T.D. Hämäläinen, Design, implementation, and experiments on outdoor deployment of wireless sensor network for environmental monitoring, in: Embedded Computer Systems: Architectures, Modeling, and Simulation, Springer, 2006, pp. 109 121. [8] J. Tian, T. Yan, G. Wang, A network coding based energy efficient data backup in survivability-heterogeneous sensor networks, IEEE Trans. Mob. Comput. 14 (10) (2015) 1992 2006. [9] J. Tian, T. Yan, X. Gao, G. Wang, Scheduling survivability-heterogeneous sensor networks for critical location surveillance, ACM Trans. Sens. Netw. 11 (4) (2015) 56:1 56:23. [10] K. Martinez, J.K. Hart, R. Ong, Environmental sensor networks, Computer (Long Beach Calif) 37 (8) (2004) 50 56. [11] L. Selavo, A. Wood, Q. Cao, T. Sookoor, H. Liu, A. Srinivasan, Y. Wu, W. Kang, J. Stankovic, D. Young, J. Porter, Luster: wireless sensor network for environmental research, in: SenSys, 2007, pp. 103 116. [12] Y. Wang, X. Wang, B. Xie, D. Wang, D. Agrawal, Intrusion detection in homogeneous and heterogeneous wireless sensor networks, IEEE Trans. Mob. Comput. 7 (2008) 698 711. [13] X. Wang, X. Wang, J. Zhao, Impact of mobility and heterogeneity on coverage and energy consumption in wireless sensor networks, in: ICDCS, 2011, pp. 477 487. [14] M. Cardei, S. Yang, J. Wu, Algorithms for fault-tolerant topology in heterogeneous wireless sensor networks, IEEE Trans. Parallel Distrib. Syst. 19 (2008) 545 558. [15] X. Du, F. Lin, Maintaining differentiated coverage in heterogeneous sensor networks, EURASIP J. Wirel. Commun. Networking (4) (2005). [16] P. Dutta, S. Dawson-Haggerty, Y. Chen, C.-J.M. Liang, A. Terzis, A-MAC: a versatile and efficient receiver-initiated link layer for low-power wireless, ACM Trans. Sens. Netw. 8 (4) (2012) 30:1 30:29. [17] Y. Sun, O. Gurewitz, D.B. Johnson, RI-MAC: a receiver-initiated asynchronous duty cycle MAC protocol for dynamic traffic loads in wireless sensor networks, in: Proceedings of the 6th ACM Conference on Embedded Network Sensor Systems, in: SenSys 08, 2008, pp. 1 14. [18] L. Tang, Y. Sun, O. Gurewitz, D. Johnson, PW-MAC: an energy-efficient predictive-wakeup MACprotocol for wireless sensor networks, in: INFOCOM, 2011 Proceedings IEEE, 2011, pp. 1305 1313. [19] Y. Peng, Z. Li, D. Qiao, W. Zhang, Delay-bounded MAC with minimal idle listening for sensor networks, in: INFOCOM, 2011 Proceedings IEEE, 2011, pp. 1314 1322. [20] X. Fafoutis, A. Di Mauro, M.D. Vithanage, N. Dragoni, Receiver-initiated medium access control protocols for wireless sensor networks, Comput. Networks 76 (2015) 55 74. [21] W. Kang, J.A. Stankovic, S.H. Son, On using weather information for efficient remote data collection in WSN, Workshop on Embedded Networked Sensors, 2008. [22] R. Krashinsky, H. Balakrishnan, Minimizing energy for wireless web access with bounded slowdown, Wirel. Netw. 11 (1 2) (2005) 135 148. [23] W. Goble, Getting failure rate data, 2002. [Online]. Available: www.exida.com [24] S. Aschenbrenner, Failure modes, effects and diagnostic analysis, Channels (2006). [25] Vaisala, User s guide vaisala drycap dewpoint transmitter dmt143, [Online]. Available: www.vaisala.com 2015. [26] L. Richardson, Weather Prediction by Numerical Process, Cambridge University Press, 2007. [27] A. Lorenc, Analysis methods for numerical weather prediction, Q. J. R. Meteorolog. Soc. (1986). [28] P. Michelle, M. Eston, Weather forecasts: just how reliable are they?, ( https://www.minitab.com/en- us/published- Articles/Weather- Forecasts- - Just- How- Reliable- Are- They- ). Accessed May 19, 2017. [29] Weather station with morning, noon & night precision forecast, ( https://www. acurite.com/digital- weather- center- with- morning- noon- night- precisionforecast-02005.html ). Accessed May 19, 2017. [30] W.R. Heinzelman, J. Kulik, H. Balakrishnan, Adaptive protocols for information dissemination in wireless sensor networks, in: Proceedings of the 5th Annual ACM/IEEE International Conference on Mobile Computing and Networking, ACM, 1999, pp. 174 185. [31] Z. Yang, L. Cai, Y. Liu, J. Pan, Environment-aware clock skew estimation and synchronization for wireless sensor networks, in: IEEE INFOCOM, 2012, pp. 1017 1025. [32] Z. Zhong, P. Chen, T. He, On-demand time synchronization with predictable accuracy, in: IEEE INFOCOM, 2011, pp. 2480 2488. [33] J. Tian, X. Liang, T. Yan, M.K. Somashekar, G. Wang, C. Bandera, A novel disjoint set division algorithm for joint scheduling and routing in wireless sensor networks, Wirel. Netw. 21 (5) (2015) 1443 1455. [34] X. Shi, G. Stromberg, SyncWUF: an ultra low-power MAC protocol for wireless sensor networks, Mob. Comput. IEEE Trans. 6 (1) (2007) 115 125. [35] I. Demirkol, C. Ersoy, F. Alagöz, H. Deliç, The impact of a realistic packet traffic model on the performance of surveillance wireless sensor networks, Comput. Netw. 53 (3) (2009) 382 399. [36] Y. Ma, J. Aylor, System lifetime optimization for heterogeneous sensor networks with a hub-spoke technology, Mob. Comput. IEEE Trans. 3 (3) (2004) 286 294. [37] M.C. Kestwal, S. Joshi, L.S. Garia, Prediction of rain attenuation and impact of rain in wave propagation at microwave frequency for tropical region (Uttarakhand, India), Int. J. Microw. Sci.Technol. 2014 (2014). [38] J. Zhao, R. Govindan, Understanding packet delivery performance in dense wireless sensor networks, in: Proceedings of the 1st International Conference on Embedded Networked Sensor Systems, ACM, 2003, pp. 1 13. [39] S. Boulfekhar, M. Benmohammed, Synchronous receiver initiated MAC protocol for long-lived sensor networks, Comput. Electrical Eng. 40 (2) (2014) 504 516. [40] Q. Lampin, D. Barthel, I. Auge-Blum, F. Valois, Sari-MAC: The self adapting receiver initiated MACprotocol for wireless sensor networks, in: Wireless and Mobile Computing, Networking and Communications (WiMob), 2012 IEEE 8th International Conference on, 2012, pp. 12 18. [41] Y. Qiu, S. Li, D. Yang, Z. Li, Rwb: An efficient receiver-initiated single-hop broadcast protocol for asynchronous MAC in wireless sensor networks, in: Recent Advances in Computer Science and Information Engineering, 127, Springer Berlin Heidelberg, 2012, pp. 261 266. [42] H. Tang, C. Sun, Y. Liu, B. Fan, Low-latency asynchronous duty-cycle MAc protocol for burst traffic in wireless sensor networks, in: Wireless Communications and Mobile Computing Conference (IWCMC), 2013 9th International, 2013, pp. 412 417. [43] X. Fafoutis, C. Orfanidis, N. Dragoni, Altruistic backoff: collision avoidance for receiver-initiated MAC protocols for wireless sensor networks, Int. J. Distrib. Sens. Netw. 2014 (2014). [44] H. Date, T. Shigeyasu, Effects of receiver initiated MAC protocol for reducing power consumption in wireless sensor networks, in: Network-Based Information Systems (NBiS), 2013 16th International Conference on, 2013, pp. 214 221. [45] W.-H. Liao, Y.-C. Lin, S.-C. Kuai, A receiver-initiated MAC protocol for underwater acoustic sensor networks, in: Information Networking (ICOIN), 2014 International Conference on, 2014, pp. 1 6. [46] H. Liang, W. Zhuang, Double-loop receiver-initiated MAC for cooperative data dissemination via roadside WLANs, Commun. IEEE Trans. 60 (9) (2012) 2644 2656.
52 J. Tian et al. / Ad Hoc Networks 67 (2017) 40 52 Jie Tian received the B.S. degree in Computer Science from Tianjin University, Tianjin, China, in 2005, the M.S. degree in Computer Science at Nankai University, Tianjin, China, in 2008 and the Ph.D. degree in Department of Computer Science at New Jersey Institute of Technology, USA, in 2015. He joined Audible Inc. as a software development engineer in 2015. His research includes wireless networks, ad hoc/sensor network and mobile computing. Yi Wang received the B.S. degree in Software Engineering from Dalian University of Technology, Dalian, China, in 2012 and the M.S. degree in Computer Applied Technology from University of Chinese Academy of Sciences, Beijing, China, in 2015. He joined Alphabet Inc. as a software development engineer in 2015. His research includes wireless networks and content centric networking. Xiaoyuan Liang is currently a Ph.D. student at Computer Science Department in New Jersey Institute of Technology, USA, since 2013. He received his bachelor degree in Computer Science and Technology department at Harbin Institute of Technology in China. His research interest includes wireless networks, vehicular networks, deep learning and data analysis. Guiling Wang received the B.S. degree in software from Nankai University, Tianjin, China, and the Ph.D. degree in computer science and engineering with a minor in statistics from The Pennsylvania State University, State College, PA, USA, in 2006. She is currently a Professor in the New Jersey Institute of Technology, Newark, NJ, USA. Her research interest includes mobile computing, network, system security and deep learning applications. Yujun Zhang received the B.S. degree in computer science from Nankai University, China, in 1999 and the Ph.D. degree in computer science in from Chinese Academy of Sciences, China, in 2004. He is currently a Professor in the Institute of Computing Technology, Chinese Academy of Sciences. His research interest includes future Internet architecture and network security.