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

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)

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

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 DCF to work in multi-channel environment 1 2

Spring 2005CMPE257 UCSC 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

Spring 2005CMPE257 UCSC Power Saving Mechanism A B C Time Beacon ATIM Window Beacon Interval

Spring 2005CMPE257 UCSC Power Saving Mechanism A B C Time Beacon ATIM ATIM Window Beacon Interval

Spring 2005CMPE257 UCSC Power Saving Mechanism A B C Time Beacon ATIM ATIM-ACK ATIM Window Beacon Interval

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

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

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

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

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

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

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

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

Spring 2005CMPE257 UCSC17 MMAC n Idea similar to IEEE 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

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

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

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

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

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

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

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 : IEEE single channel protocol p DCA: Wu’s protocol p MMAC: Proposed protocol

Spring 2005CMPE257 UCSC25 Wireless LAN - Throughput 30 nodes64 nodes MMAC DCA MMAC shows higher throughput than DCA and DCA MMAC Packet arrival rate per flow (packets/sec) Aggregate Throughput (Kbps)

Spring 2005CMPE257 UCSC26 Multi-hop Network – Throughput 3 channels4 channels MMAC DCA DCA MMAC Packet arrival rate per flow (packets/sec) Packet arrival rate per flow (packets/sec) Aggregate Throughput (Kbps)

Spring 2005CMPE257 UCSC27 Throughput of DCA and MMAC (Wireless LAN) DCA MMAC 2 channels MMAC shows higher throughput compared to DCA 6 channels channels 6 channels Aggregate Throughput (Kbps) Packet arrival rate per flow (packets/sec)

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

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

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

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)

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

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

Spring 2005CMPE257 UCSC34 SSCH: Slots and Seeds Divide time into slots: switch channels at beginning of a slot 3 channels E.g. for b Ch 1 maps to 0 Ch 6 maps to 1 Ch 11 maps to 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

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 Seed Follow A: Change next (channel, seed) to (2, 2) A B Stale (channel, seed) info simply results in delayed syncing B wants to start a flow with A 2

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 A B

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 A B

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 (1 + 1) mod 3 = 2 (2 + 2) mod 3 = 1 Parity Slot = seed 1

Spring 2005CMPE257 UCSC39 Illustration of the SSCH Protocol Node A 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) Seeds Suppose each node has 2 seeds, and hops through 3 channels.

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 B’s broadcast Node A Node B Seeds SSCH Approach Rebroadcast the packet over ‘X’ consecutive slots  a greater number of nodes receive the broadcast B’s broadcast in SSCH

Spring 2005CMPE257 UCSC41 Simulation Environment QualNet simulator: n IEEE a 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

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

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 a Average route length for IEEE a

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 a Average route length for IEEE a SSCH achieves much better throughput although it forces DSR to discover slightly longer routes

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)

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

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  [BCD04] Bahl et al., SSCH: Slotted Seeded Channel Hopping for Capacity Improvement in IEEE Ad-Hoc Wireless Networks, in Proc. of ACM MobiCom 2004.

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 /ssch_mobicom.ppt /ssch_mobicom.ppt