1. doc.: IEEE 802.11-02/301R0 Submission May 2002 Terry Cole, AMDSlide 1 A More Efficient Protection Mechanism Terry Cole AMD Fellow terry.cole@amd.com +1 512 602 2454

2. doc.: IEEE 802.11-02/301R0 Submission May 2002 Terry Cole, AMDSlide 2 Introduction Slides to assist the committee to consider available alternatives, if any, for improving the RTS/CTS protection mechanism We have numerous comments on the protection mechanism: –Indicating that RTS/CTS is insufficiently efficient and requesting improvement –Proposing a OFDM only contention period –Suggesting the RTS/CTS does not function for fragments and requesting clarification

3. doc.: IEEE 802.11-02/301R0 Submission May 2002 Terry Cole, AMDSlide 3 Methodology Use ns2 to explore and quantify the options –Validated a mixed b/g model by recreating the results presented in 02/065 8021.11g MAC Analysis Modeled the situation of 02/181r1 –Modeled certain possible improvements Modeled a proposal based on multiple OFDM frames protected by a single RTS/CTS

4. doc.: IEEE 802.11-02/301R0 Submission May 2002 Terry Cole, AMDSlide 4 Base Simulation Multiple flows modeled for the following cases representative of a variety of mixed networks: –3b, 2b+1g, 1b+1g, 1b+2g, 3g with RTS/CTS, 3g no protection Modeled 802.11g according to the draft 2.0 spec –OFDM-24 (24Mbps) –short preamble and CCK-11 (11Mbps) –aCWmin = 15 slot times –Infinite flows (network overload at each source)

5. doc.: IEEE 802.11-02/301R0 Submission May 2002 Terry Cole, AMDSlide 5 Base Case Results (802.11g D2.0)

6. doc.: IEEE 802.11-02/301R0 Submission May 2002 Terry Cole, AMDSlide 6 ERP Contention Period (ERP-CP) Simulation Assumptions –CCK-11 beacon an OFDM-24 CF-End at regular intervals of 50ms –AP has a locally generated control variable to set the duty cycle (ERP-CP time as set by the CF parameters / total time). We set this to 30-60% to get results shown. –Same topologies and infinite flows as base case –aCwmin was varied during common contention period (for reasons that will be seen in results) –aCWmin= 15 slots during ERP-CP.

7. doc.: IEEE 802.11-02/301R0 Submission May 2002 Terry Cole, AMDSlide 7 ERP-CP Results KEY: CCP(a) b a = common contentio period aCWmin (slot times), b = ERP-CP duty cycle (ratio)

8. doc.: IEEE 802.11-02/301R0 Submission May 2002 Terry Cole, AMDSlide 8 ERP-CP Results KEY: CCP(a) b a = common contentio period aCWmin (slot times), b = ERP-CP duty cycle (ratio)

9. doc.: IEEE 802.11-02/301R0 Submission May 2002 Terry Cole, AMDSlide 9 ERP-CP Results KEY: CCP(a) b a = common contentio period aCWmin (slot times), b = ERP-CP duty cycle (ratio)

10. doc.: IEEE 802.11-02/301R0 Submission May 2002 Terry Cole, AMDSlide 10 Observations 802.11g nodes get more throughput as predicted! 802.11b nodes get significantly less throughput! –The common contention period is the only time a CCK node can transmit, and the common period is reducing –With aCWmin=15 slots times, a 802.11g node is twice as likely to win contention during the common contention period as compared to a 802.11b node Using common contention aCWmin=31 or 63, we can make the 802.11b nodes perform as in the base case –compensating the CCK nodes during the common contention period since they dont get to participate in the ERP-CP

11. doc.: IEEE 802.11-02/301R0 Submission May 2002 Terry Cole, AMDSlide 11 Changes Needed for ERP-CP Allow CF-End to be broadcast using OFDM Define ERP contention period (ERP-CP): –ERP-CP starts with any CCK beacon with non-zero CF parameter time elements followed by OFDM modulated CF-END before the expiration of the CF time elements. –ERP-CP ends with expiration of the original non-zero CFP time elements or by a HR modulated CF-END Change the behavior of ERP nodes: –A ERP device shall ignore nonERP bits (i.e. nonERP = 00) during the ERP-CP and shall use aCWmin = 15 slot times –802.11g node that has observed any ERP-CP within the last 30 seconds shall use aCWmin = 63 slot times except during an ERP-CP; it shall use aCWmin = 15 slot times otherwise.

12. doc.: IEEE 802.11-02/301R0 Submission May 2002 Terry Cole, AMDSlide 12 Exploring another Method RTS/CTS sets the NAV of all CCK nodes Why not allow optional transmission of more than one OFDM frame during this NAV protected time? –From same sender –To same recipient –Time not to exceed maximum packet length transmitted at 11Mbps (to avoid messing up future QoS) –Can be used for fragments or simple frames –When using optional multi-pump RTS/CTS, must contend equally with CCK nodes, i.e. aCWmin = 31 slot times –May be mixed with mandatory mode simple RTS/CTS using aCWmin=15 slot times

13. doc.: IEEE 802.11-02/301R0 Submission May 2002 Terry Cole, AMDSlide 13 Multi-pump RTS/CTS Simulation Assumptions –CCK-11 RTS/CTS –Short preamble CCK –OFDM-24 data frames therefore only double pumping allowed –Same topologies and flows as base case –aCWmin= 15 slot times for single RTS/CTS –aCWmin= 31 slot times for multi-pumped RTS/CTS

14. doc.: IEEE 802.11-02/301R0 Submission May 2002 Terry Cole, AMDSlide 14 Multi-Pump RTS/CTS Results

15. doc.: IEEE 802.11-02/301R0 Submission May 2002 Terry Cole, AMDSlide 15 Multi-Pump RTS/CTS Results

16. doc.: IEEE 802.11-02/301R0 Submission May 2002 Terry Cole, AMDSlide 16 Multi-Pump RTS/CTS Results

17. doc.: IEEE 802.11-02/301R0 Submission May 2002 Terry Cole, AMDSlide 17 Multi-Pump RTS/CTS Results

18. doc.: IEEE 802.11-02/301R0 Submission May 2002 Terry Cole, AMDSlide 18 Multi-Pump RTS/CTS Results

19. doc.: IEEE 802.11-02/301R0 Submission May 2002 Terry Cole, AMDSlide 19 Multi-Pump RTS/CTS Results

20. doc.: IEEE 802.11-02/301R0 Submission May 2002 Terry Cole, AMDSlide 20 Changes Needed for Multi-Pump 7.2.1.1 RTS. –In the case of the ERP, the duration value (of the RTS) may alternately be the time, in microseconds, required to transmit several pending data or management frames, plus one CTS frame and SIFS, plus one ACK frame per data or management frame, and 2 SIFS per data or management frame. The RTS and all data or management frames shall be addressed from the same sender and to a single recipient address. The calculated duration field for the ERP RTS shall not exceed the time required to transmit a single 2254 octet data frame plus a RTS, CTS, and ACK frames using the HR 11Mbps PHY.

21. doc.: IEEE 802.11-02/301R0 Submission May 2002 Terry Cole, AMDSlide 21 Changes Needed for Multi-Pump CTS – no modification is required Add to Table 21 (allowed sequences): –erpRTS – CTS – [ Last – Ack]+ –erpRTS – CTS [Frag – Ack]+ Last – Ack –Note 24: Items enclosed in brackets with a + […]+ may occur one or more times in the sequence –Note 25: erpRTS is a control frame of subtype RTS that contains a duration value as described in 7.2.2.1 covering time required to transmit multiple data or management frames from a single requester to a single recipient address.

22. doc.: IEEE 802.11-02/301R0 Submission May 2002 Terry Cole, AMDSlide 22 Changes Needed for Multi-Pump 19.4.3.8.5 –Change the aCWmin to 15 slot times except if using the frame sequences defined in Table 21 starting with erpRTS. For frame sequences defined in Table 21 starting with erpRTS, aCWmin shall be 31 slot times.

23. doc.: IEEE 802.11-02/301R0 Submission May 2002 Terry Cole, AMDSlide 23 Changes Needed for Multi-Pump 9.2.5.5 Control of the channel –Add to the 6 th paragraph –In the case of an ERP using a sequence defined in Table 21 beginning with erpRTS, the source STA shall attempt to retransmit the failed MPDU without contending for the channel again, if the transmitted frame and the ACK can be completed prior to the expiration of the NAV period described by the erpRTS frame. Otherwise, the source STA may transmit the failed MPDU without contending using a sequence in Table 21 starting with RTS (and not with erpRTS).

24. doc.: IEEE 802.11-02/301R0 Submission May 2002 Terry Cole, AMDSlide 24 Which Method is Best? Simple RTS/CTS described in the current draft may be sufficient ERP contention period (ERP-CP) with aCWmin=15 seems to negatively impact CCK nodes ERP-CP aCWmin=31 or 63 slot times gives significant benefits Multi-pump RTS/CTS option seems viable

25. doc.: IEEE 802.11-02/301R0 Submission May 2002 Terry Cole, AMDSlide 25 Straw Poll Binary yes/no – Should we improve the efficiency of the current RTS/CTS method in 802.11g D2.0? Binary yes/no –Should we add one of the ERP contention period methods Exclusive (choose 1) Should we add an ERP-CP option with common contention aCWmin = –15 ? or 31? or 63? Binary (yes/no) –Should we add the optional multi-pump RTS/CTS method