802.11N-Draftstd June2009.Pdf

IEEE P802.11n/D11.0, June 2009

1 2 IEEE P802.11n™/D11.0 3 4 5 6 7 Draft STANDARD for 8 9 10 Information Technology— 11 12 13 Telecommunications and information exchange 14 15 between systems— 16 17 18 Local and metropolitan area networks— 19 20 Specific requirements 21 22 23 24 25 26 Part 11: Wireless LAN Medium Access Control 27 28 (MAC) and Physical Layer (PHY) specifications 29 30 31 32 33 Amendment 5: Enhancements for Higher 34 35 36 Throughput 37 38 39 40 41 Prepared by the 802.11 Working Group of the 802 Committee 42 43 Copyright © 2009 by the IEEE. 44 Three Park Avenue 45 46 New York, NY 10016-5997, USA 47 48 All rights reserved. 49 50 51 This document is an unapproved draft of a proposed IEEE Standard. As such, this document is subject to 52 change. USE AT YOUR OWN RISK! Because this is an unapproved draft, this document must not be uti- 53 lized for any conformance/compliance purposes. Permission is hereby granted for IEEE Standards Commit- 54 55 tee participants to reproduce this document for purposes of international standardization consideration. Prior 56 to adoption of this document, in whole or in part, by another standards development organization, permis- 57 sion must first be obtained from the IEEE Standards Activities Department ([email protected]). Other enti- 58 ties seeking permission to reproduce this document, in whole or in part, must also obtain permission from 59 the IEEE Standards Activities Department. 60 61 IEEE Standards Activities Department 62 63 445 Hoes Lane 64 65 Piscataway, NJ 08854, USA

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Abstract: This amendment defines modifications to both the 802.11 physical layers (PHY) and the 802.11 2 Medium Access Control Layer (MAC) so that modes of operation can be enabled that are capable of much 3 higher throughputs, with a maximum throughput of at least 100 Mb/s, as measured at the MAC data service 4 5 access point (SAP). 6 7 Keywords: Wireless LAN, Medium Access Control, Physical Layer, Radio, Multiple Input Multiple Out- 8 put, MIMO, MIMO-OFDM, High Throughput 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Introduction 2 3 (This introduction is not part of IEEE P802.11n/D11.0, Draft Amendment to Standard for Information 4 Technology-Telecommunications and information exchange between systems-Local and Metropolitan 5 networks-Specific requirements-Part 11: Wireless LAN Medium Access Control (MAC) and Physical 6 7 Layer (PHY) specifications: Enhancements for Higher Throughput.) 8 9 10 This amendment specifies enhancements to 802.11 PHY and MAC layers to provide modes of operation with 11 useful data rates substantially higher than those previously available. Significantly higher 802.11 wireless lo- 12 cal area network (LAN) throughput is expected to improve user experiences for current applications and to 13 14 enable new applications and market segments. 15 16 17 Notice to users 18 19 20 Laws and regulations 21 22 Users of these documents should consult all applicable laws and regulations. Compliance with the provisions 23 of this standard does not imply compliance to any applicable regulatory requirements. Implementers of the 24 25 standard are responsible for observing or referring to the applicable regulatory requirements. IEEE does not, 26 by the publication of its standards, intend to urge action that is not in compliance with applicable laws, and 27 these documents may not be construed as doing so. 28 29 30 Copyrights 31 32 33 This document is copyrighted by the IEEE. It is made available for a wide variety of both public and private 34 uses. These include both use, by reference, in laws and regulations, and use in private self-regulation, stan- 35 dardization, and the promotion of engineering practices and methods. By making this document available for 36 use and adoption by public authorities and private users, the IEEE does not waive any rights in copyright to 37 this document. 38 39 40 41 Updating of IEEE documents 42 43 Users of IEEE standards should be aware that these documents may be superseded at any time by the issuance 44 of new editions or may be amended from time to time through the issuance of amendments, corrigenda, or 45 errata. An official IEEE document at any point in time consists of the current edition of the document together 46 47 with any amendments, corrigenda, or errata then in effect. In order to determine whether a given document is 48 the current edition and whether it has been amended through the issuance of amendments, corrigenda, or er- 49 rata, visit the IEEE Standards Association website at http://ieeexplore.ieee.org/xpl/standards.jsp, or contact 50 the IEEE at the address listed previously. 51 52 53 For more information about the IEEE Standards Association or the IEEE standards development process, visit 54 the IEEE-SA website at http://standards.ieee.org. 55 56 57 Errata 58 59 Errata, if any, for this and all other standards can be accessed at the following URL: 60 61 http://standards.ieee.org/reading/ieee/updates/errata/index.html. Users are encouraged to check this URL for 62 errata periodically. 63 64 65 Interpretations

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Current interpretations can be accessed at the following URL: 2 http://standards.ieee.org/reading/ieee/interp/index.html. 3 4 5 Patents 6 7 8 Attention is called to the possibility that implementation of this amendment may require use of subject mat- 9 ter covered by patent rights. By publication of this standard, no position is taken with respect to the existence 10 or validity of any patent rights in connection therewith. A patent holder or patent applicant has filed a state- 11 ment of assurance that it will grant licenses under these rights without compensation or under reasonable 12 13 rates, with reasonable terms and conditions that are demonstrably free of any unfair discrimination to appli- 14 cants desiring to obtain such licenses. Other Essential Patent Claims may exist for which a statement of 15 assurance has not been received. The IEEE is not responsible for identifying Essential Patent Claims for 16 which a license may be required, for conducting inquiries into the legal validity or scope of Patents Claims, 17 or determining whether any licensing terms or conditions are reasonable or non-discriminatory. Users of this 18 19 standard are expressly advised that determination of the validity of any patent rights, and the risk of infringe- 20 ment of such rights, is entirely their own responsibility. Further information may be obtained from the IEEE 21 Standards Association. 22 23 24 Participants 25 26 27 At the time this draft Standard was completed, the 802.11 Working Group had the following membership: 28 Bruce Kraemer, Chair 29 Jon Rosdahl and Adrian Stephens, Vice-chairs 30 Stephen McCann, Secretary 31 32 EDITORIAL NOTE—a three column list of voting members of 802.11 on the day the draft was sent for 33 34 sponsor ballot will be inserted 35 36 The following were officers of Task Group n: 37 Bruce Kraemer, Chair 38 Sheung Li, Vice-Chair 39 40 Garth Hillman, Secretary 41 Adrian P. Stephens, Technical Editor 42 43 Contributions to this amendment were received from the following individuals: 44 Abbott, Bill Bjerke, Bjorn de Courville, Marc 45 46 Abraham, Santosh Blakenship, Yufei de Vegt, Rolf 47 Adachi, Tomoko Borges, Daniel Dielacher, Franz 48 Akhmetov, Dmitry Chan, Douglas Doi, Yoshiharu 49 Aldana, Carlos Chang, Jerry Dorsey, John 50 Andrus, Dave Chang, John Douglas, Brett 51 52 Anholt, Micha Chen, Jeng-Hong Ecclesine, Peter 53 Aoki, Tsuguhide Chen, Stephen Engwer, Darwin 54 Asai, Yusuke Chen, Yi-Ming Epstein, Leonid 55 Awater, Geert Chiang, Pei-ju Erceg, Vinko 56 Bagby, David Chin, Francois Eroz, Mustafa 57 58 Banerjea, Raja Chin, Woon Hau Fechtel, Stefan 59 Banerjee, Kaberi Chou, Emily Feinberg, Paul 60 Bansal, Amit Chu, Liwen Fischer, Matthew 61 Basson, Gal Chugg, Keith Frederiks, Guido 62 Batra, Anuj Classon, Brian Fukagawa, Takashi 63 64 Benko, John Coffey, Sean Fung, Patrick 65 Benveniste, Mathilde Convertino, Gabriella Gallizio, Edoardo

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Gardner, James Li, Pen Poloni, Angelo 2 Gatti, Devis Li, Sheung Poojary, Neeraj 3 Ghosh, Monisha Li, Yuan Ptasinski, Henry 4 5 Gosteau, Jeremy Liao, Kevin Purkovic, Aleksandar 6 Grandhi, Sudheer Lim, Isaac Qian, Luke 7 Gray, Paul Lin, Alfred Raissinia, Ali 8 Gresset, Nicolas Liu, Albert Ramakrishnan, Sthanunathan 9 Gu, Daqing Liu, Der-Zheng Ramamurthy, Harish 10 11 Gunduzhan, Emre Livshitz, Michael Ramesh, Sridhar 12 Hansen, Christopher Loc, Peter Riva, Raffaele 13 Hart, Brian Lojko, Peter Rosdahl, Jon 14 Hedberg, David Lou, Hui-Ling Rouquette-Leveil, Stephanie 15 Hillman, Garth Matache, Adina Rude, Mike 16 17 Ho, Jin-Meng Mazet, Laurent Sadowsky, John 18 Hocevar, Dale McFarland, William Salhotra, Atul 19 Hoo, Louise McNamara, Darren Scarpa, Vincenzo 20 Ikram, Muhammad Medvedev, Irina Schultz, Donald 21 22 Inoue, Yasuhiko Meylan, Arnaud Schylander, Erik 23 Ishida, Kaz Miki, Morgan Seals, Michael 24 Ishidoshiro, Takashi Min, Seungwook Shao, Huai-Rong 25 Iyer, Lakshmi Mo, Patrick Sharma, Suman 26 Jacobson, Eric Molisch, Andy Shellhammer, Steve 27 28 Jauh, Yuh-Ren Moorti, R. Tushar Sherlock, Ian 29 Jeon, Taehyun Moreton, Mike Shida, Masaaki 30 Jokela, Jari Morioka, Yuichi Shono, Takashi 31 Jones, VK Muck, Markus Simoens, Sebastien 32 Kafle, Padam Mujtaba, Syed Aon Siti, Massimiliano 33 34 Kakani, Naveen Myles, Andrew Smith, Doug 35 Kandala, Sriniavs Nabar, Rohit Smith, Matt 36 Kapur, Ateet Nagai, Yukimasa Soomro, Amjad 37 Kasher, Assaf Nagata, Kengo Stacey, Robert 38 Kato, Masato Nakao, Seigo Stephens, Adrian 39 40 Ketchum, John Nanda, Sanjiv Stephenson, Dave 41 Kim, Joonsuk Ngo, Chiu Stolpman, Victor 42 Kim, Pansop Nimbalker, Ajit Sun, Sumei 43 Kim, Youngsoo Nitsche, Gunnar Sun, Xiantao 44 Kleindl, Guenter Niu, Huaning Surineni, Shravan 45 46 Kobayashi, Kiyotaka Oakes, Ivan Sutskover, Ilan 47 Kose, Cenk Ohtani, Yoshihiro Takagi, Eiji 48 Kraemer, Bruce Ojard, Eric Takagi, Masahiro 49 Kuehnel, Thomas Onizawa, Takeshi Takahashi, Seiichiro 50 Kunihiro, Takushi Oostveen, Job Takeda, Daisuke 51 52 Kwak, Joe Osnato, Fabio Tan, Teik-Kheong 53 Kwak, Joseph Padam, Kafle Tanaka, Yasuhiro 54 Kwon, Edwin Pai, Pratima ten Brink, Stephan 55 Labbe, Patrick Palanivelu, Arul Thiagarajan, Ganesan 56 Lauer, Joseph Parameswaran, Subra Tokubo, Eric 57 58 Lee, Dongjun Pare, Thomas Towell, Tim 59 Lee, Lin-Nan Patillon, Jean-Noel Trachewsky, Jason 60 Lee, Sheng Peng, Wei-Chung Trainin, Solomon 61 Lee, Sok-kyu Perahia, Eldad Tung, David 62 Lei, Zhongding Petranovich, Jim Valle, Stefano 63 64 Levy, Joseph Pillai, Krishna Madhavan van Nee, Richard 65 Leyonhjelm, Scott Pillai, Madhavan van Waes, Nico

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 van Zelst, Allert Webster, Mark Yeh, Wen-Chang 2 Vila Casado, Andres Wentink, Menzo Young, Christopher 3 4 Vlantis, George Wesel, Richard Yu, Heejung 5 Wakeley, Timothy Wilhoyte, Mike Zaks, Artur 6 Walker, Jesse Wong, Timothy Zeira, Eldad 7 Wallace, Brad Woodyatt, James Zhang, Hongyuan 8 Wallace, Mark Wu, Yan Zhang, Jin 9 10 Walton, Rod Xhafa, Ariton Zhang, Ning 11 Wang, Qi Xia, Bo Zhou, Quan 12 Wang, Xiaowen Yamaura, Tomoya Zweig, Johnny 13 Waters, Deric Yang, Eric Zyren, Jim 14 15 16 17 18 The following members of the individual balloting committee voted on this Standard. Balloters may have 19 voted for approval, disapproval, or abstention. 20 21 EDITORIAL NOTE—a three-column list of responding sponsor ballot members will be inserted by IEEE 22 23 staff 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table of Contents 2 3 4 2. Normative references...... 2 5 6 3. Definitions ...... 2 7 8 9 3A. Definitions specific to IEEE 802.11 ...... 3 10 11 4. Abbreviations and acronyms ...... 8 12 13 14 5. General description...... 9 15 16 5.2.9 High Throughput (HT) STA ...... 9 17 18 6. MAC service definition ...... 10 19 20 21 6.1 Overview of MAC services ...... 10 22 6.1.5 MAC data service architecture ...... 10 23 24 7. Frame formats ...... 12 25 26 27 7.1 MAC frame formats...... 12 28 7.1.1 Conventions ...... 12 29 7.1.2 General frame format...... 12 30 31 7.1.3 Frame fields ...... 13 32 7.1.3.1 Frame control field...... 13 33 7.1.3.1.2 Type and Subtype fields ...... 13 34 7.1.3.1.6 Power Management field...... 13 35 7.1.3.1.7 More Data field...... 13 36 37 7.1.3.1.9 Order field...... 14 38 7.1.3.2 Duration/ID field...... 14 39 7.1.3.3 Address fields ...... 14 40 7.1.3.3.3 BSSID field...... 14 41 42 7.1.3.3.4 DA field ...... 14 43 7.1.3.3.5 SA field...... 14 44 7.1.3.4 Sequence Control field...... 15 45 7.1.3.4.1 Sequence Number field...... 15 46 7.1.3.4.2 Fragment Number field...... 15 47 48 7.1.3.5 QoS Control field...... 15 49 7.1.3.5.1 TID subfield...... 16 50 7.1.3.5.3 Ack Policy subfield...... 17 51 7.1.3.5.5 Queue Size subfield ...... 17 52 53 7.1.3.5.6 TXOP Duration Requested subfield ...... 18 54 7.1.3.5.7 AP PS Buffer State subfield...... 18 55 7.1.3.5.8 A-MSDU Present subfield...... 18 56 7.1.3.5a HT Control field...... 18 57 58 7.1.3.6 Frame Body field ...... 22 59 7.1.4 Duration/ID field (QoS STA)in data and management frames ...... 23 60 7.1.4.1 General...... 23 61 7.1.4.2 Duration/ID field setting for single and multiple protection under 62 EDCA 23 63 64 7.1.4.3 Duration/ID field setting for QoS CF-Poll frames...... 25 65 7.1.4.4 Duration/ID field setting for frames sent by a TXOP holder under

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 HCCA 25 2 7.1.4.5 Duration/ID field settings within a PSMP sequence ...... 26 3 7.1.4.6 Duration/ID field settings within a dual-CTS sequence ...... 26 4 5 7.1.4.7 Duration/ID field setting for control response frames ...... 26 6 7.1.4.8 Duration/ID field setting for other response frames ...... 26 7 7.2 Format of individual frame types...... 27 8 7.2.1 Control frames ...... 27 9 7.2.1.1 RTS frame format ...... 27 10 11 7.2.1.2 CTS frame format ...... 27 12 7.2.1.3 ACK frame format...... 28 13 7.2.1.7 Block Ack Request (BlockAckReq) frame format...... 29 14 7.2.1.7.1 Overview of the BlockAckReq frame format...... 29 15 7.2.1.7.2 Basic BlockAckReq variant...... 31 16 17 7.2.1.7.3 Compressed BlockAckReq variant...... 31 18 7.2.1.7.4 Multi-TID BlockAckReq variant...... 31 19 7.2.1.8 Block Ack (BlockAck) frame format ...... 32 20 7.2.1.8.1 Overview of the BlockAck frame format ...... 32 21 22 7.2.1.8.2 Basic BlockAck variant ...... 34 23 7.2.1.8.3 Compressed BlockAck variant ...... 34 24 7.2.1.8.4 Multi-TID BlockAck variant ...... 35 25 7.2.1.9 Control Wrapper frame...... 35 26 7.2.2 Data frames ...... 36 27 28 7.2.2.1 Data frame format...... 36 29 7.2.2.2 Aggregate MSDU format (A-MSDU) ...... 38 30 7.2.3 Management frames...... 39 31 7.2.3.1 Beacon frame format ...... 40 32 7.2.3.4 Association Request frame format...... 41 33 34 7.2.3.5 Association Response frame format ...... 41 35 7.2.3.6 Reassociation Request frame format ...... 42 36 7.2.3.7 Reassociation Response frame format...... 42 37 7.2.3.8 Probe Request frame format ...... 43 38 7.2.3.9 Probe Response frame format...... 43 39 40 7.2.3.13 Action No Ack frame format...... 43 41 7.3 Management frame body components...... 44 42 7.3.1 Fields that are not information elements...... 44 43 7.3.1.7 Reason Code field...... 44 44 7.3.1.9 Status Code field...... 44 45 46 7.3.1.11 Action field ...... 45 47 7.3.1.14 Block Ack Parameter Set field...... 45 48 7.3.1.17 QoS Info field ...... 46 49 7.3.1.21 Channel Width field...... 46 50 7.3.1.22 Spatial Multiplexing (SM) Power Control field ...... 47 51 52 7.3.1.23 Phased coexistence operation (PCO) Phase Control field...... 47 53 7.3.1.24 Power save multi-poll (PSMP) Parameter Set field...... 48 54 7.3.1.25 PSMP STA Info field...... 49 55 7.3.1.26 MIMO Control field...... 50 56 7.3.1.27 CSI Report field...... 51 57 58 7.3.1.28 Non-compressed Beamforming Report field...... 53 59 7.3.1.29 Compressed Beamforming Report field ...... 55 60 7.3.1.30 Antenna Selection Indices field ...... 58 61 7.3.2 Information elements ...... 59 62 7.3.2.2 Supported Rates element ...... 59 63 64 7.3.2.14 Extended Supported Rates element ...... 60 65 7.3.2.20a Secondary Channel Offset element...... 61

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 7.3.2.21 Measurement Request element ...... 62 2 7.3.2.21.8 STA Statistics Request...... 62 3 7.3.2.22 Measurement Report element ...... 62 4 5 7.3.2.22.6 Beacon Report...... 62 6 7.3.2.22.8 STA Statistics Report...... 63 7 7.3.2.25 RSN information element ...... 64 8 7.3.2.25.3 RSN capabilities ...... 64 9 7.3.2.27 Extended Capabilities information element...... 65 10 11 7.3.2.28 BSS Load element ...... 67 12 7.3.2.29 EDCA Parameter Set element...... 67 13 7.3.2.30 TSPEC element...... 68 14 7.3.2.37 Neighbor Report element...... 70 15 7.3.2.56 HT Capabilities element ...... 71 16 17 7.3.2.56.1 HT Capabilities element structure ...... 71 18 7.3.2.56.2 HT Capabilities Info field...... 72 19 7.3.2.56.3 A-MPDU Parameters field...... 73 20 7.3.2.56.4 Supported MCS Set field ...... 74 21 22 7.3.2.56.5 HT Extended Capabilities field...... 75 23 7.3.2.56.6 Transmit Beamforming Capabilities...... 77 24 7.3.2.56.7 Antenna Selection Capability ...... 79 25 7.3.2.57 HT Operation element ...... 81 26 7.3.2.58 20/40 BSS Intolerant Channel Report element ...... 84 27 28 7.3.2.59 Overlapping BSS Scan Parameters element ...... 84 29 7.3.2.60 20/40 BSS Coexistence element ...... 85 30 7.4 Action frame format details ...... 86 31 7.4.1 Spectrum management action details ...... 86 32 7.4.1.5 Channel Switch Announcement frame format...... 86 33 34 7.4.3 DLS Action frame details ...... 86 35 7.4.3.1 DLS Request frame format...... 86 36 7.4.3.2 DLS Response frame format...... 87 37 7.4.4 Block Ack Action frame details...... 87 38 7.4.7 Public Action frame details ...... 87 39 40 7.4.7.1 Public Action frame...... 87 41 7.4.7.1a 20/40 BSS Coexistence Management frame format ...... 88 42 7.4.10 HT Action frame details ...... 88 43 7.4.10.1 HT Action field...... 88 44 7.4.10.2 Notify Channel Width frame format...... 88 45 46 7.4.10.3 SM Power Save frame format...... 89 47 7.4.10.4 PSMP frame format ...... 90 48 7.4.10.5 Set PCO Phase frame format ...... 90 49 7.4.10.6 CSI frame format ...... 91 50 7.4.10.7 Non-compressed Beamforming frame format ...... 91 51 52 7.4.10.8 Compressed Beamforming frame format ...... 92 53 7.4.10.9 Antenna Selection Indices Feedback frame format ...... 92 54 7.4a Aggregate MPDU (A-MPDU)...... 93 55 7.4a.1 A-MPDU format...... 93 56 7.4a.2 MPDU Delimiter CRC field ...... 94 57 58 7.4a.3 A-MPDU contents ...... 94 59 7.5 Frame usage ...... 98 60 61 8. Security ...... 99 62 63 64 8.1 Framework...... 99 65 8.1.5 RSNA assumptions and constraints...... 99

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 8.3 RSNA data confidentiality protocols...... 99 2 8.3.3 CTR with CBC-MAC Protocol (CCMP)...... 99 3 8.3.3.3 CCMP cryptographic encapsulation ...... 99 4 5 8.3.3.3.2 Construct AAD ...... 99 6 8.3.3.3.5 CCM originator processing...... 100 7 8.3.3.4 CCMP decapsulation ...... 100 8 8.3.3.4.3 PN and replay detection...... 100 9 8.4 RSNA security association management...... 100 10 11 8.4.3 RSNA policy selection in an ESS...... 100 12 8.4.4 RSNA policy selection in an IBSS and for DLS ...... 101 13 8.7 Per-frame pseudo-code ...... 101 14 8.7.2 RSNA frame pseudo-code ...... 101 15 8.7.2.1 Per-MSDU/Per-A-MSDU Tx pseudo-code...... 101 16 17 8.7.2.2 Per-MPDU Tx pseudo-code...... 102 18 8.7.2.4 Per-MSDU/A-MSDU Rx pseudo-code ...... 103 19 20 9. MAC sublayer functional description...... 104 21 22 23 9.1 MAC architecture ...... 104 24 9.1.3.1 HCF contention-based channel access (EDCA) ...... 104 25 9.1.5 Fragmentation/defragmentation overview...... 104 26 9.1.6 MAC data service ...... 105 27 28 9.2 DCF...... 105 29 9.2.2 MAC-Level acknowledgments...... 105 30 9.2.3 IFS...... 105 31 9.2.3.0a Overview...... 105 32 9.2.3.0b RIFS...... 106 33 34 9.2.3.1 SIFS ...... 106 35 9.2.3.2 PIFS ...... 106 36 9.2.3.5 EIFS ...... 107 37 9.2.4 Random backoff time...... 107 38 9.2.5 DCF access procedure ...... 108 39 40 9.2.5.1 Basic access ...... 108 41 9.2.5.3 Recovery procedures and retransmit limits ...... 108 42 9.2.5.4 Setting and resetting the NAV...... 108 43 9.2.5.5a Dual CTS protection ...... 109 44 9.2.5.5a.1 Dual CTS protection procedure ...... 109 45 46 9.2.5.5a.2 Dual CTS protection examples...... 110 47 9.2.5.7 CTS procedure ...... 111 48 9.2.6 Individually addressed MPDU transfer procedure ...... 111 49 9.2.7 Broadcast and multicast MPDU transfer procedure ...... 112 50 9.2.8 ACK procedure ...... 112 51 52 9.2.8a BlockAck procedure ...... 112 53 9.2.9 Duplicate detection and recovery ...... 112 54 9.2.10 DCF timing relations ...... 113 55 9.2.10a Signal Extension ...... 113 56 9.6 Multirate support...... 113 57 58 9.6.0a Overview...... 113 59 9.6.0b Basic MCS Set...... 115 60 9.6.0c Basic STBC MCS ...... 115 61 9.6.0d Rate selection for data and management frames ...... 115 62 9.6.0d.1 Rate selection for non-STBC Beacon and non-STBC PSMP frames.... 63 64 115 65 9.6.0d.2 Rate selection for STBC group addressed data and management frames

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 115 2 9.6.0d.3 Rate selection for other group addressed data and management frames 3 115 4 5 9.6.0d.4 Rate selection for polling frames...... 116 6 9.6.0d.5 Rate selection for +CF-Ack frames ...... 116 7 9.6.0d.6 Rate selection for other data and management frames ...... 116 8 9.6.0e Rate selection for control frames ...... 117 9 9.6.0e.1 General rules for rate selection for control frames ...... 117 10 11 9.6.0e.2 Rate selection for control frames that initiate a TXOP...... 117 12 9.6.0e.3 Rate selection for CF_End control frames...... 118 13 9.6.0e.4 Rate selection for control frames that are not control response frames. 14 119 15 9.6.0e.5 Rate selection for control response frames ...... 119 16 17 9.6.0e.5.1 Introduction...... 119 18 9.6.0e.5.2 Selection of a rate or MCS...... 119 19 9.6.0e.5.3 Control response frame MCS computation ...... 120 20 9.6.0e.5.4 Selection of an alternate rate or MCS for a control re- 21 sponse frame 121 22 23 9.6.0e.5.5 Control response frame TXVECTOR parameter restric- 24 tions 122 25 9.6.0e.6 Channel Width selection for control frames...... 122 26 9.6.0e.7 Control frame TXVECTOR parameter restrictions...... 122 27 28 9.6.1 Modulation classes...... 123 29 9.6.2 Non-HT basic rate calculation ...... 124 30 9.7 MSDU transmission restrictions...... 124 31 9.7a High Throughput Control field operation...... 125 32 9.7b Control Wrapper operation ...... 125 33 34 9.7c A-MSDU operation...... 126 35 9.7d A-MPDU operation...... 126 36 9.7d.1 A-MPDU contents ...... 126 37 9.7d.2 A-MPDU length limit rules ...... 126 38 9.7d.3 Minimum MPDU Start Spacing ...... 127 39 40 9.7d.4 A-MPDU aggregation of group addressed data frames...... 127 41 9.7d.5 Transport of A-MPDU by the PHY data service...... 127 42 9.7e PPDU Duration Constraint ...... 127 43 9.7f LDPC Operation ...... 128 44 9.7g STBC Operation ...... 128 45 46 9.7h Short GI Operation...... 128 47 9.7i Greenfield operation ...... 128 48 9.9 HCF...... 129 49 9.9.1 HCF contention-based channel access (EDCA) ...... 129 50 9.9.1.2 EDCA TXOPs...... 129 51 52 9.9.1.4 Multiple frame transmission in an EDCA TXOP...... 129 53 9.9.1.5 EDCA Backoff procedure...... 130 54 9.9.1.6 Retransmit procedures ...... 132 55 9.9.1.7 Truncation of TXOP ...... 133 56 9.9.2 HCCA ...... 134 57 58 9.9.2.1 HCCA procedure ...... 134 59 9.9.2.1.3 Recovery from the absence of an expected reception.... 60 134 61 9.9.2.2 TXOP structure and timing...... 134 62 9.9.2.3 HCCA transfer rules ...... 134 63 64 9.10 Block Acknowledgment (Block Ack)...... 135 65 9.10.1 Introduction...... 135

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 9.10.2 Setup and modification of the Block Ack parameters ...... 135 2 9.10.3 Data and acknowledgment transfer using immediate Block Ack policy and delayed 3 Block Ack policy136 4 5 9.10.4 Receive buffer operation...... 139 6 9.10.6 Selection of BlockAck and BlockAckReq variants...... 139 7 9.10.7 HT-immediate Block Ack extensions...... 139 8 9.10.7.1 Introduction to HT-immediate Block Ack extensions...... 139 9 9.10.7.2 HT-immediate Block Ack architecture...... 139 10 11 9.10.7.3 Scoreboard Context Control during full state operation...... 141 12 9.10.7.4 Scoreboard Context Control during partial state operation ...... 141 13 9.10.7.5 Generation and transmission of BlockAck by an HT STA ...... 142 14 9.10.7.6 Receive Reordering Buffer Control operation...... 143 15 9.10.7.6.1 General...... 143 16 17 9.10.7.6.2 Operation for each received data MPDU...... 144 18 9.10.7.6.3 Operation for each received BlockAckReq ...... 144 19 9.10.7.7 Originator’s behavior...... 145 20 9.10.7.8 Maintaining BlockAck state at the originator...... 146 21 9.10.7.9 Originator’s support of recipient’s partial state ...... 146 22 23 9.10.8 HT-delayed Block Ack extensions ...... 146 24 9.10.8.1 Introduction to HT-delayed Block Ack extensions ...... 146 25 9.10.8.2 HT-delayed Block Ack negotiation ...... 146 26 9.10.8.3 Operation of HT-delayed Block Ack...... 146 27 28 9.10.9 Protected Block Ack Agreement ...... 147 29 9.12 Frame exchange sequences...... 147 30 9.13 Protection mechanisms for non-ERP receivers ...... 148 31 9.13.1 Introduction...... 148 32 9.13.2 Protection mechanism for non-ERP receivers ...... 148 33 34 9.13.3 Protection mechanisms for transmissions of HT PPDUs ...... 148 35 9.13.3.1 General...... 148 36 9.13.3.2 Protection rules for HT STA operating a direct link ...... 149 37 9.13.3.3 RIFS protection...... 150 38 9.13.3.4 Use of OBSS Non-HT STAs Present field ...... 151 39 40 9.13.4 L_LENGTH and L_DATARATE parameter values for HT-mixed format PPDUs . 41 151 42 9.13.5 L-SIG TXOP protection...... 153 43 9.13.5.1 General rules...... 153 44 9.13.5.2 L-SIG TXOP protection rules at the TXOP holder ...... 154 45 46 9.13.5.3 L-SIG TXOP protection rules at the TXOP responder...... 155 47 9.13.5.4 L-SIG TXOP protection NAV update rule ...... 156 48 9.15 Reverse Direction (RD) protocol ...... 156 49 9.15.1 The RD exchange sequence...... 156 50 9.15.2 Support for RD...... 156 51 52 9.15.3 Rules for the RD initiator...... 157 53 9.15.4 Rules for the RD responder ...... 158 54 9.16 PSMP Operation ...... 159 55 9.16.1 Frame transmission mechanism during PSMP ...... 159 56 9.16.1.1 PSMP frame transmission (PSMP-DTT and PSMP-UTT)...... 159 57 58 9.16.1.2 PSMP Down link transmission (PSMP-DTT)...... 160 59 9.16.1.3 PSMP Up link transmission (PSMP-UTT)...... 160 60 9.16.1.4 PSMP burst ...... 162 61 9.16.1.5 Resource allocation within a PSMP Burst...... 162 62 9.16.1.6 PSMP-UTT retransmission...... 164 63 64 9.16.1.7 PSMP Acknowledgement rules ...... 164 65 9.16.1.8 PSMP group addressed transmission rules ...... 166

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 9.16.1.8.1 Rules at the AP ...... 166 2 9.16.1.8.2 Rules at the STA...... 166 3 9.16.2 Scheduled PSMP...... 166 4 5 9.16.3 Unscheduled PSMP ...... 166 6 9.17 Sounding PPDUs ...... 167 7 9.18 Link adaptation ...... 168 8 9.18.1 Introduction...... 168 9 9.18.2 Link adaptation using the HT Control field...... 168 10 11 9.19 Transmit beamforming ...... 170 12 9.19.1 General...... 170 13 9.19.2 Transmit beamforming with implicit feedback ...... 171 14 9.19.2.1 General...... 171 15 9.19.2.2 Unidirectional implicit transmit beamforming ...... 172 16 17 9.19.2.3 Bidirectional implicit transmit beamforming ...... 173 18 9.19.2.4 Calibration ...... 174 19 9.19.2.4.1 Introduction...... 174 20 9.19.2.4.2 Calibration Capabilities ...... 174 21 22 9.19.2.4.3 Sounding exchange for calibration ...... 175 23 9.19.2.4.4 CSI reporting for calibration...... 178 24 9.19.3 Explicit feedback beamforming...... 179 25 9.20 Antenna selection...... 182 26 9.20.1 Introduction...... 182 27 28 9.20.2 Procedure ...... 182 29 9.21 Null Data Packet (NDP) sounding...... 186 30 9.21.1 NDP Rules ...... 186 31 9.21.2 Transmission of an NDP...... 187 32 9.21.3 Determination of NDP destination ...... 188 33 34 9.21.4 Determination of NDP source...... 188 35 36 10. Layer management...... 189 37 38 10.3 MLME SAP interface ...... 189 39 40 10.3.2 Scan...... 189 41 10.3.2.2 MLME-SCAN.confirm...... 189 42 10.3.2.2.2 Semantics of the service primitive...... 189 43 10.3.3 Synchronization ...... 191 44 10.3.3.1 MLME-JOIN.request...... 191 45 46 10.3.3.1.2 Semantics of the service primitive...... 191 47 10.3.3.1.4 Effect of receipt ...... 191 48 10.3.6 Associate...... 192 49 10.3.6.1 MLME-ASSOCIATE.request...... 192 50 10.3.6.1.2 Semantics of the service primitive...... 192 51 52 10.3.6.2 MLME-ASSOCIATE.confirm ...... 192 53 10.3.6.2.2 Semantics of the service primitive...... 192 54 10.3.6.3 MLME-ASSOCIATE.indication ...... 193 55 10.3.6.3.2 Semantics of the service primitive...... 193 56 10.3.6.4 MLME-ASSOCIATE.response ...... 194 57 58 10.3.6.4.2 Semantics of the service primitive...... 194 59 10.3.7 Reassociate...... 195 60 10.3.7.1 MLME-REASSOCIATE.request ...... 195 61 10.3.7.1.2 Semantics of the service primitive...... 195 62 10.3.7.2 MLME-REASSOCIATE.confirm ...... 196 63 64 10.3.7.2.2 Semantics of the service primitive...... 196 65 10.3.7.3 MLME-REASSOCIATE.indication...... 197

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 10.3.7.3.2 Semantics of the service primitive...... 197 2 10.3.7.4 MLME-REASSOCIATE.response...... 198 3 10.3.7.4.2 Semantics of the service primitive...... 198 4 5 10.3.10 Start...... 199 6 10.3.10.1 MLME-START.request...... 199 7 10.3.10.1.2 Semantics of the service primitive...... 199 8 10.3.10.1.4 Effect of receipt ...... 201 9 10.3.15 Channel switch...... 201 10 11 10.3.15.1 MLME-CHANNELSWITCH.request ...... 201 12 10.3.15.1.2 Semantics of the service primitive...... 201 13 10.3.15.3 MLME-CHANNELSWITCH.indication...... 202 14 10.3.15.3.2 Semantics of the service primitive...... 202 15 10.3.15.4 MLME-CHANNELSWITCH.response...... 202 16 17 10.3.15.4.2 Semantics of the service primitive...... 202 18 10.3.24 TS management interface ...... 203 19 10.3.24.5 MLME-DELTS.request ...... 203 20 10.3.24.5.2 Semantics of the service primitive...... 203 21 22 10.3.24.7 MLME-DELTS.indication...... 203 23 10.3.24.7.2 Semantics of the service primitive...... 203 24 10.3.25 Management of direct links ...... 204 25 10.3.25.2 MLME-DLS.confirm...... 204 26 10.3.25.2.2 Semantics of the service primitive...... 204 27 28 10.3.25.3 MLME-DLS.indication...... 204 29 10.3.25.3.2 Semantics of the service primitive...... 204 30 10.4 PLME SAP interface ...... 205 31 10.4.3 PLME-CHARACTERISTICS.confirm ...... 205 32 10.4.3.2 Semantics of the service primitive...... 205 33 34 10.4.6 PLME-TXTIME.request...... 207 35 10.4.6.1 Function ...... 207 36 10.4.6.2 Semantics of the service primitive...... 207 37 10.4.6.3 When generated ...... 207 38 39 40 11. MLME ...... 208 41 42 11.1 Synchronization ...... 208 43 11.1.2 Maintaining synchronization ...... 208 44 11.1.2.1 Beacon generation in infrastructure networks ...... 208 45 46 11.1.3 Acquiring synchronization, scanning ...... 208 47 11.1.3.4 Synchronizing with a BSS ...... 208 48 11.1.4 Adjusting STA timers ...... 209 49 11.1.6 Supported Rates and Extended Supported Rates advertisement ...... 209 50 11.2 Power management...... 210 51 52 11.2.1 Power management in an infrastructure network ...... 210 53 11.2.1.1 STA Power Management modes ...... 211 54 11.2.1.2 AP TIM transmissions ...... 211 55 11.2.1.3 TIM types...... 211 56 11.2.1.4 Power management with APSD ...... 211 57 58 11.2.1.5 AP operation during the CP...... 212 59 11.2.1.6 AP operation during the CFP...... 214 60 11.2.1.7 Receive operation for STAs in PS mode during the CP...... 215 61 11.2.1.8 Receive operation for STAs in PS mode during the CFP...... 216 62 11.2.1.9 Receive operation for non-AP STAs using APSD ...... 216 63 64 11.2.1.12 PSMP Power management...... 216 65 11.2.2 Power management in an IBSS ...... 217

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 11.2.2.1 Basic approach...... 217 2 11.2.2.3 STA power state transitions...... 218 3 11.2.2.4 ATIM and frame transmission...... 218 4 5 11.2.3 SM Power Save...... 219 6 11.3 STA Authentication and Association ...... 220 7 11.3.2 Association, reassociation, and disassociation ...... 220 8 11.3.2.2 AP association procedures ...... 220 9 11.3.2.4 AP reassociation procedures...... 220 10 11 11.4 TS operation...... 221 12 11.4.4b PSMP management...... 221 13 11.4.7 TS deletion...... 222 14 11.5 Block Ack operation ...... 222 15 11.5.1 Setup and modification of the Block Ack parameters ...... 222 16 17 11.5.1.1 Procedure at the originator...... 222 18 11.5.1.3 Procedure common to both originator and recipient ...... 222 19 11.6 Higher layer timer synchronization ...... 222 20 11.6.2 Procedure at the STA...... 222 21 22 11.7 DLS operation...... 223 23 11.7.1 DLS procedures ...... 223 24 11.7.1.2 Setup procedure at the AP ...... 223 25 11.7.2 Data transfer after setup...... 224 26 11.9 DFS procedures...... 224 27 28 11.9.2 Quieting channels for testing ...... 224 29 11.9.6 Requesting and reporting of measurements...... 224 30 11.9.7 Selecting and advertising a new channel ...... 225 31 11.9.7.2 Selecting and advertising a new channel in an IBSS...... 225 32 11.9.7.3 HT-greenfield transmissions in regulatory classes with a Behavior 33 34 Limits set of 16 225 35 11.14 20/40 MHz BSS Operation...... 226 36 11.14.1 Rules for operation in 20/40 MHz BSS ...... 226 37 11.14.2 Basic 20/40 MHz BSS functionality...... 226 38 11.14.3 Channel selection methods for 20/40 MHz Operation ...... 226 39 40 11.14.3.1 General...... 226 41 11.14.3.2 Scanning requirements for a 20/40 MHz BSS...... 227 42 11.14.3.3 Channel management at the AP and in an IBSS ...... 228 43 11.14.4 40 MHz PPDU transmission restrictions...... 230 44 11.14.4.1 Fields used to determine 40 MHz PPDU transmission restrictions. 230 45 46 11.14.4.2 Infrastructure non-AP STA restrictions...... 231 47 11.14.4.3 AP restrictions...... 232 48 11.14.4.4 Restrictions on non-AP STAs that are not a member of an infrastructure 49 BSS 233 50 11.14.5 Scanning requirements for 40 MHz capable STA ...... 233 51 52 11.14.6 Exemption from OBSS Scanning ...... 234 53 11.14.7 Communicating 20/40 BSS Coexistence information...... 235 54 11.14.8 Support of DSSS/CCK in 40 MHz ...... 235 55 11.14.9 STA CCA sensing in a 20/40 MHz BSS ...... 235 56 11.14.10 NAV assertion in 20/40 MHz BSS...... 236 57 58 11.14.11 Signaling 40 MHz intolerance ...... 236 59 11.14.12 Switching between 40 MHz and 20 MHz ...... 236 60 11.15 Phased Coexistence Operation (PCO) ...... 238 61 11.15.1 General description of PCO...... 238 62 11.15.2 Operation at a PCO active AP ...... 239 63 64 11.15.3 Operation at a PCO active non-AP STA ...... 241 65 11.16 20/40 BSS Coexistence Management frame usage ...... 241

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 11.17 RSNA A-MSDU procedures ...... 242 2 11.18 Public Action frame addressing...... 242 3 4 5 12. PHY service specification...... 244 6 7 12.3 Detailed PHY service specifications...... 244 8 12.3.4 Basic service and options...... 244 9 12.3.4.2 PHY-SAP sublayer-to-sublayer service primitives ...... 244 10 11 12.3.4.3 PHY-SAP service primitives parameters...... 244 12 12.3.4.4 Vector descriptions ...... 244 13 12.3.5 PHY-SAP detailed service specification ...... 245 14 12.3.5.4 PHY-TXSTART.request...... 245 15 12.3.5.4.1 Function ...... 245 16 17 12.3.5.4.2 Semantics of the service primitive...... 245 18 12.3.5.4.3 When generated ...... 245 19 12.3.5.6 PHY-TXEND.request...... 246 20 12.3.5.6.1 Function ...... 246 21 12.3.5.6.2 When generated ...... 246 22 23 12.3.5.7 PHY-TXEND.confirm...... 246 24 12.3.5.7.3 When generated ...... 246 25 12.3.5.10 PHY-CCA.indication...... 246 26 12.3.5.10.2 Semantics of the service primitive...... 246 27 28 12.3.5.10.3 When generated ...... 246 29 12.3.5.12 PHY-RXEND.indication ...... 247 30 12.3.5.12.1 Function ...... 247 31 12.3.5.12.2 Semantics of the service primitive...... 247 32 12.3.5.13 PHY-CONFIG.request...... 247 33 34 12.3.5.13.1 Function ...... 247 35 12.3.5.13.2 Semantics of the service primitive...... 247 36 12.3.5.13.3 When generated ...... 248 37 12.3.5.13.4 Effect of receipt ...... 248 38 12.3.5.14 PHY-CONFIG.confirm...... 248 39 40 12.3.5.14.1 Function ...... 248 41 12.3.5.14.2 Semantics of the service primitive...... 248 42 12.3.5.14.3 When generated ...... 248 43 12.3.5.14.4 Effect of receipt ...... 248 44 45 46 20. High Throughput (HT) PHY specification ...... 249 47 48 20.1 Introduction...... 249 49 20.1.1 Introduction to the HT PHY ...... 249 50 20.1.2 Scope...... 249 51 52 20.1.3 HT PHY functions ...... 249 53 20.1.3.1 HT PLCP sublayer...... 250 54 20.1.3.2 HT PMD sublayer...... 250 55 20.1.3.3 PHY management entity (PLME)...... 250 56 20.1.3.4 Service specification method ...... 250 57 58 20.1.4 PPDU Formats ...... 250 59 20.2 HT PHY service interface...... 251 60 20.2.1 Introduction...... 251 61 20.2.2 TXVECTOR and RXVECTOR parameters ...... 251 62 20.2.3 Effect of CH_BANDWIDTH, CH_OFFSET and MCS parameters on PPDU format 63 64 258 65 20.2.4 Support for NON_HT formats...... 259

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 20.3 HT PLCP sublayer ...... 259 2 20.3.1 Introduction...... 259 3 20.3.2 PLCP frame format...... 261 4 5 20.3.3 Transmitter block diagram...... 263 6 20.3.4 Overview of the PPDU encoding process...... 265 7 20.3.5 Modulation and Coding Scheme (MCS) ...... 268 8 20.3.6 Timing related parameters ...... 269 9 20.3.7 Mathematical description of signals ...... 271 10 11 20.3.8 Transmission in the upper/lower 20 MHz of a 40 MHz channel...... 273 12 20.3.9 HT preamble ...... 274 13 20.3.9.1 Introduction...... 274 14 20.3.9.2 HT-mixed format preamble ...... 275 15 20.3.9.3 Non-HT portion of the HT-mixed format preamble...... 275 16 17 20.3.9.3.1 Introduction...... 275 18 20.3.9.3.2 Cyclic shift definition ...... 275 19 20.3.9.3.3 Non-HT Short Training field (L-STF)...... 275 20 20.3.9.3.4 Non-HT Long Training field ...... 276 21 22 20.3.9.3.5 The Non-HT SIGNAL field...... 277 23 20.3.9.4 The HT portion of the HT-mixed format preamble...... 278 24 20.3.9.4.1 Introduction...... 278 25 20.3.9.4.2 Cyclic shift definition ...... 279 26 20.3.9.4.3 The HT SIGNAL field...... 279 27 28 20.3.9.4.4 CRC calculation for the HT SIGNAL field...... 282 29 20.3.9.4.5 The HT short training field ...... 283 30 20.3.9.4.6 The HT long training field...... 284 31 20.3.9.5 HT-greenfield format preamble ...... 288 32 20.3.9.5.1 Cyclic shift definition for HT-greenfield format pream- 33 34 ble 288 35 20.3.9.5.2 HT-greenfield format Short Training field (HT-GF- 36 STF) 289 37 20.3.9.5.3 HT-greenfield format SIGNAL field...... 289 38 20.3.9.5.4 HT-greenfield format Long Training field ...... 291 39 40 20.3.10 Transmission of NON_HT format PPDUs with more than one antenna...... 291 41 20.3.11 The Data field ...... 291 42 20.3.11.1 The SERVICE field ...... 292 43 20.3.11.2 Scrambler...... 292 44 20.3.11.3 Coding...... 292 45 46 20.3.11.4 Encoder parsing operation for two BCC FEC encoders ...... 292 47 20.3.11.5 Binary convolutional coding and puncturing...... 293 48 20.3.11.6 Low density parity check (LDPC) codes...... 293 49 20.3.11.6.1 Introduction...... 293 50 20.3.11.6.2 LDPC coding rates and codeword block lengths..... 293 51 52 20.3.11.6.3 LDPC encoder...... 294 53 20.3.11.6.4 Parity check matrices...... 294 54 20.3.11.6.5 LDPC PPDU encoding process ...... 295 55 20.3.11.6.6 LDPC parser ...... 297 56 20.3.11.7 Data interleaver...... 298 57 58 20.3.11.7.1 Overview...... 298 59 20.3.11.7.2 Stream parser ...... 298 60 20.3.11.7.3 Frequency interleaver ...... 299 61 20.3.11.8 Constellation mapping ...... 300 62 20.3.11.8.1 Space-Time Block Coding (STBC) ...... 300 63 64 20.3.11.9 Pilot subcarriers ...... 301 65 20.3.11.10 OFDM modulation...... 302

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 20.3.11.10.1 Spatial mapping ...... 303 2 20.3.11.10.2 Transmission in 20 MHz HT format...... 306 3 20.3.11.10.3 Transmission in 40 MHz HT Format...... 307 4 5 20.3.11.10.4 Transmission in MCS 32 format...... 307 6 20.3.11.10.5 Transmission with a short guard interval...... 308 7 20.3.11.11 Non-HT duplicate transmission ...... 308 8 20.3.12 Beamforming ...... 309 9 20.3.12.1 Implicit feedback beamforming...... 310 10 11 20.3.12.2 Explicit feedback beamforming...... 312 12 20.3.12.2.1 CSI Matrices feedback...... 312 13 20.3.12.2.2 CSI Matrices feedback decoding procedure ...... 312 14 20.3.12.2.3 Example of CSI Matrices feedback encoding...... 313 15 20.3.12.2.4 Non-compressed beamforming matrix feedback..... 314 16 17 20.3.12.2.5 Compressed beamforming matrix feedback ...... 314 18 20.3.13 HT Preamble format for sounding PPDUs ...... 316 19 20.3.13.1 Sounding with a Null Data Packet...... 317 20 20.3.13.2 Sounding PPDU for calibration ...... 317 21 22 20.3.13.3 Sounding PPDU for channel quality assessment...... 318 23 20.3.14 Regulatory requirements...... 319 24 20.3.15 Channel numbering and channelization...... 319 25 20.3.15.1 Channel allocation in the 2.4 GHz Band ...... 319 26 20.3.15.2 Channel allocation in the 5 GHz band...... 319 27 28 20.3.15.3 40 MHz channelization...... 320 29 20.3.16 Transmit and receive in-band and out-of-band spurious transmissions ...... 320 30 20.3.17 Transmitter RF delay ...... 320 31 20.3.18 Slot time...... 320 32 20.3.19 Transmit and receive port impedance...... 320 33 34 20.3.20 Transmit and receive operating temperature range...... 320 35 20.3.21 PMD transmit specification ...... 320 36 20.3.21.1 Transmit spectrum mask...... 320 37 20.3.21.2 Spectral flatness ...... 321 38 20.3.21.3 Transmit power...... 322 39 40 20.3.21.4 Transmit center frequency tolerance...... 322 41 20.3.21.5 Packet alignment...... 322 42 20.3.21.6 Symbol clock frequency tolerance...... 323 43 20.3.21.7 Modulation accuracy...... 323 44 20.3.21.7.1 Introduction to Modulation accuracy tests...... 323 45 46 20.3.21.7.2 Transmit center frequency leakage...... 323 47 20.3.21.7.3 Transmitter constellation error...... 323 48 20.3.21.7.4 Transmitter modulation accuracy (EVM) test ...... 324 49 20.3.22 HT PMD receiver specification ...... 325 50 20.3.22.1 Receiver minimum input sensitivity...... 325 51 52 20.3.22.2 Adjacent channel rejection...... 325 53 20.3.22.3 Non-adjacent channel rejection ...... 326 54 20.3.22.4 Receiver maximum input level...... 326 55 20.3.22.5 Clear Channel Assessment (CCA) sensitivity ...... 326 56 20.3.22.5.1 Clear channel assessment (CCA) sensitivity in 20 MHz 57 58 326 59 20.3.22.5.2 Clear channel assessment (CCA) sensitivity in 40 MHz 60 326 61 20.3.22.6 Received channel power indicator (RCPI) measurement...... 327 62 20.3.22.7 Reduced interframe Space (RIFS) ...... 328 63 64 20.3.23 PLCP transmit procedure...... 328 65 20.3.24 PLCP receive procedure ...... 331

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 20.4 HT PLME ...... 335 2 20.4.1 PLME_SAP sublayer management primitives ...... 335 3 20.4.2 PHY Management Information Base...... 336 4 5 20.4.3 TXTIME calculation...... 340 6 20.4.4 PHY characteristics...... 342 7 20.5 HT PMD sublayer...... 343 8 20.5.1 Scope and field of application ...... 343 9 20.5.2 Overview of service ...... 344 10 11 20.5.3 Overview of interactions...... 344 12 20.5.4 Basic service and options...... 344 13 20.5.4.1 Status of service primitives...... 344 14 20.5.4.2 PMD_SAP peer-to-peer service primitives ...... 344 15 20.5.4.3 PMD_SAP sublayer-to-sublayer service primitives...... 344 16 17 20.5.4.4 PMD_SAP service primitive parameters...... 344 18 20.5.5 PMD_SAP detailed service specification ...... 344 19 20.5.5.1 Introduction to PMD_SAP service specification...... 344 20 20.5.5.2 PMD_DATA.request ...... 344 21 22 20.5.5.2.1 Function ...... 344 23 20.5.5.2.2 Semantics of the service primitive...... 345 24 20.5.5.2.3 When generated ...... 345 25 20.5.5.2.4 Effect of receipt ...... 345 26 20.5.5.3 PMD_DATA.indication...... 345 27 28 20.5.5.3.1 Function ...... 345 29 20.5.5.3.2 Semantics of the service primitive...... 345 30 20.5.5.3.3 When generated ...... 345 31 20.5.5.3.4 Effect of receipt ...... 347 32 20.5.5.4 PMD_TXSTART.request ...... 347 33 34 20.5.5.4.1 Function ...... 347 35 20.5.5.4.2 Semantics of the service primitive...... 347 36 20.5.5.4.3 When generated ...... 347 37 20.5.5.4.4 Effect of receipt ...... 347 38 20.5.5.5 PMD_TXEND.request...... 347 39 40 20.5.5.5.1 Function ...... 347 41 20.5.5.5.2 Semantics of the service primitive...... 347 42 20.5.5.5.3 When generated ...... 347 43 20.5.5.5.4 Effect of receipt ...... 347 44 20.5.5.6 PMD_TXEND.confirm...... 347 45 46 20.5.5.6.1 Function ...... 347 47 20.5.5.6.2 Semantics of the service primitive...... 347 48 20.5.5.6.3 When generated ...... 348 49 20.5.5.6.4 Effect of receipt ...... 348 50 20.5.5.7 PMD_TXPWRLVL.request ...... 348 51 52 20.5.5.7.1 Function ...... 348 53 20.5.5.7.2 Semantics of the service primitive...... 348 54 20.5.5.7.3 When generated ...... 348 55 20.5.5.7.4 Effect of receipt ...... 348 56 20.5.5.8 PMD_RSSI.indication ...... 348 57 58 20.5.5.8.1 Function ...... 348 59 20.5.5.8.2 Semantics of the service primitive...... 348 60 20.5.5.8.3 When generated ...... 348 61 20.5.5.8.4 Effect of receipt ...... 349 62 20.5.5.9 PMD_RCPI.indication...... 349 63 64 20.5.5.9.1 Function ...... 349 65 20.5.5.9.2 Semantics of the service primitive...... 349

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 20.5.5.9.3 When generated ...... 349 2 20.5.5.9.4 Effect of receipt ...... 349 3 20.5.5.10 PMD_TX_PARAMETERS.request ...... 349 4 5 20.5.5.10.1 Function ...... 349 6 20.5.5.10.2 Semantics of the service primitive...... 349 7 20.5.5.10.3 When generated ...... 349 8 20.5.5.10.4 Effect of receipt ...... 349 9 20.5.5.11 PMD_CBW_OFFSET.indication ...... 350 10 11 20.5.5.11.1 Function ...... 350 12 20.5.5.11.2 Semantics of the service primitive...... 350 13 20.5.5.11.3 When generated ...... 350 14 20.5.5.11.4 Effect of receipt ...... 350 15 20.5.5.12 PMD_CHAN_MAT.indication...... 350 16 17 20.5.5.12.1 Function ...... 350 18 20.5.5.12.2 Semantics of the service primitive...... 350 19 20.5.5.12.3 When generated ...... 350 20 20.5.5.12.4 Effect of receipt ...... 350 21 22 20.5.5.13 PMD_FORMAT.indication ...... 350 23 20.5.5.13.1 Function ...... 350 24 20.5.5.13.2 Semantics of the service primitive...... 351 25 20.5.5.13.3 When generated ...... 351 26 20.5.5.13.4 Effect of receipt ...... 351 27 28 20.6 Parameters for HT Modulation and Coding Schemes (MCS) ...... 351 29 30 Annex A (normative) PICS...... 362 31 A.4 PICS proforma–IEEE Std 802.11-2007...... 362 32 A.4.3 IUT configuration ...... 362 33 34 A.4.4 MAC protocol...... 362 35 A.4.4.1 MAC protocol capabilities...... 362 36 A.4.4.3 Frame exchange sequences...... 363 37 A.4.4.4 MAC addressing functions ...... 363 38 A.4.14 QoS base functionality...... 364 39 40 A.4.16 QoS hybrid coordination function (HCF) controlled channel access (HCCA) ... 365 41 A.4.20 High Throughput (HT) features...... 365 42 A.4.20.1 HT MAC features ...... 365 43 A.4.20.2 HT PHY features ...... 369 44 45 46 Annex C (informative) Formal description of a subset of MAC operation...... 377 47 C.3 State machines for MAC stations ...... 377 48 49 Annex D (normative) ASN.1 encoding of the MAC and PHY MIB...... 378 50 51 52 Annex G (informative) An example Examples of encoding a frame for the OFDM PHYs...... 434 53 G.1 Example 1 - BCC encoding ...... 434 54 G.1.1 Introduction...... 434 55 G.1.2 The message for the BCC example...... 435 56 G.1.5 Generating the DATA bits for the BCC example...... 436 57 58 G.1.5.1 Delineating, SERVICE field prepending, and zero padding ...... 436 59 G.1.5.2 Scrambling the BCC example...... 439 60 G.1.6 Generating the first DATA symbol for the BCC example ...... 441 61 G.1.6.1 Coding the DATA bits...... 441 62 G.1.8 The entire packet for the BCC example...... 443 63 64 G.2 Generating encoded DATA bits — LDPC example 1...... 453 65 G.2.1 The message for LDPC example 1 ...... 453

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 G.2.2 Prepending the SERVICE field for LDPC example 1...... 453 2 G.2.3 Scrambling LDPC example 1 ...... 453 3 G.2.4 Inserting the shortening bits for LDPC example 1 ...... 457 4 5 G.2.5 Encoding the data for LDPC example 1 ...... 459 6 G.2.6 Removing the shortening bits and puncturing for LDPC example 1...... 462 7 G.3 Generating encoded DATA bits — LDPC example 2...... 465 8 G.3.1 The message for LDPC example 2 ...... 465 9 G.3.2 Prepending the SERVICE field for LDPC example 2...... 465 10 11 G.3.3 Scrambling LDPC example 2 ...... 466 12 G.3.4 Inserting the shortening bits for LDPC example 2 ...... 470 13 G.3.5 Encoding the data for LDPC example 2 ...... 472 14 G.3.6 Removing the shortening bits and repetition for LDPC example 2...... 475 15 16 17 Annex I (normative) Regulatory Classes...... 480 18 I.1 External regulatory references ...... 480 19 20 Annex J (normative) Country information element and regulatory classes ...... 482 21 J.1 Country information and regulatory classes ...... 482 22 23 24 Annex P (informative) Bibliography ...... 486 25 P.1 General...... 486 26 27 Annex Q (normative) ASN.1 encoding of the RRM MIB...... 488 28 29 30 Annex R (normative) HT LDPC matrix definitions ...... 512 31 32 Annex S (informative) Frame exchange sequences...... 516 33 34 35 Annex T (informative) Additional high throughput information ...... 527 36 T.1 Waveform generator tool ...... 527 37 T.2 A-MPDU de-aggregation...... 527 38 T.3 Example of an RD exchange sequence...... 529 39 T.4 Illustration of determination of NDP addresses...... 530 40 41 T.5 20/40 MHz BSS establishment and maintenance ...... 531 42 T.5.1 Signaling 20/40 MHz BSS capability and operation...... 531 43 T.5.2 Establishing a 20/40 MHz BSS ...... 531 44 T.5.3 Monitoring channels for other BSS operation ...... 532 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Tables 2 3 4 Table 7-1—Valid type and subtype combinations ...... 13 5 Table 7-4—QoS Control Ffield ...... 16 6 Table 7-6—Ack Policy subfield in QoS Control field of QoS data frames ...... 17 7 8 Table 7-6a—Link Adaptation Control subfields ...... 19 9 Table 7-6c—The ASEL Command and ASEL Data subfields...... 20 10 Table 7-6b—Subfields of the MAI field...... 20 11 Table 7-6d—Calibration Control subfields ...... 21 12 Table 7-6g—RDG/More PPDU values ...... 22 13 14 Table 7-6e—CSI/Steering values ...... 22 15 Table 7-6f—AC Constraint values ...... 22 16 Table 7-6h—BAR Ack Policy subfield ...... 30 17 Table 7-6i—BlockAckReq frame variant encoding ...... 30 18 Table 7-6j—BA Ack Policy subfield...... 33 19 20 Table 7-6k—BlockAck frame variant encoding...... 33 21 Table 7-7—Address field contents ...... 37 22 Table 7-8—Beacon frame body...... 40 23 Table 7-8—Beacon frame body...... 40 24 25 Table 7-10—Association Request frame body...... 41 26 Table 7-11—Association Response frame body ...... 41 27 Table 7-12—Reassociation Request frame format...... 42 28 Table 7-13—Reassociation Response frame body ...... 42 29 Table 7-14—Probe Request frame body ...... 43 30 31 Table 7-15—Probe Response frame body ...... 43 32 Table 7-22—Reason codes ...... 44 33 Table 7-23—Status codes ...... 44 34 Table 7-19a—Action No Ack frame body ...... 44 35 36 Table 7-24—Category Values ...... 45 37 Table 7-25—Settings of the Max SP Length subfield...... 46 38 Table 7-25a—Settings of the Channel Width field ...... 47 39 Table 7-25b—Settings of the PCO Phase Control field ...... 48 40 Table 7-25c—Subfields of the MIMO Control field ...... 50 41 42 Table 7-25d—CSI Report field (20 MHz)...... 52 43 Table 7-25e—CSI Report field (40 MHz)...... 52 44 Table 7-25f—Number of matrices and carrier grouping ...... 53 45 Table 7-25h—Non-compressed Beamforming Report field (40 MHz)...... 54 46 47 Table 7-25g—Non-compressed Beamforming Report field (20 MHz)...... 54 48 Table 7-25i—Order of angles in the Compressed Beamforming Report field...... 56 49 Table 7-25j—Quantization of angles...... 56 50 Table 7-25k—Compressed Beamforming Report field (20 MHz)...... 57 51 Table 7-25l—Compressed Beamforming Report field (40 MHz)...... 57 52 53 Table 7-26—Element IDs...... 59 54 Table 7-26—Element IDs...... 59 55 Table 7-26a—BSS membership selector value encoding...... 61 56 Table 7-29j—Group Identity for a STA Statistics Request...... 62 57 58 Table 7-27a—Values of the Secondary Channel Offset field ...... 62 59 Table 7-31f—Group Identity for a STA Statistics Report...... 63 60 Table 7-31f—Group Identity for a STA Statistics Report...... 64 61 Table 7-35a—Capabilities field...... 66 62 Table 7-37—Default EDCA Parameter Set element parameter values...... 68 63 64 Table 7-38—Direction subfield encoding ...... 68 65 Table 7-41—Setting of Schedule Subfield ...... 69

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table 7-43b—Optional Subelement IDs for Neighbor Report...... 71 2 Table 7-43k—Subfields of the HT Capabilities Info field ...... 72 3 Table 7-43l—Subfields of the A-MPDU Parameters field...... 74 4 5 Table 7-43m—Transmit MCS Set...... 75 6 Table 7-43n—Subfields of the HT Extended Capabilities field...... 76 7 Table 7-43o—Subfields of the Transmit Beamforming Capabilities field...... 77 8 Table 7-43p—Subfields of the Antenna Selection Capability field ...... 80 9 Table 7-43q—HT Operation element ...... 81 10 11 Table 7-51—DLS Request frame body ...... 87 12 Table 7-52—DLS Response frame body...... 87 13 Table 7-57e—Public Action field values...... 88 14 Table 7-57e1—20/40 BSS Coexistence Management frame body ...... 88 15 Table 7-57o—SM Power Save ...... 89 16 17 Table 7-57m—HT Action field values ...... 89 18 Table 7-57n—Notify Channel Width ...... 89 19 Table 7-57p—Format of the PSMP Management Action field...... 90 20 Table 7-57q—Set PCO Phase...... 90 21 22 Table 7-57r—CSI ...... 91 23 Table 7-57s—Non-compressed Beamforming ...... 91 24 Table 7-57t—Compressed Beamforming...... 92 25 Table 7-57u—Antenna Selection Indices Feedback...... 92 26 Table 7-57v— MPDU Delimiter fields ...... 93 27 28 Table 7-57w—A-MPDU Contexts ...... 95 29 Table 7-57x—A-MPDU contents in the data enabled immediate response context ...... 96 30 Table 7-57y—A-MPDU contents in the data enabled no immediate response context ...... 97 31 Table 7-57z—A-MPDU contents in the PSMP context ...... 97 32 Table 7-57aa—A-MPDU contents MPDUs in the control response context ...... 98 33 34 Table 9-1a—Dual CTS rules ...... 109 35 Table 9-1b—CH_BANDWIDTH control frame response mapping ...... 122 36 Table 9-2—Modulation classes ...... 123 37 Table 9-2a—Non-HT reference rate...... 124 38 Table 9-6—Protection requirements for HT Protection field values non-member protection mode and non- 39 40 HT mixed mode ...... 150 41 Table 9-7—Applicable HT protection mechanisms ...... 150 42 Table 9-8—STA type requirements for transmit Beamforming with implicit feedback...... 171 43 Table 9-9—Transmit beamforming support required with implicit feedback...... 172 44 Table 9-10—Rules for beamformee immediate feedback transmission responding to non-NDP sounding180 45 46 Table 9-11—Rules for beamformee immediate feedback transmission responding to NDP sounding ...... 181 47 Table 11-1—Power Management modes ...... 211 48 Table 11-3—Encoding of ReasonCode to Reason Code field value for DELTS...... 222 49 Table 11-5a—Types of Block Ack agreement based on capabilities and ADDBA conditions ...... 223 50 Table 11-8a—A-MSDU STA Behavior for RSN associations ...... 243 51 52 Table 12-2— PHY-SAP sublayer-to-sublayer service primitives...... 244 53 Table 12-3—PHY-SAP service primitive parameters...... 244 54 Table 12-3—PHY-SAP service primitive parameters...... 244 55 Table 12-4—Vector descriptions...... 245 56 Table 20-1—TXVECTOR and RXVECTOR parameters ...... 251 57 58 Table 20-2—PPDU format as a function of CH_BANDWIDTH and CH_OFFSET parameters...... 258 59 Table 20-3—Mapping of the HT PHY parameters for NON_HT operation...... 260 60 Table 20-4—Elements of the HT PLCP packet...... 262 61 Table 20-5—Timing related constants ...... 269 62 Table 20-6—Frequently used parameters...... 270 63 64 Table 20-7—Value of tone scaling factor ...... 274 65 Table 20-8—Cyclic shift for non-HT portion of the packet...... 276

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table 20-9—Cyclic shift values of the HT portion of the packet ...... 279 2 Table 20-10—Fields of the HT SIGNAL field...... 280 3 Table 20-11—Determining the number of space time streams ...... 285 4 5 Table 20-12—Number of DLTFs required for data space-time streams...... 285 6 Table 20-13—Number of ELTFs required for extension spatial streams...... 285 7 Table 20-14—LDPC parameters ...... 294 8 Table 20-15—PPDU encoding parameters...... 296 9 Table 20-16—Number of rows and columns in the interleaver ...... 299 10 11 Table 20-17—Constellation mapper output to spatial mapper input for STBC ...... 301 12 Table 20-18—Pilot values for 20 MHz transmission ...... 302 13 Table 20-19—Pilots values for 40 MHz transmission (excluding MCS 32)...... 303 14 Table 20-20—Maximum available space-time streams ...... 319 15 Table 20-21—Allowed relative constellation error versus constellation size and coding rate...... 323 16 17 Table 20-22—Receiver minimum input level sensitivity...... 325 18 Table 20-23—HT PHY MIB attributes ...... 336 19 Table 20-24—MIMO PHY characteristics ...... 342 20 Table 20-25—PMD_SAP peer-to-peer service primitives...... 344 21 22 Table 20-26—PMD_SAP sublayer-to-sublayer service primitives...... 345 23 Table 20-27—List of parameters for the PMD primitives ...... 346 24 Table 20-28—Symbols used in MCS parameter tables...... 351 25 Table 20-29—MCS parameters for mandatory 20 MHz, NSS = 1, NES = 1 ...... 352 26 Table 20-30—MCS parameters for optional 20 MHz, N = 2, N = 1, EQM...... 352 27 SS ES 28 Table 20-31—MCS parameters for optional 20 MHz, NSS = 3, NES = 1, EQM...... 353 29 Table 20-32—MCS parameters for optional 20 MHz, NSS = 4, NES = 1, EQM...... 353 30 Table 20-33—MCS parameters for optional 40 MHz, NSS = 1, NES = 1 ...... 354 31 Table 20-34—MCS parameters for optional 40 MHz, NSS = 2, NES = 1, EQM...... 354 32 Table 20-35—MCS parameters for optional 40 MHz, N = 3, EQM ...... 355 33 SS 34 Table 20-36—MCS parameters for optional 40 MHz, NSS = 4, EQM ...... 355 35 Table 20-37—MCS parameters for optional 40 MHz MCS 32 format, NSS = 1, NES = 1 ...... 356 36 Table 20-38—MCS parameters for optional 20 MHz, NSS = 2, NES = 1, UEQM...... 356 37 Table 20-39—MCS parameters for optional 20 MHz, NSS = 3, NES = 1, UEQM ...... 357 38 Table 20-40—MCS parameters for optional 20 MHz, N = 4, N = 1, UEQM ...... 358 39 SS ES 40 Table 20-41—MCS parameters for optional 40 MHz, NSS = 2, NES = 1, UEQM...... 359 41 Table 20-42—MCS parameters for optional 40 MHz, NSS = 3, UEQM ...... 359 42 Table 20-43—MCS parameters for optional 40 MHz, NSS = 4, UEQM ...... 360 43 Table G.1—The message for the BCC example ...... 436 44 Table G.13—The DATA bits before scrambling ...... 438 45 46 Table G.16—The DATA bits after scrambling ...... 440 47 Table G.18—The BCC encoded DATA bits ...... 442 48 Table G.24—Time domain representation of the short training sequence ...... 444 49 Table G.25—Time domain representation of the long training sequence ...... 446 50 Table G.26—Time domain representation of the SIGNAL field (1 symbol) ...... 447 51 52 Table G.27—Time domain representation of the DATA field: symbol 1of 6 ...... 448 53 Table G.28—Time domain representation of the DATA field: symbol 2 of 6 ...... 449 54 Table G.29—Time domain representation of the DATA field: symbol 3 of 6 ...... 450 55 Table G.30—Time domain representation of the DATA field: symbol 4 of 6 ...... 450 56 Table G.31—Time domain representation of the DATA field: symbol 5 of 6 ...... 451 57 58 Table G.32—Time domain representation of the DATA field: symbol 6 of 6 ...... 452 59 Table G.33—The message for LDPC example 1 ...... 454 60 Table G.34—The DATA bits for LDPC example 1 before scrambling ...... 455 61 Table G.35—The DATA bits for LDPC example 1 after scrambling ...... 456 62 Table G.36—The DATA bits for LDPC example 1 after insertion of shortening bits ...... 458 63 64 Table G.37—The DATA bits for LDPC example 1 after LDPC encoding...... 460 65 Table G.38—The DATA bits after puncturing and removal of shortening bits ...... 463

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table G.39—The message for LDPC example 2 ...... 466 2 Table G.40—The DATA bits for LDPC example 2 before scrambling ...... 467 3 Table G.41—The DATA bits for LDPC example 2 after scrambling ...... 468 4 5 Table G.42—The DATA bits for LDPC example 2 after insertion of shortening bits ...... 470 6 Table G.43—The DATA bits for LDPC example 2 after LDPC encoding ...... 472 7 Table G.44—The DATA bits after removal of shortening bits and copying of repetition bits ...... 476 8 Table I.3—Behavior limits sets ...... 480 9 Table J.1—Regulatory classes in the USA...... 482 10 11 Table J.1—Regulatory classes in the USA...... 482 12 Table J.2—Regulatory classes in Europe ...... 483 13 Table J.3—Regulatory classes in Japan...... 484 14 Table J.3—Regulatory classes in Japan...... 484 15 Table R.1—Matrix prototypes for codeword block length n=648 bits, subblock size is Z = 27 bits...... 512 16 17 Table R.2—Matrix prototypes for codeword block length n=1296 bits, subblock size is Z= 54 bits...... 513 18 Table R.3—Matrix prototypes for codeword block length n=1944 bits, subblock size is Z = 81 bits...... 514 19 Table S.1—Attributes applicable to frame exchange sequence definition...... 517 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Figures 2 3 4 Figure 6-1—MAC data plane architecture ...... 11 5 Figure 7-1—MAC frame format...... 13 6 Figure 7-4c—MAI field...... 19 7 8 Figure 7-4a—HT Control field ...... 19 9 Figure 7-4b—Link Adaptation Control field...... 19 10 Figure 7-4d—ASELC subfield ...... 20 11 Figure 7-12—BlockAckReq frame...... 29 12 Figure 7-13—BAR Control field...... 29 13 14 Figure 7-13a—BAR Information field (Multi-TID BlockAckReq) ...... 31 15 Figure 7-15—BlockAck frame ...... 32 16 Figure 7-16—BA Control field...... 32 17 Figure 7-13b—Per TID Info field...... 32 18 Figure 7-16a—BA Information field (BlockAck) ...... 34 19 20 Figure 7-16b—BA Information field (Compressed BlockAck) ...... 34 21 Figure 7-16c—BA Information field (Multi-TID BlockAck) ...... 35 22 Figure 7-16d—Control Wrapper frame ...... 35 23 Figure 7-17—Data frame...... 36 24 25 Figure 7-17a—A-MSDU structure ...... 38 26 Figure 7-17b—A-MSDU subframe structure ...... 38 27 Figure 7-18—Management frame format...... 39 28 Figure 7-32—Block Ack Parameter Set fixed field...... 45 29 Figure 7-36e—SM Power Control fixed field ...... 47 30 31 Figure 7-36d—Channel Width fixed field...... 47 32 Figure 7-36g—PSMP Parameter Set fixed field...... 48 33 Figure 7-36f—PCO Phase Control fixed field ...... 48 34 Figure 7-36h—PSMP STA Info fixed field (group addressed)...... 49 35 36 Figure 7-36i—PSMP STA Info fixed field (individually addressed)...... 49 37 Figure 7-36j—MIMO Control field...... 50 38 Figure 7-36k—CSI Matrix coding...... 53 39 Figure 7-36l—V Matrix coding (Non-compressed Beamforming)...... 55 40 Figure 7-36m—First example of Compressed Beamforming Report field encoding ...... 58 41 42 Figure 7-36n—Second example of Compressed Beamforming Report field encoding ...... 58 43 Figure 7-36o—Antenna Selection Indices fixed field ...... 59 44 Figure 7-57a—Secondary Channel Offset element format ...... 61 45 Figure 7-74—RSN Capabilities field format...... 65 46 47 Figure 7-95c—BSSID Information field ...... 70 48 Figure 7-95o17—HT Capabilities element format...... 71 49 Figure 7-95o18—HT Capabilities Info field ...... 72 50 Figure 7-95o19—A-MPDU Parameters field...... 74 51 Figure 7-95o20—Supported MCS Set field ...... 75 52 53 Figure 7-95o21—HT Extended Capabilities field...... 76 54 Figure 7-95o22—Transmit Beamforming Capabilities field...... 77 55 Figure 7-95o23—Antenna Selection Capability field ...... 79 56 Figure 7-95o24—HT Operation element format ...... 81 57 58 Figure 7-95o25—20/40 MHz BSS Intolerant Channel Report element format ...... 84 59 Figure 7-95o26—Overlapping BSS Scan Parameters element format...... 84 60 Figure 7-95o27—20/40 BSS Coexistence element format...... 85 61 Figure 7-100—Channel Switch Announcement frame body format...... 86 62 Figure 7-101o—A-MPDU format ...... 93 63 64 Figure 7-101p—A-MPDU subframe format ...... 93 65 Figure 7-101q—MPDU delimiter CRC calculation ...... 94

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Figure 9-8a—Example of the Dual CTS mechanism (STBC initiator)...... 110 2 Figure 9-8b—Example of the Dual CTS mechanism (non-STBC initiator) ...... 111 3 4 Figure 9-18a—Example of TXOP truncation...... 133 5 Figure 9-22—A typical Block Ack sequence when immediate policy is used ...... 137 6 Figure 9-23—A typical BlockAck sequence when delayed policy is used...... 138 7 Figure 9-24—HT-immediate Block Ack architecture ...... 140 8 9 Figure 9-25—Basic Concept of L-SIG TXOP Protection ...... 153 10 Figure 9-26—Example of L-SIG Duration Setting ...... 154 11 Figure 9-27—Illustration of PSMP sequence with and without PSMP recovery...... 161 12 Figure 9-28—PSMP burst ...... 162 13 14 Figure 9-29—PSMP burst showing resource allocation...... 163 15 Figure 9-30—PSMP burst showing retransmission and resource allocation ...... 164 16 Figure 9-31—Example PPDU exchange for unidirectional implicit transmit beamforming ...... 172 17 Figure 9-32—Example PPDU exchange for bidirectional implicit transmit beamforming ...... 173 18 19 Figure 9-33—Calibration procedure with sounding PPDU containing an MPDU ...... 175 20 Figure 9-34—Calibration procedure with NDP ...... 177 21 Figure 9-35—Calibration procedure with NDP in the case STA B supports transmitting sounding PPDUs for 22 which only one channel dimension can be estimated (i.e., a single column of the MIMO channel matrix) .... 23 177 24 25 Figure 9-36—Transmit antenna selection...... 184 26 Figure 9-37—Receive antenna selection ...... 185 27 Figure 11-17a—Phased Coexistence Operation ...... 239 28 Figure 20-1—PPDU format...... 262 29 30 Figure 20-2—Transmitter block diagram 1 ...... 264 31 Figure 20-3—Transmitter block diagram 2 ...... 265 32 Figure 20-4—Timing boundaries for PPDU fields...... 272 33 34 Figure 20-5—Non-HT SIGNAL field ...... 277 35 Figure 20-6—Format of HT-SIG1 and HT-SIG2...... 281 36 Figure 20-7—Data tone constellations in an HT-mixed format PPDU...... 282 37 Figure 20-8—HT-SIG CRC calculation ...... 283 38 39 Figure 20-9—Generation of Data HT-LTFs...... 287 40 Figure 20-10—Generation of the Extension HT-LTFs ...... 287 41 Figure 20-11—Puncturing at rate 5/6 ...... 293 42 Figure 20-12—Examples of cyclic-permutation matrices with Z=8...... 295 43 44 Figure 20-13—LDPC PPDU encoding padding and puncturing of a single codeword ...... 297 45 Figure 20-14—The beamforming MIMO channel model (3x2 example)...... 310 46 Figure 20-15—The baseband-to-baseband channel...... 311 47 Figure 20-16—Example of an NDP used for sounding...... 317 48 49 Figure 20-17—Transmit spectral mask for 20 MHz transmission ...... 321 50 Figure 20-18—Transmit spectral mask for a 40 MHz channel ...... 321 51 Figure 20-19—Packet alignment example (HT-greenfield format packet with short GI)...... 322 52 Figure 20-20—PLCP transmit procedure (HT-mixed format PPDU)...... 329 53 54 Figure 20-21—PLCP transmit procedure (HT-greenfield format PPDU)...... 330 55 Figure 20-22—PLCP transmit state machine ...... 331 56 Figure 20-23—PLCP receive procedure for HT-mixed format PLCP format ...... 333 57 Figure 20-24—PLCP receive procedure for HT-greenfield format PLCP...... 334 58 59 Figure 20-25—PLCP receive state machine...... 335 60 Figure 20-26—PMD layer reference model ...... 343 61 Figure T.1—A-MPDU parsing ...... 528 62 Figure T.2—Example of RD exchange sequence showing response burst ...... 529 63 64 Figure T.3—Determination of NDP source and destination for unidirectional NDP sequences ...... 530 65 Figure T.4—Determination of NDP source and destination for bidirectional NDP sequence...... 531

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 2 IEEE P802.11n™/D11.0 3 4 5 6 7 8 Draft STANDARD for 9 10 Information Technology— 11 12 13 Telecommunications and information exchange 14 15 16 between systems— 17 18 19 Local and metropolitan area networks— 20 21 Specific requirements 22 23 24 25 26 27 Part 11: Wireless LAN Medium Access Control 28 29 30 (MAC) and Physical Layer (PHY) specifications 31 32 33 34 35 Amendment 5: Enhancements for Higher 36 37 38 Throughput 39 40 41 42 43 44 45 46 47 [This amendment is based on IEEE Std 802.11™-2007, as amended by IEEE Std 802.11k™-2008, IEEE Std 48 49 802.11r™-2008, IEEE Std 802.11y™-2008 and IEEE P802.11w D9.0] 50 51 52 53 NOTE—The editing instructions contained in this amendment define how to merge the material contained therein into 54 55 the existing base standard and its amendments to form the comprehensive standard. 56 57 The editing instructions are shown in bold italic. Four editing instructions are used: change, delete, insert, and replace. 58 Change is used to make corrections in existing text or tables. The editing instruction specifies the location of the change 59 and describes what is being changed by using strikethrough (to remove old material) and underscore (to add new mate- 60 rial). Delete removes existing material. Insert adds new material without disturbing the existing material. Insertions may 61 require renumbering. If so, renumbering instructions are given in the editing instruction. Replace is used to make 62 63 changes in figures or equations by removing the existing figure or equation and replacing it with a new one. Editorial 64 instructions, change markings and this NOTE will not be carried over into future editions because the changes will be 65 incorporated into the base standard.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 2. Normative references 2 3 4 Delete the normative reference “ISO/IEC 14977:1996, Information technology—Information 5 technology. Syntactic Metalanguage. Extended BNF.” 6 7 EDITORIAL NOTE—This normative reference is now moved to the Bibliography. See editing 8 instruction in Annex P. 9 10 11 12 3. Definitions 13 14 Insert the following definitions in alphabetical order into Clause 3, renumbering as necessary: 15 16 17 3.225 aggregate MAC protocol data unit (A-MPDU): A structure containing multiple MPDUs, transported 18 as a single PSDU by the PHY. 19 20 3.226 aggregate MAC service data unit (A-MSDU): A structure containing multiple MSDUs, transported 21 22 within a single (unfragmented) data MPDU. 23 24 3.227 aggregated MAC service data unit (A-MSDU) subframe: A portion of an A-MSDU containing a 25 header and associated MSDU. 26 27 28 3.228 antenna selection receiver (ASEL receiver): A STA that performs receive antenna selection. 29 30 3.229 antenna selection transmitter (ASEL transmitter): A STA that performs transmit antenna selection. 31 32 3.230 beamformee: A STA that receives a PPDU that was transmitted using a beamforming steering matrix. 33 34 35 3.231 beamformer: A STA that transmits a PPDU using a beamforming steering matrix. 36 37 3.232 beamforming : A spatial filtering mechanism used at a transmitter to improve the received signal pow- 38 er or signal-to-noise ratio at an intended receiver. Beamforming is also known as beam steering. 39 40 41 3.233 calibration initiator: A STA that initiates a calibration sequence. 42 43 3.234 calibration responder: A STA that transmits during a calibration sequence in response to a transmis- 44 sion by a calibration initiator. 45 46 47 3.235 multiple input, multiple output (MIMO): A PHY configuration in which both transmitter and receiv- 48 er use multiple antennas. 49 50 3.236 non-AP STA: A STA that is not also an AP. 51 52 53 3.237 null data packet (NDP): A PPDU that carries no Data field. 54 55 3.238 operating channel width: Indicates the channel width in which the STA is currently able to receive. 56 57 58 3.239 overlapping basic service set (OBSS): A BSS operating on the same channel as the STA’s BSS and 59 within (either partly or wholly) its basic service area (BSA). 60 61 3.240 primary channel: The common channel of operation for all STAs that are members of the BSS. 62 63 64 3.241 quadrature binary phase shift keying (QBPSK): A binary phase shift keying modulation in which 65 the binary data is mapped onto the imaginary (Q) axis.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 3.242 receive chain: The physical entity that implements any necessary signal processing to provide the re- 2 ceived signal to the digital baseband. This includes filtering, amplification, down-conversion and sampling. 3 4 5 3.243 sounding: The use of preamble training fields to measure the channel for purposes other than demod- 6 ulation of the Data portion of the PPDU containing the training fields. 7 NOTE—These uses include calculation of transmit steering, calculation of recommended MCS, and calculation of cali- 8 bration parameters. 9 10 3.244 space-time block code / spatial multiplexing (STBC/SM): A combination of space-time block cod- 11 12 ing and spatial multiplexing where one spatial stream is transmitted using space time block coding, and one 13 or two additional spatial streams are transmitted using spatial multiplexing. 14 15 3.245 space-time streams: Streams of modulation symbols created by applying a combination of spatial and 16 temporal processing to one or more spatial streams of modulation symbols. 17 18 19 3.246 spatial multiplexing (SM): A transmission technique in which data streams are transmitted on multi- 20 ple spatial channels that are provided through the use of multiple antennas at the transmitter and the receiver. 21 22 3.247 spatial stream: One of several streams of bits or modulation symbols that may be transmitted over 23 24 multiple spatial dimensions that are created by the use of multiple antennas at both ends of a communications 25 link. 26 27 3.248 transmit opportunity (TXOP) responder: A STA that transmits a frame in response to a frame re- 28 ceived from a TXOP holder during a frame exchange sequence, but that does not acquire a TXOP in the pro- 29 30 cess. 31 32 Insert the following Clause (3A) after Clause 3: 33 34 35 36 3A. Definitions specific to IEEE 802.11 37 38 The following terms and definitions are specific to terms or references in this standard and are not appropriate 39 for inclusion in The Authoritative Dictionary of IEEE Standards Terms [B11]. 40 41 42 43 44 3A.1 20 MHz BSS: a BSS in which the Secondary Channel Offset field is set to SCN. 45 46 47 3A.2 20 MHz HT: a Clause 20 transmission using FORMAT=HT_MF or HT_GF and 48 CH_BANDWIDTH=HT_CBW20 49 50 3A.3 20 MHz mask PPDU: a Clause 17 PPDU, a Clause 19 orthogonal frequency division multiplexing 51 52 (OFDM) PPDU, or a Clause 20 20 MHz HT-PPDU with the TXVECTOR parameter CH_BANDWIDTH set 53 to HT_CBW20 and the CH_OFFSET parameter set to CH_OFF_20. The PLCP protocol data unit (PPDU) is 54 transmitted using a 20 MHz transmit spectral mask defined in Clause 17, Clause 19, or Clause 20, respective- 55 ly. 56 57 58 3A.4 20 MHz PPDU: either a Clause 15 PPDU, Clause 17 PPDU, Clause 18 PPDU, Clause 19 OFDM PP- 59 DU, or a Clause 20 20 MHz HT-PPDU with the TXVECTOR parameter CH_BANDWIDTH set to 60 HT_CBW20. 61 62 3A.5 20/40 MHz BSS: a BSS in which the supported channel width of the AP or IBSS DFS owner (IDO) 63 64 STA is 20 MHz and 40 MHz (Channel Width field is set to 1) and the Secondary Channel Offset field is set 65 to a value of SCA or SCB.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 3A.6 40 MHz HT: a Clause 20 transmission using FORMAT=HT_MF or HT_GF and 2 CH_BANDWIDTH=HT_CBW40 3 4 5 3A.7 40 MHz mask PPDU: one of the following PPDUs: 1) a 40 MHz HT PPDU (TXVECTOR parameter 6 CH_BANDWIDTH set to HT_CBW40); 2) a 40 MHz non-HT duplicate PPDU (TXVECTOR parameter 7 CH_BANDWIDTH set to NON_HT_CBW40); or 3) a Clause 20 20 MHz HT-PPDU with the TXVECTOR 8 parameter CH_BANDWIDTH set to HT_CBW20 and the CH_OFFSET parameter set to either 9 CH_OFF_20U or CH_OFF_20L. The PPDU is transmitted using a 40 MHz transmit spectral mask defined 10 11 in Clause 20. 12 13 3A.8 40 MHz PPDU: a 40 MHz HT PPDU (TXVECTOR parameter CH_BANDWIDTH set to HT_CBW40) 14 or a 40 MHz non-HT duplicate PPDU (TXVECTOR parameter CH_BANDWIDTH set to 15 NON_HT_CBW40) as defined in Clause 20. 16 17 18 3A.9 basic space time block coding modulation and coding scheme (basic STBC MCS): An MCS value 19 and STBC encoder specification used in the transmission of STBC encoded control frames and STBC encod- 20 ed group addressed frames. The value is defined in 9.6.0c. 21 22 23 3A.10 BSSBasicMCSSet: The set of MCS values that must be supported by all HT STAs that are members 24 of an HT BSS. 25 26 3A.11 DSSS/CCK: a Clause 15 or Clause 18 transmission 27 28 29 3A.12 FC HT AP: an HT AP that included a value of 1 in the Supported Channel Width Set field (indicating 30 its capability to operate on a 40 MHz channel) of its most recent transmission of a frame containing an HT 31 Capabilities element. 32 NOTE—In this and related definitions, FC stands for “forty MHz capable”. 33 34 35 3A.13 FC HT AP 2G4: an HT AP 2G4 that is also an FC HT AP. 36 37 3A.14 FC HT AP 5G: an HT AP 5G that is also an FC HT AP. 38 39 3A.15 FC HT STA: an HT STA that included a value of 1 in the Supported Channel Width Set field (indi- 40 41 cating its capability to operate on a 40 MHz channel) of its most recent transmission of a frame containing an 42 HT Capabilities element. 43 44 3A.16 FC HT STA 2G4: an HT STA 2G4 that is also an FC HT STA. 45 46 47 3A.17 FC HT STA 5G: an HT STA 5G that is also an FC HT STA. 48 49 3A.18 high throughput basic service set (HT BSS): A BSS in which Beacon frames transmitted by an HT 50 STA include the HT Capabilities element. 51 52 53 3A.19 high throughput delayed (HT-delayed) block ack: A Delayed Block Ack mechanism that requires 54 the use of the compressed BlockAck frame and the NoAck ack policy setting within both BlockAckReq and 55 BlockAck frames. This Block Ack scheme is negotiated between two HT STAs that both support HT Delayed 56 Block Ack. 57 58 59 3A.20 high throughput immediate (HT-immediate) block ack: An Immediate Block Ack mechanism that 60 requires the use of the compressed BlockAck frame and an an implicit Block Ack request, and allows partial 61 state operation at the recipient. This Block Ack scheme is negotiated between two HT STAs. 62 63 64 3A.21 high throughput greenfield format (HT-greenfield format): A PPDU format of the HT PHY using 65 the HT-greenfield format preamble. This is represented at the PHY data SAP by the TXVECTOR/RXVEC-

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 TOR FORMAT parameter being set to HT_GF. 2 3 3A.22 high throughput mixed format (HT-mixed format): A PPDU format of the HT PHY using the HT- 4 5 mixed format preamble. This is represented at the PHY data SAP by the TXVECTOR/RXVECTOR FOR- 6 MAT parameter being set to HT_MF. 7 8 3A.23 high throughput physical layer protocol data unit (HT PPDU): A Clause 20 PPDU with the TX- 9 VECTOR FORMAT parameter set to HT_MF or HT_GF. 10 11 12 3A.24 HT STA 5G: an HT STA that is also a STA 5G. 13 14 3A.25 HT STA 2G4: an HT STA that is also a STA 2G4. 15 16 17 3A.26 independent basic service set dynamic frequency selection owner STA (IDO STA): a STA that is 18 the DFS Owner of an IBSS that is operating on a channel within a regulatory class that has a value of 20 or 19 40 for the entry in the column labeled "Channel Spacing (MHz)" and that has a value of 5 for the entry in the 20 column labeled "Channel Starting Frequency (GHz)" of any of the tables found in Annex J. 21 22 23 3A.27 minimum downlink transmission time to uplink transmission time spacing (minimum 24 DTT2UTT spacing): The minimum time within a PSMP sequence between the end of a STA’s PSMP-DTT 25 and the start of its PSMP-UTT. 26 27 28 3A.28 modulation and coding scheme (MCS): A specification of the HT PHY parameters that consists of 29 modulation order (BPSK, QPSK, 16-QAM, 64-QAM) and FEC coding rate (1/2, 2/3, 3/4, 5/6). 30 31 3A.29 modulation and coding scheme 32 format (MCS 32 format): A PPDU format of the HT PHY in 32 which signals in two halves of the occupied channel width contain the same information. This is the HT 33 34 PPDU format that supports the lowest rate. 35 36 3A.30 modulation and coding scheme feedback (MFB) requester: A STA that transmits a PPDU that con- 37 tains an HT Control field with the MRQ field set to 1. 38 39 40 3A.31 modulation and coding scheme feedback (MFB) responder: A STA that responds to a PPDU con- 41 taining an HT Control field in which the MRQ field is set to 1 with a PPDU containing an HT Control field 42 in which the MFB field contains an MCS index or the value 127. 43 44 3A.32 non-aggregate MAC protocol data unit frame (non-A-MPDU frame): A frame that is transmitted 45 46 in a PPDU with the TXVECTOR AGGREGATION parameter either absent or set to NOT_AGGREGATED. 47 48 3A.33 non-FC HT STA: a STA that is not an FC HT STA 49 50 3A.34 non-HT duplicate: A transmission format of the PHY that duplicates a 20 MHz non-HT transmission 51 52 in two adjacent 20 MHz channels, allowing a STA in a non-HT BSS on either channel to receive the trans- 53 mission. 54 55 3A.35 non-HT duplicate frame: A frame transmitted in a non-HT duplicate PPDU. 56 57 58 3A.36 non-HT duplicate PPDU: A PPDU transmitted by a Clause 20 PHY with the TXVECTOR FORMAT 59 parameter set to NON_HT and the CH_BANDWIDTH parameter set to NON_HT_CBW40. 60 61 3A.37 non-HT physical layer protocol data unit (non-HT PPDU): A Clause 20 PHY PPDU with the TX- 62 VECTOR FORMAT parameter set to NON_HT. 63 64 65 3A.38 non-HT SIGNAL field transmit opportunity protection (L-SIG TXOP): A protection mechanism

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 in which protection is established by the non-HT SIG Length and Rate fields indicating a duration that is long- 2 er than the duration of the packet itself. 3 4 5 3A.39 non-PCO capable 20/40 STA: an HT STA that included a value of 1 in the Supported Channel Width 6 Set field (indicating its capability to operate on a 40 MHz channel) of its most recent transmission of a frame 7 containing an HT Capabilities element and that sets the PCO field in the HT Extended Capabilities field to 8 the value 0. 9 10 11 3A.40 non-STBC frame: A frame that is transmitted in a PPDU that has the TXVECTOR STBC parameter 12 set to 0, or a frame that is received in a PPDU that has the RXVECTOR STBC parameter set to 0. 13 14 3A.41 null data packet (NDP) announcement: A PPDU that contains one or more +HTC frames that have 15 the NDP Announcement field set to 1. 16 17 18 3A.42 payload protected A-MSDU (PP A-MSDU): An A-MSDU that is CCMP protected but does not in- 19 clude the A-MSDU Present field (bit 7 of the QoS control field) in the construction of the AAD. 20 21 3A.43 phased coexistence operation (PCO): A BSS mode with alternating 20 MHz and 40 MHz phases 22 23 controlled by an AP. 24 25 3A.44 PCO active AP: an HT AP that is operating PCO. 26 27 28 3A.45 PCO active BSS: a BSS in which a PCO active AP has the PCO Active field in the HT Operation 29 element set to 1. 30 31 3A.46 PCO active non-AP STA: an HT non-AP STA that is associated with a PCO BSS and following PCO. 32 33 34 3A.47 PCO active STA: a STA that is either a PCO active AP or a PCO active non-AP STA. 35 36 3A.48 PCO capable AP: an HT AP that sets the PCO field in the HT Extended Capabilities field to the value 37 1. 38 39 40 3A.49 PCO capable non-AP STA: an HT non-AP STA that sets the PCO field in the HT Extended Capabil- 41 ities field to the value 1. 42 43 3A.50 PCO capable STA: a STA that is either a PCO capable AP or a PCO capable non-AP STA. 44 45 46 3A.51 PCO inactive BSS: a 20/40 MHz BSS in which an AP has the PCO Active field in the HT Operation 47 element set to 0. 48 49 3A.52 power save multi-poll (PSMP): A mechanism that provides a time schedule that is used by an AP and 50 its STAs to access the wireless medium. The mechanism is controlled using the PSMP Action frame. 51 52 53 3A.53 power save multi-poll burst (PSMP burst): A series of one or more PSMP sequences, separated by 54 SIFS. 55 56 3A.54 power save multi-poll downlink transmission time (PSMP-DTT): A period of time described by a 57 58 PSMP frame during which the AP transmits. 59 60 3A.55 power save multi-poll sequence (PSMP sequence): A sequence of frames where the first frame is a 61 PSMP frame that is followed by transmissions in zero or more PSMP-DTTs and then by transmissions in zero 62 or more PSMP-UTTs. The schedule of the PSMP-DTTs and PSMP-UTTs is defined in the PSMP frame. 63 64 65 3A.56 power save multi-poll session (PSMP session): A PSMP session is the periodic generation of a PSMP

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 burst aligned to its service period. 2 3 4 3A.57 power save multi-poll uplink transmission time (PSMP-UTT): A period of time described by a 5 PSMP frame during which a non-AP STA may transmit. 6 7 8 3A.58 power save multi-poll uplink transmission time spacing (PSMP-UTT spacing (PUS)): The period 9 of time between the end of one PSMP-UTT and the start of the following PSMP-UTT within the same PSMP 10 sequence. 11 12 13 3A.59 reverse direction (RD) initiator: A STA that is a TXOP holder that transmits an MPDU with the 14 RDG/More PPDU field set to 1. 15 16 17 3A.60 reverse direction (RD) responder: A STA that is not the RD initiator and whose MAC address 18 matches the value of the Address 1 field of a received MPDU that has the RDG/More PPDU field set to 1. 19 20 21 3A.61 secondary channel: A 20 MHz channel associated with a primary channel used by HT STAs for the 22 purpose of creating a 40 MHz channel. 23 24 25 3A.62 signaling and payload protected A-MSDU (SPP A-MSDU): An A-MSDU that is CCMP protected 26 and that includes the A-MSDU Present field (bit 7 of the QoS control field) in the construction of the AAD. 27 28 29 3A.63 space time block coded delivery traffic indication map (STBC DTIM): An STBC beacon transmis- 30 sion that is a DTIM Beacon. 31 32 33 3A.64 space time block coding (STBC) beacon: A beacon that is transmitted using the basic STBC MCS 34 to enable discovery of the BSS by HT STAs that support the HT STBC feature in order to extend the range 35 of the BSS. 36 37 38 3A.65 STA 5G: a STA that is operating on a channel that belongs to any regulatory class that has a value of 39 “20” or “40” for the entry in the column labeled “Channel Spacing (MHz)” and that has a value of “5” for the 40 entry in the column labeled “Channel Starting Frequency (GHz)” of any of the tables found in Annex J. 41 42 43 3A.66 STA 2G4: a STA that is operating on a channel that belongs to any regulatory class that has a value 44 of “25” or “40” for the entry in the column labeled “Channel Spacing (MHz)” and that has a value of “2.407” 45 or “2.414” for the entry in the column labeled “Channel Starting Frequency (GHz)” of any of the tables found 46 47 in Annex J. 48 49 3A.67 staggered preamble: A PLCP preamble in a sounding PPDU that is not an NDP that includes one or 50 51 more DLTFs and one or more ELTFs. 52 53 3A.68 staggered sounding: The use of a sounding PPDU that is not an NDP and that includes one or more 54 55 DLTFs and one or more ELTFs. 56 57 3A.69 STBC frame: A frame that is transmitted in a PPDU that has the TXVECTOR STBC parameter set 58 to a non-zero value, or a frame that is received in a PPDU that has the RXVECTOR STBC parameter set to 59 60 a non-zero value. 61 62 3A.70 sounding PPDU: A PPDU that is intended by the transmitting STA to enable the receiving STA to 63 64 estimate the channel between the transmitting STA and the receiving STA. The Not Sounding field in the HT- 65 SIG is set to 0 in sounding PPDUs.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 4. Abbreviations and acronyms 2 3 4 Insert the following abbreviations and acronyms into Clause 4 in alphabetical order: 5 6 A-MPDU aggregate MAC protocol data unit 7 8 9 A-MSDU aggregate MAC service data unit 10 11 ASEL antenna selection 12 13 CSD cyclic shift diversity 14 15 16 CSI channel state information 17 18 CTS1 clear to send 1 19 20 21 CTS2 clear to send 2 22 23 DFT discrete Fourier transform 24 25 26 DLTF data long training field 27 28 ELTF extension long training field 29 30 31 FEC forward error correction 32 33 HT high throughput 34 35 HTC high throughput control 36 37 38 HT-GF-STF high throughput greenfield short training field 39 40 HT-SIG high throughput SIGNAL field 41 42 43 HT-STF high throughput short training field 44 45 IDFT inverse discrete Fourier transform 46 47 48 IDO IBSS DFS owner 49 50 LDPC low density parity check 51 52 53 L-LTF non-HT long training field 54 55 L-SIG non-HT SIGNAL field 56 57 58 L-STF non-HT short training field 59 60 LTF long training field 61 62 MCS modulation and coding scheme 63 64 65 MFB MCS feedback

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 MIMO multiple input, multiple output 2 3 MRQ MCS request 4 5 6 NDP Null Data Packet 7 8 OBSS overlapping basic service set 9 10 11 PBAC protected block ack agreement capable 12 13 PCO phased coexistence operation 14 15 PSMP power save multi-poll 16 17 18 PSMP-DTT power save multi-poll downlink transmission time 19 20 PSMP-UTT power save multi-poll uplink transmission time 21 22 23 QBPSK quadrature binary phase shift keying 24 25 RD reverse direction 26 27 RDG reverse direction grant 28 29 30 RIFS reduced interframe spacing 31 32 RXASSI receive antenna selection sounding indication 33 34 35 RXASSR receive antenna selection sounding request 36 37 SM spatial multiplexing 38 39 SN sequence number 40 41 42 SNR signal to noise ratio 43 44 SPP A-MSDU Signaling and Payload Protected A-MSDU 45 46 47 SSN starting sequence number 48 49 STBC space-time block code 50 51 TXASSI transmit antenna selection sounding indication 52 53 54 TXASSR transmit antenna selection sounding request 55 56 57 58 5. General description 59 60 Insert the following subclause (5.2.9) after 5.2.8.4: 61 62 5.2.9 High Throughput (HT) STA 63 64 65 The IEEE 802.11 HT STA provides PHY and MAC features that can support a throughput of 100 Mb/s and

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 greater, as measured at the MAC data service access point (SAP). An HT STA supports HT features as iden- 2 tified in Clause 9 and Clause 20. An HT STA operating in the 5 GHz band supports transmission and recep- 3 tion of frames that are compliant with mandatory PHY specifications as defined in Clause 17. An HT STA 4 5 operating in the 2.4 GHz band supports transmission and reception of frames that are compliant with manda- 6 tory PHY specifications as defined in Clauses 18 and 19. An HT STA is also a QoS STA. The HT features 7 are available to HT STAs associated with an HT AP in a BSS. A subset of the HT features is available for use 8 between two HT STAs that are members of the same IBSS. 9 10 11 An HT STA has PHY features consisting of the modulation and coding scheme (MCS) set described in 20.3.5 12 and PLCP protocol data unit (PPDU) formats described in 20.1.4. Some PHY features that distinguish an HT 13 STA from a non-HT STA are referred to as: multiple input, multiple output (MIMO) operation; spatial mul- 14 tiplexing; spatial mapping (including transmit beamforming); space time block code (STBC) encoding; low 15 density parity check (LDPC) encoding; and antenna selection. The allowed PPDU formats are non-HT for- 16 17 mat, HT-mixed format, and HT-greenfield format. The PPDUs may be transmitted with 20 MHz or 40 MHz 18 bandwidth. 19 20 An HT STA has MAC features that include frame aggregation, some Block Ack features, power save multi- 21 poll (PSMP) operation, reverse direction, and protection mechanisms supporting coexistence with non-HT 22 23 STAs. 24 25 26 6. MAC service definition 27 28 29 30 6.1 Overview of MAC services 31 32 6.1.5 MAC data service architecture 33 34 Change the first two paragraphs of 6.1.5 as follows: 35 36 37 The MAC data plane architecture (i.e., processes that involve transport of all or part of an MSDU) is shown 38 in Figure 6-1. During transmission, an MSDU goes through some or all of the following processes: A-MSDU 39 aggregation, frame delivery deferral during power save mode, sequence number assignment, fragmentation, 40 encryption, integrity protection, and frame formatting and A-MPDU aggregation. IEEE Std 802.1X-2004 41 42 may block the MSDU at the Controlled Port. At some point, the data frames that contain all or part of the 43 MSDU are queued per AC/TS. This queuing may be at any of the three points indicated in Figure 6-1. 44 45 During reception, a received data frame goes through processes of possible A-MPDU de-aggregation, MPDU 46 header and cyclic redundancy code (CRC) validation, duplicate removal, possible reordering if the Block Ack 47 48 mechanism is used, decryption, defragmentation, integrity checking, and replay detection. After replay detec- 49 tion (or defragmentation if security is used) and possible A-MSDU de-aggregation, the one or more MSDUs 50 is are delivered to the MAC_SAP or to the DS. The IEEE 802.1X Controlled/Uncontrolled Ports discard the 51 any received MSDU if the Controlled Port is not enabled and if the MSDU does not represent an IEEE 802.1X 52 frame. TKIP and CCMP MPDU frame order enforcement occurs after decryption, but prior to MSDU defrag- 53 54 mentation; therefore, defragmentation will fail if MPDUs arrive out of order. 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Replace Figure 6-1—MAC data plane architecture with the following figure: 2 3 EDITORIAL NOTE—The changes comprise the addition the A-MSDU Aggregation, A-MPDU 4 Aggregation, A-MSDU De-aggregation, A-MPDU De-aggregation boxes; the removal of the “Per Access 5 6 Category/TS queuing and three arrows; the addition of “and” to the “MSDU Integrity and Protection 7 (optional) box on the left hand side; the re-ordering of the “Block Ack Reordering” and “MPDU 8 Decryption and Integrity” boxes with the addition of a callout allowing these to be performed in either 9 order; and the addition of “- Transmitting” and “- Receiving” to the arrows at the left and right sides. 10 11 12 IEEE 802.1X IEEE 802.1X 13 Controlled and Controlled and 14 Uncontrolled Port Uncontrolled Port 15 Filtering (optional) Filtering (optional) 16 MSDU 17 LLC/SNAP Flow LLC/SNAP 18 IEEE 802.1X IEEE 802.1X 19 IEEE 802.1 MAC Controlled Port Controlled Port Relay Entity 20 Filtering Filtering (RSNA AP only) 21 (optional) (optional) 22 23 24 Intra BSS Relay (pre – RSNA AP only) 25 26 A-MSDU A-MSDU

MSDU Flow – MSDU Receiving 27 Aggregation Flow De-aggregation 28 29 PS Defer Queuing Replay Detection 30 (AP or IBSS STA (optional) only) 31 MSDU Integrity 32 and Protection 33 Sequence Number (optional) 34 Assignment 35 MSDU Flow - Transmitting Defragmentation MSDU Integrity 36 and Protection 37 (optional) Block Ack 38 The ‘MPDU Decryption and Integrity Reordering (optional)’ and ‘Block Ack 39 Reordering’ processes may be Fragmentation MPDU Decryption 40 performed in either order and Integrity 41 (optional) 42 MPDU Encryption 43 and Integrity Duplicate Removal 44 (optional) 45 46 MPDU Header + MPDU Header + CRC CRC Validation 47 48 A-MPDU A-MPDU 49 Aggregation De-aggregation 50 51 52 Figure 6-1—MAC data plane architecture 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 7. Frame formats 2 3 4 7.1 MAC frame formats 5 6 7 Change list item a) A MAC header in 7.1 as follows: 8 9 a) A MAC header, which comprises frame control, duration, address, and optional sequence control 10 information, and, for QoS data frames optional QoS cControl information (QoS data frames only) 11 and optional HT Control fields (+HTC frames only); 12 13 7.1.1 Conventions 14 15 16 Change the second paragraph of 7.1.1 as follows: 17 18 In figures, all bits within fields are numbered, from 0 to k, where the length of the field is k + 1 bits. Bits 19 within numeric fields that are longer than a single bit are depicted in increasing order of significance – i.e, 20 21 with the lowest numbered bit having the least significance. The octet boundaries within a field can be 22 obtained by taking the bit numbers of the field modulo 8. Octets within numeric fields that are longer than a 23 single octet are depicted in increasing order of significance, from lowest numbered bit to highest numbered 24 bit. The octets in fields longer than a single octet are sent to the PLCP in order from the octet containing the 25 lowest numbered bits to the octet containing the highest numbered bits. 26 27 28 Insert the following paragraph after the seventh paragraph in 7.1.1: 29 30 A frame that contains the HT Control field, including the Control Wrapper frame, is referred to as a +HTC 31 frame. 32 33 34 7.1.2 General frame format 35 36 Change the first two paragraphs of 7.1.2 as follows: 37 38 The MAC frame format comprises a set of fields that occur in a fixed order in all frames. Figure 7-1 depicts 39 40 the general MAC frame format. The first three fields (Frame Control, Duration/ID, and Address 1) and the 41 last field (FCS) in Figure 7-1 constitute the minimal frame format and are present in all frames, including 42 reserved types and subtypes. The fields Address 2, Address 3, Sequence Control, Address 4, QoS Control, 43 HT Control, and Frame Body are present only in certain frame types and subtypes. Each field is defined in 44 7.1.3. The format of each of the individual subtypes of each frame types is defined in 7.2. The components 45 46 of management frame bodies are defined in 7.3. The formats of management frames of subtype Action are 47 defined in 7.4. 48 49 The Frame Body field is of variable size. The maximum frame body size is determined by the maximum 50 MSDU size (2304 octets) or the maximum A-MSDU size (3839 or 7935 octets, depending upon the STA’s 51 52 capability), plus any overhead from security encapsulation. 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Replace Figure 7-1 with the following figure: 2 3 EDITORIAL NOTE—The change comprises the insertion of the HT Control field and the change in the 4 length of the frame body. 5 6 7 8 9 Octets: 2 2 6 6 6 2 6 2 4 0-7955 4 10 Frame Duration Address Address Address Sequence Address QoS HT Frame FCS 11 Control /ID 1 2 3 Control 4 Control Control Body 12 13 14 MAC Header 15 16 Figure 7-1—MAC frame format 17 18 19 20 7.1.3 Frame fields 21 22 7.1.3.1 Frame control field 23 24 25 7.1.3.1.2 Type and Subtype fields 26 27 Insert management subtype 1110, change the management reserved subtypes 1110-1111, change the 28 control reserved subtypes 0000-0111, and insert the control subtype 0111 in Table 7-1 as follows: 29 30 31 32 Table 7-1—Valid type and subtype combinations 33 34 Type value Type Subtype value 35 Subtype description 36 b3 b2 description b7 b6 b5 b4 37 00 Management 1110 Action No Ack 38 39 00 Management 1110-1111 Reserved 40 41 01 Control 0000-01110 Reserved 42 43 01 Control 0111 Control Wrapper 44 45 46 47 7.1.3.1.6 Power Management field 48 49 Change the first paragraph of 7.1.3.1.6 as follows: 50 51 52 The Power Management field is 1 bit in length and is used to indicate the power management mode of a STA. 53 The value of this field remains constant in each frame from a particular STA within a frame exchange se- 54 quence (see Annex S)defined in 9.12. The value indicates the mode in which the STA will be after the suc- 55 cessful completion of the frame exchange sequence. 56 57 58 7.1.3.1.7 More Data field 59 60 Change the first paragraph of 7.1.3.1.7 as follows: 61 62 The More Data field is 1 bit in length and is used to indicate to a STA in PS mode that more MSDUs, A- 63 64 MSDUs or MMPDUs are buffered for that STA at the AP. The More Data field is valid in directed data or 65 management type frames transmitted by an AP to a STA in PS mode. A value of 1 indicates that at least one

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 additional buffered MSDU, A-MSDU or MMPDU is present for the same STA. 2 3 7.1.3.1.9 Order field 4 5 6 Change 7.1.3.1.9 as follows : 7 8 The Order field is 1 bit in length and is set to 1 in any non-QoS data frame that contains an MSDU, or fragment 9 thereof, which is being transferred using the StrictlyOrdered service class. This field is set to 0 in all other 10 11 frames. All QoS STAs set this subfield to 0. 12 13 The Order field is 1 bit in length. 14 15 It is used for two purposes: 16 17 — When set to 1 in a non-QoS data frame transmitted by a non-QoS STA, it indicates that the frame 18 contains an MSDU, or fragment thereof, which is being transferred using the StrictlyOrdered service 19 class. 20 21 — When set to 1 in a QoS data or management frame transmitted with a value of HT_GF or HT_MF for 22 the FORMAT parameter of the TXVECTOR, it indicates that the frame contains an HT Control 23 field. 24 25 26 Otherwise the Order field is set to 0. 27 28 7.1.3.2 Duration/ID field 29 30 31 Insert the following paragraph at the end of 7.1.3.2: 32 33 The Duration/ID fields in the MAC Headers of MPDUs in an A-MPDU all carry the same value. 34 NOTE—The reference point for the Duration/ID field is the end of the PPDU carrying the MPDU. Setting the Duration/ 35 ID field to the same value in the case of A-MPDU aggregation means that each MPDU consistently specifies the same 36 NAV setting. 37 38 7.1.3.3 Address fields 39 40 41 7.1.3.3.3 BSSID field 42 43 Change the third paragraph of 7.1.3.3.3 as follows: 44 45 46 The value of all 1s is used to indicate the wildcard BSSID. A wildcard BSSID shall not be used in the BSSID 47 field except for management frames of subtype probe request and of subtype Action with Category Public. 48 49 7.1.3.3.4 DA field 50 51 52 Change 7.1.3.3.4 as follows: 53 54 The DA field contains an IEEE MAC individual or group address that identifies the MAC entity or entities 55 intended as the final recipient(s) of the MSDU (or fragment thereof) or A-MSDU, as defined in 7.2.2.1, con- 56 tained in the frame body field. 57 58 59 7.1.3.3.5 SA field 60 61 Change 7.1.3.3.5 as follows: 62 63 64 The SA field contains an IEEE MAC individual address that identifies the MAC entity from which the trans- 65 fer of the MSDU (or fragment thereof) or A-MSDU, as defined in 7.2.2.1, contained in the frame body field

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 was initiated. The individual/group bit is always transmitted as a zero in the source address. 2 3 4 7.1.3.4 Sequence Control field 5 6 7.1.3.4.1 Sequence Number field 7 8 9 Change 7.1.3.4.1 as follows (note strikeout of a comma in the second paragraph): 10 11 The Sequence Number field is a 12-bit field indicating the sequence number of an MSDU, A-MSDU or 12 13 MMPDU. Each MSDU, A-MSDU or MMPDU transmitted by a STA is assigned a sequence number. Se- 14 quence numbers are not assigned to control frames, as the Sequence Control field is not present. 15 16 17 Non-QoS STAs, as well as QoS STAs operating as non-QoS STAs because they are in a non-QoS BSS or 18 non-QoS IBSS, assign sequence numbers, to management frames and data frames (QoS subfield of the Sub- 19 20 type field is set to 0), from a single modulo-4096 counter, starting at 0 and incrementing by 1 for each MSDU 21 or MMPDU. 22 23 24 QoS STAs associated in a QoS BSS maintain one modulo-4096 counter, per TID, per unique receiver (spec- 25 ified by the Address 1 field of the MAC header). Sequence numbers for QoS data frames are assigned using 26 27 the counter identified by the TID subfield of the QoS Control field of the frame, and that counter is increment- 28 ed by 1 for each MSDU or A-MSDU belonging to that TID. Sequence numbers for management frames, QoS 29 data frames with a broadcast/multicast group address in the Address 1 field, and all non-QoS data frames sent 30 31 by QoS STAs are assigned using an additional single modulo-4096 counter, starting at 0 and incrementing by 32 1 for each MSDU, A-MSDU or MMPDU. Sequence numbers for QoS (+)Null frames may be set to any value. 33 34 35 Each fragment of an MSDU or MMPDU contains a copy of the sequence number assigned to that MSDU or 36 MMPDU. The sequence number remains constant in all retransmissions of an MSDU, MMPDU, or fragment 37 38 thereof. 39 40 7.1.3.4.2 Fragment Number field 41 42 43 Change 7.1.3.4.2 as follows: 44 45 46 The Fragment Number field is a 4-bit field indicating the number of each fragment of an MSDU or MMPDU. 47 The fragment number is set to 0 in the first or only fragment of an MSDU or MMPDU and is incremented by 48 one for each successive fragment of that MSDU or MMPDU. The fragment number is set to 0 in the only 49 50 fragment of an A-MSDU. The fragment number remains constant in all retransmissions of the fragment. 51 52 7.1.3.5 QoS Control field 53 54 55 Change the first paragraph of 7.1.3.5 as follows: 56 57 58 The QoS Control field is a 16-bit field that identifies the TC or TS to which the frame belongs and various 59 other QoS-related information about the frame that varies by frame type and subtype. The QoS Control field 60 61 is present in all data frames in which the QoS subfield of the Subtype field is set to 1 (see 7.1.3.1.2). Each 62 QoS Control field comprises five subfields, as defined for the particular sender (HC or non-AP STA) and 63 frame type and subtype. The usage of these subfields and the various possible layouts of the QoS Control field 64 65 are described 7.1.3.5.1 through 7.1.3.5.7 7.1.3.5.8 and illustrated in Table 7-4.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Change Table 7-4 as follows: 2 3 EDITORIAL NOTE—The changes comprise using bit 7 to indicate A-MSDU present in only QoS data 4 subtypes. 5 6 7 8 Table 7-4—QoS Control Ffield 9 10 Applicable frame 11 Bits 0-3 Bit 4 Bit 5-6 Bit 7 Bits 8-15 12 (sub-)types 13 14 QoS CF-Poll and QoS CF-Ack+CF- TID EOSP Ack Policy Reserved TXOP limit 15 Poll frames sent by HC 16 QoS (+)CF-Poll frames sent by HC 17 18 QoS Data+CF-Poll and QoS TID EOSP Ack Policy A-MSDU TXOP limit 19 Data+CF-Ack+CF-Poll frames sent Present 20 by HC 21 QoS Data and QoS Data+CF-Ack TID EOSP Ack Policy A-MSDU AP PS Buffer State 22 frames sent by HC Present 23 24 QoS Null frames sent by HC TID EOSP Ack Policy Reserved AP PS Buffer State 25 QoS Data, QoS Null, and QoS 26 Data+CF-Ack frames sent by HC 27 28 QoS Data and QoS Data+CF-Ack TID 0 Ack Policy A-MSDU TXOP duration 29 frames sent by non-AP STAs Present requested 30 31 TID 1 Ack Policy A-MSDU Queue size 32 Present 33 34 QoS Null frames sent by non-AP TID 0 Ack Policy Reserved TXOP duration 35 STAs requested QoS data frames sent by non-AP 36 TID 1 Ack Policy Reserved Queue size 37 STAs 38 39 40 7.1.3.5.1 TID subfield 41 42 43 Change the first paragraph of 7.1.3.5.1 as follows: 44 45 The TID subfield identifies the TC or TS to which the corresponding MSDU (or fragment thereof) or A- 46 MSDU in the Frame Body field belongs. The TID subfield also identifies the TC or TS of traffic for which a 47 48 TXOP is being requested, through the setting of TXOP duration requested or queue size. The encoding of the 49 TID subfield depends on the access policy (see 7.3.2.30) and is shown in Table 7-5. Additional information 50 on the interpretation of the contents of this field appears in 6.1.1.2. 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 7.1.3.5.3 Ack Policy subfield 2 3 4 Change the first three non-header rows of Table 7-6 as follows: 5 6 7 Table 7-6—Ack Policy subfield in QoS Control field of QoS data frames 8 9 10 Bits in QoS Control field 11 Meaning 12 Bit 5 Bit 6 13 14 0 0 Normal Ack or Implicit Block Ack Request. 15 16 In a frame that is a non-A-MPDU frame: 17 The addressed recipient returns an ACK or QoS +CF-Ack frame after a short 18 interframe space (SIFS) period, according to the procedures defined in 9.2.8, 19 9.3.3 and 9.9.2.3. The Ack Policy subfield is set to this value in all directed 20 frames in which the sender requires acknowledgment. For QoS Null (no data) 21 frames, this is the only permissible value for the Ack Policy subfield. 22 23 In a frame that is part of an A-MPDU: 24 The addressed recipient returns a BlockAck MPDU, either individually or as part 25 of an A-MPDU starting a SIFS after the PPDU carrying the frame, according to 26 the procedures defined in 9.2.8a, 9.10.7.5, 9.10.8.3, 9.15.3, 9.15.4 and 9.19.3. 27 28 10No Ack 29 The addressed recipient takes no action upon receipt of the frame. More details 30 are provided in 9.11. 31 The Ack Policy subfield is set to this value in all directed frames in which the 32 sender does not require acknowledgment. This combination is also used for 33 broadcast and multicast group addressed frames that use the QoS frame format. 34 This combination is not used for QoS data frames with a TID for which a Block 35 Ack agreement exists. 36 37 0 1 No explicit acknowledgment, or PSMP Ack. 38 39 When bit 6 of the frame control field (see 7.1.3.1.2) is set to 1: 40 There may be a response frame to the frame that is received, but it is neither the 41 ACK nor any data frame of subtype +CF-Ack. 42 For QoS CF-Poll and QoS CF-Ack+CF-Poll data frames, this is the only permis- 43 sible value for the Ack Policy subfield. 44 45 When bit 6 of the frame control field (see 7.1.3.1.2) is set to 0: 46 The acknowledgement for a frame indicating PSMP Ack when it appears in a 47 PSMP-DTT is to be received in a later PSMP-UTT. 48 The acknowledgement for a frame indicating PSMP Ack when it appears in a 49 PSMP-UTT is to be received in a later PSMP-DTT. 50 51 NOTE—Bit 6 of the frame control field (see 7.1.3.1.2) indicates the absence of a 52 data payload. When set to 1, the QoS data frame contains no payload, and any 53 response is generated in response to a QoS CF-Poll or QoS CF-Ack+CF-Poll 54 frame, but does not signify an acknowledgement of data. When set to 0, the QoS 55 data frame contains a payload, which is acknowledged as described in 9.16.1.7. 56 57 58 59 7.1.3.5.5 Queue Size subfield 60 61 Change the second paragraph of 7.1.3.5.5 as follows: 62 63 64 The queue size value is the total size, rounded up to the nearest multiple of 256 octets and expressed in units 65 of 256 octets, of all MSDUs and A-MSDUs buffered at the STA (excluding the MSDU or A-MSDU of the

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 present QoS data frame) in the delivery queue used for MSDUs and A-MSDUs with TID values equal to the 2 value in the TID subfield of this QoS Control field. A queue size value of 0 is used solely to indicate the ab- 3 sence of any buffered traffic in the queue used for the specified TID. A queue size value of 254 is used for all 4 5 sizes greater than 64 768 octets. A queue size value of 255 is used to indicate an unspecified or unknown size. 6 If a QoS data frame is fragmented, the queue size value may remain constant in all fragments even if the 7 amount of queued traffic changes as successive fragments are transmitted. 8 9 10 7.1.3.5.6 TXOP Duration Requested subfield 11 12 Change the second paragraph of 7.1.3.5.6 as follows: 13 14 TXOP Duration Requested subfield values are not cumulative. A TXOP duration requested for a particular 15 16 TID supersedes any prior TXOP duration requested for that TID. A value of 0 in the TXOP Duration Request- 17 ed subfield may be used to cancel a pending unsatisfied TXOP request when its MSDU or A-MSDU is no 18 longer queued for transmission. The TXOP duration requested is inclusive of the PHY and IFS overhead, and 19 a STA should account for this when attempting to determine whether a given transmission fits within a spec- 20 ified TXOP duration. 21 22 23 7.1.3.5.7 AP PS Buffer State subfield 24 25 Change the third and fourth paragraphs of 7.1.3.5.7 as follows: 26 27 28 The Highest-Priority Buffered AC subfield is 2 bits in length and is used to indicate the AC of the highest 29 priority traffic remaining that is buffered at the AP, excluding the MSDU or A-MSDU of the present frame. 30 31 32 The AP Buffered Load subfield is 4 bits in length and is used to indicate the total buffer size, rounded up to 33 the nearest multiple of 4096 octets and expressed in units of 4096 octets, of all MSDUs and A-MSDUs buff- 34 ered at the QoS AP (excluding the MSDU or A-MSDU of the present QoS data frame). An AP Buffered Load 35 field value of 15 indicates that the buffer size is greater than 57 344 octets. An AP Buffered Load subfield 36 value of 0 is used solely to indicate the absence of any buffered traffic for the indicated highest priority buff- 37 38 ered AC when the Buffer State Indicated bit is 1. 39 40 Insert the following subclause (7.1.3.5.8) after 7.1.3.5.7: 41 42 7.1.3.5.8 A-MSDU Present subfield 43 44 45 The A-MSDU Present subfield is 1 bit in length, and indicates the presence of an A-MSDU. When the A- 46 MSDU Present subfield is set to 1, the Frame Body field contains an entire A-MSDU as defined in 7.2.2.2. 47 When the A-MSDU Present subfield is set to 0, the Frame Body field contains an MSDU or fragment thereof 48 as defined in 7.2.2.1. 49 50 51 Insert the following subclause (7.1.3.5a) after 7.1.3.5.8: 52 53 7.1.3.5a HT Control field 54 55 56 The HT Control field is always present in a Control Wrapper frame, and is present in QoS Data and manage- 57 ment frames as determined by the Order bit of the Frame Control field as defined in 7.1.3.1.9. 58 NOTE—The only Control frame subtype for which HT control field is present is the Control Wrapper frame. A control 59 frame that is described as +HTC (e.g., RTS+HTC, CTS+HTC, BlockAck+HTC or BlockAckReq+HTC) implies the use 60 of the Control Wrapper frame to carry that control frame. 61 62 The format of the 4-octet HT Control field is shown in Figure 7-4a. 63 64 65 The format of the Link Adaptation Control field is defined in Figure 7-4b.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 2 B0 B15 B16 B17 B18 B19 B20 B21 B22 B23 B24 B25 B29 B30 B31 3 Link Calibration Calibration CSI/ NDP AC RDG/ 4 Adaptation Reserved Announce- Reserved 5 Control Position Sequence Steering ment Constraint More PPDU 6 7 Bits1622221511 8 9 Figure 7-4a—HT Control field 10 11 12 13 B0 B1 B2 B5 B6 B8 B9 B15 14 15 Reserved TRQ MAI MFSI MFB/ASELC 16 17 Bits1143 7 18 19 Figure 7-4b—Link Adaptation Control field 20 21 22 23 The subfields of the Link Adaptation Control field are defined in Table 7-6a. 24 25 26 Table 7-6a—Link Adaptation Control subfields 27 28 29 Field Meaning Definition 30 31 TRQ Training Set to 1 to request the responder to transmit a sounding PPDU. 32 Request When set to 0, the responder is not requested to transmit a sounding PPDU. 33 See 9.19.2 and 9.21.2. 34 35 MAI MCS request When set to 14 (indicating ASELI), the MFB/ASELC field is interpreted as 36 or Antenna ASELC. Otherwise, the MAI field is interpreted as shown in Figure 7-4c and 37 Selection Indi- the MFB/ASELC field is interpreted as MCS feedback. 38 cation 39 MFSI MFB Set to the received value of MSI contained in the frame to which the MFB 40 Sequence information refers. 41 Identifier Set to 7 for unsolicited MFB 42 43 MFB/ASELC MCS Feed- When the MAI field is set to the value ASELI, this field is interpreted as 44 back and defined in Figure 7-4d and Table 7-6c. 45 Antenna 46 Selection Otherwise, this field contains recommended MCS feedback. 47 Command/ A value of 127 indicates that no feedback is present. 48 Data 49 50 51 52 The structure of the MAI field is defined in Figure 7-4c. The subfields of the MAI field are defined in Table 53 7-6b. 54 55 56 57 B0 B1 B3 58 59 MRQ MSI 60 61 Bits 1 3 62 63 64 Figure 7-4c—MAI field 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table 7-6b—Subfields of the MAI field 2 3 4 Field Meaning Definition 5 6 MRQ MCS Request When the MRQ field is set to 1, MCS feedback is requested. 7 When set to 0, no MCS feedback is requested. 8 MSI MCS Request Sequence Identifier When the MRQ field is set to 1, the MSI field contains a sequence 9 number in the range 0 to 6 that identifies the specific request.When 10 the MRQ field is set to 0, the MSI subfield is reserved. 11 12 13 14 The ASELC subfield contains the ASEL Command and ASEL Data subfields, as shown in Figure 7-4d. The 15 encoding of these fields is shown in Table 7-6c. 16 17 18 19 B0 B2 B3 B6 20 21 ASEL Command ASEL Data 22 23 Bits 3 4 24 25 Figure 7-4d—ASELC subfield 26 27 28 29 Table 7-6c—The ASEL Command and ASEL Data subfields 30 31 Interpretation of ASEL 32 ASEL Command ASEL Data 33 Command 34 35 0 Transmit Antenna Selection Number of remaining sounding PPDUs to be trans- 36 Sounding Indication (TXASSI) mitted 37 0 to 15 38 39 See NOTE 40 1 Transmit Antenna Selection 0 when the command is Transmit Antenna Selection 41 Sounding Request (TXASSR) Sounding Request 42 or Transmit Antenna Selection A number in the range of values of 1 through 15, the 43 Sounding Resumption number being the number of the first sounding 44 PPDU to be transmitted when the command is 45 Transmit Antenna Selection Sounding Resumption, 46 where 0 corresponds to the first sounding PPDU in 47 the original antenna selection training sequence 48 49 2 Receive Antenna Selection Number of remaining sounding PPDUs to be 50 Sounding Indication (RXASSI) received 51 0 to 15 52 53 See NOTE 54 55 3 Receive Antenna Selection Number of sounding PPDUs required 56 Sounding Request (RXASSR) 0 to 15 57 58 4 Sounding Label Sequence number of the sounding PPDU corre- 59 sponding to a channel state information (CSI) 60 frame in antenna selection feedback 61 0 to 15 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table 7-6c—The ASEL Command and ASEL Data subfields (continued) 2 3 4 Interpretation of ASEL ASEL Command ASEL Data 5 Command 6 7 5 No feedback due to antenna A number in the range of values of 0 through 15, the 8 selection training failure or number being the number of the first sounding 9 stale feedback PPDU that was not received properly, where 0 cor- 10 responds to the first sounding PPDU in the antenna 11 selection training sequence, or 0 if no sounding 12 PPDUs were received properly, or 0 if this is a 13 request for a full retraining sequence 14 15 6 Transmit Antenna Selection Number of remaining sounding PPDUs to be trans- 16 Sounding Indication (TXASSI- mitted 17 CSI) requesting feedback of 0 to 15 18 explicit CSI 19 See NOTE 20 21 7 Reserved Reserved 22 NOTE—If the HT Control field is carried in a sounding PPDU, then the value of the ASEL Data field contains the 23 remaining number of sounding frames following the current one. If NDP sounding frame is used, then the value in 24 the ASEL Data field contains the number of NDPs following a non-NDP+HTC. The NDP announcement field in 25 the HT Control field is set to 1 to indicate NDP sounding. 26 27 28 29 The Calibration Position and Calibration Sequence fields are defined in Table 7-6d. 30 31 The Calibration Sequence field identifies an instance of the calibration procedure. The field is included in 32 33 each frame within a calibration procedure and its value is unchanged for frames within the same calibration 34 procedure. 35 36 Table 7-6d—Calibration Control subfields 37 38 39 Field Meaning Definition 40 41 Calibration Position in Calibration Sounding Set to 0 indicates this is not a calibration frame, 42 Position Exchange Sequence Set to 1 indicates Calibration Start, 43 Set to 2 indicates Sounding Response, 44 Set to 3 indicates Sounding Complete. 45 Calibration Calibration Sequence Identifier The field is included in each frame within the calibration 46 Sequence procedure and its value is unchanged for the frame 47 exchanges during one calibration procedure. 48 See 9.19.2.4.3. 49 50 51 52 The CSI/Steering field indicates the type of feedback, as shown in Table 7-6e. 53 54 55 The NDP Announcement subfield indicates that an NDP will be transmitted after the frame (according to the 56 rules described in 9.21). It is set to 1 to indicate that an NDP will follow, otherwise it is set to 0. 57 58 The AC Constraint field indicates whether the mapped AC of an RD data frame is constrained to a single AC 59 or not, as defined in Table 7-6f. 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table 7-6e—CSI/Steering values 2 3 4 Value Definition 5 6 0 No feedback required 7 8 1 CSI 9 10 2 Non-compressed Beamforming 11 3 Compressed Beamforming 12 13 14 15 Table 7-6f—AC Constraint values 16 17 18 AC Constraint field Description 19 value 20 21 0 The response to a reverse direction grant (RDG) may contain data frames from any TID 22 The response to an RDG may contain data frames only from the same AC as the last 23 1 24 data frame received from the RD initiator 25 26 27 The RDG/More PPDU field of the HT Control field is interpreted differently when transmitted by an RD ini- 28 29 tiator or an RD responder, as defined in Table 7-6g. 30 31 32 Table 7-6g—RDG/More PPDU values 33 34 35 RDG/More Role of Interpretation of value 36 PPDU value transmitting STA 37 38 0 RD initiator No reverse grant 39 40 RD responder The PPDU carrying the frame is the last transmission by the 41 RD responder 42 43 1 RD initiator An RDG is present, as defined by the Duration/ID field 44 RD responder The PPDU carrying the frame is followed by another PPDU 45 46 47 48 7.1.3.6 Frame Body field 49 50 51 Change 7.1.3.6 as follows: 52 53 The Frame Body is a variable length field that contains information specific to individual frame types and 54 subtypes. The minimum length of the frame body is 0 octets. The maximum length of the frame body is de- 55 fined by the maximum length MSDU or A-MSDU plus any overhead for encryption as defined in Clause 56 57 8.(MSDU + ICV + IV), where integrity check value (ICV) and initialization vector (IV) are the WEP fields 58 defined in 8.2.1. 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Change the heading of 7.1.4 as follows: 2 3 7.1.4 Duration/ID field (QoS STA)in data and management frames 4 5 6 Change 7.1.4 as follows: 7 8 Within all data frames containing QoS CF-Poll, the Duration/ID field value is set to one of the following: 9 10 — One SIFS duration plus the TXOP limit, if the TXOP limit is nonzero, or 11 — The time required for the transmission of one MPDU of nominal MSDU size and the associated 12 13 ACK frame plus two SIFS intervals, if the TXOP limit is zero. 14 15 Within all data or management frames sent in a CP by the QoS STAs outside of a controlled access phase 16 (CAP), following a contention access of the channel, the Duration/ID field is set to one of the following val- 17 18 ues: 19 a) For management frames, frames with QoS Data subfield set to 0, and unicast data frames with Ack 20 Policy subfield set to Normal Ack, 21 22 1) The time required for the transmission of one ACK frame (including appropriate IFS values), if 23 the frame is the final fragment of the TXOP, or 24 25 2) The time required for the transmission of one ACK frame plus the time required for the trans- 26 mission of the following MPDU and its response if required (including appropriate IFS values). 27 b) For unicast data frames with the Ack Policy subfield set to No Ack or Block Ack and for multicast/ 28 29 broadcast frames, 30 1) Zero, if the frame is the final fragment of the TXOP, or 31 32 2) The time required for the transmission of the following MPDU and its response frame, if 33 required (including appropriate IFS values). 34 c) The minimum of 35 36 1) The time required for the transmission the pending MPDUs of the AC and the associated 37 ACKs, if any, and applicable SIFS durations, and 38 39 2) The time limit imposed by the MIB attribute dot11EDCATableTXOPLimit 40 (dot11EDCAQAPTableTXOPLimit for the AP) for that AC minus the already used time within 41 the TXOP. 42 43 44 Within all data or management frames sent under HCCA, to ensure NAV protection for the entire CAP, the 45 Duration/ID field is set to one of the following values: 46 — The remaining duration of the TXOP, if the frame is a nonfinal frame in a TXOP with multiple frame 47 exchanges. 48 49 — The actual remaining time needed for this frame exchange sequence, if the frame is the sole or final 50 frame in the TXOP. 51 52 53 7.1.4.1 General 54 55 The value in the Duration/ID field in a frame transmitted by a QoS STA is defined in 7.1.4.2, 7.1.4.3, 7.1.4.4, 56 7.1.4.5, and 7.1.4.6. 57 58 59 All times are calculated in microseconds. If a calculated duration includes a fractional microsecond, that value 60 inserted in the Duration/ID field is rounded up to the next higher integer. 61 62 7.1.4.2 Duration/ID field setting for single and multiple protection under EDCA 63 64 65 Within a frame (excluding data frames containing QoS CF-Poll, PSMP frames, and frames that have the

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 RDG/More PPDU field set to 1) transmitted under EDCA by a STA that initiates a TXOP, there are two class- 2 es of duration settings: single protection and multiple protection. In single protection, the value of the Du- 3 ration/ID field of the frame can set a NAV value at receiving STAs that protects up to the end of any following 4 5 data, management or response frame plus any additional overhead frames as described below. In multiple 6 protection, the value of the Duration/ID field of the frame can set a NAV that protects up to the estimated end 7 of a sequence of multiple frames. Frames that have the RDG/More PPDU field set to 1 always use multiple 8 protection. PSMP frames always use multiple protection. The STA selects between single and multiple pro- 9 tection when it transmits the first frame of a TXOP. All subsequent frames transmitted by the STA in the 10 11 same TXOP use the same class of duration settings. 12 a) Single protection settings: 13 14 1) For an RTS that is not part of a dual CTS exchange, the Duration/ID field is set to the esti- 15 mated time, in microseconds, required to transmit the pending frame, plus one CTS frame, plus 16 one ACK or BlockAck frame if required, plus any NDPs required, plus explicit feedback if 17 required, plus applicable IFS durations. 18 19 2) For all CTS frames sent by STAs as the first frame in the exchange under EDCA and with the 20 RA matching the MAC address of the transmitting STA, the Duration/ID field is set to one of 21 the following: 22 23 i) If there is a response frame, the estimated time requred to transmit the pending frame, plus 24 one SIFS interval, plus the response frame (ACK or BlockAck), plus an additional SIFS 25 interval 26 27 ii) If there is no response frame, the time required to transmit the pending frame, plus one 28 SIFS interval 29 3) For a BlockAckReq frame, the Duration/ID field is set to the estimated time required to trans- 30 31 mit one ACK or BlockAck frame, as applicable, plus one SIFS interval. 32 4) For a BlockAck frame that is not sent in response to a BlockAckReq or an implicit Block Ack 33 request, the Duration/ID field is set to the estimated time required to transmit an ACK frame 34 35 plus a SIFS interval. 36 5) For management frames, non-QoS data frames (i.e., with bit 7 of the Frame Control field set to 37 0), and individually addressed data frames with the Ack Policy subfield set to Normal Ack 38 only, the Duration/ID field is set to one of the following: 39 40 i) If the frame is the final fragment of the TXOP, then the estimated time required for the 41 transmission of one ACK frame (including appropriate IFS values), else 42 43 ii) The estimated time required for the transmission of one ACK frame plus the time required 44 for the transmission of the following MPDU and its response if required, plus applicable 45 IFS durations. 46 47 6) For individually addressed QoS data frames with the Ack Policy subfield set to No Ack or 48 Block Ack, management frames of subtype Action No Ack, and for group addressed frames, 49 the Duration/ID field is set to one of the following: 50 51 i) If the frame is the final fragment of the TXOP, then zero, else 52 ii) The estimated time required for the transmission of the following frame and its response 53 frame, if required (including appropriate IFS values). 54 55 b) Multiple protection settings. The Duration/ID field is set to a value D as follows: 56 1) If T = 0 and T = 0, then D = T - T 57 TXOP END_NAV SINGLE-MSDU PPDU 58 2) Else if TTXOP = 0 and TEND_NAV > 0, then D = TEND-NAV -TPPDU 59 60 3) Else if TEND-NAV = 0, then minTPENDING TTXOP – TPPDU DTTXOP – TPPDU 61 62 4) Else TEND– NAV – TPPDU DTTXOP– REMAINING – TPPDU 63 64 65 where:

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 TSINGLE-MSDU is the estimated time required for the transmission of the allowed frame exchange 2 sequence defined in 7.3.2.29 (for a TXOP limit value of 0), including applicable IFS durations 3 4 TPENDING is the estimated time required for the transmission of: 5 6 — pending MPDUs of the same AC 7 — any associated immediate response frames 8 9 — any NDP transmissions and explicit feedback response frames, 10 — applicable IFS durations 11 12 — any RDG 13 14 TTXOP is the value of the MIB attribute dot11EDCATableTXOPLimit 15 (dot11EDCAQAPTableTXOPLimit for the AP) for that AC 16 17 TTXOP_REMAINING is TTXOP less the time already used time within the TXOP 18 T is the remaining duration of any NAV set by the TXOP holder, or 0 if no NAV has 19 END-NAV 20 been established 21 TPPDU is the time required for transmission of the current PPDU 22 23 24 7.1.4.3 Duration/ID field setting for QoS CF-Poll frames 25 26 Within a data frame containing QoS CF-Poll, the Duration/ID field value is set to one of the following: 27 28 a) One SIFS duration plus the TXOP limit, if the TXOP limit is nonzero, or 29 b) The time required for the transmission of one MPDU of nominal MSDU size and the associated 30 31 ACK frame plus two SIFS intervals, if the TXOP limit is zero. 32 33 7.1.4.4 Duration/ID field setting for frames sent by a TXOP holder under HCCA 34 35 36 Within a frame sent by a TXOP holder under HCCA, to ensure NAV protection for the entire CAP, the Du- 37 ration/ID field is set to one of the following values: 38 a) For an RTS frame: 39 40 1) If the pending frame is the final frame, the duration value is set to the time required to transmit 41 the pending frame, plus one CTS frame, plus one ACK frame if required, plus three SIFS inter- 42 vals. 43 44 2) If the pending frame is not the final frame in the TXOP, the duration value is set to the remain- 45 ing duration of the TXOP. 46 47 b) For a CTS frame: 48 1) If the pending frame is the sole frame in the TXOP, the duration value is set to 49 50 i) The time required to transmit the pending frame, plus one SIFS interval, plus the response 51 frame (ACK or BlockAck), plus an additional SIFS interval, if there is a response frame, 52 or 53 54 ii) The time required to transmit the pending frame, plus one SIFS interval, if there is no 55 response frame. 56 57 2) If the pending frame is not the final frame in the TXOP, the duration value is set to the remain- 58 ing duration of the TXOP. 59 c) Otherwise: 60 61 1) The remaining duration of the TXOP, if the frame is a nonfinal frame in a TXOP with multiple 62 frame exchanges. 63 64 2) The actual remaining time needed for this frame exchange sequence, if the frame is the sole or 65 final frame in the TXOP.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 7.1.4.5 Duration/ID field settings within a PSMP sequence 2 3 Within a PSMP frame, the Duration/ID field is set to a value that is no less than the time required to complete 4 5 all PSMP-DTT and PSMP-UTT periods described in the frame. 6 7 Within the PSMP-DTT and PSMP-UTT of a PSMP sequence, the Duration/ID field is set to the Duration/ID 8 value of the preceding PSMP frame, less the time between the end of the PSMP frame and the end of the 9 PPDU carrying the frame. 10 11 NOTE—This means that all frames transmitted within a PSMP sequence locate the same NAV endpoint. 12 13 7.1.4.6 Duration/ID field settings within a dual-CTS sequence 14 15 Within a frame ("Frame1") (excluding a CTS2 transmission, as defined in 9.2.5.5a) sent by a QoS STA that 16 17 is not a TXOP holder in a PPDU that contains an immediate response or that is sent by an RD responder, the 18 Duration/ID field is set to the Duration/ID value from the frame(s) ("Frames2") that elicited the response or 19 that carried the RDG minus the time interval between the end of the PPDU that carried Frame1 and the end 20 of the PPDU that carries Frames2. 21 22 23 Within a frame ("Frame1") (excluding a CTS2 transmission, as defined in 9.2.5.5a) sent by a QoS STA that 24 is a TXOP holder, the Duration/ID field is set according to the rules in the following subclauses: 25 — 7.1.4.2 item b) for multiple protection if Frame1 is not a QoS+CF-Poll frame and the TXOP holder is 26 not operating under HCCA or PSMP, 27 28 — 7.1.4.3 if Frame1 is a QoS+CF-Poll frame and the TXOP holder is not operating under HCCA or 29 PSMP, 30 31 — 7.1.4.4 if the TXOP holder is operating under HCCA, and 32 — 7.1.4.5. if the TXOP holder is operating under PSMP. 33 34 35 Within the CTS2 of a Dual CTS exchange, defined in 9.2.5.5a, the Duration/ID field is set to the value of the 36 Duration/ID field of the RTS that initiated the exchange, minus the time required to transmit CTS1, CTS2 37 and the applicable IFS intervals. 38 39 7.1.4.7 Duration/ID field setting for control response frames 40 41 42 This subclause describes how to set the Duration/ID field for CTS, ACK and BlockAck control response 43 frames, transmitted by a QoS STA. 44 45 46 For a CTS frame that is not part of a dual-CTS sequence transmitted in response to an RTS frame, the Dura- 47 tion/ID field is set to the value obtained from the Duration/ID field of the RTS frame that elicited the response, 48 minus the time, in microseconds, between the end of the PPDU carrying the RTS frame and the end of the 49 PPDU carrying the CTS frame. 50 51 52 For an ACK frame, the Duration/ID field is set to the value obtained from the Duration/ID field of the frame 53 that elicited the response, minus the time, in microseconds between the end of the PPDU carrying the frame 54 that elicited the response and the end of the PPDU carrying the ACK frame. 55 56 For a BlockAck frame transmitted in response to a BlockAckReq frame or transmitted in response to a frame 57 58 containing an implicit Block Ack request, the Duration/ID field is set to the value obtained from the Duration/ 59 ID field of the frame that elicited the response, minus the time, in microseconds between the end of the PPDU 60 carrying the frame that elicited the response and the end of the PPDU carrying the BlockAck frame. 61 62 7.1.4.8 Duration/ID field setting for other response frames 63 64 65 For any frame transmitted by a STA that is not the TXOP holder and is not specified by subclauses 7.1.4.1 to

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 7.1.4.7, the Duration/ID field is set to the value obtained from the Duration/ID field of the frame that elicited 2 the response, minus the time, in microseconds between the end of the PPDU carrying the frame that elicited 3 the response and the end of the PPDU carrying the frame. 4 5 6 7 7.2 Format of individual frame types 8 9 7.2.1 Control frames 10 11 7.2.1.1 RTS frame format 12 13 14 Change the fourth and fifth paragraphs of 7.2.1.1 as follows: 15 16 For all RTS frames sent by non-QoS STAs, the duration value is the time, in microseconds, required to trans- 17 mit the pending data or management frame, plus one CTS frame, plus one ACK frame, plus three SIFS inter- 18 19 vals. If the calculated duration includes a fractional microsecond, that value is rounded up to the next higher 20 integer. For RTS frames sent by QoS STAs, see 7.1.4. For all RTS frames sent by STAs under EDCA, fol- 21 lowing a contention access of the channel, the duration value is set in the following manner: 22 23 — If the NAV protection is desired for only the first or sole frame in the TXOP, the duration value is set 24 to the time, in microseconds, required to transmit the pending frame, plus one CTS frame, plus one 25 ACK frame if requiredplus three SIFS intervals. 26 27 — Otherwise, the duration value is set to the remaining duration of the TXOP. 28 29 For all RTS frames sent under HCCA, the duration value is set to one of the following values: 30 — If the pending frame is the final frame, the duration value is set to the time, in microseconds, required 31 32 to transmit the pending frame, plus one CTS frame, plus one ACK frame if required, plus three SIFS 33 intervals. 34 — If the pending frame is not the final frame in the TXOP, the duration value is set to the remaining 35 36 duration of the TXOP. 37 38 7.2.1.2 CTS frame format 39 40 Change the third to the sixth paragraphs of 7.2.1.2 as follows: 41 42 43 For all CTS frames transmitted by a non-QoS STA sent in response to RTS frames, the duration value is the 44 value obtained from the Duration field of the immediately previous RTS frame, minus the time, in microsec- 45 onds, required to transmit the CTS frame and its SIFS interval. If the calculated duration includes a fractional 46 microsecond, that value is rounded up to the next higher integer. 47 48 49 At a non-QoS STA, if the CTS is the first frame in the exchange and the pending data or management frame 50 requires acknowledgment, the duration value is the time, in microseconds, required to transmit the pending 51 data or management frame, plus two SIFS intervals plus one ACK frame. At a non-QoS STA, if the CTS is 52 the first frame in the exchange and the pending data or management frame does not require acknowledgment, 53 54 the duration value is the time, in microseconds, required to transmit the pending data or management frame, 55 plus one SIFS interval. If the calculated duration includes a fractional microsecond, that value is rounded up 56 to the next higher integer. 57 58 For other CTS transmissions by a QoS STA, the duration value is set as defined in 7.1.4. 59 60 61 For all CTS frames sent by STAs as the first frame in the exchange under EDCA, the duration value is set in 62 the following manner: 63 64 — If the NAV protection is desired for only the first or sole frame in the TXOP the duration value is set 65 to

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 — The time, in microseconds, required to transmit the pending frame, plus one SIFS interval, plus 2 the response frame (ACK or Block Ack), plus an additional SIFS interval, if there is a response 3 frame, or 4 5 — The time, in microseconds, required to transmit the pending frame, plus one SIFS interval, if 6 there is no response frame. 7 8 — Otherwise, the duration value is set to the remaining duration of the TXOP. 9 10 For CTS frames sent under HCCA, the duration value is set to one of the following values: 11 12 — If the pending frame is the sole frame in the TXOP, the duration value is set to 13 — The time, in microseconds, required to transmit the pending frame, plus one SIFS interval, plus 14 the response frame (ACK or Block Ack), plus an additional SIFS interval, if there is a response 15 frame, or 16 17 — The time, in microseconds, required to transmit the pending frame, plus one SIFS interval, if 18 there is no response frame. 19 20 — If the pending frame is not the final frame in the TXOP, the duration value is set to the remaining 21 duration of the TXOP. 22 23 7.2.1.3 ACK frame format 24 25 26 Change the third paragraph of 7.2.1.3 as follows: 27 28 For ACK frames sent by non-QoS STAs, if the More Fragments bit was set to 0 in the Frame Control field of 29 the immediately previous directed data or management frame, the duration value is set to 0. In all other ACK 30 frames sent by non-QoS STAs, the duration value is the value obtained from the Duration/ID field of the im- 31 32 mediately previous data, management, PS-Poll, BlockAckReq, or BlockAck frame minus the time, in micro- 33 seconds, required to transmit the ACK frame and its SIFS interval. If the calculated duration includes a 34 fractional microsecond, that value is rounded up to the next higher integer. 35 36 In all other ACK frames, the duration value is specified by 7.1.4. 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Change the heading of 7.2.1.7 as follows: 2 3 4 7.2.1.7 Block Ack Request (BlockAckReq) frame format 5 6 Insert the following heading immediately after the heading 7.2.1.7: 7 8 9 7.2.1.7.1 Overview of the BlockAckReq frame format 10 11 Replace Figure 7-12 with the following figure: 12 13 14 EDITORIAL NOTE—The changes comprise renaming the “Block Ack Starting Sequence Control” field 15 to “BAR Information”. 16 17 18 19 Octets: 2 2 6 6 2 Variable 4 20 21 Frame BAR BAR Duration/ID RA TA FCS 22 Control Control Information 23 24 25 26 MAC Header 27 28 29 Figure 7-12—BlockAckReq frame 30 31 32 33 Replace Figure 7-13 with the following figure: 34 35 EDITORIAL NOTE—The changes comprise the addition of BAR Ack Policy, Multi-TID and 36 37 Compressed Bitmap fields from the reserved field and renaming the TID field to TID_INFO. 38 39 40 41 B0 B1 B2 B3 B11 B12 B15 42 BAR Ack Compressed 43 Multi-TID Reserved TID_INFO 44 Policy Bitmap 45 Bits: 1 1 1 9 4 46 47 48 Figure 7-13—BAR Control field 49 50 51 52 Change the second paragraph of the new 7.2.1.7.1 as follows: (this change also deletes footnote 16). 53 54 The Duration/ID field value is set as defined in 7.1.4. 55 56 57 The Duration/ID field value is greater than or equal to the time16, in microseconds, required to transmit one 58 59 ACK or BlockAck frame, as applicable, plus one SIFS interval. If the calculated duration includes a fractional 60 microsecond, that value is rounded up to the next higher integer. 61 62 63 16To allow the possibility of time remaining in the TXOP, which the sender may use to schedule other trans- 64 65 missions

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Delete the sixth paragraph of the new 7.2.1.7.1 starting “The TID subfield…” 2 3 Delete the seventh paragraph of the new 7.2.1.7.1 starting “The Block Ack Starting Sequence Control…” 4 5 6 Insert the following text, Table 7-6h, Table 7-6i and subclause (7.2.1.7.2) after the now deleted seventh 7 paragraph of the new 7.2.1.7.1:, i.e. just before Figure 7-14. 8 9 10 The BAR Ack Policy subfield has the meaning shown in Table 7-6h. 11 12 Table 7-6h—BAR Ack Policy subfield 13 14 15 Value Meaning 16 17 Normal Acknowledgement. 18 The BAR Ack Policy field is set to this value when the sender requires immediate acknowledge- 19 ment. 0 20 The addressee returns an ACK. 21 22 See 9.16.1.7. 23 24 No Acknowledgement 25 The addressee sends no immediate response upon receipt of the frame. 26 The BAR Ack Policy is set to this value when the sender does not require immediate acknowl- 27 1 edgement. 28 29 The value 1 is not used in a Basic BlockAckReq frame outside a PSMP sequence. 30 The value 1 is not used in an Multi-TID BlockAckReq frame. 31 32 33 34 The values of the Multi-TID and Compressed Bitmap fields determine which of three possible BlockAckReq 35 36 frame variants is represented, as indicated in Table 7-6i. 37 38 39 Table 7-6i—BlockAckReq frame variant encoding 40 41 42 Compressed Multi-TID BlockAckReq frame variant 43 Bitmap 44 45 0 0 Basic BlockAckReq 46 47 0 1 Compressed BlockAckReq 48 49 10Reserved 50 1 1 Multi-TID BlockAckReq 51 52 53 54 55 The meaning of the TID_INFO subfield of the BAR Control field depends on the BlockAckReq frame variant 56 type. The meaning of this subfield is explained within the subclause for each of the BlockAckReq frame vari- 57 58 ants. 59 60 The meaning of the BAR Information field depends on the BlockAckReq frame variant type. The meaning 61 62 of this field is explained within the subclause for each of the BlockAckReq frame variants. 63 NOTE—Reference to “a BlockAckReq” frame without any other qualification from other subclauses applies to any of 64 65 the variants, unless specific exclusions are called out.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 7.2.1.7.2 Basic BlockAckReq variant 2 3 4 The TID_INFO subfield of the BAR Control field of the Basic BlockAckReq frame contains the TID for 5 which a Basic BlockAck frame is requested. 6 7 8 The BAR Information within the Basic BlockAckReq frame comprises the Block Ack Starting Sequence 9 10 Control field, as shown in Figure 7-14. The Starting Sequence number subfield is the sequence number of the 11 first MSDU for which this Basic BlockAckReq is sent. The Fragment Number subfield is set to 0. 12 13 14 EDITORIAL NOTE—The editing instructions above result in Figure 7-14 appearing at this point. 15 16 Insert the following subclauses (7.2.1.7.3 to 7.2.1.7.4) after 7.2.1.7.2: 17 18 19 7.2.1.7.3 Compressed BlockAckReq variant 20 21 The TID_INFO subfield of the BAR Control field of the Compressed BlockAckReq frame contains the TID 22 23 for which a BlockAck frame is requested. 24 25 26 The BAR Information field within the Compressed BlockAckReq frame comprises the Block Ack Starting 27 28 Sequence Control field, as shown in Figure 7-14. The Starting Sequence number subfield of the Block Ack 29 Starting Sequence Control field is the sequence number of the first MSDU or A-MSDU for which this Block- 30 31 AckReq is sent. The Fragment Number subfield of the Block Ack Starting Sequence Control field is set to 0. 32 33 34 7.2.1.7.4 Multi-TID BlockAckReq variant 35 36 The TID_INFO subfield of the BAR Control field of the Multi-TID BlockAckReq frame determines the num- 37 38 ber of TIDs present in the Multi-TID BlockAckReq frame as given by TID_INFO + 1, i.e., a value of 2 in the 39 40 TID_INFO field means that there are 3 TID values present in the Multi-TID BlockAckReq frame’s BAR In- 41 42 formation field. 43 44 The BAR Information field of the Multi-TID BlockAckReq frame comprises multiple sets of Per TID Info 45 46 fields and Block Ack Starting Sequence Control fields, as shown in Figure 7-13a. The Per TID Info field is 47 48 shown in Figure 7-13b. The Block Ack Starting Sequence Control field is shown in Figure 7-14. The Starting 49 Sequence Number subfield of the Block Ack Starting Sequence Control field contains the sequence number 50 51 of the first MSDU or A-MSDU for which this BlockAckReq is sent. The Fragment Number subfield of the 52 53 Block Ack Starting Sequence Control field is set to 0. 54 55 56 Octets: 2 2 57 Per TID 58 Block Ack Starting Sequence Control 59 Info 60 61 62 Repeat for each TID 63 64 65 Figure 7-13a—BAR Information field (Multi-TID BlockAckReq)

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 2 B0 B11 B12 B15 3 4 Reserved TID Value 5 6 Bits: 12 4 7 8 Figure 7-13b—Per TID Info field 9 10 11 Change the heading of 7.2.1.8 as follows: 12 13 14 7.2.1.8 Block Ack (BlockAck) frame format 15 16 Insert the following heading (7.2.1.8.1) immediately after the heading 7.2.1.8: 17 18 19 7.2.1.8.1 Overview of the BlockAck frame format 20 21 Replace Figure 7-15 with the following figure: 22 23 EDITORIAL NOTE—The changes merge the Block Ack Starting Sequence Control and Block Ack 24 25 Bitmap fields into the BA Information field. 26 27 28 Octets: 2 2 6 6 2 variable 4 29 30 Frame Control Duration / ID RA TA BA Control BA Information FCS 31 32 33 MAC Header 34 35 36 Figure 7-15—BlockAck frame 37 38 39 Replace Figure 7-16 with the following figure: 40 41 42 EDITORIAL NOTE—the changes comprise adding BA Ack Policy, Multi-TID and Compressed Bitmap 43 fields from the former reserved field and renaming the TID field to TID_INFO.: 44 45 46 47 B0 B1 B2 B3 B11 B12 B15 48 BA Ack Multi- Compressed 49 Reserved TID_INFO 50 Policy TID Bitmap 51 Bits: 1 1 1 9 4 52 53 54 Figure 7-16—BA Control field 55 56 57 58 Change the second paragraph of the new 7.2.1.8.1 as follows: (this change also deletes footnote 17) 59 60 The Duration/ID field value is set as defined in 7.1.4. 61 62 If the BlockAck frame is sent in response to the BlockAckReq frame, the Duration/ID field value is the value 63 64 obtained from the Duration/ID field of the immediate BlockAckReq frame, minus the time, in microseconds, 65 required to transmit the BlockAck frame and its SIFS interval. If the BlockAck frame is not sent in response

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 to the BlockAckReq, the Duration/ID field value is greater than (subject to the TXOP limit) or equal to the 2 17 3 time for transmission of an ACK frame plus a SIFS interval. If the calculated duration includes a fractional 4 microsecond, that value is rounded to the next higher integer. 5 6 17The default values for TXOP limit are expressed in milliseconds and are multiples of 32 µs. 7 8 9 Delete the sixth paragraph of the new 7.2.1.8.1 starting “The Block Ack Starting Sequence…” 10 11 Delete the seventh paragraph of the new 7.2.1.8.1 starting “The Block Ack Bitmap…” 12 13 Insert the following text and tables at the end of the new 7.2.1.8.1: 14 15 16 The BA Ack Policy subfield has the meaning shown in Table 7-6j. 17 18 19 Table 7-6j—BA Ack Policy subfield 20 21 22 Value Meaning 23 24 Normal Acknowledgement. 25 The BA Ack Policy field is set to this value when the sender requires immediate acknowledgement. 26 0 27 The addressee returns an ACK. 28 29 The value 0 is not used for data sent under HT-delayed BlockAck during a PSMP sequence. 30 31 No Acknowledgement. 32 The addressee sends no immediate response upon receipt of the frame. 33 The BA Ack Policy is set to this value when the sender does not require immediate acknowledge- 34 1 ment. 35 36 The value 1 is not used in a Basic BlockAck frame outside a PSMP sequence. 37 The value 1 is not used in an Multi-TID BlockAck frame. 38 39 40 41 The values of the Multi-TID and Compressed Bitmap fields determine which of three possible BlockAck 42 frame variants is represented, as indicated in the Table 7-6k. 43 44 45 Table 7-6k—BlockAck frame variant encoding 46 47 48 Compressed Multi-TID BlockAck frame variant 49 Bitmap 50 51 0 0 Basic BlockAck 52 53 0 1 Compressed BlockAck 54 55 10 Reserved 56 1 1 Multi-TID BlockAck 57 58 59 60 NOTE—Reference to “a BlockAck” frame without any other qualification from other subclauses applies to any of the 61 variants, unless specific exclusions are called out. 62 63 64 The meaning of the TID_INFO subfield of the BA Control field depends on the BlockAck frame variant type. 65 The meaning of this subfield is explained within the subclause for each of the BlockAck frame variants.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 The meaning of the BA Information field depends on the BlockAck frame variant type. The meaning of this 2 field is explained within the subclause for each of the BlockAck frame variants. 3 4 5 Insert the following subclauses (7.2.1.8.2 to 7.2.1.9) after 7.2.1.8.1: 6 7 7.2.1.8.2 Basic BlockAck variant 8 9 10 The TID_INFO subfield of the BA Control field of the Basic BlockAck frame contains the TID for which a 11 BlockAck frame is requested. 12 13 The BA Information field within the Basic BlockAck frame comprises the Block Ack Starting Sequence Con- 14 trol field and the Block Ack Bitmap, as shown in Figure 7-16a. The format of the Block Ack Starting Se- 15 16 quence Control field is shown in Figure 7-14. The Starting Sequence Number subfield of the Block Ack 17 Starting Sequence Control field is the sequence number of the first MSDU for which this Basic BlockAck is 18 sent, and is set to the same value as in the immediately previously received Basic BlockAckReq frame. 19 20 21 22 Octets: 2 128 23 24 Block Ack Starting Sequence Control Block Ack Bitmap 25 26 Figure 7-16a—BA Information field (BlockAck) 27 28 29 30 The Block Ack Bitmap field is 128 octets in length and is used to indicate the received status of up to 64 MS- 31 DUs. Bit position n of the Block Ack bitmap, if set to 1, acknowledges receipt of an MPDU with an MPDU 32 sequence control value equal to (Block Ack Starting Sequence Control + n). Bit position n of the Block Ack 33 bitmap, if set to 0, indicates that an MPDU with MPDU sequence control value equal to (Block Ack Starting 34 35 Sequence Control + n) has not been received. Both the MPDU Sequence Control and Block Ack Starting Se- 36 quence Control fields are treated as a 16-bit unsigned integer. For unused fragment numbers of an MSDU, 37 the corresponding bits in the bitmap are set to 0. 38 39 40 7.2.1.8.3 Compressed BlockAck variant 41 42 The TID_INFO subfield of the BA Control field of the Compressed BlockAck frame contains the TID for 43 which a BlockAck frame is requested. 44 45 46 The BA Information field within the Compressed BlockAck frame comprises the Block Ack Starting Se- 47 quence Control field and the Block Ack bitmap, as shown in Figure 7-16b. The Starting Sequence Number 48 subfield of the Block Ack Starting Sequence Control field is the sequence number of the first MSDU or A- 49 MSDU for which this BlockAck is sent. The value of this field is defined in 9.10.7.5. The Fragment Number 50 51 subfield of the Block Ack Starting Sequence Control field is set to 0. 52 53 54 Octets: 2 8 55 56 Block Ack Starting Sequence Control Block Ack Bitmap 57 58 59 Figure 7-16b—BA Information field (Compressed BlockAck) 60 61 62 The Block Ack bitmap within the Compressed BlockAck frame is 8 octets in length and is used to indicate 63 64 the received status of up to 64 MSDUs and A-MSDUs. Each bit that is set to 1 in the compressed Block Ack 65 Bitmap acknowledges the successful reception of a single MSDU or A-MSDU in the order of sequence num-

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 ber, with the first bit of the Block Ack Bitmap corresponding to the MSDU or A-MSDU with the sequence 2 number that matches the Block Ack Starting Sequence Control field Starting Sequence Number field value. 3 4 5 7.2.1.8.4 Multi-TID BlockAck variant 6 7 The TID_INFO subfield of the BA Control field of the Multi-TID BlockAck frame contains the number of 8 TIDs, less one, for which information is reported in the BA Information field. For example, a value of 2 in 9 10 the TID_INFO field means that information for 3 TIDs is present. 11 12 The BA Information field within the Multi-TID BlockAck frame comprises 1 or more instances of the Per 13 TID Info, Block Ack Starting Sequence Control field and the Block Ack bitmap, as shown in Figure 7-16c. 14 15 The Per TID Info field is shown in Figure 7-13b, the Block Ack Starting Sequence Control field is shown in 16 Figure 7-14. 17 18 The Starting Sequence Number subfield of the Block Ack Starting Sequence Control field is the sequence 19 number of the first MSDU or A-MSDU for which this BlockAck is sent. The value of this field is defined in 20 21 9.10.7.5. The Fragment Number subfield of the Block Ack Starting Sequence Control field is set to 0. The 22 first instance of the Per TID Info, Block Ack Starting Sequence Control and Block Ack Bitmap fields that is 23 transmitted corresponds to the lowest TID value, with subsequent instances following ordered by increasing 24 values of the Per TID Info field. 25 26 27 28 Octets: 2 2 8 29 30 Per TID Info Block Ack Starting Sequence Control Block Ack Bitmap 31 32 33 34 Repeat for each TID 35 36 37 Figure 7-16c—BA Information field (Multi-TID BlockAck) 38 39 40 The Block Ack bitmap within the Multi-TID BlockAck frame contains an 8-octet Block Ack Bitmap. Each 41 bit that is set to 1 in the Block Ack Bitmap acknowledges the successful reception of a single MSDU or A- 42 43 MSDU in the order of sequence number with the first bit of the Block Ack Bitmap corresponding to the 44 MSDU or A-MSDU with the sequence number that matches the Block Ack Starting Sequence Control field 45 Starting Sequence Number field value. 46 47 7.2.1.9 Control Wrapper frame 48 49 50 The format of the Control Wrapper frame is shown in Figure 7-16d. 51 52 Octets: 2 2 6 2 4 variable 4 53 Frame Control Duration /ID Address 1 Carried Frame Control HT Control Carried Frame FCS 54 55 Figure 7-16d—Control Wrapper frame 56 57 The Control Wrapper frame is used to carry any other control frame (i.e., excluding the Control Wrapper 58 59 frame) together with a High Throughput Control field. 60 61 The Frame control field is defined in 7.2.1. The value for the subtype field is the value from Table 7-1 of 62 7.1.3.1.2 that corresponds to Control Frame Wrapper. 63 64 65 The value for the Duration/ID field of the Control Wrapper frame is generated by following the rules for the

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Duration/ID field of the control frame that is being carried. 2 3 The value for the Address 1 field of the Control Wrapper frame is generated by following the rules for the 4 5 Address 1 field of the control frame that is being carried. 6 7 The Carried Frame Control field contains the value of the Frame Control field of the carried control frame. 8 9 The Carried Frame field contains the fields that follow the Address 1 field of the control frame that is being 10 11 carried, excluding the FCS field. 12 13 The HT Control field is defined in 7.1.3.5a. 14 15 The FCS field is defined in 7.1.3.7. 16 17 18 7.2.2 Data frames 19 20 Insert the following heading (7.2.2.1) immediately after the heading 7.2.2: 21 22 23 7.2.2.1 Data frame format 24 25 Replace Figure 7-17 with the following figure: 26 27 EDITORIAL NOTE—The changes comprise the addition of the HT Control field and the change in the 28 frame body length. 29 30 31 32 Octets: 33 2 6 6 6 2 6 2 4 0-7955 4 2 34 35 Frame Duration / Address Address Address Sequence QoS HT Frame Address 4 FCS 36 Control ID 1 2 3 Control Control Control Body 37 38 39 40 MAC Header 41 42 43 Figure 7-17—Data frame 44 45 46 Change the fourth paragraph formerly of 7.2.2 as follows: 47 48 49 The content of the address fields of data frames are dependent upon the values of the To DS and From DS 50 fields in the Frame Control field and whether the Frame Body field contains either an MSDU (or fragment 51 thereof) or an entire A-MSDU, as determined by the A-MSDU Present subfield of the QoS Control field (see 52 7.1.3.5.8). The contents of the address fields are defined in Table 7-7. Where the content of a field is shown 53 54 as not applicable (N/A), the field is omitted. Note that Address 1 always holds the receiver address of the in- 55 tended receiver (or, in the case of multicast group addressed frames, receivers), and that Address 2 always 56 holds the address of the STA that is transmitting the frame. 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Change Table 7-7 as follows: 2 3 4 Table 7-7—Address field contents 5 6 7 Address 3 Address 4 8 To From Address 1 Address 2 9 DS DS 10 MSDU case A-MSDU case MSDU case A-MSDU case 11 12 0 0 RA = DA TA = SA BSSID BSSID N/A N/A 13 0 1 RA = DA TA = BSSID SA BSSID N/A N/A 14 15 1 0 RA = BSSID TA = SA DA BSSID N/A N/A 16 17 1 1 RA TA DA BSSID SA BSSID 18 19 20 21 Change the seventh and eighth paragraphs formerly of 7.2.2 as follows: 22 23 The DA field is the destination of the MSDU (or fragment thereof) or A-MSDU in the Frame Body field. 24 25 26 The SA field is the address of the MAC entity that initiated the MSDU (or fragment thereof) or A-MSDU in 27 the Frame Body field. 28 29 Insert the following two new paragraphs and note after paragraph eight formerly of 7.2.2: 30 31 32 When a data frame carries an MSDU (or fragment thereof), the DA and SA values related to that MSDU are 33 carried in the Address 1, Address 2, Address 3 and Address 4 fields (according to the setting of the To DS 34 and From DS fields) as defined in Table 7-7. 35 36 37 When a data frame carries an A-MSDU, DA and SA values related to each MSDU carried by the A-MSDU 38 are carried within the A-MSDU. One or both of these fields may also be present in the Address 1 and Address 39 2 fields as indicated in Table 7-7. 40 NOTE—If a DA or SA value also appears in any of these address fields, the value is necessarily the same for all MSDUs 41 within the A-MSDU because this is guaranteed by the To DS and From DS field settings. 42 43 Insert the following paragraph after paragraph 13 formerly of 7.2.2 containing “The QoS Control field is 44 45 defined in 7.1.3.5.”: 46 47 The HT Control field is defined in 7.1.3.5a. The presence of the HT Control field is determined by the Order 48 subfield of the Frame Control field, as specified in 7.1.3.1.9. 49 50 Change paragraphs 14 to 16 formerly of 7.2.2 as follows: 51 52 53 The frame body consists of the MSDU (or a fragment thereof) or A-MSDU, and a security header and trailer 54 (if and only if the Protected Frame subfield in the Frame Control field is set to 1). The frame body is null (0 55 octets in length) in data frames of subtype Null (no data), CF-Ack (no data), CF-Poll (no data), and CF- 56 57 Ack+CF-Poll (no data), regardless of the encoding of the QoS subfield in the Frame Control field. The pres- 58 ence of an A-MSDU in the frame body is indicated by setting the A-MSDU Present subfield of the QoS con- 59 trol field to 1, as shown in Table 7-4. 60 61 EDITORIAL NOTE—Note that the changes in this paragraph, amongst others, correct CF+Poll to CF- 62 Poll, however the “+” character with strikeout is hard to distinguish. 63 64 65 For data frames of subtype Null (no data), CF-Ack (no data), CF-Poll (no data), and CF-Ack+CF-Poll (no

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 data) and for the corresponding QoS data frame subtypes, the Frame Body field is null (i.e., has a length of 0 2 octets) omitted; these subtypes are used for MAC control purposes. For data frames of subtypes Data, Da- 3 ta+CF-Ack, Data+CF-Poll, and Data+CF-Ack+CF+-Poll, and for the corresponding four QoS data frame 4 5 subtypes, the Frame Body field contains all of, or a fragment of, an MSDU after any encapsulation for secu- 6 rity. For data frames of subtypes QoS Data, QoS Data+CF-Ack, QoS Data+CF-Poll, and QoS Data+CF- 7 Ack+CF-Poll the Frame Body field contains an MSDU (or fragment thereof) or A-MSDU after any encapsu- 8 lation for security. 9 10 11 The maximum length of the Frame Body field can be determined from the maximum MSDU or A-MSDU 12 length plus any overhead from encapsulation for encryption (i.e., it is always possible to send a maximum 13 length MSDU, with any encapsulations provided by the MAC layer within a single data MPDU). When the 14 15 frame body carries an A-MSDU, the size of the frame body field may be limited by: 16 — the PHY’s maximum PSDU length, 17 18 — if A-MPDU aggregation is used, the maximum MPDU length is limited to 4095 octets (see 7.4a). 19 20 Insert the following subclause (7.2.2.2) after 7.2.2.1: 21 22 23 7.2.2.2 Aggregate MSDU format (A-MSDU) 24 25 26 An A-MSDU is a sequence of A-MSDU subframes as shown in Figure 7-17a. Each A-MSDU subframe con- 27 sists of an A-MSDU subframe header followed by an MSDU and 0-3 octets of padding as shown in Figure 28 7-17b. Each A-MSDU subframe (except the last) is padded so that its length is a multiple of 4 octets. The last 29 A-MSDU subframe has no padding. 30 31 32 The A-MSDU subframe header contains three fields: Destination Address (DA), Source Address (SA), and 33 Length. The order of these fields and the bits within these fields is the same as the IEEE 802.3 frame format. 34 The DA and SA fields of the A-MSDU subframe header contain the values passed in the MA-UNITDATA.re- 35 36 quest and MA-UNITDATA.indication primitives. The Length field contains the length in octets of the MS- 37 DU. 38 39 40 41 A-MSDU subframe 1 A-MSDU subframe 2 … A-MSDU subframe n 42 43 Figure 7-17a—A-MSDU structure 44 45 46 47 Octets: 6 6 2 0-2304 0-3 48 49 DA SA Length MSDU Padding 50 51 52 53 A-MSDU subframe header 54 55 Figure 7-17b—A-MSDU subframe structure 56 57 58 59 An A-MSDU only contains MSDUs whose DA and SA parameter values map to the same RA and TA values, 60 i.e., all the MSDUs are intended to be received by a single receiver, and necessarily they are all transmitted 61 by the same transmitter. The rules for determining RA and TA are independent of whether the Frame Body 62 63 carries an A-MSDU. 64 NOTE 1—It is possible to have different DA and SA in A-MSDU subframe headers of the same A-MSDU as long as 65 they all map to the same Address 1 and Address 2 values.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 The MPDU containing the A-MSDU is carried in any of the following Data subtypes: QoS Data, QoS Data 2 + CF-Ack, QoS Data + CF-Poll, QoS Data + CF-Ack + CF-Poll. The A-MSDU structure is contained in the 3 Frame Body field of a single MPDU. If encrypted, the MPDU is encrypted as a single unit. 4 5 NOTE 2—The value of TID present in the QoS Control field of the MPDU carrying the A-MSDU indicates the TID for 6 all MSDUs in the A-MSDU. Because this value of TID is common to all MSDUs in the A-MSDU, only MSDUs deliv- 7 ered to the MAC by an MA-UNITDATA.request with an integer priority parameter that maps to the same TID can be 8 aggregated together using A-MSDU. 9 NOTE 3—The maximum MPDU length that can be transported using A-MPDU aggregation is 4095 octets. An A- 10 MSDU cannot be fragmented. So an A-MSDU of length that exceeds 4065 octets (4095 - QoS data MPDU overhead) 11 cannot be transported in an A-MPDU. 12 13 7.2.3 Management frames 14 15 16 EDITORIAL NOTE—The changes to Figure 7-18 comprise the addition of the HT C ontrol field. 17 18 Replace Figure 7-18 with the following: 19 20 21 22 Octets: 2 2 6 6 6 2 4 0-2312 4 23 24 Frame Address 1 Sequence HT Frame 25 Duration SA BSSID FCS Control (DA) Control Control Body 26 27 28 29 MAC Header 30 31 32 Figure 7-18—Management frame format 33 34 35 36 Change the first to the third paragraphs of 7.2.3 as follows: 37 38 A STA uses the contents of the Address 1 (DA) field to perform the address matching for receive decisions. 39 In the case where the Address 1 (DA) field contains a group address and the frame subtype is other than Bea- 40 con, the BSSID also is validated to ensure that the broadcast or multicast originated from a STA in the BSS 41 42 of which the receiving STA is a member. In the case where the Address 1 (DA) field contains a group address 43 and the frame subtype is either Probe Request or Action with Category Public, a wildcard BSSID value 44 matches all receiving STA’s BSSIDs. If the frame subtype is Beacon, other address matching rules apply, as 45 specified in 11.1.2.3. Frames of subtype Probe Request with a group address in the Address 1 field are addi- 46 tionally processed as described in 11.1.3.2.1. If the frame subtype is Action, the Category is Public and the 47 48 Action is 20/40 BSS Coexistence Management, then additional address matching rules for receive decisions 49 apply as specified in 11.14 and 11.16. 50 51 The address fields for management frames do not vary by frame subtype. 52 53 54 The BSSID of the management frame is determined as follows: 55 a) In management frames of subtype Probe Request, the BSSID is either a specific BSSID as described 56 in item c) below, or the wildcard BSSID as defined in the procedures specified in 11.1.3. 57 58 b) In management frames of subtype Action, Category Public, the BSSID value is set according to 59 11.18. 60 61 c) Otherwise: 62 1)a) If the STA is an AP or is associated with an AP, the BSSID is the address currently in use by 63 the STA contained in the AP. 64 65 2)b) If the STA is a member of an IBSS, the BSSID is the BSSID of the IBSS.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 c) In management frames of subtype Probe Request, the BSSID is either a specific BSSID, or the wild- 2 3 card BSSID as defined in the procedures specified in 11.1.3. 4 5 Insert the following paragraph after the fourteenth paragraph of 7.2.3 (i.e., after the paragraph starting 6 7 “The duration value...”): 8 9 The HT Control field is defined in 7.1.3.5a. The presence of the HT Control field is determined by the Order 10 11 subfield of the Frame Control field, as specified in 7.1.3.1.9. 12 13 7.2.3.1 Beacon frame format 14 15 16 Change the rows for DS Parameter Set and CF Parameter Set in Table 7-8 as follows: 17 18 19 Table 7-8—Beacon frame body 20 21 22 Order Information Notes 23 24 7 DS Parameter Set The DS Parameter Set information element is present 25 within Beacon frames generated by STAs using Clause 15, 26 Clause 18, and Clause 19 PHYs, or if one of the rates 27 defined in Clause 15 or Clause 18 is being used to transmit 28 the beacon. 29 30 8 CF Parameter Set The CF Parameter Set information element is present only 31 within Beacon frames generated by APs supporting a 32 point coordination function (PCF). 33 This element shall not be present if 34 dot11HighThroughputOptionImplemented is TRUE and 35 the Dual CTS Protection field of the HT Operation ele- 36 ment is set to 1 37 38 39 40 Insert order 37 to 41 information fields into Table 7-8: 41 42 43 Table 7-8—Beacon frame body 44 45 46 Order Information Notes 47 48 37 HT Capabilities The HT Capabilities element is present when 49 dot11HighThroughputOptionImplemented attribute is 50 TRUE 51 52 38 HT Operation The HT Operation element is included by an AP when 53 dot11HighThroughputOptionImplemented attribute is 54 TRUE 55 56 39 20/40 BSS Coexistence The 20/40 BSS Coexistence element may be present when 57 the dot112040BSSCoexistenceManagementSupport 58 attribute is TRUE. 59 60 40 Overlapping BSS Scan The Overlapping BSS Scan Parameters element may be 61 Parameters present if the dot11FortyMHzOptionImplemented 62 attribute is TRUE. 63 64 41 Extended CapabilitiesThe Extended Capabilities element may be present if any 65 of the fields in this element are non-zero.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 7.2.3.4 Association Request frame format 2 3 Insert order 13 to 15 information fields into Table 7-10: 4 5 6 7 Table 7-10—Association Request frame body 8 9 10 Order Information Notes 11 12 13 HT Capabilities The HT Capabilities element is present when 13 dot11HighThroughputOptionImplemented attribute is 14 TRUE 15 16 14 20/40 BSS Coexistence The 20/40 BSS Coexistence element may be present when 17 the dot112040BSSCoexistenceManagementSupport 18 attribute is TRUE. 19 15 Extended CapabilitiesThe Extended Capabilities element may be present if any 20 of the fields in this element are non-zero. 21 22 23 24 7.2.3.5 Association Response frame format 25 26 27 Insert order 14 to 18 information fields into Table 7-11: 28 29 30 Table 7-11—Association Response frame body 31 32 33 Order Information Notes 34 35 14 HT Capabilities The HT Capabilities element is present when 36 dot11HighThroughputOptionImplemented attribute is 37 TRUE. 38 39 15 HT Operation The HT Operation element is included by an AP when 40 dot11HighThroughputOptionImplemented attribute is 41 TRUE. 42 43 16 20/40 BSS Coexistence The 20/40 BSS Coexistence element may be present when 44 the dot112040BSSCoexistenceManagementSupport 45 attribute is TRUE. 46 17 Overlapping BSS Scan The Overlapping BSS Scan Parameters element may be 47 Parameters present if the dot11FortyMHzOptionImplemented 48 attribute is TRUE.. 49 50 18 Extended CapabilitiesThe Extended Capabilities element may be present if any 51 of the fields in this element are non-zero. 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 7.2.3.6 Reassociation Request frame format 2 3 Insert order 16 to 18 information fields into Table 7-12: 4 5 6 7 Table 7-12—Reassociation Request frame format 8 9 10 Order Information Notes 11 12 16 HT Capabilities The HT Capabilities element is present when 13 dot11HighThroughputOptionImplemented attribute is 14 TRUE. 15 16 17 20/40 BSS Coexistence The 20/40 BSS Coexistence element may be present when 17 the dot112040BSSCoexistenceManagementSupport 18 attribute is TRUE. 19 18 Extended CapabilitiesThe Extended Capabilities element may be present if any 20 of the fields in this element are non-zero. 21 22 23 24 7.2.3.7 Reassociation Response frame format 25 26 27 Insert order 16 to 20 information fields into Table 7-13: 28 29 30 Table 7-13—Reassociation Response frame body 31 32 33 Order Information Notes 34 35 16 HT Capabilities The HT Capabilities element is present when 36 dot11HighThroughputOptionImplemented attribute is 37 TRUE. 38 39 17 HT Operation The HT Operation element is included by an AP when 40 dot11HighThroughputOptionImplemented attribute is 41 TRUE. 42 43 18 20/40 BSS Coexistence The 20/40 BSS Coexistence element may be present when 44 the dot112040BSSCoexistenceManagementSupport 45 attribute is TRUE. 46 19 Overlapping BSS Scan The Overlapping BSS Scan Parameters element may be 47 Parameters present if the dot11FortyMHzOptionImplemented 48 attribute is TRUE. 49 50 20 Extended CapabilitiesThe Extended Capabilities element may be present if any 51 of the fields in this element are non-zero. 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 7.2.3.8 Probe Request frame format 2 3 Insert order 7 to 9 information fields into Table 7-14: 4 5 6 7 Table 7-14—Probe Request frame body 8 9 10 Order Information Notes 11 12 7 HT Capabilities The HT Capabilities element is present when 13 dot11HighThroughputOptionImplemented attribute is 14 TRUE. 15 16 8 20/40 BSS Coexistence The 20/40 BSS Coexistence element may be present when 17 the dot112040BSSCoexistenceManagementSupport 18 attribute is TRUE. 19 9 Extended Capabilities The Extended Capabilities element may be present if any 20 of the fields in this element are non-zero. 21 22 23 24 7.2.3.9 Probe Response frame format 25 26 27 Insert order 35 to 39 information fields into Table 7-15: 28 29 30 Table 7-15—Probe Response frame body 31 32 33 Order Information Notes 34 35 35 HT Capabilities The HT Capabilities element is present when 36 dot11HighThroughputOptionImplemented attribute is 37 TRUE 38 39 36 HT Operation The HT Operation element is included by an AP when 40 dot11HighThroughputOptionImplemented attribute is 41 TRUE. 42 43 37 20/40 BSS Coexistence The 20/40 BSS Coexistence element may be present when 44 the dot112040BSSCoexistenceManagementSupport 45 attribute is TRUE. 46 47 38 Overlapping BSS Scan The Overlapping BSS Scan Parameters element may be 48 Parameters present if the dot11FortyMHzOptionImplemented attribute 49 is TRUE.. 50 39 Extended Capabilities The Extended Capabilities element may be present if any of 51 the fields in this element are non-zero. 52 53 54 55 Insert the following subclause (7.2.3.13) after 7.2.3.12: 56 57 58 7.2.3.13 Action No Ack frame format 59 60 The frame body of a management frame of subtype Action No Ack contains the information shown in Table 61 7-19a. 62 63 NOTE—The selection of Action or Action No Ack is made per frame that uses these formats. 64 65 Unless specified as allowing the use of the Action No Ack management subtype, a frame described as an “Ac-

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table 7-19a—Action No Ack frame body 2 3 4 Order Information 5 6 1Action 7 8 Last One or more vendor-specific information elements may appear in this frame. 9 This information element follows all other information elements. 10 11 12 13 tion frame” uses only the Action subtype. 14 15 16 7.3 Management frame body components 17 18 7.3.1 Fields that are not information elements 19 20 21 7.3.1.7 Reason Code field 22 23 Insert reason code 31 and change the Reserved reason code row (25-31) in Table 7-22 as follows (note 24 that the entire table is not shown here): 25 26 27 28 Table 7-22—Reason codes 29 30 31 Reason code Meaning 32 33 25-301 Reserved 34 35 31 TS deleted because QoS AP lacks sufficient bandwidth for this QoS STA 36 due to a change in BSS service characteristics or operational mode (e.g., 37 an HT BSS change from 40 MHz channel to 20 MHz channel) 38 39 40 41 7.3.1.9 Status Code field 42 43 Change status code 27, insert status code 29 and change the Reserved status code (29-31) rows in Table 7- 44 45 23 as follows (note that the entire table is not shown here): 46 47 48 Table 7-23—Status codes 49 50 51 Status code Meaning 52 53 27 Reserved Association denied because the re- 54 questing STA does not support HT features 55 56 29 Association denied because the requesting STA 57 does not support the PCO transition time re- 58 quired by the AP. 59 60 2930-31 Reserved 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 7.3.1.11 Action field 2 3 4 Insert category code 7 and change the Reserved category code rows in Table 7-24 as follows (note that the 5 entire table is not shown here): 6 7 8 Table 7-24—Category Values 9 10 11 Code Meaning See subclause Robust 12 13 7 HT 7.4.10 No 14 15 78-126 Reserved - 16 17 18 19 7.3.1.14 Block Ack Parameter Set field 20 21 22 EDITORIAL NOTE—Figure 7-32 is changed below to replace the reserved value in B0 with “A-MSDU 23 Supported”. 24 25 Replace Figure 7-32 with the following 26 27 28 29 B0 B1 B2 B5 B6 B15 30 31 A-MSDU Block Ack Policy TID Buffer Size 32 Supported 33 34 35 Octets 36 2 37 38 Figure 7-32—Block Ack Parameter Set fixed field 39 40 41 42 Insert the following paragraph after the first paragraph of 7.3.1.14: 43 44 The A-MSDU Supported subfield determines whether an A-MSDU may be carried in a QoS data MPDU sent 45 46 under this Block Ack agreement. When set to 1, use of A-MSDU is permitted. When set to 0, use of A-MSDU 47 is not permitted. 48 49 Change the second to fourth paragraphs of 7.3.1.14 as follows: (note strikeout of a space in the third para- 50 51 graph resulting in “BlockAck”) 52 53 The Block Ack Policy subfield is set to 1 for immediate Block Ack and 0 for delayed Block Ack. The Block 54 Ack Policy subfield value assigned by the originator of the QoS data frames is advisory. 55 56 57 The TID subfield contains the value of the TC or TS for which the Block Ack is being requested. 58 59 60 The Buffer Size subfield indicates the number of buffers of size 2304 octets available for this particular 61 TID.18 When the A-MSDU Supported field is set to 0 as indicated by the STA transmitting the Block Ack 62 Parameter Set field, each buffer is capable of holding a number of octets equal to the maximum size of an 63 64 MSDU. When the A-MSDU Supported field is set to 1 as indicated by the STA, each buffer is capable of 65 holding a number of octets equal to the maximum size of an A-MSDU that is supported by the STA.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Change footnote 18 in 7.3.1.14 as follows: 2 3 18For buffer size, the recipient of data advertises a scalar number that is the number of maximum-size frag- 4 ment buffers of the maximum MSDU or A-MSDU size (indicated by the A-MSDU Supported field) availa- 5 6 ble for the Block Ack agreement that is being negotiated. Every buffered MPDU that is associated with this 7 BlockAck agreement will consume one of these buffers regardless of whether the frame contains a whole 8 MSDU (or a fragment of an MSDUthereof) or an A-MSDU. In other wordsFor example, ten maximum-size 9 10 unfragmented MSDUs will consume the same amount of buffer space at the recipient as 10ten smaller frag- 11 ments of a single MSDU of maximum size. 12 13 7.3.1.17 QoS Info field 14 15 16 Change paragraph 10 of 7.3.1.17 as follows: 17 18 19 The Max SP Length subfield is 2 bits in length and indicates the maximum number of total buffered MSDUs, 20 A-MSDUs and MMPDUs the AP may deliver to a non-AP STA during any SP triggered by the non-AP STA. 21 This subfield is reserved when the APSD subfield in the Capability Information field is set to 0. This subfield 22 23 is also reserved when all four U-APSD flags are set to 0. If the APSD subfield in the Capability Information 24 field is set to 1 and at least one of the four U-APSD flags is set to 1, the settings of the values in the Max SP 25 26 Length subfield are defined in Table 7-25. 27 28 Change Table 7-25 as follows: 29 30 31 Table 7-25—Settings of the Max SP Length subfield 32 33 34 35 Bit 5 Bit 6 Usage 36 37 00AP may deliver all buffered MSDUs, A-MSDUs and MMPDUs. 38 39 10AP may deliver a maximum of two MSDUs, A-MSDUs and 40 MMPDUs per SP. 41 42 01AP may deliver a maximum of four MSDUs, A-MSDUs and 43 MMPDUs per SP. 44 45 11AP may deliver a maximum of six MSDUs, A-MSDUs and 46 MMPDUs per SP. 47 48 49 50 Insert the following subclauses (7.3.1.21 to 7.3.1.30) after 7.3.1.20: 51 52 53 7.3.1.21 Channel Width field 54 55 The Channel Width field is used in a Notify Channel Width frame (see 7.4.10.2) to indicate the channel 56 57 width on which the sending STA is able to receive. The length of the field is 1 octet. The Channel Width 58 field is illustrated in Figure 7-36d. 59 60 61 If a STA transmitting or receiving this field is operating in a regulatory class that includes a value of 13 or 14 62 in the behavior limits as specified in Annex J, then the values of the Channel Width field are defined in Table 63 7-25a. If a STA transmitting or receiving this field is operating in a regulatory class that does not include a 64 65 value of 13 or 14 in the behavior limits as specified in Annex J, then this field is reserved.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 2 B0 B7 3 4 Channel Width 5 6 Octets 7 1 8 9 10 Figure 7-36d—Channel Width fixed field 11 12 13 Table 7-25a—Settings of the Channel Width field 14 15 16 Value Meaning 17 18 0 20 MHz channel width 19 20 1 Any channel width in the STA’s Supported Channel Width Set 21 22 2-255 Reserved 23 24 25 26 7.3.1.22 Spatial Multiplexing (SM) Power Control field 27 28 The SM Power Control field is used in an SM Power Save frame (see 7.4.10.3) by a STA to communicate 29 30 changes in its SM power saving state. The field is 1 octet in length and is illustrated in Figure 7-36e. 31 32 33 34 B0 B1 B2 B7 35 36 SM Power Save Enabled SM Mode Reserved 37 38 39 Octets 40 1 41 42 Figure 7-36e—SM Power Control fixed field 43 44 45 46 The SM Power Save Enabled field indicates whether SM power saving is enabled at the STA. A value of 1 47 48 indicates enabled, and a value of 0 indicates disabled. 49 50 The SM Mode field indicates the mode of operation. A value of 1 indicates Dynamic SM Power Save mode, 51 52 a value of 0 indicates Static SM Power Save mode. The modes are described in 11.2.3. 53 54 55 7.3.1.23 Phased coexistence operation (PCO) Phase Control field 56 57 The PCO Phase Control field is used in a Set PCO Phase frame (see 7.4.10.5) to indicate the phase of PCO 58 59 operation (see 11.15). The length of the field is 1 octet. The PCO Phase control field is illustrated in Figure 60 61 7-36f. 62 63 The PCO Phase Control field indicates the current PCO phase. The values of the PCO Phase Control field are 64 65 defined in Table 7-25b.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 2 B0 B7 3 4 PCO Phase Control 5 6 7 Octets 8 1 9 10 Figure 7-36f—PCO Phase Control fixed field 11 12 13 14 Table 7-25b—Settings of the PCO Phase Control field 15 16 Value Meaning 17 18 19 0 20 MHz phase 20 1 40 MHz phase 21 22 2-255 Reserved 23 24 25 26 7.3.1.24 Power save multi-poll (PSMP) Parameter Set field 27 28 29 The PSMP Parameter Set field is used in a PSMP frame (see 7.4.10.4) to define the number of PSMP STA 30 Info records held in the PSMP frame, to indicate whether the PSMP sequence is to be followed by another 31 and to indicate the duration of the PSMP sequence. 32 33 34 The PSMP Parameter Set field is 2 octets in length. The structure of the PSMP Parameter Set field is defined 35 in Figure 7-36g. 36 37 38 39 B0 B4 B5 B6 B15 40 41 42 N_STA More PSMP PSMP Sequence Duration 43 44 45 Octets: 46 2 47 48 Figure 7-36g—PSMP Parameter Set fixed field 49 50 51 52 The N_STA field indicates the number of STA Info fields present in the PSMP frame that contains the PSMP 53 Parameter Set field. 54 55 56 The More PSMP field, when set to 1, indicates that the current PSMP sequence will be followed by another 57 PSMP sequence. A value of 0 indicates that there will be no PSMP sequence following the current PSMP 58 sequence. 59 60 61 The PSMP Sequence Duration field indicates the duration of the current PSMP sequence that is described by 62 the PSMP frame, in units of 8 µs, relative to the end of the PSMP frame. Therefore, this field can describe a 63 64 PSMP sequence with a duration of up to 8.184 ms. The next PSMP sequence within the current PSMP burst 65 starts a SIFS interval after the indicated duration.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 7.3.1.25 PSMP STA Info field 2 3 The PSMP STA Info field is used by the PSMP frame (see 7.4.10.4). The PSMP STA Info field defines the 4 5 allocation of time to the downlink (PSMP-DTT) and/or uplink (PSMP-UTT) associated with a single 6 receiver address. There are two variants of the structure for the individually addressed and group addressed 7 cases. The length of the PSMP STA Info field is 8 octets. 8 9 10 The structure of the STA Info field is defined in Figure 7-36h and Figure 7-36i. 11 12 B0 B1 B2 B12 B13 B20 B21 B63 13 14 STA_INFO PSMP-DTT PSMP-DTT PSMP Group 15 Type Start Offset Duration Address ID 16 (=1) 17 18 Octets: 8 19 20 Figure 7-36h—PSMP STA Info fixed field (group addressed) 21 22 B0 B1 B2 B12 B13 B20 B21 B36 B37 B47 B48 B57 B58 B63 23 24 STA_INFO PSMP-DTT PSMP-DTT STA_ID PSMP-UTT PSMP-UTT Reserved 25 Type Start Offset Duration Start Offset Duration 26 (=2) 27 28 Octets: 8 29 30 Figure 7-36i—PSMP STA Info fixed field (individually addressed) 31 32 The STA_INFO Type field indicates the format of the remainder of the structure. When STA_INFO Type is 33 set to 1, the PSMP STA Info field is structured as defined in Figure 7-36h, and supports the transmission of 34 group addressed data by the AP. When STA_INFO Type is set to 2, the PSMP STA Info field is structured 35 36 as defined in Figure 7-36i, and supports the exchange of data with a single STA. STA_INFO Type values 0 37 and 3 are reserved. 38 39 The PSMP-DTT Start Offset field indicates the start of the PSMP-DTT for the destination identified by the 40 PSMP STA Info field, relative to the end of the PSMP frame, in units of 4 µs. This field locates the start of 41 42 the first PPDU containing downlink data for this destination. 43 44 The PSMP-DTT Duration field indicates the duration of the PSMP-DTT for the destination identified by the 45 PSMP STA Info field, in units of 16 µs. This field locates the end of the last PPDU containing downlink data 46 47 for this destination relative to the PDMP-DTT Start Offset. 48 49 If no PSMP-DTT is scheduled for a STA, but a PSMP-UTT is scheduled for that STA, the PSMP-DTT Du- 50 ration is set to 0 and the PSMP-DTT Start Offset is reserved. 51 52 53 The STA_ID field contains the AID of the STA to which the PSMP STA Info field is directed. 54 55 The PSMP Group Address ID (B21 to B63) field contains the least significant 43 bits of a 48 bit MAC ad- 56 dress. Use of this field is described in 9.16.1.8. B63 contains the least significant bit of the group address (con- 57 58 sidering the Individual/Group bit to be the most significant bit). 59 60 The PSMP-UTT Start Offset field indicates the start of the PSMP-UTT. The offset is specified relative to the 61 end of the PSMP frame. It is specified in units of 4 µs. The first PSMP-UTT is scheduled to begin after a SIFS 62 interval from the end of the last PSMP-DTT described in the PSMP. 63 64 65 The PSMP-UTT Duration field indicates the maximum length of a PSMP-UTT for a STA. PSMP-UTT Du-

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 ration is specified in units of 4 µs. All transmissions by the STA within the current PSMP sequence lie within 2 3 the indicated PSMP-UTT. 4 5 If no PSMP-UTT is scheduled for a STA, but a PSMP-DTT is scheduled for that STA, the PSMP-UTT Start 6 7 Offset and PSMP-UTT Duration fields are both set to 0. 8 9 7.3.1.26 MIMO Control field 10 11 12 The MIMO Control field is used to manage the exchange of MIMO channel state or transmit beamforming 13 14 feedback information. It is used in the CSI (see 7.4.10.6), Non-compressed Beamforming (see 7.4.10.7) and 15 Compressed Beamforming (see 7.4.10.8) frames. 16 17 18 The MIMO Control field is 6 octets in length and is defined in Figure 7-36j. 19 20 21 22 B0 B1 B2 B3 B4 B5 B6 B7 B8 B9 B10 B11 B13 B14 B15 23 MIMO 24 Remaining Nc Nr Control Grouping Coefficient Codebook Sounding 25 Matrix Reserved Index Index Channel (Ng) Size Information Timestamp 26 Segment 27 Width 28 29 30 Octets: 2 4 31 32 33 Figure 7-36j—MIMO Control field 34 35 36 37 The subfields of the MIMO Control field are defined in Table 7-25c. 38 39 40 Table 7-25c—Subfields of the MIMO Control field 41 42 43 Subfield Description 44 45 Nc Index Indicates the number of columns in a matrix, less one 46 Set to 0 for Nc = 1 47 Set to 1 for Nc = 2 48 Set to 2 for Nc = 3 49 Set to 3 for Nc = 4 50 51 Nr Index Indicates the number of rows in a matrix, less one 52 Set to 0 for Nr = 1 53 Set to 1 for Nr = 2 54 Set to 2 for Nr = 3 55 Set to 3 for Nr = 4 56 57 MIMO Control Channel Indicates the width of the channel in which a measurement was made 58 Width Set to 0 for 20 MHz 59 Set to 1 for 40 MHz 60 61 Grouping (Ng) Number of carriers grouped into one: 62 Set to 0 for Ng=1 (No grouping) 63 Set to 1 for Ng=2 64 Set to 2 for Ng=4 65 The value 3 is reserved

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table 7-25c—Subfields of the MIMO Control field (continued) 2 3 4 Subfield Description 5 6 Coefficient Size Indicates the number of bits in the representation of the real and imaginary parts of 7 each element in the matrix. 8 9 For CSI feedback: 10 Set to 0 for Nb=4 11 Set to 1 for Nb=5 12 Set to 2 for Nb=6 13 Set to 3 for Nb=8 14 15 For Non-compressed beamforming matrix feedback: 16 Set 0 for Nb=4 17 Set 1 for Nb=2 18 Set 2 for Nb=6 19 Set 3 for Nb=8 20 21 Codebook Information Indicates the size of codebook entries: 22 Set to 0 for 1 bit for ψ, 3 bits for φ 23 Set to 1 for 2 bits for ψ, 4 bits for φ 24 Set to 2 for 3 bits for ψ, 5 bits for φ 25 Set to 3 for 4 bits for ψ, 6 bits for φ 26 27 Remaining Matrix Segment Contains the remaining segment number for the associated measurement report. 28 Valid range: 0 to 7. 29 Set to 0 for the last segment of a segmented report or the only segment of an unseg- 30 mented report. 31 Sounding Timestamp Contains the lower four octets of the TSF timer value sampled at the instant that 32 the MAC received the PHY-CCA.indication(IDLE) signal that corresponds to the 33 end of the reception of the sounding packet that was used to generate feedback 34 information contained in the frame. 35 36 37 38 7.3.1.27 CSI Report field 39 40 The CSI Report field is used by the CSI frame (see 7.4.10.6) to carry explicit channel state information to a 41 42 transmit beamformer, as described in 9.19.3. 43 44 The CSI Matrix fields in the CSI Report field shown in Table 7-25d and Table 7-25e are matrices whose el- 45 ements are taken from the CHAN_MAT parameter of RXVECTOR (see Table 20-1). 46 47 48 The structure of the field depends on the the value of the MIMO Control Channel width field. The CSI Report 49 field for 20 MHz has the structure defined in Table 7-25d. 50 51 where 52 53 Nb is the number of bits determined by the Coefficients Size field of the MIMO Control field 54 55 Nc is the number of columns in a CSI matrix determined by the Nc Index field of the MIMO Control 56 field 57 58 Nr is the number of rows in a CSI matrix determined by the Nr Index field of the MIMO Control field 59 60 The CSI Report field for 40 MHz has the structure defined in Table 7-25e. 61 62 The SNR values in Table 7-25d and Table 7-25e are encoded as an 8-bit two's complement value of 4 x 63 64 (SNR_average - 22), where SNR_average is the dB representation of linearly averaged values over the tones 65 represented. This encoding covers the SNR range from -10 dB to 53.75 dB in 0.25 dB steps.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table 7-25d—CSI Report field (20 MHz) 2 3 4 Field Size Meaning 5 6 SNR in receive chain 1 8 bits Signal to Noise Ratio in the first receive chain 7 of the STA sending the report. 8 9 ... 10 11 SNR in receive chain Nr 8 bits Signal to Noise Ratio in the Nr'th receive 12 chain of the STA sending the report. 13 CSI Matrix for carrier -28 3+2× Nb×Nc×Nr bits CSI Matrix (see Figure 7-36k) 14 15 ... 16 17 CSI Matrix for carrier -1 3+2× Nb×Nc×Nr bits CSI Matrix 18 19 CSI Matrix for carrier 1 3+2× Nb×Nc×Nr bits CSI Matrix 20 21 ... 22 CSI Matrix for carrier 28 3+2× Nb×Nc×Nr bits CSI Matrix 23 24 25 26 Table 7-25e—CSI Report field (40 MHz) 27 28 29 Field Size Meaning 30 31 SNR in receive chain 1 8 bits Signal to Noise Ratio in the first receive chain of 32 the STA sending the report. 33 34 ... 35 36 SNR in receive chain Nr 8 bits Signal to Noise Ratio in the Nr'th receive chain 37 of the STA sending the report. 38 CSI Matrix for carrier -58 3+2× Nb×Nc×Nr bits CSI Matrix (see Figure 7-36k) 39 40 ... 41 42 CSI Matrix for carrier -2 3+2× Nb×Nc×Nr bits CSI Matrix 43 44 CSI Matrix for carrier 2 3+2× Nb×Nc×Nr bits CSI Matrix 45 46 ... 47 CSI Matrix for carrier 58 3+2× Nb×Nc×Nr bits CSI Matrix 48 49 50 51 Grouping is a method that reduces the size of the CSI Report field by reporting a single value for each group 52 of Ng adjacent subcarriers. With grouping, the size of the CSI Report field is Nr8+Ns(3+2NbNcNr) 53 bits, where the number of subcarriers sent Ns is a function of Ng and whether matrices for 40 MHz or 20 MHz 54 55 are sent. The value of Ns and the specific carriers for which matrices are sent is shown in Table 7-25f. If the 56 size of the CSI report field is not an integral multiple of 8 bits, up to 7 zeros are appended to the end of the 57 report to make its size an integral multiple of 8 bits. 58 59 The CSI matrix H for a single carrier has the structure defined in Figure 7-36k. The encoding rules for the 60 eff 61 elements of the Heff matrix are given in 20.3.12.2.1. 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table 7-25f—Number of matrices and carrier grouping 2 3 4 Grouping BW Ns Carriers for which matrices are sent 5 Ng 6 7 1 56 All data and pilot carriers: -28, -27,…-2, -1, 1, 2,…27, 28 8 -28,-26,-24,-22,-20,-18,-16,-14,-12,-10,-8,-6,-4,-2,-1, 9 20 MHz 230 10 1,3,5,7,9,11,13,15,17,19,21,23,25,27,28 11 12 4 16 -28,-24,-20,-16,-12,-8,-4,-1,1,5,9,13,17,21,25,28 13 1 114 All data and pilot carriers: -58, -57, …, -3, -2, 2, 3,…, 57, 58 14 15 -58,-56,-54,-52,-50,-48,-46,-44,-42,-40,-38,-36,-34,-32,-30, 16 -28,-26,-24,-22,-20,-18,-16,-14,-12,-10,-8,-6,-4,-2, 258 17 40 MHz 2,4,6,8,10,12,14,16,18,20,22,24,26,28, 18 30,32,34,36,38,40,42,44,46,48,50,52,54,56,58 19 20 -58,-54,-50,-46,-42,-38,-34,-30,-26,-22,-18,-14,-10,-6, -2, 430 21 2,6,10,14,18,22,26,30,34,38,42,46,50,54,58 22 23 24 25 26 For each subcarrier include 27 28 { 29 Carrier Matrix Amplitude of 3 bits 30 For each of Nr rows in each CSI matrix in order: (1, …, Nr) 31 { 32 Include Nc complex coefficients of CSI matrix H in order: (1, …, Nc ); 33 eff 34 each element of Heff includes the real part of the element (Nb bits) and 35 imaginary part of the element (Nb bits) in that order 36 } 37 38 39 } 40 41 Figure 7-36k—CSI Matrix coding 42 43 44 45 7.3.1.28 Non-compressed Beamforming Report field 46 47 48 The Non-compressed Beamforming Report field is used by the Non-compressed Beamforming frame to carry 49 explicit feedback in the form of non-compressed beamforming matrices V for use by a transmit beamformer 50 to determine steering matrices Q, as described in 9.19.3 and 20.3.12.2. 51 52 53 The structure of the field is dependent on the value of the MIMO Control Channel width field. The Non-com- 54 pressed Beamforming Report field for 20 MHz has the structure defined in Table 7-25g. 55 56 57 where 58 59 Nb is the number of bits determined by the Coefficients Size field of the MIMO Control field 60 Nc is the number of columns in a beamforming matrix determined by the Nc Index field of the MIMO 61 62 Control field 63 64 Nr is the number of rows in a beamforming matrix determined by the Nr Index field of the MIMO 65 Control field

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table 7-25g—Non-compressed Beamforming Report field (20 MHz) 2 3 4 Field Size Meaning 5 6 SNR for space-time stream 1 8 bits Average Signal to Noise Ratio in the 7 STA sending the report for space-time 8 stream 1. 9 10 ... 11 12 SNR for space-time stream Nc 8 bits Average Signal to Noise Ratio in the 13 STA sending the report for space-time 14 stream Nc. 15 Beamforming Feedback Matrix for carrier -28 2× Nb×Nc×Nr bits Beamforming Feedback Matrix V (see 16 Figure 7-36l) 17 18 ... 19 20 Beamforming Feedback Matrix for carrier -1 2× Nb×Nc×Nr bits Beamforming Feedback Matrix V 21 22 Beamforming Feedback Matrix for carrier 1 2× Nb×Nc×Nr bits Beamforming Feedback Matrix V 23 24 ... 25 Beamforming Feedback Matrix for carrier 28 2× Nb×Nc×Nr bits Beamforming Feedback Matrix V 26 27 28 29 The Non-compressed Beamforming Report field for 40 MHz has the structure defined in Table 7-25h. 30 31 32 Table 7-25h—Non-compressed Beamforming Report field (40 MHz) 33 34 35 Field Size Meaning 36 37 SNR for space-time stream 1 8 bits Average Signal to Noise Ratio in the STA 38 sending the report for space-time stream 39 1. 40 41 ... 42 43 SNR for space-time stream Nc 8 bits Average Signal to Noise Ratio in the STA 44 sending the report for space-time stream 45 Nc. 46 47 Beamforming Feedback Matrix for car- 2× Nb×Nc×Nr bits Beamforming Feedback Matrix V (see 48 rier -58 Figure 7-36l) 49 50 ... 51 Beamforming Feedback Matrix for car- 2× Nb×Nc×Nr bits Beamforming Feedback Matrix V 52 rier -2 53 54 Beamforming Feedback Matrix for car- 2× Nb×Nc×Nr bits Beamforming Feedback Matrix V 55 rier 2 56 57 ... 58 59 Beamforming Feedback Matrix for car- +2× Nb×Nc×Nr bits Beamforming Feedback Matrix V 60 rier 58 61 62 63 64 The SNR values in Table 7-25g and Table 7-25h are encoded as an 8-bit two's complement value of 4 x 65 (SNR_average - 22), where SNR_average is sum of the values of SNR per tone (in units of decibels) divided

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 by the number of tones represented. This encoding covers the SNR range from -10 dB to 53.75 dB in 0.25 dB 2 steps. The SNR in space-time stream i corresponds to the SNR associated with the column i of the Beamform- 3 ing Feedback matrix V. Each SNR corresponds to the predicted SNR at beamformee when the beamformer 4 5 applies the matrix V. 6 7 Grouping is a method that reduces the size of the Non-compressed Beamforming Report field by reporting a 8 single value for each group of Ng adjacent subcarriers. With grouping, the size of the Non-compressed Beam- 9 forming Report field is Nc+Ns(2NbNcNr) bits. The number of subcarriers sent Ns is a function of Ng 10 11 and whether matrices for 40 MHz or 20 MHz are sent. The value of Ns and the specific carriers for which 12 matrices are sent is shown in Table 7-25f. If the size of the Non-compressed Beamforming Report field is not 13 an integral multiple of 8 bits, up to 7 zeros are appended to the end of the report to make its size an integral 14 multiple of 8 bits. 15 16 17 A beamforming matrix V for a single carrier has the structure defined in Figure 7-36l. 18 19 20 21 For each subcarrier include 22 { 23 For each of Nr rows in the 24 Non-compressed Beamforming matrix in order: (1, …, Nr) 25 26 { 27 Include Nc complex coefficients of the Non-compressed Beamforming 28 matrix V in order: (1, …, Nc ); each element of V includes the real 29 part of the element (Nb bits) and imaginary part of the element (Nb bits) 30 31 in that order 32 } 33 } 34 35 Figure 7-36l—V Matrix coding (Non-compressed Beamforming) 36 37 38 39 Encoding rules for elements of the V matrix are given in 20.3.12.2.4. 40 41 7.3.1.29 Compressed Beamforming Report field 42 43 44 The Compressed Beamforming Report field is used by the Compressed Beamforming frame (see 7.4.10.8) 45 to carry explicit feedback information in the form of angles representing compressed beamforming matrices 46 V, for use by a transmit beamformer to determine steering matrices Q, as described in 9.19.3 and 20.3.12.2. 47 48 49 The size of the Compressed Beamforming Report field depends on the values in the MIMO Control field. 50 51 The Compressed Beamforming Report field contains the channel matrix elements indexed first by matrix an- 52 gles in the order shown in Table 7-25i and secondly by data subcarrier index from lowest frequency to highest 53 frequency. The explanation on how these angles are generated from the beamforming matrix V is given in 54 55 20.3.12.2.5. 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 2 Table 7-25i—Order of angles in the Compressed Beamforming Report field 3 4 5 Size of V Number of angles The order of angles in the Quantized Beamforming 6 (Nr x Nc) (Na) Matrices Feedback Information field 7 8 2x1 2 11, 21 9 10 2x2 2 11, 21 11 12 3x1 4 11, 21, 21, 31 13 3x2 6 11, 21, 21, 31, 22, 32 14 15 3x3 6 11, 21, 21, 31, 22, 32 16 17 4x1 6 11, 21, 31, 21, 31, 41 18 19 4x2 10 11, 21, 31, 21, 31, 41, 22, 32, 32, 42 20 21 4x3 12 11, 21, 31, 21, 31, 41, 22, 32, 32, 42, 33, 43 22 4x4 12 11, 21, 31, 21, 31, 41, 22, 32, 32, 42, 33, 43 23 24 25 26 The angles are quantized as defined in Table 7-25j. All angles are transmitted LSB to MSB. 27 28 29 30 Table 7-25j—Quantization of angles 31 32 33 Quantized  Quantized  34 35 k  k  radians radians 36   b 1  b 2   b 1  b 37 2  2  2  2  38 39 where where 40

41 b b 42 k  0,1,...,2 1 k  0,1,...,2 1 43 44 b b 45 is the number of bits used to quan- is the number of bits used to quan- 46 tize  (defined by the Codebook tize  (defined by the Codebook 47 Information field of the MIMO Information field of the MIMO 48 Control field, see 7.3.1.26); Control field, see 7.3.1.26) 49 50 51 52 The Compressed Beamforming Report field for 20 MHz has the structure defined in Table 7-25k, where Na 53 54 is the number of angles used for beamforming feedback matrix V (see Table 7-25i). 55 56 The Compressed Beamforming Report field for 40 MHz has the structure defined in Table 7-25l, where Na 57 is the number of angles used for beamforming feedback matrix V (see Table 7-25i). 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 2 Table 7-25k—Compressed Beamforming Report field (20 MHz) 3 4 5 Field Size Meaning 6 7 SNR in space-time stream 1 8 bits Average Signal to Noise Ratio in the STA 8 sending the report for space-time stream 1 9 10 ... 11 12 SNR in space-time stream Nc 8 bits Average Signal to Noise Ratio in the STA 13 sending the report for space-time stream Nc 14 Beamforming Feedback Matrix V for Na×(b+b )/2 bits Beamforming Feedback Matrix V 15 carrier -28 16 17 ... 18 19 Beamforming Feedback Matrix V for Na×(b+b )/2 bits Beamforming Feedback Matrix V 20 carrier -1 21 22 Beamforming Feedback Matrix V for Na×(b+b )/2 bits Beamforming Feedback Matrix V 23 carrier 1 24 25 ... 26 Beamforming Feedback Matrix V for Na×(b+b )/2 bits Beamforming Feedback Matrix V 27 carrier 28 28 29 30 31 Table 7-25l—Compressed Beamforming Report field (40 MHz) 32 33 34 Field Size Meaning 35 36 SNR in space-time stream 1 8 bits Average Signal to Noise Ratio in the STA 37 sending the report for space-time stream 1 38 39 ... 40 41 SNR in space-time stream Nc 8 bits Average Signal to Noise Ratio in the STA 42 sending the report for space-time stream Nc 43 Beamforming Matrix V for carrier -58 Na×(b +b )/2 bits Beamforming Feedback Matrix V 44   45 Beamforming Feedback Matrix V for carrier Na×(b+b )/2 bits Beamforming Feedback Matrix V 46 -58 + Ng 47 48 ... 49 50 Beamforming Feedback Matrix V for carrier Na×(b+b )/2 bits Beamforming Feedback Matrix V 51 -2 52 53 Beamforming Feedback Matrix V for carrier Na×(b+b )/2 bits Beamforming Feedback Matrix V 54 2 55 Beamforming Feedback Matrix V for carrier Na×(b+b )/2 bits Beamforming Feedback Matrix V 56 2 + Ng 57 58 ... 59 60 Beamforming Feedback Matrix V for carrier Na×(b+b )/2 bits Beamforming Feedback Matrix V 61 58 62 63 64 65 The SNR values in Table 7-25k and Table 7-25l are encoded as an 8-bit two's complement value of 4 x

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 (SNR_average - 22), where SNR_average is sum of the values of SNR per tone (in units of decibels) divided 2 3 by the number of tones represented. This encoding covers the SNR range from -10 dB to 53.75 dB in 0.25 dB 4 steps. Each SNR value per tone in stream i (before being averaged) corresponds to the SNR associated with 5 6 the column i of the beamforming feedback matrix V determined at the beamformee. Each SNR corresponds 7 to the predicted SNR at the beamformee when the beamformer applies the matrix V. 8 9 10 Grouping is a method that reduces the size of the Compressed Beamforming Report field by reporting a single 11 12 value for each group of Ng adjacent subcarriers. With grouping, the size of the Compressed Beamforming 13 Report field is Nc×8+Ns×(Na×(b+b )/2) bits, where the number of subcarriers sent Ns is a function of Ng 14 15 and whether matrices for 40 MHz or 20 MHz are sent. Ns and the specific carriers for which matrices are sent 16 is defined in Table 7-25f. If the size of the Compressed Beamforming Report field is not an integral multiple 17 18 of 8 bits, up to 7 zeros are appended to the end of the report to make its size an integral multiple of 8 bits. 19 20 21 See Figure 7-36n and Figure 7-36m for examples of this encoding. 22 23 Bits b1..b5 b6..b8 b9..b13 b14..b16 … b441..b445 b446..b448 24 25  (-28)  (-28)  (-27)  (-27)  (28)  (28) 26 Data 11 21 11 21 … 11 21 27 Conditions: 28 — 2 x 2 V, 29 30 —b = 3, b= 5, 31 — no grouping, 32 — 20 MHz width, and 33 34 — the matrix V is encoded using 8 bits per tone 35 Figure 7-36m—First example of Compressed Beamforming Report field encoding 36 37 38 Bits b1..b4 b5..b8 … b27..b28 b29..b30 b31..b34 … b59..b60 … b871..b874 … b899..b900 39 40 Data 11(-58) 21(-58) … 32(-58) 42(-58) 11(-54) … 42(-54) … 11(58) … 42(58) 41 42 Conditions: 43 — 4 x 2 V, 44 —b= 2, b = 4, 45   46 — 4 tone grouping, 47 — 40 MHz width, and 48 — the matrix V is encoded using 30 bits per tone. 49 50 Figure 7-36n—Second example of Compressed Beamforming Report field encoding 51 52 7.3.1.30 Antenna Selection Indices field 53 54 55 The Antenna Selection Indices field is used within the Antenna Selection Indices Feedback frame to carry 56 antenna selection feedback, as described in 9.20. 57 58 59 The Antenna Selection Indices field is 1 octet in length, and illustrated in Figure 7-36o. 60 61 62 Bits 0 to 7 in the Antenna Selection Indices field correspond to antennas with indices 0 to 7 respectively. A 63 value of 1 in a bit represents the corresponding antenna is selected, and the value of 0 indicates the corre- 64 65 sponding antenna is not selected.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 2 B0 B7 3 4 Antenna Selection Indices 5 6 7 Octets 8 1 9 10 Figure 7-36o—Antenna Selection Indices fixed field 11 12 13 14 7.3.2 Information elements 15 16 Change the row for “Extended Capabilities” in Table 7-26 as follows: 17 18 19 Table 7-26—Element IDs 20 21 22 Element Length (in Information element Extensible 23 ID octets) 24 25 Extended Capabilities 127 2 to 257 Yes 26 3 27 28 29 30 Change the element identifiers (IDs) 45 row, change the Reserved element IDs 58-62 row, insert element 31 32 IDs 61 to 62 rows, delete the Reserved element IDs 72-74 row and insert element IDs 72 to 74 rows in 33 Table 7-26 as follows (note that the entire table is not shown here): 34 35 36 Table 7-26—Element IDs 37 38 39 Element Length (in Information element Extensible 40 ID octets) 41 42 ReservedHT Capabilities (see 7.3.2.56) 45 28 Yes 43 44 Reserved 58-6062 45 46 HT Operation (see 7.3.2.57) 61 24 Yes 47 Secondary Channel Offset (see 7.3.2.20a) 62 3 48 49 Reserved 72-74 50 51 20/40 BSS Coexistence (see 7.3.2.60) 72 3 Yes 52 53 20/40 BSS Intolerant Channel Report (see 7.3.2.58) 73 3-257 54 55 Overlapping BSS Scan Parameters (see 7.3.2.59) 74 16 56 57 58 59 7.3.2.2 Supported Rates element 60 61 Change the first paragraph of 7.3.2.2 as follows: 62 63 64 The Supported Rates element specifies up to eight rates in the Operational-Rate-Set parameter, as described 65 in the MLME-JOIN.request and MLME-START.request primitives, and zero or more BSS membership se-

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 lectors. The information field is encoded as 1 to 8 octets, where each octet describes a single Supported Rate 2 or BSS membership selector. If the combined total of the number of rates in the Operational Rate Set and the 3 number of BSS membership selectors exceeds eight, then an Extended Supported Rate element shall beis gen- 4 5 erated to specify the remaining supported rates and BSS membership selectors. The use of the Extended Sup- 6 ported Rates element is optional otherwise. 7 8 Insert a new paragraph to follow the second paragraph of 7.3.2.2 as follows: 9 10 11 Within Beacon, Probe Response, Association Response, and Reassociation Response management frames, 12 each BSS membership selector contained in the BSSMembershipSelectorSet parameter is encoded as an octet 13 with the MSB (bit 7) set to 1, and bits 6 through 0 set to the encoded value for the selector as found in Table 14 7-26a (e.g., an HT PHY BSS membership selector contained in the BSSMembershipSelectorSet parameter is 15 encoded as X'FF'). A BSS membership selector that has the MSB (bit 7) set to 1 in the supported rates element 16 17 is defined to be basic. The MSB of each Supported Rate octet in other management frame types is ignored by 18 receiving STAs. 19 20 Change the existing third paragraph of 7.3.2.2 as follows: 21 22 23 The Supported Rate information in Beacon and Probe Response management frames is delivered to the man- 24 agement entity in a STA via the BSSBasicRateSet parameter in the MLME-SCAN.confirm primitive. The 25 BSS membership selector information in Beacon and Probe Response management frames is delivered to the 26 management entity in a STA via the BSSMembershipSelectorSet parameter in the MLME-SCAN.confirm 27 28 primitive. Together, these parameters areIt is used by the management entity in a STA to avoid associating 29 with a BSS if the STA cannot receive and transmit all the data rates in the BSSBasicRateSet parameter (see 30 Figure 7-39) or does not support all of the features represented in the BSSMembershipSelectorSet parameter. 31 32 Insert the following NOTE and paragraph after the third paragraph of 7.3.2.2: 33 34 NOTE—A STA that was implemented before the existence of the BSSMembershipSelectorSet parameter will interpret 35 each BSS membership selector in the Supported Rates element that is contained in the BSSMembershipSelectorSet of 36 the transmitting STA as though it were a rate from the BSSBasicRateSet parameter. The value of each BSS membership 37 selector will not match a rate that is known to the STA and therefore, the management entity in the STA will avoid asso- 38 ciating with the BSS because it determines that the STA cannot receive or transmit at what appears to be a required rate. 39 40 41 A STA that is implemented after the existence of the BSSMembershipSelectorSet parameter includes each 42 octet of the Supported rates element that is encoded with the MSB (bit 7) set to 1 and that it does not recognize 43 as a rate in its BSSMembershipSelectorSet parameter. The STA then determines if it can support all of the 44 features represented in its BSSMembershipSelectorSet parameter before attempting to join the network. If 45 there are some BSSMembershipSelectorSet values that are not recognized by the STA, the STA does not at- 46 47 tempt to join the network. 48 Insert the following paragraph, NOTE and table at the end of 7.3.2.2: 49 50 51 The valid values for BSS membership selectors and their associated features are shown in Table 7-26a. 52 NOTE—Because the BSS membership selector and supported rates are carried in the same field, the BSS membership 53 selector value cannot match the value corresponding to any valid supported rate. This allows any value in the supported 54 rates set to be determined as either a supported rate or a BSS membership selector. 55 56 7.3.2.14 Extended Supported Rates element 57 58 59 Change the first paragraph of 7.3.2.14 as follows: 60 61 The Extended Supported Rates element specifies the rates in the OperationalRateSet as described in the 62 MLME-JOIN.request and MLME-START.request primitives, and zero or more BSS membership selector 63 64 values that are not carried in the Supported Rates element. The information field is encoded as 1 to 255 octets 65 where each octet describes a single supported rate or BSS membership selector.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table 7-26a—BSS membership selector value encoding 2 3 4 BSS 5 membership Feature Interpretation 6 selector value 7 8 127 HT PHY Support for the mandatory features of Clause 20 is required in 9 order to join the BSS that was the source of the supported 10 rates element or extended supported rates element containing 11 this value 12 13 14 15 Insert the following new paragraph after the second paragraph of 7.3.2.14 as follows: 16 17 Within Beacon, Probe Response, Association Response, and Reassociation Response management frames, 18 19 each BSS membership selector contained in the BSSMembershipSelectorSet parameter is encoded as an octet 20 with the MSB (bit 7) set to 1, and bits 6 through 0 are set to the encoded value for the selector as found in 21 Table 7-26a (e.g., an HT PHY BSS membership selector contained in the BSSMembershipSelectorSet pa- 22 rameter is encoded as X'FF'). 23 24 25 Change the existing third and fourth paragraphs of 7.3.2.14 as follows: 26 27 Extended Supported Rate information in Beacon and Probe Response management frames is used by STAs 28 29 in order to avoid associating with a BSS if they do not support all the data rates in the BSSBasicRateSet pa- 30 rameter or all of the BSS membership requirements in the BSSMembershipSelectorSet parameter. 31 32 For stations supporting a combined total of eight or fewer data rates and BSS membership selectors, this el- 33 34 ement is optional for inclusion in all of the frame types that include the supported rates element. For stations 35 supporting more than a combined total of eight data rates and BSS membership selectors, this element shall 36 beis included in all of the frame types that include the supported rates element. 37 38 39 Insert the following subclause (7.3.2.20a) after 7.3.2.20: 40 41 7.3.2.20a Secondary Channel Offset element 42 43 44 The Secondary Channel Offset element is used by an AP in a BSS or a STA in an IBSS together with the 45 Channel Switch Announcement element when changing to a new 40 MHz channel. The format of the Sec- 46 ondary Channel Offset element is shown in Figure 7-57a. 47 48 49 The Secondary Channel Offset element is included in Channel Switch Announcement frames, as described 50 in 7.4.1.5. 51 52 53 54 Length 55 Element ID Secondary Channel Offset (=1) 56 57 Octets: 1 1 1 58 59 60 Figure 7-57a—Secondary Channel Offset element format 61 62 63 64 The Secondary Channel Offset field represents the position of the secondary channel relative to the primary 65 channel. The values of the Secondary Channel Offset field are defined in Table 7-27a.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table 7-27a—Values of the Secondary Channel Offset field 2 3 4 Value Name Description 5 6 0 SCN - no secondary channel Indicates that no secondary channel is 7 present 8 9 1 SCA - secondary channel above Indicates that the secondary channel is 10 above the primary channel 11 12 2 Reserved 13 14 3 SCB - secondary channel below Indicates that the secondary channel is 15 below the primary channel 16 17 4-255 Reserved 18 19 20 21 7.3.2.21 Measurement Request element 22 23 7.3.2.21.8 STA Statistics Request 24 25 26 Insert Group identities 11 to 15 and change the row for Reserved in Table 7-29j as follows (note that the 27 entire table is not shown here): 28 29 30 Table 7-29j—Group Identity for a STA Statistics Request 31 32 33 Statistics Group Name Group Identity 34 35 STA Counters from dot11CountersGroup3 (A-MSDU) 11 36 37 STA Counters from dot11CountersGroup3 (A-MPDU) 12 38 39 STA Counters from dot11CountersGroup3 (BlockAckReq, Channel 13 40 Width, PSMP) 41 42 STA Counters from dot11CountersGroup3 (RD, Dual CTS, L-SIG 14 43 TXOP protection) 44 45 STA Counters from dot11CountersGroup3 (beamforming and 15 46 STBC) 47 Reserved 1116-255 48 49 50 51 7.3.2.22 Measurement Report element 52 53 54 7.3.2.22.6 Beacon Report 55 56 Change paragraph 17 of 7.3.2.22.6 as follows: 57 58 59 The Reported Frame Body subelement contains the requested fields and elements of the frame body of the 60 reported Beacon, Measurement Pilot, or Probe Response frame. If the Reporting Detail subelement of the cor- 61 responding Beacon Request equals 0, the Reported Frame Body subelement is not included in the Beacon Re- 62 port. If the Reporting Detail subelement equals 1, all fixed fields and any information elements whose 63 64 Element IDs are present in the Request information element in the corresponding Beacon Request are includ- 65 ed in the Reported Frame Body subelement, in the order that they appeared in the reported frame. If the Re-

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 porting Detail field equals 2, all fixed fields and information elements are included in the order they appeared 2 in the reported frame. Reported TIM elements are truncated such that only the first 4 octets of the element are 3 reported and the element length field is modified to indicate the truncated length of 4. Reported IBSS DFS 4 5 elements shall be truncated such that only the lowest and highest channel number map are reported and the 6 element length field is modified to indicate the truncated length of 13. Reported RSN elements shall be trun- 7 cated such that only the first 4 octets of the element are reported and the element length field is modified to 8 indicate the truncated length of 4. If the Reported Frame Body subelement would cause the Measurement Re- 9 port element to exceed the maximum information element size, then the Reported Frame Body subelement is 10 11 truncated so that the last information element in the Reported Frame Body subelement is a complete informa- 12 tion element. 13 14 7.3.2.22.8 STA Statistics Report 15 16 17 Insert Group Identities 11 to 15 in Table 7-31f : 18 19 20 Table 7-31f—Group Identity for a STA Statistics Report 21 22 23 Statistics Group 24 Group Data Identity Statistics Returned 25 field length Requested 26 (octets) 27 28 11 40 STA Counters from dot11CountersGroup3 (A-MSDU): 29 dot11TransmittedAMSDUCount (Counter32), 30 dot11FailedAMSDUCount (Counter32), 31 dot11RetryAMSDUCount (Counter32), 32 dot11MultipleRetryAMSDUCount (Counter32), 33 dot11TransmittedOctetsInAMSDUCount (Counter64), 34 dot11AMSDUAckFailureCount (Counter32), 35 dot11ReceivedAMSDUCount (Counter32), 36 dot11ReceivedOctetsInAMSDUCount (Counter64) 37 38 12 36 STA Counters from dot11CountersGroup3 (A-MPDU): 39 dot11TransmittedAMPDUCount (Counter32), 40 dot11TransmittedMPDUsInAMPDUCount (Counter32), 41 dot11TransmittedOctetsInAMPDUCount (Counter64), 42 dot11AMPDUReceivedCount (Counter32), 43 dot11MPDUInReceivedAMPDUCount (Counter32), 44 dot11ReceivedOctetsInAMPDUCount (Counter64), 45 dot11AMPDUDelimiterCRCErrorCount (Counter32) 46 47 13 36 STA Counters from dot11CountersGroup3 (BlockAckReq, Channel 48 Width, PSMP): 49 dot11ImplicitBARFailureCount (Counter32), 50 dot11ExplicitBARFailureCount (Counter32), 51 dot11ChannelWidthSwitchCount (Counter32), 52 dot11TwentyMHzFrameTransmittedCount (Counter32), 53 dot11FortyMHzFrameTransmittedCount (Counter32), 54 dot11TwentyMHzFrameReceivedCount (Counter32), 55 dot11FortyMHzFrameReceivedCount (Counter32), 56 dot11PSMPUTTGrantDuration (Counter32), 57 dot11PSMPUTTUsedDuration (Counter32) 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table 7-31f—Group Identity for a STA Statistics Report (continued) 2 3 4 Statistics Group 5 Group Data Identity Statistics Returned 6 field length Requested 7 (octets) 8 9 14 36 STA Counters from dot11CountersGroup3 (RD, Dual CTS, L-SIG TXOP 10 protection): 11 dot11GrantedRDGUsedCount (Counter32), 12 dot11GrantedRDGUnusedCount (Counter32), 13 dot11TransmittedFramesInGrantedRDGCount (Counter32), 14 dot11TransmittedOctetsInGrantedRDGCount (Counter64), 15 dot11DualCTSSuccessCount (Counter32), 16 dot11DualCTSFailureCount (Counter32), 17 dot11RTSLSIGSuccessCount (Counter32), 18 dot11RTSLSIGFailureCount (Counter32) 19 20 15 20 STA Counters from dot11CountersGroup3 (beamforming and STBC): 21 dot11BeamformingFrameCount (Counter32), 22 dot11STBCCTSSuccessCount (Counter32), 23 dot11STBCCTSFailureCount (Counter32), 24 dot11nonSTBCCTSSuccessCount (Counter32), 25 dot11nonSTBCCTSFailureCount (Counter32) 26 27 28 Change the last row of Table 7-31f as follows: 29 30 31 32 Table 7-31f—Group Identity for a STA Statistics Report 33 34 Statistics 35 Group Group Data 36 Identity Statistics Returned field length 37 Requested 38 (octets) 39 40 116-255 Reserved 41 42 43 44 7.3.2.25 RSN information element 45 46 7.3.2.25.3 RSN capabilities 47 48 EDITORIAL NOTE—The changes to Figure 7-74 comprise the following: addition of thee fields “SPP 49 50 A-MSDU Capable”, “SPP A-MSDU Required”, and “PBAC”; showing the fields using two rows in order 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 to make text more readable; replacing the 2-octet arrow previously straddling all the fields (which is now 2 not feasible) with individual bit counts below each field. 3 4 Replace Figure 7-74 with the following: 5 6 7 8 B0 B1 B2 B3 B4 B5 B6 B7 9 10 Pre-Auth No Pair- PTKSA Replay GTKSA Replay Management Management 11 wise Counter Counter Frame Protection Frame Protection 12 Required (MFPR) Capable (MFPC) 13 14 Bits: 1 1 2 2 1 1 15 16 17 B8 B9 B10 B11 B12 B13 B15 18 19 Reserved Peerkey SPP A-MSDU SPP A-MSDU PBAC Reserved Enabled Capable Required 20 21 Bits: 1 1 1 1 1 3 22 23 24 Figure 7-74—RSN Capabilities field format 25 26 27 Insert the following three list items before list item “Bits 8 and 10-15”: 28 29 — Bit 10: SPP A-MSDU Capable. A STA sets the SPP A-MSDU Capable subfield of the RSN Capabil- 30 ities field to 1 to signal that it supports SPP A-MSDU (see 11.17). Otherwise, this subfield is set to 0. 31 32 — Bit 11: SPP A-MSDU Required. A STA sets the SPP A-MSDU Required subfield of the RSN Capa- 33 bilities field to 1 when it only allows SPP A-MSDUs (i.e., will not send or receive PP A-MSDUs) 34 (see 11.17). Otherwise, this subfield is set to 0. 35 36 — Bit 12: Protected Block Ack Agreement Capable (PBAC). A STA sets the PBAC subfield of RSN 37 Capabilities field to 1 to indicate it supports PBAC. Otherwise this subfield is set to 0. 38 39 Change list item “Bits 8 and 10-15” as follows: 40 41 — Bits 8 and 1013-15: Reserved. The remaining subfields of the RSN Capabilities field are reserved 42 and shall be set to 0 on transmission and ignored on reception. 43 44 45 7.3.2.27 Extended Capabilities information element 46 47 Insert the row for Bit 0 (20/40 BSS Coexistence), change the reserved rows for Bits 0-1 and Bits 3-n, 48 insert the rows for Bit 4 (PSMP Capability), Bit 5 (Service Interval Granularity) and Bit 6 (S-PSMP 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Support), and insert the reserved row for Bits 7-n in Table 7-35a as follows (note, not all of Table 7-35a is 2 shown below): 3 4 5 6 Table 7-35a—Capabilities field 7 8 Bit Information Notes 9 10 0 20/40 BSS Coex- The 20/40 BSS Coexistence Management Support field indicates support 11 istence Manage- for the 20/40 BSS Coexistence Management frame and its use. The 20/40 12 ment Support BSS Coexistence Management Support field is set to 1 to indicate support 13 for the communication of STA information through the transmission and 14 reception of the 20/40 BSS Coexistence Management frame. The 20/40 15 BSS Coexistence Management Support field is set to 0 to indicate a lack 16 of support for the communication of STA information through the trans- 17 mission and reception of the 20/40 BSS Coexistence Management frame. 18 19 0, 1 Reserved 20 21 3-n Reserved 22 23 4 PSMP Capability This bit in the Extended Capabilities information element is set to 1 if the 24 STA supports PSMP operation described in 9.16. 25 26 In Beacon and Probe Response frames transmitted by an AP: 27 Set to 0 if the AP does not support PSMP operation 28 Set to 1 if the AP supports PSMP operation 29 30 In Beacon frames transmitted by a non-AP STA: 31 Set to 0 32 33 Otherwise: 34 Set to 0 if the STA does not support PSMP operation 35 Set to 1 if the STA supports PSMP operation 36 5 Service Interval Duration of the shortest Service Interval. 37 Granularity Used for scheduled PSMP only. 38 This field is defined when the S-PSMP Support field is set to 1, otherwise 39 it is reserved. 40 41 See 11.4.4b. 42 43 Set to 0 for 5 ms 44 Set to 1 for 10 ms 45 Set to 2 for 15 ms 46 Set to 3 for 20 ms 47 Set to 4 for 25 ms 48 Set to 5 for 30 ms 49 Set to 6 for 35 ms 50 Set to 7 for 40 ms 51 52 6 S-PSMP Support Indicates support for scheduled PSMP 53 54 When PSMP Support is set to 0, S-PSMP support is set to 0. 55 56 When PSMP support is set to 1, the S-PSMP Support field is defined as 57 follows: 58 Set to 0 if STA does not support S-PSMP 59 Set to 1 is STA supports S-PSMP 60 61 7-n Reserved 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Add the following NOTE after paragraph 5: (Starting “The Capabilities field is a bit field indicating the 2 capabilities being advertised by the STA...”): 3 4 NOTE—The fields of the Extended Capabilities element are not dynamic. They are determined by the parameters of the 5 MLME-START.request or MLME-JOIN.request that caused the STA to start or join its current BSS, and they remain 6 unchanged until the next MLME-START.request or MLME-JOIN.request. 7 8 7.3.2.28 BSS Load element 9 10 11 Change the third paragraph of 7.3.2.28 as shown: 12 13 The Channel Utilization field is defined as the percentage of time, normalized to 255, the AP sensed the me- 14 dium was busy, as indicated by either the physical or virtual carrier sense (CS) mechanism. When more than 15 one channel is in use for the BSS, the Channel Utilization value is calculated only for the primary channel. 16 17 This percentage is computed using the formula, ((channel busy time/ 18 (dot11ChannelUtilizationBeaconIntervals * dot11BeaconPeriod * 1024)) * 255), where channel busy time is 19 defined to be the number of microseconds during which the CS mechanism, as defined in 9.2.1, has indicated 20 a channel busy indication, and the MIB attribute dot11ChannelUtilizationBeaconIntervals represents the 21 number of consecutive beacon intervals during which the channel busy time is measured. The default value 22 23 of dot11ChannelUtilizationBeaconIntervals is defined in Annex D. 24 25 7.3.2.29 EDCA Parameter Set element 26 27 Change paragraph 13 starting “The value of the TXOP Limit field is specified as an unsigned integer, 28 29 with the least significant octet transmitted first, in units of 32 µs.” as follows: 30 31 The value of the TXOP Limit field is specified as an unsigned integer, with the least significant octet trans- 32 mitted first, in units of 32 µs. A TXOP Limit field value of 0 indicates that a single MSDU or MMPDU, in 33 addition to a possible RTS/CTS exchange or CTS to itself, may be transmitted at any rate for each TXOP. the 34 35 TXOP holder may transmit or cause to be transmitted (as responses) the following within the current TXOP: 36 a) A single MSDU, MMPDU, A-MSDU, or A-MPDU at any rate, subject to the rules in 9.6 37 38 b) Any required acknowledgements 39 c) Any frames required for protection, including one of the following: 40 41 1) An RTS/CTS exchange 42 2) CTS to itself 43 44 3) Dual CTS as specified in 9.2.5.5a 45 d) Any frames required for beamforming as specified in 9.17 46 47 e) Any frames required for link adaptation as specified in 9.16.2 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Change Table 7-37 as follows: 2 3 4 Table 7-37—Default EDCA Parameter Set element parameter values 5 6 7 TXOP limit 8 9 For PHYs 10 For PHYs AC CWmin CWmax AIFSN defined in 11 defined in Other Clause 17 and, 12 Clause 15 and PHYs Clause 19 and 13 Clause 18 14 Clause 20 15 16 AC_BK aCWmin aCWmax 7 0 0 0 17 18 AC_BE aCWmin aCWmax 3 0 0 0 19 AC_VI (aCWmin+1)/2 - 1 aCWmin 2 6.016 ms 3.008 ms 0 20 21 AC_VO (aCWmin+1)/4 - 1 (aCWmin+1)/2 - 1 2 3.264 ms 1.504 ms 0 22 23 24 25 7.3.2.30 TSPEC element 26 27 28 Change the paragraph 4 of 7.3.2.30 as follows: 29 30 — The Traffic Type subfield is a single bit and is set to 1 for a periodic traffic pattern (e.g., isochronous 31 TS of MSDUs or A-MSDUs, with constant or variable sizes, that are originated at fixed rate) or set 32 to 0 for an aperiodic, or unspecified, traffic pattern (e.g., asynchronous TS of low-duty cycles). 33 34 35 Change Table 7-38 as follows: 36 37 38 Table 7-38—Direction subfield encoding 39 40 41 Bit 5 Bit 6 Usage 42 43 0 0 Uplink (MSDUs or A-MSDUs are sent from the non-AP STA to HC) 44 45 1 0 Downlink (MSDUs or A-MSDUs are sent from the HC to the non-AP STA) 46 47 0 1 Direct link (MSDUs or A-MSDUs are sent from the non-AP STA to another non-AP 48 STA) 49 1 1 Bidirectional link (equivalent to a downlink request plus an uplink request, each direction 50 having the same parameters). 51 The fields in the TSPEC element specify resources for a single direction. Double the 52 specified resources are required to support both streams. 53 54 55 56 Change paragraphs 10 and 11 of 7.3.2.30 as follows: 57 58 — The UP subfield is 3 bits and indicates the actual value of the UP to be used for the transport of 59 60 MSDUs or A-MSDUs belonging to this TS in cases where relative prioritization is required. When 61 the TCLAS element is present in the request, the UP subfield in TS Info field of the TSPEC element 62 is reserved. 63 64 — The TS Info Ack Policy subfield is 2 bits in length and indicates whether MAC acknowledgments 65 are required for MPDUs or A-MSDUs belonging to this TID and the desired form of those acknowl-

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 edgments. The encoding of the TS Info Ack Policy subfield is shown in Table 7-40. If the TS Info 2 Ack Policy subfield is set to Block Ack and the type of Block Ack policy is unknown to the HC, the 3 HC shall assume, for TXOP scheduling, that the immediate Block Ack policy is being used (see 4 5 9.10). 6 7 Change Table 7-41 as follows: 8 9 10 Table 7-41—Setting of Schedule Subfield 11 12 13 APSD Schedule Usage 14 15 0 0 No Schedule 16 17 1 0 Unscheduled APSD 18 19 01Reserved Scheduled PSMP 20 21 1 1 Scheduled APSD 22 23 24 25 Change paragraphs 14 and 15 of 7.3.2.30 as follows: 26 27 The Nominal MSDU Size field is 2 octets long, contains an unsigned integer that specifies the nominal size, 28 in octets, of MSDUs or A-MSDUs belonging to the TS under this TSPEC, and is defined in Figure 7-84. If 29 30 the Fixed subfield is set to 1, then the size of the MSDU or A-MSDU is fixed and is indicated by the Size 31 subfield. If the Fixed subfield is set to 0, then the size of the MSDU or A-MSDU might not be fixed and the 32 Size subfield indicates the nominal MSDU size. If both the Fixed and Size subfields are set to 0, then the nom- 33 inal MSDU size is unspecified. 34 35 36 The Maximum MSDU Size field is 2 octets long and contains an unsigned integer that specifies the maximum 37 size, in octets, of MSDUs or A-MSDUs belonging to the TS under this TSPEC. 38 39 Change paragraphs 21 to 28 of 7.3.2.30 as follows: 40 41 42 The Minimum Data Rate field is 4 octets long and contains an unsigned integer that specifies the lowest data 43 rate specified at the MAC_SAP, in bits per second, for transport of MSDUs or A-MSDUs belonging to this 44 TS within the bounds of this TSPEC. The minimum data rate does not include the MAC and PHY overheads 45 incurred in transferring the MSDUs or A-MSDUs. 46 47 20 48 The Mean Data Rate field is 4 octets long and contains an unsigned integer that specifies the average data 49 rate specified at the MAC_SAP, in bits per second, for transport of MSDUs or A-MSDUs belonging to this 50 TS within the bounds of this TSPEC. The mean data rate does not include the MAC and PHY overheads in- 51 curred in transferring the MSDUs or A-MSDUs. 52 53 54 The Peak Data Rate field is 4 octets long and contains an unsigned integer that specifies the maximum allow- 55 able data rate, in bits per second, for transfer of MSDUs or A-MSDUs belonging to this TS within the bounds 56 of this TSPEC. If p is the peak rate in bits per second, then the maximum amount of data, belonging to this 57 58 TS, arriving in any time interval [t1,t2], where t1 < t2 and t2 – t1 > 1 TU, does not exceed p * (t2 – t1) bits. 59 60 The Burst Size field is 4 octets long and contains an unsigned integer that specifies the maximum burst, in 61 octets, of the MSDUs or A-MSDUs belonging to this TS that arrive at the MAC_SAP at the peak data rate. 62 A value of 0 indicates that there are no bursts. 63 64 65 The Delay Bound field is 4 octets long and contains an unsigned integer that specifies the maximum amount

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 of time, in microseconds, allowed to transport an MSDU or A-MSDU belonging to the TS in this TSPEC, 2 measured between the time marking the arrival of the MSDU, or the first MSDU of the MSDUs comprising 3 an A-MSDU, at the local MAC sublayer from the local MAC_SAP and the time of completion of the suc- 4 5 cessful transmission or retransmission of the MSDU or A-MSDU to the destination. The completion of the 6 MSDU or A-MSDU transmission includes the relevant acknowledgment frame transmission time, if present. 7 8 The Minimum PHY Rate field is 4 octets long and contains an unsigned integer that specifies the desired min- 9 10 imum PHY rate to use for this TS, in bits per second, that is required for transport of the MSDUs or A-MSDUs 11 belonging to the TS in this TSPEC. 12 13 The Surplus Bandwidth Allowance field is 2 octets long and specifies the excess allocation of time (and band- 14 15 width) over and above the stated application rates required to transport an MSDU or A-MSDU belonging to 16 the TS in this TSPEC. This field is represented as an unsigned binary number and, when specified, is greater 17 than 0. 18 19 20 The 13 least significant bits (LSBs) indicate the decimal part while the three MSBs indicate the integer part 21 of the number. This field takes into account the retransmissions, as the rate information does not include re- 22 transmissions. It represents the ratio of over-the-air bandwidth (i.e., time that the scheduler allocates for the 23 transmission of MSDUs or A-MSDUs at the required rates) to bandwidth of the transported MSDUs or A- 24 25 MSDUs required for successful transmission (i.e., time that would be necessary at the minimum PHY rate if 26 there were no errors on the channel) to meet throughput and delay bounds under this TSPEC, when specified. 27 As such, it should be greater than unity. A value of 1 indicates that no additional allocation of time is request- 28 ed. 29 30 31 Delete from 7.3.2.30 the paragraph containing: “The configuration of APSD=0, Schedule=1 is reserved”, 32 which follows the ninth dashed list item of 7.3.2.30. 33 34 7.3.2.37 Neighbor Report element 35 36 37 EDITORIAL NOTE—The change to Figure 7-95c comprises the addition of the “High Throughput” 38 field in position B11, and the adjustment of the “reserved” field. 39 40 Replace Figure 7-95c with the following: 41 42 43 44 B0 B1 B2 B3 B4 B9 B10 B11 B12 B31 45 46 AP Reachability Security Key Scope Capabilities Mobility High Reserved 47 Domain Throughput 48 49 Bits: 2 1 1 6 1 1 20 50 51 Figure 7-95c—BSSID Information field 52 53 54 55 Insert the following paragraph after the paragraph in 7.3.2.37 that starts “The Mobility Domain”: 56 57 The High Throughput bit, when set to one, indicates that the AP represented by this BSSID is an HT AP in- 58 59 cluding the HT Capabilities element in its Beacons, and that the contents of that HT Capabilities element are 60 identical to the HT Capabilities element advertised by the AP sending the report. 61 62 Change the paragraph that starts “Bits 11-31 are reserved...” as follows: 63 64 65 Bits 1112-31 are reserved.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Change the reserved entry for subelement IDs 3-65, insert the entry for subelement ID 45, insert the 2 reserved entry for subelement IDs 46-60, insert the entries for subelement IDs 61-62, and insert the 3 4 reserved entry for subelement IDs 63-65, in Table 7-43b as follows: 5 6 7 Table 7-43b—Optional Subelement IDs for Neighbor Report 8 9 10 Subelement Length field Name Extensible 11 ID (octets) 12 13 3-6544 Reserved 14 15 45 HT Capabilities subelement 26 Yes 16 17 46-60 Reserved 18 61 HT Operation subelement 22 Yes 19 20 62 Secondary Channel Offset subelement 1 21 22 63-65 Reserved 23 24 25 26 Insert the following after the paragraph starting “The Measurement Pilot Transmission Information 27 28 subelement”: 29 30 The HT Capabilities subelement is the same as the HT Capabilities element as defined in 7.3.2.56. 31 32 33 The HT Operation subelement is the same as the HT Operation element as defined in 7.3.2.57. 34 35 The Secondary Channel Offset subelement is the same as the Secondary Channel Offset element as defined 36 37 in 7.3.2.20a. 38 39 Insert the following subclauses (7.3.2.56 to 7.3.2.60) after 7.3.2.55: 40 41 42 7.3.2.56 HT Capabilities element 43 44 7.3.2.56.1 HT Capabilities element structure 45 46 47 An HT STA declares that it is an HT STA by transmitting the HT Capabilities element. 48 49 50 The HT Capabilities element contains a number of fields that are used to advertise optional HT capabilities 51 of an HT STA. The HT Capabilities element is present in Beacon, Association Request, Association Re- 52 sponse, Reassociation Request, Reassociation Response, Probe Request and Probe Response frames. The HT 53 54 Capabilities element is defined in Figure 7-95o17. 55 56 57 58 Element Length HT A-MPDU Supported HT Extended Transmit ASEL 59 ID Capabilities Info Parameters MCS set Capabilities Beamform- Capabili- 60 ing ties 61 Capabilities 62 Octets:1 1 2 1 16 2 4 1 63 64 65 Figure 7-95o17—HT Capabilities element format

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 The Element ID field of the HT Capabilities element is defined in Table 7-26. 2 3 The Length field is set to 26. 4 5 6 7.3.2.56.2 HT Capabilities Info field 7 8 The HT Capabilities Info field is 2 octets in length, and contains capability information bits. The structure of 9 this field is defined in Figure 7-95o18. 10 11 12 13 B0 B1 B2 B3 B4 B5 B6 B7 B8 B9 14 15 LDPC Supported SM Power HT- Short GI Short GI Tx Rx 16 coding channel Save greenfield for 20 MHz for 40 MHz STBC STBC 17 capability width set 18 19 20 21 22 B10 B11 B12 B13 B14 B15 23 DSSS/CCK L-SIG TXOP HT-delayed Maximum A- Forty MHz 24 Mode in 40 Reserved Protection 25 Block Ack MSDU length Intolerant MHz support 26 27 28 Figure 7-95o18—HT Capabilities Info field 29 30 31 32 The subfields of the HT Capabilities Info field are defined in Table 7-43k. 33 34 35 Table 7-43k—Subfields of the HT Capabilities Info field 36 37 38 Subfield Definition Encoding 39 40 LDPC cod- Indicates support for receiv- Set to 0 if not supported 41 ing capabil- ing LDPC coded packets Set to 1 if supported 42 ity 43 44 Supported Indicates the channel Set to 0 if only 20 MHz operation is supported 45 channel widths supported by the Set to 1 if both 20 MHz and 40 MHz operation is supported 46 width set STA. 47 See 11.14. This field is reserved when the transmitting or receiving STA is oper- 48 ating in a regulatory class that does not include a value of 13 or 14 in 49 the behavior limits as specified in Annex J. 50 SM Power Indicates the Spatial Multi- Set to 0 for Static SM Power Save mode 51 Save plexing (SM) Power Save Set to 1 for Dynamic SM Power Save mode 52 mode. Set to 3 for SM Power Save disabled 53 See 11.2.3. 54 The value 2 is reserved 55 56 HT-green- Indicates support for the Set to 0 if not supported 57 field reception of PPDUs with Set to 1 if supported 58 HT-greenfield format. 59 See 20.1.4. 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table 7-43k—Subfields of the HT Capabilities Info field (continued) 2 3 4 Subfield Definition Encoding 5 6 Short GI for Indicates Short GI support Set to 0 if not supported 7 20 MHz for the reception of packets Set to 1 if supported 8 transmitted with TXVEC- 9 TOR parameter 10 CH_BANDWIDTH set to 11 HT_CBW20 12 13 Short GI for Indicates Short GI support Set to 0 if not supported 14 40 MHz for the reception of packets Set to 1 if supported 15 transmitted with TXVEC- 16 TOR parameter 17 CH_BANDWIDTH set to 18 HT_CBW40 19 20 Tx STBC Indicates support for the Set to 0 if not supported 21 transmission of PPDUs Set to 1 if supported 22 using STBC 23 Rx STBC Indicates support for the Set to 0 for no support 24 reception of PPDUs using Set to 1 for support of one spatial stream 25 STBC Set to 2 for support of one and two spatial streams 26 Set to 3 for support of one, two and three spatial streams 27 28 HT-delayed Indicates support for HT- Set to 0 if not supported 29 Block Ack delayed Block Ack opera- Set to 1 if supported 30 tion. 31 See 9.10.8. Support indicates that the STA is able to accept an ADDBA request 32 for HT-delayed Block Ack 33 34 Maximum Indicates maximum A- Set to 0 for 3839 octets 35 A-MSDU MSDU length. Set to 1 for 7935 octets 36 length See 9.7c. 37 38 DSSS/CCK Indicates use of DSSS/CCK In Beacon and Probe Response frames: 39 Mode in 40 mode in a 20/40 MHz BSS. Set to 0 if the BSS does not allow use of DSSS/CCK in 40 MHz 40 MHz See 11.14. Set to 1 if the BSS does allow use of DSSS/CCK in 40 MHz 41 42 Otherwise: 43 Set to 0 if the STA does not use DSSS/CCK in 40 MHz 44 Set to 1 if the STA uses DSSS/CCK in 40 MHz 45 46 See 11.14.8 for operating rules 47 48 Forty MHz Indicates whether APs Set to 1 by an HT STA to prohibit a receiving AP from operating 49 Intolerant receiving this information that AP’s BSS as a 20/40 MHz BSS, otherwise, set to 0. 50 or reports of this informa- 51 tion are required to prohibit 52 40 MHz transmissions (see 53 11.14.12). 54 L-SIG Indicates support for the L- Set to 0 if not supported 55 TXOP pro- SIG TXOP protection Set to 1 if supported 56 tection sup- mechanism (see 9.13.5) 57 port 58 59 60 61 7.3.2.56.3 A-MPDU Parameters field 62 63 The structure of the A-MPDU Parameters field is shown in Figure 7-95o19. 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 2 B0 B1 B2 B4 B5 B7 3 Maximum A-MPDU Length Minimum MPDU Start 4 Reserved 5 Exponent Spacing 6 7 Octets 8 1 9 10 11 Figure 7-95o19—A-MPDU Parameters field 12 13 14 The subfields of the A-MPDU Parameters field are defined in Table 7-43l. 15 16 17 18 Table 7-43l—Subfields of the A-MPDU Parameters field 19 20 Subfield Definition Encoding 21 22 Maximum Indicates the maximum length of A-MPDU This field is an integer in the range 0 to 3. 23 A-MPDU that the STA can receive. 24 Length The length defined by this field is equal to 25 Exponent 13+ Maximum A-MPDU Length Exponent 26 2 – 1 octets. 27 28 Minimum Determines the minimum time between the Set to 0 for no restriction 29 MPDU Start start of adjacent MPDUs within an A- Set to 1 for 1/4 s 30 Spacing MPDU that the STA can receive, measured Set to 2 for 1/2 s 31 at the PHY-SAP. Set to 3 for 1 s 32 See 9.7d.3. Set to 4 for 2s 33 Set to 5 for 4 s 34 Set to 6 for 8s 35 Set to 7 for 16 s 36 37 38 39 7.3.2.56.4 Supported MCS Set field 40 41 The Supported MCS Set field indicates which MCSs a STA supports. 42 43 44 An MCS is identified by an MCS index, which is represented by an integer in the range 0 to 76. The interpre- 45 tation of the MCS index (i.e., the mapping from MCS to data rate) is PHY dependent. For the HT PHY, see 46 20.6. 47 48 The structure of the MCS Set field is defined in Figure 7-95o20. 49 50 51 B0 B76 B77 B79 B80 B89 B90 B95 52 53 Rx MCS Bitmask Reserved Rx Highest Supported Data Rate Reserved 54 55 Bits773106 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 2 B96 B97 B98 B99 B100 B101 B127 3 Tx MCS Set Tx Rx MCS Tx Maximum Number Tx Unequal Reserved 4 Defined Set Not Equal Spatial Streams Sup- Modulation 5 ported Supported 6 7 Bits 1 1 2 1 27 8 9 Figure 7-95o20—Supported MCS Set field 10 11 12 The Rx MCS Bitmask subfield defines a set of MCS index values, where bit B0 corresponds to MCS 0 and 13 bit B76 corresponds to MCS 76. 14 NOTE— An HT STA includes the mandatory MCS values defined in 20.1 in the Rx MCS Bitmask field. 15 16 17 The Rx Highest Supported Data Rate subfield defines the highest data rate that the STA is able to receive, in 18 units of 1 Mb/s, where 1 represents 1 Mb/s, and incrementing by 1 Mb/s steps to the value 1023 which rep- 19 20 resents 1023 Mb/s. The value 0 indicates that this subfield does not specify a highest data rate that the STA 21 is able to receive, see 9.6.0e.5.3. 22 23 24 The Tx MCS Set Defined, Tx Rx MCS Set Not Equal, Tx Maximum Number Spatial Streams Supported and Tx 25 Unequal Modulation Supported subfields indicate the transmit supported MCS set, as defined in Table 7- 26 27 43m. 28 29 30 Table 7-43m—Transmit MCS Set 31 32 33 Tx MCS Tx Rx Tx Maximum Number Tx Unequal Modulation 34 Condition Set MCS Set Spatial Streams Supported Supported 35 Defined Not Equal 36 37 No Tx MCS 00 0 0 38 39 Set is Defined 40 The Tx MCS 10 0 0 41 42 Set is defined 43 to be equal to 44 the Rx MCS 45 Set 46 47 The Tx MCS 1 1 Indicates the maximum Indicates whether transmit 48 Set may differ number of spatial streams unequal modulation is sup- 49 50 from the Rx supported when transmit- ported: 51 MCS Set ting: Set to 0 for unequal modula- 52 Set to 0 for 1 spatial stream, tion not supported, 53 Set to 1 for 2 spatial streams, Set to 1 for unequal modula- 54 Set to 2 for 3 spatial streams tion supported. 55 56 Set to 3 for 4 spatial streams. 57 58 59 60 7.3.2.56.5 HT Extended Capabilities field 61 62 The structure of the HT Extended Capabilities field is defined in Figure 7-95o21. 63 64 65 The subfields of the HT Extended Capabilities field are defined in Table 7-43n.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 2 B0 B1 B2 B3 B7 B8 B9 B10 B11 B12 B15 3 PCO Transition MCS +HTC RD 4 PCO Reserved Reserved Time Feedback Support Responder 5 6 Bits: 1 2 5 2 1 1 4 7 8 9 Figure 7-95o21—HT Extended Capabilities field 10 11 12 13 14 15 Table 7-43n—Subfields of the HT Extended Capabilities field 16 17 Subfield Definition Encoding 18 19 PCO Indicates support for PCO. Set to 0 if not supported 20 Set to 1 if supported 21 When transmitted by an AP: indicates 22 whether the AP can operate its BSS as a 23 PCO BSS or not. 24 When transmitted by a non-AP STA: 25 indicates whether the STA can operate 26 as a PCO active STA when the Transi- 27 tion Time field in its HT Extended 28 Capabilities field meets the intended 29 transition time of the PCO capable AP. 30 31 PCO Transi- When transmitted by a non-AP STA: If the PCO subfield is set to 0, this field is reserved. 32 tion Time indicates that the STA can switch 33 between 20 MHz channel width and 40 Otherwise: 34 MHz channel width within the specified Set to 1 for 400 µs 35 time. Set to 2 for 1.5 ms 36 Set to 3 for 5 ms 37 When transmitted by an AP: indicates 38 the PCO Transition Time to be used dur- Set to 0 for no transition. In this case the PCO active 39 ing PCO operation. The value contained STA does not change its operating channel width and is 40 in this field is dynamic when transmit- able to receive 40 MHz PPDUs during the 20 MHz 41 ted by an AP - i.e., the value of this phase (see 11.15). 42 field may change at any time during the 43 lifetime of the association of a STA with 44 the AP. See 11.15.3. 45 46 MCS Feed- Indicates whether the STA can provide Set to 0 (No Feedback) if the STA does not provide 47 back MCS feedback MCS Feedback 48 Set to 2 (Unsolicited) if the STA provides only unsolic- 49 ited MCS Feedback 50 Set to 3 (Both) if the STA can provide MCS Feedback in 51 response to MRQ (either Delayed or Immediate, see 52 9.18.1) as well as unsolicited MCS Feedback 53 54 The value 1 is reserved 55 56 +HTC Sup- Indicates support of the High Through- Set to 0 if not supported 57 port put Control field. Set to 1 if supported 58 See 9.7a 59 60 RD Indicates support for acting as a reverse Set to 0 if not supported 61 Responder direction responder - i.e., the STA may Set to 1 if supported 62 use an offered RDG to transmit data to 63 an RD initiator using the RD protocol 64 described in 9.15. 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 7.3.2.56.6 Transmit Beamforming Capabilities 2 3 The structure of the Transmit Beamforming Capabilities field is defined in Figure 7-95o22. The subfields of 4 5 the Transmit Beamforming Capabilities field are defined in Table 7-43o. 6 7 8 B0 B1 B2 B3 B4 B5 B6 B7 B8 9 Implicit 10 Receive Transmit Implicit Explicit CSI Transmit Receive Transmit 11 Staggered Staggered Transmit Transmit 12 Beamforming NDP NDP Calibration Sounding Sounding Beamforming Beamforming 13 Receiving Capable Capable Capable Capable Capable Capable 14 Capable 15 16 Bits: 1 1 1 1 1 1 2 1 17 18 19 B9 B10 B11B12 B13 B14 B15 B16 B17 B18 B19 B20 20 21 Explicit Non- Explicit CSI Number Explicit 22 Explicit Non- Explicit compressed Compressed of Transmit Minimal 23 compressed Compressed Beamforming Beamforming Beamformer Beamforming Grouping 24 Steering Capable Steering Capable Feedback Feedback Antennas CSI Feedback 25 Capable Capable Supported 26 27 1122222 28 29 30 31 B21 B22 B23 B24 B25 B26 B27 B28 B29 B31 32 Non-compressed Steering Compressed Steering CSI Max Number of Channel 33 Number of Beamformer Number of Beamformer Rows Beamformer Estimation Reserved 34 Antennas Supported Antennas Supported Supported Capability 35 36 22223 37 38 Figure 7-95o22—Transmit Beamforming Capabilities field 39 40 41 42 Table 7-43o—Subfields of the Transmit Beamforming Capabilities field 43 44 45 Transmit 46 Beamforming Definition Encoding 47 Capabilities field 48 49 Implicit Transmit Indicates whether this STA can receive Set to 0 if not supported 50 Beamforming Transmit Beamforming steered frames Set to 1 if supported 51 Receiving Capable using implicit feedback 52 Receive Staggered Indicates whether this STA can receive Set to 0 if not supported 53 Sounding Capable staggered sounding frames. Set to 1 if supported 54 55 Transmit Staggered Indicates whether this STA can transmit Set to 0 if not supported 56 Sounding Capable staggered sounding frames. Set to 1 if supported 57 58 Receive NDP Capa- Indicates whether this receiver can inter- Set to 0 if not supported 59 ble pret Null Data Packets as sounding Set to 1 if supported 60 frames. 61 62 Transmit NDP Capa- Indicates whether this STA can transmit Set to 0 if not supported 63 ble Null Data Packets as sounding frames. Set to 1 if supported 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table 7-43o—Subfields of the Transmit Beamforming Capabilities field (continued) 2 3 4 Transmit 5 Beamforming Definition Encoding 6 Capabilities field 7 8 Implicit Transmit Indicates whether this STA can apply Set to 0 if not supported 9 Beamforming Capa- Implicit transmit beamforming. Set to 1 if supported 10 ble 11 12 Calibration Indicates that the STA can participate in a Set to 0 if not supported 13 calibration procedure initiated by another 14 STA that is capable of generating an Set to 1 if the STA can respond to a calibra- 15 immediate response sounding PPDU, and tion request using the CSI Report, but cannot 16 can provide a CSI Report in response to initiate calibration 17 the receipt of a sounding PPDU. 18 The value 2 is reserved 19 20 Set to 3 if the STA can both initiate and 21 respond to a calibration request 22 23 Explicit CSI Trans- Indicates whether this STA can apply Set to 0 if not supported 24 mit Beamforming transmit beamforming using CSI explicit Set to 1 if supported 25 Capable feedback in its transmission 26 Explicit Non-com- Indicates whether this STA can apply Set to 0 if not supported 27 pressed Steering transmit beamforming using non-com- Set to 1 if supported 28 Capable pressed beamforming feedback matrix 29 explicit feedback in its transmission 30 31 Explicit Com- Indicates whether this STA can apply Set to 0 if not supported 32 pressed Steering transmit beamforming using compressed Set to 1 if supported 33 Capable beamforming feedback matrix explicit 34 feedback in its transmission 35 36 Explicit Transmit Indicates whether this receiver can return Set to 0 if not supported 37 Beamforming CSI CSI explicit feedback. Set to 1 for delayed feedback 38 Feedback Set to 2 for immediate feedback 39 Set to 3 for delayed and immediate feedback 40 41 Explicit Non-com- Indicates whether this receiver can return Set to 0 if not supported 42 pressed Beamform- non-compressed beamforming feedback Set to 1 for delayed feedback 43 ing Feedback matrix explicit feedback. Set to 2 for immediate feedback 44 Capable Set to 3 for delayed and immediate feedback 45 46 Explicit Com- Indicates whether or not this receiver can Set to 0 if not supported 47 pressed Beamform- return compressed beamforming feedback Set to 1 for delayed feedback 48 ing Feedback matrix explicit feedback. Set to 2 for immediate feedback 49 Capable Set to 3 for delayed and immediate feedback 50 Minimal Grouping Indicates the minimal grouping used for Set to 0 if the STA supports groups of 1 (no 51 explicit feedback reports grouping) 52 Set to 1 indicates groups of 1, 2 53 Set to 2 indicates groups of 1, 4 54 Set to 3 indicates groups of 1, 2, 4 55 56 CSI Number of Indicates the maximum number of beam- Set to 0 for single Tx antenna sounding 57 Beamformer Anten- former antennas the beamformee can sup- Set to 1 for 2 Tx antenna sounding 58 nas Supported port when CSI feedback is required Set to 2 for 3 Tx antenna sounding 59 Set to 3 for 4 Tx antenna sounding 60 61 Non-compressed Indicates the maximum number of beam- Set to 0 for single Tx antenna sounding 62 Steering Number of former antennas the beamformee can sup- Set to 1 for 2 Tx antenna sounding 63 Beamformer Anten- port when non-compressed beamforming Set to 2 for 3 Tx antenna sounding 64 nas Supported feedback matrix is required Set to 3 for 4 Tx antenna sounding 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table 7-43o—Subfields of the Transmit Beamforming Capabilities field (continued) 2 3 4 Transmit 5 Beamforming Definition Encoding 6 Capabilities field 7 8 Compressed Steer- Indicates the maximum number of beam- Set to 0 for single Tx antenna sounding 9 ing Number of former antennas the beamformee can sup- Set to 1 for 2 Tx antenna sounding 10 Beamformer Anten- port when compressed beamforming Set to 2 for 3 Tx antenna sounding 11 nas Supported feedback matrix is required Set to 3 for 4 Tx antenna sounding 12 13 CSI Max Number of Indicates the maximum number of rows of Set to 0 for a single row of CSI 14 Rows Beamformer CSI explicit feedback from the beam- Set to 1 for 2 rows of CSI 15 Supported formee or calibration responder or trans- Set to 2 for 3 rows of CSI 16 mit antenna selection responder that a Set to 3 for 4 rows of CSI 17 beamformer or calibration initiator or 18 transmit antenna selection initiator can 19 support when CSI feedback is required. 20 21 Channel Estimation Indicates the maximum number of space Set 0 for 1 space time stream 22 Capability time streams (columns of the MIMO chan- Set 1 for 2 space time streams 23 nel matrix) for which channel dimensions Set 2 for 3 space time streams 24 can be simultaneously estimated when Set 3 for 4 space time streams 25 receiving an NDP sounding PPDU or the 26 extension portion of the HT long training 27 fields in a staggered sounding PPDU. See 28 NOTE. 29 NOTE—The maximum number of space time streams for which channel coefficients can be simultaneously esti- 30 mated using the HT long training fields corresponding to the data portion of the packet is limited by 1) the Rx MCS 31 Bitmask subfield of the Supported MCS Set field and 2) the Rx STBC subfield, both of the HT Capabilities element. 32 33 34 35 7.3.2.56.7 Antenna Selection Capability 36 37 The structure of the ASEL Capability field is defined in Figure 7-95o23. 38 39 40 41 B0 B1 B2 B3 B4 B5 B6 B7 42 43 Antenna Explicit CSI 44 Indices Explicit Feedback Antenna Transmit 45 Antenna Feedback CSI Receive 46 Based Indices Sounding Selection Based Feed- ASEL Reserved 47 Transmit Feedback PPDUs Capable Transmit Capable 48 ASEL back Capable Capable ASEL 49 Capable Capable 50 Capable 51 52 Bits: 11 1 11111 53 54 Figure 7-95o23—Antenna Selection Capability field 55 56 57 58 The fields of the Antenna Selection Capability field are defined in Table 7-43p. 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table 7-43p—Subfields of the Antenna Selection Capability field 2 3 4 Antenna Selection Definition Encoding 5 Capability field 6 7 Antenna Selection Capa- Indicates whether this STA supports antenna selec- Set to 0 if not supported 8 ble tion Set to 1 if supported 9 10 Explicit CSI Feedback Indicates whether this STA supports transmit Set to 0 if not supported 11 Based Transmit ASEL antenna selection based on explicit CSI feedback Set to 1 if supported 12 Capable 13 14 Antenna Indices Feedback Indicates whether this STA supports transmit Set to 0 if not supported 15 Based Transmit ASEL antenna selection based on antenna indices feedback Set to 1 if supported 16 Capable 17 Explicit CSI Feedback Indicates whether this STA can compute CSI and Set to 0 if not supported 18 Capable provide CSI feedback in support of antenna selec- Set to 1 if supported 19 tion 20 21 Antenna Indices Feedback Indicates whether this STA can compute an antenna Set to 0 if not supported 22 Capable indices selection and return an antenna indices Set to 1 if supported 23 selection in support of antenna selection 24 25 Receive ASEL Capable Indicates whether this STA supports receive antenna Set to 0 if not supported 26 selection Set to 1 if supported 27 28 Transmit Sounding Indicates whether this STA can transmit sounding Set to 0 if not supported 29 PPDUs Capable PPDUs for antenna selection training on request Set to 1 if supported 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 7.3.2.57 HT Operation element 2 3 The operation of HT STAs in the BSS is controlled by the HT Operation element. The structure of this ele- 4 5 ment is defined in Figure 7-95o24. 6 7 B0 B1 B2 B3 B4 B7 8 9 Element Length Primary Secondary STA Channel RIFS Reserved 10 11 ID Channel Channel Off- Width Mode 12 set 13 14 Octets: 1 1 1 15 1 16 17 B0 B1 B2 B3 B4 B5 B15 18 19 HT Protection Non-greenfield HT Reserved OBSS Non-HT Reserved 20 STAs Present STAs Present 21 22 23 2 24 25 26 B0 B5 B6 B7 B8 B9 B10 B11 B12 B15 27 28 Reserved Dual Beacon Dual CTS Pro- STBC Bea- L-SIG TXOP PCO PCO Reserved Basic 29 tection con Protection Active Phase MCS 30 Full Support Set 31 32 16 33 2 34 35 Figure 7-95o24—HT Operation element format 36 37 The Element ID field is set to the value for HT Operation, specified in Table 7-26. 38 39 40 The fields of the HT Operation element are defined in Table 7-43q. The “Reserved in IBSS?” column indi- 41 cates for each field whether it is reserved (Y) or not reserved (N) when this element is present in a frame trans- 42 mitted within an IBSS. 43 44 45 46 Table 7-43q—HT Operation element 47 48 Reserved in 49 Field Definition Encoding 50 IBSS ? 51 52 Primary Indicates the channel number Channel number of the primary channel N 53 Channel of the primary channel. 54 See 11.14.2. 55 Secondary Indicates the offset of the sec- Set to 1 (SCA) if the secondary channel is above N 56 Channel ondary channel relative to the the primary channel 57 Offset primary channel. Set to 3 (SCB) if the secondary channel is below 58 the primary channel 59 Set to 0 (SCN) if no secondary channel is present 60 61 The value 2 is reserved 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table 7-43q—HT Operation element (continued) 2 3 4 Reserved in Field Definition Encoding 5 IBSS ? 6 7 STA Chan- Defines the channel widths Set to 0 for a 20 MHz channel width N 8 nel Width that may be used to transmit to Set to 1 allows use of any channel width in the 9 the STA. Supported channel width set 10 See 11.14.12 11 This field is reserved when the transmitting or 12 receiving STA is operating in a regulatory class 13 that does not include a value of 13 or 14 in the 14 behavior limits as specified in Annex J. 15 16 See NOTE 1. 17 18 RIFS Mode Indicates whether the use of Set to 0 if use of RIFS is prohibited Y 19 reduced interframe spacing Set to 1 if use of RIFS is permitted 20 (RIFS) is permitted within the 21 BSS. 22 See 9.2.3.0b and 9.13.3.3 23 24 HT Protec- Indicates protection require- Set to 0 for no protection mode Y 25 tion ments of HT transmissions. Set to 1 for non-member protection mode 26 See 9.13.3. Set to 2 for 20 MHz protection mode 27 Set to 3 for non-HT mixed mode 28 Non-green- Indicates if any HT STAs that Set to 0 if all HT STAs that are associated are HT- Y 29 field HT are not HT-greenfield capable greenfield capable 30 STAs have associated. Set to 1 if one or more HT STAs that are not HT- 31 Present Determines when a non-AP greenfield capable are associated 32 STA should use HT-green- 33 field protection. 34 Present in Beacon and Probe 35 response frames transmitted by 36 an AP. Otherwise reserved. 37 See 9.13.3.1. 38 39 OBSS Non- Indicates if the use of protec- If not operating in a regulatory class for which the Y 40 HT STAs tion for non-HT STAs by over- Behavior limits set listed in Annex J includes the 41 Present lapping BSSs is determined to value 16: 42 be desirable. 43 Set to 1 if the use of protection for non-HT STAs 44 If the BSS is operating in a by overlapping BSSs is determined to be desirable. 45 regulatory class for which the See NOTE 2. 46 Behavior limits set listed in 47 Annex J includes the value 16, Set to 0 otherwise. 48 this field indicates if there exist 49 any non-HT OBSSs and 50 whether HT-greenfield trans- If operating in a regulatory class for which the 51 missions are allowed. Behavior limits set listed in Annex J includes the 52 value 16: 53 Present in Beacon and Probe 54 response frames transmitted by Set to 1 if there exists one or more non-HT OBSSs. 55 an AP. Otherwise reserved. Indicates that HT-greenfield transmissions are dis- 56 See 9.13.3.4 and 11.9.7.3. allowed in the BSS. 57 58 Set to 0 otherwise. 59 60 Dual Bea- Indicates whether the AP Set to 0 if no STBC beacon is transmitted Y 61 con transmits an STBC beacon. Set to 1 if an STBC beacon is transmitted by the 62 AP 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table 7-43q—HT Operation element (continued) 2 3 4 Reserved in Field Definition Encoding 5 IBSS ? 6 7 Dual CTS Dual CTS Protection is used Set to 0 if Dual CTS protection is not required Y 8 Protection by the AP to set a NAV at Set to 1 if Dual CTS protection is required 9 STAs that do not support 10 STBC and at STAs that can 11 associate solely through the 12 STBC beacon. 13 See 9.2.5.5a. 14 15 STBC Bea- Indicates whether the beacon Set to 0 in a primary beacon Y 16 con containing this element is a Set to 1 in an STBC beacon 17 primary or an STBC beacon. 18 The STBC beacon has half a 19 beacon period shift relative to 20 the primary beacon. 21 Defined only in a Beacon 22 transmitted by an AP. Other- 23 wise reserved. 24 See 11.1.2.1. 25 26 L-SIG Indicates whether all HT STA Set to 0 if one or more HT STA in the BSS do not Y 27 TXOP Pro- in the BSS support L-SIG support L-SIG TXOP Protection 28 tection Full TXOP Protection. Set to 1 if all HT STA in the BSS support L-SIG 29 Support See 9.13.5. TXOP Protection 30 PCO Active Indicates whether PCO is Set to 0 if PCO is not active in the BSS Y 31 active in the BSS Set to 1 if PCO is active in the BSS 32 Present in Beacon/Probe 33 Response frames transmitted 34 by an AP. Otherwise reserved. 35 Non-PCO STAs regard the 36 BSS as a 20/40 MHz BSS and 37 may associate with the BSS 38 without regard to this field. 39 See 11.15. 40 41 PCO Phase Indicates the PCO phase of Set to 0 indicates switch to or continue 20 MHz Y 42 operation phase 43 Defined only in a Beacon and Set to 1 indicates switch to or continue 40 MHz 44 Probe Response frames when phase 45 PCO Active is 1. Otherwise 46 reserved. 47 See 11.15. 48 49 Basic MCS Indicates the MCS values that The Basic MCS Set is a bitmap of size 128 bits. Bit N 50 Set are supported by all HT STAs 0 corresponds to MCS 0. A bit is set to 1 to indi- 51 in the BSS. cate support for that MCS and 0 otherwise. 52 Present in Beacon/Probe 53 Response frames. Otherwise MCS values are defined in 7.3.2.56.4. 54 reserved. 55 56 NOTE 1—Any change of STA Channel Width value does not impact the value of the HT Protection field. 57 58 NOTE 2—Examples of when this bit may be set to 1 include, but are not limited to, when: 59 — one or more non-HT STAs are associated 60 — a non-HT BSS is overlapping (a non-HT BSS may be detected by the reception of a Beacon where the supported 61 rates only contain Clause 15, 17, 18 or 19 rates) 62 63 — a management frame (excluding a Probe Request) is received where the supported rate set includes only Clause 64 15, 17, 18 and 19 rates. 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 7.3.2.58 20/40 BSS Intolerant Channel Report element 2 3 4 The 20/40 BSS Intolerant Channel Report element contains a list of channels on which a STA has found con- 5 ditions that disallow the use of a 20/40 MHz BSS. The format of the 20/40 BSS Intolerant Channel Report 6 element is shown in Figure 7-95o25. 7 8 9 10 Element ID Length Regulatory Class Channel List 11 12 Octets: 1 1 1 Variable 13 14 Figure 7-95o25—20/40 MHz BSS Intolerant Channel Report element format 15 16 17 18 The Element ID field is equal to the 20/40 BSS Intolerant Channel Report value in Table 7-26. 19 20 21 The Length field is variable, and depends on the number of channels reported in the Channel List. The min- 22 imum value of the length field is 1 (based on a minimum length for the channel list field of 0 octets). 23 24 Regulatory Class contains an enumerated value from Annex J, encoded as an unsigned integer, specifying the 25 26 regulatory class in which the Channel List is valid. A 20/40 BSS Intolerant Channel Report only reports chan- 27 nels for a single regulatory class. Multiple 20/40 BSS Intolerant Channel Report elements are used to report 28 channels in more than one regulatory class. 29 30 31 The Channel List contains a variable number of octets, where each octet describes a single channel number. 32 Channel numbering shall be dependent on Regulatory Class according to Annex J. 33 34 35 A 20/40 BSS Intolerant Channel Report element includes only channels that are valid for the regulatory do- 36 main in which the STA transmitting the element is operating and that are consistent with the Country element 37 transmitted by the AP of the BSS of which it is a member. 38 39 40 7.3.2.59 Overlapping BSS Scan Parameters element 41 42 The Overlapping BSS Scan Parameters element is used by an AP in a BSS to indicate the values to be used 43 by BSS members when performing overlapping BSS scan operations. The format of the Overlapping BSS 44 45 Scan Parameters element is shown in Figure 7-95o26. 46 47 48 49 Element Length OBSS OBSS BSS OBSS Scan OBSS Scan BSS Width OBSS Scan 50 ID Scan Scan Channel Passive Active Total Channel Activity 51 Passive Active Width Total Per Per Channel Transition Threshold 52 Dwell Dwell Trigger Channel Delay Factor 53 Scan 54 Interval 55 56 Octets: 1 1 2 2 2 2 2 2 2 57 58 Figure 7-95o26—Overlapping BSS Scan Parameters element format 59 60 61 62 The element ID value is equal to the Overlapping BSS Scan Parameters value in Table 7-26. 63 64 65 The length field is set to 14.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 The OBSS Scan Passive Dwell field contains a value in TUs, encoded as an unsigned integer, that a receiving 2 STA uses to set its dot11OBSSScanPassiveDwell MIB variable as described in 11.14.5. 3 4 5 The OBSS Scan Active Dwell field contains a value in TUs, encoded as an unsigned integer, that a receiving 6 STA uses to set its dot11OBSSScanActiveDwell MIB variable as described in 11.14.5. 7 8 The BSS Channel Width Trigger Scan Interval field contains a value in seconds, encoded as an unsigned in- 9 10 teger, that a receiving STA uses to set its dot11BSSWidthTriggerScanInterval MIB variable as described in 11 11.14.5. 12 13 The OBSS Scan Passive Total Per Channel field contains a value in TUs, encoded as an unsigned integer, that 14 a receiving STA uses to set its dot11OBSSScanPassiveTotalPerChannel MIB variable as described in 15 16 11.14.5. 17 18 The OBSS Scan Active Total Per Channel field contains a value in TUs, encoded as an unsigned integer, that 19 a receiving STA uses to set its dot11OBSSScanActiveTotalPerChannel MIB variable as described in 11.14.5. 20 21 22 The BSS Width Channel Transition Delay Factor field contains an integer value that a receiving STA uses to 23 set its dot11BSSWidthChannelTransitionDelayFactor MIB variable as described in 11.14.5. 24 25 The OBSS Scan Activity Threshold field contains a value in hundredths of percent, encoded as an unsigned 26 27 integer, that a receiving STA uses to set its dot11OBSSScanActivityThreshold MIB variable as described in 28 11.14.5. 29 30 The use of each of these parameters is described in 11.14.5. 31 32 33 7.3.2.60 20/40 BSS Coexistence element 34 35 The 20/40 BSS Coexistence element is used by STAs to exchange information that affects 20/40 BSS Coex- 36 istence. 37 38 39 The 20/40 BSS Coexistence element is formatted as shown in Figure 7-95o27. 40 41 42 43 B0 B1 B2 B3 B4 B5 B7 44 45 Element Length Information Forty MHz 20 MHz OBSS OBSS Reserved 46 ID Request Intolerant BSS Width Scanning Scanning 47 Request Exemption Exemption 48 Request Grant 49 50 Octets: 1 1 51 1 52 53 54 Figure 7-95o27—20/40 BSS Coexistence element format 55 56 57 58 The Element ID field is set to the value for 20/40 BSS Coexistence element defined in Table 7-26. 59 60 The Information Request field is used to indicate that a transmitting STA is requesting the recipient to trans- 61 mit a 20/40 BSS Coexistence Management frame with the transmitting STA as the recipient. 62 63 64 The Forty MHz Intolerant field, when set to 1, prohibits an AP that receives this information or reports of this 65 information from operating a 20/40 MHz BSS. When set to 0, it does not prohibit a receiving AP from oper-

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 ating a 20/40 MHz BSS. This field is used for inter-BSS communication. The definition of this field is the 2 same as the definition of the Forty MHz Intolerant field in the HT Capabilities element (see 7.3.2.56) and its 3 operation is described in 11.14.11. 4 5 6 The 20 MHz BSS Width Request field, when set to 1, prohibits a receiving AP from operating its BSS as a 7 20/40 MHz BSS. Otherwise it is set to 0. This field is used for intra-BSS communication. The operation of 8 this field is described in 11.14.12. 9 10 11 The OBSS Scanning Exemption Request field is set to 1 to indicate that the transmitting non-AP STA is re- 12 questing the BSS to allow the STA to be exempt from OBSS scanning. Otherwise it is set to 0. The OBSS 13 Scanning Exemption Request field is reserved when transmitted by an AP. The OBSS Scanning Exemption 14 Request field is reserved when a 20/40 BSS Coexistence element is included in a group addressed frame. 15 16 17 The OBSS Scanning Exemption Grant field is set to 1 by an AP to indicate that the receiving STA is exempted 18 from performing OBSS Scanning. Otherwise it is set to 0. The OBSS Scanning Exemption Grant field is re- 19 served when transmitted by a non-AP STA. The OBSS Scanning Exemption Grant field is reserved when a 20 20/40 BSS Coexistence element is included in a group addressed frame. 21 22 23 24 7.4 Action frame format details 25 26 7.4.1 Spectrum management action details 27 28 29 7.4.1.5 Channel Switch Announcement frame format 30 31 Replace Figure 7-100 with the following figure: 32 33 EDITORIAL NOTE—The changes comprise insertion of the Secondary Channel Offset element field at 34 the end of the existing structure. 35 36 37 38 Action Channel Switch 39 Category Secondary Channel Offset element 40 Value Announcement element 41 42 Octets 1 1 5 3 43 44 Figure 7-100—Channel Switch Announcement frame body format 45 46 47 48 Insert the following paragraph at the end of 7.4.1.5: 49 50 The Secondary Channel Offset element is defined in 7.3.2.20a. This element is present when switching to a 51 40 MHz channel. It may be present when switching to a 20 MHz channel (in which case the secondary chan- 52 53 nel offset is set to SCN). 54 55 7.4.3 DLS Action frame details 56 57 58 7.4.3.1 DLS Request frame format 59 60 Change the first paragraph of 7.4.3.1 as follows: 61 62 The DLS Request frame is used to set up a direct link with a peer MAC. The frame body of the DLS Request 63 64 frame contains the information shown in Table 7-51, with some fields being optionally present as indicated 65 in the Notes column of the table.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Change Table 7-51 by inserting a new column to the right headed “Notes” 2 3 Insert the following additional row at the end of Table 7-51: 4 5 6 7 Table 7-51—DLS Request frame body 8 9 10 Order Information Notes 11 HT Capabilities The HT Capabilities element shall be present when the 12 9 13 dot11HighThroughputOptionImplemented attribute is TRUE 14 15 16 17 7.4.3.2 DLS Response frame format 18 19 Change the first paragraph of 7.4.3.2 as follows: 20 21 22 The DLS Response frame is sent in response to a DLS Request frame. The frame body of a DLS Response 23 24 frame contains the information shown in Table 7-52, with some fields being optionally present as indicated 25 in the Notes column of the table. 26 27 Change Table 7-52 by inserting a new column to the right headed “Notes” 28 29 30 Insert the following additional row at the end of Table 7-52: 31 32 33 Table 7-52—DLS Response frame body 34 35 36 Order Information Notes 37 38 HT Capabilities The HT Capabilities element shall be present when the 9 39 dot11HighThroughputOptionImplemented attribute is TRUE 40 41 42 43 7.4.4 Block Ack Action frame details 44 45 46 Change the first paragraph of 7.4.4 as follows: 47 48 49 The ADDBA frames are used to set up or, if PBAC is used, to modify Block Ack for a specific TC or TS. 50 The Action field value associated with each frame format within the Block Ack category are defined in Table 51 52 7-54. 53 54 7.4.7 Public Action frame details 55 56 57 7.4.7.1 Public Action frame 58 59 Change the first paragraph of 7.4.7.1 as follows: 60 61 62 The Public Action frame is defined to allow inter-BSS and AP to unassociated-STA communications in 63 addition to intra-BSS communication. The defined Public Action frames are listed in Table 7-57e (Public 64 65 Action field values).

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Change Table 7-57e row with an action field value of 0 as follows: 2 3 4 Table 7-57e—Public Action field values 5 6 7 Action field value Meaning 8 9 0 Reserved 20/40 BSS Coexistence Management (see 7.4.7.1a) 10 11 12 13 Insert the following subclause 7.4.7.1a after 7.4.7.1: 14 15 16 7.4.7.1a 20/40 BSS Coexistence Management frame format 17 18 19 The 20/40 BSS Coexistence Management frame is an Action frame of category Public. The format of its 20 frame body is defined in Table 7-57e1 21 22 23 24 Table 7-57e1—20/40 BSS Coexistence Management frame body 25 26 27 Order Information Notes 28 Category 29 1 30 Action 31 2 32 20/40 BSS Coexistence (see 7.3.2.60) 33 3 34 4 20/40 BSS Intolerant Channel Report May appear zero or more times 35 (see 7.3.2.58) 36 37 38 39 The Category field is set to the value for Public, specified in Table 7-24. 40 41 42 The Action field is set to value for 20/40 BSS Coexistence Management, specified in Table 7-57e. 43 44 Insert the following subclauses (7.4.10 to 7.4.10.9) after 7.4.9.2: 45 46 47 7.4.10 HT Action frame details 48 49 50 7.4.10.1 HT Action field 51 52 Several Action frame formats are defined to support HT features. The Action field values associated with 53 54 each frame format within the HT category are defined in Table 7-57m. The frame formats are defined in 55 7.4.10.2 to 7.4.10.9. 56 57 58 7.4.10.2 Notify Channel Width frame format 59 60 61 A STA sends the Notify Channel Width Action Frame to another STA if it wants to change the Channel Width 62 of frames that the other STA sends to it. See definition in 11.14.2. 63 64 65 The format of the Notify Channel Width Action frame is defined in Table 7-57n.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table 7-57m—HT Action field values 2 3 4 Action field value Meaning 5 6 0 Notify Channel Width 7 8 1 SM Power Save 9 10 2 PSMP 11 3 Set PCO Phase 12 13 4 CSI 14 15 5 Non-compressed Beamforming 16 17 6 Compressed Beamforming 18 19 7 Antenna Selection Indices Feedback 20 8-255 Reserved 21 22 23 24 Table 7-57n—Notify Channel Width 25 26 27 Order Information 28 29 1 Category 30 31 2 Action 32 33 3 Channel Width (see 7.3.1.21) 34 35 36 This frame can be sent by both non-AP STA and AP. If an AP wishes to receive 20 MHz packets, it broadcasts 37 this Action frame to all STAs in the BSS. In addition, the AP indicates its current STA Channel Width in the 38 39 HT Operation element in the beacon. 40 41 The Category field is set to the value for HT, specified in Table 7-24. 42 43 44 The Action field is set to the value for Notify Channel Width, specified in Table 7-57m. 45 46 7.4.10.3 SM Power Save frame format 47 48 49 The SM Power Save Action frame is of Category HT. The SM Power Save frame is used to manage spatial 50 multiplexing power saving state transitions as defined in 11.2.3. 51 52 53 The frame body of the SM Power Save Action frame is defined in Table 7-57o. 54 55 56 Table 7-57o—SM Power Save 57 58 59 Order Information 60 61 1 Category 62 63 2Action 64 65 3 SM Power Control (see 7.3.1.22)

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 The Category field is set to the value for HT, specified in Table 7-24. 2 3 4 The Action field is set to the value for SM Power Save, specified in Table 7-57m. 5 6 7.4.10.4 PSMP frame format 7 8 9 PSMP (Power Save Multi-Poll) is an Action frame of category HT. 10 11 The DA field of this frame is a group address. (See 9.16.1.8). 12 13 14 The PSMP Parameter Set field and PSMP STA Info fields define zero or more PSMP-DTT (downlink) and 15 PSMP-UTT (uplink) time allocations that follow immediately after the PSMP frame. 16 17 18 The frame body of this frame is defined in Table 7-57p. The PSMP Parameter Set field is followed by zero 19 or more PSMP STA Info fields. 20 21 22 Table 7-57p—Format of the PSMP Management Action field 23 24 25 Order Information 26 27 1 Category 28 29 2 Action 30 31 3 PSMP Parameter Set (see 7.3.1.24) 32 33 4 to (N_STA+3) PSMP STA Info (see 7.3.1.25) 34 Repeated N_STA times (N_STA is a subfield of the PSMP Parameter Set 35 field) 36 37 38 39 The Category field is set to the value for HT, specified in Table 7-24. 40 41 The Action field is set to the value for PSMP, specified in Table 7-57m. 42 43 44 The PSMP STA Info fields within a PSMP frame are ordered by STA_INFO Type as follows: group ad- 45 dressed (STA_INFO Type=1) and then individually addressed (STA_INFO Type=2). 46 47 48 7.4.10.5 Set PCO Phase frame format 49 50 Set PCO Phase is an Action frame of category HT that announces the phase change between 20 MHz and 40 51 MHz. The format of its frame body is defined in Table 7-57q. The operation of the PCO feature is defined in 52 53 11.15. 54 55 56 Table 7-57q—Set PCO Phase 57 58 59 Order Information 60 61 1 Category 62 63 2Action 64 65 3 PCO Phase Control (see 7.3.1.23)

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 The Category field is set to the value for HT, specified in Table 7-24. 2 3 The Action field is set to the value for Set PCO Phase, specified in Table 7-57m. 4 5 6 This frame is sent by a PCO active AP. 7 8 7.4.10.6 CSI frame format 9 10 11 The CSI frame is an Action or an Action No Ack frame of category HT. The format of its frame body is de- 12 fined in Table 7-57r. 13 14 15 Table 7-57r—CSI 16 17 18 Order Information 19 20 1 Category 21 22 2 Action 23 24 3 MIMO Control (see 7.3.1.26) 25 26 4 CSI Report (see 7.3.1.27) 27 28 29 The Category field is set to the value for HT, specified in Table 7-24. 30 31 32 The Action field is set to the value for CSI, specified in Table 7-57m. 33 34 In a CSI frame, the fields of the MIMO Control field (see 7.3.1.26) are used as described in Table 7-25c. The 35 Codebook Information subfield is reserved in this frame. 36 37 38 7.4.10.7 Non-compressed Beamforming frame format 39 40 The Non-compressed Beamforming frame is an Action or an Action No Ack frame of category HT. The for- 41 mat of the frame body is defined in Table 7-57s. 42 43 44 45 Table 7-57s—Non-compressed Beamforming 46 47 48 Order Information 49 50 1Category 51 52 2Action 53 3 MIMO Control (see 7.3.1.26) 54 55 4 Non-compressed Beamforming Report 56 (see 7.3.1.28) 57 58 59 60 The Category field is set to the value for HT, specified in Table 7-24. 61 62 The Action field is set to the value for Non-compressed Beamforming, specified in Table 7-57m. 63 64 65 In a Non-compressed Beamforming frame, the fields of the MIMO Control field (see 7.3.1.26) are used as

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 described in Table 7-25c. The Codebook Information subfield is reserved in this frame. 2 3 7.4.10.8 Compressed Beamforming frame format 4 5 6 The Compressed Beamforming frame is an Action or an Action No Ack frame of category HT. The format 7 of its frame body is defined in Table 7-57t. 8 9 10 Table 7-57t—Compressed Beamforming 11 12 13 Order Information 14 15 1 Category 16 17 2 Action 18 19 3 MIMO Control (see 7.3.1.26) 20 21 4 Compressed Beamforming Report 22 (see 7.3.1.29) 23 24 25 26 The Category field is set to the value for HT, specified in Table 7-24. 27 28 The Action field is set to the value for Compressed Beamforming), specified in Table 7-57m. 29 30 In a Compressed Beamforming frame, the fields of the MIMO Control field (see 7.3.1.26) are used as de- 31 32 scribed in Table 7-25c. The Coefficient Size subfield is reserved in this frame. 33 34 7.4.10.9 Antenna Selection Indices Feedback frame format 35 36 The Antenna Selection Indices Feedback frame is carried in a Action or Action No Ack frame of category 37 38 HT. The format of its frame body is defined in Table 7-57u. 39 40 41 Table 7-57u—Antenna Selection Indices Feedback 42 43 44 Order Information 45 46 1 Category 47 48 2Action 49 50 3 Antenna Selection Indices (see 7.3.1.30) 51 52 53 The Category field is set to the value for HT, specified in Table 7-24. 54 55 56 The Action field is set to the value for Antenna Selection Indices Feedback, specified in Table 7-57m. 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Insert the following subclauses 7.4a to 7.4a.3 after 7.4 and its subclauses, if any: 2 3 4 7.4a Aggregate MPDU (A-MPDU) 5 6 7 7.4a.1 A-MPDU format 8 9 10 An A-MPDU consists of a sequence of one or more A-MPDU subframes as shown in Figure 7-101o. 11 12 13 A-MPDU subframe 1 A-MPDU subframe 2 … A-MPDU subframe n 14 15 Octets: variable variable variable 16 17 18 Figure 7-101o—A-MPDU format 19 20 21 22 Each A-MPDU subframe consists of an MPDU delimiter followed by an MPDU. Except when it is the last 23 A-MPDU subframe in an A-MPDU, padding octets are appended to make each A-MPDU subframe a multiple 24 25 of 4 octets in length. The A-MPDU maximum length is 65 535 octets. The length of an A-MPDU addressed 26 to a particular STA may be further constrained as described in 9.7d.2. 27 28 29 The MPDU delimiter is 4 octets in length. The structure of the MPDU Delimiter field is defined in Figure 7- 30 101p. 31 32 33 34 Bits: B0 B3 B4 B15 B16 B23 B24 B31 35 36 Reserved MPDU length CRC Delimiter Signature MPDU Pad 37 MPDU Delimiter 38 Octets: Variable 0-3 39 4 40 41 Figure 7-101p—A-MPDU subframe format 42 43 44 45 The fields of the MPDU Delimiter field are defined in Table 7-57v. 46 47 48 49 Table 7-57v— MPDU Delimiter fields 50 51 MPDU delimiter Size 52 Description 53 Field (bits) 54 55 Reserved 4 56 MPDU length 12 Length of the MPDU in octets 57 58 CRC 8 8-bit CRC of the preceding 16-bits. 59 60 Delimiter Signature 8 Pattern that may be used to detect an MPDU delimiter when scanning for a 61 delimiter. 62 The unique pattern is set to the value 0x4E. 63 64 NOTE—As the Delimiter Signature field was created by the IEEE 802.11 Task 65 Group n, it chose the ASCII value for the character ‘N’ as the unique pattern.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 The purpose of the MPDU delimiter is to locate the MPDUs within the A-MPDU such that the structure of 2 the A-MPDU can usually be recovered when one or more MPDU delimiters are received with errors. See T.2 3 for a description of a de-aggregation algorithm. 4 5 6 A delimiter with MPDU length zero is valid. This is used as defined in 9.7d.3 to meet the Minimum MPDU 7 Start Spacing requirement. 8 9 10 7.4a.2 MPDU Delimiter CRC field 11 12 The MPDU Delimiter CRC field is an 8-bit CRC value. It is used as a Frame Check Sequence (FCS) to protect 13 the Reserved and MPDU length fields. The CRC field is the one’s complement of the remainder generated 14 15 by the modulo 2 division of the protected bits by the polynomial xxx8211 , where the shift-register 16 state is preset to all-ones. 17 NOTE—The order of transmission of bits within the CRC field is defined in 7.1.1. 18 19 20 Figure 7-101q illustrates the CRC calculation for the MPDU Delimiter. 21

22 Delimiter) (MPDU 23 24 B15…..B0 25 26 27 28 The feedback term is set to 0 29 during the shifting out of the result. 30 0 31 Serial c c c c c c c c 32 Input 7 6 5 4 3 2 1 0 33 34 35 C7==B16 36 Serial B16...B23 37 Output (MPDU Delimiter) 38 39 Figure 7-101q—MPDU delimiter CRC calculation 40 41 7.4a.3 A-MPDU contents 42 43 44 An A-MPDU is a sequence of MPDUs carried in a single PPDU with the TXVECTOR/RXVECTOR AG- 45 GREGATION parameter set to 1. 46 47 48 All the MPDUs within an A-MPDU are addressed to the same receiver address. All QoS data frames within 49 an A-MPDU that have a TID for which an HT-immediate Block Ack agreement exists have the same value 50 for the Ack Policy subfield of the QoS Control field. 51 52 The Duration/ID fields in the MAC Headers of all MPDUs in an A-MPDU carry the same value. 53 54 55 An A-MPDU is transmitted in one of the contexts specified in Table 7-57w. Ordering of MPDUs within an 56 A-MPDU is not constrained, except where noted in these tables. See 9.7d.1. 57 NOTE—1 The TIDs present in a data enabled A-MPDU context are also constrained by the channel access rules (for a 58 TXOP holder, see 9.9.1 and 9.9.2) and the reverse direction response rules (for an RD responder, see 9.15.4). This is not 59 shown in these tables. 60 61 NOTE—2 MPDUs carried in an A-MPDU are limited to a maximum length of 4095 octets. If a STA supports A- 62 MSDUs of 7935 octets (indicated by the Maximum A-MSDU length field in the HT Capabilities element), A-MSDUs 63 transmitted by that STA within an A-MPDU are constrained so that the length of the QoS data MPDU carrying the A- 64 MSDU is no more than 4095 octets. The use of A-MSDU within A-MPDU can be further constrained as described in 65 7.3.1.14 through the operation of the A-MSDU Supported field.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table 7-57w—A-MPDU Contexts 2 3 4 Table defining Name of Context Definition of Context 5 permitted contents 6 7 Data Enabled The A-MPDU is transmitted outside a PSMP sequence by a Table 7-57x 8 Immediate TXOP holder or an RD responder including potential immedi- 9 Response ate responses. 10 11 Data Enabled No The A-MPDU is transmitted outside a PSMP sequence by a Table 7-57y 12 Immediate TXOP holder that does not include or solicit an immediate 13 Response response. 14 See NOTE. 15 16 PSMP The A-MPDU is transmitted within a PSMP sequence. Table 7-57z 17 Control Response The A-MPDU is transmitted by a STA that is neither a TXOP Table 7-57aa 18 holder nor an RD responder that also needs to transmit one of 19 the following immediate response frames: 20 21 a) Ack 22 b) BlockAck with a TID for which an HT-immediate 23 Block Ack agreement exists 24 25 NOTE—this includes cases when no response is generated, or when a response is generated later by the operation 26 of the delayed Block Ack rules. 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table 7-57x—A-MPDU contents in the data enabled immediate response context 2 3 4 MPDU Description Conditions 5 6 ACK MPDU If the preceding PPDU contains an MPDU that requires an 7 ACK response, a single ACK MPDU at the start of the A- 8 MPDU. 9 HT-immediate BlockAck If the preceding PPDU contains an implicit or explicit At most one of these 10 MPDUs is present. 11 Block Ack request for a TID for which an HT-immediate 12 Block Ack agreement exists, 13 at most one BlockAck for this TID, in which case it occurs 14 at the start of the A-MPDU. 15 16 Delayed BlockAcks BlockAck frames with the BA Ack Policy field set to No Acknowledgement with a 17 TID for which an HT-delayed Block Ack agreement exists. 18 19 20 Delayed Block Ack data QoS Data MPDUs with a TID that corresponds to a Delayed or HT-delayed Block 21 Ack agreement. 22 These have the Ack Policy field set to Block Ack. 23 24 Action No Ack Management frames of subtype Action No Ack. 25 26 27 28 Delayed BlockAckReqs BlockAckReq MPDUs with a TID that corresponds to an HT-delayed Block Ack 29 agreement in which the BA Ack Policy field is set to No Acknowledgement. 30 31 32 Data MPDUs sent under an QoS Data MPDUs with the same TID, 33 HT-immediate Block Ack which corresponds to an HT-immediate 34 agreement. Block Ack agreement. 35 Of these, at most one of the following These MPDUs all have the Ack Policy 36 is present: 37 field set to the same value, which is either a) One or more QoS Data 38 Implicit Block Ack Request or Block Ack. 39 MPDUs with the Ack Policy 40 Immediate BlockAckReq At most one BlockAckReq frame with a field set to Implicit Block 41 TID that corresponds to an HT-immediate Ack Request, Block Ack agreement. 42 b) BlockAckReq. 43 This is the last MPDU in the A-MPDU. 44 45 It is not present if any QoS data frames for 46 that TID are present. 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table 7-57y—A-MPDU contents in the data enabled no immediate response context 2 3 4 MPDU Description Conditions 5 6 Delayed BlockAcks BlockAck frames for a TID for which an HT-delayed Block Ack agreement exists 7 with the BA Ack Policy field set to No Acknowledgement. 8 9 10 11 Delayed Block Ack data QoS Data MPDUs with a TID that corresponds to a Delayed or HT-delayed Block 12 Ack agreement. 13 These have the Ack Policy field set to Block Ack. 14 15 Data without a Block Ack QoS Data MPDUs with a TID that does not correspond to a Block Ack agreement. 16 agreement These have the Ack Policy field set to No Ack and the A-MSDU Present subfield 17 set to 0. 18 Action No Ack Management frames of subtype Action No Ack. 19 20 21 22 Delayed BlockAckReqs BlockAckReq MPDUs with the BA Ack Policy field set to No Acknowledgement 23 and with a TID that corresponds to an HT-delayed Block Ack agreement. 24 25 26 27 28 Table 7-57z—A-MPDU contents in the PSMP context 29 30 31 MPDU Description Conditions 32 33 Acknowledgement for PSMP data At most one Multi-TID BlockAck MPDU. 34 35 Acknowledgement in response to data received with the Ack Policy field 36 set to PSMP Ack and/or a Multi-TID BlockAckReq MPDU in the previous 37 PSMP-UTT or PSMP-DTT. 38 39 Delayed BlockAcks BlockAck frames with the BA Ack Policy field set to No Acknowledge- 40 ment and with a TID for which an HT-delayed Block Ack agreement exists. 41 42 HT-immediate Data QoS Data MPDUs in which the Ack Pol- 43 icy field is set to PSMP Ack or Block 44 Ack and with a TID that corresponds to 45 an HT-immediate Block Ack agreement. 46 47 Delayed Block Ack data QoS Data MPDUs with a TID that corre- 48 sponds to a Delayed or HT-delayed Block An A-MPDU containing 49 Ack agreement. MPDUs with a Block Ack 50 These have the Ack Policy field set to agreement, cannot also con- 51 Block Ack. tain MPDUs without a Block 52 Ack agreement. 53 Data without a Block Ack agreement QoS Data MPDUs with a TID that does 54 not correspond to a Block Ack agree- 55 ment. 56 These have the Ack Policy field set to No 57 Ack and the A-MSDU Present subfield is 58 set to 0. 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table 7-57z—A-MPDU contents in the PSMP context (continued) 2 3 4 MPDU Description Conditions 5 6 Action No Ack Management frames of subtype Action No Ack. 7 8 9 Delayed BlockAckReqs BlockAckReq MPDUs a with the BA Ack Policy field set to No Acknowl- 10 edgement and with a TID that corresponds to an HT-delayed Block Ack. 11 12 Multi-TID BlockAckReq At most one Multi-TID BlockAckReq MPDU with the BA Ack Policy field 13 set to No Ack. 14 15 16 Table 7-57aa—A-MPDU contents MPDUs in the control response context 17 18 19 MPDU Conditions 20 21 ACK ACK transmitted in response to an MPDU that 22 requires an ACK. 23 Only one of these is present at the 24 BlockAck BlockAck with a TID that corresponds to an start of the A-MPDU. 25 HT-immediate Block Ack agreement. 26 27 Action No Management frames of subtype Action No Ack +HTC carrying a Management Action 28 Ack Body containing an explicit feedback response. 29 30 31 32 7.5 Frame usage 33 34 Delete subclause 7.5 in its entirety (including the subclause heading and Table 7-58) 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 8. Security 2 3 4 8.1 Framework 5 6 7 8.1.5 RSNA assumptions and constraints 8 9 Insert the following paragraph at the end of subclause 8.1.5: 10 11 12 An HT STA shall not use either of the pairwise cipher suite selectors: “Use group cipher suite” or TKIP to 13 communicate with another HT STA. 14 15 16 8.3 RSNA data confidentiality protocols 17 18 19 8.3.3 CTR with CBC-MAC Protocol (CCMP) 20 21 8.3.3.3 CCMP cryptographic encapsulation 22 23 8.3.3.3.2 Construct AAD 24 25 26 Change the third paragraph of 8.3.3.3.2 as follows: 27 28 The AAD is constructed from the MPDU header. The AAD does not include the header Duration field, 29 30 because the Duration field value can change due to normal IEEE 802.11 operation (e.g., a rate change during 31 retransmission). The AAD includes neither the Duration/ID field nor the HT Control field, because the con- 32 tents of these fields can change during normal operation (e.g., due to a rate change preceding re-transmis- 33 sion). The HT Control field can also be inserted or removed during normal operation (e.g., retransmission of 34 an A-MPDU, where the original A-MPDU included an MCS request that has already generated a response). 35 36 For similar reasons, several subfields in the Frame Control field are masked to 0. AAD construction is per- 37 formed as follows: 38 a) FC – MPDU Frame Control field, with 39 40 1) Subtype bits (bits 4 5 6) in a Data MPDU masked to 0 41 2) Retry bit (bit 11) masked to 0 42 43 3) PwrMgt bit (bit 12) masked to 0 44 45 4) MoreData bit (bit 13) masked to 0 46 5) Protected Frame bit (bit 14) always set to 1 47 48 6) Order bit (bit 15) as follows: 49 i) masked to 0 in all data MPDUs containing a QoS Control field 50 51 ii) unmasked otherwise 52 b) A1 – MPDU Address 1 field. 53 54 c) A2 – MPDU Address 2 field. 55 d) A3 – MPDU Address 3 field. 56 57 e) SC – MPDU Sequence Control field, with the Sequence Number subfield (bits 4–15 of the Sequence 58 Control field) masked to 0. The Fragment Number subfield is not modified. 59 60 f) A4 – MPDU Address field, if present. 61 g) QC – QoS Control field, if present, a 2-octet field that includes the MSDU priority. The QC TID 62 field is used in the construction of the AAD. When both the STA and its peer have their SPP A- 63 64 MSDU Capable fields set to 1, bit 7 (the A-MSDU Present field) is used in the construction of the 65 AAD. ,, and tThe remaining QC fields are maskedset to 0 for the AAD calculation (bits 4 to 6, bits 8

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 to 15, and bit 7 when either the STA or its peer has the SPP A-MSDU Capable field set to 0are set to 2 0). 3 4 5 8.3.3.3.5 CCM originator processing 6 7 Change item c) of the second paragraph of this subclause as follows: 8 9 c) Frame body: the frame body of the MPDU (1–79192296 octets; 79192296 = 79352312 – 8 MIC octets – 10 11 8 CCMP header octets). 12 13 8.3.3.4 CCMP decapsulation 14 15 8.3.3.4.3 PN and replay detection 16 17 18 Change list items e), f) and g) of 8.3.3.4.3 as follows: 19 20 e) For each PTKSA, GTKSA, and STKSA, the recipient shall maintain a separate replay counter for 21 each IEEE 802.11 MSDU or A-MSDU priority and shall use the PN recovered from a received 22 frame to detect replayed frames, subject to the limitation of the number of supported replay counters 23 indicated in the RSN Capabilities field (see 7.3.2.25). A replayed frame occurs when the PN 24 extracted from a received frame is less than or equal to the current replay counter value for the 25 26 frame’s MSDU or A-MSDU priority and frame type. A transmitter shall not use IEEE 802.11 27 MSDU or A-MSDU priorities without ensuring that the receiver supports the required number of 28 replay counters. The transmitter shall not reorder frames within a replay counter, but may reorder 29 frames across replay counters. One possible reason for reordering frames is the IEEE 802.11 MSDU 30 or A-MSDU priority. 31 32 For each IGTKSA the recipient shall maintain a single frame replay counter for protected broadcast/ 33 multicast Robust Management frames, and shall compare the PN recovered from a received, pro- 34 tected broadcast/multicast Robust Action frame to the replay counter to detect replayed frames as 35 36 described above for data frames. 37 f) The receiver shall discard MSDUs, A-MSDUs and MMPDUs whose constituent MPDU PN values 38 are not sequential. sequential. A receiver shall discard any MPDU that is received with its PN less 39 40 than or equal to the replay counter. When discarding a frame, the receiver shall increment by 1 the 41 value of dot11RSNAStatsCCMPReplays for data frames or 42 dot11RSNAStatsRobustMgmtCCMPReplays for Robust Management frames. 43 44 g) For MSDUs or A-MSDUs sent using the Block Ack feature, reordering of received MSDUs or A- 45 MSDUs according to the Block Ack receiver operation (described in 9.10.4) is performed prior to 46 replay detection. 47 48 49 8.4 RSNA security association management 50 51 52 8.4.3 RSNA policy selection in an ESS 53 54 Change the third paragraph of 8.4.3 as follows: 55 56 The STA’s SME initiating an association shall insert an RSN information element into its (Re)Association 57 58 Request;, via the MLME-ASSOCIATE.request primitive, when the targeted AP indicates RSNA support. 59 The initiating STA’s RSN information element shall include one authentication and pairwise cipher suite 60 from among those advertised by the targeted AP in its Beacon and Probe Response frames. It shall also spec- 61 ify the group cipher suite specified by the targeted AP. If at least one RSN information element field from the 62 AP’s RSN information element fails to overlap with any value the STA supports, the STA shall decline to 63 64 associate with that AP. An HT STA shall eliminate TKIP as a choice for the pairwise cipher suite if CCMP 65 is advertised by the AP or if the AP included an HT Capabilities element in its Beacons and Probe Responses.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 The elimination of TKIP as a choice for the pairwise cipher suite may result in a lack of overlap of the re- 2 maining pairwise cipher suite choices, in which case, the STA shall decline to create an RSN association with 3 that AP. 4 5 6 8.4.4 RSNA policy selection in an IBSS and for DLS 7 8 Change the first paragraph of 8.4.4 as follows: 9 10 11 In an IBSS, all STAs must use a single group cipher suite, and all STAs must support a common subset of 12 pairwise cipher suites. However, the SMEs of any pair of non-HT STAs may negotiate to use any common 13 pairwise cipher suite they both support. Each STA shall include the group cipher suite and its list of pairwise 14 cipher suites in its Beacon and Probe Response messages. Two STAs shall not establish a PMKSA unless 15 16 they have advertised the same group cipher suite. Similarly, the two STAs shall not establish a PMKSA if the 17 STAs have advertised disjoint sets of pairwise cipher suites. 18 19 An HT STA that is in an IBSS or that is transmitting frames through a direct link shall eliminate TKIP as a 20 choice for the pairwise cipher suite if CCMP is advertised by the other STA or if the other STA included an 21 22 HT Capabilities element in any of its Beacon, Probe Response, DLS Request or DLS Response messages. 23 NOTE—The elimination of TKIP as a choice for the pairwise cipher suite might result in a lack of overlap of the remain- 24 ing pairwise cipher suites choices, in which case, the STAs will not exchange encrypted frames. 25 26 27 8.7 Per-frame pseudo-code 28 29 8.7.2 RSNA frame pseudo-code 30 31 32 Change 8.7.2 as follows: 33 34 STAs transmit protected MSDUs, or MMPDUs, or A-MSDUs to an RA when temporal keys are configured 35 and an MLME.SETPROTECTION. request primitive has been invoked with ProtectType parameter Tx, 36 Rx_Tx, Tx_MMPDU or Rx_Tx_MMPDU to that RA. STAs expect to receive protected MSDUs, or MMP- 37 38 DUs, or A-MSDUs from a TA when temporal keys are configured and an MLME.SETPROTECTION.re- 39 quest primitive has been invoked with ProtectType parameter Rx, Rx_Tx, Rx_MMPDU or Rx_Tx_MMPDU 40 from that TA. MSDUs, or MMPDUs, or A-MSDUs that do not match these conditions are sent in the clear 41 and are received in the clear. 42 43 Change heading 8.7.2.1 as follows: 44 45 46 8.7.2.1 Per-MSDU/Per-A-MSDU Tx pseudo-code 47 48 Change 8.7.2.1 as follows: 49 50 if dot11RSNAEnabled = trueTRUE then 51 if MSDU or A-MSDU has an individual RA and Protection for RA is off for Tx then 52 53 transmit the MSDU or A-MSDU without protections 54 else if (MPDU has individual RA and Pairwise key exists for the MPDU’s RA) or 55 (MPDU has a multicast or broadcast group addressed RA 56 and network type is IBSS and IBSS GTK exists for MPDU’s TA) then 57 // If we find a suitable Pairwise or GTK for the mode we are in… 58 59 if key is a null key then 60 discard the entire MSDU or A-MSDU and generate one or more an 61 MA-UNITDATA.confirm primitives to notify LLC that the MSDUs waswere 62 undeliverable due to a null key 63 64 else 65 // Note that it is assumed that no entry will be in the key

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 // mapping table of a cipher type that is unsupported. 2 Set the Key ID subfield of the IV field to zero. 3 if cipher type of entry is AES-CCM then 4 5 Transmit the MSDU or A-MSDU, to be protected after fragmentation using 6 AES-CCM 7 else if cipher type of entry is TKIP then 8 Compute MIC using Michael algorithm and entry’s Tx MIC key. 9 10 Append MIC to MSDU 11 Transmit the MSDU, to be protected with TKIP 12 else if cipher type of entry is WEP then 13 Transmit the MSDU, to be protected with WEP 14 endif 15 16 endif 17 else // Else we didn’t find a key but we are protected, so handle the default key case or discard 18 if GTK entry for Key ID contains null then 19 discard the MSDU or A-MSDU and generate anone or more MAUNITDATA. confirm 20 primitives to notify LLC that the entire MSDUs waswere undeliverable due to a 21 22 null GTK 23 else if GTK entry for Key ID is not null then 24 Set the Key ID subfield of the IV field to the Key ID. 25 if MPDU has an individual RA and cipher type of entry is not TKIP then 26 27 discard the entire MSDU or A-MSDU and generate anone or more 28 MAUNITDATA. confirm primitives to notify LLC that the entire MSDUs 29 waswere undeliverable due to a null key 30 else if cipher type of entry is AES-CCM then 31 Transmit the MSDU or A-MSDU, to be protected after fragmentation using 32 33 AES-CCM 34 else if cipher type of entry is TKIP then 35 Compute MIC using Michael algorithm and entry’s Tx MIC key. 36 Append MIC to MSDU 37 38 Transmit the MSDU, to be protected with TKIP 39 else if cipher type of entry is WEP then 40 Transmit the MSDU, to be protected with WEP 41 endif 42 endif 43 44 endif 45 endif 46 47 8.7.2.2 Per-MPDU Tx pseudo-code 48 49 50 Change 8.7.2.2 as follows: 51 if dot11RSNAEnabled = TRUE then 52 53 if MPDU is member of an MSDU that is to be transmitted without protections 54 transmit the MPDU without protections 55 else if MSDU or A-MSDU that MPDU is a member of is to be protected using AES-CCM 56 Protect the MPDU using entry’s key and AES-CCM 57 58 Transmit the MPDU 59 else if MSDU that MPDU is a member of is to be protected using TKIP 60 Protect the MPDU using TKIP encryption 61 Transmit the MPDU 62 else if MSDU that MPDU is a member of is to be protected using WEP 63 64 Encrypt the MPDU using entry’s key and WEP 65 Transmit the MPDU

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 else 2 // should not arrive here 3 endif 4 5 endif 6 7 8.7.2.4 Per-MSDU/A-MSDU Rx pseudo-code 8 9 Change 8.7.2.4 as follows: 10 11 if dot11RSNAEnabled = TRUE then 12 if the frame was not protected then 13 14 Receive the MSDU or A-MSDU unprotected 15 Make MSDU(s) available to higher layers 16 else// Have a protected MSDU or A-MSDU 17 if Pairwise key is an AES-CCM key then 18 Accept the MSDU or A-MSDU if its MPDUs had sequential PNs (or if it consists of only 19 20 one MPDU), otherwise discard the MSDU or A-MSDU as a replay attack and 21 increment dot11RSNAStatsCCMPReplays 22 Make MSDU(s) available to higher layers 23 else if Pairwise key is a TKIP key then 24 Compute the MIC using the Michael algorithm 25 26 Compare the received MIC against the computed MIC 27 discard the frame if the MIC fails increment dot11RSNAStatsTKIPLocalMICFailures 28 and invoke countermeasures if appropriate 29 compare TSC against replay counter, if replay check fails increment 30 dot11RSNAStatsTKIPReplays otherwise accept the MSDU 31 32 Make MSDU available to higher layers 33 else if dot11WEPKeyMappings has a WEP key then 34 Accept the MSDU since the decryption took place at the MPDU 35 Make MSDU available to higher layers 36 endif 37 38 endif 39 endif 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 9. MAC sublayer functional description 2 3 4 Change the first paragraph of Clause 9 as follows: 5 6 7 The MAC functional description is presented in this clause. The architecture of the MAC sublayer, including 8 the distributed coordination function (DCF), the point coordination function (PCF), the hybrid coordination 9 10 function (HCF), and their coexistence in an IEEE 802.11 LAN are introduced in 9.1. These functions are 11 expanded on in 9.2 (DCF), 9.3 (PCF), and 9.9 (HCF). Fragmentation and defragmentation are defined in 9.4 12 and 9.5. Multirate support is addressed in 9.6. A number of additional restrictions to limit the cases in which 13 MSDUs are reordered or discarded are described in 9.7. Operation across regulatory domains is defined in 14 9.8. The Block Ack mechanism is described in 9.10. The No Ack mechanism is described in 9.11. The 15 16 allowable frame exchange sequences are defined in 9.12. The protection mechanism is described in 9.13. 17 18 19 9.1 MAC architecture 20 21 22 9.1.3.1 HCF contention-based channel access (EDCA) 23 24 25 Change list item e) of 9.1.3.1 as follows: 26 27 28 e) During an EDCA TXOP won by an EDCAF, a STA may initiate multiple frame exchange sequences 29 to transmit MMPDUs and/or MSDUs within the same AC. The duration of this EDCA TXOP is 30 bounded, for an AC, by the value in dot11QAPEDCATXOPLimit MIB variable for an AP and in 31 dot11EDCATableTXOPLimit MIB table for a non-AP STA. A value of 0 for this duration means 32 that the EDCA TXOP is limited as defined by the rule for TXOP Limit value 0 found in 9.9.1.2 to a 33 34 single MSDU or MMPDU at any rate in the operational set of the BSS. 35 36 37 9.1.5 Fragmentation/defragmentation overview 38 39 40 Change the second and third paragraphs of 9.1.5 as follows: 41 42 43 Only MPDUs with a unicast receiver address shall be fragmented. An MSDU transmitted under HT-imme- 44 diate or HT-delayed Block Ack agreement shall not be fragmented, even if its length exceeds the 45 dot11FragmentationThreshold. An MSDU transmitted within an A-MPDU shall not be fragmented, even if 46 its length exceeds the dot11FragmentationThreshold. Broadcast/multicast Group addressed framesMSDUs or 47 MMPDUs shall not be fragmented even if their length exceeds dot11FragmentationThreshold. 48 49 NOTE 1—A fragmented MSDU or MMPDU transmitted by an HT STA to another HT STA can only be acknowledged 50 using immediate acknowledgement (i.e., transmission of an ACK frame after a SIFS). 51 52 NOTE 2—As specified in 9.7c, A-MSDUs are never fragmented. 53 54 55 Except as described below,Wwhen an individually addressed MSDU is received from the LLC or an individ- 56 ually addressed MMPDU is received from the MLME that would result in an MPDU of length greater than 57 58 dot11FragmentationThreshold when after any encryption and the MAC header and FCS are added, the 59 MSDU or MMPDU shall be fragmented. The exception applies when an MSDU is transmitted using an HT- 60 immediate or HT-delayed Block Ack agreement, or when the MSDU or MMPDU is carried in an A-MPDU; 61 in which case the MSDU or MMPDU is transmitted without fragmentation. The MSDU or MMPDU is divid- 62 ed into MPDUs. Each fragment is a frame no larger than dot11FragmentationThreshold. It is possible that any 63 64 fragment may be a frame smaller than dot11FragmentationThreshold. An illustration of fragmentation is 65 shown in Figure 9-2.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 9.1.6 MAC data service 2 3 Change 9.1.6 as follows: 4 5 6 The MAC data service provides the transport of MSDUs between MAC peer entities as characterized in 6.1.1. 7 8 The transmission process is started by receipt of an MA-UNITDATA.request primitive containing an MSDU 9 and the associated parameters. This may might cause one or more data MPDUs containing the MSDU to be 10 11 transmitted following A-MSDU aggregation, fragmentation and security encapsulation, as appropriate. 12 13 The MA-UNITDATA.indication primitive is generated in response to one or more received data MPDUs 14 containing an MSDU following validation, address filtering, decryption, decapsulation, and defragmentation, 15 16 and A-MSDU de-aggregation, as appropriate. 17 18 19 9.2 DCF 20 21 Change paragraph 11 of 9.2 as follows: 22 23 The medium access protocol allows for STAs to support different sets of data rates. All STAs that are mem- 24 25 bers of a BSS shall beare able to receive and transmit at all the data rates in the BSSBasicRateSet parameter 26 of the MLME-START.request or BSSBasicRateSet parameter of the BSSDescription representing the 27 SelectedBSS parameter of the MLME-JOIN.request, see 10.3.3.1.4 and 10.3.10.1.4. All HT STAs that are 28 members of a BSS are able to receive and transmit using all the MCSs in the BSSBasicMCSSet parameter of 29 the MLME-START.request or BSSBasicMCSSet parameter of the BSSDescription representing the Select- 30 31 edBSS parameter of the MLME-JOIN.request, see 10.3.3.1.4 and 10.3.10.1.4. To support the proper opera- 32 tion of the RTS/CTS and the virtual CS mechanism, all STAs shall be able to detect the interpret control 33 frames with the subtype field set to RTS andor CTS frames. 34 35 9.2.2 MAC-Level acknowledgments 36 37 38 Change the first paragraph of 9.2.2 as follows: 39 40 The reception of some frames, as described in 9.2.8, and 9.3.3.4, and 9.12, requires the receiving STA to 41 42 respond with an acknowledgment, generally an ACK frame, if the FCS of the received frame is correct. This 43 technique is known as positive acknowledgment. 44 45 9.2.3 IFS 46 47 48 Insert the following heading immediately after the heading for 9.2.3: 49 50 9.2.3.0a Overview 51 52 Change the first paragraph of 9.2.3 as follows: 53 54 55 The time interval between frames is called the IFS. A STA shall determine that the medium is idle through 56 the use of the CS function for the interval specified. FiveSix different IFSs are defined to provide priority lev- 57 els for access to the wireless media; Figure 9-3 shows some of these relationships. All timings are referenced 58 from PHY interface signals PHY-TXEND.confirm, PHY-TXSTART.confirm, PHY-RXSTART.indication, 59 60 and PHY-RXEND.indication. 61 62 Change the list of items after the first paragraph of 9.2.3 as follows (changes to the existing letters are not 63 shown for clarity): 64 65 a) RIFS reduced interframe space

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 b) SIFS short interframe space 2 3 c) PIFS PCF interframe space 4 d) DIFS DCF interframe space 5 6 e) AIFS arbitration interframe space (used by the QoS facility) 7 f) EIFS extended interframe space 8 9 Insert the following subclause (9.2.3.0b) after the new 9.2.3.0a: 10 11 12 9.2.3.0b RIFS 13 14 RIFS (Reduced Interframe Spacing) is a means of reducing overhead and thereby increasing network effi- 15 ciency. 16 17 18 RIFS may be used in place of SIFS to separate multiple transmissions from a single transmitter, when no 19 SIFS-separated response transmission is expected. RIFS shall not be used between frames with different RA 20 values. The duration of RIFS is defined by the aRIFS PHY characteristic (see Table 20-24). The RIFS is the 21 22 time from the end of the last symbol of the previous frame to the beginning of the first symbol of the preamble 23 of the subsequent frame as seen at the air interface. A STA shall not allow the space between frames that are 24 defined to be separated by a RIFS time, as measured on the medium, to vary from the nominal RIFS value 25 (aRIFSTime) by more than ±10% of aRIFSTime. Two frames separated by a RIFS shall both be HT PPDUs. 26 27 28 There are additional restrictions regarding when RIFS may be employed as defined in 9.15 and 9.16. See also 29 9.13.3.3. 30 31 9.2.3.1 SIFS 32 33 34 Change the first paragraph of 9.2.3.1 as follows: 35 36 The SIFS shall be used prior to transmission of an ACK frame, a CTS frame, a PPDU containing a BlockAck 37 frame that is an immediate response to either a BlockAckReq frame or an A-MPDU, the second or subsequent 38 MPDU of a fragment burst, and by a STA responding to any polling by the PCF. The SIFS may also be used 39 40 by a PC for any types of frames during the CFP (see 9.3). The SIFS is the time from the end of the last symbol, 41 or signal extension if present, of the previous frame to the beginning of the first symbol of the preamble of 42 the subsequent frame as seen at the air interface. The valid cases where the SIFS may or shall be used are 43 listed in the frame exchange sequences in 9.12. 44 45 Change the third paragraph of 9.2.3.1 as follows: 46 47 48 SIFS is the shortest of the IFSs between transmissions from different STAs. SIFS shall be used when STAs 49 have seized the medium and need to keep it for the duration of the frame exchange sequence to be performed. 50 Using the smallest gap between transmissions within the frame exchange sequence prevents other STAs, 51 52 which are required to wait for the medium to be idle for a longer gap, from attempting to use the medium, 53 thus giving priority to completion of the frame exchange sequence in progress. 54 55 9.2.3.2 PIFS 56 57 58 Change 9.2.3.2 as follows: 59 60 The PIFS shall be used only by STAs operating under the PCF to gain priority access to the medium at the 61 start of the CFP or by a STA to transmit a Channel Switch Announcement frame. A STA using the PCF shall 62 be allowed to transmit CF traffic after its CS mechanism (see 9.2.1) determines that the medium is idle at the 63 64 TxPIFS slot boundary as defined in 9.2.10. A STA may also transmit a Channel Switch Announcement frame 65 after its CS mechanism (see 9.2.1) determines that the medium is idle at the TxPIFS slot boundary. The use

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 of the PIFS by STAs operating under the PCF is described in 9.3. The use of PIFS by STAs transmitting a 2 Channel Switch Announcement frame is described in 11.9. 3 4 5 The PIFS is used to gain priority access to the medium. 6 7 8 The PIFS may be used as described in the following list, and shall not be used otherwise. 9 10 — A STA operating under the PCF as described in 9.3 11 12 — A STA transmitting a Channel Switch Announcement frame as described in 11.9 13 14 — An HC starting a CFP or a TXOP as described in 9.9.2.1.2 15 16 — An HC or a non-AP QoS STA that is a polled TXOP holder recovering from the absence of an 17 expected reception in a CAP as described in 9.9.2.1.3 18 19 — An HT STA using dual CTS protection before transmission of the second CTS (CTS2) as described 20 in 9.2.5.5a 21 22 — A TXOP holder continuing to transmit after a transmission failure as described in 9.9.1.4 23 24 — An RD initiator continuing to transmit using error recovery as described in 9.15.3 25 26 — An HT AP during a PSMP sequence transmitting a PSMP recovery frame as described in 9.16.1.3 27 28 — An HT STA performing CCA in the secondary channel before transmitting a 40 MHz mask PPDU 29 using EDCA channel access as described in 11.14.9 30 31 32 With the exception of performing CCA in the secondary channel (where the timing is defined in 11.14.9 ), a 33 STA using PIFS starts its transmission after its CS mechanism (see 9.2.1) determines that the medium is idle 34 at the TxPIFS slot boundary as defined in 9.2.10. 35 36 37 9.2.3.5 EIFS 38 39 40 Insert the following paragraph at the end of 9.2.3.5. 41 42 43 EIFS shall not be invoked if the NAV is updated by the frame that would have caused an EIFS, such as in the 44 case when the MAC FCS fails and L-SIG TXOP function employs signal field information to update the 45 NAV. EIFS shall not be invoked for an A-MPDU if one or more of its frames are received correctly. 46 47 48 9.2.4 Random backoff time 49 50 51 Change the second paragraph of 9.2.4 as follows: 52 53 54 The contention window (CW) parameter shall take an initial value of aCWmin. Every STA shall maintain a 55 STA short retry count (SSRC) as well as a STA long retry count (SLRC), both of which shall take an initial 56 value of zero. The SSRC shall be incremented when any short retry count (SRC) associated with any MPDU 57 58 of type Data is incremented. The SLRC shall be incremented when any long retry count (LRC) associated 59 with any MPDU of type Data is incremented. The CW shall take the next value in the series every time an 60 unsuccessful attempt to transmit an MPDU causes either STA retry counter to increment, until the CW reach- 61 es the value of aCWmax. A retry is defined as the entire sequence of frames sent, separated by SIFS intervals, 62 in an attempt to deliver an MPDU, as (described in Annex S)9.12. Once it reaches aCWmax, the CW shall 63 64 remain at the value of aCWmax until the CW is reset. This improves the stability of the access protocol under 65 high-load conditions. See Figure 9-4.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 9.2.5 DCF access procedure 2 3 4 9.2.5.1 Basic access 5 6 7 Change the second paragraph of 9.2.5.1 as follows: 8 9 10 In general, a STA may transmit a pending MPDU when it is operating under the DCF access method, either 11 in the absence of a PC, or in the CP of the PCF access method, when the STA determines that the medium is 12 idle for greater than or equal to a DIFS period, or an EIFS period if the immediately preceding medium-busy 13 event was caused by detection of a frame that was not received at this STA with a correct MAC FCS value. 14 15 If, under these conditions, the medium is determined by the CS mechanism to be busy when a STA desires 16 to initiate the initial frame of a one of the frame exchange sequences (described in 9.12Annex S), exclusive 17 of the CF period, the random backoff procedure described in 9.2.5.2 shall be followed. There are conditions, 18 specified in 9.2.5.2 and 9.2.5.5, where the random backoff procedure shall be followed even for the first at- 19 tempt to initiate a frame exchange sequence. 20 21 22 9.2.5.3 Recovery procedures and retransmit limits 23 24 25 Change the first paragraph of 9.2.5.3 as follows: 26 27 28 Under DCF, eError recovery is always the responsibility of the STA that initiates a frame exchange sequence, 29 30 as defined in 9.12 (described in Annex S). Many circumstances may cause an error to occur that requires re- 31 covery. For example, the CTS frame may not be returned after an RTS frame is transmitted. This may happen 32 due to a collision with another transmission, due to interference in the channel during the RTS or CTS frame, 33 or because the STA receiving the RTS frame has an active virtual CS condition (indicating a busy medium 34 time period). 35 36 37 9.2.5.4 Setting and resetting the NAV 38 39 40 Change the first paragraph of 9.2.5.4 as follows: 41 42 43 STAs receiving a A STA that receives at least one valid frame within a received PSDU shall update theirits 44 NAV with the information received in theany valid Duration field from within that PSDU, for all frames 45 46 where the new NAV value is greater than the current NAV value, except the NAV shall not be updatedfor 47 those where the RA is equal to the receiving STA's MAC address of the STA. Upon receipt of a PS-Poll 48 frame, a the STA shall update its NAV settings as appropriate under the data rate selection rules using a du- 49 ration value equal to the time, in microseconds, required to transmit one ACK frame plus one SIFS interval, 50 but only when the new NAV value is greater than the current NAV value. If the calculated duration includes 51 52 a fractional microsecond, that value is rounded up the next higher integer. Various additional conditions may 53 set or reset the NAV, as described in 9.3.2.2. When the NAV is reset, a PHY-CCARESET.request shall be 54 issued. This NAV update operation is performed when the PHY-RXEND.indication primitive is received. 55 56 57 Insert the following paragraph at the end of 9.2.5.4: 58 59 60 A STA supporting L-SIG TXOP that used the information from a frame with different L-SIG Duration and 61 MAC duration endpoints (characteristics of an L-SIG TXOP initiating frame, see 9.13.5.4 for details) as the 62 most recent basis to update its NAV setting, may reset its NAV if no PHY-RXSTART.indication is detected 63 64 from the PHY during a period with a duration of aSIFSTime++ aPHY-RX-START-Delay 2 aSlotTime 65 starting at the expiration of the L-SIG Duration. For details of L-SIG Duration see 9.13.5.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Insert the following subclauses (9.2.5.5a to 9.2.5.5a.2) after 9.2.5.5: 2 3 9.2.5.5a Dual CTS protection 4 5 6 9.2.5.5a.1 Dual CTS protection procedure 7 8 If the Dual CTS Protection field of the HT Operation element has value 1 in the Beacon frames transmitted 9 10 by its AP, a non-AP HT STA shall start every TXOP with an RTS addressed to the AP. The RTS shall be an 11 STBC frame if the STBC transmit and receive capabilities of the non-AP HT STA allow it to receive and 12 transmit STBC frames using a single spatial stream, otherwise the RTS shall be a non-STBC frame. The AP 13 shall respond with a dual CTS (CTS1 followed by CTS2) separated by PIFS or SIFS. Table 9-1a describes 14 the sequence of CTS transmissions and the required timing. 15 16 17 18 Table 9-1a—Dual CTS rules 19 20 21 Type of RTS CTS description Timing 22 23 RTS (non- CTS1: Same rate or MCS as PIFS shall be used as the interval between CTS1 and CTS2. 24 STBC frame) the RTS (non-STBC frame) 25 CTS2: basic STBC MCS If the CS mechanism (see 9.2.1) indicates that the medium is busy 26 (STBC frame) at the TxPIFS slot boundary (defined in 9.2.10) following CTS1, 27 CTS2 shall not be transmitted as part of this frame exchange. 28 29 RTS (STBC CTS1: basic STBC MCS SIFS shall be used as the interval between CTS1 and CTS2. 30 frame) (STBC frame) The STA resumes transmission a SIFS+CTS2+SIFS after receiv- 31 CTS2: Lowest Basic Rate ing CTS1, instead of after SIFS. 32 (non-STBC frame) 33 34 35 The dual CTS response only applies to the AP; a non-AP STA shall respond to an RTS request with a single 36 37 CTS. 38 39 If dual CTS Protection is enabled, the AP shall begin each EDCA TXOP with a CTS frame. This CTS frame 40 uses STBC when the immediately following frame uses non-STBC and vice versa. The RA of this CTS shall 41 42 be identical to the RA of the immediately following frame. The AP may continue a PIFS after the CTS, only 43 if the CS mechanism (see 9.2.1) indicates that the medium is busy at the TxPIFS slot boundary (defined in 44 9.2.10) following the transmission of the CTS. 45 46 To avoid the resetting of NAV by STAs which have set their NAV due to the reception of a non-STBC RTS 47 48 that is part of a dual-CTS exchange, but then do not hear the CTS2, a non-AP HT STA may create a NAV 49 that is not resettable according to the RTS NAV reset rule defined in 9.2.5.4 at the receiving STAs by initiat- 50 ing the TXOP with a non-STBC CTS addressed to the AP (known as “CTS-to-AP”). 51 NOTE—Sending a CTS-to-AP allows NAV protection to be established without causing the AP to update its NAV, as 52 opposed to, for example, the sending of a CTS-to-self, which would potentially have caused the AP NAV to become set 53 and then prevented it from responding to the subsequent RTS. The AP does not set a NAV in the CTS-to-AP case, and 54 will be able to respond to the following RTS. The NAV at receiving STAs is not updated by the RTS because its dura- 55 tion does not exceed the duration of the preceding CTS, and subsequently, the NAV cannot be reset during CTS2. 56 57 An STBC CTS addressed to the AP may be transmitted prior to an STBC RTS, to set a NAV that is not re- 58 59 settable according to the RTS NAV reset rule defined in 9.2.5.4 at receiving STAs. 60 NOTE—When an HT STA sends an RTS to the AP that is a non-STBC frame, the AP returns a CTS that is a non-STBC 61 frame to the STA and then immediately transmits a CTS that is an STBC frame. The original non-AP STA is now free to 62 transmit. But a non-HT station that has set its NAV based on the original RTS may reset its NAV and then decrement its 63 backoff counter - given that a SIFS + the duration of CTS2 is longer than a DIFS (i.e., the STA does not detect PHY- 64 RXSTART.indication within the period specified in 9.2.5.4). Thus, without sending a CTS-to-AP, the NAV reservation 65 will not always work.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 If dual CTS protection is enabled and a STA obtains a TXOP and does not have any frames to transmit before 2 the expiry of the TXOP duration, the STA may indicate truncation of the TXOP provided that the remaining 3 duration of the TXOP after the transmission of the last frame, can accommodate the CF-End frame, a CF-End 4 5 frame that is an STBC frame duration at the basic STBC MCS, a CF-End frame that is a non-STBC frame at 6 the lowest basic rate, and three SIFS durations. The STA indicates truncation of the TXOP by transmitting a 7 CF-End frame with TXVECTOR parameter restrictions as specified in 9.6.0e.3. 8 9 10 On receiving a CF-End frame from a STA with a matching BSSID, an AP whose last transmitted HT Oper- 11 ation element contained the Dual CTS Protection field set to 1 shall respond with dual CF-End frames, one 12 CF-End frame that is an STBC frame at the basic STBC MCS and one CF-End frame that is a non-STBC 13 14 frame at the lowest basic rate, after a SIFS duration. Dual CF-End frames eliminate unfairness towards STAs 15 that are not of the same mode as the one that owns the TXOP being truncated. 16 17 18 If the TXOP is owned by the AP and dual CTS Protection is enabled in the system, the AP may send dual CF- 19 End frames if it runs out of frames to transmit, provided that the remaining TXOP duration after the transmis- 20 sion of the last frame can accommodate a STBC CF-End frame duration at the lowest STBC basic rate, a CF- 21 End frame that is a non-STBC frame at the lowest basic rate, and two SIFS durations. 22 23 24 The spacing between the dual CF-End frames sent by the AP shall be SIFS. The first CF-End frame shall use 25 the same encoding (STBC frame versus non-STBC frame) used for transmissions in the TXOP being truncat- 26 27 ed and the second CF-End frame shall use the other encoding. 28 29 30 An STBC capable STA shall choose between control frame operation using either STBC frames or non- 31 STBC frames. In the non-STBC frame case, it discards control frames that are STBC frames it receives. In 32 the STBC frame case, it discards control frames that are non-STBC frames received from its own BSS. This 33 choice is a matter of policy local at the STA. 34 35 36 9.2.5.5a.2 Dual CTS protection examples 37 38 39 Figure 9-8a shows an example of the operation of the Dual CTS protection mechanism. In this example, the 40 initiating STA is an STBC non-AP STA. 41 42 43 Key: 44 STBC frame 45 STBC RTS 46 Data Non-STBC frame CF-End CTS to AP 47 non-AP STA 48 49 SIFS SIFS SIFS SIFS >= SIFS SIFS SIFS 50 51 Optional 52 AP

53 CTS CTS ACK

54 CF-End CF-End 55 56 rd 57 NAV of 3 -party STBC STA near non-AP STA 58 NAV of 3rd-party STBC STA near AP 59 rd 60 NAV of 3 -party non-STBC STA 61 62 Figure 9-8a—Example of the Dual CTS mechanism (STBC initiator) 63 64 65 Figure 9-8b shows an example of the operation of the Dual CTS protection mechanism. In this example, the

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 initiating STA is a non-STBC non-AP HT STA. 2 3 4 Key: 5 STBC frame 6 STA RTS 7 Data Non-STBC frame CF-End Non-STBC Non-STBC non-AP HT HT non-AP 8 AP CTS to 9 10 SIFS SIFS PIFS SIFS >= SIFS SIFS SIFS 11 12 Optional 13 AP CTS CTS 14 ACK 15 CF-End CF-End 16 17 NAV of 3rd-party STBC STA 18 rd 19 NAV of 3 -party non-STBC STA near non-AP STA 20 NAV of 3rd-party non-STBC not near non-AP STA 21 22 Figure 9-8b—Example of the Dual CTS mechanism (non-STBC initiator) 23 24 25 9.2.5.7 CTS procedure 26 27 Change the second paragraph of 9.2.5.7 as follows: 28 29 30 After transmitting an RTS frame, the STA shall wait for a CTSTimeout interval, with a value of aSIFSTime 31 + aSlotTime + aPHY-RX-START-Delay, starting at the PHY-TXEND.confirm. If a PHY-RXSTART.indi- 32 cation does not occur during the CTSTimeout interval, the STA shall conclude that the transmission of the 33 RTS has failed, and this STA shall invoke its backoff procedure upon expiration of the CTSTimeout interval. 34 If a PHYRXSTART.indication does occur during the CTSTimeout interval, the STA shall wait for the corre- 35 36 sponding PHY-RXEND.indication to determine whether the RTS transmission was successful. The recogni- 37 tion of a valid CTS frame sent by the recipient of the RTS frame, corresponding to this PHY- 38 RXEND.indication, shall be interpreted as successful response, permitting the frame sequence to continue 39 (see 9.12Annex S). The recognition of anything else, including any other valid frame, shall be interpreted as 40 failure of the RTS transmission. In this instance, the STA shall invoke its backoff procedure at the PHY-RX- 41 42 END.indication and may process the received frame. 43 44 9.2.6 Individually addressed MPDU transfer procedure 45 46 47 Change 9.2.6 as follows: 48 49 A STA shall use an RTS/CTS exchange for individually addressed frames only when the length of the MPDU 50 PSDU is greater than the length threshold indicated by the dot11RTSThreshold attribute. 51 52 53 The dot11RTSThreshold attribute shall be is a managed object within the MAC MIB, and its value may be 54 set and retrieved by the MLME. The value 0 shall be used to indicate that all MPDUs shall be delivered with 55 the use of RTS/CTS. Values of dot11RTSThreshold larger than the maximum MSDU PSDU length shall in- 56 dicate that all MPDUsPSDUs shall be delivered without RTS/CTS exchanges. 57 58 59 When an RTS/CTS exchange is used, the asynchronous data framePSDU shall be transmitted starting one 60 SIFS period after the end of the CTS frame and a SIFS period. No regard shall be given to the busy or idle 61 status of the medium when transmitting this data framePSDU. 62 63 64 When an RTS/CTS exchange is not used, the asynchronous data framePSDU shall be transmitted following 65 the success of the basic access procedure. With or without the use of the RTS/CTS exchange procedure, the

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 STA that is the destination of an asynchronous data frame shall follow the ACK procedure. 2 3 4 9.2.7 Broadcast and multicast MPDU transfer procedure 5 6 Insert the following paragraph at the end of 9.2.7: 7 8 9 An STBC-capable STA shall discard either all received group addressed data frames that are STBC frames, 10 or all received group addressed data frames that are non-STBC frames. How it makes this decision is outside 11 12 the scope of this standard. 13 14 9.2.8 ACK procedure 15 16 17 Change the first paragraph of 9.2.8 as follows: 18 19 20 The cases when anAn ACK frame canshall be generated areas shown in the frame exchange sequences listed 21 in 9.12Annex S. 22 23 24 Insert the following paragraph to become the new second paragraph of 9.2.8: 25 26 On receipt of a frame of type Management, subtype Action NoAck, a STA shall not send an ACK frame in 27 response. 28 29 30 Change the first sentence of the existing third paragraph of 9.2.8 as follows: 31 32 33 After transmitting an MPDU that requires an ACK frame as a response (see 9.12Annex S), the STA shall wait 34 for an ACKTimeout interval, with a value of aSIFSTime + aSlotTime + aPHY-RX-START-Delay, starting 35 at the PHY-TXEND.confirm. 36 37 38 Insert the following subclause (9.2.8a) after 9.2.8: 39 40 9.2.8a BlockAck procedure 41 42 43 Upon successful reception of a frame of a type that requires an immediate BlockAck response, the receiving 44 STA shall transmit a BlockAck frame after a SIFS period, without regard to the busy/idle state of the medium. 45 46 The rules that specify the contents of this BlockAck frame are defined in 9.10. 47 48 9.2.9 Duplicate detection and recovery 49 50 51 Change the second and third paragraphs of 9.2.9 as follows: 52 53 54 Duplicate frame filtering is facilitated through the inclusion of a Sequence Control field (consisting of a se- 55 quence number and fragment number) within data and management frames as well as TID subfield in the QoS 56 Control field within QoS data frames. MPDUs that are part of the same MSDU or A-MSDU shall have the 57 same sequence number, and different MSDUs or A-MSDUs shall (with a high probability) have a different 58 59 sequence number. 60 61 The sequence number, for management frames and for data frames with QoS subfield of the Subtype field set 62 to 0, is generated by the transmitting STA as an incrementing sequence of integers. In a QoS STA, the se- 63 64 quence numbers for QoS (+)Ddata frames are generated by different counters for each TID and receiver pair 65 and shall be incremented by one for each new MSDU or A-MSDU corresponding to the TID/receiver pair.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 9.2.10 DCF timing relations 2 3 Change the second paragraph of 9.2.10 as follows: 4 5 6 All medium timings that are referenced from the end of the transmission are referenced from the end of the 7 last symbol, or signal extension if present, of the PPDU a frame on the medium. The beginning of transmis- 8 sion refers to the first symbol of the preamble of the next PPDU the next frame on the medium. All MAC 9 timings are referenced from PHY interface signals PHY-TXEND.confirm, PHY-TXSTART.confirm, PHY- 10 11 RXSTART.indication, and PHY-RXEND.indication. 12 13 Change paragraph 13 of 9.2.10 as follows: 14 15 The following equations define the MAC Slot Boundaries, using attributes provided by the PHY, which are 16 such that they compensate for implementation timing variations. The starting reference of these slot bound- 17 18 aries is again the end of the last symbol of the previous PPDU the previous frame on the medium. 19 20 Insert the following new subclause (9.2.10a) after 9.2.10: 21 22 9.2.10a Signal Extension 23 24 25 Transmissions of frames with TXVECTOR parameter FORMAT of type NON_HT with 26 NON_HT_MODULATION values of ERP-OFDM, DSSS-OFDM and NON_HT_DUPOFDM and transmis- 27 sions of frames with TXVECTOR parameter FORMAT with values of HT_MF and HT_GF include a period 28 of no transmission of duration aSignalExtension, except for RIFS transmissions. The purpose of this signal 29 30 extension is to ensure that the NAV value of Clause 18 STAs is set correctly. 31 32 When an HT STA transmits a PPDU using a RIFS and with the TXVECTOR parameter FORMAT set to 33 NON_HT with the NON_HT_MODULATION parameter set to one of ERP-OFDM, DSSS-OFDM and 34 NON_HT_DUPOFDM or a PPDU using a RIFS and with the TXVECTOR parameter FORMAT set to 35 36 HT_MF or HT_GF, it shall set the TXVECTOR parameter NO_SIG_EXTN to TRUE. Otherwise it shall set 37 the TXVECTOR parameter NO_SIG_EXTN to FALSE. 38 39 40 9.6 Multirate support 41 42 Insert the following subclause heading (9.6.0a) immediately after subclause heading 9.6: 43 44 45 9.6.0a Overview 46 47 Change 9.6 as follows: 48 49 Some PHYs have multiple data transfer rate capabilities that allow implementations to perform dynamic rate 50 51 switching with the objective of improving performance. The algorithm for performing rate switching is be- 52 yond the scope of this standard, but in order to ensure coexistence and interoperability on multirate-capable 53 PHYs, this standard defines a set of rules to be followed by all STAs. 54 55 A STA that transmits a frame shall select a rate defined by the rules for determining the rates of transmission 56 57 of protection frames in 9.13 when the following conditions apply: 58 — the STA’s protection mechanism for non-ERP receivers is enabled, 59 60 — the frame is a protection mechanism frame, and 61 — the frame initiates an exchange. 62 63 64 Otherwise the frame shall be transmitted using a rate that is in accordance with rules defined in 9.6.0d and 65 9.6.0e.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Control frames that initiate a frame exchange shall be transmitted at one of the rates in the BSS-BasicRateSet 2 parameter except in the following cases: 3 4 — When the transmitting STA’s protection mechanism is enabled and the control frame is a protection- 5 mechanism frame 6 7 — When the control frame is a BlockAckReq or BlockAck frame 8 9 In the former case, the control frame shall be transmitted at a rate according to the separate rules for deter- 10 mining the rates of transmission of protection frames in 9.13. In the latter case, the control frame shall be 11 transmitted in accordance with this subclause. 12 13 14 All frames with multicast and broadcast in the Address 1 field that have a UP of zero shall be transmitted at 15 one of the rates included in the BSSBasicRateSet parameter, regardless of their type or subtype. 16 17 18 All data frames of subtype (QoS) (+)CF-Poll sent in the CP shall be transmitted at one of the rates in the BSS- 19 BasicRateSet parameter so that they will be understood by all STAs in the BSS, unless an RTS/CTS exchange 20 has already been performed before the transmission of the data frame of subtype CF-Poll and the Duration 21 field in the RTS frame covers the entire TXOP. All other data, BlockAckReq, and BlockAck frames and/or 22 management MPDUs with unicast in the Address 1 field shall be sent using any data rate subject to the fol- 23 24 lowing constraints. No STA shall transmit a unicast frame at a rate that is not supported by the receiver STA, 25 as reported in any Supported Rates and Extended Supported Rates element in the management frames trans- 26 mitted by that STA. For frames of type (QoS) Data+CF-Ack, (QoS) Data+CF-Poll+CF-Ack, and (QoS) CF- 27 Poll+CF-Ack, the rate chosen to transmit the frame should be supported by both the addressed recipient STA 28 and the STA to which the ACK frame is intended. The BlockAck control frame shall be sent at the same rate 29 30 and modulation class as the BlockAckReq frame if it is sent in response to a BlockAckReq frame. 31 32 Under no circumstances shall a STA initiate transmission of a data or management frame at a data rate higher 33 than the greatest rate in the OperationalRateSet, a parameter of the MLME-JOIN.request primitive. 34 35 36 In the case where the supported rate set of the receiving STA is not known, the transmitting STA shall trans- 37 mit at a rate contained in the BSSBasicRateSet parameter or a rate at which the transmitting STA has received 38 a frame from the receiving STA. 39 40 41 To allow the transmitting STA to calculate the contents of the Duration/ID field, a STA responding to a re- 42 ceived frame shall transmit its Control Response frame (either CTS or ACK), other than the BlockAck control 43 frame, at the highest rate in the BSSBasicRateSet parameter that is less than or equal to the rate of the imme- 44 diately previous frame in the frame exchange sequence (as defined in 9.12) and that is of the same modulation 45 class (see 9.6.1) as the received frame. If no rate contained in the BSSBasicRateSet parameter meets these 46 47 conditions, then the control frame sent in response to a received frame shall be transmitted at the highest man- 48 datory rate of the PHY that is less than or equal to the rate of the received frame, and that is of the same mod- 49 ulation class as the received frame. In addition, the Control Response frame shall be sent using the same PHY 50 options as the received frame, unless they conflict with the requirement to use the BSSBasicRateSet param- 51 eter. 52 53 54 An alternative rate for the control response frame may be used, provided that the duration of the control re- 55 sponse frame at the alternative rate is the same as the duration of the control response frame at the originally 56 chosen rate and the alternative rate is in either the BSSBasicRateSet parameter or the mandatory rate set of 57 58 the PHY and the modulation of the control response frame at the alternative rate is the same type as that of 59 the received frame. 60 61 For the Clause 17, Clause 18, and Clause 19, and Clause 20 PHYs, the time required to transmit a frame for 62 use in calculating the value for the Duration/ID field is determined using the PLME-TXTIME.request 63 64 primitive (see 10.4.6) and the PLME-TXTIME.confirm primitive (see 10.4.7), both defined in 17.4.3, 18.3.4, 65 19.8.3.1, 19.8.3.2, or 19.8.3.3, or 20.4.3 depending on the PHY options. In QoS STAs, the Duration/ID field

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 may cover multiple frames and may involve using the PLME-TXTIME.request primitive several times. 2 3 Insert the following subclauses (9.6.0b to 9.6.0e.7) after the new 9.6.0a: 4 5 6 9.6.0b Basic MCS Set 7 8 An AP that transmits a frame containing an HT Operation element with either the Dual Beacon field or the 9 Dual CTS Protection field set to the value 1 shall include at least one MCS that has only one spatial stream 10 11 in the Basic MCS Set field of the HT Operation element of that frame. 12 13 9.6.0c Basic STBC MCS 14 15 16 The Basic STBC MCS has the value NULL when any of the following conditions is true: 17 — The Dual Beacon field in the HT Operation element is set to 0, and the Dual CTS Protection field in 18 the HT Operation element is set to 0 19 20 — No HT Operation element is present in the most recently received Association Response frame that 21 was addressed to this STA 22 23 — The BSSBasicMCSSet is empty or does not exist 24 — The lowest MCS of the BSSBasicMCSSet has NSS value greater than 1 (the mapping of MCS to 25 NSS is PHY dependent, for the HT PHY see 20.6) 26 27 28 If none of the above conditions is true, then the Basic STBC MCS is the lowest MCS index of the BSSBasic- 29 MCSSet parameter. 30 31 When an MCS from the Basic STBC MCS is required in 9.6.0d and 9.6.0e but the Basic STBC MCS has the 32 33 value NULL, the STA shall select a mandatory MCS of the attached PHY. 34 35 9.6.0d Rate selection for data and management frames 36 37 38 9.6.0d.1 Rate selection for non-STBC Beacon and non-STBC PSMP frames 39 40 This subclause describes the rate selection rules for non-STBC Beacon and non-STBC PSMP frames. 41 42 43 If the BSSBasicRateSet parameter is not empty, a non-STBC Beacon or a non-STBC PSMP frame shall be 44 transmitted in a non-HT PPDU using one of the rates included in the BSSBasicRateSet parameter. 45 46 If the BSSBasicRateSet parameter is empty, the frame shall be transmitted in a non-HT PPDU using one of 47 the mandatory PHY rates. 48 49 50 9.6.0d.2 Rate selection for STBC group addressed data and management frames 51 52 This subclause describes the rate selection rules for STBC group addressed data and management frames. 53 54 55 When a STA has the MIB attribute dot11TxSTBCOptionEnabled set to TRUE, it shall use the basic STBC 56 MCS when it transmits an STBC Beacon frame or when it transmits a group addressed data or management 57 frame that is an STBC frame. 58 59 60 9.6.0d.3 Rate selection for other group addressed data and management frames 61 62 This subclause describes the rate selection rules for group addressed data and management frames, exclud- 63 ing: 64 65 — non-STBC Beacon and non-STBC PSMP frames

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 — STBC group addressed data and management frames 2 3 4 If the BSSBasicRateSet parameter is not empty, a data or management frame (excluding those frames listed 5 above) with a group address in the Address 1 field shall be transmitted in a non-HT PPDU using one of the 6 rates included in the BSSBasicRateSet parameter. 7 8 9 If the BSSBasicRateSet parameter is empty and the BSSBasicMCSSet parameter is not empty, the frame shall 10 be transmitted in an HT PPDU using one of the MCSs included in the BSSBasicMCSSet parameter. 11 12 If both the BSSBasicRateSet parameter and the BSSBasicMCSSet parameter are empty (e.g., a scanning STA 13 that is not yet associated with a BSS), the frame shall be transmitted in a non-HT PPDU using one of the man- 14 15 datory PHY rates. 16 17 9.6.0d.4 Rate selection for polling frames 18 19 20 A data frame of a subtype that includes CF-Poll that does not also include CF-Ack and that is sent in the CP 21 shall be transmitted at a rate selected as follows: 22 23 a) If an initial exchange has already established protection and the Duration/ID field in the frame 24 establishing protection covers the entire TXOP, the rate or MCS is selected according to the rules in 25 9.6.0d.6. 26 27 b) Otherwise, the data frame shall be transmitted at a rate or MCS as defined in 9.6.0d.3, treating the 28 frame as though it has a group address in the Address 1 field, solely for the purpose of determining 29 the appropriate rate or MCS. 30 31 32 9.6.0d.5 Rate selection for +CF-Ack frames 33 34 For a frame of type (QoS) Data+CF-Ack, (QoS) Data+CF-Poll+CFAck, or (QoS) CF-Poll+CF-Ack, the rate 35 or MCS and TXVECTOR parameter CH_BANDWIDTH used to transmit the frame shall be chosen from 36 37 among those supported by both the addressed recipient STA and the STA to which the ACK frame is intend- 38 ed. 39 40 9.6.0d.6 Rate selection for other data and management frames 41 42 43 A data or management frame not identified in 9.6.0d.1, 9.6.0d.2, 9.6.0d.3, 9.6.0d.4 or 9.6.0d.5 shall be sent 44 using any data rate or MCS subject to the following constraints: 45 46 — A STA shall not transmit a frame using a rate or MCS that is not supported by the receiver STA or 47 STAs, as reported in any Supported Rates element, Extended Supported Rates element or Supported 48 MCS field in management frames transmitted by the receiver STA. 49 50 — A STA shall not transmit a frame using a value for the CH_BANDWIDTH parameter of the 51 TXVECTOR that is not supported by the receiver STA. 52 53 — A STA shall not initiate transmission of a frame at a data rate higher than the greatest rate in the 54 OperationalRateSet or the HTOperationalMCSset, which are parameters of the MLME-JOIN.request 55 primitive. 56 57 In the case where the supported rate set of the receiving STA or STAs is not known, the transmitting STA 58 59 shall transmit using a rate in the BSSBasicRateSet or an MCS in the BSSBasicMCSSet parameter, or a rate 60 from the mandatory rate set of the attached PHY if both the BSSBasicRateSet and the BSSBasicMCSSet are 61 empty. 62 63 64 The rules in this subclause also apply to A-MPDUs that aggregate MPDUs of type Data or Management with 65 any other types of MPDU.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 9.6.0e Rate selection for control frames 2 3 9.6.0e.1 General rules for rate selection for control frames 4 5 6 Control frames carried in an A-MPDU shall be sent at a rate selected from the rules defined in 9.6.0d.6. 7 NOTE—The rules defined in 9.6.0e.2 to 9.6.0e.5 apply only to control frames not carried in an A-MPDU. 8 9 The following rules determine whether a control frame is carried in an HT PPDU or non-HT PPDU: 10 11 a) A control frame shall be carried in an HT PPDU when the control frame meets any of the following 12 conditions: 13 14 i) the control frame contains an L-SIG Duration value (see 9.13.5), or 15 ii) the control frame is sent using an STBC frame. 16 17 b) A control response frame shall be carried in an HT PPDU when the control frame is a response to a 18 frame that meets the following conditions: 19 i) the frame eliciting the response included an HT Control field with the TRQ field set to 1 20 21 and the NDP announcement field set to 0 and this responder set the Implicit Transmit 22 Beamforming Receiving Capable field to 1 in its last transmitted HT Capabilities element, 23 or 24 ii) the frame eliciting the response was an RTS frame carried in an HT PPDU, or 25 26 iii) the frame eliciting the response was an STBC frame and the Dual CTS Protection field 27 was set to 1 in the last HT Operation element received from its AP or transmitted by the 28 STA (see 9.2.5.5a). 29 30 c) A control frame may be carried in an HT PPDU when the control frame meets any of the following 31 conditions: 32 33 i) the control frame contains an HT Control field with the MRQ field set to 1, or 34 ii) the control frame contains an HT Control field with the TRQ field set to 1. 35 36 NOTE—In these cases, requirements specified in 9.17, 9.18.2, and 9.19 further constrain the choice of non-HT 37 or HT PPDU. 38 d) Otherwise the control frame shall be carried in a non-HT PPDU. 39 40 41 Selection of channel width is defined in 9.6.0e.6. 42 43 A control response frame is a control frame that is transmitted as a response to the reception of a frame a 44 SIFS time after the PPDU containing the frame that elicited the response, e.g. a CTS in response to an RTS 45 46 reception, an ACK in response to a DATA reception, a BlockAck in response to a BlockAckReq reception. 47 In some situations, the transmission of a control frame is not a control response transmission, such as when a 48 CTS is used to initiate a TXOP. 49 50 9.6.0e.2 Rate selection for control frames that initiate a TXOP 51 52 53 This subclause describes the rate selection rules for control frames that initiate a TXOP and that are not car- 54 ried in an A-MPDU. 55 56 If a control frame other than a Basic BlockAckReq or Basic BlockAck is carried in a non-HT PPDU, the trans- 57 58 mitting STA shall transmit the frame using one of the rates in the BSSBasicRate set parameter or a rate from 59 the mandatory rate set of the attached PHY if the BSSBasicRateSet is empty. 60 61 If a Basic BlockAckReq or Basic BlockAck is carried in a non-HT PPDU, the transmitting STA shall transmit 62 the frame using a rate supported by the receiver STA, if known (as reported in the Supported Rates element 63 64 and/or Extended Supported Rates element in frames transmitted by that STA). If the supported rate set of the 65 receiving STA or STAs is not known, the transmitting STA shall transmit using a rate from the BSSBasicRa-

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 teSet parameter or using a rate from the mandatory rate set of the attached PHY if the BSSBasicRateSet is 2 empty. 3 4 NOTE—Because of their utility in resolving contention and in establishing a NAV, most control subtype frames that ini- 5 tiate a frame exchange are subject to explicit limitations regarding the choice of transmission rate with the intent of 6 ensuring maximum possible coverage and receptibility of the frame. But the Basic BlockAckReq and Basic BlockAck 7 frames are subject to fewer restrictions because their use at times will mimic a typical DATA-ACK exchange, where no 8 BSS BasicRateSet rate restriction exists on the DATA frame. In addition, the Basic BlockAck frame is significantly 9 larger than the other control frames. 10 11 When L-SIG TXOP protection is not used for an HT PPDU, an HT STA shall select an MCS from the Basic- 12 13 MCSSet parameter when protection is required (as defined in 9.13) and shall select an MCS from the Sup- 14 portedMCSSet of the intended receiver when protection is not required. 15 16 When L-SIG TXOP protection is used, an HT STA shall select an MCS from the SupportedMCSSet of the 17 18 intended receiver. 19 20 9.6.0e.3 Rate selection for CF_End control frames 21 22 23 This subclause describes the rate selection rules for CF-End control frames. 24 25 26 If not operating during the 40 MHz phase of PCO, a STA that transmits a CF-End control frame that is not at 27 the end of a TXOP that was obtained through the use of the dual CTS mechanism shall transmit the frame 28 using a rate in BSSBasicRateSet or from the mandatory rate set of the attached PHY if the BSSBasicRateSet 29 is empty. 30 31 32 If operating during the 40 MHz phase of PCO, a STA that transmits a CF-End control frame that is not at the 33 end of a TXOP that was obtained through the use of the dual CTS mechanism shall transmit the frame using 34 35 an MCS from the BSSBasicMCSSet parameter. 36 37 A STA that transmits a CF-End control frame at the end of a TXOP that was obtained by a non-AP STA 38 39 through the use of the dual CTS mechanism shall transmit the CF-End control frame with the same value for 40 the TXVECTOR parameter STBC, TXVECTOR parameter MCS (if present), and TXVECTOR parameter 41 RATE, as was used for the transmission of the matching control frame at the beginning of the TXOP. The 42 matching control frame is defined as follows: 43 44 — For the first CF-End transmitted in the TXOP, the matching control frame is the first RTS transmit- 45 ted in the TXOP. 46 47 — For the second CF-End transmitted in the TXOP, the matching control frame is the first CTS that fol- 48 lows the first RTS transmitted in the TXOP. 49 50 — For the third CF-End transmitted in the TXOP, the matching control frame is the second CTS that 51 follows the first RTS transmitted in the TXOP. 52 53 54 A STA that transmits a CF-End control frame at the end of a TXOP that was obtained by an AP through the 55 use of the dual CTS mechanism shall transmit the CF-End control frame with the same value for the TXVEC- 56 TOR parameter STBC, TXVECTOR parameter MCS (if present), and TXVECTOR parameter RATE, as was 57 58 used for the transmission of the matching control frame at the beginning of the TXOP. The matching control 59 frame is defined as follows: 60 61 — For the first CF-End transmitted in the TXOP, the matching control frame is the first CTS-to-self 62 transmitted in the TXOP. 63 64 — For the second CF-End transmitted in the TXOP, the matching control frame is the first RTS trans- 65 mitted in the TXOP.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 9.6.0e.4 Rate selection for control frames that are not control response frames 2 3 4 This subclause describes the rate selection rules for control frames that are not control response frames, and 5 are not the frame that initiates a TXOP, and are not the frame that terminates a TXOP, and are not carried in 6 an A-MPDU. 7 8 9 A frame other than a BlockAckReq or BlockAck that is carried in a non-HT PPDU shall be transmitted by 10 the STA using a rate no higher than the highest rate in the BSSBasicRateSet parameter that is less than or 11 equal to the rate or non-HT reference rate (see 9.6.2) of the previously transmitted frame that was directed to 12 the same receiving STA. If no rate in the BSSBasicRateSet parameter meets these conditions, the control 13 frame shall be transmitted at a rate no higher than the highest mandatory rate of the attached PHY that is less 14 15 than or equal to the rate or non-HT reference rate (see 9.6.2) of the previously transmitted frame that was di- 16 rected to the same receiving STA. 17 18 A BlockAckReq or BlockAck that is carried in a non-HT PPDU shall be transmitted by the STA using a rate 19 20 supported by the receiver STA, as reported in the Supported Rates element and/or Extended Supported Rates 21 element in frames transmitted by that STA. In the case where the supported rate set of the receiving STA or 22 STAs is not known, the transmitting STA shall transmit using a rate from the BSSBasicRateSet parameter or 23 from the mandatory rate set of the attached PHY if the BSSBasicRateSet is empty. 24 25 26 A frame that is carried in an HT PPDU shall be transmitted by the STA using an MCS supported by the re- 27 ceiver STA, as reported in the Supported MCS field in the HT capabilities element in management frames 28 transmitted by that STA. In the case where the supported rate set of the receiving STA or STAs is not known, 29 the transmitting STA shall transmit using an MCS in the BSSBasicMCSSet parameter. 30 31 32 9.6.0e.5 Rate selection for control response frames 33 34 35 9.6.0e.5.1 Introduction 36 37 Subclauses 9.6.0e.5.2 to 9.6.0e.5.5 describe the rate selection rules for control response frames that are not 38 carried in an A-MPDU. 39 40 41 9.6.0e.5.2 Selection of a rate or MCS 42 43 To allow the transmitting STA to calculate the contents of the Duration/ID field, a STA responding to a re- 44 45 ceived frame transmits its control response frame at a primary rate, or at an alternate rate or at an MCS, as 46 specified by the following rules: 47 48 — If a CTS or ACK control response frame is carried in a non-HT PPDU, the primary rate is defined to 49 be the highest rate in the BSSBasicRateSet parameter that is less than or equal to the rate (or non-HT 50 reference rate, see 9.6.2) of the previous frame. If no rate in the BSSBasicRateSet parameter meets 51 these conditions, the primary rate is defined to be the highest mandatory rate of the attached PHY 52 that is less than or equal to the rate (or non-HT reference rate, see 9.6.2) of the previous frame. The 53 54 STA may select an alternate rate according to the rules in 9.6.0e.5.4. The STA shall transmit the non- 55 HT PPDU CTS or ACK control response frame at either the primary rate or the alternate rate, if one 56 exists. 57 58 — If a BlockAck frame is sent as an immediate response to either an implicit BlockAck request or to a 59 BlockAckReq frame that was carried in an HT PPDU and the BlockAck frame is carried in a non-HT 60 PPDU, the primary rate is defined to be the highest rate in the BSSBasicRateSet parameter that is 61 less than or equal to the rate (or non-HT reference rate, see 9.6.2) of the previous frame. If no rate in 62 the BSSBasicRateSet parameter meets these conditions, the primary rate is defined to be the highest 63 64 mandatory rate of the attached PHY that is less than or equal to the rate (or non-HT reference rate, 65 see 9.6.2) of the previous frame. The STA may select an alternate rate according to the rules in

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 9.6.0e.5.4. The STA shall transmit the non-HT PPDU BlockAck control response frame at either the 2 primary rate or the alternate rate, if one exists. 3 4 — If a Basic BlockAck frame is sent as an immediate response to a BlockAckReq frame that was car- 5 ried in a non-HT PPDU and the Basic BlockAck frame is carried in a non-HT PPDU, the primary 6 rate is defined to be the same rate and modulation class as the BlockAckReq frame and the STA shall 7 transmit the Basic BlockAck frame at the primary rate. 8 9 — If a Compressed BlockAck frame is sent as an immediate response to a BlockAckReq frame that was 10 carried in a non-HT PPDU and the Compressed BlockAck frame is carried in a non-HT PPDU, the 11 primary rate is defined to be the highest rate in the BSSBasicRateSet parameter that is less than or 12 13 equal to the rate (or non-HT reference rate, see 9.6.2) of the previous frame. If no rate in the BSSBa- 14 sicRateSet parameter meets these conditions, the primary rate is defined to be the highest mandatory 15 rate of the attached PHY that is less than or equal to the rate (or non-HT reference rate, see 9.6.2) of 16 the previous frame. The STA may select an alternate rate according to the rules in 9.6.0e.5.4. The 17 STA shall transmit the non-HT PPDU Compressed BlockAck control response frame at either the 18 19 primary rate or the alternate rate, if one exists. 20 — If the control response frame is carried in an HT PPDU, then it is transmitted at an MCS as deter- 21 mined by the procedure defined in 9.6.0e.5.3. 22 23 24 The modulation class of the control response frame shall be selected according to the following rules: 25 — If the received frame is of a modulation class other than HT and the control response frame is carried 26 in a non-HT PPDU, the control response frame shall be transmitted using the same modulation class 27 28 as the received frame. In addition, the control response frame shall be sent using the same value for 29 the TXVECTOR parameter PREAMBLE_TYPE as the received frame. 30 — If the received frame is of the modulation class HT and the control response frame is carried in a 31 32 non-HT PPDU, the control response frame shall be transmitted using one of the ERP-OFDM or 33 OFDM modulation classes. 34 — If the control response frame is carried in an HT PPDU the modulation class shall be HT. 35 36 37 The selection of the value for the channel width (CH_BANDWIDTH parameter of the TXVECTOR) of the 38 response transmission is defined in 9.6.0e.6. 39 40 9.6.0e.5.3 Control response frame MCS computation 41 42 43 If a control response frame is to be transmitted within an HT PPDU, the channel width (CH_BANDWIDTH 44 parameter of the TXVECTOR) shall be selected first according to 9.6.0e.6 and then the MCS shall be selected 45 from a set of MCSs called the CandidateMCSSet as described in this subclause. 46 47 48 The Rx Supported MCS Set of the STA that transmitted the frame eliciting the response is determined from 49 its Supported MCS Set field as follows: 50 51 — If a bit in the Rx MCS Bitmask subfield is set to 0, the corresponding MCS is not supported. 52 — If a bit in the Rx MCS Bitmask subfield is set to 1 and the integer part of the data rate (expressed in 53 units of Mb/s) of the corresponding MCS is less than or equal to the rate represented by the Rx High- 54 est Supported Data Rate field, then the MCS is supported by the STA on receive. If the Rx Highest 55 56 Supported Data Rate field is zero and a bit in the Rx MCS Bitmask is set to 1, then the corresponding 57 MCS is supported by the STA on receive. 58 59 The CandidateMCSSet is determined using the following rules: 60 61 — If the frame eliciting the response was an STBC frame and the Dual CTS Protection bit is set to 1, the 62 CandidateMCSSet shall contain only the Basic STBC MCS. 63 64 — If the frame eliciting the response had an L-SIG Duration value (see 9.13.5) and initiates a TXOP, 65 the CandidateMCSSet is the MCS Set consisting of the intersection of the Rx Supported MCS Set of

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 the STA that sent the frame that is eliciting the response and the set of MCSs that the responding 2 STA is capable of transmitting. 3 4 — If none of the above conditions is true, the CandidateMCSSet is the BSSBasicMCSSet parameter. If 5 the BSSBasicMCSSet parameter is empty, the CandidateMCSSet shall consist of the set of manda- 6 tory HT PHY MCSs. 7 8 9 MCS values from the CandidateMCSSet that cannot be transmitted with the selected CH_BANDWIDTH pa- 10 rameter value shall be eliminated from the CandidateMCSSet. 11 12 The choice of a response MCS is made as follows: 13 14 a) If the frame eliciting the response is within a non-HT PPDU, 15 1) Eliminate from the CandidateMCSSet all MCSs that have a Data Rate greater than the Data 16 17 Rate of the received PPDU (the mapping of MCS to Data Rate is defined in 20.6). 18 2) Find the highest indexed MCS from the CandidateMCSSet. The index of this MCS is the index 19 of the MCS that is the primary MCS for the response transmission. 20 21 3) If the CandidateMCSSet is empty, the primary MCS is the lowest indexed MCS of the manda- 22 tory MCSs. 23 24 b) If the frame eliciting the response is within an HT-PPDU, 25 1) Eliminate from the CandidateMCSSet all MCSs that have an index that is higher than the index 26 of the MCS of the received frame. 27 28 2) Determine the highest number of spatial streams (NSS) value of the MCSs in the CandidateMC- 29 SSet that is less than or equal to the NSS value of the MCS of the received frame. Eliminate all 30 MCSs from the CandidateMCSSet that have an N value that is not equal to this N value. 31 SS SS 32 The mapping from MCS to NSS is dependent on the attached PHY. For the HT PHY, see 20.6. 33 3) Find the highest-indexed MCS of the CandidateMCSSet for which the modulation value of 34 each stream is less than or equal to the modulation value of each stream of the MCS of the 35 36 received frame and for which the coding rate value is less than or equal to the coding rate value 37 of the MCS from the received frame. The index of this MCS is the index of the MCS that is the 38 primary MCS for the response transmission. The mapping from MCS to modulation and coding 39 rate is dependent on the attached PHY. For the HT PHY, see 20.6. For the purpose of compar- 40 ing modulation values, the following sequence shows increasing modulation values: BPSK, 41 42 QPSK, 16-QAM, 64-QAM. 43 4) If there is no MCS that meets the condition in step 3), remove each MCS from the Candi- 44 dateMCSSet that has the highest value of N in the CandidateMCSSet. If the resulting Candi- 45 SS 46 dateMCSSet is empty, then set the CandidateMCSSet to the HT PHY mandatory MCSs. 47 Repeat step 3) using the modified CandidateMCSSet. 48 49 Once the primary MCS has been selected, the STA may select an alternate MCS according to 9.6.0e.5.4. The 50 STA shall transmit the HT-PPDU control response frame using either the primary MCS or the alternate MCS, 51 52 if one exists. 53 54 9.6.0e.5.4 Selection of an alternate rate or MCS for a control response frame 55 56 57 An alternate rate may be selected provided that the following conditions are met: 58 — the duration of frame at the alternate rate is the same as the duration of the frame at the primary rate 59 determined by 9.6.0e.5.2; and 60 61 — the alternate rate is in either the BSSBasicRateSet parameter or is a mandatory rate of the attached 62 PHY; and 63 64 — the modulation class of the frame at the alternate rate is the same class as that of the primary rate 65 selected by 9.6.0e.5.2.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 An alternate MCS may be selected provided that the following conditions are met: 2 3 — the duration of the frame at the alternate MCS is the same as the duration of the frame at the primary 4 MCS; and 5 — the alternate MCS is in the CandidateMCSSet that was generated according to the procedure of 6 9.6.0e.5.3. 7 8 9 9.6.0e.5.5 Control response frame TXVECTOR parameter restrictions 10 11 A STA shall not transmit a control response frame with TXVECTOR parameter GI_TYPE set to SHORT_GI 12 13 unless it is in response to a reception of a frame with the RXVECTOR parameter GI_TYPE set to 14 SHORT_GI. 15 16 A STA shall not transmit a control response frame with TXVECTOR parameter FEC_CODING set to 17 LDPC_CODING unless it is in response to a reception of a frame with the RXVECTOR parameter 18 19 FEC_CODING set to LDPC_CODING. 20 21 A STA shall not transmit a control response frame with the TXVECTOR parameter FORMAT set to HT_GF. 22 23 9.6.0e.6 Channel Width selection for control frames 24 25 26 An HT STA that receives a frame that elicits a control frame transmission shall send the control frame re- 27 sponse using a value for the CH_BANDWIDTH parameter that is based on the CH_BANDWIDTH parame- 28 ter value of the received frame according to Table 9-1b. 29 30 31 32 Table 9-1b—CH_BANDWIDTH control frame response mapping 33 34 35 CH_BANDWIDTH CH_BANDWIDTH 36 RXVECTOR value TXVECTOR value 37 38 HT_CBW20 HT_CBW20 or NON_HT_CBW20 39 HT_CBW40 HT_CBW40 or NON_HT_CBW40 40 41 NON_HT_CBW20 HT_CBW20 or NON_HT_CBW20 42 43 NON_HT_CBW40 HT_CBW40 or NON_HT_CBW40 44 45 46 47 NOTE 1—This rule, combined with the rules in 9.6.0e.1 determines the format of control response frames. 48 49 A frame that is intended to provide protection is transmitted using a channel width selected by the rules de- 50 fined in 9.13. 51 52 53 An HT STA that uses a non-HT duplicate frame to establish protection of its TXOP shall send any CF-End 54 frame using a non-HT duplicate frame except during the 40 MHz phase of PCO operation. During the 40 MHz 55 phase of PCO operation, the rules in 11.15 apply. 56 57 58 9.6.0e.7 Control frame TXVECTOR parameter restrictions 59 60 A STA shall not transmit a control frame that initiates a TXOP with the TXVECTOR parameter GI_TYPE 61 set to a value of SHORT_GI. 62 63 64 A STA shall not transmit a control frame that initiates a TXOP with the TXVECTOR parameter 65 FEC_CODING set to a value of LDPC_CODING.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 9.6.1 Modulation classes 2 3 4 Change 9.6.1 as follows: 5 6 7 In order to determine the rules for response frames given in 9.6, the following modulation classes are defined 8 in Table 9-2. Each row defines a modulation class. Modulations described within the same row have the same 9 modulation class, while modulations described in different rows have different modulation classes. For 10 Clause 20 PHY transmissions, the modulation class is determined by the FORMAT and 11 12 NON_HT_MODULATION parameters of the TXVECTOR/RXVECTOR. Otherwise, the modulation class 13 is determined by the Clause or subclause number defining that modulation. 14 15 EDITORIAL NOTE—The changes to Table 9-2 comprise the addition of two columns and a spanned 16 17 column heading, one column showing the condition that selects the modulation class for non-Clause 20 18 PHYs and one that selects the condition for Clause 20 PHY. The non-Clause 20 condition is a reference 19 to a clause or subclause that is moved from the existing text in the “description of modulation” column. 20 The row for HT PHY is added. 21 22 23 Change Table 9-2 as follows: 24 25 26 Table 9-2—Modulation classes 27 28 29 Condition that selects this modulation class 30 Modulation 31 Description of Modulation Class PHYs defined by Clauses 32 Clause 20 PHY 14, 15, 16, 17, 18 or 19 33 34 35 1 Infrared (IR) PHY (Clause Clause 16 transmission N/A 36 16) 37 38 2 Frequency-hopping spread Clause 14 transmission N/A 39 spectrum (FHSS) PHY 40 (Clause 14) 41 42 3 DSSS PHY (Clause 15) and Clause 15 or Clause 18 FORMAT = NON_HT and 43 HR/DSSS PHY (Clause 18) transmission NON_HT_MODULATION is one of: 44 —ERP-DSSS 45 — ERP-CCK 46 47 48 4 ERP-PBCC PHY (19.6) Clause 19.6 transmission FORMAT = NON_HT and 49 NON_HT_MODULATION is ERP-PBCC 50 51 5 DSSS-OFDM PHY (19.7) Clause 19.7 transmission FORMAT = NON_HT and 52 NON_HT_MODULATION is DSSS- 53 OFDM 54 55 6 ERP-OFDM PHY (19.5) Clause 19.5 transmission FORMAT = NON_HT and 56 NON_HT_MODULATION is ERP- 57 OFDM 58 59 7 OFDM PHY (Clause 17) Clause 17 transmission FORMAT = NON_HT and 60 NON_HT_MODULATION one of: 61 —OFDM 62 — NON_HT_DUP_OFDM 63 64 65 8 HT N/A FORMAT is HT_MF or HT_GF

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Insert the following subclause (9.6.2) after 9.6.1 : 2 3 4 9.6.2 Non-HT basic rate calculation 5 6 This subclause defines how to convert an HT MCS to a non-HT basic rate for the purpose of determining the 7 rate of the response frame. It consists of two steps as follows: 8 9 a) Use the modulation and coding rate determined from the HT MCS (defined in 20.6) to a non-HT ref- 10 erence rate by lookup into Table 9-2a 1. In the case of an MCS with unequal modulation, the modu- 11 lation of stream 1 is used. 12 13 b) The non-HT Basic Rate is the highest rate in the BSSBasicRateSet that is less than or equal to this 14 non-HT reference rate. 15 16 17 18 Table 9-2a—Non-HT reference rate 19 20 Coding rate Non-HT reference rate 21 Modulation 22 (R) (Mb/s) 23 24 BPSK 1/2 6 25 BPSK 3/4 9 26 27 QPSK 1/2 12 28 29 QPSK 3/4 18 30 31 16-QAM 1/2 24 32 33 16-QAM 3/4 36 34 64-QAM 1/2 48 35 36 64-QAM 2/3 48 37 38 64-QAM 3/4 54 39 40 64-QAM 5/6 54 41 42 43 44 9.7 MSDU transmission restrictions 45 46 Change the second to sixth paragraphs of 9.7 as follows: (note the conversion of part of second and third 47 48 paragraphs to a NOTE by the insertion of a paragraph and formatting changes appropriate to a NOTE). 49 50 A non-QoS STA shall ensure that no more than one MSDU or MMPDU from a particular SA to a particular 51 individual RA is outstanding at a time. 52 53 NOTE—Note that aA simpler, more restrictive invariant to maintain more restrictive alternative to the rule in the above 54 paragraph that may be used - is that no more than one MSDU with a particular individual RA may be outstanding at a 55 time. 56 57 For all transmissions not using the acknowledgement policy of Block Ack or frames that are not sent within 58 the context of a Block Ack agreement, a QoS STA shall ensure that no more than one MSDU or A-MSDUor 59 60 MMPDU with for each a particular TID or MMPDU from a particular SA to a particular individual RA is 61 outstanding at any time. Note that a 62 63 1. For example if an HT PPDU transmission uses 64-QAM and coding rate of ¾, the related non-HT 64 65 reference rate is 54 Mb/s.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 NOTE—A simpler, more restrictive invariant to maintain more restrictive alternative to the rule in the above paragraph 2 that may be used - is that no more than one MSDU or A-MSDU with any particular TID with a particular individual RA 3 may be outstanding at any time. This restriction is not applicable for MSDUs that are to be transmitted using the Block 4 Ack mechanism. 5 6 7 In a STA where the optional StrictlyOrdered service class has been implemented, that STA shall ensure that 8 there is no group-addressed (multidestination) MSDU of the StrictlyOrdered service class outstanding from 9 the SA of any other outstanding MSDU (either individual or group-addressed). This is because a group ad- 10 dressed MSDU is implicitly addressed to a collection of peer STAs that could include any individual RA. 11 12 13 It is recommended that the STA select a value of dot11MaxTransmitMSDULifetime that is sufficiently large 14 that the STA does not discard MSDUs or A-MSDUs due to excessive Transmit MSDU timeouts under normal 15 operating conditions. 16 17 18 An A-MSDU shall contain only MSDUs of a single service class, and inherits that service class for the pur- 19 pose of the following rules. For MSDUs or A-MSDUs belonging to the service class of QoSAck, when the 20 21 receiver is a QoS STA, the QoS data frames that are used to send these MSDUs or A-MSDUs shall have the 22 Ack Policy subfield in the QoS Control field set to Normal Ack, or Block Ack, Implicit Block Ack Request, 23 or PSMP Ack. For MSDUs or A-MSDUs belonging to the service class of QoSNoAck when the receiver is 24 a QoS STA, the QoS data frames that are used to send these MSDUs or A-MSDUs shall have the Ack Policy 25 subfield in the QoS Control field set to No Ack. 26 27 28 Insert the following subclauses (9.7a to 9.7i) after 9.7: 29 30 31 32 9.7a High Throughput Control field operation 33 34 If the value of its MIB variable dot11HTControlFieldSupported is TRUE, a STA shall set the +HTC Support 35 36 subfield of the HT Extended Capabilities field of the HT Capabilities element to 1 in HT Capabilities ele- 37 ments that it transmits. 38 39 40 A STA that has a value of TRUE for at least one of its MIB variables 41 dot11RDResponderOptionImplemented and dot11MCSFeedbackOptionImplemented shall set 42 dot11HTControlFieldSupported to TRUE. 43 44 45 An HT Control field shall not be present in a frame addressed to a STA unless that STA declares support for 46 +HTC in the HT Extended Capabilities field of its HT Capabilities element (see 7.3.2.56). 47 48 NOTE—An HT STA that does not support +HTC that receives a +HTC frame addressed to another STA still performs 49 the CRC on the actual length of the MPDU and uses the Duration/ID field to update the NAV, as described in 9.2.5.4. 50 51 If the HT Control field is present in an MPDU aggregated in an A-MPDU, then all MPDUs of the same frame 52 type (i.e., having the same value for the Type subfield of the Frame Control field) aggregated in the same A- 53 54 MPDU shall contain an HT Control field. The HT Control field of all MPDUs containing the HT Control field 55 aggregated in the same A-MPDU shall be set to the same value. 56 57 58 9.7b Control Wrapper operation 59 60 61 A STA supporting the HT Control field that receives a Control Wrapper frame shall process it as though it 62 received a frame of the subtype of the wrapped frame. 63 64 NOTE—A STA supporting the HT Control field can reset the NAV set by a wrapped RTS frame following the rules 65 defined in 9.2.5.4.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 9.7c A-MSDU operation 2 3 4 An A-MSDU shall contain only MSDUs whose DA and SA parameter values map to the same RA and TA 5 values. 6 7 The constituent MSDUs of an A-MSDU shall all have the same priority parameter value from the corre- 8 sponding MA-UNITDATA.request. 9 10 11 An A-MSDU shall be carried, without fragmentation, within a single QoS data MPDU. 12 13 The Address 1 field of an MPDU carrying an A-MSDU shall be set to an individual address. 14 15 16 The channel access rules for a QoS data MPDU carrying an A-MSDU are the same as a data MPDU carry- 17 ing an MSDU (or fragment thereof) of the same TID. 18 19 20 The expiration of the A-MSDU lifetime timer occurs only when the lifetime timer of all of the constituent 21 MSDUs of the A-MSDU have expired. 22 NOTE 1—This implicitly allows an MSDU that is a constituent of an A-MSDU to potentially be transmitted after the 23 expiry of its lifetime. 24 25 NOTE 2—Selecting any other value for the time-out would result in loss of MSDUs. Selecting the Maximum value 26 avoids this at the cost of transmitting MSDUs that have exceeded their lifetime. 27 28 A STA that has a value of FALSE for the MIB attribute dot11HighthroughputOptionImplemented shall not 29 transmit an A-MSDU. A STA shall not transmit an A-MSDU to a STA from which it has not received a 30 frame containing an HT Capabilities element. 31 32 33 Support for the reception of an A-MSDU, where the A-MSDU is carried in a QoS data MPDU with Ack 34 Policy set to Normal Ack, and the A-MSDU is not aggregated within an A-MPDU, is mandatory for an HT 35 STA. 36 37 38 The use of an A-MSDU carried in a QoS data MPDU under a Block Ack agreement is determined per Block 39 Ack agreement. A STA shall not transmit an A-MSDU within a QoS data MPDU under a Block Ack agree- 40 ment unless the recipient indicates support for A-MSDU by setting the A-MSDU Supported field to 1 in its 41 BlockAck Parameter Set field of the ADDBA response frame. 42 43 44 A STA shall not transmit an A-MSDU to a STA that exceeds its Maximum A-MSDU Length capability. 45 NOTE 3—Support for A-MSDU aggregation does not affect the maximum size of MSDU transported by the MA- 46 UNITDATA primitives. 47 48 49 9.7d A-MPDU operation 50 51 9.7d.1 A-MPDU contents 52 53 54 According to its context (defined in Table 7-57w), an A-MPDU shall be constrained so that it contains only 55 MPDUs as specified in the relevant table referenced from Table 7-57w. 56 57 58 9.7d.2 A-MPDU length limit rules 59 60 An HT STA indicates a value in the Maximum A-MPDU Length Exponent field in its HT Capabilities ele- 61 ment that defines the maximum A-MPDU length that it can receive. The encoding of this field is defined in 62 Table 7-43l. Using this field, the STA establishes at association the maximum length of A-MPDUs that will 63 64 be sent to it. The STA shall be capable of receiving A-MPDUs of length up to the value indicated by this 65 field.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 An HT STA shall not transmit an A-MPDU that is longer than the value indicated by the Maximum A-MPDU 2 Length Exponent field declared by the intended receiver. 3 NOTE—The A-MPDU length limit applies to the maximum length of the PSDU that may be received. If the A-MPDU 4 includes any padding delimiters (i.e., delimiters with the length field set to 0) in order to meet the MPDU Start Spacing 5 requirement, this padding is included in this length limit. 6 7 8 9.7d.3 Minimum MPDU Start Spacing 9 10 An HT STA shall not start the transmission of more than one MPDU within the time limit described in the 11 Minimum MPDU Start Spacing field declared by the intended receiver. To satisfy this requirement, the num- 12 13 ber of octets between the start of two consecutive MPDUs in an A-MPDU, measured at the PHY SAP, shall 14 be equal or greater than: 15 16 t  r  8 17 MMSS 18 19 where 20 21 tMMSS is the time (in units of s) defined in the Encoding column of Table 7-43l for the value of the 22 23 Minimum MPDU Start Spacing field 24 r is the value of the PHY Data Rate (in units of Mb/s) defined in 20.6 based on the TXVECTOR 25 26 parameters: MCS, GI_TYPE and CH_BANDWIDTH 27 28 If necessary, in order to satisfy this requirement, a STA shall add padding between MPDUs in an A-MPDU. 29 Any such padding shall be in the form of one or more MPDU Delimiters with the MPDU length field set to 0. 30 31 32 9.7d.4 A-MPDU aggregation of group addressed data frames 33 34 A non-AP HT STA shall not transmit an A-MPDU containing an MPDU with a group addressed RA. 35 NOTE—An HT AP can transmit an A-MPDU containing MPDUs with a group addressed RA. 36 37 38 An HT AP shall not transmit an A-MPDU containing group addressed MPDUs if the HT Protection field is 39 set to non-HT mixed mode. 40 41 When an HT AP transmits an A-MPDU containing MPDUs with a group addressed RA, both of the following 42 43 shall apply: 44 — the value of Maximum A-MPDU Length Exponent that applies is the minimum value in the Maxi- 45 mum A-MPDU Length Exponent subfield of the A-MPDU Parameters field of the HT Capabilities 46 47 element across all HT STAs associated with the AP; 48 — the value of Minimum MPDU Start Spacing that applies is the maximum value in the Minimum 49 MPDU Start Spacing subfield of the A-MPDU Parameters field of the HT Capabilities element 50 51 across all HT STAs associated with the AP. 52 53 9.7d.5 Transport of A-MPDU by the PHY data service 54 55 56 An A-MPDU shall be transmitted in a PSDU associated with a PHY-TXSTART.request with the TXVEC- 57 TOR AGGREGATION parameter set to 1. A received PSDU is determined to be an A-MPDU when the as- 58 sociated PHY-RXSTART.indication RXVECTOR AGGREGATION parameter is set to 1. 59 60 61 9.7e PPDU Duration Constraint 62 63 64 An HT STA shall not transmit a PPDU that has a duration (as determined by the PHY-TXTIME.confirm 65 primitive defined in 10.4.6) that is greater than aPPDUMaxTime.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 9.7f LDPC Operation 2 3 4 An HT STA shall not transmit a frame with the TXVECTOR parameter FORMAT set to HT_MF or HT_GF 5 and the TXVECTOR parameter FEC_CODING set to LDPC_CODING unless the RA of the frame corre- 6 sponds to a STA for which the LDPC coding capability subfield of the most recently received HT Capabili- 7 ties element from that STA contained a value of 1 and the MIB variable dot11LDPCCodingOptionEnabled 8 9 is set to TRUE. 10 11 Further restrictions on TXVECTOR parameter values may apply due to rules found in 9.13 and 9.6. 12 13 14 15 9.7g STBC Operation 16 17 18 Only a STA that sets the Tx STBC subfield to 1 in the HT Capabilities element may transmit frames with a 19 TXVECTOR parameter STBC set to a non-zero value to a STA from which the most recently received value 20 of the Rx STBC field of the HT Capabilities element is non-zero. 21 22 23 9.7h Short GI Operation 24 25 26 A STA may transmit a frame with TXVECTOR parameters CH_BANDWIDTH set to HT_CBW20 and 27 GI_TYPE set to SHORT_GI only if all of the following conditions are met: 28 29 — the STA is an HT STA 30 31 — the TXVECTOR parameter FORMAT is set to HT_MF or HT_GF 32 33 — the RA of the frame corresponds to a STA for which the Short GI for 20 MHz subfield of the most 34 recently received HT Capabilities element contained a value of 1 35 36 — the MIB variable dot11ShortGIOptionInTwentyEnabled is present and has a value of TRUE 37 38 39 A STA may transmit a frame with TXVECTOR parameters CH_BANDWIDTH set to HT_CBW40 and 40 GI_TYPE set to SHORT_GI only if all of the following conditions are met: 41 42 — the STA is an HT STA 43 44 — the TXVECTOR parameter FORMAT is set to HT_MF or HT_GF 45 — the RA of the frame corresponds to a STA for which the Short GI for 40 MHz subfield of the most 46 47 recently received HT Capabilities element contained a value of 1 48 — the MIB variable dot11ShortGIOptionInFortyEnabled is present and has a value of TRUE 49 50 51 An HT STA shall not transmit a frame with the TXVECTOR parameter FORMAT set to HT_GF and the 52 and GI_TYPE parameter set to SHORT_GI when the MCS parameter indicates a single spatial stream. 53 54 55 Further restrictions on TXVECTOR parameter values may apply due to rules found in 9.13 and 9.6. 56 57 58 9.7i Greenfield operation 59 60 61 An HT STA shall not transmit a frame with the TXVECTOR parameter FORMAT set to HT_GF unless the 62 RA of the frame corresponds to a STA for which the HT-greenfield subfield of the most recently received 63 64 HT Capabilities element contained a value of 1, and the MIB variable dot11HTGreenfieldOptionEnabled is 65 set to TRUE. Further restrictions may apply due to rules found in 9.13, 9.6, and 11.9.7.3.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 9.9 HCF 2 3 4 9.9.1 HCF contention-based channel access (EDCA) 5 6 9.9.1.2 EDCA TXOPs 7 8 Change the second paragraph of 9.9.1.2 as follows: 9 10 11 The TXOP limit duration values are advertised by the AP in the EDCA Parameter Set information element 12 in Beacon and Probe Response frames transmitted by the AP. A TXOP limit value of 0 indicates that a single 13 MSDU or MMPDU, in addition to a possible RTS/CTS exchange or CTS to itself, may be transmitted at any 14 15 rate for each TXOP. 16 17 A TXOP limit value of 0 indicates that the TXOP holder may transmit or cause to be transmitted (as respons- 18 es) the following within the current TXOP: 19 20 a) A single MSDU, MMPDU, A-MSDU, or A-MPDU at any rate, subject to the rules in 9.6 21 b) Any required acknowledgements 22 23 c) Any frames required for protection, including one of the following: 24 1) An RTS/CTS exchange 25 26 2) CTS to itself 27 3) Dual CTS as specified in 9.2.5.5a 28 29 d) Any frames required for beamforming as specified in 9.17 30 e) Any frames required for link adaptation as specified in 9.16.2 31 32 f) Any number of BlockAckReq and BlockAck frames 33 NOTE 1—This is a rule for the TXOP holder. A TXOP responder need not be aware of the TXOP limit, nor of when the 34 TXOP was started. Behavior at the TXOP responder is restricted by the Duration/ID field value(s) in frames it receives 35 from the TXOP holder. 36 37 NOTE 2—The TXOP holder can control how much time, if any, the TXOP responder has to transmit frames required for 38 beamforming (e.g., channel state information feedback). 39 40 NOTE 3—This rule prevents the use of RD when the TXOP limit is set to 0. 41 42 Change the fourth paragraph 9.9.1.2 as follows: 43 44 A STA shall fragment an unicastindividually addressed MSDU so that the transmission of the first MPDU of 45 46 the TXOP does not cause the TXOP limit to be exceeded at the PHY rate selected for the initial transmission 47 attempt of that MPDU. The TXOP limit may be exceeded, when using a lower PHY rate than selected for the 48 initial transmission attempt of the first MPDU, for a retransmission of an MPDU, for the initial transmission 49 of an MPDU if any previous MPDU in the current MSDU has been retransmitted, or for group addressed MS- 50 DUs. When the TXOP limit is exceeded due to the retransmission of an MPDU at a reduced PHY rate, the 51 52 STA shall not transmit more than one MPDU in the TXOP. 53 54 9.9.1.4 Multiple frame transmission in an EDCA TXOP 55 56 Change the first to third paragraphs of 9.9.1.4 as follows: (note strikeout of an isolated “t” in line 6 and 57 58 comma in the third paragraph) 59 60 Multiple frames may be transmitted in an acquired EDCA TXOP that was acquired following the rules in 61 9.9.1.3 if there areis more than one frame pending in the AC for which the channel has been acquired. How- 62 ever, those frames that are pending in other ACs shall not be transmitted in this EDCA TXOP. If a TXOP 63 64 holderSTA has in its transmit queue an additional frame of the same AC as the one just transmitted and the 65 duration of transmission of that frame plus any expected acknowledgment for that frame is less than the re-

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 maining TXNAVmedium occupancy timer value, then the STA may commence transmission of that frame at 2 SIFS (or RIFS, under the conditions defined in 9.2.3.0b) after the completion of the immediately preceding 3 frame exchange sequence. An HT STA that is a TXOP holder may transmit multiple MPDUs of the same AC 4 5 within an A-MPDU as long as the duration of transmission of the A-MPDU plus any expected BlockAck re- 6 sponse is less than the remaining TXNAV timer value. 7 NOTE—An RD responder can transmit multiple MPDUs as described in 9.15.4. 8 9 10 The TXNAV timer is a timer that is initialized with the duration from the Duration/ID field in the frame most 11 recently successfully transmitted by the TXOP holder. The TXNAV timer begins counting down from the 12 end of the transmission of the PPDU containing that frame. Following the BlockAck response, the HT STA 13 may start transmission of another MPDU or A-MPDU a SIFS after the completion of the immediately pre- 14 ceding frame exchange sequence. The HT STA may retransmit unacknowledged MPDUs within the same 15 16 TXOP or in a subsequent TXOP. The intention of using the multiple frame transmission shall be indicated by 17 the STA through the setting of the duration/ID values in one of the following two ways (see 7.1.4): 18 a) Long enough to cover the response frame, the next frame, and its response frame. 19 20 b) Long enough to cover the transmission of a burst of MPDUs subject to the limit set by 21 dot11EDCATableTXOPLimit. 22 23 24 After a valid response to the initial frame of a TXOP, and if If the Duration/ID field is set for multiple frame 25 transmission and there is a subsequent transmission failure, the corresponding channel access function may 26 recover transmit after the CS mechanism (see 9.2.1) indicates that the medium is idle at the TxPIFS slot 27 boundary (defined in 9.2.10), before the expiry of the TXNAV timer.NAV setting due to the setting of the 28 29 Duration/ID field in the frame that resulted in a transmission failure. The backoff procedure is described in 30 9.9.1.5. However, at At the expiry of the TXNAV timer NAV set by the frame that resulted in a transmission 31 failure, if the channel access function has not regained access to the medium recovered, then the EDCAF shall 32 invoke the backoff procedure that is described in 9.9.1.5. Transmission failure is defined in 9.9.1.5. 33 34 35 No other AC at the STA shall transmit before the expiry of the NAV set by the frame that resulted in a trans- 36 mission failure. All other ACs channel access functions at the STA shall treat the medium as busy until the 37 expiry of the TXNAV timer NAV set by the frame that resulted in a transmission failure, just as they would 38 if they had received that transmissionfrom another STA. 39 40 41 Change the last paragraph of 9.9.1.4 as follows: 42 43 Note that, as for an EDCA TXOP, a multiple frame transmission is granted to an EDCAF, not to a non-AP 44 45 STA or AP, so that the multiple frame transmission is permitted only for the transmission of a frame of the 46 same AC as the frame that was granted the EDCA TXOP, unless the EDCA TXOP obtained is used by an AP 47 for a PSMP sequence, in which case, this AC transmission restriction does not apply to either the AP or the 48 STAs participating in the PSMP sequence, but the specific restrictions on transmission during a PSMP se- 49 quence described in 9.16 do apply. 50 51 52 9.9.1.5 EDCA Backoff procedure 53 54 Change 9.9.1.5 as follows: 55 56 57 Each EDCAF shall maintain a state variable CW[AC], which shall be initialized to the value of the parameter 58 CWmin[AC]. 59 60 61 For the purposes of this subclause, successful transmission and transmission failure are defined as follows: 62 — After transmitting an MPDU (regardless of whether it is carried in an A-MPDU or not) that requires 63 64 an immediate frame as a response, the STA shall wait for a timeout interval of duration of aSIFS- 65 Time + aSlotTime + aPHY-RX-START-Delay, starting at the PHY-TXEND.confirm. If a PHY-

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 RXSTART.indication does not occur during the timeout interval, the STA concludes that the trans- 2 mission of the MPDU has failed. 3 4 — If a PHY-RXSTART.indication does occur during the timeout interval, the STA shall wait for the 5 corresponding PHY-RXEND.indication to determine whether the MPDU transmission was success- 6 ful. The recognition of a valid response frame sent by the recipient of the MPDU requiring a 7 response, corresponding to this PHY-RXEND.indication, shall be interpreted as a successful 8 9 response. 10 — The recognition of anything else, including any other valid frame, shall be interpreted as failure of 11 the MPDU transmission. The recognition of a valid data frame sent by the recipient of a PS-Poll 12 frame shall also be accepted as successful acknowledgment of the PS-Poll frame. A transmission that 13 14 does not require an immediate frame as a response is defined as a successful transmission. 15 16 If a frame is successfully transmitted by a specific EDCAF, indicated by the successful reception of a CTS in 17 response to an RTS, the successful reception of an ACK frame in response to a unicast MPDU or BlockAck, 18 the successful reception of a BlockAck or ACK frame in response to a BlockAckReq frame, or the transmis- 19 20 sion of a multicast frame or a frame with No Ack policy, CW[AC] shall be reset to CWmin[AC]. 21 22 Note the change from dashed list to lettered list. This is not shown with strikeouts and underlines for clar- 23 ity. 24 25 26 The backoff procedure shall be invoked for an EDCAF when any of the following events occurs: 27 a) A frame with that AC is requested to be transmitted, the medium is busy as indicated by either phys- 28 ical or virtual CS, and the backoff timer has a value of zero for that AC. 29 30 b) The final transmission by the TXOP holder initiated during the TXOP for that AC was successful 31 and the TXNAV timer has expired. 32 33 c) The transmission of a the initial frame of a TXOP of that AC fails, indicated by a failure to receive a 34 CTS in response to an RTS, a failure to receive an ACK frame that was expected in response to a 35 unicast MPDU, or a failure to receive a BlockAck or ACK frame in response to a BlockAckReq 36 frame. 37 38 d) The transmission attempt collides internally with another EDCAF of an AC that has higher priority, 39 that is, two or more EDCAFs in the same STA are granted a TXOP at the same time. 40 41 In addition, the backoff procedure may be invoked for an EDCAF when the following event occurs: 42 43 e) The transmission of a non-initial frame by the TXOP holder fails. 44 NOTE—A STA can perform a PIFS recovery as described in 9.9.1.4 or perform a backoff as described in e) as 45 a response to transmission failure within a TXOP. How it chooses between these two is implementation depen- 46 dent. 47 48 49 A STA that performs a backoff within its existing TXOP shall not extend the TXNAV timer value. 50 NOTE—This means that the backoff is a continuation of the TXOP, not the start of a new TXOP. 51 52 If the backoff procedure is invoked for reason a) above, the value of CW[AC] shall be left unchanged. If the 53 backoff procedure is invoked because of reason b) above, the value of CW[AC] shall be reset to CWmin[AC]. 54 55 56 If the backoff procedure is invoked because of a failure event [either reasons c), or d), or e) above], the value 57 of CW[AC] shall be updated as follows before invoking the backoff procedure: 58 59 Note the change from lettered list to dashed list. This is not shown with strikeouts and underlines for 60 clarity. 61 62 — If the QSRC[AC] or the QLRC[AC] for the QoS STA has reached dot11ShortRetryLimit or 63 dot11LongRetryLimit respectively, CW[AC] shall be reset to CWmin[AC]. 64 65 —Otherwise,

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 — If CW[AC] is less than CWmax[AC], CW[AC] shall be set to the value (CW[AC] + 1)*2 – 1. 2 3 — If CW[AC] is equal to CWmax[AC], CW[AC] shall remain unchanged for the remainder of 4 any retries. 5 6 7 The backoff timer is set to an integer value chosen randomly with a uniform distribution taking values in the 8 range [0,CW[AC]] inclusive. 9 10 11 All backoff slots occur following an AIFS[AC] period during which the medium is determined to be idle for 12 the duration of the AIFS[AC] period, or following an EIFS – DIFS + AIFS[AC] period during which the me- 13 dium is determined to be idle for the duration of the EIFS – DIFS + AIFS[AC] period, as appropriate (see 14 9.2.3). 15 16 17 If the backoff procedure is invoked following the transmission of a 40 MHz mask PPDU, the backoff counter 18 shall be decremented based on a medium busy indication that ignores activity in the secondary channel. Ad- 19 20 ditional 40 MHz mask PPDU backoff rules are found in 11.14.9. 21 22 9.9.1.6 Retransmit procedures 23 24 25 Change the first to fourth paragraphs of 9.9.1.6 as follows: 26 27 28 QoS STAs shall maintain a short retry counter and a long retry counter for each MSDU, A-MSDU or MMP- 29 DU that belongs to a TC requiring acknowledgment. The initial value for the short and long retry counters 30 shall be zero. QoS STAs also maintain a short retry counter and a long retry counter for each AC. They are 31 defined as QSRC[AC] and QLRC[AC], respectively, and each is initialized to a value of zero. 32 33 34 After transmitting a frame that requires acknowledgment, the STA shall perform either of the acknowledg- 35 ment procedures as appropriate and , as defined in 9.2.8 and 9.10.3. The short retry count for an MSDU or A- 36 37 MSDU that is not part of a Block Ack agreement or for an MMPDU and the QSRC[AC] shall be incremented 38 every time transmission of a MAC frame of length less than or equal to dot11RTSThreshold fails for that MS- 39 DU, A-MSDU or MMPDU. QSRC[AC] shall be incremented every time transmission of an A-MPDU or 40 frame of length less than or equal to dot11RTSThreshold fails. This short retry count and the QoS STA QS- 41 RC[AC] shall be reset when an A-MPDU or MAC frame of length less than or equal to dot11RTSThreshold 42 43 succeeds for that MSDU or MMPDU. The long retry count for an MSDU or A-MSDU that is not part of a 44 Block Ack agreement or for an MMPDU and the QLRC[AC] shall be incremented every time transmission 45 of a MAC frame of length greater than dot11RTSThreshold fails for that MSDU, A-MSDU or MMPDU. QL- 46 RC[AC] shall be incremented every time transmission of an A-MPDU or frame of length greater than or equal 47 to dot11RTSThreshold fails. This long retry count and the QLRC[AC] shall be reset when an A-MPDU or 48 49 MAC frame of length greater than dot11RTSThreshold succeeds for that MSDU or MMPDU. All retransmis- 50 sion attempts for an MPDU that is not sent under a Block Ack agreement and that has failed the acknowledg- 51 ment procedure one or more times shall be made with the Retry field set to 1 in the data or management frame. 52 53 54 Retries for failed transmission attempts shall continue until the short retry count for the MSDU, A-MSDU or 55 MMPDU is equal to dot11ShortRetryLimit or until the long retry count for the MSDU, A-MSDU or MMPDU 56 is equal to dot11LongRetryLimit. When either of these limits is reached, retry attempts shall cease, and the 57 MSDU, A-MSDU or MMPDU shall be discarded. 58 59 60 For internal collisions occurring with the EDCA access method, the appropriate retry counters (short retry 61 counter for MSDU, A-MSDU or MMPDU and QSRC[AC] or long retry counter for MSDU, A-MSDU or 62 MMPDU and QLRC[AC]) are incremented. For transmissions that use Block Ack, the rules in 9.10.3 also 63 64 apply. STAs shall retry failed transmissions until the transmission is successful or until the relevant retry limit 65 is reached.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Insert the following paragraph at the end of 9.9.1.6: 2 3 4 When A-MSDU aggregation is used, the HT STA maintains a single timer for the whole A-MSDU. The timer 5 is restarted each time an MSDU is added to the A-MSDU. This ensures that no MSDU in the A-MSDU is 6 discarded before a period of dot11EDCATableMSDULifetime has elapsed. 7 8 9 Insert the following subclause (9.9.1.7) after the end of 9.9.1.6: 10 11 12 9.9.1.7 Truncation of TXOP 13 14 15 When a STA gains access to the channel using EDCA and empties its transmission queue, it may transmit a 16 CF-End frame provided that the remaining duration is long enough to transmit this frame. By transmitting the 17 CF-End frame, the STA is explicitly indicating the completion of its TXOP. 18 19 20 A TXOP holder that transmits a CF-End frame shall not initiate any further frame exchange sequences within 21 the current TXOP. 22 23 24 A non-AP STA that is not the TXOP holder shall not transmit a CF-End frame. 25 26 27 A STA shall interpret the reception of a CF-End frame as a NAV reset, i.e., it resets its NAV timer to zero at 28 the end of the PPDU containing this frame. After receiving a CF-End frame with a matching BSSID, an AP 29 may respond by transmitting a CF-End frame after SIFS. 30 31 NOTE—The transmission of a single CF-End frame by the TXOP holder resets the NAV of STAs hearing the TXOP 32 holder. There may be STAs that could hear the TXOP responder that had set their NAV that do not hear this NAV reset. 33 Those STAs will be prevented from contending for the medium until the original NAV reservation expires. 34 35 Figure 9-18a shows an example of TXOP truncation. In this example, the STA accesses the medium using 36 37 38 39 TXOP Duration 40 41 42 43 nav-set sequence initiator-sequence TXOP

44 CF-End

45 Nominal end of 46 EDCA Channel 47 Access 48 SIFS SIFS 49 50 Figure 9-18a—Example of TXOP truncation 51 52 EDCA channel access and then transmits a nav-set sequence (e.g., RTS/CTS) (using the terminology of An- 53 nex S) after a SIFS, it then transmits an initiator-sequence, which may involve the exchange of multiple PP- 54 DUs between the TXOP holder and a TXOP responder. At the end of the second sequence, the TXOP holder 55 56 has no more data that it can send that fits within the TXOP, so it truncates the TXOP by transmitting a CF- 57 End frame. 58 59 60 STAs that receive the CF-End frame reset their NAV and can start contending for the medium without further 61 delay. 62 63 64 TXOP truncation shall not be used in combination with L-SIG TXOP Protection when the HT Protection field 65 of the HT Operation element is set to non-member protection mode or non-HT mixed mode.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 9.9.2 HCCA 2 3 4 9.9.2.1 HCCA procedure 5 6 9.9.2.1.3 Recovery from the absence of an expected reception 7 8 9 Change paragraph 2 of 9.9.2.1.3 as follows: 10 11 12 If the beginning of reception of an expected response, as detected by the occurrence of PHYCCA.indica- 13 tion(busyBUSY,channel-list) primitive at the STA that is expecting the response where 14 15 — the channel-list parameter is absent, or 16 — the channel-list is equal to {primary} and the HT STA expected to transmit the expected response 17 supports 20 MHz operation only, or 18 19 — the channel-list is equal to either {primary} or {primary, secondary} and the HT STA expected to 20 transmit the expected response supports both 20 MHz and 40 MHz operation (see 11.14.2), 21 22 23 does not occur during the first slot time following SIFS, then23 24 25 a) If the transmitting STA is the HC, it may initiate recovery by transmitting at a PIFS after the end of 26 the HC’s last transmission only if PHY-CCA.indication primitive is clear. 27 28 b) If the transmitting STA is a non-AP QoS STA, it shall initiate recovery by transmitting at a PIFS 29 after the end of the last transmission, if PHY-CCA.indication primitive is clear, the polled TXOP 30 limit is greater than 0 and at least one frame (re)transmissions can be completed within the remain- 31 32 ing duration of a nonzero polled TXOP limit. 33

34 23 35 This restriction is intended to avoid collisions due to inconsistent CCA reports in different STAs, not to optimize the bandwidth 36 usage efficiency 37 38 9.9.2.2 TXOP structure and timing 39 40 41 Change the second paragraph of 9.9.2.2 as follows: 42 43 44 A TXOP or transmission within a TXOP shall not extend across TBTT, dot11CFPMaxDuration (if during 45 CFP), dot11MaxDwellTime (if using an FH PHY), or dot11CAPLimit. The HC shall ensure that the full du- 46 ration of any granted TXOP meets these requirements so that non-AP STAs may use the time prior to the 47 TXOP limit of a polled TXOP without checking for these constraints. Subject to these limitations, all deci- 48 49 sions regarding what MSDUs, A-MSDUs and/or MMPDUs are transmitted during any given TXOP are made 50 by the STA that holds the TXOP. 51 52 9.9.2.3 HCCA transfer rules 53 54 55 Change the third paragraph of 9.9.2.3 as follows: 56 57 58 If a STA has set up at least one TS for which the Aggregation subfield in the associated TSPEC is set to 0, 59 the AP shall use only QoS CF-Poll or QoS CF-Ack+CF-Poll frames to poll the STA and shall never use QoS 60 (+)Data+CF-Poll to poll the STA. It should be noted that although QoS (+)CF-Poll is a data frame, but it 61 should be transmitted at one of the rates in the BSSBasicRateSet parameter in order to set the NAV of all 62 STAs that are not being polled (see 9.6). If a CF-Poll is piggybacked with a QoS data frame, then the frame 63 64 containing all or part of an MSDU or A-MSDU may be transmitted at the rate that is below the negotiated 65 minimum PHY rate.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 9.10 Block Acknowledgment (Block Ack) 2 3 4 9.10.1 Introduction 5 6 Change the third paragraph of 9.10.1 as follows: 7 8 The Block Ack mechanism does not require the setting up of a TS; however, QoS STAs using the TS facility 9 10 may choose to signal their intention to use Block Ack mechanism for the scheduler’s consideration in 11 assigning TXOPs. Acknowledgments of frames belonging to the same TID, but transmitted during multiple 12 TXOPs, may also be combined into a single BlockAck frame. This mechanism allows the originator to have 13 flexibility regarding the transmission of data MPDUs. The originator may split the block of frames across 14 TXOPs, separate the data transfer and the Block Ack exchange, and interleave blocks of MPDUs carrying 15 16 all or part of MSDUs or A-MSDUs for different TIDs or RAs. 17 18 Insert the following paragraph at the end of 9.10.1: 19 20 All operations on sequence numbers are performed modulo 212. Comparisons between sequence numbers 21 12 22 are circular modulo 2 , which means that the sequence number space is considered divided into two parts, 23 one of which is "old" and one of which is "new" by means of a boundary created by adding half the sequence 24 number range to the current start of receive window (modulo 212). 25 26 9.10.2 Setup and modification of the Block Ack parameters 27 28 29 Change the first paragraph of 9.10.2 as follows (note the insertion of two new paragraph breaks, which 30 cannot be indicated with insertion marks): 31 32 An originator STA that intends to use the Block Ack mechanism for the transmission of QoS data frames to 33 34 an intended recipientpeer should first check whether the intended peer recipient STA is capable of participat- 35 ing in Block Ack mechanism by discovering and examining its Delayed Block Ack and Immediate Block Ack 36 capability bits. If the intended peer recipient STA is capable of participating, the originator sends an ADDBA 37 Request frame indicating the TID for which the Block Ack is being set up. For an ADDBA set up between 38 STAs where one is a non-HT STA, the Block Ack Policy and Buffer Size fields in the ADDBA Request frame 39 40 are advisory and may be changed by the recipient. The Buffer Size field in the ADDBA Request frame is ad- 41 visory and may be changed by the recipient for an ADDBA setup between HT STAs. 42 43 The receiving STA shall respond by an ADDBA Response frame. The receiving STA, which is the intended 44 peer recipient, has the option of accepting or rejecting the request. When the intended recipientSTA accepts, 45 46 then a Block Ack agreement exists between the originator and recipient. 47 48 When the intended recipient STA accepts, it indicates the type of Block Ack and the number of buffers that 49 it shall allocate for the support of this blockBlock Ack agreement within the ADDBA response frame. Each 50 51 Block Ack agreement that is established by a STA may have a different buffer allocation. If the receiving STA 52 rejects the request, then the originator shall not use the Block Ack mechanism. 53 54 Insert the following three paragraphs and note immediately after the above change: 55 56 When the Block Ack Policy subfield value is set to 1 by the originator of an ADDBA request frame between 57 58 HT STAs, then the ADDBA response frame accepting the ADDBA request frame shall contain 1 in the Block 59 Ack Policy subfield. 60 61 When a Block Ack agreement is established between two HT STAs, the originator may change the size of its 62 transmission window if the value in the Buffer Size field of the ADDBA Response frame is larger than the 63 64 value in the ADDBA Request frame. If the value in the Buffer Size field of the ADDBA Response frame is 65 smaller than the value in the ADDBA Request frame, the originator shall change the size of its transmission

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 window (WinSizeO) so that it is not greater than the value in the Buffer Size field of the ADDBA Response 2 frame and is not greater than the value 64. 3 4 5 The A-MSDU Supported field indicates whether an A-MSDU may be sent under the particular Block Ack 6 agreement. The originator sets this field to 1 to indicate that it might transmit A-MSDUs with this TID. The 7 recipient sets this field to 1 to indicate that it is capable of receiving an A-MSDU with this TID. 8 NOTE—The recipient is free to respond with any setting of the A-MSDU supported field. If the value in the ADDBA 9 response frame is not acceptable to the originator, it can delete the Block Ack agreement and transmit data using normal 10 acknowledgement. 11 12 13 9.10.3 Data and acknowledgment transfer using immediate Block Ack policy and delayed 14 Block Ack policy 15 16 Change 9.10.3, replace Figure 9-22, and replace Figure 9-23 as follows: 17 18 19 After setting up either an immediate Block Ack agreement or a Delayed Block agreement following the pro- 20 cedure in 9.10.2, the originator may transmit a block of QoS data frames separated by SIFS period, with the 21 total number of frames not exceeding the Buffer Size subfield value in the associated ADDBA Response 22 frame. Each of the frames shall have the Ack Policy subfield in the QoS Control field set to Block Ack. The 23 24 RA field of the frames shall be the recipient’s unicast address. The originator requests acknowledgment of 25 outstanding QoS data frames by sending a Basic BlockAckReq frame. The recipient shall maintain a Block 26 Ack record for the block. 27 28 Subject to any constraints in this subclause about permitted use of TXOP according to the channel access 29 30 mechanism used, the originator may 31 — Separate the Block and Basic BlockAckReq frames into separate TXOPs 32 33 — Split a Block frame across multiple TXOPs 34 — Split transmission of data MPDUs sent under Block Ack policy across multiple TXOPs 35 36 — Interleave MPDUs with different TIDs within the same TXOP 37 — Sequence or interleave MPDUs for different RAs within a TXOP 38 39 40 A protective mechanism (such as transmitting using HCCA, RTS/CTS, or the mechanism described in 9.13) 41 should be used to reduce the probability of other STAs transmitting during the TXOP. If no protective 42 mechanism is used, then the first frame that is sent as a block shall have a response frame and shall have the 43 Duration field set so that the NAVs are set to appropriate values at all STAs in the BSS. 44 45 46 The originator shall use the Block Ack starting sequence control to signal the first MPDU in the block for 47 which an acknowledgment is expected. MPDUs in the recipient’s buffer with a sequence control value that 48 precedes the starting sequence control value are called preceding MPDUs. The recipient shall reassemble any 49 complete MSDUs from buffered preceding MPDUs and indicate these to its higher layer. The recipient shall 50 then release any buffers held by preceding MPDUs. The range of the outstanding MPDUs (i.e., the reorder 51 52 buffer) shall begin on an MSDU boundary. The total number of frames that can be sent depends on the total 53 number of MPDUs in all the outstanding MSDUs. The total number of MPDUs in these MSDUs may not 54 exceed the reorder buffer size in the receiver. 55 56 The recipient shall maintain a Block Ack record consisting of originator address, TID, and a record of 57 58 reordering buffer size indexed by the received MPDU sequence control value. This record holds the acknowl- 59 edgment state of the data frames received from the originator. 60 61 If the immediate Block Ack policy is used, the recipient shall respond to a Basic BlockAckReq frame with a 62 Basic BlockAck frame. If the recipient sends the Basic BlockAck frame, the originator updates its own record 63 64 and retries any frames that are not acknowledged in the Basic BlockAck frame, either in another block or in- 65 dividually.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 EDITORIAL NOTE—Note strikeout of a space in the second line below: 2 3 4 If the delayed Block Ack policy is used, the recipient shall respond to a Basic BlockAckReq frame with an 5 ACK frame. The recipient shall then send its Basic Block Ack response in a subsequently obtained TXOP. 6 Once the contents of the Basic BlockAck frame have been prepared, the recipient shall send this frame in the 7 earliest possible TXOP using the highest priority AC. The originator shall respond with an ACK frame upon 8 receipt of the Basic BlockAck frame. If delayed Block Ack policy is used and if the HC is the recipient, then 9 10 the HC may respond with a +CF-Ack frame if the Basic BlockAckReq frame is the final frame of the polled 11 TXOP's frame exchange. If delayed Block Ack policy is used and if the HC is the originator, then the HC may 12 respond with a +CF-Ack frame if the Basic BlockAck frame is the final frame of the TXOP's frame exchange. 13 14 The Basic BlockAck frame contains acknowledgments for the MPDUs of up to 64 previous MSDUs. In the 15 16 Basic BlockAck frame, the STA acknowledges only the MPDUs starting from the starting sequence control 17 until the MPDU with the highest sequence number (modulo 212) that has been received, and the STA shall 18 set bits in the Block Ack bitmap corresponding to all other MPDUs to 0. The status of MPDUs that are con- 19 20 sidered "old" and prior to the sequence number range for which the receiver maintains status shall be reported 21 as successfully received (i.e., the corresponding bit in the bitmap shall be set to 1). The sequence number 22 space is considered divided into two parts, one of which is "old" and one of which is "new" by means of a 23 boundary created by adding half the sequence number range to the current start of receive window (modulo 24 12 25 2 ). If the Basic BlockAck frame indicates that an MPDU was not received correctly, the originator shall 26 retry that MPDU subject to that MPDU's appropriate lifetime limit. 27 28 EDITORIAL NOTE—Note insertion of a space in the first line below. 29 30 31 A typical Block Ack frame exchange sequence using the immediate Block Ack for a single TID is shown in 32 Figure n 9-22. 33 34 Originator Data Block Block Ack 35 Exchange 36 37 Frame-exchange 38 for NAV Protection 39 40 Basic QoS DataQoS DataQoS DataQoS DataQoS

41 BlockAckReq 42 43 44 Recipient 45 46 47 48 49 Ack Policy = Block Ack 50 Basic BlockAck Basic 51 52 53 54 NAV at 55 other STAs 56 57 58 Figure 9-22—A typical Block Ack sequence when immediate policy is used 59 60 61 EDITORIAL NOTE—The changes to Figure 9-23 replace insertion of “Basic” before “BlockAck” and 62 “BlockAckReq”. 63 64 65 A typical Block Ack sequence using the delayed Block Ack is shown in Figure n 9-23.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 2 Originator Data Block Block Ack 3 Exchange 4 5 Frame-exchange 6 7 for NAV Protection ACK 8 Basic 9 Data QoS Data QoS Data QoS Data QoS 10 BlockAckReq 11 NAV due to 12 Recipient recipient 13 14 15 16

17 Ack Policy = Block Ack ACK 18

19 BlockAck Basic 20 21 22 NAV at 23 24 other STAs 25 26 27 Figure 9-23—A typical BlockAck sequence when delayed policy is used 28 29 EDITORIAL NOTE—The changes to Figure 9-22 replace insertion of “Basic” before “BlockAck” and 30 31 “BlockAckReq”. 32 33 The subsequent Basic BlockAckReq Block AckReq request starting sequence number shall be higher than or 34 12 35 equal to the starting sequence number (modulo 2 ) of the immediately preceding Basic BlockAckReq frame 36 for the same TID. 37 38 The originator may continue to transmit MPDUs to the recipient after transmitting the Basic BlockAckReq 39 frame, but before receiving the Basic BlockAck frame (applicable only to delayed Block Ack). The bitmap 40 41 in the Basic BlockAck frame shall include the status of frames received between the start sequence number 42 and the transmission of the Basic BlockAckReq frame. A recipient sending a delayed Basic BlockAck frame 43 may update the bitmap with information on QoS data frames received between the receipt of the Basic Block- 44 AckReq frame and the transmission of the Basic BlockAck frame. 45 46 47 If there is no response (i.e., neither a Basic BlockAck nor an ACK frame) to the Basic BlockAckReq frame, 48 the originator may retransmit the Basic BlockAckReq frame within the current TXOP (if time permits) or 49 within a subsequent TXOP. MSDUs that are sent using the Block Ack mechanism are not subject to retry 50 limits but only to MSDU lifetime. The originator need not set the retry bit for any possible retransmissions of 51 52 the MPDUs. 53 54 The Basic BlockAckReq frame shall be discarded if all MSDUs referenced by this Basic BlockAckReq frame 55 have been discarded from the transmit buffer due to expiry of their lifetime limit. 56 57 58 In order to improve efficiency, originators using the Block Ack facility may send MPDU frames with the Ack 59 Policy subfield in QoS control frames set to Normal Ack if only a few MPDUs are available for transmission. 60 The Block Ack record shall be updated irrespective of the Ack Policy subfield in the QoS data frame for the 61 TID with an active Block Ack. When there are sufficient number of MPDUs, the originator may switch back 62 to the use of Block Ack. The reception of QoS data frames using Normal Ack policy shall not be used by the 63 64 recipient to reset the timer to detect Block Ack timeout (see 11.5.3). This allows the recipient to delete the 65 Block Ack if the originator does not switch back to using Block Ack.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 The frame exchange sequences are provided in 9.12Annex S. 2 3 4 9.10.4 Receive buffer operation 5 6 Change the third to sixth paragraphs of 9.10.4 as follows: 7 8 9 If a BlockAckReq frame is received, all complete MSDUs and A-MSDUs with lower sequence numbers than 10 the starting sequence number contained in the BlockAckReq frame shall be indicated to the MAC client using 11 the MAUNIDATA. indication primitive passed up to the next MAC process as shown in Figure 6-1. Upon 12 arrival of a BlockAckReq frame, the recipient shall indicatepass up the MSDUs and A-MSDUs starting with 13 14 the starting sequence number sequentially until there is an incomplete MSDU or A-MSDU in the buffer. 15 16 If, after an MPDU is received, the receive buffer is full, the complete MSDU or A-MSDU with the earliest 17 sequence number shall be indicated to the MAC client using the MA-UNIDATA.indication primitive passed 18 19 up to the next MAC process. 20 21 12 22 All comparisons of sequence numbers are performed circularly modulo 2 . 23 24 The recipient shall always indicate the reception of pass MSDUs and A-MSDUs up to the next MAC process- 25 to its MAC client in order of increasing sequence number. 26 27 28 Insert the following subclauses (9.10.6 to 9.10.8.3) after 9.10.5: 29 30 9.10.6 Selection of BlockAck and BlockAckReq variants 31 32 33 The Compressed Bitmap subfield of the BA Control field or BAR Control field shall be set to 1 in all Block- 34 Ack and BlockAckReq frames sent from one HT STA to another HT STA, and shall be set to 0 otherwise. 35 36 37 The Multi-TID subfield of the BA Control field shall be set to 1 in all BlockAck frames related to an HT- 38 immediate agreement transmitted inside a PSMP sequence, and shall be set to 0 otherwise. The Multi-TID 39 subfield of the BAR Control field shall be set to 1 in all BlockAckReq frames related to an HT-immediate 40 agreement transmitted inside a PSMP sequence, and shall be set to 0 otherwise. 41 42 43 Where the terms BlockAck and BlockAckReq are used within 9.10.7 and 9.10.8, the appropriate variant ac- 44 cording to this subclause (e.g. Compressed, Multi-TID) is referenced by the generic term. 45 46 47 9.10.7 HT-immediate Block Ack extensions 48 49 9.10.7.1 Introduction to HT-immediate Block Ack extensions 50 51 52 An HT extension to the Block Ack feature (defined in 9.10.1 to 9.10.5), called HT-immediate Block Ack, is 53 defined in 9.10.7.2 to 9.10.7.9. 54 55 56 The HT-immediate extensions simplify immediate Block Ack use with A-MPDUs and reduce recipient re- 57 source requirements. 58 59 60 An HT STA shall support HT-immediate Block Ack in the role of recipient. 61 62 9.10.7.2 HT-immediate Block Ack architecture 63 64 65 The HT-immediate Block Ack rules are explained in terms of the architecture shown in Figure 9-24 and ex-

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 plained in this subclause. 2 3 4 Originator Recipient 5 6 Receive Reordering Buffer Control per TA/TID Transmit Buffer Control 7 (WinStart , WinSize ) 8 per RA/TID B B Scoreboard Context 9 (WinStartO, WinSizeO) 10 Control 11 (WinStartR, WinSizeR) 12 Aggregation control De-aggregation control 13 14 A-MPDU 15 16 BlockAck (BitMap, SSN) 17 18 Figure 9-24—HT-immediate Block Ack architecture 19 20 21 The originator contains a Transmit Buffer Control that uses WinStartO and WinSizeO to submit MPDUs for 22 transmission, and releases transmit buffers upon receiving BlockAck frames from the recipient. 23 24 25 WinStartO is the starting sequence number of the transmit window, and WinSizeO is the number of buffers 26 negotiated in the Block Ack agreement. 27 28 29 The Aggregation control creates A-MPDUs. It may adjust the Ack Policy field of transmitted QoS data 30 frames according to the rules defined in 9.10.7.7 in order to solicit BlockAck responses. 31 32 33 The recipient contains a Receive Reordering Buffer Control per TA/TID, which contains related control state. 34 The receive reordering buffer is responsible for reordering MSDUs or A-MSDUs so that MSDUs or A-MS- 35 DUs are eventually passed up to the next MAC process in order of received sequence number (SN). It main- 36 tains its own state independent of the Scoreboard Context Control to perform this reordering as specified in 37 9.10.7.6. 38 39 40 For each HT-immediate Block Ack agreement, the recipient chooses either full state or partial state operation 41 (this is known only to the recipient). A STA may simultaneously use full state operation for some agreements 42 and partial state operation for other agreements. The Scoreboard Context Control stores an acknowledgement 43 44 bitmap containing the current reception status of MSDUs or A-MSDUs for HT-immediate Block Ack agree- 45 ments. Under full state operation, status is maintained in statically assigned memory. Under partial state op- 46 eration, status is maintained in a cache memory and therefore the status information is subject to cache 47 replacement. This entity provides the bitmap and the value for the Starting Sequence Number (SSN) field to 48 be sent in BlockAck responses to the originator. 49 50 51 The de-aggregation control entity separates frames contained in an A-MPDU. 52 53 54 Each received MPDU is analyzed by the scoreboard context control, as well as by the receive reordering buff- 55 er control. 56 57 58 Each HT-immediate Block Ack agreement is uniquely identified by a tuple of Address 1, Address 2 and TID 59 from the ADDBA response frame that successfully established the HT-immediate Block Ack agreement. The 60 STA that corresponds to Address 1 of the ADDBA response frame is the originator. The STA that corre- 61 sponds to Address 2 of the ADDBA response frame is the recipient. Data MPDUs that contain the same val- 62 ues for Address 1, Address 2 and TID as a successful ADDBA response frame are related with the HT- 63 64 immediate Block Ack agreement that was established by the successful receipt of that ADDBA response 65 frame provided that the HT-immediate Block Ack agreement is still active.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 9.10.7.3 Scoreboard Context Control during full state operation 2 3 For each HT-immediate Block Ack agreement that uses full state operation, a recipient shall maintain a block 4 5 acknowledgement record as defined in 9.10.3. This record includes a bitmap, indexed by sequence number 6 (SN), a 12-bit unsigned integer starting sequence number WinStartR representing the lowest SN position in 7 the bitmap, a variable WinEnd and the maximum Transmission Window size, WinSize , which is set to the 8 R R 9 smaller of 64 and the value of the Buffer Size field of the associated ADDBA response frame that established 10 the Block Ack agreement. WinEndR is defined as the highest SN in the current Transmission Window. A STA 11 implementing full state operation for an HT-immediate Block Ack agreement shall maintain the block ac- 12 knowledgement record for that agreement according to the following rules: 13 14 a) At HT-immediate Block Ack agreement establishment: 15 1) WinStart = SSN from the ADDBA request frame that elicited the ADDBA response frame 16 R 17 that established the HT-immediate Block Ack agreement 18 2) WinEndR = WinStartR + WinSizeR – 1. 19 20 b) For each received data MPDU that is related with a specific full-state operation HT-immediate 21 Block Ack agreement, the block acknowledgement record for that agreement is modified as follows, 22 where SN is the value of the Sequence Number field of the received data MPDU: 23 24 1) If WinStartR SN WinEndR , set to one the bit in position SN within the bitmap 25 11 2) If WinEndR SN WinStartR+2 26 27 i) set to zero the bits corresponding to MPDUs with Sequence Number field values from 28 WinEndR+1 to SN - 1 29 ii) set WinStart = SN - WinSize + 1 30 R R 31 iii) set WinEndR = SN 32 iv) set to one, the bit at position SN in the bitmap 33 11 34 3) If WinStartR+2  SN WinStartR , make no changes to the record 35 NOTE—A later-arriving data MPDU may validly contain a SN that is lower than an earlier-arriving one. 36 This can happen because the transmitter may choose to send data MPDUs in a non-sequential SN order or 37 38 because a previous data MPDU transmission with lower SN is not successful and is being retransmitted. 39 c) For each received BlockAckReq frame that is related with a specific full-state operation HT-imme- 40 diate non-Protected Block Ack agreement, the block acknowledgement record for that agreement is 41 modified as follows, where SSN is the value from the Starting Sequence Number field of the 42 43 received BlockAckReq frame: 44 1) If WinStart  SSN  WinEnd 45 R R 46 i) set WinStartR = SSN 47 ii) set to zero the bits corresponding to MPDUs with Sequence Number field values from 48 WinEnd + 1 through WinStart + WinSize – 1 49 R R R 50 iii) set WinEndR = WinStartR + WinSizeR – 1. 51 11 52 2) If WinEndR SSN WinStartR+2 53 i) set WinStartR = SSN 54 55 ii) set WinEndR = WinStartR + WinSizeR – 1 56 iii) set to zero bits the corresponding to MPDU with Sequence Number field values from Win- 57 StartR to WinEndR 58 11 59 3) If WinStartR+2 SSN WinStartR , make no changes to the record 60 61 9.10.7.4 Scoreboard Context Control during partial state operation 62 63 64 For an HT-immediate Block Ack agreement that uses partial state operation, a recipient shall maintain a tem- 65 porary block acknowledgement record as defined in 9.10.3. This temporary record includes a bitmap, indexed

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 by sequence number (SN), a 12-bit unsigned integer WinStartR (the lowest SN represented in the bitmap), a 2 12-bit unsigned integer WinEnd (the highest SN in the bitmap), the originator address, TID and the maxi- 3 R 4 mum Transmission Window size, WinSizeR, which is set to the smaller of 64 and the value of the Buffer Size 5 field of the associated ADDBA Response frame that established the Block Ack agreement. 6 7 8 During partial state operation of scoreboard context control the recipient retains the current record for an HT- 9 immediate Block Ack agreement at least as long as it receives data from the same originator. If a frame for 10 an HT-immediate Block Ack agreement from a different originator is received, the temporary record may be 11 discarded if the resources it uses are needed to store the temporary record corresponding to the newly arriving 12 frame. 13 14 15 A STA implementing partial state operation for an HT-immediate Block Ack agreement shall maintain the 16 temporary block acknowledgement record for that agreement according to the following rules: 17 18 a) During partial state operation, WinStartR is determined by the Sequence Number field value (SN) of 19 received data MPDUs and by the Starting Sequence Number field value (SSN) of received Block- 20 AckReq frames as described below. 21 22 b) For each received data MPDU that is related with a specific partial-state operation HT-immediate 23 Block Ack agreement, when no temporary record for the agreement related with the received data 24 MPDU exists at the time of receipt of the data MPDU, a temporary block acknowledgement record 25 is created as follows, where SN is the value of the Sequence Number field of the received data 26 MPDU: 27 28 1) WinEndR = SN 29 30 2) WinStartR = WinEndR - WinSizeR + 1 31 3) Create a bitmap of size WinSizeR, with the first bit corresponding to sequence number Win- 32 StartR and the last bit corresponding to sequence number WinEndR, setting all bits in the bitmap 33 to 0 34 35 4) Set to 1 the bit in the position in the bitmap that corresponds to SN 36 37 c) For each received data MPDU that is related with a specific partial-state operation HT-immediate 38 Block Ack agreement, when a temporary record for the agreement related with the received data 39 MPDU exists at the time of receipt of the data MPDU, the temporary block acknowledgement 40 record for that agreement is modified in the same manner as the acknowledgement record for a full- 41 state agreement described in 9.10.7.3. 42 43 d) For each received BlockAckReq frame that is related with a specific partial-state operation HT- 44 immediate non-Protected Block Ack agreement, when no temporary record for the agreement 45 related with the received frame exists at the time of receipt of the frame, a temporary block acknowl- 46 47 edgement record is created as follows, where SSN is the starting value of the Sequence Number field 48 of the received BlockAckReq frame: 49 1) WinStart = SSN 50 R 51 2) WinEndR = WinStartR + WinSizeR – 1 52 3) Create a bitmap of size WinSize , setting all bits in the bitmap to 0 53 R 54 e) For each received BlockAckReq frame that is related with a specific partial-state operation HT- 55 immediate non-Protected Block Ack agreement, when a temporary record for the agreement related 56 with the received frame exists at the time of receipt of the frame, the temporary block acknowledge- 57 58 ment record for that agreement is modified in the same manner as the acknowledgement record for a 59 full-state agreement described in 9.10.7.3. 60 61 9.10.7.5 Generation and transmission of BlockAck by an HT STA 62 63 64 Except when operating within a PSMP exchange, a STA that receives a PPDU that contains a BlockAckReq 65 in which the Address 1 field matches its MAC address during either full-state operation or partial-state oper-

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 ation shall transmit a PPDU containing a BlockAck frame that is separated on the air by a SIFS interval from 2 the PPDU that elicited the BlockAck as a response. A STA that receives an A-MPDU that contains one or 3 more MPDUs in which the Address 1 field matches its MAC address with the ACK Policy field set to Normal 4 5 Ack (i.e., implicit Block Ack request) during either full-state operation or partial-state operation shall transmit 6 a PPDU containing a BlockAck frame that is separated on the air by a SIFS interval from the PPDU that elic- 7 ited the BlockAck as a response. 8 9 10 When responding with a BlockAck frame to either a received BlockAckReq frame or a received A-MPDU 11 with ACK Policy set to Normal Ack (i.e., implicit Block Ack request) during either full-state operation or 12 partial-state operation, any adjustment to the value of WinStartR according to the procedures defined within 13 9.10.7.3 and 9.10.7.4 shall be performed before the generation and transmission of the response BlockAck 14 15 frame. The Starting Sequence Number of the Block Ack Starting Sequence Control field of the BlockAck 16 frame shall be set to any value in the range from (WinEndR – 63) to WinStartR . The values in the recipient's 17 record of status of MPDUs beginning with the MPDU for which the Sequence Number field value is equal to 18 WinStart and ending with the MPDU for which the Sequence Number field value is equal to WinEnd shall 19 R R 20 be included in the bitmap of the BlockAck frame. 21 22 When responding with a BlockAck frame to either a received BlockAckReq frame or a received A-MPDU 23 with ACK Policy set to Normal Ack (i.e., implicit Block Ack request) during either full-state or partial-state 24 25 operation, if the adjusted value of WinStartR is greater than the value of the SSN of the BlockAck frame, with- 26 in the bitmap of the BlockAck frame, the status of MPDUs with sequence numbers that are less than the ad- 27 justed value of WinStartR may be set to any value. 28 29 30 When responding with a BlockAck frame to either a received BlockAckReq frame or a received A-MPDU 31 with ACK Policy set to Normal Ack (i.e., implicit Block Ack request) during either full-state or partial-state 32 operation, if the adjusted value of WinEndR is less than the value of the SSN of the BlockAck frame plus 63, 33 34 within the bitmap of the BlockAck frame, the status of MPDUs with sequence numbers that are greater than 35 the adjusted value of WinEndR shall be reported as unsuccessfully received (i.e., the corresponding bit in the 36 bitmap shall be set to 0). 37 38 39 If a BlockAckReq is received and no matching partial state is available, the recipient shall send a null Block- 40 Ack in which the bitmap is set to all zeros. 41 42 9.10.7.6 Receive Reordering Buffer Control operation 43 44 45 9.10.7.6.1 General 46 47 The behavior described in this subclause, 9.10.7.6.2 and 9.10.7.6.3 applies to a STA that uses either partial 48 49 state operation or full state operation for an HT-immediate Block Ack agreement. 50 51 A receive reordering buffer shall be maintained for each HT-immediate Block Ack agreement. Each receive 52 reordering buffer includes a record comprising: 53 54 — buffered MSDUs or A-MSDUs that have been received, but not yet passed up to the next MAC pro- 55 cess 56 57 —a WinStartB parameter, indicating the value of the Sequence Number field (SN) of the first (in order 58 of ascending sequence number) MSDU or A-MSDU that has not yet been received 59 —a WinEnd parameter, indicating the highest SN expected to be received in the current reception win- 60 B 61 dow 62 —a WinSizeB parameter, indicating the size of the reception window 63 64 65 WinStartB is initialized to the Starting Sequence Number field value (SSN) of the ADDBA request frame that

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 elicited the ADDBA response frame that established the HT-immediate Block Ack agreement. 2 3 4 WinEndB is initialized to WinStartB + WinSizeB – 1, where WinSizeB is set to the smaller of 64 and the value 5 of the Buffer Size field of the ADDBA Response frame that established the Block Ack agreement. 6 7 Any MSDU or A-MSDU that has been passed up to the next MAC process shall be deleted from the receive 8 9 reordering buffer. 10 11 The recipient shall always pass MSDUs or A-MSDUs up to the next MAC process in order of increasing Se- 12 quence Number field value. 13 14 15 9.10.7.6.2 Operation for each received data MPDU 16 17 For each received data MPDU that is related to a specific HT-immediate Block Ack agreement, the receive 18 reordering buffer record is modified as follows, where SN is the value of the Sequence Number field of the 19 20 received MPDU: 21 a) If WinStartB SN WinEndB 22 23 1) Store the received MPDU in the buffer 24 2) Pass MSDUs or A-MSDUs up to the next MAC process that are stored in the buffer in order of 25 increasing value of the Sequence Number field starting with the MSDU or A-MSDU that has 26 27 SN=WinStartB and proceeding sequentially until there is no buffered MSDU or A-MSDU for 28 the next sequential value of the Sequence Number field. 29 3) Set WinStart to the value of the Sequence Number field of the last MSDU or A-MSDU that 30 B 31 was passed up to the next MAC process plus one 32 4) Set WinEndB = WinStartB + WinSizeB – 1 33 34 b) If WinEnd SN WinStart +211 35 B B 36 1) Store the received MPDU in the buffer 37 38 2) set WinEndB = SN 39 3) set WinStart = WinEnd – WinSize + 1 40 B B B 41 4) Any complete MSDUs or A-MSDUs stored in the buffer with Sequence Number field values 42 that are lower than the new value of WinStartB are passed up to the next MAC process in order 43 of increasing Sequence Number field value. Gaps may exist in the Sequence Number field val- 44 ues of the MSDUs or A-MSDUs that are passed up to the next MAC process. 45 46 5) MSDUs or A-MSDUs stored in the buffer shall be passed up to the next MAC process in order 47 of increasing value of the Sequence Number field starting with WinStartB and proceeding 48 sequentially until there is no buffered MSDU or A-MSDU for the next sequential Sequence 49 50 Number field value 51 6) Set WinStartB to the Sequence Number field value of the last MSDU or A-MSDU that was 52 passed up to the next MAC process plus one 53 54 7) Set WinEndB = WinStartB + WinSizeB – 1 55 11 56 c) If WinStartB+2  SN WinStartB , discard the MPDU (do not store the MPDU in the buffer, do 57 58 not pass the MSDU or A-MSDU up to the next MAC process) 59 60 9.10.7.6.3 Operation for each received BlockAckReq 61 62 For each received BlockAckReq frame that is related with a specific HT-immediate Block Ack agreement, 63 64 the receive reordering buffer record is modified as follows, where SSN is the Starting Sequence Number field 65 value of the received BlockAckReq frame:

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

11 1 a) If WinStartB SSN WinStartB+2 2 3 1) For a non-Protected Block Ack agreement set WinStartB = SSN. See 9.10.9 for a Protected 4 Block Ack agreement. 5 6 2) Set WinEndB = WinStartB + WinSizeB - 1 7 3) Any complete MSDUs or A-MSDUs stored in the buffer with Sequence Number field values 8 that are lower than the new value of WinStart shall be passed up to the next MAC process in 9 B 10 order of increasing Sequence Number field value. Gaps may exist in the Sequence Number 11 field values of the MSDUs or A-MSDUs that are passed up to the next MAC process. 12 13 4) MSDUs or A-MSDUs stored in the buffer shall be passed up to the next MAC process in order 14 of increasing Sequence Number field value starting with SN=WinStartB and proceeding 15 sequentially until there is no buffered MSDU or A-MSDU for the next sequential Sequence 16 Number field value. 17 18 5) Set WinStartB to the Sequence Number field value (SN) of the last MSDU or A-MSDU that 19 was passed up to the next MAC process plus one 20 21 6) Set WinEndB = WinStartB + WinSizeB – 1 22 11 23 b) If WinStartB+2  SSN WinStartB , do not make any changes to the receive reordering buffer 24 record 25 26 27 9.10.7.7 Originator’s behavior 28 29 A STA may send a block of data in a single A-MPDU where each data MPDU has its Ack Policy field set to 30 31 Normal Ack. The originator expects to receive a BlockAck response immediately following the A-MPDU if 32 at least one data frame is received without error. 33 34 Alternatively, the originator may send an A-MPDU where each data MPDU has its Ack Policy field set to 35 36 Block Ack under an HT-immediate Block Ack agreement if it does not require a BlockAck response imme- 37 diately following the A-MPDU. 38 39 If the BlockAck is lost, the originator may transmit a BlockAckReq to solicit an immediate BlockAck or it 40 41 may retransmit the data frames. 42 43 A BlockAckReq sent using HT-delayed operation may be transmitted within an A-MPDU provided that its 44 BAR Ack Policy field is set to No Acknowledgement. 45 46 47 The originator may transmit QoS data MPDUs with a TID matching an established Block Ack agreement in 48 any order provided that their sequence numbers lie within the current transmission window. The originator 49 may transmit an MPDU with an SN that is beyond the current transmission window (SN > WinStart + Win- 50 O 51 SizeO - 1), in which case the originator’s transmission window (and the recipient’s window) will be moved 52 forward. The originator should not transmit MPDUs that are lower than (i.e., SN < WinStartO) the current 53 54 transmission window. 55 56 The originator shall not retransmit an MPDU after that MPDU’s appropriate lifetime limit. 57 58 59 The originator may send a BlockAckReq for non-Protected Block Ack agreement or a Robust Management 60 ADDBA frame for Protected Block Ack agreement, when a data MPDU that was previously transmitted with- 61 in an A-MPDU that had the Ack Policy field set to Normal Ack is discarded due to exhausted MSDU Life- 62 time. The purpose of this BlockAckReq is to shift the recipient’s WinStart value past the hole in the SN space 63 B 64 that is created by the discarded data MPDU and thereby to allow the earliest possible passing of buffered 65 frames up to the next MAC process.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 9.10.7.8 Maintaining BlockAck state at the originator 2 3 If an originator successfully receives a BlockAck in response to a BlockAckReq, the originator shall maintain 4 5 BlockAck state as defined in 9.10.3. 6 7 If the originator receives a BlockAck in response to HT-immediate BlockAckReq, it shall in addition: 8 9 — Not update the status of MPDUs with Sequence Number field values between WinStartO and SSN of 10 the received BlockAck, and 11 NOTE 1—It is possible for the Starting Sequence Number field value (SSN) of the received BlockAck to be 12 greater than WinStartO because of the failed reception of a non-zero number of MPDUs beginning with the 13 MPDU with Sequence Number field value equal to WinStartO at a recipient that is using partial state operation. 14 15 — Not update the status of MPDUs that have been already positively acknowledged. 16 NOTE 2—This second rule means that if an originator successfully delivered an MPDU and received the Block- 17 Ack in one TXOP and then receives a BlockAck in a later TXOP in which the MPDU is not indicated as suc- 18 cessfully received (because the partial state has been reset), the originator knows not to retry the MPDU. 19 20 21 9.10.7.9 Originator’s support of recipient’s partial state 22 23 A recipient may choose to employ either full state operation or partial state operation for each individual 24 Block Ack agreement. An originator is unaware of the recipient’s choice of full state or partial state operation. 25 NOTE—The originator can solicit a BlockAck as the last activity associated with that Block Ack agreement in the cur- 26 rent TXOP to reduce the probability that data is unnecessarily retransmitted due to loss of partial state. 27 28 29 9.10.8 HT-delayed Block Ack extensions 30 31 9.10.8.1 Introduction to HT-delayed Block Ack extensions 32 33 34 Subclauses 9.10.8.2 and 9.10.8.3 define an HT extension to the Block Ack feature to support operation on 35 delayed Block Ack agreements established between HT STAs. Other than the exceptions noted in 9.10.8.1 to 36 9.10.8.3, the operation of HT Delayed Block Ack is the same as is described in 9.10.7. 37 38 The HT-delayed extensions simplify the use of delayed Block Ack in an A-MPDU and reduce resource re- 39 40 quirements. 41 42 9.10.8.2 HT-delayed Block Ack negotiation 43 44 HT-delayed Block Ack is an optional feature. An HT STA declares support for HT-delayed Block Ack in the 45 46 HT Capabilities element. 47 48 An HT STA shall not attempt to create a BlockAck agreement under HT-delayed Block Ack Policy unless 49 the recipient HT STA declares support for this feature. 50 51 52 9.10.8.3 Operation of HT-delayed Block Ack 53 54 The BlockAck response to an HT-delayed BlockAckReq is transmitted after an unspecified delay, and when 55 the recipient of the BlockAckReq next has the opportunity to transmit. This response may be transmitted in 56 a later TXOP owned by the recipient of the BlockAckReq or in the current or a later TXOP owned by the 57 58 sender of the BlockAckReq using the reverse direction feature (see 9.15). 59 60 The No Ack feature of the BlockAckReq and BlockAck frame may be used under an HT-delayed Block Ack 61 agreement. 62 63 64 A BlockAckReq or BlockAck frame containing a BAR Ack Policy or BA Ack Policy field set to 1 indicates 65 that no acknowledgement is expected to these control frames. Otherwise, an Ack MPDU response is expected

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 after a SIFS. 2 3 4 Setting of the BAR Ack Policy and BA Ack Policy fields may be performed independently for BlockAckReq 5 and BlockAck frames associated with the same HT-delayed Block Ack agreement. All four combinations of 6 the values of these fields are valid. 7 8 9 Setting of the BAR Ack Policy and BA Ack Policy fields is dynamic, and can change from PPDU to PPDU. 10 11 12 9.10.9 Protected Block Ack Agreement 13 14 15 A STA indicates support for Protected Block Ack by setting the MFPC, MFPR and PBAC RSN Capabilities 16 subfields to 1. Such a STA is a PBAC STA, otherwise, the STA is a non-PBAC STA. A Block Ack agreement 17 18 that is successfully negotiated between two PBAC STAs is a Protected Block Ack agreement. A Block Ack 19 agreement that is successfully negotiated between two STAs when either or both of the STAs is not a PBAC 20 STA is a non-Protected Block Ack agreement. 21 22 23 A PBAC STA may choose to negotiate a Block Ack agreement with a non-PBAC STA if 24 dot11RSNAPBACRequired is set to 0; otherwise it shall only negotiate a Block Ack agreement with other 25 PBAC STAs. If a PBAC STA is communicating with a non-PBAC STA, it shall follow the rules for an non- 26 27 Protected Block Ack agreement. 28 29 30 A STA that has successfully negotiated a Protected Block Ack agreement shall obey the following rule as a 31 Block Ack originator in addition to rules specified in 9.10.7.7 and 9.10.7.8: 32 33 — to change the value of WinStartB at the receiver, the STA shall use a Robust Management ADDBA 34 request action frame. 35 36 37 A STA that has successfully negotiated a Protected Block Ack agreement shall obey the following rules as a 38 Block Ack recipient in addition to rules specified in 9.10.7.3 to 9.10.7.6: 39 40 — The recipient STA shall respond to a BlockAckReq from a PBAC enabled originator with an imme- 41 diate BlockAck. The Block Ack Starting Sequence Control field value shall be ignored for the pur- 42 43 poses of updating the value of WinStartB. The Block Ack Starting Sequence Control field value may 44 be utilized for the purposes of updating the value of WinStartR. If the Block Ack Starting Sequence 45 Control field value is greater than WinEndB or less than WinStartB, dot11PBACErrors shall be incre- 46 mented by 1. 47 48 — Upon receipt of a valid Robust Management ADDBA request action frame for an established Pro- 49 tected Block Ack agreement whose TID and transmitter address are the same as those of the Block 50 51 Ack agreement, the STA shall update its WinStartR and WinStartB values based on the Starting 52 Sequence number in the Robust Management ADDBA request frame according to the procedures 53 outlined for reception of BlockAckReq frames in 9.10.7.3, 9.10.7.4, 9.10.7.6.1 and 9.10.7.6.3, while 54 treating the Starting Sequence number as though it were the SSN of a received BlockAckReq frame. 55 Values in other fields of the ADDBA frame shall be ignored. 56 57 58 59 9.12 Frame exchange sequences 60 61 62 Change 9.12 by moving it to informative Annex S. 63 64 65 EDITORIAL NOTE—Other changes to 9.12 are shown in that Annex.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Change the heading of 9.13 as follows: 2 3 4 9.13 Protection mechanisms for non-ERP receivers 5 6 7 Insert the following subclause (9.13.1) immediately following the heading 9.13: 8 9 9.13.1 Introduction 10 11 These protection mechanisms ensure that a STA that is a potential interferer defers any transmission for a 12 13 known period of time. These mechanisms are used to ensure that non-ERP STAs do not interfere with frame 14 exchanges using ERP PPDUs between ERP STAs and that non-HT STAs do not interfere with frame ex- 15 changes using HT PPDUs between HT STAs, thereby allowing non-ERP and/or non-HT STAs to coexist 16 with ERP and/or HT STAs. 17 18 19 Insert the following heading (9.13.2) immediately after the new 9.13.1: 20 21 9.13.2 Protection mechanism for non-ERP receivers 22 23 EDITORIAL NOTE—The editing instructions given above result in the original contents of 9.13 24 25 appearing after this heading. 26 27 Insert the following subclauses (9.13.3 to 9.21.4) after the new 9.13.2 : 28 29 9.13.3 Protection mechanisms for transmissions of HT PPDUs 30 31 32 9.13.3.1 General 33 34 Transmissions of HT PPDUs, referred to as HT transmissions, are protected if there are other STAs present 35 that cannot interpret HT transmissions correctly. The fields HT Protection and Non-greenfield HT STAs 36 37 Present in the HT Operation element within Beacon and Probe Response frames are used to indicate the pro- 38 tection requirements for HT transmissions. 39 40 The HT Protection field may be set to no protection mode only if: 41 42 — All STAs detected (by any means) in the primary or the secondary channel are HT STAs, and 43 — All STAs that are known by the transmitting STA to be a member of this BSS are either: 44 45 — 20/40 MHz HT STAs in a 20/40 MHz BSS, or 46 — 20 MHz HT STAs in a 20 MHz BSS. 47 48 49 The HT Protection field may be set to non-member protection mode only if: 50 — A non-HT STA is detected (by any means) in either the primary or the secondary channel or in both 51 the primary and secondary channels, that is not known by the transmitting STA to be a member of 52 53 this BSS, and 54 — All STAs that are known by the transmitting STA to be a member of this BSS are HT STAs. 55 56 57 The HT Protection field may be set to 20 MHz protection mode only if: 58 — All STAs detected (by any means) in the primary and all STAs detected (by any means) in the sec- 59 ondary channel are HT STAs and all STAs that are members of this BSS are HT STAs, and 60 61 — This BSS is a 20/40 MHz BSS, and 62 — There is at least one 20 MHz HT STA associated with this BSS. 63 64 65 The HT Protection field is set to non-HT mixed mode otherwise.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 NOTE —the rules stated above allow an HT AP to select non-HT mixed mode at any time. 2 3 In an IBSS, the HT Protection field is reserved, but an HT STA shall protect HT transmissions as though the 4 HT Protection field were set to non-HT mixed mode. A STA that is a member of an IBSS shall protect HT- 5 6 greenfield format PPDUs and RIFS sequences, adhering to the same requirements as described in the column 7 of Table 9-6 labeled "Use_Protection = 0 or ERP information element is not present (HT Protection field set 8 to non-HT mixed mode)". 9 10 In an IBSS, the RIFS Mode field of the HT Operation element is also reserved, but an HT STA shall operate 11 12 as though this field were set to 1. 13 14 During the 40 MHz phase of PCO operation, a PCO active STA may act as though the HT Protection field 15 were set to no protection mode, regardless of the actual value of the HT Protection field transmitted by the AP. 16 17 18 When the HT Protection field is set to no protection mode or 20 MHz protection mode and the Non-greenfield 19 HT STAs Present field is set to 0, no protection is required since all HT STAs in the BSS are capable of de- 20 coding HT-mixed format and HT-greenfield format transmissions. 21 22 When the HT Protection field is set to no protection mode or 20 MHz protection mode and the Non-greenfield 23 24 HT STAs Present field is set to 1, HT transmissions that use the HT-greenfield format shall be protected. This 25 protection may be established by transmitting a PPDU with the TXVECTOR FORMAT parameter set to 26 HT_MF or any of the methods described in Table 9-7. 27 28 When the HT Protection field is set to non-member protection mode and the Use_Protection field in the ERP 29 30 Information element is set to 0, HT transmissions should be protected. When the HT Protection field is set to 31 non-member protection mode, the Use_Protection field in the ERP Information element is set to 0 and the 32 Non-greenfield HT STAs Present field is set to 1, HT transmissions using HT-greenfield format shall be pro- 33 tected. When the HT Protection field is set to non-member protection mode and the Use_Protection field in 34 the ERP Information element is set to 1, HT transmissions shall be protected according to the requirements 35 36 described in Table 9-6 37 38 When the HT Protection field is set to non-HT mixed mode, HT transmissions shall be protected. The type 39 of protection required depends on the type of transmission as well as the type of the non-HT STAs that are 40 present in the BSS. Protection requirements that apply when the HT Protection field is set to non-HT mixed 41 42 mode are described in Table 9-6. 43 44 If the transmission requires protection and the Use_Protection field within the ERP Information element is 45 set to 0 or the ERP Information element is not present in the Beacon, HT transmissions shall be protected 46 using one of the mechanisms identified in Table 9-7. 47 48 NOTE—Rules for rate selection for the HT protection mechanisms listed in Table 9-7 are described in 9.6. 49 50 If the HT Protection field is set to no protection mode and the Secondary Channel Offset field is set to SCA 51 or SCB, a STA may transmit a 40 MHz HT PPDU (TXVECTOR parameter CH_BANDWIDTH set to 52 HT_CBW40) to initiate a TXOP provided that the restrictions specified in 9.6 are obeyed. When the HT Pro- 53 tection field is not set to no protection mode or the Secondary Channel Offset field is set to SCN, a STA shall 54 55 not transmit a 40 MHz HT PPDU (TXVECTOR parameter CH_BANDWIDTH set to HT_CBW40) to initiate 56 a TXOP. 57 58 9.13.3.2 Protection rules for HT STA operating a direct link 59 60 61 An HT STA operating a direct link with another HT STA in a non-HT BSS shall operate according to the 62 rules found in 9.13 as though the following fields have the settings indicated: 63 a) the RIFS mode field of the HT Operation element set to 1 64 65 b) the HT Protection field set to non-HT mixed mode

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table 9-6—Protection requirements for HT Protection field values non-member protection 2 mode and non-HT mixed mode 3 4 5 Condition Requirements 6 7 Use_Protection = 0 or ERP information element is The protection requirements for HT transmissions using HT- 8 not present greenfield format are specified in 9.13.3.1. 9 (HT Protection field set to non-HT mixed mode) 10 The protection requirements for HT transmissions using 11 RIFS within the HT transmission burst are specified in 12 9.13.3.3. 13 14 The protection mechanism for other transmissions not 15 already described above is based on one of the sequences 16 defined in Table 9-7. 17 18 Use_Protection = 1 All HT transmissions shall be protected using mechanisms as 19 (HT Protection field set to non-member protection described in 9.13.2. 20 mode or non-HT mixed mode) The frames that are used for providing the protection shall be 21 sent at a Clause 15 or Clause 18 rate. 22 23 24 25 Table 9-7—Applicable HT protection mechanisms 26 27 28 HT protection mechanism 29 30 Control frames such as RTS/CTS or CTS-to-self prior to the HT transmissions: 31 a) 20 MHz transmissions use the rates defined in Clause 17 or Clause 19 32 b) 40 MHz transmissions use non-HT duplicate frames defined in Clause 20. 33 34 Transmit an initial frame within a non-HT PPDU that requires a response frame. The 35 remaining TXOP following the first PPDU exchange may contain PPDUs using HT- 36 greenfield format and/or separated by RIFS. 37 38 L-SIG TXOP protection 39 Using a PPDU with the TXVECTOR FORMAT parameter set to HT_MF, transmit first 40 a PPDU that requires a response that is sent using a non-HT PPDU. The remaining 41 TXOP following the first PPDU exchange may contain HT-greenfield format and/or 42 RIFS sequences. 43 44 45 46 c) the Non-Greenfield HT STAs present field set to 1 47 48 d) the OBSS Non-HT STAs present field set to 1 49 50 e) the L-SIG TXOP Full Support field set to 0 51 f) the PCO Active field set to 0 52 53 g) the Basic MCS Set field set to all zeros 54 55 56 9.13.3.3 RIFS protection 57 58 59 If the HT Protection field is set to non-member protection mode or non-HT mixed mode, the AP may set the 60 RIFS Mode field to 0 according to implementation-specific criteria (i.e., such as to protect overlapping non- 61 HT BSSs in the primary or secondary channels). 62 63 64 If the HT Protection field is not set to non-member protection mode and it is not set to non-HT mixed mode, 65 the RIFS Mode field shall be set to 1.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 If the RIFS Mode field of an AP’s HT Operation element is set to 1: 2 3 a) A STA that is associated with the AP may protect RIFS sequences when the HT Protection field of 4 the HT Operation element transmitted by the AP is set to non-member protection mode. 5 6 b) A STA that is associated with the AP shall protect RIFS sequences when the HT Protection field of 7 the HT Operation element transmitted by the AP is set to non-HT mixed mode. 8 9 10 A STA shall not transmit PPDUs separated by a RIFS unless the RIFS Mode field of the HT Operation ele- 11 ment is set to 1. 12 13 14 9.13.3.4 Use of OBSS Non-HT STAs Present field 15 16 17 The OBSS Non-HT STAs Present field allows HT APs to report the presence of non-HT STAs that are not 18 members of its BSS in the primary channel, the secondary channel, or in both primary and secondary chan- 19 nels. 20 21 22 A second HT AP that detects a first HT AP’s Beacon frame with the OBSS Non-HT STAs Present field set 23 to 1 may cause HT-greenfield format and RIFS sequence transmissions of the second AP’s BSS to be pro- 24 tected by setting the HT Protection field of its HT Operation element to non-HT mixed mode. If the 25 NonERP_Present field is set to 1 in the first AP’s Beacon frame, the Use_Protection field may also be set to 26 27 1 by the second AP. 28 29 An HT STA may also scan for the presence of non-HT devices either autonomously or, for example, after 30 the STA’s AP transmits an HT Operation element with the HT Protection field set to non-member protection 31 32 mode. Non-HT devices can be detected as follows : 33 34 — reception of a management frame that does not carry an HT Capabilities element and the frame is 35 required to carry this element when transmitted by an HT STA, or 36 37 — reception of a Beacon containing an HT Operation element with the OBSS Non-HT STAs Present 38 field set to 1. 39 40 41 When non-HT devices are detected, the STA may enable protection of its HT-greenfield format and RIFS 42 sequence transmissions. 43 NOTE—If a non-HT device is detected and the STA determines that its HT-greenfield format or RIFS sequence trans- 44 missions are affecting the operation of the non-HT device, then the STA can enable protection of its HT-greenfield for- 45 mat and RIFS sequence transmissions. 46 47 48 See also 11.9.7.3, which defines rules for the OBSS Non-HT STAs Present field related to HT-greenfield 49 transmissions in certain regulatory classes. 50 51 52 9.13.4 L_LENGTH and L_DATARATE parameter values for HT-mixed format PPDUs 53 54 55 L_LENGTH and L_DATARATE determine the duration that non-HT STAs will not transmit, equal to the 56 remaining duration of the HT PPDU or the L-SIG Duration when L-SIG TXOP protection is used as defined 57 in 9.13.5, following the non-HT portion of the preamble of the HT-mixed format PPDU. 58 59 60 The L_DATARATE parameter of the TXVECTOR shall be set to the value 6 Mb/s. 61 62 A STA that is transmitting a PPDU with the FORMAT parameter of the TXVECTOR set to HT_MF, and that 63 64 is not operating by the L-SIG TXOP protection rules described in 9.13.5 shall set the value of the L_LENGTH 65 parameter to the value (in units of octets) given by Equation (9-1) :

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 TXTIME– Signal Extension – aPreambleLength+ aPLCPHeaderLength 2 L_LENGTH = ------(9-1) 3 aSymbolLength 4 aPLCPServiceLength+ aPLCPConvolutionalTailLength  NOPS– ------5 8 6 7 where 8 9 10 x denotes the smallest integer greater than or equal to x 11 12 TXTIME is the duration (µs) of the HT PPDU defined in 10.4.6 13 14 Signal Extension is 0 µs when TXVECTOR parameter NO_SIG_EXTN is TRUE, and is the 15 duration of signal extension as defined by aSignalExtension in Table 20-4 of 16 20.4.4 when TXVECTOR parameter NO_SIG_EXTN is FALSE 17 18 aSymbolLength is the duration of a symbol (µs), defined in 10.4.3 19 20 (aPreambleLength + aPLCPHeaderLength) is the duration (µs) of the non-HT PLCP preamble and 21 signal field defined in 10.4.3 22 23 NOPS is the number of octets transmitted during a period of aSymbolLength at the 24 rate specified by L_DATARATE 25 26 aPLCPServiceLength is the number of bits in the PLCP SERVICE field, defined in 10.4.3 27 (PLME-CHARACTERISTICS.confirm) 28 29 aPLCPConvolutionalTailLength is the number of bits in the convolutional code tail bit sequence, defined 30 in 10.4.3 (PLME-CHARACTERISTICS.confirm) 31 32 NOTE 1—The last term of the L_LENGTH definition corrects for the fact that non-HT STAs add the length of the Ser- 33 vice field and tail bits (assuming a single convolutional encoder) to the value communicated by the L_LENGTH field. 34 TXTIME– Signal Extension – 20 NOTE 2—For a Clause 20 PHY, this simplifies to L_LENGTH = ------ 3 – 3 . 35 4 36 37 A STA that is operating under L-SIG TXOP protection shall set the L_LENGTH parameter according to rules 38 described in 9.13.5. 39 40 A STA shall not transmit a PPDU with the FORMAT parameter set to HT_MF in TXVECTOR if the corre- 41 42 sponding L_LENGTH value calculated with Equation (9-1) exceeds 4095 octets. 43 NOTE 3—The transmission of frames with L_LENGTH above 2340 octets can be accompanied by a protection mecha- 44 nism (e.g., RTS/CTS or CTS-to-self protection) if it is determined that the use of L_LENGTH fails to effectively sup- 45 press non-HT transmissions. How this is determined is outside the scope of this standard. 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 9.13.5 L-SIG TXOP protection 2 3 4 9.13.5.1 General rules 5 6 Figure 9-25 illustrates the basic concept of L-SIG TXOP Protection. The terms used in this figure are defined 7 below and in 20.3.2. 8 9 10 aPreambleLength + 11 aPLCPHeaderLength L-SIG Duration = (L_LENGTH / L_DATARATE) + Signal Extension 12 13 SIG L-STF L-LTF L-SIG HT-SIG HT-STF HT-LTF(s) DATA 14 EXT 15 - L_DATARATE - MCS 16 - L_LENGTH - LENGTH SIG Signal Extension ACK 17 EXT 18 19 Figure 9-25—Basic Concept of L-SIG TXOP Protection 20 21 22 The AP determines whether all HT STAs associated with its BSS support L-SIG TXOP Protection and indi- 23 cates this in the L-SIG TXOP Protection Full Support field of its HT Operation element. This field shall not 24 be set to 1 unless the L-SIG TXOP Protection field is set to 1 by all HT STAs in the BSS. 25 26 27 Support for L-SIG TXOP protection at an intended recipient can be determined through examination of its 28 HT Capability element. 29 30 In an IBSS, the L-SIG TXOP Protection Full Support field of the HT Operation element is reserved but HT 31 32 STAs shall operate as though the field were set to 0. 33 34 A STA shall not transmit a frame using L-SIG TXOP Protection directed to a recipient that does not support 35 L-SIG TXOP Protection. 36 37 38 A STA that transmits an L-SIG TXOP Protected frame should use an MCS from the BasicMCSSet for the 39 transmission of that frame if: 40 41 — the frame initiates a TXOP in an IBSS, or 42 — the L-SIG TXOP Protection Full Support field is set to zero by its AP. 43 44 45 Under L-SIG TXOP Protection operation, the L-SIG field with an HT-mixed format PHY preamble repre- 46 sents a duration value equivalent (except in the case of the initial frame that establishes the TXOP, as de- 47 scribed below) to the sum of: 48 49 a) the value of Duration/ID field contained in the MAC header, and 50 b) the duration remaining in the current packet after the L-SIG, which is equal to the duration of the 51 52 current packet less (aPreambleLength + aPLCPHeaderLength). 53 54 A duration value determined from the L_DATARATE and L_LENGTH parameters of the TXVECTOR or 55 RXVECTOR rounded up to a multiple of aSymbolLength that is not equal to the remaining duration of the 56 frame is called an L-SIG Duration. The TXVECTOR L_LENGTH (defined in 20.2.2), when L-SIG TXOP 57 58 Protection is used, shall contain the value (in units of octets) given by Equation (9-2): 59 60 61 L-SIG Duration– Signal Extension L_LENGTH = ------ NOPS 62 aSymbolLength (9-2) 63 64 – ------aPLCPServiceLength+ aPLCPConvolutionalTailLength------65 8

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 where 2 3 denotes the lowest integer greater than or equal to 4 x x 5 6 Signal Extension is defined in 9.13.4 7 aSymbolLength is the duration of symbol, defined in 10.4.3 8 9 N is the number of octets transmitted during a period of aSymbolLength at 10 OPS 11 the rate specified by L_DATARATE 12 13 aPLCPServiceLength is the number of bits in the PLCP SERVICE field, defined in 10.4.3 14 (PLME-CHARACTERISTICS.confirm) 15 16 aPLCPConvolutionalTailLength is the number of bits in the convolutional code tail bit sequence, defined 17 in 10.4.3 (PLME-CHARACTERISTICS.confirm) 18 19 durations are expressed in units of µs 20 L-SIG Duration– Signal Extension 21 NOTE—For a Clause 20 PHY, this simplifies to L_LENGTH = ------ 3 – 3 . 22 4 23 24 Non-HT STAs are not able to receive any PPDUs that start during the L-SIG duration. Therefore, no frame 25 26 shall be transmitted to a non-HT STA during an L-SIG protected TXOP. 27 28 See also 9.2.5.4, which describes a rule for resetting a NAV value that was set by an L-SIG TXOP protected 29 frame. 30 31 32 9.13.5.2 L-SIG TXOP protection rules at the TXOP holder 33 34 Figure 9-26 illustrates an example of how L-SIG Durations are set when using L-SIG TXOP Protection. 35 36 37 38 MAC Duration 39 40 MAC Duration 41 42 RTS DATA CF_End L-SIG L-SIG L-LTF L-LTF 43 L-STF L-STF 44 L-SIG Duration L-SIG Duration 45 46 MAC Duration 47 CTS BA L-SIG L-SIG L-LTF L-LTF 48 L-STF L-SIG Duration L-STF 49 50 51 52 Figure 9-26—Example of L-SIG Duration Setting 53 54 55 An L-SIG TXOP protected sequence shall start with one of the following: 56 — an initial handshake, which is the exchange of two frames (each inside an HT-mixed format PPDU) 57 that establish protection (e.g., RTS/CTS); or 58 59 — an initial frame that establishes protection but generates no response (e.g., a CTS to self); 60 provided that this initial sequence is also valid for the start of a TXOP. The term L-SIG TXOP protected se- 61 62 quence includes these initial frames and any subsequent frames transmitted within the protected duration. 63 64 Under L-SIG TXOP Protection operation, when the initial PPDU that establishes protection requires a 65 response, the L-SIG Duration of the initial PPDU shall be:

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 L-SIG Duration = T – aPreambleLength+ aPLCPHeaderLength ++SIFS T 2 Init_PPDU Res_PPDU 3 4 where 5 T is the length in time (µs) of the entire initial PPDU 6 Init_PPDU 7 8 TRes_PPDU is the length in time (µs) of the expected response PPDU 9 10 aPreambleLength+ aPLCPHeaderLength is the length in time (µs) of the non-HT PCLP header 11 defined in 10.4.3 12 13 14 When the initial PPDU that establishes protection requires no response, the L-SIG Duration shall contain a 15 value: 16 17 L-SIG Duration = T + T – aPreambleLength+ aPLCPHeaderLength 18 Init_MACDur Init_PPDU 19 20 where 21 22 TInit_MACDur is the Duration/ID value carried in the MAC Header of the initial PPDU 23 24 25 An HT STA using L-SIG TXOP protection should use an accurate prediction of the TXOP duration inside 26 the Duration/ID field of the MAC header to avoid inefficient use of the channel capability. 27 28 The L-SIG duration of the initial frame shall allow for the longest possible duration of the response frame 29 30 (i.e., taking into account wrapped +HTC in the case of control response frames). If the actual duration of the 31 response frame is less than this allowed duration, the TXOP holder shall delay transmission of the third PPDU 32 in the L-SIG TXOP protected sequence until a SIFS after this L-SIG duration expires. 33 NOTE—This ensures that a non-HT STA sees a SIFS interval between the end of the first PPDU and the start of the 34 third PPDU. 35 36 If the initial frame handshake succeeds (i.e., upon reception of a response frame with L-SIG TXOP Protection 37 38 addressed to the TXOP holder), all HT-mixed format PPDUs transmitted inside an L-SIG TXOP Protection 39 protected TXOP shall contain an L-SIG Duration that extends to the endpoint indicated by the MAC Dura- 40 tion/ID field. The first PPDU transmitted after a successful initial handshake (i.e., upon reception of a re- 41 sponse frame with L-SIG TXOP Protection addressed to the TXOP holder), shall have the TXVECTOR 42 FORMAT parameter set to HT_MF. 43 44 NOTE—The requirement to use HT_MF for the third PPDU arises as follows. A third-party STA receives the first 45 PPDU, but cannot receive any MPDU correctly from it. It sets its NAV based on the L-SIG duration. The STA does not 46 receive the second PPDU. It is necessary for the STA to be able to determine either an L-SIG duration or MAC duration 47 value from the third PPDU in order to protect the remaining time in the TXOP. This is enabled by sending the third 48 PPDU using HT-mixed format, containing an L-SIG duration as shown in Figure 9-26. 49 50 The TXOP holder should transmit a CF_End frame starting a SIFS after the L-SIG TXOP protected period. 51 This enables STAs to terminate the EIFS procedure to avoid potential unfairness or a capture effect. 52 NOTE—This is not an instance of TXOP truncation, because it is not transmitted to reset the NAV. 53 54 55 9.13.5.3 L-SIG TXOP protection rules at the TXOP responder 56 57 On receiving a PPDU containing an L-SIG Duration addressed to itself, a TXOP responder that set the L-SIG 58 TXOP Protection Support field to 1 on association shall generate an L-SIG TXOP Protection response frame 59 with the L-SIG Duration equivalent to: 60 61 62 L-SIG Duration = TMACDur –SIFS –  aPreambleLength+ aPLCPHeaderLength 63 64 65 where

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 T is the Duration/ID value carried in the MAC Header of frame(s) received in the PPDU that 2 MACDur 3 generated the response 4 5 A STA shall not transmit a response frame containing an L-SIG Duration unless it is in response to a frame 6 that also contained an L-SIG duration. 7 8 9 9.13.5.4 L-SIG TXOP protection NAV update rule 10 11 An HT STA that set the L-SIG TXOP Protection Support field to 1 on association that receives a PHY-RX- 12 START.indication with RXVECTOR parameter FORMAT set to HT_MF and LSIGVALID set to TRUE, 13 14 and that receives no valid MPDU from which a Duration/ID value can be determined shall, when the PHY- 15 RXEND.indication is received, update its NAV to a value equal to: 16 17 18 L-SIG duration–  TXTIME–  aPreambleLength+ aPLCPHeaderLength 19 20 where 21 TXTIME is the time required to send the entire PPDU. 22 23 Insert the following subclauses (9.15 to 9.21.5) after 9.14.2: 24 25 26 27 9.15 Reverse Direction (RD) protocol 28 29 9.15.1 The RD exchange sequence 30 31 An RD exchange sequence comprises the following: 32 33 a) The transmission of a PPDU by a TXOP holder containing an RDG (the “RDG PPDU”), which is 34 indicated by the PPDU containing one or more +HTC MPDUs in which the RDG/More PPDU field 35 is set to 1. The STA that transmits this PPDU is known as the RD initiator. The rules for an RD ini- 36 37 tiator apply only during a single RD exchange sequence, i.e., after the transmission of an RDG 38 PPDU and up to the end of the last PPDU in the RD exchange sequence. 39 b) The transmission of one or more PPDUs (the “RD response burst”) by the STA addressed in the 40 41 MPDUs of the RDG PPDU. The first (or only) PPDU of the RD response burst contains at most one 42 immediate BlockAck or ACK response frame. The last (or only) PPDU of the RD response burst 43 contains any MPDUs requiring an immediate BlockAck or ACK response. The STA that transmits 44 the RD response burst is known as the RD responder. The rules for an RD responder apply only dur- 45 ing a single RD exchange sequence, i.e., following the reception of an RDG PPDU and up to the 46 47 transmission of a PPDU by the RD responder in which the RDG/More PPDU field is set to 0. 48 c) The transmission of a PPDU by the RD initiator containing an immediate BlockAck or ACK 49 MPDU (the “RD initiator final PPDU”), if so required by the last PPDU of the RD response burst. 50 51 NOTE—An RD initiator can include multiple reverse direction exchange sequences within a single TXOP. Each reverse 52 direction exchange sequence within a single TXOP can be addressed to a different receipient, and any single recipient 53 can be given more than one reverse direction grant within a single TXOP. 54 55 An example of an RD exchange sequence is given in T.3. 56 57 58 9.15.2 Support for RD 59 60 Support of the RD feature is an option for an HT STA. It is optional in the sense that a TXOP holder is never 61 required to generate an RDG, and a STA receiving an RDG is never required to use the grant. 62 63 64 Support of the reverse direction feature as an RD responder is indicated using the RD Responder subfield of 65 the HT Extended Capabilities field of the HT Capabilities element. A STA shall set the RD Responder sub-

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 field to 1 in frames that it transmits containing the HT Capabilities element if 2 dot11RDResponderOptionImplemented is TRUE. Otherwise, the STA shall set the RD Responder subfield 3 to 0. 4 5 6 9.15.3 Rules for the RD initiator 7 8 An RDG shall not be present unless the MPDU carrying the grant, or every MPDU carrying the grant in an 9 10 A-MPDU, matches one of the following conditions: 11 — A QoS data MPDU with the Ack Policy field set to any value except PSMP Ack (i.e., including 12 Implicit Block Ack Request), or 13 14 — A BlockAckReq related to an HT-immediate Block Ack agreement, or 15 — An MPDU not needing an immediate response (e.g., BlockAck under an HT-immediate Block Ack 16 17 agreement, or Action No Ack). 18 19 An RDG shall not be present within a PSMP sequence. 20 NOTE 1—These rules together with those in 7.4a.3 ensure that an RDG is delivered in a PPDU that either requires no 21 immediate response or requires an immediate BlockAck or ACK response. 22 23 NOTE 2—An RD initiator is not required to examine the RD Responder field of a potential responder before deciding 24 whether to send a PPDU to that STA in which the RDG/More PPDU field is set to 1. 25 26 NOTE 3—An RD initiator is required according to 9.7a to examine the +HTC Support field of a potential responder 27 before deciding whether to send a PPDU to that STA in which the RDG/More PPDU field is set to 1. 28 29 Transmission of a +HTC frame by an RD initiator with the RDG/More PPDU field set to 1 (either transmitted 30 as a non-A-MPDU frame or within an A-MPDU) indicates that the duration indicated by the Duration/ID field 31 is available for the RD response burst and RD initiator final PPDU (if present). 32 33 34 An RD initiator that sets the RDG/More PPDU field to 1 in a +HTC frame shall set the AC Constraint field 35 to 1 in that frame if the TXOP was gained through the EDCA channel access mechanism, and shall otherwise 36 set it to 0. 37 38 39 An RD initiator shall not transmit a +HTC frame with the RDG/More PPDU field set to 1 that requires a re- 40 sponse MPDU that is not one of the following: 41 —Ack 42 — Compressed BlockAck 43 44 45 Subject to TXOP constraints, after transmitting an RDG PPDU, an RD initiator may transmit its next PPDU 46 as follows : 47 48 a) Normal Continuation: The RD initiator may transmit its next PPDU a minimum of a SIFS after 49 receiving a response PPDU that meets one of the following conditions: 50 1) contains one or more correctly received +HTC frames with the RDG/More PPDU field set to 51 0, or 52 53 2) contains one or more correctly received frames that are capable of carrying the HT Control 54 field but did not contain an HT Control field, or 55 56 3) contains a correctly received frame that requires an immediate response 57 b) Error Recovery: The RD initiator may transmit its next PPDU when the CS mechanism (see 9.2.1) 58 59 indicates that the medium is idle at the TxPIFS slot boundary (defined in 9.2.10) (this is a continua- 60 tion of the current TXOP). 61 NOTE 4—Error recovery of the RDG mechanism is the responsibility of the RD initiator. 62 63 NOTE 5—After transmitting a PPDU containing an RDG, if the response is corrupted so that the state of the RDG/More 64 PPDU field is unknown, the RD initiator of the RD exchange is not allowed to transmit after a SIFS interval. Transmis- 65 sion can occur a PIFS interval after de-assertion of carrier sense.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 NOTE 6—After transmitting a PPDU requiring a response but not containing an RDG, the state of the RDG/More 2 PPDU field in the response does not affect the behavior of the RD initiator. 3 4 A STA that transmits a QoS +CF-ACK data frame according to the rules in 9.9.2.3 may also include an RDG 5 in that frame provided that: 6 7 — it is a non-A-MPDU frame; and 8 9 — the target of the +CF-ACK is equal to the Address 1 field of the frame. 10 NOTE 7—The RD initiator can transmit a CF-End frame according to the rules for TXOP truncation in 9.9.1.7 follow- 11 ing a reverse direction transmit sequence. An RD responder never transmits a CF-End. 12 13 9.15.4 Rules for the RD responder 14 15 16 An RD responder shall transmit the initial PPDU of the RD response burst a SIFS after the reception of the 17 RDG PPDU. PPDUs in a response burst are separated by SIFS or RIFS. The RIFS rules in the reverse direc- 18 tion are the same as in the forward direction; the use of RIFS is constrained as defined in 9.2.3.0b and 9.13.3.3. 19 NOTE 1—The transmission of a response by the RD responder does not comprise a new channel access but a continua- 20 tion of the RD initiator’s TXOP. An RD responder ignores the NAV when responding to an RDG. 21 22 23 The recipient of an RDG may decline the RDG by: 24 — not transmitting any frames following the RDG PPDU when no response is otherwise required, or 25 26 — transmitting a control response frame with the RDG/More PPDU field set to 0, or 27 — transmitting a control response frame that contains no HT Control field. 28 29 30 An RD responder may transmit a +CF-ACK non-A-MPDU frame in response to a non-A-MPDU QoS Data 31 +HTC MPDU that has the Ack Policy field set to Normal Ack and the RDG/More PPDU field set to 1. 32 33 The RD responder shall ensure that its PPDU transmission(s) and any expected responses fit entirely within 34 the remaining TXOP duration, as indicated in the Duration/ID field of MPDUs within the RDG PPDU. 35 36 37 An RD responder shall not transmit an MPDU (either individually or aggregated within an A-MPDU) that is 38 not one of the following: 39 —Ack 40 41 — Compressed BlockAck 42 — Compressed BlockAckReq 43 — QoS data 44 — Management 45 46 47 If the AC Constraint field is set to 1, the RD responder shall transmit data frames of only the same AC as the 48 last frame received from the RD initiator. For a BlockAckReq or BlockAck frame, the AC is determined by 49 examining the TID field. For a management frame, the AC is AC_VO. The RD initiator shall not transmit a 50 +HTC MPDU with the RDG/More PPDU field set to 1 from which the AC cannot be determined. If the AC 51 52 Constraint field is set to 0, the RD responder may transmit data frames of any TID. 53 54 During an RDG, the RD responder shall not transmit any frames with an Address 1 field that does not match 55 the MAC address of the RD initiator. 56 57 58 If an RDG PPDU also requires an immediate BlockAck response, the BlockAck response frame shall be in- 59 cluded in the first PPDU of the response. 60 61 When a PPDU is not the final PPDU of a response burst, an HT Control field carrying the RDG/More PPDU 62 field set to 1 shall be present in every MPDU within the PPDU capable of carrying the HT Control field. The 63 64 last PPDU of a response burst shall have the RDG/More PPDU field set to 0 in all +HTC MPDUs contained 65 in that PPDU.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 The RD responder shall not set the RDG/More PPDU field to 1 in any MPDU in a PPDU that contains an 2 MPDU that requires an immediate response. 3 NOTE 2— If the RD responder transmits a PPDU that expects a transmission by the RD initiator after SIFS, and no such 4 transmission is detected, the RD responder has to wait for either another RDG or its own TXOP before it can retry the 5 exchange. 6 7 8 After transmitting a PPDU containing one or more +HTC MPDUs in which the RDG/More PPDU field set 9 to 0, the RD responder shall not transmit any more PPDUs within the current response burst. 10 NOTE 3— If an RD capable STA that is not the TXOP holder receives a PPDU that does not indicate an RDG, there is 11 no difference in its response compared to a STA that is not RD capable. 12 13 14 9.16 PSMP Operation 15 16 9.16.1 Frame transmission mechanism during PSMP 17 18 19 9.16.1.1 PSMP frame transmission (PSMP-DTT and PSMP-UTT) 20 21 The attribute aDTT2UTTTime is the minimum time between the end of the PSMP-DTT and the start of a 22 PSMP-UTT addressed to the same STA. This value represents the minimum time the STA is provided to react 23 24 to Multi-TID BlockAck, BlockAck, Multi-TID BlockAckReq, BlockAckReq and data frames received dur- 25 ing the PSMP-DTT with data, BlockAck, BlockAckReq, Multi-TID BlockAckReq, Multi-TID BlockAck 26 frames transmitted in the PSMP-UTT. In a PSMP sequence, if the traffic conditions are such that the time 27 between the PSMP-DTT and PSMP-UTT of a STA would otherwise be less than the value of 28 aDTT2UTTTime, the AP shall delay the start of entire PSMP-UTT phase to meet this requirement. 29 30 31 A PSMP sequence may be used to transmit group addressed frames along with individually addressed frames. 32 Individually addressed frames shall be scheduled after group addressed frames. 33 34 35 In a PSMP frame, the STA_ID fields of all its STA Info fields with STA_INFO Type set to 2 (individually 36 addressed) shall be unique, i.e., each STA identified in the PSMP frame is identified exactly once. 37 38 Individually addressed entries in the PSMP frame should have their PSMP-DTT and PSMP-UTT Start Off- 39 sets scheduled to minimize the number of on/off transitions or to maximize the delay between their PSMP- 40 41 DTT and PSMP-UTT periods. Entries that have only PSMP-DTT should be scheduled closer to the start of 42 the PSMP-DTTs. Entries that have only PSMP-UTT should be scheduled towards the end of PSMP-UTTs. 43 Entries that have both PSMP-DTT and PSMP-UTT should be scheduled closer to the transition point from 44 Downlink to Uplink transmissions. 45 46 NOTE—For effective resource allocation, the AP should precisely estimate the PSMP-UTT Duration for each STA using 47 48 the information indicated in a TSPEC, such as Minimum Data Rate, Mean Data Rate, Peak Data Rate, Burst Size, and 49 Delay Bound fields. However, in the case where the traffic characteristic is quite bursty (e.g., a real-time video applica- 50 tion), precise estimation of PSMP-UTT Duration is difficult without timely and frequent feedback of the current traffic 51 statistics. In order to avoid wasting the available bandwidth by overestimating the PSMP-UTT Duration, the AP can al- 52 locate the minimum amount of time to each STA using the PSMP-UTT Duration field in the PSMP frame, based on the 53 value of the Minimum Data Rate field specified in the TSPEC. When the STA receives the PSMP frame, it decides if the 54 allocated resource indicated by the PSMP-UTT Duration is sufficient for its queued data. If the allocated resource is suf- 55 ficient, the STA can transmit all the queued data at the allocated time. 56 57 58 Frames of different TIDs may be transmitted within a PSMP-DTT or PSMP-UTT allocation of a PSMP se- 59 quence without regard to User Priority. 60 61 Within a PSMP-DTT or PSMP-UTT between HT STAs, BlockAckReq and BlockAck frames for which an 62 HT-immediate Block Ack agreement exists shall be the multi-TID variants, i.e. Multi-TID BlockAckReq and 63 64 Multi-TID BlockAck, respectively. Within a PSMP-DTT or PSMP-UTT between STAs where one is not an 65 HT STA, BlockAckReq and BlockAck frames shall be exchanged through the use of an immediate Block Ack

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 agreement and shall be the Basic variants, i.e. Basic BlockAck Req and Basic BlockAck, respectively. 2 3 4 9.16.1.2 PSMP Down link transmission (PSMP-DTT) 5 6 During a PSMP sequence, a STA shall be able to receive frames during its scheduled PSMP-DTT and is not 7 required to be able to receive frames at other times. 8 9 10 The AP shall ensure that any transmissions within a PSMP sequence to a STA participating in the PSMP se- 11 quence occur wholly within the STA’s PSMP-DTT. 12 13 The PSMP-DTT may contain one or more PPDUs, each of which may contain either an A-MPDU or a single 14 15 (non-A-MPDU) MPDU. Data may be transmitted using either format, provided that the format is supported 16 by both the transmitter and the receiver. 17 18 PPDUs within a PSMP-DTT may be separated using RIFS or SIFS. The use of RIFS is limited as defined in 19 20 9.2.3.0b and 9.13.3.3. 21 22 Each PSMP-DTT shall contain only frames addressed to the receiver address signaled by the corresponding 23 STA_INFO field. PPDUs from adjacent PSMP-DTTs shall be separated by at least SIFS. This means that PP- 24 DUs to different RA are separated by at least SIFS. 25 26 27 9.16.1.3 PSMP Up link transmission (PSMP-UTT) 28 29 A STA that has frames to send that are valid for transmission within the PSMP-UTT shall start transmission 30 31 without performing CCA and regardless of NAV at the start of its PSMP-UTT. 32 33 The STA shall complete its transmission within the allocated PSMP-UTT, even if it has more data queued 34 than can be transmitted during its allocated PSMP-UTT. 35 36 NOTE—PSMP-UTT is a scheduled transmission period for the STA and transmission within a PSMP-UTT does not 37 imply that the STA is a TXOP holder. This disallows a STA from using TXOP truncation during PSMP-UTT. 38 39 The uplink schedule in a PSMP frame shall include an interval between the end of one PSMP-UTT and the 40 start of the following PSMP-UTT within the same PSMP sequence. This interval shall be either aIUStime or 41 SIFS. The aIUStime value shall not be used unless the use of RIFS is permitted, as defined in 9.13.3.3. The 42 43 PSMP-UTT Duration field in the PSMP frame does not include this interval. 44 45 PPDUs transmitted within a PSMP-UTT may be separated using RIFS or SIFS. The use of RIFS is limited as 46 defined in 9.2.3.0b and 9.13.3.3. 47 48 49 An AP may transmit a PSMP frame (called a PSMP recovery frame) during a PSMP-UTT when both of the 50 following conditions are met: 51 52 — the CS mechanism (see 9.2.1) indicates that the medium is idle at the TxPIFS slot boundary (defined 53 in 9.2.10) after the start of the PSMP-UTT, and 54 — the PSMP-UTT Duration is longer than the total time of the PSMP recovery frame plus PIFS. 55 56 57 The PSMP recovery frame shall not modify the schedule of a STA that is not scheduled to use this PSMP- 58 UTT. The schedules of other STAs shall remain unchanged. The PSMP recovery frame may include: 59 60 a) a modified PSMP-UTT (and/or PSMP-DTT) for the currently scheduled STA by adjusting the time 61 remaining by a PIFS interval plus the duration of the PSMP recovery frame, and 62 b) PSMP-UTTs for other STAs that were originally scheduled after this PSMP-UTT in the PSMP 63 64 sequence in which the PSMP-UTT Start Offset values are reduced by the time difference between 65 the end of the original PSMP frame and the end of the PSMP recovery frame.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 If the currently scheduled PSMP-UTT Duration is shorter than the total time of PSMP recovery frame plus 2 PIFS, no PSMP recovery frame is transmitted. 3 4 5 Figure 9-27 illustrates a PSMP sequence with and without PSMP recovery. 6 7 8 STA 2 and STA3 do not 9 Downlink Phase receive the PSMP frame 10 PSMP- PSMP- PSMP- PSMP- AP 11 PSMP DTT1 DTT2 DTT3 DTT4 12 (STA1) (STA2) (STA3) (STA4) PSMP- PSMP- 13 PSMP-UTT2 PSMP-UTT4 UTT1 UTT3

STA (STA2) (STA4) 14 (STA1) (STA3) 15 16 Uplink Phase 17 (a): PSMP sequence without PSMP recovery 18 19 20 PSMP-recovery frame uses the 21 standard PSMP frame. PSMP- 22 recovery frame includes: modified 23 PSMP-UTT transmission schedule of STA2 and unmodified 24 from STA2 does not start schedules of STA3 and STA4. 25 New PSMP-UTT start offsets are 26 specified relative to the end of the 27 Downlink Phase PSMP-recovery frame (T'). 28 PSMP- PSMP- PSMP- PSMP- PIFS PSMP PSMP- 29 AP DTT1 DTT2 DTT3 DTT4 recovery 30 (STA1) (STA2) (STA3) (STA4) PSMP- PSMP- PSMP- 31 PSMP-UTT4 UTT1 UTT2 UTT3

STA (STA4) 32 (STA1) (STA2) (STA3) 33 T' 34 Uplink Phase 35 36 37 (b): PSMP sequence with PSMP recovery 38 39 Figure 9-27—Illustration of PSMP sequence with and without PSMP recovery 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 9.16.1.4 PSMP burst 2 3 After transmission of an initial PSMP sequence, additional PSMP sequences can be transmitted by the AP in 4 5 order to support resource allocation and error recovery. An initial PSMP sequence followed by one or more 6 PSMP sequences is termed a PSMP burst. This is shown in Figure 9-28. 7 8 SIFS SIFS Last PSMP 9 Initial PSMP sequence sequence 10 Downlink Phase Uplink Phase 11 12 13 Data Data Data

(TID1) (TID2) (TID2) etc... Multi-TID

14 Ack Block (RA1) PSMP PSMP PSMP Ack (RA2) 15 A-MPDU A-MPDU A-MPDU Multi-TID Block 16 AP MorePSMP=1 (RA2) MorePSMP=1 (RA1) MorePSMP=0 17 SIFS SIFS 18 SIFS or SIFS

19 RIFS or aIUStime (TA1) Multi-TID Multi-TID Block Ack

20 (TID1) Data (TID2) Data

21 A-MPDU Ack (TA1)

STA1 Block Multi-TID 22 (TA1)

23 (TA2) Ack (TA2)Ack STA1 A-MPDU (TID1, TID2) (TID1, 24 STA2 UTT Block Multi-TID 25 STA2 26 UTT 27 28 Figure 9-28—PSMP burst 29 30 A STA shall not transmit a +HTC MPDU in which the RDG/More PPDU field is set to 1 during a PSMP burst. 31 32 33 An AP may transmit a CF-End frame a SIFS period after the end of a PSMP sequence to end the PSMP burst. 34 NOTE 1—A non-AP STA does not transmit a CF-End frame during the PSMP burst because it is not a TXOP holder 35 during its PSMP-UTT. 36 37 During the PSMP-DTT or PSMP-UTT, a STA shall not transmit a frame unless it is one of the following: 38 39 — Multi-TID BlockAck under HT-immediate policy 40 — Multi-TID BlockAckReq under HT-immediate policy 41 42 — BlockAck under an immediate policy with the BA Ack Policy subfield set to 1 (representing No 43 Acknowledgement) 44 45 — BlockAckReq under an immediate policy with the BAR Ack Policy subfield set to 1 (representing 46 No Acknowledgement) 47 48 — QoS data 49 — PSMP (a PSMP recovery frame as described in 9.16.1.3) 50 51 — BlockAckReq under HT-delayed policy with the BAR Ack Policy subfield set to 1 (representing No 52 Acknowledgement) 53 — BlockAck under HT-delayed policy with the BA Ack Policy subfield set to 1 (representing No 54 55 Acknowledgement) 56 — An MPDU that does not require an immediate response (e.g., Management Action No Ack) 57 58 NOTE 2—An AP can gain access to the channel after a PIFS in order to start transmission of a PSMP sequence. 59 60 9.16.1.5 Resource allocation within a PSMP Burst 61 62 If the allocated PSMP-UTT Duration is not long enough for its queued data, the STA transmits only the part 63 64 of the queued data that fits within the allocated PSMP-UTT Duration and may transmit a resource request to 65 the AP within that PSMP-UTT. The resource request is communicated by setting either the Queue Size field

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 or the TXOP Duration Request field of the QoS Control field that is carried in a QoS data frame (see Figure 2 9-29). 3 4 5 If a STA receives an PSMP-UTT that is not long enough to transmit data from its queues, it may transmit 6 within the PSMP-UTT a QoS Null containing information about the state of its transmit queues. 7 NOTE 1—An HT AP can use this information to schedule a PSMP-UTT either in the current PSMP burst or a later 8 PSMP burst. 9 10 NOTE 2—An HT AP can allocate a PSMP-UTT Duration in the next PSMP sequence based on the resource request 11 from the STA sufficient to allow transmission of the remaining queued data. 12 NOTE 3—The PSMP burst supports retransmission as well as additional resource allocation (see Figure 9-30). Frames 13 transmitted under an HT-immediate Block Ack agreement during the PSMP-DTT are acknowledged by a Multi-TID 14 BlockAck frame during the PSMP-UTT period of the current PSMP sequence. Frames transmitted under an immediate 15 Block Ack agreement during the PSMP-DTT are acknowledged by a Basic BlockAck during the PSMP-UTT period of 16 the current PSMP sequence. Frames transmitted under an HT-immediate Block Ack agreement during the PSMP UTT 17 can be acknowledged using a Multi-TID BlockAck frame during the PSMP-DTT period of the next PSMP sequence. 18 Frames transmitted under an immediate Block Ack agreement during the PSMP-UTT can be acknowledged using a 19 Basic BlockAck during the PSMP-DTT period of the next PDMP sequence. Any failed transmissions during the PSMP- 20 DTT or PSMP-UTT periods can be respectively retransmitted during the PSMP-DTT or PSMP-UTT period of the next 21 PSMP sequence. 22 23 Figure 9-29 and Figure 9-30 illustrate the operation of resource allocation. STA1 requests the AP to provide 24 25 additional resources in its transmission to the AP. The box labeled “Queued data” represents the duration that 26 would be required to transmit data queued for transmission at the STA. In Figure 9-30, since the AP does not 27 receive an acknowledgement from STA2, the AP retransmits the data addressed to STA2 and also allocates 28 resources to STA2 so that STA2 can transmit in the next PSMP sequence. 29 30 31 32 33 34 PSMP PSMP to STA1 to STA2 35 AP A-MPDU A-MPDU 36 Allocated duration 37 is not enough 38 39 40 Queued data 41 AP to AP to 42 STA1 A-MPDU A-MPDU 43 44 Contains Allocated duration 45 a resource is enough request 46 47 to AP

48 STA2 A-MPDU 49 50 Figure 9-29—PSMP burst showing resource allocation 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 2 3 partially corrupted retransmission 4 5 6 PSMP PSMP PSMP PSMP to STA 1 to STA 2 to STA 2 A-MPDU A-MPDU A-MPDU Multi-TID Multi-TID Multi-TID 7 AP Block Ack Block Ack Block Ack 8 9 additional resource allocation 10 11 Queued 12 data to AP to AP A-MPDU A-MPDU A-MPDU Multi-TID Multi-TID 13 STA1 Ack Block 14 15 Contains 16 a resource 17 request 18 to AP to AP to A-MPDU A-MPDU 19 Multi-TID Multi-TID STA2 Block Ack Block Ack 20 21 partially corrupted retransmission 22 23 24 Figure 9-30—PSMP burst showing retransmission and resource allocation 25 26 9.16.1.6 PSMP-UTT retransmission 27 28 29 An AP transmits BlockAck or Multi-TID BlockAck responses, if any, to a STA’s PSMP-UTT data transmis- 30 sions under an immediate or HT-immediate Block Ack agreement, respectively, in the PSMP-DTT of a sub- 31 sequent PSMP sequence. 32 NOTE 1—An AP can reserve a PSMP-UTT in a subsequent PSMP sequence to allow a STA to retransmit failed frames. 33 The STA can retransmit failed frames in a PSMP sequence of the current PSMP burst if a PSMP-UTT reservation is 34 present or in a subsequent service period. 35 36 A STA that cannot complete its retransmissions in the last PSMP sequence of the PSMP burst because not 37 38 enough time is allocated in its PSMP-UTT may transmit the data outside any PSMP sequence. 39 NOTE 2—In the case of uplink frames transmitted outside the scheduled SP, the Multi-TID BlockAck frame that 40 acknowledges these frames is delivered in the PSMP-DTT within the next SP. 41 42 NOTE 3—A non-AP STA can transmit data outside the PSMP sequence. The acknowledgement of such frames is based 43 on their Ack Policy field value and whether a Block Ack agreements has been established, as follows: 44 — An Ack Policy of Block Ack, Normal Ack or Implicit Block Ack Request results in the behavior defined in 45 7.1.3.5.3 (Ack Policy subfield). 46 47 — An Ack Policy of PSMP Ack causes the AP to record the received data frame and results in the transmission of 48 a Multi-TID BlockAck frame in the next PSMP-DTT allocated to the STA. 49 50 9.16.1.7 PSMP Acknowledgement rules 51 52 53 A non-AP STA shall transmit a Multi-TID BlockAck frame during its PSMP-UTT for data received with the 54 ACK policy field set to PSMP Ack or for TIDs in a received Multi-TID BlockAckReq frame for which a 55 BlockAck (Compressed BlockAck or Multi-TID BlockAck) has not yet been transmitted. An AP shall trans- 56 mit a Multi-TID BlockAck frame during a PSMP-DTT addressed to the STA for the data received from that 57 58 STA with the ACK policy field set to PSMP Ack or for TIDs in a Multi-TID BlockAckReq frame received 59 from that STA for which a BlockAck (Compressed BlockAck or Multi-TID BlockAck) has not yet been trans- 60 mitted. 61 62 Data sent and received by a non-AP STA within a PSMP sequence may be contained in an A-MPDU that 63 64 contains MPDUs of multiple TIDs. Frames of differing TID may be transmitted in the same PSMP-DTT or 65 PSMP-UTT and are not subject to Access Category prioritization.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 The subtype subfield of data frames and the Ack Policy subfield of QoS data frames transmitted during either 2 PSMP-DTT or PSMP-UTT periods are limited by the following rules: 3 4 — A QoS data frame transmitted under an immediate or HT-immediate Block Ack agreement during 5 either a PSMP-DTT or a PSMP-UTT shall have one of the following Ack Policy values: PSMP Ack 6 or Block Ack. 7 8 — A QoS data frame transmitted under an HT-delayed Block Ack agreement during either a PSMP- 9 DTT or a PSMP-UTT shall have the Ack Policy field set to Block Ack. 10 — A data frame with the RA field containing an individual address transmitted during either a PSMP- 11 12 DTT or a PSMP-UTT and for which no Block Ack agreement exists shall be a QoS data subtype and 13 shall have the Ack Policy field set to No Ack. 14 — The Ack Policy field of a QoS data frame transmitted during a PSMP sequence shall not be set to 15 16 either Normal ACK or Implicit Block ACK. 17 18 All TID values within a Multi-TID BlockAck frame or Multi-TID BlockAckReq frame shall identify a Block 19 Ack agreement that is HT-immediate. QoS data frames transmitted with Ack Policy set to PSMP Ack shall 20 have a TID value that identifies a Block Ack agreement that is immediate or HT-immediate BlockAck. 21 22 NOTE 1—In this case, HT-immediate relates to the keeping of acknowledgement state for timely generation of a Multi- 23 TID BlockAck frame. It does not imply that there is any response mechanism for sending a Multi-TID BlockAck frame 24 after a SIFS interval. The timing of any response is determined by the PSMP schedule. 25 26 Acknowledgement for data transmitted under an immediate or HT-immediate Block Ack agreement may be 27 requested implicitly using PSMP Ack setting of the Ack Policy field in data frames or explicitly with a Basic 28 BlockAckReq or Multi-TID BlockAckReq frame. An AP that transmits data frames with the Ack Policy field 29 30 set to PSMP Ack or that transmits a Basic BlockAckReq or Multi-TID BlockAckReq frame addressed to a 31 STA in a PSMP-DTT shall allocate sufficient time for a Basic BlockAck or Multi-TID BlockAck transmis- 32 sion, respectively, in a PSMP-UTT allocated to that STA within the same PSMP sequence. A STA that has 33 correctly received a PSMP frame and that receives a QoS data MPDU with the Ack Policy field set to PSMP 34 Ack or that receives a Basic BlockAckReq or Multi-TID BlockAckReq frame shall transmit a Basic Block- 35 36 Ack frame or Multi-TID BlockAck frame, respectively, in the PSMP-UTT of the same PSMP sequence. 37 NOTE 2—If the STA does not receive the PSMP frame, it might still receive the downlink data, in which case it can 38 record the status of the data in it Block Ack buffer, but it cannot transmit a Multi-TID BlockAck frame. 39 NOTE 3—A Multi-TID BlockAck frame or Multi-TID BlockAckReq frame can contain any TID related to an HT- 40 Immediate Block ACK agreement regardless of the contents of any prior Multi-TID BlockAck or Multi-TID BlockAck- 41 Req or QoS data transmission. 42 43 44 An AP that receives a QoS data MPDU with the Ack Policy field set to PSMP Ack during a PSMP-UTT shall 45 transmit a Basic BlockAck or Multi-TID BlockAck response in the next PSMP-DTT that it schedules for that 46 STA, except if it has transmitted a BlockAck for such TIDs to the STA outside the PSMP mechanism. 47 NOTE 4—The exception may occur if the non-AP STA transmits one or more BlockAckReq frames, or QoS data 48 frames with Ack Policy set to Implicit Block Ack outside the PSMP mechanism. 49 50 NOTE 5—An AP might receive a Multi-TID BlockAck frame in the PSMP-UTT of the current PSMP sequence. If the 51 Multi-TID BlockAck frame indicates lost frames or if the AP does not receive an expected Multi-TID BlockAck frame, 52 the AP can schedule and retransmit those frames in a PSMP sequence within the current PSMP burst or in the next ser- 53 vice period. 54 55 A Multi-TID BlockAck frame shall include all the TIDs for which data was received with ACK policy field 56 set to PSMP Ack and for the TIDs listed in any Multi-TID BlockAckReq frame received during the previous 57 58 PSMP-DTT (STA) or PSMP-UTT (AP). The originator may ignore the bitmap for TIDs in the Multi-TID 59 BlockAck frame for which the originator has not requested a Multi-TID BlockAck frame to be present either 60 implicitly (by the transmission of data MPDUs with the Ack Policy field set to PSMP Ack) or explicitly (by 61 the transmission of a Multi-TID BlockAckReq frame). 62 63 64 If a BlockAckReq frame for an HT-delayed Block Ack agreement is transmitted during a PSMP sequence, 65 the BAR Ack Policy subfield of the BlockAckReq frame shall be set to the value representing No Acknowl-

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 edgement. 2 NOTE—Multi-TID BlockAck and Multi-TID BlockAckReq frames transmitted during PSMP use the Normal Acknowl- 3 edgement setting of the BA Ack Policy or BAR Ack Policy subfield. 4 5 6 9.16.1.8 PSMP group addressed transmission rules 7 8 9.16.1.8.1 Rules at the AP 9 10 11 This subclause defines rules that shall be followed by a PSMP Capable AP for the transmission of group ad- 12 dressed frames (data and management) during a PSMP sequence. 13 14 Each separate group address for which frames are transmitted during a PSMP sequence shall have a single 15 STA_INFO record with STA_INFO Type set to 1 (group addressed) present in the PSMP frame and transmit 16 17 frames with the matching Address 1 field only during the PSMP-DTT indicated in this record. 18 19 The DA of the PSMP shall be set to the broadcast address; except if the PSMP contains only a single non-null 20 PSMP-DTT and this PSMP-DTT contains frames for a group address, in which case the DA of the PSMP 21 frame may be set to this group address. 22 23 NOTE—The transmission of a group addressed frame within a PSMP sequence does not change the rules regarding 24 when that frame can be transmitted. This means that, if there is a power-saving STA in the BSS, the group addressed 25 frame is transmitted following a DTIM beacon according to the rules in 11.2.1. 26 27 9.16.1.8.2 Rules at the STA 28 29 This subclause defines rules that shall be followed by a PSMP Capable STA for the reception of group ad- 30 31 dressed frames during a PSMP sequence. 32 33 The STA shall be awake to receive during all PSMP-DTTs identified by a group addressed STA_INFO record 34 where the PSMP Group Address ID field matches the least significant bits of any address within its 35 36 dot11GroupAddressesTable. 37 38 9.16.2 Scheduled PSMP 39 40 A PSMP session exists while any periodic traffic stream exists that was established by a TSPEC with the 41 42 APSD field set to 0 and the Schedule field set to 1 (representing Scheduled PSMP). The creation of a PSMP 43 session is described in 11.4.4b. 44 45 While one or more PSMP sessions exist with the same SP, the AP shall periodically initiate a PSMP sequence 46 47 by transmitting a PSMP frame using the service period indicated to the STA in response to the received 48 TSPEC. Under S-PSMP rules, the AP shall not transmit a PSMP frame containing a STA_INFO record ad- 49 dressed to a STA unless the transmission occurs within a service period of that STA. The PSMP-DTT and 50 PSMP-UTT allocated to a STA shall occur within a service period of that STA. 51 NOTE—An AP can simultaneously maintain multiple PSMP sessions with distinct Service Intervals. The Service Inter- 52 vals of an AP's PSMP sessions are multiples of the Service Interval granularity. It is possible that an AP can combine the 53 schedule of multiple PSMP sessions into a single PSMP frame if the start times of the PSMP sessions coincide. For 54 example, the schedule carried by a PSMP frame related to a PSMP session at 20 ms and 30 ms service intervals can be 55 combined into a single PSMP frame once every 3 service intervals of PSMP session at 20 ms or once every 2 service 56 intervals of the PSMP session at 30 ms. 57 58 59 The start time of a PSMP sequence should be aligned with the start time of the SP. 60 61 9.16.3 Unscheduled PSMP 62 63 64 An HT AP may start an unscheduled PSMP sequence that includes STAs that are PSMP capable at any time 65 that these STAs are awake.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 NOTE—A STA in power save is awake as defined in 11.2.1.4 (U-APSD, S-APSD), 11.2.1.5 (PS-poll) or during a DTIM 2 period. 3 4 U-APSD STAs can signal the queue size or TXOP duration required to transmit its queued data to the AP in 5 the QoS control field of the trigger frame. This information can be used by the AP to estimate the duration of 6 7 the PSMP-UTT, so that the STA can transmit the queued data. 8 9 All the behavior defined in (11.2.1.4, 11.2.1.5 and 11.2.1.9) applies to unscheduled PSMP with the following 10 exceptions: 11 12 — PSMP allows the STA to sleep during PSMP-DTT and PSMP-UTTs in which it has no interest, and 13 — in addition to the EOSP mechanism, the AP may indicate the end of a SP through the transmission of 14 15 a PSMP frame with the More PSMP field set to 0, or by transmission of a CF-End frame when a 16 PSMP frame was expected. 17 18 19 9.17 Sounding PPDUs 20 21 A sounding PPDU is a PPDU for which the SOUNDING parameter of the corresponding RXVECTOR or 22 23 TXVECTOR has the value SOUNDING. Sounding PPDUs are transmitted by STAs to enable the receiving 24 STAs to estimate the channel between the transmitting STA and the receiving STA. 25 26 A STA transmits sounding PPDUs when it operates in the following roles: 27 28 — MCS feedback requester (see 9.18.2), 29 — beamformee responding to a training request, calibration initiator or responder involved in implicit 30 31 transmit beamforming (see 9.19.2.2, 9.19.2.3, and 9.19.2.4), 32 — beamformer involved in explicit transmit beamforming (see 9.19.3), and 33 34 — ASEL transmitter and ASEL sounding capable transmitter involved in antenna selection (see 9.20.2). 35 36 A STA receives sounding PPDUs when it operates in the following roles: 37 38 — MCS feedback responder (see 9.18.2), 39 — beamformer sending a training request, calibration initiator or responder involved in implicit trans- 40 mit beamforming (see 9.19.2.2, 9.19.2.3, and 9.19.2.4), 41 42 — beamformee involved in explicit transmit beamforming (see 9.19.3), and 43 — transmit ASEL responder and ASEL receiver involved in antenna selection (see 9.20.2). 44 45 46 When transmitting a sounding PPDU, the transmitting STA follows the rules stated below to determine the 47 maximum number of space time streams for which channel coefficients can be simultaneously estimated. 48 49 50 When transmitting a sounding PPDU that 51 — contains a +HTC frame with the MRQ field set to 1, or 52 53 — is sent as a response to a +HTC frame with the TRQ field set to 1, or 54 — is sent during a calibration sounding exchange, or 55 56 — is sent by a beamformer involved in explicit transmit beamforming, or 57 — is sent in transmit or receive ASEL exchanges, 58 59 60 then: 61 — If the sounding PPDU is not an NDP sounding PPDU, the NUM_EXTEN_SS parameter in the 62 TXVECTOR shall not be set to a value greater than the limit indicated by the Channel Estimation 63 64 Capability subfield in the Transmit Beamforming Capabilities field transmitted by the STA that is 65 the intended receiver of the sounding PPDU.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 NOTE—The maximum number of space time streams for which channel coefficients can be simultaneously 2 estimated using the HT long training fields corresponding to the data portion of the packet is limited by 1) the 3 Rx MCS Bitmask subfield of the Supported MCS Set field and 2) the Rx STBC subfield, both of the HT Capa- 4 bilities element. 5 6 — If the sounding PPDU is an NDP, the number of spatial streams corresponding to the MCS parameter 7 of the TXVECTOR shall not exceed the limit indicated by the Channel Estimation Capability sub- 8 field in the Transmit Beamforming Capabilities field transmitted from the STA that is the intended 9 receiver of the NDP (see 9.21.2 for details on setting the MCS parameter). 10 11 12 If a STA sets the Receive Staggered Sounding Capable bit in the Transmit Beamforming Capabilities field to 13 1, the STA shall set the Channel Estimation Capability bit in the Transmit Beamforming Capabilities field to 14 indicate a dimension that is greater than or equal to the dimension indicated by the Supported MCS Set field 15 of the HT Capabilities element. 16 17 18 19 9.18 Link adaptation 20 21 9.18.1 Introduction 22 23 24 To fully exploit MIMO channel variations and transmit beamforming on a MIMO link, a STA can request 25 that another STA provide MIMO channel sounding and MCS feedback. 26 27 Link Adaptation may be supported by immediate response or delayed response as described below. Unsolic- 28 ited MCS feedback is also possible. 29 30 — Immediate: An immediate response occurs when the MFB responder transmits the response in the 31 TXOP obtained by the TXOP holder. This approach allows the MFB requester to obtain the benefit 32 of link adaptation within the same TXOP. 33 34 — Delayed : A delayed response occurs when the MFB responder transmits the response in the role of a 35 TXOP holder in response to an MCS request in a previous TXOP obtained by the MFB requester. 36 37 — Unsolicited : An unsolicited response occurs when a STA sends MCS feedback independent of any 38 preceding MCS request. 39 40 9.18.2 Link adaptation using the HT Control field 41 42 43 A STA that supports link adaptation using the HT Control field shall set the MCS Feedback field of the HT 44 Extended Capabilities field to Unsolicited or Both, depending on its specific MCS feedback capability, in HT 45 Capabilities elements that it transmits. MCS requests shall not be sent to STAs that have not advertised sup- 46 47 port for link adaptation. A STA whose most recently transmitted MCS Feedback field of the HT Extended 48 capabilities field of the HT Capabilities element is set to Unsolicited or Both may transmit unsolicited MCS 49 feedback in any frame that contains a +HTC field. 50 51 The MFB requester may set the MRQ field to 1 in the MAI field of the HT Control field of a +HTC frame to 52 53 request a STA to provide MCS feedback. In each MCS request the MFB requester shall set the MSI field in 54 the MAI field to a value in the range 0 to 6. How the MFB requester chooses the MSI value is implementation 55 dependent. 56 NOTE—The MFB requester can use the MSI field as an MRQ sequence number or it can implement any other encoding 57 of the field. 58 59 60 The appearance of more than one instance of an HT Control field with the MRQ field set to 1 within a single 61 PPDU shall be interpreted by the receiver as a single request for MCS feedback. 62 63 An MFB requester shall transmit +HTC frames with the MRQ field set to 1 in one of the following two ways: 64 65 — within a sounding PPDU, or

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 — with the NDP Announcement field in the +HTC frame set to 1 and following the +HTC frame by an 2 NDP transmission. 3 4 5 The number of HT-LTFs sent in the sounding PPDU or in the NDP is determined by the total number of spa- 6 tial dimensions to be sounded, including any extra spatial dimensions beyond those used by the data portion 7 of the frame. 8 9 An MCS feedback capable STA (identified by the MCS Feedback field in Extended HT Capabilities Info field 10 11 set to 3) shall support the following: 12 — MFB estimate computation and feedback on the receipt of MCS request (MRQ=1 in +HTC) in a 13 sounding PPDU for which the RXVECTOR NUM_EXTEN_SS parameter contains 0 in the 14 15 PHYRXSTART.indication. 16 — MFB estimate computation and feedback on the receipt of MCS request (MRQ=1 in +HTC) in a 17 staggered sounding PPDU if this STA declares support for Receive Staggered Sounding by setting 18 the Receive Staggered Sounding Capable subfield of the Transmit Beamforming Capabilities field 19 20 to 1. 21 — MFB estimate computation and feedback on the receipt of NDP (see 9.21) if this STA declares sup- 22 port for receiving NDP sounding by setting the Receive NDP Capable subfield of the Transmit 23 24 Beamforming Capabilities field to 1. The MFB requester shall set the MRQ field to 1 in the frame 25 where the NDP Announcement field is set to 1. 26 27 On receipt of a +HTC frame with the MRQ field set to 1, an MFB responder initiates computation of the MCS 28 estimate based on the associated sounding PPDU and labels the result of this computation with the MSI value. 29 30 The MFB responder includes the received MSI value in the MFSI field of the corresponding response frame. 31 In the case of a delayed response, this allows the MFB requester to correlate the MCS feedback with the re- 32 lated MCS request. 33 34 The responder may send a response frame with any of the following combinations of MFB and MFSI: 35 36 — MFB = 127, MFSI = 7: no information is provided for the immediately preceding request or for any 37 other pending request. This combination is used when the responder is required to include an HT 38 Control field due to other protocols that use this field (i.e., the RD protocol) and when no MCS feed- 39 40 back is available. It has no effect on the status of any pending MCS request. 41 — MFB = 127, MFSI in the range 0 to 6: the responder is not now providing, and will never provide 42 feedback for the request that had the MSI value that matches the MFSI value 43 44 — MFB in the range 0 to 126, MFSI in the range 0 to 6: the responder is providing feedback for the 45 request that had the MSI value that matches the MFSI value 46 — MFB in the range 0 to 126, MFSI = 7: the responder is providing unsolicited feedback 47 48 49 Hardware and buffer capability may limit the number of MCS estimate computations that a MFB responder 50 is capable of computing simultaneously. When a new MRQ is received either from a different MFB requester 51 or from the same MFB requester with a different MSI value, and the MFB responder is not able to complete 52 53 the computation for MRQ, the MFB responder may either discard the new request or may abandon an existing 54 request and initiate an MCS estimate computation for the new MRQ. 55 56 An MFB responder that discards or abandons the computation for an MRQ should indicate this to the MFB 57 requester by setting the MFB to the value 127 in the next transmission of a frame addressed to the MFB re- 58 59 quester that includes the HT Control field. The value of the MFSI is set to the MSI value of the sounding 60 frame for which the computation was abandoned. 61 NOTE—The MFB requester can advertise the maximum number of spatial streams that it can transmit in its HT Capa- 62 bilities element. In order to do so, the MFB requester sets the Tx MCS Set Defined bit of the Supported MCS Set field to 63 1 and indicates the maximum number of streams in the Tx Maximum Number Spatial Streams Supported sub-field of the 64 Supported MCS Set field. If the Tx Rx MCS Set Not Equal bit is set to 0, the Tx MCS set is equal to the Rx MCS set, 65 and the maximum number of transmit spatial streams is derived from the value of this field.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 When computing the MCS estimate for an MFB requester whose Tx MCS Set Defined field is set to 1, the 2 number of spatial streams corresponding to the recommended MCS shall not exceed the limit indicated by 3 the Tx Maximum Number Spatial Streams Supported field. The MFB responder shall not recommend an 4 5 MCS corresponding to unequal modulation unless the MFB requester supports such modulation, as indicated 6 by the Tx Unequal Modulation Supported bit in the Supported MCS Set field. 7 8 If the MCS feedback is in the same PPDU as a Non-compressed Beamforming frame or a Compressed Beam- 9 10 forming frame, the MFB responder should estimate the recommended MCS under the assumption that the 11 MFB requester will use the steering matrices contained therein. 12 13 After the MCS estimate computation is completed, the MFB responder should include the MCS feedback in 14 the MFB field in the next transmission of a frame addressed to the MFB requester that includes an HT Control 15 16 field. When the MFB requester sets the MRQ field to 1 and sets the MSI value to a value that matches the 17 MSI value of a previous request for which the responder has not yet provided feedback, the responder shall 18 discard or abandon the computation for the MRQ that corresponds to the previous use of that MSI value. 19 20 A STA may respond immediately to a current request for MCS feedback with a frame containing an MFSI 21 22 value and MFB value that correspond to a request that precedes the current request. 23 NOTE 1—If an HT STA includes the HT Control field in the initial frame of an immediate response exchange and the 24 responding HT STA includes the HT Control field in the immediate response frame, the immediate response exchange 25 effectively permits the exchange of HT Control field elements. 26 27 NOTE 2—If an MRQ is included in the last PPDU in a TXOP and there is not enough time for a response, the recipient 28 can transmit the response MFB in a subsequent TXOP. 29 NOTE 3—Bidirectional request/responses are supported. In this case, a STA acts as the MFB requester for one direction 30 of a duplex link and a MFB responder for the other direction, transmitting both MRQ and MFB in the same HT data 31 frame. 32 33 NOTE 4—A STA that sets the MCS Feedback field to 0 in the HT Extended Capabilities field of the HT Capability ele- 34 ments that it transmits does not respond to an MRQ. 35 36 If a beamformer transmits a PPDU with the TXVECTOR EXPANSION_MAT_TYPE set to either 37 COMPRESSED_SV or NON_COMPRESSED_SV, it should use the recommended MCS associated with 38 those matrices reported in a Non-compressed Beamforming frame or a Compressed Beamforming frame. 39 40 41 9.19 Transmit beamforming 42 43 9.19.1 General 44 45 46 In order for a beamformer to calculate an appropriate steering matrix for transmit spatial processing when 47 transmitting to a specific beamformee, the beamformer needs to have an accurate estimate of the channel that 48 it is transmitting over. There are two methods defined as follows: 49 50 — Implicit feedback: When using implicit feedback, the beamformer receives long training symbols 51 transmitted by the beamformee, which allow the MIMO channel between the beamformee and beam- 52 former to be estimated. If the channel is reciprocal, the beamformer can use the training symbols that 53 54 it receives from the beamformee to make a channel estimate suitable for computing the transmit 55 steering matrix. Generally, calibrated radios in MIMO systems can improve reciprocity. See 9.19.2. 56 — Explicit feedback: When using explicit feedback, the beamformee makes a direct estimate of the 57 58 channel from training symbols sent to the beamformee by the beamformer. The beamformee may 59 prepare Channel State Information or Steering feedback based on an observation of these training 60 symbols. The beamformee quantizes the feedback and sends it to the beamformer. The beamformer 61 can use the feedback as the basis for determining transmit steering vectors. See 9.19.3. 62 63 64 An HT STA shall not transmit a PPDU with the TXVECTOR EXPANSION_MAT parameter present if the 65 MIB variable dot11BeamFormingOptionEnabled is set to FALSE.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 9.19.2 Transmit beamforming with implicit feedback 2 3 4 9.19.2.1 General 5 6 Transmit beamforming with implicit feedback can operate in a unidirectional or a bidirectional manner. In 7 unidirectional implicit transmit beamforming, only the beamformer sends beamformed transmissions. In bi- 8 directional implicit transmit beamforming, both STAs send beamformed transmissions, i.e., a STA may act 9 10 as both beamformer and beamformee. 11 12 Calibration of receive/transmit chains should be done to improve performance of transmit beamforming using 13 implicit feedback. Over-the-air calibration is described in 9.19.2.4. For implicit transmit beamforming, only 14 the beamformer, which is sending the beamformed transmissions, needs to be calibrated. 15 16 17 A STA that advertises itself as being capable of being a beamformer and/or beamformee using implicit feed- 18 back shall support the requirements in Table 9-8. 19 20 21 22 Table 9-8—STA type requirements for transmit Beamforming with implicit feedback 23 24 STA capability Required support 25 26 Beamformer Shall set the Implicit Transmit Beamforming Capable subfield = 1 of the 27 Transmit Beamforming Capability field of the HT Capabilities element in HT 28 Capabilities elements that it transmits. 29 30 Shall set the Implicit Transmit Beamforming Receiving Capable subfield = 1 31 of the Transmit Beamforming Capability field of the HT Capabilities element. 32 33 Shall be capable of receiving a sounding PPDU for which the SOUNDING 34 parameter is 'SOUNDING" and the NUM_EXTEN_SS is set to 0 in the 35 RXVECTOR in the PHY-RXSTART.indication, independently of the values 36 of the Receive Staggered Sounding Capable and Receive NDP Capable sub- 37 fields. 38 Shall set the Calibration subfield = 3 of the Transmit Beamforming Capability 39 field of the HT Capabilities element to advertise full calibration support. 40 41 Beamformee Shall set the Implicit Transmit Beamforming Receiving Capable subfield = 1 42 of the Transmit Beamforming Capability field of the HT Capabilities element 43 in HT Capabilities elements that it transmits. 44 45 Shall be capable of setting the SOUNDING parameter to 'SOUNDING" and 46 the NUM_EXTEN_SS to 0 in the TXVECTOR in the PHY-TXSTART.request 47 when transmitting a sounding PPDU, as a response to TRQ=1, independently 48 of the values of the Transmit Staggered Sounding Capable and Transmit NDP 49 Capable subfields. 50 51 52 53 A STA that performs one of the roles related to transmit beamforming with implicit feedback shall support 54 the associated capabilities shown in Table 9-9. 55 56 When a beamformee transmits a sounding PPDU, the SOUNDING parameter in the TXVECTOR in the 57 58 PHY-TXSTART.request shall be set to SOUNDING. If the beamformee is capable of implicit transmit beam- 59 forming and the beamformer is capable of receiving implicit transmit beamforming, the sounding PPDU from 60 the beamformee may be steered. 61 62 A PPDU containing one or more +HTC MPDUs in which the TRQ field is set to 1 shall not be sent to a STA 63 64 that sets the Implicit Transmit Beamforming Receiving Capable subfield of the Transmit Beamforming field 65 of the HT Capabilities element to 0.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table 9-9—Transmit beamforming support required with implicit feedback 2 3 4 Role Required Support 5 6 Beamformee: A receiver Shall transmit sounding PPDUs as a response to TRQ=1. 7 of transmit beamformed 8 PPDUs 9 10 Beamformer: A transmit- Can receive sounding PPDUs. 11 ter of beamformed PPDUs Can compute steering matrices from MIMO channel estimates obtained from long 12 training symbols in sounding PPDUs received from the beamformee. 13 14 A responder in a calibra- Can receive and transmit sounding PPDUs. 15 tion exchange Can respond with a CSI frame that contains channel measurement information 16 obtained during reception of a sounding PPDU. 17 An initiator in a calibra- Can receive and transmit sounding PPDUs. 18 tion exchange Can receive a CSI frame sent by a calibration responder. 19 20 21 22 If a PPDU containing one or more +HTC MPDUs in which the TRQ field is set to 1 requires an immediate 23 response, the response from the beamformee shall either be included in a sounding PPDU, or the NDP An- 24 nouncement field of the HT Control field shall be set to 1 and the PPDU shall be followed by an NDP. If the 25 26 PPDU in which the TRQ field is set to 1 does not require an immediate response, the beamformee shall either 27 transmit a sounding PPDU in the next TXOP obtained by the beamformee, or the beamformee shall transmit 28 a PPDU in the next TXOP obtained by the beamformee in which the NDP Announcement subfield of the HT 29 Control field is set to 1 and that PPDU shall be followed by an NDP. The use of NDP as a sounding PPDU is 30 described in 9.21. 31 32 NOTE—A STA that acts as a beamformer using implicit feedback expects to receive a sounding PPDU in response to a 33 training request. The STA can compute steering matrices from the channel estimates obtained from the received sound- 34 ing PPDU. 35 36 37 At the end of the TXOP, the final PPDU from the beamformer shall not have the TRQ field set to 1 in a frame 38 that requests an immediate response if there is not enough time left in the TXOP for the beamformee to trans- 39 mit the longest valid sounding PPDU with its response. 40 41 42 9.19.2.2 Unidirectional implicit transmit beamforming 43 44 45 Figure 9-31 shows an example of a PPDU exchange used in unidirectional implicit transmit beamforming, 46 using the Clause 20 PHY. In this example, sounding PPDUs are used that carry MPDUs (i.e., an example of 47 implicit beamforming using NDPs is not shown here.) STA A is the beamformer that initiates the PPDU ex- 48 49 change, and STA B is the beamformee. 50 51 STA A computes Tx 52 Unsteered steering Steered 53 HT-LTF HT-LTF 54 Unsteered Steered HT Data 55 56 TRQ ... 57 STA A Data/TRQ 58 59 Unsteered Unsteered HT-LTF Unsteered HT-LTF Unsteered 60 Sounding PPDU Sounding PPDU 61 62 STA B 63 64 65 Figure 9-31—Example PPDU exchange for unidirectional implicit transmit beamforming

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 The PPDU exchange can be summarized as follows: 2 3 a) STA A initiates the frame exchange sequence by sending an unsteered PPDU to STA B. The PPDU 4 includes a training request (TRQ= 1) in a +HTC MPDU. 5 b) STA B sends a sounding PPDU in response to the training request from STA A. 6 7 c) On receiving the sounding PPDU, STA A uses the resulting channel estimate to compute steering 8 matrices, and uses these to send a steered PPDU back to STA B. 9 10 d) The steered PPDU transmitted in step c) and subsequent steered PPDUs transmitted by STA A may 11 include training requests (TRQ=1) in a +HTC MPDU. In response to each training request, STA B 12 returns a sounding PPDU to STA A, which enables STA A to update its steering vectors. If the steer- 13 ing vectors resulting from step c) or subsequent sounding PPDUs are deemed stale due to delay, the 14 sequence can be restarted by returning to step a). 15 16 Step d) in the above PPDU exchange represents steady state unidirectional Transmit Beamforming 17 18 operation. 19 20 During the PPDU exchange, neither the receiving nor the transmitting STA should switch antennas. 21 22 9.19.2.3 Bidirectional implicit transmit beamforming 23 24 Figure 9-32 shows an example of a PPDU exchange used in bidirectional implicit transmit beamforming, us- 25 ing the Clause 20 PHY. In this example, sounding PPDUs are used that carry MPDUs. STA A initiates the 26 27 frame exchange, and STA A and STA B alternate in the roles of beamformer and beamformee. 28 29 30 STA A computes Tx steering 31 32 Steered 33 Unsteered HT-LTF HT-LTF 34 Steered HT Data 35 Unsteered Sounding PPDU 36 37 38 STA A TRQ [TRQ]/Data …………………... 39 40 Unsteered Steered 41 HT-LTF Unsteered HT Data HT-LTF Steered HT Data 42 Sounding PPDU Sounding PPDU 43 44 STA B TRQ/Data [TRQ]/Data 45 46 47 48 49 50 STA B computes 51 Tx steering 52 53 Figure 9-32—Example PPDU exchange for bidirectional implicit transmit beamforming 54 55 The PPDU exchange can be summarized as follows: 56 57 a) STA A initiates the frame exchange sequence by sending an unsteered PPDU to STA B. The PPDU 58 includes a training request (TRQ= 1) in a +HTC MPDU. 59 60 b) STA B sends a sounding PPDU in response to the training request. In addition, this PPDU includes a 61 training request in a +HTC MPDU to enable implicit transmit beamforming in the reverse direction 62 c) On receiving the sounding PPDU, STA A uses the resulting channel estimate to compute steering 63 64 matrices, and uses these to send a steered PPDU back to STA B. This steered PPDU is also a sound- 65 ing PPDU in response to the training request from STA B.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 NOTE—Steering matrices with non-orthonormal columns should not be used in transmitting sounding PPDUs 2 for implicit feedback. In general, bidirectional implicit beamforming will not function as described here when 3 the steering matrices have non-orthonormal columns. See 20.3.12.1. 4 5 d) On receiving the sounding PPDU, STA B uses the resulting channel estimate to compute steering 6 matrices, and uses these to send a steered PPDU back to STA A. The steered PPDU transmitted in 7 step c) and subsequent steered PPDUs transmitted by STA A may include training requests in HTC. 8 In response to each training request, STA B returns a sounding PPDU to STA A, which enables STA 9 10 A to update its steering vectors. If the steering vectors resulting from step c) or subsequent sounding 11 PPDUs are deemed stale due to delay, the sequence can be restarted by returning to step a). 12 e) The steered PPDU transmitted in step d) and subsequent steered PPDUs transmitted by STA B may 13 14 include training requests in HTC. In response to each training request, STA A returns a sounding 15 PPDU to STA B, which enables STA B to update its steering vectors. If the steering vectors result- 16 ing from step d) or subsequent sounding PPDUs are deemed stale due to delay, the sequence can be 17 restarted by returning to step a). 18 19 Steps d) and e) in the above PPDU exchange represent steady state bidirectional Transmit Beamforming 20 21 operation. 22 During the PPDU exchange, neither the receiving nor the transmitting STA should switch antennas. 23 24 NOTE—The TRQ protocol used with the beamforming training process is not sufficient to permit STA B to transmit 25 data frames in the reverse direction. In the example shown in Figure 9-32, STA A would additionally have to follow the 26 rules of the Reverse Direction Protocol (see 9.15). 27 28 29 9.19.2.4 Calibration 30 31 9.19.2.4.1 Introduction 32 33 34 Differences between transmit and receive chains in a STA degrade the inherent reciprocity of the over-the- 35 air time division duplex channel, and cause degradation of the performance of implicit beamforming. Cali- 36 bration acts to remove or reduce differences between transmit and receive chains and enforce reciprocity in 37 the observed baseband-to-baseband channels between two STAs. 38 39 40 A STA acting as a beamformer should be calibrated to maximize performance. A STA acting only as a beam- 41 formee does not need to be calibrated. If calibration is desired, it is performed using the over-the-air calibra- 42 tion procedure described below. 43 44 45 The calibration procedure involves the computation of correction matrices that effectively ensure that the ob- 46 served channel matrices in the two directions of the link are transposes of each other and thus renders the re- 47 sultant channel reciprocal. See 20.3.12.1 for a more detailed description. If it is able to do so, a STA should 48 calibrate upon association. 49 NOTE—STAs with two or more transmit RF chains should be calibrated in order to engage in implicit transmit beam- 50 forming. STAs with any number of RF chains, including those with a single RF chain, can participate in a calibration 51 exchange as a calibration responder. 52 53 54 9.19.2.4.2 Calibration Capabilities 55 56 A STA that sets the Implicit Transmit Beamforming Capable subfield of the Transmit Beamforming Capa- 57 58 bilities field to 1 shall support calibration and shall set the Calibration subfield of the Transmit Beamforming 59 Capabilities field to 3 (indicating full support of calibration) in HT Capabilities elements that it transmits. A 60 STA that does not set the Implicit Transmit Beamforming Capable subfield of the Transmit Beamforming 61 Capabilities field to 1 may support calibration and shall set the Calibration subfield of the Transmit Beam- 62 forming Capabilities field to the value that indicates its calibration capability in the Transmit Beamforming 63 64 Capabilities field fields in HT Capabilities elements that it transmits (see Table 7-43o), when the Transmit 65 Beamforming Capabilities field exists.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 A STA that is capable of initiating calibration (the Calibration subfield of the Transmit Beamforming Capa- 2 bilities field is set to 3) shall set the CSI Max Number of Rows Beamformer Supported subfield to an appro- 3 priate value, even if the STA sets the Explicit Transmit Beamforming CSI Feedback subfield to a zero value. 4 5 6 In order to support calibration, a STA that advertises that it is capable of responding to a calibration request 7 shall be capable of transmitting a CSI frame in which the value of the Grouping subfield of the MIMO Control 8 field is 0 (no grouping) and the Coefficients Size subfield of the MIMO Control field is 3 (Nb=8 bits) in re- 9 10 sponse to a CSI feedback request indicated by the CSI/Steering subfield of the HT Control field set to 1 and 11 the Calibration Position subfield of the HT Control field set to 3, independently of the advertised values of 12 the Explicit Transmit Beamforming CSI Feedback subfield in the Transmit Beamforming Capabilities field 13 in the HT Capabilities element. A STA that advertises that it is capable of initiating a calibration request shall 14 be capable of receiving a CSI frame in which the value of the Grouping subfield of the MIMO Control field 15 16 is set to 0 (no grouping) and the Coefficients Size subfield of the MIMO Control field is set to 3 (Nb=8 bits) 17 as a response to CSI feedback request indicated by the CSI/Steering subfield of the HT Control field set to 1 18 with the Calibration Position subfield set to 3, independently of the advertised values of the Explicit CSI 19 Transmit Beamforming Capable subfield in the Transmit Beamforming Capabilities field in the HT Capabil- 20 ities element. 21 22 23 A STA may initiate a calibration training frame exchange sequence with another STA if that STA supports 24 calibration. A STA shall not initiate a calibration training frame exchange with another STA if that STA does 25 not support calibration. 26 27 28 If the Receive NDP Capable field is set to 1, and the value of the Calibration field is set to 1 or 3, and if the 29 device supports transmitting sounding PPDUs for which two or more channel dimensions can be estimated 30 (two or more columns of the MIMO channel matrix), then transmission of NDPs shall be supported (which 31 32 causes the Transmit NDP Capable bit to be set to 1). 33 34 9.19.2.4.3 Sounding exchange for calibration 35 36 37 Figure 9-33, illustrates the calibration PPDU exchange using sounding PPDUs that contain an MPDU. 38 39 PPDU Type: Sounding Frame Type : QoS Null 40 Frame Type: QoS Null (Data) ACK Policy : Normal ACK Policy : Normal ACK 41 + HTC : TRQ 42 +HTC CSI Feedback Request Cal Position 1: Cal Position 3: 43 STA A ACK 44 Cal Start Sound Complete 45 46 PPDU Type: Sounding 47 Frame Type: ACK Frame Type: Management Action + HTC : TRQ +HTC 48

49 Cal Position 2: ACK CSI 50 STA B Cal Sound 51 52 53 Step 1 Step 2 54 55 Figure 9-33—Calibration procedure with sounding PPDU containing an MPDU 56 57 The calibration procedure begins with a calibration sounding PPDU exchange sequence shown as Step 1 in 58 59 Figure 9-33. The Calibration Sequence subfield in the HT Control field shall be incremented each time a new 60 calibration procedure is started. 61 62 STA A (the calibration initiator) shall transmit a Calibration Start frame (Calibration Position field set to 1) 63 64 with the TRQ field in the HT Control field set to 1. This frame initiates a calibration procedure. It shall be a 65 QoS Null data frame, with the ACK Policy field set to Normal ACK.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 In response, STA B (the calibration responder) shall transmit a Calibration Sounding Response frame (Cali- 2 bration Position field set to 2), a SIFS interval after the end of the Calibration Start frame, using a sounding 3 4 PPDU. This allows STA A to estimate the MIMO channel from STA B to STA A. In the Calibration Sounding 5 Response frame, the Calibration Sequence subfield in HT Control field shall be set to the same value that is 6 indicated in the Calibration Start frame. The Calibration Sounding Response frame shall have a frame type 7 of ACK+HTC, and the TRQ field in the HT Control field in this frame shall be set to 1. 8 9 10 In response, STA A shall transmit a Calibration Sounding Complete frame (Calibration Position field set to 11 12 3) that contains the CSI/Steering subfield of the HT Control field set to 1, a SIFS interval after the end of the 13 Calibration Sounding Response frame, using a sounding PPDU. This allows STA B to estimate the MIMO 14 channel from STA A to STA B. In this Calibration Sounding Complete frame, the Calibration Sequence sub- 15 16 field in the HT Control field shall be set to the same value that is indicated in the Calibration Sounding Re- 17 sponse frame. The Calibration Sounding Complete frame shall be a QoS Null+HTC with the ACK Policy 18 field set to Normal ACK. 19 20 21 A frame in which the Calibration Position field is set to 2 or 3 shall be transmitted in a sounding PPDU (a 22 23 PPDU for which the SOUNDING parameter is set to SOUNDING). The number of long training fields used 24 to obtain MIMO channel estimation that are sent in the sounding PPDU shall be determined by the number 25 of transmit chains (NTX) used in sending these long training fields at the STA transmitting the sounding PP- 26 27 DU. The transmit chains used at the calibration initiator are those for which calibration is required. 28 29 30 The calibration responder may train up to maximum available transmit chains to maximize the quality of the 31 resulting calibration, though the number of space time streams for data symbols shall be determined by the 32 rule described in 9.6. 33 34 35 When transmitting a sounding PPDU during step 1 of a calibration procedure, if the Receive Staggered Ca- 36 pability subfield in the Transmit Beamforming Capability field of the HT Capabilities element transmitted by 37 38 the intended receiver is zero, then: 39 40 — if the sounding PPDU is not an NDP, the number of antennas used by the sender shall be less than or 41 equal to the maximum number of space time streams indicated by the Rx MCS Bitmask subfield of 42 the Supported MCS Set field and the Rx STBC subfield of the HT Capabilities element transmitted 43 44 by the intended receiver; 45 46 — if the sounding PPDU is an NDP, the number of antennas used by the sender shall be less than or 47 equal to the number indicated by the Channel Estimation Capability subfield in the Transmit Beam- 48 forming Capability field of the HT Capabilities element transmitted by the intended receiver. 49 50 51 Sounding packets in which the Calibration Position field is set to 2 or 3 shall use the spatial mapping matrices 52 53 defined in 20.3.13.2. The calibration responder shall not remove the spatial mapping from the CSI to be fed 54 back to the initiator of the frame exchange. 55 56 NOTE—The calibration initiator of this frame exchange is responsible for accounting for the spatial mapping in both its 57 local channel estimate as well as in the quantized CSI fed back to it. 58 59 60 The row order in the CSI feedback matrix transmitted from STA B shall correspond to the association of the 61 rows of the spatial mapping matrix (see Equation (20-75)) to its transmit antennas. For example, the receive 62 antenna at STA B associated with row i in the CSI feedback matrix in each subcarrier is the same as its trans- 63 64 mit antenna associated with row i in the spatial mapping matrix used for transmitting the sounding response 65 with Calibration Position set to 2.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Figure 9-34 and Figure 9-35 illustrate the calibration PPDU exchange using NDPs. 2 3 4 Frame Type : QoS Data (or RTS or Management) 5 ACK Policy : Normal ACK 6 + HTC : NDP Announcement=1 7 Cal Position: 1 NDP 8 STA A Cal Start 1 9 10 11 12 13 Frame Type: ACK (or CTS) 14 15 Cal Position: 2 NDP 16 STA B Cal Sound 2 17 18 19 Step 1 Step 2 is not 20 shown here 21 22 23 Figure 9-34—Calibration procedure with NDP 24 25 Frame Type : QoS Data (or RTS or Management) 26 ACK Policy : Normal ACK 27 + HTC : NDP Announcement=1 28 29 Cal Position: 1 NDP 30 STA A Cal Start 1 31 32 33 34 PPDU Type: Sounding 35 Frame Type: ACK (or CTS) 36 37 STA B Cal Position: 2 38 Cal Sound 39 40 Step 2 is not 41 Step 1 42 shown here 43 44 45 Figure 9-35—Calibration procedure with NDP in the case STA B supports transmitting sound- 46 ing PPDUs for which only one channel dimension can be estimated (i.e., a single column of 47 the MIMO channel matrix) 48 49 50 The calibration procedure begins with a calibration sounding PPDU exchange sequence, shown as Step 1 in 51 Figure 9-34, and Figure 9-35 when STA B supports transmitting sounding PPDUs for which only one channel 52 dimension can be estimated (i.e., a single column of the MIMO channel matrix). The Calibration Sequence 53 subfield in the HT Control field shall be incremented each time a new calibration procedure is started. 54 55 56 NDP transmission within a calibration procedure follows the rules defined in 9.21.1. STA A transmits a frame 57 signaling calibration start (i.e., with the Calibration Position field set to 1), with the NDP Announcement field 58 59 set to 1, and CSI/Steering subfield of the HT Control field set to 1. Only the current TXOP holder may set 60 both the Calibration Position and NDP announcement fields to 1. This frame initiates a calibration procedure. 61 62 STA B shall transmit a frame that signals calibration sounding response (i.e., with the Calibration Position 63 64 field set to 2) after a SIFS interval after the received calibration start frame. If STA B supports transmitting 65 sounding PPDUs for which only one channel dimension can be estimated (i.e., a single column of the MIMO

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 channel matrix), this calibration sounding response is sent with the SOUNDING parameter of the TXVEC- 2 TOR set to SOUNDING (see Figure 9-35). 3 4 5 As determined by NDP rules a) or b) in 9.21.1, STA A sends the first NDP as a sounding PPDU a SIFS after 6 receiving the frame that signals calibration sounding response. This allows STA B to estimate the MIMO 7 channel from STA A to STA B. In the frame that signals calibration sounding response, the Calibration Se- 8 quence subfield in HT Control field shall be set to the same value that is contained in the frame that signals 9 calibration start. The frame that signals calibration sounding response shall contain an HT Control field and 10 11 the type and subtype of the frame are determined by the frame that signals the calibration start. 12 13 As determined by NDP rule d), STA B might transmit a second NDP as a sounding PPDU a SIFS interval 14 after receiving the first NDP. This second NDP allows STA A to estimate the channel from STA B to STA A. 15 NOTE 1—STA B does not transmit an NDP when it supports transmitting sounding PPDUs for which only one channel 16 dimension can be estimated (see Figure 9-35). 17 18 19 Otherwise (i.e., if STA B supports transmitting sounding PPDUs for which only one channel dimension can 20 be estimated (single column of the MIMO channel matrix)), the transmission of the sounding PPDU in Cali- 21 bration Position 2 allows STA A to estimate the channel from STA B to STA A. 22 23 NDP sounding PPDUs shall use the spatial mapping matrices defined in 20.3.13.2. The calibration responder 24 25 shall not remove the spatial mapping from the CSI to be fed back to the initiator of the frame exchange. 26 NOTE 2—The calibration initiator of this frame exchange is responsible for accounting for the spatial mapping in both 27 its local channel estimate as well as in the quantized CSI fed back to it. 28 29 9.19.2.4.4 CSI reporting for calibration 30 31 The remaining message exchange in the calibration procedure is not time critical. 32 33 34 The calibration initiator should not transmit any frames that are part of the calibration sequence shown in Step 35 1 in Figure 9-33, if either of the response frames from the calibration responder (the frames shown as Cali- 36 bration Position 2 and ACK in Step 1) is not received correctly within an ACKTimeout interval (as defined 37 in 9.2.8 after the PHY-TXEND.confirm. If the calibration initiator aborts the calibration sequence, it can re- 38 39 start the calibration sequence with a value of the Calibration Sequence in the Calibration Control subfield of 40 the HT Control field which is different (i.e., incremented) from the value used in the aborted sequence. Within 41 a non-NDP calibration sequence, the calibration responder should not transmit any further frames that are part 42 of the calibration sequence shown in Step 1, if the frame having Calibration Position 3 is not received cor- 43 rectly within an ACKTimeout interval (as defined in 9.2.8 after the PHY-TXEND.confirm. 44 45 46 When the MIMO channel measurements become available at STA B, STA B shall send one or more CSI 47 frames that contain the CSI Report (Step 2 in Figure 9-33). This CSI Report shall have full precision, i.e, 48 Ng=1 (no grouping) and Nb=3 (8 bits). In these CSI frames, the Calibration Sequence subfields in HT Control 49 fields shall be set to the same value that is indicated in the Calibration Sounding Complete frame. These CSI 50 51 frames shall have a frame type of Management Action +HTC. 52 53 STA B should finish transmission of the first CSI frame, within aMaxCSIMatricesReportDelay (ms) after the 54 reception of the frame containing the CSI Feedback Request or NDP Announcement. 55 NOTE—If necessary, the CSI Report field can be split into up to 8 segments as specified in Table 7-25c. 56 57 58 A STA that has started but not completed the calibration procedure and that receives some other request that 59 requires the buffering of CSI (such as another calibration initiation frame, MCS feedback request, CSI feed- 60 back request for link adaptation, or feedback request for explicit Transmit Beamforming) may ignore the 61 other request. 62 63 64 From the beginning of step 1 of the calibration procedure and continuing through the end of step 2 of the cal- 65 ibration procedure, neither the receiving nor the transmitting STA should switch antennas.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 9.19.3 Explicit feedback beamforming 2 3 In this subclause, the terms beamformer and beamformee refer to STAs that are involved in explicit feedback 4 5 beamforming. 6 7 A beamformer uses the feedback response that it receives from the beamformee to calculate a beamforming 8 matrix for transmit beamforming. This feedback response may have one of three formats: 9 10 — Channel State Information: the beamformee sends the MIMO channel coefficients to the beam- 11 former; 12 — Non-compressed Beamforming: the beamformee sends calculated beamforming matrices to the 13 14 beamformer; 15 — Compressed Beamforming: the beamformee sends compressed beamforming matrices to the beam- 16 former. 17 18 19 The supported formats shall be advertised in the beamformee’s HT Capabilities element. 20 NOTE—A beamformer can discard the feedback response if the TSF time when the PHY_CCA.indication(IDLE) prim- 21 itive corresponding to the feedback response frame’s arrival minus the value from the Sounding Timestamp field in the 22 feedback response frame is greater than the coherence time interval of the propagation channel. 23 24 A beamformee’s responding capabilities shall be advertised in HT Capabilities elements contained in Beacon, 25 Probe Request, Probe Response, Association Request, Association Response, Action, and Action No Ack 26 27 frames that are transmitted by the beamformee. Devices that are capable of acting as a beamformee shall ad- 28 vertise one of the following response capabilities in the Explicit Transmit Beamforming CSI Feedback sub- 29 field of the Transmit Beamforming Capability field: 30 31 — Immediate: the beamformee is capable of sending a feedback response a SIFS after receiving a 32 sounding PPDU and/or is capable of sending a feedback response aggregated in a PPDU that con- 33 tains a MAC response within the beamformer’s TXOP 34 — Delayed: the beamformee is not capable of sending the feedback response within the beamformer’s 35 36 TXOP, but it is capable of sending the feedback response in a TXOP that it obtains. 37 — Immediate and Delayed: the beamformee is capable of sending a feedback response a SIFS after 38 receiving a sounding PPDU or is capable of sending a feedback response aggregated in a PPDU that 39 40 contains a MAC response within the beamformer’s TXOP, or capable of sending the feedback 41 response in a TXOP that it obtains. 42 43 The sounding frame types supported by the beamformee, staggered and/or NDP, are advertised in the HT Ca- 44 pabilities element in frames that are transmitted by the beamformee. 45 46 47 A STA that sets any of the Explicit Transmit Beamforming CSI feedback capable, Explicit Non-compressed 48 Beamforming Feedback Capable, or Explicit Compressed Beamforming Feedback Capable fields to 1 shall 49 transmit explicit feedback based on the receipt of a +HTC sounding PPDU in which the CSI/Steering field 50 has a non-zero value and that does not contain extension HT-LTFs. This requirement is independent of the 51 52 values of the Receive Staggered Sounding Capable and the Receive NDP Capable fields. 53 54 A beamformer shall set the SOUNDING parameter of the TXVECTOR to SOUNDING in the PHY-TX- 55 START.request primitive corresponding to each packet that is used for sounding. 56 57 58 A beamformer shall set the response type format indicated in the CSI/steering field of the HT Control field 59 of any sounding frame excluding the NDP and of any PPDU with the NDP sounding announcement field set 60 to 1 to one of the non-zero values (CSI, Compressed Beamforming or Non-compressed Beamforming) that 61 corresponds to a type that is supported by the beamformee. 62 63 64 The receipt of a PHY-RXSTART.indication with the RXVECTOR SOUNDING parameter value set to 65 SOUNDING indicates a sounding packet.A non-NDP request for feedback is a sounding PPDU with a +HTC

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 MPDU that contains a non-zero value of the CSI/Steering field and that has the NDP Announcement field set 2 to zero. 3 4 5 An NDP request for feedback is the combination of a +HTC MPDU that contains a non-zero value of the CSI/ 6 Steering field and that has the NDP Announcement field set to 1 and the NDP that follows. 7 8 A beamformee that transmits a feedback frame in response to a sounding PPDU sent by a beamformer shall 9 10 transmit a frame of the type (CSI, Compressed Beamforming or Non-compressed Beamforming) indicated in 11 the CSI/Steering field of the HT Control field transmitted by the beamformer. 12 13 A beamformee that sets the Explicit Transmit Beamforming CSI Feedback field of its HT Capabilities ele- 14 15 ment to either 2 or 3 shall transmit Explicit CSI feedback after SIFS or later in the beamformer's TxOP as a 16 response to a non-NDP request for feedback in a frame that is appropriate for the current frame exchange se- 17 quence following Table 9-10. A beamformee that sets the Explicit Non-compressed Beamforming Feedback 18 19 20 Table 9-10—Rules for beamformee immediate feedback transmission responding to non- 21 22 NDP sounding 23 24 Type of Response Rule 25 26 If the transmission of a CTS is required, in response to the non-NDP request for 27 CTS response feedback, the transmission of the feedback response frame shall be delayed until 28 the beamformee's next transmission within the TXOP. This feedback response 29 frame may be aggregated in an A-MPDU with an ACK or BlockAck. 30 31 Acknowledgement re- If the transmission of an ACK or BlockAck control response frame is required 32 sponse in response to the non-NDP request for feedback, both the feedback response 33 frame and the control response frame may be aggregated in an A-MPDU. 34 35 No control response If the transmission of a control response frame is not required in response to the 36 non-NDP request for feedback, the feedback response frame shall be sent a 37 SIFS after the reception of the sounding PPDU containing the request for feed- 38 back. 39 40 Later aggregation of If the immediate feedback capable beamformee cannot transmit an aggregated 41 feedback and acknowl- or immediate CSI/Steering response in a SIFS time after the end of the received 42 edgement sounding packet, and the beamformee is subsequently required to transmit an 43 ACK or BlockAck response in the same TXOP, it may transmit the feedback 44 response in an A-MPDU with the ACK or BlockAck. 45 46 47 48 Capable field of its HT Capabilities element to either 2 or 3 shall transmit Explicit Non-compressed Beam- 49 forming feedback after SIFS or later in the beamformer's TxOP as a response to a non-NDP request for feed- 50 back in a frame that is appropriate for the current frame exchange sequence following Table 9-10. 51 52 53 A beamformee that sets the Explicit Compressed Feedback Capable field of its HT Capabilities element to 54 either 2 or 3 shall transmit Explicit Compressed Beamforming feedback after SIFS or later in the beamform- 55 er's TxOP as a response to a non-NDP request for feedback in a frame that is appropriate for the current frame 56 exchange sequence following Table 9-10. 57 58 59 A beamformee that sets the Explicit Transmit Beamforming CSI Feedback field of its HT Capabilities ele- 60 ment to either 2 or 3 shall transmit the Explicit CSI feedback after SIFS or later in the beamformer’s TXOP 61 as a response to an NDP request for feedback in a frame that is appropriate for the current frame exchange 62 sequence following Table 9-11. 63 64 65 A beamformee that sets the Explicit Non-Compressed Beamforming Feedback Capable field of its HT Capa-

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table 9-11—Rules for beamformee immediate feedback transmission responding to NDP 2 sounding 3 4 5 Type of response Rule 6 7 Control response If the transmission of a control response frame is required in response to the NDP 8 request for feedback, the control response frame is transmitted a SIFS after reception of 9 the PPDU that elicited the control response and the feedback response frame may be 10 transmitted a SIFS after the reception of the NDP. 11 — If the feedback response frame is not transmitted a SIFS after the reception of 12 the NDP, and the beamformee is subsequently required to transmit an ACK or 13 14 BlockAck response in the same TXOP, then the feedback response may be 15 aggregated with the ACK or BlockAck. 16 — If the feedback response frame is not transmitted a SIFS after the reception of 17 the NDP, and is not transmitted as part of an aggregated ACK or BlockAck 18 response in the same TXOP, then the feedback response frame is delayed until 19 the beamformee's next transmission within the TXOP. 20 21 No control re- If the transmission of a control response frame is not required in response to the NDP 22 sponse request for feedback, the feedback response frame may be sent a SIFS after the recep- 23 tion of the NDP. 24 — If the feedback response frame is not transmitted a SIFS after the reception of 25 the NDP, and the beamformee is subsequently required to transmit an ACK or 26 BlockAck response in the same TXOP, then the feedback response may be 27 28 aggregated with the ACK or BlockAck. 29 — If the feedback response frame is not transmitted a SIFS after the reception of 30 the NDP, and is not transmitted as part of an aggregated ACK or BlockAck 31 response in the same TXOP, then the feedback response frame is delayed until 32 the beamformee's next transmission within the TXOP. 33 34 35 36 bilities element to either 2 or 3 shall transmit the Explicit Non-compressed Beamforming feedback after SIFS 37 or later in the beamformer’s TXOP as a response to an NDP request for feedback in a frame that is appropriate 38 for the current frame exchange sequence following Table 9-11. 39 40 41 A beamformee that sets the Explicit Compressed Beamforming Feedback Capable field of its HT Capabilities 42 element to either 2 or 3 shall transmit the Explicit Compressed Beamforming feedback after SIFS or later in 43 the beamformer’s TXOP as a response to an NDP request for feedback in a frame that is appropriate for the 44 45 current frame exchange sequence following Table 9-11. 46 47 When the beamformee sets the Explicit Transmit Beamforming CSI Feedback field of its HT Capabilities el- 48 49 ement to either 2 or 3, and the beamformer has transmitted an NDP, or an non-NDP Explicit Beamforming 50 CSI feedback request in a frame that does not require immediate control response, the beamformer shall not 51 transmit the next packet to the beamformee, until PIFS after transmitting the sounding request. 52 53 54 When the beamformee sets the Explicit Non-compressed Beamforming Feedback Capable field of its HT Ca- 55 pabilities element to either 2 or 3, and the beamformer has transmitted an NDP, or an non-NDP Explicit Non- 56 Compressed Beamforming feedback request in a frame that does not require immediate control response, the 57 beamformer shall not transmit the next packet to the beamformee, until PIFS after the sounding request. 58 59 60 When the beamformee sets the Explicit Compressed Beamforming Feedback Capable field of its HT Capa- 61 bilities element to either 2 or 3, and the beamformer has transmitted an NDP, or an non-NDP Explicit Com- 62 pressed Beamforming feedback request in a frame that does not require immediate control response, the 63 64 beamformer shall not transmit the next packet to the beamformee, until PIFS after transmitting the sounding 65 request.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 A beamformee shall not transmit a CSI, Compressed Beamforming or Non-compressed Beamforming frame 2 except in response to a request for feedback. 3 NOTE—Error recovery in a TXOP is not affected by sounding. A beamformer that is a TXOP holder and that fails to 4 receive an expected response to a sounding PPDU can continue transmission as specified in 9.9.1.4. 5 6 7 A beamformee transmitting a feedback response after SIFS or later in the beamformer’s TXOP shall use an 8 Action No Ack frame or an Action No Ack +HTC frame (defined in 7.2.3.13). 9 10 A beamformee transmitting delayed feedback response shall use an Action frame or an Action +HTC frame 11 to send this information within a separate TXOP. 12 13 14 If necessary, the CSI Report field, Non-compressed Beamforming Report field or Compressed Beamforming 15 Report field may be split into up to 8 frames. The length of each segment shall be equal number of octets for 16 all segments except the last, which may be smaller. 17 NOTE—A STA that has been granted an RDG can act as a beamformer during the RDG time period, provided that the 18 RD rules are obeyed. 19 20 21 A beamformee that advertises itself as delayed feedback capable shall not transmit an immediate feedback 22 response, unless it also advertises itself as immediate feedback capable. 23 24 A beamformer may use the following worst case parameters to estimate the duration of the expected frame 25 26 that contains the feedback response: Basic MCS, HT-mixed format, Supported Grouping. 27 28 An Explicit Feedback Request may be combined with an MRQ. If the response contains a Beamforming Ma- 29 trix, the returned MCS shall be derived from the same information that was used to generate this particular 30 beamforming matrix. If the response contains channel coefficients, the returned MCS shall be derived from 31 32 an analysis of the sounding frame that was used to generate the channel coefficients. The MFB field set to 33 127 (meaning no feedback) may be used when the beamformee is unable to generate the MCS in time for 34 inclusion in the response transmission frame. A CSI capable STA may be incapable of generating MCS feed- 35 back. 36 37 38 Explicit feedback shall only be calculated from a sounding PPDU. 39 40 41 9.20 Antenna selection 42 43 9.20.1 Introduction 44 45 46 Antenna selection is a time-variant mapping of the signals at the RF chains onto a set of antenna elements, 47 when the number of RF chains is smaller than the number of antenna elements at a STA and/or AP. The map- 48 ping can be chosen based on instantaneous or averaged channel state information. Antenna selection requires 49 the training of the full size channel associated with all antenna elements, which is obtained by transmitting or 50 receiving sounding PPDUs over all antennas. These sounding PPDUs should be sent within a single TXOP. 51 52 To avoid channel distortions, these sounding PPDUs shall be transmitted consecutively. The training infor- 53 mation is exchanged using the HT control field. When both transmitter and receiver have antenna selection 54 capabilities, training of transmit and receive antennas can be done one after another. Antenna selection sup- 55 ports up to eight antennas and up to four RF chains. 56 57 58 9.20.2 Procedure 59 60 A STA shall not initiate an antenna selection training frame exchange sequence with another STA unless that 61 STA supports antenna selection, as determined by the Antenna Selection Capable field (see 7.3.2.56.7). 62 63 64 A STA that is capable of supporting antenna selection should set each subfield of the Antenna Selection Ca- 65 pabilities field of the HT Capabilities element to 1 depending on its capabilities in HT Capabilities elements

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 that it transmits (See 7.3.2.56.7). 2 3 4 A STA that sets the Explicit CSI Feedback Based Tx ASEL Capable subfield of the Antenna Selection Ca- 5 pable field (see 7.3.2.56.7) to 1 shall set the CSI Max Number of Rows Beamformer Supported subfield of 6 the Transmit Beamforming Capabilities field to an appropriate value, even if the STA sets the Explicit Trans- 7 8 mit Beamforming CSI Feedback subfield to a zero value. 9 10 11 The frame exchange sequence for transmit antenna selection is shown in Figure 9-36, where the term ASEL 12 transmitter identifies the STA that is conducting transmit antenna selection, and the term transmit ASEL re- 13 sponder identifies the STA that provides ASEL feedback. The frame exchange comprises the following steps: 14 15 a) (Optional) A transmit ASEL responder may initiate the transmit antenna selection training by send- 16 ing a +HTC frame with the ASEL Command subfield set to Transmit Antenna Selection Sounding 17 18 Request (TXASSR). 19 20 b) The ASEL transmitter sends out consecutive sounding PPDUs separated by SIFS in a TXOP of 21 which it is the TXOP holder with no ACK over different antenna sets, each PPDU containing a 22 +HTC frame with the ASEL Command subfield set to Transmit Antenna Selection Sounding Indica- 23 tion (TXASSI or TXASSI-CSI). Each sounding PPDU is transmitted over one antenna set. 24 25 26 If the ASEL transmitter allows antenna indices feedback (by setting the ASEL Command field to 27 TXASSI), the antenna sets from which the sounding PPDUs are transmitted shall be disjoint. If the 28 ASEL transmitter uses NDP sounding PPDUs for the antenna selection sounding, the spatial map- 29 ping matrix Qk shall be set equal to the identity matrix starting with the first NDP. If the ASEL 30 31 transmitter uses non-NDP sounding PPDUs for the antenna selection sounding, the spatial mapping 32 matrix Qk shall be an FFT matrix. An FFT matrix of size N is defined as a square matrix of dimen- 33 34 1 im sion NxN with entries wim , i=0,..N-1, m=0,..N-1 where wim = ------ exp –j2------. 35 N N 36 The ASEL transmitter shall not include TXASSI-CSI in the command field of the sounding frame if 37 38 the last received value of the Explicit CSI Feedback Capable subfield of the Antenna Selection 39 Capability field (see 7.3.2.56.7) from the receiver was zero. 40 41 NOTE—For example, in the case of sounding over all disjointed antenna sets, the number of consecutive 42 sounding PPDUs equals the smallest integer that is greater than or equal to the number of antennas divided by 43 the number of RF chains. These sounding PPDUs should be sent within a single TXOP. 44 45 c) The transmit ASEL responder estimates the subchannel corresponding to each sounding PPDU. 46 47 d) If the ASEL Command field in the sounding frames is set to TXASSI-CSI, after receiving all the 48 sounding PPDUs, the transmit ASEL responder shall respond with the full size channel state infor- 49 50 mation in a subsequent TXOP. If the ASEL Command field in the sounding frames is set to 51 TXASSI, after receiving all the sounding PPDUs, the transmit ASEL responder may either respond 52 with the full size channel state information in a subsequent TXOP, or conduct antenna selection 53 computation and provide the selected antenna indices in a subsequent TXOP. 54 55 1) Channel state information is transported using the MIMO CSI Matrices frame defined in 56 57 7.4.10.6 contained within either an Action No Ack or Action frame. Multiple CSI frames may 58 be required to provide the complete feedback, in which case the value of the Sounding Times- 59 tamp field within each of these CSI frames shall correspond to the arrival time of the sounding 60 frame that was used to generate the feedback information contained in the frame. 61 62 2) Antenna indices feedback is carried in the Antenna Selection Indices Feedback frame, defined 63 64 in 7.4.10.9. One octet of the antenna selection indices field is used to carry the selected antenna 65 indices feedback.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 If the transmit ASEL responder does not correctly receive all the sounding PPDUs, but having correctly re- 2 ceived at least one of the preceding sounding PPDUs, it shall send a +HTC frame with the MAI subfield set 3 4 to the value ASELI (see Table 7-6a) and the ASEL Command subfield set to No feedback, antenna selection 5 training failure, to indicate the failure of the antenna selection training process, and the ASEL Data subfield 6 set to either of: 7 8 — the integer value corresponding to the number in sequence of the first sounding PPDU that was not 9 10 properly received, where 0 corresponds to the first sounding PPDU in the antenna selection training 11 sequence, or 12 13 — zero. 14 15 16

17 + HTC frame Consecutive Sounding PPDUs 18 with NDP 19 20 Announce = 1 21 TXASSI NDP NDP 22 ASEL … 23 or SIFS SIFS Transmitter 24 TXASSI 25 TXASSI 26 SIFS 27 Segmented Segmented 28 sounding PPDU sounding PPDU

29 ASEL

30 Transmit TXASSR ASEL Feedback

Responder 31 32 (optional) Transmit Antenna Selection sounding 33 request 34 35 Figure 9-36—Transmit antenna selection 36 37 38 A transmit ASEL responder that determines that the antenna selection feedback is stale shall notify the ASEL 39 40 transmitter by transmitting a +HTC MPDU with the MAI subfield set to ASELI and the ASEL Command 41 subfield set to No feedback, antenna selection training failure and the ASEL Data subfield set to zero. 42 43 44 If, in response to the transmission of a sequence of sounding PPDUs, the ASEL transmitter receives a +HTC 45 MPDU with the MAI subfield set to ASELI and the ASEL Command subfield set to No feedback, antenna 46 47 selection training failure with a non-zero value in the ASEL Data field, indicating a failed antenna selection 48 training frame sequence, the ASEL transmitter may perform any of the following actions: 49 50 — do nothing 51 52 — restart the failed antenna selection training frame sequence from the point of failure by transmitting a 53 +HTC MPDU with the MAI subfield set to ASELI and the ASEL Command subfield set to TXASSR 54 55 with a non-zero value in the ASEL Data field, corresponding to the command Transmit Antenna 56 Selection Sounding Resumption (a Resumption MPDU), where the ASEL Data field value is the 57 order number (from the original training frame sequence) of the first sounding PPDU transmitted in 58 59 the restarted antenna selection training frame sequence, where 0 corresponds to the first sounding 60 PPDU in the original antenna selection training sequence 61 62 — execute a new antenna selection training frame sequence by transmitting a +HTC MPDU with the 63 64 MAI subfield set to ASELI and the ASEL Command subfield set to TXASSI or TXASSI-CSI with a 65 non-zero value in the ASEL Data field

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 If a transmit ASEL responder receives a +HTC MPDU with the MAI subfield set to ASELI and the ASEL 2 Command subfield set to TXASSR with a non-zero value in the ASEL Data field, corresponding to the com- 3 mand Transmit Antenna Selection Sounding Resumption (a Resumption MPDU), when the transmit ASEL 4 5 responder transmits a response to the training sequence, it shall respond according to the original command 6 value (i.e., TXASSI or TXASSI-CSI) and shall assume a total number of sounding PPDUs that corresponds 7 to the number of sounding PPDUs from the original command frame. The number of sounding frames that 8 follows the Resumption MPDU is equal to the number of sounding PPDUs from the original command frame 9 minus the order number transmitted in the ASEL Data field of the Resumption MPDU. 10 11 12 The frame exchange sequence for receive antenna selection is shown in Figure 9-37, where the term ASEL 13 receiver identifies the STA that is conducting receive antenna selection, and the term ASEL sounding capable 14 transmitter identifies the STA sending the consecutive sounding PPDUs used for receive antenna selection 15 16 calculations. The frame exchange comprises the following steps: 17 — The ASEL receiver transmits a +HTC frame with the MAI field set to ASELI, the ASEL Command 18 19 subfield set to Receive Antenna Selection Request (RXASSR) and the ASEL Data subfield set to the 20 number of sounding PPDUs required. 21 NOTE— For example, in case of sounding over all disjointed antenna sets, the number of total consecutive 22 sounding PPDUs or NDPs equals the smallest integer that is greater than or equal to the number of antennas 23 divided by the number of RF chains. 24 25 — The ASEL sounding capable transmitter responds with the corresponding number of sounding 26 27 PPDUs in its subsequent TXOP. These PPDUs are separated by SIFS. When using non-NDP sound- 28 ing, each PPDU contains a +HTC frame in which the MAI field is set to ASELI, the ASEL Com- 29 mand field is set to Receive Antenna Selection Sounding Indication (RXASSI), and the ASEL Data 30 subfield is set to the remaining number of sounding PPDUs to be transmitted. When using NDP 31 sounding, the PPDU that precedes the first NDP contains a +HTC frame in which the NDP 32 33 Announce field is set to 1, the MAI field is set to ASELI, the ASEL Command field is set to 34 RXASSI and the ASEL Data field is set to the remaining number of sounding PPDUs to be transmit- 35 ted. 36 37 38 Consecutive Sounding PPDUs 39 + HTC frame

40 with NDP

41 announce = 1 42 43 RXASSI NDP NDP … 44 Capable or SIFS SIFS 45 Transmitter

ASEL Sounding 46 RXASSI RXASSI 47 SIFS 48 Segmented Segmented 49 sounding PPDU sounding PPDU 50 ASEL ASEL

51 Receiver 52 RXASSR 53 ASEL Receiver transmits a Receive 54 Antenna Selection Sounding Request 55 56 Figure 9-37—Receive antenna selection 57 58 59 The ASEL receiver uses different antenna sets to receive these sounding PPDUs, estimates channel state in- 60 formation after receiving all these sounding PPDUs, and conducts the antenna selection. 61 62 When transmitting the consecutive sounding PPDUs in transmit and receive ASEL exchanges (illustrated in 63 64 Figure 9-36 and Figure 9-37), the transmitter shall not change the TXPWR_LEVEL parameter of the TX- 65 VECTOR.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 When transmitting a sounding PPDU sent in transmit and receive ASEL exchanges (illustrated in Figure 9- 2 36 and Figure 9-37), if the Receive Staggered Capability subfield of the Transmit Beamforming Capability 3 field of the HT Capabilities element transmitted by the intended receiver is zero, then: 4 5 — If the sounding PPDU is not an NDP, the number of antennas used by the sender, as indicated by the 6 ANTENNA_SET parameter in the TXVECTOR, shall be less than or equal to the maximum number 7 of space time streams indicated by the Rx MCS Bitmask subfield of the Supported MCS Set field 8 9 and the Rx STBC subfield of the HT Capabilities element transmitted by the intended receiver. 10 — If the sounding PPDU is an NDP, the number of antennas used by the sender, as indicated by the 11 ANTENNA_SET parameter in the TXVECTOR, shall be less than or equal to the number indicated 12 by the Channel Estimation Capability subfield of the Transmit Beamforming Capability field of the 13 14 HT Capabilities element transmitted by the intended receiver. 15 16 When both transmitter and receiver have antenna selection capabilities the following constraints apply: 17 18 — During a transmit antenna selection frame exchange, the transmit ASEL responder shall use a subset 19 of antennas that does not change during the reception of all of the sounding PPDUs of the ASEL 20 sounding sequence. 21 22 — During a receive antenna selection frame exchange, the ASEL sounding capable transmitter shall use 23 a subset of antennas that does not change during the transmission of all of the sounding PPDUs of 24 the ASEL sounding sequence. 25 NOTE—When a receiver (either a transmit ASEL responder or an ASEL receiver) conducts antenna selection computa- 26 tions (for either transmit or receive antenna selection), if there is no transmit beamforming conducted at the same time, 27 28 to achieve the best performance of antenna selection, the receiver should assume that the first NSTS columns of the 29 same spatial mapping matrix Q used for transmitting antenna selection sounding PPDUs, where N is the number 30 k STS 31 of space time streams, will be applied for the spatial mapping at the ASEL transmitter after the ASEL exchange as in 32 Figure 9-36 and Figure 9-37. To achieve the best performance of antenna selection, the ASEL transmitter should apply 33 the first NSTS columns of the same Qk for spatial mapping after the antenna selection exchange as in Figure 9-36 and 34 Figure 9-37. 35 36 37 9.21 Null Data Packet (NDP) sounding 38 39 40 9.21.1 NDP Rules 41 42 Sounding may be accomplished using either staggered sounding PPDU or NDP, as described in 20.3.13. The 43 MAC rules associated with sounding using NDP are described in 9.21.1 to 9.21.4. 44 45 46 An HT STA that has set the Receive NDP Capable field of its HT Capabilities element to 1 during association, 47 processes an NDP as a sounding packet if the destination of the sounding packet is determined to match itself 48 as described in 9.21.3, and if the source of the sounding packet can be ascertained as described in 9.21.4. 49 50 An RXVECTOR LENGTH parameter set to 0 indicates that the PPDU is an NDP. 51 52 53 A STA that is a TXOP holder or an RD responder shall not set both the NDP Announcement and RDG/More 54 PPDU fields to 1 simultaneously. The Calibration Position field shall not be set to any value except 0 and 1 55 in any +HTC frame in a PPDU that is also an NDP Announcement. The Calibration Position field shall be set 56 to 0 in any +HTC frame in a PPDU that is an NDP Announcement that also contains any +HTC frame with 57 58 the MAI field set to ASELI. The Calibration Position field shall be set to 0 in all +HTC frames in a PPDU 59 that is an NDP Announcement and that contains any +HTC frame with the MRQ field set to 1. The TRQ field 60 shall be set to 0 in all +HTC frames in a PPDU that is an NDP Announcement. 61 62 An NDP sequence contains at least one non-NDP PPDU and at least one NDP PPDU. Only one PPDU in the 63 64 NDP sequence may contain an NDP announcement. An NDP sequence begins with an NDP announcement. 65 The NDP sequence ends at the end of the transmission of the last NDP PPDU that is announced by the NDP

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 announcement. A STA that transmits the first PPDU of an NDP sequence is the NDP sequence owner. In the 2 NDP sequence, only PPDUs carrying NDP and PPDUs carrying non-A-MPDU control frames may follow 3 the NDP sequence's starting PPDU. 4 5 6 A STA shall transmit only one NDP per NDP announcement, unless the NDP Announcement includes a value 7 in the ASEL Data subfield of the ASEL Command subfield of the HTC Control field that is greater than one. 8 Each PPDU in an NDP sequence shall start a SIFS interval after end of the previous PPDU. 9 10 11 The +HTC field of a CTS frame shall not contain the NDP Announcement field set to 1. 12 NOTE—A CTS frame cannot be used for NDP announcement: if the CTS frame is a response to an RTS frame, the 13 optional NAV reset timeout that starts at the end of the RTS frame does not include the additional NDP and SIFS dura- 14 tion (see 9.2.5.4). Also if the CTS were the first frame of an NDP sequence it would not be possible to determine the des- 15 tination address of the NDP. 16 17 A STA shall transmit an NDP as follows: 18 19 a) A SIFS interval after sending a PPDU that is an NDP Announcement and that does not contain an 20 MPDU that requires an immediate response. 21 22 b) A SIFS interval after successfully receiving a correctly formed and addressed immediate response to 23 a PPDU that is an NDP announcement and that contains an MPDU that requires an immediate 24 response. 25 c) A SIFS interval after transmitting an NDP if the NDP announcement contains an ASEL Command 26 27 field set to TXASSI, TXASSI-CSI or RXASSI and the ASEL Data field is set to value greater than 28 zero, and the number of NDPs sent before this one is less that the value in the ASEL Data field + 1. 29 NOTE—The total number of sent NDPs is equal to the value of in the ASEL Data field + 1. 30 31 d) A SIFS interval after receiving an NDP from a STA whose NDP announcement contained one or 32 more +HTC frames with the Calibration Position field set to 1, when the receiving STA supports 33 transmitting sounding PPDUs for which more than one channel dimensions can be estimated (i.e., 34 35 more than one column of the MIMO channel matrix). 36 37 This rule enables the NDP receiver to know that it will receive an NDP and can determine the source and 38 destination of the NDP. It enables the receiver and transmitter to know when the immediate response and 39 40 NDP will be transmitted relative to the frame containing the NDP announcement indication. 41 42 A STA that has transmitted an NDP announcement in a frame that requires an immediate response, and that 43 does not receive the response expected shall terminate the NDP sequence at that point (i.e., the STA does not 44 transmit an NDP in the current NDP sequence). 45 46 47 A STA that has received an NDP announcement in a +HTC with the Calibration Position set to 1 or 2, and 48 that does not receive the NDP PPDU expected shall terminate the NDP sequence at that point (i.e., does not 49 transmit an NDP in the current NDP sequence) and not transmit any further frames that are a part of this cal- 50 ibration sequence shown in Step 1 of Figure 9-34. 51 52 53 Feedback information generated from the reception of an NDP is transmitted using any of the feedback rules 54 and signaling as appropriate, e.g., immediate or delayed. 55 56 57 9.21.2 Transmission of an NDP 58 59 A STA that transmits an NDP shall set the LENGTH, MCS, SOUNDING, STBC and NUM_EXTEN_SS pa- 60 rameters of the TXVECTOR as specified in this subclause. 61 62 — LENGTH shall be set to 0. 63 — SOUNDING shall be set to SOUNDING. 64 65 — STBC shall be set to 0.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 — MCS shall indicate two or more spatial streams. 2 3 The number of spatial streams sounded is indicated by the MCS parameter of the TXVECTOR, and shall not 4 5 exceed the limit indicated by the Channel Estimation Capability field in the Transmit Beamforming Capabil- 6 ities field transmitted by the STA that is the intended receiver of the NDP. The MCS parameter may be set to 7 any value, subject to the constraint of the previous sentence, regardless of the value of the Supported MCS 8 Set field of the HT Capabilities field at either the transmitter or recipient of the NDP. A STA shall set the 9 NUM_EXTEN_SS parameter of the TXVECTOR to zero in the PHY-TXSTART.request primitive corre- 10 11 sponding to an NDP transmission. 12 13 A STA shall not transmit an NDP announcement with a receiver address corresponding to another STA unless 14 it has received an HT Capabilities element from the destination STA in which the Receive NDP Capable field 15 is set to 1. 16 17 18 9.21.3 Determination of NDP destination 19 20 The destination of an NDP is determined at the NDP receiver by examining the NDP Announcement as fol- 21 lows: 22 23 — The destination of the first NDP in the NDP sequence is equal to the RA of any MPDU within NDP 24 Announcement. 25 26 — If Calibration Position field is set to 1 in the NDP announcement at the NDP receiver, the destination 27 of the second NDP is equal to the TA of that frame. Otherwise, the destination of the second and any 28 subsequent NDPs is equal to the destination of the previous NDP. 29 30 See T.4 for an illustration of these rules. 31 32 33 9.21.4 Determination of NDP source 34 35 The source of an NDP is determined at the NDP receiver by examining the NDP sequences’s starting PPDU 36 as follows: 37 38 — If any MPDU within the NDP Announcement contains two or more addresses, the source of the first 39 NDP is equal to the TA of that frame. 40 41 — Otherwise (the NDP Announcement contains one address) the source of the first NDP is equal to the 42 RA of the MPDU to which the NDP Announcement is a response. 43 — If the Calibration Position field is set to 1 in an MPDU in the NDP Announcement, the source of the 44 45 second NDP is equal to the RA of that MPDU. Otherwise, the source of the second and any subse- 46 quent NDPs is equal to the source of the previous NDP. 47 48 See T.4 for an illustration of these rules. 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 10. Layer management 2 3 4 10.3 MLME SAP interface 5 6 7 10.3.2 Scan 8 9 10 10.3.2.2 MLME-SCAN.confirm 11 12 10.3.2.2.2 Semantics of the service primitive 13 14 15 Change the second paragraph of 10.3.2.2.2 as follows: 16 17 Each BSSDescription consists of the following elements shown in the following table.: The IBSS adoption 18 column indicates whether: 19 20 a) this parameter is adopted by a STA that is joining an IBSS, 21 22 b) this parameter is adopted by a STA that is a member of an IBSS that receives a beacon from a STA 23 that is a member of the same IBSS and that has a timestamp value that is greater than the local TSF 24 value (see 11.1.4). 25 26 27 Change the table defining BSSDescription in 10.3.2.2.2 by adding a new column to the right labelled 28 “IBSS adoption” and insert the value “Adopt” for all entries, except those cited in the following editorial 29 instruction. 30 31 Change the rows shown below in the table defining BSSDescription in 10.3.2.2.2 as follows: 32 33 34 35 IBSS 36 Name Type Valid range Description 37 adoption 38 39 Local Time Integer N/A The value of the STA’s TSF timer at the start Do not adopt 40 of reception of the first octet of the times- 41 tamp field of the received frame (probe 42 response or beacon) from the found BSS. 43 CF Parame- As defined As defined in The parameter set for the CF periods, if Do not adopt 44 ter Set in frame for- frame format found BSS supports CF mode. 45 mat 7.3.2.5 46 47 Capability- As defined As defined in The advertised capabilities of the BSS. Do not adopt 48 Information in frame for- frame format 49 mat 7.3.1.4 50 51 Operational- Set of inte- 1–127 inclusive The set of data rates that the STA desires to Do not adopt 52 RateSet gers (for each integer use for communication within the BSS. The 53 in the set) STA must be able to receive at each of the 54 data rates listed in the set. This set is a super- 55 set of the rates contained in the BSSBasi- 56 cRateSet parameter. 57 58 RSN RSN infor- As defined in A description of the cipher suites and AKM Do not adopt 59 mation ele- frame format suites supported in the BSS 60 ment 7.3.2.25 61 62 Load As defined As defined in The values from the BSS Load information Do not adopt 63 in frame for- frame format element if such an element was present in 64 mat 7.3.2.28 the probe response or Beacon frame, else 65 null.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Insert the following entries at the end of the table defining BSSDescription in 10.3.2.2.2 as follows: 2 3 4 5 Table defining BSSDescription in 10.3.2.2.2 6 7 IBSS 8 Name Type Valid range Description adoption 9 10 HT Capabili- As defined As defined in The values from the HT Capabilities ele- Do not adopt 11 ties in frame for- 7.3.2.56 ment if such an element was present in the 12 mat Probe Response or Beacon frame, else null. 13 The parameter may be present only if the 14 MIB attribute 15 dot11HighThroughputOptionImplemented 16 is TRUE. 17 18 HT Opera- As defined As defined in The values from the HT Operation element Adopt 19 tion in frame for- 7.3.2.57 if such an element was present in the Probe 20 mat Response or Beacon frame, else null. 21 The parameter may be present only if the 22 MIB attribute 23 dot11HighThroughputOptionImplemented 24 is TRUE. 25 26 BSSMem- set of inte- A value from The BSS membership selectors that repre- Adopt 27 bershipSe- gers Table 7-26a for sent the set of features that shall be sup- 28 lectorSet each member of ported by all STAs to join this BSS. 29 the set 30 31 BSSBasic- Set of inte- Each member of The set of MCS values that shall be sup- Adopt 32 MCSSet gers the set takes a ported by all HT STAs to join this BSS. The 33 value in the STA that is creating the BSS shall be able to 34 range 0 to 76, receive and transmit at each of the MCS val- 35 representing an ues listed in the set. 36 MCS index 37 value 38 39 HTOpera- Set of inte- Each member of The set of MCS values that the STA desires Do not adopt 40 tionalMCS- gers the set takes a to use for communication within the BSS. 41 Set value in the The STA must be able to receive at each of 42 range 0 to 76, the data rates listed in the set. This set is a 43 representing an superset of the MCS values contained in the 44 MCS index BSSBasicMCSSet parameter. 45 value 46 Extended As defined As defined in Specifies the parameters within the Do not adopt 47 Capabilities in frame for- 7.3.2.27 Extended Capabilities element that are sup- 48 mat ported by the MAC entity. The parameter 49 shall be present if the MIB attribute 50 dot112040BSSCoexistenceManagementSup 51 port is TRUE. 52 53 20/40 BSS As defined As defined in Specifies the parameters within the 20/40 Do not adopt 54 Coexistence in frame for- 7.3.2.60 BSS Coexistence element that are indicated 55 mat by the MAC entity. The parameter shall be 56 present if the MIB attribute 57 dot112040BSSCoexistenceManagementSup 58 port is TRUE. 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table defining BSSDescription in 10.3.2.2.2 (continued) 2 3 4 IBSS Name Type Valid range Description 5 adoption 6 7 Overlapping As defined As defined in Specifies the parameters within the Overlap- Adopt 8 BSS Scan in frame for- 7.3.2.59 ping BSS Scan Parameters element that are 9 Parameters mat indicated by the MAC entity. This parameter 10 may be present if the 11 dot11FortyMHzOptionImplemented 12 attribute is TRUE and shall not be present if 13 the dot11FortyMHzOptionImplemented 14 attribute is false. 15 16 17 18 10.3.3 Synchronization 19 20 10.3.3.1 MLME-JOIN.request 21 22 23 10.3.3.1.2 Semantics of the service primitive 24 25 Change the primitive parameters in 10.3.3.1.2 as follows: 26 27 MLME-JOIN.request( 28 29 SelectedBSS, 30 JoinFailureTimeout, 31 ProbeDelay, 32 OperationalRateSet, 33 HTOperationalMCSSet, 34 35 VendorSpecificInfo 36 ) 37 38 Insert the following entries in the table in 10.3.3.1.2 immediately before the row for VendorSpecificInfo: 39 40 41 42 Name Type Valid range Description 43 44 HTOperation- Set of integers Each member of the The set of MCS values that the STA desires to use for 45 alMCSSet set takes a value in communication within the BSS. The STA must be able 46 the range 0 to 76, to receive at each of the data rates listed in the set. 47 representing an MCS This set is a superset of the MCS values contained in 48 index value the BSSBasicMCSSet parameter. 49 50 51 52 10.3.3.1.4 Effect of receipt 53 54 55 Insert the following two paragraphs after the first paragraph of 10.3.3.1.4: 56 57 If an MLME receives an MLME-JOIN.request with the SelectedBSS parameter containing a BSSBasicRate- 58 59 Set element that contains any unsupported rates, the MLME response in the resulting MLME-JOIN.confirm 60 shall contain a ResultCode parameter that is not set to the value SUCCESS. 61 62 If the MLME of an HT STA receives an MLME-JOIN.request with the SelectedBSS parameter containing a 63 64 BasicMCSSet element that contains any unsupported MCSs, the MLME response in the resulting MLME- 65 JOIN.confirm shall contain a ResultCode parameter that is not set to the value SUCCESS.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 10.3.6 Associate 2 3 10.3.6.1 MLME-ASSOCIATE.request 4 5 6 10.3.6.1.2 Semantics of the service primitive 7 8 Change the primitive parameters in 10.3.6.1.2 as follows: 9 10 MLME-ASSOCIATE.request( 11 PeerSTAAddress, 12 AssociateFailureTimeout, 13 CapabilityInformation, 14 ListenInterval, 15 Supported Channels, 16 RSN, 17 QoSCapability, 18 Content of FT Authentication Information Elements, 19 SupportedRegulatoryClasses, 20 HT Capabilities, 21 Extended Capabilities, 22 20/40 BSS Coexistence, 23 VendorSpecificInfo 24 ) 25 26 Insert the following entries in the table in 10.3.6.1.2 immediately before the row for VendorSpecificInfo: 27 28 29 30 31 Name Type Valid range Description 32 33 HT Capabilities As defined in As defined in Specifies the parameters within the HT Capabili- 34 frame format 7.3.2.56 ties element that are supported by the MAC entity. 35 The parameter shall be present if the MIB 36 attribute 37 dot11HighThroughputOptionImplemented is 38 TRUE and shall be absent otherwise . 39 Extended Capabilities As defined in As defined in Specifies the parameters within the Extended 40 frame format 7.3.2.27 Capabilities element that are supported by the 41 MAC entity. The parameter shall be present if the 42 MIB attribute 43 dot112040BSSCoexistenceManagementSupport 44 is TRUE. 45 46 20/40 BSS Coexistence As defined in As defined in Specifies the parameters within the 20/40 BSS 47 frame format 7.3.2.60 Coexistence element that are indicated by the 48 MAC entity. The parameter shall be present if the 49 MIB attribute 50 dot112040BSSCoexistenceManagementSupport 51 is TRUE. 52 53 54 55 10.3.6.2 MLME-ASSOCIATE.confirm 56 57 58 10.3.6.2.2 Semantics of the service primitive 59 60 Change the primitive parameters of 10.3.6.2.2 as shown: 61 62 MLME-ASSOCIATE.confirm( 63 ResultCode, 64 CapabilityInformation, 65 AssociationID,

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 SupportedRates, 2 EDCAParameterSet, 3 RCPI.request, 4 RSNI.request, 5 RCPI.response, 6 RSNI.response, 7 RRMEnabledCapabilities 8 Content of FT Authentication Information Elements, 9 SupportedRegulatoryClasses, 10 HT Capabilities, 11 Extended Capabilities, 12 20/40 BSS Coexistence, 13 VendorSpecificInfo 14 ) 15 16 Insert the following entries in the table in 10.3.6.2.2 immediately before the row for VendorSpecificInfo: 17 18 19 20 Name Type Valid range Description 21 22 HT Capabilities As defined in As defined in Specifies the parameters within the HT Capabili- 23 frame format 7.3.2.56 ties element that are to be used by the peer MAC 24 entity (AP). The parameter may be present if the 25 MIB attribute 26 dot11HighThroughputOptionImplemented is 27 TRUE, otherwise this parameter shall not be 28 present. 29 30 Extended Capabilities As defined in As defined in Specifies the parameters within the Extended 31 frame format 7.3.2.27 Capabilities element that are supported by the 32 MAC entity. The parameter shall be present if the 33 MIB attribute 34 dot112040BSSCoexistenceManagementSupport 35 is TRUE. 36 37 20/40 BSS Coexistence As defined in As defined in Specifies the parameters within the 20/40 BSS 38 frame format 7.3.2.60 Coexistence element that are indicated by the 39 MAC entity. The parameter shall be present if the 40 MIB attribute 41 dot112040BSSCoexistenceManagementSupport 42 is TRUE. 43 44 45 46 10.3.6.3 MLME-ASSOCIATE.indication 47 48 10.3.6.3.2 Semantics of the service primitive 49 50 51 Change the primitive parameters of 10.3.6.3.2 as shown: 52 53 MLME-ASSOCIATE.indication( 54 PeerSTAAddress, 55 CapabilityInformation, 56 ListenInterval, 57 SSID, 58 SupportedRates, 59 RSN, 60 QoSCapability, 61 RCPI, 62 RSNI, 63 RRMEnabledCapabilities, 64 Content of FT Authentication Information Elements, 65 SupportedRegulatoryClasses,

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 DSEregisteredlocation, 2 HT Capabilities, 3 4 Extended Capabilities, 5 20/40 BSS Coexistence, 6 VendorSpecificInfo 7 8 ) 9 10 Insert the following entries in the table in 10.3.6.3.2 immediately before the row for VendorSpecificInfo: 11 12 13 14 Name Type Valid range Description 15 16 HT Capabilities As defined in As defined in Specifies the parameters within the HT Capabili- 17 frame format 7.3.2.56 ties element that are supported by the peer MAC 18 entity. The parameter may be present only if the 19 MIB attribute 20 dot11HighThroughputOptionImplemented is 21 TRUE. 22 23 Extended Capabilities As defined in As defined in Specifies the parameters within the Extended 24 frame format 7.3.2.27 Capabilities element that are supported by the 25 MAC entity. The parameter shall be present if the 26 MIB attribute 27 dot112040BSSCoexistenceManagementSupport 28 is TRUE. 29 30 20/40 BSS Coexistence As defined in As defined in Specifies the parameters within the 20/40 BSS 31 frame format 7.3.2.60 Coexistence element that are indicated by the 32 MAC entity. The parameter shall be present if the 33 MIB attribute 34 dot112040BSSCoexistenceManagementSupport 35 is TRUE. 36 37 38 39 10.3.6.4 MLME-ASSOCIATE.response 40 41 42 10.3.6.4.2 Semantics of the service primitive 43 44 Change the primitive parameters in 10.3.6.4.2 as shown: 45 46 47 MLME-ASSOCIATE.response( 48 PeerSTAAddress, 49 ResultCode, 50 CapabilityInformation, 51 AssociationID, 52 EDCAParameterSet, 53 RCPI, 54 55 RSNI, 56 RRMEnabledCapabilities, 57 Content of FT Authentication Information Elements, 58 59 SupportedRegulatoryClasses, 60 DSEREgisteredLocation, 61 HTCapabilities, 62 Extended Capabilities, 63 20/40 BSS Coexistence, 64 VendorSpecificInfo 65 )

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Insert the following entries immediately before the row for VendorSpecificInfo in the parameter table: 2 3 4 5 Name Type Valid range Description 6 7 HT Capabilities As defined in As defined in Specifies the parameters within the HT Capabili- 8 frame format 7.3.2.56 ties element that are supported by the peer MAC 9 entity. The parameter shall be present if the MIB 10 attribute 11 dot11HighThroughputOptionImplemented is 12 TRUE and shall be absent otherwise . 13 14 Extended Capabilities As defined in As defined in Specifies the parameters within the Extended 15 frame format 7.3.2.27 Capabilities element that are supported by the 16 MAC entity. The parameter shall be present if the 17 MIB attribute 18 dot112040BSSCoexistenceManagementSupport 19 is TRUE. 20 21 20/40 BSS Coexistence As defined in As defined in Specifies the parameters within the 20/40 BSS 22 frame format 7.3.2.60 Coexistence element that are indicated by the 23 MAC entity. The parameter shall be present if the 24 MIB attribute 25 dot112040BSSCoexistenceManagementSupport 26 is TRUE. 27 28 29 30 10.3.7 Reassociate 31 32 10.3.7.1 MLME-REASSOCIATE.request 33 34 35 10.3.7.1.2 Semantics of the service primitive 36 37 Change the primitive parameters in 10.3.7.1.2 as follows: 38 39 MLME-REASSOCIATE.request( 40 NewAPAddress, 41 ReassociateFailureTimeout, 42 CapabilityInformation, 43 ListenInterval, 44 Supported Channels, 45 RSN, 46 QoSCapability, 47 Content of FT Authentication Information Elements, 48 SupportedRegulatoryClasses, 49 HT Capabilities, 50 Extended Capabilities, 51 20/40 BSS Coexistence, 52 VendorSpecificInfo 53 ) 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Insert the following entries in the table in 10.3.7.1.2 immediately before the row for VendorSpecificInfo: 2 3 4 5 Name Type Valid range Description 6 7 HT Capabilities As defined in As defined in Specifies the parameters within the HT Capabili- 8 frame format 7.3.2.56 ties element that are supported by the MAC entity. 9 The parameter shall be present if the MIB 10 attribute 11 dot11HighThroughputOptionImplemented is 12 TRUE and shall be absent otherwise. 13 14 Extended Capabilities As defined in As defined in Specifies the parameters within the Extended 15 frame format 7.3.2.27 Capabilities element that are supported by the 16 MAC entity. The parameter shall be present if the 17 MIB attribute 18 dot112040BSSCoexistenceManagementSupport 19 is TRUE. 20 21 20/40 BSS Coexistence As defined in As defined in Specifies the parameters within the 20/40 BSS 22 frame format 7.3.2.60 Coexistence element that are indicated by the 23 MAC entity. The parameter shall be present if the 24 MIB attribute 25 dot112040BSSCoexistenceManagementSupport 26 is TRUE. 27 28 29 30 10.3.7.2 MLME-REASSOCIATE.confirm 31 32 33 10.3.7.2.2 Semantics of the service primitive 34 35 36 Change the primitive parameters in 10.3.7.2.2 as follows: 37 38 MLME-REASSOCIATE.confirm( 39 40 ResultCode, 41 42 CapabilityInformation, 43 AssociationID, 44 45 SupportedRates, 46 EDCAParameterSet, 47 48 RCPI.request, 49 RSNI.request, 50 51 RCPI.response, 52 RSNI.response, 53 54 RRMEnabledCapabilities, 55 56 Content of FT Authentication Information Elements, 57 SupportedRegulatoryClasses, 58 59 HT Capabilities, 60 Extended Capabilities, 61 62 20/40 BSS Coexistence, 63 VendorSpecificInfo 64 65 )

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Insert the following entries in the table in 10.3.7.2.2 immediately before the row for VendorSpecificInfo: 2 3 4 5 Name Type Valid range Description 6 7 HT Capabilities As defined in As defined in Specifies the parameters within the HT Capabili- 8 frame format 7.3.2.56 ties element that are to be used by the peer MAC 9 entity (AP). The parameter may be present only if 10 the MIB attribute 11 dot11HighThroughputOptionImplemented is 12 TRUE. 13 14 Extended Capabilities As defined in As defined in Specifies the parameters within the Extended 15 frame format 7.3.2.27 Capabilities element that are supported by the 16 MAC entity. The parameter shall be present if the 17 MIB attribute 18 dot112040BSSCoexistenceManagementSupport 19 is TRUE. 20 21 20/40 BSS Coexistence As defined in As defined in Specifies the parameters within the 20/40 BSS 22 frame format 7.3.2.60 Coexistence element that are indicated by the 23 MAC entity. The parameter shall be present if the 24 MIB attribute 25 dot112040BSSCoexistenceManagementSupport 26 is TRUE. 27 28 29 30 10.3.7.3 MLME-REASSOCIATE.indication 31 32 33 10.3.7.3.2 Semantics of the service primitive 34 35 36 Change the primitive parameters in 10.3.7.3.2 as follows: 37 38 MLME-REASSOCIATE.indication( 39 PeerSTAAddress, 40 41 CurrentAPAddress, 42 CapabilityInformation, 43 44 ListenInterval, 45 SSID, 46 SupportedRates, 47 48 RSN, 49 QoSCapability, 50 51 RCPI, 52 RSNI, 53 54 RRMEnabledCapabilities, 55 Content of FT Authentication Information Elements, 56 SupportedRegulatoryClasses, 57 58 DSERegisteredlocation, 59 HT Capabilities, 60 61 Extended Capabilities, 62 20/40 BSS Coexistence, 63 VendorSpecificInfo 64 65 )

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Insert the following entries in the table in 10.3.7.3.2 immediately before the row for VendorSpecificInfo: 2 3 4 5 Name Type Valid range Description 6 7 HT Capabilities As defined in As defined in Specifies the parameters within the HT 8 frame format 7.3.2.56 Capabilities element that are supported by the 9 peer MAC entity. The parameter may be present 10 only if the MIB attribute 11 dot11HighThroughputOptionImplemented is 12 TRUE. 13 14 Extended Capabilities As defined in As defined in Specifies the parameters within the Extended 15 frame format 7.3.2.27 Capabilities element that are supported by the 16 MAC entity. The parameter shall be present if the 17 MIB attribute 18 dot112040BSSCoexistenceManagementSupport 19 is TRUE. 20 21 20/40 BSS Coexistence As defined in As defined in Specifies the parameters within the 20/40 BSS 22 frame format 7.3.2.60 Coexistence element that are indicated by the 23 MAC entity. The parameter shall be present if the 24 MIB attribute 25 dot112040BSSCoexistenceManagementSupport 26 is TRUE. 27 28 29 30 10.3.7.4 MLME-REASSOCIATE.response 31 32 10.3.7.4.2 Semantics of the service primitive 33 34 Change the primitive parameter list of 10.3.7.4.2 as shown: 35 36 MLME-REASSOCIATE.response( 37 PeerSTAAddress, 38 ResultCode, 39 CapabilityInformation, 40 AssociationID, 41 EDCAParameterSet, 42 RCPI, 43 RSNI, 44 RRMEnabledCapabilities, 45 Content of FT Authentication Information Elements, 46 SupportedRegulatoryClasses, 47 DSERegisteredlocation, 48 HTCapabilities, 49 Extended Capabilities, 50 20/40 BSS Coexistence, 51 VendorSpecificInfo 52 ) 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Insert the following entries in the table in 10.3.7.4.2 immediately before the row for VendorSpecificInfo 2 in the parameter table: 3 4 5 6 7 Name Type Valid Range Description 8 9 HT Capabilities As defined in As defined in Specifies the parameters within the HT 10 frame format 7.3.2.56 Capabilities element that are supported by the peer MAC 11 entity. The parameter shall be present if the MIB attribute 12 dot11HighThroughputOptionImplemented is TRUE and 13 shall be absent otherwise. 14 Extended Capabili- As defined in As defined in Specifies the parameters within the Extended Capabilities 15 ties frame format 7.3.2.27 element that are supported by the MAC entity. The param- 16 eter shall be present if the MIB attribute 17 dot112040BSSCoexistenceManagementSupport is TRUE. 18 19 20/40 BSS Coexist- As defined in As defined in Specifies the parameters within the 20/40 BSS Coexist- 20 ence frame format 7.3.2.60 ence element that are indicated by the MAC entity. The 21 parameter shall be present if the MIB attribute 22 dot112040BSSCoexistenceManagementSupport is TRUE. 23 24 25 26 10.3.10 Start 27 28 29 10.3.10.1 MLME-START.request 30 31 10.3.10.1.2 Semantics of the service primitive 32 33 34 Change the primitive parameters in 10.3.10.1.2 as follows: 35 36 MLME-START.request( 37 SSID, 38 BSSType, 39 BeaconPeriod, 40 DTIMPeriod, 41 42 CF parameter set, 43 PHY parameter set, 44 IBSS parameter set, 45 ProbeDelay, 46 CapabilityInformation, 47 BSSBasicRateSet, 48 49 OperationalRateSet, 50 Country, 51 IBSS DFS Recovery Interval, 52 EDCAParameterSet, 53 DSERegisteredLocation, 54 HT Capabilities, 55 56 HT Operation, 57 BSSMembershipSelectorSet, 58 BSSBasicMCSSet, 59 HTOperationalMCSSet, 60 Extended Capabilities, 61 20/40 BSS Coexistence, 62 63 Overlapping BSS Scan Parameters, 64 VendorSpecificInfo 65 )

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Insert the following eight entries in the table in 10.3.10.1.2 immediately before the row for 2 VendorSpecificInfo: 3 4 5 6 Name Type Valid range Description 7 8 HT Capabilities As defined in As defined in The HT capabilities to be advertised for the BSS. 9 frame format 7.3.2.56 The parameter shall be present if the MIB 10 HT Capabili- attribute 11 ties element dot11HighThroughputOptionImplemented is 12 TRUE, otherwise this parameter shall not be 13 present. 14 15 HT Operation As defined in As defined in The additional HT capabilities to be advertised 16 frame format 7.3.2.57 for the BSS. 17 HT Operation The parameter shall be present if BSSType = 18 element INFRASTRUCTURE and the MIB attribute 19 dot11HighThroughputOptionImplemented is 20 TRUE, otherwise this parameter shall not be 21 present. 22 23 BSSMembershipSelec- Set of integers A value from The BSS membership selectors that represent the 24 torSet Table 7-26a for set of features that shall be supported by all STAs 25 each member of to join this BSS. The STA that is creating the BSS 26 the set shall be able to support each of the features repre- 27 sented by the set. 28 29 BSSBasicMCSSet Set of integers Each member The set of MCS values that shall be supported by 30 of the set takes all HT STAs to join this BSS. The STA that is cre- 31 a value in the ating the BSS shall be able to receive and transmit 32 range 0 to 76, at each of the MCS values listed in the set. If the 33 representing an HT Operation parameter includes a value of 1 for 34 MCS index either the Dual Beacon field or the Dual CTS Pro- 35 value tection field, the BSSBasicMCSSet parameter 36 shall include at least one integer value in the 37 range 0 to 7. 38 39 HTOperationalMCSSet Set of integers Each member The set of MCS values that the STA desires to use 40 of the set takes for communication within the BSS. The STA 41 a value in the must be able to receive at each of the data rates 42 range 0 to 76, listed in the set. This set is a superset of the MCS 43 representing an values contained in the BSSBasicMCSSet param- 44 MCS index eter. 45 value 46 Extended Capabilities As defined in As defined in Specifies the parameters within the Extended 47 frame format 7.3.2.27 Capabilities element that are supported by the 48 MAC entity. The parameter shall be present if the 49 MIB attribute 50 dot112040BSSCoexistenceManagementSupport 51 is TRUE. 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 2 Name Type Valid range Description 3 4 20/40 BSS Coexistence As defined in As defined in Specifies the parameters within the 20/40 BSS 5 frame format 7.3.2.60 Coexistence element that are indicated by the 6 MAC entity. The parameter shall be present if the 7 MIB attribute 8 dot112040BSSCoexistenceManagementSupport 9 is TRUE. 10 11 Overlapping BSS Scan As defined in As defined in Specifies the parameters within the Overlapping 12 Parameters frame format 7.3.2.59 BSS Scan Parameters element that are indicated 13 by the MAC entity. This parameter may be 14 present if the dot11FortyMHzOptionImplemented 15 attribute is TRUE and shall not be present if the 16 dot11FortyMHzOptionImplemented attribute is 17 false. 18 19 20 10.3.10.1.4 Effect of receipt 21 22 23 Insert the following two paragraphs after the first paragraph of 10.3.10.1.4: 24 25 If an MLME receives an MLME-START.request with a BSSBasicRateSet parameter containing any unsup- 26 ported rates, the MLME response in the resulting MLME-START.confirm shall contain a ResultCode 27 parameter that is not set to the value SUCCESS. 28 29 30 If the MLME of an HT STA receives an MLME-START.request with a BasicMCSSet parameter containing 31 any unsupported MCSs, the MLME response in the resulting MLME-START.confirm shall contain a 32 ResultCode parameter that is not set to the value SUCCESS. 33 34 35 10.3.15 Channel switch 36 37 10.3.15.1 MLME-CHANNELSWITCH.request 38 39 10.3.15.1.2 Semantics of the service primitive 40 41 42 Change the parameter list in 10.3.15.1.2 follows: 43 44 The primitive parameters are as follows: 45 MLME-CHANNELSWITCH.request( 46 Mode, 47 Channel Number, 48 Secondary Channel Offset, 49 Channel Switch Count, 50 VendorSpecificInfo 51 ) 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Insert the following entry in the table in 10.3.15.1.2 immediately before the row for ChannelSwitchCount: 2 3 4 5 Name Type Valid range Description 6 7 Secondary Integer As in Table 7-27a Specifies the position of secondary channel in relation to 8 Channel Offset (Values of the Sec- the primary channel. 9 ondary Channel Off- The parameter shall be present if the MIB attribute 10 set field) dot11FortyMHzOperationImplemented is TRUE, other- 11 wise the parameter shall not be present. 12 13 14 15 Insert the following paragraph at the end of 10.3.15.1.2: 16 17 The Secondary Channel Offset parameter may be present for HT STAs. 18 19 20 10.3.15.3 MLME-CHANNELSWITCH.indication 21 22 10.3.15.3.2 Semantics of the service primitive 23 24 25 Change the parameter list in 10.3.15.3.2 as follows: 26 27 MLME-CHANNELSWITCH.indication( 28 Peer MAC Address, 29 Mode, 30 Channel Number, 31 Secondary Channel Offset, 32 Channel Switch Count, 33 VendorSpecificInfo 34 ) 35 36 Insert the following entry in the table in 10.3.15.3.2 immediately before the row for Channel Switch 37 Count: 38 39 40 41 Name Type Valid range Description 42 43 Secondary Integer As in Table 7- Specifies the position of secondary channel 44 Channel 27a (Values of in relation to the primary channel. 45 Offset the Secondary The parameter may be present only if the 46 Channel Offset MIB attribute 47 field) dot11FortyMHzOperationImplemented is 48 TRUE. 49 50 51 52 10.3.15.4 MLME-CHANNELSWITCH.response 53 54 10.3.15.4.2 Semantics of the service primitive 55 56 57 Change the parameter list in 10.3.15.4.2 as follows: 58 59 MLME-CHANNELSWITCH.response( 60 Mode, 61 Channel Number, 62 Secondary Channel Offset, 63 Channel Switch Count, 64 VendorSpecificInfo 65 )

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Insert the following entry in the table in 10.3.15.4.2 immediately before the row for Channel Switch 2 Count: 3 4 5 6 Name Type Valid range Description 7 8 Secondary Integer As in Table 7- Specifies the position of secondary channel 9 Channel 27a (Values of in relation to the primary channel. 10 Offset the Secondary The parameter may be present only if the 11 Channel Offset MIB attribute 12 field) dot11FortyMHzOperationImplemented is 13 TRUE. 14 15 16 17 10.3.24 TS management interface 18 19 20 10.3.24.5 MLME-DELTS.request 21 22 10.3.24.5.2 Semantics of the service primitive 23 24 Change the row for ReasonCode in table in 10.3.24.5.2 as follows: 25 26 27 28 29 Name Type Valid range Description 30 31 Reason- Enumeration STA_LEAVING, END_TS, Indicates the reason why the TS is 32 Code UNKNOWN_TS, being deleted. 33 SERVICE_CHANGE_PRECLUDES_TS 34 35 36 10.3.24.7 MLME-DELTS.indication 37 38 39 10.3.24.7.2 Semantics of the service primitive 40 41 Change the row for ReasonCode in table in 10.3.24.7.2 as follows: 42 43 44 45 Name Type Valid range Description 46 47 Reason- Enumeration STA_LEAVING, Indicates the reason why the TS is 48 Code END_TS, being deleted. 49 UNKNOWN_TS, 50 TIMEOUT, 51 SERVICE_CHANGE_PRECLUDES_TS 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 10.3.25 Management of direct links 2 3 10.3.25.2 MLME-DLS.confirm 4 5 6 10.3.25.2.2 Semantics of the service primitive 7 8 Change the parameter list in 10.3.25.2.2 as follows: 9 10 11 The primitive parameters are as follows: 12 MLME-DLS.confirm ( 13 PeerMACAddress, 14 ResultCode, 15 CapabilityInformation, 16 DLSTimeoutValue, 17 SupportedRates, 18 HT Capabilities 19 ) 20 21 Insert the following entry in the table in 10.3.25.2.2 after the row for SupportedRates: 22 23 24 25 26 Name Type Valid range Description 27 28 HT Capa- As defined in As defined in Specifies the parameters within the HT Capa- 29 bilities frame format 7.3.2.56 bilities element that are supported by the 30 MAC entity. The parameter may be present 31 only if the MIB attribute 32 dot11HighThroughputOptionImplemented is 33 TRUE. 34 35 36 10.3.25.3 MLME-DLS.indication 37 38 39 10.3.25.3.2 Semantics of the service primitive 40 41 Change the parameter list in 10.3.25.3.2 as follows: 42 43 44 The primitive parameters are as follows: 45 MLME-DLS.indication ( 46 PeerMACAddress, 47 CapabilityInformation, 48 DLSTimeoutValue, 49 DLSResponseTimeout, 50 HT Capabilities 51 ) 52 53 Insert the following entry in the table in 10.3.25.3.2 after the row for DLSResponseTime: 54 55 56 57 58 Name Type Valid range Description 59 60 HT Capa- As defined in As defined in Specifies the parameters within the HT Capa- 61 bilities frame format 7.3.2.56 bilities element that are supported by the 62 MAC entity. The parameter may be present 63 only if the MIB attribute 64 dot11HighThroughputOptionImplemented is 65 TRUE.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 10.4 PLME SAP interface 2 3 4 10.4.3 PLME-CHARACTERISTICS.confirm 5 6 10.4.3.2 Semantics of the service primitive 7 8 9 Change the primitive parameters as shown: 10 11 PLME-CHARACTERISTICS.confirm( 12 aSlotTime, 13 aSIFSTime, 14 15 aSignalExtension, 16 aCCATime, 17 aPHY-RX-START-Delay, 18 aRxTxTurnaroundTime, 19 aTxPLCPDelay, 20 21 aRxPLCPDelay, 22 aRxTxSwitchTime, 23 aTxRampOnTime, 24 aTxRampOffTime, 25 aTxRFDelay, 26 aRxRFDelay, 27 28 aAirPropagationTime, 29 aMACProcessingDelay, 30 aPreambleLength, 31 aRIFSTime, 32 aSymbolLength, 33 34 aSTFOneLength, 35 aSTFTwoLength, 36 aLTFOneLength, 37 aLTFTwoLength, 38 aPLCPHeaderLength, 39 40 aPLCPSigTwoLength, 41 aPLCPServiceLength, 42 aPLCPConvolutionalTailLength, 43 aMPDUDurationFactor, 44 aMPDUMaxLength, 45 46 aPSDUMaxLength, 47 aPPDUMaxTime, 48 aIUSTime, 49 aDTT2UTTTime, 50 aCWmin, 51 52 aCWmax, 53 aMaxCSIMatricesReportDelay 54 ) 55 56 Change the last paragraph of the subclause as follows: 57 58 59 The values assigned to the parameters shall be as specified in the PLME SAP interface specification contained 60 within each PHY subclass of this standard. The parameters aSignalExtension, aRIFSTime, aSymbolLength, 61 aSTFOneLength, aSTFTwoLength, aLTFOneLength, aLTFTwoLength, aPLCPSigTwoLength, aPLCPSer- 62 viceLength, aPLCPConvolutionalTailLength, aMPDUDurationFactor, aMPDUMaxLength, aPSDUMax- 63 64 Length, aPPDUMaxTime, aIUSTime aDTT2UTTTime and aMaxCSIMatricesReportDelay are not used by 65 all PHYs defined within this standard.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Insert the following entry after aSIFSTime in the table as shown by the following non-header row: 2 3 4 5 Name Type Description 6 7 aSignalExtension integer Duration (in µs) of the signal extension (i.e., a period of no transmission) that is 8 included at the end of certain PPDU formats, see 20.3.2 and 9.2.10a 9 10 11 12 Change the following entries after aPreambleLength in the table as shown by the following non-header 13 14 rows: 15 16 17 18 Name Type Description 19 20 aRIFSTime integer Value of the reduced interframe spacing (in µs), which is the time by which mul- 21 tiple transmissions from a single transmitter may be separated, when no SIFS- 22 separated response transmission is expected. See 9.2.3.0b. 23 24 aSymbolLength integer The current PHY's Symbol length (in µs). If the actual value of the length is not 25 an integral number of µs, the value is rounded up to the next higher value. 26 aSTFOneLength integer Length of the non-HT Short Training field for HT-mixed format, and the HT- 27 greenfield Short Training field for HT-greenfield format (in µs) 28 29 aSTFTwoLength integer Length of the HT Short Training field (in µs) 30 31 aLTFOneLength integer Length of the First HT Long Training field (in µs) 32 33 aLTFTwoLength integer Length of the Additional HT Long Training fields (in µs) 34 35 aPLCPHeader- integer The current PHY’s PLCP header length (in µs), excluding aPLCPSigTwoLength 36 Length if present. If the actual value of the length of the modulated header is not an inte- 37 gral number of µs, the value is rounded up to the next higher value. 38 aPLCPSigTwo- integer Length of the HT SIGNAL field (in µs) 39 Length 40 41 aPLCPService- integer The length of the PLCP SERVICE field (in number of bits) 42 Length 43 44 aPLCPConvolu- integer The length of the sequence of convolutional code tail bits (in number of bits) 45 tionalTailLength 46 47 aMPDUDuration- integer The overhead added by the PHY to the MPDU as it is transmitted through the 48 Factor WM expressed as a scaling factor applied to the number of bits in the MPDU. 49 The value of aMPDUDurationFactor is generated by the following equation: 9 50 Truncate[((PPDUbits/PSDUbits)–1)  10 )]. 51 The total time to transmit a PPDU over the air is generated by the following 52 equation rounded up to the next integer µs: 53 aPreambleLength + aPLCPHeaderLength + (((aMPDUDurationFactor  8  9 54 PSDUoctets) / 10 ) + (8  PSDUoctets)) / data rate 55 where data rate is in Mb/s. 56 The total time (in µs) to the beginning of any octet in a PPDU from the first sym- 57 bol of the preamble can be calculated using the duration factor in the following 58 equation: 59 Truncate[aPreambleLength + aPLCPHeaderLength + (((aMPDUDurationFactor 9 60  8  N) / 10 ) + (8  N)) / data rate] + 1, 61 where data rate is in Mb/s and where N counts the number of octets in the PPDU 62 prior to the desired octet, but does not count the number of octets in the pream- 63 ble PLCP header. 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 2 Name Type Description (continued) 3 4 aMPDUMax- integer The maximum number of octets in an MPDU that can be conveyed by a PLCP 5 Length protocol data unit (PPDU). 6 7 aPSDUMax- integer The maximum number of octets in a PSDU that can be conveyed by a PLCP pro- 8 Length tocol data unit (PPDU). 9 aPPDUMaxTime integer The maximum duration of a PPDU in units of ms 10 11 aIUSTime integer The minimum time between the end of a PSMP-UTT and the start of the follow- 12 ing PSMP-UTT in the same PSMP sequence 13 14 aDTT2UTTTime integer The minimum time between the end of a PSMP-DTT and the start of the PSMP- 15 UTT addressed to the same STA 16 17 aMaxCSIMatri- integer The maximum time (in units of ms) between the reception of a frame containing 18 cesReportDelay a CSI Feedback Request or an NDP announcement and the transmission of the 19 first CSI frame containing channel state information measured from the received 20 Sounding Complete frame. See 9.19.2.4.4. 21 22 23 10.4.6 PLME-TXTIME.request 24 25 26 10.4.6.1 Function 27 28 Change 10.4.6.1 as follows: 29 30 31 This primitive is a request for the PHY to calculate the time that will be required to transmit onto the WM a 32 PPDU containing a specified length MPDUPSDU, and using a specified format, data rate, and signaling. 33 34 10.4.6.2 Semantics of the service primitive 35 36 37 Change 10.4.6.2 as follows: 38 39 This primitive provides the following parameters: 40 41 PLME-TXTIME.request(TXVECTOR) 42 43 44 The TXVECTOR represents a list of parameters that the MAC sublayer provides to the local PHY entity in 45 order to transmit an MPDU PSDU, as further described in 12.3.4.4 and, 17.4 and 20.4 (which defines the local 46 PHY entity). 47 48 49 10.4.6.3 When generated 50 51 Change 10.4.6.3 as follows: 52 53 This primitive is issued by the MAC sublayer to the PHY entity when the MAC sublayer needs to determine 54 55 the time required to transmit a particular MPDUPSDU. 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 11. MLME 2 3 4 11.1 Synchronization 5 6 7 11.1.2 Maintaining synchronization 8 9 11.1.2.1 Beacon generation in infrastructure networks 10 11 12 Insert the following paragraph at the end of 11.1.2.1: 13 14 An AP whose last transmitted values for the Tx STBC subfield and Rx STBC subfield of the HT Capabilities 15 info field of the HT Capabilities element are both non-zero may transmit an STBC Beacon frame and group 16 17 addressed traffic using the Basic STBC MCS, as defined in 9.6.0c. An AP that transmits an STBC Beacon 18 shall set the Dual Beacon field to 1 in transmitted HT Operation elements. The STBC Beacon field shall be 19 set to 1 to identify an STBC Beacon frame. The TBTT for the STBC Beacon frame shall be offset by half of 20 a Beacon Interval from the TBTT of the Beacon frame with the STBC Beacon field set to 0. Except for the 21 setting of the STBC Beacon field, TIM field and TSF field, all other fields inside the STBC Beacon frame 22 23 shall be identical to the Beacon frame with the STBC Beacon field set to 0. 24 25 11.1.3 Acquiring synchronization, scanning 26 27 11.1.3.4 Synchronizing with a BSS 28 29 30 Change 11.1.3.4 as follows: 31 32 Upon receipt of an MLME-JOIN.request, a STA shall adopt the BSSID in the request. Upon receipt of a Bea- 33 con frame from the BSS, a STA shall adopt the channel synchronization information (applicable only if the 34 35 STA contains an FH PHY), and TSF timer value of the parameters in the Beacon frame using the algorithm 36 described in 11.1.2.4, and the MLME shall issue an MLME-JOIN.confirm indicating the operation was suc- 37 cessful. 38 39 40 In addition to these synchronization parameters, a STA joining an infrastructure BSS will adopt each of the 41 parameters found in the BSSDescription of the MLME-JOIN.request except Local time, Capability Informa- 42 tion, and BSSBasicRateSet parameters, and HT Capabilities element. Local time is not adopted but is used as 43 a local variable in adopting the TSF as described in 11.1.2.4. The Capability Information reflects the capabil- 44 ities of the sender and is not adopted but may be used to determine local configuration or behavior. The BSS- 45 46 BasicRateSet parameter is not adopted but may determine if the STA can join the BSS. A STA joining an 47 IBSS will adopt the same parameters except the CF parameter set (since contention free period is not permit- 48 ted in an IBSS). 49 50 If the JoinFailureTimeout timer expires prior to the receipt of a Beacon frame from the BSS, the MLME shall 51 52 issue an MLME-JOIN.confirm indicating the operation was unsuccessful. 53 54 If the dot11MultiDomainCapabilityEnabled attribute is trueTRUE, a STA joining an infrastructure BSS that 55 receivesing a Beacon or Probe Response frame containing a Country information element shall adopt all the 56 all parameters included in that Country information element when joining a BSS and the 57 58 dot11RegDomainsSupportEntry shall be set to Other. 59 60 If a Hopping Pattern Parameters element is present in the Beacon or Probe Response frame, and if the 61 dot11MultiDomainCapabilityEnabled attribute is trueTRUE, a STA that is joining an infrastructure BSS shall 62 adopt the pattern parameters in the element and calculate the hopping patterns using one of the algorithms 63 64 defined in 7.3.2.10 or 7.3.2.11. Using the appropriate pattern, set, and index values from the FH Parameter 65 Set element, the STA shall adopt the values in use by the BSS when joining. The

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 dot11RegDomainsSupportedValue shall be set to Other when the STA is operating using Country informa- 2 tion element settings. 3 4 5 In addition to adopting the synchronization parameters as described in the first paragraph of this subclause, a 6 STA joining an IBSS shall adopt each of the parameters found in the BSSDescription of the MLME-JOIN.re- 7 quest according to the rule found for that parameter in the column “IBSS adoption” of the matching row of 8 the BSSDescription table found in 10.3.2.2.2. Parameters adopted by a STA when joining an IBSS shall not 9 be changed by the STA except when adopting parameters following the reception of a Beacon with a later 10 11 timestamp as described in 11.1.4. 12 13 In addition to the table entries in 10.3.2.2.2, if the dot11MultiDomainCapabilityEnabled attribute is TRUE, a 14 STA receiving a Beacon or Probe Response frame containing a Country information element shall adopt the 15 16 all parameters included in that Country information element when joining an IBSS and the 17 dot11RegDomainsSupportEntry shall be set to Other. 18 19 In addition to the table entries in 10.3.2.2.2, if a Hopping Pattern Parameters element is present in the Beacon 20 or Probe Response frame, and if the dot11MultiDomainCapabilityEnabled attribute is TRUE, a STA that is 21 22 joining an IBSS shall adopt the pattern parameters in the element and calculate the hopping patterns using 23 one of the algorithms defined in 7.3.2.10 or 7.3.2.11. Using the appropriate pattern, set, and index values from 24 the FH Parameter Set element, the STA shall adopt the values in use by the IBSS when joining. The 25 dot11RegDomainsSupportedValue shall be set to Other when the STA is operating using Country informa- 26 tion element settings. 27 28 29 11.1.4 Adjusting STA timers 30 31 Change the third paragraph of 11.1.4 as follows: 32 33 34 All Beacon and Probe Response frames carry a Timestamp field. A STA receiving such a frame from another 35 STA in an IBSS with the same SSID shall compare the Timestamp field with its own TSF time. If the Times- 36 tamp field of the received frame is later than its own TSF timer, the STA in the IBSS shall adopt eachall pa- 37 rameters contained in the Beacon frame according to the rule for that parameter found in the column "IBSS 38 adoption" of the matching row of the BSSDescription table found in 10.3.2.2.2., except the Capability bits, 39 40 Supported Rates information element, and Extended Supported Rates information element.Parameters adopt- 41 ed by a STA due to the receipt of a later timestamp shall not be changed by the STA except when adopting 42 parameters due to a subsequently received Beacon with a later timestamp. 43 44 Insert the following subclause (11.1.6) after 11.1.5: 45 46 47 11.1.6 Supported Rates and Extended Supported Rates advertisement 48 49 A STA shall include rates from its Operational Rate Set and BSS membership selectors from its BSSMem- 50 bershipSelectorSet in frames it transmits containing Supported Rates elements and Extended Supported Rates 51 52 elements according to the rules described in this subclause. 53 54 For a STA supporting a combined total of eight or fewer data rates and BSS membership selectors, inclusion 55 of the Extended Supported Rates element is optional in all of the frame types that include the Supported Rates 56 element. 57 58 59 If the combined total of the number of rates in the Operational Rate Set and the number of BSS membership 60 selectors exceeds eight, then an Extended Supported Rate element shall be generated to specify the supported 61 rates and BSS membership selectors that are not included in the Supported Rates element. If the BSSMem- 62 bershipSelectorSet parameter contains at least one BSS membership selector, then at least one BSS member- 63 64 ship selector value from the BSSMembershipSelectorSet parameter shall be included in the Supported Rates 65 element.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 NOTE—Inclusion of at least one BSS membership selector in the Supported Rates element ensures that a receiving STA 2 that does not process the Extended Supported Rates element will still receive a BSS membership selector (which it con- 3 siders to be a basic rate) that it does not support. Any values from the BSSMembershipSelectorSet that are not transmit- 4 ted in the Supported Rates element are transmitted in the Extended Supported Rates element. 5 6 7 11.2 Power management 8 9 11.2.1 Power management in an infrastructure network 10 11 12 Change 11.2.1 as follows: 13 14 STAs changing Power Management mode shall inform the AP of this fact using the Power Management bits 15 within the Frame Control field of transmitted frames. The AP shall not arbitrarily transmit MSDUs or A-MS- 16 17 DUs to STAs operating in a PS mode, but shall buffer MSDUs and A-MSDUs and only transmit them at des- 18 ignated times. 19 20 The STAs that currently have buffered MSDUs or A-MSDUs within the AP are identified in a TIM, which 21 shall be included as an element within all beacons generated by the AP. A STA shall determine that an MSDU 22 23 or A-MSDU is buffered for it by receiving and interpreting a TIM. 24 25 STAs operating in PS modes shall periodically listen for beacons, as determined by the STA’s ListenInterval 26 and the ReceiveDTIMs parameter in the MLME-POWERMGT.request primitive. 27 28 29 In a BSS operating under the DCF, or during the CP of a BSS using the PCF, upon determining that an MSDU 30 or A-MSDU is currently buffered in the AP, a STA operating in the PS mode shall transmit a short PS-Poll 31 frame to the AP, which shall respond with the corresponding buffered MSDU or A-MSDU immediately, or 32 acknowledge the PS-Poll and respond with the corresponding MSDU or A-MSDU at a later time. If the TIM 33 indicating the buffered MSDU or A-MSDU is sent during a CFP, a CF-Pollable STA operating in the PS 34 35 mode does not send a PS-Poll frame, but remains active until the buffered MSDU or A-MSDU is received (or 36 the CFP ends). If any STA in its BSS is in PS mode, the AP shall buffer all broadcast and multicast group 37 addressed MSDUs and deliver them to all STAs immediately following the next Beacon frame containing a 38 DTIM transmission. 39 40 41 A STA shall remain in its current Power Management mode until it informs the AP of a Power Management 42 mode change via a frame exchange that includes an acknowledgement from the AP. Power Management 43 mode shall not change during any single frame exchange sequence, as (described in 9.12 Annex S). 44 45 A non-AP QoS STA may be in PS mode before the setup of DLS or Block Ack. Once DLS is set up with 46 47 another non-AP QoS STA, the non-AP QoS STA suspends the PS mode and shall always be awake. When a 48 STA enters normal (non-APSD) PS mode, any downlink Block Ack agreement without an associated sched- 49 ule is suspended for the duration of this PS mode. MSDUs and A-MSDUs for TID without a schedule are sent 50 using Normal Ack following a PS-poll as described in rest of this subclause. Uplink Block Ack, Block Acks 51 for any TID with a schedule, and any Block Acks to APSD STA continue to operate normally. 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 11.2.1.1 STA Power Management modes 2 3 4 Change the second row of Table 11-1 as follows: 5 6 7 Table 11-1—Power Management modes 8 9 10 PS STA listens to selected beacons (based upon the ListenInterval parameter of the 11 MLMEASSOCIATE.request primitive) and sends PS-Poll frames to the AP if the TIM 12 element in the most recent beacon indicates a directed MSDU or A-MSDU buffered for 13 that STA. The AP shall transmit buffered directed MSDUs or A-MSDUs to a PS STA 14 15 only in response to a PS-Poll from that STA, or during the CFP in the case of a CF- 16 Pollable PS STA. In PS mode, a STA shall be in the Doze state and shall enter the Awake 17 state to receive selected beacons, to receive broadcast and multicast group addressed 18 transmissions following certain received beacons, to transmit, and to await responses to 19 transmitted PS-Poll frames or (for CF-Pollable STAs) to receive CF transmissions of 20 21 buffered MSDUs or A-MSDUs. 22 23 24 11.2.1.2 AP TIM transmissions 25 26 27 Change 11.2.1.2 as follows: 28 29 The TIM shall identify the STAs for which traffic is pending and buffered in the AP. This information is cod- 30 31 ed in a partial virtual bitmap, as described in 7.3.2.6. In addition, the TIM contains an indication whether 32 broadcast/multicastgroup addressed traffic is pending. Every STA is assigned an AID by the AP as part of the 33 association process. AID 0 (zero) is reserved to indicate the presence of buffered broadcast/multicast group 34 addressed MSDUs. The AP shall identify those STAs for which it is prepared to deliver buffered MSDUs or 35 A-MSDUs by setting bits in the TIM’s partial virtual bitmap that correspond to the appropriate AIDs. 36 37 38 11.2.1.3 TIM types 39 40 Change the fourth paragraph of 11.2.1.3 as follows: 41 42 43 The third and fourth lines in Figure 11-4 depict the activity of two STAs operating with different power man- 44 agement requirements. Both STAs power-on their receivers when they need to listen for a TIM. This is indi- 45 cated as a ramp-up of the receiver power prior to the TBTT. The first STA, for example, powers up its receiver 46 47 and receives a TIM in the first beacon; that TIM indicates the presence of a buffered MSDU or A-MSDU for 48 the receiving STA. The receiving STA then generates a PS-Poll frame, which elicits the transmission of the 49 buffered data MSDU or A-MSDU from the AP. Broadcast and multicastGroup addressed MSDUs are sent 50 by the AP subsequent to the transmission of a beacon containing a DTIM. The DTIM is indicated by the 51 DTIM count field of the TIM element having a value of 0. 52 53 54 11.2.1.4 Power management with APSD 55 56 Change the fourth paragraph of 11.2.1.4 as follows: 57 58 59 If there is no unscheduled SP in progress, the unscheduled SP begins when the AP receives a trigger frame 60 from a non-AP STA, which is a QoS data or QoS Null frame associated with an AC the STA has configured 61 to be trigger-enabled. An A-MPDU that contains one or more trigger frames acts as a trigger frame. An un- 62 scheduled SP ends after the AP has attempted to transmit at least one MSDU, A-MSDU or MMPDU associ- 63 64 ated with a delivery-enabled AC and destined for the non-AP STA, but no more than the number indicated in 65 the Max SP Length field if the field has a nonzero value.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 11.2.1.5 AP operation during the CP 2 3 4 Change the first paragraph of 11.2.1.5 as follows: 5 6 APs shall maintain a Power Management status for each currently associated STA that indicates in which 7 Power Management mode the STA is currently operating. APs that implement and signal their support of 8 APSD shall maintain an APSD and an access policy status for each currently associated non-AP STA that 9 10 indicates whether the non-AP STA is presently using APSD and shall maintain the schedule (if any) for the 11 non-AP STA. An AP shall, depending on the Power Management mode of the STA, temporarily buffer the 12 MSDU, A-MSDU or management frame destined to the STA. An AP implementing APSD shall, if a non-AP 13 STA is using APSD and is in PS mode, temporarily buffer the MSDU, A-MSDU or management frames des- 14 tined to that non-AP STA. No MSDUs, A-MSDUs or management frames addressed directly to STAs oper- 15 16 ating in the Active mode shall be buffered for power management reasons. 17 18 Change list items a) and b) of 11.2.1.5 as follows (note strikeout of comma in first lines of both items): 19 20 a) MSDUs, A-MSDUs or management frames destined for PS STAs, shall be temporarily buffered in 21 the AP. MSDUs, A-MSDUs or management frames, destined for PS STAs using APSD shall be 22 temporarily buffered in the APSD-capable AP. The algorithm to manage this buffering is beyond the 23 24 scope of this standard, with the exception that if the AP is QoS-enabled, it shall preserve the order of 25 arrival of frames on a per-TID, per-STA basis. 26 b) MSDUs, A-MSDUs or management frames destined for STAs in the Active mode, shall be directly 27 28 transmitted to those STAs. 29 30 Change list item f) in 11.2.1.5 as follows: 31 32 f) Immediately after every DTIM, the AP shall transmit all buffered broadcast/multicastgroup 33 addressed MSDUs. The More Data field of each broadcast/multicastgroup addressed frame shall be 34 set to indicate the presence of further buffered broadcast/multicastgroup addressed MSDUs. If the 35 AP is unable to transmit all of the buffered broadcast/multicast group addressed MSDUs before the 36 37 primary or secondary TBTT following the DTIM, the AP shall indicate that it will continue to 38 deliver the broadcast/multicastgroup addressed MSDUs by setting the bit for AID 0 (zero) in the bit 39 map control field of the TIM element of every Beacon frame, until all buffered broadcast/multicast- 40 group addressed frames have been transmitted. When the AP transmits an STBC DTIM or TIM Bea- 41 con frame, the AP shall re-transmit all group addressed frames that were transmitted following the 42 43 non-STBC DTIM or TIM Beacon frame except that they are transmitted using the basic STBC 44 MCS. It may be the case that a complete set of buffered group addressed frames is sent over a period 45 of time during which non-STBC and STBC transmissions are interleaved, but the transition from 46 non-STBC group addressed transmissions to STBC group addressed transmissions shall be preceded 47 by the transmission of an STBC Beacon frame and the transition from STBC group addressed trans- 48 49 missions to non-STBC group addressed transmissions shall be preceded by the transmission of a 50 non-STBC Beacon frame. 51 52 Change list item g) of 11.2.1.5 as follows: 53 54 g) A single buffered MSDU, A-MSDU or management frame for a STA in the PS mode shall be for- 55 warded to the STA after a PS-Poll has been received from that STA. For a non-AP STAs using U- 56 APSD, the AP transmits one frame destined for the non-AP STA from any AC that is not delivery- 57 58 enabled in response to PS-Poll from the non-AP STA. When all ACs associated with the non-AP 59 STA are delivery-enabled, AP transmits one frame from the highest priority AC. The AP can 60 respond with either an immediate Ddata frame or with an ACK, while delaying the responding 61 Ddata frame. 62 63 64 For a STA in PS mode and not using U-APSD, the More Data field of the response Ddata frame 65 shall be set to indicate the presence of further buffered MSDUs, A-MSDUs or management frames

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 for the polling STA. For a non-AP STA using U-APSD, the More Data field shall be set to indicate 2 the presence of further buffered MSDUs, A-MSDUs or management frames that do not belong to 3 delivery-enabled ACs. When all ACs associated with the non-AP STA are delivery-enabled, the 4 5 More Data field shall be set to indicate the presence of further buffered MSDUs, A-MSDUs or man- 6 agement frames belonging to delivery-enabled ACs. If there are buffered frames to transmit to the 7 STA, the AP may set the More Data bit in a QoS +CF-Ack frame to 1, in response to a QoS data 8 frame to indicate that it has one or more pending frames buffered for the PS STA identified by the 9 RA address in the QoS +CF-Ack frame. An AP may also set the More Data bit in an ACK frame in 10 11 response to a QoS data frame to indicate that it has one or more pending frames buffered for the PS 12 STA identified by the RA address in the ACK frame, if that PS STA has set the More Data Ack sub- 13 field in the QoS Capability information element to 1. 14 15 Further PS-Poll frames from the same STA shall be acknowledged and ignored until the MSDU, A- 16 17 MSDU or management frame has either been successfully delivered or presumed failed due to max- 18 imum retries being exceeded. This prevents a retried PS-Poll from being treated as a new request to 19 deliver a buffered frame. 20 21 Change list item h) of 11.2.1.5 as follows: 22 23 h) At each scheduled APSD SP for a non-AP STA, the APSD-capable AP shall attempt to transmit at 24 25 least one MSDU, A-MSDU or MMPDU, associated with admitted TSPECs with the APSD and 26 Schedule subfields both set to 1, that are destined for the non-AP STA. At each unscheduled SP for 27 a non-AP STA, the AP shall attempt to transmit at least one MSDU, A-MSDU or MMPDU, but no 28 more than the value specified in the Max SP Length field in the QoS Capability element from deliv- 29 ery-enabled ACs, that are destined for the non-AP STA. 30 31 32 The More Data bit of the directed data or management frame associated with delivery-enabled ACs 33 and destined for that non-AP STA indicates that more frames are buffered for the delivery-enabled 34 ACs. The More Data bit set in MSDUs, A-MSDUs or management frames associated with nondeliv- 35 ery-enabled ACs and destined for that non-AP STA indicates that more frames are buffered for the 36 37 nondelivery-enabled ACs. For all frames except for the final frame of the SP, the EOSP subfield of 38 the QoS Control field of the QoS data frame shall be set to 0 to indicate the continuation of the SP. 39 An AP may also set the More Data bit to 1 in a QoS +CF-Ack frame in response to a QoS data frame 40 to indicate that it has one or more pending frames buffered for the target STA identified by the RA 41 address in the QoS +CF-Ack frame. If the QoS data frame is associated with a delivery-enabled AC, 42 43 the More Data bit in the QoS +CF-Ack frame indicates more frames for all delivery-enabled ACs. If 44 the QoS data frame is not associated with a delivery-enabled AC, the More Data bit in the QoS +CF- 45 Ack frame indicates more frames for all ACs that are not delivery-enabled. 46 47 The AP considers APSD STA to be in awake state after it has sent a QoS +CF-Ack frame, with the 48 49 EOSP subfield in the QoS Control field set to 0, to the APSD STA. If necessary, the AP may gener- 50 ate an extra QoS Null frame, with the EOSP set to 1. When the AP has transmitted a directed frame 51 to the non-AP STA with the EOSP subfield set to 1 during the SP except for retransmissions of that 52 frame, the AP shall not transmit any more frames to that STA using this mechanism until the next 53 SP. The AP shall set the EOSP subfield to 1 to indicate the end of the SP in APSD. 54 55 56 Change list items i) to l) of 11.2.1.5 as follows: 57 58 i) If the AP does not receive an acknowledgment to a directed MSDU, A-MSDU or management 59 frame sent to a non-AP STA in PS mode following receipt of a PS-Poll from that non-AP STA, it 60 may retransmit the frame for at most the lesser of the maximum retry limit and the MIB attribute 61 dot11QAPMissingAckRetryLimit times before the next beacon, but it shall retransmit that frame at 62 least once before the next beacon, time permitting and subject to its appropriate lifetime limit. If an 63 64 acknowledgment to the retransmission is not received, it may wait until after the next Beacon frame 65 to further retransmit that frame subject to its appropriate lifetime limit.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 j) If the AP does not receive an acknowledgment to a directed frame containing all or part of an 2 MSDU or A-MSDU sent with the EOSP subfield set to 1, it shall retransmit that frame at least once 3 within the same SP, subject to applicable retry or lifetime limit. The maximum number of retrans- 4 5 missions within the same SP is the lesser of the maximum retry limit and the MIB attribute 6 dot11QAPMissingAckRetryLimit. If an acknowledgment to the retransmission of this last frame in 7 the same SP is not received, it may wait until the next SP to further retransmit that frame, subject to 8 its applicable retry or lifetime limit. 9 10 k) An AP can delete buffered frames for implementation dependent reasons, including the use of an 11 aging function and availability of buffers. The AP may base the aging function on the listen interval 12 specified by the non-AP QoS STA in the association or reassociation request frame. 13 14 l) When an AP is informed that a STA changes to the Active mode, then the AP shall send buffered 15 MSDUs, A-MSDUs and management frames (if any exist) to that STA without waiting for a PS- 16 Poll. When an AP is informed that an APSD-capable non-AP STA is not using APSD, then the AP 17 shall send buffered MSDUs, A-MSDUs and management frames (if any exist) to that non-AP STA 18 19 according to the rules corresponding to the current PS mode of the non-AP STA. 20 21 11.2.1.6 AP operation during the CFP 22 23 Change 11.2.1.6 as follows: 24 25 26 APs shall maintain a Power Management status for each currently associated CF-Pollable STA that indicates 27 in which Power Management mode the STA is currently operating. An AP shall, for STAs in PS mode, tem- 28 porarily buffer theany MSDU or A-MSDU destined to the STA. 29 30 a) MSDUs or A-MSDUs destined for PS STAs shall be temporarily buffered in the AP. The algorithm 31 to manage this buffering is beyond the scope of this standard. 32 33 b) MSDUs or A-MSDUs destined to STAs in the Active mode shall be transmitted as defined in Clause 34 9. 35 c) Prior to every CFP, and at each Bbeacon Iinterval within the CFP, the AP shall assemble the partial 36 37 virtual bitmap containing the buffer status per destination for STAs in the PS mode, set the bits in 38 the partial virtual bitmap for STAs the PC is intending to poll during this CFP, and shall send this 39 out in the TIM field of the DTIM. The bit for AID 0 (zero) in the bit map control field of the TIM 40 information element shall be set when broadcast or multicastgroup addressed traffic is buffered, 41 according to 7.3.2.6. 42 43 d) All broadcast and multicastgroup addressed MSDUs, with the Order bit in the Frame Control field 44 clear, shall be buffered if any associated STAs are in the PS mode, whether or not those STAs are 45 CF-Pollable or not. 46 47 e) Immediately after every DTIM (Beacon frame with DTIM Count field of the TIM element equal to 48 zero), the AP shall transmit all buffered broadcast and multicastgroup addressed frames. The More 49 Data field shall be set to indicate the presence of further buffered broadcast/multicastgroup 50 addressed MSDUs. If the AP is unable to transmit all of the buffered broadcast/multicastgroup 51 52 addressed MSDUs before the non-STBC or STBC TBTT following the DTIM, the AP shall indicate 53 that it will continue to deliver the broadcast/multicastgroup addressed MSDUs by setting the bit for 54 AID 0 (zero) in the bit map control field of the TIM element of every Beacon frame, until all buff- 55 ered broadcast/multicastgroup addressed frames have been transmitted. When the AP transmits an 56 STBC DTIM or TIM Beacon frame, the AP shall re-transmit all group addressed frames that were 57 58 transmitted following the non-STBC DTIM or TIM Beacon frame except that they are transmitted 59 using the basic STBC MCS. It may be the case that a complete set of buffered group addressed 60 frames is sent over a period of time during which non-STBC and STBC transmissions are inter- 61 leaved, but the transition from non-STBC group addressed transmissions to STBC group addressed 62 transmissions shall be preceded by the transmission of a STBC Beacon frame and the transition 63 64 from STBC group addressed transmissions to non-STBC group addressed transmissions shall be 65 preceded by the transmission of a non-STBC Beacon frame.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 f) Buffered MSDUs, A-MSDUs or MMPDUs for STAs in the PS mode shall be forwarded to the CF- 2 Pollable STAs under control of the PC. Transmission of these buffered MSDUs or management 3 frames as well as CF-Polls to STAs in the PS mode that were indicated in the DTIM in accordance 4 5 with paragraph c) of this subclause shall begin immediately after transmission of buffered broadcast 6 and multicastgroup addressed frames (if any), and shall occur in order by increasing AID of F-Pol- 7 lable STAs. A CF-Pollable STA for which the TIM element of the most recent beacon indicated 8 buffered MSDUs or management frames shall be in the Awake state at least until the receipt of a 9 directed frame from the AP in which the Frame Control field does not indicate the existence of more 10 11 buffered MSDUs, A-MSDUs or management frames. After acknowledging the last of the buffered 12 MSDUs, A-MSDUs or management frames, the CF-Pollable STA operating in the PS mode may 13 enter the Doze state until the next DTIM is expected. 14 15 g) An AP shall have an aging function to delete pending traffic buffered for an excessive time period. 16 The exact specification of the aging function is beyond the scope of this standard. 17 h) When an AP detects that a CF-Pollable STA has changed from the PS mode to the Active mode, 18 19 then the AP shall queue any buffered frames addressed to that STA for transmission to that CF-Pol- 20 lable STA as directed by the AP’s PC. 21 22 11.2.1.7 Receive operation for STAs in PS mode during the CP 23 24 25 Change 11.2.1.7 as follows: 26 27 STAs in PS mode shall operate as follows to receive an MSDU, A-MSDU or management frame from the AP 28 when no PC is operating and during the CP when a PC is operating. 29 30 a) STAs shall wake up early enough to be able to receive the first beacon scheduled for transmission 31 after the time corresponding to the last TBTT plus the STA's current ListenInterval. 32 33 b) When a STA detects that the bit corresponding to its AID is set in the TIM, the STA shall issue a PS- 34 Poll to retrieve the buffered MSDU, A-MSDU or management frame. The PS-Poll shall be transmit- 35 ted after random delay uniformly distributed between zero and aCWmin slots following a DIFS. 36 37 c) The STA shall remain in the Awake state until it receives the data or management frame in response 38 to its poll or it receives another beacon whose TIM indicates that the AP does not have any MSDUs, 39 A-MSDUs or management frames buffered for this STA. If the bit corresponding to the STA’s AID 40 is set in the subsequent TIM, the STA shall issue another PS-Poll to retrieve the buffered MSDU, A- 41 MSDU or management frame(s). When a non-AP STA that is using U-APSD and has all ACs deliv- 42 43 ery enabled detects that the bit corresponding to its AID is set in the TIM, the non-AP STA shall 44 issue a trigger frame or a PS-Poll frame to retrieve the buffered MSDU, A-MSDU or management 45 frames. 46 d) If the More Data field in the received MSDU, A-MSDU or management frame indicates that more 47 48 traffic for that STA is buffered, the STA, at its convenience, shall Poll until no more MSDUs, A- 49 MSDUs or management frames are buffered for that STA. 50 e) When ReceiveDTIMs is trueTRUE, the STA shall wake up early enough to be able to receive either 51 52 every non-STBC DTIM or every STBC DTIM sent by the AP of the BSS. A STA that stays awake 53 to receive broadcast/multicastgroup addressed MSDUs shall elect to receive all group addressed 54 non-STBC transmissions or all group addressed STBC transmissions, and shall remain awake until 55 the More Data field of the appropriate type (non-STBC or STBC) of broadcast/multicastgroup 56 addressed MSDUs indicates there are no further buffered broadcast/multicastgroup addressed 57 58 MSDUs of that type, or until a TIM is received indicating there are no more buffered broadcast/mul- 59 ticastgroup addressed MSDUs of that type. If a non-AP STA receives a QoS +CF-Ack frame from 60 its AP with the More Data bit set to 1, then the STA shall operate exactly as if it received a TIM with 61 its AID bit set. If a non-AP STA has set the More Data Ack subfield in QoS Capability information 62 element to 1, then if it receives an ACK frame from its AP with the More Data bit set to 1, the STA 63 64 shall operate exactly as if it received a TIM with its AID bit set. For example, a STA that is using the 65 PS-Poll delivery method shall issue a PS-Poll frame to retrieve a buffered frame. See also 9.2.7.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 11.2.1.8 Receive operation for STAs in PS mode during the CFP 2 3 Change 11.2.1.8 as follows: 4 5 6 STAs in PS mode that are associated as CF-Pollable shall operate as follows in a BSS with an active PC to 7 receive MSDUs or management frames from the AP during the CFP: 8 9 a) STAs shall enter the Awake state so as to receive the Beacon frame (which contains a DTIM) at the 10 start of each CFP. 11 b) To receive broadcast/multicastgroup addressed MSDUs, the STA shall wake up early enough to be 12 13 able to receive either every non-STBC DTIM or every STBC DTIM that may be sent during the 14 CFP. A STA receiving broadcast/multicastgroup addressed MSDUs shall elect to receive all group 15 addressed non-STBC transmissions or all group addressed STBC transmissions, and shall remain 16 awake until the More Data field of the appropriate type (non-STBC or STBC) of broadcast /multi- 17 castgroup addressed MSDUs indicates there are no further buffered broadcast/multicastgroup 18 19 addressed MSDUs of that type, or until a TIM is received indicating there are no more broadcast/ 20 multicastgroup addressed MSDUs of that type buffered. See also 9.2.7. 21 c) When a STA detects that the bit corresponding to its AID is set in the DTIM at the start of the CFP 22 23 (or in a subsequent TIM during the CFP), the STA shall remain in the Awake state for at least that 24 portion of the CFP through the time that the STA receives a directed MSDU, A-MSDU or manage- 25 ment frame from the AP with the More Data field in the Frame Control field indicating that no fur- 26 ther traffic is buffered. 27 28 d) If the More Data field in the Frame Control field of the last MSDU, A-MSDU or management frame 29 received from the AP indicates that more traffic for the STA is buffered, then, when the CFP ends, 30 the STA may remain in the Awake state and transmit PS-Poll frames during the CP to request the 31 delivery of additional buffered MSDU, A-MSDU or management frames, or may enter the Doze 32 33 state during the CP (except at TBTTs for DTIMs expected during the CP), awaiting the start of the 34 next CFP. 35 36 11.2.1.9 Receive operation for non-AP STAs using APSD 37 38 39 Change the first paragraph of 11.2.1.9 as follows: 40 41 A non-AP STA using APSD shall operate as follows to receive an MSDU, A-MSDU or management frame 42 from the AP: 43 44 45 Change list item b) of 11.2.1.9 as follows: 46 e) If the non-AP STA is initiating an unscheduled SP, the non-AP STA wakes up and transmits a trig- 47 48 ger frame to the AP. When one or more ACs are not delivery-enabled, the non-AP STA may retrieve 49 MSDUs, A-MSDUs and MMPDUs belonging to those ACs by sending PS-Poll frames to the AP. 50 51 Insert the following subclause (11.2.1.12) after subclause 11.2.1.11: 52 53 54 11.2.1.12 PSMP Power management 55 56 An AP transmits a PSMP frame containing a schedule only for STAs that are awake. 57 NOTE 1—A STA in Power Save mode is awake as defined in 11.2.1.4 (U-APSD, S-APSD), 11.2.1.5 (PS-poll) or during 58 a DTIM period. 59 60 The AP may signal the end of the Service Period for all awake associated PSMP capable STAs by setting the 61 62 More PSMP field to 0, or by sending CF-End frame instead of the next PSMP frame. 63 NOTE 2—The AP can also signal the end of a service period on a per-STA basis using the EOSP field set to 1 in the 64 QoS Control field, as defined in 7.1.3.5.2 and 11.2.1.5. This field remains set to 1 for any retransmissions of the same 65 frame and no more new frames are sent to this particular STA in the current SP.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 NOTE 3—If a STA is awake at the start of a scheduled PSMP session, the operation of the More Data field in the Frame 2 Control field and the TIM element are defined by the S-APSD rules in 11.2.1.4, 11.2.1.5 and 11.2.1.9. 3 4 A STA shall wake up at start of the next PSMP frame if the More PSMP field is set to 1 in the current PSMP 5 frame, unless the STA has been permitted to return to sleep through the reception of a frame addressed to it 6 7 with the EOSP field set to 1 or the maximum SP interval has elapsed. 8 9 A PPDU containing MPDUs addressed to a STA shall not start after expiry of the STA's PSMP-DTT. A STA 10 completes the reception of any PPDU that starts before the end of the PSMP-DTT. If no frames addressed to 11 12 a STA begin within a PSMP-DTT, it can assume that no frame addressed to it will arrive during this PSMP 13 sequence. 14 15 The STA shall be awake to receive at the start of the PSMP-DTT determined from a STA_INFO that has the 16 STA_INFO Type field set to 2 and the AID field matching the STA’s AID where the PSMP-DTT Duration 17 18 is not set to 0. 19 20 11.2.2 Power management in an IBSS 21 22 23 11.2.2.1 Basic approach 24 25 Change the first to the sixth paragraphs of 11.2.2.1 as follows: 26 27 The basic approach is similar to the infrastructure case in that the STAs are synchronized, and multicastgroup 28 29 addressed MSDUs and those MSDUs or A-MSDUs that are to be transmitted to a power-conserving STA are 30 first announced during a period when all STAs are awake. The announcement is done via an ad hoc ATIM 31 sent in an ATIM Window. A STA in the PS mode shall listen for these announcements to determine if it needs 32 to remain in the awake state. The presence of the ATIM window in the IBSS indicates if the STA may use PS 33 Mode. To maintain correct information on the power save state of other stations in an IBSS, a station needs 34 35 to remain awake during the ATIM window. At other times the STA may enter the Doze state except as indi- 36 cated in the following procedures. 37 38 The basic approach is similar to the infrastructure case in that the STAs are synchronized, and multicastgroup 39 40 addressed MSDUs and those MSDUs or A-MSDUs that are to be transmitted to a power-conserving STA are 41 first announced during a period when all STAs are awake. The announcement is done via an ad hoc ATIM 42 sent in an ATIM Window. A STA in the PS mode shall listen for these announcements to determine if it needs 43 to remain in the awake state. The presence of the ATIM window in the IBSS indicates if the STA may use PS 44 Mode. To maintain correct information on the power save state of other stations in an IBSS, a station needs 45 46 to remain awake during the ATIM window. At other times the STA may enter the Doze state except as indi- 47 cated in the following procedures. 48 49 When an MSDU or A-MSDU is to be transmitted to a destination STA that is in a PS mode, the transmitting 50 STA first transmits an ATIM frame during the ATIM Window, in which all the STAs including those oper- 51 52 ating in a PS mode are awake. The ATIM Window is defined as a specific period of time, defined by the value 53 of the ATIM Window parameter in the IBSS Parameter Set supplied to the MLME-START.request primitive, 54 following a TBTT, during which only Beacon or ATIM frames shall be transmitted. ATIM transmission times 55 are randomized, after a Beacon frame is either transmitted or received by the STA, using the backoff proce- 56 dure with the CW equal to aCWmin. Directed ATIMs shall be acknowledged. If a STA transmitting a directed 57 58 ATIM does not receive an acknowledgment, the STA shall execute the backoff procedure for retransmission 59 of the ATIM. MulticastGroup addressed ATIMs shall not be acknowledged. 60 61 If a STA receives a directed ATIM frame during the ATIM Window, it shall acknowledge the directed ATIM 62 and stay awake for the entire beacon interval waiting for the announced MSDU(s) or A-MSDU(s) to be re- 63 64 ceived. If a STA does not receive an ATIM, it may enter the Doze state at the end of the ATIM Window. 65 Transmissions of MSDUs announced by ATIMs are randomized after the ATIM Window, using the backoff

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 procedure described in Clause 9. 2 3 4 It is possible that an ATIM may be received from more than one STA, and that a STA that receives an ATIM 5 may receive more than a single MSDU or A-MSDU from the transmitting STA. ATIM frames are only ad- 6 dressed to the destination STA of the MSDU or A-MSDU. 7 8 An ATIM for a broadcast or multicastgroup addressed MSDU shall have a destination address identical to 9 10 that of the MSDU. After the ATIM interval, only those directed MSDUs or A-MSDUs that have been suc- 11 cessfully announced with an acknowledged ATIM, and broadcast/multicastgroup addressed MSDUs that 12 have been announced with an ATIM, shall be transmitted to STAs in the PS mode. Transmission of these 13 frames shall be done using the normal DCF access procedure. 14 15 16 11.2.2.3 STA power state transitions 17 18 Change the first paragraph of 11.2.2.3 as follows: 19 20 21 A STA may enter PS mode if and only if the value of the ATIM Window in use within the IBSS is greater 22 than zero. A STA shall set the Power Management subfield in the Frame Control field of data MPDUs con- 23 taining all or part of MSDUs or A-MSDUs that it transmits using the rules in 7.1.3.1.7. 24 25 26 11.2.2.4 ATIM and frame transmission 27 28 Change 11.2.2.4 as follows: 29 30 31 If power management is in use within an IBSS, all STAs shall buffer MSDUs and A-MSDUs for STAs that 32 are known to be in PS mode. The algorithm used for the estimation of the power management state of STAs 33 within the IBSS is outside the scope of this standard. MSDUs and A-MSDUs may be sent to STAs in Active 34 mode at any valid time. 35 36 a) Following the reception or transmission of the beacon, during the ATIM Window, the STA shall 37 transmit a directed ATIM management frame to each STA for which it has one or more buffered 38 unicastindividually addressed MSDUs and A-MSDUs. If the STA has one or more buffered multi- 39 40 castgroup addressed MSDUs, with the Strictly Ordered bit clear, it shall transmit an appropriately 41 addressed multicastgroup addressed ATIM frame. A STA transmitting an ATIM management frame 42 shall remain awake for the entire current beacon interval. 43 44 b) All STAs shall use the backoff procedure defined in 9.2.5.2 for transmission of the first ATIM fol- 45 lowing the beacon. All remaining ATIMs shall be transmitted using the conventional DCF access 46 procedure. 47 48 c) ATIM management frames shall only be transmitted during the ATIM Window. 49 d) A STA shall transmit no frame types other than RTS, CTS, and ACK control frames and Beacon and 50 ATIM management frames during the ATIM Window. 51 52 e) Directed ATIM management frames shall be acknowledged. If no acknowledgment is received, the 53 ATIM shall be retransmitted using the conventional DCF access procedure. MulticastGroup 54 addressed ATIM management frames shall not be acknowledged. 55 56 f) If a STA is unable to transmit an ATIM during the ATIM Window, for example due to contention 57 with other STAs, the STA shall retain the buffered MSDU(s) and A-MSDU(s) and attempt to trans- 58 mit the ATIM during the next ATIM Window. 59 60 g) Immediately following the ATIM Window, a STA shall begin transmission of buffered broadcast/ 61 multicastgroup addressed frames for which an ATIM was previously transmitted. Following the 62 transmission of any broadcast/multicastgroup addressed frames, any MSDUs and management 63 64 frames addressed to STAs for which an acknowledgment for a previously transmitted ATIM frame 65 was received shall be transmitted. All STAs shall use the backoff procedure defined in 9.2.5.2 for

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 transmission of the first frame following the ATIM Window. All remaining frames shall be trans- 2 mitted using the conventional DCF access procedure. 3 4 h) A buffered MSDU may be transmitted using fragmentation. If an MSDU has been partially transmit- 5 ted when the next Beacon beacon frame is sent, the STA shall retain the buffered MSDU and 6 announce the remaining fragments by transmitting an ATIM during the next ATIM Window. 7 8 i) If a STA is unable to transmit a buffered MSDU during the beacon interval in which it was 9 announced, for example due to contention with other STAs, the STA shall retain the buffered 10 MSDU or A-MSDU and announce the MSDU or A-MSDU again by transmitting an ATIM during 11 the next ATIM Window. 12 13 j) Following the transmission of all buffered MSDUs or A-MSDUs, a STA may transmit MSDUs or 14 A-MSDUs without announcement to STAs that are known to be in the Awake state for the current 15 beacon interval due to an appropriate ATIM management or Beacon frame having been transmitted 16 or received. 17 18 k) A STA may discard frames buffered for later transmission to power-saving STAs if the STA deter- 19 mines that the frame has been buffered for an excessive amount of time or if other conditions inter- 20 nal to the STA implementation make it desirable to discard buffered frames (e.g., buffer starvation). 21 In no case shall a frame be discarded that has been buffered for less than dot11BeaconPeriod. The 22 23 algorithm to manage this buffering is beyond the scope of this standard. 24 25 Insert the following subclause (11.2.3) after 11.2.2.4: 26 27 11.2.3 SM Power Save 28 29 30 A STA consumes power on all active receive chains, even though they are not necessarily required for the 31 actual frame exchange. The SM Power Save feature allows a STA to operate with only one active receive 32 chain for a significant portion of time. 33 34 The STA controls which receive chains are active through the PHY-RXCONFIG.request primitive specifying 35 36 a PHYCONFIG_VECTOR parameter ACTIVE_RXCHAIN_SET that indicates which of its receive chains 37 should be active. 38 39 In Dynamic SM Power Save mode, a STA enables its multiple receive chains when it receives the start of a 40 frame sequence addressed to it. Such a frame sequence shall start with a single-spatial stream individually 41 42 addressed frame that requires an immediate response and that is addressed to the STA in Dynamic SM Power 43 Save mode. An RTS/CTS sequence may be used for this purpose. The receiver shall be capable of receiving 44 a PPDU that is sent using an MCS that indicates more than one spatial stream a SIFS after the end of its re- 45 sponse frame transmission. The receiver switches to the multiple receive chain mode when it receives the 46 RTS addressed to it and switches back immediately when the frame sequence ends. 47 48 NOTE—A STA operating Dynamic SM Power Save mode cannot distinguish between an RTS/CTS sequence that pre- 49 cedes a MIMO transmission and any other RTS/CTS and therefore always enables its multiple receive chains when it 50 receives an RTS addressed to itself. 51 52 The receiver can determine the end of the frame sequence through any of the following: 53 — It receives an individually addressed frame addressed to another STA 54 55 — It receives a frame with a TA that differs from the TA of the frame that started the TXOP 56 — The CS mechanism (see 9.2.1) indicates that the medium is idle at the TxPIFS slot boundary (defined 57 58 in 9.2.10) 59 60 A STA in Static SM Power Save mode maintains only a single receive chain active. 61 62 An HT STA may use the SM Power Save Action frame to communicate its SM Power Save state. A non-AP 63 64 HT STA may also use SM Power Save bits in the HT capabilities element of its Association Request to 65 achieve the same purpose. The latter allows the STA to use only a single receive chain immediately after as-

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 sociation. 2 3 A STA that has one or more DLS links shall notify all STAs with which it has a DLS link of any change in 4 5 SM power save mode before operating in that mode. 6 7 Changes to the number of active receive chains are made only after the SM Power Save Mode indication has 8 been successfully delivered (i.e., by acknowledgment of a frame carrying the HT Capabilities element or by 9 10 acknowledgement of a SM Power Save frame). The SM Power Save Mode indication shall be transmitted 11 using a individually addressed frame. 12 13 14 11.3 STA Authentication and Association 15 16 Change list item a.2) as follows: 17 18 a) Class 1 frames (permitted from within States 1, 2, and 3): 19 20 2) Management frames 21 i) Probe request/response 22 23 ii) Beacon 24 iii) Authentication: Successful authentication enables a STA to exchange Class 2 frames. 25 Unsuccessful authentication leaves the STA in State 1. 26 27 iv) Deauthentication: Deauthentication notification when in State 2 or State 3 changes the 28 STA's state to State 1. The STA shall become authenticated again prior to sending Class 2 29 frames. Deauthentication notification when in State 3 implies disassociation as well. 30 31 v) Announcement traffic indication message (ATIM) 32 vi) Public Action 33 34 vii) Within an IBSS, all Action frames and all Action No Ack frames. 35 36 Change list item c).2) as follows: 37 38 c) Class 3 frames (if and only if associated; allowed only from within State 3): 39 40 2) Management frames 41 i) Within an infrastructure BSS, all Action and Action No Ack frames except the following 42 frames: 43 44 A) Public Action 45 46 11.3.2 Association, reassociation, and disassociation 47 48 49 11.3.2.2 AP association procedures 50 51 Insert items b2 and b3 into the list in 11.3.2.2 as follows: 52 53 b2) An AP shall refuse an association request from a STA that does not support all the Rates in the BSS- 54 BasicRateSet parameter. 55 56 b3) An AP shall refuse an association request from an HT STA that does not support all the MCSs in the 57 BSSBasicMCSSet parameter. 58 59 11.3.2.4 AP reassociation procedures 60 61 62 Insert items b2 and b3 into the list in 11.3.2.4 as follows: 63 64 b2) An AP shall refuse a reassociation request from a STA that does not support all the Rates in the 65 BSSBasicRateSet parameter.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 b3) An AP shall refuse a reassociation request from an HT STA that does not support all the MCSs in 2 the BSSBasicMCSSet parameter. 3 4 5 6 11.4 TS operation 7 8 Insert the following subclause (11.4.4b) after 11.4.4a: 9 10 11 11.4.4b PSMP management 12 13 14 A STA may attempt to create a Scheduled PSMP session with its AP only if the AP has the S-PSMP Support 15 field in the Extended Capabilities element set to 1. 16 17 18 The TSPEC reserves resources within the AP and modifies the AP's scheduling behavior. The parameters in 19 the TSPEC can be grouped into two categories: PSMP scheduling and PSMP reservation. The scheduling pa- 20 rameters are used by the AP to schedule a suitable Service Interval. The reservation parameters are used by 21 the AP to reserve time in the PSMP-UTT and PSMP-DTT. 22 23 24 The Service Start time and Service Interval specifies the PSMP schedule in the response’s Scheduling ele- 25 ment. All other parameters result in a reservation for the PSMP-UTT and PSMP-DTT within the scheduled 26 PSMP sequence. 27 28 29 An AP shall terminate the PSMP session only when the last TS associated with the particular PSMP session 30 is terminated. 31 32 33 Once created, a PSMP session can be extended by another TSPEC setup. A STA that has an established PSMP 34 session may issue an additional TSPEC request with: 35 36 — the Aggregation field set to 1, 37 38 — the Scheduled field set to 1 and APSD field set to 0 (S-PSMP), and 39 40 — the Minimum Service Interval and Maximum Service Interval fields both set to the Service Interval 41 field value from the Schedule element specified when the PSMP session was established. 42 43 44 The AP shall return an identical Schedule element for all TSPEC response frames related to the same PSMP 45 session. 46 NOTE—A STA that does not have an established PSMP session might send a TSPEC request specifying S-PSMP ses- 47 sion with the same service interval. The AP is free to choose between aggregating this request with an existing PSMP 48 session of the same service interval, or creating a new PSMP session. 49 50 51 The parameters of a TS already associated with the PSMP session can be changed; however the Service In- 52 terval shall not be changed. The Start Time of existing STAs in the PSMP schedule shall not be changed by 53 the addition of a TSPEC from a new STA. 54 55 56 A TSPEC that reserves resources for a STA under scheduled PSMP shall have the APSD and Scheduled fields 57 set to indicate Scheduled PSMP as defined in Table 7-41. 58 59 60 The non-AP STA SME decides that a PSMP session needs to be established. How it does this, and how it 61 selects the related TSPEC parameters, is beyond the scope of this standard. 62 63 64 The Minimum Service Interval field of the TSPEC element of an ADDTS request frame shall be a multiple 65 of the Service Interval Granularity indicated by the AP in its Extended Capabilities element.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 11.4.7 TS deletion 2 3 Insert Reason Code 31 row into Table 11-3: 4 5 6 7 Table 11-3—Encoding of ReasonCode to Reason Code field value for DELTS 8 9 10 ReasonCode Reason Code field 11 12 SERVICE_CHANGE_PRECLUDES_TS 31 13 14 15 16 Change the fourth paragraph of 11.4.7 as follows: 17 18 An HC should not delete a TSPEC without a request from the SME except due to inactivity (see 11.4.8) or 19 an HC service change that precludes the HC from continuing to meet the requirements of the TSPEC. 20 21 22 11.5 Block Ack operation 23 24 25 11.5.1 Setup and modification of the Block Ack parameters 26 27 11.5.1.1 Procedure at the originator 28 29 30 Insert the following list item a) and NOTE immediately after the first paragraph of 11.5.1.1, i.e. before the 31 existing list item a). Renumber the existing list items as appropriate. 32 33 a) If the initiating STA is an HT STA, and is a member of an IBSS, and has no other existing Block 34 Ack agreement with the recipient STA, then the initiating STA shall transmit a Probe Request to the 35 recipient STA and shall not transmit an ADDBA request frame unless it receives a Probe Response 36 from the recipient within dot11ADDBAFailureTimeout. 37 38 NOTE—When the Block Ack agreement is being established between a non-AP STA and its AP, then the orig- 39 inator and the recipient have exchanged capability information during the association exchange that allows 40 them to determine whether the other STA is an HT STA or not. If the STA is establishing a Block Ack agree- 41 ment with another STA through DLS, then the DLS setup procedure includes the exchange of capability infor- 42 mation that allows both STAs to determine whether the other STA is an HT STA or not. 43 44 Insert the following subclause (11.5.1.3) after 11.5.1.2: 45 46 11.5.1.3 Procedure common to both originator and recipient 47 48 49 Once a Block Ack agreement has been successfully established between two STAs, the type of agreement 50 thus established is dependent on the capabilities of the STAs and the contents of the ADDBA frames used to 51 establish this agreement as defined in Table 11-5a. 52 53 54 11.6 Higher layer timer synchronization 55 56 11.6.2 Procedure at the STA 57 58 59 Change the second paragraph of 11.6.2 as follows: 60 61 In order to determine whether to provide an MLME-HL-SYNC.indication primitive for a particular data 62 frame, a MAC that supports MLME-HL-SYNC primitives compares the Address 1 field in a data frame’s 63 64 MAC header against a list of group addresses previously registered by an MLME-HL-SYNC.request primi- 65 tive. If the MAC and the transmitter of the Sync frame are collocated within the same STA, the MLME-HL-

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table 11-5a—Types of Block Ack agreement based on capabilities and ADDBA conditions 2 3 4 Capabilities condition ADDBA condition Type of Block Ack agreement 5 6 Block Ack Policy subfield set to 1 Immediate 7 One or both of the STA are non-HT 8 Block Ack Policy subfield set to 0 Delayed 9 10 Both STAs are HT STAs Block Ack Policy subfield set to 1 HT-Immediate 11 Both STAs are HT STAs and both of Block Ack Policy subfield set to 0 HT-Delayed 12 the STAs set the HT-Delayed Block 13 Ack subfield of the HT Capabilities 14 element to 1 15 16 Both STAs are HT STAs and at least Block Ack Policy subfield set to 0 Delayed 17 one of the STAs sets the HT-Delayed 18 Block Ack subfield of the HT Capabil- 19 ities element to 0 20 21 22 23 SYNC.indication primitive shall occur when the last symbol of the PPDU carrying a matching data frame is 24 transmitted. Otherwise, the indication shall occur when the last symbol of the PPDU carrying the matching 25 data frame is received. In both cases, the MLME-HL-SYNC.indication primitive provided is simultaneous 26 (within implementation dependent delay bounds) with the indication provided to other STAs within the BSS 27 28 for the same data frame. 29 30 Change list items a) to d) in 11.7 as follows [note item d) is split into two items]: 31 32 33 11.7 DLS operation 34 35 36 a) A STA, STA-1, that intends to exchange frames directly with another non-AP STA, STA-2, invokes 37 DLS and sends a DLS Request frame to the AP (step 1a in Figure 11-15). This request contains the 38 rate set, capabilities of STA-1, and the MAC addresses of STA-1 and STA-2. If STA-1 is an HT 39 STA, this request also contains the HT capabilities of STA-1. 40 41 b) If STA-2 is associated in the BSS, direct streams are allowed in the policy of the BSS, and STA-2 is 42 indeed a QoS STA, then the AP forwards the DLS Request frame independently of whether the AP 43 is capable of decoding all of the fields in the body of the frame, to the recipient, STA-2 (step 1b in 44 Figure 11-15). 45 46 c) If STA-2 accepts the direct stream, it sends a DLS Response frame to the AP (step 2a in Figure 11- 47 15), which contains the rate set, (extended) capabilities of STA-2, and the MAC addresses of STA-1 48 and STA-2. If STA-2 is an HT STA, this response also contains an HT capabilities element repre- 49 senting the HT capabilities of STA-2. 50 51 d) The AP forwards the DLS Response frame to STA-1 (step 2b in Figure 11-15), independently of 52 whether the AP is capable of decoding all of the fields in the body of the frame. 53 54 e) after which If the DLS Response frame contained a status code of SUCCESSFUL, the direct link 55 becomes active and frames can be sent from STA-1 to STA-2 and from STA-2 to STA-1. 56 57 11.7.1 DLS procedures 58 59 60 11.7.1.2 Setup procedure at the AP 61 62 Change 11.7.1.2 as follows: 63 64 65 Upon receipt of the DLS Request frame (step 1a in Figure 11-15), the AP shall

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 — Send DLS Response frame to the STA that sent the DLS Request frame with a result code of Not 2 Allowed in the BSS, if direct links are not allowed in the BSS (step 2b in Figure 11-15). 3 4 — Send DLS Response frame to the STA that sent the DLS Request frame with a result code of Not 5 Present, if the destination STA is not present in the BSS (step 2b in Figure 11-15). 6 — Send DLS Response frame to the STA that sent the DLS Request frame with a result code of Not a 7 8 STA, if the destination STA does not have QoS facility (step 2b in Figure 11-15). 9 — Send the DLS Request frame, with all fields having the same value as the DLS Request frame 10 received by the AP, to the destination STA (step 1b in Figure 11-15) independently of whether the 11 12 AP is capable of decoding all of the fields in the body of the frame. 13 14 Change 11.7.2 as follows: 15 16 11.7.2 Data transfer after setup 17 18 19 For each active direct link, a STA shall record the MAC and PHY features, rates and MCSs that are sup- 20 ported by the other STA participating in the direct link, according to the Supported Rates, Extended Sup- 21 ported Rates, Capability Information and HT Capabilities fields within the DLS Request and DLS Response 22 frames that were used to establish the direct link. 23 24 25 A STA transmitting frames within a direct link shall not transmit frames using features, rates or MCSs that 26 are not supported by the other STA in the direct link. After establishing protection as required by 9.13 or 27 9.2.5.5a, STAs may use features, rates or MCSs that are supported by both of the STAs in the direct link, 28 even when the AP does not support those features, except for transmission of a 40 MHz mask PPDU, which 29 is governed by the rules found in 11.14.4. 30 31 32 Both the STAs may use direct link for data transfers using any of the access mechanisms defined in this stan- 33 dard. STAs participating in a direct link may also set up Block Ack if needed. If needed, tThe STAs may set 34 up TSs with the HC to ensure they have enough bandwidth or use polled TXOPs for data transfer. A protective 35 mechanism (such as transmitting using HCCA, RTS/CTS, or the mechanism described in 9.13) should be 36 37 used to reduce the probability of other STAs interfering with the direct-link transmissions. 38 39 40 11.9 DFS procedures 41 42 11.9.2 Quieting channels for testing 43 44 Change the fourth paragraph of 11.9.2 as follows: 45 46 47 Control of the channel is lost at the start of a quiet interval, and the NAV is set by all the STAs in the BSS for 48 the length of the quiet interval. Transmission by any STA in the BSS of any MPDU and any associated ac- 49 knowledgment within either the primary channel or the secondary channel (if present) of the BSS shall be 50 complete before the start of the quiet interval. If, before starting transmission of an MPDU, there is not 51 52 enough time remaining to allow the transmission to complete before the quiet interval starts, the STA shall 53 defer the transmission by selecting a random backoff time, using the present CW (without advancing to the 54 next value in the series). The short retry counter and long retry counter for the MSDU or A-MSDU are not 55 affected. 56 57 58 11.9.6 Requesting and reporting of measurements 59 60 Change the fourth paragraph of 11.9.6 as follows: 61 62 A STA that successfully requests another STA to perform a measurement on another channel should not 63 64 transmit MSDUs, A-MSDUs or MMPDUs to that STA during the interval defined for the measurement plus 65 any required channel switch intervals. In determining this period, a STA shall assume that any required chan-

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 nel switches take less than dot11ChannelSwitchTime per switch. 2 3 11.9.7 Selecting and advertising a new channel 4 5 6 11.9.7.2 Selecting and advertising a new channel in an IBSS 7 8 Change the first paragraph of 11.9.7.2 as follows: 9 10 11 DFS in an IBSS is complicated by the following: 12 — There is no central AP function for collating measurements or coordinating a channel switch. If 13 STAs make independent decisions to switch channel in the presence of radar, there is a danger that 14 15 all STAs will announce a switch to differing channels if several of them detect the radar. 16 — There is no association protocol that can be used to 17 18 — Exchange supported channel information and 19 — Determine membership of the IBSS at a given instant for requesting measurements. 20 21 — Beaconing is a shared process; therefore, it cannot be guaranteed that a STA that has something to 22 send (e.g., a channel switch message) will be the next STA to transmit a Beacon frame. 23 — A 20/40 MHz IBSS cannot be changed to a 20 MHz IBSS and a 20 MHz IBSS cannot be changed to 24 25 a 20/40 MHz IBSS. 26 27 Insert the following subclause (11.9.7.3) after 11.9.7.2: 28 29 11.9.7.3 HT-greenfield transmissions in regulatory classes with a Behavior Limits set of 16 30 31 32 The requirements described in this subclause apply only when an HT STA is operating in a regulatory class 33 for which the Behavior Limits set listed in Annex J includes the value 16; i.e., the regulatory class is subject 34 to DFS with 50-100 µs radar pulses. 35 36 37 A Non-HT OBSS scan operation is a passive or active scan of the primary channel, and secondary channel if 38 it is within a 20/40 MHz BSS that a STA currently uses or intends to use. During a Non-HT OBSS scan op- 39 eration, the channel scan duration is a minimum of dot11OBSSScanPassiveTotalPerChannel TU when scan- 40 ning passively and a minimum of dot11OBSSScanActiveTotalPerChannel TU when scanning actively. 41 42 43 Before an HT STA starts a BSS with the OBSS Non-HT STAs Present field of the HT Operation element set 44 to 0, the HT STA shall perform a non-HT OBSS Scan in order to search for any existing non-HT OBSSs. 45 46 When an HT STA detects there are one or more non-HT OBSSs, if the HT STA starts a BSS on that channel 47 then the HT STA shall set the OBSS Non-HT STAs Present field of the HT Operation element to 1; otherwise, 48 49 the HT STA may set the OBSS Non-HT STAs Present field of the HT Operation element to 0. 50 NOTE—Detection of a non-HT OBSS can be achieved by the reception of a Beacon or Probe Response that does not 51 contain an HT Capabilities element or HT Operation element. 52 53 An HT AP shall not transmit a PPDU with the FORMAT parameter of the TXVECTOR set to HT_GF if the 54 OBSS Non-HT STAs Present field of the HT Operation element is set to 1 in the most recently transmitted 55 management frame that contained that element. 56 57 58 An HT non-AP STA shall not transmit a PPDU with the FORMAT parameter of the TXVECTOR set to 59 HT_GF if the most recently received frame received from its AP containing an HT Operation element has the 60 OBSS Non-HT STAs Present field set to 1. 61 NOTE—This requirement applies also to PPDUs transmitted on a direct link between two non-AP STAs. 62 63 64 When moving the BSS to a new channel or set of channels and before completing a non-HT OBSS scan of 65 the new channel or set of channels, an HT AP shall set the OBSS Non-HT STAs Present field of the HT Op-

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 eration element to 1. After having completed one non-HT OBSS scan of the new channel or set of channels, 2 if the HT AP has detected that there are zero non-HT OBSSs then the HT AP may set the OBSS Non-HT 3 STAs Present field of the HT Operation element to 0. 4 5 6 Insert the following subclauses (11.14 to 11.18) after 11.13: 7 8 9 11.14 20/40 MHz BSS Operation 10 11 11.14.1 Rules for operation in 20/40 MHz BSS 12 13 14 The rules described in 11.14.1 to 11.14.12 are applicable to STAs that are either a STA 5G or a STA 2G4. 15 16 An FC HT STA that transmits a frame containing an Extended Capabilities element shall set the 20/40 BSS 17 Coexistence Management Support field of this element to 1. 18 19 20 An HT STA 2G4 that is a member of an IBSS and that transmits a frame containing an HT Operation element 21 or Secondary Channel Offset element shall set the Secondary Channel Offset field of this element to SCN. 22 23 24 11.14.2 Basic 20/40 MHz BSS functionality 25 26 An HT AP declares its channel width capability (20 MHz only or 20/40 MHz) in the Supported Channel 27 Width Set field of the HT Capabilities element. 28 29 30 An HT AP shall set the STA Channel Width field to 1 in frames in which it has set the Secondary Channel 31 Offset field to SCA or SCB. An HT AP shall set the STA Channel Width field to 0 in frames in which it has 32 set the Secondary Channel Offset field to SCN. 33 34 35 A non-AP HT STA declares its channel width capability (non-FC HT STA or FC HT STA) in the Supported 36 Channel Width Set in the HT Capabilities element. 37 NOTE 1—A 20/40 MHz BSS can include any mixture of FC HT STAs, non-FC HT STAs and non-HT STAs. Protection 38 requirements for mixed networks are defined in 9.13. 39 40 NOTE 2—A non-AP HT STA can switch between FC HT STA and non-FC HT STA operation by disassociation and 41 association or reassociation. 42 43 An HT STA shall not indicate support for 40 MHz unless it supports reception and transmission of 40 MHz 44 PPDUs using all MCSs within the BasicMCSSet and all MCSs that are mandatory for the attached PHY. 45 46 47 An HT STA shall not transmit a 20 MHz PPDU containing one or more data MPDUs using the secondary 48 channel of a 20/40 MHz BSSs. The Notify Channel Width Action frame may be used by a non-AP STA to 49 notify another STA that the STA wishes to receive frames in the indicated channel width. 50 51 An HT STA that is a member of an IBSS adopts the value of the Secondary Channel Offset field in received 52 53 frames according to the rules in 11.1.4 and shall not transmit a value for the Secondary Channel Offset field 54 that differs from the most recently adopted value. 55 56 11.14.3 Channel selection methods for 20/40 MHz Operation 57 58 59 11.14.3.1 General 60 61 For an HT STA, the following MIB attributes shall be set to TRUE: dot11RegulatoryClassesImplemented, 62 dot11RegulatoryClassesRequired, and dot11ExtendedChannelSwitchEnabled. 63 64 65 An AP operating a 20/40 MHz BSS, on detecting an overlapping BSS whose primary channel is the AP’s

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 secondary channel, switches to 20 MHz BSS operation and may subsequently move to a different channel or 2 pair of channels. An IDO STA operating a 20/40 MHz IBSS, on detecting an overlapping BSS whose primary 3 channel is the IDO STA's secondary channel, may choose to move to a different pair of channels. 4 5 6 11.14.3.2 Scanning requirements for a 20/40 MHz BSS 7 8 Before an AP or IDO STA starts a 20/40 MHz BSS it shall perform a minimum of 9 10 dot11BSSWidthChannelTransitionDelayFactor overlapping BSS scans (see 11.14.5) to search for existing 11 BSSs. 12 13 If the AP or IDO STA starts a 20/40 MHz BSS in the 5 GHz band and the BSS occupies the same two chan- 14 15 nels as any existing 20/40 MHz BSSs, then the AP or IDO STA shall ensure that the primary channel of the 16 new BSS is identical to the primary channel of the existing 20/40 MHz BSSs and that the secondary channel 17 of the new 20/40 MHz BSS is identical to the secondary channel of the existing 20/40 MHz BSSs, unless the 18 AP discovers that on these two channels are existing 20/40 MHz BSSs with different primary and secondary 19 channels. 20 21 22 If an AP or IDO STA starts a 20/40 MHz BSS in the 5 GHz band, the selected secondary channel should cor- 23 respond to a channel on which no beacons are detected during the 24 dot11BSSWidthChannelTransitionDelayFactor overlapping BSS scan time performed by the AP or IDO 25 STA, unless there are beacons detected on both the selected primary and secondary channels. 26 27 NOTE—The 20/40 MHz channel sets and their corresponding behavior limits (i.e., choice of primary and secondary 28 channels) permissible in each regulatory class are defined in Annex J and Annex I respectively. 29 30 An HT AP or an IDO STA that is also an HT STA should not start a 20 MHz BSS in the 5 GHz band on a 31 channel that is the secondary channel of a 20/40 MHz BSS. 32 33 34 The AP or IDO STA may continue to periodically scan after the BSS has been started. Information obtained 35 during such scans is used as described within this subclause and within 11.14.12. 36 37 38 After starting a 20 MHz BSS, an FC HT AP 2G4 shall perform a minimum of 39 dot11BSSWidthChannelTransitionDelayFactor overlapping BSS scans, either itself or through its associated 40 STAs before making a transition from a 20 MHz BSS to a 20/40 MHz BSS. When the AP performs the scan- 41 ning and the secondary channel for the 20/40 MHz BSS has been selected, then the scan shall be performed 42 over the set of channels that are allowed operating channels within the current operational regulatory domain 43 44 and whose center frequency falls within the affected frequency range given by Equation (11-3). When the AP 45 performs the scanning without an intended secondary channel for the 20/40 MHz BSS, or when the AP's as- 46 sociated STA(s) perform the scanning, then the scan shall be performed on all channels in the frequency band. 47 NOTE—An FC HT AP can change from operating a 20 MHz BSS to a 20/40 MHz BSS while maintaining associations 48 by making a change to the transmitted value of the Secondary Channel Offset field. 49 50 f + f f + f 51 affected frequency range = [,]------P S – 2 5 M H z ------P S + 2 5 M H z (11-3) 52 2 2 53 54 55 where 56 fP = the center frequency of channel P 57 f = the center frequency of channel S 58 S 59 60 An FC HT AP 2G4 shall maintain a local boolean variable 20/40 Operation Permitted that can have either 61 the value TRUE or FALSE. The initial value of 20/40 Operation Permitted shall be FALSE. The value of 20/ 62 40 Operation Permitted is recomputed according to Equation (11-4) whenever a BSS channel width trigger 63 64 event is detected or whenever a period of time has elapsed with no BSS channel width triggers being detected 65 and no overlap being reported, as defined in 11.14.12.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 20/40 Operation Permitted = (P == OPi for all values of i) AND 2 (P == OTi for all values of i) AND 3 (S == OS for all values of i)(11-4) 4 i 5 6 where 7 P is the operating or intended primary channel of the 20/40 MHz BSS 8 S is the operating or intended secondary channel of the 20/40 MHz BSS 9 10 OPi is member i of the set of channels that are members of the channel set C and that are the primary 11 operating channel of at least one 20/40 MHz BSS that is detected within the AP's BSA during the 12 previous dot11BSSWidthChannelTransitionDelayFactor * dot11BSSWidthTriggerScanInterval 13 seconds 14 15 OSi is member i of the set of channels that are members of the channel set C and that are the secondary 16 operating channel of at least one 20/40 MHz BSS that is detected within the AP's BSA during the 17 previous dot11BSSWidthChannelTransitionDelayFactor * dot11BSSWidthTriggerScanInterval 18 seconds 19 20 OTi is member i of the set of channels that comprises all channels that are members of the channel set C 21 that were listed at least once in the Channel List fields of 20/40 BSS Intolerant Channel Report ele- 22 ments received during the previous dot11BSSWidthChannelTransitionDelayFactor * 23 dot11BSSWidthTriggerScanInterval seconds and all channels that are members of the channel set 24 25 C and that are the primary operating channel of at least one 20 MHz BSS that were detected 26 within the AP's BSA during the previous dot11BSSWidthChannelTransitionDelayFactor * 27 dot11BSSWidthTriggerScanInterval seconds 28 C is the set of all channels that are allowed operating channels within the current operational regula- 29 30 tory domain and whose center frequency falls within the affected frequency range given by 31 Equation (11-3) 32 33 and where the use of "==" in the above expressions means that the value on the left side of the "==" 34 is to be tested for equality with the value on the right side of the "==" yielding a boolean value of 35 36 TRUE if the two sides are equal and FALSE if the two sides are unequal. If either side of the 37 equality is the empty set or has a NULL value, then the expression is defined to have a boolean 38 value of TRUE. 39 40 41 An FC HT AP 2G4 shall not start a 20/40 MHz BSS in the 2.4 GHz band if the value of the local variable 20/ 42 40 Operation Permitted is FALSE (see Equation (11-4)). 43 44 An FC HT AP 2G4 may transmit a frame containing a Secondary Channel Offset field set to a value of SCA 45 or SCB only if 20/40 Operation Permitted is TRUE. 46 47 48 In addition to information obtained by the FC HT AP 2G4 through its own scanning, an FC HT AP 2G4 shall 49 use 20/40 BSS Intolerant Channel Report information from received 20/40 BSS Coexistence Management 50 frames with a value for the Address 1 field that matches the FC HT AP 2G4 using either individual or group 51 addressing, but with no qualification of the Address 3 value, when determining if 20/40 Operation Permitted 52 53 is TRUE or FALSE. The information from the Channel List fields of received 20/40 BSS Intolerant Channel 54 Report elements is used in generating the OT set for Equation (11-4). 55 56 After initial establishment of the 20/40 MHz BSS, if the value of 20/40 Operation Permitted becomes 57 58 FALSE, the FC HT AP 2G4 reverts to 20 MHz BSS operation (see 11.14.12). The FC HT AP 2G4 can sub- 59 sequently move the BSS to a pair of channels where 20/40 Operation Permitted evaluates to TRUE. 60 61 11.14.3.3 Channel management at the AP and in an IBSS 62 63 64 While operating a 20/40 MHz BSS, an IDO STA or an AP may decide to move its BSS, and an AP may decide 65 to switch the BSS to 20 MHz operation either alone or in combination with a channel move. These channel

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 move or BSS width switch operations can occur if, for example, another BSS starts to operate in either or both 2 of the primary or secondary channels, or radar is detected in either or both of the primary or secondary chan- 3 nels or for other reasons that are beyond the scope of this standard. Specifically, the AP or IDO STA may 4 5 move its BSS to a different pair of channels, and the AP may separately, or in combination with the channel 6 switch, change from a 20/40 MHz BSS to a 20 MHz BSS using either the primary channel of the previous 7 channel pair or any other available 20 MHz channel. While operating a 20 MHz BSS, an IDO STA or an AP 8 may decide to move its BSS and an AP may decide to switch the BSS to a 20/40 MHz BSS, either alone or 9 in combination with a channel move. 10 11 12 If an AP or IDO STA uses one or more Extended Channel Switch Announcement frames without also using 13 Beacon and Probe Response frames to announce a change of regulatory class and/or a change in channel(s), 14 and the new regulatory class supports either of the behavior limits 13 or 14 as identified in the appropriate 15 table of Annex J (i.e., Table J.1, Table J.2 or Table J.3), then the BSS width (20 MHz BSS or 20/40 MHz 16 17 BSS) immediately after the switch shall be the same as the BSS width immediately before the transmission 18 of the first Extended Channel Switch Announcement frame that announced the change. The AP or IDO STA 19 may subsequently perform a BSS width change. 20 NOTE—If an AP or IDO STA uses one or more Extended Channel Switch Announcement frames without also using 21 Beacon and Probe Response frames to announce a change of regulatory class and/or a change in channel(s), then the AP 22 or IDO STA cannot change from 20 MHz BSS operation to 20/40 MHz BSS operation as part of that change, even if the 23 new regulatory class supports 20/40 MHz BSS operation, because Extended Channel Switch Announcement frames do 24 not convey secondary channel information (i.e., information regarding whether a secondary channel, if permitted in the 25 regulatory class, is to be used). 26 27 28 When switching a 20/40 MHz BSS to 20 MHz BSS mode, the AP may recalculate the TS bandwidth budget 29 and may delete one or more active Traffic Streams by invoking the MLME-DELTS.request primitive with a 30 ReasonCode value of SERVICE_CHANGE_PRECLUDES_TS. 31 32 An AP switches between 20/40 MHz BSS and 20 MHz BSS: 33 34 — by changing the value of the Secondary Channel Offset field of the HT Operation element in the 35 Beacon, and/or 36 37 — by changing the value of the Secondary Channel Offset field of the Secondary Channel Offset ele- 38 ment, and/or 39 40 — through the New Regulatory Class field of transmitted Extended Channel Switch Announcement ele- 41 ments. 42 43 In order to maintain existing associations and/or minimize disruption to communications with other STAs 44 while making a channel width change or while performing a channel pair relocation, an AP may inform HT 45 46 STAs within its BSS that it is making the change by including an Extended Channel Switch Announcement 47 element in Beacon, Probe Response, and Extended Channel Switch Announcement frame transmissions until 48 the intended channel switch time. An IDO STA may inform HT STAs within its BSS that it is performing a 49 channel pair relocation by including an Extended Channel Switch Announcement element in Beacon, Probe 50 Response, and Extended Channel Switch Announcement frame transmissions until the intended channel 51 52 switch time. The New Channel Number of the Extended Channel Switch Announcement element represents 53 the new channel (when the BSS after relocation/width change will be a 20 MHz BSS) or the primary channel 54 of the new pair of channels (when the BSS after relocation/width change will be a 20/40 MHz BSS). When 55 changing to a new pair of channels, the New Regulatory Class field specifies the position of the secondary 56 channel relative to the new primary channel, i.e., either above or below. 57 58 59 When transmitting HT Operation elements, Channel Switch Announcement elements, and/or Extended Chan- 60 nel Switch Announcement elements, the AP moving the BSS or changing its channel width selects a combi- 61 nation of operating parameters from any single row of any one of the tables in Annex J that is appropriate for 62 the current operating domain of the AP. Similarly, when transmitting HT Operation elements, Channel 63 64 Switch Announcement elements, and/or Extended Channel Switch Announcement elements, the IDO STA 65 moving the BSS selects a combination of operating parameters from any single row of any one of the tables

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 in Annex J that is appropriate for the current operating domain of the IDO STA. The AP or IDO STA selects 2 one channel number from the Channel Set column of the selected row. The AP or IDO STA includes the se- 3 lected information in subsequently transmitted frames that contain any combination of the following four el- 4 5 ements: 6 — HT Operation element 7 8 — Channel Switch Announcement element 9 — Extended Channel Switch Announcement element 10 11 — Secondary Channel Offset element 12 13 The AP or IDO STA shall set the Secondary Channel Offset field of transmitted HT Operation elements and 14 transmitted Secondary Channel Offset elements to SCA if the Behavior Limit parameter of the selected row 15 16 contains the value 13. The AP or IDO STA shall set the Secondary Channel Offset field of transmitted HT 17 Operation elements and transmitted Secondary Channel Offset elements to SCB if the Behavior Limit param- 18 eter of the selected row contains the value 14. The AP or IDO STA shall set the Secondary Channel Offset 19 field of transmitted HT Operation elements and transmitted Secondary Channel Offset elements to SCN if the 20 Behavior Limit parameter of the selected row contains neither the value 13 nor the value 14. 21 22 23 The AP or IDO STA shall set the New Channel Number field of transmitted Channel Switch Announcement 24 elements and Extended Channel Switch Announcement elements to the value of the selected channel from 25 the selected row. 26 27 28 The AP or IDO STA shall set the New Regulatory Class field of transmitted Extended Channel Switch An- 29 nouncement elements to the value of the Regulatory Class column of the selected row. 30 31 Movement of a 20/40 MHz BSS from one channel pair to a different channel pair and changing between 20 32 MHz and 20/40 MHz operation should be scheduled so that all STAs in the BSS, including STAs in power 33 34 save mode, have the opportunity to receive at least one Extended Channel Switch Announcement element or 35 Channel Switch Announcement element before the switch. 36 37 When the Extended Channel Switch Announcement element and Extended Channel Switch Announcement 38 frame are transmitted in bands where dot11SpectrumManagementRequired is TRUE, the Channel Switch 39 40 Announcement element and Channel Switch Announcement frame may also be transmitted. A STA that an- 41 nounces a channel switch using both the Extended Channel Switch Announcement element and the Channel 42 Switch Announcement element shall set the New Channel Number of both elements to the same value. An 43 HT STA that receives a channel switch announcement through both the Extended Channel Switch Announce- 44 ment element and the Channel Switch Announcement element shall ignore the received Channel Switch An- 45 46 nouncement element. 47 48 For 20 MHz operation when the New Regulatory Class signifies 40 MHz channel spacing, the 20 MHz chan- 49 nel is the primary channel of the 40 MHz channel. 50 51 52 11.14.4 40 MHz PPDU transmission restrictions 53 54 11.14.4.1 Fields used to determine 40 MHz PPDU transmission restrictions 55 56 Several fields from various frames are used to convey information between STAs regarding the support for 57 58 40 MHz PPDU transmission and reception and regarding any current prohibition against the transmission and 59 reception of 40 MHz PPDUs. 60 61 The rules defined in 11.14.4.2, 11.14.4.3 and 11.14.4.4 describe the behavior that accompanies those fields. 62 63 64 The fields that are used to determine the status of the transmission and reception of 40 MHz PPDUs are as 65 follows:

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 — The Supported Channel Width Set field of the HT Capabilities element 2 3 — The Secondary Channel Offset field of the HT Operation element 4 — The STA Channel Width field of the HT Operation element 5 6 — The Channel Width field of the Notify Channel Width action frame 7 — The Extended Channel Switch Announcement element 8 9 The Supported Channel Width Set field is used to indicate whether or not the transmitting STA is capable of 10 11 transmitting and receiving 40 MHz PPDUs. 12 NOTE—The Supported Channel Width Set field transmitted by an AP is constant for the lifetime of its BSS as it is a 13 parameter of the MLME-START.request primitive. 14 15 In addition to the restrictions on transmission of 40 MHz mask PPDUs found in subclause 11.14.4.1 to 16 11.14.4.4, if a STA operating in the 2.4 GHz ISM band has no means of determining the presence of non- 17 802.11 communication devices operating in the area, then the STA shall not transmit any 40 MHz mask PP- 18 19 DUs. 20 21 In addition to the restrictions on transmission of 40 MHz mask PPDUs found in subclauses 11.14.4.1 to 22 11.14.4.4, if a STA operating in the 2.4 GHz ISM band has a means of determining the presence of non- 23 802.11 communication devices operating in the area and determines that either no non-802.11 communica- 24 25 tion device is operating in the area or that non-802.11 communication devices are operating in the area but 26 the STA implements a coexistence mechanism for these non-802.11 communication devices, then the STA 27 may transmit 40 MHz mask PPDUs, otherwise, the STA shall not transmit any 40 MHz mask PPDUs. 28 29 11.14.4.2 Infrastructure non-AP STA restrictions 30 31 32 A STA that is associated with an AP shall not transmit a value for the Supported Channel Width Set field that 33 differs from a previously transmitted value during its current association. 34 35 The Secondary Channel Offset field is used to indicate whether the BSS is occupying a 40 MHz wide pair of 36 37 channels or not, and when a secondary channel exists, whether it is above or below the primary channel in 38 frequency. The Extended Channel Switch Announcement action frame and the Extended Channel Switch An- 39 nouncement element can each be used to indicate a transition from 20/40 MHz BSS operation to 20 MHz BSS 40 operation and vice versa, and to indicate whether a secondary channel, when it exists, is above or below the 41 primary channel in frequency. 42 43 44 An FC HT STA shall maintain a local boolean variable 40MHzRegulatoryClass as described here. The initial 45 value of 40MHzRegulatoryClass shall be FALSE. The value of 40MHzRegulatoryClass is recomputed ac- 46 cording to the rules in this subclause at every TBTT and following the reception of a frame transmitted by the 47 AP associated with the STA when that frame contains either of the following fields: 48 49 — Current Regulatory Class field 50 — New Regulatory Class field 51 52 53 The local boolean variable 40MHzRegulatoryClass becomes TRUE upon reception of a frame transmitted by 54 the associated AP if the frame contained a Current Regulatory Class field with a value that corresponds to a 55 regulatory class that corresponds to a Channel Spacing value of 40 MHz, as specified in Annex J. 56 57 58 The local boolean variable 40MHzRegulatoryClass becomes FALSE upon reception of a frame transmitted 59 by the associated AP if the frame contained a Current Regulatory Class field with a value that corresponds to 60 a regulatory class that does not correspond to a Channel Spacing value of 40 MHz. 61 62 The local boolean variable 40MHzRegulatoryClass becomes TRUE at the nth TBTT following reception of 63 64 a frame transmitted by the associated AP that contains an Extended Channel Switch Announcement element 65 with a value of n in the Channel Switch Count field and a value in the New Regulatory Class field that cor-

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 responds to a regulatory class that corresponds to a Channel Spacing value of 40 MHz provided that the frame 2 is the most recently received frame meeting the above conditions. 3 4 5 The local boolean variable 40MHzRegulatoryClass becomes FALSE at the nth TBTT following reception of 6 a frame transmitted by the associated AP that contains an Extended Channel Switch Announcement element 7 with a value of n in the Channel Switch Count field and a value in the New Regulatory Class field that cor- 8 responds to a regulatory class that does not correspond to a Channel Spacing value of 40 MHz provided that 9 the frame is the most recently received frame meeting the above conditions. 10 11 12 A STA can choose to dynamically constrain its operating channel width to 20 MHz while being a member of 13 a 20/40 MHz BSS. Transitions to and from this constrained state are indicated using the transmission of a 14 frame that carries the Channel Width field. A transmitted value of zero in the Channel Width field indicates 15 16 that the transmitting STA is not currently able to receive 40 MHz PPDUs, beginning at the end of the trans- 17 mission of the frame that contained the Channel Width field. 18 19 A STA shall not transmit a frame containing a STA Channel Width field or a Channel Width field set to the 20 value 1 if the value of its most recently transmitted Supported Channel Width Set field is 0. 21 22 23 A STA that is associated with an infrastructure BSS (STA1) shall not transmit a 40 MHz PPDU containing 24 one or more frames addressed to a STA (STA2) unless the following three conditions are true: 25 26 — The Supported Channel Width Set field of the HT Capabilities element of both STAs is set to 1 27 — The Secondary Channel Offset field of the most recently received HT Operation element sent by the 28 AP of the BSS has a value of SCA or SCB 29 30 — The local boolean variable 40MHzRegulatoryClass is TRUE. 31 32 If the above three conditions are met, STA1 should not transmit a 40 MHz PPDU containing one or more 33 34 frames addressed to STA2 unless the following two conditions are true: 35 — Either STA1 has not received a Notify Channel Width action frame that was transmitted by STA2, or 36 the Channel Width field of the most recently received Notify Channel Width action frame at STA1 37 38 that was transmitted by STA2 is non-zero 39 — If STA2 is an AP, the STA Channel Width field of the most recently received HT Operation element 40 that was transmitted by STA2 is set to 1. 41 42 43 11.14.4.3 AP restrictions 44 45 An AP shall not transmit a 40 MHz PPDU containing one or more frames addressed to another STA unless 46 the following three conditions are true: 47 48 — The Supported Channel Width Set field of the HT Capabilities element of the AP and the STA are set 49 to a non-zero value 50 51 — The Secondary Channel Offset field of the AP's most recently transmitted HT Operation element 52 sent has a value of SCA or SCB 53 54 — The local boolean variable 40MHzRegulatoryClass is TRUE. 55 56 If the above three conditions are met, the AP should not transmit a 40 MHz PPDU containing frames ad- 57 dressed to another STA unless either the AP has not received a Notify Channel Width action frame that was 58 transmitted by the STA or the Channel Width field of the most recently received Notify Channel Width action 59 60 frame at the AP that was transmitted by the STA is non-zero. 61 62 An AP shall not transmit a 40 MHz PPDU containing one or more frames with a group address in the Address 63 1 field unless the following three conditions are true: 64 65 — The Supported Channel Width Set field of the HT Capabilities element of the AP is set to 1

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 — The Secondary Channel Offset field of the AP's most recently transmitted HT Operation element 2 sent has a value of SCA or SCB 3 4 — The local boolean variable 40MHzRegulatoryClass is TRUE. 5 6 If the above three conditions are met, the AP should not transmit a 40 MHz PPDU containing one or more 7 frames with a group address in the Address 1 field if the most recently received Notify Channel Width action 8 9 frame for any of the STA associated with the AP has the Channel Width field set to 0. 10 11 11.14.4.4 Restrictions on non-AP STAs that are not a member of an infrastructure BSS 12 13 An HT STA 2G4 that is not a member of an infrastructure BSS shall not transmit a 40 MHz mask PPDU. 14 15 16 An HT STA 5G that is not associated with an infrastructure BSS (STA1) shall not transmit a 40 MHz PPDU 17 containing frames addressed to a STA (STA2) unless the following three conditions are true: 18 — The Supported Channel Width Set field of the HT Capabilities element of both STAs is set to 1 19 20 — The Secondary Channel Offset field of the most recently received HT Operation element sent by 21 STA2 has a value of SCA or SCB 22 23 — The Secondary Channel Offset field of the most recently transmitted HT Operation element sent by 24 STA1 has a value of SCA or SCB 25 26 If the above three conditions are met, STA1 should not transmit a 40 MHz PPDU containing one or more 27 frames addressed to a STA2 unless the STA1 has not received a STA Channel Width field that was transmit- 28 29 ted by STA2, or the value of the most recently received STA Channel Width field at STA1 that was transmit- 30 ted by STA2 is non-zero. 31 32 An HT STA 5G that is not associated with an infrastructure BSS (STA1) shall not transmit a 40 MHz PPDU 33 containing one or more frames with a group address in the Address 1 field unless the following two conditions 34 35 are true: 36 — The Supported Channel Width Set field of the HT Capabilities element most recently transmitted by 37 the transmitting STA is set to 1. 38 39 — The Secondary Channel Offset field of the most recently transmitted HT Operation element sent by 40 STA1 has a value of SCA or SCB. 41 42 If the above two conditions are met, STA1 should not transmit a 40 MHz PPDU containing one or more 43 44 frames with a group address in the Address 1 field unless the most recently received STA Channel Width field 45 for each other known member of the BSS of which STA1 is a member is set to 1. 46 47 11.14.5 Scanning requirements for 40 MHz capable STA 48 49 50 An overlapping BSS scan operation is a passive or active scan of a set of channels that are potentially affected 51 by 20/40 MHz BSS operation. Each channel in the set may be scanned more than once during a single over- 52 lapping BSS scan operation. Overlapping BSS scans are performed by FC HT STA 2G4. FC HT STA 5G are 53 not required to perform overlapping BSS scan operations. 54 NOTE—STAs that perform overlapping BSS scans report discovered BSSs and received 20/40 BSS Coexistence infor- 55 mation to their associated AP (see 11.14.12). 56 57 58 During an individual scan within an overlapping BSS scan operation, the mininum per-channel scan duration 59 is dot11OBSSScanPassiveDwell TU (when scanning passively) or dot11OBSSScanActiveDwell TU (when 60 scanning actively). During an overlapping BSS scan operation, each channel in the set is scanned at least once 61 per dot11BSSWidthTriggerScanInterval seconds and the minimum total scan time (i.e., the sum of the scan 62 durations) per channel within a single overlapping BSS scan operation is 63 64 dot11OBSSScanPassiveTotalPerChannel TU for a passive scan and dot11OBSSScanActiveTotalPerChannel 65 TU for an active scan.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 NOTE—The values provided in the previous paragraph indicate the minimum requirements. For some combinations of 2 parameter values, it is necessary to exceed the minimum values of some parameters in order to meet the minimum value 3 constraints of all parameters. 4 5 When an AP transmits an Overlapping BSS Scan Parameters element, the value of each of the fields of the 6 7 element shall be set to the value of the MIB variable from the transmitting AP's MIB according to the mapping 8 between the frame fields and MIB variables as defined in 7.3.2.59. 9 10 Upon receipt of a frame containing an Overlapping BSS Scan Parameters element from the AP with which 11 an FC HT STA 2G4 is associated, the MLME of the receiving FC HT STA 2G4 shall update each of the val- 12 13 ues of the MIB variables used during overlapping BSS scanning operations according to the mapping between 14 the frame fields and MIB variables as defined in 7.3.2.59. 15 16 An FC HT AP 2G4 may transmit frames containing an Overlapping BSS Scan Parameters element to any or 17 all associated STAs in order to provide overlapping BSS scan parameter values that are different from the 18 19 default values. 20 21 An FC HT STA 2G4 that is associated with an FC HT AP 2G4 shall perform at least one OBSS scan every 22 dot11BSSWidthTriggerScanInterval seconds, unless the FC HT STA 2G4 satisfies the conditions described 23 24 in 11.14.6. 25 26 11.14.6 Exemption from OBSS Scanning 27 28 An FC HT STA 2G4 shall maintain a local variable ActivityFraction. The value of ActivityFraction is defined 29 30 by Equation (11-5). 31 32 T 33 ActivityFraction = ------ACTIVE - (11-5) 34 TMEASURE-ACTIVE 35 36 where 37 38 T is the total duration of transmitted MSDUs and received individually addressed MSDUs during 39 ACTIVE 40 the previous TMEASURE-ACTIVE seconds 41 42 T is dot11BSSWidthChannelTransitionDelayFactor * 43 MEASURE-ACTIVE 44 dot11BSSWidthTriggerScanInterval seconds. 45 46 An FC HT STA 2G4 may transmit a 20/40 BSS Coexistence Management Action frame with the Scanning 47 Exemption Request field in 20/40 Coexistence element set to 1 to its associated AP. 48 49 50 If the last 20/40 BSS Coexistence Management Action frame received by an FC HT STA 2G4 in an individ- 51 ually addressed frame from its associated AP has the Scanning Exemption Grant field set to 1, the STA is 52 exempted from scanning whenever the value of its local variable ActivityFraction is less than 53 54 dot11OBSSScanActivityThreshold/10000. 55 56 An FC HT AP 2G4 shall not transmit a 20/40 BSS Coexistence Management Action frame with the Scanning 57 Exemption Grant field set to 1 addressed to an FC HT STA if the following condition is true: 58 59 — The FC HT STA has transmitted one or more channel report elements and is the only STA in the 60 BSS that has indicated one or more channels on which a STA has found conditions that disallow the 61 use of a 20/40 MHz BSS. 62 63 64 If there is more than one FC HT STA in the BSS that has indicated conditions that disallow the use of 20/40 65 MHz BSS on a specific channel then:

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 — If all the FC HT STAs that have indicated unavailability of a channel have also requested to be 2 exempt from scanning, the AP shall disallow at least one of the FC HT STA to be exempt from 3 scanning. 4 5 — If there is at least one FC HT STA from the group of FC HT STAs that have indicated unavailability 6 of a channel and that has not requested to be exempt from scanning, the AP may allow all the STAs 7 that have requested to be exempt from scanning to be exempted from scanning. 8 9 10 11.14.7 Communicating 20/40 BSS Coexistence information 11 12 In addition to the 20/40 BSS Coexistence Management frame, a STA can include the 20/40 BSS Coexistence 13 element in transmitted Beacon, Probe Request, Probe Response, (Re)Association Request and (Re)Associa- 14 15 tion Response frames. 16 17 11.14.8 Support of DSSS/CCK in 40 MHz 18 19 Transmission and reception of PPDUs using DSSS/CCK by FC HT STAs is managed using the DSSS/CCK 20 21 Mode in 40 MHz subfield of the HT Capabilities Info field (see 7.3.2.56.2). 22 23 An HT STA declares its capability to use DSSS/CCK rates while it has a 40 MHz operating channel width 24 through the DSSS/CCK Mode in 40 MHz subfield of its Association and Reassociation Request frames. 25 26 27 If the DSSS/CCK Mode in 40 MHz subfield is set to 1 in Beacon and Probe Response frames, an associated 28 HT STA in a 20/40 MHz BSS may generate DSSS/CCK transmissions. If the subfield is set to 0: 29 — associated HT STAs shall not generate DSSS/CCK transmissions; 30 31 — the AP shall not include an ERP Information element in its Beacon and Probe Response frames; 32 33 — the AP shall not include DSSS/CCK rates in the Supported Rates information element; 34 — the AP shall refuse association requests from a STA that includes only DSSS/CCK rates in its Sup- 35 ported Rates and Extended Supported Rates information elements. 36 37 38 11.14.9 STA CCA sensing in a 20/40 MHz BSS 39 40 A STA may transmit a 20 MHz mask PPDU in the primary channel following the rules in 9.9.1. 41 42 43 A STA transmitting a 40 MHz mask PPDU that 44 — begins a TXOP using EDCA as described in 9.9.1.3, or 45 46 — is using a PIFS as permitted in 9.2.3.2, 47 shall sense CCA on both the 20 MHz primary channel and the 20 MHz secondary channel before the 40 MHz 48 mask PPDU transmission starts. 49 50 51 Unless explicitly stated otherwise, a STA may treat a PHY-CCA.indication that is BUSY as though it were 52 IDLE in the following cases: 53 54 — If the channel-list parameter is present and equal to {secondary} and the STA is transmitting a 20 55 MHz mask PPDU on the primary channel, or 56 — If the channel-list parameter is present and equal to {primary} and the STA is transmitting a 20 MHz 57 mask PPDU on the secondary channel. 58 59 NOTE—Transmission of PPDUs on the secondary channel is also subject to constraints in 11.14.2. 60 61 At the specific slot boundaries (defined in 9.2.10) determined by the STA based on the 20 MHz primary chan- 62 nel CCA, when the transmission begins a TXOP using EDCA (as described in 9.9.1.3), the STA may transmit 63 64 a pending 40 MHz mask PPDU only if the secondary channel has also been idle during the times the primary 65 channel CCA is performed (defined in 9.2.10) during an interval of a PIFS for the 5 GHz band and DIFS for

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 the 2.4 GHz band immediately preceding the expiration of the backoff counter. If a STA was unable to trans- 2 mit a 40 MHz mask PPDU because the secondary channel was occupied during this interval, it may: 3 4 a) Transmit a 20 MHz mask PPDU on the primary channel. 5 b) Restart the channel access attempt. In this case, the STA shall invoke the backoff procedure as spec- 6 7 ified in 9.9.1 as though the medium is busy as indicated by either physical or virtual CS and the 8 backoff timer has a value of zero. 9 NOTE—This means that the STA selects a new random number using the current value of CW[AC] and that the 10 retry counters are not updated. 11 12 13 When a TXOP is obtained for a 40 MHz PPDU, the STA may transmit 40 MHz PPDUs and/or 20 MHz PP- 14 DUs during the TXOP. When the TXOP is obtained by the exchange of 20 MHz PPDUs only in the primary 15 channel, the station shall not transmit 40 MHz PPDUs during the TXOP. 16 17 18 11.14.10 NAV assertion in 20/40 MHz BSS 19 20 An HT STA shall update its NAV using the Duration/ID field value in any frame received in a 20 MHz PPDU 21 in the primary channel or received in a 40 MHz PPDU and that does not have an RA matching the STA MAC 22 address. 23 24 NOTE—A STA need not set its NAV in response to 20 MHz frames received on the secondary channel or any other 25 channel that is not the primary channel, even if it is capable of receiving those frames. 26 27 11.14.11 Signaling 40 MHz intolerance 28 29 An HT STA 2G4 shall set the Forty MHz Intolerant field to 1 in transmitted HT Capabilities elements if the 30 31 value of the MIB attribute dot11FortyMHzIntolerant is TRUE, otherwise the field shall be set to 0. 32 33 A STA 2G4 shall set the Forty MHz Intolerant field to 1 in transmitted 20/40 BSS Coexistence fields if the 34 value of the MIB attribute dot11FortyMHzIntolerant is TRUE, otherwise the field shall be set to 0. A STA 35 36 2G4 that is not an HT STA 2G4 shall include a 20/40 BSS Coexistence element in management frames in 37 which the element may be present if the STA has a MIB attribute dot11FortyMHzIntolerant and the value of 38 that MIB attribute is TRUE. 39 40 A STA 5G shall set the Forty MHz Intolerant field to 0 in transmitted HT Capabilities elements and 20/40 41 42 BSS Coexistence fields. 43 44 11.14.12 Switching between 40 MHz and 20 MHz 45 46 47 The following events are defined to be BSS channel width trigger events: 48 a) TE-A: on any of the channels of the channel set defined in Clause 19, reception of a Beacon frame 49 that does not contain an HT Capabilities element 50 51 b) TE-B: on any of the channels of the channel set defined in Clause 19, reception of a 20/40 BSS 52 Coexistence, Beacon, Probe Request, or Probe Response frame that contains a value of 1 in a Forty 53 MHz Intolerant field and that has the Address 1 field set to the receiving STA’s address or to a group 54 address value, with no further addressing qualifications 55 56 c) TE-C: reception of a 20/40 BSS Coexistence frame with the 20 MHz BSS Width Request field set 57 to 1 and with a value for the Address 1 field that matches the receiving STA using either individual 58 or group addressing and with a value for the TA field that corresponds to the MAC address of a STA 59 60 with which the receiver is associated 61 d) TE-D: reception of a 20/40 BSS Coexistence frame containing at least one 20/40 BSS Intolerant 62 Channel Report element with a non-zero length and with a value for the Address 1 field set to the 63 64 receiving STA’s address or to a group address value, but with no qualification of the Address 3 65 value.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 An FC HT AP 2G4 shall re-evaluate the value of the local variable 20/40 Operation Permitted (see 11.14.3.2) 2 when: 3 4 — a BSS channel width trigger event TE-A is detected, or 5 — a BSS channel width trigger event TE-D is detected. 6 7 8 An FC HT AP 2G4 may re-evaluate the value of the local variable 20/40 Operation Permitted (see 11.14.3.2) 9 when: 10 — no BSS channel width trigger events TE-A are detected for a period of time equal to 11 12 dot11BSSWidthChannelTransitionDelayFactor * dot11BSSWidthTriggerScanInterval seconds, or 13 — no BSS channel width trigger events TE-D are detected for a period of time with a duration of 14 dot11BSSWidthChannelTransitionDelayFactor * dot11BSSWidthTriggerScanInterval seconds. 15 16 17 An FC HT AP 2G4 that detects either of the BSS channel width trigger events TE-B or TE-C or that 18 determines that the value of its variable 20/40 Operation Permitted has changed from TRUE to FALSE shall 19 set the Secondary Channel Offset field to SCN in transmitted HT Operation elements beginning at the next 20 DTIM or next TBTT if no DTIMs are transmitted to indicate that no secondary channel is present (i.e., that 21 22 the BSS operating width is 20 MHz). 23 24 An FC HT AP 2G4 shall not set the Secondary Channel Offset field to a value of SCA or SCB in transmitted 25 HT Operation elements unless the following two conditions have been met: 26 27 — A period of dot11BSSWidthChannelTransitionDelayFactor * dot11BSSWidthTriggerScanInterval 28 seconds have elapsed during which no BSS channel width trigger events TE-B or TE-C are detected. 29 — The value of the local variable 20/40 Operation Permitted (see 11.14.3.2) is TRUE. 30 31 32 To request an update of the status of the 20 MHz BSS Width Request field, an FC HT AP 2G4 can transmit 33 a 20/40 BSS Coexistence Management frame with a value of 1 in the Information Request field as described 34 in 11.16. 35 36 37 An FC HT STA 2G4 that is associated with an FC HT AP 2G4 shall maintain a record of detected BSS chan- 38 nel width trigger events as follows: 39 — For each detected BSS channel width trigger event TE-A: 40 41 — If a DS Parameter Set field is present in the received Beacon frame, the channel of the BSS 42 channel width trigger event is the value of the Current Channel field of the DS Parameter Set 43 field, otherwise, the channel of the BSS channel width trigger event is the channel on which 44 the detecting STA received the Beacon frame. 45 46 — If a Supported Regulatory Classes element is present in the received Beacon frame, the regula- 47 tory class of the BSS channel width trigger event is the value of the Current Regulatory Class 48 field of the Supported Regulatory Classes element of the received Beacon frame, otherwise, 49 50 the regulatory class of the BSS channel width trigger event is “unknown”. 51 — For each detected BSS channel width trigger event TE-A of a unique combination of regulatory class 52 and channel, the FC HT STA 2G4 shall maintain a record containing two variables: 53 54 — the regulatory class of the BSS channel width trigger event, 55 — the channel of the BSS channel width trigger event. 56 57 NOTE—If a BSS channel width trigger event TE-A is detected for a regulatory class and channel combination for which 58 no record exists, the STA creates such a record. 59 60 If a BSS channel width trigger event TE-A is detected for a regulatory class and channel combination for 61 which a record already exists, the information in that record shall be updated with the information determined 62 from the new trigger event. 63 64 65 For all BSS channel width trigger events TE-B, the FC HT STA 2G4 shall maintain a single record containing

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 an indication of whether one or more trigger events TE-B have been detected. 2 3 At the completion of an overlapping scan operation (i.e., at the end of the period of time equal to 4 5 dot11BSSWidthTriggerScanInterval) or when it receives a 20/40 BSS Coexistence Management frame from 6 its associated AP that contains a value of 1 in the Information Request field, an FC HT STA 2G4 that is 7 associated with an FC HT AP 2G4 shall create a 20/40 BSS Coexistence Management frame by including a 8 value of zero for all fields of a 20/40 BSS Coexistence Management frame and then transferring information 9 from the BSS channel width trigger event TE-A and TE-B records to the frame according to the following 10 11 four steps: 12 — For each unique regulatory class that is stored in the set of BSS channel width trigger event TE-A 13 records, the STA shall create a 20/40 BSS Intolerant Channel Report element for inclusion in the 14 15 frame and include all of the unique channels associated with the regulatory class in the channel list of 16 that element. 17 — The STA sets the Forty MHz Intolerant field of the 20/40 BSS Coexistence element based on value 18 of the dot11FortyMHzIntolerant MIB attribute (see 11.14.11). 19 20 — The STA shall set to 1 the 20 MHz BSS Width Request field of the 20/40 BSS Coexistence element 21 for inclusion in the frame if a record for BSS channel width trigger event TE-B exists and indicates 22 that at least one trigger event TE-B has been detected. 23 24 — The STA may set to 1 the Information Request field. 25 26 Upon completion of these four steps, the FC HT STA 2G4 shall delete all records for trigger events TE-A and 27 TE-B. Subsequently detected trigger events cause the creation of new records as necessary to be used in 28 29 subsequently generated 20/40 BSS Coexistence Management action frames. Following the record deletion, 30 the FC HT STA 2G4 shall transmit to its associated FC HT AP 2G4 the 20/40 BSS Coexistence Management 31 action frame if any of the following five conditions is true: 32 33 — at least one 20/40 BSS Intolerant Channel Report element with the Length field set to a non-zero 34 value is included 35 — the Forty MHz Intolerant field is set to 1 36 37 — the 20 MHz BSS Width Request field is set to 1 38 — the Information Request field is set to 1 39 40 — the frame was created in response to the reception of an Information Request field that was set to 1 41 42 43 11.15 Phased Coexistence Operation (PCO) 44 45 11.15.1 General description of PCO 46 47 48 PCO is an optional coexistence mechanism in which a PCO active AP divides time into alternating 20 MHz 49 and 40 MHz phases (see Figure 11-17a). The PCO active AP reserves the 20 MHz primary channel and the 50 20 MHz secondary channel in turn to start the 40 MHz phase and resets the NAV in the 20 MHz channels in 51 the opposite order to start the 20 MHz phase. Due to the protection of the 40 MHz period in both channels, it 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 is tolerant of overlapping BSSs on both 20 MHz halves of a 40 MHz channel. 2 3 Beacon 4 Set PCO or CTS-to-self CF-End CF-End 5 Phase 6 Set PCO Phase 7 20 MHz phase 8 ch_a 40 MHz 9 (primary) phase 10 11 ch_b 12 (secondary) 13 14 NAV 15 20 MHz STA 16 in ch_a 17 18 20 MHz STA NAV 19 in ch_b 20 NAV NAV 21 PCO active STA 22 23 Figure 11-17a—Phased Coexistence Operation 24 25 A PCO active STA that does not know the current PCO phase shall transmit using a 20 MHz PPDU. 26 27 28 During the 40 MHz phase, a PCO active STA shall transmit data frames using a 40 MHz HT PPDU and con- 29 trol frames using a non-HT duplicate or a 40 MHz HT PPDU, with the following exceptions: 30 31 — Any CF-End frame shall be sent using only a 40 MHz HT PPDU. 32 — A PCO active AP may transmit 20 MHz group addressed frames as defined in 9.6.0d.3. 33 34 35 A PCO active STA shall transmit management frames in 20 MHz or 40 MHz PPDUs according to 9.6.0d dur- 36 ing the 40 MHz phase, except that Set PCO Phase frames shall be sent following the rules specified in 11.15.2. 37 38 During the 40 MHz phase, a PCO active STA can act as though the HT Protection field were set to no pro- 39 40 tection mode, as defined in 9.13.3.1. 41 42 During the 20 MHz phase, a PCO active STA shall not transmit frames using a 40 MHz (HT or non-HT du- 43 plicate) PPDU. The protection of a PCO active STA during the 20 MHz phase is the same as protection in a 44 45 20 MHz BSS. 46 47 During the 20 MHz phase, a STA may transmit a 40 MHz mask PPDU that is not also a 40 MHz PPDU. 48 NOTE—This allows a STA to transmit 20 MHz PPDUs without requiring it to change to a 20 MHz transmit mask. 49 50 51 A PCO capable AP may set the PCO Active field to 1 only if it is in a 20/40 MHz BSS. 52 NOTE—A non-PCO capable 20/40 STA regards the PCO active BSS as a PCO inactive BSS. A non-PCO capable 20/40 53 STA that associates with a PCO active BSS protects its transmissions as though the BSS were a PCO inactive BSS. 54 55 The value indicated by the PCO Transition Time field in the HT Extended Capabilities field is measured from 56 the end of the PPDU carrying the Set PCO Phase frame. The PCO active STA shall be able to receive a PPDU 57 using the new channel width no later than the value specified by the PCO Transition Time field after the end 58 59 of the PPDU carrying the Set PCO Phase frame. 60 61 11.15.2 Operation at a PCO active AP 62 63 64 A PCO capable AP activates PCO if it decides that PCO active BSS is more appropriate than either PCO in- 65 active BSS or 20 MHz BSS in the current circumstances. The algorithm for making this decision is beyond

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 the scope of this standard.1 2 3 4 A PCO active AP shall set the PCO Active field in the HT Operation element to 1. 5 6 7 When a PCO active AP detects that PCO is not providing a performance benefit, the PCO active AP may de- 8 activate PCO and operate in either PCO inactive BSS or 20 MHz BSS. A PCO capable AP shall set the PCO 9 Active field in the HT Operation element to 0 when PCO operation is disabled. Since the AP advertises the 10 current mode in its Beacon and Probe Response frames, its associated STAs are informed of the mode change. 11 12 13 Values of the PCO Transition Time field in the HT Extended Capabilities field from 1 to 3 indicate the max- 14 imum time the PCO active STA takes to switch between a 20 MHz channel width and a 40 MHz channel 15 width. A PCO active AP may set the PCO Transition Time field to 0 when it requires the associated PCO 16 active STAs to be able to receive 40 MHz frames and respond with 40 MHz frames during the 20 MHz phase. 17 18 19 The PCO active AP shall increase the value of the PCO Transition Time field if the PCO active AP accepts 20 the association of a PCO capable STA whose value of the PCO Transition Time field exceeds the one cur- 21 rently used by the PCO active AP. If the PCO active AP decides not to extend its transition time to meet the 22 23 value of the requesting STA, the PCO active AP shall deny the association. The AP may choose to continue 24 PCO when a non-PCO capable 20/40 STA requests association, and in such case, the PCO active AP shall be 25 able to receive 40 MHz frames and respond using 40 MHz frames during the 20 MHz phase. 26 27 28 A PCO active AP that indicates a switch to the 40 MHz phase by a PCO Phase field in a Beacon or by a PCO 29 Phase Control field in a Set PCO Phase frame and that transmits a non-zero value of the PCO Transition Time 30 field shall wait for at least the transition time specified by the PCO Transition Time field before sending a 31 CF-End frame in the 40 MHz channel to start the 40 MHz operating phase. 32 33 34 When switching to the 40 MHz phase, a PCO active AP indicates a NAV duration either in the CF Parameter 35 Set element of a Beacon frame, or in the Duration/ID field of a Set PCO Phase frame sent on the primary 36 channel that shall protect up to the end of the intended 40 MHz phase, plus a transition time. A PCO active 37 AP may continue the CFP after the 40 MHz phase by setting a longer duration for the CFP. The value of the 38 39 Duration/ID field in a CTS-to-self frame sent to protect a 40 MHz phase shall be set to protect up to the in- 40 tended end of the 40 MHz phase, plus a transition time. The CTS-to-self shall be sent in a non-HT duplicate 41 PPDU. The transmission of the CTS-to-self shall be delayed until the secondary channel CCA has indicated 42 idle for at least a PIFS interval. It need not sense the primary channel since it is already reserved by a Beacon 43 frame or a Set PCO Phase Action frame. 44 45 46 If the PCO Transition Time field is non-zero, a PCO active AP shall start a timer with a time-out value equal 47 to the time specified by the PCO Transition Time field after transmitting a Beacon or a Set PCO Phase Action 48 frame. If this timer expires while attempting to reserve the secondary channel, the AP shall transmit a Set PCO 49 50 Phase Action frame indicating switch back to the 20 MHz phase and shall transmit a CF-End frame on the 51 primary channel. 52 NOTE—If this timer expires while attempting to reserve the secondary channel, the AP abandons switching to the 40 53 MHz phase to avoid an unexpectedly long delay. 54 55 56 A PCO active AP may transmit a Set PCO Phase frame in a non-HT duplicate PPDU followed by a CF-End 57 frame in a 40 MHz HT PPDU to reserve both the primary channel and the secondary channel again for the 40 58 MHz phase or to extend the 40 MHz phase. The value of the Duration/ID field in a Set PCO Phase frame 59 contained in a non-HT duplicate PPDU for this intent shall protect up to the end of the intended 40 MHz 60 phase, plus the transition time. 61 62 63 1. A PCO capable AP can consider the performance impact, for example throughput and jitter, caused by and given to STAs based on 64 their capabilities, traffic types or load to determine the BSS's PCO mode. STAs under consideration may not be only associated STAs 65 but those that were detected in overlapping BSSs.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 To start the 20 MHz phase, a PCO active AP shall send a Set PCO Phase frame in a 40 MHz HT PPDU or in 2 a non-HT duplicate PPDU with the Duration/ID field set to cover the transition time. It may also send a CF- 3 End frame in both primary and secondary channels following the Set PCO Phase frame, where a CF-End 4 5 frame in the primary channel shall be sent out at least after the transition time. The Duration/ID field of the 6 Set PCO Phase frame for this case shall cover the transition time plus the duration of a CF-End frame. 7 8 A PCO active AP may broadcast a Set PCO Phase frame to advertise the current PCO phase to PCO active 9 STAs. 10 11 12 Although PCO improves throughput in some circumstances, PCO might also introduce jitter. To minimize 13 the jitter, the maximum duration of 40 MHz phase and 20 MHz phase is dot11PCOFortyMaxDuration and 14 dot11PCOTwentyMaxDuration, respectively. Also in order for the PCO active AP to give opportunities for 15 each STA to send frames, the minimum duration of 40 MHz phase and 20 MHz phase is 16 17 dot11PCOFortyMinDuration and dot11PCOTwentyMinDuration, respectively. 18 19 11.15.3 Operation at a PCO active non-AP STA 20 21 22 If the PCO field in the Association Request to a PCO active AP is set to 1 and the association succeeds, the 23 STA shall operate in PCO mode. When requesting association, a PCO capable STA shall set the PCO Tran- 24 sition Time field to 0 if the PCO active AP has set the PCO Transition Time field to 0. A PCO capable STA 25 may attempt to associate with a transition time that is larger than one currently advertised by the PCO active 26 AP. If such an association fails, the PCO capable non-AP STA may regard the BSS as a PCO inactive BSS 27 28 and may attempt an association as a non-PCO capable 20/40 STA. 29 NOTE—A STA that does not support the PCO Transition Time indicated by an AP can still attempt association with that 30 AP. The AP will either refuse the association based on PCO Transition Time, or respond by adjusting its PCO Transi- 31 tion Time to suit the STA. 32 33 A PCO active non-AP STA may transmit a Probe Request frame to the associated PCO active AP to deter- 34 mine the current PCO phase. A PCO active STA associated with a PCO active AP shall switch its operating 35 phase from 20 MHz channel width to 40 MHz channel width when it receives a Beacon frame or a Probe Re- 36 37 sponse frame that contains the PCO Phase field set to 1 or a Set PCO Phase frame with the PCO Phase field 38 set to 1 from its AP. The CFP DurRemaining field in the CF Parameter Set element of a Beacon frame or the 39 value of the Duration/ID field of a Set PCO Phase frame shall be interpreted as the duration of the PCO 40 40 MHz phase. 41 42 43 A PCO active STA associated with a PCO active AP shall switch its operating phase from 40 MHz channel 44 width to 20 MHz channel width when it receives a Beacon frame or a Probe Response frame that contains the 45 PCO Phase field set to 0 or a Set PCO Phase frame with the PCO Phase field set to 0. It also may switch from 46 40 MHz channel width to 20 MHz channel width based on the expiry of the value in the Duration/ID field of 47 a Set PCO Phase frame that indicated a 40 MHz phase, or based on the expiry of the value in the CFP Dur- 48 49 Remaining field of the CF Parameter Set element of a Beacon frame that indicated a 40 MHz phase. 50 51 A PCO active STA shall halt PCO operation if it receives an HT Operation element from its AP with the PCO 52 Active field set to 0. 53 NOTE—An HT STA can change its PCO capabilities by disassociating and associating or reassociating with an AP. 54 55 56 11.16 20/40 BSS Coexistence Management frame usage 57 58 59 A STA that supports the 20/40 BSS Coexistence Management frame type shall set the 20/40 BSS Coexistence 60 Management Support field to 1 in transmitted Extended Capabilities information elements. 61 62 A STA that supports the 20/40 BSS Coexistence Management frame type shall include an Extended Capabil- 63 64 ities information element in transmitted Beacon frames, Association Request frames, Association Response 65 frames, Reassociation Request frames, Reassociation Response frames, Probe Request frames, and Probe Re-

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 sponse frames. 2 3 4 A STA shall not transmit to another STA a 20/40 BSS Coexistence Management frame with an individual 5 address in the Address 1 field if the most recently received Extended Capabilities element from the recipient 6 STA contained a value of 0 in the the 20/40 BSS Coexistence Management Support field. A STA that trans- 7 mits a 20/40 BSS Coexistence Management frame may set the Address 1 field to a group address. 8 NOTE—A 20/40 BSS Coexistence Management frame is a class 1 frame and therefore, can be sent to a STA that sup- 9 ports reception of such frames and that is not a member of the same BSS as the transmitting STA, in which case, the 10 BSSID of the frame is set to the wildcard BSSID value, regardless of whether the Address 1 field contains a unicast or 11 group address value. 12 13 14 A STA may transmit a 20/40 BSS Coexistence Management frame that contains a value of 1 for the Request 15 Information field to another STA that supports the transmission of and reception of the 20/40 BSS Coexist- 16 ence Management frame, except when the frame is a response to a 20/40 BSS Coexistence Management 17 frame that contains a value of 1 for the Request Information field. 18 19 20 A STA that receives a 20/40 BSS Coexistence element with the Information Request field set to 1, a value 21 for the Address 1 field that matches the receiving STA using an individual address, and a non-wildcard 22 BSSID field that matches the STA's BSS shall immediately queue for transmission a 20/40 BSS Coexistence 23 Management frame with the transmitting STA as the recipient. 24 25 26 27 11.17 RSNA A-MSDU procedures 28 29 When dot11RSNAEnabled is TRUE, a STA indicates support for payload protected (PP) A-MSDU or sig- 30 naling and payload protected (SPP) A-MSDU during association or reassociation. On either association or 31 reassociation, the associating STA and its peer STA both determine and maintain a record of whether an en- 32 33 crypted A-MSDU sent to its peer is to be a PP A-MSDU or an SPP A-MSDU based on the value of the SPP 34 A-MSDU Capable and SPP A-MSDU Required subfields of the RSN Capabilities field of the RSN informa- 35 tion element (see 7.3.2.25.3). 36 37 38 Table 11-8a defines behavior related to the transmission and reception of individually addressed A-MSDUs 39 of a first HT STA (STA1) that has successfully negotiated an RSNA (re)association with a second HT STA 40 (STA2). Reception and transmission of A-MSDUs using a non-RSN association is unaffected by the values 41 of the SPP A-MSDU Capable and SPP A-MSDU Required fields. 42 NOTE—This subclause does not describe the operation of group addressed A-MSDUs because the use of group 43 addressed A-MSDUs is not permitted, as defined in 9.7c. 44 45 46 11.18 Public Action frame addressing 47 48 49 A STA that is a member of a BSS that transmits a Management frame of Subtype Action, Category Public 50 with a unicast value in the Address 1 field corresponding to a STA that is not a member of the same BSS as 51 the transmitting STA shall set the BSSID field of the frame to the wildcard BSSID value. 52 53 54 A STA that is a member of a BSS that transmits a Management frame of Subtype Action, Category Public to 55 a group address, shall set the BSSID field of the frame to the wildcard BSSID value or to the transmitting 56 STA's BSSID value. 57 58 59 A STA that is a member of a BSS that transmits a Management frame of Subtype Action, Category Public 60 with a unicast value in the Address 1 field corresponding to a STA that is a member of the same BSS as the 61 transmitting STA shall set the BSSID field of the frame to the transmitting STA's BSSID value. 62 63 64 A STA that is not a member of a BSS that transmits a Management frame of Subtype Action, Category Public 65 shall set the BSSID field of the frame to the wildcard BSSID value.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table 11-8a—A-MSDU STA Behavior for RSN associations 2 3 4 STA1 State STA2 State 5 6 SPP SPP SPP SPP STA1 Action with respect to STA2. 7 A-MSDU A-MSDU A-MSDU A-MSDU 8 Capable Required Capable Required 9 10 0 0 X 0 May transmit PP A-MSDU 11 Shall not transmit SPP A-MSDU 12 Shall receive PP A-MSDU 13 Received SPP A-MSDU MIC will fail 14 15 0 0 X 1 Shall not transmit PP A-MSDU 16 Shall not transmit SPP A-MSDU 17 Shall discard received (PP and SPP) A-MSDU 18 19 0 1 X X Shall not transmit PP A-MSDU 20 Shall not transmit SPP A-MSDU 21 Shall discard received (PP and SPP) A-MSDU 22 23 1 0 0 0 May transmit PP A-MSDU 24 Shall not transmit SPP A-MSDU 25 Shall receive PP A-MSDU 26 Received SPP A-MSDU MIC will fail 27 1 0 0 1 Shall not transmit PP A-MSDU 28 Shall not transmit SPP A-MSDU 29 Shall discard received (PP and SPP) A-MSDU 30 31 1 X 1 X Shall not transmit PP A-MSDU 32 May transmit SPP A-MSDU 33 Received PP A-MSDU MIC will fail 34 Shall receive SPP A-MSDU 35 36 1 1 0 X Shall not transmit PP A-MSDU 37 Shall not transmit SPP A-MSDU 38 Shall discard received (PP and SPP) A-MSDU 39 40 NOTE: 41 X = Don’t Care 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 12. PHY service specification 2 3 4 5 12.3 Detailed PHY service specifications 6 7 8 12.3.4 Basic service and options 9 10 12.3.4.2 PHY-SAP sublayer-to-sublayer service primitives 11 12 13 Insert the following entries into Table 12-2: 14 15 16 17 Table 12-2— PHY-SAP sublayer-to-sublayer service primitives 18 19 Primitive Request Indicate Confirm 20 21 22 PHY-CONFIG X X 23 24 25 26 12.3.4.3 PHY-SAP service primitives parameters 27 28 29 Change the row for the STATUS parameter in Table 12-3 as follows: 30 31 32 Table 12-3—PHY-SAP service primitive parameters 33 34 35 Parameter Associated primitive Value 36 37 STATUS PHY-CCA.indication (BUSY,[channel-list]), 38 39 (IDLE) 40 41 42 43 Insert the following row into Table 12-3: 44 45 46 Table 12-3—PHY-SAP service primitive parameters 47 48 49 Parameter Associated primitive Value 50 51 PHYCONFIG_VECTOR PHY-CONFIG A set of parameters 52 53 54 55 56 12.3.4.4 Vector descriptions 57 58 Insert the following new paragraph at the end of 12.3.4.4: 59 60 61 The Clause 20 PHY TXVECTOR and RXVECTOR contain additional parameters related to the operation of 62 the Clause 20 PHY modes of operation as described in 20.2. In certain modes of operation, the DATARATE 63 64 parameter is replaced by a modulation and coding scheme (MCS) value. The mapping from Clause 20 MCS 65 to data rate is defined in 20.6.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Insert the following rows into Table 12-4 : 2 3 4 Table 12-4—Vector descriptions 5 6 7 Parameter Associated vector Value 8 9 ACTIVE_RXCHAIN_SET PHYCONFIG_VECTOR The ACTIVE_RXCHAIN_SET parameter indicates 10 which receive chains of the available receive chains 11 are active. The length of the field is 8 bits. A 1 in bit 12 position n indicates that the receive chain numbered 13 n is used. At most 4 bits out of 8 may be set to 1. 14 15 OPERATING_CHANNEL PHYCONFIG_VECTOR The operating channel the PHY is set to use. 16 17 CHANNEL_OFFSET PHYCONFIG_VECTOR Enumerated type: 18 19 CH_OFFSET_NONE—indicates operation in 20 20 MHz HT STAs 21 22 CH_OFFSET_ABOVE—indicates operation in 40 23 MHz with the secondary channel above the primary 24 25 CH_OFFSET_BELOW—indicates operation in 40 26 MHz with the secondary channel below the primary 27 28 29 30 12.3.5 PHY-SAP detailed service specification 31 32 33 12.3.5.4 PHY-TXSTART.request 34 35 12.3.5.4.1 Function 36 37 38 Change 12.3.5.4.1 as follows: 39 40 This primitive is a request by the MAC sublayer to the local PHY entity to start the transmission of an MPDU 41 42 PSDU. 43 44 12.3.5.4.2 Semantics of the service primitive 45 46 47 Change 12.3.5.4.2 as follows: 48 49 The primitive provides the following parameters: 50 51 PHY-TXSTART.request(TXVECTOR) 52 53 The TXVECTOR represents a list of parameters that the MAC sublayer provides to the local PHY entity in 54 order to transmit an MPDU PSDU. This vector contains both PLCP and PHY management parameters. The 55 56 required PHY parameters are listed in 12.3.4.4. 57 58 12.3.5.4.3 When generated 59 60 61 Change 12.3.5.4.3 as follows: 62 63 This primitive will be issued by the MAC sublayer to the PHY entity when the MAC sublayer needs to begin 64 65 the transmission of an MPDU PSDU.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 12.3.5.6 PHY-TXEND.request 2 3 12.3.5.6.1 Function 4 5 6 Change 12.3.5.6.1 as follows: 7 8 This primitive is a request by the MAC sublayer to the local PHY entity that the current transmission of the 9 MPDU PSDU be completed. 10 11 12 12.3.5.6.2 When generated 13 14 Change 12.3.5.6.3 as follows: 15 16 17 This primitive will be generated when the MAC sublayer has received the last PHY-DATA.confirm from the 18 local PHY entity for the MPDUPSDU currently being transferred. 19 20 12.3.5.7 PHY-TXEND.confirm 21 22 23 12.3.5.7.3 When generated 24 25 Change 12.3.5.7.3 as follows: 26 27 28 This primitive will be issued by the PHY to the MAC entity when the PHY has received a PHYTXEND.re- 29 quest immediately after transmitting the end of the last bit of the last data octet indicating that the symbol 30 containing the last data octet has been transferred, and any Signal Extension has expired. 31 32 12.3.5.10 PHY-CCA.indication 33 34 35 12.3.5.10.2 Semantics of the service primitive 36 37 Change 12.3.5.10.2 as follows: 38 39 40 The primitive provides the following parameters: 41 PHY-CCA.indication (STATE, channel-list) 42 43 The STATE parameter can be one of two values: BUSY or IDLE. The parameter value is BUSY if the chan- 44 nel(s) assessment by the PHY determines that the channel is not available. Otherwise, the value of the param- 45 46 eter is IDLE. 47 48 When STATE is IDLE or when, for the type of PHY in operation, CCA is determined by a single channel and 49 the channel-list parameter is absent. Otherwise, it carries a set indicating which channels are busy, represented 50 by the values {primary}, {primary, secondary}, and {secondary}. 51 52 53 12.3.5.10.3 When generated 54 55 Change 12.3.5.10.3 as follows 56 57 58 This primitive is generated within aCCATime of the occurrence of a change in the status of the channel(s) 59 changes from channel idle to channel busy or from channel busy to channel idle. This includes the period of 60 time when the PHY is receiving data. If the STA is not an HT STA the PHY maintains the channel busy in- 61 dication until the period indicated by the LENGTH field in a valid PLCP header has expired. 62 63 64 If the STA is an HT STA and the operating channel width is 20 MHz the PHY maintains the channel busy 65 indication until the period indicated by the LENGTH field has expired, where the LENGTH field is:

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 — in a valid SIG field if the format of the PPDU is NON_HT, or 2 3 — in a valid HT-SIG field if the format of the PPDU is HT_MF or HT_GF. 4 5 If the STA is an HT STA and the operating channel width is 40 MHz the PHY maintains the channel busy 6 7 indication until the period indicated by the LENGTH field has expired, where the LENGTH field is: 8 — in a valid SIG field if the format of the PPDU is NON_HT and the PPDU is received in the primary 9 channel, or 10 11 — in a valid HT-SIG field if the format of the PPDU is HT_MF or HT_GF provided that the PPDU is 12 either a 20 MHz PPDU received in the primary channel, or a 40 MHz PPDU. 13 14 15 12.3.5.12 PHY-RXEND.indication 16 17 12.3.5.12.1 Function 18 19 20 Change 12.3.5.12.1 as follows: 21 22 23 This primitive is an indication by the PHY to the local MAC entity that the MPDUPSDU currently being re- 24 ceived is complete. 25 26 12.3.5.12.2 Semantics of the service primitive 27 28 29 Change 12.3.5.12.2 as follows: 30 31 32 The primitive provides the following parameter: 33 PHY-RXEND.indication (RXERROR,RXVECTOR) 34 35 The RXERROR parameter can convey one or more of the following values: NoError, FormatViolation, Car- 36 37 rierLost, or UnsupportedRate. A number of error conditions may occur after the PLCP’s receive state ma- 38 chine has detected what appears to be a valid preamble and SFD. The following describes the parameter 39 returned for each of those error conditions. 40 41 — NoError. This value is used to indicate that no error occurred during the receive process in the PLCP. 42 — FormatViolation. This value is used to indicate that the format of the received PPDU was in error. 43 44 — CarrierLost. This value is used to indicate that during the reception of the incoming MPDUPSDU, 45 the carrier was lost and no further processing of the MPDUPSDU can be accomplished. 46 47 — UnsupportedRate. This value is used to indicate that during the reception of the incoming PPDU, an 48 unsupported date rate was detected. 49 50 51 Insert the following subclauses 12.3.5.13 to 12.3.5.14.4 after 12.3.5.12 and its subclauses: 52 53 12.3.5.13 PHY-CONFIG.request 54 55 56 12.3.5.13.1 Function 57 58 This primitive is a request by the MAC sublayer to the local PHY entity to configure the PHY. 59 60 61 12.3.5.13.2 Semantics of the service primitive 62 63 The semantics of the primitives are as follows: 64 65 PHY-CONFIG.request (PHYCONFIG_VECTOR)

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 12.3.5.13.3 When generated 2 3 This primitive is generated by the MAC sublayer for the local PHY entity when it desires to change the con- 4 5 figuration of the PHY. 6 7 12.3.5.13.4 Effect of receipt 8 9 The effect of receipt of this primitive by the PHY is to apply the parameters provided and configure the PHY 10 11 for future operation. 12 13 12.3.5.14 PHY-CONFIG.confirm 14 15 12.3.5.14.1 Function 16 17 18 This primitive is issued by the PHY to the local MAC entity to confirm that the PHY has applied the param- 19 eters provided in the PHY-CONFIG.request. 20 21 12.3.5.14.2 Semantics of the service primitive 22 23 24 The semantics of the primitives are as follows: 25 PHY-CONFIG.confirm 26 27 This primitive has no parameters. 28 29 30 12.3.5.14.3 When generated 31 32 This primitive is issued by the PHY to the MAC entity when the PHY has received and successfully applied 33 the parameters in the PHY-CONFIG.request. 34 35 36 12.3.5.14.4 Effect of receipt 37 38 The effect of the receipt of this primitive by the MAC is unspecified. 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Insert the following Clause 20 (finishing at subclause 20.6) after Clause 19 and its subclauses: 2 3 4 5 20. High Throughput (HT) PHY specification 6 7 8 20.1 Introduction 9 10 11 20.1.1 Introduction to the HT PHY 12 13 Clause 20 specifies the PHY Entity for a high throughput (HT) orthogonal frequency division multiplexing 14 (OFDM) system. 15 16 17 In addition to the requirements found in Clause 20, when operating in a 20 MHz channel width in the 5 GHz 18 band, an HT STA shall be capable of transmitting and receiving frames that are compliant with mandatory 19 PHY specifications as defined in Clause 17. In addition to the requirements found in Clause 20, when oper- 20 ating in a 20 MHz channel width in the 2.4 GHz band, an HT STA shall be capable of transmitting and re- 21 ceiving frames that are compliant with mandatory PHY specifications as defined in Clauses 18 and 19. 22 23 24 The HT PHY is based on the OFDM PHY defined in Clause 17, with extensibility up to 4 spatial streams, 25 operating in 20 MHz bandwidth. Additionally, transmission using 1 to 4 spatial streams is defined for opera- 26 tion in 40 MHz bandwidth. These features are capable of supporting data rates up to 600 Mb/s (4 spatial 27 28 streams, 40 MHz bandwidth). 29 30 The HT PHY data subcarriers are modulated using binary phase shift keying (BPSK), quadrature phase shift 31 keying (QPSK), 16-quadrature amplitude modulation (16-QAM), or 64-QAM. Forward error correction cod- 32 ing (convolutional coding) is used with a coding rate of 1/2, 2/3, 3/4, or 5/6. Low-density parity-check (LD- 33 34 PC) codes are added as an optional feature. 35 36 Other optional features at both transmit and receive sides are 400 ns short guard interval (GI), transmit beam- 37 forming, HT-greenfield format, and space-time block codes (STBC). 38 39 40 An HT non-AP STA shall support all equal modulation rates for 1 spatial stream (MCSs 0 through 7) using 41 20 MHz channel width. An HT AP shall support all equal modulation rates for 1 and 2 spatial streams (MCSs 42 0 through 15) using 20 MHz channel width. 43 44 45 The maximum HT PSDU length is 65 535 octets. 46 47 20.1.2 Scope 48 49 50 The services provided to the MAC by the HT PHY consist of two protocol functions, defined as follows: 51 a) A PHY convergence function, which adapts the capabilities of the physical medium dependent 52 (PMD) system to the PHY service. This function is supported by the physical layer convergence 53 54 procedure (PLCP), which defines a method of mapping the PLCP service data units (PSDU) into a 55 framing format (PPDU) suitable for sending and receiving PSDUs between two or more STAs using 56 the associated PMD system. 57 58 b) A PMD system whose function defines the characteristics and method of transmitting and receiving 59 data through a wireless medium between two or more STAs. Depending on the PPDU format, these 60 STAs support a mixture of HT PHY and Clause 15, Clause 17, Clause 18 or Clause 19 PHYs. 61 62 20.1.3 HT PHY functions 63 64 65 The HT PHY contains three functional entities: the PHY convergence function (PLCP), the layer manage-

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 ment function (PLME) and the PMD function. Each of these functions is described in detail in 20.3 to 20.5. 2 3 4 The HT PHY service is provided to the MAC through the PHY service primitives defined in Clause 12. 5 6 7 20.1.3.1 HT PLCP sublayer 8 9 10 In order to allow the MAC to operate with minimum dependence on the PMD sublayer, a PHY convergence 11 sublayer is defined (PLCP). The PLCP sublayer simplifies the PHY service interface to the MAC services. 12 13 14 20.1.3.2 HT PMD sublayer 15 16 17 The HT PMD sublayer provides a means to send and receive data between two or more STAs. This Clause is 18 concerned with the 2.4 GHz and 5 GHz frequency bands using HT OFDM modulation. 19 20 21 20.1.3.3 PHY management entity (PLME) 22 23 24 The PLME performs management of the local PHY functions in conjunction with the MLME. 25 26 27 20.1.3.4 Service specification method 28 29 30 The models represented by figures and state diagrams are intended to be illustrations of the functions provid- 31 ed. It is important to distinguish between a model and a real implementation. The models are optimized for 32 simplicity and clarity of presentation; the actual method of implementation is left to the discretion of the HT 33 PHY compliant developer. The service of a layer or sublayer is the set of capabilities that it offers to a user 34 in the next higher layer (or sublayer). Abstract services are specified here by describing the service primitives 35 36 and parameters that characterize each service. This definition is independent of any particular implementa- 37 tion. 38 39 40 20.1.4 PPDU Formats 41 42 43 The structure of the PPDU transmitted by an HT STA is determined by the TXVECTOR FORMAT, 44 CH_BANDWIDTH, CH_OFFSET and MCS parameters as defined in Table 20-1. The effect of the 45 CH_BANDWIDTH, CH_OFFSET and MCS parameters on PPDU format is described in 20.2.3. 46 47 48 The FORMAT parameter determines the overall structure of the PPDU as follows: 49 50 — Non-HT format (NON_HT): packets of this format are structured according to the Clause 17 51 (OFDM) or 19 (ERP) specification. Support for Non-HT format is mandatory. 52 53 — HT-mixed format (HT_MF): packets of this format contain a preamble compatible with Clause 17 54 and Clause 19 receivers. The non-HT Short Training field (L-STF), the non-HT Long Training field 55 56 (L-LTF) and the non-HT SIGNAL field are defined so they can be decoded by non-HT Clause 17 57 and 19 STAs. The rest of the packet cannot be decoded by Clause 17 or Clause 19 STAs. Support for 58 HT-mixed format is mandatory. 59 60 — HT-greenfield format (HT_GF): HT packets of this format do not contain a non-HT compatible part. 61 Support for HT-greenfield format is optional. An HT STA that does not support the reception of an 62 HT-greenfield format packet shall be able to detect that an HT-greenfield format packet is an HT 63 64 transmission (as opposed to a non-HT transmission). In this case the receiver shall decode the HT- 65 SIG and determine if the HT-SIG cyclic redundancy check (CRC) passes.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 20.2 HT PHY service interface 2 3 4 20.2.1 Introduction 5 6 7 The PHY interfaces to the MAC through the TXVECTOR , RXVECTOR , and the PHYCONFIG_VECTOR. 8 The TXVECTOR supplies the PHY with per packet transmit parameters. Using the RXVECTOR , the PHY 9 10 informs the MAC of the received packet parameters. Using the PHYCONFIG_VECTOR, the MAC config- 11 ures the PHY for operation, independent of frame transmission or reception. 12 13 14 This interface is an extension of the generic PHY service interface defined in 12.3.4. 15 16 17 20.2.2 TXVECTOR and RXVECTOR parameters 18 19 20 The parameters in Table 20-1 are defined as part of the TXVECTOR parameter list in the PHY-TX- 21 START.request service primitive and/or as part of the RXVECTOR parameter list in the PHY-RXSTART.in- 22 23 dication service primitive. 24 25 26 Table 20-1—TXVECTOR and RXVECTOR parameters 27 28 29 30 31 32 Condition Value 33 TXVECTOR RXVECTOR

34 Parameter 35 See 36 NOTE 1 37 38 Determines the format of the PPDU. YY 39 Enumerated Type: 40 NON_HT indicates Clause 15, 17, 18 or 19 PPDU formats, or non-HT 41 duplicated PPDU format. In this case the modulation is determined by the 42 NON_HT_MODULATION parameter. FORMAT 43 HT_MF indicates HT-mixed format. 44 HT_GF indicates HT-greenfield format. 45 FORMAT is Enumerated Type: YY 46 NON_HT ERP-DSSS 47 ERP-CCK 48 ERP-OFDM 49 ERP-PBCC 50 DSSS-OFDM 51 OFDM 52 NON_HT_DUP_OFDM 53 54 Otherwise Not present

55 NON_HT_ MODULATION 56 57 FORMAT is Indicates the length of the PSDU in octets in the range 1-4095. This value YY 58 NON_HT is used by the PHY to determine the number of octet transfers that occur 59 between the MAC and the PHY. 60 61 FORMAT is HT_MF Indicates the value in the Length field of the Non-HT SIGNAL field in the YY 62 range 1-4095. This use is defined in 9.13.4. This parameter may be used

63 L_LENGTH for the protection of more than one PPDU as described in 9.13.5. 64 65 FORMAT is HT_GF Not present N N

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table 20-1—TXVECTOR and RXVECTOR parameters (continued) 2 3 4 5 6 7 Condition Value 8 TXVECTOR RXVECTOR

9 Parameter 10 See 11 NOTE 1 12 13 FORMAT is Indicates the rate used to transmit the PSDU in Mb/s. Allowed values YY 14 NON_HT depend on the value of the NON_HT_MODULATION parameter thus: 15 ERP-DSSS: 1 and 2 16 ERP-CCK: 5.5 and 11 17 ERP-PBCC: 5.5, 11, 22 and 33 18 DSSS-OFDM, ERP-OFDM, NON_HT_DUP_OFDM: 19 6, 9, 12, 18, 24, 36, 48 and 54 20 OFDM: 6, 9, 12, 18, 24, 36, 48, and 54 21 L_DATARATE FORMAT is HT_MF Indicates the data rate value that is in the Non-HT SIGNAL field. This use YY 22 is defined in 9.13.4. 23 24 FORMAT is HT_GF Not Present N N 25 26 FORMAT is HT_MF True if L-SIG Parity is valid NY 27 False if L-SIG Parity is not valid 28 29 FORMAT is not Not Present N N HT_MF

30 LSIGVALID 31 32 FORMAT is Scrambler initialization, 7 null bits + 9 reserved null bits Y N 33 NON_HT and 34 NON_HT_MODUL 35 ATION is one of: 36 — DSSS-OFDM, 37 —ERP-OFDM, 38 — OFDM

39 SERVICE 40 FORMAT is HT_MF Scrambler initialization, 7 null bits + 9 reserved null bits Y N 41 or HT_GF 42 Otherwise Not present N N 43 44 The allowed values for the TXPWR_LEVEL parameter are in the range YN 45 from 1 to 8. This parameter is used to indicate which of the available 46 TxPowerLevel attributes defined in the MIB shall be used for the current 47 transmission. 48 49

50 TXPWR_LEVEL 51 52 The allowed values for the RSSI parameter are in the range from 0 through NY 53 RSSI maximum. This parameter is a measure by the PHY of the power 54 observed at the antennas used to receive the current PPDU. RSSI shall be 55 measured during the reception of the PLCP preamble. In HT-mixed format 56 RSSI the reported RSSI shall be measured during the reception of the HT LTFs. 57 RSSI is intended to be used in a relative manner, and it shall be a monoton- 58 ically increasing function of the received power. 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table 20-1—TXVECTOR and RXVECTOR parameters (continued) 2 3 4 5 6 7 Condition Value 8 TXVECTOR RXVECTOR

9 Parameter 10 See 11 NOTE 1 12 13 FORMAT is Enumerated type: YY 14 NON_HT and SHORTPREAMBLE, LONGPREAMBLE 15 NON_HT_MODUL 16 ATION is one of: 17 — ERP-DSSS, — ERP-CCK, 18 — ERP-PBCC, 19 — DSSS-OFDM. 20 PREAMBLE_TYPE 21 Otherwise Not present N N 22 23 FORMAT is HT_MF The MCS field selects the modulation and coding scheme used in the YY 24 or HT_GF transmission of the packet. The value used in each modulation and coding 25 scheme is the index defined in 20.6. 26 Integer: range 0 to 76. Values of 77 to 127 are reserved. 27 MCS The interpretation of the MCS index is defined in 20.6. 28 29 Otherwise Not present N N 30 FORMAT is HT_MF The MCS that the STA's receiver recommends. N O 31 or HT_GF 32 33 Otherwise Not Present N N

34 REC_MCS 35 36 FORMAT is HT_MF The CH_BANDWIDTH parameter indicates whether the packet is trans- YY 37 or HT_GF mitted using 40 MHz or 20 MHz channel width. 38 Enumerated type: 39 HT_CBW20 for 20 MHz and 40 MHz Upper and 40 MHz Lower modes 40 HT_CBW40 for 40 MHz 41 FORMAT is Enumerated type: YY 42 NON_HT NON_HT_CBW40 for non-HT duplicate format 43 CH_BANDWIDTH NON_HT_CBW20 for all other non-HT formats 44 45 The CH_OFFSET parameter indicates which portion of the channel is YN 46 used for transmission. Refer to Table 20-2 for valid combinations of 47 CH_OFFSET and CH_BANDWIDTH. 48 49 Enumerated type: 50 CH_OFF_20 indicates the use of a 20 MHz channel (that is not part of a 40 51 MHz channel). 52 CH_OFFSET CH_OFF_40 indicates the entire 40 MHz channel. 53 CH_OFF_20U indicates the upper 20 MHz of the 40 MHz channel 54 CH_OFF_20L indicates the lower 20 MHz of the 40 MHz channel. 55 56 FORMAT is HT_MF Indicates the length of an HT PSDU in the range 0-65535 octets. A value YY 57 or HT_GF of zero indicates a Null Data Packet that contains no data symbols after the 58 HT preamble (see 20.3.9). 59 60 LENGTH Otherwise Not present N N 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table 20-1—TXVECTOR and RXVECTOR parameters (continued) 2 3 4 5 6 7 Condition Value 8 TXVECTOR RXVECTOR

9 Parameter 10 See 11 NOTE 1 12 13 FORMAT is HT_MF Indicates whether frequency-domain smoothing is recommended as part of YY 14 or HT_GF channel estimation. (See NOTE 2.) 15 Enumerated type: 16 SMOOTHING_REC indicates that smoothing is recommended. 17 SMOOTHING_NOT_REC indicates that smoothing is not recommended.

18 SMOOTHING Otherwise Not present N N 19 20 FORMAT is HT_MF Indicates whether this packet is a sounding packet. YY 21 or HT_GF Enumerated type: 22 SOUNDING indicates this is a sounding packet. 23 NOT_SOUNDING indicates this is not a sounding packet. 24 25 SOUNDING Otherwise Not present N N 26 27 FORMAT is HT_MF Indicates whether the PSDU contains an A-MPDU. YY 28 or HT_GF Enumerated type: 29 AGGREGATED indicates this is a packet with A-MPDU aggregation. 30 NOT_AGGREGATED indicates this is a packet without A-MPDU aggre- 31 gation 32 33 AGGREGATION Otherwise Not present N N 34 FORMAT is HT_MF YY 35 Indicates the difference between the number of space time streams (NSTS ) or HT_GF 36 and the number of spatial streams (NSS ) indicated by the MCS. 37 Set to 0 indicates no STBC (N = N ). 38 STS SS 39 Set to 1 indicates NSTS –1NSS = . 40 STBC Set to 2 indicates N –2N = . 41 STS SS 42 Value of 3 is reserved. 43 Otherwise Not present N N 44 45 FORMAT is HT_MF Indicates whether Binary Convolutional Code (BCC) or Low Density Par- YY 46 or HT_GF ity Check (LDPC) encoding is used. 47 Enumerated type: 48 BCC_CODING indicates Binary Convolutional Code. 49 LDPC_CODING indicates Low Density Parity Check code. 50 51 FEC_CODING Otherwise Not present N N 52 53 FORMAT is HT_MF Indicates whether a short Guard Interval (GI) is used in the transmission of YY 54 or HT_GF the packet. 55 Enumerated type: 56 LONG_GI indicates short GI is not used in the packet. 57 SHORT_GI indicates short GI is used in the packet. 58 GI_TYPE 59 Otherwise Not present N N 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table 20-1—TXVECTOR and RXVECTOR parameters (continued) 2 3 4 5 6 7 Condition Value 8 TXVECTOR RXVECTOR

9 Parameter 10 See 11 NOTE 1 12 13 FORMAT is HT_MF Indicates the number of extension spatial streams that are sounded during YY 14 or HT_GF the extension part of the HT training in the range 0-3. 15 Otherwise Not present N N 16 17 18

19 NUM_EXTEN_SS 20 21 FORMAT is HT_MF The ANTENNA_SET parameter indicates which antennas of the available ON 22 or HT_GF antennas are used in the transmission. The length of the field is 8 bits. A 1 23 in bit position n, relative to the LSB, indicates that antenna n is used. At 24 most 4 bits out of 8 may be set to 1. 25 This field is only present if antenna selection is applied. 26 27 ANTENNA_SET Otherwise Not present N N 28 FORMAT is HT_MF The N_TX parameter indicates the number of transmit chains. Y N 29 or HT_GF 30 31 N_TX Otherwise Not present N N 32 33 EXPANSION_MAT Contains a set of compressed beamforming matrices as defined in YN 34 _TYPE is 20.3.12.2.5. The number of elements depends on the number of spatial 35 COMPRESSED_SV streams and the number of transmit chains. 36 37 EXPANSION_MAT Contains a set of non-compressed beamforming matrices as defined in YN _TYPE is 38 20.3.12.2.4. The number of complex elements is NST  Nr  Nc where NON_COMPRESSE 39 N is the total number of subcarriers, N is the number of columns and 40 D_SV ST c 41 Nr is the number of rows in each matrix. 42 43 EXPANSION Contains a set of CSI matrices as defined in 20.3.12.2.1. The number of YN 44 _MAT_TYPE is EXPANSION_MAT complex elements is NST  Nr  Nc where NST is the total number of sub- 45 CSI_MATRICES carriers, N is the number of columns and N is the number of rows in 46 c r 47 each matrix. 48 49 Otherwise. Not present NN 50 EXPANSION_MAT Enumerated type: YN 51 is present. COMPRESSED_SV indicates that EXPANSION_MAT is a set of com- 52 pressed beamforming matrices. 53 NON_COMPRESSED_SV indicates that EXPANSION_MAT is a set of 54 non-compressed beamforming matrices. 55 CSI_MATRICES indicates that EXPANSION_MAT is a set of channel 56 state matrices. 57 58 Otherwise Not present N N 59

60 EXPANSION_MAT_TYPE 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table 20-1—TXVECTOR and RXVECTOR parameters (continued) 2 3 4 5 6 7 Condition Value 8 TXVECTOR RXVECTOR

9 Parameter 10 See 11 NOTE 1 12 13 CHAN_MAT_TYPE CHAN_MAT contains a set of compressed beamforming matrices as NY 14 is defined in 20.3.12.2.5 based on the channel measured during the training 15 COMPRESSED_SV. symbols of the received PPDU. The number of elements depends on the 16 number of spatial streams and the number of transmit chains. 17 CHAN_MAT_TYPE CHAN_MAT contains a set of non-compressed beamforming matrices as NY 18 is defined in 20.3.12.2.4 based on the channel measured during the training 19 NON_COMPRESSE symbols of the received PPDU. The number of complex elements is 20 D_SV. 21 NST  Nr  Nc where NST is the total number of subcarriers, Nc is the 22 number of columns and Nr is the number of rows in each matrix. 23

24 CHAN_MAT CHAN_MAT_TYPE CHAN_MAT contains a set of CSI matrices as defined in 20.3.12.2.1 NY 25 is CSI_MATRICES. based on the channel measured during the training symbols of the received 26 PPDU. The number of complex elements is NST  Nr  Nc where NST is 27 28 the total number of subcarriers, Nc is the number of columns and Nr is the 29 number of rows in each matrix. 30 31 Otherwise. Not present. N N 32 FORMAT is HT_MF Enumerated type: NY 33 or HT_GF. COMPRESSED_SV indicates that CHAN_MAT is a set of compressed 34 beamforming vector matrices. 35 NON_COMPRESSED_SV indicates that CHAN_MAT is a set of non- 36 compressed beamforming vector matrices. 37 CSI_MATRICES indicates that CHAN_MAT is a set of channel state 38 matrices. 39

40 CHAN_MAT_TYPE Otherwise Not present N N 41 42 This parameter is a measure of the received RF Power averaged over all NY 43 the receive chains in the data portion of a received frame.

44 RCPI Refer to 20.3.22.6 for the definition of RCPI. 45 46 CHAN_MAT_TYPE This parameter is a measure of the received SNR per chain. SNR indica- NY 47 is CSI_MATRICES tions of 8 bits are supported. SNR shall be the dB representation of linearly 48 averaged values over the tones represented in each receive chain as 49 described in 7.3.1.27 50 51 CHAN_MAT_TYPE This parameter is a measure of the received SNR per stream. SNR indica- NY 52 SNR is tions of 8 bits are supported. SNR shall be the sum of the dB values of 53 COMPRESSED_SV SNR per tone divided by the number of tones represented in each stream as 54 or described in 7.3.1.28 and 7.3.1.29 55 NON_COMPRESSE 56 D_SV 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table 20-1—TXVECTOR and RXVECTOR parameters (continued) 2 3 4 5 6 7 Condition Value 8 TXVECTOR RXVECTOR

9 Parameter 10 See 11 NOTE 1 12 13 Either: Indicates whether signal extension needs to be applied at the end of trans- YN 14 mission or not. 15 FORMAT is HT_MF 16 or HT_GF, or Boolean with values TRUE (no signal extension is present) and FALSE 17 (signal extension may be present depending on other TXVECTOR param- 18 FORMAT is eters, see 20.2.2). 19 NON_HT and 20 NON_HT_MODUL 21 ATION is ERP- 22 OFDM, DSSS- NO_SIG_EXTN 23 OFDM or 24 NON_HT_DUPOFD 25 M. 26 Otherwise Not Present N N 27 28 NOTE 1—In the TXVECTOR and RXVECTOR columns, the following apply: 29 Y = Present 30 N = Not present 31 O = Optional 32 NOTE 2—Setting of the smoothing bit is defined in 20.3.11.10.1. 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 20.2.3 Effect of CH_BANDWIDTH, CH_OFFSET and MCS parameters on PPDU format 2 3 The structure of the PPDU transmitted by an HT STA is determined by the TXVECTOR FORMAT, 4 5 CH_BANDWIDTH, CH_OFFSET and MCS parameters as defined in Table 20-1. The effect of the FOR- 6 MAT parameter is described in 20.1.4. 7 8 The operation of the PHY in the frequency domain is determined by the CH_BANDWIDTH and 9 CH_OFFSET parameters. Table 20-2 shows the combination of CH_BANDWIDTH and CH_OFFSET pa- 10 11 rameters that are supported. 12 13 14 Table 20-2—PPDU format as a function of CH_BANDWIDTH and CH_OFFSET parameters 15 16 17 18 CH_BANDWIDTH CH_OFFSET 19 20 HT_CBW20 CH_OFF_20 or CH_OFFSET is not present: 20 MHz HT Format—a STA that 21 has a 20 MHz operating channel width transmits an HT-mixed or HT-greenfield 22 format packet of 20 MHz bandwidth with one to four spatial streams. 23 24 CH_OFF_40: Not defined 25 CH_OFF_20U: 40 MHz HT upper format—the STA transmits an HT-mixed or 26 HT-greenfield format packet of 20 MHz bandwidth with one to four spatial 27 streams in the upper 20 MHz of a 40 MHz channel. 28 29 CH_OFF_20L: 40 MHz HT lower format—the STA transmits an HT-mixed or 30 HT-greenfield format packet of 20 MHz bandwidth with one to four spatial 31 streams in the lower 20 MHz of a 40 MHz channel. 32 33 HT_CBW40 Not present: Not defined 34 CH_OFF_20: Not defined 35 36 CH_OFF_40: 40 MHz HT format—a PPDU of this format occupies a 40 MHz 37 channel to transmit an HT-mixed or HT-greenfield format packet of 40 MHz 38 bandwidth with one to four spatial streams. 39 40 CH_OFF_20U: Not defined 41 CH_OFF_20L: Not defined 42 43 NON_HT_CBW20 CH_OFF_20 or CH_OFFSET is not present: 20 MHz non-HT format—a STA 44 that has a 20 MHz operating channel width transmits a non-HT format packet 45 according to Clause 17 or Clause 19 operation. 46 47 CH_OFF_40: Not defined 48 CH_OFF_20U: 40 MHz Non-HT upper format—the STA transmits a non-HT 49 packet of type ERP-DSSS, ERP-CCK, ERP-OFDM, ERP-PBCC, DSSS- 50 OFDM, or OFDM in the upper 20 MHz of a 40 MHz channel. 51 52 CH_OFF_20L: 40 MHz Non-HT lower format—the STA transmits a non-HT 53 packet of type ERP-DSSS, ERP-CCK, ERP-OFDM, ERP-PBCC, DSSS- 54 OFDM, or OFDM in the lower 20 MHz of a 40 MHz channel. 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table 20-2—PPDU format as a function of CH_BANDWIDTH and CH_OFFSET parameters 2 (continued) 3 4 5 CH_BANDWIDTH CH_OFFSET 6 7 NON_HT_CBW40 Not present: Not defined 8 9 CH_OFF_20: Not defined 10 CH_OFF_40: Non-HT duplicate format—the STA operates in a 40 MHz chan- 11 nel composed of two adjacent 20 MHz channels. The packets to be sent are in 12 the Clause 17 format in each of the 20 MHz channels. The upper channel 13 (higher frequency) is rotated by +90º relative to the lower channel. See 14 20.3.11.11. 15 16 CH_OFF_20U: Not defined 17 18 CH_OFF_20L: Not defined 19 20 21 NOTE—Support of 20 MHz Non-HT Format and 20 MHz HT Format with one and two spatial streams is mandatory at 22 APs. Support of 20 MHz Non-HT Format and 20 MHz HT Format with one spatial stream is mandatory at non-AP 23 STAs. 24 25 26 20.2.4 Support for NON_HT formats 27 28 When the FORMAT parameter is set to NON_HT, the behavior of the HT PHY is defined in other Clauses 29 as shown in Table 20-3, dependent on the operational band. In this case, the PHY-TXSTART.request is han- 30 dled by mapping the TXVECTOR parameters as defined in Table 20-3 and following operation as defined in 31 32 the referenced clause. Likewise the PHY-RXSTART.indication emitted when a NON_HT PPDU is received 33 is defined in the referenced clauses, with mapping of RXVECTOR parameters as defined in Table 20-3. 34 35 Non-HT format PPDUs structured according to Clause 15, Clause 17, Clause 18, or Clause 19 are transmitted 36 within the limits of the transmit spectrum mask specified in the respective clauses, transmitted as non-HT du- 37 38 plicate PPDUs within the limits of the 40 MHz transmit spectrum mask defined in 20.3.21.1, or transmitted 39 as 20 MHz format non-HT PPDUs, within the limits of the 40 MHz transmit spectrum mask defined in 40 20.3.21.1, in the upper (CH_BANDWIDTH of value NON_HT_CBW20 and CH_OFFSET of value 41 CH_OFF_20U) or lower (CH_BANDWIDTH of value NON_HT_CBW20 and CH_OFFSET of value 42 CH_OFF_20U) 20 MHz of the 40 MHz channel. Non-HT PPDUs transmitted using the 40 MHz transmit 43 44 spectrum mask are referred to as 40 MHz mask non-HT PPDUs. Refer to 11.14.9 for CCA sensing rules for 45 transmission of 40 MHz mask non-HT PPDUs. 46 47 48 20.3 HT PLCP sublayer 49 50 20.3.1 Introduction 51 52 53 A convergence procedure, in which PSDUs are converted to and from PPDUs, is provided for the HT PHY 54 in 20.3. During transmission, the PSDU is processed (i.e., scrambled and coded) and appended to the PLCP 55 preamble to create the PPDU. At the receiver, the PLCP preamble is processed to aid in demodulation and 56 delivery of the PSDU. 57 58 59 Two preamble formats are defined. For HT-mixed format operation, the preamble has a non-HT portion and 60 an HT portion. The non-HT portion of the HT-mixed format preamble enables detection of the PPDU and 61 acquisition of carrier frequency and timing by both HT STAs and STAs that are compliant with Clause 17 62 and/or Clause 19. The non-HT portion of the HT-mixed format preamble also consists of the SIGNAL field 63 64 defined in Clause 17 and is thus decodable by STAs compliant with Clause 17 and Clause 19, as well as HT 65 STAs.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table 20-3—Mapping of the HT PHY parameters for NON_HT operation 2 3 4 2.4 GHz operation 2.4 GHz operation 2.4 GHz operation 5.0 GHz operation HT PHY 5 Operation defined Operation defined Operation defined Operation defined Parameter 6 by Clause 15 by Clause 18 by Clause 19 by Clause 17 7 8 L_LENGTH LENGTH LENGTH LENGTH LENGTH 9 10 L_DATARATE DATARATE DATARATE DATARATE DATARATE 11 12 LSIGVALID---- 13 14 TXPWR_LEVEL TXPWR_LEVEL TXPWR_LEVEL TXPWR_LEVEL TXPWR_LEVEL 15 16 RSSI RSSI RSSI RSSI RSSI 17 18 FORMAT---- 19 20 PREAMBLE_TYP - - PREAMBLE_TYP - 21 E E 22 23 NON_HT_MODUL - MODULATION MODULATION - 24 ATION 25 SERVICE SERVICE SERVICE SERVICE SERVICE 26 27 MCS---- 28 29 CH_BANDWIDTH ---- 30 31 CH_OFFSET---- 32 33 LENGTH---- 34 SMOOTHING---- 35 36 SOUNDING---- 37 38 AGGREGATION---- 39 40 STBC---- 41 42 FEC_CODING---- 43 GI_TYPE---- 44 45 NUM_EXTEN_SS---- 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table 20-3—Mapping of the HT PHY parameters for NON_HT operation (continued) 2 3 4 2.4 GHz operation 2.4 GHz operation 2.4 GHz operation 5.0 GHz operation HT PHY 5 Operation defined Operation defined Operation defined Operation defined Parameter 6 by Clause 15 by Clause 18 by Clause 19 by Clause 17 7 8 ANTENNA_SET ---- 9 10 EXPANSION_MAT---- 11 12 EXPANSION_MAT ---- 13 _TYPE 14 CHAN_MAT---- 15 16 CHAN_MAT_TYP ---- 17 E 18 19 N_TX---- 20 21 RCPI RCPI RCPI RCPI RCPI 22 23 REC_MCS---- 24 NO_SIG_EXTN---- 25 26 NOTE—A dash (‘-’) in an entry above indicates that the related parameter is not present. 27 28 29 30 The HT portion of the HT-mixed format preamble enables estimation of the MIMO channel to support de- 31 modulation of the HT data by HT STAs. The HT portion of the HT-mixed format preamble also includes the 32 HT-SIG field, which supports HT operation. The SERVICE field is prepended to the PSDU. 33 34 35 For HT-greenfield operation, compatibility with Clause 17 and Clause 19 STAs is not required. Therefore, 36 the non-HT portions of the preamble are not included in the HT-greenfield format preamble. 37 38 20.3.2 PLCP frame format 39 40 41 Two formats are defined for the PLCP (PHY Layer Convergence Protocol): HT-mixed format and HT-green- 42 field format. These two formats are called HT formats. Figure 20-1 shows the non-HT format1 and the HT 43 formats. There is also an MCS 32 format (specified in 20.3.11.10.4) used for MCS 32 that provides the lowest 44 45 rate in a 40 MHz channel. In addition to the HT formats, there is a non-HT duplicate format (specified in 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 1. The Non-HT format is shown related to the terminology of this subclause. The Non-HT PPDU format is defined in 17.3.3 65 and 17.3.2.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 20.3.11.11) that duplicates the 20 MHz non-HT packet in two 20 MHz halves of a 40 MHz channel. 2 3

4 Format of Data field SERVICE Scrambled 6·NES Pad 5 (non LDPC case only) 16 bits PSDU Tail bits bits 6 Non-HT PPDU 7 8 8µs 8µs 4µs 9 L- 10 L-STF L-LTF Data 11 SIG 12 13 HT-mixed format PPDU 14 Data HT-LTFs Extension HT-LTFs 15 8µs 8µs4µs 8µs 4µs 4µs per LTF 4µs per LTF 16 17 L- HT- HT- HT- HT- HT- L-STF L-LTF HT-SIG Data 18 SIG STF LTF LTF LTF LTF 19 20 21 HT-greenfield format PPDU Data HT-LTFs Extension HT-LTFs 22 8µs 8µs 8µs 4µs per LTF 4µs per LTF 23 24 HT- HT- HT- HT- HT-GF-STF HT-LTF1 HT-SIG Data 25 LTF LTF LTF LTF 26 27 Figure 20-1—PPDU format 28 29 30 The elements of the PLCP packet are summarized in Table 20-4. 31 32 33 Table 20-4—Elements of the HT PLCP packet 34 35 36 Element Description 37 38 L-STF Non-HT Short Training field 39 40 L-LTF Non-HT Long Training field 41 42 L-SIG Non-HT SIGNAL field 43 44 HT-SIG HT SIGNAL field 45 HT-STF HT Short Training field 46 47 HT-GF-STF HT-greenfield Short Training field 48 49 HT-LTF1 First HT Long Training field (Data HT-LTF) 50 51 HT-LTFs Additional HT Long Training fields (Data HT-LTFs and Extension HT-LTFs) 52 53 Data The data field includes the PSDU (PHY Service Data Unit) 54 55 56 57 The HT-SIG, HT-STF, HT-GF-STF, HT-LTF1, and HT-LTFs exist only in HT packets. In non-HT and non- 58 HT duplicate formats only the L-STF, L-LTF, L-SIG and Data fields exist. 59 60 61 In both HT-mixed format and HT-greenfield format frames, there are two types of HT-LTFs: Data HT-LTFs 62 (DLTFs) and Extension HT-LTFs (ELTFs). DLTFs are always included in HT PPDUs to provide the neces- 63 sary reference for the receiver to form a channel estimate that allows it to demodulate the data portion of the 64 65 frame. The number of DLTFs, NDLTF , may be either 1, 2, or 4, and is determined by the number of space

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 time streams being transmitted in the frame (see Table 20-12). ELTFs provide additional reference in sound- 2 ing PPDUs so that the receiver can form an estimate of additional dimensions of the channel beyond those 3 4 that are used by the data portion of the frame. The number of ELTFs, NELTF , may be either 0, 1, 2, or 4 (see 5 Table 20-13). PLCP preambles in which DLTFs are followed by ELTFs are referred to as staggered pream- 6 bles. The HT-mixed format and HT-greenfield format frames shown in Figure 20-1 both contain staggered 7 8 preambles for illustrative purposes. 9 10 Transmissions of frames with TXVECTOR parameter NO_SIG_EXTN set to FALSE are followed by a 11 period of no transmission for a duration of aSignalExtension µs. See 9.2.10a. 12 13 14 A Signal Extension shall be present in a transmitted PPDU, based on the parameters of the TXVECTOR, 15 when the NO_SIG_EXTN parameter is set to FALSE and either of the following is TRUE: 16 — the FORMAT parameter is set to HT_MF, or HT_GF 17 18 — the FORMAT parameter is set to NON_HT and the NON_HT_MODULATION parameter is set to 19 one of ERP-OFDM, DSSS-OFDM and NON_HT_DUPOFDM. 20 21 22 A Signal Extension shall be assumed to be present (for the purpose of timing of PHY-RXEND.indication and 23 PHY-CCA.indication primitives, as described below and in 20.3.24) in a received PPDU when either of the 24 following is true, based on the determined parameter values of the RXVECTOR: 25 26 — The FORMAT parameter is HT_MF, or HT_GF 27 — The FORMAT parameter is NON_HT and the NON_HT_MODULATION parameter is set to one of 28 ERP-OFDM, DSSS-OFDM and NON_HT_DUPOFDM. 29 30 31 A PPDU containing a Signal Extension is called a signal extended PPDU. When transmitting a signal extend- 32 ed PPDU, the PHY-TXEND.indication primitive shall be emitted a period of aSignalExtension µs after the 33 end of the last symbol of the PPDU. When receiving a signal extended PPDU, the PHY-RXEND.indication 34 primitive shall be emitted a period of aSignalExtension µs after the end of the last symbol of the PPDU. 35 36 37 20.3.3 Transmitter block diagram 38 39 HT-mixed format and HT-greenfield format transmissions can be generated using a transmitter consisting of 40 of the following blocks: 41 42 a) Scrambler: scrambles the data to reduce the probability of long sequences of zeros or ones, see 43 20.3.11.2. 44 45 b) Encoder parser: if BCC encoding is to be used, de-multiplexes the scrambled bits among NES (num- 46 ber of BCC encoders for the Data field) BCC encoders, in a round robin manner. 47 48 c) FEC encoders: encode the data to enable error correction—an FEC encoder may include a binary 49 convolutional encoder followed by a puncturing device, or an LDPC encoder. 50 d) Stream parser: divides the outputs of the encoders into blocks that are sent to different interleaver 51 52 and mapping devices. The sequence of the bits sent to an interleaver is called a spatial stream. 53 e) Interleaver: interleaves the bits of each spatial stream (changes order of bits) to prevent long 54 sequences of adjacent noisy bits from entering the BCC decoder. Interleaving is only applied when 55 56 BCC encoding is used. 57 f) Constellation mapper: maps the sequence of bits in each spatial stream to constellation points (com- 58 plex numbers). 59 60 g) Space time block encoder: constellation points from NSS spatial streams are spread into NSTS space 61 62 time streams using a space time block code. Space time block coding is only used when NSS  NSTS 63 – see 20.3.11.8.1. 64 65 h) Spatial mapper: maps space time streams to transmit chains. This may include one of the following:

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 1) Direct mapping: constellation points from each space time stream are mapped directly onto the 2 transmit chains (one-to-one mapping). 3 4 2) Spatial expansion: vectors of constellation points from all the space time streams are expanded 5 via matrix multiplication to produce the input to all the transmit chains. 6 3) Beamforming: similar to spatial expansion: each vector of constellation points from all the 7 8 space time streams is multiplied by a matrix of steering vectors to produce the input to the 9 transmit chains. 10 i) Inverse discrete Fourier transform (IDFT): converts a block of constellation points to a time domain 11 12 block. 13 j) Cyclic shift (CSD) insertion: insertion of the cyclic shifts prevents unintentional beamforming. CSD 14 insertion may occur before or after the IDFT. There are three cyclic shift types as follows: 15 16 1) A cyclic shift specified per transmitter chain with the values defined in Table 20-8 (a possible 17 implementation is shown in Figure 20-2). 18 2) A cyclic shift specified per space time stream with the values defined in Table 20-9 (a possible 19 20 implementation is shown in Figure 20-3). 21 3) A cyclic shift M k may be applied as a part of the spatial mapper, see 20.3.11.10.1. 22 CSD 23 k) Guard interval (GI) insertion: prepend to the symbol a circular extension of itself. 24 25 l) Windowing: optionally smoothing the edges of each symbol to increase spectral decay. 26 27 Insert 28 Analog GI and 29 and RF 30 Window 31 32 Insert 33 Analog CSD GI and 34 and RF 35 Window 36

37 IDFT

Mapper Insert Analog 38 Interleaver CSD GI and Constellation

BCC Encoder and RF 39 Window 40 41 42 Insert Analog 43 CSD GI and and RF 44 Window 45 46 47 48 49 Single Spatial Stream NTX Transmit Chains 50 51 Figure 20-2—Transmitter block diagram 1 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 2 Insert Constellation GI Analog Interleaver IDFT 3 mapper and and RF 4 Window 5 6 7 8

FEC encoder Insert 9 Constellation Analog Interleaver CSD IDFT GI and mapper and RF 10 Window 11 12 13

14 STBC Scrambler

15 Encoder Parser Spatial Mapping

Stream Parser Insert Constellation Analog 16 Interleaver CSD IDFT GI and mapper and RF 17 Window 18 19 20

21 FEC encoder

22 Insert Constellation Analog 23 Interleaver CSD IDFT GI and mapper and RF 24 Window 25 26 27 NSS Spatial Streams NSTS Space Time 28 NTX Transmit Chains NOTES Streams 29 —There may be 1 or 2 FEC encoders when BCC encoding is used. 30 —The stream parser may have 1, 2, 3 or 4 outputs. 31 —When LDPC encoding is used, the interleavers are not used 32 —When STBC is used, the STBC block has more outputs than inputs. —When spatial mapping is used, there may be more transmit chains than space time streams. 33 —The number of inputs to the spatial mapper may be 1, 2, 3, or 4. 34 35 Figure 20-3—Transmitter block diagram 2 36 37 38 Figure 20-2 and Figure 20-3 show example transmitter block diagrams. In particular, Figure 20-2 shows the 39 transmitter blocks used to generate the HT signal field of the HT-mixed format PPDU. These transmitter 40 blocks are also used to generate the non-HT portion of the HT-mixed format PPDU, except that the BCC en- 41 coder and interleaver are not used when generating the L-STF and L-LTF fields. Figure 20-3 shows the trans- 42 mitter blocks used to generate the Data field of the HT-mixed format and HT-greenfield format PPDUs. A 43 44 subset of these transmitter blocks consisting of the constellation mapper and CSD blocks, as well as the blocks 45 to the right of, and including, the spatial mapping block, are also used to generate the HT-STF, HT-GF-STF, 46 and HT-LTF fields. The HT-greenfield format signal field is generated using the transmitter blocks shown in 47 Figure 20-2, augmented by additional CSD and spatial mapping blocks. 48 49 50 20.3.4 Overview of the PPDU encoding process 51 52 53 The encoding process is composed of the steps described below. The following overview is intended to facil- 54 itate understanding of the details of the convergence procedure: 55 56 57 a) Determine the number of transmit chains, NTX , from the N_TX field of the TXVECTOR. Produce 58 the PLCP Preamble training fields for each of the N transmit chains based on the FORMAT, 59 TX 60 NUM_EXTEN_SS, CH_BANDWIDTH, and MCS parameters of the TXVECTOR. The format and 61 relative placement of the PLCP Preamble training fields vary depending on the frame format being 62 used, as indicated by these parameters. Apply cyclic shifts. Determine spatial mapping to be used for 63 64 HT-STF and HT-LTFs in HT-mixed format frame and HT-GF-STF and HT-LTFs in HT-greenfield 65 format frame from EXPANSION_MAT parameter of the TXVECTOR. Refer to 20.3.9 for details.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 b) Construct the PLCP preamble signal fields from the appropriate fields of the TXVECTOR, adding 2 tail bits, applying convolutional coding, formatting into one or more OFDM symbols, applying 3 cyclic shifts, applying spatial processing, calculating an inverse Fourier transform for each OFDM 4 5 symbol and transmit chain, and prepending a cyclic prefix, or guard interval (GI) to each OFDM 6 symbol in each transmit chain. The number and placement of the PLCP preamble signal fields 7 depends on the frame format being used. Refer to 20.3.9.3.5, 20.3.9.4.3, and 20.3.9.5.3. 8 9 c) Concatenate the PLCP Preamble training and signal fields for each transmit chain one field after 10 another, in the appropriate order, as described in 20.3.2 and 20.3.7. 11 d) Use the MCS and CH_BANDWIDTH parameters of the TXVECTOR to determine the number of 12 13 data bits per OFDM symbol (NDBPS ), the coding rate (R ), the number of coded bits in each OFDM 14 subcarrier (N ), and the number of coded bits per OFDM symbol (N ). Determine the num- 15 BPSC CBPS 16 ber of encoding streams (NES ) from the MCS, CH_BANDWIDTH, and FEC_CODING parameters 17 18 of the TXVECTOR. Refer to 20.3.11.3 for details. 19 e) Append the PSDU to the SERVICE field (see 20.3.11.1). If BCC encoding is to be used, as indicated 20 by the FEC_CODING parameter of the TXVECTOR, tail bits are appended to the PSDU. If a single 21 22 BCC encoder is used (i.e., when the value of NES is 1), the bit string is extended by 6 zero bits. If 23 24 two BCC encoders are used (i.e., when the value of NES is 2), the bit string is extended by 12 zero 25 bits. The number of symbols, N , is calculated according to Equation (20-32) and if necessary, 26 SYM 27 the bit string is further extended with zero bits so that the resulting length is a multiple of 28 NSYM  NDBPS , as described in 20.3.11. If LDPC encoding is to be used, as indicated by the 29 30 FEC_CODING parameter of the TXVECTOR, the resulting bit string is padded, if needed, by 31 repeating coded bits rather than using zero bits, as given in the encoding procedure of 20.3.11.6.5. 32 The number of resulting symbols is given by Equation (20-41), and the number of repeated coded 33 bits used for padding is given by Equation (20-42). The resulting bit string constitutes the DATA 34 part of the packet. 35 36 f) Initiate the scrambler with a pseudo-random nonzero seed, generate a scrambling sequence, and 37 XOR (boolean exclusive OR operation) it with the string of data bits, as described in 17.3.5.4. 38 39 g) If BCC encoding is to be used, replace the scrambled zero bits that served as tail bits (six bits if the 40 value of NES is 1, twelve bits if the value of NES is 2) following the data with the same number of 41 42 nonscrambled zero bits, as described in 17.3.5.2. (These bits return the convolutional encoder to the 43 zero state.) 44 45 h) If BCC encoding is to be used, and the value of NES is 2, the scrambled data bits are divided 46 between two BCC encoders by sending alternating bits to the two different encoders, as described in 47 20.3.11.4. 48 49 i) If BCC encoding is to be used, encode the extended, scrambled data string with a rate ½ convolu- 50 tional encoder (see 17.3.5.5 (Convolutional encoder)). Omit (puncture) some of the encoder output 51 string (chosen according to puncturing pattern) to reach the desired coding rate, R. Refer to 52 53 20.3.11.5 for details. If LDPC encoding is to be used, encode the scrambled data stream according to 54 20.3.11.6.5. 55 j) Parse the coded bit stream that results from the BCC encoding or LDPC encoding into N spatial 56 SS 57 streams, where the value of NSS is determined from the MCS parameter of the TXVECTOR. See 58 59 20.3.11.7.2 for details. 60 k) Divide each of the N encoded and parsed spatial streams of bits into groups of N i bits. If 61 SS CBPSS 62 BCC encoding is to be used, within each spatial stream and group, perform an “interleaving” (reor- 63 dering) of the bits according to a rule corresponding to N i , where i is the index of the spa- 64 BPSCS 65 tial stream. Refer to 20.3.6 for details.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 l) For each of the N encoded, parsed and interleaved spatial streams, divide the resulting coded and 2 SS 3 interleaved data string into groups of NBPSCSi bits, where i is the index of the spatial stream. For 4 each of the bit groups, convert the bit group into a complex number according to the modulation 5 6 encoding tables. Refer to 17.3.5.7 for details. 7 m) Divide the complex number string for each of the resulting N spatial streams into groups of N 8 SS SD 9 complex numbers, where the value of NSD is determined from the CH_OFFSET parameter of 10 11 TXVECTOR and the CH_BANDWIDTH parameter of TXVECTOR. Each such group is associated 12 with one OFDM symbol in one spatial stream. In each group, the complex numbers are indexed 0 to 13 NSD – 1 and these indices have an associated one-to-one correspondence with subcarrier indices via 14 15 the mapping function M rk as described in 20.3.11.10, 20.3.11.10.2, 20.3.11.10.3, 20.3.11.10.4, 16 17 and 20.3.11.11. 18 n) If space time block coding (STBC) is to be applied, as indicated by the STBC parameter in the 19 TXVECTOR, operate on the complex number associated with each data subcarrier in sequential 20 21 pairs of OFDM symbols as described in 20.3.11.8.1 to generate NSTS OFDM symbols for every 22 N OFDM symbols associated with the N spatial streams. If STBC is not to be used, the number 23 SS SS 24 of space time streams is the same as the number of spatial streams, and the sequences of OFDM 25 symbols in each space time stream are composed of the sequences of OFDM symbols in the corre- 26 27 sponding spatial stream. In each group of NSD resulting complex numbers in each space time 28 stream, the complex numbers indexed 0 to NSD – 1 are mapped onto OFDM subcarriers via the 29 30 mapping function M rk as described in 20.3.11.10, 20.3.11.10.2, 20.3.11.10.3, 20.3.11.10.4, and 31 32 20.3.11.11. 33 o) Determine whether 20 MHz or 40 MHz operation is to be used from the CH_BANDWIDTH param- 34 eter of the TXVECTOR. Specifically, when CH_BANDWIDTH is HT_CBW20 or 35 36 NON_HT_CBW20, 20 MHz operation is to be used. When CH_BANDWIDTH is HT_CBW40 or 37 NON_HT_CBW40, 40 MHz operation is to be used. For 20 MHz operation (with the exception of 38 non-HT formats), insert four subcarriers as pilots into positions –21, –7, 7, and 21. The total number 39 of the subcarriers, N , is 56. For 40 MHz operation (with the exception of MCS 32 and non-HT 40 ST 41 duplicate format ), insert six subcarriers as pilots into positions -53, -25, -11, 11, 25, and 53, result- 42 ing in a total of N = 114 subcarriers. See 20.3.11.10.4 for pilot locations when using MCS 32, 43 ST 44 and 20.3.11.11 for pilot locations when using non-HT duplicate format. The pilots are modulated 45 using a pseudo-random cover sequence. Refer to 20.3.11.9 for details. For 40 MHz operation, apply 46 a +90 degree phase shift to the complex value in each OFDM subcarrier with an index greater than 47 0, as described in 20.3.11.10.3, 20.3.11.10.4, and 20.3.11.11. 48 49 p) Map each of the complex numbers in each of the NST subcarriers in each of the OFDM symbols in 50 51 each of the NSTS space time streams to the NTX transmit chain inputs. For direct-mapped operation, 52 53 NTX = NSTS and there is a one-to-one correspondence between space time streams and transmit 54 chains. In this case, the OFDM symbols associated with each space time stream are also associated 55 with the corresponding transmit chain. Otherwise, a spatial mapping matrix associated with each 56 OFDM subcarrier, as indicated by the EXPANSION_MAT parameter of the TXVECTOR, is used 57 58 to perform a linear transformation on the vector of NSTS complex numbers associated with each 59 subcarrier in each OFDM symbol. This spatial mapping matrix maps the vector of N complex 60 STS 61 numbers in each subcarrier into a vector of NTX complex numbers in each subcarrier. The sequence 62 63 of NST complex numbers associated with each transmit chain (where each of the NST complex 64 65 numbers is taken from the same position in the NTX vector of complex numbers across the NST sub-

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 carriers associated with an OFDM symbol) constitutes an OFDM symbol associated with the corre- 2 sponding transmit chain. For details, see 20.3.11.10. Spatial mapping matrices may include cyclic 3 shifts, as described in 20.3.11.10.1. 4 5 q) If the CH_BANDWIDTH and CH_OFFSET parameters of the TXVECTOR indicate that upper or 6 lower 20 MHz are to be used in 40 MHz, move the complex numbers associated with subcarriers -28 7 to 28 in each transmit chain to carriers 4 to 60 in the upper channel or -60 to -4 in the lower channel. 8 9 Note that this shifts the signal in frequency from the center of the 40 MHz channel to +10 MHz or - 10 10 MHz offset from the center of the 40 MHz channel. The complex numbers in the other subcarri- 11 ers are set to zero. 12 13 r) For each group of NST subcarriers and each of the NTX transmit chains, convert the subcarriers to 14 time domain using inverse discrete Fourier transform. Prepend to the Fourier-transformed waveform 15 a circular extension of itself, thus forming a GI, and truncate the resulting periodic waveform to a 16 17 single OFDM symbol length by applying time domain windowing. Determine the length of the 18 guard interval according to the GI_TYPE parameter of the TXVECTOR. Refer to 20.3.11.10 and 19 20.3.11.11 for details. When beamforming is not used it is sometimes possible to implement the 20 cyclic shifts in the time domain. 21 22 s) Append the OFDM symbols associated with each transmit chain one after another, starting after the 23 final field of the PLCP preamble. Refer to 20.3.2 and 20.3.7 for details. 24 t) Up-convert the resulting complex baseband waveform associated with each transmit chain to an RF 25 26 signal according to the center frequency of the desired channel and transmit. Refer to 20.3.7 for 27 details. The transmit chains are connected to antenna elements according to ANTENNA_SET of the 28 TXVECTOR if antenna selection is applied. 29 30 20.3.5 Modulation and Coding Scheme (MCS) 31 32 33 The Modulation and Coding Scheme (MCS) is a value that determines the modulation, coding and number 34 of spatial channels. It is a compact representation that is carried in the HT SIGNAL field. Rate dependent 35 parameters for the full set of modulation and coding schemes (MCS) are shown in 20.6 in Table 20-29 to Ta- 36 ble 20-43. These tables give rate dependent parameters for MCSs with indices 0 through 76. MCSs with in- 37 38 dices 0 to 7 and 32 have a single spatial stream; MCSs with indices 8 to 31 have multiple spatial streams using 39 equal modulation on all the streams (EQM); MCSs with indices 33 to 76 have multiple spatial streams using 40 unequal modulation on the spatial streams (UEQM). MCS indices 77-127 are reserved. 41 42 MCS Table 20-29 to Table 20-32 show rate-dependent parameters for equal-modulation MCSs for one, two, 43 44 three, and four streams for 20 MHz operation. Table 20-33 to Table 20-36 show rate-dependent parameters 45 for equal-modulation MCSs in one, two, three, and four streams for 40 MHz operation. The same equal mod- 46 ulation MCSs are used for 20 MHz and 40 MHz operation. Table 20-37 shows rate-dependent parameters for 47 the 40 MHz, 6 Mb/s MCS 32 format. 48 49 50 The remaining tables, Table 20-38 to Table 20-43, show rate-dependent parameters for the MCSs with un- 51 equal modulation of the spatial streams for use with NSS > 1, including: 52 53 — transmit beamforming 54 — STBC modes for which two spatial streams (NSS=2) are encoded into three space time streams 55 (NSTS=3) and three spatial streams (NSS=3) are encoded into four space time streams (NSTS=4). 56 These STBC mode cases are specified in Table 20-17. 57 58 59 Unequal modulation MCSs are detailed in the following tables: Table 20-38 to Table 20-40 are for 20 MHz 60 operation. Table 20-41 to Table 20-43 are for 40 MHz operation. 61 62 MCS 0 through 15 are mandatory in 20 MHz with 800 ns guard interval at an access point (AP). MCS 0 63 64 through 7 are mandatory in 20 MHz with 800 ns guard interval at all STAs. All other MCSs and modes are 65 optional, specifically including transmit and receive support of 400 ns guard interval, operation in 40 MHz,

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 and support of MCSs with indices 16 through 76. 2 3 20.3.6 Timing related parameters 4 5 6 Table 20-5 defines the timing related parameters. 7 8 9 Table 20-5—Timing related constants 10 11 12 Parameter TXVECTOR CH_BANDWIDTH 13 14 NON_HT_CBW20 HT_CBW_20 HT_CBW40 or 15 NON_HT_CBW40 16 17 HT for- MCS 32 and Non- 18 mat HT duplicate 19 NSD: Number of complex 48 52 108 48 20 data numbers 21 22 NSP: Number of pilot val- 4464 23 ues 24 25 NST: Total Number of sub- 52 56 114 104 26 carriers 27 See NOTE 1 28 29 NSR: The highest data sub- 26 28 58 58 30 carrier index 31 32 F : subcarrier frequency 312.5kHz (20 MHz/64) 312.5kHz 312.5kHz (40 MHz/128) 33 spacing 34 T : IDFT/DFT period 3.2 µs 3.2 µs 3.2 µs 35 DFT 36 TGI: Guard Interval dura- 0.8 µs= TDFT/4 0.8 µs 0.8 µs 37 tion 38 39 TGI2: Double GI 1.6 µs 1.6 µs 1.6 µs 40 41 TGIS: Short Guard Interval N/A 0.4 µs = TDFT/8 0.4 µs 42 duration See NOTE 2 43 44 TL-STF: Non-HT Short 8 µs=10× TDFT/4 8 µs 8 µs 45 training sequence duration 46 THT-GF-STF: HT GF Short N/A 8 µs=10× TDFT/4 8 µs 47 training field duration See NOTE 2 48 49 TL-LTF: Non-HT Long 8 µs=2× TDFT+TGI2 8 µs 8 µs 50 training field duration 51 52 TSYM: Symbol Interval 4 µs= TDFT+TGI 4 µs 4 µs 53 54 TSYMS: Short GI Symbol N/A 3.6 µs = TDFT+TGIS 3.6 µs 55 Interval See NOTE 2 56 57 TL-SIG 4 µs= TSYM 4 µs 4 µs 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table 20-5—Timing related constants (continued) 2 3 4 Parameter TXVECTOR CH_BANDWIDTH 5 6 NON_HT_CBW20 HT_CBW_20 HT_CBW40 or 7 NON_HT_CBW40 8 HT for- MCS 32 and Non- 9 mat HT duplicate 10 11 THT-SIG N/A 8 µs= 2TSYM 8 µs 12 See NOTE 2 13 14 THT-STF: HT-STF duration N/A 4 µs 4 µs 15 See NOTE 2 16 17 THT-LTF1: HT first long N/A 4 µs in HT-mixed 4 µs in HT-mixed format, 8 µs in 18 training field duration format, 8 µs in HT- HT-greenfield format 19 greenfield format See NOTE 2 20 21 THT-LTFs: HT second, and N/A 4 µs 4 µs 22 subsequent, long training See NOTE 2 23 fields duration 24 NOTE 1—N =N +N except in the cases of MCS 32 and Non-HT duplicate, where the number of data subcar- 25 ST SD SP 26 riers differs from the number of complex data numbers, and the number of pilot subcarriers differs from the num- 27 ber of pilot values. In those cases, data numbers and pilot values are replicated in upper and lower 20 MHz 28 portions of 40 MHz signal to make a total of 104 subcarriers. 29 NOTE 2—Not applicable in Non-HT formats 30 NOTE 3—N/A = Not applicable 31 32 33 Table 20-6 defines parameters used frequently in Clause 20. 34 35 36 37 Table 20-6—Frequently used parameters 38 39 40 Symbol Explanation 41 42 NCBPS Number of coded bits per symbol 43 Number of coded bits per symbol per the i-th spatial 44 NCBPSSi 45 stream 46 47 NDBPS Number of data bits per symbol 48 49 NBPSC Number of coded bits per single carrier 50 NBPSCSi Number of coded bits per single carrier for spatial 51 stream i 52 53 NRX Number of receive chains 54 55 NSTS Number of space time streams 56 57 NSS Number of spatial streams 58 59 NESS Number of extension spatial streams 60 N Number of transmit chains 61 TX 62 NES Number of BCC encoders for the Data field 63 64 NLTF Number of HT long training fields (see 20.3.9.4.6) 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table 20-6—Frequently used parameters (continued) 2 3 4 Symbol Explanation 5 6 NDLTF Number of Data HT long training fields 7 8 NELTF Number of Extension HT long training fields 9 10 R Coding rate 11 12 13 20.3.7 Mathematical description of signals 14 15 16 For the description of the convention on mathematical description of signals see 17.3.2.4. 17 18 In the case of either a 20 MHz Non-HT Format (TXVECTOR parameter FORMAT set to NON_HT, MOD- 19 ULATION parameter set to one of {DSSS-OFDM, ERP-OFDM, OFDM}) transmission or a 20 MHz HT For- 20 mat (TXVECTOR parameter FORMAT set to HT_MF or HT_GF, CH_BANDWIDTH set to HT_CBW_20) 21 22 transmission, the channel is divided into 64 sub-carriers. In the 20 MHz Non-HT Format, the signal is trans- 23 mitted on sub-carriers -26 to -1 and 1 to 26, with 0 being the center (DC) carrier. In the 20 MHz HT Format, 24 the signal is transmitted on sub-carriers -28 to -1 and 1 to 28. 25 26 In the case of the 40 MHz HT Format, a 40 MHz channel is used. The channel is divided into 128 sub-carriers. 27 28 The signal is transmitted on sub-carriers -58 to -2 and 2 to 58. 29 30 In the case of 40 MHz HT Upper Format or 40 MHz HT Lower Format, the upper or lower 20 MHz is divided 31 into 64 sub-carriers. The signal is transmitted on sub-carriers -60 to -4 in the case of a 40 MHz HT Lower 32 Format transmission and on sub-carriers 4 to 60 in the case of a 40 MHz HT Upper Format transmission. 33 34 35 In the case of the MCS 32 and Non-HT duplicate formats, the same data are transmitted over two adjacent 20 36 MHz channels. In this case, the 40 MHz channel is divided into 128 sub-carriers and the data are transmitted 37 on sub-carriers -58 to -6 and 6 to 58. 38 39 40 The transmitted signal is described in complex base-band signal notation. The actual transmitted signal is re- 41 lated to the complex baseband signal by the following relation: 42 43 r t = Rertexpj2f t (20-1) 44 RF c 45 46 where 47 48 Re . represents the real part of a complex variable; 49 50 fc is the center frequency of the carrier. 51 52 53 The transmitted RF signal is derived by modulating the complex baseband signal, which consists of several 54 fields. The timing boundaries for the various fields are shown in Figure 20-4. 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 2 3 HT- HT- HT- HT- 4 HT-mixed Format Data Data L-STF L-LTF L-SIG HT-SIG STF LTF1 LTF2 ... LTFn 5 6 7 8 tL-LTF tL-SIG tHT-SIG tHT-STF tHT-LTF tHT-Data 9 10 11 12 HT-greenfield HT-GF-STF HT-LTF1 HT-SIG HT- HT- Data Data 13 Format LTF2 ... LTFn 14 15 16 tHT-LTF1 tHT-SiG tHT-LTFs tHT-Data 17 18 Figure 20-4—Timing boundaries for PPDU fields 19 20 21 The time offset, tField , determines the starting time of the corresponding field. 22 23 24 In HT-mixed format, the signal transmitted on transmit chain iTX shall be 25 26 i i i 27 r TX t = r TX t + r TX tt– (20-2) 28 PPDU L-STF L-LTF L-LTF 29 30 iTX iTX iTX 31 ++rL-SIGtt– L-SIG rHT-SIGtt– HT-SIG +rHT-STFtt– HT-STF 32 33 NLTF 34 iTX iLTF iTX 35 ++ rHT-LTF tt– HT-LTF – iLTF – 1 THT-LTFs rHT-DATAtt– HT-DATA 36 i = 1 37 LTF 38 39 where 40 41 tL-LTF = TL-STF 42 43 tL-SIG = tL-LTF + TL-LTF 44 45 tHT-SIG = tL-SIG + TL-SIG 46 47 t = t + T 48 HT-STF HT-SIG HT-SIG 49 t = t + T 50 HT-LTF HT-STF HT-STF 51 52 tHT-Data = tHT-LTF + NLTF  THT-LTFs 53 54 55 In the case of HT-greenfield format, the transmitted signal on transmit chain iTX shall be: 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 i i i 2 r TX t = r TX t + r TX tt– (20-3) 3 PPDU HT– GF – STF HT– LTF1 HT– LTF1 4 5 iTX 6 + rHT– SIGtt– HT– SIG 7 8 NLTF 9 iTX iLTF 10 +  rHT– LTFtt– HT– LTFs – iLTF – 2 THT– LTFs 11 i = 2 12 LTF

13 iTX 14 + rHT– DATAtt– HT– DATA 15 16 where 17 18 tHT– LTF1 = THT– GF – STF 19 20 t = t + T 21 HT-SIG HT-LTF1 HT-LTF1 22 23 tHT-LTFs = tHT-SIG + THT-SIG 24 25 tHT-Data = tHT-LTFs + NLTF – 1  THT-LTFs 26 27

28 iTX 29 Each baseband waveform, rFieldt , is defined via the discrete Fourier transform per OFDM symbol as 30 31 i i 32 TX 1 TX rFieldt = ------wT t kXk expj2kFt (20-4) 33 Tone Field  N  N k 34 Field TX 35 36 This general representation holds for all fields. A suggested definition of the windowing function, wT t , 37 Field 38 iTX 39 is given in 17.3.2.4. The frequency-domain symbols Xk represent the output of any spatial processing in 40 subcarrier k for transmit chain iTX required for the field. 41 42 43 The function  is used to represent a rotation of the upper tones in a 40 MHz channel: 44 k 45 46 47  1 k  0 in a 40 MHz channel k =  (20-5) 48  jk  0 in a 40 MHz channel 49 50 51  = 1 in a 20 MHz channel (20-6) 52 k 53 54 Tone 55 The 1  NField  NTX scale factor in Equation (20-4) ensures that the total power of the time domain signal as 56 summed over all transmit chains is either 1 or lower than 1 when required. Table 20-7 summarizes the various 57 Tone 58 values of NField . 59 60 61 20.3.8 Transmission in the upper/lower 20 MHz of a 40 MHz channel 62 63 When transmitting in the upper/lower 20 MHz portion of a 40 MHz channel, the mathematical definition of 64 65 transmission shall follow that of a 20 MHz channel with fc in Equation (20-1) replaced byfc  10 MHz .

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

Tone 1 Table 20-7—Value of tone scaling factor NField 2 3 Field Tone 4 NField , see NOTE 1 5 6 20 MHz 40 MHz 7 8 L-STF 12 24 9 10 HT-GF-STF 12 24 11 L-LTF 52 104 12 13 L-SIG 52 104 14 15 HT-SIG 52/56, see NOTE 2 104/114, see NOTE 2 16 17 HT-STF 12 24 18 19 HT-LTF 56 114 20 HT-Data 56 114 21 22 MCS 32, see NOTE 3 - 104 23 Tone 24 NOTE 1—The numbers in the table refer only to the value of NField as it 25 appears in Equation (20-4) and in subsequent specification of various fields. It 26 may be different from the actual number of tones being transmitted. 27 28 NOTE 2—The values 56 and 114 are for HT-greenfield format, 52 and 104 are 29 for HT-mixed format. 30 NOTE 3—This is the Data field in an MCS 32 format PPDU. 31 32 33 34 This applies to 20 MHz HT transmission in the upper/lower 20 MHz of a 40 MHz channel (TXVECTOR 35 primitive CH_BANDWIDTH set to HT_CBW20 and CH_OFFSET primitive set to CH_OFF_20U or 36 CH_OFF_20L), and to 20 MHz non-HT in the upper/lower 20 MHz of a 40 MHz channel (TXVECTOR 37 primitive CH_BANDWIDTH set to NON_HT_CBW20 and CH_OFFSET primitive set to CH_OFF_20U or 38 39 CH_OFF_20L). 40 41 20.3.9 HT preamble 42 43 20.3.9.1 Introduction 44 45 46 The HT preambles are defined in HT-mixed format and in HT-greenfield format to carry the required infor- 47 mation to operate in a system with multiple transmit and multiple receive antennas. 48 49 In the HT-mixed format, to ensure compatibility with non-HT STAs, specific non-HT fields are defined so 50 51 that they can be received by Non-HT STAs compliant with Clause 17 or Clause 19 followed by the fields 52 specific to HT STAs. 53 54 In the HT-greenfield format, all of the non-HT fields are omitted. The specific HT fields used are: 55 56 — One HT GF Short Training field (HT-GF-STF) for automatic gain control convergence, timing 57 acquisition, and coarse frequency acquisition, 58 59 — One or several HT Long Training fields (HT-LTF): provided as a way for the receiver to estimate the 60 channel between each spatial mapper input and receive chain. The first HT-LTFs (Data HT-LTFs) 61 are necessary for demodulation of the HT-Data portion of the PPDU, and are followed, for sounding 62 packets only, by optional HT-LTFs (Extension HT-LTFs) to sound extra spatial dimensions of the 63 MIMO channel, 64 65 — HT SIGNAL field (HT-SIG): provides all the information required to interpret the HT packet format.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 In the case of multiple transmit chains, the HT preambles use cyclic shift techniques to prevent unintentional 2 beamforming. 3 4 5 20.3.9.2 HT-mixed format preamble 6 7 In HT-mixed format frames, the preamble has fields that support compatibility with Clause 17 and Clause 19 8 STAs, and fields that support HT operation. The non-HT portion of the HT-mixed format preamble enables 9 10 detection of the PPDU and acquisition of carrier frequency and timing by both HT STAs and STAs that are 11 compliant with Clause 17 or Clause 19. The non-HT portion of the HT-mixed format preamble contains the 12 SIGNAL (L-SIG) field defined in Clause 17 and is thus decodable by STAs compliant with Clause 17 and 13 Clause 19, as well as HT STAs. 14 15 16 The HT portion of the HT-mixed format preamble enables estimation of the MIMO channel to support de- 17 modulation of the data portion of the frame by HT STAs. The HT portion of the HT-mixed format preamble 18 also contains the HT-SIG field that supports HT operation. 19 20 20.3.9.3 Non-HT portion of the HT-mixed format preamble 21 22 23 20.3.9.3.1 Introduction 24 25 The transmission of the non-HT training fields and the non-HT SIGNAL field as part of an HT-mixed format 26 27 packet is described in 20.3.9.3.2 to 20.3.9.3.5. 28 29 20.3.9.3.2 Cyclic shift definition 30 31 32 The cyclic shift values defined in this subclause apply to the non-HT fields in the HT-mixed format preamble, 33 and the HT-SIG field in the HT-mixed format preamble. 34 35 Cyclic shifts are used to prevent unintentional beamforming when the same signal or scalar multiples of one 36 signal are transmitted through different spatial streams or transmit chains. A cyclic shift of duration T on 37 CS 38 a signal st on interval 0 tT is defined as follows, where T is defined as TDFT as referenced in Table 39 20-5. 40 41 42 With TCS  0 , replace st with st– TCS when 0  tTT + CS , and with st– TCS – T when 43 44 TT+ CS tT. In this case the cyclic shifted signal is defined as 45 46 47  st– TCS 0  tTT + CS 48 s tT; =  (20-7) CS CS T  0 49 CS st– TCS – T TT+ CS tT 50 51 The cyclic shift is applied to each OFDM symbol in the packet separately. Table 20-8 specifies the values for 52 53 the cyclic shifts that are applied in the non-HT short training field (in an HT-mixed format packet), the non- 54 HT long training field, and non-HT SIGNAL field. It also applies to the HT SIGNAL field in an HT-mixed 55 format packet. 56 57 58 With more than four transmit chains, each cyclic shift on the additional transmit chains shall be between -200 59 ns and 0 ns inclusive. 60 61 20.3.9.3.3 Non-HT Short Training field (L-STF) 62 63 64 The L-STF is identical to the Clause 17 short training symbol. The non-HT short training OFDM symbol in 65 the 20 MHz channel width is:

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table 20-8—Cyclic shift for non-HT portion of the packet 2 3 iTX 4 TCS values for the non-HT portion of the packet 5 6 Number of Cyclic shift for Cyclic shift for Cyclic shift for Cyclic shift for 7 transmit Chains transmit chain 1 transmit chain 2 transmit chain 3 transmit chain 4 8 9 1 0ns - - - 10 11 2 0ns -200 ns - - 12 13 3 0ns -100 ns -200 ns - 14 15 4 0ns -50ns -100 ns -150ns 16 17 18 19 S-26,26 = 12 (20-8) 20 001 + j000– 1– j0001+ j000 – 1– j000– 1– j0001+ j000 21 22 0000– 1– j000– 1– j0001+ j0001+ j0001+ j0001+ j00 23 24 25 The normalization factor 12 is the QPSK normalization. 26 27 28 The non-HT short training OFDM symbol in a 40 MHz channel width is given by Equation (20-9), after ro- 29 tating the tones in the upper sub-channel (sub-carriers 6-58) by +90º (see Equation (20-10)). 30 31 32 S-58,58 = 12 33 001 + j000– 1– j0001+ j000 – 1– j000– 1– j0001+ j000 (20-9) 34 0000– 1– j000– 1– j0001+ j0001+ j0001+ j0001+ j00000 35 36 00000000001 + j000– 1– j0001+ j000– 1– j000– 1– j0001+ j 37 0000000– 1– j000– 1– j0001+ j0001+ j0001+ j0001+ j00 38 39 40 In HT-mixed format, the L-STF on transmit chain iTX shall be: 41 42 43 NSR iTX 1 iTX 44 r t = ------w t S expj2k tT– (20-10) LSTF– TLSTF–  k k F CS 45 N  NTone 46 TX LSTF– kN= – SR 47 48 where 49 50 iTX 51 TCS represents the cyclic shift for transmit chain iTX and takes values from Table 20-8. 52 53  is defined in Equation (20-5) and Equation (20-6). 54 k 55 56 57 The L-STF has a period of 0.8 µs. The entire short training field includes ten such periods, with a total dura- 58 tion of TL-STF = 8 µs. 59 60 61 20.3.9.3.4 Non-HT Long Training field 62 63 64 The non-HT long training OFDM symbol is identical to the Clause 17 long training OFDM symbol. In the 20 65 MHz channel width, the long training OFDM symbol is given by:

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 L-26,26 = 11– 1 – 111– 11– 1111111– 1 – 111– 11– 111110 (20-11) 2 111111111111111 –  – – – –  –  –  – – 11111111111–  – – –  3 4 5 The non-HT long training OFDM symbol in a 40 MHz channel width is given by Equation (20-12), after ro- 6 tating the tones in the upper sub-channel (sub-carriers 6-58) by +90º (see Equation (20-13)). 7 8 (20-12) 9 L-58,58 = 11– 1 – 111– 11– 1111111– 1 – 111– 11– 111110 10 111111111111111 –  – – – –  –  –  – – 1111111111100000–  – – –  11 00000011– 1 – 111– 11– 1111111– 1 – 111– 11– 111110 12 13 11111111111111111111111111 –  – – – –  –  –  –  – –  – – –  14 15 The sub-carriers at ±32 in 40 MHz, which are the DC sub-carriers for the non-HT 20 MHz transmission, are 16 both nulled in the L-LTF. Such an arrangement allows proper synchronization of a 20 MHz non-HT STA. 17 18 19 The L-LTF waveform shall be: 20

21 NSR 22 iTX 1 iTX rLLTF– t = ------wT t kLk expj2kFtT– GI2 – TCS (20-13) 23 Tone LLTF–  24 N  N TX LLTF– kN= – SR 25 26 27 where 28 29 TGI2 is 1.6 s 30 i 31 T TX represents the cyclic shift for transmit chain i and takes values specified in Table 20-8. 32 CS TX 33 34 k is defined in Equation (20-5) and Equation (20-6). 35 36 The entire long training field includes two 3.2 µs IDFT/DFT periods and an additional 1.6 µs double guard 37 38 interval. The entire long training field is modulated with the L-LTF waveform. 39 40 20.3.9.3.5 The Non-HT SIGNAL field 41 42 43 The Non-HT SIGNAL field is used to communicate rate and length information.The structure of the Non-HT 44 SIGNAL field is shown in Figure 20-5. 45 46 47 Rate Length Tail 48 (4 bits) (12 bits) (6 bits) 49 R P 50 51 R1 R2 R3 R4 “0” “0” “0” “0” “0” “0” 52 53 01234567891011121314151617181920212223 54 55 Figure 20-5—Non-HT SIGNAL field 56 57 58 The value in the Rate field is obtained from the L_DATARATE field of the TXVECTOR. The value in the 59 Length field is obtained from the L_LENGTH field of the TXVECTOR. The length field is transmitted least 60 significant bit (LSB) first. 61 62 The reserved bit shall be set to 0. 63 64 65 The parity field has the even parity of bits 0-16.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 The Non-HT SIGNAL field shall be encoded, interleaved and mapped, and have pilots inserted following the 2 steps described in 17.3.5.5, 17.3.5.6, and 17.3.5.8. The stream of 48 complex numbers generated by the steps 3 4 described in 17.3.5.6 is denoted by dk k = 047 . The time domain waveform of the Non-HT SIGNAL 5 field in 20 MHz transmission shall be as given by: 6 7 8 26 i i 9 TX 1 TX rLSIG– t = ------wT t Dk + p0Pk expj2kFtT– GI – TCS (20-14) 10 Tone SYM  N  N 11 TX LSIG– k = –26 12 13 In a 40 MHz transmission the time domain waveform of the Non-HT SIGNAL field shall be as given by: 14 15 16 26 17 iTX 1 rLSIG– t = ------wT t Dk + p0Pk (20-15) 18 Tone SYM  19 NTX  NLSIG– k = –26 20 i i 21 TX TX  expj2k – 32 FtT– GI – TCS + jjexp2k + 32 FtT– GI – TCS 22 23 24 25 where 26 27  28  0 k = 0721    D =  29 k d  otherwise  Mrk 30  31 32 33  34  k + 26 – 26 k –22  35 k + 25 – 20 k –8 36  r  k + 24 – 6 k –1 37 M k =  38  k + 23 1 k 6 39  40  k + 22 8 k 20 41  k + 21 22 k 26 42  43 44 Pk is defined in 17.3.5.9 45 46 p is the first pilot value in the sequence defined in 17.3.5.9 47 0 48 Tone 49 NLSIG– has the value given in Table 20-7 50

51 iTX 52 TCS represents the cyclic shift for transmit chain iTX and is defined by Table 20-8 for HT-mixed 53 format PPDUs 54 r 55 NOTE— Dk exists for –NSR kNSR and takes the values from dk that exists for 0 kNSD – 1 . M k is a 56 "reverse" function of the function Mk defined in 17.3.5.9. 57 58 59 20.3.9.4 The HT portion of the HT-mixed format preamble 60 61 20.3.9.4.1 Introduction 62 63 64 When an HT-mixed format preamble is transmitted, the high throughput preamble consists of the HT short 65 training field, the HT long training fields and the HT SIGNAL field.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 20.3.9.4.2 Cyclic shift definition 2 3 The cyclic shift values defined in this subclause apply to the HT-STF and the HT-LTF portions of the HT 4 5 portion of the HT-mixed format preamble. The cyclic shift values defined in 20.3.9.3.2 apply to the HT-SIG 6 in an HT-mixed format preamble. 7 8 Throughout the HT portion of an HT-mixed format preamble, cyclic shift is applied to prevent beamforming 9 when similar signals are transmitted in different space time streams. The same cyclic shift is applied to these 10 11 streams during the transmission of the data portion of the frame. The values of the cyclic shifts to be used 12 during the HT portion of the HT-mixed format preamble (with the exception of the HT_SIG) and the data 13 portion of the frame are specified in Table 20-9. 14 15 16 Table 20-9—Cyclic shift values of the HT portion of the packet 17 18 i 19 T STS values for HT portion of the packet 20 CS 21 Cyclic shift for Cyclic shift for Cyclic shift for Cyclic shift for 22 Number of space space time stream space time stream space time stream space time stream 23 time streams 24 1 2 3 4 25 26 1 0ns - - - 27 2 0ns -400 ns - - 28 29 3 0ns -400 ns -200 ns - 30 31 4 0ns -400 ns -200 ns -600 ns 32 33 34 35 20.3.9.4.3 The HT SIGNAL field 36 37 The HT SIGNAL field is used to carry information required to interpret the HT packet formats. The fields of 38 the HT SIGNAL field are described in Table 20-10. 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table 20-10—Fields of the HT SIGNAL field 2 3 4 Number Field Name Explanation and coding 5 of bits 6 7 Modulation and 7 Index into the MCS table, 8 Coding Scheme See NOTE 1. 9 10 CBW 20/40 1 Set to 0 for 20 MHz or 40 MHz upper/lower 11 Set to 1 for 40 MHz 12 13 HT Length 16 The number of octets of data in the PSDU in the range 0-65535 14 See NOTE 1 and NOTE 2. 15 Smoothing 1 Set to 1 indicates that channel estimate smoothing is recommended 16 Set to 0 indicates that only per-carrier independent (unsmoothed) channel esti- 17 mate is recommended 18 See 20.3.11.10.1 19 20 Not Sounding 1 Set to 0 indicates that PPDU is a sounding PPDU 21 Set to 1 indicates that the PPDU is not a sounding PPDU 22 23 Reserved 1 Set to 1 24 25 Aggregation 1 Set to 1 to indicate that the PPDU in the data portion of the packet contains an A- 26 MPDU; otherwise, set to 0. 27 28 STBC 2 Set to a non-zero number, to indicate the difference between the number of space 29 time streams (NSTS ) and the number of spatial streams (NSS ) indicated by the 30 MCS. 31 Set to 00 to indicate no STBC (NSTS = NSS ) 32 See NOTE 1. 33 34 FEC coding 1 Set to 1 for LDPC 35 Set to 0 for BCC 36 37 Short GI 1 Set to 1 to indicate that the short GI is used after the HT training. 38 Set to 0 otherwise 39 40 Number of exten- 2 Indicates the Number of extension spatial streams (NESS ). 41 sion spatial streams Set to 0 for no extension spatial stream 42 Set to 1 for 1 extension spatial stream 43 Set to 2 for 2 extension spatial streams 44 Set to 3 for 3 extension spatial streams 45 See NOTE 1 46 47 CRC 8 CRC of bits 0-23 in HT-SIG1 and bits 0-9 in HT-SIG2—see 20.3.9.4.4. The first 48 bit to be transmitted is bit C7 as explained in 20.3.9.4.4. 49 Tail Bits 6 Used to terminate the trellis of the convolution coder. Set to 0. 50 51 NOTE 1—Integer fields are transmitted in unsigned binary format, least significant bit first. 52 NOTE 2—A value of 0 in the HT Length field indicates a PPDU that does not include a data field, i.e., NDP. NDP 53 transmissions are used for sounding purposes only (see 9.21.2). The packet ends after the last HT-LTF or the HT-SIG. 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 The structure of the HT-SIG1 and HT-SIG2 fields is defined in Figure 20-6. 2 3 4 5 6 7 8 Modulation and Coding 9 HT Length 10 Scheme 11 LSB MSB LSB MSB 12 13 012345678910 11 12 13 14 15 16 17 18 19 20 21 22 23 14 15 HT-SIG 16 1 17 18 19 20 21 22 23 24 25 26 27 28 CRC Tail Bits 29 30 31 C7 C0 STBC FEC CODING GISHORT Number of Extension Spatial Streams 20/40 CBW Smoothing Sounding Not Reserved Aggregation 32 012345678910 11 12 13 14 15 16 17 18 19 20 21 22 23 33 34

35 HT-SIG2 36 LSB LSB 37 38 39 Figure 20-6—Format of HT-SIG and HT-SIG 40 1 2 41 42 43 The HT-SIG is composed of two parts, HT-SIG1 and HT-SIG2, each containing 24 bits, as shown in Figure 44 45 20-6. All the fields in the HT-SIG are transmitted LSB first, and HT-SIG1 is transmitted before HT-SIG2. 46 47 The HT-SIG parts shall be encoded at R = 1/2, interleaved, mapped to a BPSK constellation, and have pilots 48 49 inserted following the steps described in 17.3.5.5, 17.3.5.6, 17.3.5.7, and 17.3.5.8, respectively. The BPSK 50 constellation is rotated by 90° relative to the non-HT SIGNAL field in order to accommodate detection of the 51 start of the HT SIGNAL field. The stream of 96 complex numbers generated by these steps is divided into 52 two groups of 48 complex numbers: d  0 k 47 n = 01 . The time domain waveform for the HT SIG- 53 kn 54 NAL field in an HT-mixed format packet in a 20 MHz transmission shall be: 55 56 57 1 58 iTX 1 rHT– SIGt = ------wT tnT– SYM (20-16) 59 Tone  SYM 60 NTX  NHT– SIG n = 0 61 62 26 i 63 TX  jDkn + pn + 1Pk expj2kFtnT– SYM – TGI – TCS 64  65 k = –26

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 For a 40 MHz transmission the time domain waveform shall be: 2 3 4 1 i 5 TX 1 rHT– SIGt = ------wT tnT– SYM (20-17) 6 Tone  SYM 7 NTX  NHT– SIG n = 0 8 26 9 iTX 10   jDkn + pn + 1Pk  expj2k – 32 FtnT– SYM–TGI–TCS 11 k = –26 12 13 iTX 14 + jjexp2k + 32 FtnT– SYM – TGI – TCS  15 16 17 where 18 19 20  21  0 k = 0721    Dkn =  22 d r  otherwise  M k  n 23  24 25 r 26 M k is defined in 20.3.9.3 27 28 Pk and pn are defined in 17.3.5.9 29 30 Tone 31 NHT– SIG has the value given in Table 20-7 32 i 33 T TX represents the cyclic shift for transmit chain i and is defined by Table 20-8 for HT-mixed 34 CS TX 35 format PPDUs. 36 NOTE—This definition results in a QBPSK modulation in which the constellation of the data tones is rotated by 90º rel- 37 ative to the non-HT SIGNAL field in HT-mixed format PPDUs, and relative to the first HT-LTF in HT-greenfield for- 38 mat PPDUs (see Figure 20-7). In HT-mixed format PPDUs, the HT SIGNAL field is transmitted with the same number 39 of subcarriers and the same cyclic shifts as the preceding non-HT portion of the preamble. This is done to accommodate 40 the estimation of channel parameters needed to robustly demodulate and decode the information contained in the HT 41 SIGNAL field. 42 43 44 45 L-SIGQ HT-SIG Q 46 47 +1 +1 1 48 49 50 0 1 51 II 52 -1 -1 53 +1 +1 54 55 -1 -1 0 56 57 58 59 Figure 20-7—Data tone constellations in an HT-mixed format PPDU 60 61 20.3.9.4.4 CRC calculation for the HT SIGNAL field 62 63 The CRC protects bits 0-33 of the HT-SIG (bits 0-23 of HT-SIG and bits 0-9 of HT-SIG ). The value of the 64 1 2 65 CRC field shall be the ones complement of

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 8 2 crc D = MD IDD modulo G D (20-18) 3 4 where 5 6 33 32 MD= m0D ++++m1D  m32Dm33 is the HT-SIG represented as a polynomial 7 8 9 where 10 11 m0 is bit 0 of HT-SIG1 and m33 is bit 9 of HT-SIG2 12 13 33 14 ID= Di are initialization values that are added modulo 2 to the first 8 bits of HT-SIG 15  1 16 i = 26 17 8 2 18 GD= D +++D D 1 is the CRC generating polynomial 19 20 crc D = c D7 ++++c D6  c Dc 21 0 1 6 7 22 23 The CRC field is transmitted with c7 first. 24 25 26 m33 27 to The feedback term is set to 0 28 during the shifting out of the result. m0 29 0 30 Serial c c c c c c c c 31 Input 7 6 5 4 3 2 1 0 32 33 34 Serial Output 35 C7 First 36 37 Figure 20-8—HT-SIG CRC calculation 38 39 40 Figure 20-8 shows the operation of the CRC. First, the shift register is reset to all ones. The bits are then 41 passed through the exclusive-or operation (XOR) at the input. When the last bit has entered, the output is gen- 42 erated by shifting the bits out of the shift register, C7 first, through an inverter. 43 44 45 As an example, if bits m0m33 are given by: {1 1 1 1 0 0 0 1 0 0 1 0 0 1 1 0 0 0 0 0 0 0 0 0 1 1 1 0 0 0 0 0 0 0}, the 46 CRC bits c c are {1 0 1 0 1 0 0 0}. 47 7 0 48 49 20.3.9.4.5 The HT short training field 50 51 52 The purpose of the HT-STF training field is to improve automatic gain control estimation in a MIMO system. 53 The duration of the HT-STF is 4 µs; the frequency sequence used to construct the HT-STF in 20 MHz trans- 54 mission is identical to L-STF; in 40 MHz transmission, the HT-STF is constructed from the 20 MHz version 55 by duplicating and frequency shifting, and rotating the upper sub-carriers by 90°. The frequency sequences 56 are shown in Equation (20-19) and Equation (20-20). 57 58 59 For 20 MHz: 60 61 (20-19) 62 HTS-28,28 = 12 63 00001 + j000– 1– j0001+ j000 – 1– j000– 1– j0001+ j000 64 65 0000– 1– j000– 1– j0001+ j0001+ j0001+ j0001+ j0000

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 For 40 MHz: 2 3 4 HTS-58,58 = 12 (20-20) 5 001 + j000– 1– j0001+ j000 – 1– j000– 1– j0001+ j000 6 0000– 1– j000– 1– j0001+ j0001+ j0001+ j0001+ j00000 7 8 00000000001 + j000– 1– j0001+ j000– 1– j000– 1– j0001+ j 9 0000000– 1– j000– 1– j0001+ j0001+ j0001+ j0001+ j00 10 11 12 The time domain representation of the transmission in transmit chain iTX shall be: 13 14 15 iTX 1 16 r t = ------w t (20-21) HT– STF THT– STF 17 Tone NSTS  NHT– STF 18 19 N N 20 SR STS i 21 Q  HTS expj2k tT– STS   k iTX iSTS k k F CS 22 kN= – i = 1 23 SR STS 24 25 26 where 27 i 28 T STS represents the cyclic shift for the space time stream i and takes the values given in Table 29 CS STS 30 20-9. 31 32 Qk is defined in 20.3.11.10.1. 33 34 k is defined in Equation (20-5) and Equation (20-6). 35 36 37 20.3.9.4.6 The HT long training field 38 39 The HT long training field provides a means for the receiver to estimate the MIMO channel between the set 40 of QAM mapper outputs (or, if STBC is applied, the STBC encoder outputs) and the receive chains. If the 41 42 transmitter is providing training for exactly the space time streams (spatial mapper inputs) used for the trans- 43 mission of the PSDU, the number of training symbols, NLTF , is equal to the number of space time streams, 44 45 NSTS , except that for three space time streams, four training symbols are required. If the transmitter is pro- 46 viding training for more space time streams (spatial mapper inputs) than the number used for the transmission 47 of the PSDU, the number of training symbols is greater than the number of space time streams. This latter 48 49 case happens in a sounding PPDU. 50 51 The HT long training field portion has one or two parts. The first part consists of one, two, or four HT long 52 training fields that are necessary for demodulation of the HT-Data portion of the PPDU. These HT-LTFs are 53 referred to as Data HT-LTFs. The optional second part consists of zero, one, two, or four HT-LTFs that may 54 55 be used to sound extra spatial dimensions of the multiple-input multiple-output channel that are not utilized 56 by the HT-Data portion of the PPDU. These HT-LTFs are referred to as Extension HT-LTFs. If a receiver has 57 not advertised its ability to receive Extension HT-LTFs, it shall either issue a PHY-RXEND.indicate(Unsup- 58 portedRate) primitive upon reception of a frame that includes Extension HT-LTFs, or decode that frame. 59 (When an HT packet includes one or more extension HT-LTFs, it is optional for a receiver that has not ad- 60 61 vertised its capability to receive Extension HT-LTFs to decode the data portion of the PPDU.) 62 63 The number of Data HT-LTFs is denoted N . The number of extension HT-LTFs is denoted N . The 64 DLTF ELTF 65 total number of HT-LTFs is:

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 N = N + N (20-22) 2 LTF DLTF ELTF 3 4 NLTF shall not exceed 5. Table 20-11 shows the determination of the number of space time streams from the 5 MCS and STBC fields in the HT-SIG. Table 20-12 shows the number of Data HT-LTFs as a function of the 6 7 number of space time streams (NSTS ). Table 20-13 shows the number of extension HT-LTFs as a function of 8 the number of extension spatial streams (N ). N plus N is less than or equal to 4. In the case where 9 ESS STS ESS 10 NSTS equals 3, NESS cannot exceed one; if NESS equals one in this case then NLTF equals 5. 11 12 13 14 Table 20-11—Determining the number of space time streams 15 16 17 Number of Spatial Number of space 18 Streams (from MCS) STBC field time streams 19 NSS NSTS 20 21 101 22 23 112 24 25 202 26 27 213 28 224 29 30 303 31 32 314 33 34 404 35 36 37 Table 20-12—Number of DLTFs required for data space-time streams 38 39 40 N N 41 STS DLTF 42 11 43 44 22 45 46 34 47 48 44 49 50 51 Table 20-13—Number of ELTFs required for extension spatial streams 52 53 54 N N 55 ESS ELTF 56 00 57 58 11 59 60 22 61 62 34 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 The following HT-LTF sequence is transmitted in the case of 20 MHz operation: 2 3 4 5 HTLTF-28,28 = 1111– 1 – 111– 11– 1111111– 1 – 111– 11– 111110 6 111111111111111 –  – – – –  –  –  – – 1111111111111–  – – – –  –  7 (20-23) 8 9 NOTE—This sequence is an extension of the non-HT LTF where the 4 extra sub-carriers are filled with +1 for negative 10 frequencies and -1 for positive frequencies. 11 12 13 In 40 MHz transmissions, including MCS 32 format frames, the sequence to be transmitted is: 14 15 HTLTF-58,58 = 11– 1 – 111– 11– 1111111– 1 – 111– 11– 111111 16 111111111111111 –  – – – –  –  –  – – 111111111111–  – – – –1 –1 –10  17 18 00–111 1 –111111111111111111111111111–  – – – –  – – –  19 11111111111111111111111111 –  – – – –  –  –  –  – –  – – –  (20-24) 20 21 NOTE—This sequence is also constructed by extending the non-HT LTF in the following way: first, the non-HT LTF is 22 duplicated and shifted as explained in 20.3.9.3.4 for the non-HT duplicate format; then the missing sub-carriers, [-32, -5, 23 -4, -3, -2, 2, 3, 4, 5, 32], are filled with the values [1, -1, -1, -1, 1, -1, 1, 1, -1, 1] respectively. 24 25 This sequence, occupying 114 tones, is used even if the data portion is transmitted with MCS 32 format, 26 27 which uses 104 tones. 28 29 NOTE—This sequence uses 114 tones when MCS 32 format is used to retain consistency with other 40 MHz formats 30 and to facilitate channel estimation for beam forming and link adaptation. 31 32 33 In an HT-mixed format preamble, each HT-LTF consists of a single occurrence of the sequence plus a GI 34 insertion, and has a duration of 4 µs. In case of multiple space time streams, cyclic shift is invoked as specified 35 in Table 20-9. 36 37 The generation of Data HT-LTFs is shown in Figure 20-9. The generation of Extension HT-LTFs is shown 38 39 in Figure 20-10. In these figures, and in the following text, the following notational conventions are used: 40 41 —X mn indicates the element in row m and column n of matrix X 42 43 —X indicates a matrix consisting of the first N columns of matrix X 44 N 45 46 —X M:N indicates a matrix consisting of columns M through N of matrix X 47 48 where 49 50 MN 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 X is either Q or P 2 k HTLTF 3 4 P 5  HTLTF 1,n 6 7 HTLTFk x 8 IFFT 9 10 11 12 CSD Qk  NSTS 13 14 15 16 IFFT 17 x 18 19 PHTLTF  20 NnSTS , 21 22 Figure 20-9—Generation of Data HT-LTFs 23 24 25 26 PHTLTF  27 1,nN DLTF 28 HTLTF 29 k x 30 IFFT 31 32 Q 33  k NNN1: 34 CSD STS STS ESS 35 36 37 IFFT 38 39 x 40 PHTLTF  41 NnNESS,  DLTF 42 43 Figure 20-10—Generation of the Extension HT-LTFs 44 45 46 47 The mapping between space time streams and transmit chains is defined by the columns of an antenna map 48 matrix Q for subcarrier k. The first N columns define the space time streams used for data transmission, 49 k STS 50 and the next NESS columns (up to NTX – NSTS columns) define the extension spatial streams. Thus, for the 51 52 purpose of defining HT-LTFs, Qk is an NTX  NSTS + NESS dimension matrix. Columns 1NSTS of Qk 53 are excited by the Data HT-LTFs, and columns N ++1N N are excited by the Extension HT- 54 STS STS ESS 55 LTFs, where NSTS + NESS  NTX is the total number of spatial streams being probed by the HT-LTFs. 56 57 58 Possible forms of Q , and other limitations on Q are specified in 20.3.11.10.1. P is defined in Equa- 59 k k HTLTF 60 tion (20-27)). 61 62 63 The time domain representation of the waveform transmitted on transmit chain iTX during Data HT-LTF 64 65 n 1 nNDLTF shall be:

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 ni 2  TX 1 rHT– LTFt = ------wT t (20-25) 3 Tone HT– LTFs 4 NSTS  NHT– LTF 5 6 NSR NSTS 7 iSTS  Qk PHTLTF kHTLTFk expj2kFtT– GI – TCS 8   iTX iSTS iSTS n

9 kN= – SR iSTS = 1 10 11 12 For the extension HT-LTFs NDLTF  nN LTF , it shall be: 13 14 15 ni TX 1 16 r t = ------w t (20-26) HT– LTF THT– LTFs 17 NTone  N 18 HT– LTF ESS 19 20 NSR NESS 21   Qk PHTLTF kHTLTFk 22    iTX NSTS + iESS iESS nN– DLTF 23 kN= – SR iESS = 1 24 25 26 i  expj2k tT– – T ESS  27 F GI CS  28 29 30 where 31 iSTS 32 TCS cyclic shift values are given in Table 20-9 33

34 iESS 35 TCS cyclic shift values are given in Table 20-9 with iESS = iSTS 36 37 Qk is defined in 20.3.11.10.1 38 39 k is defined in Equation (20-5) and Equation (20-6) 40 41 P the HT-LTF mapping matrix, is given by: 42 HTLTF 43 44 45 11–11 46 11–1 1 47 PHTLTF = (20-27) 48 111– 1 49 –1111 50 51 52 20.3.9.5 HT-greenfield format preamble 53 54 For HT-greenfield operation, compatibility with Clause 17 and Clause 19 STAs is not required. Therefore, 55 the portions of the preamble that are compatible with Clause 17 and Clause 19 STAs are not included. The 56 result is a shorter and more efficient PLCP frame format that includes a short training field, long training 57 58 field(s), and an HT SIGNAL field. 59 60 20.3.9.5.1 Cyclic shift definition for HT-greenfield format preamble 61 62 Throughout the HT-greenfield format preamble, cyclic shift is applied to prevent beamforming when similar 63 64 signals are transmitted on different spatial streams. The same cyclic shift is applied to these streams during 65 the transmission of the data portion of the frame. The values of the cyclic shift to be used during the HT-green-

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 field format preamble, as well as the data portion of the HT-greenfield format frame, are specified in Table 2 20-9. 3 4 5 20.3.9.5.2 HT-greenfield format Short Training field (HT-GF-STF) 6 7 The HT-greenfield format short training field (HT-GF-STF) is placed at the beginning of an HT-greenfield 8 format frame. The time domain waveform for the HT-GF-STF on transmit chain i shall be: 9 TX 10 11 12 iTX 1 rHT– GF – STFt = ------wT t 13 Tone HT– GF – STF 14 NSTS  NHT– GF – STF 15 (20-28) N N 16 SR STS i 17 STS  Qk i i PHTLTF i 1kSk expj2kFtT– CS 18   TX STS STS 19 kN= – SR iSTS = 1 20 21 where 22

23 iSTS 24 TCS represents the cyclic shift for the space time stream iSTS and takes values from Table 20-9 25 26 Qk is defined in 20.3.11.10.1 27 28 PHTLTF is defined in Equation (20-27) 29 30 Sk is defined in Non-HT Short Training field (L-STF), Equation (20-8) for 20 MHz operation and 31 32 Equation (20-9) for 40 MHz operation 33 34 k is defined in Equation (20-5) and Equation (20-6) 35 36 The waveform defined by Equation (20-28) has a period of 0.8 µs, and the HT-GF-STF includes ten such pe- 37 38 riods, with a total duration of THT– GF – STF = 8 µs. 39 40 20.3.9.5.3 HT-greenfield format SIGNAL field 41 42 43 The content and format of the HT SIGNAL field of an HT-greenfield format frame is identical to the HT SIG- 44 NAL field in an HT-mixed format frame, as described in 20.3.9.4.3. The placement of the HT SIGNAL field 45 in an HT-greenfield format frame is shown in Figure 20-1. In HT-greenfield format frames, the HT SIGNAL 46 field is transmitted with the same cyclic shifts, and the same spatial mapping as the preceding portions of the 47 48 preamble. This is done to accommodate the estimation of channel parameters needed to robustly demodulate 49 and decode the information contained in the HT SIGNAL field. 50 51 The time domain waveform for the signal field on transmit chain i with 20 MHz operation shall be: 52 TX 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 2 1 3 iTX 1 rHT– SIGt = ------wT tnT– SYM (20-29) 4 Tone  SYM 5 NSTS  NHT– SIG n = 0 6 7 26 NSTS 8  Qk PHTLTF jDkn + pnPk 9   iTX iSTS iSTS 1 10 k = –26 iSTS = 1 11 12 i 13  expj2k tnT– – T – T STS 14 F SYM GI CS 15 16 where 17 18 P and p are defined in 17.3.5.9 19 k n 20 21 Dkn is defined in 20.3.9.4.3 22 i 23 T STS represents the cyclic shift for space time stream i and takes values from Table 20-9 24 CS STS 25 26 Qk is defined in 20.3.11.10.1 27 28 PHTLTF is defined in Equation (20-27) 29 30 31 The time domain waveform for the signal field on transmit chain iTX with 40 MHz operation shall be: 32 33 34 1 35 iTX 1 rHT– SIGt = ------wT tnT– SYM (20-30) 36 Tone  SYM 37 NSTS  NHT– SIG n = 0 38 N 39 26 STS 40  PHTLTF i 1jDkn + pnPk 41   STS 42 k = –26 iSTS = 1 43 44 iSTS 45  Qk – 32 i  i expj2k – 32 FtnT– SYM – TGI – TCS 46 TX STS 47 48 49 iSTS + jQexpj2k + 32 tnT– – T – T  50 k + 32 iTX iSTS F SYM GI CS 51 52 53 where 54 55 pn and Pk are defined in 17.3.5.9 56 57 D is defined in 20.3.9.4.3 58 kn 59 iSTS 60 TCS represents the cyclic shift for space time stream iSTS and takes values from Table 20-9 61 62 Q is defined in 20.3.11.10.1 63 k 64 65 PHTLTF is defined in Equation (20-27)

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 20.3.9.5.4 HT-greenfield format Long Training field 2 3 The format of the long training field portion of the preamble in an HT-greenfield format frame is similar to 4 5 that of the HT long training field in an HT-mixed format frame, as described in 20.3.9.4.6, with the difference 6 being the first HT-LTF (HT-LTF1), which is twice as long (8 s) as the other HT-LTFs. The time domain 7 waveform for the long training symbol on transmit chain iTX for the first HT-LTF in an HT-greenfield format 8 frame shall be 9 10

11 1 iTX 1 12 rHT– LTFt = ------wT t (20-31) Tone HT– LTF1 13 NSTS  NHT– LTF 14

15 NSR NSTS 16 i  Q P  HTLTF k expj2k tT– – T STS 17   k iTX iSTS HTLTF iSTS 1 k F GI2 CS

18 kN= – SR iSTS = 1 19 20 21 where 22 iSTS 23 TCS represents the cyclic shift for space time stream iSTS and takes values from Table 20-9 24 25 Q is defined in 20.3.11.10.1 26 k 27 P is defined in Equation (20-27) 28 HTLTF 29 30 The first HT-LTF (HT-LTF1) consists of two periods of the long training symbol, preceded by a double- 31 length (1.6 s) cyclic prefix. The placement of the first and subsequent HT-LTFs in an HT-greenfield format 32 33 frame is shown in Figure 20-1. 34 35 20.3.10 Transmission of NON_HT format PPDUs with more than one antenna 36 37 When an HT device transmits a NON_HT format PPDU with MODULATION parameter set to OFDM or 38 39 ERP-OFDM using more than one transmit chain, it shall apply the cyclic shifts defined in Table 20-8 to the 40 transmission in each chain. 41 42 20.3.11 The Data field 43 44 45 When BCC encoding is used, the Data field consists of the 16-bit SERVICE field, the PSDU, either six or 46 twelve tail bits, depending on whether there are one or two encoding streams, and pad bits. When LDPC en- 47 coding is used, the Data field consists of the 16-bit SERVICE field and the PSDU, processed by the procedure 48 in 20.3.11.6.5. 49 50 51 The number of OFDM symbols in the data field when BCC encoding is used is computed using the formula: 52 53 8  length ++16 6  NES 54 NSYM = mSTBC ------(20-32) 55 mSTBC  NDBPS 56 57 where 58 59 m is 2 if STBC is used and 1 otherwise (making sure that the number of symbols is even when 60 STBC 61 STBC is used) 62 63 length is the value of the HT Length field in the HT-SIG field defined in Table 20-10 64 65 NDBPS can take the values defined in Table 20-29 through Table 20-43

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 x denotes the smallest integer greater than or equal to x 2 3 4 The number of “zero” pad bits is thus NSYM · NDBPS - 8 · length - 16 - 6 · NES. The number of symbols in the 5 data field when LDPC encoding is used is described in 20.3.11.6. 6 7 8 For LDPC encoding, the number of encoded data bits, N , is given by Equation (20-39), the number of 9 avbits 10 OFDM symbols, NSYM , is given by Equation (20-41), and the number of repeated encoded bits for padding, 11 12 Nrep , is given by Equation (20-42), in 20.3.11.6.5. 13 14 15 20.3.11.1 The SERVICE field 16 17 The SERVICE field is used for scrambler initialization. The service field is composed of 16 bits, all set to 18 19 zero before scrambling. In non-HT PPDUs the service field is the same as in 17.3.5.1. In HT PPDUs, the ser- 20 vice field is composed of 16 zero bits, scrambled by the scrambler, as defined in 20.3.11.2. 21 22 23 20.3.11.2 Scrambler 24 25 The data field shall be scrambled by the scrambler defined in 17.3.5.4, initialized with a pseudo-random non- 26 27 zero seed. 28 29 20.3.11.3 Coding 30 31 32 The Data field shall be encoded using either the binary convolutional code (BCC) defined in 17.3.5.5, or the 33 low density parity check (LDPC) code defined in 20.3.11.6. The encoder is selected by the FEC coding field 34 in the High Throughput Signal field, as described in 20.3.9.4.3. A single FEC encoder is always used when 35 36 LDPC coding is used. When the BCC FEC encoder is used, a single encoder is used, except that two encoders 37 shall be used when the selected MCS has a PHY rate greater than 300 Mb/s. For the purposes of determining 38 whether to use one or two BCC FEC encoders, the rate is calculated based on the use of an 800 ns GI. The 39 operation of the BCC FEC is described in 20.3.11.5. The operation of the LDPC coder is described in 40 20.3.11.6. 41 42 43 Support for the reception of BCC-encoded Data field frames is mandatory. 44 45 46 20.3.11.4 Encoder parsing operation for two BCC FEC encoders 47 48 49 If two BCC encoders are used, the scrambled data bits are divided between the encoders by sending alternat- (j) 50 ing bits to different encoders. Bit with index i sent to the encoder j, denoted xi , is: 51 52 53 xj =;0b jN– 1 (20-33) 54 i NES  ij+ ES 55 56 Following the parsing operation, 6 scrambled “zero” bits following the end of the message bits in each BCC 57 58 input sequence are replaced by unscrambled “zero” bits, as described in 17.3.5.2. 59 60 The replaced bits are: 61 62 63 j length  8 + 16 length  8 + 16 x :0jN– 1 ; ------i ------+ 5 (20-34) 64 i ES N 65 ES NES

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 20.3.11.5 Binary convolutional coding and puncturing 2 3 0 1 4 When BCC encoding is used, the encoder parser output sequences {xi }, and {xi } where applicable, are 5 each encoded by the rate-½ convolutional encoder defined in 17.3.5.5. After encoding, the encoded data shall 6 be punctured by the method defined in 17.3.5.6 to achieve the rate selected by the modulation and coding 7 8 scheme. 9 10 In the case that rate 5/6 coding is selected, the puncturing scheme is defined in Figure 20-11. 11 12 13 Source Data 14 X0 X1 X2 X3 X4 15 16 17 18 19 Encoded data 20 A0 A1 A2 A3 A4 21 22 B0 B1 B2 B3 B4 23 24 25 26 27

28 Bit Stolen data A0 B0 A1 B2 A3 B4 29 30 31 32 33

34 A0 A1 A2 A3 A4 35 Bit inserted data 36 37 B0 B1 B2 B3 B4 38 39 40 41 42 Decoded data Y Y Y Y Y 43 0 1 2 3 4 44 45 Figure 20-11—Puncturing at rate 5/6 46 47 48 20.3.11.6 Low density parity check (LDPC) codes 49 50 20.3.11.6.1 Introduction 51 52 53 HT LDPC codes are described in 20.3.11.6.2 to 20.3.11.6.6. These codes are optionally used in the HT system 54 as a high-performance error correcting code, instead of the convolutional code (20.3.11.5). The LDPC encod- 55 er shall use the rate-dependent parameters in Table 20-29 to Table 20-43, with the exception of the NES pa- 56 rameter. 57 58 59 Support for LDPC codes is optional. 60 61 20.3.11.6.2 LDPC coding rates and codeword block lengths 62 63 64 The supported coding rates, information block lengths, and codeword block lengths are described in Table 65 20-14.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table 20-14—LDPC parameters 2 3 4 Coding rate LDPC information block length LDPC codeword block length 5 (R) (bits) (bits) 6 7 1/2 972 1944 8 9 1/2 648 1296 10 11 1/2 324 648 12 2/3 1296 1944 13 14 2/3 864 1296 15 16 2/3 432 648 17 18 3/4 1458 1944 19 20 3/4 972 1296 21 3/4 486 648 22 23 5/6 1620 1944 24 25 5/6 1080 1296 26 27 5/6 540 648 28 29 30 20.3.11.6.3 LDPC encoder 31 32 33 For each of the three available codeword block lengths, the LDPC encoder supports rate-1/2, rate-2/3, rate-3/ 34 4 and rate-5/6 encoding. The LDPC encoder is systematic, i.e., it encodes an information block, c=(i0,i1,..., 35 i ), of size k, into a codeword, c, of size n, c=(i ,i ,... i p , p ,…, p ), by adding n-k parity bits 36 (k-1) 0 1 (k-1), 0 1 (n-k-1) 37 obtained so that HcT = 0, where H is an (n-k)×n parity-check matrix. The selection of the codeword block 38 length (n) is achieved via the LDPC PPDU encoding process described in 20.3.11.6.5. 39 40 41 20.3.11.6.4 Parity check matrices 42 43 Each of the parity-check matrices can be partitioned into square subblocks (submatrices) of size Z × Z. These 44 submatrices are either cyclic-permutations of the identity matrix or null submatrices. 45 46 47 The cyclic-permutation matrix Pi is obtained from the Z × Z identity matrix by cyclically shifting the columns 48 to the right by i elements. The matrix P0 is the Z × Z identity matrix. Figure 20-12 illustrates examples (for a 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 subblock size of 8 × 8) of cyclic-permutation matrices Pi. 2 3 4 5 10000000 01000000 00000100 6 01000000 00100000 00000010 7 00100000 00010000 00000001 8 9 00010000 00001000 10000000 P0 = P1 = P5 = 10 00001000 00000100 01000000 11 12 00000100 00000010 00100000 13 00000010 00000001 00010000 14 00000001 10000000 00001000 15 16 17 Figure 20-12—Examples of cyclic-permutation matrices with Z=8. 18 19 Table R.1 of Annex P displays the “matrix prototypes” of parity-check matrices for all four coding rates at 20 block length n=648 bits. The integer i denotes the cyclic-permutation matrix P , as illustrated in Figure 20- 21 i 22 12. Vacant entries of the table denote null (zero) submatrices. 23 24 Table R.2 of Annex P displays the matrix prototypes of parity-check matrices for block length n=1296 bits, 25 26 in the same fashion. 27 28 Table R.3 of Annex P displays the matrix prototypes of parity-check matrices for block length n=1944 bits, 29 in the same fashion. 30 31 32 20.3.11.6.5 LDPC PPDU encoding process 33 34 To encode an LDPC PPDU, steps a) to g) defined below shall be performed in sequence. 35 36 a) Compute the number of available bits, Navbits , in the minimum number of OFDM symbols in which 37 38 the Data field of the packet may fit. 39 40 N = length  8 + 16 (20-35) 41 pld 42 43 Npld 44 Navbits = NCBPS  mSTBC  ------(20-36) 45 NCBPS  R  mSTBC 46 47 where 48 49 mSTBC is 2 if STBC is used and 1 otherwise 50 51 length is the value of the HT Length field in the HT-SIG field defined in Table 20-10 52 53 x denotes the smallest integer greater than or equal to x 54 55 Npld is the number of bits in the PSDU and SERVICE field 56 57 b) Compute the integer number of LDPC codewords to be transmitted, NCW, and the length of the 58 codewords to be used, L from Table 20-15. 59 LDPC 60 c) Compute the number of shortening bits, N , to be padded to the N data bits before encoding, as 61 shrt pld 62 follows. 63 64 65 Nshrt = max 0 NCW  LLDPC  R – Npld (20-37)

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table 20-15—PPDU encoding parameters 2 3 4 Number of LDPC codewords Range of Navbits (bits) LDPC codeword length LLDPC (bits) 5 (NCW) 6 7 N  648 1 1296, if N  N + 912 × (1-R) 8 avbits avbits pld 9 648, otherwise 10 1 11 648  Navbits  1296 1944, if Navbits  Npld + 1464 × (1-R) 12 1296, otherwise 13 1 1944 14 1296  Navbits  1944 15 16 1944  N  2592 2 1944, if N  N + 2916 × (1-R) 17 avbits avbits pld 18 1296, otherwise 19 2592 < Navbits N 1944 20 ------pld - 21 1944  R 22 23 24 25 When Nshrt = 0 , shortening is not performed. (Note that Nshrt is inherently restricted to be non-neg- 26 27 ative due to the codeword length and count selection of 20-15). When Nshrt  0 , shortening bits shall 28 29 be equally distributed over all NCW codewords with the first remNshrt NCW codewords being 30 shortened one bit more than the remaining codewords. Define N = N  N . Then, when 31 spcw shrt CW 32 N  0 , the shortening is performed by setting information bits i  i to 0 in the first shrt kN–1spcw – k – 1 33 remN  N codewords and setting information bits i  i to 0 in the remaining code- 34 shrt CW kN– spcw k – 1 35 36 words. For all values of Nshrt , encode each of the NCW codewords using the LDPC encoding tech- 37 nique described in 20.3.11.6.2 through 20.3.11.6.4. When N  0 , the shortened bits shall be 38 shrt 39 discarded after encoding. 40 41 d) Compute the number of bits to be punctured, Npunc , from the codewords after encoding, as follows. 42 43 44 Npunc = max 0 NCW  LLDPC – Navbits – Nshrt (20-38) 45 46 R 47 If N  0.1  N  L  1 – R AND N  1.2  N  ------is true OR if 48 punc CW LDPC shrt punc 1 – R 49 50 Npunc  0.3  NCW  LLDPC  1 – R is true, increment Navbits and recompute Npunc by the fol- 51 lowing two equations once: 52 53 54 Navbits = Navbits + NCBPS × mSTBC (20-39) 55 56 57 Npunc = max 0 NCW  LLDPC – Navbits – Nshrt (20-40) 58 59 The punctured bits shall be equally distributed over all N codewords with the first 60 CW 61 remNpunc NCW codewords being punctured one bit more than the remaining codewords. Define 62 63 Nppcw = Npunc  NCW . When Nppcw  0 , the puncturing is performed by discarding parity bits 64 pnk– –1N –  pnk–1– of the first remNpunc NCW codewords and discarding parity bits 65 ppcw

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 p  p of the remaining codewords after encoding. The number of OFDM sym- 2 nk– – Nppcw nk–1– 3 bols to be transmitted in the PPDU is computed as follows: 4 5 N = N / N (20-41) 6 SYM avbits CBPS 7 8 e) Compute the number of coded bits to be repeated, Nrep , as follows. 9 10 11 Nrep = max 0 Navbits – NCW  LLDPC  1 – R – Npld (20-42) 12 13 14 The number of coded bits to be repeated shall be equally distributed over all NCW codewords with one 15 more bit repeated for the first remNrep NCW codewords than for the remaining codewords. 16 17 NOTE—When puncturing occurs, the coded bits are not repeated, and vice versa. 18 19 The coded bits to be repeated for any codeword shall be copied only from that codeword itself, starting 20 from information bit i0 and continuing sequentially through the information bits and, when necessary, 21 22 into the parity bits, until the required number of repeated bits are obtained for that codeword. Note 23 that these repeated bits are copied from the codeword after the shortening bits have been removed. If 24 for a codeword the required number of repeated bits cannot be obtained in this manner (i.e., repeating 25 the codeword once), the procedure is repeated until the required number is achieved. These repeated 26 bits are then concatenated to the codeword after the parity bits in their same order. The is process is 27 28 illustrated in Figure 20-13. In this figure, the outlined arrows indicate the encoding procedure steps, 29 while the solid arrows indicate the direction of puncturing and padding with repeated bits. 30 31 32 LDPC Encoding 33 (concatenate parity) 34 (c) 35 Data Data Shortened Data Shortened Parity 36 Bits Bits Bits Bits Bits Bits 37 38 39 40 41 (Discard Punctured Bits) 42 (Discard Shortened Bits) 43 (d) (e) 44 Data Parity Data Parity Data Parity Repeat 45 Bits Bits Bits Bits Bits Bits Bits 46 47 48 49 50 Copy Repeat Bits 51 52 53 Figure 20-13—LDPC PPDU encoding padding and puncturing of a single codeword 54 55 56 f) For each of the NCW codewords, process the data using the number of shortening bits per codeword 57 as computed in step c) for encoding, and puncture or repeat bits per codeword as computed per step 58 d) and e), as illustrated in Figure 20-13. 59 60 g) Aggregate all codewords and parse as defined in 20.3.11.6.6. 61 62 20.3.11.6.6 LDPC parser 63 64 65 The succession of LDPC codewords that result from the encoding process of 20.3.11.6.5 shall be converted

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 into a bitstream in sequential fashion. Within each codeword, bit i0 is ordered first. The parsing of this encod- 2 ed data stream into spatial streams shall follow exactly the parsing rules defined for the BCC encoder, as de- 3 4 fined in 20.3.11.7.1. However, the frequency interleaver of 20.3.11.7.3 is bypassed. 5 6 20.3.11.7 Data interleaver 7 8 20.3.11.7.1 Overview 9 10 11 After coding and puncturing, the data bit streams at the output of the FEC encoders are re-arranged into blocks 12 of N i bits, where i = 12N is the spatial stream index. This operation is referred to as 13 CBPSS SS SS SS 14 “stream parsing” and is described in 20.3.11.7.2. If BCC encoding was used, each of these blocks is then in- 15 terleaved by an interleaver that is a modification of the Clause 17 interleaver. 16 17 20.3.11.7.2 Stream parser 18 19 20 The number of bits assigned to a single axis (real or imaginary) in a constellation point in spatial stream iSS 21 is denoted by 22 23 24 NBPSCSiSS 25 siSS = max 1 ------(20-43) 26 2 27 28 N 29 SS 30 The sum of these over all streams is: Ssi= SS . 31  i = 1 32 SS 33 NOTE—if equal MCS is used for all spatial streams this becomes NSS  s , where s is the number of bits for an axis 34 common to all streams. 35 36 Consecutive blocks of si bits are assigned to different spatial streams in a round robin fashion. 37 SS 38 39 If two encoders are present, the output of each encoder is used alternately for each round robin cycle, i.e., at 40 the beginning S bits from the output of first encoder are fed into all spatial streams, and then S bits from the 41 output of second encoder are used and so on. 42 43 44 Input k to spatial stream i shall be yj , which is output bit i of the encoder j, 45 SS i 46 47 where 48 49 k 50 j = ------mod NES (20-44) 51 siSS 52

53 iSS – 1 54 k 55 isi=  ' ++S  ------k mod siSS (20-45) NES  siSS 56 i'1= 57 58 1 i N 59 SS SS 60 x is the largest integer less than or equal to x 61 62 63 z mod t is the remainder resulting from the division of integer z by integer t 64 65 for iSS = 1 , the first term in Equation (20-45) has a value of 0.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 20.3.11.7.3 Frequency interleaver 2 3 MCS32 interleaving shall be as defined in Clause 17.3.5.6. Interleaving for all other MCSs is defined in this 4 5 subclause below. 6 7 The bits at the output of the stream parser are divided into blocks of N i , i = 12N bits, 8 CBPSS SS SS SS 9 and if BCC encoding was used, each block shall be interleaved by an interleaver based on the Clause 17 in- 10 terleaver. This interleaver, which is based on entering the data in rows and reading it out in columns, has a 11 different number of columns and rows depending on whether a 20 MHz channel or a 40 MHz channel is used. 12 Table 20-16 defines the interleaver parameters. If LDPC encoding was used, no frequency interleaving is per- 13 14 formed, hence the parsed streams are immediately mapped to symbols as defined in 20.3.11.8. 15 16 17 Table 20-16—Number of rows and columns in the interleaver 18 19 20 Parameter 20 MHz 40 MHz 21 22 NCOL 13 18 23 24 NROW 4  NBPSCSiSS 6  NBPSCSiSS 25 26 NROT 11 29 27 28 29 After the operations based on the Clause 17 interleaver have been applied, if more than one spatial stream 30 31 exists, a third operation called frequency rotation shall be applied to the additional spatial streams. The pa- 32 rameter for the frequency rotation is NROT. 33 34 The interleaving is defined using three permutations. The first permutation is defined by the rule: 35 36 37 iN= ROWk mod NCOL + floor()kN COL k = 01 NCBPSSiSS – 1 (20-46) 38 39 40 The second permutation is defined by the rule 41 42 jsi= SS  floor()isi SS + iN+ CBPSSiSS – floor()NCOL  iN CBPSSiSS mod siSS ; (20-47) 43 i = 01 N i – 1 44 CBPSS SS 45 46 The value of siSS is determined by the number of coded bits per sub carrier: 47 48 49 siSS = maxNBPSCSiSS  2 1 (20-48) 50 51 If more than one spatial stream exists, a frequency rotation is applied to the output of the second permutation 52 53 54 i – 1 rj= –  i– 1  2 mod 3+ 3 floor------SS -  N  N i mod N i ; (20-49) 55 SS 3 ROT BPSCS SS CBPSS SS 56 57 j = 01 N i – 1 58 CBPSS SS 59 60 where 61 62 iSS = 12 NSS is the index of the spatial stream on which this interleaver is operating. 63 64 65 The deinterleaver uses the following operations to perform the inverse rotation. The index of the bit in the

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 received block (per spatial stream) is denoted by r. The first permutation reverses the third (frequency rota- 2 tion) permutation of the interleaver 3 4 5 i – 1 jr= +  i– 1  2 mod 3+ 3 floor------SS -  N  N i mod N i ; 6 SS 3 ROT BPSCS SS CBPSS SS 7 (20-50) 8 r = 01 N i – 1 9 CBPSS SS 10 11 The second permutation reverses the second permutation in the interleaver. 12 13 14 isi= SS  floor()jsi SS + j + floor()NCOL  jN CBPSSiSS mod siSS ; (20-51) 15 j = 01 NCBPSSiSS – 1 16 17 18 where siSS is defined in Equation (20-48). 19 20 21 The third permutation reverses the first permutation of the interleaver: 22 23 kN=  i – N i – 1  flooriN i = 01 N i – 1 (20-52) 24 COL CBPSS SS ROW CBPSS SS 25 26 20.3.11.8 Constellation mapping 27 28 The mapping between bits at the output of the interleaver and complex constellation points for BPSK, QPSK, 29 30 16-QAM and 64-QAM follows the rules defined in 17.3.5.7. 31 32 The streams of complex numbers are denoted: 33 34 35 dkln  0 kNSD – 11; lNSS;0 nNSYM – 1 (20-53) 36 37 20.3.11.8.1 Space-Time Block Coding (STBC) 38 39 40 This subclause defines a set of optional robust transmission formats that are applicable only when NSTS is 41 greater than N . In this case, N spatial streams are mapped to N space time streams, which are mapped 42 SS SS STS 43 to NTX transmit chains. These formats are based on Space-Time Block Coding (STBC). When the use of 44 45 STBC is indicated in the STBC field of the HT-SIG, a symbol operation shall occur between the constellation 46 mapper and the spatial mapper (see Figure 20-3) as defined in this subclause. 47 48 If space time block coding is applied, the stream of complex numbers, 49 50 dkin ;0k ===NSD –11;i NSS;0n NSYM–1 , generated by the constellation mapper, is the input of 51 the STBC encoder, which produces as output the stream of complex numbers 52 ˜ 53 dkin ;0k ===NSD –11;i NSTS;0n NSYM – 1 . For given values of k and i, STBC processing op- 54 ˜ 55 erates on the complex modulation symbols in sequential pairs of OFDM symbols, so that the value of dki2m 56 depends on d and d , and d˜ also depends on d and d , as defined in Table 57 ki2m ki2m + 1 ki2m + 1 ki2m ki2m + 1 58 20-17. 59 60 ˜ 61 If space time block coding is not applied, dkin = dkin and NSS = NSTS . 62 63 64 NOTE—The specific STBC schemes for single spatial streams (NSS = 1 ) with NTX  3 are not detailed in this sub- 65 clause since they can be covered through the use of spatial expansion as detailed in 20.3.11.10.1.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table 20-17—Constellation mapper output to spatial mapper input for STBC 2 3 4 N HT-SIG MCS N HT-SIG iSTS ˜ ˜ STS SS dki2m dki2m + 1 5 field (bits 0-6 STBC field 6 in HT-SIG1) (bits 4–5 in 7 HT-SIG2) 8 1 9 dk12m dk12m + 1 10 20-7 1 1 11 2 * * 12 –dk12m + 1 dk12m 13 1 14 dk12m dk12m + 1 15 16 2 * * 3 8-15, 33-38 2 1 17 –dk12m + 1 dk12m 18 19 3 dk22m dk22m + 1 20 21 1 22 dk12m dk12m + 1 23 2 * * 24 –d d 25 k12m + 1 k12m 48-15 2 2 26 3 27 dk22m dk22m + 1 28 4 * * 29 –d d 30 k22m + 1 k22m 31 1 32 dk12m dk12m + 1 33 34 2 * * –d d 35 16-23, 39, 41, k12m + 1 k12m 4 31 36 43, 46, 48, 50 3 37 dk22m dk22m + 1 38 39 4 d d 40 k32m k32m + 1 41 42 43 NOTE—STBC is only applied for the HT-SIG MCS field values specified in Table 20-17 and is not used with MCS 32. 44 45 46 20.3.11.9 Pilot subcarriers 47 48 49 In the case of 20 MHz, 4 pilot tones shall be inserted in the same sub-carriers used in Clause 17, i.e., in sub- th th 50 carriers -21, -7, 7 and 21. The pilot sequence for the n symbols and iSTS space time stream shall be as fol- 51 lows: 52 53 54 55  N N P-28,28 = 0000000 STS 0000000000000 STS 0000000 56 iSTS n  iSTS n  4 iSTS n + 1  4 57  58 NSTS NSTS  59 000000i  n + 2  4 0000000000000i  n + 3  4 0000000 60 STS STS  61 (20-54) 62 63 In the case of 40 MHz transmission (excluding MCS 32, see 20.3.11.10.4), pilot signals shall be inserted in 64 65 sub-carriers -53, -25, -11, 11, 25, 53. The pilot sequence for symbol n and space time stream iSTS shall be as

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 follows 2 3 4 -58,58  NSTS 5 Pi  n = 00000i  n  6 0000000000000000000000000 6 STS  STS 7 N N 8 00 STS 0000000000000 STS 000000000 9 iSTS n + 1  6 iSTS n + 2  6 10 11 N N 000000000000 STS 0000000000000 STS  12 iSTS n + 3  6 iSTS n + 4  6 13 14 N  15 STS 000000000000000000000000000i  n + 5  6 00000 16 STS  17 (20-55) 18 19 20 NSTS where na indicates symbol number modulo integer a and the patterns i n are defined in Table 20-18 21 STS 22 and Table 20-19. 23 NOTE—For each space time stream there is a different pilot pattern and the pilot patterns are cyclically rotated over 24 symbols. 25 26 27 The basic patterns are also different according to the total number of space time streams for the packet. 28 29 30 Table 20-18—Pilot values for 20 MHz transmission 31 32 NSTS NSTS NSTS NSTS 33 NSTS iSTS i  0 i  1 i  2 i  3 34 STS STS STS STS 35 11111-1 36 37 2 1 1 1 -1 -1 38 39 22 1 -1-11 40 3 1 1 1 -1 -1 41 42 321-11-1 43 44 33 -11 1 -1 45 46 41111-1 47 48 42 1 1 -11 49 431-111 50 51 44 -11 1 1 52 53 54 55 20.3.11.10 OFDM modulation 56 57 58 The time domain signal is composed from the stream of complex numbers 59 60 ˜ 61 dkln  0 kNSD – 11; lNSTS;0 nNSYM – 1 (20-56) 62 63 64 and from the pilot signals. In the case of 40 MHz transmission, the upper sub-carriers are rotated 90° relative 65 to the lower sub-carriers.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table 20-19—Pilots values for 40 MHz transmission (excluding MCS 32) 2 3 NSTS NSTS NSTS NSTS NSTS NSTS 4 NSTS iSTS i  0 i  1 i  2 i  3 i  4 i  5 5 STS STS STS STS STS STS 6 1111 1-1-11 7 8 2 1 1 1 -1 -1 -1 -1 9 10 22 1 1 1 -11 1 11 3 1 1 1 -1 -1 -1 -1 12 13 32 1 1 1 -11 1 14 15 331-11-1-11 16 17 4 1 1 1 -1 -1 -1 -1 18 19 42 1 1 1 -11 1 20 431-11-1-11 21 22 4 4 -1 1 1 1 -1 1 23 24 25 26 20.3.11.10.1 Spatial mapping 27 28 The transmitter may choose to rotate and/or scale the constellation mapper output vector (or the space time 29 30 block coder output, if applicable). This is useful in the following cases: 31 — there are more transmit chains than space time streams, NSTS  NTX , 32 33 — as part of (an optional) sounding packet, 34 — as part of (an optional) calibration procedure, 35 36 — when the packet is transmitted using one of the (optional) beamforming techniques. 37 38 iSTS 39 If the data to be transmitted on sub-carrier k on space time stream iSTS is Xk , the transmitted data on the 40 41 transmit chain iTX shall be: 42 43

44 NSR NSTS 45 iTX 1 iSTS iSTS 46 rField = ------wT t Qk Xk expj2kFtT– CS Tone Field   iTX iSTS 47 N  N STS Field kN= – SR iSTS = 1 48 49 (20-57) 50 51 where 52 53 Qk i i is the element in row iTX and column iSTS in a matrix Qk with NTX rows and NSTS columns. 54 TX STS 55 Qk may be frequency dependent. 56 57 Field is any field, as defined in 20.3.7, excluding L-STF, L-LTF, L-SIG, and HT-SIG in HT_MF format 58 PPDU. 59 60 61 Below are some examples of spatial mapping matrices that can be used. There exist many other alternatives, 62 implementation is not restricted to the spatial mapping matrices shown. 63 64 a) Direct Mapping: in this case Qk is a diagonal matrix of unit magnitude complex values that can take 65 two forms:

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 1)Qk = I , the identity matrix 2 3 2) A CSD matrix in which the diagonal elements represent cyclic shifts in the time domain: 4 i i 5 Qk ii = exp–j2kFCS , where CS i = 1 NTX represents the CSD applied. 6 7 b) Indirect Mapping: Qk may be the product of a CSD matrix and a square unitary matrix such as the 8 9 Hadamard matrix or the Fourier matrix. 10 11 c) Spatial Expansion: in this case Qk is the product of a CSD matrix and a square matrix formed of 12 orthogonal columns. As an illustration: 13 14 1) the spatial expansion may be performed by duplicating some of the N streams to form the 15 STS 16 N streams, with each stream being scaled by the normalization factor N  N . The spa- 17 TX STS TX 18 tial expansion may be performed by using for instance one of the following matrices, denoted 19 D, left multiplied by a CSD matrix, denoted MCSDk , and/or possibly multiplied by any 20 21 square unitary matrix. The resulting spatial mapping matrix is then Qk = MCSDk  D , where 22 D may take on one of the following values: 23 24 1 T 25 i) NTX=2, NSTS=1, D = ------11 26 2 27 28 1 T 29 ii) NTX=3, NSTS=1, D = ------111 30 3 31 1 T 32 iii) N =4, N =1, D = --- 33 TX STS 2 1111 34 35 10 36 2 37 iv) N =3, N =2, D = --- TX STS 3 01 38 10 39 40 41 10 42 43 1 01 v) NTX=4, NSTS=2, D = ------44 2 10 45 46 01 47 48 100 49 50 3 010 vi) NTX=4, NSTS=3, D = ------51 2 001 52 53 100 54 55 2) Different Spatial Expansion over sub-carriers—this should be used in HT-mixed format only 56 and with the smoothing bit set to 0: 57 58 T T i) N =2, N =1, Q =orQ = 59 TX STS k NSTS 10 k NSTS 01 60 61 62 10 10 00 63 ii) NTX=3, NSTS=2, Qk N = 00 01 or 10 64 STS 65 01 00 01

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 2 10 10 00 00 3 iii) N =4, N =2, Q = 0000 10 or 10 4 TX STS k NSTS 5 00 01 00 01 6 01 00 01 00 7 8 9 100 100 10 010 000 iv) NTX=4, NSTS=3, Qk N = or 11 STS 000 010 12 13 001 001 14 15 d) Beamforming Steering Matrix: In this case, Qk is any matrix that improves the reception in the 16 receiver based on some knowledge of the channel between the transmitter and the receiver. With 17 18 transmit beamforming with explicit feedback, the steering matrix Qk is determined using either 19 Heff for CSI feedback or Vk for Non-Compressed and Compressed Matrices feedback from the 20 21 STA to which the beamformed packet is addressed. 22 23 In the case where there are fewer space time streams than transmit chains, the first N columns of the ma- 24 STS 25 trices above that are square can be used. 26 27 The same matrix Q shall be applied to subcarrier k during all parts of the packet in HT-greenfield format 28 k 29 and all parts of the packet following and including the HT-STF field in an HT-mixed format packet. This 30 operation is transparent to the receiver. 31 32 If 95 percent of the sum of the energy from all impulse responses of the time domain channels between all 33 34 space time streams and all transmit chain inputs, induced by the CSD added according to Table 20-9 and the 35 frequency-dependence in the matrix Qk , is contained within 800 ns, the smoothing bit should be set to 1, oth- 36 37 erwise it shall be set to 0. 38 39 The CSD of Table 20-9 shall be applied at the input of the spatial mapper. 40 41 In the case of the identity matrix Direct Mapping, the smoothing bit should be set to 1. 42 43 44 If no spatial mapping is applied, the matrix Qk is equal to the identity matrix and NSTS = NTX . 45 46 47 Sounding PPDUs using spatial expansion shall use unitary Qk . 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 20.3.11.10.2 Transmission in 20 MHz HT format 2 3 4 The signal from transmit chain iTX 1 iTX NTX shall be: 5 6 7 NSYM – 1 8 iTX 1 rHT– DATAt = ------wT tnT– SYM (20-58) 9 Tone  SYM 10 NSTS  NHT– DATA n = 0 11 12 N N 13 SR STS ˜ k 14  Q Dkin + p P   k iTX iSTS STS nz+ iSTS n 15 kN= – i = 1 16 SR STS 17 18 i 19  expj2k tnT– – T – T STS  20 F SYM GI CS 21 22 where: 23 24 z is 3 in an HT-mixed format packet and 2 in an HT-greenfield format packet, 25 26 pn is defined in 17.3.5.9, 27 28 29   0 k = 0721    30 D˜ = kiSTS n  ˜ 31 r  dM k i n otherwise 32  STS 33 34 35  36  k + 28 – 28 k –22  37  k + 27 – 20 k –8 38 r  k + 26 – 6 k –1 39 M k =  , and 40  k + 25 1 k 6 41  k + 24 8 k 20 42   k + 23 22 k 28 43  44 45 k 46 P is defined in Equation (20-54). iSTS n 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 20.3.11.10.3 Transmission in 40 MHz HT Format 2 3 4 In the case of 40 MHz, the signal from transmit chain iTX shall be: 5 6 7 8 9 NSYM–1 iTX 1 10 r t = ------w tnT– (20-59) HT– DATA  TSYM SYM 11 N  NTone 12 STS HT– DATA n = 0 13 14 N N 15 SR STS ˜ k 16  Q Dkin + p P   k iTX iSTS STS nz+ iSTS n k 17 kN= – i = 1 18 SR STS 19 20

21 iSTS 22  expj2kFtnT– SYM – TGI – TCS  23 24 25 where 26 27 z is 3 in an HT-mixed format packet and 2 in an HT-greenfield format packet 28 29 p is defined in 17.3.5.9 30 n 31 32 33  ˜  0 k = 01112553        34 Dki n = STS  ˜ 35  dMrk i n otherwise 36  STS 37 38 39  k + 58 – 58 k –54 40  41  k + 57 – 52 k –26  42  k + 56 – 24 k –12 43 r  k + 55 – 10 k –2 44 M k =  45  k + 52 2 k 10 46  k + 51 12 k 24 47   k + 50 26 k 52 48  49  k + 49 54 k 58 50 51 52 k P i n is defined in Equation (20-55). 53 STS 54 NOTE—The 90º rotation that is applied to the upper part of the 40 MHz channel is applied in the same way to the HT- 55 STF, HT-LTF, and HT-SIG. The rotation applies to both pilots and the data in the upper part of the 40 MHz channel. 56 57 58 20.3.11.10.4 Transmission in MCS 32 format 59 60 61 MCS 32 format provides the lowest transmission rate in 40 MHz. It is only used for one spatial stream and 62 only with BPSK modulation and rate-½ coding. 63 64 65 In the MCS 32 format, the signal shall be:

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 N – 1 2 SYM iTX 1 3 r t = ------w tnT– (20-60) HT– DATA  TSYM SYM 4 Tone NHT– Duplicate n = 0 5 6 N 7 SR 8  D + p P Q expj2k – 32 tnT– – T  kn nz+ k k – 32 iTX 1 F SYM GI 9 kN= – 10 SR 11 12 13 + jQk + 32 i  1 expj2k + 32 FtnT– SYM – TGI  14 TX 15 16 where: 17 18 z is defined in 20.3.11.10.2 19 20 Pk and pn are defined in 17.3.5.9 21 22 Dkn is defined in 20.3.9.4.3 23 24 NSR has the value defined for non-HT 20 MHz transmission 25 26 Qk i 1 is an element from a vector of length NTX , which may be frequency dependent 27 TX 28 Tone 29 NHT– Duplicate is defined in Table 20-7 30 31 32 The rules of spatial expansion CSD limitation, as specified in 20.3.11.10.1, shall apply to Qk i  1 . 33 TX 34 35 20.3.11.10.5 Transmission with a short guard interval 36 37 Short guard interval is used in the data field of the packet when the Short GI field in the HT-SIG is set to 1. 38 When it is used, the same formula for the formation of the signal shall be used as in 20.3.11.10.2, 39 40 20.3.11.10.3, and 20.3.11.10.4, with TGI replaced by TGIS and TSYM replaced by TSYMS . 41 NOTE—Short GI is not used in HT-greenfield format with one spatial stream, in which case the HT-SIG is immediately 42 followed by data. It is very difficult to parse the HT-SIG in time to demodulate this data with the correct GI length if the 43 GI length is not known in advance. 44 45 20.3.11.11 Non-HT duplicate transmission 46 47 48 Non-HT duplicate transmission is used to transmit to Clause 17 STAs, Clause 19 STAs, and Clause 20 STAs 49 that may be present in either the upper or lower halves of the 40 MHz channel. The L-STF, L-LTF, and L- 50 SIG shall be transmitted in the same way as in the HT 40 MHz transmission. The HT-SIG, HT-STF, and HT- 51 LTF are not transmitted. Data transmission shall be as defined in Equation (20-61). 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 2 NSYM – 1 3 iTX 1 rLEG– DUPt = ------wT tnT– SYM (20-61) 4 Tone  SYM 5 NHT– Duplicate n = 0 6 7 26 i 8  D + p P  expj2k – 32 tnT– – T – T TX 9  kn n + 1 k F SYM GI CS 10 k = –26 11 12 iTX 13 + jjexp2k + 32 FtnT– SYM – TGI – TCS  14 15 16 where: 17 18 P and p are defined in 17.3.5.9 19 k n 20 21 Dkn is defined in 20.3.9.4.3 22 i 23 T TX represents the cyclic shift of the transmit chain i and is defined in Table 20-8 24 CS TX 25 Tone 26 NHT– Duplicate is defined in Table 20-7 27 28 29 20.3.12 Beamforming 30 31 Beamforming is a technique in which the beamformer utilizes the knowledge of the MIMO channel to gen- 32 33 erate a steering matrix Qk that improves reception in the beamformee. 34 35 The equivalent complex baseband MIMO channel model is one in which when a vector 36 37 T T xk = x1x2 xN is transmitted in subcarrier k the received vector yk = y1y2 yN is modeled 38 TX RX 39 as: 40 41 y = H x + n (20-62) 42 k k k 43 44 where 45 46 Hk is channel matrix of dimensions NRX  NTX 47 48 n is white (spatially and temporally) Gaussian noise. This is illustrated in Figure 20-14 49 50 51 When beamforming is used, the beamformer replaces xk , which in this case has NSTS  NTX elements, with 52 53 Qkxk , where Qk has NTX rows and NSTS columns, so that the received vector is 54 55 y = H Q x + n (20-63) 56 k k k k 57 58 The beamforming steering matrix that is computed (or updated) from a new channel measurement replaces 59 the existing Q for the next beamformed data transmission. There are several methods of beamforming, dif- 60 k 61 fering in the way the beamformer acquires the knowledge of the channel matrices Hk and on whether the 62 63 beamformer generates Qk or the beamformee provides feedback information for the beamformer to generate 64 65 Qk .

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

2 HAB 3 4 5 6 7 STA A STA B 8 9 10 11 12 13 HBA 14 BTX , BRX 15 A , A 16 TX RX 17 18 Figure 20-14—The beamforming MIMO channel model (3x2 example) 19 20 20.3.12.1 Implicit feedback beamforming 21 22 Implicit feedback beamforming is a technique that relies on reciprocity in the time division duplex channel 23 24 to estimate the channel that a device is transmitting over based on the MIMO reference that is received from 25 the device to which it plans to transmit. This allows the transmitting device to calculate a set of transmit steer- 26 ing matrices, Qk , one for each subcarrier, which are intended to optimize the performance of the link. 27 28 29 Referring to Figure 20-14 beamforming transmissions from a STA A to a STA B using implicit techniques 30 are enabled when STA B sends STA A a sounding PPDU, allowing STA A to form an estimate of the MIMO 31 channel from STA B to STA A, for all subcarriers. For a TDD channel in which the forward and reverse chan- 32 33 nels are reciprocal, the channel from STA A to STA B in subcarrier k is the matrix transpose of the channel 34 T 35 from STA B to STA A in subcarrier k , to within a complex scaling factor, i.e., HAB k = HBA k . Here 36 H is the MIMO channel matrix from STA A to STA B at subcarrier k , and H is the channel matrix 37 AB k BA k 38 from STA B to STA A at subcarrier k . STA A uses this relationship to compute transmit steering matrices 39 40 that are suitable for transmitting to STA B over HAB k . 41 NOTE—In order for the recipient of the sounding to compute steering matrices when steered or unsteered sounding is 42 H H H 43 used, the steering matrices should have the property: HkQk HkQk = HkHk , where X indicates the conjugate 44 transpose of the matrix X . 45 46 47 While the over-the-air channel between the antenna(s) at one STA and the antenna(s) at a second STA is re- 48 ciprocal, the observed baseband-to-baseband channel used for communication may not be, as it includes the 49 transmit and receive chains of the STAs. Differences in the amplitude and phase characteristics of the transmit 50 and receive chains associated with individual antennas degrade the reciprocity of the over-the-air channel, 51 and cause degradation of performance of implicit beamforming techniques. The over-the-air calibration pro- 52 53 cedure described in 9.19.2.4 may be used to restore reciprocity. The procedure provides the means for calcu- 54 lating a set of correction matrices that can be applied at the transmit side of a STA to correct the amplitude 55 and phase differences between the transmit and receive chains in the STA. If this is done at least at the STA 56 that serves as the beamformer, there is sufficient reciprocity for implicit feedback in the baseband-to-base- 57 band response of the forward link and reverse channel. 58 59 60 Figure 20-15 illustrates the observed baseband-to-baseband channel, including reciprocity correction. The 61 amplitude and phase responses of the transmit and receive chains can be expressed as diagonal matrices with 62 63 complex valued diagonal entries, of the form ATX k and ARX k at STA A. The relationship between the base- 64 ˜ 65 band-to-baseband channel, HAB k , and the over-the-air channel, HAB k , is

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 H˜ = B H A (20-64) 2 AB k RX k AB k TX k 3 4 ˜ 5 and, similarly, the relationship between HBA k and HBA k is 6 7 ˜ 8 HBA k = ARX kHBA kBTX k (20-65) 9 10 11 12 H AB 13 14 15 16 17 KA ATX HAB BRX 18 19 20 STA A STA B 21 22 23 A H B K 24 RX BA TX B 25 26 27 28

29 H BA 30 31 Figure 20-15—The baseband-to-baseband channel 32 33 34 As an example, consider the case where calibration is performed at both STA A and STA B. The objective is 35 to compute correction matrices, K and K , that restore reciprocity such that 36 A k B k 37 38 ˜ ˜ T 39 HAB kKA k = HBA kKB k (20-66) 40 41 42 The correction matrices are diagonal matrices with complex valued diagonal entries. The reciprocity condi- 43 tion in Equation (20-66) is enforced when 44 45 –1 46 KA k = A kATX k ARX k (20-67) 47 48 49 and 50 51 –1 52 KB k = B kBTX k BRX k (20-68) 53 54 55 where A k and B k are complex valued scaling factors. 56 57 58 Using these expressions for the correction matrices, the calibrated baseband-to-baseband channel between 59 STA A and STA B is expressed as 60 61 ˆ ˜ 62 HAB k ==HAB kKA k A kBRX kHAB kARX k (20-69) 63 64 65 and if both sides apply the correction matrices,

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 ˆ B k ˆ T 2 HBA k ==B kARX kHBA kBRX k ------HAB k (20-70) 3 A k 4 5 Focusing on STA A, the procedure for estimating K is as follows: 6 A k 7 ˜ 8 a) STA A sends STA B a sounding PPDU, allowing STA B to estimate the channel matrices HAB k . 9 ˜ 10 b) STA B sends STA A a sounding PPDU, allowing STA A to estimate the channel matrices HBA k . 11 ˜ 12 c) STA B sends the quantized estimates of HAB k to STA A. 13 14 d) STA A uses its local estimates of H˜ and the quantized estimates H˜ received from STA B to 15 BA k AB k 16 compute the correction matrices KA k . 17 18 19 Steps a) and b) occur over a short time interval to ensure that the channel changes as little as possible between 20 measurements. A similar procedure is used to estimate KB k at STA B. The details of the computation of the 21 22 correction matrices is implementation specific, and beyond the scope of this document. 23 24 20.3.12.2 Explicit feedback beamforming 25 26 27 In explicit beamforming, in order for STA A to transmit a beamformed packet to STA B, STA B measures 28 the channel matrices and sends STA A, either the effective channel, Heff k , or the beamforming feedback ma- 29 30 trix, Vk , for STA A to determine a steering matrix, Qsteer,k = QkVk , with Vk found from HkQk , where Qk 31 is the orthonormal spatial mapping matrix that was used to transmit the sounding packet that elicited the V 32 k 33 feedback. The effective channel, Heff k = HkQk , is the product of the spatial mapping matrix used on trans- 34 35 mit with the channel matrix. When new steering matrix Qsteer k is found, Qsteer k may replace Qk for the next 36 beamformed data transmission. 37 38 NOTE— Qsteer k is a mathematical term to update a new steering matrix for Qk in the next beamformed data transmis- 39 sion. 40 41 20.3.12.2.1 CSI Matrices feedback 42 43 44 In CSI Matrices feedback the beamformer receives the quantized MIMO channel matrix, Heff , from the 45 46 beamformee. The beamformer then may use this matrix to compute a set of transmit steering matrices, Qk . 47 The CSI matrix, H , shall be determined from the transmitter spatial mapper input to the receiver FFT out- 48 eff 49 puts. The beamformee shall remove the CSD in Table 20-9 from the measured channel matrix. 50 51 52 The matrices Heffk , where k is the subcarrier index, are encoded so that applying the procedure in 53 20.3.12.2.2 will optimally reconstruct the matrix. 54 55 56 20.3.12.2.2 CSI Matrices feedback decoding procedure 57 58 q 59 The received, quantized, matrix Heffk (of a specific subcarrier, k ) shall be decoded as follows: 60 61 qR qI a) The real and imaginary parts of each element of the matrix Heff m l k and Heff m l k are 62 63 decoded as a pair of two's complement numbers to create the complex element, where 1 mNr 64 65 and 1 lNc .

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 b) Each element in the matrix of subcarrier k is then scaled using the value in the carrier matrix ampli- 2 3 tude field (3 bits), MHk , interpreted as a positive integer in dB, as follows: 4 5 1) Calculate the linear value as defined in Equation (20-71), and 6 2) Calculate decoded values of the real and imaginary parts of the matrix element as defined in 7 Equation (20-72) and Equation (20-73). 8 9 M k  20 10 rk= 10 H (20-71) 11 12 13 qR ˜ Heff m l k 14 ReHeff m l k = ------(20-72) 15 rk 16 17 qI ˜ Heff m l k 18 ImHeff m l k = ------(20-73) 19 rk 20 21 20.3.12.2.3 Example of CSI Matrices feedback encoding 22 23 24 The following is an example of an encoding process: 25 a) The maximum of the real part and the imaginary part of each element of the matrix in each subcar- 26 rier are found, as defined by Equation (20-74). 27 28 29 30 mN==r l Nc mN==r l Nc mHk = max max ReHeff m l k m ==1 l 1  max ImHeff m l k m ==1 l 1 31  32 33 (20-74) 34 35 b) The scaling ratio is calculated and quantized to 3 bits as defined by Equation (20-75). A linear scaler 36 is given by Equation (20-76). 37 38 zN= 39 maxm z SR H zN= – SR 40 MHk = min 7 20log10------(20-75) 41 mHk 42 43 where 44 45 x is the largest integer smaller than or equal to x 46 47 48 zN= maxm z SR 49 lin H zN= – SR MH k = ------(20-76) 50 MHk  20 51 10 52 53 c) The real and imaginary parts of each element in the matrix H k are quantized to N bits in 54 eff m l b 55 two's complement encoding as defined by Equation (20-77) and Equation (20-78). 56 57 ReH k N – 1 58 qR eff m l b Heff m l k = round------2 – 1 (20-77) 59 Mlink 60 H 61 62 ImH k N – 1 63 qI eff m l b Heff m l k = round------2 – 1 (20-78) 64 Mlink 65 H

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Each matrix is encoded using 32+  N  N  N bits, where N and N are the number of rows and col- 2 b r c r c 3 umns, respectively, in the channel matrix estimate computed by the receiving station, and Nb may have the 4 value of 4, 5, 6, 8 bits. 5 6 7 20.3.12.2.4 Non-compressed beamforming matrix feedback 8 9 10 In non-compressed beamforming matrix feedback, the beamformee shall remove the space-time stream CSD 11 in Table 20-9 from the measured channel before computing a set of matrices for feedback to the beamformer. 12 13 The beamforming matrices, Vk , found by the beamformee, are sent to the beamformer in the order of real 14 and imaginary components per tone as specified in 7.3.1.28. The beamformer can use these matrices to de- 15 termine the steering matrices Q . 16 k 17 18 19 The beamformee shall encode the matrices Vk so a beamformer applying the procedure below will opti- 20 mally reconstruct the matrix. 21 22 23 The received matrix Vqk (of a specific subcarrier k ) shall be decoded as follows: 24 25 qR qI 26 a) The real and imaginary parts of each element of the matrix, Vml and Vml , shall be decoded as a 27 pair of two's complement numbers to create the complex element, where 1 mN and 1 lN . 28 r c 29 30 b) The dimensions of the beamforming matrices is Nr  Nc , where Nr and Nc are the number of rows 31 and columns, respectively, in the beamforming matrix computed by the receiving station. Each 32 33 matrix is encoded using 2  Nb  Nr  Nc bits. Nb may have the value of 2, 4, 6, or 8 bits. 34 35 c) Columns 1Nc of the beamforming feedback matrix correspond to spatial streams 1Nc , respec- 36 37 tively. Spatial stream to modulation mapping is defined in the MCS Tables in 20.6. A transmitter 38 shall not re-order the columns of the beamforming feedback matrices. 39 40 20.3.12.2.5 Compressed beamforming matrix feedback 41 42 43 In compressed beamforming matrix feedback, the beamformee shall remove the space-time stream CSD in 44 Table 20-9 from the measured channel before computing a set of matrices for feedback to the beamformer. 45 46 The beamforming matrices, Vk , found by the beamformee are compressed in the form of angles, which are 47 sent to the beamformer. The beamformer can use these angles to de-compress the matrices and determine the 48 49 steering matrices Qk . 50 51 52 The matrix V per tone shall be compressed as follows. The unitary beamforming Nr  Nc matrix V found 53 by the beamformee shall be represented as: 54 55 56 min()N  N – 1 N 57 c r j r 58 jii Nr – 1 i T ˜ V = Di 1i – 1 e  e 1 Glili IN  N 59   r c (20-79) 60 i = 1 li= + 1 61 62 63 j jN – 1 i 64 The matrix D 1 e ii  e r 1 is an N  N diagonal matrix, where 1 represents a sequence 65 ii – 1 r r i – 1

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 of ones with length of i-1, as follows: 2 3 4 I 0 0 5 i – 1 j 6 0 e ii 0  0 jN – 1 i 7 jii r D1 e  e 1 = (20-80) 8 i – 1  0  00 9 jN – 1 i r 10 0 e 0 11 00001 12 13 14 The matrix Gli is an Nr  Nr Givens rotation matrix: 15 16 17 I 0000 18 i – 1 19 0 cos 0 sin 0 20 G  = 00I 00 (20-81) 21 li li–1– 22 0 –0sin cos 0 23 00 0 0I 24 Nr – l 25 26 27 where each Im is an mm identity matrix, and cos and sin are located at row l and column i. 28 ˜ IN N is an identity matrix padded with zeros to fill the additional rows or columns when N  N . 29 r  c r c 30 31 For example, a 4x2 V matrix has the following representation: 32 33 34 T T T j11 35 e 000 cos21 sin21 0 0 cos31 0 sin31 0 cos41 0 0 sin41 36 j 21 –sin21 cos21 0 0 0100 0100 37 V = 0 e 00   j31 0010–0sin cos 0 0010 38 00e 0 31 31 –00sin cos 39 0001 0001 0001 41 41 40 (20-82) 41 T T 10 00 10 00 1000 10 42 j 22 0 cos sin 0 0 cos 0 sin 43  0 e 00 32 32  42 42  01 44 j32 00e 0 0 –sin32 cos32 0 0010 00 45 00 01 0 –0sin cos 00 46 00 01 42 42 47 48 The procedure for finding a compressed V matrix is described as follows: 49 50 51 A unitary Nr  Nc beamforming matrix V is column-wise phase invariant because the steering matrix needs 52 53 a reference in phase per each column. This means V is equivalent to V˜ D˜ , where D˜ is a column-wise phase 54 j 55 j j N shift matrix such as D˜ = diage 1 e 2 e c . When the beamformee estimates the channel, it may find 56  57 ˜ ˜ ˜ 58 V for the beamforming matrix for the beamformer, but it should send VD back to the beamformer, where 59 ˜ ˜ ˜ ˜ ˜ 60 VV= D . The angle, i , in D is found to make the last row of VD to be non-negative real numbers. 61 62 j * 63 j11 Nr – 11 64 The angles   in the diagonal matrix D e  e 1 shall satisfy the constraint that 11 Nr – 11 1 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 * 2 all elements in the first column of D1V are non-negative real numbers. Now, the first column of 3 T G G G D*  V can be by the Givens rotations G such as 4 Nr1 31 21 1 10 0 l1 5 6 * 7 j cos 0 0 sin 11 8 Nr1 Nr1 cos31 0 sin31 0 cos21 sin21 0 0 e 000 1000 9 0 00 0 0100 0100–sin21 cos21 0 0   V = 10 j 0010 –0sin cos 0 Nr –11 0 V 11 31 31 001000e 0 2 –00sinN 1 cosN 1 0001 0001 0 12 r r 00 0 1 13 14 (20-83) 15 16 For a new Nr – 1  Nc – 1 submatrix V2 , this process is applied in the same way. Then, the angles 17 18 j jN – 12 * 19   in the diagonal matrix D 1 e 22  e r 1 shall satisfy the constraint that all ele- 20 22 Nr – 12 2 21 * 22 ments in the second column of D2  diag(1,V2  are all non-negative real numbers. Now, the first two col- 23 * * ˜ 24 umns of G G D G G G D  V can be IN  2 by the Givens rotations G such as Nr2 32 2 Nr1 31 21 1 r l2 25 26 27 * 28 1000 10 0010 0 0 1000 29 0 cos 0 sin j22 Nr2 Nr2 0 cos32 sin32 0 0 e 00 * 0100 30   GN 1G31G21D1  V = jN – 12 0010 0 –sin32 cos32 0 r 00 31 00e 0 V3 0 –0sin cos 00 01 00 32 Nr2 Nr2 00 0 1 33 34 (20-84) 35 36 ˜ This process continues until the first N columns of the right side matrix become IN  N . When N  N , this 37 c r c c r 38 ˜ process does not need to continue because V will be nulled out by IN  N . Then, by multiplying the com- 39 Nc + 1 r c 40 plex conjugate transpose of the products of the Di and Gli matrices on the left, V can be expressed as 41 42 43 T T T T T T T T T ˜ VD= G G G  D G G G    D G G G  IN  N ,(20-85) 44 1 21 31 Nr 1 2 32 42 Nr 2 p p + 1 p p + 2 p Nr p r C 45 46 where p = minN  N – 1 , which can be written in short form as in Equation (20-79). 47 c r 48 49 The angles found from the decomposition process above, e.g., the values of  and  , are quantized as 50 ij kl 51 described in 7.4.10.8. 52 53 54 Columns 1Nc of the beamforming feedback matrix correspond to spatial streams 1Nc , respectively. 55 Spatial stream to modulation mapping is defined in the MCS Tables in 20.6. A transmitter shall not re-order 56 the columns of the beamforming feedback matrices in determining steering matrices. 57 58 59 20.3.13 HT Preamble format for sounding PPDUs 60 61 The MIMO channel measurement takes place in every PPDU as a result of transmitting the HT-LTFs as part 62 of the PLCP preamble. The number of HT-LTFs transmitted shall be determined by the number of space-time 63 64 streams transmitted unless additional dimensions are optionally sounded using extension HT-LTFs, and these 65 are transmitted using the same spatial transformation that is used for the HT-Data. This enables the compu-

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 tation of the spatial equalization at the receiver. 2 3 4 When the number of space time streams, NSTS , is less than the number of transmit antennas, or less than 5 6 minNTX NRX , sending only NSTS HT-LTFs does not allow the receiver to recover a full characterization 7 of the MIMO channel, even though the resulting MIMO channel measurement is sufficient for receiving the 8 HT-Data. 9 10 11 However, there are several cases where it is desirable to obtain as full a characterization of the channel as is 12 possible, thus requiring the transmission of a sufficient number of HT-LTFs to sound the full dimensionality 13 14 of the channel, which is in some cases NTX , and in other cases minNTX NRX . These cases of MIMO chan- 15 nel measurement are referred to as MIMO channel sounding. A sounding packet may be used to sound avail- 16 able channel dimensions. A sounding PPDU is identified by setting the Not Sounding field in the HT-SIG to 17 18 zero. A sounding PPDU may have any allowed number of HT-LTFs satisfying NLTF  NSTS . In general, if 19 the Not Sounding field in the HT-SIG is set to zero and N  N , extension HT-LTFs are used, except 20 LTF STS 21 for the case where NSS = 3 and NLTF = 4 or in an NDP. 22 23 24 20.3.13.1 Sounding with a Null Data Packet 25 26 27 A STA may sound the channel using a Null Data Packet (NDP) (indicated by zero in the HT Length field in 28 the HT-SIG) with the Not Sounding field set to 0. The number of LTFs is the number implied by the MCS, 29 which shall indicate two or more spatial streams. The last HT-LTF of an NDP shall not be followed by a Data 30 field (see Figure 20-16). 31 32 33 It is optional for a STA to process an NDP. 34 35 36 HT- 37 HT-GF-STF HT-LTF1 HT-SIG LTF2 38 39 40 Figure 20-16—Example of an NDP used for sounding 41 42 20.3.13.2 Sounding PPDU for calibration 43 44 45 In the case of a bidirectional calibration exchange, two STAs exchange sounding PPDUs, enabling the receiv- 46 47 ing STA to compute an estimate of the MIMO channel matrix Hk for each sub-carrier k. In general, in an 48 exchange of calibration messages, the number of spatial streams is less than the number of transmit antennas, 49 necessitating the use of extension HT-LTFs. In the case of sounding PPDUs for calibration, the antenna map- 50 ping matrix shall be 51 52 53 Q = C k P (20-86) 54 k CSD CAL 55 56 where 57 58 C k is a diagonal cyclic shift matrix in which the diagonal elements carry frequency-domain 59 CSD 60 representation of the cyclic shifts given in Table 20-8 and 61 62 PCAL is one of the following unitary matrices: 63 64 65 For NTX ==1 PCAL 1

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 2 2 11– For NTX ==2 PCAL ------3 2 11 4 5 6 11 1 7 3 8 For N ==3 P ------–3j2  –j4  3 TX CAL 3 1 e e 9 –j4  3 –j2  3 10 1 e e 11 12 13 11–11 14 1 11–1 1 15 For NTX ==4 PCAL --- . 16 2 111– 1 17 –1111 18 19 20 20.3.13.3 Sounding PPDU for channel quality assessment 21 22 23 In response to the reception of an MCS request, sent by STA A to STA B, the responding STA B returns to 24 the requesting STA A an MCS selection that STA B determines to be a suitable MCS for STA A to use in 25 26 subsequent transmissions to STA B. In determining the MCS, STA B performs a channel quality assessment, 27 which entails using whatever information STA B has about the channel, such as an estimate of the MIMO 28 channel derived from the sounding PPDU that carries the MCS request. To enable this calculation, the MCS 29 request is sent in conjunction with a sounding PPDU. 30 31 32 The STA sending the MCS request (STA A) determines how many HT-LTFs to send, and whether to use ex- 33 tension HT-LTFs or an NDP, based on the Transmit Beamforming Capabilities field, number of space time 34 35 streams used in the PPDU carrying the MCS request, the number of transmit chains it is using (NTX ), whether 36 or not the transmit and receive STAs support STBC, and in some cases, the number of receive chains at the 37 38 responding STA (NRX ). 39 40 41 The maximum number of available space-time streams is set by the number of transmit and receive chains, 42 and the STBC capabilities of the transmitter and receiver, as is shown in Table 20-20. While the number of 43 receive chains at a STA is not communicated in a capabilities indicator, the maximum number of space time 44 streams supported may be inferred from the MCS capabilities and the STBC capabilities of the receiving 45 46 STA. When the number of receive chains is known at the transmitter, the number of HT-LTFs sent to obtain 47 a full channel quality assessment is determined according to the maximum number of space-time streams in- 48 dicated in Table 20-20. The number of HT-LTFs to use in conjunction with the indicated number of space 49 time streams is determined according to 20.3.9.4.6 50 51 52 If the requesting STA A sends an MCS request in a PPDU that uses fewer space time streams in the data por- 53 tion than the maximum number of space time streams possible given the number of antennas at STA A and 54 the responding STA B, the channel quality assessment made by STA B may be based on the Data HT-LTFs 55 56 alone. In this case the MCS feedback will be limited to MCSs using the number of streams used in the data 57 portion of the PPDU, or fewer. To determine whether an MCS should be chosen that uses more spatial streams 58 than the PPDU containing the MCS request, it is necessary for the requesting STA A to either use extension 59 HT-LTFs (send the MCS request in a staggered sounding PPDU), or use an NDP (send the MCS request in 60 conjunction with an NDP.) 61 62 63 The sounding PPDU may have non-identity spatial mapping matrix Q . For different receiving STAs, Q 64 k k 65 may vary.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table 20-20—Maximum available space-time streams 2 3 4 5 NSTS max NSTS max NTX NRX 6 without STBC with STBC 7 8 111 N/A 9 10 211 2 11 12 311 2 13 14 32 23 15 16 411 2 17 18 422 4 19 20 21 22 20.3.14 Regulatory requirements 23 24 25 Wireless LANs implemented in accordance with this standard are subject to equipment certification and op- 26 erating requirements established by regional and national regulatory administrations. The PMD specification 27 establishes minimum technical requirements for interoperability, based upon established regulations at the 28 time this standard was issued. These regulations are subject to revision, or may be superseded. Requirements 29 that are subject to local geographic regulations are annotated within the PMD specification. Regulatory re- 30 31 quirements that do not affect interoperability are not addressed in this standard. Implementers are referred to 32 the regulatory sources in Annex I for further information. Operation in countries within defined regulatory 33 domains may be subject to additional or alternative national regulations. 34 35 20.3.15 Channel numbering and channelization 36 37 38 The STA may operate in the 5 GHz band and/or 2.4 GHz band. When using 20 MHz channels it uses channels 39 defined in 17.3.8.3 (5 GHz band) or 18.4.6 (2.4 GHz band). When using 40 MHz channels, it can operate in 40 the channels defined in 20.3.15.1 and 20.3.15.2. 41 42 43 The set of valid operating channel numbers by regulatory domain is defined in Annex J. 44 45 20.3.15.1 Channel allocation in the 2.4 GHz Band 46 47 Channel center frequencies are defined at every integral multiple of 5 MHz in the 2.4 GHz band. The rela- 48 49 tionship between center frequency and channel number is given by the following equation: 50 51 Channel center frequency = 2407 + 5  n (MHz) (20-87) 52 ch 53 54 where 55 56 nch = 12 13 57 58 20.3.15.2 Channel allocation in the 5 GHz band 59 60 61 Channel center frequencies are defined at every integral multiple of 5 MHz above 5 GHz. The relationship 62 between center frequency and channel number is given as follows: 63 64 65 Channel center frequency = Channel starting frequency + 5  nch(MHz) (20-88)

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 where 2 3 nch = 01 200 4 5 6 Channel starting frequency is defined as dot11ChannelStartingFactor × 500 kHz or is defined as 5 GHz for 7 systems where dot11RegulatoryClassesRequired is false or not defined. 8 9 20.3.15.3 40 MHz channelization 10 11 12 The set of valid operating channel numbers by regulatory domain is defined in Annex J. 13 14 The 40 MHz channels are specified by two fields: (Nprimary_ch, Secondary). The first field represents the 15 16 channel number of the primary channel, and the second one indicates whether the secondary channel is above 17 or below the primary channel (1 -> above, –1 -> below). The secondary channel number shall be 18 Nprimary_ch+ Secondary  4 . 19 20 21 For example, a 40 MHz channel consisting of 40 MHz channel number 36 and Secondary 1 specifies the pri- 22 mary channel is 36 and the secondary channel is 40. 23 24 25 20.3.16 Transmit and receive in-band and out-of-band spurious transmissions 26 27 The OFDM PHY shall conform to in-band and out-of-band spurious emissions as set by regulatory bodies. 28 29 30 20.3.17 Transmitter RF delay 31 32 The transmitter RF delay shall follow 17.3.8.5. 33 34 20.3.18 Slot time 35 36 37 The slot time shall follow 17.3.8.6 for 5 GHz bands and 19.4.4 for 2.4 GHz bands. 38 39 20.3.19 Transmit and receive port impedance 40 41 42 The transmit and receive antenna port impedance for each transmit and receive antenna shall follow 17.3.8.7. 43 44 20.3.20 Transmit and receive operating temperature range 45 46 47 The transmit and receive temperature range shall follow 17.3.8.8. 48 49 20.3.21 PMD transmit specification 50 51 52 20.3.21.1 Transmit spectrum mask 53 54 NOTE 1—In the presence of additional regulatory restrictions, the device has to meet both the regulatory requirements 55 and the mask defined here – i.e., its emissions can be no higher at any frequency offset than the minimum of the values 56 specified in the regulatory and default masks. 57 58 NOTE 2—The transmit spectral mask figures in this subclause are not drawn to scale. 59 60 When transmitting in a 20 MHz channel, the transmitted spectrum shall have a 0 dBr (dB relative to the max- 61 imum spectral density of the signal) bandwidth not exceeding 18 MHz, –20 dBr at 11 MHz frequency offset, 62 –28 dBr at 20 MHz frequency offset and the maximum of –45 dBr and –53 dBm/MHz at 30 MHz frequency 63 64 offset and above. The transmitted spectral density of the transmitted signal shall fall within the spectral mask, 65 as shown in Figure 20-17. The measurements shall be made using a 100 kHz resolution bandwidth and a 30

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 kHz video bandwidth. 2 3 4 5 PSD 6 0dBr 7 8 9 10 11 -20dBr 12 13 -28dBr 14 15 16 17 18 -45dBr 19 Freq [MHz] 20 21 -30 -20-11 -9 9 11 20 30 22 23 Figure 20-17—Transmit spectral mask for 20 MHz transmission 24 25 26 When transmitting in a 40 MHz channel, the transmitted spectrum shall have a 0 dBr bandwidth not exceeding 27 38 MHz, –20 dBr at 21 MHz frequency offset, –28 dBr at 40 MHz offset and the maximum of –45 dBr and 28 –56 dBm/MHz at 60 MHz frequency offset and above. The transmitted spectral density of the transmitted sig- 29 nal shall fall within the spectral mask, as shown in Figure 20-18. 30 31 32 Transmission with CH_OFF_20U or CH_OFF_20L or CH_OFF_40 shall conform to the same mask that is 33 used for the 40 MHz channel. 34 35 36 PSD 37 38 0dBr 39 40 41 42 43 -20dBr 44 45 46 -28dBr 47 48 49 50 -45dBr 51 52 Freq [MHz] 53 -60 -40 -21 -19 0 19 21 40 60 54 55 Figure 20-18—Transmit spectral mask for a 40 MHz channel 56 57 58 20.3.21.2 Spectral flatness 59 60 In a 20 MHz channel and in corresponding 20 MHz transmission in a 40 MHz channel, the average energy 61 of the constellations in each of the subcarriers with indices –16 to –1 and +1 to +16 shall deviate no more than 62 ± 2 dB from their average energy. The average energy of the constellations in each of the subcarriers with 63 64 indices –28 to –17 and +17 to +28 shall deviate no more than +2/–4 dB from the average energy of subcarriers 65 with indices –16 to –1 and +1 to +16.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 In a 40 MHz transmission (excluding PPDUs in MCS 32 format and non-HT duplicate format) the average 2 energy of the constellations in each of the subcarriers with indices –42 to –2 and +2 to +42 shall deviate no 3 more than ± 2 dB from their average energy. The average energy of the constellations in each of the subcar- 4 5 riers with indices –43 to –58 and +43 to +58 shall deviate no more than +2/–4 dB from the average energy of 6 subcarriers with indices –42 to –2 and +2 to +42. 7 8 9 In MCS 32 format and non-HT duplicate format the average energy of the constellations in each of the sub- 10 carriers with indices -42 to -33, -31 to -6, +6 to +31, and +33 to +42 shall deviate no more than ± 2 dB from 11 their average energy. The average energy of the constellations in each of the subcarriers with indices –43 to 12 –58 and +43 to +58 shall deviate no more than +2/-4 dB from the average energy of subcarriers with indices 13 14 –42 to –33, –31 to –6, +6 to +31, and +33 to +42. 15 16 17 The tests for the spectral flatness requirements can be performed with spatial mapping Qk = I (see 18 20.3.11.10.1). 19 20 21 20.3.21.3 Transmit power 22 23 24 The maximum allowable transmit power by regulatory domain is defined in Annex I. 25 26 27 20.3.21.4 Transmit center frequency tolerance 28 29 30 The transmitter center frequency tolerance shall be ±20 ppm maximum for the 5 GHz band and ±25 ppm max- 31 imum for the 2.4 GHz band. The different transmit chain center frequencies (LO) and each transmit chain 32 symbol clock frequency shall all be derived from the same reference oscillator. 33 34 35 20.3.21.5 Packet alignment 36 37 38 If no signal extension is required (see 20.3.2), the receiver shall emit a PHY-CCA.indication(idle) primitive 39 (see 12.3.5.10) at the 4µs boundary following the reception of the last symbol of the packet. If a signal exten- 40 sion is required, the receiver shall emit a PHY-CCA.indication(idle) primitive a duration of aSignalExtension 41 42 µs after the 4µs boundary following the reception of the last symbol of the packet. This is illustrated for the 43 case of an HT-greenfield format packet using short GI in Figure 20-19. 44 45 46 If no signal extension is required the transmitter shall emit a PHY-TXEND.confirm primitive (see 12.3.5.7) 47 at the 4µs boundary following the trailing boundary of the last symbol of the packet on the air. If a signal 48 extension is required the transmitter shall emit a PHY-TXEND.confirm primitive (see 12.3.5.7) a duration of 49 aSignalExtension µs after the 4µs boundary following the trailing boundary of the last symbol of the packet 50 51 on the air. This is illustrated in Figure 20-19. 52 53 54 8 µs 8 µs 8 µs 4 µs 3.6 µs 3.6 µs 3.6 µs 4 µs aSignalExtension µs 55 boundary 56 57 HT- Data Data Data 58 HT-GF-STF HT-LTF1 HT-SIG Signal Extension 59 LTF2 Sym 1 Sym 2 Sym 3 60 61 Note that Signal Extension field is only PHY-TXEND.confirm 62 present in some PPDU formats. See and 63 20.3.2. PHY-CCA.indicate(IDLE) 64 65 Figure 20-19—Packet alignment example (HT-greenfield format packet with short GI)

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 20.3.21.6 Symbol clock frequency tolerance 2 3 4 The symbol clock frequency tolerance shall be ±20 ppm maximum for 5 GHz bands and ±25 ppm for 2.4 GHz 5 bands. The transmit center frequency and the symbol clock frequency for all transmit antennas shall be de- 6 rived from the same reference oscillator. 7 8 9 20.3.21.7 Modulation accuracy 10 11 12 20.3.21.7.1 Introduction to Modulation accuracy tests 13 14 15 Transmit modulation accuracy specifications are described in 20.3.21.7.2 and 20.3.21.7.3. The test method is 16 described in 20.3.21.7.4. 17 18 19 20.3.21.7.2 Transmit center frequency leakage 20 21 22 The transmitter center frequency leakage shall follow 17.3.9.6.1 for all transmissions in a 20 MHz channel 23 width. For transmissions in a 40 MHz channel width, the center frequency leakage shall not exceed –20 dB 24 relative to overall transmitted power, or, equivalently, 0 dB relative to the average energy of the rest of the 25 26 subcarriers. For upper or lower 20 MHz transmissions in a 40 MHz channel, the center frequency leakage 27 (center of a 40 MHz channel) shall not exceed –17 dB relative to overall transmitted power, or, equivalently, 28 0 dB relative to the average energy of the rest of the subcarriers. The transmit center frequency leakage is 29 specified per antenna. 30 31 32 20.3.21.7.3 Transmitter constellation error 33 34 35 The relative constellation frame averaged RMS error, calculated first by averaging over subcarriers, OFDM 36 frames, and spatial streams shall not exceed a data-rate dependent value according to Table 20-21. The num- 37 ber of spatial streams under test shall be equal to the number of utilized transmitting STA antenna (output) 38 39 ports and also equal to the number of utilized testing instrumentation input ports. In the test NSS = NSTS with 40 equal modulation MCSs shall be used. Each output port of the transmitting STA shall be connected through 41 a cable to one input port of the testing instrumentation. The same requirement applies both to 20 MHz chan- 42 43 nels and 40 MHz channels. 44 45 46 Table 20-21—Allowed relative constellation error versus constellation size and coding rate 47 48 49 Coding Modulation Relative constellation error (dB) 50 rate 51 52 BPSK 1/2 –5 53 54 QPSK 1/2 –10 55 56 QPSK 3/4 –13 57 16-QAM 1/2 –16 58 59 16-QAM 3/4 –19 60 61 64-QAM 2/3 –22 62 63 64-QAM 3/4 –25 64 65 64-QAM 5/6 –28

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 20.3.21.7.4 Transmitter modulation accuracy (EVM) test 2 3 The transmit modulation accuracy test shall be performed by instrumentation capable of converting the trans- 4 5 mitted signals into a streams of complex samples at 40 Msample/s or more, with sufficient accuracy in terms 6 of I/Q arm amplitude and phase balance, dc offsets, phase noise, and analog to digital quantization noise. Each 7 transmit chain is connected directly through a cable to the setup input port. A possible embodiment of such a 8 setup is converting the signals to a low IF frequency with a microwave synthesizer, sampling the signal with 9 a digital oscilloscope and decomposing it digitally into quadrature components. The sampled signal shall be 10 11 processed in a manner similar to an actual receiver, according to the following steps, or an equivalent proce- 12 dure: 13 a) Start of frame shall be detected. 14 15 b) Transition from short sequences to channel estimation sequences shall be detected, and fine timing 16 (with one sample resolution) shall be established. 17 18 c) Coarse and fine frequency offsets shall be estimated. 19 d) The frame shall be derotated according to estimated frequency offset. 20 21 e) The complex channel response coefficients shall be estimated for each of the subcarriers and each of 22 the transmit chains. 23 24 f) For each of the data OFDM symbols: transform the symbol into subcarrier received values, estimate 25 the phase from the pilot subcarriers in all spatial streams, derotate the subcarrier values according to 26 estimated phase, group the results from all the receiver chains in each subcarrier to a vector, multi- 27 ply the vector by a zero-forcing equalization matrix generated from the channel estimated during the 28 channel estimation phase. 29 30 g) For each data-carrying subcarrier in each spatial stream, find the closest constellation point and 31 compute the Euclidean distance from it. 32 33 h) Compute the average of the RMS of all errors in a frame. It is given by: 34 35 NSYM NSS NST 36 2 2 37    Iifis iss isc – I0ifis iss isc + Qifis iss isc – Q0ifis iss isc Nf  38 is = 1 iss = 1 isc = 1  ------39 NSYM  NSS  NST  P0 if = 1 40 ErrorRMS = ------41 Nf 42 (20-89) 43 44 45 where 46 N is the number of frames for the measurement 47 f 48 I i i i i  Q i i i i 49 0 f s ss sc 0 f s ss sc 50 51 denotes the ideal symbol point in the complex plane in subcarrier isc, spatial stream iss, and 52 OFDM symbol is of frame if 53 54 Iifis iss isc  Qifis iss isc 55 56 denotes the observed symbol point in the complex plane in subcarrier isc, spatial stream iss, and 57 OFDM symbol i of frame i 58 s f 59 60 P0 is the average power of the constellation 61 62 The vector error on a phase plane is shown in Figure 17-13. 63 64 65 The test shall be performed over at least 20 frames (Nf), and the average of the RMS shall be taken. The frames

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 under test shall be at least 16 OFDM symbols long. Random data shall be used for the symbols. 2 3 20.3.22 HT PMD receiver specification 4 5 6 20.3.22.1 Receiver minimum input sensitivity 7 8 The packet error rate (PER) shall be less than 10% for a PSDU length of 4096 octets with the rate-dependent 9 input levels listed in Table 20-22 or less. The minimum input levels are measured at the antenna connectors 10 11 and are referenced as the average power per receive antenna. The number of spatial streams under test shall 12 be equal to the number of utilized transmitting STA antenna (output) ports and also equal to the number of 13 utilized Device Under Test input ports. Each output port of the transmitting STA shall be connected through 14 a cable to one input port of the Device Under Test. The test in this subclause and the minimum sensitivity 15 levels specified in Table 20-22 only apply to non-STBC modes, MCSs 0-31, 800 ns GI, and BCC. 16 17 18 19 Table 20-22—Receiver minimum input level sensitivity 20 21 Adjacent Minimum 22 Minimum sensitivity Modulation Rate channel Non-adjacent channel sensitivity (dBm) 23 (dBm) (20 MHz channel (R) rejection rejection (dB) (40 MHz channel 24 spacing) 25 (dB) spacing) 26 27 BPSK 1/2 16 32 –82 –79 28 29 QPSK 1/2 13 29 –79 –76 30 QPSK 3/4 11 27 –77 –74 31 32 16-QAM 1/2 8 24 –74 –71 33 34 16-QAM 3/4 4 20 –70 –67 35 36 64-QAM 2/3 0 16 –66 –63 37 38 64-QAM 3/4 –1 15 –65 –62 39 64-QAM 5/6 –2 14 –64 –61 40 41 42 43 20.3.22.2 Adjacent channel rejection 44 45 46 For all transmissions in a 20 MHz channel width, the adjacent channel rejection shall be measured by setting 47 the desired signal's strength 3 dB above the rate dependent sensitivity specified in Table 20-22 and raising the 48 power of the interfering signal until 10% PER is caused for a PSDU length of 4096 octets. The power differ- 49 ence between the interfering and the desired channel is the corresponding adjacent channel rejection. The ad- 50 jacent channel center frequencies shall be separated by 20 MHz when operating in the 5 GHz band and the 51 52 adjacent channel center frequencies shall be separated by 25 MHz when operating in the 2.4 GHz band. For 53 all transmissions in a 40 MHz channel width, the adjacent channel rejection shall be measured by setting the 54 desired signal's strength 3 dB above the rate dependent sensitivity specified in Table 20-22 and raising the 55 power of the interfering signal until 10% PER is caused for a PSDU length of 4096 octets. The power differ- 56 ence between the interfering and the desired channel is the corresponding adjacent channel rejection. The ad- 57 58 jacent channel center frequencies shall be separated by 40 MHz. 59 60 The interfering signal in the adjacent channel shall be a conformant OFDM signal, unsynchronized with the 61 signal in the channel under test. For a conforming OFDM PHY, the corresponding rejection shall be no less 62 than specified in Table 20-22. The interference signal shall have a minimum duty cycle of 50%. 63 64 65 The test in this subclause and the adjacent channel rejection levels specified in Table 20-22 only apply to non-

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 STBC modes, MCSs 0–31, 800 ns GI, and BCC. 2 3 4 20.3.22.3 Non-adjacent channel rejection 5 6 For all transmissions in a 20 MHz channel width in the 5 GHz band, the non-adjacent channel rejection shall 7 be measured by setting the desired signal's strength 3 dB above the rate-dependent sensitivity specified in Ta- 8 ble 20-22, and raising the power of the interfering signal until a 10% PER occurs for a PSDU length of 4096 9 10 octets. The power difference between the interfering and the desired channel is the corresponding non-adja- 11 cent channel rejection. The non-adjacent channel center frequencies shall be separated by 40 MHz or more. 12 For all transmissions in a 40 MHz channel width in the 5 GHz band, the non-adjacent channel rejection shall 13 be measured by setting the desired signal's strength 3 dB above the rate-dependent sensitivity specified in Ta- 14 ble 20-22, and raising the power of the interfering signal until a 10% PER occurs for a PSDU length of 4096 15 16 octets. The power difference between the interfering and the desired channel is the corresponding non-adja- 17 cent channel rejection. The non-adjacent channel center frequencies shall be separated by 80 MHz or more. 18 19 The interfering signal in the non-adjacent channel shall be a conformant OFDM signal, unsynchronized with 20 21 the signal in the channel under test. For a conforming OFDM PHY, the corresponding rejection shall be no 22 less than specified in Table 20-22. The interference signal shall have a minimum duty cycle of 50%. The non- 23 adjacent channel rejection for transmissions in a 20 MHz or 40 MHz channel width is applicable only to 5 24 GHz band. 25 26 27 Non-adjacent channel rejection level specified in Table 20-22 and test only applies to non-STBC modes, 28 MCSs 0–31, 800 ns GI, and BCC. 29 30 20.3.22.4 Receiver maximum input level 31 32 33 The receiver shall provide a maximum PER of 10% at a PSDU length of 4096 octets, for a maximum input 34 level of –30 dBm in the 5 GHz band, and –20 dBm in the 2.4 GHz band, measured at each antenna for any 35 baseband modulation. 36 37 38 20.3.22.5 Clear Channel Assessment (CCA) sensitivity 39 40 CCA sensitivity requirements for non-HT PPDUs in the primary channel are described in 17.3.10.5 and 41 19.4.6. 42 43 44 20.3.22.5.1 Clear channel assessment (CCA) sensitivity in 20 MHz 45 46 The following paragraph describes the CCA sensitivity requirements for an HT STA with the operating chan- 47 48 nel width set to 20 MHz. 49 50 The start of a valid 20 MHz HT signal at a receive level equal to or greater than the minimum modulation and 51 coding rate sensitivity of –82 dBm shall cause the PHY to set PHY-CCA.indicate(BUSY) with a probability 52 53 > 90% within 4 s. The receiver shall hold the CCA signal busy for any signal 20 dB or more above the min- 54 imum modulation and coding rate sensitivity (–82 + 20 = –62 dBm) in the 20 MHz channel. 55 56 A receiver that does not support the reception of HT-GF format PPDUs shall hold the CCA signal busy 57 (PHY_CCA.indicate(BUSY)) for any valid HT-GF signal in the 20 MHz channel at a receive level equal to 58 59 or greater than –72 dBm. 60 61 20.3.22.5.2 Clear channel assessment (CCA) sensitivity in 40 MHz 62 63 64 The following paragraphs describe the CCA sensitivity requirements for an HT STA with the operating chan- 65 nel width set to 40 MHz.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 The receiver of a 20/40 MHz STA with the operating channel width set to 40 MHz shall provide CCA on both 2 the primary and secondary channels. 3 4 5 When the secondary channel is idle, the start of a valid 20 MHz HT signal in the primary channel at a receive 6 level equal to or greater than the minimum modulation and coding rate sensitivity of –82 dBm shall cause the 7 PHY to set PHY-CCA.indicate(BUSY, {primary}) with a probability > 90% within 4 s. The start of a valid 8 9 40 MHz HT signal that occupies both the primary channel and the secondary channel at a receive level equal 10 to or greater than the minimum modulation and coding rate sensitivity of –79 dBm shall cause the PHY to set 11 PHY-CCA.indicate(BUSY, {primary, secondary}) for both the primary channel and the secondary channel 12 with a probability per channel > 90% within 4 s. 13 14 15 A receiver that does not support the reception of HT-GF format PPDUs shall hold the CCA signal busy 16 (PHY_CCA.indicate(BUSY, {primary})) for any valid HT-GF signal in the primary channel at a receive level 17 equal to or greater than –72 dBm when the secondary channel is idle. A receiver that does not support the 18 reception of HT-GF format PPDUs shall hold both the 20 MHz primary channel CCA and the 20 MHz sec- 19 20 ondary channel CCA busy (PHY_CCA.indicate(BUSY, {primary, secondary})) for any valid 40 MHz HT- 21 GF signal in both the primary and the secondary channel at a receive level equal to or greater than –69 dBm. 22 23 The receiver shall hold the 20 MHz primary channel CCA signal busy for any signal at or above –62 dBm in 24 25 the 20 MHz primary channel. This level is 20 dB above the minimum modulation and coding rate sensitivity 26 for a 20 MHz PPDU. When the primary channel is idle, the receiver shall hold the 20 MHz secondary channel 27 CCA signal busy for any signal at or above –62 dBm in the 20 MHz secondary channel. The receiver shall 28 hold both the 20 MHz primary channel CCA and the 20 MHz secondary channel CCA busy for any signal 29 present in both the primary and secondary channel that is at or above –62 dBm in the primary channel and at 30 31 or above –62 dBm in the secondary channel. 32 33 20.3.22.6 Received channel power indicator (RCPI) measurement 34 35 36 The RCPI indicator is a measure of the received RF power in the selected channel. This parameter shall be a 37 measure by the PHY layer of the received RF power in the channel measured over the data portion of the re- 38 ceived frame. The received power shall be the average of the power in all active receive chains. RCPI shall 39 40 be a monotonically increasing, logarithmic function of the received power level defined in dBm. The allowed 41 values for the Received Channel Power Indicator (RCPI) parameter shall be an 8 bit value in the range from 42 0 through 220, with indicated values rounded to the nearest 0.5 dB as follows: 43 44 — 0: Power < –110 dBm 45 46 — 1: Power = –109.5 dBm 47 — 2: Power = –109.0 dBm 48 49 — and so on up to 50 51 — 220: Power > 0 dBm 52 53 — 221–254: reserved 54 55 — 255: Measurement not available 56 57 where 58 59 60 RCPI = int{(Power in dBm +110)*2} for 0 dBm > Power > –110 dBm (20-90) 61 62 RCPI shall equal the received RF power within an accuracy of +/– 5 dB (95% confidence interval) within the 63 64 specified dynamic range of the receiver. The received RF power shall be determined assuming a receiver 65 noise equivalent bandwidth equal to the channel width multiplied by 1.1.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 20.3.22.7 Reduced interframe Space (RIFS) 2 3 4 The receiver shall be able to decode a packet that was transmitted by a STA with a RIFS separation from the 5 previous packet. 6 7 20.3.23 PLCP transmit procedure 8 9 10 There are three options for transmit PLCP procedure. The first two options, for which typical transmit proce- 11 dures are shown in Figure 20-20 and Figure 20-21, are selected if the FORMAT field of PHY-TXSTART.re- 12 quest(TXVECTOR) is set to HT_MF or HT_GF, respectively. These transmit procedures do not describe the 13 operation of optional features, such as LDPC or STBC. The third option is to follow the transmit procedure 14 as in Clause 17 or Clause 19 if the FORMAT field is set to NON_HT. Additionally, if the FORMAT field is 15 16 set to NON_HT, CH_BANDWIDTH indicates NON_HT_CBW20, and NON_HT_MODULATION indi- 17 cates OFDM, follow the transmit procedure as in Clause 17. If the FORMAT field is set to NON_HT, 18 CH_BANDWIDTH indicates NON_HT_CBW20, and NON_HT_MODULATION indicates other than 19 OFDM, follow the transmit procedure as in Clause 19. And furthermore, if the FORMAT field is set to 20 NON_HT and CH_BANDWIDTH indicates NON_HT_CBW40, follow the transmit procedure as in Clause 21 22 17, except that the signal in Clause 17 is generated simultaneously on each of the upper and lower 20 MHz 23 channels that comprise the 40 MHz channel as defined in 20.3.8 and 20.3.11.11. In all these options, in order 24 to transmit data, PHY-TXSTART.request shall be enabled so that the PHY entity shall be in the transmit state. 25 Further, the PHY shall be set to operate at the appropriate frequency through station management via the 26 PLME, as specified in 20.4. Other transmit parameters, such as MCS Coding types and transmit power, are 27 28 set via the PHY-SAP with the PHY-TXSTART.request(TXVECTOR), as described in 20.2.2. 29 30 A clear channel shall be indicated by PHY-CCA.indication(IDLE). Note - under some circumstances, the 31 MAC uses the latest value of PHY-CCA.indication before issuing the PHY-TXSTART.request. Transmis- 32 33 sion of the PPDU shall be initiated after receiving the PHYTXSTART.request(TXVECTOR) primitive. The 34 TXVECTOR elements for the PHY-TXSTART.request are specified in Table 20-1. 35 36 The PLCP shall issue the parameters in the following PMD primitives to configure the PHY: 37 38 — PMD_TXPWRLVL 39 — PMD_TX_PARAMETERS 40 41 42 The PLCP shall then issue a PMD_TXSTART.request, and transmission of the PLCP preamble may start, 43 based on the parameters passed in the PHY-TXSTART.request primitive. The data shall then be exchanged 44 between the MAC and the PHY through a series of PHY-DATA.request(DATA) primitives issued by the 45 MAC, and PHY-DATA.confirm primitives issued by the PHY. Once PLCP preamble transmission is started, 46 47 the PHY entity shall immediately initiate data scrambling and data encoding. The encoding method shall be 48 based on the FEC_CODING, CH_BANDWIDTH, and MCS parameter of the TXVECTOR. A modulation 49 rate change, if any, shall be initiated starting with the SERVICE field data, as described in 20.3.2. 50 51 52 The PHY proceeds with PSDU transmission through a series of data octet transfers from the MAC. The SER- 53 VICE field and PSDU are encoded by the encoder selected by the FEC_CODING, CH_BANDWIDTH, and 54 MCS parameters of the TXVECTOR as described in 20.3.3. At the PMD layer, the data octets are sent in bit 55 0–7 order and presented to the PHY through PMD_DATA.request primitives. Transmission can be prema- 56 turely terminated by the MAC through the primitive PHY-TXEND.request. PHY-TXSTART shall be dis- 57 58 abled by receiving a PHY-TXEND.request. Normal termination occurs after the transmission of the final bit 59 of the last PSDU octet, according to the number supplied in the LENGTH field. 60 61 The packet transmission shall be completed and the PHY entity shall enter the receive state (i.e., PHYTX- 62 START shall be disabled). Each PHY-TXEND.request is acknowledged with a PHY-TXEND.confirm prim- 63 64 itive from the PHY. If the length of the coded PSDU (C-PSDU) is not an integral multiple of the OFDM 65 symbol length, bits shall be stuffed to make the C-PSDU length an integral multiple of the OFDM symbol

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 length. 2 3 In the PMD, the GI or short GI shall be inserted in every OFDM symbol as a countermeasure against delay 4 5 spread. 6 7 In some PPDU formats (as defined in 20.3.2)), a signal extension is present. When no signal extension is 8 present, the PHY-TXEND.confirm is generated at the end of last symbol of the PPDU. When a signal exten- 9 sion is present, the PHY-TXEND.confirm is generated at the end of the signal extension. 10 11 12 A typical state machine implementation of the transmit PLCP is provided in Figure 20-22. Requests (.req) 13 and confirmations(.confirm) are issued once per state as shown. This state machine does not describe the op- 14 eration of optional features, such as LDPC or STBC. 15 16 17 18 19 20 …………..………… 21 MAC PHY-DATA.request PHY-DATA.confirm PHY-TXEND.request PHY-TXEND.confirm

22 (TXVECTOR)

23 PHY-TXSTART.confirm PHY-DATA.request PHY-DATA.confirm MPDU 24 PHY-TXSTART.request 25 Tail Bits (if BCC) 26 L-SIG HT-SIG PSDU 27 28 Scrambling + encoding Bit Padding 29 IF needed Non-HT Training HT Training 30 L-SIG HT-SIG C-PSDU Signal Extension 31 symbols Symbols (if present) 32 33 PHY 34 PLCP 35 PMD_TXPWRLVL.request PMD_TX_PARAMETERS.request PMD_DATA.request 36

37 PMD_TXEND.request PHY 38 PMD_TXEND.indication PMD Non-HT 39 L-SIG HT-SIG HT-Training Data (Variable number of OFDM symbols) Preamble 40 Coded Coded OFDM OFDM Coded OFDM, MCS indicated in HT-SIG 41 BPSK, QBPSK, Rate ½ Rate ½ 42 NOTE—This procedure does 43 not describe the operation of 44 optional features, such as LDPC 45 or STBC 46 47 Figure 20-20—PLCP transmit procedure (HT-mixed format PPDU) 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 2 3 4 5 …………..………… 6 MAC PHY-DATA.request PHY-DATA.confirm 7 PHY-TXEND.request PHY-TXEND.confirm (TXVECTOR)

8 PHY-TXSTART.confirm PHY-DATA.request PHY-DATA.confirm MPDU 9 PHY-TXSTART.request 10 11 Tail Bits (if BCC) 12 HT-SIG PSDU 13 Scrambling + encoding Bit Padding 14 IF needed 15 16 HT_Training HT Training Signal Extension Part I HT-SIG C-PSDU (if present) 17 Symbols 18 19 PHY 20 PLCP 21 PMD_TXPWRLVL.request PMD_TX_PARAMETERS.request PMD_DATA.request 22 23 24 PHY PMD_TXEND.request

25 PMD PMD_TXEND.indication 26 HT-Training Data (Variable number of OFDM symbols) 27 Part I HT-SIG HT-Training 28 Coded OFDM Coded OFDM, MCS indicated in HT-SIG 29 QBPSK, 30 NOTE—This procedure does Rate ½ 31 not describe the operation of 32 optional features, such as LDPC 33 or STBC. 34 35 Figure 20-21—PLCP transmit procedure (HT-greenfield format PPDU) 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 2 PHY-TXSTART.request (TXVECTOR) TX PSDU OCTET PHY-DATA. 3 request(DATA) Get octet from MAC 4 and encoding 5 Initialize PHY-data.confirm 6 7 Length >1 Length =1 8 PMD_TXPWRLVL.request 9 PMD_RATE.request FORMAT=HT_MF OR TAIL APPEND PMD_TX_PARAMETERS.request FORMAT=NON_HT 10 PMD_EXPANSIONS_MAT.request Tails bits are appended 11 12 BIT PADDING 13 Tails bits are appended 14 FORMAT=HT_GF 15 TX GF HT-Preamble TX L-Preamble 16 TX SYMBOL 17 Tx HT Training Part I PMD_TXSTART.request Set symbol bit count 18 TX HT-SIG in TX Training Symbols PMD_DATA.request 19 QBPSK rate 1/2 TX L-SIG in BPSK rate 1/2 TX HT Training Bit Count > 0 20 FORMAT= HT_MF FORMAT= 21 NON_HT Decrement Bit 22 Refer to TX HT-Preamble clause 17 or Decrement bit count 23 19 by bits per symbol 24 Change Modulation to QBPSK, Bit Count = 0 25 TX HT-SIG TX HT Training 26 Decrement Length 27 Symbols 28 Decrement Length count Length >0 29 30 Length = 0 31 TX PLCP Data 32 Wait TX_END 33 Change coding rate PMD_TXEND.request 34 and modulation type TX encoded 16 bit 35 signal extension and 36 service field PMD_TXEND.indication 37 no signal Add Signal Extension 38 extension and 39 PMD_TXEND Wait for duration of SETUP MPDU TX .indication signal extension 40 PHY-DATA. 41 request(DATA) PHY-TXSTART.confirm 42 Set length count 43 Switch RX state 44 NOTE—This state machine A 45 At any stage in the does not describe the operation 46 A above flow diagram, if of optional features, such as a PHY- TXEND.request is 47 LDPC or STBC. 48 received 49 Figure 20-22—PLCP transmit state machine 50 51 52 20.3.24 PLCP receive procedure 53 54 Typical PLCP receive procedures are shown in Figure 20-23 and Figure 20-24. The receive procedures cor- 55 respond to HT-mixed format and HT-greenfield format, respectively. A typical state machine implementation 56 of the receive PLCP is given in Figure 20-25. These receive procedures and state machine do not describe the 57 58 operation of optional features, such as LDPC or STBC. If the detected format indicates a non-HT PPDU for- 59 mat, refer to the receive procedure and state machine in Clause 17 or Clause 19. Further, through station man- 60 agement (via the PLME) the PHY is set to the appropriate frequency, as specified in 20.4. Other receive 61 parameters, such as RSSI and indicated DATARATE, may be accessed via the PHY-SAP. 62 63 64 Upon receiving the transmitted PLCP preamble, PMD_RSSI.indication shall report a receive signal strength 65 to the PLCP. This indicates activity to the MAC via PHY-CCA.indication. PHY-CCA.indication(BUSY,

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 channel-list) shall also be issued as an initial indication of reception of a signal. The channel-list parameter 2 of the PHY-CCA.indication is determined as follows: 3 4 — It is absent when the operating channel width is 20 MHz 5 — It is set to {primary} when the operating channel width is 40 MHz and the signal is present only in 6 the primary channel 7 8 — It is set to {secondary} when the operating channel width is 40 MHz and the signal is present only in 9 the secondary channel 10 11 — It is set to {primary, secondary} when the operating channel width is 40 MHz and the signal is 12 present in both the primary and the secondary channels. 13 14 The PMD primitive PMD_RSSI is issued to update the RSSI and parameter reported to the MAC. 15 16 17 After the PHY-CCA.indication(BUSY, channel-list) is issued, the PHY entity shall begin receiving the train- 18 ing symbols and searching for SIGNAL and HT-SIG in order to set the length of the data stream, the demod- 19 ulation type, code type, and the decoding rate. If signal loss occurs before validating L-SIG and/or HT-SIG, 20 the HT PHY shall maintain PHY-CCA.indication(BUSY, channel-list) until the received level drops below 21 22 the CCA sensitivity level (for a missed preamble) specified in 20.3.22.5. If the check of the HT-SIG CRC is 23 not valid, a PHY-RXSTART.indication is not issued. The PHY shall issue the error condition PHY-RX- 24 END.indication(FormatViolation). The HT PHY shall maintain PHY-CCA.indication(BUSY, channel-list) 25 until the received level drops below the CCA sensitivity level (for a missed preamble) specified in 20.3.22.5. 26 27 28 If the PLCP preamble reception is successful and a valid HT-SIG CRC is indicated: 29 — Upon reception of an HT-mixed format preamble, the HT PHY shall maintain PHY-CCA.indica- 30 tion(BUSY, channel-list) for the predicted duration of the transmitted frame, as defined by TXTIME 31 in 20.4.3, for all supported and unsupported modes except Reserved HT-SIG Indication. Reserved 32 33 HT-SIG Indication is defined in the fourth bullet below. 34 — Upon reception of a GF preamble by an HT STA that does not support GF, PHY-CCA.indica- 35 tion(BUSY, channel-list) shall be maintained until either the predicted duration of the packet from 36 37 the contents of the HT-SIG field, as defined by TXTIME in 20.4.3, except Reserved HT-SIG Indica- 38 tion, or until the received level drops below the receiver minimum sensitivity level of BPSK, R=1/2 39 in Table 20-22 + 10 dB (–72 dBm for 20 MHz, –69 dBm for 40 MHz). Reserved HT-SIG Indication 40 is defined in the fourth bullet below. 41 42 — Upon reception of a GF preamble by an HT STA that supports GF, the HT PHY shall maintain PHY- 43 CCA.indication(BUSY, channel-list) for the predicted duration of the transmitted frame, as defined 44 by TXTIME in 20.4.3, for all supported and unsupported modes except Reserved HT-SIG Indica- 45 tion. Reserved HT-SIG Indication is defined in the fourth bullet below. 46 47 — If the HT-SIG indicates a Reserved HT-SIG Indication, the HT PHY shall maintain PHY-CCA.indi- 48 cation(BUSY, channel-list) until the received level drops below the CCA sensitivity level (minimum 49 modulation and coding rate sensitivity + 20 dB) specified in 20.3.22.5. Reserved HT-SIG Indication 50 is defined as an HT-SIG with MCS field in the range 77–127 or Reserved field = 0 or STBC field = 51 52 3 and any other HT-SIG field bit combinations that do not correspond to modes of PHY operation 53 defined in Clause 20. 54 55 Subsequent to an indication of a valid HT-SIG CRC, a PHY-RXSTART.indication(RXVECTOR) shall be 56 issued. The RXVECTOR associated with this primitive includes the parameters specified in Table 20-1. 57 58 Upon reception of a GF preamble by an HT STA that does not support GF, the FORMAT field of RXVEC- 59 TOR is set to HT_GF and the remaining fields may be empty, and the PHY shall issue the error condition 60 PHY-RXEND.indication(FormatViolation). If the HT-SIG indicates an unsupported mode or Reserved HT- 61 SIG Indication the PHY shall issue the error condition PHY-RXEND.indication(UnsupportedRate). 62 63 64 Following training and signal fields, the coded PSDU (C-PSDU) (which comprises the coded PLCP SER- 65 VICE field and scrambled and coded PSDU) shall be received. If signal loss occurs during reception prior to

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 completion of the PSDU reception, the error condition PHY-RXEND.indication(CarrierLost) shall be report- 2 ed to the MAC. After waiting for the intended end of the PSDU, if no signal extension is present (as defined 3 in 20.3.2), the PHY shall set PHY-CCA.indication(IDLE) and return to RX IDLE state. Otherwise, the re- 4 5 ceiver waits for the duration of the signal extension before returning to the RX IDLE state. 6 7 The received PSDU bits are assembled into octets, decoded, and presented to the MAC using a series of PHY- 8 9 DATA.indication(DATA) primitive exchanges. The number of PSDU octets is indicted in the HT Length 10 field of the HT-SIG. The PHY shall proceed with PSDU reception. After the reception of the final bit of the 11 last PSDU octet, and possible tail and padding bits, the receiver shall be returned to the RX IDLE state, if no 12 signal extension is present (as defined in 20.3.2), as shown in Figure 20-25. Otherwise, the receiver waits for 13 the duration of the signal extension before returning to the RX IDLE state. A PHY-RXEND.indication(No- 14 15 Error) primitive shall be issued on entry to the RX IDLE state. 16 17 While in the Signal Extension state, if the receiver detects a CS/CCA event, it issues an RXEND.indication 18 (with the RXERROR parameter set to NoError or CarrierLost, depending on whether a carrier lost event oc- 19 20 curred during the reception of the PPDU), leaves the Signal Extension state and enters the Detect SIG state. 21 This occurs when signal-extended PPDUs are transmitted separated by a RIFS. 22 23 24 If the binary convolutional code is used, any data received after the indicated data length are considered pad 25 bits (to fill out an OFDM symbol) and should be discarded. 26 27 28 29 30 31 CS/CCA state RX state 32 33 34 35 36 37

MAC PHY-CCA.ind (STATUS=busy) 38 PHY-RXEND.ind RXVECTOR) (NoError, PHY-DATA.ind PHY-DATA.ind PHY-CCA.ind (IDLE) 39 PHY-RXSTART.ind (RXVECTOR) 40 MPDU 41

42 Decoding Delay 43 L-SIG HT-SIG PSDU Tail Bits (if BCC 44 used) Issued at Decoded and 45 the same descrambled time 46 L-SIG HT-SIG C-PSDU Signal Extension 47 (if present) 48 49 PHY Bit removing IF needed 50 PLCP 51 PMD_RSSI.ind PMD_Data.ind(first) PMD_FORMAT.ind PMD_BW_OFFSET.ind

52 PMD_CHAN_MAT.ind 53 54 PHY L-STF L-LTF L-SIG HT-SIG HT-Training Data (Variable number of OFDM symbols) 55 PMD 56 Coded Coded OFDM OFDM Coded OFDM, MCS indicated in HT-SIG 57 BPSK, QBPSK, 58 Rate ½ Rate ½ 59 60 NOTE—This procedure does 61 not describe the operation of 62 optional features, such as LDPC 63 or STBC. 64 65 Figure 20-23—PLCP receive procedure for HT-mixed format PLCP format

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 2 CS/CCA state RX state 3 4 5 6 7 8 9 MAC PHY-CCA.ind (STATUS=busy) PHY-DATA.ind PHY-DATA.ind PHY-RXEND.ind RXVECTOR) (NoError, 10 PHY-CCA.ind (IDLE) PHY-RXSTART.ind (RXVECTOR) 11 MPDU 12 13 14 15 HT-SIG PSDU Tail Bits 16 (if BCC Decoded and used) Issued at the 17 descrambled same time 18 Signal Extension 19 HT-SIG C-PSDU (if present) 20 21 Bit removing 22 PHY IF needed 23 PLCP PMD_Data.ind(first)

24 PMD_BW_OFFSET .ind PMD_FORMAT.ind 25 PMD_RSSI.ind PMD_CHAN_MAT.ind 26

27 PHY HT-Training HT-SIG HT-Training Data (Variable number of OFDM symbols) 28 PMD Part I Coded 29 OFDM Coded OFDM, MCS indicated in HT-SIG 30 QBPSK, Rate ½ 31 32 33 NOTE—This procedure does 34 not describe the operation of 35 optional features, such as LDPC 36 or STBC. 37 38 Figure 20-24—PLCP receive procedure for HT-greenfield format PLCP 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 2 RX IDLE state 3 4 CS/CCA 5 Set PHY_CCA.ind(BUSY) 6 7 End of Wait Detect SIG A 8 RX Symbol 9 Set Determine type of HT_SIG (GF preamble) PHY_CCA.ind(ID SIG field 10 LE) when receive PMD_DATA.ind 11 level drops below L-SIG (MM or non-HT threshold (missed preamble) 12 preamble) Valid Signal 13 Detect L-SIG Carrier lost Carrier Lost 14 Receive L-SIG Set field Signal Not Valid Decode Symbol 15 PHY_RXEND.indicate 16 (CarrierLost) Signal Valid Set RxEndStatus Decode and 17 = (CarrierLost, descramble 18 RX L-SIG Null) symbol 19 RX and test 20 Parity 21 Not HT-SIG: 22 Refer to 17.3.12 Decrement Time Decrement Length Detect HT-SIG or 19.3.6 23 Carrier Lost Determine Wait for intended PHY_DATA.ind(DATA) (bit removing if needed) 24 Set whether HT-SIG end of PSDU Decrement length count Length PHY_RXEND.indicate follows L-SIG >0 25 (CarrierLost) HT_SIG Time=0 26 Length=0 27 RX HT-SIG 28 CRC Fail: End of Wait End of PSDU RX 29 Set RX and test CRC PHY_RXEND.indica Set RxEndStatus = Check for Signal (NoError,RXVECTOR) 30 te(FormatViolation) Extension Check for Signal 31 CRC OK Extension

32 End of Wait Check Preamble 33 Unsupported Type no signal signal signal no signal Set Preamble: extension extension Check for HT_GF extension extension 34 PHY_CCA.ind(ID Set LE) when receive PHY_RXSTART. or HT_MF 35 level drops below ind preamble type Signal Extension (RXVECTOR) 36 threshold then set CS/CCA (minimum PHY_RXEND.in Supported Preamble 37 detected. Wait for duration of modulation and dicate(FormatVio lation) Evaluate HT-SIG A Set signal extension 38 coding rate PHY_RXE sensitivity + 10 39 Check contents in ND.ind((Rx dB) 40 HT-SIG for EndStatus) supported mode 41 Unsupported mode: Supported 42 Set End of Wait PHY_RXSTART.ind mode 43 (RXVECTOR) Set Setup PSDU RX 44 then set PHY_CCA.ind(IDLE). 45 PHY_RXEND.indicat Set Length Set e(UnsupportedRate) Set PHY_RXEND.ind(Rx 46 PHY_RXSTART.ind EndStatus) 47 (RXVECTOR) 48 End of Wait 49 For Reserved HT-SIG For unsupported Indication: set 50 modes: set PHY_CCA.ind(IDLE) 51 PHY_CCA.ind(IDLE) when receive level 52 when predicted drops below threshold duration based on (minimum modulation 53 NOTE—This state machine does not describe the operation TXTIME has elapsed and coding rate of optional features, such as LDPC or STBC. 54 sensitivity + 20 dB) 55 56 Figure 20-25—PLCP receive state machine 57 58 59 20.4 HT PLME 60 61 20.4.1 PLME_SAP sublayer management primitives 62 63 64 Table 20-23 lists the MIB attributes that may be accessed by the PHY entities and the intralayer of higher 65 level LMEs. These attributes are accessed via the PLME-GET, PLME-SET, PLME-RESET, and PLME-

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 CHARACTERISTICS primitives defined in 10.4. 2 3 4 20.4.2 PHY Management Information Base 5 6 HT PHY MIB attributes are defined in Annex D with specific values defined in Table 20-23. The column 7 8 titled “Operational semantics” in Table 20-23 contains two types: static and dynamic: 9 — Static MIB attributes are fixed and cannot be modified for a given PHY implementation. 10 11 — Dynamic MIB attributes are interpreted according to the MAX-ACCESS field of the MIB variable. 12 When MAX-ACCESS is set to read-only the MIB variable value may be updated by the PLME and 13 14 read from the MIB variable by management entities. When MAX-ACCESS is set to read-write the 15 MIB variable may be read and written by management entities. 16 17 18 Table 20-23—HT PHY MIB attributes 19 20 21 Operational Managed Object Default value/range 22 semantics 23 24 dot11PHYOperationTable 25 26 dot11PHYType HT (X’07’) Static 27 28 dot11CurrentRegDomain Implementation Dynamic 29 dependent 30 31 dot11TempType Implementation Static 32 dependent 33 34 dot11PHYAntennaTable 35 dot11CurrentTxAntenna Implementation Dynamic 36 dependent 37 38 dot11DiversitySupport Implementation Static 39 dependent 40 41 dot11CurrentRxAntenna Implementation Dynamic 42 dependent 43 dot11AntennaSelectionOptionImplemented False/Boolean Static 44 45 dot11TransmitExplicitCSIFeedbackASOptionImplemented False/Boolean Static 46 47 dot11TransmitIndicesFeedbackASOptionImplemented False/Boolean Static 48 49 dot11ExplicitCSIFeedbackASOptionImplemented False/Boolean Static 50 51 dot11TransmitIndicesComputationASOptionImplemented False/Boolean Static 52 dot11ReceiveAntennaSelectionOptionImplemented False/Boolean Static 53 54 dot11TransmitSoundingPPDUOptionImplemented False/Boolean Static 55 56 dot11PHYTxPowerTable 57 58 dot11NumberSupportedPowerLevels Implementation Static 59 dependent 60 61 dot11TxPowerLevel1 Implementation Static 62 dependent 63 64 dot11TxPowerLevel2 Implementation Static 65 dependent

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table 20-23—HT PHY MIB attributes (continued) 2 3 4 dot11TxPowerLevel3 Implementation Static 5 dependent 6 7 dot11TxPowerLevel4 Implementation Static 8 dependent 9 dot11TxPowerLevel5 Implementation Static 10 dependent 11 12 dot11TxPowerLevel6 Implementation Static 13 dependent 14 15 dot11TxPowerLevel7 Implementation Static 16 dependent 17 18 dot11TxPowerLevel8 Implementation Static 19 dependent 20 21 dot11CurrentTxPowerLevel Implementation Dynamic 22 dependent 23 24 dot11PhyDSSSTable 25 dot11CurrentChannel Implementation Dynamic 26 dependent 27 28 dot11RegDomainsSupportedTable 29 30 dot11RegDomainsSupported Implementation Static 31 dependent 32 33 dot11FrequencyBandsSupported Implementation Static 34 dependent 35 36 dot11PHYAntennasListTable 37 dot11SupportedTxAntenna Implementation Dynamic 38 dependent 39 40 dot11SupportedRxAntenna Implementation Static 41 dependent 42 43 dot11DiversitySelectionRx Implementation Dynamic 44 dependent 45 46 dot11SupportedDataRatesTxTable 47 48 dot11SupportedDataratesTxValue X'02' = 1 Mb/s (2.4) Static 49 X'04' = 2 Mb/s (2.4) 50 X'0B' = 5.5 Mb/s 51 (2.4) 52 X'16' = 11 Mb/s (2.4) 53 X'0C' = 6 Mb/s 54 X'12' = 9 Mb/s 55 X'18' = 12 Mb/s 56 X'24' = 18 Mb/s 57 X'2C = 22 Mb/s 58 X'30' = 24 Mb/s 59 X'42 = 33 Mb/s 60 X'48' = 36 Mb/s 61 X'60' = 48 Mb/s 62 X'6C' = 54 Mb/s 63 64 dot11SupportedDataRatesRxTable 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table 20-23—HT PHY MIB attributes (continued) 2 3 4 dot11SupportedDataratesRxValue X'02' = 1 Mb/s (2.4) Static 5 X'04' = 2 Mb/s (2.4) 6 X'0B' = 5.5 Mb/s 7 (2.4) 8 X'16' = 11 Mb/s (2.4) 9 X'0C' = 6 Mb/s 10 X'12' = 9 Mb/s 11 X'18' = 12 Mb/s 12 X'24' = 18 Mb/s 13 X'2C = 22 Mb/s 14 X'30' = 24 Mb/s 15 X'42 = 33 Mb/s 16 X'48' = 36 Mb/s 17 X'60' = 48 Mb/s 18 X'6C' = 54 Mb/s 19 20 dot11HRDSSSPHYTable 21 dot11ShortPreambleOptionImplemented True Static 22 23 dot11PBCCOptionImplemented Implementation Static 24 dependent 25 26 dot11ChannelAgilityPresent False/Boolean Static 27 28 dot11ChannelAgilityEnabled False/Boolean Static 29 30 dot11PHYOFDMTable 31 32 dot11CurrentFrequency Implementation Dynamic 33 dependent 34 dot11TIThreshold Implementation Dynamic 35 dependent 36 37 dot11 Channel starting factor Implementation Dynamic 38 dependent 39 40 dot11PHYERPTable 41 42 dot11ERP-PBCCOptionImplemented Implementation Static 43 dependent 44 45 dot11DSSS-OFDMOptionImplemented Implementation Static 46 dependent 47 dot11DSSS-OFDMOptionEnabled Implementation Dynamic 48 dependent 49 50 dot11ShortSlotTimeOptionImplemented Implementation Static 51 dependent 52 53 dot11ShortSlotTimeOptionEnabled Implementation Dynamic 54 dependent 55 56 dot11PHYHTTable 57 58 dot11FortyMHzOperationImplemented False/Boolean Static 59 60 dot11FortyMHzOperationEnabled False/Boolean Dynamic 61 dot11CurrentPrimaryChannel Implementation Dynamic 62 dependent 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table 20-23—HT PHY MIB attributes (continued) 2 3 4 dot11CurrentSecondaryChannel Implementation Dynamic 5 dependent 6 7 dot11NumberOfSpatialStreamsImplemented Implementation Static 8 dependent 9 dot11NumberOfSpatialStreamsEnabled Implementation Dynamic 10 dependent 11 12 dot11HTGreenfieldOptionImplemented False/Boolean Static 13 14 dot11HTGreenfieldOptionEnabled False/Boolean Dynamic 15 16 dot11ShortGIOptionInTwentyImplemented False/Boolean Static 17 18 dot11ShortGIOptionInTwentyEnabled False/Boolean Dynamic 19 dot11ShortGIOptionInFortyImplemented False/Boolean Static 20 21 dot11ShortGIOptionInFortyEnabled False/Boolean Dynamic 22 23 dot11LDPCCodingOptionImplemented False/Boolean Static 24 25 dot11LDPCCodingOptionEnabled False/Boolean Dynamic 26 27 dot11TxSTBCOptionImplemented False/Boolean Static 28 dot11TxSTBCOptionEnabled False/Boolean Dynamic 29 30 dot11RxSTBCOptionImplemented False/Boolean Static 31 32 dot11RxSTBCOptionEnabled False/Boolean Dynamic 33 34 dot11BeamFormingOptionImplemented False/Boolean Static 35 36 dot11BeamFormingOptionEnabled False/Boolean Dynamic 37 38 dot11HTSupportedMCSTxTable 39 dot11SupportedMCSTxValue MCS 0–76 for 20 Static 40 MHz; 41 MCS 0–76 for 40 42 MHz 43 (MCS 0–7 for 20 44 MHz mandatory at 45 non-AP STA; MCS 46 0–15 for 20 MHz 47 mandatory at AP) 48 49 dot11HTSupportedMCSRxTable 50 51 dot11SupportedMCSRxValue MCS 0–76 for 20 Static 52 MHz; 53 54 MCS 0–76 for 40 55 MHz 56 (MCS 0–7 for 20 57 MHz mandatory at 58 non-AP STA; MCS 59 60 0–15 for 20 MHz 61 mandatory at AP) 62 63 dot11TransmitBeamformingConfigTable 64 dot11ReceiveStaggerSoundingOptionImplemented False/Boolean Static 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table 20-23—HT PHY MIB attributes (continued) 2 3 4 dot11TransmitStaggerSoundingOptionImplemented False/Boolean Static 5 6 dot11ReceiveNDPOptionImplemented False/Boolean Static 7 dot11TransmitNDPOptionImplemented False/Boolean Static 8 9 dot11ImplicitTransmitBeamformingOptionImplemented False/Boolean Static 10 11 dot11CalibrationOptionImplemented Implementation Static 12 dependent 13 14 dot11ExplicitCSITransmitBeamformingOptionImplemented False/Boolean Static 15 16 dot11ExplicitNonCompressedBeamformingMatrixOptionImplemented False/Boolean Static 17 dot11ExplicitTransmitBeamformingCSIFeedbackOptionImplemented Implementation Static 18 dependent 19 20 dot11ExplicitNoncompressedBeamformingFeedbackOptionImplemented Implementation Static 21 dependent 22 23 dot11ExplicitCompressedBeamformingFeedbackOptionImplemented Implementation Static 24 dependent 25 26 dot11NumberBeamFormingCSISupportAntenna Implementation Static 27 dependent 28 29 dot11NumberNonCompressedBeamformingMatrixSupportAntenna Implementation Static 30 dependent 31 dot11NumberCompressedBeamformingMatrixSupportAntenna Implementation Static 32 dependent 33 34 dot11TxMCSSetDefined False/Boolean Static 35 36 dot11TxRxMCSSetNotEqual False/Boolean Static 37 38 dot11TxMaximumNumberSpatialStreamsSupported False/Boolean Static 39 40 dot11TxUnequalModulationSupported False/Boolean Static 41 42 43 20.4.3 TXTIME calculation 44 45 46 The value of the TXTIME parameter returned by the PLME-TXTIME.confirm primitive or calculated for the 47 PLCP receive procedure shall be calculated for HT-mixed format according to the Equation (20-91) and 48 Equation (20-92) for short and regular GI, and for HT-greenfield format according to Equation (20-93) and 49 50 Equation (20-94) for short and regular GI, respectively: 51 52 53 TXTIME = T ++T T +T (20-91) 54 LEG_PREAMBLE L_SIG HT_PREAMBLE HT_SIG 55 T  N 56 ++T  Ceiling------SYMS SYM- SignalExtension SYM  57 TSYM 58 59 60 TXTIME = TLEG_PREAMBLE ++TL_SIG THT_PREAMBLE +THT_SIG (20-92) 61 62 ++TSYM  NSYM SignalExtension 63 64 65 TXTIME = TGF_HT_PREAMBLE ++THT_SIG TSYMS  NSYM +SignalExtension (20-93)

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 TXTIME = T ++T T  N +SignalExtension (20-94) 2 GF_HT_PREAMBLE HT_SIG SYM SYM 3 4 where 5 6 TLEG_PREAMBLE = TL-STF + TL-LTF is the duration of the non-HT preamble 7 8 THT_PREAMBLE is the duration of the HT preamble in HT-mixed format, given by: 9 T ++T N – 1 T 10 HT– STF HT– LTF1 LTF HT– LTFs 11 T is the duration of the preamble in HT-greenfield format, given by: 12 GF_HT_PREAMBLE 13 THT– GF – STF ++THT– LTF1 NLTF – 1 THT– LTFs , 14 15 T , T , T , T , T , T , T , T and T are defined in Table 16 SYM SYMS HT-SIG L-STF HT-STF HT-GF-STF L-LTF HT-LTF1 HT-LTFs 17 20-5 18 SignalExtension is 0 µs when TXVECTOR parameter NO_SIG_EXTN is TRUE, and is the duration of 19 20 signal extension as defined by aSignalExtension in Table 20-4 of 20.4.4 when TXVECTOR 21 parameter NO_SIG_EXTN is FALSE 22 23 NLTF is defined in Equation (20-22) 24 N is the total number of data symbols in the data portion, which may be calculated according to 25 SYM 26 Equation (20-95) 27 28 8  length ++16 6  N 29 ES NSYM =mSTBC  Ceil ------When BCC is used 30 mSTBC  NDBPS (20-95) 31 N 32 avbits NSYM =------When LDPC is used 33 NCBPS 34 35 where 36 37 length is the number of octets in the data portion of the PPDU 38 39 mSTBC is equal to 2 when space time block code (STBC) is used, and otherwise 1 40 41 NES and NCBPS are defined in Table 20-6 42 43 NDBPS is defined in Table 20-28 44 45 Navbits is defined in Equation (20-39) 46 47 For non-HT modes of operation refer to Clause 17 and Clause 19 for TXTIME calculations, except that 48 49 frames transmitted with a value of NON_HT_DUP_OFDM for the TXVECTOR parameter 50 NON_HT_MODULATION shall use equation (19-6) for TXTIME calculation. 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 20.4.4 PHY characteristics 2 3 The static HT PHY characteristics, provided through the PLME-CHARACTERISTICS service primitive, 4 5 shall be as shown in Table 20-24. The definitions for these characteristics are given in 10.4. 6 7 8 Table 20-24—MIMO PHY characteristics 9 10 11 Characteristics Value 12 13 aRIFSTime 2 µs 14 15 aSlotTime When operating in the 2.4 GHz band: 16 long = 20 µs, short = 9 µs 17 18 When operating in the 5 GHz band: 19 9 µs 20 21 aSIFSTime 10 µs when operating in the 2.4 GHz band and 22 16 µs when operating in the 5 GHz bands 23 aSignalExtension 0 µs when operating in the 5 GHz band, 24 6 µs when operating in the 2.4 GHz band 25 26 aCCATime < 4 µs 27 28 aPHY-RX-START-Delay 33 µs for both MF and GF 29 30 aRxTxTurnaroundTime < 2 µs 31 32 aTxPLCPDelay Implementation dependent 33 aRxPLCPDelay Implementation dependent 34 35 aRxTxSwitchTime << 1 µs 36 37 aTxRampOnTime Implementation dependent 38 39 aTxRampOffTime Implementation dependent 40 41 aTxRFDelay Implementation dependent 42 aRxRFDelay Implementation dependent 43 44 aAirPropagationTime << 1 µs 45 46 aMACProcessingDelay < 2 µs 47 48 aPreambleLength 16 µs 49 50 aSTFOneLength 8 µs 51 aSTFTwoLength 4 µs 52 53 aLTFOneLength 8 µs 54 55 aLTFTwoLength 4 µs 56 57 aPLCPHeaderLength 4 µs 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table 20-24—MIMO PHY characteristics (continued) 2 3 4 Characteristics Value 5 6 aPLCPSigTwoLength 8 µs 7 8 aPLCPServiceLength 16 bits 9 10 aPLCPConvolutionalTailLength 6 bits 11 aPSDUMaxLength 65535 octets 12 13 aPPDUMaxTime 10 ms 14 15 aIUStime 8 µs 16 17 aDTT2UTTTime, 32 µs 18 19 aCWmin 15 20 aCWmax 1023 21 22 aMaxCSIMatricesReportDelay 250 ms 23 24 25 26 For non-HT modes of operation refer to Clause 17 and Clause 19 for PHY characteristics. 27 28 29 20.5 HT PMD sublayer 30 31 20.5.1 Scope and field of application 32 33 34 The PMD services provided to the PLCP for the High Throughput (HT) PHY are described in 20.5. Also de- 35 fined in this subclause are the functional, electrical, and RF characteristics required for interoperability of im- 36 plementations conforming to this specification. The relationship of this specification to the entire HT PHY is 37 shown in Figure 20-26. 38 39 40 41 42 43 44 HT PLCP Sublayer 45 46 47 48 49 PMD_SAP PHY Station PHY Layer 50 Management Management 51 52 53 54 HT PMD Sublayer 55 56 57 58 59 60 61 Figure 20-26—PMD layer reference model 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 20.5.2 Overview of service 2 3 4 The HT PMD sublayer accepts PLCP sublayer service primitives and provides the actual means by which 5 data are transmitted or received from the medium. The combined function of the HT PMD sublayer primitives 6 and parameters for the receive function results in a data stream, timing information, and associated receive 7 signal parameters being delivered to the PLCP sublayer. A similar functionality is provided for data transmis- 8 sion. 9 10 11 20.5.3 Overview of interactions 12 13 The primitives provided by the HT PMD fall into two basic categories: 14 15 a) Service primitives that support PLCP peer-to-peer interactions; 16 17 b) Service primitives that have local significance and support sublayer-to-sublayer interactions. 18 19 20.5.4 Basic service and options 20 21 22 20.5.4.1 Status of service primitives 23 24 All of the service primitives described in 20.5.4 are mandatory, unless otherwise specified. 25 26 27 20.5.4.2 PMD_SAP peer-to-peer service primitives 28 29 30 Table 20-25 indicates the primitives for peer-to-peer interactions. 31 32 33 Table 20-25—PMD_SAP peer-to-peer service primitives 34 35 36 Primitive Request Indicate Confirm Response 37 38 PMD_DATA X X — — 39 40 41 42 20.5.4.3 PMD_SAP sublayer-to-sublayer service primitives 43 44 Table 20-26 indicates the primitives for sublayer-to-sublayer interactions. 45 46 47 20.5.4.4 PMD_SAP service primitive parameters 48 49 50 Table 20-27 shows the parameters used by one or more of the PMD_SAP service primitives. 51 52 20.5.5 PMD_SAP detailed service specification 53 54 55 20.5.5.1 Introduction to PMD_SAP service specification 56 57 20.5.5.2 to 20.5.5.13 describe the services provided by each PMD primitive. 58 59 60 20.5.5.2 PMD_DATA.request 61 62 20.5.5.2.1 Function 63 64 65 This primitive defines the transfer of data from the PLCP sublayer to the PMD entity.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table 20-26—PMD_SAP sublayer-to-sublayer service primitives 2 3 4 Primitive Request Indicate Confirm Response 5 6 PMD_TXSTART X — — — 7 8 PMD_TXEND X — — — 9 10 PMD_TXPWRLVL X — — — 11 PMD_TX_PARAMETERS X — — — 12 13 PMD_RSSI — X — — 14 15 PMD_RCPI — X — — 16 17 PMD_CHAN_MAT — X — — 18 19 PMD_FORMAT — X — — 20 PMD_CBW_OFFSET — X — — 21 22 23 24 20.5.5.2.2 Semantics of the service primitive 25 26 27 This primitive shall provide the following parameters: PMD_DATA.request (TXD_UNIT) 28 29 The TXD_UNIT parameter shall be the n-bit combination of 0 and 1 for one symbol of OFDM modulation. 30 If the length of a coded PSDU (C-PSDU) is shorter than n bits, 0 bits are added to form an OFDM symbol. 31 32 This parameter represents a single block of data that, in turn, shall be used by the PHY to be encoded into an 33 OFDM transmitted symbol. 34 35 20.5.5.2.3 When generated 36 37 38 This primitive shall be generated by the PLCP sublayer to request transmission of one OFDM symbol. 39 40 20.5.5.2.4 Effect of receipt 41 42 43 The PMD performs transmission of the data. 44 45 46 20.5.5.3 PMD_DATA.indication 47 48 20.5.5.3.1 Function 49 50 51 This primitive defines the transfer of data from the PMD entity to the PLCP sublayer. 52 53 20.5.5.3.2 Semantics of the service primitive 54 55 56 This primitive shall provide the following parameter: PMD_DATA.indication(RXD_UNIT) 57 58 The RXD_UNIT parameter shall be 0 or 1, and shall represent either a SIGNAL field bit or a data field bit 59 60 after the decoding of the FEC by the PMD entity. 61 62 20.5.5.3.3 When generated 63 64 65 This primitive, generated by the PMD entity, forwards received data to the PLCP sublayer.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table 20-27—List of parameters for the PMD primitives 2 3 4 Parameter Associate primitive Value 5 6 TXD_UNIT PMD_DATA.request One OFDM symbol value, NDBPS bits (depending on 7 MCS) 8 9 RXD_UNIT PMD_DATA.indication Bit, either 0 or 1 10 11 TXPWR_LEVEL PMD_TXPWRLVL.request 1 to 8 (max of 8 levels) 12 MCS PMD_TX_PARAMETERS.request 0 to 76, MCS index defined in 20.6 13 14 CH_BANDWIDT PMD_TX_PARAMETERS.request The CH_BANDWIDTH parameter indicates whether the 15 H PMD_CBW_OFFSET.indication packet is transmitted using 40 MHz or 20 MHz channel 16 width. 17 Enumerated type: 18 HT_CBW20, for 20 MHz, and 40 MHz Upper and 19 Lower modes 20 HT_CBW40, for 40 MHz. 21 22 CH_OFFSET PMD_TX_PARAMETERS.request Enumerated type: 23 PMD_CBW_OFFSET.indication CH_OFF_20 indicates the use of a 20 MHz channel (that 24 is not part of a 40 MHz channel). 25 CH_OFF_40 indicates the entire 40 MHz channel. 26 CH_OFF_20U indicates the upper 20 MHz of the 40 27 MHz channel 28 CH_OFF_20L indicates the lower 20 MHz of the 40 29 MHz channel. 30 31 STBC PMD_TX_PARAMETERS.request Set to a non-zero number, indicates the difference 32 between the number of space time streams NSTS and the 33 number of spatial streams NSS indicated by the MCS 34 Set to 00 indicates no STBC (NSTS=NSS) 35 36 GI_TYPE PMD_TX_PARAMETERS.request Set to 0 indicates Short GI is not used in the packet 37 Set to 1 indicates Short GI is used in the packet 38 ANTENNA_SET PMD_TX_PARAMETERS.request Bit field with 8 bits 39 40 EXPANSION_MAT PMD_TX_PARAMETERS.request N + N complex matrices of size N  N 41 SD SP TX STS 42 43 EXPANSION_MAT PMD_TX_PARAMETERS.request COMPRESSED_SV: EXPANSION_MAT contains a set 44 _TYPE of compressed beamforming matrices. 45 NON_COMPRESSED_SV: EXPANSION_MAT con- 46 tains a set of non-compressed beamforming matrices. 47 CSI_MATRICES: EXPANSION_MAT contains a set of 48 CSI matrices 49 RSSI PMD_RSSI.indication 0 to 255 50 51 RCPI PMD_RCPI.indication 0 to 255 – see 20.3.22.6 for definition of each value. 52 53 CHAN_MAT PMD_CHAN_MAT.indicationNSD + NSP complex matrices of size NRX  NSTS 54 55 FORMAT PMD_FORMAT.indication Set to 0 for NON_HT 56 Set to 1 for HT_MF 57 Set to 2 for HT_GF 58 59 FEC_CODING PMD_TX_PARAMETERS.request Indicates whether Binary Convolutional Code (BCC) or 60 Low Density Parity Check (LDPC) encoding is used. 61 Enumerated type: 62 BCC_CODING indicates Binary Convolutional Code. 63 LDPC_CODING indicates Low Density Parity Check 64 code. 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 20.5.5.3.4 Effect of receipt 2 3 The PLCP sublayer decodes the bits that it receives from the PMD and either interprets them as part of its 4 5 own signaling or passes them to the MAC sublayer as part of the PSDU after any necessary additional pro- 6 cessing (e.g. descrambling). 7 8 20.5.5.4 PMD_TXSTART.request 9 10 11 20.5.5.4.1 Function 12 13 This primitive, generated by the PHY PLCP sublayer, initiates PPDU transmission by the PMD layer. 14 15 20.5.5.4.2 Semantics of the service primitive 16 17 18 This primitive has no parameters. 19 20 20.5.5.4.3 When generated 21 22 23 This primitive shall be generated by the PLCP sublayer to initiate the PMD layer transmission of the PPDU. 24 The PHY-TXSTART.request primitive shall be provided to the PLCP sublayer prior to issuing the 25 PMD_TXSTART command. 26 27 28 20.5.5.4.4 Effect of receipt 29 30 PMD_TXSTART initiates transmission of a PPDU by the PMD sublayer. 31 32 20.5.5.5 PMD_TXEND.request 33 34 35 20.5.5.5.1 Function 36 37 This primitive, generated by the PHY PLCP sublayer, ends PPDU transmission by the PMD layer. 38 39 40 20.5.5.5.2 Semantics of the service primitive 41 42 This primitive has no parameters. 43 44 20.5.5.5.3 When generated 45 46 47 This primitive shall be generated by the PLCP sublayer to terminate the PMD layer transmission of the PPDU. 48 49 20.5.5.5.4 Effect of receipt 50 51 52 PMD_TXEND terminates transmission of a PPDU by the PMD sublayer. 53 54 20.5.5.6 PMD_TXEND.confirm 55 56 20.5.5.6.1 Function 57 58 59 This primitive, generated by the PMD entity indicates the end of PPDU transmission by the PMD layer. It is 60 generated at the 4µs boundary following the trailing boundary of the last symbol transmitted. 61 62 20.5.5.6.2 Semantics of the service primitive 63 64 65 This primitive has no parameters.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 20.5.5.6.3 When generated 2 3 4 This primitive shall be generated by the PMD entity at the 4µs boundary following the trailing boundary of 5 the last symbol transmitted. 6 7 20.5.5.6.4 Effect of receipt 8 9 10 The PLCP sublayer determines that transmission of the last symbol of the PPDU is complete, which is used 11 as a timing reference in the PLCP state machines. See 20.3.23. 12 13 14 20.5.5.7 PMD_TXPWRLVL.request 15 16 20.5.5.7.1 Function 17 18 19 This primitive, generated by the PHY PLCP sublayer, selects the power level used by the PHY for transmis- 20 sion. 21 22 23 20.5.5.7.2 Semantics of the service primitive 24 25 This primitive shall provide the following parameter: PMD_TXPWRLVL.request (TXPWR_LEVEL) 26 27 28 TXPWR_LEVEL selects which of the transmit power levels should be used for the current packet transmis- 29 sion. The number of available power levels shall be determined by the MIB parameter aNumberSupported- 30 PowerLevels. See 20.3.21.3 for further information on the OFDM PHY power level control capabilities. 31 32 33 20.5.5.7.3 When generated 34 35 This primitive shall be generated by the PLCP sublayer to select a specific transmit power. This primitive 36 37 shall be applied prior to setting PMD_TXSTART into the transmit state. 38 39 20.5.5.7.4 Effect of receipt 40 41 42 PMD_TXPWRLVL immediately sets the transmit power level to that given by TXPWR_LEVEL. 43 44 20.5.5.8 PMD_RSSI.indication 45 46 47 20.5.5.8.1 Function 48 49 50 This primitive, generated by the PMD sublayer, provides the receive signal strength to the PLCP and MAC 51 entity. 52 53 20.5.5.8.2 Semantics of the service primitive 54 55 56 This primitive shall provide the following parameter: PMD_RSSI.indication (RSSI) 57 58 The RSSI shall be a measure of the RF energy received by the HT PHY. RSSI indications of up to 8 bits (256 59 60 levels) are supported. 61 62 20.5.5.8.3 When generated 63 64 65 This primitive shall be generated by the PMD after the reception of the HT training fields.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 20.5.5.8.4 Effect of receipt 2 3 4 This parameter shall be provided to the PLCP layer for information only. The RSSI may be used as part of a 5 CCA scheme. 6 7 20.5.5.9 PMD_RCPI.indication 8 9 10 20.5.5.9.1 Function 11 12 This primitive, generated by the PMD sublayer, provides the received channel power indicator to the PLCP 13 14 and MAC entity. 15 16 20.5.5.9.2 Semantics of the service primitive 17 18 19 The primitive shall provide the following parameter: PMD_RCPI.indication(RCPI). 20 21 The RCPI is a measure of the channel power received by the OFDM PHY. RCPI measurement and parameter 22 values are defined in 20.3.22.6. 23 24 25 20.5.5.9.3 When generated 26 27 This primitive shall be generated by the PMD when the OFDM PHY is in the receive state. It is generated at 28 29 the end of the last received symbol. 30 31 20.5.5.9.4 Effect of receipt 32 33 34 This parameter shall be provided to the PLCP layer for information only. The RCPI may be used in conjunc- 35 tion with RSSI to measure input signal quality. 36 37 20.5.5.10 PMD_TX_PARAMETERS.request 38 39 40 20.5.5.10.1 Function 41 42 This primitive, generated by the PHY PLCP sublayer, selects the related parameters used by the PHY for 43 44 transmission. 45 46 20.5.5.10.2 Semantics of the service primitive 47 48 49 This primitive shall provide the following parameters: 50 51 PMD_TX_PARAMETERS.request (MCS, CH_BANDWIDTH, CH_OFFSET, STBC, GI_TYPE, 52 ANTENNA_SET, FEC_CODING, PMD_EXPANSIONS_MAT, PMD_EXPANSIONS_MAT_TYPE) 53 54 55 20.5.5.10.3 When generated 56 57 This primitive shall be generated by the PLCP sublayer to select a specific transmit parameter. This primitive 58 59 shall be applied prior to setting PMD_TXSTART into the transmit state. 60 61 20.5.5.10.4 Effect of receipt 62 63 64 PMD_TX_PARAMETERS immediately sets the transmit parameters. The receipt of these parameters selects 65 the values that shall be used for all subsequent PPDU transmissions

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 20.5.5.11 PMD_CBW_OFFSET.indication 2 3 20.5.5.11.1 Function 4 5 6 This primitive, generated by the PMD sublayer, provides the bandwidth and channel offset of the received 7 frame to the PLCP and MAC entity. 8 9 20.5.5.11.2 Semantics of the service primitive 10 11 12 This primitive shall provide the following parameter: PMD_CBW_OFFSET.indication (CH_BANDWIDTH, 13 CH_OFFSET) 14 15 CH_BANDWIDTH represents channel width (20 MHz or 40 MHz) in which the data is transmitted, and the 16 17 transmission format (non-HT duplicate or MCS 32). CH_OFFSET indicates in a 20 MHz bandwidth, in a 20 18 MHz sub-channel of the 40 MHz channel (upper or lower), or in the entire 40 MHz channel. 19 20 20.5.5.11.3 When generated 21 22 23 This primitive shall be generated by the PMD when the OFDM PHY is in the receive state. It shall be avail- 24 able continuously to the PLCP that, in turn, shall provide the parameter to the MAC entity. 25 26 20.5.5.11.4 Effect of receipt 27 28 29 The PLCP sublayer passes the data to the MAC sublayer as part of the RXVECTOR. 30 31 20.5.5.12 PMD_CHAN_MAT.indication 32 33 34 20.5.5.12.1 Function 35 36 This primitive, generated by the PMD sublayer, provides the channel response matrices to the PLCP and 37 MAC entity. 38 39 40 20.5.5.12.2 Semantics of the service primitive 41 42 This primitive shall provide the following parameter: PMD_CHAN_MAT.indication (CHAN_MAT) 43 44 The CHAN_MAT parameter contains the channel response matrices that were measured during the reception 45 46 of the current frame. 47 48 20.5.5.12.3 When generated 49 50 This primitive shall be generated by the PMD when the OFDM PHY is in the receive state. It shall be avail- 51 52 able continuously to the PLCP that, in turn, shall provide the parameter to the MAC entity. 53 54 20.5.5.12.4 Effect of receipt 55 56 The PLCP sublayer passes the data to the MAC sublayer as part of the RXVECTOR. 57 58 59 20.5.5.13 PMD_FORMAT.indication 60 61 20.5.5.13.1 Function 62 63 64 This primitive, generated by the PMD sublayer, provides the format of the received frame to the PLCP and 65 MAC entity.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 20.5.5.13.2 Semantics of the service primitive 2 3 This primitive shall provide the following parameter: PMD_FORMAT.indication (FORMAT). 4 5 6 The format indicates one of the PPDU formats: non HT, HT-mixed format or HT-greenfield format. 7 8 20.5.5.13.3 When generated 9 10 11 This primitive shall be generated by the PMD after the reception of the HT training fields. 12 13 20.5.5.13.4 Effect of receipt 14 15 The PLCP sublayer passes the data to the MAC sublayer as part of the RXVECTOR. 16 17 18 19 20.6 Parameters for HT Modulation and Coding Schemes (MCS) 20 21 Table 20-28 defines the symbols used in the rate dependent parameter tables. 22 23 24 Table 20-28—Symbols used in MCS parameter tables 25 26 27 Symbol Explanation 28 29 N Number of spatial streams 30 SS 31 R Coding rate 32 33 NBPSC Number of coded bits per single carrier (total 34 across spatial streams) 35 36 NBPSCS(iSS) Number of coded bits per single carrier for 37 each spatial stream, iSS = 1,...,NSS 38 N Number of complex data numbers per spatial 39 SD stream per OFDM symbol 40 41 N Number of pilot values per OFDM symbol 42 SP 43 NCBPS Number of coded bits per OFDM symbol 44 45 NDBPS Number of data bits per OFDM symbol 46 47 NES Number of BCC encoders for the DATA 48 field 49 N Total bits per subcarrier 50 TBPS 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 The rate dependent parameters for mandatory 20 MHz, NSS = 1 MCSs with NES = 1 shall be as shown in 2 Table 20-29. 3 4 5 6 Table 20-29—MCS parameters for mandatory 20 MHz, NSS = 1, NES = 1 7 8 9 10 Data rate (Mb/s) 11 MCS Modulation R N (i )N N N N 12 Index BPSCS SS SD SP CBPS DBPS 400 ns GI 800 ns GI 13 see NOTE 14 15 0 BPSK 1/2 1 52 4 52 26 6.5 7.2 16 17 1 QPSK 1/2 2 52 4 104 52 13.0 14.4 18 19 2 QPSK 3/4 2 52 4 104 78 19.5 21.7 20 21 3 16-QAM 1/2 4 52 4 208 104 26.0 28.9 22 4 16-QAM 3/4 4 52 4 208 156 39.0 43.3 23 24 5 64-QAM 2/3 6 52 4 312 208 52.0 57.8 25 26 6 64-QAM 3/4 6 52 4 312 234 58.5 65.0 27 28 7 64-QAM 5/6 6 52 4 312 260 65.0 72.2 29 30 NOTE—Support of 400 ns guard interval is optional on transmit and receive 31 32 33 The rate dependent parameters for optional 20 MHz, N = 2 MCSs with N = 1 and equal modulation of 34 SS ES 35 the spatial streams shall be as shown in Table 20-30. 36 37 38 Table 20-30—MCS parameters for optional 20 MHz, NSS = 2, NES = 1, EQM 39 40 41 42 Data rate (Mb/s) 43 MCS 44 Modulation R N (i )N N N N Index BPSCS SS SD SP CBPS DBPS 400 ns GI 45 800 ns GI 46 See NOTE 47 48 8 BPSK 1/2 1 52 4 104 52 13.0 14.4 49 9 QPSK 1/2 2 52 4 208 104 26.0 28.9 50 51 10 QPSK 3/4 2 52 4 208 156 39.0 43.3 52 53 11 16-QAM 1/2 4 52 4 416 208 52.0 57.8 54 55 12 16-QAM 3/4 4 52 4 416 312 78.0 86.7 56 57 13 64-QAM 2/3 6 52 4 624 416 104.0 115.6 58 14 64-QAM 3/4 6 52 4 624 468 117.0 130.0 59 60 15 64-QAM 5/6 6 52 4 624 520 130.0 144.4 61 62 NOTE—The 400 ns GI rate values are rounded to 1 decimal place 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 The rate dependent parameters for optional 20 MHz, NSS = 3 MCSs with NES = 1 and equal modulation of 2 the spatial streams shall be as shown in Table 20-31. 3 4 5 6 Table 20-31—MCS parameters for optional 20 MHz, NSS = 3, NES = 1, EQM 7 8 9 10 Data rate (Mb/s) MCS 11 Modulation R N (i )N N N N Index BPSCS SS SD SP CBPS DBPS 12 800 ns GI 400 ns GI 13 14 16 BPSK 1/2 1 52 4 156 78 19.5 21.7 15 16 17 QPSK 1/2 2 52 4 312 156 39.0 43.3 17 18 18 QPSK 3/4 2 52 4 312 234 58.5 65.0 19 20 19 16-QAM 1/2 4 52 4 624 312 78.0 86.7 21 20 16-QAM 3/4 4 52 4 624 468 117.0 130.0 22 23 21 64-QAM 2/3 6 52 4 936 624 156.0 173.3 24 25 22 64-QAM 3/4 6 52 4 936 702 175.5 195.0 26 27 23 64-QAM 5/6 6 52 4 936 780 195.0 216.7 28 29 30 31 The rate dependent parameters for optional 20 MHz, NSS = 4 MCSs with NES = 1 and equal modulation of 32 the spatial streams shall be as shown in Table 20-32. 33 34 35 Table 20-32—MCS parameters for optional 20 MHz, N = 4, N = 1, EQM 36 SS ES 37 38 39 Data rate (Mb/s) 40 MCS 41 Modulation R NBPSCS(iSS)NSD NSP NCBPS NDBPS Index 1 42 800 ns GI 400 ns GI 43 44 24 BPSK 1/2 1 52 4 208 104 26.0 28.9 45 46 25 QPSK 1/2 2 52 4 416 208 52.0 57.8 47 26 QPSK 3/4 2 52 4 416 312 78.0 86.7 48 49 27 16-QAM 1/2 4 52 4 832 416 104.0 115.6 50 51 28 16-QAM 3/4 4 52 4 832 624 156.0 173.3 52 53 29 64-QAM 2/3 6 52 4 1248 832 208.0 231.1 54 55 30 64-QAM 3/4 6 52 4 1248 936 234.0 260.0 56 31 64-QAM 5/6 6 52 4 1248 1040 260.0 288.9 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 The rate dependent parameters for optional 40 MHz, NSS = 1 MCSs with NES = 1 shall be as shown in Table 2 20-33. 3 4 5 6 Table 20-33—MCS parameters for optional 40 MHz, NSS = 1, NES = 1 7 8 Data rate (Mb/s) 9 MCS Modulation R N (i )N N N N 10 Index BPSCS SS SD SP CBPS DBPS 11 800 ns GI 400 ns GI 12 13 0 BPSK 1/2 1 108 6 108 54 13.5 15.0 14 15 1 QPSK 1/2 2 108 6 216 108 27.0 30.0 16 17 2 QPSK 3/4 2 108 6 216 162 40.5 45.0 18 3 16-QAM 1/2 4 108 6 432 216 54.0 60.0 19 20 4 16-QAM 3/4 4 108 6 432 324 81.0 90.0 21 22 5 64-QAM 2/3 6 108 6 648 432 108.0 120.0 23 24 6 64-QAM 3/4 6 108 6 648 486 121.5 135.0 25 26 7 64-QAM 5/6 6 108 6 648 540 135.0 150.0 27 28 29 The rate dependent parameters for optional 40 MHz, N = 2 MCSs with N = 1 and equal modulation of 30 SS ES 31 the spatial streams shall be as shown in Table 20-34. 32 33 34 Table 20-34—MCS parameters for optional 40 MHz, NSS = 2, NES = 1, EQM 35 36 37 Data rate (Mb/s) MCS 38 Modulation R N (i )N N N N Index BPSCS SS SD SP CBPS DBPS 39 800 ns GI 400 ns GI 40 41 8 BPSK 1/2 1 108 6 216 108 27.0 30.0 42 43 9 QPSK 1/2 2 108 6 432 216 54.0 60.0 44 45 10 QPSK 3/4 2 108 6 432 324 81.0 90.0 46 47 11 16-QAM 1/2 4 108 6 864 432 108.0 120.0 48 49 12 16-QAM 3/4 4 108 6 864 648 162.0 180.0 50 13 64-QAM 2/3 6 108 6 1296 864 216.0 240.0 51 52 14 64-QAM 3/4 6 108 6 1296 972 243.0 270.0 53 54 15 64-QAM 5/6 6 108 6 1296 1080 270.0 300.0 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 The rate dependent parameters for optional 40 MHz, NSS = 3 MCSs, with equal modulation of the spatial 2 streams shall be as shown in Table 20-35. 3 4 5 6 Table 20-35—MCS parameters for optional 40 MHz, NSS = 3, EQM 7 8 Data rate (Mb/s) 9 MCS Modulation R N (i )N N N N N 10 Index BPSCS SS SD SP CBPS DBPS ES 11 800 ns GI 400 ns GI 12 13 16 BPSK 1/2 1 108 6 324 162 1 40.5 45.0 14 15 17 QPSK 1/2 2 108 6 648 324 1 81.0 90.0 16 17 18 QPSK 3/4 2 108 6 648 486 1 121.5 135.0 18 19 16-QAM 1/2 4 108 6 1296 648 1 162.0 180.0 19 20 20 16-QAM 3/4 4 108 6 1296 972 1 243.0 270.0 21 22 21 64-QAM 2/3 6 108 6 1944 1296 2 324.0 360.0 23 24 22 64-QAM 3/4 6 108 6 1944 1458 2 364.5 405.0 25 26 23 64-QAM 5/6 6 108 6 1944 1620 2 405.0 450.0 27 28 29 The rate dependent parameters for optional 40 MHz, N = 4 MCSs, with equal modulation of the spatial 30 SS 31 streams shall be as shown in Table 20-36. 32 33 34 Table 20-36—MCS parameters for optional 40 MHz, NSS = 4, EQM 35 36 37 Data rate (Mb/s) MCS 38 Modulation R N (i )N N N N N Index BPSCS SS SD SP CBPS DBPS ES 39 800 ns GI 400 ns GI 40 41 24 BPSK 1/2 1 108 6 432 216 1 54.0 60.0 42 43 25 QPSK 1/2 2 108 6 864 432 1 108.0 120.0 44 45 26 QPSK 3/4 2 108 6 864 648 1 162.0 180.0 46 47 27 16-QAM 1/2 4 108 6 1728 864 1 216.0 240.0 48 49 28 16-QAM 3/4 4 108 6 1728 1296 2 324.0 360.0 50 29 64-QAM 2/3 6 108 6 2592 1728 2 432.0 480.0 51 52 30 64-QAM 3/4 6 108 6 2592 1944 2 486.0 540.0 53 54 31 64-QAM 5/6 6 108 6 2592 2160 2 540.0 600.0 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 The rate dependent parameters for optional 40 MHz MCS 32 format with NSS = 1 and NES = 1 shall be shall 2 be as shown in Table 20-37. 3 4 5 6 Table 20-37—MCS parameters for optional 40 MHz MCS 32 format, NSS = 1, NES = 1 7 8 Data rate (Mb/s) 9 MCS Modulation R N (i )N N N N 10 Index BPSCS SS SD SP CBPS DBPS 11 800 ns GI 400 ns GI 12 13 32 BPSK 1/2 1 48 4 48 24 6.0 6.7 14 15 16 17 The rate dependent parameters for optional 20 MHz, NSS = 2 MCSs with NES = 1 and unequal modulation of 18 the spatial streams shall be as shown in Table 20-38. 19 20 21 22 Table 20-38—MCS parameters for optional 20 MHz, NSS = 2, NES = 1, UEQM 23 24 25 Modulation Data rate (Mb/s) 26 MCS Index RNBPSC NSD NSP NCBPS NDBPS 27 Stream 1 Stream 2 800 ns GI 400 ns GI 28 29 33 16-QAM QPSK 1/2 6 52 4 312 156 39 43.3 30 31 34 64-QAM QPSK 1/2 8 52 4 416 208 52 57.8 32 35 64-QAM 16-QAM 1/2 10 52 4 520 260 65 72.2 33 34 36 16-QAM QPSK 3/4 6 52 4 312 234 58.5 65.0 35 36 37 64-QAM QPSK 3/4 8 52 4 416 312 78 86.7 37 38 38 64-QAM 16-QAM 3/4 10 52 4 520 390 97.5 108.3 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 The rate dependent parameters for optional 20 MHz, NSS = 3 MCSs with NES = 1 and unequal modulation of 2 the spatial streams shall be as shown in Table 20-39. 3 4 5 6 Table 20-39—MCS parameters for optional 20 MHz, NSS = 3, NES = 1, UEQM 7 8 9 Modulation Data rate (Mb/s) MCS 10 RN N N N N 11 Index BPSC SD SP CBPS DBPS 800 ns 400 ns Stream 1 Stream 2 Stream 3 12 GI GI 13 14 39 16-QAM QPSK QPSK 1/2 8 52 4 416 208 52 57.8 15 16 40 16-QAM 16-QAM QPSK 1/2 10 52 4 520 260 65 72.2 17 18 41 64-QAM QPSK QPSK 1/2 10 52 4 520 260 65 72.2 19 42 64-QAM 16-QAM QPSK 1/2 12 52 4 624 312 78 86.7 20 21 43 64-QAM 16-QAM 16-QAM 1/2 14 52 4 728 364 91 101.1 22 23 44 64-QAM 64-QAM QPSK 1/2 14 52 4 728 364 91 101.1 24 25 45 64-QAM 64-QAM 16-QAM 1/2 16 52 4 832 416 104 115.6 26 27 46 16-QAM QPSK QPSK 3/4 8 52 4 416 312 78 86.7 28 47 16-QAM 16-QAM QPSK 3/4 10 52 4 520 390 97.5 108.3 29 30 48 64-QAM QPSK QPSK 3/4 10 52 4 520 390 97.5 108.3 31 32 49 64-QAM 16-QAM QPSK 3/4 12 52 4 624 468 117 130.0 33 34 50 64-QAM 16-QAM 16-QAM 3/4 14 52 4 728 546 136.5 151.7 35 36 51 64-QAM 64-QAM QPSK 3/4 14 52 4 728 546 136.5 151.7 37 52 64-QAM 64-QAM 16-QAM 3/4 16 52 4 832 624 156 173.3 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 The rate dependent parameters for optional 20 MHz, NSS = 4 MCSs with NES = 1 and unequal modulation in 2 the spatial streams shall be as shown in Table 20-40. 3 4 5 6 Table 20-40—MCS parameters for optional 20 MHz, NSS = 4, NES = 1, UEQM 7 8 Data rate 9 Modulation (Mb/s) 10 MCS RN N N N N 11 Index BPSC SD SP CBPS DBPS 12 800 ns 400 ns Stream 1 Stream 2 Stream 3 Stream 4 13 GI GI 14 15 53 16-QAM QPSK QPSK QPSK 1/2 10 52 4 520 260 65 72.2 16 17 54 16-QAM 16-QAM QPSK QPSK 1/2 12 52 4 624 312 78 86.7 18 19 55 16-QAM 16-QAM 16-QAM QPSK 1/2 14 52 4 728 364 91 101.1 20 56 64-QAM QPSK QPSK QPSK 1/2 12 52 4 624 312 78 86.7 21 22 57 64-QAM 16-QAM QPSK QPSK 1/2 14 52 4 728 364 91 101.1 23 24 58 64-QAM 16-QAM 16-QAM QPSK 1/2 16 52 4 832 416 104 115.6 25 26 59 64-QAM 16-QAM 16-QAM 16-QAM 1/2 18 52 4 936 468 117 130.0 27 28 60 64-QAM 64-QAM QPSK QPSK 1/2 16 52 4 832 416 104 115.6 29 61 64-QAM 64-QAM 16-QAM QPSK 1/2 18 52 4 936 468 117 130.0 30 31 62 64-QAM 64-QAM 16-QAM 16-QAM 1/2 20 52 4 1040 520 130 144.4 32 33 63 64-QAM 64-QAM 64-QAM QPSK 1/2 20 52 4 1040 520 130 144.4 34 35 64 64-QAM 64-QAM 64-QAM 16-QAM 1/2 22 52 4 1144 572 143 158.9 36 37 65 16-QAM QPSK QPSK QPSK 3/4 10 52 4 520 390 97.5 108.3 38 66 16-QAM 16-QAM QPSK QPSK 3/4 12 52 4 624 468 117 130.0 39 40 67 16-QAM 16-QAM 16-QAM QPSK 3/4 14 52 4 728 546 136.5 151.7 41 42 68 64-QAM QPSK QPSK QPSK 3/4 12 52 4 624 468 117 130.0 43 44 69 64-QAM 16-QAM QPSK QPSK 3/4 14 52 4 728 546 136.5 151.7 45 46 70 64-QAM 16-QAM 16-QAM QPSK 3/4 16 52 4 832 624 156 173.3 47 71 64-QAM 16-QAM 16-QAM 16-QAM 3/4 18 52 4 936 702 175.5 195.0 48 49 72 64-QAM 64-QAM QPSK QPSK 3/4 16 52 4 832 624 156 173.3 50 51 73 64-QAM 64-QAM 16-QAM QPSK 3/4 18 52 4 936 702 175.5 195.0 52 53 74 64-QAM 64-QAM 16-QAM 16-QAM 3/4 20 52 4 1040 780 195 216.7 54 55 75 64-QAM 64-QAM 64-QAM QPSK 3/4 20 52 4 1040 780 195 216.7 56 76 64-QAM 64-QAM 64-QAM 16-QAM 3/4 22 52 4 1144 858 214.5 238.3 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 The rate dependent parameters for optional 40 MHz, NSS = 2 MCSs with NES = 1 and unequal modulation of 2 the spatial streams shall be as shown in Table 20-41. 3 4 5 6 Table 20-41—MCS parameters for optional 40 MHz, NSS = 2, NES = 1, UEQM 7 8 9 Modulation Data rate (Mb/s) 10 MCS Index RNBPSC NSD NSP NCBPS NDBPS 11 Stream 1 Stream 2 800 ns GI 400 ns GI 12 13 33 16-QAM QPSK 1/2 6 108 6 648 324 81 90 14 15 34 64-QAM QPSK 1/2 8 108 6 864 432 108 120 16 17 35 64-QAM 16-QAM 1/2 10 108 6 1080 540 135 150 18 36 16-QAM QPSK 3/4 6 108 6 648 486 121.5 135 19 20 37 64-QAM QPSK 3/4 8 108 6 864 648 162 180 21 22 38 64-QAM 16-QAM 3/4 10 108 6 1080 810 202.5 225 23 24 25 26 The rate dependent parameters for optional 40 MHz, NSS = 3 MCSs, with unequal modulation of the spatial 27 streams shall be as shown in Table 20-42. 28 29 30 31 Table 20-42—MCS parameters for optional 40 MHz, NSS = 3, UEQM 32 33 34 Modulation Data rate (Mb/s) MCS 35 RN N N N N N Index BPSC SD SP CBPS DBPS ES 800 ns 400 ns 36 Stream 1 Stream 2 Stream 3 37 GI GI 38 39 39 16-QAM QPSK QPSK 1/2 8 108 6 864 432 1 108 120 40 41 40 16-QAM 16-QAM QPSK 1/2 10 108 6 1080 540 1 135 150 42 41 64-QAM QPSK QPSK 1/2 10 108 6 1080 540 1 135 150 43 44 42 64-QAM 16-QAM QPSK 1/2 12 108 6 1296 648 1 162 180 45 46 43 64-QAM 16-QAM 16-QAM 1/2 14 108 6 1512 756 1 189 210 47 48 44 64-QAM 64-QAM QPSK 1/2 14 108 6 1512 756 1 189 210 49 50 45 64-QAM 64-QAM 16-QAM 1/2 16 108 6 1728 864 1 216 240 51 46 16-QAM QPSK QPSK 3/4 8 108 6 864 648 1 162 180 52 53 47 16-QAM 16-QAM QPSK 3/4 10 108 6 1080 810 1 202.5 225 54 55 48 64-QAM QPSK QPSK 3/4 10 108 6 1080 810 1 202.5 225 56 57 49 64-QAM 16-QAM QPSK 3/4 12 108 6 1296 972 1 243 270 58 59 50 64-QAM 16-QAM 16-QAM 3/4 14 108 6 1512 1134 1 283.5 315 60 51 64-QAM 64-QAM QPSK 3/4 14 108 6 1512 1134 1 283.5 315 61 62 52 64-QAM 64-QAM 16-QAM 3/4 16 108 6 1728 1296 2 324 360 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 The rate dependent parameters for optional 40 MHz, NSS = 4 MCSs, with unequal modulation of the spatial 2 streams shall be as shown in Table 20-43. 3 4 5 6 Table 20-43—MCS parameters for optional 40 MHz, NSS = 4, UEQM 7 8 Data rate 9 Modulation (Mb/s) 10 MCS RN N N N N N 11 Index BPSC SD SP CBPS DBPS ES 12 Stream Stream Stream Stream 800 ns 400 ns 13 1 2 3 4 GI GI 14 15 53 16- QPSK QPSK QPSK 1/2 10 108 6 1080 540 1 135 150 16 QAM 17 18 54 16- 16- QPSK QPSK 1/2 12 108 6 1296 648 1 162 180 19 QAM QAM 20 21 55 16- 16- 16- QPSK 1/2 14 108 6 1512 756 1 189 210 22 QAM QAM QAM 23 56 64- QPSK QPSK QPSK 1/2 12 108 6 1296 648 1 162 180 24 QAM 25 26 57 64- 16- QPSK QPSK 1/2 14 108 6 1512 756 1 189 210 27 QAM QAM 28 29 58 64- 16- 16- QPSK 1/2 16 108 6 1728 864 1 216 240 30 QAM QAM QAM 31 32 59 64- 16- 16- 16- 1/2 18 108 6 1944 972 1 243 270 33 QAM QAM QAM QAM 34 35 60 64- 64- QPSK QPSK 1/2 16 108 6 1728 864 1 216 240 36 QAM QAM 37 61 64- 64- 16- QPSK 1/2 18 108 6 1944 972 1 243 270 38 QAM QAM QAM 39 40 62 64- 64- 16- 16- 1/2 20 108 6 2160 1080 1 270 300 41 QAM QAM QAM QAM 42 43 63 64- 64- 64- QPSK 1/2 20 108 6 2160 1080 1 270 300 44 QAM QAM QAM 45 46 64 64- 64- 64- 16- 1/2 22 108 6 2376 1188 1 297 330 47 QAM QAM QAM QAM 48 49 65 16- QPSK QPSK QPSK 3/4 10 108 6 1080 810 1 202.5 225 50 QAM 51 66 16- 16- QPSK QPSK 3/4 12 108 6 1296 972 1 243 270 52 QAM QAM 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table 20-43—MCS parameters for optional 40 MHz, NSS = 4, UEQM (continued) 2 3 4 Data rate Modulation 5 (Mb/s) MCS 6 RN N N N N N Index BPSC SD SP CBPS DBPS ES 7 Stream Stream Stream Stream 800 ns 400 ns 8 1 2 3 4 GI GI 9 10 67 16- 16- 16- QPSK 3/4 14 108 6 1512 1134 1 283.5 315 11 QAM QAM QAM 12 13 68 64- QPSK QPSK QPSK 3/4 12 108 6 1296 972 1 243 270 14 QAM 15 16 69 64- 16- QPSK QPSK 3/4 14 108 6 1512 1134 1 283.5 315 17 QAM QAM 18 19 70 64- 16- 16- QPSK 3/4 16 108 6 1728 1296 2 324 360 20 QAM QAM QAM 21 71 64- 16- 16- 16- 3/4 18 108 6 1944 1458 2 364.5 405 22 QAM QAM QAM QAM 23 24 72 64- 64- QPSK QPSK 3/4 16 108 6 1728 1296 2 324 360 25 QAM QAM 26 27 73 64- 64- 16- QPSK 3/4 18 108 6 1944 1458 2 364.5 405 28 QAM QAM QAM 29 30 74 64- 64- 16- 16- 3/4 20 108 6 2160 1620 2 405 450 31 QAM QAM QAM QAM 32 33 75 64- 64- 64- QPSK 3/4 20 108 6 2160 1620 2 405 450 34 QAM QAM QAM 35 76 64- 64- 64- 16- 3/4 22 108 6 2376 1782 2 445.5 495 36 QAM QAM QAM QAM 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Annex A (normative) PICS 2 3 4 5 6 A.4 PICS proforma–IEEE Std 802.11-2007 7 8 9 A.4.3 IUT configuration 10 11 12 Change PICS items CF10, CF11, and CF12 and insert CF16 at the end of the table as follows: 13 14 15 16 Item IUT configuration References Status Support 17 18 *CF10 Is spectrum management operation sup- 7.3.1.4, 11.6 (CF6 OR Yes  No  19 ported? 20 CF16):O 21 *CF11 Is regulatory classes capability 7.3.2.12, (CF6 OR Yes  No  22 23 implemented? 17.3.8.3.2, CF16)& N/A  24 17.3.8.6, CF8&CF10:O 25 17.4.2, 26 Annex I, 27 Annex J 28 29 *CF12 QoS 9.9, 9.10, 5.2.9 O Yes  No  30 N/A 31 CF16:M  32 33 *CF16 High Throughput (HT) features 7.3.2.56 O Yes  No  34 35 36 37 38 A.4.4 MAC protocol 39 40 41 A.4.4.1 MAC protocol capabilities 42 43 Change table items PC31, PC32 and PC34 of A.4.4.1 as follows: 44 45 46 47 48 Item Protocol capability References Status Support 49 50 PC31 Support transmission of CTS-to-self 9.2.11, 9.12 CF9:O Yes  No  sequence as described in the references 51 N/A  52 53 PC32 Support reception of CTS-to-self 9.2.11, 9.12 CF9:M Yes  No  sequence as described in the references 54 N/A  55 56 PC34 Robust security network association 7.2.2.1, O Yes  No  57 (RSNA) 7.3.1.4, 58 5.4.3.3, 59 8.7.2, 11.3.1, 60 11.3.2, 8.3.3 61 62 *PC36 Power Save Multi-Poll (PSMP) 7.4.10.4, 9.16 O Yes  No  63 64 *PC36.1 Scheduled PSMP 7.3.2.30, PC36:M Yes  No  65 11.4.4b N/A 

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 2 Item Protocol capability References Status Support 3 4 PC36.1.1 PSMP additions to TSPEC 7.3.2.30 PC36.1:M Yes  No  5 N/A  6 7 PC36.1.2 AP role in scheduled PSMP 9.16.1.2, (PC36.1 AND Yes  No  8 sequence 9.16.1.3 CF1):M N/A  9 10 PC36.1.3 STA role in scheduled PSMP 9.16.1.2, (PC36.1 AND Yes  No  11 sequence 9.16.1.3 CF2):M N/A  12 13 *PC36.2 Unscheduled PSMP 9.16.3 PC36:M Yes  No  14 N/A  15 16 PC36.2.1 PSMP additions to TSPEC 7.3.2.30 (CF1 AND Yes  No  17 PC36.2):M N/A  18 (CF2 AND 19 PC36.2):O 20 21 PC36.3 Creation, scheduling and transmis- 7.4.10.4, (PC36 AND Yes  No  22 sion of PSMP Action frame 9.16.1.1 CF1):M N/A  23 24 PC36.4 Reception and interpretation of 7.4.10.4 (PC36 AND Yes  No  25 PSMP Action frame CF2):M N/A  26 PC36.5 Multi-TID Block Ack rules in PSMP 7.2.1.7.4, PC36: M Yes  No  27 sequence 7.2.1.8.4, N/A  28 9.16.1.7, 11.5.2 29 30 PC36.6 Multi-phase PSMP 9.16.1.5 PC36:M Yes  No  31 N/A  32 33 34 35 A.4.4.3 Frame exchange sequences 36 37 Change the table items FS1 and FS2 in A.4.4.3 as follows: 38 39 40 41 Item Frame exchange sequence References Status Support 42 43 Are the following frame sequences 44 45 supported? 46 FS1 Basic frame sequences 9.12, M Yes  No  47 48 Annex C 49 9.2.5.6, 9.2.5.7, 50 9.2.6, 9.2.7, 51 9.2.8, 9.2.9 52 53 FS2 CF-Frame sequences 9.12, (PC4 OR Yes  No  54 Annex C PC5):M N/A  55 56 9.3.2, 9.3.3 57 58 59 A.4.4.4 MAC addressing functions 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Change PICS item AD3 as follows: 2 3 4 5 Item MAC Address Function References Status Support 6 7 AD3 Receive address matching 7.1.3.3, 7.2.2.1, MYes  No  8 Annex C N/A  9 10 11 12 A.4.14 QoS base functionality 13 14 15 Change PICS items QB4 and QB1, and insert the following two rows immediately below it as follows: 16 17 18 19 Item Protocol capability References Status Support 20 21 QB1 QoS frame format 7.2.1.1–7.2.1.3, CF12:M Yes  No  22 7.2.2.1, 7.2.3.1, N/A  23 7.2.3.4–7.2.3.7, 24 7.2.3.9, 25 7.2.3.12 26 27 QB4 Block Acknowledgements (Block 7.2.1.7, CF12:O Yes  No  28 Acks) 7.2.1.8, N/A  29 7.4.4, 9.10, 30 11.5 31 32 QB4.1 Immediate Block Ack 7.2.1.7.1, CF12:O Yes  No  33 7.2.1.7.2, CF16:M N/A  34 7.2.1.8.1, 35 36 7.2.1.8.2, 37 7.4.4, 9.10 38 (except 9.10.7 39 and 9.10.8), 40 11.5 41 *QB4.2 Delayed Block Ack CF12:O Yes  No  42 7.2.1.7.1, N/A  43 7.2.1.7.2, 44 7.2.1.8.1, 45 7.2.1.8.2, 46 7.4.4, 9.10 47 (except 9.10.7 48 and 9.10.8), 49 11.5 50 51 QB4.3 Compressed Block Ack 7.2.1.7.3 CF12:O Yes  No  52 CF16:M N/A  53 54 QB4.4 MultiTID Block Ack 7.2.1.7.4 CF12:O Yes  No  55 CF16:M N/A  56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 A.4.16 QoS hybrid coordination function (HCF) controlled channel access (HCCA) 2 3 4 Change table item QP4 of A.4.16 as follows: 5 6 7 8 Item Protocol capability References Status Support 9 10 QP4 HCF frame exchange sequences 9.12 CF12:M Yes  No  11 9.9.1, 9.3.2 N/A  12 13 14 15 Insert the following subclauses (A.4.20 to A.4.20.2) after A.4.18: 16 17 18 A.4.20 High Throughput (HT) features 19 20 21 A.4.20.1 HT MAC features 22 23 24 25 Item Protocol capability References Status Support 26 27 Are the following MAC protocol fea- 28 tures supported? 29 30 HTM1 HT capabilities signaling 31 32 HTM1.1 HT capabilities element 7.3.2.56.1 CF16:M Yes  No  33 N/A  34 35 HTM1.2 Signaling of STA capabilities in 7.3.2.56, (CF16 AND Yes  No  36 Probe Request, Association Request 7.2.3.8, 7.2.3.4, CF2):M N/A  37 and Reassociation Request frames 7.2.3.6 38 HTM1.3 Signaling of STA and BSS capabili- 7.3.2.56, (CF16 AND Yes  No  39 ties in Beacon, Probe Response, 7.2.3.1, 7.2.3.9, CF1):M N/A  40 Association Response and Reassoci- 7.2.3.5, 7.2.3.7 41 ation Response frames 42 43 HTM2 Signaling of HT Operation 7.3.2.57 (CF16 AND Yes  No  44 CF1):M N/A  45 46 HTM3 MPDU aggregation 47 48 HTM3.1 Reception of A-MPDU 7.3.2.56.3, 8.3, CF16:M Yes  No  49 9.7d.2 N/A  50 51 HTM3.2 A-MPDU format 7.4a.1 CF16:M Yes  No  52 N/A  53 HTM3.3 A-MPDU contents 7.4a.3 CF16:M Yes  No  54 N/A  55 56 HTM3.4 A-MPDU frame exchange 9.9.1.4 CF16:M Yes  No  57 sequences N/A  58 59 HTM3.5 Transmission of A-MPDU 7.3.2.56.3, 8.3CF16:O Yes  No  60 N/A  61 62 HTM4 MSDU aggregation 63 64 HTM4.1 Reception of A-MSDUs 7.1.3.5, 7.2.2.2 CF16:M Yes  No  65 N/A 

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 2 Item Protocol capability References Status Support 3 4 HTM4.2 A-MSDU format 7.2.2.2 CF16:M Yes  No  5 N/A  6 7 HTM4.3 A-MSDU content 7.2.2.2 CF16:M Yes  No  8 N/A  9 HTM4.4 Transmission of A-MSDUs 7.2.2.2, 7.1.3.5 CF16:O Yes  No  10 N/A  11 12 HTM5 Block Acknowledgement 13 14 HTM5.1 Block Ack mechanism 7.2.1.7, 7.2.1.8, CF16:M Yes  No  15 7.3.1.14, N/A  16 9.10,11.5 17 18 HTM5.2 Use of Compressed Bitmap between 7.2.1.8.3, CF16:M Yes  No  19 HT STAs 9.10.6, N/A  20 21 HTM5.3 HT-immediate Block Ack extensions 9.10.7 CF16:M Yes  No  22 N/A  23 HTM5.4 HT-delayed Block Ack extensions 9.10.8 CF16 AND Yes  No  24 QB4.2:M N/A  25 26 HTM5.5 Multiple TID Block Ack 7.2.1.7.4, HTM12:M Yes  No  27 7.2.1.8.4, N/A  28 9.16.1.7 29 30 HTM6 Protection mechanisms for different HT 31 PHY options 32 33 HTM6.1 Protection of RIFS PPDUs in the 9.13.3.3 CF16:M Yes  No  34 presence of non-HT STAs N/A  35 36 HTM6.1a Protection of RIFS PPDUs in an 9.13.3.3 CF16:M Yes  No  37 IBSS N/A  38 HTM6.2 Protection of HT-greenfield PPDUs 9.13.3.1 HTP1.3:M Yes  No  39 in the presence of non-HT STAs N/A  40 41 HTM6.2a Protection of HT-greenfield PPDUs 9.13.3.1 CF16:M Yes  No  42 in an IBSS N/A  43 44 *HTM7 L-SIG TXOP protection mechanism 9.13.5 CF16:O Yes  No  45 N/A  46 47 HTM7.1 Update NAV according to L-SIG 9.13.5.4 HTM7:M Yes  No  48 N/A  49 50 HTM8 Duration/ID rules for A-MPDU and 7.1.3.2 CF16:O Yes  No  51 TXOP N/A  52 HTM9 Truncation of TXOP as TXOP holder 9.9.1.7 CF16:O Yes  No  53 N/A  54 55 HTM10 Reception of +HTC frames 7.1.3.1.9, CF16:O Yes  No  56 7.3.2.56.5, 9.7a N/A  57 58 *HTM11 Reverse direction aggregation 9.15 CF16:O Yes  No  59 exchanges N/A  60 61 HTM11.1 Constraints regarding responses 9.15.4 HTM11:M Yes  No . 62 N/A 63 64 HTM12 Link Adaptation 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 2 Item Protocol capability References Status Support 3 4 HTM12.1 Use of the HT Control field for Link 7.1.3.5a, CF16:O Yes  No  5 Adaptation in immediate response 7.2.3.13, 9.18.2 N/A  6 exchange. 7 8 HTM12.2 Link adaptation using explicit feed- 7.2.3.13, 9.19.3 CF16:O Yes  No  9 back mechanism N/A  10 HTM13 Transmit Beam forming 11 12 *HTM13.1 Transmission of beam formed 9.19 CF16:O Yes  No  13 PPDUs N/A  14 15 *HTM13.2 Reception of beam formed PPDUs 9.19 CF16:O Yes  No  16 N/A  17 18 *HTM13.3 Initiate transmit beam forming frame 9.19.2 HTM13.1:O Yes  No  19 exchange with implicit feedback N/A  20 21 HTM13.3.1 Reception of sounding PPDUs 9.19.2 HTM13.3:M Yes  No  22 N/A  23 *HTM13.4 Response to transmit beam forming 9.19.2 HTM13.2:O Yes  No  24 frame exchange with implicit feed- N/A  25 back 26 27 HTM13.4.1 Transmission of sounding PPDUs 9.19.2 HTM13.4:M Yes  No  28 N/A  29 30 *HTM13.5 Initiate transmit beam forming frame 7.4.10.6, 9.19.3 HTM13.1:O Yes  No  31 exchange with explicit feedback N/A  32 33 HTM13.5.1 Transmission of sounding PPDUs 9.19.3 HTM13.5:M Yes  No  34 N/A  35 36 *HTM13.6 Respond to transmit beam forming 9.19.3 HTM13.2:O Yes  No  37 frame exchange with explicit feed- N/A  38 back 39 HTM13.6.1 Transmission of Action No Ack 9.19.3, 7.4.10.6 HTM13.6:O.1 Yes  No  40 +HTC frame including Action pay- N/A  41 load of type CSI 42 43 HTM13.6.2 Transmission of Action No Ack 9.19.3, 7.4.10.7 HTM13.6:O.1 Yes  No  44 +HTC frame including Action pay- N/A  45 load of type “non-compressed beam- 46 forming” 47 48 HTM13.6.3 Transmission of Action No Ack 9.19.3, 7.4.10.8 HTM13.6:O.1 Yes  No  49 +HTC frame including Action pay- N/A  50 load of type “Compressed beam- 51 forming” 52 53 *HTM13.7 Calibration procedure 7.2.3.13, HTM13:O Yes  No  54 9.19.2.4 N/A  55 56 HTM14 Antenna Selection 7.1.3.5a, CF16:O Yes  No  57 7.3.2.56.7, N/A  58 7.4.10.9, 9.20 59 *HTM15 Null Data Packet (NDP) 9.21 CF16:O Yes  No  60 N/A  61 62 HTM16 Space-Time Block Coding (STBC) sup- 63 port 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 2 Item Protocol capability References Status Support 3 4 HTM16.1 STBC beacon transmission 11.1.2.1 HTP2.11:O Yes  No  5 N/A  6 7 HTM16.2 Dual CTS protection 9.2.5.5a HTP2.11:O Yes  No  8 N/A  9 HTM17 SM Power Save support 10 11 *HTM17.1 AP Support for dynamic and Static 11.2.3 (CF16 AND Yes  No  12 SM Power Save mode CF1):M N/A  13 14 *HTM17.2 STA Support for dynamic and Static 11.2.3 (CF16 AND Yes  No  15 SM Power Save mode CF2):O N/A  16 17 HTM17.3 Transmit SM Power Save state infor- 7.4.10.3, 11.2.3 (HTM17.1 OR Yes  No  18 mation using HT capabilities, or SM HTM17.2):M N/A  19 Power Save Action frame 20 21 HTM17.4 Receive SM Power Save state infor- 11.2.3 CF16:M Yes  No  22 mation and support frame exchanges N/A  23 with SM Power Save STAs 24 HTM18 Mechanisms for coexistence of 20 MHz 11.14 CF16:M Yes  No  25 and 40 MHz channels N/A  26 27 HTM19 Channel selection methods for 20/40 11.14.3 (HTP2.3.4 Yes  No  28 MHz operation AND CF1):M N/A  29 30 HTM20 20/40 MHz Operation 11.14 HTP2.3.4:M Yes  No  31 N/A  32 33 HTM21 Phased Coexistence Operation (PCO) 34 35 *HTM21.1 PCO capability at AP 11.15 (CF16 AND Yes  No  36 CF1):O N/A  37 HTM21.1.1 Rules for operation at a PCO active 7.4.10.5, HTM21.1:M Yes  No  38 AP 11.15.2 N/A  39 40 *HTM21.2 STA support for PCO mode 11.15 (CF16 AND Yes  No  41 CF2):O N/A  42 43 HTM21.2.1 Rules for operation at PCO active 7.4.10.5, HTM21.2:M Yes  No  44 STA 11.15.3 N/A  45 46 HTM22 Management Information Base (MIB) 47 48 HTM22.1 dot11PhyHTComplianceGroup Annex D CF16:M Yes  No  49 N/A  50 HTM22.2 dot11PhyMCSGroup Annex D CF16:M Yes  No  51 N/A  52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 A.4.20.2 HT PHY features 2 3 4 Item Protocol capability References Status Support 5 6 Are the following PHY protocol fea- 7 tures supported? 8 9 HTP1 PHY operating modes 10 11 HTP1.1 Operation according to Clause 17 20.1.4 CF16:M Yes  No  and/or Clause 19 12 N/A  13 14 HTP1.2 HT-mixed format 20.1.4 CF16:M Yes  No  15 N/A  16 17 *HTP1.3 HT-greenfield format 20.1.4 CF16:O Yes  No  18 19 N/A  20 HTP2 PLCP frame format 21 22 HTP2.1 HT-mixed format PLCP format 20.3.2 CF16:M Yes  No  23 24 N/A  25 HTP2.2 HT-greenfield PLCP format 20.3.2 26 HTP1.3:M Yes  No  27 N/A  28 HTP2.3 Modulation and Coding Schemes 29 (MCS) 30 31 HTP2.3.1 MCS 0 through MCS 7 in 20 MHz 32 with 800 ns guard interval 33 34 HTP2.3.1.1 Support for 20 MHz with 800 ns 20.3.5, CF16:M Yes  No  35 guard interval MCS index 0 20.6 36 N/A  37 HTP2.3.1.2 Support for 20 MHz with 800 ns 20.3.5, CF16:M Yes  No  38 guard interval MCS index 1 20.6 39 N/A  40 HTP2.3.1.3 Support for 20 MHz with 800 ns 20.3.5, 41 CF16:M Yes  No  guard interval MCS index 2 20.6 42 N/A  43 44 HTP2.3.1.4 Support for 20 MHz with 800 ns 20.3.5, CF16:M Yes  No  guard interval MCS index 3 20.6 45 N/A  46 47 HTP2.3.1.5 Support for 20 MHz with 800 ns 20.3.5, CF16:M Yes  No  guard interval MCS index 4 20.6 48 N/A  49 50 HTP2.3.1.6 Support for 20 MHz with 800 ns 20.3.5, CF16:M Yes  No  51 guard interval MCS index 5 20.6 52 N/A  53 HTP2.3.1.7 Support for 20 MHz with 800 ns 20.3.5, CF16:M Yes  No  54 guard interval MCS index 6 20.6 55 N/A  56 HTP2.3.1.8 Support for 20 MHz with 800 ns 20.3.5, 57 CF16:M Yes  No  guard interval MCS index 7 20.6 58 N/A  59 60 HTP2.3.2 MCS 8 through MCS 15 in 20 MHz 61 with 800 ns guard interval 62 HTP2.3.2.1 Support for 20 MHz with 800 ns 20.3.5, (CF16 AND Yes  No  63 guard interval MCS index 8 20.6 64 CF1):M N/A  65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 2 Item Protocol capability References Status Support 3 4 HTP2.3.2.2 Support for 20 MHz with 800 ns 20.3.5, (CF16 AND Yes  No  guard interval MCS index 9 20.6 5 CF1):M N/A  6 7 HTP2.3.2.3 Support for 20 MHz with 800 ns 20.3.5, (CF16 AND Yes  No  8 guard interval MCS index 10 20.6 CF1):M N/A  9 10 HTP2.3.2.4 Support for 20 MHz with 800 ns 20.3.5, (CF16 AND Yes  No  11 guard interval MCS index 11 20.6 12 CF1):M N/A  13 HTP2.3.2.5 Support for 20 MHz with 800 ns 20.3.5, (CF16 AND Yes  No  14 guard interval MCS index 12 20.6 15 CF1):M N/A  16 HTP2.3.2.6 Support for 20 MHz with 800 ns 20.3.5, 17 (CF16 AND Yes  No  guard interval MCS index 13 20.6 18 CF1):M N/A  19 20 HTP2.3.2.7 Support for 20 MHz with 800 ns 20.3.5, (CF16 AND Yes  No  guard interval MCS index 14 20.6 21 CF1):M N/A  22 23 HTP2.3.2.8 Support for 20 MHz with 800 ns 20.3.5, (CF16 AND Yes  No  guard interval MCS index 15 20.6 24 CF1):M N/A  25 26 HTP2.3.3 Transmit and receive support for 400 20.3.5, CF16:O Yes  No  27 ns guard interval 20.6 28 N/A  29 *HTP2.3.4 Operation at 40 MHz 20.3.5, CF16:O Yes  No  30 20.6 31 N/A  32 HTP2.3.5 Support for MCS with indices 16 33 through 76 34 35 HTP2.3.5.1 Support for MCS with index 16 20.3.5, CF16:O Yes  No  36 20.6 37 N/A  38 39 40 HTP2.3.5.2 Support for MCS with index 17 20.3.5, CF16:O Yes  No  20.6 41 N/A  42 43 44 HTP2.3.5.3 Support for MCS with index 18 20.3.5, CF16:O Yes  No  45 20.6 46 N/A  47 48 49 HTP2.3.5.4 Support for MCS with index 19 20.3.5, CF16:O Yes  No  20.6 50 N/A  51 52 53 HTP2.3.5.5 Support for MCS with index 20 20.3.5, CF16:O Yes  No  54 20.6 55 N/A  56 57 58 HTP2.3.5.6 Support for MCS with index 21 20.3.5, CF16:O Yes  No  20.6 59 N/A  60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 2 Item Protocol capability References Status Support 3 4 HTP2.3.5.7 Support for MCS with index 22 20.3.5, CF16:O Yes  No  20.6 5 N/A  6 7 8 HTP2.3.5.8 Support for MCS with index 23 20.3.5, CF16:O Yes  No  9 20.6 10 N/A  11 12 13 HTP2.3.5.9 Support for MCS with index 24 20.3.5, CF16:O Yes  No  20.6 14 N/A  15 16 17 HTP2.3.5.10 Support for MCS with index 25 20.3.5, CF16:O Yes  No  18 20.6 19 N/A  20 21 22 HTP2.3.5.11 Support for MCS with index 26 20.3.5, CF16:O Yes  No  20.6 23 N/A  24 25 26 HTP2.3.5.12 Support for MCS with index 27 20.3.5, CF16:O Yes  No  27 20.6 28 N/A  29 30 31 HTP2.3.5.13 Support for MCS with index 28 20.3.5, CF16:O Yes  No  20.6 32 N/A  33 34 35 HTP2.3.5.14 Support for MCS with index 29 20.3.5, CF16:O Yes  No  36 20.6 N/A 37  38 39 HTP2.3.5.15 Support for MCS with index 30 20.3.5, CF16:O 40 Yes  No  20.6 41 N/A  42 43 44 HTP2.3.5.16 Support for MCS with index 31 20.3.5, CF16:O Yes  No  45 20.6 N/A  46 47 48 HTP2.3.5.17 Support for MCS with index 32 20.3.5, CF16:O 49 Yes  No  20.6 50 N/A  51 52 53 HTP2.3.5.18 Support for MCS with index 33 20.3.5, CF16:O Yes  No  20.6 54 N/A  55 56 57 HTP2.3.5.19 Support for MCS with index 34 20.3.5, CF16:O Yes  No  58 20.6 59 N/A  60 61 62 HTP2.3.5.20 Support for MCS with index 35 20.3.5, CF16:O Yes  No  20.6 63 N/A  64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 2 Item Protocol capability References Status Support 3 4 HTP2.3.5.21 Support for MCS with index 36 20.3.5, CF16:O Yes  No  20.6 5 N/A  6 7 8 HTP2.3.5.22 Support for MCS with index 37 20.3.5, CF16:O Yes  No  9 20.6 10 N/A  11 12 13 HTP2.3.5.23 Support for MCS with index 38 20.3.5, CF16:O Yes  No  20.6 14 N/A  15 16 17 HTP2.3.5.24 Support for MCS with index 39 20.3.5, CF16:O Yes  No  18 20.6 19 N/A  20 21 22 HTP2.3.5.25 Support for MCS with index 40 20.3.5, CF16:O Yes  No  20.6 23 N/A  24 25 26 HTP2.3.5.26 Support for MCS with index 41 20.3.5, CF16:O Yes  No  27 20.6 28 N/A  29 30 31 HTP2.3.5.27 Support for MCS with index 42 20.3.5, CF16:O Yes  No  20.6 32 N/A  33 34 35 HTP2.3.5.28 Support for MCS with index 43 20.3.5, CF16:O Yes  No  36 20.6 N/A 37  38 39 HTP2.3.5.29 Support for MCS with index 44 20.3.5, CF16:O 40 Yes  No  20.6 41 N/A  42 43 44 HTP2.3.5.30 Support for MCS with index 45 20.3.5, CF16:O Yes  No  45 20.6 N/A  46 47 48 HTP2.3.5.31 Support for MCS with index 46 20.3.5, CF16:O 49 Yes  No  20.6 50 N/A  51 52 53 HTP2.3.5.32 Support for MCS with index 47 20.3.5, CF16:O Yes  No  20.6 54 N/A  55 56 57 HTP2.3.5.33 Support for MCS with index 48 20.3.5, CF16:O Yes  No  58 20.6 59 N/A  60 61 62 HTP2.3.5.34 Support for MCS with index 49 20.3.5, CF16:O Yes  No  20.6 63 N/A  64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 2 Item Protocol capability References Status Support 3 4 HTP2.3.5.35 Support for MCS with index 50 20.3.5, CF16:O Yes  No  20.6 5 N/A  6 7 8 HTP2.3.5.36 Support for MCS with index 51 20.3.5, CF16:O Yes  No  9 20.6 10 N/A  11 12 13 HTP2.3.5.37 Support for MCS with index 52 20.3.5, CF16:O Yes  No  20.6 14 N/A  15 16 17 HTP2.3.5.38 Support for MCS with index 53 20.3.5, CF16:O Yes  No  18 20.6 19 N/A  20 21 22 HTP2.3.5.39 Support for MCS with index 54 20.3.5, CF16:O Yes  No  20.6 23 N/A  24 25 26 HTP2.3.5.40 Support for MCS with index 55 20.3.5, CF16:O Yes  No  27 20.6 28 N/A  29 30 31 HTP2.3.5.41 Support for MCS with index 56 20.3.5, CF16:O Yes  No  20.6 32 N/A  33 34 35 HTP2.3.5.42 Support for MCS with index 57 20.3.5, CF16:O Yes  No  36 20.6 N/A 37  38 39 HTP2.3.5.43 Support for MCS with index 58 20.3.5, CF16:O 40 Yes  No  20.6 41 N/A  42 43 44 HTP2.3.5.44 Support for MCS with index 59 20.3.5, CF16:O Yes  No  45 20.6 N/A  46 47 48 HTP2.3.5.45 Support for MCS with index 60 20.3.5, CF16:O 49 Yes  No  20.6 50 N/A  51 52 53 HTP2.3.5.46 Support for MCS with index 61 20.3.5, CF16:O Yes  No  20.6 54 N/A  55 56 57 HTP2.3.5.47 Support for MCS with index 62 20.3.5, CF16:O Yes  No  58 20.6 59 N/A  60 61 62 HTP2.3.5.48 Support for MCS with index 63 20.3.5, CF16:O Yes  No  20.6 63 N/A  64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 2 Item Protocol capability References Status Support 3 4 HTP2.3.5.49 Support for MCS with index 64 20.3.5, CF16:O Yes  No  20.6 5 N/A  6 7 8 HTP2.3.5.50 Support for MCS with index 65 20.3.5, CF16:O Yes  No  9 20.6 10 N/A  11 12 13 HTP2.3.5.51 Support for MCS with index 66 20.3.5, CF16:O Yes  No  20.6 14 N/A  15 16 17 HTP2.3.5.52 Support for MCS with index 67 20.3.5, CF16:O Yes  No  18 20.6 19 N/A  20 21 22 HTP2.3.5.53 Support for MCS with index 68 20.3.5, CF16:O Yes  No  20.6 23 N/A  24 25 26 HTP2.3.5.54 Support for MCS with index 69 20.3.5, CF16:O Yes  No  27 20.6 28 N/A  29 30 31 HTP2.3.5.55 Support for MCS with index 70 20.3.5, CF16:O Yes  No  20.6 32 N/A  33 34 35 HTP2.3.5.56 Support for MCS with index 71 20.3.5, CF16:O Yes  No  36 20.6 N/A 37  38 39 HTP2.3.5.57 Support for MCS with index 72 20.3.5, CF16:O 40 Yes  No  20.6 41 N/A  42 43 44 HTP2.3.5.58 Support for MCS with index 73 20.3.5, CF16:O Yes  No  45 20.6 N/A  46 47 48 HTP2.3.5.59 Support for MCS with index 74 20.3.5, CF16:O 49 Yes  No  20.6 50 N/A  51 52 53 HTP2.3.5.60 Support for MCS with index 75 20.3.5, CF16:O Yes  No  20.6 54 N/A  55 56 57 HTP2.3.5.61 Support for MCS with index 76 20.3.5, CF16:O Yes  No  58 20.6 59 N/A  60 61 HTP2.4 PHY timing parameters 62 HTP2.4.1 Values in non-HT 20 MHz channel 20.3.6 63 CF16:M Yes  No  64 N/A  65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 2 Item Protocol capability References Status Support 3 4 HTP2.4.2 Values in 20 MHz HT channel 20.3.6 CF16:M Yes  No  5 N/A  6 7 HTP2.4.3 Values in 40 MHz channel 20.3.6 HTP2.3.4:M Yes  No  8 N/A  9 10 HTP2.5 HT Preamble field definition and 11 coding 12 13 HTP2.5.1 HT-mixed format preamble 20.3.9.2 CF16:M Yes  No  14 N/A  15 16 HTP2.5.2 HT-greenfield preamble 20.3.9.5 HTP1.3:M Yes  No  17 18 N/A  19 HTP2.5.3 Extension HT-LTFs 20.3.9.4.6 20 CF16:O Yes  No  21 N/A  22 HTP2.6 HT Data field definition and coding 20.3.11 23 CF16:M Yes  No  24 N/A  25 26 HTP2.6.1 Use of LDPC codes 20.3.11.6 CF16:O Yes  No  27 N/A  28 29 HTP2.7 Beam forming 20.3.12 CF16:O Yes  No  30 N/A  31 32 HTP2.8 Sounding PPDUs 33 34 HTP2.8.1 HT preamble format for sounding 20.3.13 CF16:O Yes  No  35 PPDUs N/A  36 37 HTP2.8.2 Sounding with an NDP 20.3.13.1 HTM15:O Yes  No  38 39 N/A  40 HTP2.8.3 Sounding PPDU for calibration 20.3.13.2 41 HTM14.7:M Yes  No  42 N/A  43 44 HTP2.9 Channel numbering and channelization 45 HTP2.9.1 Channel allocation for 20 MHz 17.3.8.3 46 CF16:M Yes  No  channels at 5 GHz 47 N/A  48 49 HTP2.9.2 Channel allocation for 20 MHz 19.4.2 CF16:M Yes  No  channels at 2.4 GHz 50 N/A  51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 2 Item Protocol capability References Status Support 3 4 HTP2.9.3 Channel allocation for 40 MHz 20.3.15.2 HTP2.3.4:M Yes  No  channels at 5 GHz 5 N/A  6 7 HTP2.9.4 Channel allocation for 40 MHz 20.3.15.1 HTP2.3.4:M Yes  No  8 channels at 2.4 GHz N/A  9 10 HTP2.10 PMD transmit specification 11 12 HTP2.10.1 PMD transmit specification for 20 20.3.21 CF16:M Yes  No  13 MHz channel 14 N/A  15 HTP2.10.2 PMD transmit specification for 40 20.3.21 HTP2.3.4:M Yes  No  16 MHz channel 17 N/A  18 *HTP2.11 Space-Time Block Coding (STBC) 20.3.11.8.1 19 CF16:O Yes  No  20 N/A  21 22 HTP2.12 PMD receive specification 23 HTP2.12.1 PMD receive specification for 20 20.3.22 24 CF16:M Yes  No  MHz channel 25 N/A  26 27 HTP2.12.2 PMD receive specification for 40 20.3.22 HTP2.3.4:M Yes  No  MHz channel 28 N/A  29 30 HTP2.13 PPDU reception with RIFS 20.3.22.7 CF16:M Yes  No  31 N/A  32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Annex C (informative) Formal description of a subset of MAC 2 3 operation 4 5 6 7 C.3 State machines for MAC stations 8 9 Insert the following paragraph after the fourth paragraph of C.3: 10 11 12 This Clause does not describe the behavior of an HT STA. 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Annex D (normative) ASN.1 encoding of the MAC and PHY MIB 2 3 4 Change the list of imports as follows: 5 6 IEEE802dot11-MIB DEFINITIONS ::= BEGIN 7 8 IMPORTS 9 MODULE-IDENTITY, OBJECT-TYPE, 10 11 NOTIFICATION-TYPE,Integer32, Counter32, Counter64, 12 Unsigned32 FROM SNMPv2-SMI 13 14 DisplayString , MacAddress, RowStatus, 15 16 TruthValue FROM SNMPv2-TC 17 MODULE-COMPLIANCE, OBJECT-GROUP, 18 19 NOTIFICATION-GROUP FROM SNMPv2-CONF 20 ifIndex FROM RFC1213-MIB; 21 22 23 Change the “Station Management (SMT) Attributes” of “Major Sections” of the MIB as follows: 24 25 --********************************************************************** 26 --* Major sections 27 28 --********************************************************************** 29 -- 30 31 -- Station Management (SMT) Attributes 32 33 -- DEFINED AS “The SMT object class provides the necessary support 34 -- at the station to manage the processes in the station such that 35 36 -- the station may work cooperatively as part of the IEEE 802.11 37 38 -- network. 39 40 41 dot11smt OBJECT IDENTIFIER ::= { ieee802dot11 1 } 42 -- dot11 SMT GROUPS 43 44 -- dot11StationConfigTable ::= { dot11smt 1 } 45 46 -- dot11AuthenticationAlgorithmTable ::= { dot11smt 2 } 47 -- dot11WEPDefaultKeysTable ::= {dot11smt 3} 48 49 -- dot11WEPKEYMappingsTable ::= { dot11smt 4 } 50 -- dot11PrivacyTable ::= { dot11smt 5 } 51 52 -- dot11SMTnotification ::= { dot11smt 6 } 53 54 -- dot11MultiDomainCapabilityTable ::= { dot11smt 7 } 55 -- dot11SpectrumManagementTable ::= { dot11smt 8 } 56 57 -- dot11RSNAConfigTable ::= { dot11smt 9 } 58 59 -- dot11RSNAConfigPairwiseCiphersTable ::= { dot11smt 10 } 60 -- dot11RSNAConfigAuthenticationSuitesTable ::= { dot11smt 11 } 61 62 -- dot11RSNAStatsTable ::= { dot11smt 12 } 63 -- dot11RegulatoryClassesTable ::= { dot11smt 13 } 64 65 -- dot11RadioResourceManagement ::= { dot11smt 14 }

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 -- dot11FastBSSTransitionConfigTable ::= { dot11smt 15 } 2 3 -- dot11LCIDSETable ::= { dot11smt 16 } 4 -- dot11HTStationConfigTable ::= { dot11smt 17 } 5 6 7 8 9 In Annex D, change the list following the dot11phy object identifier as shown: 10 11 dot11phy OBJECT IDENTIFIER ::= { ieee802dot11 4 } 12 13 -- PHY GROUPS 14 -- dot11PhyOperationTable ::= { dot11phy 1 } 15 16 -- dot11PhyAntennaTable ::= { dot11phy 2 } 17 -- dot11PhyTxPowerTable ::= { dot11phy 3 } 18 19 -- dot11PhyFHSSTable ::= { dot11phy 4 } 20 21 -- dot11PhyDSSSTable ::= { dot11phy 5 } 22 -- dot11PhyIRTable ::= { dot11phy 6 } 23 24 -- dot11RegDomainsSupportedTable ::= { dot11phy 7 } 25 -- dot11AntennasListTable ::= { dot11phy 8 } 26 27 -- dot11SupportedDataRatesTxTable ::= { dot11phy 9 } 28 29 -- dot11SupportedDataRatesRxTable ::= { dot11phy 10 } 30 -- dot11PhyOFDMTable ::= { dot11phy 11 } 31 32 -- dot11PhyHRDSSSTable ::= { dot11phy 12 } 33 34 -- dot11EHCCHoppingPatternTable ::= { dot11phy 13 } 35 -- dot11PhyERPTable ::= { dot11phy 14 } 36 37 -- dot11PhyHTTable ::= {dot11phy 15 } 38 -- dot11HTSupportedMCSTxTable ::= { dot11phy 16 } 39 40 -- dot11HTSupportedMCSRxTable ::= { dot11phy 17 } 41 42 -- dot11TransmitBeamformingConfigTable ::= { dot11phy 18 } 43 44 45 Change the “Dot11StationConfigEntry” of the “dotStationConfig TABLE” as follows: 46 47 -- ********************************************************************* 48 49 -- * dotStationConfig TABLE 50 51 -- ********************************************************************* 52 Dot11StationConfigEntry ::= 53 54 SEQUENCE { 55 dot11StationID MacAddress, 56 57 dot11MediumOccupancyLimit INTEGER, 58 59 dot11CFPollable TruthValue, 60 dot11CFPeriod INTEGER, 61 62 dot11CFPMaxDuration INTEGER, 63 dot11AuthenticationResponseTimeOut Unsigned32, 64 65 dot11PrivacyOptionImplemented TruthValue,

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 dot11PowerManagementMode INTEGER, 2 3 dot11DesiredSSID OCTET STRING, 4 dot11DesiredBSSType INTEGER, 5 6 dot11OperationalRateSet OCTET STRING, 7 8 dot11BeaconPeriod INTEGER, 9 dot11DTIMPeriod INTEGER, 10 11 dot11AssociationResponseTimeOut Unsigned32, 12 dot11DisassociateReason INTEGER, 13 14 dot11DisassociateStation MacAddress, 15 16 dot11DeauthenticateReason INTEGER, 17 dot11DeauthenticateStation MacAddress, 18 19 dot11AuthenticateFailStatus INTEGER, 20 dot11AuthenticateFailStation MacAddress, 21 22 dot11MultiDomainCapabilityImplemented TruthValue, 23 24 dot11MultiDomainCapabilityEnabled TruthValue, 25 dot11CountryString OCTET STRING, 26 27 dot11SpectrumManagementImplemented TruthValue, 28 dot11SpectrumManagementRequired TruthValue, 29 30 dot11RSNAOptionImplemented TruthValue, 31 dot11RSNAPreauthenticationImplemented TruthValue, 32 33 dot11RegulatoryClassesImplemented TruthValue, 34 35 dot11RegulatoryClassesRequired TruthValue, 36 dot11QosOptionImplemented TruthValue, 37 38 dot11ImmediateBlockAckOptionImplemented TruthValue, 39 dot11DelayedBlockAckOptionImplemented TruthValue, 40 41 dot11DirectOptionImplemented TruthValue, 42 43 dot11APSDOptionImplemented TruthValue, 44 dot11QAckOptionImplemented TruthValue, 45 46 dot11QBSSLoadOptionImplemented TruthValue, 47 dot11QueueRequestOptionImplemented TruthValue, 48 49 dot11TXOPRequestOptionImplemented TruthValue, 50 51 dot11MoreDataAckOptionImplemented TruthValue, 52 dot11AssociatedinNQBSS TruthValue, 53 54 dot11DLSAllowdInQBSS TruthValue, 55 dot11DLSAllowed TruthValue, 56 57 dot11AssociateStation MacAddress, 58 59 dot11AssociateID INTEGER, 60 dot11AssociateFailStation MacAddress, 61 62 dot11AssociateFailStatus INTEGER, 63 dot11ReassociateStation MacAddress, 64 65 dot11ReassociateID INTEGER,

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 dot11ReassociateFailStation MacAddress, 2 3 dot11ReassociateFailStatus INTEGER, 4 dot11RadioMeasurementCapable TruthValue, 5 6 dot11RadioMeasurementEnabled TruthValue, 7 8 dot11RRMMeasurementProbeDelay INTEGER, 9 dot11RRMMeasurementPilotPeriod INTEGER, 10 11 dot11RRMLinkMeasurementEnabled TruthValue, 12 dot11RRMNeighborReportEnabled TruthValue, 13 14 dot11RRMParallelMeasurementsEnabled TruthValue, 15 16 dot11RRMRepeatedMeasurementsEnabled TruthValue, 17 dot11RRMBeaconPassiveMeasurementEnabled TruthValue, 18 19 dot11RRMBeaconActiveMeasurementEnabled TruthValue, 20 dot11RRMBeaconTableMeasurementEnabled TruthValue, 21 22 dot11RRMBeaconMeasurementReportingConditionsEnabled TruthValue, 23 24 dot11RRMFrameMeasurementEnabled TruthValue, 25 dot11RRMChannelLoadMeasurementEnabled TruthValue, 26 27 dot11RRMNoiseHistogramMeasurementEnabled TruthValue 28 29 dot11RRMStatisticsMeasaurementEnabled TruthValue, 30 dot11RRMLCIMeasurementEnabled TruthValue, 31 32 dot11RRMLCIAzimuthEnabled TruthValue, 33 dot11RRMTransmitStreamCategoryMeasurementEnabled TruthValue, 34 35 dot11RRMTriggeredTransmitStreamCategoryMeasurementEnabled 36 TruthValue, 37 38 dot11RRMAPChannelReportEnabled TruthValue, 39 40 dot11RRMMIBEnabled TruthValue, 41 dot11RRMMaxMeasurementDuration Unsigned32, 42 43 dot11RRMNonOperatingChannelMaxMeasurementDuration Unsigned32, 44 dot11RRMMeasurementPilotTransmissionInformationEnabled TruthValue, 45 46 dot11RRMMeasurementPilotCapability Unsigned32, 47 dot11RRMNeighborReportTSFOffsetEnabled TruthValue, 48 49 dot11RRMRCPIMeasurementEnabled TruthValue, 50 51 dot11RRMRSNIMeasurementEnabled TruthValue, 52 dot11RRMBSSAverageAccessDelayEnabled TruthValue, 53 54 dot11RRMBSSAvailableAdmissionCapacityEnabled TruthValue, 55 dot11RRMAntennaInformationEnabled TruthValue, 56 57 dot11FastBSSTransitionImplemented TruthValue 58 59 dot11LCIDSEImplemented TruthValue, 60 dot11LCIDSERequired TruthValue, 61 62 dot11DSERequired TruthValue, 63 dot11ExtendedChannelSwitchEnabled TruthValue, 64 65 dot11RSNAProtectedManagementFramesEnabled TruthValue,

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 dot11RSNAUnprotectedManagementFramesAllowed TruthValue, 2 3 dot11AssociationSAQueryMaximumTimeout Unsigned32, 4 5 dot11AssociationSAQueryRetryTimeout INTEGER, 6 dot11HighThroughputOptionImplemented TruthValue, 7 8 dot11RSNAPBACRequired TruthValue, 9 10 dot11PSMPOptionImplemented TruthValue} 11 12 13 14 Change the definition of dot11OperationalRateSet as shown below: 15 16 dot11OperationalRateSet OBJECT-TYPE 17 SYNTAX OCTET STRING (SIZE(1..126)) 18 19 MAX-ACCESS read-write 20 21 STATUS current 22 DESCRIPTION 23 24 "This attribute shall specify the set of non-HT data rates at 25 which the station may transmit data. The attribute that specifies the set of 26 27 HT data rates is dot11HTOperationalMCSSet. Each octet contains a value 28 representing a rate. Each rate shall be within the range from 2 to 127, 29 corresponding to data rates in increments of 500 kbit/s from 1 Mb/s to 63.5 30 31 Mb/s, and shall be supported (as indicated in the supported rates table) for 32 receiving data. This value is reported in transmitted Beacon, Probe Request, 33 34 Probe Response, Association Request, Association Response, Reassociation 35 Request, and Reassociation Response frames, and is used to determine whether 36 a BSS with which the station desires to synchronize is suitable. It is also 37 38 used when starting a BSS, as specified in 10.3." 39 ::= { dot11StationConfigEntry 11 } 40 41 42 Insert the following element to the end of dot11StationConfigTable element definitions after 43 dot11AssociationMaximumPingAttempts: 44 45 dot11HighThroughputOptionImplemented OBJECT-TYPE 46 47 SYNTAX TruthValue 48 MAX-ACCESS read-only 49 50 STATUS current 51 52 DESCRIPTION 53 "This attribute indicates whether the entity is HT Capable." 54 55 ::= { dot11StationConfigEntry 92} 56 57 58 dot11RSNAPBACRequired OBJECT-TYPE 59 60 SYNTAX TruthValue 61 62 MAX-ACCESS read-write 63 STATUS current 64 65 DESCRIPTION

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 "This variable indicates whether or not this STA requires the 2 3 Protection of Block Ack agreements." 4 DEFAULT { FALSE } 5 6 ::= { dot11StationConfigEntry 93} 7 8 9 dot11PSMPOptionImplemented OBJECT-TYPE 10 11 SYNTAX TruthValue 12 MAX-ACCESS read-only 13 14 STATUS current 15 DESCRIPTION 16 17 "This attribute, when TRUE, indicates that the station 18 implementation is capable of supporting PSMP. ” 19 20 DEFVAL { false } 21 ::= { dot11StationConfigEntry 94 } 22 23 24 25 Insert the following table after the dot11LCIDSE TABLE : 26 27 -- ********************************************************************** 28 29 -- * dot11HTStationConfig TABLE 30 -- ********************************************************************** 31 32 dot11HTStationConfigTable OBJECT-TYPE 33 34 SYNTAX SEQUENCE OF Dot11HTStationConfigEntry 35 MAX-ACCESS not-accessible 36 37 STATUS current 38 DESCRIPTION 39 40 "Station Configuration attributes. In tabular form to allow 41 for multiple instances on an agent." 42 43 ::= { dot11smt 17 } 44 45 46 dot11HTStationConfigEntry OBJECT-TYPE 47 48 SYNTAX Dot11HTStationConfigEntry 49 MAX-ACCESS not-accessible 50 51 STATUS current 52 DESCRIPTION 53 54 "An entry (conceptual row) in the dot11HTStationConfig Table. 55 56 57 ifIndex - Each IEEE 802.11 interface is represented by an 58 59 ifEntry. Interface tables in this MIB module are indexed by ifIndex." 60 INDEX { ifIndex } 61 62 ::= { dot11HTStationConfigTable 1 } 63 64 65 Dot11HTStationConfigEntry ::=

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 SEQUENCE { 2 3 dot11HTOperationalMCSSet OCTET STRING, 4 dot11MIMOPowerSave INTEGER, 5 6 dot11NDelayedBlockAckOptionImplemented TruthValue, 7 dot11MaxAMSDULength INTEGER, 8 9 dot11STBCControlFrameOptionImplemented TruthValue, 10 dot11LsigTxopProtectionOptionImplemented TruthValue, 11 12 dot11MaxRxAMPDUFactor INTEGER, 13 dot11MinimumMPDUStartSpacing INTEGER, 14 15 dot11PCOOptionImplemented TruthValue, 16 dot11TransitionTime INTEGER, 17 18 dot11MCSFeedbackOptionImplemented INTEGER, 19 dot11HTControlFieldSupported TruthValue, 20 dot11RDResponderOptionImplemented TruthValue, 21 22 dot11SPPAMSDUCapable TruthValue, 23 dot11SPPAMSDURequired TruthValue, 24 25 dot11FortyMHzOptionImplemented TruthValue 26 27 } 28 29 30 dot11HTOperationalMCSSet OBJECT-TYPE 31 SYNTAX OCTET STRING (SIZE(1..127)) 32 33 MAX-ACCESS read-write 34 35 STATUS current 36 DESCRIPTION 37 38 "This attribute shall specify the set of MCS at which the 39 station may transmit data. Each octet contains a value representing a rate. 40 41 Each MCS shall be within the range from 1 to 127, and shall be supported for 42 receiving data. This value is reported in transmitted Beacon, Probe Request, 43 Probe Response, Association Request, Association Response, Reassociation 44 45 Request, and Reassociation Response frames, and is used to determine whether 46 a BSS with which the station desires to synchronize is suitable. It is also 47 48 used when starting a BSS, as specified in 10.3." 49 ::= { dot11HTStationConfigEntry 1 } 50 51 52 dot11MIMOPowerSave OBJECT-TYPE 53 54 SYNTAX INTEGER { static(1), dynamic(2), mimo(3) } 55 56 MAX-ACCESS read-only 57 STATUS current 58 59 DESCRIPTION 60 "This is an 8-bit integer value that identifies the configured 61 62 power save state of MIMO.” 63 ::= { dot11HTStationConfigEntry 2 } 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 dot11NDelayedBlockAckOptionImplemented OBJECT-TYPE 2 3 SYNTAX TruthValue 4 MAX-ACCESS read-only 5 6 STATUS current 7 8 DESCRIPTION 9 "This attribute, when TRUE, indicates that the station 10 11 implementation is capable of supporting the No ack option of the Delayed 12 Block Ack. ” 13 DEFVAL { false } 14 15 ::= { dot11HTStationConfigEntry 3 } 16 17 18 dot11MaxAMSDULength OBJECT-TYPE 19 20 SYNTAX INTEGER { 3839, 7935 } 21 MAX-ACCESS read-only 22 23 STATUS current 24 25 DESCRIPTION 26 “This attribute indicates the supported maximum size of A- 27 28 MSDU.” 29 DEFVAL { 3839} 30 31 ::= { dot11HTStationConfigEntry 4 } 32 33 34 dot11STBCControlFrameOptionImplemented OBJECT-TYPE 35 SYNTAX TruthValue 36 37 MAX-ACCESS read-only 38 39 STATUS current 40 DESCRIPTION 41 42 "This attribute, when TRUE, indicates that the station 43 implementation is capable of processing the received control frames that are 44 45 STBC frames. ” 46 DEFVAL { false } 47 48 ::= { dot11HTStationConfigEntry 5 } 49 50 51 dot11LsigTxopProtectionOptionImplemented OBJECT-TYPE 52 SYNTAX TruthValue 53 54 MAX-ACCESS read-only 55 56 STATUS current 57 DESCRIPTION 58 59 "This attribute, when TRUE, indicates that the station 60 implementation is capable of supporting L-SIG TXOP Protection option.” 61 62 DEFVAL { false } 63 ::= { dot11HTStationConfigEntry 6 } 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 dot11MaxRxAMPDUFactor OBJECT-TYPE 2 3 SYNTAX INTEGER (0..3) 4 MAX-ACCESS read-only 5 6 STATUS current 7 8 DESCRIPTION 9 "This attribute indicates the maximum length of A-MPDU that 10 11 the STA can receive. The Maximum Rx A-MPDU defined by this field is equal to 12 213+dot11MaxRxAMPDUFactor -1 octets." 13 14 DEFVAL { 0 } 15 ::= { dot11HTStationConfigEntry 7 } 16 17 18 dot11MinimumMPDUStartSpacing OBJECT-TYPE 19 20 SYNTAX INTEGER (0..7) 21 22 MAX-ACCESS read-only 23 STATUS current 24 25 DESCRIPTION 26 "This attribute indicates the minimum time between the start 27 28 of adjacent MPDUs within an A-MPDU. This time is measured at the PHY-SAP; the 29 number of octets between the start of two consecutive MPDUs in A-MPDU shall 30 31 be equal or greater than (dot11MinimumMPDUStartSpacing*PHY-bit-rate)/8. The 32 encoding of the minimum time to this attribute is: 33 0 no restriction 34 35 1 1/4 µs 36 37 2 1/2 µs 38 3 1 µs 39 40 4 2 µs 41 5 4 µs 42 43 6 8 µs 44 45 7 16 µs " 46 DEFVAL { 0 } 47 48 ::= { dot11HTStationConfigEntry 8 } 49 50 51 dot11PCOOptionImplemented OBJECT-TYPE 52 SYNTAX TruthValue 53 54 MAX-ACCESS read-only 55 56 STATUS current 57 DESCRIPTION 58 59 "This attribute, when TRUE, indicates that the station 60 implementation is capable of supporting Phased Coexistence Operation." 61 62 DEFVAL { false } 63 ::= { dot11HTStationConfigEntry 9 } 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 dot11TransitionTime OBJECT-TYPE 2 3 SYNTAX INTEGER (0..3) 4 MAX-ACCESS read-only 5 6 STATUS current 7 8 DESCRIPTION 9 "This attribute indicates that the maximum transition time 10 11 within which the STA can switch between 20 MHz channel width and 40 MHz 12 channel width with a high probability. The encoding of the transition time to 13 this attribute is: 14 15 0 no transition 16 17 1 400 µs 18 2 1500 µs 19 20 3 5000 µs " 21 22 DEFVAL { 2 } 23 ::= { dot11HTStationConfigEntry 10 } 24 25 26 dot11MCSFeedbackOptionImplemented OBJECT-TYPE 27 28 SYNTAX INTEGER { none(0), unsolicited (2), both (3) } 29 30 MAX-ACCESS read-only 31 STATUS current 32 33 DESCRIPTION 34 35 "This attribute indicates the MCS feed back capability 36 supported by the station implementation." 37 38 DEFVAL { 0 } 39 ::= { dot11HTStationConfigEntry 11 } 40 41 42 dot11HTControlFieldSupported OBJECT-TYPE 43 44 SYNTAX TruthValue 45 46 MAX-ACCESS read-only 47 STATUS current 48 49 DESCRIPTION 50 51 "This attribute, when TRUE, indicates that the station 52 implementation is capable of receiving HT Control field." 53 54 DEFVAL { false } 55 ::= { dot11HTStationConfigEntry 12 } 56 57 58 dot11RDResponderOptionImplemented OBJECT-TYPE 59 60 SYNTAX TruthValue 61 62 MAX-ACCESS read-only 63 STATUS current 64 65 DESCRIPTION

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 "This attribute, when TRUE, indicates that the station 2 3 implementation is capable operating as an RD responder." 4 DEFVAL { false } 5 6 ::= { dot11HTStationConfigEntry 13 } 7 8 9 dot11SPPAMSDUCapable OBJECT-TYPE 10 11 SYNTAX TruthValue 12 MAX-ACCESS read-write 13 14 STATUS current 15 DESCRIPTION 16 17 "This attribute, when TRUE, indicates that the STA 18 implementation is capable of protecting the A-MSDU bit (Bit 7) in the QoS 19 20 Control field when dot11RSNAEnabled is TRUE." 21 DEFVAL { false } 22 23 ::= { dot11HTStationConfigEntry 14 } 24 25 26 dot11SPPAMSDURequired OBJECT-TYPE 27 28 SYNTAX TruthValue 29 MAX-ACCESS read-write 30 31 STATUS current 32 33 DESCRIPTION 34 "This attribute, when TRUE, indicates that the STA is 35 36 configured to disallow (not to send or receive) of PP A-MSDUs when 37 dot11RSNAEnabled is TRUE." 38 39 DEFVAL { false } 40 ::= { dot11HTStationConfigEntry 15 } 41 42 43 dot11FortyMHzOptionImplemented OBJECT-TYPE 44 45 SYNTAX TruthValue 46 47 MAX-ACCESS read-write 48 STATUS current 49 50 DESCRIPTION 51 “This attribute, when TRUE, indicates that the STA is capable 52 53 of transmitting and receiving on a 40 MHz channel using a 40 MHz mask.” 54 DEFVAL ( false } 55 56 ::= { dot11HTStationConfigEntry 16 } 57 58 Change Dot11OperationEntry in dot11OperationTable as follows: 59 60 Dot11OperationEntry ::= 61 62 SEQUENCE { 63 dot11MACAddress MacAddress, 64 65 dot11RTSThreshold INTEGER,

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 dot11ShortRetryLimit INTEGER, 2 3 dot11LongRetryLimit INTEGER, 4 dot11FragmentationThreshold INTEGER, 5 6 dot11MaxTransmitMSDULifetime Unsigned32, 7 8 dot11MaxReceiveLifetime Unsigned32, 9 dot11ManufacturerID DisplayString, 10 11 dot11ProductID DisplayString, 12 dot11CAPLimit INTEGER, 13 14 dot11HCCWmin INTEGER, 15 16 dot11HCCWmax INTEGER, 17 dot11HCCAIFSN INTEGER, 18 19 dot11ADDBAResponseTimeout INTEGER, 20 dot11ADDTSResponseTimeout INTEGER, 21 22 dot11ChannelUtilizationBeaconInterval INTEGER, 23 24 dot11ScheduleTimeout INTEGER, 25 dot11DLSResponseTimeout INTEGER, 26 27 dot11QAPMissingAckRetryLimit INTEGER, 28 dot11EDCAAveragingPeriod INTEGER, 29 30 dot11PeerStatsTableBSSaging Unsigned32, 31 32 dot11PeerStatsTableIBSSaging Unsigned32, 33 dot11HTProtection INTEGER, 34 35 dot11RIFSMode TruthValue, 36 dot11PSMPControlledAccess TruthValue, 37 38 dot11ServiceIntervalGranularity INTEGER, 39 40 dot11DualCTSProtection TruthValue, 41 dot11LSIGTXOPFullProtectionEnabled TruthValue, 42 43 dot11NonGFEntitiesPresent TruthValue, 44 dot11PCOActivated TruthValue, 45 46 dot11PCOFortyMaxDuration INTEGER, 47 48 dot11PCOTwentyMaxDuration INTEGER, 49 dot11PCOFortyMinDuration INTEGER, 50 51 dot11PCOTwentyMinDuration INTEGER 52 dot11FortyMHzIntolerant TruthValue, 53 54 dot11BSSWidthTriggerScanInterval INTEGER, 55 dot11BSSWidthChannelTransitionDelayFactor INTEGER, 56 57 dot11OBSSScanPassiveDwell INTEGER, 58 59 dot11OBSSScanActiveDwell INTEGER, 60 dot11OBSSScanPassiveTotalPerChannel INTEGER, 61 62 dot11OBSSScanActiveTotalPerChannel INTEGER, 63 dot112040BSSCoexistenceManagementSupport TruthValue, 64 65 dot11OBSSScanActivityThreshold INTEGER

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 } 2 3 Change the entry for dot11RTSThreshold as follows: 4 5 dot11RTSThreshold OBJECT-TYPE 6 7 SYNTAX INTEGER (0..65536) 8 MAX-ACCESS read-write 9 10 STATUS current 11 DESCRIPTION 12 13 "This attribute shall indicate the number of octets in an MPDUPSDU, 14 below which an RTS/CTS handshake shall not be performed, except as RTS/CTS is 15 16 used as a cross modulation protection mechanism as defined in 9.10. An RTS/ 17 CTS handshake shall be performed at the beginning of any frame exchange 18 sequence where the MPDUPSDU is of type Data or Management, the MPDUPSDU has 19 20 an individual address in the Address 1 field, and the length of the MPDUPSDU 21 is greater than this threshold. Setting this attribute to be larger than the 22 maximum MSDUPSDU size shall have the effect of turning off the RTS/CTS 23 24 handshake for frames of Data or Management type transmitted by this STA. 25 Setting this attribute to zero shall have the effect of turning on the RTS/ 26 27 CTS handshake for all frames of Data or Management type transmitted by this 28 STA. The default value of this attribute shall be 3000." 29 DEFVAL { 65535 }::= { dot11OperationEntry 2 } 30 31 32 Change the entry for dot11FragmentationThreshold as follows: 33 34 dot11FragmentationThreshold OBJECT-TYPE 35 SYNTAX INTEGER (256..23408000) 36 MAX-ACCESS read-write 37 38 STATUS current 39 DESCRIPTION 40 41 "This attribute shall specify the current maximum size, in 42 octets, of the MPDU PSDU that may be delivered to the PHY. 43 This maximum size does not apply when an MSDU or A-MSDU is 44 45 transmitted using an HT-immediate or HT-delayed Block Ack 46 agreement, or when an MSDU, A-MSDU or MMPDU is carried in an 47 A-MPDU. An MSDU, A-MSDU or MMPDU shall be broken into 48 fragments if its size exceeds the value of this attribute 49 50 after adding MAC headers and trailers. Except as described 51 above, aAn MSDU, A-MSDU or MMPDU shall be fragmented when the 52 resulting frame has an individual address in the Address 1 53 field, and the length of the frame is larger than this 54 55 threshold. The default value for this attribute shall be the 56 lesser of 3000 8000 or the aMPDUMaxLength or the 57 aPSDUMaxLength of the attached PHY and shall never exceed the 58 lesser of 3000 8000 or the aMPDUMaxLength or the 59 60 aPSDUMaxLength of the attached PHY. The value of this 61 attribute shall never be less than 256." 62 ::= { dot11OperationEntry 5 } 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Insert the following definitions behind the definition of dot11EDCAAveragingPeriod: 2 3 dot11HTProtection OBJECT-TYPE 4 5 SYNTAX INTEGER { HTNoProtection (O), HTNonmemberProtection(1), 6 HT20MHzProtection(2), HTNonHTmixed(3) } 7 8 MAX-ACCESS read-write 9 STATUS current 10 11 DESCRIPTION 12 “This attribute indicates the level of protection that needs 13 14 to be provided to the transmissions in an IEEE 802.11 network with HT STAs.” 15 DEFVAL { HTNoProtection} 16 17 ::= { dot11OperationEntry 21 } 18 19 20 dot11RIFSMode OBJECT-TYPE 21 22 SYNTAX TruthValue 23 MAX-ACCESS read-write 24 25 STATUS current 26 DESCRIPTION 27 28 “This attribute, when TRUE, indicates that use of RIFS is 29 allowed in the BSS.” 30 31 DEFVAL { false } 32 ::= { dot11OperationEntry 22 } 33 34 35 36 dot11PSMPControlledAccess OBJECT-TYPE 37 SYNTAX TruthValue 38 39 MAX-ACCESS read-write 40 STATUS current 41 42 DESCRIPTION 43 “This attribute, when TRUE indicates that the AP accepts 44 45 associations only from STAs for which dot11PSMPOptionImplemented is TRUE.” 46 DEFVAL { false } 47 48 ::= { dot11OperationEntry 23 } 49 50 51 dot11ServiceIntervalGranularity OBJECT-TYPE 52 53 SYNTAX INTEGER (0..7) 54 MAX-ACCESS read-write 55 56 STATUS current 57 DESCRIPTION 58 59 “This attribute indicates the Service Interval Granularity to 60 be used for scheduled PSMP. The value of the granularity is given by 61 62 (dot11ServiceIntervalGranularity+1)*5 ms.” 63 DEFVAL { 0 } 64 65 ::= { dot11OperationEntry 24 }

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 2 3 dot11DualCTSProtection OBJECT-TYPE 4 SYNTAX TruthValue 5 6 MAX-ACCESS read-write 7 8 STATUS current 9 DESCRIPTION 10 11 “This attribute, when TRUE indicates that the AP uses dual CTS 12 protection to protect the non-STBC frame and STBC frame transmissions.” 13 14 DEFVAL { false } 15 ::= { dot11OperationEntry 25 } 16 17 18 dot11LSIGTXOPFullProtectionEnabled OBJECT-TYPE 19 20 SYNTAX TruthValue 21 22 MAX-ACCESS read-write 23 STATUS current 24 25 DESCRIPTION 26 “This attribute, when TRUE, indicates that the LSIG TXOP 27 28 Protection may be used by STAs that have the attribute 29 dot11LSigTxopProtectionOptionImplemented set to TRUE.” 30 31 DEFVAL { false } 32 ::= { dot11OperationEntry 26 } 33 34 35 dot11NonGFEntitiesPresent OBJECT-TYPE 36 37 SYNTAX TruthValue 38 39 MAX-ACCESS read-write 40 STATUS current 41 42 DESCRIPTION 43 “This attribute, when TRUE, indicates that STA that are not 44 45 HT-greenfield Capable are present in the BSS.” 46 DEFVAL { false } 47 48 ::= { dot11OperationEntry 27 } 49 50 51 dot11PCOActivated OBJECT-TYPE 52 53 SYNTAX TruthValue 54 MAX-ACCESS read-write 55 56 STATUS current 57 DESCRIPTION 58 59 “This attribute, when TRUE, indicates that the PCO is 60 activated.” 61 62 DEFVAL { false } 63 ::= { dot11OperationEntry 28 } 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 dot11PCOFortyMaxDuration OBJECT-TYPE 2 3 SYNTAX INTEGER (1..200) 4 MAX-ACCESS read-write 5 6 STATUS current 7 8 DESCRIPTION 9 "The attribute indicates the maximum duration of 40 MHz phase in TU under PCO 10 11 operation. The value of this attribute shall be equal to or larger than 12 dot11PCOFortyMinDuration." 13 DEFVAL { 30 } 14 15 ::= { dot11OperationEntry 29 } 16 17 18 dot11PCOTwentyMaxDuration OBJECT-TYPE 19 20 SYNTAX INTEGER (1..200) 21 MAX-ACCESS read-write 22 23 STATUS current 24 25 DESCRIPTION 26 "The attribute indicates the maximum duration of 20 MHz phase in TU under PCO 27 28 operation. The value of this attribute shall be equal to or larger than 29 dot11PCOTwentyMinDuration." 30 31 DEFVAL { 30 } 32 ::= { dot11OperationEntry 30 } 33 34 35 dot11PCOFortyMinDuration OBJECT-TYPE 36 37 SYNTAX INTEGER (1..200) 38 MAX-ACCESS read-write 39 40 STATUS current 41 42 DESCRIPTION 43 "The attribute indicates the minimum duration of 40 MHz phase in TU under PCO 44 45 operation." 46 DEFVAL { 20 } 47 48 ::= { dot11OperationEntry 31 } 49 50 51 dot11PCOTwentyMinDuration OBJECT-TYPE 52 SYNTAX INTEGER (1..200) 53 54 MAX-ACCESS read-write 55 56 STATUS current 57 DESCRIPTION 58 59 "The attribute indicates the minimum duration of 20 MHz phase in TU under PCO 60 operation." 61 62 DEFVAL { 20 } 63 ::= { dot11OperationEntry 32 } 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 dot11FortyMHzIntolerant OBJECT-TYPE 2 3 SYNTAX TruthValue 4 5 MAX-ACCESS read-write 6 STATUS current 7 8 DESCRIPTION 9 “This attribute, when TRUE, indicates that the STA requests that 40 MHz mask 10 11 PPDUs are not transmitted within range of the STA.” 12 DEFVAL { false } 13 14 ::= { dot11OperationEntry 33 } 15 16 17 dot11BSSWidthTriggerScanInterval OBJECT-TYPE 18 19 SYNTAX INTEGER (10..900) 20 21 MAX-ACCESS read-write 22 STATUS current 23 24 DESCRIPTION 25 “This attribute indicates the maximum interval in seconds between scan 26 27 operations to be performed to detect BSS channel width trigger events.” 28 DEFVAL { 300 } 29 30 :::= { dot11OperationEntry 34 } 31 32 33 dot11BSSWidthChannelTransitionDelayFactor OBJECT-TYPE 34 35 SYNTAX INTEGER (5..100) 36 37 MAX-ACCESS read-write 38 STATUS current 39 40 DESCRIPTION 41 42 “This attribute indicates the minimum ratio between the delay time in 43 performing a switch from 20 MHz BSS operation to 20/40 MHz BSS operation and 44 the maximum interval between overlapping BSS scan operations.” 45 46 DEFVAL { 5 } 47 48 :::= { dot11OperationEntry 35 } 49 50 51 dot11OBSSScanPassiveDwell OBJECT-TYPE 52 SYNTAX INTEGER (5..1000) 53 54 MAX-ACCESS read-write 55 56 STATUS current 57 DESCRIPTION 58 59 “This attribute indicates the minimum amount of time in TU that the STA 60 continuously scans each channel when performing a passive OBSS scan 61 62 operation.” 63 DEFVAL { 20 } 64 65 :::= { dot11OperationEntry 36 }

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 2 3 dot11OBSSScanActiveDwell OBJECT-TYPE 4 5 SYNTAX INTEGER (10..1000) 6 MAX-ACCESS read-write 7 8 STATUS current 9 DESCRIPTION 10 11 “This attribute indicates the minimum amount of time in TU that the STA 12 continuously scans each channel when performing an active OBSS scan 13 14 operation.” 15 DEFVAL { 10 } 16 17 ::= { dot11OperationEntry 37 } 18 19 20 dot11OBSSScanPassiveTotalPerChannel OBJECT-TYPE 21 22 SYNTAX INTEGER (200..10000) 23 24 MAX-ACCESS read-write 25 STATUS current 26 27 DESCRIPTION 28 “This attribute indicates the minimum total amount of time in TU that the STA 29 30 scans each channel when performing a passive OBSS scan operation.” 31 DEFVAL { 200 } 32 33 ::= { dot11OperationEntry 38 } 34 35 36 dot11OBSSScanActiveTotalPerChannel OBJECT-TYPE 37 38 SYNTAX INTEGER (20..10000) 39 40 MAX-ACCESS read-write 41 STATUS current 42 43 DESCRIPTION 44 “This attribute indicates the minimum total amount of time in TU that the STA 45 46 scans each channel when performing an active OBSS scan operation.” 47 DEFVAL { 20 } 48 49 ::= { dot11OperationEntry 39 } 50 51 52 dot112040BSSCoexistenceManagementSupport OBJECT-TYPE 53 54 SYNTAX TruthValue 55 56 MAX-ACCESS read-write 57 STATUS current 58 59 DESCRIPTION 60 “This attribute, when TRUE, indicates that the STA supports the transmission 61 62 and reception of the 20/40 BSS Coexistence Management frame.” 63 DEFVAL { false } 64 65 ::= { dot11OperationEntry 40 }

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 2 3 dot11OBSSScanActivityThreshold OBJECT-TYPE 4 5 SYNTAX INTEGER (0..100) 6 MAX-ACCESS read-write 7 8 STATUS current 9 DESCRIPTION 10 11 “This attribute indicates in hundredths of percent, the maximum total time 12 that a STA may be active on the medium during a period of 13 14 dot11BSSWidthChannelTransitionDelayFactor * dot11BSSWidthTriggerScanInterval 15 seconds without being obligated to perform OBSS Scan operations. The default 16 value of this attribute is 25, which equates to 0.25%.” 17 18 DEFVAL { 25 } 19 20 ::= { dot11OperationEntry 41} 21 22 Change Dot11CountersEntry in dot11CountersTable as follows: 23 24 Dot11CountersEntry ::= 25 SEQUENCE { 26 27 dot11TransmittedFragmentCount Counter32, 28 dot11MulticastTransmittedFrameCount Counter32, 29 30 dot11FailedCount Counter32, 31 dot11RetryCount Counter32, 32 33 dot11MultipleRetryCount Counter32, 34 dot11FrameDuplicateCount Counter32, 35 36 dot11RTSSuccessCount Counter32, 37 dot11RTSFailureCount Counter32, 38 39 dot11ACKFailureCount Counter32, 40 dot11ReceivedFragmentCount Counter32, 41 dot11MulticastReceivedFrameCount Counter32, 42 43 dot11FCSErrorCount Counter32, 44 dot11TransmittedFrameCount Counter32, 45 46 dot11WEPUndecryptableCount Counter32, 47 dot11QoSDiscardedFragmentCount Counter32, 48 49 dot11AssociatedStationCount Counter32, 50 dot11QoSCFPollsReceivedCount Counter32, 51 52 dot11QoSCFPollsUnusedCount Counter32, 53 dot11QoSCFPollsUnusableCount Counter32, 54 55 dot11QoSCFPollsLostCount Counter32, 56 dot11TransmittedAMSDUCount Counter32, 57 58 dot11FailedAMSDUCount Counter32, 59 dot11RetryAMSDUCount Counter32, 60 61 dot11MultipleRetryAMSDUCount Counter32, 62 dot11TransmittedOctetsInAMSDUCount Counter64, 63 dot11AMSDUAckFailureCount Counter32, 64 65 dot11ReceivedAMSDUCount Counter32,

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 dot11ReceivedOctetsInAMSDUCount Counter64, 2 3 dot11TransmittedAMPDUCount Counter32, 4 dot11TransmittedMPDUsInAMPDUCount Counter32, 5 dot11TransmittedOctetsInAMPDUCount Counter64, 6 7 dot11AMPDUReceivedCount Counter32, 8 dot11MPDUInReceivedAMPDUCount Counter32, 9 10 dot11ReceivedOctetsInAMPDUCount Counter64, 11 dot11AMPDUDelimiterCRCErrorCount Counter32, 12 13 dot11ImplicitBARFailureCount Counter32, 14 dot11ExplicitBARFailureCount Counter32, 15 16 dot11ChannelWidthSwitchCount Counter32, 17 dot11TwentyMHzFrameTransmittedCount Counter32, 18 19 dot11FortyMHzFrameTransmittedCount Counter32, 20 dot11TwentyMHzFrameReceivedCount Counter32, 21 22 dot11FortyMHzFrameReceivedCount Counter32, 23 dot11PSMPUTTGrantDuration Counter32, 24 25 dot11PSMPUTTUsedDuration Counter32, 26 dot11GrantedRDGUsedCount Counter32, 27 28 dot11GrantedRDGUnusedCount Counter32, 29 dot11TransmittedFramesInGrantedRDGCount Counter32, 30 dot11TransmittedOctetsInGrantedRDGCount Counter64, 31 32 dot11BeamformingFrameCount Counter32, 33 dot11DualCTSSuccessCount Counter32, 34 35 dot11DualCTSFailureCount Counter32, 36 dot11STBCCTSSuccessCount Counter32, 37 38 dot11STBCCTSFailureCount Counter32, 39 dot11nonSTBCCTSSuccessCount Counter32, 40 41 dot11nonSTBCCTSFailureCount Counter32, 42 dot11RTSLSIGSuccessCount Counter32, 43 44 dot11RTSLSIGFailureCount Counter32, 45 dot11PBACErrors Counter32 46 47 } 48 49 50 51 Insert the following definitions after the existing dot11CountersEntry attributes: 52 53 dot11TransmittedAMSDUCount OBJECT-TYPE 54 SYNTAX Counter32 55 56 MAX-ACCESS read-only 57 STATUS current 58 59 DESCRIPTION 60 61 "This counter shall be incremented for an acknowledged A-MSDU 62 frame with an individual address in the address 1 field or an A-MSDU frame 63 with a group address in the address 1 field." 64 65 ::= { dot11CountersEntry 21 }

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 2 3 dot11FailedAMSDUCount OBJECT-TYPE 4 SYNTAX Counter32 5 6 MAX-ACCESS read-only 7 8 STATUS current 9 DESCRIPTION 10 11 "This counter shall be incremented when an A-MSDU is not 12 transmitted successfully due to the number of transmit attempts exceeding 13 either the dot11ShortRetryLimit or dot11LongRetryLimit." 14 15 ::= { dot11CountersEntry 22 } 16 17 18 dot11RetryAMSDUCount OBJECT-TYPE 19 20 SYNTAX Counter32 21 MAX-ACCESS read-only 22 23 STATUS current 24 25 DESCRIPTION 26 "This counter shall be incremented when an A-MSDU is 27 28 successfully transmitted after one or more retransmissions." 29 ::= { dot11CountersEntry 23 } 30 31 32 dot11MultipleRetryAMSDUCount OBJECT-TYPE 33 34 SYNTAX Counter32 35 MAX-ACCESS read-only 36 37 STATUS current 38 39 DESCRIPTION 40 "This counter shall be incremented when an A-MSDU is 41 42 successfully transmitted after more than one retransmission." 43 ::= { dot11CountersEntry 24 } 44 45 46 dot11TransmittedOctetsInAMSDU OBJECT-TYPE 47 48 SYNTAX Counter64 49 50 MAX-ACCESS read-only 51 STATUS current 52 53 DESCRIPTION 54 "This counter shall be incremented by the number of octets in 55 56 the framebody of an A-MSDU frame when an A-MSDU frame is successfully 57 transmitted." 58 59 ::= { dot11CountersEntry 25 } 60 61 62 dot11AMSDUAckFailureCount OBJECT-TYPE 63 SYNTAX Counter32 64 65 MAX-ACCESS read-only

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 STATUS current 2 3 DESCRIPTION 4 "This counter shall be incremented when an acknowledgement to 5 6 an A-MSDU is not received when expected. This acknowledgement can be in an 7 ACK or the BlockAck frame." 8 9 ::= { dot11CountersEntry 26 } 10 11 12 dot11ReceivedAMSDUCount OBJECT-TYPE 13 14 SYNTAX Counter32 15 MAX-ACCESS read-only 16 17 STATUS current 18 DESCRIPTION 19 20 "This counter shall be incremented for a received A-MSDU frame 21 with the station’s MAC address in the address 1 field or an A-MSDU frame with 22 23 a group address in the address 1 field." 24 ::= { dot11CountersEntry 27 } 25 26 27 dot11ReceivedOctetsInAMSDUCount OBJECT-TYPE 28 29 SYNTAX Counter64 30 31 MAX-ACCESS read-only 32 STATUS current 33 34 DESCRIPTION 35 "This counter shall be incremented by the number of octets in 36 37 the framebody of an A-MSDU frame when an A-MSDU frame is received." 38 ::= { dot11CountersEntry 28 } 39 40 41 42 dot11TransmittedAMPDUCount OBJECT-TYPE 43 SYNTAX Counter32 44 45 MAX-ACCESS read-only 46 STATUS current 47 48 DESCRIPTION 49 "This counter shall be incremented when an A-MPDU is 50 51 transmitted." 52 ::= { dot11CountersEntry 29 } 53 54 55 56 dot11TransmittedMPDUsInAMPDUCount OBJECT-TYPE 57 SYNTAX Counter32 58 59 MAX-ACCESS read-only 60 STATUS current 61 62 DESCRIPTION 63 64 "This counter shall increment by the number of MPDUs in the A- 65 MPDU when an A-MPDU is transmitted."

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 ::= { dot11CountersEntry 30 } 2 3 4 dot11TransmittedOctetsInAMPDUCount OBJECT-TYPE 5 6 SYNTAX Counter64 7 8 MAX-ACCESS read-only 9 STATUS current 10 11 DESCRIPTION 12 13 "This counter shall be incremented by the number of octets in 14 the A-MPDU frame when an A-MPDU frame is transmitted." 15 16 ::= { dot11CountersEntry 31 } 17 18 19 dot11AMPDUReceivedCount OBJECT-TYPE 20 SYNTAX Counter32 21 22 MAX-ACCESS read-only 23 24 STATUS current 25 DESCRIPTION 26 27 "This counter shall be incremented when the MAC receives an A- 28 MPDU from the PHY." 29 30 ::= { dot11CountersEntry 32 } 31 32 33 dot11MPDUInReceivedAMPDUCount OBJECT-TYPE 34 35 SYNTAX Counter32 36 MAX-ACCESS read-only 37 38 STATUS current 39 40 DESCRIPTION 41 "This counter shall be incremented by the number of MPDUs 42 43 received in the A-MPDU when an A-MPDU is received." 44 ::= { dot11CountersEntry 33 } 45 46 47 dot11ReceivedOctetsInAMPDUCount OBJECT-TYPE 48 49 SYNTAX Counter64 50 51 MAX-ACCESS read-only 52 STATUS current 53 54 DESCRIPTION 55 "This counter shall be incremented by the number of octets in 56 57 the A-MPDU frame when an A-MPDU frame is received." 58 ::= { dot11CountersEntry 34 } 59 60 61 62 dot11AMPDUDelimiterCRCErrorCount OBJECT-TYPE 63 SYNTAX Counter32 64 65 MAX-ACCESS read-only

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 STATUS current 2 3 DESCRIPTION 4 "This counter shall be incremented when an MPDU delimiter has 5 6 a CRC error when this is the first CRC error in the received A-MPDU or when 7 the previous delimiter has been decoded correctly.” 8 9 ::= { dot11CountersEntry 35 } 10 11 12 dot11ImplicitBARFailureCount OBJECT-TYPE 13 SYNTAX Counter32 14 15 MAX-ACCESS read-only 16 17 STATUS current 18 DESCRIPTION 19 20 "This counter shall be incremented when the expected BlockAck 21 is not received in response to an Implicit BlockAckReq frame.” 22 23 ::= { dot11CountersEntry 36 } 24 25 26 dot11ExplicitBARFailureCount OBJECT-TYPE 27 28 SYNTAX Counter32 29 MAX-ACCESS read-only 30 31 STATUS current 32 DESCRIPTION 33 34 "This counter shall be incremented when the expected BlockAck 35 is not received in response to an Explicit BlockAckReq.” 36 37 ::= { dot11CountersEntry 37 } 38 39 40 dot11ChannelWidthSwitchCount OBJECT-TYPE 41 42 SYNTAX Counter32 43 MAX-ACCESS read-only 44 45 STATUS current 46 DESCRIPTION 47 48 "This counter shall be increment when the bandwidth used is 49 switched from 20 to 40 or vice-versa.” 50 51 ::= { dot11CountersEntry 38 } 52 53 54 dot11TwentyMHzFrameTransmittedCount OBJECT-TYPE 55 56 SYNTAX Counter32 57 MAX-ACCESS read-only 58 59 STATUS current 60 DESCRIPTION 61 62 "This counter shall be incremented when a Frame is transmitted 63 only on the primary channel.” 64 65 ::= { dot11CountersEntry 39 }

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 2 3 dot11FortyMHzFrameTransmittedCount OBJECT-TYPE 4 SYNTAX Counter32 5 6 MAX-ACCESS read-only 7 8 STATUS current 9 DESCRIPTION 10 11 "This counter shall be incremented when a Frame is transmitted 12 on both control and secondary channels.” 13 14 ::= { dot11CountersEntry 40 } 15 16 17 dot11TwentyMHzFrameReceivedCount OBJECT-TYPE 18 19 SYNTAX Counter32 20 MAX-ACCESS read-only 21 22 STATUS current 23 24 DESCRIPTION 25 "This counter shall be incremented when a Frame is received 26 27 only on the primary channel.” 28 ::= { dot11CountersEntry 41 } 29 30 31 dot11FortyMHzFrameReceivedCount OBJECT-TYPE 32 33 SYNTAX Counter32 34 35 MAX-ACCESS read-only 36 STATUS current 37 38 DESCRIPTION 39 40 "This counter shall be incremented when a Frame is received on 41 both the control and secondary channels.” 42 43 ::= { dot11CountersEntry 42 } 44 45 46 dot11PSMPUTTGrantDuration OBJECT-TYPE 47 SYNTAX Counter32 48 49 MAX-ACCESS read-only 50 51 STATUS current 52 DESCRIPTION 53 54 "This counter contains the cumulative duration of PSMP-UTT 55 granted to the STA, in units of 4µs." 56 57 ::= { dot11CountersEntry 43 } 58 59 60 dot11PSMPUTTUsedDuration OBJECT-TYPE 61 62 SYNTAX Counter32 63 MAX-ACCESS read-only 64 65 STATUS current

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 DESCRIPTION 2 3 "This counter contains the cumulative duration of transmission 4 by the STA during its allocated PSMP-UTT, in units of 4µs" 5 6 ::= { dot11CountersEntry 44 } 7 8 9 10 11 dot11GrantedRDGUsedCount OBJECT-TYPE 12 SYNTAX Counter32 13 14 MAX-ACCESS read-only 15 16 STATUS current 17 DESCRIPTION 18 19 "This counter at the RD initiator shall be incremented when an 20 allocated RDG is used by the station, apart from transmitting a response 21 22 frame such as ACK or BlockAck frames." 23 ::= { dot11CountersEntry 45 } 24 25 26 27 dot11GrantedRDGUnusedCount OBJECT-TYPE 28 SYNTAX Counter32 29 30 MAX-ACCESS read-only 31 32 STATUS current 33 DESCRIPTION 34 35 "This counter at the initiator shall be incremented when an 36 allocated RDG is not used by the station, apart from transmitting a response 37 38 frame such as ACK or BlockAck frames." 39 ::= { dot11CountersEntry 46 } 40 41 42 43 dot11TransmittedFramesInGrantedRDGCount OBJECT-TYPE 44 SYNTAX Counter32 45 46 MAX-ACCESS read-only 47 STATUS current 48 49 DESCRIPTION 50 51 "This counter at the initiator shall be incremented for every 52 frame, other than response frames such as ACK or BlockAck frames, 53 transmitted by the station during a granted RDG." 54 55 ::= { dot11CountersEntry 47 } 56 57 58 dot11TransmittedOctetsInGrantedRDGCount OBJECT-TYPE 59 60 SYNTAX Counter64 61 62 MAX-ACCESS read-only 63 STATUS current 64 65 DESCRIPTION

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 "This counter at the initiator shall be incremented by the 2 3 number of octets in the framebody of a frame, other than response frames such 4 as ACK or BlockAck frames, transmitted by the station during a granted RDG." 5 6 ::= { dot11CountersEntry 48 } 7 8 9 dot11BeamformingFrameCount OBJECT-TYPE 10 SYNTAX Counter32 11 12 MAX-ACCESS read-only 13 STATUS current 14 15 DESCRIPTION 16 17 "This counter shall be incremented when the transmitter sends 18 a frame with new/updated beam forming parameters." 19 20 ::= { dot11CountersEntry 49 } 21 22 23 dot11DualCTSSuccessCount OBJECT-TYPE 24 SYNTAX Counter32 25 26 MAX-ACCESS read-only 27 28 STATUS current 29 DESCRIPTION 30 31 "This counter shall be incremented when AP sends a dual CTS in 32 response to a STA initiating TXOP in extended range." 33 34 ::= { dot11CountersEntry 50 } 35 36 37 38 dot11DualCTSFailureCount OBJECT-TYPE 39 40 SYNTAX Counter32 41 42 MAX-ACCESS read-only 43 STATUS current 44 45 DESCRIPTION 46 "This counter shall be incremented when AP fails to send a 47 48 dual CTS in response to a STA initiating TXOP in extended range." 49 ::= { dot11CountersEntry 51 } 50 51 52 dot11STBCCTSSuccessCount OBJECT-TYPE 53 54 SYNTAX Counter32 55 56 MAX-ACCESS read-only 57 STATUS current 58 59 DESCRIPTION 60 "This counter shall be incremented when AP does not detect a 61 62 collision PIFS after sending a CTS to self STBC frame in extended range." 63 ::= { dot11CountersEntry 52 } 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 dot11STBCCTSFailureCount OBJECT-TYPE 2 3 SYNTAX Counter32 4 MAX-ACCESS read-only 5 6 STATUS current 7 8 DESCRIPTION 9 "This counter shall be incremented when AP detects a collision 10 11 PIFS after sending a CTS to self STBC frame in extended range." 12 ::= { dot11CountersEntry 53 } 13 14 15 dot11nonSTBCCTSSuccessCount OBJECT-TYPE 16 17 SYNTAX Counter32 18 19 MAX-ACCESS read-only 20 STATUS current 21 22 DESCRIPTION 23 "This counter shall be incremented when AP does not detect a 24 25 collision PIFS after sending a CTS to self that is an non-STBC frame in 26 extended range." 27 28 ::= { dot11CountersEntry 54 } 29 30 31 dot11nonSTBCCTSFailureCount OBJECT-TYPE 32 SYNTAX Counter32 33 34 MAX-ACCESS read-only 35 36 STATUS current 37 DESCRIPTION 38 39 "This counter shall be incremented when AP detects a collision 40 PIFS after sending a CTS to self that is an non-STBC frame in extended 41 42 range." 43 ::= { dot11CountersEntry 55 } 44 45 46 dot11RTSLSIGSuccessCount OBJECT-TYPE 47 48 SYNTAX Counter32 49 MAX-ACCESS read-only 50 51 STATUS current 52 53 DESCRIPTION 54 "This counter shall be incremented when the duration/ID field 55 56 is set according to the rules of EPP in the received CTS following a 57 transmission of RTS in EPP mode." 58 59 ::= { dot11CountersEntry 56 } 60 61 62 dot11RTSLSIGFailureCount OBJECT-TYPE 63 SYNTAX Counter32 64 65 MAX-ACCESS read-only

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 STATUS current 2 3 DESCRIPTION 4 "This counter shall be incremented when the duration/ID field 5 6 is not set according to the rules of EPP in the received CTS following a 7 transmission of RTS in EPP mode." 8 9 ::= { dot11CountersEntry 57 } 10 11 12 dot11PBACErrors OBJECT-TYPE 13 14 SYNTAX Counter32 15 MAX-ACCESS read-only 16 17 STATUS current 18 19 DESCRIPTION 20 "This variable indicates the number of errors encountered in the 21 22 PBAC procedures." 23 DEFAULT { 0 } 24 25 ::= { dot11CountersEntry 58} 26 27 28 29 Change dot11PhyType in dot11PhyOperationTable as shown below: 30 31 32 dot11PHYType OBJECT-TYPE 33 34 SYNTAX INTEGER { fhss(1), dsss(2), irbaseband(3), ofdm(4), 35 hrdsss(5), erp(6), ht (7) } 36 37 MAX-ACCESS read-only 38 39 STATUS current 40 DESCRIPTION 41 42 "This is an 8-bit integer value that identifies the PHY type 43 supported by the attached PLCP and PMD. Currently defined values and their 44 45 corresponding PHY types are: 46 47 48 FHSS 2.4 GHz = 01, DSSS 2.4 GHz = 02, IR Baseband = 03, OFDM 5 49 GHz = 04, HRDSSS = 05, ERP = 06, HT = 07" 50 51 ::= { dot11PhyOperationEntry 1 } 52 53 54 55 Change Dot11PhyAntennaEntry as follows: 56 57 Dot11PhyAntennaEntry ::= 58 SEQUENCE { 59 60 dot11CurrentTxAntenna Integer32, 61 62 dot11DiversitySupport INTEGER, 63 dot11CurrentRxAntenna Integer32, 64 65 dot11AntennaSelectionOptionImplemented TruthValue,

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 dot11TransmitExplicitCSIFeedbackASOptionImplemented 2 3 TruthValue, 4 dot11TransmitIndicesFeedbackASOptionImplemented TruthValue, 5 6 dot11ExplicitCSIFeedbackASOptionImplemented TruthValue, 7 dot11TransmitIndicesComputationASOptionImplemented TruthValue, 8 9 dot11ReceiveAntennaSelectionOptionImplemented TruthValue, 10 11 dot11TransmitSoundingPPDUOptionImplemented TruthValue, 12 dot11NumberOfActiveRxAntennas INTEGER 13 14 } 15 16 17 18 Insert the following after the definition of dot11CurrentRxAntenna: 19 20 dot11AntennaSelectionOptionImplemented OBJECT-TYPE 21 SYNTAX TruthValue 22 23 MAX-ACCESS read-only 24 STATUS current 25 26 DESCRIPTION 27 28 “This attribute, when TRUE, indicates that antenna selection 29 is supported by the station implementation. ” 30 31 DEFVAL { false } 32 ::= { dot11PhyAntennaEntry 4 } 33 34 35 dot11TransmitExplicitCSIFeedbackASOptionImplemented OBJECT-TYPE 36 37 SYNTAX TruthValue 38 39 MAX-ACCESS read-only 40 STATUS current 41 42 DESCRIPTION 43 “This attribute, when TRUE, indicates that the transmit 44 45 antenna selection based on explicit CSI feedback is supported by the station 46 implementation. ” 47 48 DEFVAL { false } 49 ::= { dot11PhyAntennaEntry 5 } 50 51 52 53 dot11TransmitIndicesFeedbackASOptionImplemented OBJECT-TYPE 54 SYNTAX TruthValue 55 56 MAX-ACCESS read-only 57 STATUS current 58 59 DESCRIPTION 60 61 “This attribute, when TRUE, indicates that the transmit 62 antenna selection based on antenna indices feedback is supported by the 63 station implementation.” 64 65 DEFVAL { false }

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 ::= { dot11PhyAntennaEntry 6 } 2 3 4 dot11ExplicitCSIFeedbackASOptionImplemented OBJECT-TYPE 5 6 SYNTAX TruthValue 7 8 MAX-ACCESS read-only 9 STATUS current 10 11 DESCRIPTION 12 “This attribute, when TRUE, indicates that the computation of 13 14 CSI and feedback the results to support the peer to do antenna selection is 15 supported by the station implementation.” 16 17 DEFVAL { false } 18 ::= { dot11PhyAntennaEntry 7 } 19 20 21 dot11TransmitIndicesComputationASOptionImplemented OBJECT-TYPE 22 23 SYNTAX TruthValue 24 25 MAX-ACCESS read-only 26 STATUS current 27 28 DESCRIPTION 29 “This attribute, when TRUE, indicates that the transmit 30 31 antenna selection based on antenna indices selection computation and 32 feedback the results to support the peer to do antenna selection is supported 33 34 by the station implementation.” 35 DEFVAL { false } 36 37 ::= { dot11PhyAntennaEntry 8 } 38 39 40 dot11ReceiveAntennaSelectionOptionImplemented OBJECT-TYPE 41 42 SYNTAX TruthValue 43 MAX-ACCESS read-only 44 45 STATUS current 46 DESCRIPTION 47 48 “This attribute, when TRUE, indicates that the receive antenna 49 selection is supported by the station implementation. ” 50 51 DEFVAL { false } 52 ::= { dot11PhyAntennaEntry 9 } 53 54 55 56 dot11TransmitSoundingPPDUOptionImplemented OBJECT-TYPE 57 SYNTAX TruthValue 58 59 MAX-ACCESS read-only 60 STATUS current 61 62 DESCRIPTION 63 64 “This attribute, when TRUE, indicates that the transmission of 65 sounding PPDUs is supported by the station implementation. ”

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 DEFVAL { false } 2 3 ::= { dot11PhyAntennasEntry 10 } 4 5 6 dot11NumberOfActiveRxAntennas OBJECT-TYPE 7 8 SYNTAX INTEGER (1..4) 9 MAX-ACCESS read-write 10 11 STATUS current 12 DESCRIPTION 13 14 "This attribute indicates the number of current active antennas 15 being used to receive." 16 17 ::= { dot11PhyAntennaEntry 11 } 18 19 20 21 Insert the following dot11PhyHTTable after dot11PhyERPTable: 22 23 -- ********************************************************************** 24 -- * dot11 Phy HT TABLE 25 26 -- ********************************************************************** 27 dot11PhyHTTable OBJECT-TYPE 28 29 SYNTAX SEQUENCE OF Dot11PhyHTEntry 30 31 MAX-ACCESS not-accessible 32 STATUS current 33 34 DESCRIPTION 35 "Entry of attributes for dot11PhyHTTable. Implemented as a 36 37 table indexed on ifIndex to allow for multiple instances on an Agent." 38 ::= { dot11phy 15 } 39 40 41 42 dot11PhyHTEntry OBJECT-TYPE 43 SYNTAX Dot11PhyHTEntry 44 45 MAX-ACCESS not-accessible 46 STATUS current 47 48 DESCRIPTION 49 "An entry in the dot11PhyHTEntry Table. ifIndex - Each 802.11 50 51 interface is represented by an ifEntry. Interface tables in this MIB module 52 are indexed by ifIndex." 53 54 INDEX {ifIndex} 55 ::= { dot11PhyHTTable 1 } 56 57 58 59 Dot11PhyHTEntry ::= SEQUENCE { 60 dot11FortyMHzOperationImplemented TruthValue, 61 62 dot11FortyMHzOperationEnabled TruthValue, 63 dot11CurrentPrimaryChannel INTEGER, 64 65 dot11CurrentSecondaryChannel INTEGER,

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 dot11NumberOfSpatialStreamsImplemented INTEGER, 2 3 dot11NumberOfSpatialStreamsEnabled INTEGER, 4 dot11HTGreenfieldOptionImplemented TruthValue, 5 6 dot11HTGreenfieldOptionEnabled TruthValue, 7 8 dot11ShortGIOptionInTwentyImplemented TruthValue, 9 dot11ShortGIOptionInTwentyEnabled TruthValue, 10 11 dot11ShortGIOptionInFortyImplemented TruthValue, 12 dot11ShortGIOptionInFortyEnabled TruthValue, 13 14 dot11LDPCCodingOptionImplemented TruthValue, 15 16 dot11LDPCCodingOptionEnabled TruthValue, 17 dot11TxSTBCOptionImplemented TruthValue, 18 19 dot11TxSTBCOptionEnabled TruthValue, 20 dot11RxSTBCOptionImplemented TruthValue, 21 22 dot11RxSTBCOptionEnabled TruthValue, 23 24 dot11BeamFormingOptionImplemented TruthValue, 25 dot11BeamFormingOptionEnabled TruthValue, 26 27 dot11HighestSupportedDataRate Integer, 28 29 dot11TxMCSSetDefined TruthValue, 30 dot11TxRxMCSSetNotEqual TruthValue, 31 32 dot11TxMaximumNumberSpatialStreamsSupported Integer, 33 dot11TxUnequalModulationSupported TruthValue } 34 35 36 37 dot11FortyMHzOperationImplemented OBJECT-TYPE 38 SYNTAX TruthValue 39 40 MAX-ACCESS read-only 41 STATUS current 42 43 DESCRIPTION 44 45 "This attribute, when TRUE, indicates that the 40 MHz 46 Operation is implemented." 47 48 DEFVAL { false } 49 ::= { dot11PhyHTEntry 1 } 50 51 52 dot11FortyMHzOperationEnabled OBJECT-TYPE 53 54 SYNTAX TruthValue 55 56 MAX-ACCESS read-only 57 STATUS current 58 59 DESCRIPTION 60 "This attribute, when TRUE, indicates that the 40 MHz 61 62 Operation is enabled." 63 DEFVAL { false } 64 65 ::= { dot11PhyHTEntry 2 }

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 2 3 dot11CurrentPrimaryChannel OBJECT-TYPE 4 SYNTAX INTEGER 5 6 MAX-ACCESS read-only 7 8 STATUS current 9 DESCRIPTION 10 11 "This attribute indicates the operating channel. If 20/40 MHz 12 BSS is currently in use then this attribute indicates the primary channel." 13 14 ::= { dot11PhyHTEntry 3 } 15 16 17 dot11CurrentSecondaryChannel OBJECT-TYPE 18 19 SYNTAX INTEGER 20 MAX-ACCESS read-only 21 22 STATUS current 23 DESCRIPTION 24 25 "This attribute indicates the channel number of the secondary 26 channel. If 20/40 MHz BSS is not currently in use, this attribute value shall 27 28 be 0." 29 ::= { dot11PhyHTEntry 4 } 30 31 32 33 34 dot11NumberOfSpatialStreamsImplemented OBJECT-TYPE 35 SYNTAX INTEGER (1..4) 36 37 MAX-ACCESS read-only 38 STATUS current 39 40 DESCRIPTION 41 "This attribute indicates the maximum number of spatial 42 43 streams implemented." 44 DEFVAL { 2 } 45 46 ::= { dot11PhyHTEntry 5 } 47 48 49 dot11NumberOfSpatialStreamsEnabled OBJECT-TYPE 50 SYNTAX INTEGER (1..4) 51 52 MAX-ACCESS read-only 53 STATUS current 54 55 DESCRIPTION 56 "This attribute indicates the maximum number of spatial 57 58 streams enabled." 59 DEFVAL { 2 } 60 61 ::= { dot11PhyHTEntry 6 } 62 63 64 65 dot11HTGreenfieldOptionImplemented OBJECT-TYPE

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 SYNTAX TruthValue 2 3 MAX-ACCESS read-only 4 STATUS current 5 6 DESCRIPTION 7 "This attribute, when TRUE, indicates that the HT-greenfield 8 9 option is implemented." 10 DEFVAL { false } 11 ::= { dot11PhyHTEntry 7 } 12 13 14 dot11HTGreenfieldOptionEnabled OBJECT-TYPE 15 16 SYNTAX TruthValue 17 MAX-ACCESS read-write 18 19 STATUS current 20 DESCRIPTION 21 22 "This attribute, when TRUE, indicates that the HT-greenfield 23 option is enabled." 24 25 DEFVAL { false } 26 ::= { dot11PhyHTEntry 8 } 27 28 29 30 31 dot11ShortGIOptionInTwentyImplemented OBJECT-TYPE 32 SYNTAX TruthValue 33 34 MAX-ACCESS read-only 35 STATUS current 36 37 DESCRIPTION 38 "This attribute, when TRUE, indicates that the Short Guard 39 40 option is implemented for 20 MHz operation." 41 DEFVAL { false } 42 43 ::= { dot11PhyHTEntry 9 } 44 45 46 dot11ShortGIOptionInTwentyEnabled OBJECT-TYPE 47 SYNTAX TruthValue 48 49 MAX-ACCESS read-write 50 STATUS current 51 52 DESCRIPTION 53 "This attribute, when TRUE, indicates that the Short Guard 54 55 option is enabled for 20 MHz operation." 56 DEFVAL { false } 57 58 ::= { dot11PhyHTEntry 10 } 59 60 dot11ShortGIOptionInFortyImplemented OBJECT-TYPE 61 62 SYNTAX TruthValue 63 MAX-ACCESS read-only 64 65 STATUS current

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 DESCRIPTION 2 3 "This attribute, when TRUE, indicates that the Short Guard 4 option is implemented for 40 MHz operation." 5 6 DEFVAL { false } 7 ::= { dot11PhyHTEntry 11 } 8 9 10 dot11ShortGIOptionInFortyEnabled OBJECT-TYPE 11 12 SYNTAX TruthValue 13 MAX-ACCESS read-write 14 15 STATUS current 16 DESCRIPTION 17 18 "This attribute, when TRUE, indicates that the Short Guard 19 option is enabled for 40 MHz operation." 20 21 DEFVAL { false } 22 ::= { dot11PhyHTEntry 12 } 23 24 25 26 dot11LDPCCodingOptionImplemented OBJECT-TYPE 27 SYNTAX TruthValue 28 29 MAX-ACCESS read-only 30 31 STATUS current 32 DESCRIPTION 33 34 "This attribute, when TRUE, indicates that the LDPC coding 35 option is implemented." 36 37 DEFVAL { false } 38 39 ::= { dot11PhyHTEntry 13 } 40 41 42 dot11LDPCCodingOptionEnabled OBJECT-TYPE 43 44 SYNTAX TruthValue 45 MAX-ACCESS read-only 46 47 STATUS current 48 49 DESCRIPTION 50 "This attribute, when TRUE, indicates that the LDPC coding 51 52 option is enabled." 53 DEFVAL { false } 54 55 ::= { dot11PhyHTEntry 14 } 56 57 58 dot11TxSTBCOptionImplemented OBJECT-TYPE 59 60 SYNTAX TruthValue 61 62 MAX-ACCESS read-only 63 STATUS current 64 65 DESCRIPTION

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 "This attribute, when TRUE, indicates that the entity is 2 3 capable of transmitting frames using Space-Time Block Code (STBC) option." 4 DEFVAL { false } 5 6 ::= { dot11PhyHTEntry 15 } 7 8 9 dot11TxSTBCOptionEnabled OBJECT-TYPE 10 11 SYNTAX TruthValue 12 MAX-ACCESS read-only 13 14 STATUS current 15 DESCRIPTION 16 17 "This attribute, when TRUE, indicates that the entity’s 18 capability of transmitting frames using Space-Time Block Code (STBC) option 19 20 is enabled." 21 DEFVAL { false } 22 23 ::= { dot11PhyHTEntry 16 } 24 25 26 dot11RxSTBCOptionImplemented OBJECT-TYPE 27 28 SYNTAX TruthValue 29 MAX-ACCESS read-only 30 31 STATUS current 32 DESCRIPTION 33 34 "This attribute, when TRUE, indicates that the entity is 35 capable of receiving frames that are sent using the Space-Time Block Code 36 37 (STBC)." 38 DEFVAL { false } 39 40 ::= { dot11PhyHTEntry 17 } 41 42 43 dot11RxSTBCOptionEnabled OBJECT-TYPE 44 45 SYNTAX TruthValue 46 MAX-ACCESS read-only 47 48 STATUS current 49 DESCRIPTION 50 51 "This attribute, when TRUE, indicates that the entity’s 52 capability of receiving frames that are sent using the Space-Time Block Code 53 54 (STBC) is enabled." 55 DEFVAL { false } 56 57 ::= { dot11PhyHTEntry 18 } 58 59 60 dot11BeamFormingOptionImplemented OBJECT-TYPE 61 62 SYNTAX TruthValue 63 MAX-ACCESS read-only 64 65 STATUS current

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 DESCRIPTION 2 3 "This attribute, when TRUE, indicates that the Beam Forming 4 option is implemented." 5 6 DEFVAL { false } 7 ::= { dot11PhyHTEntry 19 } 8 9 10 11 dot11BeamFormingOptionEnabled OBJECT-TYPE 12 SYNTAX TruthValue 13 14 MAX-ACCESS read-only 15 16 STATUS current 17 DESCRIPTION 18 19 "This attribute, when TRUE, indicates that the Beam Forming 20 option is enabled." 21 22 DEFVAL { false } 23 ::= { dot11PhyHTEntry 20 } 24 25 26 27 dot11HighestSupportedDataRate OBJECT-TYPE 28 SYNTAX INTEGER (0..600) 29 30 MAX-ACCESS read-write 31 STATUS current 32 33 DESCRIPTION 34 35 "This attribute shall specify the Highest Data Rate in Mb/s at 36 which the station may receive data." 37 38 DEFVAL { 0 } 39 ::= { dot11PhyHTEntry 21 } 40 41 42 43 dot11TxMCSSetDefined OBJECT-TYPE 44 SYNTAX TruthValue 45 46 MAX-ACCESS read-write 47 STATUS current 48 49 DESCRIPTION 50 51 "This attribute, when TRUE, indicates that the Tx MCS set is 52 defined." 53 54 DEFVAL { false } 55 ::= { dot11PhyHTEntry 22 } 56 57 58 dot11TxRxMCSSetNotEqual OBJECT-TYPE 59 60 SYNTAX TruthValue 61 62 MAX-ACCESS read-only 63 STATUS current 64 65 DESCRIPTION

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 "This attribute, when TRUE, indicates that the supported Tx 2 3 and Rx MCS sets are not equal." 4 DEFVAL { false } 5 6 ::= { dot11PhyHTEntry 23 } 7 8 9 dot11TxMaximumNumberSpatialStreamsSupported OBJECT-TYPE 10 11 SYNTAX INTEGER (0..3) 12 MAX-ACCESS read-only 13 14 STATUS current 15 16 DESCRIPTION 17 "This attribute indicates the Tx maximum number of spatial 18 19 streams supported." 20 DEFVAL { 0 } 21 22 ::= { dot11PhyHTEntry 24 } 23 24 25 dot11TxUnequalModulationSupported OBJECT-TYPE 26 27 SYNTAX TruthValue 28 MAX-ACCESS read-only 29 30 STATUS current 31 DESCRIPTION 32 33 "This attribute, when TRUE, indicates that Tx unequal 34 modulation is supported." 35 36 DEFVAL { false } 37 38 ::= { dot11PhyHTEntry 25 } 39 40 41 -- ********************************************************************** 42 43 -- * End of dot11 PHY HT TABLE 44 -- ********************************************************************** 45 46 47 -- ********************************************************************** 48 49 -- * dot11 Supported MCS Tx TABLE 50 51 -- ********************************************************************** 52 dot11SupportedMCSTxTable OBJECT-TYPE 53 54 SYNTAX SEQUENCE OF Dot11SupportedMCSTxEntry 55 MAX-ACCESS not-accessible 56 57 STATUS current 58 59 DESCRIPTION 60 "The Transmit MCS supported by the PLCP and PMD, represented by a 61 62 count from 1 to 127, subject to limitations of each individual PHY." 63 ::= { dot11phy 16 } 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 dot11SupportedMCSTxEntry OBJECT-TYPE 2 3 SYNTAX Dot11SupportedDataRatesTxEntry 4 MAX-ACCESS not-accessible 5 6 STATUS current 7 8 DESCRIPTION 9 "An Entry (conceptual row) in the dot11SupportedMCSTx Table. 10 11 ifIndex - Each IEEE 802.11 interface is represented by an 12 13 ifEntry. Interface tables in this MIB module are indexed by 14 ifIndex." 15 INDEX { ifIndex, 16 17 dot11SupportedMCSTxIndex } 18 19 ::= { dot11SupportedMCSTxTable 1 } 20 21 22 Dot11SupportedMCSTxEntry ::= 23 24 SEQUENCE { 25 dot11SupportedMCSTxIndex Integer32, 26 27 dot11SupportedMCSTxValue Integer32 } 28 29 30 dot11SupportedMCSTxIndex OBJECT-TYPE 31 32 SYNTAX Integer32 (1..255) 33 MAX-ACCESS not-accessible 34 35 STATUS current 36 DESCRIPTION 37 38 "Index object that identifies which MCS to access. Range is 39 1..255." 40 41 ::= { dot11SupportedMCSTxEntry 1 } 42 43 44 dot11SupportedMCSTxValue OBJECT-TYPE 45 46 SYNTAX Integer32 (1..127) 47 MAX-ACCESS read-only 48 49 STATUS current 50 51 DESCRIPTION 52 "The Transmit MCS supported by the PLCP and PMD, represented 53 54 by a count from 1 to 127, subject to limitations of each individual PHY." 55 ::= { dot11SupportedDataRatesTxEntry 2 } 56 57 -- ********************************************************************** 58 59 -- * End of dot11 Supported MCS Tx TABLE 60 -- ********************************************************************** 61 62 63 -- ********************************************************************** 64 65 -- * dot11 Supported MCS Rx TABLE

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 -- ********************************************************************** 2 3 dot11SupportedMCSRxTable OBJECT-TYPE 4 SYNTAX SEQUENCE OF Dot11SupportedMCSRxEntry 5 6 MAX-ACCESS not-accessible 7 8 STATUS current 9 DESCRIPTION 10 11 "The receive MCS supported by the PLCP and PMD, represented by 12 a count from 1 to 127, subject to limitations of each individual PHY." 13 14 ::= { dot11phy 16 } 15 16 17 dot11SupportedMCSRxEntry OBJECT-TYPE 18 19 SYNTAX Dot11SupportedDataRatesRxEntry 20 MAX-ACCESS not-accessible 21 22 STATUS current 23 24 DESCRIPTION 25 "An Entry (conceptual row) in the dot11SupportedMCSRx Table. 26 27 ifIndex - Each IEEE 802.11 interface is represented by an ifEntry. Interface 28 tables in this MIB module are indexed by ifIndex." 29 30 INDEX { 31 ifIndex, 32 33 dot11SupportedMCSRxIndex } 34 ::= { dot11SupportedMCSRxTable 1 } 35 36 37 38 Dot11SupportedMCSRxEntry ::= 39 SEQUENCE { 40 41 dot11SupportedMCSRxIndex Integer32, 42 43 dot11SupportedMCSRxValue Integer32 } 44 45 46 dot11SupportedMCSRxIndex OBJECT-TYPE 47 SYNTAX Integer32 (1..255) 48 49 MAX-ACCESS not-accessible 50 51 STATUS current 52 DESCRIPTION 53 54 "Index object that identifies which MCS to access. Range is 55 1..255." 56 57 ::= { dot11SupportedMCSTxEntry 1 } 58 59 60 dot11SupportedMCSRxValue OBJECT-TYPE 61 62 SYNTAX Integer32 (1..127) 63 MAX-ACCESS read-only 64 65 STATUS current

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 DESCRIPTION 2 3 "The receive MCS supported by the PLCP and PMD, represented by 4 a count from 1 to 127, subject to limitations of each individual PHY." 5 6 ::= { dot11SupportedDataRatesTxEntry 2 } 7 8 9 -- ********************************************************************** 10 11 -- * End of dot11 Supported MCS Rx TABLE 12 -- ********************************************************************** 13 14 15 -- ********************************************************************** 16 17 -- * dot11 Transmit Beamforming Config TABLE 18 19 -- ********************************************************************** 20 dot11TransmitBeamformingConfigTable OBJECT-TYPE 21 22 SYNTAX SEQUENCE OF Dot11TransmitBeamformingConfigEntry 23 MAX-ACCESS not-accessible 24 25 STATUS current 26 27 DESCRIPTION 28 "Entry of attributes for dot11TransmitBeamformingConfigTable. 29 30 Implemented as a table indexed on ifIndex to allow for multiple instances on 31 an Agent." 32 33 ::= { dot11phy 18 } 34 35 36 dot11TransmitBeamformingConfigEntry OBJECT-TYPE 37 SYNTAX Dot11TransmitBeamformingConfigEntry 38 39 MAX-ACCESS not-accessible 40 STATUS current 41 42 DESCRIPTION 43 44 "An entry in the dot11TransmitBeamformingConfig Table. 45 46 47 ifIndex - Each 802.11 interface is represented by an ifEntry. 48 Interface tables in this MIB module are indexed by ifIndex." 49 50 INDEX {ifIndex} 51 ::= { dot11TransmitBeamformingConfigTable 1 } 52 53 54 55 Dot11TransmitBeamformingConfigEntry ::= SEQUENCE { 56 dot11ReceiveStaggerSoundingOptionImplemented TruthValue, 57 58 dot11TransmitStaggerSoundingOptionImplemented TruthValue, 59 dot11ReceiveNDPOptionImplemented TruthValue, 60 61 dot11TransmitNDPOptionImplemented TruthValue, 62 dot11ImplicitTransmitBeamformingOptionImplemented TruthValue, 63 dot11CalibrationOptionImplemented INTEGER, 64 65 dot11ExplicitCSITransmitBeamformingOptionImplemented TruthValue,

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 dot11ExplicitNonCompressedBeamformingMatrixOptionImplemented 2 3 TruthValue, 4 dot11ExplicitTransmitBeamformingCSIFeedbackOptionImplemented 5 6 INTEGER, 7 dot11ExplicitNonCompressedBeamformingFeedbackOptionImplemented 8 INTEGER, 9 10 dot11ExplicitCompressedBeamformingFeedbackOptionImplemented 11 INTEGER, 12 13 dot11NumberBeamFormingCSISupportAntenna INTEGER, 14 dot11NumberNonCompressedBeamformingMatrixSupportAntenna 15 16 INTEGER, 17 dot11NumberCompressedBeamformingMatrixSupportAntenna INTEGER 18 19 } 20 21 22 dot11ReceiveStaggerSoundingOptionImplemented OBJECT-TYPE 23 24 SYNTAX TruthValue 25 MAX-ACCESS read-only 26 27 STATUS current 28 29 DESCRIPTION 30 "This attribute, when TRUE, indicates that the STA 31 32 implementation supports the receiving of staggered sounding frames." 33 DEFVAL { false } 34 35 ::= { dot11TransmitBeamformingConfigEntry 1 } 36 37 38 dot11TransmitStaggerSoundingOptionImplemented OBJECT-TYPE 39 40 SYNTAX TruthValue 41 MAX-ACCESS read-only 42 43 STATUS current 44 45 DESCRIPTION 46 "This attribute, when TRUE, indicates that the STA 47 48 implementation supports the transmission of staggered sounding frames." 49 DEFVAL { false } 50 51 ::= { dot11TransmitBeamformingConfigEntry 2 } 52 53 54 dot11ReceiveNDPOptionImplemented OBJECT-TYPE 55 56 SYNTAX TruthValue 57 MAX-ACCESS read-only 58 59 STATUS current 60 DESCRIPTION 61 62 "This attribute, when TRUE, indicates that the STA 63 implementation is capable of receiving NDP as sounding frames." 64 65 DEFVAL { false }

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 ::= { dot11TransmitBeamformingConfigEntry 3 } 2 3 4 dot11TransmitNDPOptionImplemented OBJECT-TYPE 5 6 SYNTAX TruthValue 7 8 MAX-ACCESS read-only 9 STATUS current 10 11 DESCRIPTION 12 "This attribute, when TRUE, indicates that the STA 13 14 implementation is capable of transmitting NDP as sounding frames." 15 DEFVAL { false } 16 17 ::= { dot11TransmitBeamformingConfigEntry 4 } 18 19 20 dot11ImplicitTransmitBeamformingOptionImplemented OBJECT-TYPE 21 22 SYNTAX TruthValue 23 MAX-ACCESS read-only 24 25 STATUS current 26 DESCRIPTION 27 28 "This attribute, when TRUE, indicates that STA implementation 29 is capable of applying implicit transmit beamforming." 30 31 DEFVAL { false } 32 33 ::= { dot11TransmitBeamformingConfigEntry 5 } 34 35 36 dot11CalibrationOptionImplemented OBJECT-TYPE 37 SYNTAX INTEGER { inCapable (0), unableToInitiate (1), 38 39 ableToInitiate (2), fullyCapable (3) } 40 MAX-ACCESS read-only 41 42 STATUS current 43 DESCRIPTION 44 45 "This attribute indicates the level of calibration supported 46 by the STA implementation." 47 48 DEFVAL { inCapable } 49 50 ::= { dot11TransmitBeamformingConfigEntry 6 } 51 52 53 dot11ExplicitCSITransmitBeamformingOptionImplemented OBJECT-TYPE 54 SYNTAX TruthValue 55 56 MAX-ACCESS read-only 57 STATUS current 58 59 DESCRIPTION 60 61 "This attribute, when TRUE, indicates that STA implementation 62 is capable of applying transmit beamforming using CSI explicit feedback in 63 its transmission." 64 65 DEFVAL { false }

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 ::= { dot11TransmitBeamformingConfigEntry 7 } 2 3 4 dot11ExplicitNonCompressedBeamformingMatrixOptionImplemented OBJECT-TYPE 5 6 SYNTAX TruthValue 7 8 MAX-ACCESS read-only 9 STATUS current 10 11 DESCRIPTION 12 13 "This attribute, when TRUE, indicates that STA implementation 14 is capable of applying transmit beamforming using non-compressed beamforming 15 matrix explicit feedback in its transmission." 16 17 DEFVAL { false } 18 ::= { dot11TransmitBeamformingConfigEntry 8 } 19 20 21 22 23 dot11ExplicitTransmitBeamformingCSIFeedbackOptionImplemented OBJECT-TYPE 24 25 SYNTAX INTEGER { inCapable (0), delayed (1), immediate (2), 26 unsolicitedImmediate (3), aggregated (4), delayedAggregated (5), 27 28 immediateAggregated(6), unsolicitedImmediateAggregated (7) } 29 MAX-ACCESS read-only 30 31 STATUS current 32 33 DESCRIPTION 34 "This attribute indicates the level of CSI explicit feedback 35 36 returned by the STA implementation." 37 DEFVAL { inCapable } 38 39 ::= { dot11TransmitBeamformingConfigEntry 9 } 40 41 42 dot11ExplicitNonCompressedBeamformingFeedbackOptionImplemented OBJECT-TYPE 43 44 SYNTAX INTEGER { inCapable (0), delayed (1), immediate (2), 45 unsolicitedImmediate (3), aggregated (4), delayedAggregated (5), 46 immediateAggregated(6), unsolicitedImmediateAggregated (7) } 47 48 MAX-ACCESS read-only 49 50 STATUS current 51 DESCRIPTION 52 53 "This attribute indicates the level of non-compressed 54 beamforming matrix explicit feedback returned by the STA implementation." 55 56 DEFVAL { inCapable } 57 ::= { dot11TransmitBeamformingConfigEntry 10 } 58 59 60 61 dot11ExplicitCompressedBeamformingFeedbackOptionImplemented OBJECT-TYPE 62 SYNTAX INTEGER { inCapable (0), delayed (1), immediate (2), 63 64 unsolicitedImmediate (3), aggregated (4), delayedAggregated (5), 65 immediateAggregated(6), unsolicitedImmediateAggregated (7) }

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 MAX-ACCESS read-only 2 3 STATUS current 4 DESCRIPTION 5 6 "This attribute indicates the level of non-compressed 7 beamforming matrix explicit feedback returned by the STA implementation." 8 9 DEFVAL { inCapable } 10 11 ::= { dot11TransmitBeamformingConfigEntry 11 } 12 13 14 dot11NumberBeamFormingCSISupportAntenna OBJECT-TYPE 15 SYNTAX INTEGER (1..4) 16 17 MAX-ACCESS read-only 18 19 STATUS current 20 DESCRIPTION 21 22 "This attribute indicates the maximum number of beamform 23 antennas the beamformee can support when CSI feedback is required." 24 25 ::= { dot11TransmitBeamformingConfigEntry 12 } 26 27 28 dot11NumberNonCompressedBeamformingMatrixSupportAntenna OBJECT-TYPE 29 30 SYNTAX INTEGER (1..4) 31 MAX-ACCESS read-only 32 33 STATUS current 34 DESCRIPTION 35 36 "This attribute indicates the maximum number of beamform 37 antennas the beamformee can support when non-compressed beamforming matrix 38 39 feedback is required." 40 ::= { dot11TransmitBeamformingConfigEntry 13 } 41 42 43 44 dot11NumberCompressedBeamformingMatrixSupportAntenna OBJECT-TYPE 45 SYNTAX INTEGER (1..4) 46 47 MAX-ACCESS read-only 48 STATUS current 49 50 DESCRIPTION 51 52 "This attribute indicates the maximum number of beamform 53 antennas the beamformee can support when compressed beamforming matrix 54 feedback is required." 55 56 ::= { dot11TransmitBeamformingConfigEntry 14 } 57 58 -- ********************************************************************** 59 -- * End of dot11 Transmit Beamforming Config TABLE 60 61 -- ********************************************************************** 62 63 Change dot11Compliance as follows: 64 65 dot11Compliance MODULE-COMPLIANCE

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 STATUS current 2 3 DESCRIPTION 4 "The compliance statement for SNMPv2 entities that implement 5 6 the IEEE 802.11 MIB." 7 MODULE -- this module 8 9 MANDATORY-GROUPS { 10 11 dot11SMTbase910, 12 dot11MACbase23, dot11CountersGroup23, 13 14 dot11SmtAuthenticationAlgorithms, 15 dot11ResourceTypeID, dot11PhyOperationComplianceGroup } 16 17 Insert at the end of the compliance statements after dot11PhyERPComplianceGroup the following 18 19 component of the compliance statement: 20 21 GROUP dot11PhyHTComplianceGroup 22 DESCRIPTION 23 24 "Implementation of this group is required when object 25 dot11PHYType has the value of ht. This group is mutually exclusive with the 26 27 groups dot11PhyIRComplianceGroup and dot11PhyFHSSComplianceGroup" 28 29 Change the status of dot11PHYAntennaComplianceGroup to deprecated as follows: 30 31 dot11PhyAntennaComplianceGroup OBJECT-GROUP 32 OBJECTS 33 34 { dot11CurrentTxAntenna, dot11DiversitySupport, 35 dot11CurrentRxAntenna } 36 37 STATUS currentdeprecated 38 39 DESCRIPTION 40 "Attributes for Data Rates for IEEE 802.11." 41 42 ::= { dot11Groups 8 } 43 44 45 Change the status of dot11MACbase2 as deprecated as follows: 46 47 48 dot11MACbase2 OBJECT-GROUP 49 OBJECTS { dot11MACAddress, dot11Address, 50 51 dot11GroupAddressesStatus, 52 dot11RTSThreshold, dot11ShortRetryLimit, 53 54 dot11LongRetryLimit, dot11FragmentationThreshold, 55 dot11MaxTransmitMSDULifetime, 56 57 dot11MaxReceiveLifetime, dot11ManufacturerID, 58 59 dot11ProductID, dot11CAPLimit, dot11HCCWmin, 60 dot11HCCWmax, dot11HCCAIFSN, 61 62 dot11ADDBAResponseTimeout, dot11ADDTSResponseTimeout, 63 dot11ChannelUtilizationBeaconInterval, dot11ScheduleTimeout, 64 65 dot11DLSResponseTimeout, dot11QAPMissingAckRetryLimit,

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 dot11EDCAAveragingPeriod } 2 3 STATUS currentdeprecated 4 DESCRIPTION 5 6 "The MAC object class provides the necessary support for the 7 access control, generation, and verification of frame check sequences 8 9 (FCSs), and proper delivery of valid data to upper layers." 10 ::= { dot11Groups 31 } 11 12 13 14 Change the status of dot11CountersGroup2 to deprecated as follows: 15 16 dot11CountersGroup2 OBJECT-GROUP 17 18 OBJECTS { dot11TransmittedFragmentCount, 19 dot11MulticastTransmittedFrameCount, 20 21 dot11FailedCount, dot11ReceivedFragmentCount, 22 dot11MulticastReceivedFrameCount, 23 24 dot11FCSErrorCount, 25 26 dot11WEPUndecryptableCount, 27 dot11TransmittedFrameCount, 28 29 dot11QosDiscardedFragmentCount, 30 dot11AssociatedStationCount, 31 32 dot11QosCFPollsReceivedCount, 33 dot11QosCFPollsUnusedCount, 34 35 dot11QosCFPollsUnusableCount } 36 37 STATUS currentdeprecated 38 DESCRIPTION 39 40 "Attributes from the dot11CountersGroup that are not described 41 in the dot11MACStatistics group. These objects are mandatory." 42 43 ::= { dot11Groups 32 } 44 45 Change the status of dot11SMTbase9 to deprecated as follows (note the objects and description of this 46 group are represented by “...”): 47 48 dot11SMTbase9 OBJECT-GROUP 49 50 OBJECTS 51 { ... } 52 53 STATUS currentdeprecated 54 DESCRIPTION 55 56 "..." 57 58 ::= { dot11Groups 40} 59 60 Change the Optional Groups of the “Compliance Statements” as follows: 61 62 -- OPTIONAL-GROUPS { dot11SMTprivacy, dot11MACStatistics, 63 -- dot11PhyAntennaComplianceGroup, dot11PhyTxPowerComplianceGroup, 64 65 -- dot11PhyRegDomainsSupportGroup,

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 -- dot11PhyAntennasListGroup, dot11PhyRateGroup, 2 3 -- dot11SMTbase3, dot11MultiDomainCapabilityGroup, 4 -- dot11PhyFHSSComplianceGroup, dot11RSNAadditions, 5 6 -- dot11RegulatoryClassesGroup, dot11Qosadditions, 7 8 -- dot11RRMComplianceGroup, 9 -- dot11FTComplianceGroup, 10 11 -- dot11PhyAntennaComplianceGroup2, 12 -- dot11HTMACadditions, 13 14 -- dot11PhyMCSGroup, 15 -- dot11TransmitBeamformingGroup } 16 17 18 19 Change the status of dot11CountersGroup2 to deprecated as follows: 20 21 dot11CountersGroup2 OBJECT-GROUP 22 OBJECTS { dot11TransmittedFragmentCount, 23 24 dot11MulticastTransmittedFrameCount, 25 dot11FailedCount, dot11ReceivedFragmentCount, 26 27 dot11MulticastReceivedFrameCount, 28 dot11FCSErrorCount, 29 30 dot11WEPUndecryptableCount, 31 dot11TransmittedFrameCount, 32 33 dot11QosDiscardedFragmentCount, 34 dot11AssociatedStationCount, 35 36 dot11QosCFPollsReceivedCount, 37 dot11QosCFPollsUnusedCount, 38 dot11QosCFPollsUnusableCount } 39 40 STATUS currentdeprecated 41 DESCRIPTION 42 43 "Attributes from the dot11CountersGroup that are not described 44 in the dot11MACStatistics group. These objects are mandatory." 45 46 ::= { dot11Groups 32 } 47 48 49 50 Insert the following units of conformance: 51 52 dot11PhyAntennaComplianceGroup2 OBJECT-GROUP 53 OBJECTS { 54 55 dot11CurrentTxAntenna, 56 dot11DiversitySupport, 57 58 dot11CurrentRxAntenna, 59 dot11AntennaSelectionOptionImplemented, 60 61 dot11TransmitExplicitCSIFeedbackASOptionImplemented, 62 dot11TransmitIndicesFeedbackASOptionImplemented, 63 dot11ExplicitCSIFeedbackASOptionImplemented, 64 65 dot11TransmitIndicesComputationASOptionImplemented,

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 dot11ReceiveAntennaSelectionOptionImplemented } 2 3 STATUS current 4 DESCRIPTION 5 6 "Attributes for Data Rates for IEEE 802.11." 7 ::= { dot11Groups 44 } 8 9 10 11 dot11MACbase3 OBJECT-GROUP 12 OBJECTS { 13 14 dot11MACAddress, 15 dot11Address, 16 17 dot11GroupAddressesStatus, 18 19 dot11RTSThreshold, 20 dot11ShortRetryLimit, 21 22 dot11LongRetryLimit, 23 dot11FragmentationThreshold, 24 25 dot11MaxTransmitMSDULifetime, 26 27 dot11MaxReceiveLifetime, 28 dot11ManufacturerID, 29 30 dot11ProductID, 31 dot11CAPLimit, 32 33 dot11HCCWmin, 34 35 dot11HCCWmax, 36 dot11HCCAIFSN, 37 38 dot11ADDBAResponseTimeout, 39 dot11ADDTSResponseTimeout, 40 41 dot11ChannelUtilizationBeaconInterval, 42 43 dot11ScheduleTimeout, 44 dot11DLSResponseTimeout, 45 46 dot11QAPMissingAckRetryLimit, 47 dot11EDCAAveragingPeriod, 48 49 dot11HTProtection, 50 51 dot11RIFSMode, 52 dot11PSMPControlledAccess, 53 54 dot11ServiceIntervalGranularity, 55 dot11DualCTSProtection, 56 57 dot11LSIGTXOPFullProtectionEnabled, 58 59 dot11NonGFEntitiesPresent, dot11PCOActivated, 60 dot11PCOFortyMaxDuration, 61 62 dot11PCOTwentyMaxDuration, 63 dot11PCOFortyMinDuration, 64 65 dot11PCOTwentyMinDuration }

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 STATUS current 2 3 DESCRIPTION 4 "The MAC object class provides the necessary support for the 5 6 access control, generation, and verification of frame check sequences 7 (FCSs), and proper delivery of valid data to upper layers." 8 9 ::= { dot11Groups 45 } 10 11 12 dot11CountersGroup3 OBJECT-GROUP 13 14 OBJECTS { 15 dot11TransmittedFragmentCount, 16 17 dot11MulticastTransmittedFrameCount, 18 dot11FailedCount, 19 20 dot11ReceivedFragmentCount, 21 22 dot11MulticastReceivedFrameCount, 23 dot11FCSErrorCount, 24 25 dot11WEPUndecryptableCount, 26 dot11TransmittedFrameCount, 27 28 dot11QosDiscardedFragmentCount, 29 30 dot11AssociatedStationCount, 31 dot11QosCFPollsReceivedCount, 32 33 dot11QosCFPollsUnusedCount, 34 dot11QosCFPollsUnusableCount, 35 36 dot11QoSCFPollsLostCount, 37 38 dot11TransmittedAMSDUCount, 39 dot11FailedAMSDUCount, 40 41 dot11RetryAMSDUCount, 42 dot11MultipleRetryAMSDUCount, 43 44 dot11TransmittedOctetsInAMSDUCount, 45 46 dot11AMSDUAckFailureCount, 47 dot11ReceivedAMSDUCount, 48 49 dot11ReceivedOctetsInAMSDUCount, 50 51 dot11TransmittedAMPDUCount, 52 dot11TransmittedMPDUsInAMPDUCount, 53 54 dot11TransmittedOctetsInAMPDUCount, 55 dot11AMPDUReceivedCount, 56 57 dot11MPDUInReceivedAMPDUCount, 58 59 dot11ReceivedOctetsInAMPDUCount, 60 dot11AMPDUDelimiterCRCErrorCount, 61 62 dot11ImplicitBARFailureCount, 63 dot11ExplicitBARFailureCount, 64 65 dot11ChannelWidthSwitchCount,

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 dot11TwentyMHzFrameTransmittedCount, 2 3 dot11FortyMHzFrameTransmittedCount, 4 dot11TwentyMHzFrameReceivedCount, 5 6 dot11FortyMHzFrameReceivedCount, 7 8 dot11PSMPUTTGrantDuration, 9 dot11PSMPUTTUsedDuration, 10 11 dot11GrantedRDGUsedCount, 12 dot11GrantedRDGUnusedCount, 13 14 dot11TransmittedFramesInGrantedRDGCount, 15 16 dot11TransmittedOctetsInGrantedRDGCount, 17 dot11BeamformingCount, 18 19 dot11DualCTSSuccessCount, 20 dot11DualCTSFailureCount, 21 22 dot11STBCCTSSuccessCount, 23 24 dot11STBCCTSFailureCount, 25 dot11nonSTBCCTSSuccessCount, 26 27 dot11nonSTBCCTSFailureCount, 28 dot11RTSLSIGSuccessCount, 29 30 dot11RTSLSIGFailureCount } 31 32 STATUS current 33 DESCRIPTION 34 35 "Attributes from the dot11CountersGroup that are not described 36 in the dot11MACStatistics group. These objects are mandatory." 37 38 ::= { dot11Groups 46 } 39 40 41 dot11SMTbase10 OBJECT-GROUP 42 43 OBJECTS { 44 dot11MediumOccupancyLimit, 45 46 dot11CFPollable, 47 dot11CFPPeriod, 48 49 dot11CFPMaxDuration, 50 51 dot11AuthenticationResponseTimeOut, 52 dot11PrivacyOptionImplemented, 53 54 dot11PowerManagementMode, 55 dot11DesiredSSID, 56 57 dot11DesiredBSSType, 58 59 dot11OperationalRateSet, 60 dot11BeaconPeriod, 61 62 dot11DTIMPeriod, 63 dot11AssociationResponseTimeOut, 64 65 dot11DisassociateReason,

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 dot11DisassociateStation, 2 3 dot11DeauthenticateReason, 4 dot11DeauthenticateStation, 5 6 dot11AuthenticateFailStatus, 7 8 dot11AuthenticateFailStation, 9 dot11MultiDomainCapabilityImplemented, 10 11 dot11MultiDomainCapabilityEnabled, 12 dot11CountryString, 13 14 dot11RSNAOptionImplemented, 15 16 dot11RegulatoryClassesImplemented, 17 dot11RegulatoryClassesRequired, 18 19 dot11QosOptionImplemented, 20 dot11ImmediateBlockAckOptionImplemented, 21 22 dot11DelayedBlockAckOptionImplemented, 23 24 dot11DirectOptionImplemented, 25 dot11APSDOptionImplemented, 26 27 dot11QAckOptionImplemented, 28 dot11QBSSLoadOptionImplemented, 29 30 dot11QueueRequestOptionImplemented, 31 dot11TXOPRequestOptionImplemented, 32 33 dot11MoreDataAckOptionImplemented, 34 35 dot11AssociateinNQBSS, 36 dot11DLSAllowedInQBSS, 37 38 dot11DLSAllowed, 39 dot11AssociateStation, 40 41 dot11AssociateID, 42 43 dot11AssociateFailStation, 44 dot11AssociateFailStatus, 45 46 dot11ReassociateStation, 47 dot11ReassociateID, 48 49 dot11ReassociateFailStation, 50 51 dot11ReassociateFailStatus, 52 dot11RadioMeasurementCapable, 53 54 dot11RadioMeasurementEnabled, 55 dot11RadioMeasurementProbeDelay, 56 57 dot11MeasurementPilotReceptionEnabled, 58 59 dot11MeasurementPilotTransmissionEnabled, 60 dot11MeasurementPilotTransmissionInVirtualApSetEnabled, 61 62 dot11MeasurementPilotPeriod, 63 dot11LinkMeasurementEnabled, 64 65 dot11NeighborReportEnabled,

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 dot11ParallelMeasurementsEnabled, 2 3 dot11TriggeredMeasurementsEnabled, 4 dot11RepeatedMeasurementsEnabled, 5 6 dot11MeasurementPauseEnabled, 7 8 dot11QuietIntervalEnabled, 9 dot11FastBSSTransitionImplemented, 10 11 dot11LCIDSEImplemented, 12 13 dot11LCIDSERequired, 14 dot11DSERequired, 15 16 dot11ExtendedChannelSwitchEnabled, 17 dot11HighThroughputOptionImplemented, 18 19 dot11RSNAPBACRequired, 20 21 dot11PSMPOptionImplemented } 22 STATUS current 23 24 DESCRIPTION 25 "The SMTbase10 object class provides the necessary support at 26 27 the STA to manage the processes in the STA such that the STA may work 28 cooperatively as a part of an IEEE 802.11 network." 29 30 ::= { dot11Groups 47 } 31 32 33 dot11PhyMCSGroup OBJECT-GROUP 34 35 OBJECTS { 36 dot11SupportedMCSTxValue, 37 38 dot11SupportedMCSRxValue } 39 STATUS current 40 41 DESCRIPTION 42 43 "Attributes for Modulation and Coding Schemes (MCS) for IEEE 44 802.11 HT." 45 46 ::= { dot11Groups 48 } 47 48 49 dot11PhyHTComplianceGroup OBJECT-GROUP 50 OBJECTS { 51 52 dot11HighThroughputOptionImplemented, 53 54 dot11FortyMHzOperationImplemented, 55 dot11FortyMHzOperationEnabled, 56 57 dot11CurrentPrimaryChannel, 58 59 dot11CurrentSecondaryChannel, 60 dot11HTGreenfieldOptionImplemented, 61 62 dot11HTGreenfieldOptionEnabled, 63 dot11ShortGIOptionInTwentyImplemented, 64 65 dot11ShortGIOptionInTwentyEnabled,

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 dot11ShortGIOptionInFortyImplemented, 2 3 dot11ShortGIOptionInFortyEnabled, 4 dot11LDPCCodingOptionImplemented, 5 6 dot11LDPCCodingOptionEnabled, 7 8 dot11TxSTBCOptionImplemented, 9 dot11TxSTBCOptionEnabled, 10 11 dot11RxSTBCOptionImplemented, 12 dot11RxSTBCOptionEnabled, 13 14 dot11BeamFormingOptionImplemented, 15 16 dot11BeamFormingOptionImplemented } 17 STATUS current 18 19 DESCRIPTION 20 "Attributes that configure the HT for IEEE 802.11." 21 22 ::= { dot11Groups 49 } 23 24 25 dot11HTMACAdditions OBJECT-GROUP 26 27 OBJECTS { 28 dot11HTOperationalMCSSet, 29 30 dot11MIMOPowerSave, 31 dot11NDelayedBlockAckOptionImplemented, 32 33 dot11MaxAMSDULength, 34 35 dot11STBCControlFrameOptionImplemented, 36 dot11LsigTxopProtectionOptionImplemented, 37 38 dot11MaxRxAMPDUFactor, 39 dot11MinimumMPDUStartSpacing, 40 41 dot11PCOOptionImplemented, 42 43 dot11TransitionTime, 44 dot11MCSFeedbackOptionImplemented, 45 46 dot11HTControlFieldSupported, 47 dot11RDResponderOptionImplemented } 48 49 STATUS current 50 51 DESCRIPTION 52 "Attributes that configure the HT for IEEE 802.11." 53 54 ::= { dot11Groups 50 } 55 56 57 dot11TransmitBeamformingGroup OBJECT-GROUP 58 59 OBJECTS { 60 dot11ReceiveStaggerSoundingOptionImplemented, 61 62 dot11TransmitStaggerSoundingOptionImplemented, 63 dot11ReceiveNDPOptionImplemented, 64 65 dot11TransmitNDPOptionImplemented,

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 dot11ImplicitTransmitBeamformingOptionImplemented, 2 3 dot11CalibrationOptionImplemented, 4 dot11ExplicitCSITransmitBeamformingOptionImplemented, 5 6 dot11ExplicitNonCompressedBeamformingMatrixOptionImplemented, 7 8 dot11ExplicitTransmitBeamformingCSIFeedbackOptionImplemented, 9 dot11ExplicitNonCompressedBeamformingFeedbackOptionImplemented, 10 11 dot11ExplicitCompressedBeamformingFeedbackOptionImplemented, 12 dot11NumberBeamFormingCSISupportAntenna, 13 14 dot11NumberNonCompressedBeamformingMatrixSupportAntenna, 15 dot11NumberCompressedBeamformingMatrixSupportAntenna 16 17 } 18 19 STATUS current 20 DESCRIPTION 21 22 "Attributes that configure the Beamforming for IEEE 802.11 23 HT." 24 25 ::= { dot11Groups 51 } 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Change the heading of Clause G as follows: 2 3 4 5 Annex G(informative) An example Examples of encoding a frame 6 7 for the OFDM PHYs 8 9 EDITORIAL NOTE—This amendment adds two new examples to Annex G, requiring significant 10 11 renumbering of the existing headings. It is not possible to show the changes to the numbering of the 12 subclause headings in place (i.e., while they are also acting as headings for this document) without 13 creating infelicities in the table of contents and PDF bookmarks. So the changes are shown in two passes. 14 Firstly the changes to the numbering of the existing headings (where the headings don’t themselves 15 appear in the table of contents or bookmarks), then any changes to the re-numbered headings are shown 16 17 in place using the revised numbering. 18 19 Change the subclause headings within Clause G as follows (this inserts a new G.1 heading and demotes 20 the existing headings to be under that heading): 21 22 G.1 Example 1 - BCC encoding 23 24 G.1.1 Introduction 25 G.1.2 The message 26 27 G.1.3 Generation of the preamble 28 29 G.1.3.1 Generation of the short sequences 30 G.1.3.2 Generation of the long sequence 31 32 G.1.4 Generation of the SIGNAL fields 33 G.1.4.1 SIGNAL field bit assignment 34 35 G.1.4.2 Coding the SIGNAL field bits 36 37 G.1.4.3 Interleaving the SIGNAL field bits 38 G.1.4.4 SIGNAL field frequency domain 39 40 G.1.4.5 SIGNAL field time domain 41 G.1.5 Generating the DATA bits 42 43 G.1.5.1 Delineating, SERVICE field prepending, and zero padding 44 G.1.5.2 Scrambling 45 46 G.1.6 Generating the first DATA symbol 47 48 G.1.6.1 Coding the DATA bits 49 G.1.6.2 Interleaving the DATA bits 50 51 G.1.6.3 Mapping into symbols 52 G.1.7 Generating the additional DATA symbols 53 54 G.1.8 The entire packet 55 56 EDITORIAL NOTE—Subsequent editing instructions assume that the renumbering indicated above has 57 58 already been performed. 59 60 61 62 G.1 Example 1 - BCC encoding 63 64 65 G.1.1 Introduction

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Add the following new paragraph at the end of G.1.1: 2 3 In each Annex G Table which has "Binary Val" columns, the bit positions of the binary values are specified 4 5 in the header of the Table. 6 7 Change G.1.2 as follows: 8 9 10 G.1.2 The message for the BCC example 11 12 The message being encoded consists of the first 72 characters (shown in bold font) of the well-known "Ode 13 14 to Joy" by F. Schiller: 15 16 Change the first 72 characters of the text quoted from G.2 to a bold font as follows: 17 18 Joy, bright spark of divinity, 19 Daughter of Elysium, 20 21 Fire-insired we tread 22 Thy sanctuary. 23 Thy magic power re-unites 24 All that custom has divided, 25 All men become brothers 26 27 Under the sway of thy gentle wings. 28 29 EDITORIAL NOTE—The text in the baseline Annex G contains a typographical error “Fire-insired” 30 rather than “Fire-inspired”. This amendment corrects only the technical errors in the baseline Annex G 31 in order to minimize changes. This explains why the typographical error is not corrected above, and why 32 the uncorrected text is re-used in the new examples. 33 34 35 The message is converted to ASCII; then it is prepended with an appropriate MAC header and a CRC32 is 36 added. The resulting 100 octets PSDU is shown in Table G.1. 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 EDITORIAL NOTE—There are four changes: (1) The header for the left column has changed; (2) seven 2 entries in the left column have been corrected; (3) the last 4 entries of the bottom row have the corrected 3 CRC32 value; and (4) the caption indicates the example is specific to BCC. 4 5 6 Replace Table G.1 with the following: 7 8 9 Table G.1—The message for the BCC example 10 11 12 Octet ## Val Val Val Val Val 13 14 1...5 0x04 0x02 0x00 0x2E 0x00 15 16 6...10 0x60 0x08 0xCD 0x37 0xA6 17 18 11...15 0x00 0x20 0xD6 0x01 0x3C 19 16...20 0xF1 0x00 0x60 0x08 0xAD 20 21 21...25 0x3B 0xAF 0x00 0x00 0x4A 22 23 26...30 0x6F 0x79 0x2C 0x20 0x62 24 25 31...35 0x72 0x69 0x67 0x68 0x74 26 27 36...40 0x20 0x73 0x70 0x61 0x72 28 41...45 0x6B 0x20 0x6F 0x66 0x20 29 30 46...50 0x64 0x69 0x76 0x69 0x6E 31 32 51...55 0x69 0x74 0x79 0x2C 0x0A 33 34 56...60 0x44 0x61 0x75 0x67 0x68 35 36 61...65 0x74 0x65 0x72 0x20 0x6F 37 66...70 0x66 0x20 0x45 0x6C 0x79 38 39 71...75 0x73 0x69 0x75 0x6D 0x2C 40 41 76...80 0x0A 0x46 0x69 0x72 0x65 42 43 81...85 0x2D 0x69 0x6E 0x73 0x69 44 45 86...90 0x72 0x65 0x64 0x20 0x77 46 47 91...95 0x65 0x20 0x74 0x72 0x65 48 96...100 0x61 0x67 0x33 0x21 0xB6 49 50 51 52 Change the heading of G.1.5 as follows: 53 54 55 G.1.5 Generating the DATA bits for the BCC example 56 57 58 G.1.5.1 Delineating, SERVICE field prepending, and zero padding 59 60 Change G.1.5.1 as follows: 61 62 The transmitted message shown in Table G.1 contains 100 octets or, equivalently, 800 bits. The bits are 63 64 prepended by the 16 SERVICE field bits and are appended by 6 tail bits. The resulting 822 bits are appended 65 by zerosome number of bits with value zero to yield an integerral number of OFDM symbols. For the 36 Mb/

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 s mode, there are 144 data bits per OFDM symbol; the overall number of bits is ceiling (822/144) × 144 = 2 864. Hence, 864 – 822 = 42 zero bits are appended. 3 4 5 The data bits are shown in Table G.13 and Table G.14. For clarity, only the first and last 144 bits are shown. 6 The DATA bits are shown in Table G.13. 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 EDITORIAL NOTE—The replacement table G.13 includes all data bits, so it replaces both G.13 and 2 G.14. The replacement table includes the corrected CRC value. 3 4 Replace Table G.13 with the following table and delete Table G.14: 5 6 7 8 Table G.13—The DATA bits before scrambling 9 10 Binary Val Binary Val Binary Val 11 Bit ## Hex Val Hex Val Hex Val 12 b7 b0 b15 b8 b23 b16 13 14 000-023 00000000 00000000 00000100 0x00 0x00 0x04 15 16 024-047 00000010 00000000 00101110 0x02 0x00 0x2E 17 048-071 00000000 01100000 00001000 0x00 0x60 0x08 18 19 072-095 11001101 00110111 10100110 0xCD 0x37 0xA6 20 21 096-119 00000000 00100000 11010110 0x00 0x20 0xD6 22 23 120-143 00000001 00111100 11110001 0x01 0x3C 0xF1 24 25 144-167 00000000 01100000 00001000 0x00 0x60 0x08 26 168-191 10101101 00111011 10101111 0xAD 0x3B 0xAF 27 28 192-215 00000000 00000000 01001010 0x00 0x00 0x4A 29 30 216-239 01101111 01111001 00101100 0x6F 0x79 0x2C 31 32 240-263 00100000 01100010 01110010 0x20 0x62 0x72 33 34 264-287 01101001 01100111 01101000 0x69 0x67 0x68 35 288-311 01110100 00100000 01110011 0x74 0x20 0x73 36 37 312-335 01110000 01100001 01110010 0x70 0x61 0x72 38 39 336-359 01101011 00100000 01101111 0x6B 0x20 0x6F 40 41 360-383 01100110 00100000 01100100 0x66 0x20 0x64 42 43 384-407 01101001 01110110 01101001 0x69 0x76 0x69 44 408-431 01101110 01101001 01110100 0x6E 0x69 0x74 45 46 432-455 01111001 00101100 00001010 0x79 0x2C 0x0A 47 48 456-479 01000100 01100001 01110101 0x44 0x61 0x75 49 50 480-503 01100111 01101000 01110100 0x67 0x68 0x74 51 52 504-527 01100101 01110010 00100000 0x65 0x72 0x20 53 528-551 01101111 01100110 00100000 0x6F 0x66 0x20 54 55 552-575 01000101 01101100 01111001 0x45 0x6C 0x79 56 57 576-599 01110011 01101001 01110101 0x73 0x69 0x75 58 59 600-623 01101101 00101100 00001010 0x6D 0x2C 0x0A 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table G.13—The DATA bits before scrambling (continued) 2 3 4 Binary Val Binary Val Binary Val Bit ## Hex Val Hex Val Hex Val 5 b7 b0 b15 b8 b23 b16 6 7 624-647 01000110 01101001 01110010 0x46 0x69 0x72 8 9 648-671 01100101 00101101 01101001 0x65 0x2D 0x69 10 11 672-695 01101110 01110011 01101001 0x6E 0x73 0x69 12 696-719 01110010 01100101 01100100 0x72 0x65 0x64 13 14 720-743 00100000 01110111 01100101 0x20 0x77 0x65 15 16 744-767 00100000 01110100 01110010 0x20 0x74 0x72 17 18 768-791 01100101 01100001 01100111 0x65 0x61 0x67 19 20 792-815 00110011 00100001 10110110 0x33 0x21 0xB6 21 816-839 00000000 00000000 00000000 0x00 0x00 0x00 22 23 840-863 00000000 00000000 00000000 0x00 0x00 0x00 24 25 26 27 Change the heading of G.1.5.2 as follows: 28 29 G.1.5.2 Scrambling the BCC example 30 31 Change G.1.5.2 as follows: 32 33 34 The 864 bits are scrambled by the scrambler defined in 17.3.5.4. The initial state of the scrambler is the state 35 1011101. The generated scrambling sequence is given in Table G.15. 36 37 After scrambling, the 6 bits in location 816 (i.e., bit 817) to 821 (bit 822) are zeroed. The first and last 144 38 39 scrambled bits are show in Table G.16 and G.17, respectively. The scrambled DATA bits are shown in 40 Table G.16. 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 EDITORIAL NOTE—The replacement table G.16 includes all data bits, so it replaces both G.16 and 2 G.17. The replacement table includes the corrected CRC value. 3 4 Replace Table G.16 as follows and delete Table G.17: 5 6 7 8 Table G.16—The DATA bits after scrambling 9 10 Binary Val Binary Val Binary Val 11 Bit ## Hex Val Hex Val Hex Val 12 b0 b7 b8 b15 b16 b23 13 14 000-023 01101100 00011001 10001001 0x6C 0x19 0x89 15 16 024-047 10001111 01101000 00100001 0x8F 0x68 0x21 17 048-071 11110100 10100101 01100001 0xF4 0xA5 0x61 18 19 072-095 01001111 11010111 10101110 0x4F 0xD7 0xAE 20 21 096-119 00100100 00001100 11110011 0x24 0x0C 0xF3 22 23 120-143 00111010 11100100 10111100 0x3A 0xE4 0xBC 24 25 144-167 01010011 10011000 11000000 0x53 0x98 0xC0 26 168-191 00011110 00110101 10110011 0x1E 0x35 0xB3 27 28 192-215 11100011 11111000 00100101 0xE3 0xF8 0x25 29 30 216-239 01100000 11010110 00100101 0x60 0xD6 0x25 31 32 240-263 00110101 00110011 11111110 0x35 0x33 0xFE 33 34 264-287 11110000 01000001 00101011 0xF0 0x41 0x2B 35 288-311 10001111 01010011 00011100 0x8F 0x53 0x1C 36 37 312-335 10000011 01000001 10111110 0x83 0x41 0xBE 38 39 336-359 00111001 00101000 01100110 0x39 0x28 0x66 40 41 360-383 01000100 01100110 11001101 0x44 0x66 0xCD 42 43 384-407 11110110 10100011 11011000 0xF6 0xA3 0xD8 44 408-431 00001101 11010100 10000001 0x0D 0xD4 0x81 45 46 432-455 00111011 00101111 11011111 0x3B 0x2F 0xDF 47 48 456-479 11000011 01011000 11110111 0xC3 0x58 0xF7 49 50 480-503 11000110 01010010 11101011 0xC6 0x52 0xEB 51 52 504-527 01110000 10001111 10011110 0x70 0x8F 0x9E 53 528-551 01101010 10010000 10000001 0x6A 0x90 0x81 54 55 552-575 11111101 01111100 10101001 0xFD 0x7C 0xA9 56 57 576-599 11010001 01010101 00010010 0xD1 0x55 0x12 58 59 600-623 00000100 01110100 11011001 0x04 0x74 0xD9 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table G.16—The DATA bits after scrambling (continued) 2 3 4 Binary Val Binary Val Binary Val Bit ## Hex Val Hex Val Hex Val 5 b0 b7 b8 b15 b16 b23 6 7 624-647 11101001 00111011 11001101 0xE9 0x3B 0xCD 8 9 648-671 10010011 10001101 01111011 0x93 0x8D 0x7B 10 11 672-695 01111100 01110000 00000010 0x7C 0x70 0x02 12 696-719 00100000 10011001 10100001 0x20 0x99 0xA1 13 14 720-743 01111101 10001010 00100111 0x7D 0x8A 0x27 15 16 744-767 00010111 00111001 00010101 0x17 0x39 0x15 17 18 768-791 10100000 11101100 10010101 0xA0 0xEC 0x95 19 20 792-815 00010110 10010001 00010000 0x16 0x91 0x10 21 816-839 00000000 11011100 01111111 0x00 0xDC 0x7F 22 23 840-863 00001110 11110010 11001001 0x0E 0xF2 0xC9 24 25 26 27 Change the heading of G.1.6 as follows: 28 29 30 G.1.6 Generating the first DATA symbol for the BCC example 31 32 Change G.1.6.1 as follows: 33 34 35 G.1.6.1 Coding the DATA bits 36 37 The scrambled bits are coded with a rate 3/4 convolutional code. The first 144 scrambled bits of Table G.16 38 are mapped into the 192 bits of G.18. The DATA encoded bits are shown in Table G.18. 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Replace Table G.18 with the following: 2 3 4 Table G.18—The BCC encoded DATA bits 5 6 7 Binary Val Binary Val Binary Val Binary Val Bit ## Hex ValHex ValHex ValHex Val 8 b0 b7 b8 b15 b16 b23 b24 b31 9 10 0000-0031 00101011 00001000 10100001 11110000 0x2B 0x08 0xA1 0xF0 11 12 0032-0063 10011101 10110101 10011010 00011101 0x9D 0xB5 0x9A 0x1D 13 14 0064-0095 01001010 11111011 11101000 11000010 0x4A 0xFB 0xE8 0xC2 15 16 0096-0127 10001111 11000000 11001000 01110011 0x8F 0xC0 0xC8 0x73 17 18 0128-0159 11000000 01000011 11100000 00011001 0xC0 0x43 0xE0 0x19 19 0160-0191 11100000 11010011 11101011 10110010 0xE0 0xD3 0xEB 0xB2 20 21 0192-0223 10101111 10011000 11111101 01011001 0xAF 0x98 0xFD 0x59 22 23 0224-0255 00001111 10001011 01101001 01100110 0x0F 0x8B 0x69 0x66 24 25 0256-0287 00001100 10101010 11011001 00010000 0x0C 0xAA 0xD9 0x10 26 27 0288-0319 01010110 10001011 10100110 01000000 0x56 0x8B 0xA6 0x40 28 0320-0351 01100100 10110011 00100001 10011110 0x64 0xB3 0x21 0x9E 29 30 0352-0383 10001110 10010001 11000001 00000101 0x8E 0x91 0xC1 0x05 31 32 0384-0415 10110111 10110111 11000101 11011000 0xB7 0xB7 0xC5 0xD8 33 34 0416-0447 10000000 00101111 10100010 11011101 0x80 0x2F 0xA2 0xDD 35 36 0448-0479 01101111 00101011 10010111 01100001 0x6F 0x2B 0x97 0x61 37 0480-0511 11011001 11011101 00001101 00010010 0xD9 0xDD 0x0D 0x12 38 39 0512-0543 01110110 00100111 00000010 01001100 0x76 0x27 0x02 0x4C 40 41 0544-0575 10010010 10111100 00010010 01001011 0x92 0xBC 0x12 0x4B 42 43 0576-0607 01101010 11110111 01110000 00100011 0x6A 0xF7 0x70 0x23 44 45 0608-0639 00100111 10001110 00000001 10110100 0x27 0x8E 0x01 0xB4 46 0640-0671 11010110 11000011 01101010 01100000 0xD6 0xC3 0x6A 0x60 47 48 0672-0703 01001101 01001011 11001011 01010001 0x4D 0x4B 0xCB 0x51 49 50 0704-0735 10011100 10110000 10000000 11101011 0x9C 0xB0 0x80 0xEB 51 52 0736-0767 10001001 00110100 00010100 01000000 0x89 0x34 0x14 0x40 53 54 0768-0799 01101100 10011110 00101100 01010001 0x6C 0x9E 0x2C 0x51 55 0800-0831 01001011 01111100 01101001 00010001 0x4B 0x7C 0x69 0x11 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table G.18—The BCC encoded DATA bits (continued) 2 3 4 Binary Val Binary Val Binary Val Binary Val Bit ## Hex ValHex ValHex ValHex Val 5 b0 b7 b8 b15 b16 b23 b24 b31 6 7 0832-0863 00010101 10000110 11111101 10111110 0x15 0x86 0xFD 0xBE 8 9 0864-0895 01011110 11111001 10111110 00101000 0x5E 0xF9 0xBE 0x28 10 11 0896-0927 11101111 11001010 01010101 00000011 0xEF 0xCA 0x55 0x03 12 0928-0959 11111101 00100110 10010001 00111011 0xFD 0x26 0x91 0x3B 13 14 0960-0991 10010101 11101100 01011011 00100011 0x95 0xEC 0x5B 0x23 15 16 0992-1023 10011001 01011111 00101000 00111110 0x99 0x5F 0x28 0x3E 17 18 1024-1055 11010100 11101001 11110111 10111000 0xD4 0xE9 0xF7 0xB8 19 20 1056-1087 00010011 01110101 10001110 11110010 0x13 0x75 0x8E 0xF2 21 1088-1119 10100000 00011011 01101100 11101001 0xA0 0x1B 0x6C 0xE9 22 23 1120-1151 00000111 01011101 10110000 10111111 0x07 0x5D 0xB0 0xBF 24 25 26 27 Change G.1.8 as follows: 28 29 30 G.1.8 The entire packet for the BCC example 31 32 The packet in its entirety is shown in Table G.24 to Table G.32. The short sequences section, the long 33 34 sequences section, the SIGNAL field, and the DATA symbols are separated by double lines. These tables 35 illustrate the short training sequence section (Table G.24), the long training sequence section (Table G.25), 36 the SIGNAL field (Table G.26), and the six DATA symbols (Table G.27 to G.32). 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Replace Table G.24 with the following: 2 3 4 5 Table G.24—Time domain representation of the short training sequence 6 7 8 ## Real Imag ## Real Imag ## Real Imag ## Real Imag 9 10 0 0.023 0.023 1 -0.132 0.002 2 -0.013 -0.079 3 0.143 -0.013 11 4 0.092 0.000 5 0.143 -0.013 6 -0.013 -0.079 7 -0.132 0.002 12 13 8 0.046 0.046 9 0.002 -0.132 10 -0.079 -0.013 11 -0.013 0.143 14 15 12 0.000 0.092 13 -0.013 0.143 14 -0.079 -0.013 15 0.002 -0.132 16 17 16 0.046 0.046 17 -0.132 0.002 18 -0.013 -0.079 19 0.143 -0.013 18 19 20 0.092 0.000 21 0.143 -0.013 22 -0.013 -0.079 23 -0.132 0.002 20 24 0.046 0.046 25 0.002 -0.132 26 -0.079 -0.013 27 -0.013 0.143 21 22 28 0.000 0.092 29 -0.013 0.143 30 -0.079 -0.013 31 0.002 -0.132 23 24 32 0.046 0.046 33 -0.132 0.002 34 -0.013 -0.079 35 0.143 -0.013 25 26 36 0.092 0.000 37 0.143 -0.013 38 -0.013 -0.079 39 -0.132 0.002 27 28 40 0.046 0.046 41 0.002 -0.132 42 -0.079 -0.013 43 -0.013 0.143 29 44 0.000 0.092 45 -0.013 0.143 46 -0.079 -0.013 47 0.002 -0.132 30 31 48 0.046 0.046 49 -0.132 0.002 50 -0.013 -0.079 51 0.143 -0.013 32 33 52 0.092 0.000 53 0.143 -0.013 54 -0.013 -0.079 55 -0.132 0.002 34 35 56 0.046 0.046 57 0.002 -0.132 58 -0.079 -0.013 59 -0.013 0.143 36 37 60 0.000 0.092 61 -0.013 0.143 62 -0.079 -0.013 63 0.002 -0.132 38 64 0.046 0.046 65 -0.132 0.002 66 -0.013 -0.079 67 0.143 -0.013 39 40 68 0.092 0.000 69 0.143 -0.013 70 -0.013 -0.079 71 -0.132 0.002 41 42 72 0.046 0.046 73 0.002 -0.132 74 -0.079 -0.013 75 -0.013 0.143 43 44 76 0.000 0.092 77 -0.013 0.143 78 -0.079 -0.013 79 0.002 -0.132 45 46 80 0.046 0.046 81 -0.132 0.002 82 -0.013 -0.079 83 0.143 -0.013 47 84 0.092 0.000 85 0.143 -0.013 86 -0.013 -0.079 87 -0.132 0.002 48 49 88 0.046 0.046 89 0.002 -0.132 90 -0.079 -0.013 91 -0.013 0.143 50 51 92 0.000 0.092 93 -0.013 0.143 94 -0.079 -0.013 95 0.002 -0.132 52 53 96 0.046 0.046 97 -0.132 0.002 98 -0.013 -0.079 99 0.143 -0.013 54 55 100 0.092 0.000 101 0.143 -0.013 102 -0.013 -0.079 103 -0.132 0.002 56 104 0.046 0.046 105 0.002 -0.132 106 -0.079 -0.013 107 -0.013 0.143 57 58 108 0.000 0.092 109 -0.013 0.143 110 -0.079 -0.013 111 0.002 -0.132 59 60 112 0.046 0.046 113 -0.132 0.002 114 -0.013 -0.079 115 0.143 -0.013 61 62 116 0.092 0.000 117 0.143 -0.013 118 -0.013 -0.079 119 -0.132 0.002 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table G.24—Time domain representation of the short training sequence (continued) 2 3 4 ## Real Imag ## Real Imag ## Real Imag ## Real Imag 5 6 120 0.046 0.046 121 0.002 -0.132 122 -0.079 -0.013 123 -0.013 0.143 7 8 124 0.000 0.092 125 -0.013 0.143 126 -0.079 -0.013 127 0.002 -0.132 9 10 128 0.046 0.046 129 -0.132 0.002 130 -0.013 -0.079 131 0.143 -0.013 11 132 0.092 0.000 133 0.143 -0.013 134 -0.013 -0.079 135 -0.132 0.002 12 13 136 0.046 0.046 137 0.002 -0.132 138 -0.079 -0.013 139 -0.013 0.143 14 15 140 0.000 0.092 141 -0.013 0.143 142 -0.079 -0.013 143 0.002 -0.132 16 17 144 0.046 0.046 145 -0.132 0.002 146 -0.013 -0.079 147 0.143 -0.013 18 19 148 0.092 0.000 149 0.143 -0.013 150 -0.013 -0.079 151 -0.132 0.002 20 152 0.046 0.046 153 0.002 -0.132 154 -0.079 -0.013 155 -0.013 0.143 21 22 156 0.000 0.092 157 -0.013 0.143 158 -0.079 -0.013 159 0.002 -0.132 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Insert the following tables, Table G.25 to Table G.32, after Table G.24: 2 3 4 5 Table G.25—Time domain representation of the long training sequence 6 7 8 ## Real Imag ## Real Imag ## Real Imag ## Real Imag 9 10 160 -0.055 0.023 161 0.012 -0.098 162 0.092 -0.106 163 -0.092 -0.115 11 164 -0.003 -0.054 165 0.075 0.074 166 -0.127 0.021 167 -0.122 0.017 12 13 168 -0.035 0.151 169 -0.056 0.022 170 -0.060 -0.081 171 0.070 -0.014 14 15 172 0.082 -0.092 173 -0.131 -0.065 174 -0.057 -0.039 175 0.037 -0.098 16 17 176 0.062 0.062 177 0.119 0.004 178 -0.022 -0.161 179 0.059 0.015 18 19 180 0.024 0.059 181 -0.137 0.047 182 0.001 0.115 183 0.053 -0.004 20 184 0.098 0.026 185 -0.038 0.106 186 -0.115 0.055 187 0.060 0.088 21 22 188 0.021 -0.028 189 0.097 -0.083 190 0.040 0.111 191 -0.005 0.120 23 24 192 0.156 0.000 193 -0.005 -0.120 194 0.040 -0.111 195 0.097 0.083 25 26 196 0.021 0.028 197 0.060 -0.088 198 -0.115 -0.055 199 -0.038 -0.106 27 28 200 0.098 -0.026 201 0.053 0.004 202 0.001 -0.115 203 -0.137 -0.047 29 204 0.024 -0.059 205 0.059 -0.015 206 -0.022 0.161 207 0.119 -0.004 30 31 208 0.062 -0.062 209 0.037 0.098 210 -0.057 0.039 211 -0.131 0.065 32 33 212 0.082 0.092 213 0.070 0.014 214 -0.060 0.081 215 -0.056 -0.022 34 35 216 -0.035 -0.151 217 -0.122 -0.017 218 -0.127 -0.021 219 0.075 -0.074 36 37 220 -0.003 0.054 221 -0.092 0.115 222 0.092 0.106 223 0.012 0.098 38 224 -0.156 0.000 225 0.012 -0.098 226 0.092 -0.106 227 -0.092 -0.115 39 40 228 -0.003 -0.054 229 0.075 0.074 230 -0.127 0.021 231 -0.122 0.017 41 42 232 -0.035 0.151 233 -0.056 0.022 234 -0.060 -0.081 235 0.070 -0.014 43 44 236 0.082 -0.092 237 -0.131 -0.065 238 -0.057 -0.039 239 0.037 -0.098 45 46 240 0.062 0.062 241 0.119 0.004 242 -0.022 -0.161 243 0.059 0.015 47 244 0.024 0.059 245 -0.137 0.047 246 0.001 0.115 247 0.053 -0.004 48 49 248 0.098 0.026 249 -0.038 0.106 250 -0.115 0.055 251 0.060 0.088 50 51 252 0.021 -0.028 253 0.097 -0.083 254 0.040 0.111 255 -0.005 0.120 52 53 256 0.156 0.000 257 -0.005 -0.120 258 0.040 -0.111 259 0.097 0.083 54 55 260 0.021 0.028 261 0.060 -0.088 262 -0.115 -0.055 263 -0.038 -0.106 56 264 0.098 -0.026 265 0.053 0.004 266 0.001 -0.115 267 -0.137 -0.047 57 58 268 0.024 -0.059 269 0.059 -0.015 270 -0.022 0.161 271 0.119 -0.004 59 60 272 0.062 -0.062 273 0.037 0.098 274 -0.057 0.039 275 -0.131 0.065 61 62 276 0.082 0.092 277 0.070 0.014 278 -0.060 0.081 279 -0.056 -0.022 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table G.25—Time domain representation of the long training sequence (continued) 2 3 4 ## Real Imag ## Real Imag ## Real Imag ## Real Imag 5 6 280 -0.035 -0.151 281 -0.122 -0.017 282 -0.127 -0.021 283 0.075 -0.074 7 8 284 -0.003 0.054 285 -0.092 0.115 286 0.092 0.106 287 0.012 0.098 9 10 288 -0.156 0.000 289 0.012 -0.098 290 0.092 -0.106 291 -0.092 -0.115 11 292 -0.003 -0.054 293 0.075 0.074 294 -0.127 0.021 295 -0.122 0.017 12 13 296 -0.035 0.151 297 -0.056 0.022 298 -0.060 -0.081 299 0.070 -0.014 14 15 300 0.082 -0.092 301 -0.131 -0.065 302 -0.057 -0.039 303 0.037 -0.098 16 17 304 0.062 0.062 305 0.119 0.004 306 -0.022 -0.161 307 0.059 0.015 18 19 308 0.024 0.059 309 -0.137 0.047 310 0.001 0.115 311 0.053 -0.004 20 312 0.098 0.026 313 -0.038 0.106 314 -0.115 0.055 315 0.060 0.088 21 22 316 0.021 -0.028 317 0.097 -0.083 318 0.040 0.111 319 -0.005 0.120 23 24 25 26 Table G.26—Time domain representation of the SIGNAL field (1 symbol) 27 28 29 ## Real Imag ## Real Imag ## Real Imag ## Real Imag 30 31 320 0.109 0.000 321 0.033 -0.044 322 -0.002 -0.038 323 -0.081 0.084 32 33 324 0.007 -0.100 325 -0.001 -0.113 326 -0.021 -0.005 327 0.136 -0.105 34 328 0.098 -0.044 329 0.011 -0.002 330 -0.033 0.044 331 -0.060 0.124 35 36 332 0.010 0.097 333 0.000 -0.008 334 0.018 -0.083 335 -0.069 0.027 37 38 336 -0.219 0.000 337 -0.069 -0.027 338 0.018 0.083 339 0.000 0.008 39 40 340 0.010 -0.097 341 -0.060 -0.124 342 -0.033 -0.044 343 0.011 0.002 41 42 344 0.098 0.044 345 0.136 0.105 346 -0.021 0.005 347 -0.001 0.113 43 348 0.007 0.100 349 -0.081 -0.084 350 -0.002 0.038 351 0.033 0.044 44 45 352 0.062 0.000 353 0.057 0.052 354 0.016 0.174 355 0.035 0.116 46 47 356 -0.051 -0.202 357 0.011 0.036 358 0.089 0.209 359 -0.049 -0.008 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table G.26—Time domain representation of the SIGNAL field (1 symbol) (continued) 2 3 4 ## Real Imag ## Real Imag ## Real Imag ## Real Imag 5 6 360 -0.035 0.044 361 0.017 -0.059 362 0.053 -0.017 363 0.099 0.100 7 8 364 0.034 -0.148 365 -0.003 -0.094 366 -0.120 0.042 367 -0.136 -0.070 9 10 368 -0.031 0.000 369 -0.136 0.070 370 -0.120 -0.042 371 -0.003 0.094 11 372 0.034 0.148 373 0.099 -0.100 374 0.053 0.017 375 0.017 0.059 12 13 376 -0.035 -0.044 377 -0.049 0.008 378 0.089 -0.209 379 0.011 -0.036 14 15 380 -0.051 0.202 381 0.035 -0.116 382 0.016 -0.174 383 0.057 -0.052 16 17 384 0.062 0.000 385 0.033 -0.044 386 -0.002 -0.038 387 -0.081 0.084 18 19 388 0.007 -0.100 389 -0.001 -0.113 390 -0.021 -0.005 391 0.136 -0.105 20 392 0.098 -0.044 393 0.011 -0.002 394 -0.033 0.044 395 -0.060 0.124 21 22 396 0.010 0.097 397 0.000 -0.008 398 0.018 -0.083 399 -0.069 0.027 23 24 25 26 Table G.27—Time domain representation of the DATA field: symbol 1of 6 27 28 29 ## Real Imag ## Real Imag ## Real Imag ## Real Imag 30 31 400 -0.139 0.050 401 0.004 0.014 402 0.011 -0.100 403 -0.097 -0.020 32 33 404 0.062 0.081 405 0.124 0.139 406 0.104 -0.015 407 0.173 -0.140 34 408 -0.040 0.006 409 -0.133 0.009 410 -0.002 -0.043 411 -0.047 0.092 35 36 412 -0.109 0.082 413 -0.024 0.010 414 0.096 0.019 415 0.019 -0.023 37 38 416 -0.087 -0.049 417 0.002 0.058 418 -0.021 0.228 419 -0.103 0.023 39 40 420 -0.019 -0.175 421 0.018 0.132 422 -0.071 0.160 423 -0.153 -0.062 41 42 424 -0.107 0.028 425 0.055 0.140 426 0.070 0.103 427 -0.056 0.025 43 428 -0.043 0.002 429 0.016 -0.118 430 0.026 -0.071 431 0.033 0.177 44 45 432 0.020 -0.021 433 0.035 -0.088 434 -0.008 0.101 435 -0.035 -0.010 46 47 436 0.065 0.030 437 0.092 -0.034 438 0.032 -0.123 439 -0.018 0.092 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table G.27—Time domain representation of the DATA field: symbol 1of 6 (continued) 2 3 4 440 0.000 -0.006 441 -0.006 -0.056 442 -0.019 0.040 443 0.053 -0.131 5 6 444 0.022 -0.133 445 0.104 -0.032 446 0.163 -0.045 447 -0.105 -0.030 7 448 -0.110 -0.069 449 -0.008 -0.092 450 -0.049 -0.043 451 0.085 -0.017 8 9 452 0.090 0.063 453 0.015 0.153 454 0.049 0.094 455 0.011 0.034 10 11 456 -0.012 0.012 457 -0.015 -0.017 458 -0.061 0.031 459 -0.070 -0.040 12 13 460 0.011 -0.109 461 0.037 -0.060 462 -0.003 -0.178 463 -0.007 -0.128 14 15 464 -0.059 0.100 465 0.004 0.014 466 0.011 -0.100 467 -0.097 -0.020 16 468 0.062 0.081 469 0.124 0.139 470 0.104 -0.015 471 0.173 -0.140 17 18 472 -0.040 0.006 473 -0.133 0.009 474 -0.002 -0.043 475 -0.047 0.092 19 20 476 -0.109 0.082 477 -0.024 0.010 478 0.096 0.019 479 0.019 -0.023 21 22 23 24 Table G.28—Time domain representation of the DATA field: symbol 2 of 6 25 26 27 ## Real Imag ## Real Imag ## Real Imag ## Real Imag 28 29 480 -0.058 0.016 481 -0.096 -0.045 482 -0.110 0.003 483 -0.070 0.216 30 484 -0.040 0.059 485 0.010 -0.056 486 0.034 0.065 487 0.117 0.033 31 32 488 0.078 -0.133 489 -0.043 -0.146 490 0.158 -0.071 491 0.254 -0.021 33 34 492 0.068 0.117 493 -0.044 0.114 494 -0.035 0.041 495 0.085 0.070 35 36 496 0.120 0.010 497 0.057 0.055 498 0.063 0.188 499 0.091 0.149 37 38 500 -0.017 -0.039 501 -0.078 -0.075 502 0.049 0.079 503 -0.014 -0.007 39 504 0.030 -0.027 505 0.080 0.054 506 -0.186 -0.067 507 -0.039 -0.027 40 41 508 0.043 -0.072 509 -0.092 -0.089 510 0.029 0.105 511 -0.144 0.003 42 43 512 -0.069 -0.041 513 0.132 0.057 514 -0.126 0.070 515 -0.031 0.109 44 45 516 0.161 -0.009 517 0.056 -0.046 518 -0.004 0.028 519 -0.049 0.000 46 47 520 -0.078 -0.005 521 0.015 -0.087 522 0.149 -0.104 523 -0.021 -0.051 48 524 -0.154 -0.106 525 0.024 0.030 526 0.046 0.123 527 -0.004 -0.098 49 50 528 -0.061 -0.128 529 -0.024 -0.038 530 0.066 -0.048 531 -0.067 0.027 51 52 532 0.054 -0.050 533 0.171 -0.049 534 -0.108 0.132 535 -0.161 -0.019 53 54 536 -0.070 -0.072 537 -0.177 0.049 538 -0.172 -0.050 539 0.051 -0.075 55 56 540 0.122 -0.057 541 0.009 -0.044 542 -0.012 -0.021 543 0.004 0.009 57 544 -0.030 0.081 545 -0.096 -0.045 546 -0.110 0.003 547 -0.070 0.216 58 59 548 -0.040 0.059 549 0.010 -0.056 550 0.034 0.065 551 0.117 0.033 60 61 552 0.078 -0.133 553 -0.043 -0.146 554 0.158 -0.071 555 0.254 -0.021 62 63 556 0.068 0.117 557 -0.044 0.114 558 -0.035 0.041 559 0.085 0.070 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table G.29—Time domain representation of the DATA field: symbol 3 of 6 2 3 4 ## Real Imag ## Real Imag ## Real Imag ## Real Imag 5 6 560 0.001 0.011 561 -0.099 -0.048 562 0.054 -0.196 563 0.124 0.035 7 8 564 0.092 0.045 565 -0.037 -0.066 566 -0.021 -0.004 567 0.042 -0.065 9 10 568 0.061 0.048 569 0.046 0.004 570 -0.063 -0.045 571 -0.102 0.152 11 572 -0.039 -0.019 573 -0.005 -0.106 574 0.083 0.031 575 0.226 0.028 12 13 576 0.140 -0.010 577 -0.132 -0.033 578 -0.116 0.088 579 0.023 0.052 14 15 580 -0.171 -0.080 581 -0.246 -0.025 582 -0.062 -0.038 583 -0.055 -0.062 16 17 584 -0.004 -0.060 585 0.034 0.000 586 -0.030 0.021 587 0.075 -0.122 18 19 588 0.043 -0.080 589 -0.022 0.041 590 0.026 0.013 591 -0.031 -0.018 20 592 0.059 0.008 593 0.109 0.078 594 0.002 0.101 595 -0.016 0.054 21 22 596 -0.059 0.070 597 0.017 0.114 598 0.104 -0.034 599 -0.024 -0.059 23 24 600 -0.081 0.051 601 -0.040 -0.069 602 -0.069 0.058 603 -0.067 0.117 25 26 604 0.007 -0.131 605 0.009 0.028 606 0.075 0.117 607 0.118 0.030 27 28 608 -0.041 0.148 609 0.005 0.098 610 0.026 0.002 611 -0.116 0.045 29 612 -0.020 0.084 613 0.101 0.006 614 0.205 -0.064 615 0.073 -0.063 30 31 616 -0.174 -0.118 617 -0.024 0.026 618 -0.041 0.129 619 -0.042 -0.053 32 33 620 0.148 -0.126 621 -0.030 -0.049 622 -0.015 -0.021 623 0.089 -0.069 34 35 624 -0.119 0.011 625 -0.099 -0.048 626 0.054 -0.196 627 0.124 0.035 36 37 628 0.092 0.045 629 -0.037 -0.066 630 -0.021 -0.004 631 0.042 -0.065 38 632 0.061 0.048 633 0.046 0.004 634 -0.063 -0.045 635 -0.102 0.152 39 40 636 -0.039 -0.019 637 -0.005 -0.106 638 0.083 0.031 639 0.226 0.028 41 42 43 44 Table G.30—Time domain representation of the DATA field: symbol 4 of 6 45 46 47 ## Real Imag ## Real Imag ## Real Imag ## Real Imag 48 49 640 0.085 -0.065 641 0.034 -0.142 642 0.004 -0.012 643 0.126 -0.043 50 51 644 0.055 0.068 645 -0.020 0.077 646 0.008 -0.056 647 -0.034 0.046 52 648 -0.040 -0.134 649 -0.056 -0.131 650 0.014 0.097 651 0.045 -0.009 53 54 652 -0.113 -0.170 653 -0.065 -0.230 654 0.065 -0.011 655 0.011 0.048 55 56 656 -0.091 -0.059 657 -0.110 0.024 658 0.074 -0.034 659 0.124 0.022 57 58 660 -0.037 0.071 661 0.015 0.002 662 0.028 0.099 663 -0.062 0.068 59 60 664 0.064 0.016 665 0.078 0.156 666 0.009 0.219 667 0.147 0.024 61 668 0.106 0.030 669 -0.080 0.143 670 -0.049 -0.100 671 -0.036 -0.082 62 63 672 -0.089 0.021 673 -0.070 -0.029 674 -0.086 0.048 675 -0.066 -0.015 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table G.30—Time domain representation of the DATA field: symbol 4 of 6 (continued) 2 3 4 ## Real Imag ## Real Imag ## Real Imag ## Real Imag 5 6 676 -0.024 0.002 677 -0.030 -0.023 678 -0.032 0.020 679 -0.002 0.212 7 8 680 0.158 -0.024 681 0.141 -0.119 682 -0.146 0.058 683 -0.155 0.083 9 10 684 -0.002 -0.030 685 0.018 -0.129 686 0.012 -0.018 687 -0.008 -0.037 11 688 0.031 0.040 689 0.023 0.097 690 0.014 -0.039 691 0.050 0.019 12 13 692 -0.072 -0.141 693 -0.023 -0.051 694 0.024 0.099 695 -0.127 -0.116 14 15 696 0.094 0.102 697 0.183 0.098 698 -0.040 -0.020 699 0.065 0.077 16 17 700 0.088 -0.147 701 -0.039 -0.059 702 -0.057 0.124 703 -0.077 0.020 18 19 704 0.030 -0.120 705 0.034 -0.142 706 0.004 -0.012 707 0.126 -0.043 20 708 0.055 0.068 709 -0.020 0.077 710 0.008 -0.056 711 -0.034 0.046 21 22 712 -0.040 -0.134 713 -0.056 -0.131 714 0.014 0.097 715 0.045 -0.009 23 24 716 -0.113 -0.170 717 -0.065 -0.230 718 0.065 -0.011 719 0.011 0.048 25 26 720 -0.026 -0.021 721 -0.002 0.041 722 0.001 0.071 723 -0.037 -0.117 27 28 29 Table G.31—Time domain representation of the DATA field: symbol 5 of 6 30 31 32 ## Real Imag ## Real Imag ## Real Imag ## Real Imag 33 34 724 -0.106 -0.062 725 0.002 0.057 726 -0.008 -0.011 727 0.019 0.072 35 36 728 0.016 0.059 729 -0.065 -0.077 730 0.142 -0.062 731 0.087 0.025 37 38 732 -0.003 -0.103 733 0.107 -0.152 734 -0.054 0.036 735 -0.030 -0.003 39 40 736 0.058 -0.020 737 -0.028 0.007 738 -0.027 -0.099 739 0.049 -0.075 41 42 740 0.174 0.031 741 0.134 0.156 742 0.060 0.077 743 -0.010 -0.022 43 744 -0.084 0.040 745 -0.074 0.011 746 -0.163 0.054 747 -0.052 -0.008 44 45 748 0.076 -0.042 749 0.043 0.101 750 0.058 -0.018 751 0.003 -0.090 46 47 752 0.059 -0.018 753 0.023 -0.031 754 0.007 -0.017 755 0.066 -0.017 48 49 756 -0.135 -0.098 757 -0.056 -0.081 758 0.089 0.154 759 0.120 0.122 50 51 760 0.102 0.001 761 -0.141 0.102 762 0.006 -0.011 763 0.057 -0.039 52 764 -0.059 0.066 765 0.132 0.111 766 0.012 0.114 767 0.047 -0.106 53 54 768 0.160 -0.099 769 -0.076 0.084 770 -0.049 0.073 771 0.005 -0.086 55 56 772 -0.052 -0.108 773 -0.073 0.129 774 -0.129 -0.034 775 -0.153 -0.111 57 58 776 -0.193 0.098 777 -0.107 -0.068 778 0.004 -0.009 779 -0.039 0.024 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table G.31—Time domain representation of the DATA field: symbol 5 of 6 (continued) 2 3 4 ## Real Imag ## Real Imag ## Real Imag ## Real Imag 5 6 780 -0.054 -0.079 781 0.024 0.084 782 0.052 -0.002 783 0.028 -0.044 7 8 784 0.040 0.018 785 -0.002 0.041 786 0.001 0.071 787 -0.037 -0.117 9 10 788 -0.106 -0.062 789 0.002 0.057 790 -0.008 -0.011 791 0.019 0.072 11 792 0.016 0.059 793 -0.065 -0.077 794 0.142 -0.062 795 0.087 0.025 12 13 796 -0.003 -0.103 797 0.107 -0.152 798 -0.054 0.036 799 -0.030 -0.003 14 15 16 17 Table G.32—Time domain representation of the DATA field: symbol 6 of 6 18 19 20 ## Real Imag ## Real Imag ## Real Imag ## Real Imag 21 22 800 0.029 -0.026 801 -0.047 0.077 802 -0.007 -0.002 803 0.050 -0.021 23 24 804 0.046 -0.040 805 -0.061 -0.099 806 -0.121 0.008 807 0.014 0.050 25 808 0.145 0.034 809 0.001 -0.046 810 -0.058 -0.121 811 0.040 0.001 26 27 812 -0.029 0.041 813 0.002 -0.066 814 0.015 -0.054 815 0.010 -0.029 28 29 816 0.008 -0.119 817 -0.134 0.002 818 0.064 0.079 819 0.095 -0.102 30 31 820 -0.069 -0.014 821 0.156 0.037 822 0.047 -0.008 823 -0.076 0.025 32 33 824 0.117 -0.143 825 0.056 -0.042 826 0.002 0.075 827 -0.039 -0.058 34 828 -0.092 0.014 829 -0.041 0.047 830 -0.058 0.092 831 0.012 0.154 35 36 832 0.079 0.091 833 -0.067 0.017 834 -0.102 -0.032 835 0.039 0.084 37 38 836 -0.036 0.014 837 -0.001 -0.046 838 0.195 0.131 839 0.039 0.067 39 40 840 -0.007 0.045 841 0.051 0.008 842 -0.074 -0.109 843 -0.033 0.070 41 42 844 -0.028 0.176 845 -0.041 0.045 846 0.014 -0.084 847 0.054 -0.040 43 848 0.110 -0.020 849 0.014 -0.021 850 0.006 0.139 851 0.008 0.011 44 45 852 -0.060 -0.040 853 0.008 0.179 854 0.008 0.020 855 0.044 -0.114 46 47 856 0.021 -0.015 857 -0.008 -0.052 858 0.091 -0.109 859 -0.025 -0.040 48 49 860 -0.049 0.006 861 -0.043 -0.041 862 -0.178 -0.026 863 -0.073 -0.057 50 51 864 0.000 -0.031 865 -0.047 0.077 866 -0.007 -0.002 867 0.050 -0.021 52 868 0.046 -0.040 869 -0.061 -0.099 870 -0.121 0.008 871 0.014 0.050 53 54 872 0.145 0.034 873 0.001 -0.046 874 -0.058 -0.121 875 0.040 0.001 55 56 876 -0.029 0.041 877 0.002 -0.066 878 0.015 -0.054 879 0.010 -0.029 57 58 880 0.004 -0.059 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Insert the following subclauses G.2 to G.3.6 after G.1 and its subclauses : 2 3 4 5 G.2 Generating encoded DATA bits — LDPC example 1 6 7 LDPC example 1 is similar to the BCC Example. This example illustrates LDPC shortening, encoding, and 8 9 puncturing of a single codeword. 10 11 Input TXVECTOR parameters for LDPC example 1: 12 13 — FEC_CODING = LDPC_CODING = 1 (LDPC encoder; not BCC) 14 — CH_BANDWIDTH = HT_CBW20 = 0 (CH_BANDWIDTH = 0 => 20 MHz) 15 16 — MCS = 4 (MCS = 4; QAM 16; Coding rate = 3/4) 17 — Coding rate R = 3/4 18 19 — LENGTH = 100 octets (with 16-bit SERVICE field becomes 102 Octets = 20 816 bits to scramble and encode) 21 22 — STBC = 0 (STBC = 0 => OFF; m_STBC=1) 23 24 25 G.2.1 The message for LDPC example 1 26 27 The message being encoded consists of the first 72 characters (shown in bold below) of the well-known "Ode 28 to Joy" by F. Schiller: 29 30 31 Joy, bright spark of divinity, 32 Daughter of Elysium, 33 Fire-insired we tread 34 Thy sanctuary. 35 36 Thy magic power re-unites 37 All that custom has divided, 38 All men become brothers 39 Under the sway of thy gentle wings. 40 41 EDITORIAL NOTE—The text in the baseline Annex G contains a typographical error “Fire-insired” 42 43 rather than “Fire-inspired”. This amendment corrects only the technical errors in the baseline Annex G 44 in order to minimize changes. This explains why the uncorrected text is re-used in this example. 45 46 The message is converted to ASCII; then it is prepended with an appropriate MAC header and a CRC32 is 47 48 added. The resulting 100 octets PSDU is shown in Table G.33. 49 NOTE 1—The message for LDPC example 1 is identical to the message for the BCC example, meaning that the FCS 50 field (octets 97-100) has the same CRC 32 value. 51 NOTE 2—The DurationID field (i.e., octets 3 and 4) remains 0x02E = 46 µs. 52 53 54 G.2.2 Prepending the SERVICE field for LDPC example 1 55 56 57 The transmitted message shown in Table G.33 contains 100 octets, or equivalently, 800 bits. The bits are 58 prepended by the 16 SERVICE field bits (bits 0-15 in Table G.34), as defined in 20.3.11.1, but tail bits and 59 padding bits are not appended as in the BCC Example. The resulting 816 bits are shown in Table G.34. 60 61 62 G.2.3 Scrambling LDPC example 1 63 64 65 The 816 bits are scrambled by the scrambler defined in 17.3.5.4. The initial state of the scrambler is the state

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table G.33—The message for LDPC example 1 2 3 4 Octet ## Val Val Val Val Val 5 6 1...5 0x04 0x02 0x00 0x2E 0x00 7 8 6...10 0x60 0x08 0xCD 0x37 0xA6 9 10 11...15 0x00 0x20 0xD6 0x01 0x3C 11 16...20 0xF1 0x00 0x60 0x08 0xAD 12 13 21...25 0x3B 0xAF 0x00 0x00 0x4A 14 15 26...30 0x6F 0x79 0x2C 0x20 0x62 16 17 31...35 0x72 0x69 0x67 0x68 0x74 18 19 36...40 0x20 0x73 0x70 0x61 0x72 20 41...45 0x6B 0x20 0x6F 0x66 0x20 21 22 46...50 0x64 0x69 0x76 0x69 0x6E 23 24 51...55 0x69 0x74 0x79 0x2C 0x0A 25 26 56...60 0x44 0x61 0x75 0x67 0x68 27 28 61...65 0x74 0x65 0x72 0x20 0x6F 29 66...70 0x66 0x20 0x45 0x6C 0x79 30 31 71...75 0x73 0x69 0x75 0x6D 0x2C 32 33 76...80 0x0A 0x46 0x69 0x72 0x65 34 35 81...85 0x2D 0x69 0x6E 0x73 0x69 36 37 86...90 0x72 0x65 0x64 0x20 0x77 38 91...95 0x65 0x20 0x74 0x72 0x65 39 40 96...100 0x61 0x67 0x33 0x21 0xB6 41 42 43 44 1011101 binary (0x5D hexadecimal). The scrambled sequence is given in Table G.35. 45 46 NOTE—The scrambled entries for the correct CRC32 value are given in bits 784-815. 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table G.34—The DATA bits for LDPC example 1 before scrambling 2 3 4 Binary Val Binary Val Binary Val Bit ## Hex Val Hex Val Hex Val 5 b7 b0 b15 b8 b23 b16 6 7 000-023 00000000 00000000 00000100 0x00 0x00 0x04 8 9 024-047 00000010 00000000 00101110 0x02 0x00 0x2E 10 11 048-071 00000000 01100000 00001000 0x00 0x60 0x08 12 072-095 11001101 00110111 10100110 0xCD 0x37 0xA6 13 14 096-119 00000000 00100000 11010110 0x00 0x20 0xD6 15 16 120-143 00000001 00111100 11110001 0x01 0x3C 0xF1 17 18 144-167 00000000 01100000 00001000 0x00 0x60 0x08 19 20 168-191 10101101 00111011 10101111 0xAD 0x3B 0xAF 21 192-215 00000000 00000000 01001010 0x00 0x00 0x4A 22 23 216-239 01101111 01111001 00101100 0x6F 0x79 0x2C 24 25 240-263 00100000 01100010 01110010 0x20 0x62 0x72 26 27 264-287 01101001 01100111 01101000 0x69 0x67 0x68 28 29 288-311 01110100 00100000 01110011 0x74 0x20 0x73 30 312-335 01110000 01100001 01110010 0x70 0x61 0x72 31 32 336-359 01101011 00100000 01101111 0x6B 0x20 0x6F 33 34 360-383 01100110 00100000 01100100 0x66 0x20 0x64 35 36 384-407 01101001 01110110 01101001 0x69 0x76 0x69 37 38 408-431 01101110 01101001 01110100 0x6E 0x69 0x74 39 432-455 01111001 00101100 00001010 0x79 0x2C 0x0A 40 41 456-479 01000100 01100001 01110101 0x44 0x61 0x75 42 43 480-503 01100111 01101000 01110100 0x67 0x68 0x74 44 45 504-527 01100101 01110010 00100000 0x65 0x72 0x20 46 47 528-551 01101111 01100110 00100000 0x6F 0x66 0x20 48 552-575 01000101 01101100 01111001 0x45 0x6C 0x79 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table G.34—The DATA bits for LDPC example 1 before scrambling (continued) 2 3 4 Binary Val Binary Val Binary Val Bit ## Hex Val Hex Val Hex Val 5 b7 b0 b15 b8 b23 b16 6 7 576-599 01110011 01101001 01110101 0x73 0x69 0x75 8 9 600-623 01101101 00101100 00001010 0x6D 0x2C 0x0A 10 11 624-647 01000110 01101001 01110010 0x46 0x69 0x72 12 648-671 01100101 00101101 01101001 0x65 0x2D 0x69 13 14 672-695 01101110 01110011 01101001 0x6E 0x73 0x69 15 16 696-719 01110010 01100101 01100100 0x72 0x65 0x64 17 18 720-743 00100000 01110111 01100101 0x20 0x77 0x65 19 20 744-767 00100000 01110100 01110010 0x20 0x74 0x72 21 768-791 01100101 01100001 01100111 0x65 0x61 0x67 22 23 792-815 00110011 00100001 10110110 0x33 0x21 0xB6 24 25 26 27 28 29 30 Table G.35—The DATA bits for LDPC example 1 after scrambling 31 32 33 Binary Val Binary Val Binary Val Bit ## Hex Val Hex Val Hex Val 34 b0 b7 b8 b15 b16 b23 35 36 000-023 01101100 00011001 10001001 0x6C 0x19 0x89 37 38 024-047 10001111 01101000 00100001 0x8F 0x68 0x21 39 40 048-071 11110100 10100101 01100001 0xF4 0xA5 0x61 41 072-095 01001111 11010111 10101110 0x4F 0xD7 0xAE 42 43 096-119 00100100 00001100 11110011 0x24 0x0C 0xF3 44 45 120-143 00111010 11100100 10111100 0x3A 0xE4 0xBC 46 47 144-167 01010011 10011000 11000000 0x53 0x98 0xC0 48 49 168-191 00011110 00110101 10110011 0x1E 0x35 0xB3 50 192-215 11100011 11111000 00100101 0xE3 0xF8 0x25 51 52 216-239 01100000 11010110 00100101 0x60 0xD6 0x25 53 54 240-263 00110101 00110011 11111110 0x35 0x33 0xFE 55 56 264-287 11110000 01000001 00101011 0xF0 0x41 0x2B 57 58 288-311 10001111 01010011 00011100 0x8F 0x53 0x1C 59 312-335 10000011 01000001 10111110 0x83 0x41 0xBE 60 61 336-359 00111001 00101000 01100110 0x39 0x28 0x66 62 63 360-383 01000100 01100110 11001101 0x44 0x66 0xCD 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table G.35—The DATA bits for LDPC example 1 after scrambling (continued) 2 3 4 Binary Val Binary Val Binary Val Bit ## Hex Val Hex Val Hex Val 5 b0 b7 b8 b15 b16 b23 6 7 384-407 11110110 10100011 11011000 0xF6 0xA3 0xD8 8 9 408-431 00001101 11010100 10000001 0x0D 0xD4 0x81 10 11 432-455 00111011 00101111 11011111 0x3B 0x2F 0xDF 12 456-479 11000011 01011000 11110111 0xC3 0x58 0xF7 13 14 480-503 11000110 01010010 11101011 0xC6 0x52 0xEB 15 16 504-527 01110000 10001111 10011110 0x70 0x8F 0x9E 17 18 528-551 01101010 10010000 10000001 0x6A 0x90 0x81 19 20 552-575 11111101 01111100 10101001 0xFD 0x7C 0xA9 21 576-599 11010001 01010101 00010010 0xD1 0x55 0x12 22 23 600-623 00000100 01110100 11011001 0x04 0x74 0xD9 24 25 624-647 11101001 00111011 11001101 0xE9 0x3B 0xCD 26 27 648-671 10010011 10001101 01111011 0x93 0x8D 0x7B 28 29 672-695 01111100 01110000 00000010 0x7C 0x70 0x02 30 696-719 00100000 10011001 10100001 0x20 0x99 0xA1 31 32 720-743 01111101 10001010 00100111 0x7D 0x8A 0x27 33 34 744-767 00010111 00111001 00010101 0x17 0x39 0x15 35 36 768-791 10100000 11101100 10010101 0xA0 0xEC 0x95 37 38 792-815 00010110 10010001 00010000 0x16 0x91 0x10 39 40 41 G.2.4 Inserting the shortening bits for LDPC example 1 42 43 44 The equations of 20.3.11.6.5 are solved to calculate the following derived parameters for LDPC example 1 45 from the input TXVECTOR parameters: 46 47 —NCW = 1 (number of codewords) 48 49 —LLDPC = 1944 (size of codeword) 50 51 —NCBPS = 208 (number of coded bits per symbol) 52 53 —Navbits = 1248 (number of available bits) 54 55 —Nshrt = 642 (number of bits to be shortened) 56 57 —Npunc = 54 (number of bits to be punctured) 58 59 —NSYM = 6 (number of OFDM symbols) 60 61 —Nrep = 0 (number of bits to be repeated) 62 63 The results of applying shortening bits, as prescribed in paragraph (c) of 20.3.11.6.5 is given in Table G.36. 64 65 NOTE—Nshrt = 642 shortening bits have been inserted as zeros in bits 816-1457.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table G.36—The DATA bits for LDPC example 1 after insertion of shortening bits 2 3 4 Binary Val Binary Val Binary Val Bit ## Hex Val Hex Val Hex Val 5 b0 b7 b8 b15 b16 b23 6 7 0000-0023 01101100 00011001 10001001 0x6C 0x19 0x89 8 9 0024-0047 10001111 01101000 00100001 0x8F 0x68 0x21 10 11 0048-0071 11110100 10100101 01100001 0xF4 0xA5 0x61 12 0072-0095 01001111 11010111 10101110 0x4F 0xD7 0xAE 13 14 0096-0119 00100100 00001100 11110011 0x24 0x0C 0xF3 15 16 0120-0143 00111010 11100100 10111100 0x3A 0xE4 0xBC 17 18 0144-0167 01010011 10011000 11000000 0x53 0x98 0xC0 19 20 0168-0191 00011110 00110101 10110011 0x1E 0x35 0xB3 21 0192-0215 11100011 11111000 00100101 0xE3 0xF8 0x25 22 23 0216-0239 01100000 11010110 00100101 0x60 0xD6 0x25 24 25 0240-0263 00110101 00110011 11111110 0x35 0x33 0xFE 26 27 0264-0287 11110000 01000001 00101011 0xF0 0x41 0x2B 28 29 0288-0311 10001111 01010011 00011100 0x8F 0x53 0x1C 30 0312-0335 10000011 01000001 10111110 0x83 0x41 0xBE 31 32 0336-0359 00111001 00101000 01100110 0x39 0x28 0x66 33 34 0360-0383 01000100 01100110 11001101 0x44 0x66 0xCD 35 36 0384-0407 11110110 10100011 11011000 0xF6 0xA3 0xD8 37 38 0408-0431 00001101 11010100 10000001 0x0D 0xD4 0x81 39 0432-0455 00111011 00101111 11011111 0x3B 0x2F 0xDF 40 41 0456-0479 11000011 01011000 11110111 0xC3 0x58 0xF7 42 43 0480-0503 11000110 01010010 11101011 0xC6 0x52 0xEB 44 45 0504-0527 01110000 10001111 10011110 0x70 0x8F 0x9E 46 47 0528-0551 01101010 10010000 10000001 0x6A 0x90 0x81 48 0552-0575 11111101 01111100 10101001 0xFD 0x7C 0xA9 49 50 0576-0599 11010001 01010101 00010010 0xD1 0x55 0x12 51 52 0600-0623 00000100 01110100 11011001 0x04 0x74 0xD9 53 54 0624-0647 11101001 00111011 11001101 0xE9 0x3B 0xCD 55 56 0648-0671 10010011 10001101 01111011 0x93 0x8D 0x7B 57 0672-0695 01111100 01110000 00000010 0x7C 0x70 0x02 58 59 0696-0719 00100000 10011001 10100001 0x20 0x99 0xA1 60 61 0720-0743 01111101 10001010 00100111 0x7D 0x8A 0x27 62 63 0744-0767 00010111 00111001 00010101 0x17 0x39 0x15 64 65 0768-0791 10100000 11101100 10010101 0xA0 0xEC 0x95

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table G.36—The DATA bits for LDPC example 1 after insertion of shortening bits (contin- 2 3 4 Binary Val Binary Val Binary Val Bit ## Hex Val Hex Val Hex Val 5 b0 b7 b8 b15 b16 b23 6 7 0792-0815 00010110 10010001 00010000 0x16 0x91 0x10 8 9 0816-0839 00000000 00000000 00000000 0x00 0x00 0x00 10 11 0840-0863 00000000 00000000 00000000 0x00 0x00 0x00 12 0864-0887 00000000 00000000 00000000 0x00 0x00 0x00 13 14 0888-0911 00000000 00000000 00000000 0x00 0x00 0x00 15 16 0912-0935 00000000 00000000 00000000 0x00 0x00 0x00 17 18 0936-0959 00000000 00000000 00000000 0x00 0x00 0x00 19 20 0960-0983 00000000 00000000 00000000 0x00 0x00 0x00 21 0984-1007 00000000 00000000 00000000 0x00 0x00 0x00 22 23 1008-1031 00000000 00000000 00000000 0x00 0x00 0x00 24 25 1032-1055 00000000 00000000 00000000 0x00 0x00 0x00 26 27 1056-1079 00000000 00000000 00000000 0x00 0x00 0x00 28 29 1080-1103 00000000 00000000 00000000 0x00 0x00 0x00 30 1104-1127 00000000 00000000 00000000 0x00 0x00 0x00 31 32 1128-1151 00000000 00000000 00000000 0x00 0x00 0x00 33 34 1152-1175 00000000 00000000 00000000 0x00 0x00 0x00 35 36 1176-1199 00000000 00000000 00000000 0x00 0x00 0x00 37 38 1200-1223 00000000 00000000 00000000 0x00 0x00 0x00 39 1224-1247 00000000 00000000 00000000 0x00 0x00 0x00 40 41 1248-1271 00000000 00000000 00000000 0x00 0x00 0x00 42 43 1272-1295 00000000 00000000 00000000 0x00 0x00 0x00 44 45 1296-1319 00000000 00000000 00000000 0x00 0x00 0x00 46 47 1320-1343 00000000 00000000 00000000 0x00 0x00 0x00 48 1344-1367 00000000 00000000 00000000 0x00 0x00 0x00 49 50 1368-1391 00000000 00000000 00000000 0x00 0x00 0x00 51 52 1392-1415 00000000 00000000 00000000 0x00 0x00 0x00 53 54 1416-1439 00000000 00000000 00000000 0x00 0x00 0x00 55 56 1440-1457 00000000 00000000 00 ------0x00 0x00 0x0- 57 58 59 G.2.5 Encoding the data for LDPC example 1 60 61 62 The DATA with shortening bits are LDPC encoded as a single (NCW=1) codeword (LLDPC=944; R=3/4) as 63 prescribed by paragraph (c) of 20.3.11.6.5. The results are given in Table G.37. 64 65 NOTE—The LDPC encoder appends 486 bits, bits 1458-1943, after the shortening bits.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table G.37—The DATA bits for LDPC example 1 after LDPC encoding. 2 3 4 Binary Val Binary Val Binary Val Bit ## Hex Val Hex Val Hex Val 5 b0 b7 b8 b15 b16 b23 6 7 0000-0023 01101100 00011001 10001001 0x6C 0x19 0x89 8 9 0024-0047 10001111 01101000 00100001 0x8F 0x68 0x21 10 11 0048-0071 11110100 10100101 01100001 0xF4 0xA5 0x61 12 0072-0095 01001111 11010111 10101110 0x4F 0xD7 0xAE 13 14 0096-0119 00100100 00001100 11110011 0x24 0x0C 0xF3 15 16 0120-0143 00111010 11100100 10111100 0x3A 0xE4 0xBC 17 18 0144-0167 01010011 10011000 11000000 0x53 0x98 0xC0 19 20 0168-0191 00011110 00110101 10110011 0x1E 0x35 0xB3 21 0192-0215 11100011 11111000 00100101 0xE3 0xF8 0x25 22 23 0216-0239 01100000 11010110 00100101 0x60 0xD6 0x25 24 25 0240-0263 00110101 00110011 11111110 0x35 0x33 0xFE 26 27 0264-0287 11110000 01000001 00101011 0xF0 0x41 0x2B 28 29 0288-0311 10001111 01010011 00011100 0x8F 0x53 0x1C 30 0312-0335 10000011 01000001 10111110 0x83 0x41 0xBE 31 32 0336-0359 00111001 00101000 01100110 0x39 0x28 0x66 33 34 0360-0383 01000100 01100110 11001101 0x44 0x66 0xCD 35 36 0384-0407 11110110 10100011 11011000 0xF6 0xA3 0xD8 37 38 0408-0431 00001101 11010100 10000001 0x0D 0xD4 0x81 39 0432-0455 00111011 00101111 11011111 0x3B 0x2F 0xDF 40 41 0456-0479 11000011 01011000 11110111 0xC3 0x58 0xF7 42 43 0480-0503 11000110 01010010 11101011 0xC6 0x52 0xEB 44 45 0504-0527 01110000 10001111 10011110 0x70 0x8F 0x9E 46 47 0528-0551 01101010 10010000 10000001 0x6A 0x90 0x81 48 0552-0575 11111101 01111100 10101001 0xFD 0x7C 0xA9 49 50 0576-0599 11010001 01010101 00010010 0xD1 0x55 0x12 51 52 0600-0623 00000100 01110100 11011001 0x04 0x74 0xD9 53 54 0624-0647 11101001 00111011 11001101 0xE9 0x3B 0xCD 55 56 0648-0671 10010011 10001101 01111011 0x93 0x8D 0x7B 57 0672-0695 01111100 01110000 00000010 0x7C 0x70 0x02 58 59 0696-0719 00100000 10011001 10100001 0x20 0x99 0xA1 60 61 0720-0743 01111101 10001010 00100111 0x7D 0x8A 0x27 62 63 0744-0767 00010111 00111001 00010101 0x17 0x39 0x15 64 65 0768-0791 10100000 11101100 10010101 0xA0 0xEC 0x95

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table G.37—The DATA bits for LDPC example 1 after LDPC encoding. (continued) 2 3 4 Binary Val Binary Val Binary Val Bit ## Hex Val Hex Val Hex Val 5 b0 b7 b8 b15 b16 b23 6 7 0792-0815 00010110 10010001 00010000 0x16 0x91 0x10 8 9 0816-0839 00000000 00000000 00000000 0x00 0x00 0x00 10 11 0840-0863 00000000 00000000 00000000 0x00 0x00 0x00 12 0864-0887 00000000 00000000 00000000 0x00 0x00 0x00 13 14 0888-0911 00000000 00000000 00000000 0x00 0x00 0x00 15 16 0912-0935 00000000 00000000 00000000 0x00 0x00 0x00 17 18 0936-0959 00000000 00000000 00000000 0x00 0x00 0x00 19 20 0960-0983 00000000 00000000 00000000 0x00 0x00 0x00 21 0984-1007 00000000 00000000 00000000 0x00 0x00 0x00 22 23 1008-1031 00000000 00000000 00000000 0x00 0x00 0x00 24 25 1032-1055 00000000 00000000 00000000 0x00 0x00 0x00 26 27 1056-1079 00000000 00000000 00000000 0x00 0x00 0x00 28 29 1080-1103 00000000 00000000 00000000 0x00 0x00 0x00 30 1104-1127 00000000 00000000 00000000 0x00 0x00 0x00 31 32 1128-1151 00000000 00000000 00000000 0x00 0x00 0x00 33 34 1152-1175 00000000 00000000 00000000 0x00 0x00 0x00 35 36 1176-1199 00000000 00000000 00000000 0x00 0x00 0x00 37 38 1200-1223 00000000 00000000 00000000 0x00 0x00 0x00 39 1224-1247 00000000 00000000 00000000 0x00 0x00 0x00 40 41 1248-1271 00000000 00000000 00000000 0x00 0x00 0x00 42 43 1272-1295 00000000 00000000 00000000 0x00 0x00 0x00 44 45 1296-1319 00000000 00000000 00000000 0x00 0x00 0x00 46 47 1320-1343 00000000 00000000 00000000 0x00 0x00 0x00 48 1344-1367 00000000 00000000 00000000 0x00 0x00 0x00 49 50 1368-1391 00000000 00000000 00000000 0x00 0x00 0x00 51 52 1392-1415 00000000 00000000 00000000 0x00 0x00 0x00 53 54 1416-1439 00000000 00000000 00000000 0x00 0x00 0x00 55 56 1440-1463 00000000 00000000 00100110 0x00 0x00 0x26 57 1464-1487 00111101 10101001 10011100 0x3D 0xA9 0x9C 58 59 1488-1511 01000000 11010111 10110010 0x40 0xD7 0xB2 60 61 1512-1535 10000110 11100011 10111111 0x86 0xE3 0xBF 62 63 1536-1559 01000011 10100101 11011001 0x43 0xA5 0xD9 64 65 1560-1583 00001101 00000110 11010110 0x0D 0x06 0xD6

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table G.37—The DATA bits for LDPC example 1 after LDPC encoding. (continued) 2 3 4 Binary Val Binary Val Binary Val Bit ## Hex Val Hex Val Hex Val 5 b0 b7 b8 b15 b16 b23 6 7 1584-1607 01100000 11110100 00011111 0x60 0xF4 0x1F 8 9 1608-1631 00110001 00001100 00010011 0x31 0x0C 0x13 10 11 1632-1655 01110110 00001111 10011111 0x76 0x0F 0x9F 12 1656-1679 11011010 10011111 10101001 0xDA 0x9F 0xA9 13 14 1680-1703 01110100 01011001 11011100 0x74 0x59 0xDC 15 16 1704-1727 10001001 11110010 11100010 0x89 0xF2 0xE2 17 18 1728-1751 11011000 01101000 10100001 0xD8 0x68 0xA1 19 20 1752-1775 01100011 00011101 10100101 0x63 0x1D 0xA5 21 1776-1799 10100110 10000000 11010001 0xA6 0x80 0xD1 22 23 1800-1823 10001001 01010111 11011100 0x89 0x57 0xDC 24 25 1824-1847 10110011 01011101 00110011 0xB3 0x5D 0x33 26 27 1848-1871 01110000 11011100 10110010 0x70 0xDC 0xB2 28 29 1872-1895 11110110 00111001 00111101 0xF6 0x39 0x3D 30 1896-1919 00100011 10011011 00110110 0x23 0x9B 0x36 31 32 1920-1943 00111110 00010101 00010001 0x3E 0x15 0x11 33 34 35 36 G.2.6 Removing the shortening bits and puncturing for LDPC example 1 37 38 The shortening bits, applied before LDPC encoding, are now removed as prescribed in paragraph (c) of 39 40 20.3.11.6.5. Finally, either puncturing is applied as described in paragraph (d) of the same subclause or the 41 copying of repeated bits are applied as described in paragraph (e) of the same subclause. In LDPC example 42 1, because Npunc = 54 is non-zero and Nrep = 0, puncturing is prescribed, completing the LDPC encoding pro- 43 44 cess. 45 46 The results are given in Table G.38. 47 NOTE—The Nshrt = 642 shortening bits have been removed and that the Npunc = 54 bits have been punctured from 48 Table G.37 to produce bits 816-1247 of Table G.38. 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table G.38—The DATA bits after puncturing and removal of shortening bits 2 3 4 Binary Val Binary Val Binary Val Bit ## Hex Val Hex Val Hex Val 5 b0 b7 b8 b15 b16 b23 6 7 0000-0023 01101100 00011001 10001001 0x6C 0x19 0x89 8 9 0024-0047 10001111 01101000 00100001 0x8F 0x68 0x21 10 11 0048-0071 11110100 10100101 01100001 0xF4 0xA5 0x61 12 0072-0095 01001111 11010111 10101110 0x4F 0xD7 0xAE 13 14 0096-0119 00100100 00001100 11110011 0x24 0x0C 0xF3 15 16 0120-0143 00111010 11100100 10111100 0x3A 0xE4 0xBC 17 18 0144-0167 01010011 10011000 11000000 0x53 0x98 0xC0 19 20 0168-0191 00011110 00110101 10110011 0x1E 0x35 0xB3 21 0192-0215 11100011 11111000 00100101 0xE3 0xF8 0x25 22 23 0216-0239 01100000 11010110 00100101 0x60 0xD6 0x25 24 25 0240-0263 00110101 00110011 11111110 0x35 0x33 0xFE 26 27 0264-0287 11110000 01000001 00101011 0xF0 0x41 0x2B 28 29 0288-0311 10001111 01010011 00011100 0x8F 0x53 0x1C 30 0312-0335 10000011 01000001 10111110 0x83 0x41 0xBE 31 32 0336-0359 00111001 00101000 01100110 0x39 0x28 0x66 33 34 0360-0383 01000100 01100110 11001101 0x44 0x66 0xCD 35 36 0384-0407 11110110 10100011 11011000 0xF6 0xA3 0xD8 37 38 0408-0431 00001101 11010100 10000001 0x0D 0xD4 0x81 39 0432-0455 00111011 00101111 11011111 0x3B 0x2F 0xDF 40 41 0456-0479 11000011 01011000 11110111 0xC3 0x58 0xF7 42 43 0480-0503 11000110 01010010 11101011 0xC6 0x52 0xEB 44 45 0504-0527 01110000 10001111 10011110 0x70 0x8F 0x9E 46 47 0528-0551 01101010 10010000 10000001 0x6A 0x90 0x81 48 0552-0575 11111101 01111100 10101001 0xFD 0x7C 0xA9 49 50 0576-0599 11010001 01010101 00010010 0xD1 0x55 0x12 51 52 0600-0623 00000100 01110100 11011001 0x04 0x74 0xD9 53 54 0624-0647 11101001 00111011 11001101 0xE9 0x3B 0xCD 55 56 0648-0671 10010011 10001101 01111011 0x93 0x8D 0x7B 57 0672-0695 01111100 01110000 00000010 0x7C 0x70 0x02 58 59 0696-0719 00100000 10011001 10100001 0x20 0x99 0xA1 60 61 0720-0743 01111101 10001010 00100111 0x7D 0x8A 0x27 62 63 0744-0767 00010111 00111001 00010101 0x17 0x39 0x15 64 65 0768-0791 10100000 11101100 10010101 0xA0 0xEC 0x95

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table G.38—The DATA bits after puncturing and removal of shortening bits (contin- 2 3 4 Binary Val Binary Val Binary Val Bit ## Hex Val Hex Val Hex Val 5 b0 b7 b8 b15 b16 b23 6 7 0792-0815 00010110 10010001 00010000 0x16 0x91 0x10 8 9 0816-0839 10011000 11110110 10100110 0x98 0xF6 0xA6 10 11 0840-0863 01110001 00000011 01011110 0x71 0x03 0x5E 12 0864-0887 11001010 00011011 10001110 0xCA 0x1B 0x8E 13 14 0888-0911 11111101 00001110 10010111 0xFD 0x0E 0x97 15 16 0912-0935 01100100 00110100 00011011 0x64 0x34 0x1B 17 18 0936-0959 01011001 10000011 11010000 0x59 0x83 0xD0 19 20 0960-0983 01111100 11000100 00110000 0x7C 0xC4 0x30 21 0984-1007 01001101 11011000 00111110 0x4D 0xD8 0x3E 22 23 1008-1031 01111111 01101010 01111110 0x7F 0x6A 0x7E 24 25 1032-1055 10100101 11010001 01100111 0xA5 0xD1 0x67 26 27 1056-1079 01110010 00100111 11001011 0x72 0x27 0xCB 28 29 1080-1103 10001011 01100001 10100010 0x8B 0x61 0xA2 30 1104-1127 10000101 10001100 01110110 0x85 0x8C 0x76 31 32 1128-1151 10010110 10011010 00000011 0x96 0x9A 0x03 33 34 1152-1175 01000110 00100101 01011111 0x46 0x25 0x5F 35 36 1176-1199 01110010 11001101 01110100 0x72 0xCD 0x74 37 38 1200-1223 11001101 11000011 01110010 0xCD 0xC3 0x72 39 1224-1247 11001011 11011000 11100100 0xCB 0xD8 0xE4 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 G.3 Generating encoded DATA bits — LDPC example 2 2 3 4 LDPC example 2 exercises the alternative branches of the LDPC encoding procedure not exercised in LDPC 5 example 1. Example 2 also exhibits LDPC shortening, encoding, and padding by repetition; employs multiple 6 codewords and diversifies the TXVECTOR parameters—all without making the length of this example cum- 7 bersome. 8 9 10 The length of the text of the message is increased by 40 octets from 72 characters to 112 characters, in order 11 to illustrate padding (rather than puncturing) and encoding of multiple codewords. 12 13 14 Input TXVECTOR parameters for LDPC example 2: 15 — FEC_CODING = LDPC_CODING = 1 (LDPC encoder; not BCC) 16 17 — CH_BANDWIDTH = HT_CBW40 = 1 (CH_BANDWIDTH = 1 => 40 MHz) 18 19 — MCS = 1 (MCS = 1; QPSK; Coding rate = 1/2) 20 — Coding rate R = 1/2 21 22 — LENGTH = 140 Octets (with 16-bit SERVICE field becomes 142 Octets = 23 1136 bits to scramble and encode) 24 25 — STBC = 1 (STBC = 1 => ON; m_STBC = 2) 26 27 28 G.3.1 The message for LDPC example 2 29 30 31 The message being encoded consists of the first 112 characters (shown in bold below) of the well-known 32 "Ode to Joy" by F. Schiller: 33 34 35 Joy, bright spark of divinity, 36 Daughter of Elysium, 37 Fire-insired we tread 38 Thy sanctuary. 39 Thy magic power re-unites 40 41 All that custom has divided, 42 All men become brothers 43 Under the sway of thy gentle wings. 44 45 EDITORIAL NOTE—The text in the baseline Annex G contains a typographical error “Fire-insired” 46 rather than “Fire-inspired”. This amendment corrects only the technical errors in the baseline Annex G 47 48 in order to minimize changes. For consistency, the uncorrected text is also used in this example. 49 50 The message is converted to ASCII; then it is prepended with an appropriate MAC header and a CRC32 is 51 added. The resulting 140 octets PSDU is shown in Table G.39. 52 53 54 Because of the additional 40 characters, note that the message for LDPC example 2 has a different FCS field 55 (octets 137-140) than the previous examples, and that the DurationID field (i.e., octets 3 and 4) changes to 56 0x036 = 54 µs. 57 58 59 60 G.3.2 Prepending the SERVICE field for LDPC example 2 61 62 The transmitted message shown in Table G.39 contains 140 octets, or equivalently, 1120 bits. The bits are 63 64 prepended by the 16 SERVICE field bits (bits 0-15 in Table G.40), as defined by 20.3.11.1, but tail bits and 65 padding bits are not appended as in the BCC Example. The resulting 1136 bits are shown in Table G.40.

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table G.39—The message for LDPC example 2 2 3 4 Octet ## Val Val Val Val Val 5 6 1...5 0x04 0x02 0x00 0x36 0x00 7 8 6...10 0x60 0x08 0xCD 0x37 0xA6 9 10 11...15 0x00 0x20 0xD6 0x01 0x3C 11 16...20 0xF1 0x00 0x60 0x08 0xAD 12 13 21...25 0x3B 0xAF 0x00 0x00 0x4A 14 15 26...30 0x6F 0x79 0x2C 0x20 0x62 16 17 31...35 0x72 0x69 0x67 0x68 0x74 18 19 36...40 0x20 0x73 0x70 0x61 0x72 20 41...45 0x6B 0x20 0x6F 0x66 0x20 21 22 46...50 0x64 0x69 0x76 0x69 0x6E 23 24 51...55 0x69 0x74 0x79 0x2C 0x0A 25 26 56...60 0x44 0x61 0x75 0x67 0x68 27 28 61...65 0x74 0x65 0x72 0x20 0x6F 29 66...70 0x66 0x20 0x45 0x6C 0x79 30 31 71...75 0x73 0x69 0x75 0x6D 0x2C 32 33 76...80 0x0A 0x46 0x69 0x72 0x65 34 35 81...85 0x2D 0x69 0x6E 0x73 0x69 36 37 86...90 0x72 0x65 0x64 0x20 0x77 38 91...95 0x65 0x20 0x74 0x72 0x65 39 40 96...100 0x61 0x64 0x0A 0x54 0x68 41 42 101...105 0x79 0x20 0x73 0x61 0x6E 43 44 106...110 0x63 0x74 0x75 0x61 0x72 45 46 111...115 0x79 0x2E 0x0A 0x54 0x68 47 116...120 0x79 0x20 0x6D 0x61 0x67 48 49 121...125 0x69 0x63 0x20 0x70 0x6F 50 51 126...130 0x77 0x65 0x72 0x20 0x72 52 53 131...135 0x65 0x2D 0x75 0x6E 0x69 54 55 136...140 0x74 0x3B 0xDB 0xB5 0x22 56 57 58 G.3.3 Scrambling LDPC example 2 59 60 61 The 1136 bits are scrambled by the scrambler defined in 17.3.5.4. The initial state of the scrambler is the state 62 1011101 binary (0x5D hexadecimal). The scrambled sequence is given in Table G.41. 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table G.40—The DATA bits for LDPC example 2 before scrambling 2 3 4 Binary Val Binary Val Binary Val Bit ## Hex Val Hex Val Hex Val 5 b7 b0 b15 b8 b23 b16 6 7 0000-0023 00000000 00000000 00000100 0x00 0x00 0x04 8 9 0024-0047 00000010 00000000 00110110 0x02 0x00 0x36 10 11 0048-0071 00000000 01100000 00001000 0x00 0x60 0x08 12 0072-0095 11001101 00110111 10100110 0xCD 0x37 0xA6 13 14 0096-0119 00000000 00100000 11010110 0x00 0x20 0xD6 15 16 0120-0143 00000001 00111100 11110001 0x01 0x3C 0xF1 17 18 0144-0167 00000000 01100000 00001000 0x00 0x60 0x08 19 20 0168-0191 10101101 00111011 10101111 0xAD 0x3B 0xAF 21 0192-0215 00000000 00000000 01001010 0x00 0x00 0x4A 22 23 0216-0239 01101111 01111001 00101100 0x6F 0x79 0x2C 24 25 0240-0263 00100000 01100010 01110010 0x20 0x62 0x72 26 27 0264-0287 01101001 01100111 01101000 0x69 0x67 0x68 28 29 0288-0311 01110100 00100000 01110011 0x74 0x20 0x73 30 0312-0335 01110000 01100001 01110010 0x70 0x61 0x72 31 32 0336-0359 01101011 00100000 01101111 0x6B 0x20 0x6F 33 34 0360-0383 01100110 00100000 01100100 0x66 0x20 0x64 35 36 0384-0407 01101001 01110110 01101001 0x69 0x76 0x69 37 38 0408-0431 01101110 01101001 01110100 0x6E 0x69 0x74 39 0432-0455 01111001 00101100 00001010 0x79 0x2C 0x0A 40 41 0456-0479 01000100 01100001 01110101 0x44 0x61 0x75 42 43 0480-0503 01100111 01101000 01110100 0x67 0x68 0x74 44 45 0504-0527 01100101 01110010 00100000 0x65 0x72 0x20 46 47 0528-0551 01101111 01100110 00100000 0x6F 0x66 0x20 48 0552-0575 01000101 01101100 01111001 0x45 0x6C 0x79 49 50 0576-0599 01110011 01101001 01110101 0x73 0x69 0x75 51 52 0600-0623 01101101 00101100 00001010 0x6D 0x2C 0x0A 53 54 0624-0647 01000110 01101001 01110010 0x46 0x69 0x72 55 56 0648-0671 01100101 00101101 01101001 0x65 0x2D 0x69 57 0672-0695 01101110 01110011 01101001 0x6E 0x73 0x69 58 59 0696-0719 01110010 01100101 01100100 0x72 0x65 0x64 60 61 0720-0743 00100000 01110111 01100101 0x20 0x77 0x65 62 63 0744-0767 00100000 01110100 01110010 0x20 0x74 0x72 64 65 0768-0791 01100101 01100001 01100100 0x65 0x61 0x64

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table G.40—The DATA bits for LDPC example 2 before scrambling (continued) 2 3 4 Binary Val Binary Val Binary Val Bit ## Hex Val Hex Val Hex Val 5 b7 b0 b15 b8 b23 b16 6 7 0792-0815 00001010 01010100 01101000 0x0A 0x54 0x68 8 9 0816-0839 01111001 00100000 01110011 0x79 0x20 0x73 10 11 0840-0863 01100001 01101110 01100011 0x61 0x6E 0x63 12 0864-0887 01110100 01110101 01100001 0x74 0x75 0x61 13 14 0888-0911 01110010 01111001 00101110 0x72 0x79 0x2E 15 16 0912-0935 00001010 01010100 01101000 0x0A 0x54 0x68 17 18 0936-0959 01111001 00100000 01101101 0x79 0x20 0x6D 19 20 0960-0983 01100001 01100111 01101001 0x61 0x67 0x69 21 0984-1007 01100011 00100000 01110000 0x63 0x20 0x70 22 23 1008-1031 01101111 01110111 01100101 0x6F 0x77 0x65 24 25 1032-1055 01110010 00100000 01110010 0x72 0x20 0x72 26 27 1056-1079 01100101 00101101 01110101 0x65 0x2D 0x75 28 29 1080-1103 01101110 01101001 01110100 0x6E 0x69 0x74 30 1104-1127 00111011 11011011 10110101 0x3B 0xDB 0xB5 31 32 1128-1135 00100010 ------0x22 ------33 34 35 36 Table G.41—The DATA bits for LDPC example 2 after scrambling 37 38 Binary Val Binary Val Binary Val 39 Bit ## Hex Val Hex Val Hex Val 40 b0 b7 b8 b15 b16 b23 41 42 0000-0023 01101100 00011001 10001001 0x6C 0x19 0x89 43 44 0024-0047 10001111 01101000 00111001 0x8F 0x68 0x39 45 0048-0071 11110100 10100101 01100001 0xF4 0xA5 0x61 46 47 0072-0095 01001111 11010111 10101110 0x4F 0xD7 0xAE 48 49 0096-0119 00100100 00001100 11110011 0x24 0x0C 0xF3 50 51 0120-0143 00111010 11100100 10111100 0x3A 0xE4 0xBC 52 53 0144-0167 01010011 10011000 11000000 0x53 0x98 0xC0 54 0168-0191 00011110 00110101 10110011 0x1E 0x35 0xB3 55 56 0192-0215 11100011 11111000 00100101 0xE3 0xF8 0x25 57 58 0216-0239 01100000 11010110 00100101 0x60 0xD6 0x25 59 60 0240-0263 00110101 00110011 11111110 0x35 0x33 0xFE 61 62 0264-0287 11110000 01000001 00101011 0xF0 0x41 0x2B 63 0288-0311 10001111 01010011 00011100 0x8F 0x53 0x1C 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table G.41—The DATA bits for LDPC example 2 after scrambling (continued) 2 3 4 Binary Val Binary Val Binary Val Bit ## Hex Val Hex Val Hex Val 5 b0 b7 b8 b15 b16 b23 6 7 0312-0335 10000011 01000001 10111110 0x83 0x41 0xBE 8 9 0336-0359 00111001 00101000 01100110 0x39 0x28 0x66 10 11 0360-0383 01000100 01100110 11001101 0x44 0x66 0xCD 12 0384-0407 11110110 10100011 11011000 0xF6 0xA3 0xD8 13 14 0408-0431 00001101 11010100 10000001 0x0D 0xD4 0x81 15 16 0432-0455 00111011 00101111 11011111 0x3B 0x2F 0xDF 17 18 0456-0479 11000011 01011000 11110111 0xC3 0x58 0xF7 19 20 0480-0503 11000110 01010010 11101011 0xC6 0x52 0xEB 21 0504-0527 01110000 10001111 10011110 0x70 0x8F 0x9E 22 23 0528-0551 01101010 10010000 10000001 0x6A 0x90 0x81 24 25 0552-0575 11111101 01111100 10101001 0xFD 0x7C 0xA9 26 27 0576-0599 11010001 01010101 00010010 0xD1 0x55 0x12 28 29 0600-0623 00000100 01110100 11011001 0x04 0x74 0xD9 30 0624-0647 11101001 00111011 11001101 0xE9 0x3B 0xCD 31 32 0648-0671 10010011 10001101 01111011 0x93 0x8D 0x7B 33 34 0672-0695 01111100 01110000 00000010 0x7C 0x70 0x02 35 36 0696-0719 00100000 10011001 10100001 0x20 0x99 0xA1 37 38 0720-0743 01111101 10001010 00100111 0x7D 0x8A 0x27 39 0744-0767 00010111 00111001 00010101 0x17 0x39 0x15 40 41 0768-0791 10100000 11101100 01010101 0xA0 0xEC 0x55 42 43 0792-0815 10001010 00111111 01101011 0x8A 0x3F 0x6B 44 45 0816-0839 10110110 11011000 10110001 0xB6 0xD8 0xB1 46 47 0840-0863 10001000 10000100 00001111 0x88 0x84 0x0F 48 0864-0887 00101100 10001000 10101000 0x2C 0x88 0xA8 49 50 0888-0911 11111000 10010010 10100000 0xF8 0x92 0xA0 51 52 0912-0935 10110111 10011110 00111100 0xB7 0x9E 0x3C 53 54 0936-0959 01100100 01010101 00001110 0x64 0x55 0x0E 55 56 0960-0983 01111000 11111011 01110011 0x78 0xFB 0x73 57 0984-1007 01010100 00000000 01000010 0x54 0x00 0x42 58 59 1008-1031 10101011 10000010 10111111 0xAB 0x82 0xBF 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table G.41—The DATA bits for LDPC example 2 after scrambling (continued) 2 3 4 Binary Val Binary Val Binary Val Bit ## Hex Val Hex Val Hex Val 5 b0 b7 b8 b15 b16 b23 6 7 1032-1055 11100111 11001011 00100110 0xE7 0xCB 0x26 8 9 1056-1079 11110011 01000000 00001101 0xF3 0x40 0x0D 10 11 1080-1103 00000111 01101010 00010101 0x07 0x6A 0x15 12 1104-1127 00010111 11111111 10100101 0x17 0xFF 0xA5 13 14 1128-1135 11011100 ------0xDC ------15 16 17 18 G.3.4 Inserting the shortening bits for LDPC example 2 19 20 The equations of 20.3.11.6.5 are solved to calculate the following derived parameters for LDPC example 2 21 22 from the input TXVECTOR parameters: 23 —NCW = 2 (number of codewords) 24 25 —LLDPC = 1296 (size of codeword) 26 —NCBPS = 216 (number of coded bits per symbol) 27 28 —Navbits = 2592 (number of available bits) 29 —N = 160 (number of bits to be shortened) 30 shrt 31 —Npunc = 0 (number of bits to be punctured) 32 —N = 12 (number of OFDM symbols) 33 SYM 34 —Nrep = 160 (number of bits to be repeated) 35 36 The results of applying shortening bits, as prescribed in paragraph (c) of 20.3.11.6.5 is given in Table G.42. 37 NOTE— N = 160 shortening bits have been inserted as zeros, 80 zeros at bits 568-647 and 80 zeros at bits 1216- 38 shrt 1295, which equally distributes the shortening bits across the N = 2 codewords. 39 CW 40 41 42 Table G.42—The DATA bits for LDPC example 2 after insertion of shortening bits 43 44 45 Binary Val Binary Val Binary Val Bit ## Hex Val Hex Val Hex Val 46 b0 b7 b8 b15 b16 b23 47 48 0000-0023 01101100 00011001 10001001 0x6C 0x19 0x89 49 50 0024-0047 10001111 01101000 00111001 0x8F 0x68 0x39 51 52 0048-0071 11110100 10100101 01100001 0xF4 0xA5 0x61 53 54 0072-0095 01001111 11010111 10101110 0x4F 0xD7 0xAE 55 56 0096-0119 00100100 00001100 11110011 0x24 0x0C 0xF3 57 0120-0143 00111010 11100100 10111100 0x3A 0xE4 0xBC 58 59 0144-0167 01010011 10011000 11000000 0x53 0x98 0xC0 60 61 0168-0191 00011110 00110101 10110011 0x1E 0x35 0xB3 62 63 0192-0215 11100011 11111000 00100101 0xE3 0xF8 0x25 64 65 0216-0239 01100000 11010110 00100101 0x60 0xD6 0x25

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table G.42—The DATA bits for LDPC example 2 after insertion of shortening bits 2 (continued) 3 4 Binary Val Binary Val Binary Val 5 Bit ## Hex Val Hex Val Hex Val 6 b0 b7 b8 b15 b16 b23 7 8 0240-0263 00110101 00110011 11111110 0x35 0x33 0xFE 9 0264-0287 11110000 01000001 00101011 0xF0 0x41 0x2B 10 11 0288-0311 10001111 01010011 00011100 0x8F 0x53 0x1C 12 13 0312-0335 10000011 01000001 10111110 0x83 0x41 0xBE 14 15 0336-0359 00111001 00101000 01100110 0x39 0x28 0x66 16 17 0360-0383 01000100 01100110 11001101 0x44 0x66 0xCD 18 0384-0407 11110110 10100011 11011000 0xF6 0xA3 0xD8 19 20 0408-0431 00001101 11010100 10000001 0x0D 0xD4 0x81 21 22 0432-0455 00111011 00101111 11011111 0x3B 0x2F 0xDF 23 24 0456-0479 11000011 01011000 11110111 0xC3 0x58 0xF7 25 26 0480-0503 11000110 01010010 11101011 0xC6 0x52 0xEB 27 0504-0527 01110000 10001111 10011110 0x70 0x8F 0x9E 28 29 0528-0551 01101010 10010000 10000001 0x6A 0x90 0x81 30 31 0552-0575 11111101 01111100 00000000 0xFD 0x7C 0x00 32 33 0576-0599 00000000 00000000 00000000 0x00 0x00 0x00 34 35 0600-0623 00000000 00000000 00000000 0x00 0x00 0x00 36 0624-0647 00000000 00000000 00000000 0x00 0x00 0x00 37 38 0648-0671 10101001 11010001 01010101 0xA9 0xD1 0x55 39 40 0672-0695 00010010 00000100 01110100 0x12 0x04 0x74 41 42 0696-0719 11011001 11101001 00111011 0xD9 0xE9 0x3B 43 44 0720-0743 11001101 10010011 10001101 0xCD 0x93 0x8D 45 0744-0767 01111011 01111100 01110000 0x7B 0x7C 0x70 46 47 0768-0791 00000010 00100000 10011001 0x02 0x20 0x99 48 49 0792-0815 10100001 01111101 10001010 0xA1 0x7D 0x8A 50 51 0816-0839 00100111 00010111 00111001 0x27 0x17 0x39 52 53 0840-0863 00010101 10100000 11101100 0x15 0xA0 0xEC 54 0864-0887 01010101 10001010 00111111 0x55 0x8A 0x3F 55 56 0888-0911 01101011 10110110 11011000 0x6B 0xB6 0xD8 57 58 0912-0935 10110001 10001000 10000100 0xB1 0x88 0x84 59 60 0936-0959 00001111 00101100 10001000 0x0F 0x2C 0x88 61 62 0960-0983 10101000 11111000 10010010 0xA8 0xF8 0x92 63 0984-1007 10100000 10110111 10011110 0xA0 0xB7 0x9E 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table G.42—The DATA bits for LDPC example 2 after insertion of shortening bits 2 (continued) 3 4 Binary Val Binary Val Binary Val 5 Bit ## Hex Val Hex Val Hex Val 6 b0 b7 b8 b15 b16 b23 7 8 1008-1031 00111100 01100100 01010101 0x3C 0x64 0x55 9 1032-1055 00001110 01111000 11111011 0x0E 0x78 0xFB 10 11 1056-1079 01110011 01010100 00000000 0x73 0x54 0x00 12 13 1080-1103 01000010 10101011 10000010 0x42 0xAB 0x82 14 15 1104-1127 10111111 11100111 11001011 0xBF 0xE7 0xCB 16 17 1128-1151 00100110 11110011 01000000 0x26 0xF3 0x40 18 1152-1175 00001101 00000111 01101010 0x0D 0x07 0x6A 19 20 1176-1199 00010101 00010111 11111111 0x15 0x17 0xFF 21 22 1200-1223 10100101 11011100 00000000 0xA5 0xDC 0x00 23 24 1224-1247 00000000 00000000 00000000 0x00 0x00 0x00 25 26 1248-1271 00000000 00000000 00000000 0x00 0x00 0x00 27 1272-1295 00000000 00000000 00000000 0x00 0x00 0x00 28 29 30 31 G.3.5 Encoding the data for LDPC example 2 32 33 34 The DATA with shortening bits are LDPC encoded as two (NCW = 2) codewords (LLDPC = 1296; R = 1/2) 35 as prescribed by paragraph (c) of 20.3.11.6.5. The results are given in Table G.43. 36 NOTE—The LDPC encoder appends 648 bits as follows: bits 648-1295 after the first shortened codeword; and another 37 648 bits, bits 1944-2591, after the second shortened codeword. 38 39 40 41 Table G.43—The DATA bits for LDPC example 2 after LDPC encoding 42 43 Binary Val Binary Val Binary Val 44 Bit ## Hex Val Hex Val Hex Val 45 b0 b7 b8 b15 b16 b23 46 47 0000-0023 01101100 00011001 10001001 0x6C 0x19 0x89 48 0024-0047 10001111 01101000 00111001 0x8F 0x68 0x39 49 50 0048-0071 11110100 10100101 01100001 0xF4 0xA5 0x61 51 52 0072-0095 01001111 11010111 10101110 0x4F 0xD7 0xAE 53 54 0096-0119 00100100 00001100 11110011 0x24 0x0C 0xF3 55 56 0120-0143 00111010 11100100 10111100 0x3A 0xE4 0xBC 57 0144-0167 01010011 10011000 11000000 0x53 0x98 0xC0 58 59 0168-0191 00011110 00110101 10110011 0x1E 0x35 0xB3 60 61 0192-0215 11100011 11111000 00100101 0xE3 0xF8 0x25 62 63 0216-0239 01100000 11010110 00100101 0x60 0xD6 0x25 64 65 0240-0263 00110101 00110011 11111110 0x35 0x33 0xFE

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table G.43—The DATA bits for LDPC example 2 after LDPC encoding (continued) 2 3 4 Binary Val Binary Val Binary Val Bit ## Hex Val Hex Val Hex Val 5 b0 b7 b8 b15 b16 b23 6 7 0264-0287 11110000 01000001 00101011 0xF0 0x41 0x2B 8 9 0288-0311 10001111 01010011 00011100 0x8F 0x53 0x1C 10 11 0312-0335 10000011 01000001 10111110 0x83 0x41 0xBE 12 0336-0359 00111001 00101000 01100110 0x39 0x28 0x66 13 14 0360-0383 01000100 01100110 11001101 0x44 0x66 0xCD 15 16 0384-0407 11110110 10100011 11011000 0xF6 0xA3 0xD8 17 18 0408-0431 00001101 11010100 10000001 0x0D 0xD4 0x81 19 20 0432-0455 00111011 00101111 11011111 0x3B 0x2F 0xDF 21 0456-0479 11000011 01011000 11110111 0xC3 0x58 0xF7 22 23 0480-0503 11000110 01010010 11101011 0xC6 0x52 0xEB 24 25 0504-0527 01110000 10001111 10011110 0x70 0x8F 0x9E 26 27 0528-0551 01101010 10010000 10000001 0x6A 0x90 0x81 28 29 0552-0575 11111101 01111100 00000000 0xFD 0x7C 0x00 30 0576-0599 00000000 00000000 00000000 0x00 0x00 0x00 31 32 0600-0623 00000000 00000000 00000000 0x00 0x00 0x00 33 34 0624-0647 00000000 00000000 00000000 0x00 0x00 0x00 35 36 0648-0671 00001001 11000001 11111011 0x09 0xC1 0xFB 37 38 0672-0695 01101000 11001101 00000101 0x68 0xCD 0x05 39 0696-0719 10110110 11000111 01100101 0xB6 0xC7 0x65 40 41 0720-0743 10100101 10011001 11100000 0xA5 0x99 0xE0 42 43 0744-0767 01110011 01110000 01101101 0x73 0x70 0x6D 44 45 0768-0791 01011110 01111001 11100011 0x5E 0x79 0xE3 46 47 0792-0815 01100111 00100111 01011110 0x67 0x27 0x5E 48 0816-0839 10010101 10101000 11110110 0x95 0xA8 0xF6 49 50 0840-0863 00110101 01001000 10100111 0x35 0x48 0xA7 51 52 0864-0887 00100110 00101001 00110001 0x26 0x29 0x31 53 54 0888-0911 00101110 00011001 11110100 0x2E 0x19 0xF4 55 56 0912-0935 00110100 01101111 01010000 0x34 0x6F 0x50 57 0936-0959 01010000 11101001 11000100 0x50 0xE9 0xC4 58 59 0960-0983 00000110 11011001 11101110 0x06 0xD9 0xEE 60 61 0984-1007 11111000 00011011 11011001 0xF8 0x1B 0xD9 62 63 1008-1031 01101100 10000110 11010011 0x6C 0x86 0xD3 64 65 1032-1055 11101001 01100100 11001000 0xE9 0x64 0xC8

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table G.43—The DATA bits for LDPC example 2 after LDPC encoding (continued) 2 3 4 Binary Val Binary Val Binary Val Bit ## Hex Val Hex Val Hex Val 5 b0 b7 b8 b15 b16 b23 6 7 1056-1079 11110001 10100001 00001011 0xF1 0xA1 0x0B 8 9 1080-1103 11000010 01000100 01010100 0xC2 0x44 0x54 10 11 1104-1127 10100000 10001100 10111011 0xA0 0x8C 0xBB 12 1128-1151 10100011 11100100 10101001 0xA3 0xE4 0xA9 13 14 1152-1175 10101011 01010000 11100010 0xAB 0x50 0xE2 15 16 1176-1199 01110000 00101000 00110110 0x70 0x28 0x36 17 18 1200-1223 11111100 00110000 00110100 0xFC 0x30 0x34 19 20 1224-1247 01101010 01001001 00100010 0x6A 0x49 0x22 21 1248-1271 11010101 00000111 11001111 0xD5 0x07 0xCF 22 23 1272-1295 00110101 00111010 10001110 0x35 0x3A 0x8E 24 25 1296-1319 10101001 11010001 01010101 0xA9 0xD1 0x55 26 27 1320-1343 00010010 00000100 01110100 0x12 0x04 0x74 28 29 1344-1367 11011001 11101001 00111011 0xD9 0xE9 0x3B 30 1368-1391 11001101 10010011 10001101 0xCD 0x93 0x8D 31 32 1392-1415 01111011 01111100 01110000 0x7B 0x7C 0x70 33 34 1416-1439 00000010 00100000 10011001 0x02 0x20 0x99 35 36 1440-1463 10100001 01111101 10001010 0xA1 0x7D 0x8A 37 38 1464-1487 00100111 00010111 00111001 0x27 0x17 0x39 39 1488-1511 00010101 10100000 11101100 0x15 0xA0 0xEC 40 41 1512-1535 01010101 10001010 00111111 0x55 0x8A 0x3F 42 43 1536-1559 01101011 10110110 11011000 0x6B 0xB6 0xD8 44 45 1560-1583 10110001 10001000 10000100 0xB1 0x88 0x84 46 47 1584-1607 00001111 00101100 10001000 0x0F 0x2C 0x88 48 1608-1631 10101000 11111000 10010010 0xA8 0xF8 0x92 49 50 1632-1655 10100000 10110111 10011110 0xA0 0xB7 0x9E 51 52 1656-1679 00111100 01100100 01010101 0x3C 0x64 0x55 53 54 1680-1703 00001110 01111000 11111011 0x0E 0x78 0xFB 55 56 1704-1727 01110011 01010100 00000000 0x73 0x54 0x00 57 1728-1751 01000010 10101011 10000010 0x42 0xAB 0x82 58 59 1752-1775 10111111 11100111 11001011 0xBF 0xE7 0xCB 60 61 1776-1799 00100110 11110011 01000000 0x26 0xF3 0x40 62 63 1800-1823 00001101 00000111 01101010 0x0D 0x07 0x6A 64 65 1824-1847 00010101 00010111 11111111 0x15 0x17 0xFF

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table G.43—The DATA bits for LDPC example 2 after LDPC encoding (continued) 2 3 4 Binary Val Binary Val Binary Val Bit ## Hex Val Hex Val Hex Val 5 b0 b7 b8 b15 b16 b23 6 7 1848-1871 10100101 11011100 00000000 0xA5 0xDC 0x00 8 9 1872-1895 00000000 00000000 00000000 0x00 0x00 0x00 10 11 1896-1919 00000000 00000000 00000000 0x00 0x00 0x00 12 1920-1943 00000000 00000000 00000000 0x00 0x00 0x00 13 14 1944-1967 01100100 10110110 01010100 0x64 0xB6 0x54 15 16 1968-1991 00110001 00000001 01100001 0x31 0x01 0x61 17 18 1992-2015 00101001 00010011 01110000 0x29 0x13 0x70 19 20 2016-2039 01010000 10000000 11001110 0x50 0x80 0xCE 21 2040-2063 01000101 11000000 10101000 0x45 0xC0 0xA8 22 23 2064-2087 11001101 11111000 01111100 0xCD 0xF8 0x7C 24 25 2088-2111 01010011 01010001 01001110 0x53 0x51 0x4E 26 27 2112-2135 11010011 10101110 00010011 0xD3 0xAE 0x13 28 29 2136-2159 11110000 11101101 10111111 0xF0 0xED 0xBF 30 2160-2183 10001110 10010100 00110100 0x8E 0x94 0x34 31 32 2184-2207 11111011 00010000 11011001 0xFB 0x10 0xD9 33 34 2208-2231 10111110 00110001 10011111 0xBE 0x31 0x9F 35 36 2232-2255 01100000 00011100 10100110 0x60 0x1C 0xA6 37 38 2256-2279 01010101 11111001 10100110 0x55 0xF9 0xA6 39 2280-2303 10101010 00111000 01110001 0xAA 0x38 0x71 40 41 2304-2327 01111010 10101100 10110010 0x7A 0xAC 0xB2 42 43 2328-2351 11110101 11010001 10000001 0xF5 0xD1 0x81 44 45 2352-2375 01010000 11110001 00001011 0x50 0xF1 0x0B 46 47 2376-2399 10111101 10010011 10001011 0xBD 0x93 0x8B 48 2400-2423 10100010 10010110 00100101 0xA2 0x96 0x25 49 50 2424-2447 11100011 01101100 11000111 0xE3 0x6C 0xC7 51 52 2448-2471 00000101 00011000 00101000 0x05 0x18 0x28 53 54 2472-2495 11110011 00111001 11011000 0xF3 0x39 0xD8 55 56 2496-2519 00010001 01110101 00010111 0x11 0x75 0x17 57 2520-2543 11011101 11111011 11010010 0xDD 0xFB 0xD2 58 59 2544-2567 10101010 11101011 10100110 0xAA 0xEB 0xA6 60 61 2568-2591 10000101 10110011 01011000 0x85 0xB3 0x58 62 63 64 65 G.3.6 Removing the shortening bits and repetition for LDPC example 2

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 The shortening bits, applied before LDPC encoding, are now removed as prescribed in paragraph (c) of 2 20.3.11.6.5. Finally, either puncturing is applied as described in paragraph (d) of the same subclause or the 3 copying of repeated bits are applied as described in paragraph (e) of the same subclause. In LDPC example 4 5 1, because Npunc = 0 and Nrep = 160 is non-zero, repetition is prescribed, completing the LDPC encoding pro- 6 cess. 7 8 9 The results are given in Table G.44. 10 NOTE 1—N = 642 shortening bits have been removed and N = 54 bits have been punctured from Table G.37 to 11 shrt punc produce bits 816-1247 of Table G.38. 12 13 NOTE 2—The first 80 shortening bits (bits 568-647 from Table G.43) have been removed from the first codeword 14 between bit 567 and 568 of Table G.44, and that the second 80 shortening bits (bits 1864-1943 of Table G.43) have been 15 removed between bits 1215 and 1216 of Table G.44. Also, 80 bits have been repeated from the beginning of the first 16 codeword (bits 0-79) to the end of the first codeword (bits 1216-1295), and 80 bits have been repeated from the begin- 17 ning of the second codeword (bits 1296-1375) to end of the second codeword (bits 2512-2591) in Table G.44. 18 19 20 21 Table G.44—The DATA bits after removal of shortening bits and copying of repetition bits 22 23 Binary Val Binary Val Binary Val 24 Bit ## Hex Val Hex Val Hex Val 25 b0 b7 b8 b15 b16 b23 26 27 0000-0023 01101100 00011001 10001001 0x6C 0x19 0x89 28 29 0024-0047 10001111 01101000 00111001 0x8F 0x68 0x39 30 0048-0071 11110100 10100101 01100001 0xF4 0xA5 0x61 31 32 0072-0095 01001111 11010111 10101110 0x4F 0xD7 0xAE 33 34 0096-0119 00100100 00001100 11110011 0x24 0x0C 0xF3 35 36 0120-0143 00111010 11100100 10111100 0x3A 0xE4 0xBC 37 38 0144-0167 01010011 10011000 11000000 0x53 0x98 0xC0 39 0168-0191 00011110 00110101 10110011 0x1E 0x35 0xB3 40 41 0192-0215 11100011 11111000 00100101 0xE3 0xF8 0x25 42 43 0216-0239 01100000 11010110 00100101 0x60 0xD6 0x25 44 45 0240-0263 00110101 00110011 11111110 0x35 0x33 0xFE 46 47 0264-0287 11110000 01000001 00101011 0xF0 0x41 0x2B 48 0288-0311 10001111 01010011 00011100 0x8F 0x53 0x1C 49 50 0312-0335 10000011 01000001 10111110 0x83 0x41 0xBE 51 52 0336-0359 00111001 00101000 01100110 0x39 0x28 0x66 53 54 0360-0383 01000100 01100110 11001101 0x44 0x66 0xCD 55 56 0384-0407 11110110 10100011 11011000 0xF6 0xA3 0xD8 57 0408-0431 00001101 11010100 10000001 0x0D 0xD4 0x81 58 59 0432-0455 00111011 00101111 11011111 0x3B 0x2F 0xDF 60 61 0456-0479 11000011 01011000 11110111 0xC3 0x58 0xF7 62 63 0480-0503 11000110 01010010 11101011 0xC6 0x52 0xEB 64 65 0504-0527 01110000 10001111 10011110 0x70 0x8F 0x9E

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table G.44—The DATA bits after removal of shortening bits and copying of repetition bits 2 3 4 Binary Val Binary Val Binary Val Bit ## Hex Val Hex Val Hex Val 5 b0 b7 b8 b15 b16 b23 6 7 0528-0551 01101010 10010000 10000001 0x6A 0x90 0x81 8 9 0552-0575 11111101 01111100 00001001 0xFD 0x7C 0x09 10 11 0576-0599 11000001 11111011 01101000 0xC1 0xFB 0x68 12 0600-0623 11001101 00000101 10110110 0xCD 0x05 0xB6 13 14 0624-0647 11000111 01100101 10100101 0xC7 0x65 0xA5 15 16 0648-0671 10011001 11100000 01110011 0x99 0xE0 0x73 17 18 0672-0695 01110000 01101101 01011110 0x70 0x6D 0x5E 19 20 0696-0719 01111001 11100011 01100111 0x79 0xE3 0x67 21 0720-0743 00100111 01011110 10010101 0x27 0x5E 0x95 22 23 0744-0767 10101000 11110110 00110101 0xA8 0xF6 0x35 24 25 0768-0791 01001000 10100111 00100110 0x48 0xA7 0x26 26 27 0792-0815 00101001 00110001 00101110 0x29 0x31 0x2E 28 29 0816-0839 00011001 11110100 00110100 0x19 0xF4 0x34 30 0840-0863 01101111 01010000 01010000 0x6F 0x50 0x50 31 32 0864-0887 11101001 11000100 00000110 0xE9 0xC4 0x06 33 34 0888-0911 11011001 11101110 11111000 0xD9 0xEE 0xF8 35 36 0912-0935 00011011 11011001 01101100 0x1B 0xD9 0x6C 37 38 0936-0959 10000110 11010011 11101001 0x86 0xD3 0xE9 39 0960-0983 01100100 11001000 11110001 0x64 0xC8 0xF1 40 41 0984-1007 10100001 00001011 11000010 0xA1 0x0B 0xC2 42 43 1008-1031 01000100 01010100 10100000 0x44 0x54 0xA0 44 45 1032-1055 10001100 10111011 10100011 0x8C 0xBB 0xA3 46 47 1056-1079 11100100 10101001 10101011 0xE4 0xA9 0xAB 48 1080-1103 01010000 11100010 01110000 0x50 0xE2 0x70 49 50 1104-1127 00101000 00110110 11111100 0x28 0x36 0xFC 51 52 1128-1151 00110000 00110100 01101010 0x30 0x34 0x6A 53 54 1152-1175 01001001 00100010 11010101 0x49 0x22 0xD5 55 56 1176-1199 00000111 11001111 00110101 0x07 0xCF 0x35 57 1200-1223 00111010 10001110 01101100 0x3A 0x8E 0x6C 58 59 1224-1247 00011001 10001001 10001111 0x19 0x89 0x8F 60 61 1248-1271 01101000 00111001 11110100 0x68 0x39 0xF4 62 63 1272-1295 10100101 01100001 01001111 0xA5 0x61 0x4F 64 65 1296-1319 10101001 11010001 01010101 0xA9 0xD1 0x55

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table G.44—The DATA bits after removal of shortening bits and copying of repetition bits 2 3 4 Binary Val Binary Val Binary Val Bit ## Hex Val Hex Val Hex Val 5 b0 b7 b8 b15 b16 b23 6 7 1320-1343 00010010 00000100 01110100 0x12 0x04 0x74 8 9 1344-1367 11011001 11101001 00111011 0xD9 0xE9 0x3B 10 11 1368-1391 11001101 10010011 10001101 0xCD 0x93 0x8D 12 1392-1415 01111011 01111100 01110000 0x7B 0x7C 0x70 13 14 1416-1439 00000010 00100000 10011001 0x02 0x20 0x99 15 16 1440-1463 10100001 01111101 10001010 0xA1 0x7D 0x8A 17 18 1464-1487 00100111 00010111 00111001 0x27 0x17 0x39 19 20 1488-1511 00010101 10100000 11101100 0x15 0xA0 0xEC 21 1512-1535 01010101 10001010 00111111 0x55 0x8A 0x3F 22 23 1536-1559 01101011 10110110 11011000 0x6B 0xB6 0xD8 24 25 1560-1583 10110001 10001000 10000100 0xB1 0x88 0x84 26 27 1584-1607 00001111 00101100 10001000 0x0F 0x2C 0x88 28 29 1608-1631 10101000 11111000 10010010 0xA8 0xF8 0x92 30 1632-1655 10100000 10110111 10011110 0xA0 0xB7 0x9E 31 32 1656-1679 00111100 01100100 01010101 0x3C 0x64 0x55 33 34 1680-1703 00001110 01111000 11111011 0x0E 0x78 0xFB 35 36 1704-1727 01110011 01010100 00000000 0x73 0x54 0x00 37 38 1728-1751 01000010 10101011 10000010 0x42 0xAB 0x82 39 1752-1775 10111111 11100111 11001011 0xBF 0xE7 0xCB 40 41 1776-1799 00100110 11110011 01000000 0x26 0xF3 0x40 42 43 1800-1823 00001101 00000111 01101010 0x0D 0x07 0x6A 44 45 1824-1847 00010101 00010111 11111111 0x15 0x17 0xFF 46 47 1848-1871 10100101 11011100 01100100 0xA5 0xDC 0x64 48 1872-1895 10110110 01010100 00110001 0xB6 0x54 0x31 49 50 1896-1919 00000001 01100001 00101001 0x01 0x61 0x29 51 52 1920-1943 00010011 01110000 01010000 0x13 0x70 0x50 53 54 1944-1967 10000000 11001110 01000101 0x80 0xCE 0x45 55 56 1968-1991 11000000 10101000 11001101 0xC0 0xA8 0xCD 57 1992-2015 11111000 01111100 01010011 0xF8 0x7C 0x53 58 59 2016-2039 01010001 01001110 11010011 0x51 0x4E 0xD3 60 61 2040-2063 10101110 00010011 11110000 0xAE 0x13 0xF0 62 63 2064-2087 11101101 10111111 10001110 0xED 0xBF 0x8E 64 65 2088-2111 10010100 00110100 11111011 0x94 0x34 0xFB

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table G.44—The DATA bits after removal of shortening bits and copying of repetition bits 2 3 4 Binary Val Binary Val Binary Val Bit ## Hex Val Hex Val Hex Val 5 b0 b7 b8 b15 b16 b23 6 7 2112-2135 00010000 11011001 10111110 0x10 0xD9 0xBE 8 9 2136-2159 00110001 10011111 01100000 0x31 0x9F 0x60 10 11 2160-2183 00011100 10100110 01010101 0x1C 0xA6 0x55 12 2184-2207 11111001 10100110 10101010 0xF9 0xA6 0xAA 13 14 2208-2231 00111000 01110001 01111010 0x38 0x71 0x7A 15 16 2232-2255 10101100 10110010 11110101 0xAC 0xB2 0xF5 17 18 2256-2279 11010001 10000001 01010000 0xD1 0x81 0x50 19 20 2280-2303 11110001 00001011 10111101 0xF1 0x0B 0xBD 21 2304-2327 10010011 10001011 10100010 0x93 0x8B 0xA2 22 23 2328-2351 10010110 00100101 11100011 0x96 0x25 0xE3 24 25 2352-2375 01101100 11000111 00000101 0x6C 0xC7 0x05 26 27 2376-2399 00011000 00101000 11110011 0x18 0x28 0xF3 28 29 2400-2423 00111001 11011000 00010001 0x39 0xD8 0x11 30 2424-2447 01110101 00010111 11011101 0x75 0x17 0xDD 31 32 2448-2471 11111011 11010010 10101010 0xFB 0xD2 0xAA 33 34 2472-2495 11101011 10100110 10000101 0xEB 0xA6 0x85 35 36 2496-2519 10110011 01011000 10101001 0xB3 0x58 0xA9 37 38 2520-2543 11010001 01010101 00010010 0xD1 0x55 0x12 39 2544-2567 00000100 01110100 11011001 0x04 0x74 0xD9 40 41 2568-2591 11101001 00111011 11001101 0xE9 0x3B 0xCD 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Annex I (normative) Regulatory Classes 2 3 4 5 I.1 External regulatory references 6 7 8 Change two rows for behavior limits sets 13 and 14, insert a row for behavior limits set 16, change the 9 reserved row for 16-255, insert a new last row to contain NOTE 1 and NOTE 2, and insert table footnote 10 d in Table I.3 as shown: 11 12 13 Table I.3—Behavior limits sets 14 15 16 Behavior limits set USA Europe Japan 17 18 13 Reserved 20/40 MHz BSS Primary chan- Reserved Reserved Reserved 19 20 nel with Secondary channel above the Prima- 21 ry channel or 20 MHz BSS primary channel 22 operated by an FC HT AP and also 20 MHz 23 operational channel for a non-AP STA when 24 the non-AP STA is associated with an FC HT 25 26 AP.d 27 28 See NOTE. 29 30 14 Reserved 20/40 MHz BSS Primary chan- Reserved Reserved Reserved 31 nel with Secondary channel below the Prima- 32 33 ry channel or 20 MHz BSS primary channel 34 operated by an FC HT AP and also 20 MHz 35 operational channel for a non-AP STA when 36 the non-AP STA is associated with an FC HT 37 d 38 AP. 39 40 See NOTE. 41 42 16 DFS with 50-100 microsecond pulses FCC Reserved ARIB STD-T71 43 47CFR2.947 (Edition 5.0) 44 and FCC Section 45 46 MO&O 06-96, 3.1.7(2)(i)(3)A)( 47 Appendix sec- b)2) 48 tion 6.2, Table 6, 49 Radar Type 5 50 51 1617-255 Reserved Reserved Reserved 52 53 NOTE—The fields that specify the 40 MHz channels are described in Clause 20.3.15.3. 54 d 55 For 20 MHz operation where the regulatory class signifies 40 MHz channel spacing, the 20 MHz channel corre- 56 sponds to the channel number indicated. 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Annex J (normative) Country information element and regulatory 2 3 classes 4 5 6 7 8 J.1 Country information and regulatory classes 9 10 11 Change the Table J.1 entries for Regulatory Classes 2 and 4 and the entry for reserved Regulatory 12 Classes 16-255 as follows: 13 14 15 16 Table J.1—Regulatory classes in the USA 17 18 19 Channel Transmit Transmit Channel 20 Regulatory Starting Power Power Emissions Behavior Spacing Channel set 21 Class Frequency limit limit Limits set Limits set (MHz) 22 (GHz) (mW) (EIRP) 23 24 2 5 20 52, 56, 60, 200 — 1 1, 4, 16 25 64 26 27 4 5 20 100, 104, 200 — 1 1, 4, 16 28 108, 112, 29 116, 120, 30 124, 128, 31 132, 136, 32 140 33 34 16-25521 Reserved Reserved Reserved Reserved Reserved Reserved Reserved 35 36 37 38 Insert the entries for Regulatory Classes 22 to 33 and reserved Regulatory Classes 34-255 in Table J.1 39 40 after the row for reserved Regulatory Classes 16-21 and insert the NOTE at the end of the table: 41 42 43 Table J.1—Regulatory classes in the USA 44 45 46 Channel Transmit Transmit Channel 47 Regulatory Starting Power Power Emissions Behavior Spacing Channel set 48 Class Frequency limit limit Limits set Limits set (MHz) 49 (GHz) (mW) (EIRP) 50 51 52 22 5 40 36, 4440 — 1 1,2,13 53 54 23 5 40 52, 60 200 — 1 1,4,13 55 24 5 40 100, 108, 200 — 1 1,4,13,16 56 116, 57 124, 132 58 59 25 5 40 149, 157 800 — 1 1,13 60 61 26 5 40 149, 157 1000 — 4 10,13 62 63 27 5 40 40, 4840 — 1 1,2,14 64 65 28 5 40 56, 64 200 — 1 1,4,14

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table J.1—Regulatory classes in the USA 2 3 4 Channel Transmit Transmit Channel 5 Regulatory Starting Power Power Emissions Behavior Spacing Channel set 6 Class Frequency limit limit Limits set Limits set (MHz) 7 (GHz) (mW) (EIRP) 8 9 10 29 5 40 104, 112, 200 — 1 1,4,14,16 11 120, 12 128, 136 13 14 30 5 40 153, 161 800 — 1 1,14 15 31 5 40 153, 161 1000 — 4 10,14 16 17 32 2.407 40 1-7 1000 — 4 10,13 18 19 33 2.407 40 5-11 1000 — 4 10,14 20 21 34-255 Reserved Reserved Reserved Reserved Reserved Reserved Reserved 22 23 NOTE—The Channel Spacing for Regulatory Classes 22-33 is for the supported bandwidth rather than the operating 24 bandwidth. In these regulatory classes, the AP operates either a 20/40 MHz BSS or a 20 MHz BSS, and the operating 25 bandwidth for a non-AP STA is either 20 MHz or 40 MHz. 26 27 28 Insert Regulatory Classes 5 to 12 in Table J.2 after the row for Regulatory Class 4, insert the NOTE at the 29 end of the table and change reserved Regulatory Classes 5-255 as follows: 30 31 32 33 Table J.2—Regulatory classes in Europe 34 35 36 Channel Transmit Channel 37 Regulatory Starting Channel Power Emissions Behavior Spacing 38 Class Frequency set limit Limits set Limits set (MHz) 39 (GHz) (mW) 40 41 42 5 5 40 36, 44200 1 2,3,13 43 6 5 40 52, 60 200 1 1,3,4,13 44 45 7 5 40 100, 108, 1000 1 1,3,4,13 46 116, 47 124, 132 48 49 8 5 40 40, 48200 1 2,3,14 50 51 9 5 40 56, 64 200 1 1,3,4,14 52 53 10 5 40 104, 112, 1000 1 1,3,4,14 54 120, 55 128, 136 56 11 2.407 40 1-9 100 4 10,13 57 58 12 2.407 40 5-13 100 4 10,14 59 60 513-255 Reserved Reserved Reserved Reserved Reserved Reserved 61 62 NOTE—The Channel Spacing for Regulatory Class 5-12 is for the supported bandwidth rather than the 63 operating bandwidth. In these regulatory classes, the AP operates in a 20/40 MHz BSS, and the operat- 64 ing bandwidth for a non-AP STA is either 20 MHz or 40 MHz. 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Change Table J.3 as follows (the changes comprise insertion of the “Transmit Power limit (mW/MHz)” 2 and “EIRP (mW/MHz)” columns and modification to the entries for Regulatory Classes 1 and 32) and 3 insert “-” in the “Transmit Power limit (mW/MHz)” and “EIRP (mW/MHz)” columns for the other 4 5 existing entries: 6 7 8 Table J.3—Regulatory classes in Japan 9 10 11 Transmit Channel Transmit 12 Channel Power EIRP Regulatory starting Power Emissions Behavior 13 spacing Channel set limit (mW/ class frequency limit Limits set Limits set 14 (MHz) (mW/ MHz) (GHz) (dBm) 15 MHz) 16 17 1 5 20 34, 38, 42, - 22 10 10 1 1, 2, 6 18 46 19 36, 40, 44, 20 48 21 22 32 5.0 20 52, 56, 60, - 22 10 10 1 1, 2, 3, 4, 23 64 5, 6 24 25 26 27 Insert Regulatory Classes 33 to 57 after the row for Regulatory Class 32, insert the NOTE at the end of 28 the table and change the reserved Regulatory Classes 33-255 row in Table J.3 as follows: 29 30 31 Table J.3—Regulatory classes in Japan 32 33 34 Transmit Channel Transmit 35 Channel Power EIRP Regulatory starting Power Emissions Behavior 36 spacing Channel set limit (mW/ class frequency limit Limits set Limits set 37 (MHz) (mW/ MHz) (GHz) (dBm) 38 MHz) 39 40 33 5 20 52, 56, 60, - 10 5 1 1, 2, 4, 5, 41 64 6 42 43 34 5 20 100, 104, - 10 50 1 1, 3, 4, 5, 44 108, 112, 6, 16 45 116, 120, 46 124, 128, 47 132, 136, 48 140 49 50 35 5 20 100, 104, - 10 25 1 1, 4, 5, 6, 51 108, 112, 16 52 116, 120, 53 124, 128, 54 132, 136, 55 140 56 57 36 5 40 36, 44 - 5 5 1 1, 2, 6, 13 58 37 5 40 52, 60 - 5 5 1 1, 2, 3, 4, 59 5, 6, 13 60 61 38 5 40 52, 60 - 5 2.5 1 1, 2, 4, 5, 62 6, 13 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table J.3—Regulatory classes in Japan (continued) 2 3 4 Transmit Channel Transmit 5 Channel Power EIRP Regulatory starting Power Emissions Behavior 6 spacing Channel set limit (mW/ class frequency limit Limits set Limits set 7 (MHz) (mW/ MHz) (GHz) (dBm) 8 MHz) 9 10 39 5 40 100, 108, - 5 25 1 1, 3, 4, 5, 11 116, 124, 6, 13, 16 12 132 13 14 40 5 40 100, 108, - 5 12.5 1 1, 4, 5, 6, 15 116, 124, 13, 16 16 132 17 18 41 5 40 40, 48 - 5 5 1 1, 2, 6, 14 19 42 5 40 56, 64 - 5 5 1 1, 2, 3, 4, 20 5, 6, 14 21 22 43 5 40 56, 64 - 5 2.5 1 1, 2, 4, 5, 23 6, 14 24 25 44 5 40 104, 112, - 5 25 1 1, 3, 4, 5, 26 120, 128, 6, 14, 16 27 136 28 29 45 5 40 104, 112, - 5 12.5 1 1, 4, 5, 6, 30 120, 128, 14, 16 31 136 32 33 46 4 40 184, 192 24 25 - 2 5, 6, 7, 13 34 47 4 40 184, 192 24 25 - 2 5, 6, 8, 13 35 36 48 4 40 184, 192 24 25 - 3 5, 6, 7, 13 37 38 49 4 40 184, 192 24 25 - 3 5, 6, 8, 13 39 40 50 4 40 184, 192 - 5 - 1 5, 6, 8, 13 41 42 51 4 40 188, 196 24 25 - 2 5, 6, 7, 14 43 52 4 40 188, 196 24 25 - 2 5, 6, 8, 14 44 45 53 4 40 188, 196 24 25 - 3 5, 6, 7, 14 46 47 54 4 40 188, 196 24 25 - 3 5, 6, 8, 14 48 49 55 4 40 188, 196 - 5 - 1 5, 6, 8, 14 50 51 56 2.407 40 1-9 - 5 - 4 10,13 52 57 2.407 40 5-13 - 5 - 4 10, 14 53 54 3358-255 Reserved Reserved Reserved Reserved Reserved Reserved Reserved Reserved 55 56 NOTE—The channel spacing for regulatory classes 34-55 is for the supported bandwidth rather than the operating 57 bandwidth. In these regulatory domains, the AP operates in a 20/40 MHz BSS, and the operating bandwidth of a 58 non-AP STA is either 20 MHz or 40 MHz. 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Annex P (informative) Bibliography 2 3 4 5 P.1 General 6 7 8 Insert the following entry in P.1, renumbering as necessary: 9 10 [B27a] ISO/IEC 14977:1996, Information technology — Syntactic metalanguage — Extended BNF. 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Annex Q (normative) ASN.1 encoding of the RRM MIB 2 3 4 EDITORIAL NOTE—This Annex is introduced by P802.11k 5 6 7 8 Change the term Dot11RRMNeighborReportEntry as follows: 9 10 Dot11RRMNeighborReportEntry ::= 11 SEQUENCE { 12 13 dot11RRMNeighborReportIndex Unsigned32, 14 dot11RRMNeighborReportIfIndex InterfaceIndex, 15 16 dot11RRMNeighborReportBSSID MacAddress, 17 dot11RRMNeighborReportAPReachability INTEGER, 18 dot11RRMNeighborReportSecurity TruthValue, 19 20 dot11RRMNeighborReportCapSpectrumMgmt TruthValue, 21 dot11RRMNeighborReportCapQoS TruthValue, 22 23 dot11RRMNeighborReportCapAPSD TruthValue, 24 dot11RRMNeighborReportCapRRM TruthValue, 25 26 dot11RRMNeighborReportCapDelayBlockAck TruthValue, 27 dot11RRMNeighborReportCapImmediateBlockAck TruthValue, 28 29 dot11RRMNeighborReportKeyScope TruthValue, 30 dot11RRMNeighborReportRegulatoryClass INTEGER, 31 32 dot11RRMNeighborReportChannelNumber INTEGER, 33 dot11RRMNeighborReportPhyType INTEGER, 34 35 dot11RRMNeighborReportNeighborTSFInfo OCTETSTRING, 36 dot11RRMNeighborReportPilotPeriod Unsigned32, 37 dot11RRMNeighborReportPilotMultipleBSSID OCTET, 38 39 ot11RRMNeighborReportRRMEnabledCapabilities OCTETSTRING, 40 dot11RRMNeighborReportVendorSpecificOCTET STRING, 41 42 dot11RRMNeighborReportRowStatus RowStatus 43 dot11RRMNeighborReportMobilityDomain TruthValue, 44 45 } 46 dot11RRMNeighborReportCapHT TruthValue, 47 dot11RRMNeighborReportHTLDPCCodingCap TruthValue, 48 49 dot11RRMNeighborReportHTSupportedChannelWidthSet TruthValue, 50 dot11RRMNeighborReportHTSMPowerSave Unsigned32, 51 52 dot11RRMNeighborReportHTGreenfield TruthValue, 53 dot11RRMNeighborReportHTShortGIfor20MHz TruthValue, 54 55 dot11RRMNeighborReportHTShortGIfor40MHz TruthValue, 56 dot11RRMNeighborReportHTTxSTBC TruthValue, 57 58 dot11RRMNeighborReportHTRxSTBC Unsigned32, 59 dot11RRMNeighborReportHTDelayedBlockAck TruthValue, 60 61 dot11RRMNeighborReportHTMaxAMSDULength TruthValue, 62 dot11RRMNeighborReportHTDSSCCKModein40MHz TruthValue, 63 dot11RRMNeighborReportHTFortyMHzIntolerant TruthValue, 64 65 dot11RRMNeighborReportHTLSIGTXOPProtectionSupport TruthValue,

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 dot11RRMNeighborReportHTMaxAMPDULengthExponent Integer, 2 3 dot11RRMNeighborReportHTMinMPDUStartSpacing Integer, 4 dot11RRMNeighborReportHTRxMCSBitMask Unsigned32, 5 dot11RRMNeighborReportHTRxHighestSupportedDataRate Unsigned32, 6 7 dot11RRMNeighborReportHTTxMCSSetDefined TruthValue, 8 dot11RRMNeighborReportHTTxRxMCSSetNotEqual TruthValue, 9 10 dot11RRMNeighborReportHTTxMaxNumberSpatialStreamsSupported Unsigned32, 11 dot11RRMNeighborReportHTTxUnequalModulationSupported TruthValue, 12 13 dot11RRMNeighborReportHTPCO TruthValue, 14 dot11RRMNeighborReportHTPCOTransitionTime Unsigned32, 15 16 dot11RRMNeighborReportHTMCSFeedback Unsigned32, 17 dot11RRMNeighborReportHTCSupport TruthValue, 18 19 dot11RRMNeighborReportHTRDResponder TruthValue, 20 dot11RRMNeighborReportHTImplictTransmitBeamformingReceivingCap 21 TruthValue, 22 23 dot11RRMNeighborReportHTReceiveStaggeredSoundingCap TruthValue, 24 dot11RRMNeighborReportHTTransmitStaggeredSoundingCap TruthValue, 25 26 dot11RRMNeighborReportHTReceiveNDPCap TruthValue, 27 dot11RRMNeighborReportHTTransmitNDPCap TruthValue, 28 29 dot11RRMNeighborReportHTImplicitTransmitBeamformingCap TruthValue, 30 dot11RRMNeighborReportHTTransmitBeamformingCalibration Unsigned32, 31 32 dot11RRMNeighborReportHTExplicitCSITransmitBeamformingCap TruthValue, 33 dot11RRMNeighborReportHTExplicitNonCompressedSteeringCap TruthValue, 34 dot11RRMNeighborReportHTExplicitCompressedSteeringCap TruthValue, 35 36 dot11RRMNeighborReportHTExplicitTransmitBeamformingFeedback 37 Unsigned32, 38 39 dot11RRMNeighborReportHTExplicitNonCompressedBeamformingFeedbackCap 40 Unsigned32, 41 dot11RRMNeighborReportHTExplicitCompressedBeamformingFeedbackCap 42 43 Unsigned32, 44 dot11RRMNeighborReportHTTransmitBeamformingMinimalGrouping Unsigned32, 45 46 dot11RRMNeighborReportHTCSINumberofTransmitBeamformingAntennasSuppt 47 Unsigned32, 48 dot11RRMNeighborReportHTNonCompressedSteeringNumberofTransmitBeamform- 49 ingAntennasSuppt Unsigned32, 50 51 dot11RRMNeighborReportHTCompressedSteeringNumberofTransmitBeamform- 52 ingAntennasSuppt Unsigned32, 53 54 dot11RRMNeighborReportHTCSIMaxNumberofRowsTransmitBeamformingSuppt 55 Unsigned32, 56 dot11RRMNeighborReportHTTransmitBeamformingChannelEstimationCap 57 58 Unsigned32, 59 dot11RRMNeighborReportHTAntSelectionCap TruthValue, 60 61 dot11RRMNeighborReportHTExplicitCSIFeedbackBasedTxASELCap TruthValue, 62 dot11RRMNeighborReportHTAntIndicesFeedbackBasedTxASELCap TruthValue, 63 dot11RRMNeighborReportHTExplicitCSIFeedbackBasedCap TruthValue, 64 65 dot11RRMNeighborReportHTAntIndicesFeedbackCap TruthValue,

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 dot11RRMNeighborReportHTRxASELCap TruthValue, 2 3 dot11RRMNeighborReportHTTxSoundingPPDUsCap TruthValue, 4 dot11RRMNeighborReportHTInfoPrimaryChannel Integer, 5 6 dot11RRMNeighborReportHTInfoSecChannelOffset Unsigned32, 7 dot11RRMNeighborReportHTInfoSTAChannelWidth TruthValue, 8 9 dot11RRMNeighborReportHTInfoRIFSMode TruthValue, 10 dot11RRMNeighborReportHTInfoProtection Unsigned32, 11 12 dot11RRMNeighborReportHTInfoNonGreenfieldHTSTAsPresent TruthValue, 13 dot11RRMNeighborReportHTInfoOBSSNonHTSTAsPresent TruthValue, 14 15 dot11RRMNeighborReportHTInfoDualBeacon TruthValue, 16 dot11RRMNeighborReportHTInfoDualCTSProtection TruthValue, 17 18 dot11RRMNeighborReportHTInfoSTBCBeacon TruthValue, 19 dot11RRMNeighborReportHTInfoLSIGTXOPProtectionSup TruthValue, 20 21 dot11RRMNeighborReportHTInfoPCOActive TruthValue, 22 dot11RRMNeighborReportHTInfoPCOPhase TruthValue, 23 24 dot11RRMNeighborReportHTInfoBasicMCSSet Unsigned32, 25 dot11RRMNeighborReportHTSecChannelOffset Unsigned32, 26 27 dot11RRMNeighborReportExtCapPSMPSupport TruthValue, 28 29 dot11RRMNeighborReportExtCapSPSMPSup TruthValue, 30 dot11RRMNeighborReportExtCapServiceIntervalGranularity Unsigned32} 31 32 33 34 Insert the following definitions at the end of the existing definitions for the dot11RRMNeighborReport 35 TABLE, just before the comment that reads 36 37 “-- ******************************************************************** 38 39 -- End of dot11RRMNeighborReport TABLE 40 -- *****************************************************************” : 41 42 dot11RRMNeighborReportCapHT OBJECT-TYPE 43 SYNTAX TruthValue 44 45 MAX-ACCESS read-create 46 STATUS current 47 48 DESCRIPTION 49 "The High Throughput Bit when set to one, indicates that the AP 50 51 represented by this BSSID is an HT AP including the HT Capabilities 52 element in its Beacons, and that the contents of that HT 53 Capabilities element are identical to the HT Capabilities element 54 advertised by the AP sending the report. See 7.3.2.37” 55 56 ::= { dot11RRMNeighborReportEntry 23 } 57 58 59 dot11RRMNeighborReportHTLDPCCodingCap OBJECT-TYPE 60 SYNTAX TruthValue 61 62 MAX-ACCESS read-create 63 STATUS current 64 65 DESCRIPTION

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 "The HT LDPC coding capability indicates support for receiving LDPC 2 coded packets, set to FALSE if not supported, set to TRUE if 3 4 supported. See 7.3.2.56.2" 5 ::= { dot11RRMNeighborReportEntry 24 } 6 7 8 dot11RRMNeighborReportHTSupportedChannelWidthSet OBJECT-TYPE 9 10 SYNTAX TruthValue 11 MAX-ACCESS read-create 12 13 STATUS current 14 DESCRIPTION 15 16 "The HT Supported channel width set indicates which channel widths 17 the STA supports, Set to FALSE if only 20 MHz operation is 18 supported, Set to TRUE if both 20 MHz and 40 MHz operation is 19 supported. See 7.3.2.56.2" 20 21 ::= { dot11RRMNeighborReportEntry 25 } 22 23 24 25 dot11RRMNeighborReportHTSMPowerSave OBJECT-TYPE 26 27 SYNTAX Unsigned32 (0..3) 28 MAX-ACCESS read-create 29 30 STATUS current 31 DESCRIPTION 32 33 "The HT SM Power Save indicates the Spatial Multiplexing (SM) Power 34 Save mode, set to 0 for Static SM Power Save mode, set to 1 for 35 36 Dynamic SM Power Save mode, set to 3 for SM Power Save disabled, 37 the value 2 is reserved, See 7.3.2.56.2" 38 ::= { dot11RRMNeighborReportEntry 26 } 39 40 41 42 43 dot11RRMNeighborReportHTGreenfield OBJECT-TYPE 44 SYNTAX TruthValue 45 46 MAX-ACCESS read-create 47 STATUS current 48 49 DESCRIPTION 50 "The HT-greenfield indicates support for the reception of PPDUs 51 52 with HT-greenfield format, set to FALSE if not supported, set to 53 TRUE if supported. See 7.3.2.56.2" 54 ::= { dot11RRMNeighborReportEntry 27 } 55 56 57 58 59 dot11RRMNeighborReportHTShortGIfor20MHz OBJECT-TYPE 60 SYNTAX TruthValue 61 62 MAX-ACCESS read-create 63 STATUS current 64 65 DESCRIPTION

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 "The HT Short GI for 20 MHZ indicates Short GI Support for the 2 reception of 20 MHz packets, set to FALSE if not supported, set to 3 4 TRUE if supported See 7.3.2.56.2" 5 ::= { dot11RRMNeighborReportEntry 28 } 6 7 8 9 10 dot11RRMNeighborReportHTShortGIfor40MHz OBJECT-TYPE 11 SYNTAX TruthValue 12 13 MAX-ACCESS read-create 14 STATUS current 15 16 DESCRIPTION 17 "The HT Short GI for 40 MHz indicates Short GI support for the 18 reception of 40 MHz packets, set to FALSE if not supported, set to 19 20 TRUE if supported. See 7.3.2.56.2" 21 ::= { dot11RRMNeighborReportEntry 29} 22 23 24 dot11RRMNeighborReportHTTxSTBC OBJECT-TYPE 25 26 SYNTAX TruthValue 27 MAX-ACCESS read-create 28 29 STATUS current 30 DESCRIPTION 31 32 "The HT Tx STBC indicates support for the transmission of PPDUs 33 using STBC, set to FALSE if not supported, set to TRUE if 34 supported. See 7.3.2.56.2" 35 36 ::= { dot11RRMNeighborReportEntry 30} 37 38 39 dot11RRMNeighborReportHTRxSTBC OBJECT-TYPE 40 SYNTAX Unsigned32 41 42 MAX-ACCESS read-create 43 STATUS current 44 45 DESCRIPTION 46 47 "The HT Rx STBC indicates support for the reception of PPDUs using 48 STBC, set to 0 for no support, set to 1 for support of one spatial 49 stream, set to 2 for support of one and two spatial streams, set to 50 3 for support of one, two, and three spatial streams. See 51 52 7.3.2.56.2" 53 ::= { dot11RRMNeighborReportEntry 31} 54 55 56 dot11RRMNeighborReportHTDelayedBlockAck OBJECT-TYPE 57 58 SYNTAX TruthValue 59 MAX-ACCESS read-create 60 61 STATUS current 62 DESCRIPTION 63 64 "The HT-delayed Block ACK indicates support for HT-delayed Block 65 ACK operation, set to FALSE if not supported, set to TRUE if

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 supported. Support indicates that the STA is able to accept an 2 ADDBA request for HT-delayed Block ACK. See 7.3.2.56.2" 3 4 ::= { dot11RRMNeighborReportEntry 32 } 5 6 7 dot11RRMNeighborReportHTMaxAMSDULength OBJECT-TYPE 8 SYNTAX TruthValue 9 10 MAX-ACCESS read-create 11 STATUS current 12 13 DESCRIPTION 14 "The HT Maximum A-MSDU length indicates maximum A-MSDU length, set 15 to FALSE for 3839 octets, set to TRUE for 7935 octets. See 16 17 7.3.2.56.2" 18 ::= { dot11RRMNeighborReportEntry 33 } 19 20 21 dot11RRMNeighborReportHTDSSCCKModein40MHz OBJECT-TYPE 22 23 SYNTAX TruthValue 24 MAX-ACCESS read-create 25 STATUS current 26 27 DESCRIPTION 28 "The HT DSSS/CCK Mode in 40 MHz indicates use of DSSS/CCK mode in a 29 30 40 MHz capable BSS operating in 20/40 MHz mode, set to FALSE if 31 DSSS/CCK in 40 MHz is not allowed, set to TRUE if the DSSS/CCK in 32 40 MHz is allowed. See 7.3.2.56.2" 33 34 ::= { dot11RRMNeighborReportEntry 34 } 35 36 37 dot11RRMNeighborReportHTFortyMHzIntolerant OBJECT-TYPE 38 SYNTAX TruthValue 39 40 MAX-ACCESS read-create 41 STATUS current 42 DESCRIPTION 43 44 "The HT Forty MHz Intolerant indicates whether other BSSs receiving 45 this information are required to prohibit 40 MHz transmissions, set 46 to TRUE to prohibit 20/40 MHz BSS operation, otherwise set to 47 48 FALSE. See 7.3.2.56.2" 49 ::= { dot11RRMNeighborReportEntry 35 } 50 51 52 dot11RRMNeighborReportHTLSIGTXOPProtectionSupport OBJECT-TYPE 53 54 SYNTAX TruthValue 55 MAX-ACCESS read-create 56 57 STATUS current 58 DESCRIPTION 59 "The HT L-SIG TXOP protection support indicates support for the 60 61 LSIG TXOP protection mechanism, set to FALSE if not supported, set 62 to TRUE if supported. See 7.3.2.56.2" 63 ::= { dot11RRMNeighborReportEntry 36 } 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 dot11RRMNeighborReportHTMaxAMPDULengthExponent OBJECT-TYPE 2 3 SYNTAX Integer (0..3) 4 MAX-ACCESS read-create 5 6 STATUS current 7 DESCRIPTION 8 9 "The HT Maximum A-MPDU Length Exponent indicates the maximum length 10 of A-MPDU that the STA can receive. This field is an integer in the 11 range 0 to 3. The length defined by this field is equal to 2(13 + 12 Maximum A-MPDU Length) - 1 octets. See 7.3.2.56.3" 13 14 ::= { dot11RRMNeighborReportEntry 37 } 15 16 17 dot11RRMNeighborReportHTMinMPDUStartSpacing OBJECT-TYPE 18 SYNTAX Integer (0..7) 19 20 MAX-ACCESS read-create 21 STATUS current 22 23 DESCRIPTION 24 "The HT Minimum MPDU Start Spacing determines the minimum time 25 26 between the 27 start of adjacent MPDUs within an AMPDU, measured at the PHY-SAP, set to 28 0 for no restriction, set to 1 for 1/4 µs, set to µ2 for 1/2 µs, set to 29 µ µ µ µ 30 3 for 1 s, set to 4 for 2 s, set to 5 for 4 s, set to 6 for 8 s, set 31 to 7 for 16 µs. See 7.3.2.57.3" 32 ::= { dot11RRMNeighborReportEntry 38 } 33 34 35 dot11RRMNeighborReportHTRxMCSBitMask OBJECT-TYPE 36 37 SYNTAX Unsigned32 38 MAX-ACCESS read-create 39 40 STATUS current 41 DESCRIPTION 42 43 "The HT Rx MCS Bitmask is a 77 bit subfield that defines a set of 44 MCS values, where bit B0 corresponds to MCS 0 and bit B76 45 corresponds to MCS 76, set to 0 when the MSC is not supported, set 46 to 1 when the MSC is supported. See 7.3.2.56.4" 47 48 ::= { dot11RRMNeighborReportEntry 39} 49 50 51 dot11RRMNeighborReportHTRxHighestSupportedDataRate OBJECT-TYPE 52 SYNTAX Unsigned32 53 54 MAX-ACCESS read-create 55 STATUS current 56 57 DESCRIPTION 58 "The HT Highest Supported Data Rate is a 10 bit subfield that 59 60 defines the highest data rate that the STA is able to receive, in 61 units of 1 Mb/s, where 1 represents 1 Mb/s, and incrementing by 1 62 Mb/s steps to the value 1023 which represents 1023 Mb/s. See 63 7.3.2.56.4" 64 65 ::= { dot11RRMNeighborReportEntry 40 }

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 2 3 dot11RRMNeighborReportHTTxMCSSetDefined OBJECT-TYPE 4 SYNTAX TruthValue 5 6 MAX-ACCESS read-create 7 STATUS current 8 9 DESCRIPTION 10 "The HT Tx MCS Set Defined indicates if the Tx MCS set is defined, 11 set to FALSE if no Tx MCS set is defined, set to TRUE if Tx MSC set 12 is defined. See 7.3.2.56.4" 13 14 ::= { dot11RRMNeighborReportEntry 41 } 15 16 17 dot11RRMNeighborReportHTTxRxMCSSetNotEqual OBJECT-TYPE 18 SYNTAX TruthValue 19 20 MAX-ACCESS read-create 21 STATUS current 22 23 DESCRIPTION 24 "The HT Tx RX MCS set not equal indicates if the Tx MCS set is 25 26 defined to be equal to the Rx MCS set, set to FALSE where no Tx MCS 27 set is defined or where the Tx MCS Set is defined to be equal to 28 the RX MCS Set, set to TRUE where the TX MCS set may differ from 29 the Rx MCS set. See 7.3.2.56.4" 30 31 ::= { dot11RRMNeighborReportEntry 42 } 32 33 34 dot11RRMNeighborReportHTTxMaxNumberSpatialStreamsSupported OBJECT-TYPE 35 SYNTAX Unsigned32 (0..3) 36 37 MAX-ACCESS read-create 38 STATUS current 39 40 DESCRIPTION 41 "The HT Tx maximum number spatial streams support indicates maximum 42 43 number of spatial streams supported when the Tx MCS Set may differ 44 from the Rx MCS set, set to 0 where no TX MCS set is defined or 45 where the Tx MCS set is defined to be equal to the RX MCS set or 46 where the maximum number of spatial streams supported when 47 48 transmitting is 1 spatial stream and the Tx MCS set may differ from 49 the Rx MCS set, set to 1 where the maximum number of spatial 50 streams supported when transmitting is 2 spatial streams and the Tx 51 MCS set may differ from the Rx MCS set, set to 2 where the maximum 52 number of spatial streams supported when transmitting is 3 spatial 53 54 streams and the Tx MCS set may differ from the Rx MCS set, set to 3 55 where the maximum number of spatial streams supported when 56 transmitting is 4 spatial streams and the Tx MCS set may differ 57 58 from the Rx MCS set. See 7.3.2.56.4" 59 ::= { dot11RRMNeighborReportEntry 43 } 60 61 62 dot11RRMNeighborReportHTTxUnequalModulationSupported OBJECT-TYPE 63 SYNTAX TruthValue 64 65 MAX-ACCESS read-create

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 STATUS current 2 3 DESCRIPTION 4 " The HT Tx unequal modulation supported indicates whether transmit 5 unequal modulation is supported when the Tx MCS set may differ from the 6 7 Rx MCS set, set to FALSE where no TX MCS set is defined or where the Tx 8 MCS set is defined to be equal to the RX MCS set or when unequal 9 modulation is not supported and the Tx MCS set may differ from the Rx 10 MCS set, set to TRUE when unequal modulation is supported and the Tx MCS 11 12 set may differ from the Rx MCS set. See 7.3.2.56.4" 13 ::= { dot11RRMNeighborReportEntry 44 } 14 15 16 dot11RRMNeighborReportHTPCO OBJECT-TYPE 17 SYNTAX TruthValue 18 19 MAX-ACCESS read-create 20 STATUS current 21 22 DESCRIPTION 23 "The HT PCO indicates support for PCO, set to FALSE if not 24 25 supported, set to TRUE if supported. See 7.3.2.56.5" 26 ::= { dot11RRMNeighborReportEntry 45 } 27 28 29 30 31 dot11RRMNeighborReportHTPCOTransitionTime OBJECT-TYPE 32 SYNTAX Unsigned32 (0..3) 33 MAX-ACCESS read-create 34 35 STATUS current 36 DESCRIPTION 37 38 "The HT PCO transition time indicates that the STA can switch 39 between 20 MHz channel width and 40 MHz channel width within the 40 indicated time, set to 0 for no transition, set to 1 for 400 µs, 41 42 set to 2 for 1.5 ms, set to 3 for 5 ms. For the no transition case 43 (set to 0) the PCO active STA does not change its operation channel 44 width and is able to receive 40 MHz PPDUs during the 20 MHz phase. 45 See 7.3.2.56.5" 46 47 ::= { dot11RRMNeighborReportEntry 46 } 48 49 50 dot11RRMNeighborReportHTMCSFeedback OBJECT-TYPE 51 SYNTAX Unsigned32 (0..3) 52 53 MAX-ACCESS read-create 54 STATUS current 55 56 DESCRIPTION 57 "The HT MCS feedback indicates the capability of the STA to provide 58 MCS feedback, set to 0 if the STA does not provide MCS feedback, 59 60 set to 2 if the STA provide only unsolicited MCS feedback, set to 3 61 if the STA can provide MCS feedback in response to MRQ as well as 62 unsolicited MCS feedback. Note the value 1 is reserved. See 63 7.3.2.56.5" 64 65 ::= { dot11RRMNeighborReportEntry 47 }

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 2 3 dot11RRMNeighborReportHTCSupport OBJECT-TYPE 4 SYNTAX TruthValue 5 MAX-ACCESS read-create 6 7 STATUS current 8 DESCRIPTION 9 10 "The HT +HTC support indicates support of the high throughput 11 control field, set to FALSE if not supported, set to TRUE if 12 supported. See 7.3.2.56.5" 13 14 ::= { dot11RRMNeighborReportEntry 48 } 15 16 17 dot11RRMNeighborReportHTRDResponder OBJECT-TYPE 18 SYNTAX TruthValue 19 20 MAX-ACCESS read-create 21 STATUS current 22 23 DESCRIPTION 24 "The HT RD responder indicates support for acting as a revere 25 direction responder, set to FALSE if not supported, set to TRUE if 26 27 supported. See 7.3.2.56.5" 28 ::= { dot11RRMNeighborReportEntry 49} 29 30 31 dot11RRMNeighborReportHTImplictTransmitBeamformingReceivingCap OBJECT-TYPE 32 SYNTAX TruthValue 33 34 MAX-ACCESS read-create 35 STATUS current 36 37 DESCRIPTION 38 "The HT implicit Transmit Beamforming receiving capable 39 indicateswhether this STA can receive Transmit Beamforming steered 40 41 frames using implicit feedback, set to FALSE if not supported, set 42 to TRUE if supported. See 7.3.2.56.6" 43 ::= { dot11RRMNeighborReportEntry 50 } 44 45 46 dot11RRMNeighborReportHTReceiveStaggeredSoundingCap OBJECT-TYPE 47 48 SYNTAX TruthValue 49 MAX-ACCESS read-create 50 51 STATUS current 52 DESCRIPTION 53 54 "The HT receive staggered sounding capable indicates whether this 55 STA can receive staggered sounding frames, set to FALSE if not 56 supported, set to TRUE if supported. See 7.3.2.56.6" 57 58 ::= { dot11RRMNeighborReportEntry 51 } 59 60 61 dot11RRMNeighborReportHTTransmitStaggeredSoundingCap OBJECT-TYPE 62 SYNTAX TruthValue 63 MAX-ACCESS read-create 64 65 STATUS current

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 DESCRIPTION 2 3 "The HT transmit staggered sounding capable indicates whether this 4 STA can transmit staggered sounding frames, set to FALSE if not 5 supported, set to TRUE if supported. See 7.3.2.56.6" 6 7 ::= { dot11RRMNeighborReportEntry 52 } 8 9 dot11RRMNeighborReportHTReceiveNDPCap OBJECT-TYPE 10 11 SYNTAX TruthValue 12 MAX-ACCESS read-create 13 14 STATUS current 15 DESCRIPTION 16 17 "The HT Receive NDP capable indicates whether this receiver can 18 interpret Null Data Packets as sounding frames, set to FALSE if not 19 supported, set to TRUE if supported. See 7.3.2.56.6" 20 21 ::= { dot11RRMNeighborReportEntry 53 } 22 23 24 dot11RRMNeighborReportHTTransmitNDPCap OBJECT-TYPE 25 SYNTAX TruthValue 26 27 MAX-ACCESS read-create 28 STATUS current 29 30 DESCRIPTION 31 "The HT Transmit NDP capable indicates whether this STA can 32 transmit Null Data Packets as sounding frames, set to FALSE if not 33 34 supported, set to TRUE if supported. See 7.3.2.56.6" 35 ::= { dot11RRMNeighborReportEntry 54 } 36 37 38 dot11RRMNeighborReportHTImplicitTransmitBeamformingCap OBJECT-TYPE 39 40 SYNTAX TruthValue 41 MAX-ACCESS read-create 42 43 STATUS current 44 DESCRIPTION 45 46 "The HT Implicit Transmit Beamforming capable indicates whether 47 this STA can apply implicit transmit beamforming, set to FALSE if 48 not supported, set to TRUE if supported. See 7.3.2.56.6" 49 50 ::= { dot11RRMNeighborReportEntry 55 } 51 52 53 dot11RRMNeighborReportHTTransmitBeamformingCalibration OBJECT-TYPE 54 SYNTAX Unsigned32 (0..3) 55 MAX-ACCESS read-create 56 57 STATUS current 58 DESCRIPTION 59 60 "The HT Beamforming Calibration indicates that the STA can 61 participate in a calibration procedure initiated by another STA 62 that is capable of generating an immediate response Sounding PPDU, 63 64 and can provide a CSI report in response to the receipt of a 65 Sounding PPDU, set to 0 if not supported, set to 1 is the STA can

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 respond to a calibration request using the CSI Report but cannot 2 initiate calibration, set to 3 if the STA can both initiate and 3 4 respond to a calibration request. See 7.3.2.56.6" 5 ::= { dot11RRMNeighborReportEntry 56 } 6 7 8 dot11RRMNeighborReportHTExplicitCSITransmitBeamformingCap OBJECT-TYPE 9 10 SYNTAX TruthValue 11 MAX-ACCESS read-create 12 13 STATUS current 14 DESCRIPTION 15 "The HT explicit CSI Transmit Beamforming capable indicates whether 16 17 this STA can apply transmit beamforming using SCI explicit feedback 18 in its transmission, set to FALSE if not supported, set to TRUE if 19 supported. See 7.3.2.56.6" 20 21 ::= { dot11RRMNeighborReportEntry 57 } 22 23 24 dot11RRMNeighborReportHTExplicitNonCompressedSteeringCap OBJECT-TYPE 25 SYNTAX TruthValue 26 27 MAX-ACCESS read-create 28 STATUS current 29 30 DESCRIPTION 31 "The HT explicit non-compressed steering capable indicates whether 32 this STA can apply transmit beamforming using non-compressed 33 34 beamforming feedback matrix explicit feedback in its transmission, 35 set to FALSE if not supported, set to TRUE if supported. See 36 7.3.2.56.6" 37 38 ::= { dot11RRMNeighborReportEntry 58 } 39 40 41 dot11RRMNeighborReportHTExplicitCompressedSteeringCap OBJECT-TYPE 42 SYNTAX TruthValue 43 44 MAX-ACCESS read-create 45 STATUS current 46 47 DESCRIPTION 48 "The HT explicit compressed steering capable indicates whether this 49 STA can apply transmit beamforming using compressed beamforming 50 51 feedback matrix explicit feedback in its transmission, set to FALSE 52 if not supported, set to TRUE if supported. See 7.3.2.56.6" 53 ::= { dot11RRMNeighborReportEntry 59} 54 55 56 dot11RRMNeighborReportHTExplicitTransmitBeamformingFeedback OBJECT-TYPE 57 58 SYNTAX Unsigned32 (0..3) 59 MAX-ACCESS read-create 60 61 STATUS current 62 DESCRIPTION 63 64 "The HT explicit Transmit Beamforming CSI feedback indicates 65 whether this receiver can return CSI explicit feedback, set to 0 if

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 not supported, set to 1 for delayed feedback, set to 2 for 2 immediate feedback, set to 3 for delayed and immediate feedback. 3 4 See 7.3.2.56.6" 5 ::= { dot11RRMNeighborReportEntry 60 } 6 7 8 dot11RRMNeighborReportHTExplicitNonCompressedBeamformingFeedbackCap OBJECT- 9 TYPE 10 11 SYNTAX Unsigned32 (0..3) 12 MAX-ACCESS read-create 13 14 STATUS current 15 DESCRIPTION 16 17 "The HT Explicit non-compressed beamforming feedback capable 18 indicates whether this receiver can return non-compressed 19 beamforming feedback matrix explicit feedback, set to 0 if not 20 supported, set to 1 for delayed feedback, set to 2 for immediate 21 22 feedback, set to 3 for delayed and immediate feedback. See 23 7.3.2.56.6" 24 ::= { dot11RRMNeighborReportEntry 61 } 25 26 27 dot11RRMNeighborReportHTExplicitCompressedBeamformingFeedbackCap OBJECT- 28 29 TYPE 30 SYNTAX Unsigned32 (0..3) 31 32 MAX-ACCESS read-create 33 STATUS current 34 DESCRIPTION 35 36 "The HT explicit compressed beamforming feedback capable indicates 37 whether of not this receiver can return compressed beamforming 38 feedback matrix explicit feedback, set to 0 if not supported, set 39 40 to 1 for delayed feedback, set to 2 for immediate feedback, set to 41 3 for delayed and immediate feedback. See 7.3.2.56.6" 42 ::= { dot11RRMNeighborReportEntry 62 } 43 44 45 dot11RRMNeighborReportHTTransmitBeamformingMinimalGrouping OBJECT-TYPE 46 47 SYNTAX Unsigned32 (0..3) 48 MAX-ACCESS read-create 49 50 STATUS current 51 DESCRIPTION 52 53 "The HT Transmit Beamforming minimal grouping indicates the minimal 54 grouping used for explicit feedback reports, set to 0 if the STA 55 supports groups of 1 (no grouping), set to 1 to indicate groups of 56 57 1, 2, set to 2 to indicate groups of 1, 4, set to 3 to indicate 58 groups of 1, 2, 4. See 7.3.2.56.6" 59 ::= { dot11RRMNeighborReportEntry 63 } 60 61 62 dot11RRMNeighborReportHTCSINumberofTransmitBeamformingAntennasSuppt OBJECT- 63 TYPE 64 65 SYNTAX Unsigned32 (0..3)

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 MAX-ACCESS read-create 2 3 STATUS current 4 DESCRIPTION 5 6 "The HT CSI number of beamformer antennas supported indicates the 7 maximum number of beamformer antennas the beamformee can support 8 when CSI feedback is required, set to 0 for single Tx antenna 9 sounding, set to 1 for 2 Tx antenna sounding, set to 2 for 3 Tx 10 11 antenna sounding, set to 3 for 4 Tx antenna sounding. See 12 7.3.2.56.6" 13 ::= { dot11RRMNeighborReportEntry 64 } 14 15 16 dot11RRMNeighborReportHTNonCompressedSteeringNumberofTransmitBeamformingAnt 17 ennasSuppt OBJECT-TYPE 18 19 SYNTAX Unsigned32 (0..3) 20 MAX-ACCESS read-create 21 22 STATUS current 23 DESCRIPTION 24 25 "The HT non-compressed steering number of beamformer antennas 26 supported indicates the maximum number of beamformer antennas the 27 beamformee can support when non-compressed beamforming feedback 28 29 matrix is required, set to 0 for single Tx antenna sounding, set to 30 1 for 2 Tx antenna sounding, set to 2 for 3 Tx antenna sounding, 31 set to 3 for 4 Tx antenna sounding. See 7.3.2.56.6" 32 33 ::= { dot11RRMNeighborReportEntry 65 } 34 35 36 dot11RRMNeighborReportHTCompressedSteeringNumberofTransmitBeamformingAntenn 37 asSuppt OBJECT-TYPE 38 SYNTAX Unsigned32 (0..3) 39 40 MAX-ACCESS read-create 41 STATUS current 42 43 DESCRIPTION 44 "The HT compressed steering number of beamformer antennas supported 45 46 indicates the maximum number of beam former antennas the beamformee 47 can support when compressed beamforming feedback matrix is 48 required, set to 0 for single Tx antenna sounding, set to 1 for 2 49 Tx antenna sounding, set to 2 for 3 Tx antenna sounding, set to 3 50 51 for 4 Tx antenna sounding. See 7.3.2.56.6" 52 ::= { dot11RRMNeighborReportEntry 66 } 53 54 55 dot11RRMNeighborReportHTCSIMaxNumberofRowsTransmitBeamformingSuppt OBJECT- 56 TYPE 57 58 SYNTAX Unsigned32 (0..3) 59 MAX-ACCESS read-create 60 61 STATUS current 62 DESCRIPTION 63 64 "The HT CSI max number o rows beamformer supported indicates the 65 maximum number of rows of CSI explicit feedback from the beamformee

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 or calibration responder or transmit ASEL responder that a 2 beamformer or calibration initiator or transmit ASEL initiator can 3 4 support when SCI feedback is required, set to 0 for a single row of 5 CSI, set to 1 for 2 rows of CSI, set to 2 for 3 rows of CSI, set to 6 3 for 4 rows of CSI. See 7.3.2.56.6" 7 8 ::= { dot11RRMNeighborReportEntry 67 } 9 10 dot11RRMNeighborReportHTTransmitBeamformingChannelEstimationCap OBJECT-TYPE 11 12 SYNTAX Unsigned32 (0..3) 13 MAX-ACCESS read-create 14 15 STATUS current 16 DESCRIPTION 17 18 "The HT channel estimation capability indicates the maximum number 19 of space time streams for which channel dimensions can be 20 simultaneously estimated when receiving an NDP sounding PPDU or the 21 extension portion of the HT long training fields in a staggered 22 23 sounding PPDU. Set to 0 for 1 space time stream, set to 1 for 2 24 space time streams, set to 2 for 3 space time streams, set to 3 for 25 4 space time streams. See 7.3.2.56.6" 26 27 ::= { dot11RRMNeighborReportEntry 68 } 28 29 30 dot11RRMNeighborReportHTAntSelectionCap OBJECT-TYPE 31 SYNTAX TruthValue 32 MAX-ACCESS read-create 33 34 STATUS current 35 DESCRIPTION 36 37 "The HT antenna selection capable indicates whether this STA 38 supports antenna selection, set to FALSE if not supported, set to 39 TRUE if supported. See 7.3.2.56.7" 40 41 ::= { dot11RRMNeighborReportEntry 69} 42 43 44 dot11RRMNeighborReportHTExplicitCSIFeedbackBasedTxASELCap OBJECT-TYPE 45 SYNTAX TruthValue 46 47 MAX-ACCESS read-create 48 STATUS current 49 50 DESCRIPTION 51 "The HT explicit CSI feedback based transmit antenna selection 52 capable indicates whether this STA has transmit antenna selection 53 capability based on explicit CSI feedback, set to FALSE if not 54 55 supported, set to TRUE if supported. See 7.3.2.56.7" 56 ::= { dot11RRMNeighborReportEntry 70 } 57 58 59 dot11RRMNeighborReportHTAntIndicesFeedbackBasedTxASELCap OBJECT-TYPE 60 61 SYNTAX TruthValue 62 MAX-ACCESS read-create 63 STATUS current 64 65 DESCRIPTION

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 "The HT antenna indices feedback based transmit antenna selection 2 capable indicates whether this STA has transmit antenna selection 3 4 capability based on antenna indices feedback, set to FALSE if not 5 supported, set to TRUE if supported. See 7.3.2.56.7" 6 ::= { dot11RRMNeighborReportEntry 71 } 7 8 9 dot11RRMNeighborReportHTExplicitCSIFeedbackBasedCap OBJECT-TYPE 10 11 SYNTAX TruthValue 12 MAX-ACCESS read-create 13 14 STATUS current 15 DESCRIPTION 16 17 "The explicit CSI feedback capable indicates whether this STA can 18 compute CSI and feedback in support of antenna selection, set to 19 FALSE if not supported, set to TRUE is supported. HT See 20 7.3.2.56.7" 21 22 ::= { dot11RRMNeighborReportEntry 72 } 23 24 25 dot11RRMNeighborReportHTAntIndicesFeedbackCap OBJECT-TYPE 26 SYNTAX TruthValue 27 28 MAX-ACCESS read-create 29 STATUS current 30 31 DESCRIPTION 32 "The HT antenna indices feedback capable indicates whether this STA 33 34 has Rx antenna selection capability, set to FALSE if not supported, 35 set to TRUE if supported. See 7.3.2.56.7" 36 ::= { dot11RRMNeighborReportEntry 73 } 37 38 39 dot11RRMNeighborReportHTRxASELCap OBJECT-TYPE 40 41 SYNTAX TruthValue 42 MAX-ACCESS read-create 43 44 STATUS current 45 DESCRIPTION 46 47 "The HT receive antenna selection capable indicates whether this 48 STA has Rx Antenna selection capability, set to FALSE if not 49 supported, set to TRUE if supported. See 7.3.2.56.7" 50 51 ::= { dot11RRMNeighborReportEntry 74 } 52 53 54 dot11RRMNeighborReportHTTxSoundingPPDUsCap OBJECT-TYPE 55 SYNTAX TruthValue 56 57 MAX-ACCESS read-create 58 STATUS current 59 60 DESCRIPTION 61 "The HT transmit sounding PPDUs capable indicates whether this STA 62 can transmit sounding PPDUs for antenna selection training per 63 64 request, set to FALSE if not supported, set to TRUE if supported. 65 See 7.3.2.56.7"

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 ::= { dot11RRMNeighborReportEntry 75 } 2 3 4 dot11RRMNeighborReportHTInfoPrimaryChannel OBJECT-TYPE 5 6 SYNTAX Integer 7 MAX-ACCESS read-create 8 STATUS current 9 10 DESCRIPTION 11 "The HT Info primary channel indicates the channel number of the 12 13 primary channel, encoding: channel number of the primary channel. 14 See 7.3.2.57” 15 ::= { dot11RRMNeighborReportEntry 76 } 16 17 18 19 20 dot11RRMNeighborReportHTInfoSecChannelOffset OBJECT-TYPE 21 SYNTAX Unsigned32 (0..3) 22 23 MAX-ACCESS read-create 24 STATUS current 25 26 DESCRIPTION 27 "The HT Info secondary channel offset indicates the offset of the 28 29 secondary channel relative to the primary channel, set to 1 if the 30 secondary channel is above the primary channel, set to 3 if the 31 secondary channel is below the primary channel, set to 0 if no 32 secondary channel is present. The value 2 is reserved. See 33 34 7.3.2.57" 35 ::= { dot11RRMNeighborReportEntry 77 } 36 37 38 dot11RRMNeighborReportHTInfoSTAChannelWidth OBJECT-TYPE 39 SYNTAX TruthValue 40 41 MAX-ACCESS read-create 42 STATUS current 43 44 DESCRIPTION 45 "The HT Info STA channel width defines the channel widths that may 46 47 be used to transmit to the STA, set to FALSE for a 20 MHz channel 48 width, set to TRUE allows use of any channel width in the supported 49 channel width set. See 7.3.2.57" 50 51 ::= { dot11RRMNeighborReportEntry 78 } 52 53 54 dot11RRMNeighborReportHTInfoRIFSMode OBJECT-TYPE 55 SYNTAX TruthValue 56 57 MAX-ACCESS read-create 58 STATUS current 59 DESCRIPTION 60 61 "The HT Info RIFS mode indicates whether use of RIFS is permitted 62 within the BSS, set to FALSE if use of RIFS is prohibited, set to 63 TRUE if use of RIFS is permitted. See 7.3.2.57" 64 65 ::= { dot11RRMNeighborReportEntry 79}

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 2 3 dot11RRMNeighborReportHTInfoProtection OBJECT-TYPE 4 SYNTAX Unsigned32 (0..3) 5 6 MAX-ACCESS read-create 7 STATUS current 8 9 DESCRIPTION 10 "The HT Info protection indicates protection requirements of HT 11 transmissions, Set to 0 if: All STAs detected in the primary or the 12 13 secondary channel or that are a member of this BSS are HT STAs. And 14 either: all STAs that are known by the transmitting STA to be a 15 member of this BSS are 20/40 MHz HT in a 20/40 MHz BSS or this BSS 16 is a 20 MHz BSS, Set to 1 (non-member protection mode) if: there is 17 18 at least one non-HT STA detected in either the primary or the 19 secondary channel or in both the primary and secondary channels, 20 that is not known by the transmitting 21 22 STA to be a member of this BSS and all STAs that are known by the 23 transmitting STA to be a member of this BSS are HT STA, Set to 2 24 if: All STAs detected in the primary or the secondary channel or 25 26 that are known by the transmitting STA to be a member of this BSS 27 are HT STA and this BSS is a 20/40 MHz BSS and there is at least 28 one 20 MHz HT STA associated with this BSS, Set to 3 (non-HT mixed 29 mode) otherwise. See 7.3.2.56.2" 30 31 ::= { dot11RRMNeighborReportEntry 80 } 32 33 34 dot11RRMNeighborReportHTInfoNonGreenfieldHTSTAsPresent OBJECT-TYPE 35 SYNTAX TruthValue 36 37 MAX-ACCESS read-create 38 STATUS current 39 40 DESCRIPTION 41 "The HT Info non-greenfield HT STAs present, indicates if any HT 42 43 STAs that are not HT-greenfield capable have associated. Determines 44 when a non-AP STA should use HT-greenfield protection. Present in 45 Beacon and Probe response frames transmitted by an AP. Set to FALSE 46 if all HT STAs that are associated are HT-greenfield capable, set 47 48 to TRUE if one or more HT STAs that are not HT-greenfield capable 49 are associated. See 7.3.2.57" 50 ::= { dot11RRMNeighborReportEntry 81 } 51 52 53 54 dot11RRMNeighborReportHTInfoOBSSNonHTSTAsPresent OBJECT-TYPE 55 SYNTAX TruthValue 56 57 MAX-ACCESS read-create 58 STATUS current 59 60 DESCRIPTION 61 "The HT Info OBSS non-HT STAs present indicates if the use of 62 protection for non-HT STAs by overlapping BSSs is determined to be 63 64 desirable. Present in Beacon and Probe response frames transmitted 65 by an AP, set to TRUE if the use of protection for non-HT STAs by

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 overlapping BSSs is determined to be desirable, set to FALSE 2 otherwise. See 7.3.2.57" 3 4 ::= { dot11RRMNeighborReportEntry 82 } 5 6 7 dot11RRMNeighborReportHTInfoDualBeacon OBJECT-TYPE 8 SYNTAX TruthValue 9 10 MAX-ACCESS read-create 11 STATUS current 12 13 DESCRIPTION 14 "The HT Info dual beacon indicates whether the AP transmits an STBC 15 beacon, set to FALSE if no STBC beacon is transmitted, set to TRUE 16 17 if an STBC beacon is transmitted. See 7.3.2.57" 18 ::= { dot11RRMNeighborReportEntry 83 } 19 20 21 dot11RRMNeighborReportHTInfoDualCTSProtection OBJECT-TYPE 22 23 SYNTAX TruthValue 24 MAX-ACCESS read-create 25 26 STATUS current 27 DESCRIPTION 28 29 "The HT Info dual CTS protection is used by the AP to set a NAV at 30 STAs that do not support STBC and at STAs that can associate solely 31 through the secondary beacon, set to FALSE if Dual CTS protection 32 is not required, set to TRUE if Dual CTS protection is required. 33 34 See 7.3.2.57" 35 ::= { dot11RRMNeighborReportEntry 84 } 36 37 38 dot11RRMNeighborReportHTInfoSTBCBeacon OBJECT-TYPE 39 40 SYNTAX TruthValue 41 MAX-ACCESS read-create 42 43 STATUS current 44 DESCRIPTION 45 46 "The HT Info STBC beacon indicates whether the beacon containing 47 this element is a primary or a STBC beacon, set to FALSE in a 48 primary beacon, set to TRUE in a STBC beacon. See 7.3.2.57" 49 50 ::= { dot11RRMNeighborReportEntry 85 } 51 52 dot11RRMNeighborReportHTInfoLSIGTXOPProtectionSup OBJECT-TYPE 53 54 SYNTAX TruthValue 55 MAX-ACCESS read-create 56 57 STATUS current 58 DESCRIPTION 59 60 "The HT Info L-SIG TXOP protection full support indicates whether 61 all HT STA in the BSS support L-SIG TXOP protection, set to FALSE 62 if one or more HT STA in the BSS do not support L-SIG TXOP 63 64 protection, set to TRUE if all HT STA in the BSS support L-SIG TXOP 65 protection. See 7.3.2.57"

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 ::= { dot11RRMNeighborReportEntry 86 } 2 3 4 dot11RRMNeighborReportHTInfoPCOActive OBJECT-TYPE 5 6 SYNTAX TruthValue 7 MAX-ACCESS read-create 8 9 STATUS current 10 DESCRIPTION 11 "The HT Info PCO active indicates whether PCO is active in the BSS, 12 13 set to FALSE if PCO is not active in the BSS, set to TRUE if PCO is 14 active in the BSS. See 7.3.2.57" 15 ::= { dot11RRMNeighborReportEntry 87} 16 17 18 dot11RRMNeighborReportHTInfoPCOPhase OBJECT-TYPE 19 20 SYNTAX TruthValue 21 MAX-ACCESS read-create 22 23 STATUS current 24 DESCRIPTION 25 26 "The HT Info PCO phase indicates the PCO phase of operation, set to 27 FALSE indicates a switch to or continued 20 MHz phase, set to TRUE 28 indicates a switch to or continuation of 40 MHz phase. See 29 30 7.3.2.57" 31 ::= { dot11RRMNeighborReportEntry 88 } 32 33 34 dot11RRMNeighborReportHTInfoBasicMCSSet OBJECT-TYPE 35 36 SYNTAX Unsigned32 37 MAX-ACCESS read-create 38 39 STATUS current 40 DESCRIPTION 41 42 "The HT Info Basic MCS Set indicates values that are supported by 43 all HT STAs in the BSS. The Basic MSC Set is a bitmap of size 128 44 bits. Bit 0 corresponds to MCS 0. A bit is set to 1 to indicate 45 support for that MCS, set to 0 otherwise. See 7.3.2.57" 46 47 ::= { dot11RRMNeighborReportEntry 89 } 48 49 50 dot11RRMNeighborReportHTSecChannelOffset OBJECT-TYPE 51 SYNTAX Unsigned32 (0..3) 52 53 MAX-ACCESS read-create 54 STATUS current 55 56 DESCRIPTION 57 "The HT secondary channel offset indicates the position of the 58 secondary channel relative to the primary channel, set to 1 to 59 60 indicate that the secondary channel is above the primary channel, 61 set to 3 to indicate the secondary channel is below the primary 62 channel, set to 0 to indicate that no secondary channel is present. 63 The value 2 is reserved. See 7.3.2.20a" 64 65 ::= { dot11RRMNeighborReportEntry 90 }

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 2 3 dot11RRMNeighborReportExtCapPSMPSupport OBJECT-TYPE 4 SYNTAX TruthValue 5 6 MAX-ACCESS read-create 7 STATUS current 8 DESCRIPTION 9 10 "The Extended Capabilities PSMP support indicates support for PSMP 11 operation, set to FALSE if PSMP is not supported, set to TRUE if 12 PSMP operation is supported. See 7.3.2.27" 13 14 ::= { dot11RRMNeighborReportEntry 91 } 15 16 17 dot11RRMNeighborReportExtCapSPSMPSup OBJECT-TYPE 18 SYNTAX TruthValue 19 20 MAX-ACCESS read-create 21 STATUS current 22 23 DESCRIPTION 24 "The HT Info S-PSMP support indicates support for scheduled PSMP, 25 set to FALSE when PSMP is supported is set to FALSE and when PSMP 26 27 support is set to 1 if the STA does not support S-PSMP, set to TRUE 28 when PSMP support is set to 1 if the STA supports S-PSMP. See 29 7.3.2.27" 30 31 ::= { dot11RRMNeighborReportEntry 92 } 32 33 34 dot11RRMNeighborReportExtCapServiceIntervalGranularity OBJECT-TYPE 35 SYNTAX Unsigned32 (0..7) 36 37 MAX-ACCESS read-create 38 STATUS current 39 40 DESCRIPTION 41 "The Extended Capabilities service interval granularity indicates 42 the duration of the shortest service interval, set to 0 for 5 ms, 43 44 set to 1 for 10 ms, set to 2 for 15 ms, set to 3 for 20 ms, set to 45 4 for 25 ms, set to 5 for 30 ms, set to 6 for 35 ms, set to 7 for 46 40 ms. See 7.3.2.27" 47 48 ::= { dot11RRMNeighborReportEntry 93 } 49 50 Change the dot11SMTRRMConfig object group as follows: 51 52 dot11SMTRRMConfig OBJECT-GROUP 53 OBJECTS { dot11APChannelReportIndex, 54 55 dot11APChannelReportIfIndex, 56 dot11APChannelReportRegulatoryClass, 57 58 dot11APChannelReportChannelList, 59 dot11RRMNeighborReportIndex, 60 dot11RRMNeighborReportIfIndex, 61 62 dot11RRMNeighborReportBSSID, 63 dot11RRMNeighborReportReachability, 64 65 dot11RRMNeighborReportSecurity,

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 dot11RRMNeighborReportCapSpectrumMgmt, 2 3 dot11RRMNeighborReportCapQoS, 4 dot11RRMNeighborReportCapAPSD, 5 dot11RRMNeighborReportCapRRM, 6 7 dot11RRMNeighborReportCapDelayBlockAck, 8 dot11RRMNeighborReportCapImmediateBlockAck, 9 10 dot11RRMNeighborReportKeyScope, 11 dot11RRMNeighborReportChannelNumber, 12 13 dot11RRMNeighborReportRegulatoryClass, 14 dot11RRMNeighborReportPhyType, 15 16 dot11RRMNeighborReportNeighborTSFInfo, 17 dot11RRMNeighborReportPilotPeriod, 18 dot11RRMNeighborReportPilotMultipleBSSID, 19 20 dot11RRMNeighborReportRRMEnabledCapabilities, 21 dot11RRMNeighborReportVendorSpecific, 22 23 dot11RRMNeighborReportRowStatus, } 24 dot11RRMNeighborReportCapHT, 25 26 dot11RRMNeighborReportHTLDPCCodingCap, 27 dot11RRMNeighborReportHTSupportedChannelWidthSet, 28 29 dot11RRMNeighborReportHTSMPowerSave, 30 dot11RRMNeighborReportHTGreenfield, 31 32 dot11RRMNeighborReportHTShortGIfor20MHz, 33 dot11RRMNeighborReportHTShortGIfor40MHz, 34 dot11RRMNeighborReportHTTxSTBC, 35 36 dot11RRMNeighborReportHTRxSTBC, 37 dot11RRMNeighborReportHTDelayedBlockAck, 38 39 dot11RRMNeighborReportHTMaxAMSDULength, 40 dot11RRMNeighborReportHTDSSCCKModein40MHz, 41 42 dot11RRMNeighborReportHTFortyMHzIntolerant, 43 dot11RRMNeighborReportHTLSIGTXOPProtectionSupport, 44 45 dot11RRMNeighborReportHTMaxAMPDULengthExponent, 46 dot11RRMNeighborReportHTMinMPDUStartSpacing, 47 48 dot11RRMNeighborReportHTRxMCSBitMask, 49 dot11RRMNeighborReportHTRxHighestSupportedDataRate, 50 dot11RRMNeighborReportHTTxMCSSetDefined, 51 52 dot11RRMNeighborReportHTTxRxMCSSetNotEqual, 53 dot11RRMNeighborReportHTTxMaxNumberSpatialStreamsSupported, 54 55 dot11RRMNeighborReportHTTxUnequalModulationSupported, 56 dot11RRMNeighborReportHTPCO, 57 58 dot11RRMNeighborReportHTPCOTransitionTime, 59 dot11RRMNeighborReportHTMCSFeedback, 60 61 dot11RRMNeighborReportHTCSupport, 62 dot11RRMNeighborReportHTRDResponder, 63 dot11RRMNeighborReportHTImplictTransmitBeamformingReceivingCap, 64 65 dot11RRMNeighborReportHTReceiveStaggeredSoundingCap,

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 dot11RRMNeighborReportHTTransmitStaggeredSoundingCap, 2 3 dot11RRMNeighborReportHTReceiveNDPCap, 4 dot11RRMNeighborReportHTTransmitNDPCap, 5 6 dot11RRMNeighborReportHTImplicitTransmitBeamformingCap, 7 dot11RRMNeighborReportHTTransmitBeamformingCalibration, 8 dot11RRMNeighborReportHTExplicitCSITransmitBeamformingCap, 9 10 dot11RRMNeighborReportHTExplicitNonCompressedSteeringCap, 11 dot11RRMNeighborReportHTExplicitCompressedSteeringCap, 12 13 dot11RRMNeighborReportHTExplicitTransmitBeamformingFeedback, 14 dot11RRMNeighborReportHTExplicitNonCompressedBeamformingFeedbackCap, 15 dot11RRMNeighborReportHTExplicitCompressedBeamformingFeedbackCap, 16 17 dot11RRMNeighborReportHTTransmitBeamformingMinimalGrouping, 18 dot11RRMNeighborReportHTCSINumberofTransmitBeamformingAntennasSuppt, 19 dot11RRMNeighborReportHTNonCompressedSteeringNumberofTransmitBeamform 20 ingAntennasSuppt, 21 dot11RRMNeighborReportHTCompressedSteeringNumberofTransmitBeamforming 22 23 AntennasSuppt, 24 dot11RRMNeighborReportHTCSIMaxNumberofRowsTransmitBeamformingSuppt, 25 dot11RRMNeighborReportHTTransmitBeamformingChannelEstimationCap, 26 27 dot11RRMNeighborReportHTAntSelectionCap, 28 dot11RRMNeighborReportHTExplicitCSIFeedbackBasedTxASELCap, 29 30 dot11RRMNeighborReportHTAntIndicesFeedbackBasedTxASELCap, 31 dot11RRMNeighborReportHTExplicitCSIFeedbackBasedCap, 32 dot11RRMNeighborReportHTAntIndicesFeedbackCap, 33 34 dot11RRMNeighborReportHTRxASELCap, 35 dot11RRMNeighborReportHTTxSoundingPPDUsCap, 36 37 dot11RRMNeighborReportHTInfoPrimaryChannel, 38 dot11RRMNeighborReportHTInfoSecChannelOffset, 39 40 dot11RRMNeighborReportHTInfoSTAChannelWidth, 41 dot11RRMNeighborReportHTInfoRIFSMode, 42 43 dot11RRMNeighborReportHTInfoProtection, 44 dot11RRMNeighborReportHTInfoNonGreenfieldHTSTAsPresent, 45 46 dot11RRMNeighborReportHTInfoOBSSNonHTSTAsPresent, 47 dot11RRMNeighborReportHTInfoDualBeacon, 48 49 dot11RRMNeighborReportHTInfoDualCTSProtection, 50 dot11RRMNeighborReportHTInfoSTBCBeacon, 51 52 dot11RRMNeighborReportHTInfoLSIGTXOPProtectionSup, 53 dot11RRMNeighborReportHTInfoPCOActive, 54 55 dot11RRMNeighborReportHTInfoPCOPhase, 56 dot11RRMNeighborReportHTInfoBasicMCSSet, 57 58 dot11RRMNeighborReportHTSecChannelOffset, 59 dot11RRMNeighborReportExtCapPSMPSupport, 60 61 dot11RRMNeighborReportExtCapSPSMPSup, 62 dot11RRMNeighborReportExtCapServiceIntervalGranularity 63 } 64 65 STATUS current

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 DESCRIPTION 2 3 "The SMTRRMConfig package is a set of attributes that shall be 4 present if the STA supports the Radio Measurement service." 5 ::= { dot11Groups 39 } 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Annex R (normative) HT LDPC matrix definitions 2 3 4 Table R.1 defines the Matrix prototypes of the parity-check matrices for a codeword block length n=648 bits, 5 with a subblock size z=27 bits. 6 7 8 Table R.1—Matrix prototypes for codeword block length n=648 bits, subblock size is Z = 27 9 10 bits. 11 12 13 (a) Coding rate R= 1/2. 14 0 - - - 0 0 - - 0 - - 0 1 0 ------15 22 0 - - 17 - 0 0 12 - - - - 0 0 ------16 6 - 0 - 10 - - - 24 - 0 - - - 0 0 ------17 2 - - 0 20 - - - 25 0 - - - - - 0 0 ------18 19 23 - - - 3 - - - 0 - 9 11 - - - - 0 0 ------20 24 - 23 1 17 - 3 - 10 ------0 0 - - - - - 21 25 - - - 8 - - - 7 18 - - 0 - - - - - 0 0 - - - - 22 13 24 - - 0 - 8 - 6 ------0 0 - - - 23 7 20 - 16 22 10 - - 23 ------0 0 - - 24 11 - - - 19 - - - 13 - 3 17 ------0 0 - 25 26 25 - 8 - 23 18 - 14 9 ------0 0 27 3 - - - 16 - - 2 25 5 - - 1 ------0 28 29 (b) Coding rate R= 2/3. 30 25 26 14 - 20 - 2 - 4 - - 8 - 16 - 18 1 0 ------31 10 9 15 11 - 0 - 1 - - 18 - 8 - 10 - - 0 0 - - - - - 32 16 2 20 26 21 - 6 - 1 26 - 7 ------0 0 - - - - 33 10 13 5 0 - 3 - 7 - - 26 - - 13 - 16 - - - 0 0 - - - 34 35 23 14 24 - 12 - 19 - 17 - - - 20 - 21 - 0 - - - 0 0 - - 36 6 22 9 20 - 25 - 17 - 8 - 14 - 18 ------0 0 - 37 14 23 21 11 20 - 24 - 18 - 19 - - - - 22 ------0 0 38 17 11 11 20 - 21 - 26 - 3 - - 18 - 26 - 1 ------0 39 40 (c) Coding rate R= 3/4. 41 16 17 22 24 9 3 14 - 4 2 7 - 26 - 2 - 21 - 1 0 - - - - 42 43 25 12 12 3 3 26 6 21 - 15 22 - 15 - 4 - - 16 - 0 0 - - - 44 25 18 26 16 22 23 9 - 0 - 4 - 4 - 8 23 11 - - - 0 0 - - 45 9 7 0 1 17 - - 7 3 - 3 23 - 16 - - 21 - 0 - - 0 0 - 46 24 5 26 7 1 - - 15 24 15 - 8 - 13 - 13 - 11 - - - - 0 0 47 2 2 19 14 24 1 15 19 - 21 - 2 - 24 - 3 - 2 1 - - - - 0 48 49 (d) Coding rate R= 5/6. 50 51 17 13 8 21 9 3 18 12 10 0 4 15 19 2 5 10 26 19 13 13 1 0 - - 52 3 12 11 14 11 25 5 18 0 9 2 26 26 10 24 7 14 20 4 2 - 0 0 - 53 22 16 4 3 10 21 12 5 21 14 19 5 - 8 5 18 11 5 5 15 0 - 0 0 54 7 7 14 14 4 16 16 24 24 10 1 7 15 6 10 26 8 18 21 14 1 - - 0 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table R.2 defines the Matrix prototypes of the parity-check matrices for a codeword block length 2 3 n=1296 bits, with a subblock size z=54 bits. 4 5 6 Table R.2—Matrix prototypes for codeword block length n=1296 bits, subblock size is Z= 54 7 bits. 8 9 10 (a) Coding rate R= 1/2. 11 12 40 - - - 22 - 49 23 43 - - - 1 0 ------13 50 1 - - 48 35 - - 13 - 30 - - 0 0 ------14 39 50 - - 4 - 2 - - - - 49 - - 0 0 ------15 33 - - 38 37 - - 4 1 ------0 0 ------16 45 - - - 0 22 - - 20 42 ------0 0 ------17 51 - - 48 35 - - - 44 - 18 ------0 0 - - - - - 18 19 47 11 - - - 17 - - 51 - - - 0 - - - - - 0 0 - - - - 20 5 - 25 - 6 - 45 - 13 40 ------0 0 - - - 21 33 - - 34 24 - - - 23 - - 46 ------0 0 - - 22 1 - 27 - 1 - - - 38 - 44 ------0 0 - 23 - 18 - - 23 - - 8 0 35 ------0 0 24 49 - 17 - 30 - - - 34 - - 19 1 ------0 25 26 (b) Coding rate R= 2/3. 27 28 39 31 22 43 - 40 4 - 11 - - 50 - - - 6 1 0 ------29 25 52 41 2 6 - 14 - 34 - - - 24 - 37 - - 0 0 - - - - - 30 43 31 29 0 21 - 28 - - 2 - - 7 - 17 - - - 0 0 - - - - 31 20 33 48 - 4 13 - 26 - - 22 - - 46 42 - - - - 0 0 - - - 32 45 7 18 51 12 25 - - - 50 - - 5 - - - 0 - - - 0 0 - - 33 35 40 32 16 5 - - 18 - - 43 51 - 32 ------0 0 - 34 35 9 24 13 22 28 - - 37 - - 25 - - 52 - 13 ------0 0 36 32 22 4 21 16 - - - 27 28 - 38 - - - 8 1 ------0 37 38 (c) Coding rate R= 3/4. 39 39 40 51 41 3 29 8 36 - 14 - 6 - 33 - 11 - 4 1 0 - - - - 40 48 21 47 9 48 35 51 - 38 - 28 - 34 - 50 - 50 - - 0 0 - - - 41 30 39 28 42 50 39 5 17 - 6 - 18 - 20 - 15 - 40 - - 0 0 - - 42 43 29 0 1 43 36 30 47 - 49 - 47 - 3 - 35 - 34 - 0 - - 0 0 - 44 1 32 11 23 10 44 12 7 - 48 - 4 - 9 - 17 - 16 - - - - 0 0 45 13 7 15 47 23 16 47 - 43 - 29 - 52 - 2 - 53 - 1 - - - - 0 46 47 (d) Coding rate R= 5/6. 48 48 29 37 52 2 16 6 14 53 31 34 5 18 42 53 31 45 - 46 52 1 0 - - 49 17 4 30 7 43 11 24 6 14 21 6 39 17 40 47 7 15 41 19 - - 0 0 - 50 51 7 2 51 31 46 23 16 11 53 40 10 7 46 53 33 35 - 25 35 38 0 - 0 0 52 19 48 41 1 10 7 36 47 5 29 52 52 31 10 26 6 3 2 - 51 1 - - 0 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table R.3defines the Matrix prototypes of the parity-check matrices for a codeword block length n=1944 bits, 2 with a subblock size z=81 bits. 3 4 5 6 Table R.3—Matrix prototypes for codeword block length n=1944 bits, subblock size is Z = 7 81 bits. 8 9 10 (a) Coding rate R= 1/2. 11 57 - - - 50 - 11 - 50 - 79 - 1 0 ------12 3 - 28 - 0 - - - 55 7 - - - 0 0 ------13 14 30 - - - 24 37 - - 56 14 - - - - 0 0 ------15 62 53 - - 53 - - 3 35 ------0 0 ------16 40 - - 20 66 - - 22 28 ------0 0 ------17 0 - - - 8 - 42 - 50 - - 8 - - - - - 0 0 - - - - - 18 69 79 79 - - - 56 - 52 - - - 0 - - - - - 0 0 - - - - 19 65 - - - 38 57 - - 72 - 27 ------0 0 - - - 20 64 - - - 14 52 - - 30 - - 32 ------0 0 - - 21 22 - 45 - 70 0 - - - 77 9 ------0 0 - 23 2 56 - 57 35 - - - - - 12 ------0 0 24 24 - 61 - 60 - - 27 51 - - 16 1 ------0 25 26 (b) Coding rate R= 2/3. 27 61 75 4 63 56 ------8 - 2 17 25 1 0 ------28 56 74 77 20 - - - 64 24 4 67 - 7 - - - - 0 0 - - - - - 29 30 28 21 68 10 7 14 65 - - - 23 - - - 75 - - - 0 0 - - - - 31 48 38 43 78 76 - - - - 5 36 - 15 72 - - - - - 0 0 - - - 32 40 2 53 25 - 52 62 - 20 - - 44 - - - - 0 - - - 0 0 - - 33 69 23 64 10 22 - 21 - - - - - 68 23 29 ------0 0 - 34 12 0 68 20 55 61 - 40 - - - 52 - - - 44 ------0 0 35 58 8 34 64 78 - - 11 78 24 - - - - - 58 1 ------0 36 37 (c) Coding rate R= 3/4. 38 39 48 29 28 39 9 61 - - - 63 45 80 - - - 37 32 22 1 0 - - - - 40 4 49 42 48 11 30 - - - 49 17 41 37 15 - 54 - - - 0 0 - - - 41 35 76 78 51 37 35 21 - 17 64 - - - 59 7 - - 32 - - 0 0 - - 42 9 65 44 9 54 56 73 34 42 - - - 35 - - - 46 39 0 - - 0 0 - 43 3 62 7 80 68 26 - 80 55 - 36 - 26 - 9 - 72 - - - - - 0 0 44 26 75 33 21 69 59 3 38 - - - 35 - 62 36 26 - - 1 - - - - 0 45 46 47 (d) Coding rate R= 5/6. 48 13 48 80 66 4 74 7 30 76 52 37 60 - 49 73 31 74 73 23 - 1 0 - - 49 69 63 74 56 64 77 57 65 6 16 51 - 64 - 68 9 48 62 54 27 - 0 0 - 50 51 15 0 80 24 25 42 54 44 71 71 9 67 35 - 58 - 29 - 53 0 - 0 0 51 16 29 36 41 44 56 59 37 50 24 - 65 4 65 52 - 4 - 73 52 1 - - 0 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Insert the following Annex S: 2 3 4 5 Annex S(informative) Frame exchange sequences 6 7 EDITORIAL NOTE—Editing instructions in 9.12 move that subclause into this informative annex. 8 9 Editing instructions in this Annex assume that this repositioning has taken place. 10 11 Change the first paragraph of Annex S as follows: 12 13 The allowable frame exchange sequences are defined using an extension of the EBNF format as defined in 14 ISO/IEC 14977: 1996(E)[B27a]. The elements of this syntax that are used here are: 15 16 — [a] = a is optional 17 — {a} = a is repeated zero or more times 18 19 — n{a} = a is repeated n or more times. For example, 3{a} requires 3 or more “a”. This notation is an 20 extension to ISO/IEC 14977, and equivalent to n*a{a} as defined in that standard. 21 22 —a|b = a or b a|b|c|... = selection between mutually exclusive alternatives, a, b, c ... 23 — () = grouping, so “a (b|c)” is equivalent to “a b | a c” 24 25 — (* a *) = “a” is a comment. Comments are placed before the text they relate to. 26 — <> = order of frames not relevante.g.. For example, is either “a b” or “b a” 27 28 — A rule is terminated by a semicolon “;” 29 — Whitespace is not significant, but it is used to highlight the nesting of grouped terms.The meaning of 30 whitespace is changed from ISO/IEC 14977 - terminals do not contain whitespace, and the concate- 31 32 nate-symbol (comma in ISO/IEC 14977) is replaced by white space. Whitespace appearing between 33 terminals indicates concatenation. Otherwise, whitespace is not significant, and is used to highlight 34 the nesting of grouped terms. 35 36 Change the second paragraph of Annex S as follows: 37 38 39 Two types of terminals are defined: 40 — Frames. A frame is shown in Bold, and identified by its type/subtype. For example, Beacon and 41 Data. Frames are shown in an initial capital letter. 42 43 — Attributes. Attributes are shown in italic. An attribute is introduced by the “+” character. The 44 attribute specifies a condition that applies to the frame that precedes it. Where there are multiple 45 attributes applied, they are generally ordered in the same order of the fields in the frame they refer to. 46 The syntax a+(b|c) where b and c are attributes is equivalent to (a+b) | (a+c). 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Change Table 9-6 renumbered to Table S.1 as follows: 2 3 4 Table S.1—Attributes applicable to frame exchange sequence definition 5 6 7 Attribute Description 8 9 a-mpdu Frame is part of an A-MPDU aggregate 10 11 a-mpdu-end Frame is the last frame in an A-MPDU aggregate 12 13 block-ack QoS Ddata frame has Ack Policy set to Block Ack 14 15 broadcast Frame RA is the broadcast address 16 17 CF Beacon contains a CFP element 18 CF-Ack Data type CF-Ack subtype bit set to 1 or CF-End+CF-Ack frame 19 20 CF-Poll Data type CF-Poll subtype bit set to 1 21 22 csi An Action frame carrying channel state feedback (either channel state 23 information, uncompressed or compressed beamforming matrices). 24 25 csi-request A +HTC frame with the Feedback Request field set to a value > 0 26 27 delayed BlockAck or BlockAckReq under a delayed policy 28 delayed-no-ack BlockAck or BlockAckReq frame has No Ack Ack Policy 29 30 DTIM Beacon is a DTIM 31 32 frag Frame has its More Fragments field set to 1 33 34 group Frame RA has Individual/Group bit set to 1 35 36 HTC +HTC frame, i.e., a frame that contains the HT Control field, including 37 the Control Wrapper frame. See NOTE. 38 implicit-bar QoS data frame in an A-MPDU with Normal Ack Ack Policy 39 40 individual Frame RA has i/g bit set to 0 41 42 last Frame has its More Fragments field set to 0 43 44 L-sig L-sig duration not equal to PPDU duration 45 46 action-no-ack Management frame of subtype Action No Ack 47 mfb A +HTC frame with the MFB field is not set to all ones 48 49 more-psmp A PSMP frame with the More PSMP field set to 1 50 51 mrq A +HTC frame with the MRQ field set to 1 52 53 ndp-announce A +HTC frame with the NDP Announcement field set to 1 54 55 no-ack QoS Ddata frame has Ack Policy set to No Ack 56 no-more-psmp A PSMP frame with the More PSMP field set to 0 57 58 normal-ack QoS Ddata frame has Ack Policy set to Normal Ack 59 60 non-QAP Frame is transmitted by a non-AP QoS STA 61 62 non-stbc PPDU TXVECTOR STBC parameter is set to 0 63 64 null Data type Null Data subtype bit set 65

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 Table S.1—Attributes applicable to frame exchange sequence definition (continued) 2 3 4 Attribute Description 5 6 pifs Frame is transmitted usingfollowing a PIFS 7 8 psmp-ack Ack Policy of QoS data frame is set to PSMP Ack 9 10 QAP Frame is transmitted by a QoS AP 11 QoS Data type QoS subtype bit set 12 13 RD Frame includes an HT control field in which the RDG/More PPDU 14 subfield is set to 1 15 16 self Frame RA = TA 17 18 sounding PPDU TXVECTOR SOUNDING parameter present and set to 19 SOUNDING 20 21 stbc PPDU TXVECTOR STBC parameter is set to a value >0 22 to-ap Frame is addressed to the AP 23 24 trq Frame is a +HTC frame with the TRQ field set to 1 25 26 NOTE—A control frame that contains the HT Control field is always transmitted using 27 the control wrapper frame. 28 29 30 31 Change the txop-sequence term in Annex S as follows: 32 33 (* A TXOP (either polled or EDCA) may be filled with txop-sequences, which are initiated by the TXOP 34 holder. *) 35 txop-sequence = (((RTS CTS) | CTS+self) Data+individual+QoS+(block-ack|no-ack)) | 36 37 [RTS CTS] (txop-part-requiring-ack txop-part-providing-ack) | 38 [RTS CTS] (Management|(Data+QAP))+individual Ack | 39 [RTS CTS] (BlockAckReq BlockAck) | 40 ht-txop-sequence; 41 42 43 44 Delete the term poll-sequence from Annex S as follows: 45 46 (* A poll-sequence is the start of a polled TXOP, in which the HC delivers a polled TXOP to a STA. The poll 47 may or may not piggyback a CF-Ack according to whether the previous frame received by the HC was a Data 48 frame. *) 49 50 poll-sequence = non-cf-ack-piggybacked-qos-poll-sequence | 51 cf-ack-piggybacked-qos-poll-sequence; 52 53 Change the term txop-part-requiring-ack in Annex S as follows: 54 55 (* These frames require acknowledgement *) 56 txop-part-requiring-ack = Data+individual[+null] | 57 Data+individual[+null]+QoS+normal-ack | 58 BlockAckReq+delayed | 59 60 BlockAck+delayed; 61 62 Change the term txop-part-providing-ack in Annex S as follows: 63 64 (* These frames provide acknowledgement to the TXOP-part-requiring-ack *) 65 txop-part-providing-ack= Ack |

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 2 (* An HC responds with a new polled TXOP on expiry of current TXOP *) 3 cf-ack-piggybacked-qos-poll-sequence | 4 5 6 (* An HC responds with CF-Ack and its own data on expiry of TXOP *) 7 cf-ack-piggybacked-qos-data-sequence | 8 Data+CF-Ack; 9 10 Insert the following paragraphs after the term starting “cf-ack-piggybacked-qos-data-sequence” in 11 12 Annex S: 13 14 (* The ht-txop-sequencedescribes the additional sequences that may be initiated by an HT STA that is the 15 holder of a TXOP *) 16 17 ht-txop-sequence = L-sig-protected-sequence | 18 ht-nav-protected-sequence | 19 dual-cts-protected-sequence | 20 1{initiator-sequence}; 21 22 23 (* an L-sig-protected-sequence is a sequence protected using the L-sig TXOP protection feature *) 24 L-sig-protected-sequence = L-sig-protection-set 1{initiator-sequence} resync-sequence; 25 26 (* an ht-nav-protected sequence consists of setting the NAV, performing one or more initiator-sequences and 27 then resetting the NAV if time permits *) 28 29 ht-nav-protected-sequence = nav-set 1{initiator-sequence} [resync-sequence] ; 30 31 (* a dual-cts-protected-sequence is a sequence protected using the dual CTS protection feature *) 32 dual-cts-protected-sequence = dual-cts-nav-set 1{initiator-sequence} [dual-cts-nav-reset]; 33 34 35 (* a dual-cts-nav-set is an initial exchange that establishes NAV protection using dual CTS protection. 36 dual-cts-nav-set = (* A dual CTS initiated by a non-AP HT STA that is not STBC capable, preceded 37 by an optional CTS frame addressed to the AP. *) 38 ( 39 [ CTS+to-ap+non-stbc+non-QAP ] 40 41 RTS+non-stbc+non-QAP 42 CTS+non-stbc+QAP 43 [ CTS+stbc+pifs+QAP ] 44 ) | 45 46 47 (* A dual CTS initiated by a non-AP STA that is STBC capable, preceded by an 48 optional CTS frame addressed to the AP. *) 49 ( 50 [ CTS+to-ap+stbc+non-QAP ] 51 52 RTS+stbc+non-QAP 53 CTS+stbc+QAP 54 CTS+non-stbc+QAP 55 ) | 56 57 58 (* An STBC initiator-sequence (i.e., containing STBC PPDUs) transmitted by 59 the AP is protected by non-STBC CTS to self *) 60 (CTS+self+non-stbc+QAP) | 61 62 (* A non-STBC initiator-sequence transmitted by the AP is protected by STBC 63 64 CTS to self *) 65 (CTS+self+stbc+QAP);

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 2 (* a dual-cts-nav-reset resets the NAV in the vicinity of the transmitting non-AP STA, and resets the NAV 3 of both STBC and non-STBC-capable STA in the vicinity of the AP *) 4 5 dual-cts-nav-reset = [CF-End+non-QAP] CF-End+stbc+QAP CF-End+non-stbc+QAP); 6 7 8 (* an ma-no-ack-htc represents a Management Action No Ack + HTC frame *) 9 ma-no-ack-htc = Management+action-no-ack+HTC; 10 11 12 (* This is the sequence of frames that establish protection using the L-sig TXOP protection method *) 13 L-sig-protection-set = (RTS+L-sig[+HTC] CTS+L-sig[+HTC]) | 14 (Data+individual+L-sig [+HTC][+null][+QoS+normal-ack] Ack [+HTC] +L- 15 sig) | 16 17 ( 1{ Data+L-sig[+HTC]+individual+QoS+implicit-bar+a-mpdu}+a-mpdu-end 18 BlockAck+L-sig[+HTC] 19 ) | 20 (BlockAckReq+L-sig[+HTC] (BlockAck[+HTC]|Ack[+HTC])+L-sig) | 21 (BlockAck+L-sig[+HTC] Ack[+HTC])+L-sig); 22 23 24 (* These are the series of frames that establish NAV protection for an HT sequence *) 25 nav-set = (RTS[+HTC] CTS[+HTC]) | 26 CTS+self | 27 28 (Data[+HTC]+individual[+null][+QoS+normal-ack] Ack) | 29 Data[+HTC]+individual[+QoS+(block-ack)] | 30 Data+group[+null][+QoS] | 31 ( 1{ Data[+HTC]+individual+QoS+implicit-bar+a-mpdu}+a-mpdu-end 32 BlockAck[+HTC] 33 34 ) | 35 (BlockAckReq[+HTC] (BlockAck[+HTC]|Ack[+HTC])) | 36 (BlockAck[+HTC] Ack); 37 38 resync-sequence = CF-End | (CF-End+non-QAP CF-End+QAP); 39 40 41 42 (* This is an initiator sequence. The different forms arise from whether the initiator transmits a frame that 43 requires a BlockAck, and whether it delivers an RDG. When an RDG is delivered, the response is distin- 44 guished according to whether it demands a BlockAck response from the initiator or not. *) 45 46 initiator-sequence = (* No BlockAck expected, no RDG *) 47 burst 48 49 (* BlockAckReq delivered, BlockAck expected. No RD *) 50 (burst-bar (BlockAck|Ack) [+HTC]) | 51 52 53 (* No BlockAckReq delivered, RDG *) 54 (burst-rd ( 55 burst | 56 burst-bar initiator-sequence-ba 57 58 ) 59 ) | 60 61 (burst-rd-bar (BlockAck|Ack) [+HTC]) | 62 (burst-rd-bar ( 63 64 burst-ba | 65 burst-ba-bar initiator-sequence-ba

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009

1 ) 2 ) | 3 ht-ack-sequence | 4 5 psmp-burst | 6 link-adaptation-exchange ; 7 8 9 (* This is the same as the initiator-sequence, except the initiator is constrained to generate a BlockAck re- 10 11 sponse because a previous reverse direction response contained a BlockAckReq *) 12 initiator-sequence-ba = burst-ba | 13 (burst-ba-bar (BlockAck|Ack)[+HTC)) | 14 (burst-ba-rd ( 15 burst | 16 17 burst-bar initiator-sequence-ba 18 ) 19 ) | 20 (burst-ba-rd-bar (BlockAck|Ack)[+HTC]) | 21 (burst-ba-rd-bar ( 22 23 burst-ba | 24 burst-ba-bar initiator-sequence-ba 25 ) 26 ); 27 28 29 (* These are sequences that occur within an ht-txop-sequence that have an ack response *) 30 ht-ack-sequence = (BlockAck+delayed[+HTC] Ack[+HTC]) | 31 (BlockAckReq+delayed[+HTC] Ack[+HTC]) | 32 (Data[+HTC]+individual[+null][+QoS+normal-ack] Ack[+HTC]); 33 34 35 (* A burst is a sequence of 1 or more packets, none of them requiring a response *) 36 burst = 1{ppdu-not-requiring-response}; 37 38 (* A burst containing a BlockAckReq *) 39 40 burst-bar = {ppdu-not-requiring-response} ppdu-bar; 41 42 (* A burst containing a BlockAck *) 43 burst-ba = ppdu-ba {ppdu-not-requiring-response}; 44 45 46 (* A burst containing a BlockAck and BlockAckReq, either in the same packet, or in separate packets. *) 47 burst-ba-bar = (ppdu-ba {ppdu-not-requiring-response} ppdu-bar) | 48 ppdu-ba-bar; 49 50 (* A burst delivering an RDG *) 51 52 burst-rd = {ppdu-not-requiring-response} ppdu-rd; 53 54 (* A burst containing a BlockAckReq and delivering an RDG *) 55 burst-rd-bar = burst ppdu-rd-bar; 56 57 58 (* A burst containing a BlockAck and delivering an RDG *) 59 burst-ba-rd = (ppdu-ba {ppdu-not-requiring-response} ppdu-rd) | 60 ppdu-ba-rd; 61 62 (* A burst containing a BlockAckReq and BlockAck and delivering an RDG *) 63 64 burst-ba-rd-bar = (ppdu-ba {ppdu-not-requiring-response} ppdu-rd-bar) | 65 ppdu-ba-rd-bar;

Authorized licensed use limited to: Univ of Calif San Diego. Downloaded on October 29, 2009 at 15:52 from IEEE Xplore. Restrictions apply. IEEE P802.11n/D11.0, June 2009