RPSF: A Routing Protocol with Selective Forwarding for Mobile Ad-Hoc Networks

1. RPSF: A Routing Protocol with Selective Forwarding for Mobile Ad-Hoc Networks Jiang, Finkel, Manivannan and Singhal.

2. Outline • Introduction • Related work • Our Routing Protocol • Performance of our Protocol • Future Work

3. Introduction • A Mobile Ad Hoc Network (MANET) consists of a set of mobile hosts that can form a network automatically without the aid of any infrastructure or human intervention. • MANETs have applications in the areas of battlefield environments, disaster recovery, etc.

4. Introduction – routing in MANETs • In MANETs, when a node wants to communicate with another node, a route needs to be established • Since nodes are mobile, established routes can break anytime • Depending on how the routes are established, routing protocols can in general be classified into three classes.

5. Types of routing protocols • Routing protocols for MANETs can be classified into three categories • Proactive Routing Protocols : Compute and maintain all the routes needed all the time • Reactive Routing Protocols : Compute routes between nodes only when they are needed • Hybrid Routing Protocols: Use a combination of reactive and proactive approaches to discover routes

6. Problems with existing reactive routing protocols • Many of the existing reactive routing protocols flood the entire network with route-request messages in order to find a route to the destination • This can cause propagation of redundant route request messages; our goal is to address this issue and propose a solution. • Can drain the battery of the hosts in the MANET • Can prevent data packets being delivered in time

7. Related work – AODV • Ad hoc On-demand Distance Vector routing (AODV) • Objectives • Provide unicast, broadcast, and multicast capability • Initiate route discovery only on demand • Disseminate changes in local connectivity to those neighboring nodes likely to need the information • Desired features • On demand route creation • Multi-hop path routing • Dynamic topology maintenance • Loop free routing

8. Related work – AODV contd. • Route table • Fields • Destination IP address • Destination sequence number • Hop count • Next hop IP address • Active neighbors • Expiration time • Each time a route entry is used to transmit data, the expiration time is updated to current time + active_route_timeout • Route entries may be updated if a route with greater sequence number or smaller hop count is discovered

9. Related work – AODV contd. • Route discovery • Source broadcasts RREQ • RREQ is a tuple of(srcId, srcSeq#, bcastId, dstId, dstSeq#, hopCount) • A node replies to a request if • It is the destination or • It has a “fresh enough” route to destination • Otherwise it rebroadcasts the RREQ • Nodes keep track of (srcId, bcastId) and discard redundant broadcasts Src Dst

10. Related work – AODV contd. • Forward path setup • The destination, or intermediate node with “fresh” route to the destination, unicasts RREP back to source • Nodes along the path create, forward route to destination • Source starts to send data after the first RREP arrives Src Dst

11. Related work – AODV contd. • Reverse path setup • Nodes update their route table with source node information before forwarding RREQ • Reverse path entry used to forward RREP back to source if one is received • Expiration time is long enough for a RREP to be received and forwarded Src Dst

12. Related work – AODV contd. • Path maintenance • Movement of nodes not along active path does not trigger protocol action • If source node moves, it can reinitiate route discovery • When destination or intermediate node moves, node upstream of broken link sends RERR messageto all active upstream neighbors • Source can reinitiate route discovery if route is still needed • RREQs for reinitiated route discovery contain destination sequence number one greater than last known number

13. Related work – AODV contd. • Node A moves to new location • Node C notices loss of link, sends RERR back to the source • The source reinitiates route discovery and finds new route to the destination through node B A Src Dest C B

14. Related work – AODV contd. • Local connectivity management • Node must periodically hear from active neighbors to know they are within range • Every time a node hears broadcast, it updates the lifetime of the route • If no broadcast within hello_interval, broadcasts Hello packet • Failure to hear from a neighbor for(1+allowed_hello_loss) * hello_lifetimeindicates loss of link

15. Our Routing Protocol - RPSF • Problems with AODV and many of the other reactive routing protocols • Need to flood RREQ messages which causes redundant retransmissions of route requests • Do not scale well • Results in high routing overhead • Our Objectives • Exploit direction and distance of neighboring nodes and design a new routing protocol that reduces propagation of redundant route request messages. • The protocol should not require the position information of all nodes but only of neighbors. • Our Solution: A Routing Protocol with Selective Forwarding (RPSF) for mobile ad hoc networks

16. RPSF - assumptions • Nodes can obtain direction and distance information of their neighbors (using smart antennas or GPS) • All nodes have the same transmission range • A message sent by any node can be heard by all its neighbors (promiscuous mode) • Nodes are mobile

17. The Flooding problem • Flooding in wireless networks can be modeled as unit disk cover problem • Each node lies at the center of a disk (circle) with radius equal to the transmission range R. • Nodes in the circle are neighbors of the node • Find the smallest set of nodes that are connected to each other by one or more wireless links, and every node in the network is covered by at least one node in the set

18. RPSF – basic idea behind flooding • Flooding messages in ideal case • The source node selects three forwarding nodes which are at distance R and 120o apart • Each selected node selects two forwarding nodes which are at distance R and 120o apart • Repeat the previous step until the network edge is reached

19. RPSF – basic idea cont. • Advantage of this approach • Optimal solution for flooding route requests or broadcasting messages • Problem with this approach • A node may not be able to always select such good nodes as its forwarding nodes because there aren’t any such neighbors. TX range:

20. RPSF – flooding in the general case • Criteria for a node n toselect forwarding nodes • Select as distant a node as possible within TX range • Select further nodes that are as far mutually apart as possible • Subject to the constraint that the angle made by any two successive nodes and n is at most 120o. This is relaxed if no node can be found Src TX range:

21. RPSF – flooding in the general case cont. • We need to further refine this to handle two exceptions • Exception 1: In the figure for example (A, B, C, D, x, y are the nodes), node y at the bottom may not be covered • Exception 2: In the figure (A, B, C, D, x, y are the nodes), node y at the top may not be covered.

22. RPSF – flooding in the general case cont. • Handling the exceptions • Rule 1 for handling Exception 1 • B may choose C first • Then it computes the shortest distance between nodes in sector <ABF and nodes in sector <BFC • If it is larger than transmission range R, then selects a node near BF as a forwarding node • Rule 2 for handling Exception 2 • A may choose B first • Then A checks if there is a node that lies in ∆ABG • If so, A selects such an x that is close to AB and A

23. RPSF – tables • Route request table • Seq, srcId, relayedFlag, directonList • Route table • dstID, nextHopInfoList (a list of pairs of next hop ID and corresponding hop count) • Neighbor information table • neighborID, direction, distance

24. RPSF – route discovery • Route discovery • Source broadcasts RREQ • RREQ is a tuple of(seq, srcID, dstID, hopCount, fwdID List) • A node can reply if • It is the destination or • It has better routes to destination • Otherwise, checks if it is a forwarding node • If so, it checks the directions from which it received the RREQ • If not all neighbors would have covered and did not relay the RREQ before, it rebroadcast the RREQ • Nodes keep track of (srcId, seq, and direction from which it received the RREQ) and discard redundant broadcasts Src Dst TX range:

25. RPSF – forward path setup • Forward path setup • The destination, or intermediate node with “better” route to the destination, unicasts RREP back to source • RREP is a tuple of(Seq, srcID, dstID, HopCount) • Nodes along path create forward route to destination • Source starts to send data after the first RREP arrives Src Dst TX range:

26. RPSF – reverse path setup • Nodes update their route table with source node information before forwarding RREQ • Reverse path entry used to forward RREP back to source if one is received Src Dst TX range:

27. RPSF – route maintenance • Nodes on a route may move • If the route is currently being used for data transmission • Then route recovery process is initiated • The node that needs to forward data will send a RRPR to its one hop neighborsRRPR: (AckFlag=false, theNodeId, dstId) • Neighbors that have valid route will send a RRPR back.RRPR: (AckFlag=true, theNodeId, dstId, hopCount) • After the node receives ack RRPR, it stores the new route, and starts transmitting data • Otherwise, initiates a route discovery for the destination if it does not receive an RRPR ack within in a specified time Src Dst TX range:

28. RPSF – simulation results • Simulator: GloMoSim • Simulation environment • Solaris, and Linux • IEEE 802.11 • Expanding ring for AODV • Network diameter: 35 • Threshold for search the entire network: TTL = 7 • Simulation code • The code for AODV is the one coming with GloMoSim 2.0.3 package • We implemented RPSF in GloMoSim

29. RPSF – simulation results cont. • Parameters • Scenarios • 1500m x 1500m with 100 nodes • 1500m x 1500m with 200 nodes • 1500m x 1500m with 300 nodes • 1500m x 1500m with 400 nodes • RREP timeout: 80xTTL ms • RPSF updates the direction and distance information of each node every 2 seconds • Mobility model – random-waypoint model • Speed range: 0 – 20 m/s • Pause time: 0, 30, 60, 90, 120, 200, 300, 500, and 900s • Traffic generator – CBR • Number of sources: 5, 10, 20, 40, and 50

30. RPSF – simulation results cont. • Scenario 1 • Varying number of data sources • Routing overhead • Packet delivery ratio • End-to-end delay • Varying the pause time • Routing overhead • Packet delivery ratio • End-to-end delay

31. RPSF – simulation results cont. • Scenario 2 • Varying number of data sources • Routing overhead • Packet delivery ratio • End-to-end delay • Varying the pause time • Routing overhead • Packet delivery ratio • End-to-end delay

32. RPSF – simulation results cont. • Scenario 3 • Varying number of data sources • Routing overhead • Packet delivery ratio • End-to-end delay • Varying the pause time • Routing overhead • Packet delivery ratio • End-to-end delay

33. RPSF – simulation results cont. • Scenario 4 • Varying number of data sources • Routing overhead • Packet delivery ratio • End-to-end delay • Varying the pause time • Routing overhead • Packet delivery ratio • End-to-end delay

34. RPSF – simulation results cont. • Analysis • Routing overhead • Overall average • AODV: 8.033733 • RPSF: 0.636250 • The routing overhead under AODV increases sharply • End-to-end delay • Overall average • AODV: 0.0871 • RPSF: 0.0573 • RPSF shows lower end-to-end delay than AODV when the network density is high • Network load • Both algorithms show increasing normalized load overhead and end-to-end delay as network load increases. • RPSF is relatively stable as the number of data sources increases

35. Future work • Extensions to RPSF • Algorithm for selecting forwarding nodes • Improve by using network edge information • Each node needs to find out if it is on the edge • The information will be exchanged from time to time • Improve by designing efficient forwarding node selection algorithm • Take into account the following two sub-criteria • Select nodes as far as possible • Select as few forwarding nodes as possible

36. Future work cont. • Multi-path routing • Node disjoint and edge-disjoint path routing • Relax direction information • Direction may not be available if hosts are not equipped with smart antennas • Each node has to have two hop neighbor information (but no direction information) • Use relative neighborhood graph (RNG) or other graphs to model flooding problem • Quality of service • Due to the need for supporting multimedia applications in ad hoc networks • Parameters • Bandwidth • Latency