## 3 Solution Approach
### Proposed Changes to AOMDV  
The plan is therefore to enhance AOMDV to support a 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 a node is able to route data on behalf of other nodes. As explained before, if a node is at the center of a 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 a situation, the node should also not respond to routing request (RREQ)  
Figure 1: Sensor Network forming mesh. 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 a node first detects rain, it will send a 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 a route to the central server via node B and node A now receives a 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:  
Figure 2: Routing decisions made based on external events. ```
if(event==NO_RAIN) begin //use standard AOMDV end if else if(event==RAIN) begin  sendBrodcastRainPacket(node_id);  Disable_hell0();  limit_response();  setPacketPriority(1); end else if(event==END_RAIN) begin  Enable_Hello0;  replyto_response();  setPacketPriority(0); end
```  
**Algorithms 1**  
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.