January 2005 doc IEEE 802 11 050016 r

  • Slides: 56
Download presentation
January 2005 doc. : IEEE 802. 11 -05/0016 r 2 WWISE MAC Proposal for

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 WWISE MAC Proposal for TGn Date: 2005 -01 -17 Authors: 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: // ieee 802. 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 <stuart. kerry@philips. com> 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 <patcom@ieee. org>. Submission 1 Matthew Fischer, Broadcom

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 Abstract Exposition of the

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 Abstract Exposition of the features of the MAC portion of the WWISE proposal for initial TGn draft. In addition, 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. Submission 2 Matthew Fischer, Broadcom

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 MAC features • The

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 MAC features • The WWi. SE proposal builds on 802. 11 e functionality as much as possible, in particular EDCA, HCCA, and Block Ack – Block Ack mandatory • WWi. SE proposal ensures backwards compatibility • Targeted effectiveness - ROI – Eliminate the big bottlenecks – Avoid schemes which yield relatively small improvement in performance in return for large complexity changes • Benefits of simplicity – Shorter time to standardization – Shorter time to productization – Shorter time to interoperability Submission 3 Matthew Fischer, Broadcom

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 WWi. SE TGn MAC

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 WWi. SE TGn MAC features • WWi. SE proposal introduces: – Only ONE new frame subtype • not actually a new subtype – uses QOS field reserved bit – No new MAC access control functions • • Re-uses existing DCF/EDCA/HCCA TGE => QOS + Efficiency enhancements EDCA: reduce DCF overhead with continuation TXOP HCCA: reduce EDCA overhead with controlled access – WWi. SE brings forth three simple efficiency enhancements • These achieve high performance, even compared to other proposed enhancements Submission 4 Matthew Fischer, Broadcom

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 The three WWi. SE

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 The three WWi. SE MAC enhancements • MSDU (MAC Layer) Aggregation – Removes significant MAC overhead • HTP Burst – Eliminates major remaining components of MAC / PHY overhead • Enhanced Block Ack – Allow No-ACK policy – Removes significant ACK overhead – Block Ack eliminates MAC transmitter turnaround overhead Submission 5 Matthew Fischer, Broadcom

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 The Ideal Protocol No

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 The Ideal Protocol No IFS MSDU = PSDU No MAC Header t 0 = - ∞ t 1 = + ∞ • All MSDU data bits, all the time • 100% MAC Efficiency Submission 6 Matthew Fischer, Broadcom

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 MSDU aggregation @ Ideal

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 MSDU aggregation @ Ideal No IFS Np Ns MH n. MSDU x. IFS MAC Header t 0 ≠ - ∞ t 1 ≠ + ∞ • Requires minor change to MAC protocol – Need new aggregation subtype • Efficiency increases as n increases – Efficiency approaches 100% for very large n – Flexibility in choice of n allows for per-installation tradeoff of latency vs throughput vs fairness Submission 7 Matthew Fischer, Broadcom

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 WWi. SE MSDU aggregation

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 WWi. SE MSDU aggregation • “New frame subtype” – Uses reserved bit of QOS subfield • Increased maximum PSDU length, to 8191 octets • Impressive improvements in MAC throughput – WWi. SE simulations use n=8 (with overriding max MPDU size limitation of 8191 Bytes) Submission 8 Matthew Fischer, Broadcom

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 MSDU aggregation shortcomings •

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 MSDU aggregation shortcomings • Upper limit on n (number of MSDU per aggregate) – PHY limitations – QOS latency limitations affect aggregate assembly process • • • IFS between aggregates PHY overhead between aggregates Single RA per aggregate Single Rate per aggregate Single TX power value per aggregate Good stuff, but not so ideal due to practical constraints Submission 9 Matthew Fischer, Broadcom

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 HTP Burst more ideal

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 HTP Burst more ideal No idle gap Np Ns PSDU Optional normal ACK policy Ns PSDU can be an aggregate MSDU! Non-normal ACK Np Ns x. IFS = N-Preamble Last PSDU bit set = N-Signal field @ robust encoding rate • Multiple RA allowed within the burst • Block Ack Request and Block Ack frames allowed within burst • More IFS eliminated • RIFS and ZIFS allowed within burst • PHY overhead reduced • “Last PSDU” bit indicates receiver should revert to preamble search Submission 10 Matthew Fischer, Broadcom

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 HTP Burst • HTP

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 HTP Burst • HTP Burst – Sequence of MPDUs from same transmitter • IFS between MPDUs not necessary, since same transmitter is used for all MPDUs in the HTP Burst – 0 usec IFS if at same Tx power level and PHY configuration – 2 usec IFS otherwise (with preamble) – IFS value not dependent on RA • Preamble also not necessary – Optional with ZIFS, required with RIFS – PPDUs may be “aggregated” • i. e. ZIFS with no preamble between PPDU – MPDUs may be of the aggregated-MSDU type – MPDUs may have different RAs and Rates Submission 11 Matthew Fischer, Broadcom

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 Block Ack - Ack

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 Block Ack - Ack policy • With “normal” block ack – HTP bursts are interrupted by Block Ack Request/response interaction • BA/BR exchange includes a change of transmitter => 2*(SIFS + preamble) • Efficiency gain of HTP burst is potentially lost • WWISE Block Ack REQ/ACK frames have ACK policy bits – Allows: • Normal ACK behavior per 802. 11 e draft • No-ACK behavior • other settings reserved – Reduces Block Ack overhead • by eliminating explicit ACKs to Block. Ack. Request and Block. Ack • by eliminating transmitter changes Submission 12 Matthew Fischer, Broadcom

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 Block Ack - Ack

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 Block Ack - Ack policy, contd. – No-ACK policy allows multiple RA + Block Ack Frames within a single HTP burst • if immediate ACK required: – HTP burst broken to allow SIFS + ACK – HTP burst single RA, ending with Block Ack Request + Block Ack + ACK • without immediate ACK requirement (i. e. using NO-ACK) – HTP burst is allowed to continue – HTP burst may contain multiple Block Ack Request to multiple RA – HTP burst may also contain Block Ack response frames – Effectively allows additional, more efficient modes of use for Block Ack mechanism Submission 13 Matthew Fischer, Broadcom

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 WWi. SE efficiency 802.

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 WWi. SE efficiency 802. 11 e TXOP Access delay M 1 M 2 M 3 M 4 breq ACK With Aggregation With HTP Burst & No-ACK Block Access delay M 1 M 2 M 3 M 4 back ACK M 1 M 2 M 3 M 4 back M 1 M 2 M 3 M 4 breq ACK Access delay M 2 breq ACK Access delay M 1 M 2 M 3 M 4 back M 1 M 2 M 3 M 4 breq M 1 M 2 M 3 M 4 back • WWi. SE approaches Ideal Protocol by minimizing overheads of MAC and PHY Submission 14 Matthew Fischer, Broadcom

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 WWi. SE efficiency M

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 WWi. SE efficiency M 1 M 2 M 3 M 4 M 1 M 2 M 3 breq back ACK breq ACK M 1 M 2 M 3 M 4 M 1 M 2 M 3 breq back breq M 1 M 2 M 1 breq back • 802. 11 E compared to WWi. SE – Per-MSDU overhead reduced -> IFS, Pream, Sig, MAChdr – ACK overhead reduced using No-ACK Block Ack – Transmitter transition overhead reduced using HCCA Submission 15 Matthew Fischer, Broadcom

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 Legacy interaction • Legacy

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 Legacy interaction • Legacy remediation – N-STA detection/advertisement • Uses proven 802. 11 g signaling and rules • Extends ERP information element • Identification of TGn and non-TGn devices and BSSs – Legacy Protection mechanisms • Existing protection mechanisms (extended to N/G case) – • Submission Set NAV to protect new modulation types • E. g. RTS/CTS, CTS 2 SELF, etc. WWi. SE adds PLCP length spoofing as additional tool 16 Matthew Fischer, Broadcom

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 40/20 MHz interaction •

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 40/20 MHz interaction • Pure 802. 11 n network – Interaction identical to existing, proven 802. 11 g mechanism for sharing with legacy devices • When 20 -MHz-only 802. 11 n devices associate, AP instructs that all BSS members shall use “ 20 MHz” protection • Protective frames are those that the 20 -MHz-only STA can understand • Protective frames set NAV to cover 20 -MHz transmissions • Protection may additionally be enabled at AP and STA discretion – (same as rules for 802. 11 g protection mechanism) • 802. 11 n mixed with 20 MHz 802. 11 a – Method identical to proven 802. 11 g concept • Mixing of 802. 11 n-40, 802. 11 n-20, 802. 11 a-20 also works • Only occurs in the 5 GHz bands Submission 17 Matthew Fischer, Broadcom

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 Simulations • PHY model

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 Simulations • PHY model in MAC simulations – – – Detailed description in IEEE 802. 11 -04/877 r 9 TGn MIMO Channel Models Impairments as specified by FRCC Union bound technique to estimate PHY layer frame errors Performance closely matches full simulations for mandatory phy configurations • Binary convolutional coding – Executes as MATLAB routine called by MAC simulator in NS Submission 18 Matthew Fischer, Broadcom

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 EDCA simulation parameters e.

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 EDCA simulation parameters e. g. , scenario 4 CWMIN (AP/STA) CWMAX (AP/STA) AIFSN (AP/STA) TXOP LIMIT msec (AP/STA) AC_BK 31/63 511/511 4/4 2. 0/1. 0 AC_BE 63/63 127/255 4/4 3. 5/3. 5 AC_VI 15/15 63/63 3/3 2. 5/1. 1 AC_VO 7/7 31/31 2/2 1. 2/1. 0 • HTP burst and MSDU aggregation employed Submission 19 Matthew Fischer, Broadcom

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 HCCA simulation parameters •

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 HCCA simulation parameters • HTP burst and MSDU aggregation used • Very simple scheduler employed – Round robin • TXOP value granted to each STA as a function of the negotiated flow • Each STA polled n times per round as a simple function of the negotiated flow • Not a very intelligent scheduler • Great results – Great ROI! Submission 20 Matthew Fischer, Broadcom

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 MAC simulation results EDCA

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 MAC simulation results EDCA HCCA CC# Name Scenario 2 x 2 x 20 2 x 2 x 40 CC 3 Goodput 1 56 74 82 82 1+ 61 93 96 167 4 77 143 103 206 4+ 79 145 109 221 6 56 62 61 62 6+ 61 105 99 181 “+” scenarios have all BE traffic offered load increased to 100 mbps (s-1) or 30 mbps (s-4, 6) Submission 21 Matthew Fischer, Broadcom

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 Complexity vs Performance •

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 Complexity vs Performance • EDCA – A simpler approach – Not as efficient, but good throughput – Cannot be expected to guarantee QOS in many situations • Adequate for some situations • HCCA – – Submission When greater efficiency is desired When QOS guarantees are desired Higher throughput More complex, but already defined 22 Matthew Fischer, Broadcom

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 Power save • Re-use

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 Power save • Re-use TGe mechanisms – PHY-independent – Legacy PS • TIM bit in beacons + PS-Poll exchange – U-APSD • Trigger frames eliciting multiple downlink frames • Increased efficiency over legacy PS ping-pong exchange • Lets STA decide when wake periods occur – S-APSD • STA and AP agree on periodic, scheduled wake times • Increased efficiency over legacy PS ping-pong exchange Submission 23 Matthew Fischer, Broadcom

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 Backward compatibility • Fully

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 Backward compatibility • Fully backward compatible with 11 b – In a mixed b/g network, the OFDM transmissions are already protected – There is no extra effect on 11 b devices, as they are unable to distinguish between 11 g and 11 n, and no further mechanisms to provide – At 2. 4 GHz, the WWi. SE proposal does not provide 40 MHz channels • Compatible with 11 j, 11 h Submission 24 Matthew Fischer, Broadcom

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 Features Examined • •

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 Features Examined • • • Preamble MSDU Aggregation HTP burst Block-Ack NO-ACK policy Multipoll • Examined for: – Complexity – Throughput gain • vs 802. 11 -2003 + 802. 11 a/g + TGe Submission 25 Matthew Fischer, Broadcom

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 Why Bother Measuring Complexity?

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 Why Bother Measuring Complexity? • TGn solutions are REQUIRED to be backwards compatible with ALL PREVIOUS 802. 11 FEATURES – – – Submission 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 26 Matthew Fischer, Broadcom

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 The Issue of MAC

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 The Issue of MAC Complexity • Combined total of 35 frame type/subtypes (v 2003+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: – – – Submission Completion date of the standardization of TGn Interpretability of the standard by implementers Implementation complexity Probability of implementation error Potential multi-vendor interoperability problems 27 Matthew Fischer, Broadcom

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 WWISE Compared to others

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 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 Submission 28 Matthew Fischer, Broadcom

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 WWISE Simplicity • HTP

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 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 Submission 29 Matthew Fischer, Broadcom

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 But How Effective is

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 But How Effective is WWISE? • Following slides demonstrate the effectiveness of WWISE-proposed features Submission 30 Matthew Fischer, Broadcom

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 PREAMBLE • WWISE --

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 PREAMBLE • WWISE -- 20 usec: – Complexity • No more than expected for a change to MIMO system – Throughput gain vs 802. 11 a/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. 11 a/g • Efficiency LOSS vs previous standard – (44. 8 usec vs 20 usec preamble) Submission 31 Matthew Fischer, Broadcom

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 Preamble = Fixed overhead

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 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 Submission 32 Matthew Fischer, Broadcom

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 Effect of Preamble Length

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 Effect of Preamble Length (%) Submission 33 Matthew Fischer, Broadcom

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 MSDU Aggregation • Effectively

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 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) Submission 34 Matthew Fischer, Broadcom

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 MSDU Aggregation Performance Increase

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 MSDU Aggregation Performance Increase Submission 35 Matthew Fischer, Broadcom

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 MSDU Aggregation • OVERALL

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 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 Submission 36 Matthew Fischer, Broadcom

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 HTP Burst • Assuming

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 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) Submission 37 Matthew Fischer, Broadcom

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 HTP Burst Performance Improvement

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 HTP Burst Performance Improvement Submission 38 Matthew Fischer, Broadcom

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 Block Ack – Existing

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 Block Ack – Existing NORMAL ACK POLICY M 1 M 2 ACK BLOCK ACK POLICY M 1 M 2 ACK M 3 M 4 ACK ACK breq ACK back • 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 Submission 39 Matthew Fischer, Broadcom

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 Block Ack – No

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 Block Ack – No ACK Policy NORMAL ACK POLICY M 1 M 2 ACK BLOCK ACK No-ACK POLICY M 1 M 2 ACK M 3 M 4 ACK breq back • 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) Submission 40 Matthew Fischer, Broadcom

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 Block Ack Comparison %

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 Block Ack Comparison % Submission 41 Matthew Fischer, Broadcom

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 Block Ack No-ACK Simplicity

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 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 Submission 42 Matthew Fischer, Broadcom

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 Block Ack No-ACK Realized

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 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 Submission 43 Matthew Fischer, Broadcom

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 Multipoll is unwise (and

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 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 Submission 44 Matthew Fischer, Broadcom

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 Multipoll “Performance” • What

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 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? Submission 45 Matthew Fischer, Broadcom

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 Multipoll “gains” as %

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 Multipoll “gains” as % Submission 46 Matthew Fischer, Broadcom

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 Multipoll problems • Polled

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 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 – – – Submission 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 47 Matthew Fischer, Broadcom

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 Summary • There are

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 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 Submission 48 Matthew Fischer, Broadcom

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 BACKUP SLIDES Submission 49

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 BACKUP SLIDES Submission 49 Matthew Fischer, Broadcom

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 Preambles: 2 Tx, “green

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 Preambles: 2 Tx, “green time” 20 MHz Short Long - N SIG-N WWi. SE: 20 msec 8 8 4 SIG-N Short-N Long-N or TGn. Sync: 44. 8 msec 20 Submission Long-N 8 50 2. 4 7. 2 Matthew Fischer, Broadcom

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 Preamble comparison • •

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 Preamble comparison • • UDP flow EDCA TXOP size of 10 msec AC 3 default parameters No Block Ack No RTS/CTS No HTP Burst No MSDU Aggregation Note that WWISE preamble is 20 usec for 2 x 2, increases to 28 usec for 4 x 4 Submission 51 Matthew Fischer, Broadcom

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 Aggregation comparison • •

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 Aggregation comparison • • UDP flow EDCA TXOP size of 10 msec AC 3 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 Submission 52 Matthew Fischer, Broadcom

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 HTP Burst Comparison •

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 HTP Burst Comparison • Non Burst: – TXOP limit = 10 msec – RTS/CTS off – Block Ack Off, Normal ACK on • HTP Burst: – – – Submission TXOP limit = 10 msec HTP Burst limit = 4 msec RTS/CTS on Block Ack On Block Ack Request every 4 MSDU 53 Matthew Fischer, Broadcom

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 Multipoll vs HCCA Poll

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 Multipoll vs HCCA Poll • TXOP = 2 msec • Multipoll = 4 Poll-RA • TXOP use = DATA-ACK – No RTS/CTS – No Block Ack Submission 54 Matthew Fischer, Broadcom

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 Block Ack - Complexity

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 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 – No. Ack • Does not require transmitter/receiver exchange Submission 55 Matthew Fischer, Broadcom

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 References Submission 56 Matthew

January 2005 doc. : IEEE 802. 11 -05/0016 r 2 References Submission 56 Matthew Fischer, Broadcom