Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


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

1 doc.: IEEE 802.11-05/1589r0 Submission January 2005 Matthew Fischer, BroadcomSlide 1 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, 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 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.http:// ieee802.org/guides/bylaws/sb-bylaws.pdfstuart.kerry@philips.compatcom@ieee.org Date: 2005-01-06 Authors:

2 doc.: IEEE 802.11-05/1589r0 Submission January 2005 Matthew Fischer, BroadcomSlide 2 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.

3 doc.: IEEE 802.11-05/1589r0 Submission January 2005 Matthew Fischer, BroadcomSlide 3 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

4 doc.: IEEE 802.11-05/1589r0 Submission January 2005 Matthew Fischer, BroadcomSlide 4 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

5 doc.: IEEE 802.11-05/1589r0 Submission January 2005 Matthew Fischer, BroadcomSlide 5 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

6 doc.: IEEE 802.11-05/1589r0 Submission January 2005 Matthew Fischer, BroadcomSlide 6 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

7 doc.: IEEE 802.11-05/1589r0 Submission January 2005 Matthew Fischer, BroadcomSlide 7 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

8 doc.: IEEE 802.11-05/1589r0 Submission January 2005 Matthew Fischer, BroadcomSlide 8 But How Effective is WWISE? Following slides demonstrate the effectiveness of WWISE-proposed features

9 doc.: IEEE 802.11-05/1589r0 Submission January 2005 Matthew Fischer, BroadcomSlide 9 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)

10 doc.: IEEE 802.11-05/1589r0 Submission January 2005 Matthew Fischer, BroadcomSlide 10 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

11 doc.: IEEE 802.11-05/1589r0 Submission January 2005 Matthew Fischer, BroadcomSlide 11 Effect of Preamble Length (%)

12 doc.: IEEE 802.11-05/1589r0 Submission January 2005 Matthew Fischer, BroadcomSlide 12 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)

13 doc.: IEEE 802.11-05/1589r0 Submission January 2005 Matthew Fischer, BroadcomSlide 13 MSDU Aggregation Performance Increase

14 doc.: IEEE 802.11-05/1589r0 Submission January 2005 Matthew Fischer, BroadcomSlide 14 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

15 doc.: IEEE 802.11-05/1589r0 Submission January 2005 Matthew Fischer, BroadcomSlide 15 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)

16 doc.: IEEE 802.11-05/1589r0 Submission January 2005 Matthew Fischer, BroadcomSlide 16 HTP Burst Performance Improvement

17 doc.: IEEE 802.11-05/1589r0 Submission January 2005 Matthew Fischer, BroadcomSlide 17 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 M2M3 M4 M1 breq ACK M2M3M4 back ACK NORMAL ACK POLICY BLOCK ACK POLICY

18 doc.: IEEE 802.11-05/1589r0 Submission January 2005 Matthew Fischer, BroadcomSlide 18 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 M2M3 M4 M1 breq M2M3M4 back ACK NORMAL ACK POLICY BLOCK ACK No-ACK POLICY

19 doc.: IEEE 802.11-05/1589r0 Submission January 2005 Matthew Fischer, BroadcomSlide 19 Block Ack Comparison %

20 doc.: IEEE 802.11-05/1589r0 Submission January 2005 Matthew Fischer, BroadcomSlide 20 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

21 doc.: IEEE 802.11-05/1589r0 Submission January 2005 Matthew Fischer, BroadcomSlide 21 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

22 doc.: IEEE 802.11-05/1589r0 Submission January 2005 Matthew Fischer, BroadcomSlide 22 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

23 doc.: IEEE 802.11-05/1589r0 Submission January 2005 Matthew Fischer, BroadcomSlide 23 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?

24 doc.: IEEE 802.11-05/1589r0 Submission January 2005 Matthew Fischer, BroadcomSlide 24 Multipoll “gains” as %

25 doc.: IEEE 802.11-05/1589r0 Submission January 2005 Matthew Fischer, BroadcomSlide 25 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

26 doc.: IEEE 802.11-05/1589r0 Submission January 2005 Matthew Fischer, BroadcomSlide 26 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

27 doc.: IEEE 802.11-05/1589r0 Submission January 2005 Matthew Fischer, BroadcomSlide 27 BACKUP SLIDES

28 doc.: IEEE 802.11-05/1589r0 Submission January 2005 Matthew Fischer, BroadcomSlide 28 Preambles: 2 Tx, “green time” 20 MHz 20  sec 44.8  sec WWiSE: TGnSync: or SIG-NShortLong - N SIG-NShort-NLong-N 208 2.4 7.2 848

29 doc.: IEEE 802.11-05/1589r0 Submission January 2005 Matthew Fischer, BroadcomSlide 29 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

30 doc.: IEEE 802.11-05/1589r0 Submission January 2005 Matthew Fischer, BroadcomSlide 30 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

31 doc.: IEEE 802.11-05/1589r0 Submission January 2005 Matthew Fischer, BroadcomSlide 31 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

32 doc.: IEEE 802.11-05/1589r0 Submission January 2005 Matthew Fischer, BroadcomSlide 32 Multipoll vs HCCA Poll TXOP = 2 msec Multipoll = 4 Poll-RA TXOP use = DATA-ACK –No RTS/CTS –No Block Ack

33 doc.: IEEE 802.11-05/1589r0 Submission January 2005 Matthew Fischer, BroadcomSlide 33 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

34 doc.: IEEE 802.11-05/1589r0 Submission January 2005 Matthew Fischer, BroadcomSlide 34 References


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

Similar presentations


Ads by Google