1. doc.: IEEE 802.11-08/1357r0 Submission November 2008 Guido R. Hiertz et al., PhilipsSlide 1 Simple improvement for EDCA usage in 802.11s Date: 2008-11-11 Authors:

2. doc.: IEEE 802.11-08/1357r0 Submission November 2008 Guido R. Hiertz et al., PhilipsSlide 2 Abstract We present a simple modification to EDCA that inherently avoids congesting the wireless medium (WM).

3. doc.: IEEE 802.11-08/1357r0 Submission November 2008 Guido R. Hiertz et al., PhilipsSlide 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 –1 st listen 2 nd 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

4. doc.: IEEE 802.11-08/1357r0 Submission 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 November 2008 Guido R. Hiertz et al., PhilipsSlide 4

5. doc.: IEEE 802.11-08/1357r0 Submission 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 November 2008 Guido R. Hiertz et al., PhilipsSlide 5

6. doc.: IEEE 802.11-08/1357r0 Submission 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: Poisson process November 2008 Guido R. Hiertz et al., PhilipsSlide 6

7. doc.: IEEE 802.11-08/1357r0 Submission Modified EDCA (example) Performs modified EDCA –Set NAV after each transmission –NAV duration according to 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 November 2008 Guido R. Hiertz et al., PhilipsSlide 7

8. doc.: IEEE 802.11-08/1357r0 Submission Simulation results Realistic channel model –Incorporates interference –SINR based frame error probability –Open source: http://www.openwns.orghttp://www.openwns.org November 2008 Guido R. Hiertz et al., PhilipsSlide 8

9. doc.: IEEE 802.11-08/1357r0 Submission November 2008 Guido R. Hiertz et al., PhilipsSlide 9 Throughput (one route) Modified EDCA inherently avoids congestion Plain EDCA achieves lower maximum throughput

10. doc.: IEEE 802.11-08/1357r0 Submission 1 st hop frame transmission rate (Mesh STA 1  Mesh STA 2) 1 st hop reveals the problem –Edge nodes have fewer neighbors –Edge nodes have higher transmission probabilities 1 st hop does not limit its transmissions Modified EDCA limits the frame transmission rate November 2008 Guido R. Hiertz et al., PhilipsSlide 10

11. doc.: IEEE 802.11-08/1357r0 Submission 2 nd hop frame transmission rate (Mesh STA 2  Mesh STA 3) With EDCA, 2 nd hop cannot carry the offered traffic & suffers from the selfish behavior on the 1 st hop With modified EDCA, 2 nd hop saturates at a traffic level that can be carried November 2008 Guido R. Hiertz et al., PhilipsSlide 11

12. doc.: IEEE 802.11-08/1357r0 Submission 3 rd hop frame transmission rate (Mesh STA 3  Mesh STA 4) EDCA severely limits the last hop Modified EDCA experience much better performanc e due to the inherent rate control November 2008 Guido R. Hiertz et al., PhilipsSlide 12

13. doc.: IEEE 802.11-08/1357r0 Submission 2 nd hop frame loss rate (Mesh STA 2  Mesh STA 3) At 2Mb/s offered traffic, the 2 nd hop successfully transmits ~12 frames per second –Additionally, the 2 nd loses ~4 frames per second Modified EDCA avoids frame losses –Traffic does not saturate November 2008 Guido R. Hiertz et al., PhilipsSlide 13

14. doc.: IEEE 802.11-08/1357r0 Submission Lost frames = Harmful to everyone … Lost frames on 2 nd 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)*2 2 -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)*2 3 -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 November 2008 Guido R. Hiertz et al., PhilipsSlide 14

15. doc.: IEEE 802.11-08/1357r0 Submission Thank you for your attention November 2008 Guido R. Hiertz et al., PhilipsSlide 15

16. doc.: IEEE 802.11-08/1357r0 Submission 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. […] November 2008 Guido R. Hiertz et al., PhilipsSlide 16

17. doc.: IEEE 802.11-08/1357r0 Submission 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. November 2008 Guido R. Hiertz et al., PhilipsSlide 17

18. doc.: IEEE 802.11-08/1357r0 Submission References (3) 802.11-2007, Annex D dot11RTSThreshold OBJECT-TYPE SYNTAX INTEGER (0..3000) MAX-ACCESS read-write STATUS current DESCRIPTION "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 } November 2008 Guido R. Hiertz et al., PhilipsSlide 18

19. doc.: IEEE 802.11-08/1357r0 Submission References (4) 802.11-2007, Annex D dot11LongRetryLimit OBJECT-TYPE SYNTAX INTEGER (1..255) MAX-ACCESS read-write STATUS current DESCRIPTION "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 } November 2008 Guido R. Hiertz et al., PhilipsSlide 19

20. doc.: IEEE 802.11-08/1357r0 Submission 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.ppthttps://mentor.ieee.org/802.11/file/07/11-07- 2534-00-000s-a-simple-scalable-traffic-engineering- solution-for-802-11s.ppt November 2008 Guido R. Hiertz et al., PhilipsSlide 20