1. doc.: IEEE 802.11-04/888r13 Submission July 2005 Syed Aon Mujtaba, Agere Systems, et. al.Slide 1 TGn Sync Complete Proposal 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-07-08 Author NameCompanyAddressPhoneEmail Syed Aon Mujtaba Agere Systems 555 Union Blvd., Allentown, PA 18109, USA +1 610 712 6616mujtaba@agere.com

2. doc.: IEEE 802.11-04/888r13 Submission July 2005 Syed Aon Mujtaba, Agere Systems, et. al.Slide 2

3. doc.: IEEE 802.11-04/888r13 Submission July 2005 Syed Aon Mujtaba, Agere Systems, et. al.Slide 3

4. doc.: IEEE 802.11-04/888r13 Submission July 2005 Syed Aon Mujtaba, Agere Systems, et. al.Slide 4

5. doc.: IEEE 802.11-04/888r13 Submission July 2005 Syed Aon Mujtaba, Agere Systems, et. al.Slide 5 Abstract  This document describes the TGn Sync complete proposal submission to IEEE 802.11 TGn

6. doc.: IEEE 802.11-04/888r13 Submission July 2005 Syed Aon Mujtaba, Agere Systems, et. al.Slide 6 PHY

7. doc.: IEEE 802.11-04/888r13 Submission July 2005 Syed Aon Mujtaba, Agere Systems, et. al.Slide 7 Summary of PHY Architecture  Mandatory features: ■ Support for 1 and 2 spatial streams in 20MHz ■ Channel coding rates: 1/2, 2/3, 3/4, and 5/6 ■ Modulations: BPSK, QPSK, 16QAM, 64QAM ■ Support for Rx assisted Rate Control ■ Guard Interval: 800ns  Optional features: ■ 40 MHz channelizations ■ STBC ■ Transmit beamforming (Tx BF) - beamsteering ■ Guard Interval: 400ns ■ Advanced coding (LDPC) ■ Support for 3 and 4 spatial streams ■ 256-QAM 130 Mbps in 2x2x20 720 Mbps in 4x4x40

8. doc.: IEEE 802.11-04/888r13 Submission July 2005 Syed Aon Mujtaba, Agere Systems, et. al.Slide 8 PHY modification since May ’05  Introduced STBC  Created MCS capability classes  Made TxBF optional for both transmit and receive

9. doc.: IEEE 802.11-04/888r13 Submission July 2005 Syed Aon Mujtaba, Agere Systems, et. al.Slide 9 STBC in the Unified Datapath Two constraints:

10. doc.: IEEE 802.11-04/888r13 Submission July 2005 Syed Aon Mujtaba, Agere Systems, et. al.Slide 10 STBC with Direct Mapped MIMO

11. doc.: IEEE 802.11-04/888r13 Submission July 2005 Syed Aon Mujtaba, Agere Systems, et. al.Slide 11 STBC with Spatial Spreading

12. doc.: IEEE 802.11-04/888r13 Submission July 2005 Syed Aon Mujtaba, Agere Systems, et. al.Slide 12 Pilots & Preambles with STBC Channel Encoder Puncturer Frequency Interleaver Constellation Mapper Pilots HT LTF Scrambled MPDU iFFT Mod. insert GI window iFFT Mod. insert GI iFFT Mod. insert GI window Spatial Parser P iFFT Mod. insert GI window STBC Pilots HT LTF Pilots HT LTF Pilots HT LTF Frequency Interleaver Constellation Mapper Example: Nss=2, Ntx=4

13. doc.: IEEE 802.11-04/888r13 Submission July 2005 Syed Aon Mujtaba, Agere Systems, et. al.Slide 13 MCS Capability Classes  Ability to support number of spatial streams  Ability to support unequal modulations across spatial streams  Ability to support 256-QAM  Ability to support 400ns GI  Ability to support 40MHz Signaled in the HT-SIG field

14. doc.: IEEE 802.11-04/888r13 Submission July 2005 Syed Aon Mujtaba, Agere Systems, et. al.Slide 14 Mandatory vs Optional Capabilties MCS Set Mandatory Capability Optional Capability Nss=1 Nss=2 Nss=3 Nss=4 256 QAM Unequal MCS (800ns GI, 20MHz) (400ns GI, 40MHz)

15. doc.: IEEE 802.11-04/888r13 Submission July 2005 Syed Aon Mujtaba, Agere Systems, et. al.Slide 15 4-bit field for MCS capability classes  The MCS capability classes are specified by a 4- bit field: b 3 b 2 b 1 b 0 ■ b 3 is set to 1 if MCSs that use 256-QAM are included, otherwise it is set to 0 ■ b 2 is set to 1 if MCSs with unequal modulations across spatial streams are included, otherwise it is set to 0 ■ b 1 b 0 indicates the maximum number of spatial streams supported: 00: maximum 1 stream 01: maximum 2 streams 10: maximum 3 streams 11: maximum 4 streams  4-bit field is signaled during association time

16. doc.: IEEE 802.11-04/888r13 Submission July 2005 Syed Aon Mujtaba, Agere Systems, et. al.Slide 16 MCS Capability Table Note: see 04/889r7 for details on MCS 0 to 126

17. doc.: IEEE 802.11-04/888r13 Submission July 2005 Syed Aon Mujtaba, Agere Systems, et. al.Slide 17 Summary of PHY features Open Loop SDM RX assisted Rate Control 2 Spatial Streams 20 MHz Robustness Enhancement Tx BF 4 Spatial Streams 256-QAM Throughput Enhancement Conv. Coding LDPC Robustness Enhancement Mandatory (130Mbps) Optional (720Mbps) 40 MHz Throughput Enhancement 800ns GI400ns GI STBC

18. doc.: IEEE 802.11-04/888r13 Submission July 2005 Syed Aon Mujtaba, Agere Systems, et. al.Slide 18 MAC

19. doc.: IEEE 802.11-04/888r13 Submission July 2005 Syed Aon Mujtaba, Agere Systems, et. al.Slide 19 MAC Efficiency is our Design Goal  Improve 802.11 MAC efficiency ■ Aggregation alone is not enough to preserve high efficiency at higher data rates with TCP and QoS flows ■ PHY improvements demand increased MAC performance  Balance performance versus simplicity ■ TGn Sync includes MAC features for quantified performance gains ■ Feedback from TGn has caused us to make significant simplifications without damaging performance

20. doc.: IEEE 802.11-04/888r13 Submission July 2005 Syed Aon Mujtaba, Agere Systems, et. al.Slide 20 Other MAC Design Objectives  Meet the requirements of the TGn Usage Models ■ Stringent QoS Requirements of emerging CE Applications ■ VoIP  Propose a forward-looking standard that will last as application demands increase ■ TGn features must allow performance improvements as devices and technology mature  Efficient operation in the presence of legacy devices ■ Efficient interoperability is more than just simply “coexistence”

21. doc.: IEEE 802.11-04/888r13 Submission July 2005 Syed Aon Mujtaba, Agere Systems, et. al.Slide 21 Scalable MAC Architecture BASELINE MAC Robust Aggregation QoS Support (802.11e) Rx assisted link adapt. ADDITIONAL EFFICIENCY MMP Sequence Reverse Dir. Data Flow BA Enhancements LEGACY INTEROP. Long NAV Extended PHY Protection CHANNEL MANAGEMENT 20/40 MHz Management 20MHz-base Managed mode Robust & Scalable MAC Architecture Blue text = simplified in July Proposal

22. doc.: IEEE 802.11-04/888r13 Submission July 2005 Syed Aon Mujtaba, Agere Systems, et. al.Slide 22 Straw Poll Guidance from May TGn Replace 3-way handshake with 1-way simple grant Replace Pairwise Spoofing with an alternative Remove negotiation of number of MSDUs in the bitmap at BA setup time Remove BA state restriction Remove implicit BAR mechanism  Add RIFS PPDU bursting feature ■ Evaluation and details not complete

23. doc.: IEEE 802.11-04/888r13 Submission July 2005 Syed Aon Mujtaba, Agere Systems, et. al.Slide 23 Changes since May 2005 (1)  Simplified Reverse Direction data ■ Remove RDL/RDR/RDG signaling ■ Single additional bit to grant RDG, re-use of existing Duration field  Simplified Protection ■ Pairwise spoofing replaced by simpler Extended PHY Protection (EPP) rules ■ No additional signaling required  Simplified and Improved Block Ack ■ Two fixed sizes for BA bitmap depending on fragmentation ■ Partial state bitmap option reduces implementation cost while providing benefits of immediate response

24. doc.: IEEE 802.11-04/888r13 Submission July 2005 Syed Aon Mujtaba, Agere Systems, et. al.Slide 24 Changes since May 2005 (2)  Simplified Coexistence Management ■ Removed modal behavior except for 20MHz-base operation ■ Removed ICB/DCB frames and use existing frames to provide 20MHz-base operation ■ Simplified text significantly  Reduced number of and simplified control frames ■ Removed ICB/DCB ■ Most of functionality of IAC/RAC removed. IAC/RAC replaced by LAC, which supports link adaptation.

25. doc.: IEEE 802.11-04/888r13 Submission July 2005 Syed Aon Mujtaba, Agere Systems, et. al.Slide 25 Reverse Direction Data  RDG mechanism supports reverse direction data flow in the single-responder case ■ Allows responder to return data in the initiator’s TXOP ■ A simple extension of 802.11e TXOP  Significantly reduced contention allowing EDCA performance to match HCCA performance.  MMP mechanism supports reverse direction flow from multiple responders ■ MMP sequence is especially suited to support a large number of VoIP calls in a BSS. ■ Allows downlink burst followed by multiple responses ■ MRA aggregation can be used in downlink burst

26. doc.: IEEE 802.11-04/888r13 Submission July 2005 Syed Aon Mujtaba, Agere Systems, et. al.Slide 26 Changes to Reverse Direction Protocol since May  Removed RDL/RDR/RDG signalling  Use existing “Duration” field, plus redefine meaning of “order” bit in MPDU header for BA, BAR, QoS data frames to mean “1-bit grant”  Enhanced to allow bursting in the reverse direction  Also considered and rejected re-use of QoS CF-Poll to be closer to 802.11e ■ It is not possible to exactly follow 802.11e rules Error Recovery Termination of TXOP ■ TXOP “transfer” proved too complex and difficult to specify ■ Simulation results suggest TXOP transfer does not significantly improve performance

27. doc.: IEEE 802.11-04/888r13 Submission July 2005 Syed Aon Mujtaba, Agere Systems, et. al.Slide 27 Reverse Direction Example

28. doc.: IEEE 802.11-04/888r13 Submission July 2005 Syed Aon Mujtaba, Agere Systems, et. al.Slide 28 Extended PHY Protection: EPP  Provide Robust Legacy and 3 rd Party Protection ■ Use of L-SIG (Length/Rate) to provide NAV Protection  EPP provides: ■ Legacy Protection with MIMO Trainable Packets Effective towards closed loop feedback with initial handshake ■ Effective 20/40 MHz Interop L-SIG field is decodable in both halves of 40MHz channel ■ Robust protection through L-SIG (6 Mbps) with a High Rate PPDU  Simplified replacement of Pairwise Spoofing

29. doc.: IEEE 802.11-04/888r13 Submission July 2005 Syed Aon Mujtaba, Agere Systems, et. al.Slide 29 Extended PHY Protection: with RTS/CTS  Rules at the Initiator ■ RTS protects until end of CTS ■ Indicate to Responder the “Protection Request” by using MAC Duration of the RTS MPDU ■ Upon receiving CTS, the first PPDU protects to end of Protection Duration of CTS plus some time X. If X > 0, EPP Duration can be extended  Rules at the Responder ■ Upon receiving a EPP RTS addressed to itself, send a CTS with a legacy duration equivalent to “Protection Request”  LAC/LAC exchange can be used instead of RTS/CTS

30. doc.: IEEE 802.11-04/888r13 Submission July 2005 Syed Aon Mujtaba, Agere Systems, et. al.Slide 30 Extended PHY Protection: MMP  EPP provide robust protection in MMP Sequence ■ The initial scheduling MMP frame provide protection towards entire MMP Sequence ■ Robust protection through L-SIG (6 Mbps) in MMP

31. doc.: IEEE 802.11-04/888r13 Submission July 2005 Syed Aon Mujtaba, Agere Systems, et. al.Slide 31 BA Simplifications and Improvements  Removed negotiation of number of MSDUs in the bitmap at BA setup time ■ Compressed BA has a fixed bitmap of 8 bytes  Removed BA state restriction ■ Removed restrictions that arise from the original semantics ■ Replaced it with HT delayed BA with immediate partial state response plus delayed full state response  Originator explicitly requests BA response ■ Through BAR (as in 802.11e) ■ Through “Normal Ack” policy in QoS Data aggregated frames

32. doc.: IEEE 802.11-04/888r13 Submission July 2005 Syed Aon Mujtaba, Agere Systems, et. al.Slide 32 Benefits of Enhanced Block Ack  Compressed BA frame ■ Simple compression achieved by dropping fragmentation ■ Reduces the BA bitmap from 128 to 8 bytes  Delayed BA with Immediate Partial State Response ■ Provides deterministic BA response time Improves QoS Decreases buffering at both ends Enhances power saving for APSD stations ■ More scalable than 11e immediate BA Does not require large on-chip memory to support many stations Perform as well as immediate BA for most common exchange sequences

33. doc.: IEEE 802.11-04/888r13 Submission July 2005 Syed Aon Mujtaba, Agere Systems, et. al.Slide 33 Compressed BA frame CompressedNum-BitsBitmap LengthBitmap Interpretation 00128Legacy 11e BA 10-638HT BA. Bit n acks/nacks an MSDU with Sequence Control = SSN+16n. The 1 st Num- Bits are valid; the remaining bits are ignored.  Compress BA by removing fragmentation

34. doc.: IEEE 802.11-04/888r13 Submission July 2005 Syed Aon Mujtaba, Agere Systems, et. al.Slide 34 Link Adaptation  Previously performed by IAC/RAC control frames  Other simplifications left the IAC/RAC performing only link adaptation, so we collapsed the remaining functions into a single frame subtype, called Link Adaptation Control (LAC)  LAC/LAC Control frame exchange ■ An enhancement of RTS/CTS exchange ■ Timely and efficient method for exchange of control information supports MCS Feedback Beamforming

35. doc.: IEEE 802.11-04/888r13 Submission July 2005 Syed Aon Mujtaba, Agere Systems, et. al.Slide 35 Timely Link Adaptation  Rate adapted transmission can be achieved in one round trip.  Timing of exchange is not constrained. SIFS response is not mandated.

36. doc.: IEEE 802.11-04/888r13 Submission July 2005 Syed Aon Mujtaba, Agere Systems, et. al.Slide 36 TGnSync MAC Benefits ItemBenefit AggregationScalable 200% compared to 802.11e Receiver assisted link adaptation 30-50% goodput increase over “open loop” Reverse direction data8-36% goodput increase (e.g. improves TCP performance) MMP sequence~100% increase in number of VoIP calls and improved APSD power- saving

37. doc.: IEEE 802.11-04/888r13 Submission July 2005 Syed Aon Mujtaba, Agere Systems, et. al.Slide 37 System Simulation Results  3 independent MAC simulations ■ 802.11-04/893 ■ 802.11-04/894 ■ 802.11-04/1359  Compliant to TGn FRCC requirements  FRCC Results and analysis of MAC features is presented in 802.11-04/892  Detailed description of MAC simulation methodology in 802.11-04/895

38. doc.: IEEE 802.11-04/888r13 Submission July 2005 Syed Aon Mujtaba, Agere Systems, et. al.Slide 38 Selected System CC Performance CC#NameResult HCCAEDCA 2x2x202x2x402x2x202x2x40 SS1 +10619299180 SS4 +110226103219 SS6 +10020491178 CC18 HT Usage Models Supported Non-QoS (Measured aggregate throughput/ offered aggregate throughput) SS1 + (Mbps/ratio) 54/0.27139/0.6947/0.23127/0.63 SS4 +101/0.22216/0.2793/0.10209/0.27 SS6 +55/0.18159/0.5346/0.15133/0.44 CC19 HT Usage Models Supported (number of QoS flows that meet their QoS requirements) SS1 +17 of 17 SS4 +18 of 18 SS6 +39 of 39 CC58HT Spectral Efficiencybps/Hz6.06.2856.06.285

39. doc.: IEEE 802.11-04/888r13 Submission July 2005 Syed Aon Mujtaba, Agere Systems, et. al.Slide 39 Selected System CC Performance CC#NameResult HCCAEDCA 2x2x202x2x402x2x202x2x40 CC3 List of goodput results for usage models 1, 4 and 6. SS1 +10619299180 SS4 +110226103219 SS6 +10020491178  Scalable performance 20  40 MHz  EDCA performance approaching HCCA

40. doc.: IEEE 802.11-04/888r13 Submission July 2005 Syed Aon Mujtaba, Agere Systems, et. al.Slide 40 MAC Summary  We received feedback from “no” voters and the May 2005 TGn session straw polls ■ This has enabled us to simplify the MAC without sacrificing performance  MAC Efficiency ■ Highly Efficient ■ Scales well from 20MHz to 40MHz ■ Improved efficiency of the TGn Sync MAC is in line with performance improvements in the PHY

41. doc.: IEEE 802.11-04/888r13 Submission July 2005 Syed Aon Mujtaba, Agere Systems, et. al.Slide 41 Glossary