Doc.: IEEE 802.11-05/1589r0 Submission January 2005 Matthew Fischer, BroadcomSlide 1 TGn Features vs Performance Notice: This document has been prepared

January 2005

Matthew Fischer, Broadcom

Slide 1

doc.: IEEE 802.11-05/1589r0

Submission

TGn Features vs Performance

Notice: This document has been prepared to assist IEEE 802.11. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.

Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.11.

Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures <http:// ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair <[email protected]> as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at <[email protected]>.

Date: 2005-01-06

Name Company Address Phone email Matthew Fischer Broadcom 190 Mathilda Place,

Sunnyvale, CA 94086

408 543 3370 [email protected]

Authors:

January 2005


Slide 2

doc.: IEEE 802.11-05/1589r0

Submission

Abstract

Various proposed TGn features are examined for complexity and performance enhancement relative to an 802.11-2003 + TGe draft 11 implementation. A few very simple mechanisms are shown to have a dramatic and positive effect on efficiency and hence, throughput.

January 2005


Slide 3

doc.: IEEE 802.11-05/1589r0

Submission

Features Examined

• Preamble• MSDU Aggregation• HTP burst• Block-Ack NO-ACK policy• Multipoll

• Examined for:– Complexity– Throughput gain

• vs 802.11-2003 + 802.11a/g + TGe

January 2005


Slide 4

doc.: IEEE 802.11-05/1589r0

Submission

Why Bother Measuring Complexity?

• TGn solutions are REQUIRED to be backwards compatible with ALL PREVIOUS 802.11 FEATURES– The existing 802.11-2003 specification is already 716 pages long

– The existing MAC portion is 76 pages

– TGe brings 195 pages of additional edits/insertions

– TGi adds 123 pages of additional edits/insertions

– STANDARD COMPLEXITY IS ALREADY AN ISSUE

January 2005


Slide 5

doc.: IEEE 802.11-05/1589r0

Submission

The Issue of MAC Complexity

• Combined total of 35 frame type/subtypes (v2003+TGe)• Combined total of 4 MAC access control functions

(DCF/PCF/EDCA/HCCA)• New frame types and subtypes and new control functions will add

to an already complex standard• Increasing complexity adds new challenges to:

– Completion date of the standardization of TGn– Interpretability of the standard by implementers– Implementation complexity– Probability of implementation error– Potential multi-vendor interoperability problems

January 2005


Slide 6

doc.: IEEE 802.11-05/1589r0

Submission

WWISE Compared to others

• WWISE has NO new access control functions– DCF, PCF, EDCA, HCCA are re-used in their most effective manner– No additional complexity added, yet performance is at, or better than,

competing proposals– Compare to addition of IAC/RAC (Tgnsync), ACF control function

(Qcom), ECCF control function (Mitmot)• WWISE has one new frame subtype

– Compare with 7 (Tgnsync),7 (Qcom) or 4 (mitmot) new subtypes for other proposals

• WWISE MAC is described in 24 pages– Compare with 65 (Tgnsync), 47 (Qcom), 20 (Mitmot)

• WWISE MAC results– Outperform or are on par with other, more complex proposals

• WWISE proposal is simple, yet effective

January 2005


Slide 7

doc.: IEEE 802.11-05/1589r0

Submission

WWISE Simplicity

• HTP Burst– a reduction in SIFS (for TX-TX events)– elimination of a preamble preceding a PPDU– It’s just that simple!

• Block Ack NO-ACK policy– One bit – MAC skips the normal ACK for the Block Ack Request

or Block Ack Response if frame is received with this bit set– It’s so easy!

• MSDU Aggregation– Not quite as simple, but everyone agrees we need this in some

form – throughput increase is dramatic

January 2005


Slide 8

doc.: IEEE 802.11-05/1589r0

Submission

But How Effective is WWISE?

• Following slides demonstrate the effectiveness of WWISE-proposed features

January 2005


Slide 9

doc.: IEEE 802.11-05/1589r0

Submission

PREAMBLE

• WWISE -- 20 usec:– Complexity

• No more than expected for a change to MIMO system

– Throughput gain vs 802.11a/g• No loss of efficiency

– (20 usec vs 20 usec preamble)

• TGNSYNC -- 44.8 usec:– Complexity

• No more than expected for a change to MIMO system

– Throughput gain vs 802.11a/g• Efficiency LOSS vs previous standard

– (44.8 usec vs 20 usec preamble)

January 2005


Slide 10

doc.: IEEE 802.11-05/1589r0

Submission

Preamble = Fixed overhead

• The effect on efficiency of the fixed preamble overhead becomes worse as the PHY rate is increased– As PHY rate increases, the payload duration decreases

• But PHY overhead remains fixed

– Therefore, efficiency continues to degrade for the longer preamble as rates increase

– Short frames aggravate the problem• Voip – not generally “aggregatable”

• Therefore:– IT IS IMPERATIVE THAT PREAMBLE OVERHEAD BE

MINIMIZED

January 2005


Slide 11

doc.: IEEE 802.11-05/1589r0

Submission

Effect of Preamble Length (%)

% increase of tput short vs long preamble

0

5

10

15

20

25

50 100 150 200 250 300

PHY RATE

% i

ncr

ease 1000

1500

4095

8191

January 2005


Slide 12

doc.: IEEE 802.11-05/1589r0

Submission

MSDU Aggregation

• Effectively creates longer packets– Combats fixed PHY overhead cost

• Complexity– Multiple “pending queues”

• Sorting per RA

– Latency timers• Per RA, TID

– Potential disassembly and reassembly of aggregate constituents for individualized retry• (Depends on approach taken)

January 2005


Slide 13

doc.: IEEE 802.11-05/1589r0

Submission

MSDU Aggregation Performance Increase

% increase in throughput of MSDU MAC tput vs MAC Payload of 1000 bytes

0

20

40

60

80

100

120

140

160

180

1000 2000 3000 4000 5000 6000 7000 8000 9000

MAC Payload

% i

ncr

ease

in

tp

ut

vs 1

000

byt

e p

ayla

od

54

81

108

121.5

135

162

243

270

January 2005


Slide 14

doc.: IEEE 802.11-05/1589r0

Submission

MSDU Aggregation

• OVERALL – a definite POSITIVE, but…

• Note that performance enhancement plateaus as payload size increases

• Numbers presented are idealized, since the ability to aggregate depends on various factors:– Latency limits per flow

– RA of frames to be aggregated

– Size of pre-aggregated MSDUs

• Ideal aggregation results are not often achievable– Limit on max aggregation size

• Latency increases as length increases

• PER increases as length increases

– Some flows not suitable for aggregation – e.g. voice

January 2005


Slide 15

doc.: IEEE 802.11-05/1589r0

Submission

HTP Burst

• Assuming that Block Ack is already implemented (as per TGe, which is required by TGn)….– And Block Ack No-ACK policy is added

• Essentially:– a reduction in SIFS

– elimination of a preamble preceding a PPDU

• NO Restrictions:– No RA restriction (compare to aggregation)

– No RATE restriction (compare to aggregation)

January 2005


Slide 16

doc.: IEEE 802.11-05/1589r0

Submission

HTP Burst Performance Improvement

% increase HTP Burst vs Non Burst

0

20

40

60

80

100

120

50 100 150 200 250 300

PHY RATE

% M

AC

Th

rou

gh

pu

t in

crea

se

1000

1500

4095

8191

January 2005


Slide 17

doc.: IEEE 802.11-05/1589r0

Submission

Block Ack – Existing

• If one Block Ack Request (BREQ) sent for each N=FOUR MPDU sent– Then overhead of Block Ack

• = 4 control frames

– Is about the same as overhead for normal ACK• = 4 control frames

– NO EFFICIENCY GAIN• Some gain starts to appear when there are more than N=FOUR frames per

block ack

M1

ACK

M2 M3 M4

M1 breq

ACK

M2 M3 M4

back

ACK

ACK ACK ACK

NORMAL ACK POLICY

BLOCK ACK POLICY

January 2005


Slide 18

doc.: IEEE 802.11-05/1589r0

Submission

Block Ack – No ACK Policy

• If one Block Ack Request (BREQ) sent for N=FOUR MPDU sent– Overhead of Block Ack with No-ACK policy

• = 2 control frames

– See chart for efficiency increase• TPUT Block ack = Bytes/[N*(MPDU) + N*(ACK)]

• TPUT Block no-ack = Bytes/[N*(MPDU) + 2*(ACK)]– Where N = Number of MPDU per Block ACK

– Efficiency gains begin when N > 2 (vs N > 4)

M1

ACK

M2 M3 M4

M1 breqM2 M3 M4

back

ACK ACK ACK

NORMAL ACK POLICY

BLOCK ACK No-ACK POLICY

January 2005


Slide 19

doc.: IEEE 802.11-05/1589r0

Submission

Block Ack Comparison %

% Increase in Throughput Using Block Ack No ACK vs MAC Payload MPDU per BA = 8

0.00

5.00

10.00

15.00

20.00

25.00

50 150 250 350 450 550

PHY RATE

% i

ncr

eas

in M

AC

T

hro

ug

hp

ut

64

512

1000

1500

4095

8191

January 2005


Slide 20

doc.: IEEE 802.11-05/1589r0

Submission

Block Ack No-ACK Simplicity

• TGE already provides for No-ACK policy– A TGe MAC can already do this!

• Extend the concept to these two control frames– i.e. Block Ack Request, Block Ack Response

– Only two new bits, in formerly reserved field

• NO-ACK is NOT a new concept for the MAC

• Simple extension of existing idea– Yielding a GOOD return in increased performance

January 2005


Slide 21

doc.: IEEE 802.11-05/1589r0

Submission

Block Ack No-ACK Realized Increase

• Realized performance increase for Block Ack No-ACK depends on various variables:– Actual average frame size

• Smaller frames = Greater improvement

– Actual average number of frames per Block Ack• More frames per Block Ack = Greater improvement

– PHY RATE• Higher PHY RATE = Greater improvement

• Simulation scenario results prove its worth in mixed environments with mix of values for the above parameters

January 2005


Slide 22

doc.: IEEE 802.11-05/1589r0

Submission

Multipoll is unwise (and not in WWISE)

• Multipoll = Poll frame from AP

• Example:– multiple “Poll-RA” (MCAST true RA) within single MAC frame

• Compare to existing Tge HCCA Poll frame – only one Poll-RA is addressed per HC Poll frame

– multiple subsequent TXOPs• Multiple TXOPs immediately follow the multipoll frame in serial

fashion

– Similar to a DOCSIS MAP concept or Schedule frame concept• Dynamic or pseudo-static schedule

January 2005


Slide 23

doc.: IEEE 802.11-05/1589r0

Submission

Multipoll “Performance”

• What is potentially gained:• Eliminate one MAC Poll frame per additional Poll-RA• I.e. Eliminate one MAC Poll frame per TXOP, roughly• Reduction from PIFS to SIFS between TXOPs

• What is potentially lost:• Poll is dropped by any of the Poll-RA STA

– (Multipoll is MCAST – NO ACKNOWLEDGEMENT)– Requires recovery scheme

• Recovery by HC• Cancellation of subsequent polled TXOPs• Reissuance of new multipoll frame• Potential for confusion over old TXOPs vs new TXOPs

• TXOP is not completely filled by TXOP grantee => wasted bandwidth– Vs HC recovery of any unused time when single-RA polling is used– Variation in performance on next chart is due to this lost bandwidth

• Net gain?

January 2005


Slide 24

doc.: IEEE 802.11-05/1589r0

Submission

Multipoll “gains” as %

Multipoll vs Single Poll Throughput % increase

-35

-30

-25

-20

-15

-10

-5

0

5

50 150 250 350 450 550

PHY RATE

% M

AC

Th

rou

gh

pu

t in

crea

se

512

1000

1500

4095

8191

January 2005


Slide 25

doc.: IEEE 802.11-05/1589r0

Submission

Multipoll problems

• Polled STA cannot often fill up the TXOP– Most flows are of same-size packets

• Non-integer number of packets fit into TXOP

• Dead air at end of TXOP unless STA can fill it– Requires some extra, shorter frames lying around

– Most STA probably have single flow to HC/AP

– Most flows have one size frame

– Remainder time in TXOP is unusable

– Unused time is wasted

January 2005


Slide 26

doc.: IEEE 802.11-05/1589r0

Submission

Summary

• There are mechanisms that can be adopted which:– Are simple, small steps beyond the functionality which already exists in

the 802.11 standard and TGe draft– Yield an excellent increase in efficiency and performance

• TGN needs to begin with these simple, effective changes– Simplicity allows

• Faster completion of the standardization of TGn• Easier interpretability of the standard by implementors• Reduced implementation complexity• Lower probability of implementation error• Reduced potential for multi-vendor interoperability problems

• The WWISE proposal meets these requirements• 14 pages of simple MAC changes yielding excellent throughput in all scenarios

January 2005


Slide 27

doc.: IEEE 802.11-05/1589r0

Submission

BACKUP SLIDES

January 2005


Slide 28

doc.: IEEE 802.11-05/1589r0

Submission

Preambles: 2 Tx, “green time” 20 MHz

20 sec

44.8 sec

WWiSE:

TGnSync:

or

SIG-NShort

Long - N

SIG-N

Short-N

Long-N Long-N

20

8 2.4 7.2 7.2

8 48

January 2005


Slide 29

doc.: IEEE 802.11-05/1589r0

Submission

Preamble comparison

• UDP flow

• EDCA TXOP size of 10 msec

• AC3 default parameters

• No Block Ack

• No RTS/CTS

• No HTP Burst

• No MSDU Aggregation

• Note that WWISE preamble is 20 usec for 2x2, increases to 28 usec for 4x4

January 2005


Slide 30

doc.: IEEE 802.11-05/1589r0

Submission

Aggregation comparison

• UDP flow

• EDCA TXOP size of 10 msec

• AC3 default parameters

• No Block Ack

• No RTS/CTS

• No HTP Burst

• No MSDU Aggregation– Just comparing different payload sizes as roughly equivalent to

savings achieved with actual aggregation

January 2005


Slide 31

doc.: IEEE 802.11-05/1589r0

Submission

HTP Burst Comparison

• Non Burst:– TXOP limit = 10 msec

– RTS/CTS off

– Block Ack Off, Normal ACK on

• HTP Burst:– TXOP limit = 10 msec

– HTP Burst limit = 4 msec

– RTS/CTS on

– Block Ack On

– Block Ack Request every 4 MSDU

January 2005


Slide 32

doc.: IEEE 802.11-05/1589r0

Submission

Multipoll vs HCCA Poll

• TXOP = 2 msec

• Multipoll = 4 Poll-RA

• TXOP use = DATA-ACK– No RTS/CTS

– No Block Ack

January 2005


Slide 33

doc.: IEEE 802.11-05/1589r0

Submission

Block Ack - Complexity

• Can efficiency of existing block ack can be increased?– Use immediate Block Ack response

• Reduces overhead by eliminating two ACKs

• But this requires much more horsepower in MAC implementation to meet SIFS timing

• Requires costly transmitter/receiver role exchange

• Delayed block ack is much less complex choice– Allows for lighter MAC implementation

– Include Block Ack – NoAck• Does not require transmitter/receiver exchange

January 2005


Slide 34

doc.: IEEE 802.11-05/1589r0

Submission

References

Documents

Doc.: IEEE 802.11-05/1589r0 Submission January 2005 Matthew Fischer, BroadcomSlide 1 TGn Features vs Performance Notice: This document has been prepared