## 4 Taxonomy of the Existing Multipath Routing Protocols
### Concurrent Multipath Routing
#### Energy-Efficient Multipath Routing Protocol
If the received _request_ message causes an update operation on the routing table, the receiver node should rebroadcast the _request_ message. This process is continued until the _request_ message is received by a sensor node that can provide sink node with the requested data. At this time, source node starts packet transmission towards the sink node through the shortest discovered path. In order to address the mutual interference problem between adjacent paths, all the intermediate nodes along the active path should notify their neighboring nodes to act as the passive nodes in order to prevent them from participating in any route discovery process. Therefore, during the data transmission process, intermediate nodes that receive a data packet should send a _bepassive_ message to all of their neighboring nodes except their next and previous-hop neighbors along the active path. Using this mechanism, whenever an additional path should be constructed (to provide sufficient bandwidth for data transmission), passive nodes are unable to respond to any _request_ message. This protocol eliminates the negative effects of wireless interference by putting some nodes in the passive state. Simulation results confirm that MR2 improves the overall data reception rate at the sink node more than 70% and 30% compared to a multipath routing approach without interference-awareness and a single-path routing scheme, respectively. Still, this protocol suffers from two main drawbacks: first, MR2 is only suitable for query-driven applications; second, the utilized flooding strategy for constructing non-interfering paths imposes a high control overhead. _Energy-Efficient and Collision-Aware Multipath Routing Protocol (EECA)_[25] is an on-demand multipath routing protocol and uses the location information of all the sensor nodes to establish two collision-free paths between a pair of source-sink nodes. EECA aims to reduce the negative effects of wireless interference through constructing two paths in both sides of the direct line between the source-destination pair. Furthermore, the distance between these two paths is more than the interference range of the sensor nodes. This is demonstrated in Figure 13. In the first stage of the route discovery process, the source node checks its neighboring nodes to find two distinct groups of the nodes on both sides of the direct line between the source-destination pair. Figure 13 represents these two groups with white and gray circles. After finding these neighboring sets, the source node broadcasts a _Route-request_ packet towards these nodes to establish two node-disjoint paths. During the route discovery process, intermediate nodes utilize the same technique (used at the source node) to select their next-hop neighboring nodes and broadcast the received _Route-request_ packet towards the sink node. Upon reception of a _Route-request_ packet by an intermediate node, the receiver node uses a back-off timer to restrict the overhead introduced by the route discovery flooding. Before broadcasting the received _Route-request_ packet by the intermediate nodes, they set a back-off timer according to their distance from the sink node and their residual battery level. Neighboring nodes with higher residual battery and shorter distance to the sink node select shorter back-off timer. Therefore, at each stage of the _Route-request_ flooding only one node wins to broadcast its received _Route-request_ packet towards the sink node. Upon reception of the _Route-request_ packet at the sink node, it sends a _Route-reply_ packet in the reverse path towards the source node. When the source node receives a _Route-reply_ packet, it can transmit its traffic through the established path. Although EECA tries to discover the two shortest paths such that their distance from each other is more than interference range of the sensor nodes, it needs the nodes to be GPS-assisted and relies on the information provided by the underlying localization update method.