1. Winter 2004 UCSC CMPE252B1 CMPE 257: Wireless and Mobile Networking SET 3m: Medium Access Control Protocols

2. Spring 2005CMPE257 UCSC2 MAC Protocol Topics n MAC protocols using multiple channels with one transceiver only p MMAC (Multi-channel MAC) p SSCH (Slotted Seeded Channel Hopping)

3. Spring 2005CMPE257 UCSC3 n Multiple orthogonal channels available in IEEE 802.11 p 3 channels in 802.11b p 12 channels in 802.11a n Utilizing multiple channels can improve throughput p Allow simultaneous transmissions Motivation for Multi-Channel 1 defer 1 2 Single channelMultiple Channels

4. Spring 2005CMPE257 UCSC4 Problem Statement n Using k channels does not translate into throughput improvement by a factor of k p Nodes listening on different channels cannot talk to each other n Constraint: Each node has only a single transceiver p Capable of listening to one channel at a time n Goal: Design a MAC protocol that utilizes multiple channels to improve overall performance p Modify 802.11 DCF to work in multi-channel environment 1 2

5. Spring 2005CMPE257 UCSC5 802.11 Power Saving Mechanism n Time is divided into beacon intervals n All nodes wake up at the beginning of a beacon interval for a fixed duration of time (ATIM window) n Exchange ATIM (Ad-hoc Traffic Indication Message) during ATIM window n Nodes that receive ATIM message stay up during for the whole beacon interval n Nodes that do not receive ATIM message may go into doze mode after ATIM window

6. Spring 2005CMPE257 UCSC6 802.11 Power Saving Mechanism A B C Time Beacon ATIM Window Beacon Interval

7. Spring 2005CMPE257 UCSC7 802.11 Power Saving Mechanism A B C Time Beacon ATIM ATIM Window Beacon Interval

8. Spring 2005CMPE257 UCSC8 802.11 Power Saving Mechanism A B C Time Beacon ATIM ATIM-ACK ATIM Window Beacon Interval

9. Spring 2005CMPE257 UCSC9 Multi-Channel Hidden Terminals n Consider the following naïve protocol p Static channel assignment (based on node ID) p Communication takes place on receiver’s channel r Sender switches its channel to receiver’s channel before transmitting

10. Spring 2005CMPE257 UCSC10 Multi-Channel Hidden Terminals A B C RTS A sends RTS Channel 1 Channel 2

11. Spring 2005CMPE257 UCSC11 Multi-Channel Hidden Terminals A B C CTS B sends CTS Channel 1 Channel 2 C does not hear CTS because C is listening on channel 2

12. Spring 2005CMPE257 UCSC12 Multi-Channel Hidden Terminals A B C DATA C switches to channel 1 and transmits RTS Channel 1 Channel 2 Collision occurs at B RTS

13. Spring 2005CMPE257 UCSC13 Nasipuri’s Protocol n Assumes N transceivers per host p Capable of listening to all channels simultaneously n Sender searches for an idle channel and transmits on the channel [Nasipuri99WCNC] n Extensions: channel selection based on channel condition on the receiver side [Nasipuri00VTC] n Disadvantage: High hardware cost

14. Spring 2005CMPE257 UCSC14 Wu’s Protocol [Wu00ISPAN] n Assumes 2 transceivers per host p One transceiver always listens on control channel n Negotiate channels using RTS/CTS/RES p RTS/CTS/RES packets sent on control channel p Sender includes preferred channels in RTS p Receiver decides a channel and includes in CTS p Sender transmits RES (Reservation) p Sender sends DATA on the selected data channel

15. Spring 2005CMPE257 UCSC15 Wu’s Protocol (cont.) n Advantage p No synchronization required n Disadvantage p Each host must have 2 transceivers p Per-packet channel switching can be expensive p Control channel bandwidth is an issue r Too small: control channel becomes a bottleneck r Too large: waste of bandwidth r Optimal control channel bandwidth depends on traffic load, but difficult to dynamically adapt

16. Spring 2005CMPE257 UCSC16 Proposed Protocol (MMAC) n Assumptions p Each node is equipped with a single transceiver p The transceiver is capable of switching channels p Channel switching delay is approximately 250us r Per-packet switching not recommended r Occasional channel switching not to expensive p Multi-hop synchronization is achieved by other means

17. Spring 2005CMPE257 UCSC17 MMAC n Idea similar to IEEE 802.11 PSM p Divide time into beacon intervals p At the beginning of each beacon interval, all nodes must listen to a predefined common channel for a fixed duration of time (ATIM window) p Nodes negotiate channels using ATIM messages p Nodes switch to selected channels after ATIM window for the rest of the beacon interval

18. Spring 2005CMPE257 UCSC18 Preferred Channel List (PCL) n Each node maintains PCL p Records usage of channels inside the transmission range p High preference (HIGH) r Already selected for the current beacon interval p Medium preference (MID) r No other vicinity node has selected this channel p Low preference (LOW) r This channel has been chosen by vicinity nodes r Count number of nodes that selected this channel to break ties

19. Spring 2005CMPE257 UCSC19 Channel Negotiation n In ATIM window, sender transmits ATIM to the receiver n Sender includes its PCL in the ATIM packet n Receiver selects a channel based on sender’s PCL and its own PCL p Order of preference: HIGH > MID > LOW p Tie breaker: Receiver’s PCL has higher priority p For “LOW” channels: channels with smaller count have higher priority n Receiver sends ATIM-ACK to sender including the selected channel n Sender sends ATIM-RES to notify its neighbors of the selected channel

20. Spring 2005CMPE257 UCSC20 Channel Negotiation A B C D Time ATIM Window Beacon Interval Common ChannelSelected Channel Beacon

21. Spring 2005CMPE257 UCSC21 Channel Negotiation A B C D ATIM ATIM- ACK(1) ATIM- RES(1) Time ATIM Window Beacon Interval Common ChannelSelected Channel Beacon

22. Spring 2005CMPE257 UCSC22 Channel Negotiation A B C D ATIM ATIM- ACK(1) ATIM- RES(1) ATIM- ACK(2) ATIM ATIM- RES(2) Time ATIM Window Beacon Interval Common ChannelSelected Channel Beacon

23. Spring 2005CMPE257 UCSC23 Channel Negotiation A B C D ATIM ATIM- ACK(1) ATIM- RES(1) ATIM- ACK(2) ATIM ATIM- RES(2) Time ATIM Window Beacon Interval Common ChannelSelected Channel Beacon RTS CTS RTS CTS DATA ACK DATA Channel 1 Channel 2

24. Spring 2005CMPE257 UCSC24 Simulation Model n ns-2 simulator n Transmission rate: 2Mbps n Transmission range: 250m n Traffic type: Constant Bit Rate (CBR) n Beacon interval: 100ms n Packet size: 512 bytes n ATIM window size: 20ms n Default number of channels: 3 channels n Compared protocols p 802.11: IEEE 802.11 single channel protocol p DCA: Wu’s protocol p MMAC: Proposed protocol

25. Spring 2005CMPE257 UCSC25 Wireless LAN - Throughput 30 nodes64 nodes MMAC DCA 802.11 MMAC shows higher throughput than DCA and 802.11 802.11 DCA MMAC Packet arrival rate per flow (packets/sec) 1 10 100 1000 2500 2000 1500 1000 500 Aggregate Throughput (Kbps) 2500 2000 1500 1000 500

26. Spring 2005CMPE257 UCSC26 Multi-hop Network – Throughput 3 channels4 channels MMAC DCA 802.11 DCA MMAC Packet arrival rate per flow (packets/sec) 1 10 100 1000 Packet arrival rate per flow (packets/sec) 1 10 100 1000 Aggregate Throughput (Kbps) 1500 1000 500 0 2000 1500 1000 500 0

27. Spring 2005CMPE257 UCSC27 Throughput of DCA and MMAC (Wireless LAN) DCA MMAC 2 channels 802.11 MMAC shows higher throughput compared to DCA 6 channels 802.11 2 channels 6 channels Aggregate Throughput (Kbps) 4000 3000 2000 1000 0 4000 3000 2000 1000 0 Packet arrival rate per flow (packets/sec)

28. Spring 2005CMPE257 UCSC28 Analysis of Results n DCA p Bandwidth of control channel significantly affects performance p Narrow control channel: High collision and congestion of control packets p Wide control channel: Waste of bandwidth p It is difficult to adapt control channel bandwidth dynamically n MMAC p ATIM window size significantly affects performance p ATIM/ATIM-ACK/ATIM-RES exchanged once per flow per beacon interval – reduced overhead r Compared to packet-by-packet control packet exchange in DCA p ATIM window size can be adapted to traffic load

29. Spring 2005CMPE257 UCSC29 Conclusion and Future Work n Conclusion: p MMAC requires a single transceiver per host to work in multi-channel ad hoc networks p MMAC achieves throughput performance comparable to a protocol that requires multiple transceivers per host n Future work p Dynamic adaptation of ATIM window size based on traffic load for MMAC p Efficient multi-hop clock synchronization

30. Spring 2005CMPE257 UCSC30 Motivation: Improving Capacity Traffic on orthogonal channels do not interfere e.g. Channels 1, 6 and 11 for IEEE 802.11b Channel 11 Channel 1 Channel 6 Example: An IEEE 802.11b network with 3 Access Points Can we get the benefits of multiple channels in ad hoc networks? Channel 6

31. Spring 2005CMPE257 UCSC31 Channel Hopping: Prior Work n Using multiple radios: p DCA (ISPAN’00): a control and a data channel p MUP (Broadnets’04): multiple data channels Consumes more power, expensive n Using non-commodity radios: p HRMA (Infocom’99): high speed FHSS networks p Nasipuri et al, Jain et al: listen on many channels Expensive, not easily available Using a single commodity radio: p Multi-channel MAC (MMAC) (Mobihoc’04)

32. Spring 2005CMPE257 UCSC32 Channel Hopping: MMAC MMAC Basic idea: Periodically rendezvous on a fixed channel to decide the next channel Issues n Packets to multiple destinations  high delays n Control channel congestion n Does not handle broadcasts Channel 1 Channel 6 Channel 11 Data ControlData Control

33. Spring 2005CMPE257 UCSC33 SSCH A new channel hopping protocol that p Increases network capacity using multiple channels p Overcomes limitations of dedicated control channel – No control channel congestion – Handles multiple destinations without high delays – Handles broadcasts for MANET routing

34. Spring 2005CMPE257 UCSC34 SSCH: Slots and Seeds Divide time into slots: switch channels at beginning of a slot 3 channels E.g. for 802.11b Ch 1 maps to 0 Ch 6 maps to 1 Ch 11 maps to 2 1 02102 1 0 01201201 New Channel = (Old Channel + seed) mod (Number of Channels) seed is from 1 to (Number of Channels - 1) Seed = 2 Seed = 1 (1 + 2) mod 3 = 0 (0 + 1) mod 3 = 1 A B Enables bandwidth utilization across all channels Does not need control channel rendezvous

35. Spring 2005CMPE257 UCSC35 SSCH: Syncing Seeds Each node broadcasts (channel, seed) once every slot If B has to send packets to A, it adjusts its (channel, seed) 3 channels 1 02102 1 0 0121021 0 Seed Follow A: Change next (channel, seed) to (2, 2) A B 22 222 2 22 12 2 22222 2 2 1 Stale (channel, seed) info simply results in delayed syncing B wants to start a flow with A 2

36. Spring 2005CMPE257 UCSC36 Nodes might not overlap! If seeds are same and channels are different in a slot: 3 channels Seed = 2 Nodes are off by a slot  Nodes will not overlap 1 02102 1 0 1 02102 12 A B

37. Spring 2005CMPE257 UCSC37 SSCH: Parity Slots 3 channels Seed = 1 Every (Number of Channels+1) slot is a Parity Slot In the parity slot, the channel number is the seed Parity Slot Guarantee: If nodes change their seeds only after the parity slot, then they will overlap 012 0122 2 0111 111 0 A B

38. Spring 2005CMPE257 UCSC38 SSCH: Partial Synchronization Syncing to multiple nodes, e.g., A sends packets to B & C Each node has multiple seeds Each seed can be synced to a different node Parity Slot Still Works Parity slot: (Number of Channels)*(Number of Seeds) + 1 In parity slot, channel is the first seed First seed can be changed only at parity slot If the number of channels is 3, and a node has 2 seeds: 1 and 2 2210110221100 (1 + 1) mod 3 = 2 (2 + 2) mod 3 = 1 Parity Slot = seed 1

39. Spring 2005CMPE257 UCSC39 Illustration of the SSCH Protocol 2210110221100 Node A 2012120221100 Node B Seeds B wants to start a flow with A Complete Sync (sync 1 st seed) Seeds (1, 2) Channels: (1, 2) Partial Sync (only 2 nd seed) Seeds: (2, 2) Channels: (2, 1) 121212121212 Seeds212222121212 Suppose each node has 2 seeds, and hops through 3 channels.

40. Spring 2005CMPE257 UCSC40 SSCH: Handling Broadcasts A single broadcast attempt will not work with SSCH since packets are not received by neighbors on other channels 21010 01220 B’s broadcast Node A Node B Seeds 1212 2222 SSCH Approach Rebroadcast the packet over ‘X’ consecutive slots  a greater number of nodes receive the broadcast B’s broadcast in SSCH

41. Spring 2005CMPE257 UCSC41 Simulation Environment QualNet simulator: n IEEE 802.11a at 54 Mbps, 13 channels n Slot Time of 10 ms and 4 seeds per node p a parity slot comes after 4*13+1 = 53 slots, p 53 slots is: 53*10 ms = 530 ms n Channel Switch Time: 80 µs p Chipset specs [Maxim04], p EE literature [J. Solid State Circuits 03] n CBR flows of 512 byte packets per 50 µs

42. Spring 2005CMPE257 UCSC42 SSCH: Stationary Throughput Per-Flow throughput for disjoint flows IEEE 802.11a SSCH SSCH significantly outperforms single channel IEEE 802.11a

43. Spring 2005CMPE257 UCSC43 SSCH Handles Broadcasts 10 Flows in a 100 node network using DSR For DSR, 6 broadcasts works well (also true for AODV) Average discovery time for IEEE 802.11a Average route length for IEEE 802.11a

44. Spring 2005CMPE257 UCSC44 SSCH in Multihop Mobile Networks Random waypoint mobility: Speeds min: 0.01 m/s max: rand(0.2, 1) m/s Average flow throughput for IEEE 802.11a Average route length for IEEE 802.11a SSCH achieves much better throughput although it forces DSR to discover slightly longer routes

45. Spring 2005CMPE257 UCSC45 Conclusions SSCH is a new channel hopping protocol that: n Improves capacity using a single radio n Does not require a dedicated control channel n Works in multi-hop mobile networks p Handles broadcasts p Supports multiple destinations (partial sync)

46. Spring 2005CMPE257 UCSC46 Future Work n Analyze TCP performance over SSCH n Study interoperability with non-SSCH nodes n Study interaction with 802.11 auto-rate n Implement and deploy SSCH (MultiNet)

47. Spring 2005CMPE257 UCSC47 References  [SV04] So and Vaidya, Multi-Channel MAC for Ad Hoc Networks: Handling Multi-Channel Hidden Terminals Using a Single Transceiver, in Proc. of ACM MobiHoc 2004.  [BCD04] Bahl et al., SSCH: Slotted Seeded Channel Hopping for Capacity Improvement in IEEE 802.11 Ad-Hoc Wireless Networks, in Proc. of ACM MobiCom 2004.

48. Spring 2005CMPE257 UCSC48 Acknowledgments n Parts of the presentation are adapted from the following sources: p So’s ACM MobiHoc 2004 presentation p Ranveer Chandra, Cornell University, r http://www.cs.cornell.edu/people/ranveer/multinet /ssch_mobicom.ppt http://www.cs.cornell.edu/people/ranveer/multinet /ssch_mobicom.ppt