480 likes | 664 Views
CMPE 257: Wireless and Mobile Networking SET 3m:. Medium Access Control Protocols. MAC Protocol Topics. MAC protocols using multiple channels with one transceiver only MMAC (Multi-channel MAC) SSCH (Slotted Seeded Channel Hopping). 1. 1. 2. defer. Motivation for Multi-Channel.
E N D
CMPE 257: Wireless and Mobile NetworkingSET 3m: Medium Access Control Protocols UCSC CMPE252B
MAC Protocol Topics • MAC protocols using multiple channels with one transceiver only • MMAC (Multi-channel MAC) • SSCH (Slotted Seeded Channel Hopping) CMPE257 UCSC
1 1 2 defer Motivation for Multi-Channel • Multiple orthogonal channels available in IEEE 802.11 • 3 channels in 802.11b • 12 channels in 802.11a • Utilizing multiple channels can improve throughput • Allow simultaneous transmissions Single channel Multiple Channels CMPE257 UCSC
1 2 Problem Statement • Using k channels does not translate into throughput improvement by a factor of k • Nodes listening on different channels cannot talk to each other • Constraint: Each node has only a single transceiver • Capable of listening to one channel at a time • Goal: Design a MAC protocol that utilizes multiple channels to improve overall performance • Modify 802.11 DCF to work in multi-channel environment CMPE257 UCSC
802.11 Power Saving Mechanism • Time is divided into beacon intervals • All nodes wake up at the beginning of a beacon interval for a fixed duration of time (ATIM window) • Exchange ATIM (Ad-hoc Traffic Indication Message) during ATIM window • Nodes that receive ATIM message stay up during for the whole beacon interval • Nodes that do not receive ATIM message may go into doze mode after ATIM window CMPE257 UCSC
802.11 Power Saving Mechanism Beacon Time A B C ATIM Window Beacon Interval CMPE257 UCSC
802.11 Power Saving Mechanism Beacon Time ATIM A B C ATIM Window Beacon Interval CMPE257 UCSC
802.11 Power Saving Mechanism Beacon Time ATIM A B ATIM-ACK C ATIM Window Beacon Interval CMPE257 UCSC
Multi-Channel Hidden Terminals • Consider the following naïve protocol • Static channel assignment (based on node ID) • Communication takes place on receiver’s channel • Sender switches its channel to receiver’s channel before transmitting CMPE257 UCSC
A C B Multi-Channel Hidden Terminals Channel 1 Channel 2 RTS A sends RTS CMPE257 UCSC
A C B Multi-Channel Hidden Terminals Channel 1 Channel 2 CTS B sends CTS C does not hear CTS because C is listening on channel 2 CMPE257 UCSC
A B Multi-Channel Hidden Terminals Channel 1 Channel 2 DATA RTS C C switches to channel 1 and transmits RTS Collision occurs at B CMPE257 UCSC
Nasipuri’s Protocol • Assumes N transceivers per host • Capable of listening to all channels simultaneously • Sender searches for an idle channel and transmits on the channel [Nasipuri99WCNC] • Extensions: channel selection based on channel condition on the receiver side [Nasipuri00VTC] • Disadvantage: High hardware cost CMPE257 UCSC
Wu’s Protocol [Wu00ISPAN] • Assumes 2 transceivers per host • One transceiver always listens on control channel • Negotiate channels using RTS/CTS/RES • RTS/CTS/RES packets sent on control channel • Sender includes preferred channels in RTS • Receiver decides a channel and includes in CTS • Sender transmits RES (Reservation) • Sender sends DATA on the selected data channel CMPE257 UCSC
Wu’s Protocol (cont.) • Advantage • No synchronization required • Disadvantage • Each host must have 2 transceivers • Per-packet channel switching can be expensive • Control channel bandwidth is an issue • Too small: control channel becomes a bottleneck • Too large: waste of bandwidth • Optimal control channel bandwidth depends on traffic load, but difficult to dynamically adapt CMPE257 UCSC
Proposed Protocol (MMAC) • Assumptions • Each node is equipped with a single transceiver • The transceiver is capable of switching channels • Channel switching delay is approximately 250us • Per-packet switching not recommended • Occasional channel switching not to expensive • Multi-hop synchronization is achieved by other means CMPE257 UCSC
MMAC • Idea similar to IEEE 802.11 PSM • Divide time into beacon intervals • At the beginning of each beacon interval, all nodes must listen to a predefined common channel for a fixed duration of time (ATIM window) • Nodes negotiate channels using ATIM messages • Nodes switch to selected channels after ATIM window for the rest of the beacon interval CMPE257 UCSC
Preferred Channel List (PCL) • Each node maintains PCL • Records usage of channels inside the transmission range • High preference (HIGH) • Already selected for the current beacon interval • Medium preference (MID) • No other vicinity node has selected this channel • Low preference (LOW) • This channel has been chosen by vicinity nodes • Count number of nodes that selected this channel to break ties CMPE257 UCSC
Channel Negotiation • In ATIM window, sender transmits ATIM to the receiver • Sender includes its PCL in the ATIM packet • Receiver selects a channel based on sender’s PCL and its own PCL • Order of preference: HIGH > MID > LOW • Tie breaker: Receiver’s PCL has higher priority • For “LOW” channels: channels with smaller count have higher priority • Receiver sends ATIM-ACK to sender including the selected channel • Sender sends ATIM-RES to notify its neighbors of the selected channel CMPE257 UCSC
Channel Negotiation Common Channel Selected Channel A Beacon B C D Time ATIM Window CMPE257 UCSC Beacon Interval
Channel Negotiation Common Channel Selected Channel ATIM- RES(1) ATIM A Beacon B ATIM- ACK(1) C D Time ATIM Window CMPE257 UCSC Beacon Interval
Channel Negotiation Common Channel Selected Channel ATIM- RES(1) ATIM A Beacon B ATIM- ACK(1) ATIM- ACK(2) C D ATIM Time ATIM- RES(2) ATIM Window CMPE257 UCSC Beacon Interval
Channel Negotiation Common Channel Selected Channel ATIM- RES(1) RTS DATA Channel 1 ATIM A Beacon Channel 1 B CTS ACK ATIM- ACK(1) ATIM- ACK(2) CTS ACK Channel 2 C Channel 2 D ATIM DATA RTS Time ATIM- RES(2) ATIM Window CMPE257 UCSC Beacon Interval
Simulation Model • ns-2 simulator • Transmission rate: 2Mbps • Transmission range: 250m • Traffic type: Constant Bit Rate (CBR) • Beacon interval: 100ms • Packet size: 512 bytes • ATIM window size: 20ms • Default number of channels: 3 channels • Compared protocols • 802.11: IEEE 802.11 single channel protocol • DCA: Wu’s protocol • MMAC: Proposed protocol CMPE257 UCSC
Wireless LAN - Throughput 2500 2000 1500 1000 500 2500 2000 1500 1000 500 MMAC MMAC DCA DCA Aggregate Throughput (Kbps) 802.11 802.11 1 10 100 1000 1 10 100 1000 Packet arrival rate per flow (packets/sec) Packet arrival rate per flow (packets/sec) 30 nodes 64 nodes MMAC shows higher throughput than DCA and 802.11 CMPE257 UCSC
Multi-hop Network – Throughput 2000 1500 1000 500 0 1500 1000 500 0 MMAC MMAC DCA DCA Aggregate Throughput (Kbps) 802.11 802.11 1 10 100 1000 1 10 100 1000 Packet arrival rate per flow (packets/sec) Packet arrival rate per flow (packets/sec) 3 channels 4 channels CMPE257 UCSC
Throughput of DCA and MMAC(Wireless LAN) 4000 3000 2000 1000 0 4000 3000 2000 1000 0 6 channels 6 channels 2 channels Aggregate Throughput (Kbps) 2 channels 802.11 802.11 Packet arrival rate per flow (packets/sec) Packet arrival rate per flow (packets/sec) MMAC DCA MMAC shows higher throughput compared to DCA CMPE257 UCSC
Analysis of Results • DCA • Bandwidth of control channel significantly affects performance • Narrow control channel: High collision and congestion of control packets • Wide control channel: Waste of bandwidth • It is difficult to adapt control channel bandwidth dynamically • MMAC • ATIM window size significantly affects performance • ATIM/ATIM-ACK/ATIM-RES exchanged once per flow per beacon interval – reduced overhead • Compared to packet-by-packet control packet exchange in DCA • ATIM window size can be adapted to traffic load CMPE257 UCSC
Conclusion and Future Work • Conclusion: • MMAC requires a single transceiver per host to work in multi-channel ad hoc networks • MMAC achieves throughput performance comparable to a protocol that requires multiple transceivers per host • Future work • Dynamic adaptation of ATIM window size based on traffic load for MMAC • Efficient multi-hop clock synchronization CMPE257 UCSC
Motivation: Improving Capacity Traffic on orthogonal channels do not interfere e.g. Channels 1, 6 and 11 for IEEE 802.11b Can we get the benefits of multiple channels in ad hoc networks? Example: An IEEE 802.11b network with 3 Access Points Channel 1 Channel 6 Channel 6 Channel 11 CMPE257 UCSC
Channel Hopping: Prior Work • Using multiple radios: • DCA (ISPAN’00): a control and a data channel • MUP (Broadnets’04): multiple data channels • Consumes more power, expensive • Using non-commodity radios: • HRMA (Infocom’99): high speed FHSS networks • Nasipuri et al, Jain et al: listen on many channels • Expensive, not easily available • Using a single commodity radio: • Multi-channel MAC (MMAC) (Mobihoc’04) CMPE257 UCSC
Channel Hopping: MMAC MMAC Basic idea: Periodically rendezvous on a fixed channel to decide the next channel Issues • Packets to multiple destinations high delays • Control channel congestion • Does not handle broadcasts Channel 1 Channel 6 Channel 11 Data Control Data Data Control CMPE257 UCSC
SSCH A new channel hopping protocol that • Increases network capacity using multiple channels • Overcomes limitations of dedicated control channel • No control channel congestion • Handles multiple destinations without high delays • Handles broadcasts for MANET routing CMPE257 UCSC
SSCH: Slots and Seeds Divide time into slots: switch channels at beginning of a slot New Channel = (Old Channel + seed) mod (Number of Channels) seed is from 1 to (Number of Channels - 1) (1 + 2) mod 3 = 0 Seed = 2 3 channels E.g. for 802.11b Ch 1 maps to 0 Ch 6 maps to 1 Ch 11 maps to 2 A 0 2 1 0 2 0 1 1 B Seed = 1 0 1 2 0 1 2 0 1 (0 + 1) mod 3 = 1 • Enables bandwidth utilization across all channels • Does not need control channel rendezvous CMPE257 UCSC
Follow A: Change next (channel, seed) to (2, 2) SSCH: Syncing Seeds • Each node broadcasts (channel, seed) once every slot • If B has to send packets to A, it adjusts its (channel, seed) Seed 2 2 2 2 2 2 2 2 2 A 0 2 1 0 2 0 2 1 1 3 channels B wants to start a flow with A B 2 0 1 2 1 0 2 1 0 2 1 1 2 2 2 2 2 2 Seed Stale (channel, seed) info simply results in delayed syncing CMPE257 UCSC
Nodes might not overlap! If seeds are same and channels are different in a slot: Seed = 2 0 2 1 0 2 0 A 1 1 3 channels B Seed = 2 2 1 1 0 2 1 0 2 Nodes are off by a slot Nodes will not overlap CMPE257 UCSC
SSCH: Parity Slots Every (Number of Channels+1) slot is a Parity Slot In the parity slot, the channel number is the seed A Seed = 1 1 2 1 0 1 2 1 0 3 channels B Seed = 1 0 1 1 2 0 1 1 2 Parity Slot Parity Slot Guarantee: If nodes change their seeds only after the parity slot, then they will overlap CMPE257 UCSC
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 (2 +2)mod 3 = 1 1 2 2 1 0 0 1 1 2 2 1 0 0 Parity Slot = seed 1 (1 +1) mod 3 = 2 CMPE257 UCSC
Illustration of the SSCH Protocol Suppose each node has 2 seeds, and hops through 3 channels. Seeds 1 2 1 2 1 2 1 2 1 2 1 2 Node A 1 2 2 1 0 0 1 1 2 2 1 0 0 B wants to start a flow with A Node B 1 2 0 1 2 0 2 1 2 2 1 0 0 Seeds 2 1 2 2 2 2 1 2 1 2 1 2 Partial Sync (only 2nd seed) Seeds: (2, 2) Channels: (2, 1) Complete Sync (sync 1st seed) Seeds (1, 2) Channels: (1, 2) CMPE257 UCSC
SSCH: Handling Broadcasts A single broadcast attempt will not work with SSCH since packets are not received by neighbors on other channels Seeds 1 2 1 2 Node A 2 1 0 0 1 B’s broadcast B’s broadcast in SSCH Node B 0 1 2 0 2 Seeds 2 2 2 2 SSCH Approach Rebroadcast the packet over ‘X’ consecutive slots a greater number of nodes receive the broadcast CMPE257 UCSC
Simulation Environment QualNet simulator: • IEEE 802.11a at 54 Mbps, 13 channels • Slot Time of 10 ms and 4 seeds per node • a parity slot comes after 4*13+1 = 53 slots, • 53 slots is: 53*10 ms = 530 ms • Channel Switch Time: 80 µs • Chipset specs [Maxim04], • EE literature [J. Solid State Circuits 03] • CBR flows of 512 byte packets per 50 µs CMPE257 UCSC
SSCH: Stationary Throughput Per-Flow throughput for disjoint flows SSCH IEEE 802.11a SSCH significantly outperforms single channel IEEE 802.11a CMPE257 UCSC
SSCH Handles Broadcasts 10 Flows in a 100 node network using DSR Average route length for IEEE 802.11a Average discovery time for IEEE 802.11a For DSR, 6 broadcasts works well (also true for AODV) CMPE257 UCSC
SSCH in Multihop Mobile Networks Random waypoint mobility: Speeds min: 0.01 m/s max: rand(0.2, 1) m/s Average route length for IEEE 802.11a Average flow throughput for IEEE 802.11a SSCH achieves much betterthroughput although it forces DSR to discover slightly longerroutes CMPE257 UCSC
Conclusions SSCH is a new channel hopping protocol that: • Improves capacity using a single radio • Does not require a dedicated control channel • Works in multi-hop mobile networks • Handles broadcasts • Supports multiple destinations (partial sync) CMPE257 UCSC
Future Work • Analyze TCP performance over SSCH • Study interoperability with non-SSCH nodes • Study interaction with 802.11 auto-rate • Implement and deploy SSCH (MultiNet) CMPE257 UCSC
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. CMPE257 UCSC
Acknowledgments • Parts of the presentation are adapted from the following sources: • So’s ACM MobiHoc 2004 presentation • Ranveer Chandra, Cornell University, • http://www.cs.cornell.edu/people/ranveer/multinet/ssch_mobicom.ppt CMPE257 UCSC