1 / 29

Starvation Mitigation Through MultiChannel Coordination in CSMA Multihop Wireless Networks

Starvation Mitigation Through MultiChannel Coordination in CSMA Multihop Wireless Networks. Jingpu Shi, Theodoros Salonidis, and Edward W. Knightly The 7th ACM international symposium on Mobile ad hoc networking and computing (MobiHoc '06). Outline. Introduction Related work

jaimie
Download Presentation

Starvation Mitigation Through MultiChannel Coordination in CSMA Multihop Wireless Networks

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Starvation Mitigation Through MultiChannel Coordination in CSMA Multihop Wireless Networks Jingpu Shi, Theodoros Salonidis, and Edward W. Knightly The 7th ACM international symposium on Mobile ad hoc networking and computing (MobiHoc '06)

  2. Outline • Introduction • Related work • Multi-Channel MAC for Ad Hoc Networks:Handling Multi-Channel Hidden Terminals Using A Single Transceiver (MMAC) • Asynchronous Multi-channel Coordination Protocol (AMCP) • Simulation • Conclusion

  3. Introduction • Motivation • Increases throughput • Addresses the fundamental coordination problems that lead to flow starvation • Multi-Channel Hidden Terminal Problem • Missing Receiver Problem

  4. RTS(A) RTS(A) RTS(A) Introduction-Information Asymmetry of Single Channel A a B b • Bb know when to contend channel • Repeated collisions at A, repeats doubling its contention window • Aa throughput low Bb t Aa t t

  5. Introduction-Flow-in-the-Middle of Single Channel b a A B C c • Bb throughput low almost zero Aa t Bb t Cc t

  6. RTS(B)CTS(b) Data(B)+ACK(b) RTS(B)CTS(b) Data(B)+ACK(b) RTS(B)CTS(b) Data(B)+ACK(b) RTS(B)CTS(b) Data(B)+ACK(b) Introduction-Starvation avoidance throughmultiple channels • Multiple channels increase throughput Bb Data channel 2 t Aa Data channel 1 t

  7. Bb Bb Data(B)+ACK(b) Data(B)+ACK(b) Data(A)+ACK(a) Aa RTS(B)CTS(b) RTS(B)CTS(b) RTS(A)CTS(a) Introduction-Starvation avoidance throughmultiple channels • Multiple channels increase throughput Data channel 2 t Data channel 1 t t Control channel

  8. 1 RTS(B) RTS(A) Control channel CTS(b) CTS(a) RTS(B) Data(A) Control channel Data channel 1 Data(B) Data channel 1 Data(B) Either listen or transmit Introduction-Multi-channel Hidden Terminal Problem A a B b Data channel 2 collision

  9. RTS(B) CTS(C) Control channel RTS(A) Data channel 2 Either listen or transmit Introduction-Missing Receiver Problem • Missing Receiver Problem • When control packets sent on a certain channel to access an intended receiver fail • Because this node is currently on a different channel D A B C Control channel Data channel 1

  10. Default channel Nodes identify a channel as Default channel (Ex: Data Channel 1) In ATIM-Window time as control channel Outside of ATIM-Windowtime as a common Data- Channel Structure of MMAC Global synchronization Beacon Interval divides ATIM-Window Data Channel Related work-Multi-Channel MAC for Ad Hoc Networks (MMAC) (ACM MobiHoc’04) ATIM-Window Data-Channel Beacon Interval

  11. Related work-Multi-Channel MAC for Ad Hoc Networks (MMAC) (ACM MobiHoc’04) • Preferable Channel List (PCL) in each node • High preference (HIGH) • This channel has already been selected by the node for use in the current beacon interval • At most one can be in this state at each other for each beacon interval • Medium preference (MID) • This channel has not yet been taken for use in the transmission range of the node • Low preference (LOW) • This channel is already taken by at least one the node’s immediate neighbors

  12. Related work-Multi-Channel MAC for Ad Hoc Networks (MMAC) (ACM MobiHoc’04) • Channels states change • When the node is power on • All the channels in the PCL reset to MID and at the start of each beacon interval. • If the source and destination nodes agree upon a channel • They both record the channel to be in HIGH state. • If a node overhears an ATIM-ACK or ATIM-RES • It changes the state of the channel to be LOW

  13. ATIM ATIM-ACK ATIM-RES Y N • S sends ATIM-RES to D • S’ neighbor nodes update their PCL • S waits for next beacon interval S and D switch to the selected channel Related work-Multi-Channel MAC for Ad Hoc Networks (MMAC) (ACM MobiHoc’04) • Channel Negotiation during ATIM Window • D selects a channel based on PCL of S,D • PCL of D has higher priority S D S judges the channel to use or not? (selected by D)

  14. ATIM-RES(1) ATIM RTS Data ATIM-ACK(1) CTS ACK ATIM-ACK(1) C sets(1) LOW Related work-Multi-Channel MAC for Ad Hoc Networks (MMAC) (ACM MobiHoc’04) Channel 1 (Default Channel) Selected Channel • Select Channels Rules • If Selected HIGH of B’s PCL • Else if Selected HIGH of A’s PCL • Else if Selecte MID of both A and B’s PCL • If all channels are LOW,add the counters of A,B PCL A B C Beacon Interval

  15. Asynchronous Multi-channel Coordination Protocol (AMCP) • Structures and variables • A local N-entry Channel (Data-Channel)Table • Avail_bitindicaets channel availability • Unavailable (avail_bit = 0) • Avaiable(avail_bit = 1) • Avail_timerindicates the remaining time • A channel is not available • An integer prefer variable takes values from 0 to N • Prefer ≠0 • Node prefers to compete for the data channel indexed by prefer • Prefer＝0:No preference

  16. RTS RTS Asynchronous Multi-channel Coordination Protocol (AMCP) • Reservation/transmission cycle • Initially all nodes reside on the control channel a A C • Steps 1:Channel selection • A selects a data channel by inspecting its channel table • Ex:A:{1,2,3} • Case1: (prefer!=0 and avail_bit=1) • Case2: (prefer=0 and avail_bit=1) • Case3:(if all avail_bit=0 then wait until any of avail_timer=0) • Steps 2:Channel contention • A selects :{1,2,3} • A insert 2 into RTS and contends on control channel • 802.11 CSMA/CA • Includes NAV

  17. Con_CTS Rej_CTS RTS RTS C a A Asynchronous Multi-channel Coordination Protocol (AMCP) • 1 A={1 ,2 ,3 } a A C Case1:a={2,3,4} Case2:a={3,4,5} • Steps 3:Channel negotiation • a receives RTS(A) then a inspects its channel table • Case1:a returns Confirming_CTS(2) to A then switches to channel 2 →A changes to channel 2 and transmits data to a • Case2:a returns Rejecting_CTS(0) and a list of available channels:(3) then remains on the control channel →A random selects a channel available in both A and a’s list of tables • Case1:if C’s neighbor is A when C overhears RTS(A) →C sets avail_bit(2)=0 and stars avail_timer(2) • Case2:if C’s neighbor is a when C overhears Confirming_CTS(a) →Csets avail_bit(2)=0 and starts avail_timer(2) • Case3: if C’s neighbor is awhen C overhears Rejecting_CTS(a) → C no action is needed

  18. ACK Asynchronous Multi-channel Coordination Protocol (AMCP) Con_CTS:Channel 2 Rej_CTS:Channel 3 a A C • Steps 4:Data transmission • a returns ACK(a) to A on channel x • A and a change to control channel • Steps 5:Setting channel availability • After A and a change to control channel • A and a set prefer_variable to channel x • A and a set avail_bit(x)=0 then start avail_timer for other channels except channel x

  19. 1 RTS(B) RTS(A) CTS(b) CTS(a) RTS(B) Asynchronous Multi-channel Coordination Protocol (AMCP) A a B b Control channel Data channel 2 Data channel 1 Control channel Data(A) collision Data(B) Data(B) Data channel 1 Solution of Multi-channel Hidden Terminal Problem • Because A and a has set prefer_variable to channel 1 • B sets avail_bit(1)=0 and starts avail_timer(1) • Whether channel 1 available or not • If B hears any RTS/CTS in avail_timer(1) period, B defers but will have synchronized for contention on channel 1

  20. B does not necessarily remain idle after the channel 1 timer is set. B will start contending immediately for channel 2 (Prefer_variable(2)) B succeeds in capturing channel 2 Tsucced Data(B)+ACK(b) RTS(B)CTS(b) Data(A)+ACK(a) Asynchronous Multi-channel Coordination Protocol (AMCP) Bb:Prefer_variable(2) Data(B)+ACK(b) t Data channel 2 Data channel 1 t RTS(A)CTS(a) Control channel t

  21. If Cc wins channel 2 and then flow Aa wins channel 1 before the channel 1 timer expiration Although B has lost both contentions, it has synchronized on both data transmission Bb has an advantage in capturing both channels, and counting down a single back-off counter Aa and Cc only compete for its preferred channel, according to a fresh back-off counter Tsync Data(C)+ACK(c) RTS(C)CTS(c) Data(A)+ACK(a) Asynchronous Multi-channel Coordination Protocol (AMCP) Data(B)+ACK(b) t Data channel 2 Data(A)+ACK(a) Data channel 1 t RTS(A)CTS(a) RTS(A)CTS(a) Control channel t

  22. Asynchronous Multi-channel Coordination Protocol (AMCP) • A intends to send data to B • If A receives RTS(B) on control channel • A defers until the transmission over and back-off • A sets CWmin and will fairly contend for B when B is in idle state • Key reason of A quickly synchronizing with B • All control messages are transmitted on a dedicated control channel • A can hear another RTS from B RTS(B) Channel2 A B C Missing Receiver Problem

  23. Simulation

  24. Simulation- Single-Hop flow starvation scenarios 2 1 A a B b

  25. Simulation-Single-Hop flow starvation scenarios b 2 1 3 a A B C c

  26. Simulation- Multil-Hop Topology MMAC uses synchronized contention AMCP 802.11 MMAC

  27. Due to ATIM window overhead • Due to random select channel Simulation-Multil-Hop Topology AMCP MMAC 802.11

  28. Conclusion • AMCP is a distributed medium access protocol • It utilizes multiple channels to address starvation in a multi-hop wireless network. • It prevents further coordination problems • Its benefits are achieved using minimal amount of resources • No infrastructure support such as global time synchronization

  29. Thanks for Your Listening

More Related