May 2002

Terry Cole, AMD

Slide 1

doc.: IEEE 802.11-02/301R0

Submission

A More Efficient Protection Mechanism

Terry ColeAMD Fellow

terry.cole@amd.com

+1 512 602 2454

May 2002

Terry Cole, AMD

Slide 2

doc.: IEEE 802.11-02/301R0

Submission

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

May 2002

Terry Cole, AMD

Slide 3

doc.: IEEE 802.11-02/301R0

Submission

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

May 2002

Terry Cole, AMD

Slide 4

doc.: IEEE 802.11-02/301R0

Submission

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)

May 2002

Terry Cole, AMD

Slide 5

doc.: IEEE 802.11-02/301R0

Submission

Base Case Results (802.11g D2.0)Transition from .11b only network to .11g only network

0

2

4

6

8

10

12

14

16

183

B F

low

En

viro

nm

en

t

2B

-1G

Flo

wE

nvi

ron

me

nt

1B

-2G

Flo

wE

nvi

ron

me

nt

3G

Flo

wE

nvi

ron

me

nt

with

rts

/cts

3G

Flo

wE

nvi

ron

me

nt

Th

rou

gh

pu

t (M

bp

s)

Flow 1

Flow2

Flow3

Total

May 2002

Terry Cole, AMD

Slide 6

doc.: IEEE 802.11-02/301R0

Submission

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.

May 2002

Terry Cole, AMD

Slide 7

doc.: IEEE 802.11-02/301R0

Submission

ERP-CP ResultsThroughput Share For 1B-2G Flow Network

0

2

4

6

8

10

12

14

16

Base 0 CCP(15) 0.5 CCP(31) 0.4 CCP(63) 0.6

Th

rou

gh

pu

t (M

bp

s)

B

G

Overall

KEY: CCP(a) b a = common contentio period aCWmin (slot times), b = ERP-CP duty cycle (ratio)

May 2002

Terry Cole, AMD

Slide 8

doc.: IEEE 802.11-02/301R0

Submission

ERP-CP ResultsThroughput Share for 2B-1G Flow Network

0

2

4

6

8

10

12

14

Base 0 CCP(15) 0.5 CCP(31) 0.4 CCP(63) 0.5

Th

rou

gh

pu

t (M

bp

s)

B

G

Overall

KEY: CCP(a) b a = common contentio period aCWmin (slot times), b = ERP-CP duty cycle (ratio)

May 2002

Terry Cole, AMD

Slide 9

doc.: IEEE 802.11-02/301R0

Submission

ERP-CP ResultsThroughput Share For 1B-1G Flow Network

0

2

4

6

8

10

12

14

Base 0 CCP(15) 0.5 CCP(31) 0.3 CCP(63) 0.5

Th

rou

gh

pu

t (M

bp

s)

B

G

Overall

KEY: CCP(a) b a = common contentio period aCWmin (slot times), b = ERP-CP duty cycle (ratio)

May 2002

Terry Cole, AMD

Slide 10

doc.: IEEE 802.11-02/301R0

Submission

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

May 2002

Terry Cole, AMD

Slide 11

doc.: IEEE 802.11-02/301R0

Submission

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.

May 2002

Terry Cole, AMD

Slide 12

doc.: IEEE 802.11-02/301R0

Submission

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

May 2002

Terry Cole, AMD

Slide 13

doc.: IEEE 802.11-02/301R0

Submission

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

May 2002

Terry Cole, AMD

Slide 14

doc.: IEEE 802.11-02/301R0

Submission

Multi-Pump RTS/CTS Results1B-2G Flow Environment

1.6152 1.728

5.94

4.5655.9

4.54

13.4552

10.833

0

2

4

6

8

10

12

14

16

Double Pump Base

Th

rou

gh

pu

t (M

bp

s)

B

G

G

Total

May 2002

Terry Cole, AMD

Slide 15

doc.: IEEE 802.11-02/301R0

Submission

Multi-Pump RTS/CTS Results

2B-1G Flow Environment

2.3544 1.942.5056

1.93

5.70726.17

10.567210.04

0

2

4

6

8

10

12

Double Pump Base

Th

rou

gh

pu

t (M

bp

s)

B

B

G

Total

May 2002

Terry Cole, AMD

Slide 16

doc.: IEEE 802.11-02/301R0

Submission

Multi-Pump RTS/CTS Results

1B-1G Flow Environment

3.2112 2.9

8.3544

6.5

11.5656

9.4

0

2

4

6

8

10

12

14

Double Pump Base

Th

rou

gh

pu

t (M

bp

s)

B

G

Total

May 2002

Terry Cole, AMD

Slide 17

doc.: IEEE 802.11-02/301R0

Submission

Multi-Pump RTS/CTS Results

3G Flow Environment

5.014.2

5.163.99

4.764

14.93

12.19

0

2

4

6

8

10

12

14

16

Double Pump Base

Th

rou

gh

pu

t (M

bp

s)

G

G

G

Total

May 2002

Terry Cole, AMD

Slide 18

doc.: IEEE 802.11-02/301R0

Submission

Multi-Pump RTS/CTS Results

3G Flow environment with 2 G flows using Double Pump and 1 G flow using Single Pump

5.134.24.5 3.994.3 4

13.93

12.19

0

2

4

6

8

10

12

14

16

Double Pump Base

Th

rou

gh

pu

t (M

bp

s)

G(SP)

G(DP)

G(DP)

Total

May 2002

Terry Cole, AMD

Slide 19

doc.: IEEE 802.11-02/301R0

Submission

Multi-Pump RTS/CTS Results

1B-2G Flow environment with 1G flow using Double Pump and 1G flow using Single Pump

1.63 1.728

5.754.5655 4.54

12.38

10.833

0

2

4

6

8

10

12

14

Double Pump Base

Th

rou

gh

pu

t (M

bp

s)

B

G (SP)

G (DP)

Total

May 2002

Terry Cole, AMD

Slide 20

doc.: IEEE 802.11-02/301R0

Submission

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.

May 2002

Terry Cole, AMD

Slide 21

doc.: IEEE 802.11-02/301R0

Submission

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.

May 2002

Terry Cole, AMD

Slide 22

doc.: IEEE 802.11-02/301R0

Submission

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.

May 2002

Terry Cole, AMD

Slide 23

doc.: IEEE 802.11-02/301R0

Submission

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

May 2002

Terry Cole, AMD

Slide 24

doc.: IEEE 802.11-02/301R0

Submission

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

May 2002

Terry Cole, AMD

Slide 25

doc.: IEEE 802.11-02/301R0

Submission

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