doc.:ieee 802.11-10/0316r0 submission mar. 2010 brian hart, cisco systemsslide 1 802.11ac preamble...
TRANSCRIPT
Brian Hart, Cisco Systems
Slide 1
doc.:IEEE 802.11-10/0316r0
Submission
Mar. 2010
Slide 1
802.11ac Preamble
Authors: Date: 2010-03-10
Name Company Address Phone email Brian Hart Cisco Systems 170 W Tasman Dr, San
Jose, CA [email protected]
Brian Hart, Cisco Systems
Slide 2
doc.:IEEE 802.11-10/0316r0
Submission
Mar. 2010
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”)
VHT-STF VHT-LTFsL-STF L-LTF L-SIG VHTSIGA VHTSIGB VHTData
2 symbols 1 symbol
T
VHT auto-detection
Rate=6MbpsLength determined by T
Brian Hart, Cisco Systems
Slide 3
doc.:IEEE 802.11-10/0316r0
Submission
Mar. 2010
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
Slide 4
doc.:IEEE 802.11-10/0316r0
Submission
Mar. 2010
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
Slide 5
doc.:IEEE 802.11-10/0316r0
Submission
Mar. 2010
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
Slide 6
doc.:IEEE 802.11-10/0316r0
Submission
Mar. 2010
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
Slide 7
doc.:IEEE 802.11-10/0316r0
Submission
Mar. 2010
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