1 / 20

Simple improvement for EDCA usage in 802.11s

Simple improvement for EDCA usage in 802.11s. Date: 2008-11-11. Authors:. Abstract. We present a simple modification to EDCA that inherently avoids congesting the wireless medium (WM). EDCA – A single hop protocol.

bunme
Download Presentation

Simple improvement for EDCA usage in 802.11s

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. Simple improvement for EDCA usage in 802.11s Date: 2008-11-11 Authors: Guido R. Hiertz et al., Philips

  2. Abstract We present a simple modification to EDCA that inherently avoids congesting the wireless medium (WM). Guido R. Hiertz et al., Philips

  3. EDCA – A single hop protocol • All current 802.11 MAC Coordination Functions (CFs) have been designed for single hop networks • DCF and EDCA use opportunistic medium access • 1st listen 2nd transmit if free • Derived from ALOHA • Works nice for single hop networks • Bad performance in multi-hop networks • Selfish behavior does not take relaying/forwarding into account • Severe impact for multi-hop networks Guido R. Hiertz et al., Philips

  4. Inherent solutions • Inherent solutions avoid problems without additional packages on top • TGs’ motto: “Perfection is achieved not when there is nothing left to add but when there is nothing left to take away.” • So, adding a mechanism to resolve a problem is not the preferred solution • Inherently resolving a problem so that it cannot occur is the way to go Guido R. Hiertz et al., Philips

  5. Modified EDCA • Following each frame transmission, a Mesh STA set its NAV, when the frame(s) need to be forwarded by the next Mesh STA • NAV duration = duration of last transmission • Last transmission = single frame or duration of last TXOP • A Mesh STA does not set its NAV, when the frame(s) sent need not be forwarded Guido R. Hiertz et al., Philips

  6. Simulation scenario • Mesh STA 1 sends traffic to Mesh STA 4 • Mesh STA 4 sends traffic to Mesh STA 1 • MSDU frame body = IP frame • IP payload = 1000B • All STAs transmit at BPSK ½ (6Mb/s) • 5GHz channel model, 802.11a • Only neighboring STAs can sense each other • Neighbor’s neighbors are hidden • Traffic arrival: Poissonprocess Guido R. Hiertz et al., Philips

  7. Modified EDCA (example) • Performs modified EDCA • Set NAV after each transmission • NAV duration accordingto last transmission • NAV = Twice the last transmission duration • Does not perform modified EDCA • Mesh STA is last hop • No forwarding required  No NAV setting required Guido R. Hiertz et al., Philips

  8. Simulation results • Realistic channel model • Incorporates interference • SINR based frame error probability • Open source: http://www.openwns.org Guido R. Hiertz et al., Philips

  9. Throughput (one route) • Modified EDCA inherently avoids congestion • Plain EDCA achieves lower maximum throughput Guido R. Hiertz et al., Philips

  10. 1st hop frame transmission rate(Mesh STA 1  Mesh STA 2) • 1st hop reveals the problem • Edge nodes have fewer neighbors • Edge nodes have higher transmission probabilities • 1st hop does not limit its transmissions • Modified EDCA limits the frame transmission rate Guido R. Hiertz et al., Philips

  11. 2nd hop frame transmission rate(Mesh STA 2  Mesh STA 3) • With EDCA, 2nd hop cannot carry the offered traffic & suffers from the selfish behavior on the 1st hop • With modified EDCA, 2nd hop saturates at a traffic level that can be carried Guido R. Hiertz et al., Philips

  12. 3rd hop frame transmission rate(Mesh STA 3  Mesh STA 4) • EDCA severely limits the last hop • Modified EDCA experience much better performance due to the inherent rate control Guido R. Hiertz et al., Philips

  13. 2nd hop frame loss rate(Mesh STA 2  Mesh STA 3) • At 2Mb/s offered traffic, the 2nd hop successfully transmits ~12 frames per second • Additionally, the 2nd loses ~4 frames per second • Modified EDCA avoids frame losses • Traffic does not saturate Guido R. Hiertz et al., Philips

  14. Lost frames = Harmful to everyone … • Lost frames on 2nd hop in one direction • 4 frames lost per second • 4 transmission attempts per frame • AIFS = 34µs • + mean duration of backoff with CW=CWmin = 7.5 * 9µs = 67.5µs • + 1000B @ BPSK½ ≙ 1,424µs • + ACKTimeout = aSIFSTime + aSlotTime + aPHY-RX-START-Delay = 16µs + 9µs + 25µs = 50µs • + AIFS = 34µs • + mean duration of backoff with CW=(CWmin+1)*2 -1 = 31 * 9µs = 139.5µs • + 1000B @ BPSK½ ≙ 1,424µs • + ACKTimeout = aSIFSTime + aSlotTime + aPHY-RX-START-Delay = 16µs + 9µs + 25µs = 50µs • + AIFS = 34µs • + mean duration of backoff with CW=(CWmin+1)*22 -1 = 63 * 9µs = 283.5µs • + 1000B @ BPSK½ ≙ 1,424µs • + ACKTimeout = aSIFSTime + aSlotTime + aPHY-RX-START-Delay = 16µs + 9µs + 25µs = 50µs • + AIFS = 34µs • + mean duration of backoff with CW=(CWmin+1)*23 -1 = 127 * 9µs = 544.5µs • + 1000B @ BPSK½ ≙ 1,424µs • + ACKTimeout = aSIFSTime + aSlotTime + aPHY-RX-START-Delay = 16µs + 9µs + 25µs = 50µs •  4 * 7,067µs  at least 28,268µs lost due to retransmissions • AIFS occurs much more often  remember, AIFS occurs each time after the wireless medium becomes idle again Guido R. Hiertz et al., Philips

  15. Thank you for your attention Guido R. Hiertz et al., Philips

  16. References (1)802.11-2007, 9.2.5.3 • Error recovery shall be attempted by retrying transmissions for frame exchange sequences that the initiating STA infers have failed. Retries shall continue, for each failing frame exchange sequence, until the transmission is successful, or until the relevant retry limit is reached, whichever occurs first. […] • This SRC and the SSRC shall be reset when a MAC frame of length less than or equal to dot11RTSThreshold succeeds for that MPDU of type Data or MMPDU. The LRC for an MPDU of type Data or MMPDU and the SLRC shall be incremented every time transmission of a MAC frame of length greater than dot11RTSThreshold fails for that MPDU of type Data or MMPDU. […] Guido R. Hiertz et al., Philips

  17. References (2)802.11-2007, 9.2.5.3 • Retries for failed transmission attempts shall continue until the SRC for the MPDU of type Data or MMPDU is equal to dot11ShortRetryLimit or until the LRC for the MPDU of type Data or MMPDU is equal to dot11LongRetryLimit. When either of these limits is reached, retry attempts shall cease, and the MPDU of type Data (and any MSDU of which it is a part) or MMPDU shall be discarded. Guido R. Hiertz et al., Philips

  18. References (3) 802.11-2007, Annex D • dot11RTSThreshold OBJECT-TYPESYNTAX INTEGER (0..3000)MAX-ACCESS read-writeSTATUS currentDESCRIPTION"This attribute shall indicate the number of octets in an MPDU, below which an RTS/CTS handshake shall not be performed, except as RTS/CTS is used as a cross modulation protection mechanism as defined in 9.13. An RTS/CTS handshake shall be performed at the beginning of any frame exchange sequence where the MPDU is of type Data or Management, the MPDU has an individual address in the Address1 field, and the length of the MPDU is greater than this threshold. Setting this attribute to be larger than the maximum MSDU size shall have the effect of turning off the RTS/CTS handshake for frames of Data or Management type transmitted by this STA. Setting this attribute to zero shall have the effect of turning on the RTS/CTS handshake for all frames of Data or Management type transmitted by this STA. The default value of this attribute shall be 3000.”::= { dot11OperationEntry 2 } Guido R. Hiertz et al., Philips

  19. References (4)802.11-2007, Annex D • dot11LongRetryLimit OBJECT-TYPESYNTAX INTEGER (1..255)MAX-ACCESS read-writeSTATUS currentDESCRIPTION"This attribute shall indicate the maximum number of transmission attempts of a frame, the length of which is greater than dot11RTSThreshold, that shall be made before a failure condition is indicated. The default value of this attribute shall be 4.”::= { dot11OperationEntry 4 } Guido R. Hiertz et al., Philips

  20. Reference (5) • “A simple & scalable traffic engineering solution for 802.11s,” https://mentor.ieee.org/802.11/file/07/11-07-2534-00-000s-a-simple-scalable-traffic-engineering-solution-for-802-11s.ppt Guido R. Hiertz et al., Philips

More Related