A Routing Protocol for k -hop Networks

1. A Routing Protocol for k-hop Networks William List & Nitin Vaidya University of Illinois – Urbana Champaign

2. Observations Goals The k-hop Architecture Routing Simulations Results Analysis Conclusions Related Work Testbed Outline A Routing Protocol for k-hop Networks

3. Motivation • Ad-hoc networks are better-suited as "range extensions” for wired networks • Performance decreases as paths get longer • Latency • Overhead • Success rate • Most evident in highly dynamic networks • Wireless LANs are cheap and can be extended to multiple hops for increased coverage • Reduce dead spots in the network A Routing Protocol for k-hop Networks

4. Goals • Assuming a network with a bound placed on wireless paths, we would like to • Improve path reliability • Even in high mobility scenarios • Reduce latency • Particularly for initial route setup • Operate with low overhead A Routing Protocol for k-hop Networks

5. More Goals • Design and implement a testbed to verify the feasibility of experimental routing protocols A Routing Protocol for k-hop Networks

6. The k-hop Architecture • A k-hop network is a network that • Supports a maximum of k hops between two wireless clients or a wireless client and a gateway • 2k wireless hops possible if both wireless endpoints are far apart and using gateways • A mobile client is in-network if • Within k-hops distance from a gateway AND there is a mobile client to relay its packets A Routing Protocol for k-hop Networks

7. Example k-hop Network (k=2) Gateway Mobile Clients A Routing Protocol for k-hop Networks

8. Routing • Want all mobile clients to be aware of their surrounding gateways at all times • Want to support multiple paths to a destination • Want fast recovery in the case of route breakages • Two-tiered routing structure • Between mobile clients and between gateways • What combination of pro/reactivity should we use? A Routing Protocol for k-hop Networks

9. Routing cont. • Gateways share information about routes to mobile clients via • Message exchanges or • A shared memory space • Mobile clients store learnt paths to gateways in its Gateway List (GL) • Think of as multiple “default” routes • Use AODV-style sequence numbers to keep messages in-order A Routing Protocol for k-hop Networks

10. Beaconing • A way for a gateway to notify all nearby mobile clients of its presence. • Periodic (every x seconds) • Broadcast up to k hops using a counter-based scheme • Which mobile clients send a RREP • Those adding the gateway to their GL • Those that have ongoing connections A Routing Protocol for k-hop Networks

11. Route Discovery (Mobile Client) • If route exists, send data right away • Else, broadcast RREQ with TTL=k • If no reply, forward data packets to nearest gateway • If no gateway is known, send a special RREQ to discover new gateways A Routing Protocol for k-hop Networks

12. Route Discovery (Gateway) • When data packets arrive • Look up shortest path in the global routing table and forward packets • If path is stale at remote gateway • It sends out a new RREQ for the destination to acquire fresh path • If no path is known or stale path is invalid • Page – RREQ sent by all gateways with TTL=k • If destination is in-network, it should respond A Routing Protocol for k-hop Networks

13. Route Discovery cont. • Resulting connection is • Local if a direct path is found • Remote if a gateway is used • Connection can migrate from remote to local • A route is overheard to the destination as a byproduct of beaconing • Gratuitous RREP sent to the destination to establish reverse path A Routing Protocol for k-hop Networks

14. Route Recovery (Mobile Client) • If the connection was remote • Switch to a different gateway • If no other gateway is available, page for new gateways • If the connection was local • First try to send a RREQ with k to find a new route to the destination • If no route is found, use a gateway; connection is now remote A Routing Protocol for k-hop Networks

15. Route Recovery (Gateway) • If path to destination fails • Forward to different gateway that has path • If no other gateway has a path, send local RREQ with TTL=k • On failure have all gateways page for the destination to see if it is in-network A Routing Protocol for k-hop Networks

16. Simulation Setup • ns2 simulator • 100 mobile clients in 2400 m x 600 m area • Gateways every 600 m (300 m from edges) • Multiple mobility patterns • CBR traffic between mobile clients • 64 byte packets with 200 ms spacing (2.5kb/s) • Similar to traffic loads in previous works • Comparison to DSDV for local routing A Routing Protocol for k-hop Networks

17. Metrics • Packet Delivery Ratio • Number of received packets / number of packets sent • End-to-end Path Latency • Time it takes for a packet to reach its destination • Routing Overhead • Measured per node in the network A Routing Protocol for k-hop Networks

18. Simulations • 30 connections between mobile clients • In other words, 60% of mobile clients are in a connection • k = 2 and k = 3 • Speeds of 1, 5, 10 and 20 m/s A Routing Protocol for k-hop Networks

19. Packet Delivery Ratio A Routing Protocol for k-hop Networks

20. Overhead A Routing Protocol for k-hop Networks

21. Packet Latency A Routing Protocol for k-hop Networks

22. Analysis • Overall • Higher packet delivery success rate as compared to DSDV • Less overhead • Slightly higher end-to-end packet latencies • Interesting optimization: skip the local RREQ step and latency improves dramatically • Tradeoff: Average path length tends to be slightly longer, especially as k increases A Routing Protocol for k-hop Networks

23. Analysis cont. • Beaconing incurs high instantaneous contention in the network • Data packets get dropped during this period • Scalability an issue as the number of connections increases • More mobile clients respond to beacons in order to keep reverse paths fresh • Routing tables for mobile clients remain small • Only have to store paths to nearest gateway and per active destination A Routing Protocol for k-hop Networks

24. Analysis cont. • Temporary non-optimal paths are possible • Gateways prefer newer routes over those that have expired, even if they are longer • Can overwrite a perfectly valid shorter path • Problem of updating “too much” • Needs strict comparison to Hierarchical AODV • Not clear whether mobile clients should do a local search first for route discovery A Routing Protocol for k-hop Networks

25. Analysis cont. • Many variables that can be optimized • Beacon interval • Count variable for broadcasting • Many variations that can be tested • Route recovery by all nodes • Adding Multiple paths • When to respond to a beacon A Routing Protocol for k-hop Networks

26. Conclusions • Supplementing an on-demand protocol with pro-activity does not necessary improve performance • Extension of network only as good as the density of mobile clients • Inexpensive, fixed relays could server better as extensions A Routing Protocol for k-hop Networks

27. Conclusions cont. • Needs comparison with AODV/DSDV (or FSR) implementations • With/without gateways, see related work • Overhead increases at high rate as the number of end-to-end connections increases • As seen when comparing to only 10 simultaneous connections A Routing Protocol for k-hop Networks

28. Conclusions cont. • Have to be careful with sequence numbers when mixing paths to local destinations and gateways • Remember that in a remote connection, the source’s path to destination == gateway • Can get tricky when the destination moves within local range • Gotcha – gateways passing data packets back and forth for a destination A Routing Protocol for k-hop Networks

29. Testbed • Array of Linux laptops • Framework written in C/C++. • Adopts a modular approach to protocol development • Uses the ASL library to customize the Linux kernel routing table. A Routing Protocol for k-hop Networks

30. Testbed Framework User-space Routing Protocol Engine Routing Table Packet Dispatcher Link Manager Kernel Sockets Routing Table ASL TCP/IP Stack Wireless tools A Routing Protocol for k-hop Networks

31. Routing Protocol Engine • The core of the testbed that talks to other components • Responsible for packet processing/creation • Controls routes with the User-space Routing Table • Receives/sends packets from/to the Packet Dispatcher. • Listens for events from the Link Manager. A Routing Protocol for k-hop Networks

32. Routing Table • Controlled by the Routing Protocol Engine • Interfaces with the kernel routing table via ASL • ASL provides functionality to • Capture outgoing packets with destinations not in the kernel routing table. • Insert/update/delete routes A Routing Protocol for k-hop Networks

33. Link Manager • Reports broken links to the Routing Protocol Engine • Can provides link information in some cases, such as signal strength • Uses wireless tools event extensions • Information received via a raw socket A Routing Protocol for k-hop Networks

34. Packet Dispatcher • Handles creation/management of UDP sockets, including socket polling • Able to send packets from the Routing Protocol Engine and invoke callbacks for packets it receives • Event-driven model A Routing Protocol for k-hop Networks

35. Related Work • 1997 – Y.B. Ko and N. Vaidya • Super-MHs (gateways) & Mini-MHs (clients) • Multi-phase reactive route discovery process • Local flood (Super-MHs respond) • Local flood by nearest Super-MHs • Flood by ALL Super-MHs • Time-intensive A Routing Protocol for k-hop Networks

36. Related Work cont. • 2002 – K. Xu, X. Hong and M. Gerla • LANMAR routing (Local – FSR; Remote – DSDV) • Clustering algorithm for backbone node (BN) selection • Backbone nodes not the same as landmarks • Mobile nodes learn to route through BNs to take advantage of shorter paths • Relies on addresses to define subnets • Mobile nodes must store entries for all nodes in the network A Routing Protocol for k-hop Networks

37. Related Work cont. • 2002 – C. Tschudin and R. Gold • LUNAR is simple protocol designed for small-hop environments A Routing Protocol for k-hop Networks

38. Related Work cont. • 2002 – K. Xu and M. Gerla • Dynamic clustering algorithm • Cluster-heads use long-range radios as backbone links • Two protocol combinations tested (intra/inter cluster) • AODV/AODV and DSDV/AODV • DSDV/AODV has lowest delay and highest packet delivery success rate • Note: clusters are single-hop, so DSDV does well A Routing Protocol for k-hop Networks