1. Designing a Large Metropolitan Area Ad Hoc Network Dave Johnson Rice University Departments of CS and ECE http://www.monarch.cs.rice.edu/ dbj@cs.rice.edu Monarch Project

2. David B. Johnsondbj@cs.rice.eduMobile Networking Architectures Traditional Wireless Networks Many forms, but all have similar architecture: Wireless cellular networks (analog, digital, PCS, 2.5G, 3G, …) Wireless LANs (proprietary, IEEE 802.11, 802.11b, 802.11a, …) Relies on a fixed infrastructure: Centralized base station or access point All users in the cell are within wireless transmission range of it Infrastructure must be planned, installed, managed, maintained, … Wireless LAN Wireless Cellular

3. Monarch ProjectDavid B. Johnsondbj@cs.rice.eduMobile Networking Architectures Wireless Ad Hoc Networking Sometimes there may be no network infrastructure available: Remote areas Unplanned meetings Emergency relief personnel quickly deployed into an area Military troops where infrastructure has been destroyed or is untrusted Sometimes users won’t want to use available infrastructure: Time to access and register on the service Cost of using the service Performance of the existing service and infrastructure Capacity of the existing service and infrastructure Can extend coverage range of any existing infrastructure: Allow users to be further away from infrastructure serving them

4. Monarch ProjectDavid B. Johnsondbj@cs.rice.eduMobile Networking Architectures Ad Hoc Network Routing Some nodes may be out of wireless transmitter range of others Need to be able to use other nodes as routers to forward packets Need to find new routes as nodes move or network conditions change ABC

5. Monarch ProjectDavid B. Johnsondbj@cs.rice.eduMobile Networking Architectures Dynamic Source Routing (DSR) Protocol DSR divides routing problem for ad hoc networks into two parts: Route Discovery: only try to find a route to some destination when you don’t have one and need one Route Maintenance: only while you’re actually using a route, try to keep it working or fix it in spite of changes Unique properties of our protocol: All aspects of protocol operation are entirely on-demand Nodes ignore all topology changes not affecting them Overhead scales automatically as movement increases Zero overhead when stationary and found routes already Can support unidirectional links and asymmetric routes

6. Monarch ProjectDavid B. Johnsondbj@cs.rice.eduMobile Networking Architectures Route Discovery Overview To discover a route to some address: Broadcast a ROUTE REQUEST with a unique request id in it When receiving a ROUTE REQUEST: –If target is yourself, return the recorded route to the initiator in a ROUTE REPLY packet; initiator caches the route –Else, if recently seen a request with this id, drop the REQUEST –Otherwise, append your own address to a route record in the packet and rebroadcast the ROUTE REQUEST Optimizations reduce frequency and spread of ROUTE REQUESTS

7. Monarch ProjectDavid B. Johnsondbj@cs.rice.eduMobile Networking Architectures Route Maintenance Overview After transmitting a packet to the next hop: Listen for link-level per-hop acknowledgement (present in many wireless LANs), or Listen for that node sending packet to its next hop (passive acknowledgement), or Set a bit in the packet to request an explicit next-hop acknowledgement When a problem with forwarding is detected: Send a ROUTE ERROR to original sender, describing the broken link Sender removes the broken link from its cache May use other routes in cache or perform a new Route Discovery if needed

8. Monarch ProjectDavid B. Johnsondbj@cs.rice.eduMobile Networking Architectures DSR Implementation and Testbed Tested and demonstrated from Dec 1998 through Mar 1999: 5 cars, driving 20–25 MPH, looping between A and B 2 stationary nodes (E1 and E2) about 3 WaveLAN hops apart All routing between ad hoc network nodes done with DSR Integrated into Internet and Mobile IP, allows nodes to join the ad hoc network Ftp, telnet, UDP CBR audio, real-time kinematic (RTK) GPS corrections, real-time statistics and position logging

9. Monarch ProjectDavid B. Johnsondbj@cs.rice.eduMobile Networking Architectures DSR Testbed Photos

10. Monarch ProjectDavid B. Johnsondbj@cs.rice.eduMobile Networking Architectures Preliminary DSR QoS Demonstration Audio/video using Windows NetMeeting over DSR network: DARPA GloMo PI meeting, Eatontown, NJ, July 2000 QuickCam Pro USB camera, microphones, and speakers NetMeeting in moving car NetMeeting in hotel

11. Monarch ProjectDavid B. Johnsondbj@cs.rice.eduMobile Networking Architectures DSR QoS Demo Endpoint Configuration

12. Monarch ProjectDavid B. Johnsondbj@cs.rice.eduMobile Networking Architectures Screen View with Running NetMeeting

13. Monarch ProjectDavid B. Johnsondbj@cs.rice.eduMobile Networking Architectures Current Primary Funding: NASA

14. Monarch ProjectDavid B. Johnsondbj@cs.rice.eduMobile Networking Architectures Metropolitan Architecture Overview Architecture consists of 3 types of nodes: Mobile nodes move about freely within the ad hoc network and communicate only through wireless Base stations are fixed (stationary): –Communicate with mobile nodes using same wireless –Also communicate over a backbone that may be wired or long-range wireless (e.g., separate frequency) Mobile Location Register is either one base station or special node: –Maintains the registration table to record which base station is serving each mobile node –Each base station maintains a registration table cache

15. Monarch ProjectDavid B. Johnsondbj@cs.rice.eduMobile Networking Architectures Maintaining the Registration Table Each time a base station hears a ROUTE REQUEST initiated by a mobile node, it forwards it to the Mobile Location Register: To ensure that the freshest information is kept in the registration table, the registration is tied to both the hop count and the ROUTE REQUEST identifier More recent ROUTE REQUEST identifiers always take precedence Between two ROUTE REQUESTs with the same identifier value, the one with the shorter hop count takes precedence If source mobile node not currently registered or if new ROUTE REQUEST takes precedence over current registration for that mobile node, then Mobile Location Register updates its registration table Records this base station as the current base station serving that mobile node

16. Monarch ProjectDavid B. Johnsondbj@cs.rice.eduMobile Networking Architectures Updating Registration on ROUTE REPLY Can also update registration when mobile node answers a ROUTE REPLY from a base station: The target mobile node includes an additional field in its ROUTE REPLY to carry what would have been that node’s next ROUTE REQUEST identifier Allows this ROUTE REPLY to be ordered relative to ROUTE REQUESTs initiated by the mobile node Mobile Location Register thus able to choose the freshest information for registration Not used on normal ROUTE REPLYs since these don’t go to a base station to allow registration table update

17. Monarch ProjectDavid B. Johnsondbj@cs.rice.eduMobile Networking Architectures Implicit Registrations ROUTE REQUESTs and REPLYs at a base station give additional registration hints: The source route lists a sequence of nodes that terminates at the base station Mobile Location Register can remember most recent such base station for each of these nodes as an implicit registration These implicit registrations cannot be used to update the registration table entries, since their freshness cannot be determined But they can be cached and used to optimize paging (described later)

18. Monarch ProjectDavid B. Johnsondbj@cs.rice.eduMobile Networking Architectures Source Route Selection A node sending a packet determines the source route: Check Route Cache for a route to destination or to a base station If none, initiate Route Discovery: –Transmit ROUTE REQUEST with hop limit of h b = maximum hop count a node can be from a base station –Mobile nodes send ROUTE REPLY as in normal DSR –Base station also returns a ROUTE REPLY along the reverse path Mobile node selects route from Route Cache: –Prefer direct route more than route through a base station –Only use base station route if hop count does not exceed h b –Within this, next preference is to shortest route Source route on packet terminates at destination or at base station

19. Monarch ProjectDavid B. Johnsondbj@cs.rice.eduMobile Networking Architectures Route Discovery and Base Station Processing Source node discovering a route to destination node: Dotted line packets are only sent if needed

20. Monarch ProjectDavid B. Johnsondbj@cs.rice.eduMobile Networking Architectures Destination Base Station Processing If destination base station has no Route Cache entry: Query the Mobile Location Register; if reply indicates this base station, try local Route Discovery for the destination Otherwise, return packets to source base station, marked as “stale”

21. Monarch ProjectDavid B. Johnsondbj@cs.rice.eduMobile Networking Architectures Paging Used to locate a destination node globally when Mobile Location Register has no registration for destination but needs one Similar to cellular systems, and can use their paging optimizations Example (simple) paging policy: If Mobile Location Register has no implicit registration for destination, it sends PAGE to all base stations Each base station does local Route Discovery, indicating it is a page If Mobile Location Register has implicit registration, it sends PAGE only to that base station If no response, send PAGE to all recent implicit base stations for it, and perhaps then to nearby base stations If no response, continue pages with exponential back, limited times

22. Monarch ProjectDavid B. Johnsondbj@cs.rice.eduMobile Networking Architectures Initial Evaluation Methodology Evaluated architecture on 3 main metrics: Packet Delivery Ratio (PDR): fraction of data packets originated by a source node that are received by destination node Packet Overhead: number of control packets sent by routing protocol Path Length: number of times a delivered packet was transmitted over the wireless medium Communication model was Constant Bit Rate (CBR): 20 randomly selected pairs of nodes, independent of location 4 packets per second each Latency over wired backbone set to 50 ms Nominal wireless transmission range increased to 1.5 km: Data rate 2 Mbps (compatible with bandwidth utilization in CDMA 2000)

23. Monarch ProjectDavid B. Johnsondbj@cs.rice.eduMobile Networking Architectures Evaluation Movement Traces Collected real traces of real mobility of city busses: Seattle, Washington, King County metro bus system Total system is 1200 busses over 2000 square mile area Busview software allows Internet users to monitor locations (http://busview.its.washington.edu/busview_launch.jsp) Recorded traces and filtered to smooth anomalous data Used Tuesday, November 20, 2001, 7:00–8:30 am “rush hour” trace Average of 950 to 975 busses active in trace at any time Average over 5 separate portions of movement trace runs: Each between 350 and 700 simulated seconds (total 2550 seconds) Memory consumption of simulator limited our run lengths (we hit the limits of 32-bit Pentium 4’s on which we ran ns-2!)

24. Monarch ProjectDavid B. Johnsondbj@cs.rice.eduMobile Networking Architectures Example Busview Display

25. Monarch ProjectDavid B. Johnsondbj@cs.rice.eduMobile Networking Architectures Base Station Placements Approximately 2000 square miles covered by the network Each red dot is a fixed base station with wired backbone connection Red square suggests scale of area served by each base station Each green dot is location of a bus at this example moment in time Total of 8 fixed base stations Base stations placed closer together in more densely populated areas Each mobile node should be within 5 hops of a base station (h b = 5)

26. Monarch ProjectDavid B. Johnsondbj@cs.rice.eduMobile Networking Architectures Initial Results Packet Delivery Ratio (PDR) averaged 97.66% (95% confidence interval was between 96.47% and 98.85%) PDR in individual scenarios ranged between 96.21% and 98.37%. Approximately 43% of delivered packets were delivered without a base station (direct routes were shorter) Approximately 32% of packets through base station traversed wide area links Average latency in each scenario was between 5.6 and 10.8 ms Bimodal path length distribution (mean is 3.5):

27. Monarch ProjectDavid B. Johnsondbj@cs.rice.eduMobile Networking Architectures Routing Overhead Average of 3.29 overhead packets for each data packet successfully delivered About an order of magnitude worse than plain DSR using 50 nodes on a 1500 m × 300 m area for DSR: Partially due to inefficient paging in our current simulations Partially due to the higher number of nodes participating in flooding each Route Discovery And of course number of nodes is very different (for example: 50 2 = 2500 vs. 1000 2 = 1,000,000) Due to the hierarchical nature of our architecture, effect of this large increase in node population is reduced

28. Monarch ProjectDavid B. Johnsondbj@cs.rice.eduMobile Networking Architectures Conclusion Overhead is still the big challenge in a large ad hoc network Our hierarchical architecture keeps overhead manageable but could still be improved such as by paging optimizations The correct value of h b is hard to set exactly in advance: Could pick a conservative (large enough) value Or could modify protocol to have node increase limit when needed (similar to an expanding ring search) New source of movement models for ad hoc networking simulation: Real traces of real mobility of real busses May be able to provide more realistic results for many kinds of simulation studies There are still no real traces of communication patterns