1 / 7

802.11ac Preamble

802.11ac Preamble. Date: 2010-03-10. Authors:. Slide 1. Situation. 10/70r1 proposes an 11ac preamble The preamble indicates an 11ac frame via A 0deg phase shift on LSIG at 16-20us (“not 11n GF”) A 0deg phase shift on VHTSIG at 20-24us (“not 11n MM”) then

stacey-lee
Download Presentation

802.11ac Preamble

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 802.11ac Preamble Date: 2010-03-10 Authors: Slide 1 Brian Hart, Cisco Systems

  2. Situation • 10/70r1 proposes an 11ac preamble • The preamble indicates an 11ac frame via • A 0deg phase shift on LSIG at 16-20us (“not 11n GF”) • A 0deg phase shift on VHTSIG at 20-24us (“not 11n MM”) then • A 90deg phase shift at 24-28 us (“not 11a”) 2 symbols 1 symbol L-STF L-LTF L-SIG VHTSIGA VHT-STF VHT-LTFs VHTSIGB VHTData T Rate=6Mbps Length determined by T VHT auto-detection Brian Hart, Cisco Systems

  3. Concern • A concern was raised that a hypothetical 11n implementation could detect a 10/70r1 (11ac) frame as 11n if the implementation checked that a) there is more Q-energy than I-energy across all of the HTSIG (20-28us) into the packet (not just 20-24us), and b) the LSIG Rate field decodes to 6 Mbps • Still, this hypothetical implementation introduces an extra 4 us of latency so seems to be an unusual choice for a real-time receiver • This hypothetical implementation would detect a 10/70r1 preamble as 11n MM with 50% likelihood, get a bad HTSIG CRC then revert to insensitive ED for CCA Brian Hart, Cisco Systems

  4. Background • From 9.13.4, the L_LENGTH field in an 11n MM packet is always a multiple of 3: it is calculated as where SignalExtension = 0 us at 5GHz • Conversely, CCA busy time = 20us + 4us*ceil(L_LENGTH+3)/3) + SignalExtension • Note: At 6 Mbps, there are 3 bytes per OFDM symbol, so each CCA busy time can actually be represented by 3 values of L_LENGTH • E.g. L_LENGTH = 4, 5, 6 all indicate a CCA busy time of 32 us + Signal Extension • This is NOT LSIG TXOP protection • it is merely spoofing the duration of the current frame • Although it could be used for LSIG TXOP spoofing too Brian Hart, Cisco Systems

  5. Improvement • This hypothetical implementation is decoding the PLCP header and checking Q-energy > I-energy over the full HTSIG field • Given such conservatism, this hypothetical implementation is also likely to be verifying a valid L_LENGTH • Therefore greater discrimination between 11n MM and 11ac (with the 10/70r1 preamble) is possible by extending the L_LENGTH spoofing rule: • 11n MM: • 11ac: - 1 • Reserved: - 2 • The Reserved value could be used a TBD future amendment Brian Hart, Cisco Systems

  6. Summary • Complementary to 10/70r1 • Provides explicit discrimination between 11n MM and 11ac • Little extra spec or implementation effort • Makes the hypothetical implementation that much more hypothetical • A problematic implementation has to wait an extra 4 us to verify Q > I over the full HTSIG field, and has to verify that the LSIG Rate maps to 6 Mbps, and cannot check that L_LENGTH is a multiple of 3 • The spoofing scheme has room for future growth, just in case Brian Hart, Cisco Systems

  7. Proposal • Add to Specification Framework: 3.2 Preamble R3.2.1.<ANA> The preamble shall define a mechanism to set the LSIG L_LENGTH field that improves the discrimination of 11ac frame formats that contain a LSIG L_LENGTH field from the 11n MM frame format Brian Hart, Cisco Systems

More Related