Multi-radio & Mixed Networks

1. Multi-radio & Mixed Networks Gaurang Sardesai & Jeff Pang

2. Papers • UCAN: A Unified Cellular and Ad-Hoc Network Architecture, Haiyun Luo, Ramachandran Ramjee, Prasun Sinha, Li Li, Songwu Lu, ACM MOBICOM 2003, San Diego, California • The Pulse Protocol: Energy Efficient Infrastructure Access, Awerbuch, Holmer, Rubens, The 23rd Conference of the IEEE Communications Society (IEEE Infocom 2004)

3. UCAN : Unified Cellular Ad-Hoc Network • Synergistically combine 3G and 802.11 networks • Service to low data users reduces cell’s aggregate throughput • 3G BS forwards packets to proxy clients with better channel quality who then forward it over their 802.11 interface. • Maintain Fairness • Why would you want to relay packets for others? • Secure crediting mechanism

4. Motivation • Ad-Hoc mode complements the Cellular infrastructure • Differences between WWAN and WLAN • Coverage area, throughput, operating mode • Mobile device needs two interfaces

5. Architecture • Clients monitor downlink channel conditions. If rate is low, use relays. • Challenges: • Proxy Discovery • Topology / Rate change • Why would you forward packets for someone?

6. Proxy discovery and Routing • When low downlink channel rate, client sends out route request message on 802.11b interface. • Message propagated by intermediate nodes, route established along the way. • Proxy client sends request to HDR BS. • All further frames sent through new route using tunneling • Every client maintains moving avg of its downlink channel quality • Greedy (proactive) • On demand (reactive)

7. Greedy Proxy Discovery • Nodes periodically exchange avg downlink channel rates by broadcasting NDADV • Route requests sent to highest rate neighbor along with TTL • On receipt of request, client makes entry in table , if TTL larger than 0, forward to it’s best neighbor, else sends proxy application message to HDR BS. • Problem? • May not always locate best path

8. Greedy Proxy Discovery

9. On-demand proxy Delivery • When required, destination client floods RTREQ message within certain range. • On receipt of req, client checks sequence number and HDR channel rate • Update channel rate, and apply to HDR BS to become a proxy client. IF TTL >0, decrement TTL and further broadcast. • BS checks seq # and decide on Proxy

10. On-demand Proxy Discovery • Locates the best path • But overhead on HDR uplink

11. Route and Proxy Maintenance • Rates change, clients move, loops may occur • Path Breaks • Proxy maintenance w.r.t rate change • Routing loops

12. Scheduling Algorithm • Proportional Fair Scheduling • Client with min is scheduled for round • Use destination client’s own downlink rate to schedule.

13. Secure Crediting • Why would you want to relay for someone else? • All intermediate clients awarded credits. • Problems? • Deletion of legitimate clients • Addition of Extra Clients • Piggyback MAC in RTREQ message • But do not handle two consecutive clients conspiring

14. Performance Evaluation

15. Single Destination Client

16. Multiple Destination Clients

17. Take Aways • Novel Idea • Will this work for voice networks? • Don’t discuss credit accounting and per packet overhead.

18. Pulse Protocol • Pulse protocol sends out periodic pulse which provides routing and synchronization. • Pulse forms a spanning tree, and so each node has a continuously updated route towards the nearest network gateway. • Allows nodes to power off radio most of the time, except when required for packet forwarding. • Synchronous sleep protocol

19. Working • Flood called pulse sent at fixed pulse intervals. Originates from sources (WAP) and propagates across ad hoc component of network. • Routing – each node only remembers the node from where it got the flood packet with lowest metric. Loop free. • Synchronization • If node needs to send packet, make reservation in response to flood. Sets up reverse routes. Like AODV. • If sending, send reservation in order to keep route fresh. • If you don’t want to send of forward a reservation, sleep until the next pulse, as you’re not sending a reservation. • To reduce contention, no data packets sent during the flood. • All broken routes repaired simultaneously by within one pulse interval by flood.

20. Comparison

21. Comparison

22. Why Multiple Radios? • Multiple Senders: Channel Diversity • Adya, et al. ‘04 • Multiple Receivers: Path Diversity • Miu, et al. ‘05 • Ferrière, et al. ‘05 Ch. 1 Ch. 11

23. Multi-Radio Unification Protocol (MUP) • Environment: • Community Mesh Networks • Goal: • Increase Forwarding Capacity • Basic Idea: • Give each node NICs on different channels • Send on channel with best quality • Constraints: • Use commodity 802.11 parts • Don’t modify 802.11 MAC • Support legacy (single channel) nodes • Decentralized MUP Architecture

24. MUP Protocol Overview • Probe neighbors to discover available channels • Periodically measure channel quality to each neighbor • Select channel with best quality • Send packets out best channel • Repeat

25. ARP CS CS-ACK ARP MAC1 MAC1,MAC2 CS-ACK CS A node A A C node C node A A C A 1 1 1 channel 1 channel 1 1 11 channel 11 11 ? ? ? quality ? ? ? rtt ? 2 10 quality MUP Protocol Example A B C Legacy node

26. Channel Quality Metric • RTT (see last lecture) • SRTT = a*RTTnew + (1-a)*SRTT • Lost CS messages => • SRTT = 3*SRTT • Problems? Alternatives? • Self-interference can cause oscillations • Could use ETX from last lecture

27. Orthogonal Channels • 802.11a • Theory: 13 • Practice: 7 • 802.11b/g • Theory: 3 • Practice: 1-2 • Signal power leakage => interference

28. MUP Throughput Improvement • 50% legacy nodes • 50% 2 NIC nodes • Simulated TCP tput

29. Alternative: Stripping • MUP picks 1 best interface • Instead, can use all interfaces simultaneously • Basic Idea: • Use round-robin to select which NIC to send a packet on • Alternatives to reduce loss? • FEC packet combining codes (next paper) • Sacrifice some capacity for redundancy

30. MUP vs. Stripping • Round-robin Stripping is worse! • Channel load not equal => lots of out-of-order packets • Load-sensitive Striping gain is negligible • Why? Hint: only 2 channels…

31. MUP Summary • Leverage channel diversity with multiple-radios per node • Use unmodified commodity parts • Channel selection based on SRTT metric

32. Multi-Radio Diversity (MRD) • Environment: • AP Infrastructure Network • Goal: • Reduce AP receiver loss/error-rate • Basic Idea: • Let multiple APs hear client packets • Recover errors by combining multiple copies • Constraints: • Don’t change link-layer • APs connected on high-speed LAN

33. MRD Protocol Overview • Client associates with one AP • Other APs on same channel listen passively • Send all received packets to MRD Combiner (MRDC): • See if at least one good copy • If not, try to recover from all bad copies • If can’t recover, fail and let client retransmit

34. MRDC 00110000 00000000 00000000 OK! (soft selection) MRD Protocol Example 00000000

35. OK! (frame combining) 00000000 MRDC 00110000 00000011 00110000 00000011 MRD Protocol Example 00000000

36. 1. Split into blocks 2. Find bad blocks 00 11 00 10 00 3. Check all possibilities against CRC in header (bad headers => drop) 00 11 00 10 00 00 11 00 00 00 00 00 00 00 00 00 00 00 10 00 Frame Combining Details received original 00 11 00 00 00 00 00 00 00 00 00 00 00 10 00

37. Frame Combining Efficiency • Bit errors are bursty • Errors at different APs are uncorrelated • Theory: small number of blocks will succeed most of the time

38. Retransmissions: RFA • When does sender know tx success? • Soft-selection => Link-layer ACK • Frame-combining => ??? • Why wait for ACK with frame combining? • Slow! Must wait for MRDC • Solution: Request for ACK • Sender periodically asks for ACK • MRDC acks all packets combined OK • Issues? • Delay => OK if short • Packet reordering => need to buffer • Overhead => piggyback RFA on data packets

39. recovered by soft selection recovered by frame combining Mobile Experiment

40. Static Experiment

41. MRD Summary • Leverage path diversity with multiple receivers • Correct errors with frame combining • Use delayed RFA to obtain tx status

42. Simple Packet Combining (SPaC) • Environment: • Multi-hop Sensor Network • Goal: • Recover from bit errors with multiple receptions of the same packet • Basic Idea: • A node overhears packets as they are forwarded • When you get more than one corrupt copy of a packet, you may be able to correct the errors

43. 0000 0001 0000 1100 0100 Merge with Frame Combining 0000 SPaC Overview 0000

44. Some SPaC Details • Can recover errors with: • Multiple overheard packets • Multiple retransmissions • Use same idea in MRD frame combining to correct errors

45. Multi-Radio Discussion • What more general type of diversity is channel diversity? • Frequency diversity • Really just using more spectrum • What more general type of diversity is receiver/path diversity? • Space diversity • Is this much different from multiple antennas? • What other types of diversity could multiple radios exploit? • Technology Diversity? (802.11, GPRS, WiMax, etc.)