CS551: Wireless and Mobile Networking

1. CS551:Wireless and Mobile Networking Christos Papadopoulos (http://netweb.usc.edu/cs551/)

2. Scalable Support for Transparent Mobile Host Internetworking Mobile IP Johnson96b

3. Key Ideas • Mobile IP: • how do people find you if you move around? • specifically: how do you keep your IP address anywhere you go

4. Mobile IP • How do we deliver IP packets when endpoints move? • Issues • Impact on IP addressing • Impact on routing • Key design considerations • Scale • Incremental deployment • Mobile IP (RFC 2290) • Internet standard for support for mobility in IP

5. Mobile IP • How do we deliver IP packets when the endpoints move? • Issues: addressing and routing • Key design considerations • Scale (many mobile nodes) • Incremental deployment (!) • Result: Mobile IP, RFC 2290 • Internet standard for support for mobility in IP

6. Possible Approaches • Why not just announce a route to your host? • doesn’t scale to millions of hosts • breaks hierarchical addressing! • Why not re-address your host? • then people can’t find out • but this is what 95% of people do today, because they only run clients, not servers • Why not separate naming and addressing? • too many protocols use IP addresses instead of hostnames, esp. for open connections

7. A location registry keeps track of where you are tunnels packets to you Pros: good scalability (many users) incremental deployment easy Cons: triangle routing through home must be careful about security is it really necessary? (consider end-to-end argument) The IETF Mobile IP Approach

8. Mobile IP Terminology corresponding host (CH) Foreign Agent (FA) Home Agent (HA) CH FA HA home network (HN) MH Mobile Host (MH)

9. Discovering Agents Routers periodically beacon ICMP router advertisements CH FA HA MH Q: How do laptops usually figure things out? Why not use that? A: DHCP… because it didn’t exist when Mobile IP started.

10. Registration CH FA HA MHhome MHtemp-local MH registers with FA when it travels and gets templocal IP addr FA informs HA so HA always knows Issues: security

11. Tunneling FA gets tunneled pkt, decapsulates it, sends it to MHtemp-local CH sends pkt to MH’s IP address like normal CH FA HA HA intercepts pkt (uses same IP network as MH) and tunnels pkt to FA MHtemp-local MH’s reply can then go straight back to the CH

12. Other Mobile IP Issues • Route optimality • resulting paths are not optimal, they all go through the HA • can be improved with route optimization • smart senders keep cache of FA & MHlocal-temp • one more thing to keep updated • Smooth handoffs • don’t want to drop pkts when changing FAs • Authentication • don’t want others to claim to be MH!

13. Improving Reliable Transport and Handoff Performance in Cellular Networks Balakrishnan95

14. Key Ideas • Deals with TCP in mobile environments • packet loss (corruption) • handoff (changing from one base station to another) • Snoop • base stations cache TCP segments and quickly retransmit • Handoff • cache TCP segments at nearby base-stations to allow rapid handoff

15. Problem: TCP Loss Handling in Wireless • TCP assumes loss implies congestion • TCP’s reaction: reduce sending rate • Wireless adds losses due to corruption, collision, handoff • desired reaction: retransmit lost packets quickly • Approach: • let base-station help out

16. Alternatives • Split-connection TCP: • use one TCP connection BS, another to MH • but requires changes to FH, BS, MH • Make TCP distinguish congestion vs. other kinds of loss • good idea: done with ECN • but done after this work and not widely deployed even today • requires changes to FH and MH • Link-layer retx • good idea, but must be careful to avoid interactions between link-layer and TCP

17. Constraints • Incremental deployment • Solution should not require modifications to fixed hosts • If possible, avoid modifying mobile hosts • Preserve TCP end-to-end semantics • ACK of a packet means it’s at the receiver, not the base station

18. FH MH Fixed Host (FH) sends data to MH no change to FH code Mobile Host (MH) receives data, sends ACKs as usual Snoop Overview Base Station (BS) snoops passing traffic (data/acks); quickly retx’s data FH-to-MH: BS data acks MH-to-FH: BS acks FH MH data BS adds SACK support (even if FH doesn’t support it)

19. FH-to-MH Snoop Data Processing • Packet in sequence • Add to cache and pass on • Out of sequence, cached • Greater than last acked: pass on • Else: generate ACK to fixed host (why not just drop)? • Out of sequence, not cached • Lost or delayed out-of-order • Pass on, and keep information

20. Snoop ACK Processing • New ACK • Pass on to FH • Clean up cache • Duplicate ACK • If data not in cache, or sender retransmitted, pass on to fixed host • If in cache, respond immediately • Suppress other dupacks

21. Handoff Support • General approach: • extend mobile IP to multicast pkts to several FA’s (base stations, BSes) • MH informs BS when it’s changing • BSes are pre-loaded w/data, can run snoop and quickly repair losses

22. Observations • Nice aspects of Snoop: • minimal changes to improve performance • good backwards compatibility • preserves TCP semantics • Other examples: • fast-retransmit in TCP • Other examples? • layer-3 caching?

23. Other Issues • What about mobile-to-fixed communication? • Modify snoop module to generate SACKs • TCP over ad-hoc networks? • Open area of research

24. MACAW: A Media Access Protocol for Wireless LANs Bharghavan94a (Link Layer Issues)

25. Overview • Wireless access and mobility • force us to rethink many of our assumptions • Our focus: • Link layer issues • Packet delivery and routing • … in combined wired-wireless networks • … in ad-hoc mobile wireless networks • Transport layer issues

26. Wireless MAC Options • Contention-based vs. token-based • why contention? because moving nodes could cause frequent token loss • Base-station vs. ad-hoc • why base-station? simpler if you have a leader that can assign things (esp. if non-mobile) • why ad-hoc? don’t always have leader • MACAW and 802.11 do both

27. Simple model: fixed tx range propagation can be r -3 or r –1 (near or far) issues: collisions, capture, interference good simple model, but only an approximation Reality is much worse Multi-path fading time-varying effects connectivity from one node to others % pkts received to 5 dests (data from Jerry Zhao, ISI, 2002) time since start (in hours) Radio Propagation

28. Token-based or multiple-access or spread spectrum First study a simple model radio transmission range defined by cell a receiver within range can hear transmission interaction of multiple transmitters at receiver collisions, capture, interference Interactions Collision: if receiver is within range of two transmitters, but can’t extract either Capture: one signal stronger than other Interference: in-range of one transmitter, out of range of another, but can’t extract signal Other, more complex environmental interactions multipath: reflected signals interfere with original The Physical Layer

29. A B C hidden terminal Carrier Sense in Wireless • Carrier Sense: before transmitting, check if carrier present • works in Ethernet • why not for wireless? because receiver and sender “sense” different “carrier” • Issues: hidden and exposed terminals A A B B C C exposed terminal

30. Src sends Ready-to-Send (RTS) before data overhearers defer Dst replies with Clear-to-Send (CTS) overhearers defer RTS around src, CTS around dest, so everyone should be quiet Must also deal with collisions, etc. A B C hidden terminal scenario Karn/MACA RTS-CTS • A sends RTS • B gets RTS and sends CTS • C hears CTS and is quiet (no hidden terminal)

31. Back-off algorithm: Back-off counter BO estimates population randomly wait [0,BO] before sending original: binary exponential: BO = 0 after success BO *= 2 after collision Problem: channel capture if I succeed, my BO = 0, so I am likely to win again others who fail get slower and slower… Fixes: share BO (send in each pkt) increase multiplicatively, decrease additively (“MILD”) per-destination back-off A B C Back-off Issues

32. A B C Adding Link-level ACKs • Wireless losses possible • noise or collisions • end-to-end argument? • Add link-level ACK of DATA • lost DATA => no ACK => retx • lost ACK => sender retx RTS, receiver sends ACK instead of CTS • A sends RTS • B gets RTS and sends CTS • A sends DATA • B sends ACK • if no ACK, A resends RTS

33. A B C Continuing Fairness Problems • An exposed terminal may not be able to compete effectively • C doesn’t know if RTS/CTS was successful, • … so reduced to trying at random times • tends to back-off more and more • Fix: • carrier sense • …or a DS packet • Doesn’t solve all fairness issues (try A sends to B) • B sends RTS • A gets RTS and sends CTS; but C misses CTS • B sends DS • C hears DS (and data length) and so knows when to try RTS again • B sends DATA • C knows to RTS after data

34. Commercializing MACAW:IEEE 802.11 • Standard for wireless communication • MAC-layer uses many of the ideas discussed • Basic MAC is a CSMA/CA • Carrier-sense and transmit, ACK • RTS/CTS exchange is optional • Allows two modes • ad-hoc (DCF; Distributed Coordination Function) • base-station (PCF; Point Coordination Function) DCF PCF

35. Dynamic Source Routing in Ad-hoc Wireless Networks Johnson96

36. Mobile Routing Alternatives • Why not just assume a base station? • good for many cases, but not some (military, disaster recovery, sensor nets) • Why not just use regular Internet routing? • completely different assumptions about stability, hierarchy • but might work well for fixed wireless • Why not just flood the data to all nodes? • best choice for rapid movement, but doesn’t work for many nodes and much traffic

37. Assumptions: multi-hop routing (all nodes forward data) wireless nodes typically mobile typically trustworthy (more or less) want low energy consumption Implications cannot really use hierarchical addressing assume things will change Approaches: a priori protocols (DSDV, TORA) pre-compute routing tables on-demand protocols (DSR, AODV) compute routes lazily (only when needed) General Ad Hoc Routing

38. Paths should be: multi-hop paths loop-free inexpensive to set up robust to node movement System should auto-configure, adapt to movement Low memory, bandwidth, energy req’d scalable with numbers of nodes localize effects of link failure Multicast? not here :-) Ad-hoc Routing Goals

39. Problems With Traditional Approaches • Periodic (a priori) routing or LS updates are expensive • Dynamic topology problems: • frequent LS updates • algorithm must converge very quickly to avoid blackholes • Many “links” in wireless (many nodes can hear each other) => large rtg tables/msgs • Not studied in the context of realistic radio propagation models, MAC layers and mobility patterns

40. Problems Using DV or LS • DV protocols may form loops • very wasteful in wireless: bandwidth, power • loop avoidance sometimes complex • LS protocols: high storage and communication overhead

41. Ad Hoc Routing • Create multi-hop connectivity among set of wireless, possibly moving, nodes • Mobile, wireless hosts act as forwarding nodes as well as end systems • Need routing protocol to find multi-hop paths • Needs to be dynamic to adapt to new routes, movement • Interesting challenges related to interference and power limitations

42. Ad-hoc Routing Requirements • Distribution paths • Multi-hop paths • loop-free • minimal data transmission overhead • multicast? • Self-starting and adaptive to dynamic topology • Low consumption of memory,bw, power • scalable with numbers of nodes • localized effects of link failure

43. Problems With Traditional Approaches • Periodic routing or LS updates require power of sender and of listening receivers • Topology very dynamic so protocols must converge quickly to avoid black holes • Not studied in the context of realistic radio propagation models, MAC layers and mobility patterns

44. Problems Using DV or LS • DV protocols may form loops • very wasteful in wireless: bandwidth, power • loop avoidance sometimes complex • LS protocols: high storage and communication overhead • More links in wireless (e.g., clusters) - may be redundant -> higher protocol overhead

45. ..Problems • Periodic updates waste power • tx sends portion of battery power into air • reception requires less power, but periodic updates prevent mobile from “sleeping” • Convergence may be slower in conventional networks but must be fast in ad-hoc networks and be done without frequent updates

46. Proposed Protocols • Destination-Sequenced Distance Vector (DSDV) • hbh, DV protocol w/periodic routing update broadcasts • Temporally-Ordered Routing Algorithm (TORA) • on demand creation of hbh routes based on link-reversal • Dynamic Source Routing (DSR) • on demand source route discovery • Ad Hoc On-Demand Distance Vector (AODV) • combination of DSR and DSDV: on demand route discovery with hbh routing

47. DSR • Components: • route discovery • route maintenance • Route discovery - basic idea • S broadcasts route-request to D • each node forwards request by adding own address and re-broadcasting • requests propagate outward until target is found

48. Route Requests (RREQ)and Replies (RREP) • A request (w/new hop) is forwarded if: • not a duplicate • node is not the destination (if D, then send RREP reply) • node not already listed in recorded source route (loop suppression) • Replies at D are returned to S via • source route from D’s cache • invert source route (not preferred because of potential asymmetry) • piggy-backed on another route request from D to S

49. Route Maintenance • several options: • use link-level info (if present) • passive ACKs (listen for data to be forwarded) • end-to-end

50. Route Cache • Keep all source routes in route cache (reuse if possible) • Can short-circuit RREQs if it matches the cache • just generate a reply • but make sure you don’t step on your neighbors • Can eavesdrop to pre-fill route cache