1 / 25

A More Efficient Protection Mechanism

A More Efficient Protection Mechanism. Terry Cole AMD Fellow terry.cole@amd.com +1 512 602 2454. 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:

brandonjohnson
Télécharger la présentation

A More Efficient Protection Mechanism

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. A More Efficient Protection Mechanism Terry Cole AMD Fellow terry.cole@amd.com +1 512 602 2454 Terry Cole, AMD

  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 Terry Cole, AMD

  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 Terry Cole, AMD

  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) Terry Cole, AMD

  5. Base Case Results (802.11g D2.0) Terry Cole, AMD

  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. Terry Cole, AMD

  7. ERP-CP Results KEY: CCP(a) b  a = common contentio period aCWmin (slot times), b = ERP-CP duty cycle (ratio) Terry Cole, AMD

  8. ERP-CP Results KEY: CCP(a) b  a = common contentio period aCWmin (slot times), b = ERP-CP duty cycle (ratio) Terry Cole, AMD

  9. ERP-CP Results KEY: CCP(a) b  a = common contentio period aCWmin (slot times), b = ERP-CP duty cycle (ratio) Terry Cole, AMD

  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 don’t get to participate in the ERP-CP Terry Cole, AMD

  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. Terry Cole, AMD

  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 Terry Cole, AMD

  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 Terry Cole, AMD

  14. Multi-Pump RTS/CTS Results Terry Cole, AMD

  15. Multi-Pump RTS/CTS Results Terry Cole, AMD

  16. Multi-Pump RTS/CTS Results Terry Cole, AMD

  17. Multi-Pump RTS/CTS Results Terry Cole, AMD

  18. Multi-Pump RTS/CTS Results Terry Cole, AMD

  19. Multi-Pump RTS/CTS Results Terry Cole, AMD

  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. Terry Cole, AMD

  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. Terry Cole, AMD

  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. Terry Cole, AMD

  23. Changes Needed for Multi-Pump • 9.2.5.5 Control of the channel • Add to the 6th 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). Terry Cole, AMD

  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 Terry Cole, AMD

  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 Terry Cole, AMD

More Related