Firstly, I would like to briefly walk you through the nature of the original DSR protocol:
This protocol is truly based on source routing whereby all the routing information is maintained (continually updated) at mobile nodes.
It has only 2 major phases which are Route Discovery and Route Maintenance.
Route Reply would only be generated if the message has reached the intended destination node (route record which is initally contained in Route Request would be inserted into the Route Reply).
To return the Route Reply, the destination node must have a route to the source node. If the route is in the Destination Node's route cache, the route would be used. Otherwise, the node will reverse the route based on the route record in the Route Reply message header (symmetric links).
In the event of fatal transmission, the Route Maintenance Phase is initiated whereby the Route Error packets are generated at a node. The erroneous hop will be removed from the node's route cache, all routes containing the hop are truncated at that point. Again, the Route Discovery Phase is initiated to determine the most viable route.
Proposal of my T-DSR:
At the moment of research, DSR is not yet a power-aware routing protocol. This feature could be implemented in ns-2's DSR whereby the routing protocol will only pick the mobile nodes with sufficient battery power for during route construction.
Improvement to the Route Reply process: I notice that the main drawback of this protocol the lack of support for alternative route in transporting the Route Reply message. This can be done by implementing the inter-Route Discovery feature during the Route Reply process. This is considered as an innovation to improve the performance of DSR. Somehow, I am still working around of realising the Theorectical Model into the C++ routing protocol. Another key issue that might be arising would be the enormous flood of the packets during route discovery. This is because at the same time there might be other mobile nodes in the same network initiating Route Discovery as well. Consequently, there must be a solution to reduce packet flooding and increase higher hit rate.
Restructural of Route Maintenance, instead of sending a route error message back to the source node, the intermediate node should at least probe for available intermediate nodes which is able of joining the broken route temporarily to transport the data packet to the destination node. Should the temporary route does not exist, generate route error back to the source node or the data packet has been sent to the destination node through the temporary route, generate route error back to the source node and initiate route discovery again to look for viable route. (Note: The temporary route will always be the critical route which might have longer hops to reach the destination).
Causes of Broken Link/Destination Unreachable
intermediate nodes moved away from the line of transmission of other mobile nodes which is involved in routing information,
intermediate nodes is busy transmitting other data packets for other source nodes,
route looping whereby the data packet looping around and yet has not reached the destination node.