Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Special Topics in Computer Engineering Wireless Networks By: Mohammad Nassiri Bu-Ali Sina University, Hamedan Access method in Wireless Ad-hoc Networks Ad-hoc mode in 802.11 Ad Hoc Simplest Rapid deployment Peer-to-peer No administration Basically, ad-hoc mode in 802.11 does not support multi-hop transmission. However, there are a lot of mechanisms to provide the multihop transmission with the help of Layer-3, namely, IP layer. Multi-hop Ad-hoc Networks An Ad-hoc network Direct transmission with neighboring nodes Each node can be router and so it can relay traffic. B relays packet from A to C Self-configuration, Self- healing In this lecture, MAC issues in Wireless Ad-hoc Networks Recall Rx = Reception Range CS = Carrier Sensing Range A can communicate to B C can only sense a transmission emitted from A D cannot overhear A RTS/CTS for hidden problem D and C are hidden to A D is within CSR of B A sends to B, D sends to B, collision is possible. RTS/CTS fails to resolve hidden terminal in this case RTS/CTS for exposed nodes ? RTS/CTS cannot handle exposed node problem The left-hand scenario Masked node C cannot decode CTS from B It’s NAV is not up to date. Later it can collide the transmission of A to B by sending an RTS. C is masked by B and D Blocked nodes in 3 pairs We consider blocked nodes in the scenario of three parallel pairs node in the middle has almost no possibility to access the channel Studied by Chaudet et al. 2005 e.g. each pair in a room A, C and E are emitters Emitter C is starved by transmissions of A and E. 9 Three pairs How does legacy DCF work in this scenario when A and E are transmitting ? EIFS DIFS A Backoff DATA DATA Busy Channel DATA DATA DATA DATA C E DATA DATA DATA DATA C is starved by A and E 10 Three pairs How does legacy DCF work in this scenario when C is transmitting ? EIFS DIFS Backoff Busy Channel E DATA DATA A C DATA DATA DATA DATA DATA Long term Unfairness 11 DCF evaluation in a chain Throughput for chain with different length Claude Chaudet: IEEE com. Magazine 2005 Next 5 slides from Does the IEEE 802.11 MAC Protocol Work Well in Multihop Wireless Ad Hoc Networks? Shugong Xu Tark Saadawi June, 2001 IEEE Communications Magazine (Adapted from mnet.cs.nthu.edu.tw/paper/jbb/010704.pps) Serious Unfairness – (1) 2 TCP Connections First session starts at 10.0s ( 6 4 ) Second session starts 20.0s later ( 2 3 ) 1 2 3 4 Source Destination Destination 5 6 Source Serious Unfairness – (2) First session start Second session start Serious Unfairness – (3) The throughput of the first session is zero in most of its lifetime after the second session starts. There is not even a chance for it to restart. The loser session is completely shutdown even if it starts much earlier. Serious Unfairness – (6) Discussion: Node5 cannot reach node4 when • Node2 is sending (collision) • Node3 is sending ACK (defer) 1 2 3 4 Source Destination Destination 5 6 Source Conclusion The hidden terminal problem still exists in multihop networks. The exposed terminal problem will be more harmful in a multihop network and there is no scheme in IEEE 802.11 standard to deal with this problem. The binary exponential backoff scheme always favors the latest successful node. It will cause unfairness. Multiple Channels for Wireless Networks Traditional Ad Hoc Network: Single Channel Each device has 1 radio. All radios are tuned to the same channel. 20 Motivation Exploit multiple channels to improve network throughput’ … why ? 1 1 defer 2 Greater parallel communication is possible Typical Wireless Networks Power Density t=0 t=1 t=2 Each network uses 1 channel only. Sender 1 frequency Can we do better? Sender 2 frequency Sender 3 frequency : : Channel 1 Channel 2 Channel 3 22 Can we do better? Power Density t=0 t=1 t=2 Simultaneous sending on different channels? Sender 1 Sender 4 Sender 3 frequency Sender 2 Sender 1 Sender 4 frequency Sender 3 Sender 4 Sender 2 frequency : : Channel 1 Channel 2 Channel 3 23 Goal Given a wireless network where: M (>1) channels are available each node has 1 tunable radio each node has many neighbors Design a Multi-Channel MAC protocol: increases total network throughput achieves low average delay robust, practical 24 Why Multi-Channel MAC? Multi-Channel MAC t=0 t=1 Sender 1 Sender 4 Sender 3 frequency Sender 2 Sender 1 Sender 4 frequency Single “Super” Channel t=0 t=1 Sender 1 frequency Sender 2 frequency 25 M-Channel Schedule example 26 M-Channel Schedule example 27 Core Design Issues Q1: Which channel is receiver Y listening on? time=t ? ? ? frequency receiver Y Q2: Is channel i free? time=t Free ? Chan i frequency 28 Multi-channel Hidden Terminals Multi-channel Hidden Terminals Observations 1. Nodes may listen to different channels 2. Virtual Carrier Sensing becomes difficult 3. The problem was absent for single channel Multi-Channel MAC Protocols (1) Dedicated Control Channel (2 radios) Dedicated control radio & channel for all control messages DCA [Wu2000], DCA-PC [Tseng2001], DPC [Hung2002]. (2) Split Phase Time divided into alternate (i) channel negotiation phase on default channel & (ii) data transfer phase on all channels MMAC [J.So2003], MAP [Chen et al.] (3) Common Hopping Sequence All idle nodes follow the same channel hopping sequence HRMA [Tang98], CHMA, CHAT [Tzamaloukas2000] (4) Parallel Rendezvous Each node follows its own channel hopping sequence SSCH [Bahl04], McMAC () 31 Protocol (1): Dedicated Control Channel Channel Keys: 2 Radios/Node; Rendezvous on 1 channel; No time sync Ch3 Data (data) Ch2 Data (data) Ack ... Data Ack Ack Ch1 (Ctrl) RTS (2,3) CTS (2) RTS (3) CTS (3) Legend: Node 1 Node 2 Node 3 Node 4 Time 32 Protocol (2): Split-Phase Channel Ch3 Keys: 1 Radio; Rendezvous on a common channel; Coarse time sync ... Unused Ch2 Rts Cts Data Ack ... Ch1 ... ... Rts Cts Data Hello Ack (1,2,3) (1) Ack Hello Ack (2,3) (2) Control Phase Time Data Transfer Phase 33 Protocol (3): Common Hopping Channel Key: 1 radio; Non-busy nodes hop together; Tight time sync Ch4 Ch3 Ch2 Data/Ack ... RTS+CTS Ch1 1 2 3 4 Enough for RTS/CTS 5 6 7 8 9 10 11 Time 34 A MAC protocol based on Split Phase 802.11 PSM (Power Saving Mode) Doze mode – less energy consumption but no communication ATIM – Ad hoc Traffic Indication Message Beacon Time A B C ATIM Window Beacon Interval 802.11 PSM (Power Saving Mode) Beacon A Time ATIM B C ATIM Window Beacon Interval 802.11 PSM (Power Saving Mode) Beacon A Time ATIM B ATIM-ACK C ATIM Window Beacon Interval 802.11 PSM (Power Saving Mode) Beacon A ATIM ATIM-RES B ATIM-ACK C ATIM Window Beacon Interval Time 802.11 PSM (Power Saving Mode) Beacon A ATIM ATIM-RES Time DATA B ATIM-ACK Doze Mode C ATIM Window Beacon Interval 802.11 PSM (Power Saving Mode) Beacon A ATIM ATIM-RES Time DATA B ATIM-ACK ACK Doze Mode C ATIM Window Beacon Interval 802.11 PSM (Power Saving Mode) Summary All nodes wake up at the beginning of a beacon interval for a fixed duration of time (ATIM window) Exchange ATIM 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 MMAC : Assumptions All channels have same BW and none of them are overlapping channels Nodes have only one transceiver Transceivers are capable of switching channels but they are half-duplex Channel switching delay is approx 250 us, avoid per packet switching MMAC : Steps Divide time into beacon intervals At the beginning, nodes listen to a pre-defined channel for ATIM window duration Channel negotiation starts using ATIM messages Nodes switch to the agreed upon channel after the ATIM window duration MMAC Preferred Channel List (PCL) For a node, PCL records usage of channels inside Tx range HIGH preference – always selected MID preference – others in the vicinity did not select the channel LOW preference – others in the vicinity selected the channel MMAC Channel Negotiation Sender transmits ATIM to the receiver and includes its PCL in the ATIM packet Receiver selects a channel based on sender’s PCL and its own PCL Receiver sends ATIM-ACK to sender including the selected channel Sender sends ATIM-RES to notify its neighbors of the selected channel MMAC Common Channel Selected Channel A Beacon B C D Time ATIM Window Beacon Interval MMAC Common Channel ATIMATIM RES(1) A B Selected Channel Beacon ATIMACK(1) C D Time ATIM Window MMAC Common Channel A B C D Selected Channel ATIM ATIMRES(1) Beacon ATIMACK(1) ATIMACK(2) ATIM ATIMRES(2) ATIM Window Time MMAC Common Channel Selected Channel ATIM ATIMRES(1) RTS DATA Channel 1 A Beacon Channel 1 B ATIMACK(1) CTS ATIMACK(2) CTS ACK ACK Channel 2 C Channel 2 D ATIM ATIMRES(2) RTS DATA ATIM Window Beacon Interval Time Experimental Parameters 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 WLAN - Throughput Multi-hop Network - Throughput Analysis For MMAC: ATIM window size significantly affects performance ATIM/ATIM-ACK/ATIM-RES exchanged once per flow per beacon interval – reduced overhead ATIM window size can be adapted to traffic load Discussions 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 Beaconing mechanism may fail to synchronize in a multi-hop network – probabilistic beaconing may help Starvation can occur with common source and multiple destinations Multi-interface Multi-channel Each node has multiple interfaces References J. So, N. Vaidya; ``Multi-Channel MAC for Ad Hoc Networks: Handling Multi-Channel Hidden Terminals Using A Single Transceiver''; Proc. ACM MobiHoc 2004 S.-L.Wu, C.-Y. Lin, Y.-C. Tseng, and J.-P. Sheu. "A new multichannel MAC protocol with on-demand channel assignment for multi-hop mobile ad hoc networks."; In Int’l Symp. on Parallel Architectures, Algorithms and Networks (I-SPAN), 2000. C. Chaudet, D. Dhoutaut, I. G. Lassous, Performance issues with IEEE 802.11 in ad hoc networking , IEEE Communications magazine, Volume 43, Number 7; Pages: 110-116, July 2005 S. Xu, T. Saadawi, Does the IEEE 802.11 MAC Protocol Work Well in Multihop Wireless Ad Hoc Networks?, IEEE Communications magazine, June 2001 Review 1-60