A Smart Sensor Grid to Enhance Irrigation Techniques in Jordan Using a Novel Event-Based Routing Protocol

Abstract

Due to rapid changes in climatic conditions worldwide, environmental monitoring has become one of the greatest concerns in the last few years. With the advancement in wireless sensing technology, it is now possible to monitor and track fine-grained changes in harsh outdoor environments. Wireless sensor networks (WSN) provide very high quality and accurate analysis for monitoring of both spatial and temporal data, thus providing the opportunity to monitor harsh outdoor environments. However, to deploy and maintain a WSN in such harsh environments is a great challenge for researchers and scientists. Several routing protocols exist for data dissemination and power management but they suffer from various disadvantages. In our case study, there are very limited water resources in the Middle East, hence soil moisture measurements must be taken into account to manage irrigation and аgriculturаl projects. In order to meet these challenges, a Smart Grid that supports a robust, reactive, event-based routing protocol is developed using Ad hoc On-Demand Multipath Distance Vector (AOMDV) as a starting point. A prototype WSN network of 5 nodes is built and a detailed simulation of 30 nodes is also developed to test the scalability of the new system.

1. Introduction

Wireless sensor networks (WSN) are part of a growing technology that has been designed to support а wide range of applications in wireless environments [1,2]. Although sensor networks have been used in various different applications, environmental monitoring is а domain in which they have had а huge impact. Recent climate change-related catastrophes have illustrated the importance of a detailed understanding of the environment and its evolution for the wellbeing of human beings. The capacity of researchers to improve this knowledge is mainly limited by current data collection techniques, which are based on very expensive stations [3]. The recent development and research in wireless technologies and the advancements in wireless network services have made wireless communications a pervasive means for monitoring the natural environment. WSN’s are particularly useful in remote or dangerous environments whose behaviors have rarely been studied due to their inaccessibility. Therefore, environmental monitoring is an important area for applying wireless sensor networks [4].

In our study we are using WSN Smart Grid for such harsh environments in Middle East region where the sun is present for at least 12 h per day which makes the climate very dry and hot. One of the biggest problems in the Middle East is the limitation of water resources. We need to measure the soil moisture regularly and very accurately to allow targeted irrigation techniques to be implemented. We are deploying WSN to detect when and where it is raining so that necessary irrigation control measures can be applied.

Many research efforts have tried to deploy WSNs for such environments. But there are many issues with their solutions [3]. Hence in attempting to deploy a WSN successfully in these type of harsh environments and to ensure proper operation of sensor networks we need to resolve following issues.

In order to deal with the harsh environment, it is necessary to build a system which has two main proprieties, i.e., event-driven and robustness. The sensor network should be reactive so that it can detect different events correctly, for example, the presence and the absence of rainfall and hence the changes in degree of moisture in the soil. After the event is detected, the affected nodes need to sample the environment at a much faster rate for example if the system is set to sample after every few minutes when it is not raining then it should sample at few seconds when it is raining. Hence the available bandwidth should be more at nodes affected by rain. Hence the required information is sent across as fast as possible and also accurately to the monitoring center or base station.

Currently there is no such robust and event-based wireless routing protocol to react to such type of outdoor environments. Resource limitations of the sensor nodes and unreliability of low-power wireless links [5], in combination with various performance demands of different applications, impose many challenges in designing efficient communication protocols for wireless sensor networks [6].

In this paper, we discuss the shortcomings of popular routing protocols for our application and we exploit the advantages of the popular routing protocol “Ad hoc On-Demand Multipath Distance Vector” (AOMDV) and modify it to achieve the objectives. To achieve the robustness of wireless sensor network (WSN) this project will enhance the protocol to be an energy aware routing protocol to expand the life time of the nodes. We also discuss in detail the design of a smart grid network that can provide all necessary physical parameters to be used in soil moisture and rainfall monitoring algorithms. We implement an algorithm for monitoring and controlling soil moisture events and evaluate the network based on power used, throughput, etc. We deploy an outdoor WSN testbed for testing our algorithm. The rest of the paper is outlined as follows: Section 2 provides a literature review, Section 3 explores a solution approach. Section 4 looks at sensor network design and in Section 5 we provide testbed results and performance. Finally, we conclude in Section 6.

2. Literature Review

There are numerous routing protocols proposed by researchers in this area, to improve performance demands of different applications through the network layer of wireless sensor networks protocol stack [7,8]. Most of the existing routing protocols in wireless sensor networks are designed based on the single-path routing strategy without considering the effects of various traffic load intensities [9,10]. In this approach, each source node selects а single path which can satisfy performance requirements of the intended applications for transmitting its traffic towards the sink node.

Although route discovery through single-path routing approach can be performed with minimum computational complexity and resource utilization, the limited capacity of а single path significantly reduces the achievable network throughput [11,12]. Furthermore, the low flexibility of this approach against node or link failures may significantly reduce the network performance in critical situations. For instance, whenever the active path fails to transmit data packets (as а result of limited power supply of the sensor nodes, high dynamics of wireless links and physical damages), finding an alternative path to continue data transmission process may cause extra overhead and delay in data delivery. Therefore, due to the resource constraints of sensor nodes and the unreliability of wireless links, single-path routing approaches cannot be considered effective to meet the performance demands of various applications. In order to cope with the limitations of single-path routing techniques, another type of routing strategy, known as multipath routing, has become а promising technique in wireless sensor and ad hoc networks. Dense deployment of the sensor nodes enables а multipath routing approach to construct several paths from individual sensor nodes towards the destination [13].

Discovered paths can be utilized concurrently to provide adequate network resources in intensive traffic conditions. Alternatively, each source node can use only one path for data transmission and switch to another path upon node or link failures. The latter one is mainly used for fault-tolerance purposes, and this is known as alternative path routing.

In the past decade, the multipath routing approach has been widely utilized for different network management purposes such as improving data transmission reliability, providing fault-tolerance routing, congestion control and Quality of Service (QoS) support in traditional wired and wireless networks.

However, the unique features of wireless sensor networks (e.g., constrained power supply, limited computational capability, and low-memory capacity) and the characteristics of short-range radio communications (e.g., fading and interference [14,15]) introduce new challenges that should be addressed in the design of multipath routing protocols. Accordingly, existing multipath routing protocols for traditional wireless networks (such as ad hoc networks) cannot be used directly in low-power sensor networks. During the past years, this issue has motivated the research community of wireless sensor networks to develop multipath routing protocols which are suitable for sensor networks.

In [7], routing challenges and design issues in wireless sensor networks were discussed. They classified all the existing routing strategies based on the network structure and protocol operation. In [16] the researchers provided а brief overview on the existing fault-tolerant routing protocols in wireless sensor networks and categorized these protocols into retransmission-based and replication-based protocols. The researchers in [17] and [18], classified the existing multipath routing protocols in ad hoc networks based on the primary criterion used in their design.

Many routing protocols have been proposed for Wireless Sensor and Ad Hoc Networks. Since we are interested in dynamic and event driven protocol so we studied the likes of AODV which is a reactive protocol that discovers routes only on the basis of demand using a route discovery mechanism. It uses traditional routing tables with one entry per destination. The main advantage of AODV [9,10] compared to other routing protocols is that less memory space is required as information of only active routes are maintained, in turn increasing the performance. While on the other side, the disadvantage is; this protocol is not scalable and in large networks it does not perform well and is not capable to support asymmetric links.

Ad-hoc On-demand Multipath Distance Vector Routing (AOMDV) [19] protocol is an extension to the AODV protocol for computing multiple loop-free and link disjoint paths [20] which aims to remove the disadvantages and the limitation of AODV. The main idea in AOMDV is to compute multiple paths during route discovery. It is designed primarily for highly dynamic ad hoc networks where link failures and route breaks occur frequently. When single path on-demand routing protocol such as AODV is used in such networks, a new route discovery is needed in response to every route break. Each route discovery is associated with high-overhead and latency. This inefficiency can be avoided by having multiple redundant paths available. Now, a new route discovery is needed only when all paths to the destination break. AOMDV can also be used to find node-disjoint or link-disjoint routes. But, AOMDV has more message overheads during route discovery due to increased flooding because it is a multipath routing protocol, the destination replies to the multiple RREQs which results in longer overheads.

In [21], researchers improved the performance of standard AOMDV in conditions like mobility or multi communication. They proposed link reliability in route choice. They modified the Route request process to enable reliable paths using Bit Error Rate (BER). They tested the effectiveness of new protocol by considering these improvements under realistic conditions and the result was compared to standard AOMDV and AODV protocols to show improved performance.

Researchers in [22] modified AOMDV protocol by proposing a new fuzzy logic based scheme. The proposed protocol was shown to select better paths and increase network survivability. The proposed protocol considered many selection criteria, where some represented network status and others were issued by preventive, reactive and tolerant saving lines. They carried out simulations to compare the modified AOMDV protocol with AODV and AOMDV. They showed the proposed protocol’s survivability under different conditions.

An AOMDV based method (E-AOMDV) was proposed by [23], to conserve energy, find shortest path and for load balancing. In order to conserve energy, they defined an energy factor as selection criteria, which was defined as product of energy factors of all nodes on different paths. The status of energy was given by Energy factor. They compared the performance of AOMDV and E-AOMDV to show that the lifetime of proposed E-AOMDV protocol was limited but it showed improved routing compared to AOMDV without including energy factor. So they concluded that performance of the proposed method was better in limited lifetime and showed better results with the new E-AOMDV protocol.

In [24], the authors proposed a modified AOMDV protocol called Network Coding-based AOMDV (NC-AOMDV) routing algorithm for MANET. The proposed method tried to increase data transmission reliability and ensure load balancing. They compared NC-AOMDV routing protocol to AOMDV routing protocol in simulation based on packet overhead, packet delivery ratio, and average end-to-end delay during packet transmission. The results in simulations showed that NC-AOMDV routing protocol was accurate and efficient and provided route stability in dynamic MANET.

An algorithm find maximal nodal remaining energy was proposed in [25], called Delay Remaining Energy for AOMDV (DRE-AOMDV) routing protocol. It claimed to get a solution for finding maximal nodal remaining energy for all routes in selecting a path for end-to-end requirement. The protocol was specifically for route failures caused by lack of energy. The proposed protocol showed significant network performance improvement in terms of energy consumption, packet delivery and network lifetime.

An extension to AOMDV routing protocol was proposed by [26]. It was channel adaptive routing protocol to accommodate channel fading. The proposed algorithm was called Channel-Aware AOMDV (CA-AOMDV). It used channel average nonfading duration as routing metric. Using this it selected stable links for path discovery by applying a pre-emptive handoff strategy. By doing this it was able to maintain reliable connections and exploit channel state information to ensure that the paths were reused when available, instead of being discarded. Simulation results were provided for downtime and lifetime multiple path system. The authors also provided theoretical expressions for network performance measures, and evaluated the differences in performance between CA-AOMDV and AOMDV. The Simulation results showed that CA-AOMDV gave better network performance than AOMDV).

A Modified AOMDV (M-AOMDV) Routing Protocol for Maritime Inter-ship Communication [27] was proposed that provides routing recovery mechanism when a link breaks in an active route to reduce lost packets, this will reduce packet loss ratio and delay time.

M-AOMDV applied to ship communications that are using UHF and VHF, these modifications use the existing AOMDV protocol and enhance the inter-ship communication by adding new recovery methods for a broken link. Normal AOMDV protocol uses one recovery method to recover from broken links; so if a link breaks, this will lead to packet loss and increases the end to end packet delay. In this modification there are two new recovery methods that will try to increase the recovery process and decrease packet loss and end to end delay.

M-AOMDV has better performance results. The delay for the AOMDV protocol is more than M-AOMDV, and the delay of these two protocols are basically consistent with the fluctuating of the speed. The link repair mechanism of M-AOMDV can reduce delays, to a certain extent, by requesting routing entities to forward data packets as soon as possible in order to complete link repair to the destination node when the node detects that the link has been interrupted.

The results show that M-AOMDV reduces average delay and packet loss ratio. Also, this proposed method increases the potential for the ad-hoc network mode to be applied to ship networks on shoreline areas.

Another modified version of AOMDV was proposed in [28], called ant-AOMDV or ant colony optimization modification for AOMDV in MANET, in this research the writers uses the modified AOMDV for multipath routing using ant colony for mobile ad hoc networks (MANETs). The final result is a comparison between ant-AODV and ant-AOMDV.

The idea behind the working of ant-AODV and ant-AOMDV is that the RREQ message packets are sent to a single path in the case of ant-AODV based routing and to multiple paths in the case of ant-AOMDV based routing. RREQ message packets can be termed as a pheromone in terms of standard algorithm of ACO used by the ants.

Parameters like Quality of Service (QoS) will suffer unless special schemes are developed to sustain such networks because of multi hop routing no default route is available. Each node acts as a router and forwards each other’s packets to enable information sharing between mobile nodes.

Ant Colony optimization falls into a class of biologically inspired algorithms that have recently been developed. The Ant Algorithm mimics the behavior of ants in nature while they are searching for food. Particle swarm optimization is inspired by the behavior of flocks of birds as they fly in search of food. These nature-inspired techniques share a common characteristic, the whole information about the state of the system is contained not in a single entity, but rather some part of the information is stored in many of the entities.

The main idea behind the proposed algorithm is that nodes in the network periodically and asynchronously send out artificial ants towards possible destination nodes of data. These ant agents are small control packets, which have the task to find a path towards their destination and gather information about it. This pheromone takes the form of routing tables maintained locally by all the nodes of the network. They indicate the relative quality of different routes from the current node towards possible destination nodes.

In ant-AOMDV multipath routing is done and it sees all possible routes. So, packets can be sent to all the selected paths and thus helps in load balancing. Routing overhead is also minimized which is shown with the help of parameters Network Routing Load (NRL) and Routing Overhead respectively. The other parameters such as Packet Delivery Fraction (PDF), number of sent packets, number of received packets and number of route request packets sent (RREQ) also shows a vast improvement in ant-AOMDV.

Another researcher [29] published a paper about AOMDV-PAMAC, they started their paper explaining that power consumption of nodes in ad-hoc networks is a critical issue because they operate on batteries, they suggested a new link layer algorithm knows as Power Aware medium Access Control (PAMAC) protocol is proposed which enables the network layer to select a route with minimum total power requirement among the possible routes between a source and a destination. The first few nodes whose battery power is drained to the set threshold value are pushed to the exterior part of the network and the nodes in the exterior are brought to the interior. So they used AOMDV using PAMAC as the mac layer protocol and the average power consumption.

AOMDV-PAMAC uses the basic ideas of Power Efficient Battery Capacity Routing (PEBCR) and it incorporates these features into the MAC layer as it is essential to minimize the total transmission power consumption. PAMAC protocol is incorporated in the link layer and simulation works are carried out using GloMoSim by considering thirty nodes randomly distributed in an area of 2000 × 2000 m. The AOMDV routing protocol in incorporated in the network layer and its performance is evaluated under CBR traffic with PAMAC as link layer protocol. Multipath routing protocols compute multiple paths during route discovery to avoid high overhead and latency. We observed the performance of AOMDV, which is a multipath routing protocol relative to AODV, and the Link layer protocol PAMAC, which is the modification to the MACA Protocol. When these two protocols are applied simultaneously, good results are produced compared to the other protocol combination.

AOMDV modifications overcomes many limitations of AOMDV but it still has some limitations when used for a real time and robust routing scenario like we have. Thus, we modified AOMDV to suit our purpose and make it more robust, reactive, event driven, and energy aware.

3. Solution Approach

Figure 1 shows the wireless sensor network being deployed over a large geographical area. Each node is able to measure the amount of soil moisture through the soil moisture sensor in the ground as well as detect the presence of rain through the rainfall sensor. The latter is necessary as the amount of soil moisture may not be enough to detect the presence of rain. In addition, the system must quickly react in order to discover over which part of the sensor network is experiencing the event: in this case rain. When rain is detected as falling in a given part of the system, the data is sent from the relevant nodes to a central administrative server or base station through the PC-USB Gateway. We have to change the routing so that information on the change in the soil content in the affected area could be sent to the server as quickly as possible. Hence, this data is routed at a higher priority that other information being sent. Our modified AOMDV protocol works as follows in two schemes. Under the first scheme, the sensor data under normal events (no rainfall) are sampled after every 3 h for 10 s and sent to the server. During these 3 h the sensors are in sleep mode to save energy and after the data is sampled they again go to sleep mode for another 3 h. If we have rainfall event we implement second scheme, in which the data sample is taken after every 1 s for the sensor node experiencing the rainfall event, hence the affected nodes send data after every 1 s, since the soil moisture may change very rapidly. In second scheme we also increase the priority of this affected node to transfer data to the base station through the gateway. All the other sensor nodes where there is no rainfall still keep sampling after every 3 h. In our previous work [30], we proposed a modified version of the AOMDV protocol. To accommodate these changes dynamically we made changes in the existing AOMDV protocol and proposed a dynamic and robust event driven routing protocol as described below.

Proposed Changes to AOMDV

The plan is therefore to enhance AOMDV to support а dynamic event-driven system as detailed in this paper. The first issue is that the routes may change due to the change in status of the individual nodes, it is necessary to allow HELLO messages, which are used to detect link changes, to not just monitor links but to fully indicate the status of the node at the other side of the link. So in this case, HELLO messages would also indicate whether or not it is raining on the other end, the network load as well as the power left in the system. A key piece of data is whether or not а node is able to route data on behalf of other nodes. As explained before, if а node is at the center of а downpour, its data is probably more important than the data of its neighboring nodes so it should not route data on behalf of other nodes. In such а situation, the node should also not respond to routing request (RREQ) messages, which are used to discover routes to individual destinations. In addition, though HELLO messages will be sent periodically, it is necessary to have another message type which can be sent immediately in response to sudden environmental, link, or node changes. These messages are called STATUS messages and are sent to neighboring nodes. For example, when а node first detects rain, it will send а STATUS message which is picked up by other nodes. By storing this information from various nodes, it would be possible to detect where the rain is falling in the sensor network.

STATUS messages will cause routes to the central server to be re-evaluated. Let us consider the case depicted in Figure 2. If node A that is not affected by rain was using а route to the central server via node B and node A now receives а STATUS message from node B saying that it has detected rain; then node A, which is not rain-affected, should no longer send data through node B if possible, since, for irrigation purposes, the data being generated by node B is more important.

Node A should look for another route back to the server using other non-affected nodes. This would suggest that routes may have priorities based on the importance of the data being routed relative to the data being generated. In this case, node A will downgrade its route through node B, resulting in other routes through non-affected nodes being favored. This is illustrated in Figure 2.

If rain is detected by both nodes, A and B, both nodes will send each other their absolute measurements as well as relative changes in the soil moisture content. Nodes with less relative soil moisture content changes which indicate less rain will downgrade routes through regions with high relative soil moisture content changes. So data will be routed away from the most rain-affected areas towards the least rain-affected areas.

C++ language compiler has been used to modify the source code of AOMDV, this modification consists of several enhancements for the current AOMDV protocol. In the following, Algorithm 1, we describes the modification:

Algorithms 1

if (event == NO_RAIN)

begin

//use standard AOMDV

end

else

if (event == RAIN)

begin

sendBrodcastRainPacket(node_id);

Disable_hello();

limit_response();

setPacketPriority(1);

end

else if (event == END_RAIN)

begin

Enable_Hello();

replyto_response();

setPacketPriority(0);

end

In the above Algorithm 1, when we detect rain we broadcast “node_id”, disable “hello” messages and set packet priority to 1 for the rain affected node.

When a node is affected by rain it will receive a rain event, this event triggers a rain STATUS broadcast message. Every node that is adjacent to this node will receive this packet. The affected nodes will still send HELLO messages but stop responding to RREQ messages, this will prevent the neighboring nodes from seeing it and sending their data through the affected node. Finally, we implemented a simple priority for the packets that are originated from the affected node; all packets that are sent from this node will have a greater value for its QoS value in the IP header.

If the event ends, the node will return to its normal activity, it will send HELLO packets normally and continue to respond on the RREQ packets and finally sets the QoS value to its normal value.

Algorithms 2

if (packet.type == RAIN_PACKET)

begin

for each(r in routing_table)

begin

if (r.nextHop == packet.source)

remove(packet.source);

end

end

In the above Algorithm 2, when an adjacent node receives a rain packet it will immediately remove all the next hops that this node is involved in. This will prevent any node from sending any data through this node.

4. Sensor Network Design

4.1. Monitoring Goals

Our proposed wireless sensor network will be used to monitor spatial variations in soil moisture as well as detect the presence of rainfall over time. Our experimental Smart Grid testbed is set up in Jordan monitored surface soil moisture and presence of rainfall. Our long term objective is to monitor soil moisture regularly so as to implement targeted irrigation techniques. The data we gather from our system will also be used for managing the irrigation resources throughout Jordan by providing improved guidelines for the Jordan irrigation management model.

The reactivity of the system should be also very high to detect the occurrence of the event as soon as possible, as in this case, rainfall. When such an event is detected the data or sensor readings should be sent to the base station reliably and quickly and for this reason we need to select the right routes. This data should be sent to the base station at a higher priority than all other data being sent [30].

Wireless systems are likely to face errors as the environment in which these sensors are deployed are harsh environments which might have severely dry conditions and can affect their performance. Hence we need a very reliable system which ensures that information is correctly and accurately routed to the base station. The sensor network must also ensure heavy data flow in case of rainfall so that no routes or links are overwhelmed with data. We need to manage the information flow and to also reduce redundancy from data to reduce traffic.

Finally, since there are always energy crises in the case of wireless sensor networks, we need to carefully plan each activity to maximize battery life and also take advantage of the high duration of sunlight available in the Middle East Region. Hence we make use of the solar-powered WSN nodes by which the problem is somewhat lessened. We still need power management as a lot of data will be sent when a wireless node is experiencing rainfall and it needs to send a lot of information and a lot of power will be required at this time. Hence the sensor network needs to strike a perfect balance and trade-off between the power left and the information required to be sent.

We need an extended WSN lifetime for the soil moisture monitoring system, because we cannot afford to breakdown the data routing operation during a rainfall event when we need to respond quickly to the change in the soil moisture level. We are using ZigBee medium range communication module standard, which is based on the IEEE 802.15.4 [31], which has a lot of advantages such as: consumes less power, also saves power as it has sleep mode, has a large capacity network, is more reliable and has low cost of related components [23,32]. The authors in [33] have proposed to reduce energy consumption by using a routing algorithm which is a combination of Ad hoc On-Demand Distance Vector Routing Junior and the Cluster-Tree technique. However, there is no practical implementation for all these research initiatives. In our system, power is directly saved by using priority based routing algorithm hence reducing the data at times of raining event when a lot of data is produced. However, even after raining data should be sampled more frequently in order to keep track of the soil moisture.

4.2. WSN Architecture

At each sensor nodes we have a soil moisture sensor and rainfall sensor attached to it. Our sensor network is based on Libelium Waspmotes sensor nodes and ATmega1281rds Microcontroller [34]. It is connected to following components:

• Wireless Interface (Waspmote XBee based on IEEE 802.15.4 standard)
• Soil moisture sensor (Watermark 200SS)
• Rainfall sensor (Libelium Weather Station WS 3000)
• USB-PC Interface (Waspmote Gateway)
• Solar Panel (Waspmote rigid solar panel 7 V-500 mA)
• 6600 mA Li-Ion rechargeable batteries

All the sensor nodes are connected to the base that is a computer using a USB-PC gateway. All the nodes act as sampling nodes and hence have both soil moisture sensor as well as rainfall sensor attached to them. The current network deployment has four sampling nodes, but more generally the architecture supports many nodes [34].

Zigbee RF nodes are used as communication models to transmit the sampled data to the gateway, these can have the best average lifetime of 8 years using dual batteries 3 V, at 3000 mAh. Some studies like [31], show that ZigBee model based on IEEE 802.15.4 standard with correct topology can last up to 10 years. Hence we are using ZigBee communication model for our research.

4.3. WSN Working Principle

The objective of our research is to provide a dynamic and robust event driven protocol for soil moisture monitoring so that the results can be used in the future to manage irrigation resources throughout Jordan. The overall data flow of our system comprises of (1) sampling soil moisture and rainfall data readings at predefined time intervals based on particular events; (2) sending sampled data to the gateway node; (3) sending the data from the gateway node to the base station; (4) moving to sleep mode; and (5) waking up and running whole process again. We use a mesh topology for network connectivity because of its advantages in our application scenario. Mesh topologies are able to route data and messages to the final gateway node through several different nodes. Even if the connection to any RF node is lost because of any environmental tragedy or loss of power, etc. still all the important data can reach to the gateway node and the base station due to the mesh topology.

Each sensor node is directly connected to the other nodes and also to the gateway node and also synchronized to each other so that they send data simultaneously after 3 h. When there is rainfall the sensor node which is affected by the event sends a STATUS message to all nodes indicating that it is receiving rainfall, and hence the priority of the messages of this node to is increased and this gives it precedence to use routes until there is no longer any rain.

4.4. Hardware Design

(1) Sensor Nodes. We are using Waspmote WSN which is an open source wireless sensor platform the speciality of which is implementing sensor nodes having low power consumption capability [31]. Hence, our sensor nodes can work autonomously, working on battery power and having a maximum lifetime of 7–8 years [35] based on the cycle of operation, communication protocol and the communication module used. The architecture of Waspmote is based on the Atmel ATMEGA 1281 microcontroller. The Atmega1281 microprocessor is based on the high-performance group of Atmel 8-bit AVR RISC based microcontrollers [34]. Its advantages are low power, high performance and advanced architecture based on RISC which has a maximum of 20 MIPS throughput and 23 𝐼/𝑂 lines.

The technique used by Waspmote to save energy is called blocking in which the program is blocked in sleep mode, until an event occurs which causes interrupts and then the program is executed. This way when an interrupt occurs, only then are the associated functions executed, thus saving energy.

As shown in Figure 3, Waspmote has a mechanism to set an absolute time by using real time clock (RTC) which runs at 32 KHz. We have total control over when the mote wakes up from sleep or hibernate mode to record values and perform other programming actions. This RTC also allows the Waspmote to work in the maximum energy saving modes when in Deep Sleep and the Hibernate modes and to wake up right at the correct moment. We are using the XBee-802.15.4 RF communication modules which have a firmware (DigiMesh). With the help of this firmware they create mesh networks instead of the usual Star topology networks.

This RF module has a long range of 7000 m but lower power consumption than Wi-Fi (802.11). It operates at a very low data rate of 250 kbps at 2.4 GHz [36,37]. These modules have mechanism to extend battery life by using sleep modes.

(2) Soil Moisture Sensor. The Soil Moisture Sensor [38] is one of the most important component in our research on which the efficiency of our study heavily relies. There were many soil moisture sensors available and each had its advantages based on accuracy, and soil texture, cost and reliability, and we chose, the Watermark 200SS [38] developed by Irrometer since it satisfied most of the above criteria. It has very satisfactory features like stable calibration, a measurement range from 0 to 239 cb (kPa), it has no soil dissolvability, can withstand freezing temperatures, and is low cost and low maintenance [38].

The WATERMARK sensor as shown in upper part of Figure 5, uses a resistance device that measures response to changes in soil moisture. After it is planted in the soil it works by exchanging water in the soil to stay in equilibrium using the electrical conductivity of water. When there is more moisture then the water increases in the sensor, thereby decreasing resistance and when the soil is dry, water in the sensor becomes low, thereby increasing resistance measurement. This features enables the sensor to have a stable and consistent calibration and it does not require recalibration for every installation. Figure 4 also shows the soil moisture sensor used in this study.

(3) Rainfall Sensor. The rainfall sensor is a part of the Weather Station WS-3000, shown in Figure 5, which comprises of an anemometer, a wind vane, and a pluviometer [39]. The Weather Station is placed above ground on a pole and connected to the WSN sensor node. Our study is only concerned about pluviometer readings which provides a digital signal whose frequency is directly proportional to the intensity of rainfall. We use the rainfall intensity in our research to control the operation of the WSN. The pluviometer has a small bucket that, starts to fill when the rainfall starts, it has a capacity of approximately 0.28 mm of water. When it is completely filled, its switch is closed and it is automatically emptied. A digital signal is produced as a result whose frequency which is proportional to rainfall intensity. It has an inbuilt function which returns rain intensity per minute. An interrupt is triggered in the microprocessor as soon as the start of rainfall is detected.

(4) Battery and Solar Panel. Our WSN Waspmote nodes will be deployed in remote areas hence they need to be self-sustained in power. To fulfil our power requirements, we use rechargeable Li-ion batteries and external solar panels to power each Waspmote deployed in the fields. The Li-ion battery has the capacity of 6600 mAh and the voltage of 3.7 volts. The external solar panel has a rating of 7 V-500 mA which is used to recharge the batteries.

4.5. Software Module

We use Digi XCTU v.6.3.0 software to implement our WSN testbed. It is a free, multi-platform, Next Generation Configuration Platform for XBee/RF Solutions [40]. Apart from these it has lot of other advantages like simple graphical network view for network architecture and configuration which also shows signal strength for each connection. It also has API frame builder for building XBee API frames. It is easy to set up, test and configure for XBee. It has following features [40]: Management and Configuration of multiple RF devices or remote devices which are connected over the air. It has a firmware update feature which automatically restores all module settings, handling all the changes. We can save our console sessions and load them in any PC running XCTU at any time.

We can deploy XCTU on multiple platforms as it is compatible with the most-used operating systems, like Microsoft Windows, Linux, and Mac OS. We can discover our local and remote radio modules automatically which are connected to our PC, regardless of their port connections or configured settings. We can explore our complete RF network by visualizing its topology and by displaying all network nodes and connections graphically or in a table.

5. Testbed and Simulation Results

5.1. WSN Testbed Setup

We setup our testbed in a garden in Jordan. The current network deployment has five nodes, which are 5 m apart from each other, but more generally the architecture supports many nodes [15]. In our protocol, the sensor data are sampled for 10 s after every 3 h, when there is no rainfall. During these 3 h the sensors are in sleep mode to save energy and after the data is sampled they again go to sleep mode for another 3 h. If we have rainfall event, the data is sampled after every 1 s for the sensor node experiencing the rainfall event. That means the affected nodes are up for 10 s and down for one second. In our protocol we also increase the priority of this affected node to transfer data to the base station through the gateway. All the other sensor nodes where there is no rainfall still keep sampling after every 3 h.

The setup of this scenario consists of 5 wireless nodes from node 0 (N0) to node 3 (N3), as shown in Figure 6 and one gateway node (GW) which is connected to the server. We will have two constant bit rates (cbr) streams, one from node 0 and the other from node 2. The destination for both streams will be gateway node (GW). We will call them cbr0 and cbr2 respectively. According to AOMDV protocol, cbr2 traffic will go from node 2 to node 0 then node GW, and cbr0 traffic will go to node GW directly. Node 2 traffic, cbr2 will go through two paths, the primary one through node 0 and the secondary through node 1. After three h during sending packets, node 0 is affected by RAIN (which is the event).

Table 1. Routing table before rain being detected at node 0.

N0			N1			N2
Dest No.	Nxt hop	Hop cnt	Dest No.	Nxt hop	Hop cnt	Dest No.	Nxt hop	Hop cnt
3	3	1	3	3	1	3	3	1
GW	GW	1	GW	GW	1	1	1	1
1	1	1	2	2	1	0	0	1
2	2	1	0	0	1	GW	1	2
							0	2
N3			GW
Dest No.	Nxt hop	hop cnt	Dest No.	Nxt hop	Hop cnt
1	1	1	0	0	1
2	2	1	1	1	1
0	0	1	2	0	2
GW	1	2		1	2
	0	2	3	0	2
				1	2

and

Table 2. Routing table after rain being detected at node 0.

N0			N1			N2
Dest No.	Nxt Hop	Hop cnt	Dest No.	Nxt hop	Hop cnt	Dest No	Nxt Hop	Hop cnt
3	3	1	3	3	1	3	3	1
GW	GW	1	GW	GW	1	1	1	1
1	1	1	2	2	1	0	0	1
2	2	1	0	0	1	GW	1	2
N3			GW
Dest No.	Nxt Hop	Hop cnt	Dest No.	Nxt Hop	Hop cnt
1	1	1	0	0	1
2	2	1	1	1	1
0	0	1	2	1	2
GW	1	2	3	1	2

show the result of routing table before and after rain is detected at node 0, the routing table for node 2 and 3 has been changed which take another route through node 1 instead of the primary one through node 0 to send data to GW (destination) because node 0 is affected by RAIN. Hence node 0 has very important data (soil moisture) and it has to send it first and should take the highest priority to send data.

5.2. Simulation Setup

To show that our proposed protocol is also scalable we used simulation tools for 5 node scenario and for a very large scenario consisting of 30 nodes. The source code of the simulation is written in TCL language and runs the simulation example on ns-2.35 Linux Ubuntu version 12.

For 5 node setup, we use standard AOMDV in first period from 0 to 900 in second one from 900 to 2000 we use the modified version of AOMDV.

An AWK script was built to calculate the average of Throughput and End to End Delay on node 0 and node 1 before and after node 1 affected by raining. The highest priority data stream will grant to cbr1 coming from node 1 because it affected by rain and it has important data that should be send to the destination node 2. Rerouting cbr0 coming from node 0 traffic through node 4 which has data with low priority. In this way we reduce forwarding load on node 1 that means the throughput and end to end delay will be better on cbr1 after node 1 affected by rain. The Simulation Scenario Environment is shown in

Table 3. Simulation Scenario Environment.

S#	Parameter Variables	Five Nodes Associated Values	30 Nodes Associated Values
1	Simulation Tool	Ubuntu 12 + NS 2.35	Ubuntu 12 + NS 2.35
2	Propagation	TwoRayGround	TwoRayGround
3	MAC Type	Mac/802_11	Mac/802_11
4	Interface Queue	Queue/DropTail/PriQueue	Queue/DropTail/PriQueue
5	Physical Wireless Data speed or Bandwidth Rate	11 Mbps	11 Mbps
6	Antenna Type	Antenna/OmniAntenna	Antenna/OmniAntenna
7	Packet Queue Size	50	50
8	Total Number of nodes	5	30
9	Base Protocol	AOMDV	AOMDV
10	Optimization Algorithm	Rain Optimization	Rain Optimization
11	X dimension of Topography	797
12	Y dimension of Topography	595	595
13	Simulation Time	2000	2500
14	No of rain affected Nodes	1	5
15	Packet size	1000	1000
16	CBR Bandwidth rate	0.05 Mbps	0.05 Mbps, 0.1 Mbps and 0.5 Mbps
17	traffic generation starts at	100.0 ms	100.0 ms

.

For the complex scenario consisting of 30 nodes, we calculate that 5 out of 30 nodes were affected by rain and measure the performance and the energy consumption.

There are 30 wireless nodes from node 0 to node 29 distributed with fixed location across the grid as shown in Figure 7. We will have two constant bit rates (cbr) streams one from node 0 and one from node 1 the destination for both streams will be node 29 (GW) we will call them cbr0 and cbr1 respectively. According to AOMDV protocol cbr0 traffic will go through the path node 0 -> node 1 -> node 2 -> node 13 -> node 4 -> node 15 -> node 6 -> node 17 -> node 18 then node 29, and cbr1 traffic will go through the same path.

The five nodes which are affected by rain are 1, 12, 16, 21, 25. This means that node 0 or 1 will use secondary paths when any node in the primary path is affected by RAIN.

Simulation time is 2500 ms, we set up the constant bit rate (cbr) with variable rate values depending on rain level. For example, when it is raining lightly, the (cbr) rate will be 0.05 Mbps, when rain becomes heavier, the (cbr) rate changed to 0.1 Mbps and, finally, when flood occurs, the (cbr) rate changes to 0.5 Mbps. Packet size for all (cbr) is 1000 byte.

5.3. Performance Measurements

5.3.1. Performance Measurements for 5 Node Simulation Setup

An AWK script was built to calculate the average of Throughput and End to End Delay on node 0 and node 2 before and after node 0 was affected by rain. Before rainfall we used the standard AOMDV protocol and after the rainfall we used our modified AOMDV protocol to compare its performance with the standard AOMDV. The highest priority data stream will be granted to cbr0 coming from node 0 because it is affected by rain and it has important data that should be sent to the destination GW. We re-routed the cbr2 coming from node 2 traffic through node 1 which has data with low priority. In this way we reduce forwarding load on node 0, that means the throughput and end to end delay will be better on cbr0 after node 0 is affected by rain because less traffic is now going through that node.

The results listed in

Table 4. Performance Measurement before and during the time when node 0 is affected by rain.

Type/Protocol and Time	Standard AOMDV 3 h before Rain	Modified AOMDV 3 h after Rain
Total Sent Size from cbr2	5000 kbit	3749 kbit
Total Sent Size from cbr0	4375 kbit	6874.7 kbit
End-to-End Delay (cbr2)	256,910 ms	349,410 ms
End-to-End Delay (cbr0)	16,210 ms	5.67 ms
Throughput (cbr2)	2.65 kbps	3.70 kbps
Throughput (cbr0)	4.20 kbps	6.20 kbps

clearly show improvement of Throughput and End to End Delay on cbr0 coming from node 0 which validate our assumptions and it showing that the event-driven approach does improve overall network efficiency.

5.3.2. Performance Measurements for 30 Node Simulation Setup

Before rainfall we used the standard AOMDV protocol and after the rainfall we used our modified AOMDV protocol to compare its performance with the standard AOMDV. In this simulation scenario we divided the simulation period depending on raining level, for instance with no rain the period from 0 to 900 s, light rain period from 900 to 2000 s and heavy rain from 2000 to 2500 s.

An AWK script was built to calculate the average of Throughput and End to End Delay on node 0 and node 1 before and after node 1 is affected by rainfall. The highest priority data stream will be granted to cbr1 coming from node 1 because it is affected by rain and it has important data that should be send to the destination node (GW). We reroute cbr0 coming from node 0 traffic through node 10 which has data with low priority. In this way we reduce forwarding load on node 1, which means that the throughput and end to end delay will be better on cbr1 after node 1 affected by rain.

Node 1 is affected by two levels of rain light rain and heavy rain, so we compared the Throughput and End to End Delay in two levels.

The results listed in

Table 5. Performance measurements before and during the time when node 1 is affected by rain.

Type/Rain-Level (Time)	Light Rain-0.05 Mbps (0–900) s	Heavy Rain-0.1 Mbps (900–2000) s	Very Heavy Flood-0.5 Mbps (2000–2500) s
Total Sent Size from cbr0	5000.1 kbit	6875.4 kbit	18,746 kbit
Total Sent Size from cbr1	4375 kbit	13,748.7 kbit	18,750.2 kbit
End-to-End Delay (cbr0)	18.78 ms	18.79 ms	4465.59 s
End-to-End Delay (cbr1)	16.62 ms	16.50 s	16.42 ms
Throughput (cbr0)	5.56 kbps	6.25 kbps	3.75 kbps
Throughput (cbr1)	4.86 kbps	12.50 kbps	37.50 kbps

clearly show improvement in Throughput and End to End Delay on cbr1 coming from node 1 which validates our assumptions and it shows that the event-driven approach does improve overall network efficiency.

Figure 8 shows the throughput of Node 1, separately being affected by rain. The reason behind this increase in throughput is that at heavy and very heavy rain, we use the modified AOMDV protocol.

5.4. Energy Consumption

We measured the energy consumption for the WSN testbed and also for simulation networks. Before rainfall we used the standard AOMDV protocol and after the rainfall we used our modified AOMDV protocol to compare the energy consumption of our proposed protocol with the standard AOMDV. Before rainfall all the nodes sent the sampled data every 3 h and use multiple routes to send data to the gateway node. When there is no rainfall, HELLO messages are being sent but after rainfall is detected at any node, it sends STATUS messages to other nodes and stops sending HELLO messages, as a result no data is now sent to the affected node and its priority to send data also increases. By rerouting, the data sent to the affected node is greatly reduced hence the receiving energy is also reduced significantly. The affected node now sends data after every 1 s, this operation is continued as long it is raining. Hence when it is raining the affected nodes are receiving very less data and have just their own data to send, the overall energy for the affected nodes also decreases significantly.

We measure the energy consumption in three modes for each sensor node, idle mode, receiving mode and transmitting mode. The energy consumed in idle mode is called idle energy (Idle Energy). The energy consumed by a node in transmission of data is called transmission energy (Trans Energy) and the energy consumed by a node to receive data is called receiving energy (Rec Energy).

When a node is affected by rain it will receive a rain event, this event triggers a special broadcast rain packet called STATUS message. Every node that is adjacent to this node will receive this packet. The affected nodes will still send HELLO messages but stop responding to RREQ messages, this will prevent the neighboring nodes from seeing it and sending their data through the affected node.

Hence, the nodes affected by rainfall will not receive any packets from other nodes and hence they will require very less receiving energy, on the other hand they will just have their own data to transmit, hence the transmission energy also decreases.

5.4.1. Energy Consumption for 5 Node WSN Testbed

The Waspmotes consumes 15 mA of energy per hour in switched on state and just consumes 55 µA of energy per hour in sleep state [41]. We have designed our protocol to be energy-efficient. In our protocol sensor data under normal events are sampled for 10 s after every 3 h and sent to the server. When we measured energy consumption for our protocol it was found that, it only consumes 0.004 mA of energy per hour. If we have a rainfall event we implement second scheme under which we sample the data for 10 s after every 10 s, only for the sensor node experiencing the rainfall event, since the soil moisture may change very rapidly. In second scheme, when there is a rainfall our protocol consumes only 0.042 mA of energy per hour for the effected node, which is also very less than the default energy consumption of 15 mA per hour for the Waspmote [41]. Hence, our protocol is also energy efficient.

As shown in

Table 6. Energy Measurements before node 0 affected by rain (Standard Ad hoc On-Demand Multipath Distance Vector (AOMDV)).

Node No.	Idle_Energy Mili Ampere	Rec Energy Mili Ampere	Trans Energy Mili Ampere
GW	0.0275	3.75	3.75
0	0.0272	4.35	3.1
1	0.0271	4.33	3.3
2	0.0269	3.21	4.31
3	0.0270	3.31	4.35

and

Table 7. Energy Measurements during rainfall on node 0 (Modified AOMDV).

Node No	Idle Energy Mili Ampere	Rec Energy Mili Ampere	Trans Energy Mili Ampere
GW	0.0275	4.21	2.05
0	0.0265	1.02	2.64
1	0.0260	3.01	2.76
2	0.0245	1.82	1.67
3	0.0210	1.79	1.46

the energy measurements in mA taken after rainfall when we use modified AOMDV, are less than those taken before rainfall when we use standard AOMDV, for both received energy (Rec Energy) as well as transmission energy (Trans Energy) because the nodes affected by rainfall will not receive any data from other nodes and hence they will require very less receiving energy, on the other hand they will just have their own data to transmit, hence the transmission energy also decreases. We also show these results in Figure 9 and Figure 10.

5.4.2. Energy Consumption for 30 Node Simulation Setup

This section of our paper is concerned about the energy consumptions for all nodes before the nodes are affected by rain, when the nodes will use the standard version of AOMDV and after the nodes are affected by rain when they will use the modified version of AOMDV, the calculation of total energy has been done during the simulation periods for each cases before and after the nodes affected by rain.

The total energy consumed has been calculated for all nodes before and after the nodes were affected by rain for the three simulations. Also, we calculated the rate of decrease in consumed energy before and after the nodes are affected by rain.

Table 8. Energy Measurements before node 1 is affected by rain.

Node No.	Total Energy	Idle Energy	Tran Energy	Rec Energy
	(Joules)	(Joules)	(Joules)	(Joules)
1	218,940,000.00	191,000,000.00	4,140,000.00	23,800,000.00
12	35,506,380.00	30,100,000.00	26,380.00	5,380,000.00
16	35,726,423.20	29,300,000.00	26,423.20	6,400,000.00
21	23,737,540.90	20,700,000.00	17,540.90	3,020,000.00
25	23,817,550.60	19,100,000.00	17,550.60	4,700,000.00

and

Table 9. Energy Measurements during rainfall on node 1.

Node No.	Total Energy	Idle Energy	Tran Energy	Rec Energy
	(joules)	(joules)	(joules)	(joules)
1	140,710,000.00	123,000,000.00	1,310,000.00	16,400,000.00
12	23,851,969.88	20,300,000.00	1969.88	3,550,000.00
16	27,722,152.14	22,800,000.00	2152.14	4,920,000.00
21	15,771,225.74	13,800,000	1225.74	1,970,000
25	16,011,241.87	12,900,000	1241.87	3,110,000.00

clearly show that of consumption energy for affected nodes before is greater than energy consumption after rainfall starts. As we can see from the ‘Total’ columns in both tables, the total energy consumed decreases for all the nodes and the decrease in energy is much greater for the nodes affected by rainfall. The idle energy, transmission energy as well received energy decreases for all the nodes. The largest decrease in total energy is due to the decrease in transmission energy.

We calculate total energy consumed by all the nodes that are affected by rainfall.

The total energy for node (k) = $idle\_energy\left(k\right)+trans\_energy\left(k\right)+recv\_energy\left(k\right)$

The total energy for all affected nodes = ${{\displaystyle \sum }}_{k=0}^n\mathrm{idle}\_\mathrm{energy}\left(\mathrm{k}\right)+trans\_energy\left(k\right)+recv\_energy\left(k\right)$

We calculated the total consumed energy for all affected nodes before rains as = T-energy-before = 337,727,894.70.

And total consumed energy for all affected nodes after rains = T-energy-after = 224,066,589.63.

Therefore, the consumed energy decreasing rate = (T-energy-before/T-energy-after) %

Rate of decrease in Consumed energy (affected nodes) = 51%

We can clearly observe that the energy consumptions for all nodes affected by rain has decreased sharply as shown in Figure 11, also the energy consumptions on all nodes has decreased. The main reason for this decrease is that we stop sending data from any neighbors through the node that is affected by rain. Hence, the nodes affected by rainfall will not receive any data from other nodes and hence they will require very less receiving energy, on the other hand they will just have their own data to transmit, hence the transmission energy also decreases.

The above figure is showing energy consumption by 5 nodes before and after they are affected by rain. Again our modified AOMDV clearly outperforms the standard AOMDV in terms of energy consumption.

The energy consumption for all the non-affected nodes and nodes neighboring the affected nodes has also decreased. This is due to the fact that the before rainfall there were many routes to send data. However, after rainfall the affected nodes do not receive data from neighboring nodes, hence there is less traffic from the neighboring nodes. So the energy consumption for the non-affected nodes and the nodes neighboring the affected nodes also decreases.

6. Conclusions

This paper outlined design, deployment and evaluation of our reactive, robust and enhanced version of AOMDV protocol. Our event driven enhancements mean that our protocol not only increases the performance but also makes it energy efficient as the energy consumption is considerably reduced for the nodes experiencing the rainfall and also in general because we use the sleep mode when it is not raining. We also successfully showed in simulation results that our enhanced AOMDV protocol is scalable. We compared its performance with prior AOMDV protocol. For our proposed protocol the results clearly show that it reduces average delay while at the same time increases the throughput of the nodes being affected by rain. The enhanced throughput and low delay clearly indicates that the proposed changes to AOMDV to support events such as rain would be a significant and meaningful addition to AOMDV which can be used in several WSN applications.