1 / 33

Simple improvement for EDCA usage in 802.11s

Simple improvement for EDCA usage in 802.11s. Date: 2009-01-08. Authors:. Abstract. This revision “r1” incorporates answers to question we received from the audience of our presentation and during intensive discussion in the MAC ad hoc sub-team.

shiloh
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: 2009-01-08 Authors: Guido R. Hiertz et al., Philips

  2. Abstract This revision “r1” incorporates answers to question we received from the audience of our presentation and during intensive discussion in the MAC ad hoc sub-team. We appreciate all feedback we received and welcome the great support of the 802.11s Task Group. 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. Basic scenario … • Alice wants to talk to Chris. However, Alice and Chris are mutually out of range. • Bob is in range of Alice. • Bob is in range of Chris. • Bob can forward messages from Alice to Chris and vice versa. Guido R. Hiertz et al., Philips

  6. The problem … • Bob has to compete with two neighbors - Alice and Chris. • Alice and Chris have only one neighbor. • Thus, they’ll find the medium much more often idle as Bob. • What happens then? • Alice will flood Bob and he won‘t be able to relay Alice’s message to Chris. That, however, is not in Alice’s own interest. If she just continues to talk, Bob will have to discard messages since he hardly ever can forward them. • Alice has no control over Bob's neighborhood. • However, Alice has control over the rate of packets that she sends to him. Guido R. Hiertz et al., Philips

  7. What would you do? • Alice has a message for Chris • Alice and Chris outside of mutual range • Alice sends its message to Bob • Bob forwards the message to Chris Alice Perfection is achieved not when there is nothing left to add but when there is nothing left to take away. Perfection is achieved not when there is nothing left to add but when there is nothing left to take away. Perfection is achieved not when there is nothing left to add but when there is nothing left to take away. Perfection is achieved not when there is nothing left to add but when there is nothing left to take away. Chris Perfection is achieved not when there is nothing left to add but when there is nothing left to take away. Perfection is achieved not when there is nothing left to add but when there is nothing left to take away. Perfection is achieved not when there is nothing left to add but when there is nothing left to take away. Perfection is achieved not when there is nothing left to add but when there is nothing left to take away. Bob Guido R. Hiertz et al., Philips

  8. Why does EDCA make it worse? • Following the current rational of 802.11, Alice could just proceed to talk endlessly. Her only neighbor is Bob. • That would be really stupid of Alice if she wouldn't ever give Bob a chance to talk to Chris. • At present, however, 802.11 will behave exactly like that. There is absolutely no function in 802.11 that would tell Alice to limit herself. She'll just continue to speak and Bob would never be able to rise to speak. • In the end, what would she achieve? Nothing … Guido R. Hiertz et al., Philips

  9. The solution (1) • The best thing Alice can do is to remain silent until Bob has forwarded her message to Chris. • On Alice’s horizon, there is Bob. Alice cannot look beyond the horizon. Thus, Alice doesn't know about the situation at Bob. • It's in Alice’s own interest, however, to help Bob as best as she can to get her message forwarded. • Since we have hop-by-hop encryption, Alice cannot detect whether Bob was able to forward her message or not. • Thus, our idea is to set the local NAV for a duration twice as long (e.g.) as the duration that it took to send the message to the next hop. Guido R. Hiertz et al., Philips

  10. The solution (2) • Remain silent – That’s all Alice can do … • Reduce the medium usage! • Reduce the contention for the wireless medium! • Think “selfish”  Alice should help her next neighbor to have a better chance to access the medium and to forward the message for her. Guido R. Hiertz et al., Philips

  11. Modified EDCA • Two (2) simple rules • Following each frame transmission, a Mesh STA set its own NAV, when the frame needs/the frames need to be forwarded by the next Mesh STA • There is a next hop … So we defer and remain silent • A Mesh STA does not set its NAV, when the frame(s) sent need not be forwarded • There is no forwarding … So we do not need to defer Guido R. Hiertz et al., Philips

  12. How to determine the NAV duration? • NAV duration = duration of last transmission • Last transmission = single frame or duration of last TXOP Guido R. Hiertz et al., Philips

  13. Modified EDCA – Q&A (1) • Q: Does the scheme set the NAV at surrounding STAs? • A: No! The scheme does not set the NAV at surrounding STAs. Guido R. Hiertz et al., Philips

  14. Modified EDCA – Q&A (2) • Q: Does the scheme manipulate the medium access parameters of neighboring STAs? • A: No, the scheme does not. The scheme implements a local mechanism only. Guido R. Hiertz et al., Philips

  15. Modified EDCA – Q&A (3) • Q: Does the scheme require usage of an RTS/CTS handshake? • A: No, the scheme works with or without RTS/CTS. Guido R. Hiertz et al., Philips

  16. Modified EDCA – Q&A (4) • Q: What is the impact if a mesh STA sets its NAV after its frame transmissions? • A: The mesh STA throttles itself, thereby avoiding to congest its neighbor. Guido R. Hiertz et al., Philips

  17. Modified EDCA – Q&A (6) • Q: What’s the problem with the congestion control signaling framework? • A: With the congestion control framework, you need extra signaling. Extra frames that eat even more capacity and add to the blocking of the wireless medium.Extra frame transmissions worsen a congested situation. Guido R. Hiertz et al., Philips

  18. Modified EDCA – Q&A (7) • Q: What about guarantees? • A: If you want guarantees, use MDA. If you need to stick with EDCA, there is no guarantee possible.However, the proposed, simple modification enhances EDCA for multi-hop usage. Guido R. Hiertz et al., Philips

  19. 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

  20. 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

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

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

  23. 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

  24. 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

  25. 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

  26. 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

  27. 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

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

  29. 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

  30. 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

  31. 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

  32. 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

  33. 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