1. Counter Proposal to CID 7177
May 2006
doc.: IEEE yy/xxxxr0
July 2006
Counter Proposal to CID 7177
Date:
Authors:
Notice: This document has been prepared to assist IEEE It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures < ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE Working Group. If you have questions, contact the IEEE Patent Committee Administrator at
Yuichi Morioka, Sony Corporation
Tomoya Yamaura (Sony)

2. Abstract This document provides a counter proposal to CID 7177
May 2006
doc.: IEEE yy/xxxxr0
July 2006
Abstract
This document provides a counter proposal to CID 7177
Comment ID 7177:
In reference to Section L-SIG TXOP Protection Rules at Third Party HT;
“When the channel SNR is low or when interference is present or when collisions occur, the L-SIG has a high probability of undetected error (as it is protected by only one parity bit--if the channel induces at least one error elsewhere it may well to induce an even number of errors on the poorly protected L-SIG). This will often result in bad behavior. A well designed device might include an algorithm to determine how reliable the L-SIG is rather than be bound to use it to set the NAV.
Yuichi Morioka, Sony Corporation
Tomoya Yamaura (Sony)

3. July 2006
Similar Comments
Similar comments on the weakness of L-SIG were raised in,
CID 7177, 7258, 8146, 8277, 8278, 11999
…with different proposed solutions
Make the NAV setting a “should” from a “shall”
CID 7177, 8278, 11999
Make the HT-SIG CRC cover the L-SIG
CID 7258, 8146
Disallow use of L-SIG TXOP Protection when there is OBSS
CID 8277
This document explains why there is NO PROBLEM
Yuichi Morioka, Sony Corporation

4. Weakness of the L-SIG Parity
July 2006
Weakness of the L-SIG Parity
L-SIG Field uses even bit parity
the parity bit CAN detect ODD bits of error
the parity bit CAN NOT detect EVEN bits of error
Weakness of the L-SIG parity has been an existing problem with legacy systems
Yuichi Morioka, Sony Corporation

5. Mixed Mode PPDU Structure
July 2006
Mixed Mode PPDU Structure
L-SIG Field is followed by an HT-SIG Field
HT-SIG Field is double the length of L-SIG
HT-SIG Field is protected by 8 bit CRC
Comment 6788: “NAV shall only be set by the L-SIG when the HT-SIG CRC passes”
This was unanimously approved by Coex. Adhoc
What is the impact of this comment…?
Yuichi Morioka, Sony Corporation

6. L-SIG only used when HT-SIG CRC Passes
July 2006
L-SIG only used when HT-SIG CRC Passes
L-SIG is only used to set the NAV when HT-SIG CRC Passes
HT-SIG(42[bits]) is protected by 8[bit] CRC
Very high probability of error detection
If the L-SIG contains an error, most likely there will an error in the HT-SIG
Odd bit error in the L-SIG will be detected by L-SIG Parity
Even bit error in the L-SIG will likely cause 1+[bit] error in the HT-SIG which will be detected by HT-SIG CRC
In the rare event (0.2%~0.4%) that there is 2x[bits] of error in the L-SIG and no error in the HT-SIG, can this error in the L-SIG be detected?
YES!!
Yuichi Morioka, Sony Corporation

7. July 2006
Validity of L-SIG
If there is 2x[bits] of error in the L-SIG can this be detected in other ways??
The validity of the L-SIG can be checked through;
Validity of RATE field
Is it 6[Mbps]?
Validity of LENGTH field
Is it within the limit of valid length?
Is it in multiples of 3[Bytes]?
Yuichi Morioka, Sony Corporation

8. Validity of L-SIG: Rate
July 2006
Validity of L-SIG: Rate
In a MM PPDU, the RATE field of the L-SIG is required to be set to 6[Mbps]: {1, 1, 0, 1}
If the RATE contains any other value, it can be rejected at the Rx
This provides additional verification of the L-SIG
Yuichi Morioka, Sony Corporation

9. Validity of L-SIG: Max Length
July 2006
Validity of L-SIG: Max Length
The Length field of the L-SIG is required to be under 2346[Bytes]
This is the maximum value defined in baseline
If the LENGTH contains any other value, it can be rejected at the Rx
Because there are 12[bits] in LENGTH field, the max it can represent is 4096[Bytes], so anything between 2347 ~ 4096[Byte] is an error
This provides additional verification of the L-SIG
Yuichi Morioka, Sony Corporation

10. Validity of L-SIG: Multiple of 3[Bytes]
July 2006
Validity of L-SIG: Multiple of 3[Bytes]
The Length field of the L-SIG is required to be in multiple of 3[Bytes]
The purpose of L-SIG is to provide adequate TIME of protection
1 [OFDM Symbol], carries 3[Bytes] when using 6[Mbps]
Therefore, Length = 1, 2, and 3[Bytes] represent the same TIME which is 1[OFDM Symbol]
If the LENGTH contains any other value, it can be rejected at the Rx
This is already approved in per packet spoofing
Explicitly stating this same rule for L-SIG TXOP would enable a common error detection mechanism
This provides additional verification of the L-SIG
Yuichi Morioka, Sony Corporation

11. Flowchart Additional validity check of the L-SIG
July 2006
Flowchart
Additional validity check of the L-SIG
HT-SIG CRC Pass?
L-SIG Rate = 6[Mbps]?
L-SIG Length < 2346[Bytes]?
L-SIG Length = 3x [Bytes]?
After these checks, the probability of L-SIG containing false positive error is extremely low
Yuichi Morioka, Sony Corporation

12. July 2006
Conclusion
Probability of using L-SIG with undetected false positive is low
The probability of “L-SIG Parity Pass/L-SIG Rate Valid/L-SIG Length ERROR” when HT-CRC passes is 0.2~0.4[%] (according to doc0865/06)
To further strengthen the error check we can adopt the following;
Proposal 1:
Add the following text to Section 9.15 L-SIG TXOP Protection;
“The length indicated in the L-SIG shall be in multiple of 3[Bytes]”
Proposal 2:
Add the following text to the first sentence in Section L-SIG TXOP Protection at 3rd Party;
STA shall update the NAV, “if the L-SIG Field is determined to be valid, and the HT-CRC passes. The validity of the L-SIG Field may be checked through the L-SIG RATE being 6[Mbps], and the L-SIG LENGTH being below 2346[Bytes] and in multiples of 3[Bytes]”
Yuichi Morioka, Sony Corporation