Scalable Geographic Routing for Mobile Ad-hoc Networks ( Joint work with Xiaojing Xiang and Zehua Zhou)

1. Scalable Geographic Routing for Mobile Ad-hoc Networks(Joint work with Xiaojing Xiang and Zehua Zhou) Xin Wang Assistant Professor Director, Wireless and Networking Systems Lab (WINS) http://www.cse.buffalo.edu/~xwang8

2. Telephone Network Internet Telephone Network Internet Base Station Base Station Wireless Gateways Edge Router Mobile Communications Today: Tale of 2 Networks • Cellular Telecommunications Networks • Tailored for voice: very low bandwidth • Devices not suitable for Internet and computing applications • Despite high penetration, Internet access has fizzled • Wireless Enterprise Networks • Tailored for best-effort data traffic: high bandwidth, no controls • Supports general computing and data networking applications • Gaining density in hot-spots, but no ubiquitous coverage Wireless Controllers Access Router

3. 4GRadios 4G AirInterface … Tomorrow – Common Net, Common Apps 3G CellularNetworks RadioController AccessRouter UrbanNetworks • Outdoor Areas • High Mobility AggregationRouter • Broadband Distribution Networks • High Speed Pico Cells • WiMAX Presence EnterpriseNetworks Location AccessRouter • 802.11++ • Local Mobility • Packet Voice • High Data Rates Core InternetBackbone AggregationRouter AggregationRouter Authentication HomeNetworks AccessRouter • DSL/Cable • High Speed Internet Access • Community • networks Ad HocNetworks 4GRadios • Allow Peer-to-Peer Communications • Self Configuring

4. Focus of Talk • Scalable geographic routing protocols for Mobile Ad Hoc networks

5. Talk Overview • Background and motivation • Self-adaptive geographic unicast routing • Scalable geographic multicast routing • On-going and future work

6. Background • Mobile Ad Hoc Networks (MANET) • Self organized networks with no fixed infrastructure • Example applications: disaster area, military, sensor networks, wireless mesh networks • May need to traverse many hops due to limited radio range • Routing: find a packet delivery path • Unicast: one-to-one • Multicast: one-to-many or many–to-many

7. Challenge of MANET Routing • Host mobility leads to dynamic topology • Rate of link failure/repair increases with moving speed • Topology and routing path maintenance become more difficult with the increase of path length and node density • Mobile devices have very limited energy, and small devices such as sensors have very limited per-node resources

8. Existing Unicast Routing Protocols • Proactive protocols (DSDV, OLSR) • Actively track network topology changes, not suitable for high mobility • Maintain routes continuously, large overhead when there is no traffic • Reactive protocols (DSR, AODV, TORA, FLR) • Maintain routes only if needed • May need network-wide flooding to discover routes, larger delay due to searching for path before sending packet • Hybrid protocols (ZRP, SHARP) • Combine the proactive and reactive approaches • Geographic routing protocols (GPSR, GFG) • Make use of location information to reduce routing overhead • Only need to be aware of local topology

9. Information Required for Geographic Routing • A node’s own position: obtained through positioning service such as GPS • The position of the destination: determined through some location service • The positions of all neighbors: learned through periodic beacons sent by neighbors

10. GPSR: Greedy Perimeter Stateless Routing (Karp’00) • Local topology construction • Periodically send beacons to announce node position to neighbors • Carry sender position with data packets • Two forwarding formats • Greedy forwarding • Make local optimal forwarding decision, choose the neighbor closest to the destination as next hop. • Perimeter forwarding • Without neighbor closer to destination, route around the perimeter of void area using a planar sub-graph (no crossed-edges exist) calculated from local topology until greedy forwarding can be resumed D x D x

11. Problems with Classical Geographic Routing • Proactive fixed-interval beaconing for positions • Generate unnecessary overhead and consume energy • Create collisions with normal data transmissions • Beaconing interval affects accuracy of the local topology and routing performance • Outdated topology => non-optimal routing, transmission failures => more network resource consumption • Continuous retransmissions due to inaccurate position • Reduce link throughput and fairness, and increase collisions => further delay and energy consumption

12. Performance Improvement • Change Beacon Sending Interval • Send out beacons only after moving a certain distance • Send beacons more frequently, e.g. piggyback position with packets (Are the sending nodes the best next hop? ) Does not consider traffic conditions. May generate unnecessary beacons. • Do not use Beacons (CBF’03, BLR’04) • Focus only on finding the forwarding node in greedy mode • No recovery strategy • No consideration of path maintenance

13. Our Contributions • Propose two geographic routing protocols • On-demand: alleviate unnecessary overhead due to proactive beacons • Introduce more flexible position distribution mechanisms: more updated topology, more efficient routing and less failure • Introduce a self adaptive routing approach: robust to topology changes and adaptive to traffic

14. Importance of adaptivity: some analysis • Positions obtained through beacons become outdated • Depending on mobility and position distribution, a large fraction of positions may be outdated. • Analysis – assumptions: • Node B sends beacons periodically to refresh its position at A • Neighbor area of A: centered at A, within transmission range R • Moving area of B: centered at B, within maximum moving distance r • Parameters

15. r z R A B r z r A A z R R Different Scenarios R R r z z A B R r A B z B A r Same as this case

16. Probability of Moving Out of Range Case 1: Case 2: Case 3:

17. Percentage of positions that are out-of-range Timeout

18. Proposed Geographic Routing Protocols • Beaconless Interactive Geographic Routing (BIGR) • BTGR: Beacon-on-Trigger Geographic Routing

19. Beaconless Interactive Geographic Routing (BIGR) • There is no beacon, routing path is built on-demand • Route searching phase • Forwarding decision made through the cooperation of forwarding node and its neighbors • How to find next hop without positions of neighbors? How to recover from geographic routing void? • Route optimization phase • Forwarding path optimized jointly by sending node and its neighbors

20. Route Searching • Every node keeps a next hop table A F Next hop table for node B B C

21. How to find next hop? • When a node (C) does not have next hop information, broadcast REQ S E F B M L C J A G H D I K N Within neighborhood Represents a node that receives a packet for the first time REQ message with

22. Forwarding Node Selection • Reply sending: nodes closer to destination respond after a backoff, and the backoff time is smaller for a node closer to destination • Reply suppression: a node cancels its reply if it overhears packet forwarding, or overhears reply sent by node closer to destination • Multiple replies: select the node closer to the destination as next hop S E F B M L C J A G H D I K N REPLY message

23. Packet Sending • C’s next hop table S E F B M L C J A G H D I K N

24. Recovery from Local Void • Without local topology, cannot use perimeter forwarding. How to recover? • Broadcast REQ to N-hop neighbors E F S B M C L J A D H I G K N REQ message with

25. E F S B M C L J A D H I N G K Finding Path in Recovery Mode • Reply sending: • [If one-hop neighbor is nearer to destination, it replies with Hop = 1; Otherwise continues broadcasting REQ] • [A two-hop neighbor nearer to destination replies (reverse path), Hop = 2; The one-hop neighbor records the next hop to the destination (D) as the REPLY sender (G), forwards REPLY to REQ sender ( C)] • Reply suppression: drop the REPLY if having forwarded/overhead one from the node closer to destination • Multiple replies: select the node closer to destination Reply message

26. Position Update and Route Optimization • Update next hop position when overhearing packet forwarding by next hop (carrying sending node position) • Validate next hop • Estimate next hop • If both old and new positions are fresh • If only new position is available, it will be used as the estimated position • Search for new route • If both old and new positions are outdated • If estimated position is out of transmission range or no longer closer to destination than current forwarding node • Optimize rerouting path: three cases • Assumption: current forwarding path is from B to C, neighboring node A overhears from both node B and C

27. Move CORRECT A Case 1: A is the destination • As A is the destination, B should sent packet directly to A, so A sends CORRECT to B • B sets its next hop to A A B C Old path Old position Current position New path

28. Move A CORRECT Case 2: Greedy Mode Forwarding A F • If A is closer to F than C is to F, A sends CORRECT to B • B compares A’s and C’s positions to F, and sets its next hop to A if it is closer to F B C Greedy Old position Current position Old path New path

29. Move A CORRECT Case 3: Recovery Forwarding F • If A is closer to F than it is to B and C, A sends CORRECT to B • If B is the first hop of recovery, if A is closer to F than B is to F, then A is closer to F than both B and C • If B is the last hop of recovery, if A is closer to F than C is to F, then A is closer to F than both B and C • B compares A and C’s positions relative to F, if A is closer to F, B sets its next hop to A • If B is the first hop of recovery, change mode to greedy A D B C Recovery mode Greedy Old position Current position Old path New path

30. Proposed Geographic Routing Protocols • Beaconless Interactive Geographic Routing (BIGR) • BTGR: Beacon-on-Trigger Geographic Routing

31. BTGR: Beacon-on-Trigger Geographic Routing • Beacons are generated on demand: triggered by data traffic, non-optimal route • Adaptive to traffic • Send beacon periodically when overhearing data forwarding or requested by neighbor • Stop beaconing if there is no traffic • Route optimization • Broadcast a beacon upon detecting non-optimal path • Topology maintenance • Only maintain positions of neighbors on demand • Packet forwarding • Forward if positions are fresh • Request position update otherwise

32. Beacon Triggering by Non-optimal Path • Route validation • Delete invalid neighbors • Update the positions of other members based on estimation • Route optimization: also three cases • The first two cases are similar to that of BIGR • Case 3: When A overhears forwarding from B to C using perimeter mode • If A is closer to the destination than the position where the perimeter mode started, B should resume greedy forwarding earlier • A broadcasts a beacon to refresh its position, B will send future packets to A

33. BIGR and BTGR delivery ratios are not impacted by speed BIGR more actively updates the position as speed increases Impact of Mobility Delivery ratio Control overhead

34. Impact of Mobility (cont) Total transmissions Average end-to-end delay GPSR has significantly higher transmission redundancy and end-to-end delay due to outdated position.

35. Summary • Propose two self-adaptive on-demand geographic routing protocols • Alleviate unnecessary overhead due to proactive beacons • More efficient position distribution and very robust to topology change: packet transmission delay is reduced more than three times at high mobility as compared to GPSR • Outperform existing geographic protocols in all test scenarios, including mobility, node density and traffic load

36. Talk Overview • Background and motivation • Self-adaptive geographic unicast routing • Scalable geographic multicast routing • On-going and future work

37. Existing Multicast Routing Protocols • Tree-based (AMRIS, MAODV, LAM) • Utilize network resources efficiently • Mesh-based (FGMP, CAMP, ODMRP) • Robust Difficult to scale due to overhead for route searching, group membership management, and tree/mesh maintenance over dynamic topology • Geographic multicast (LGT, DSM, PBM) • Reduce topology maintenance overhead, but not scalable

38. Why Is Geographic Multicast Difficult to Scale? • Putting the information of all group members into packet header creates excessive overhead for large group • Relying on location service to obtain positions for all group members adds more overhead

39. Our Contributions • Design an efficient on-demand hierarchical group membership management scheme • Avoid the need to build and maintain tree/mesh structure • Avoid the need for periodical network-range flooding of source information, and location searches for group members

40. Some Concepts Home zone • Zone • Network terrain is divided into square zones • Member Zone • A Zone with group members • Zone Leader • Manage membership in a member zone • Home Zone • Zone in which all zone members track the addresses and Zone IDs of sources Source Zone leader Group member Other nodes

41. Membership Reporting in Local Zone • A group member sends REFRESH to leader to report its membership • If leader is known, unicast • If leader is not known, elect leader • Leader election (on demand) • Flood the REFRESH, indicating leader information is requested • A leader will send back a LEADER message • If no LEADER is received, the member announces itself as the leader and floods a LEADER message within the zone Zone leader Group member Other nodes

42. Membership Management within Zone • A member • Sends REFRESH to leader periodically and when joining /leaving group, carrying its membership and position • A leader • Sends LEADER periodically within the zone to announce its leadership, carrying the positions and group IDs of the multicast members • States maintenance • Nodes in the member zone: save the information of multicast group members in the zone • Group members and zone leader: keep source information

43. Moving between Zones • When a node moves into a new zone • Clears old zone’s information • If the node is a group member • Will continue receiving packets forwarded by old zone • Sends REFRESH to new zone leader • When a leader is moving out of a zone • Hands leadership to other nodes

44. Source Announcements • A source • At session initiation time, floods an ANNOUNCE, with address, position, and group ID • Later piggybacks its information with the multicast packets • A node interested in being a member • Records source information • For joining, send REFRESH to its leader

45. Home Zone • Function of Home zone • Maintains addresses and zone IDs of sources • A source sends its zone ID to home zone when moving to new zone; floods source info to whole zone • Searching for Home zone • Source: announces its current zone as home zone • Sets sequence number to 0, sequence number increases upon home zone change • Other nodes: search home zone with increasing ring • Home zone election • When a node receives a message addressed to home zone with sequence number different from record (due to zone update or zone announcement from a new source) • If the message has larger sequence number, update its home zone info; otherwise, forward the message to recorded home zone • A home zone node sends SOURCE to message sender to update sender’s home zone information

46. Membership Management at Upper Tier • If the leader knows the source location • [Sends] report on group membership to the source • [Aggregates] reports for different sources located at the same host node • If a leader does not know source location, or the source information is outdated • Sends REPORT to home zone, which will forward the report to the source zone • A home zone node sends a SOURCE message to the leader to update leader’s source information • Source records the member zones

47. Empty Zone Handling • Member zone • The departing leader notifies the source • Home zone • The last node announces the new zone it is moving to as the home zone; floods source information within new home zone; sends ANNOUNCE to network with sequence number of home zone increased by one

48. Multicast Packet Delivery • Source • Sends packets to all member zones and members in its zone • Aggregates transmissions and sends one copy if several members share next hop • Intermediate nodes • Take similar action • If the message includes their current zone, replace zone ID in the message with the IDs of the members in the zone. Home Zone Source Zone leader Group member Other nodes

49. SGMP has up to 35% higher delivery ratio and 20 % lower overhead at high mobility Impact of mobility Delivery ratio Control overhead

50. SGMP has higher delivery ratio under all group sizes, and has more than 2.5 times higher delivery ratio for large network sizes. Scalability Group size Network size