|
CID
|
Page
|
Clause
|
Resn Status
|
Comment
|
Proposed Change
|
Resolution
|
|
20637
|
|
|
V
|
The ESS Report might be useful in a non-HE BSS too (and indeed 11.22.7.5 has no HE restrictions)
|
Remove the restrictions on use only with HE
|
REVISED (EDITOR: 2019-03-28 15:08:35Z) - In the table in 6.3.3.3.2 delete "dot11HEOptionImplemented is true and ".
In the table in 6.3.7.3.2, 6.3.7.5.2, 6.3.8.3.2, 6.3.8.5.2 delete " if dot11HEOptionImplemented is true; otherwise not present".
In Tables 9-34, 9-37, 9-39, 9-41 delete " if dot11HEOptionImplemented is true; otherwise it is not present".
|
|
20758
|
|
11.23.1
|
V
|
Re CID 16172: the things noted in the resolution need to be specified
|
At the end of the referenced subclaus add "A TDLS STA shall not transmit a triggering PPDU and shall not transmit an HE MU PPDU to more than one STA."
|
REVISED (EDITOR: 2019-03-28 16:04:15Z) - During discussion it was agreed that proposed change is already covered by requirements for a non-AP STA (a TDLS STA is a non-AP STA).
At 326.61 it states "A non-AP STA shall not send a Trigger frame or a frame with a TRS Control subfield." However, on further review, it appears there is no explicit statement restricting a non-AP STA's transmission of an HE MU PPDU to a single user. The requirement
is only implicitly in statements in 27.1 on what a non-AP STA "may" support.
Add the following statement at the end of 26.11.1 (STA_ID_LIST): "A non-AP STA shall not transmit an HE MU PPDU where the TXVECTOR parameter STA_ID_LIST includes more than one element in the range 0 to 2007."
|
|
20771
|
295.05
|
26
|
J
|
Re CID 16255: ER PPDUs are not analoguous to STBC PPDUs. A device can still receive an STBC PPDU's PHY header (and hence determine the PPDUs duration) if it does not support
STBC. A device that does not support ER PPDUs cannot receive the PHY header (and so cannot determine the PPDU's duration)
|
Add a subclause "Protection" stating "A TXOP holder that transmits an HE ER PPDU in a TXOP shall transmit an RTS frame or MU-RTS Trigger frame at the start of the TXOP."
|
REJECTED (EDITOR: 2019-03-28 19:59:31Z) - The RTS/CTS mechanism does not necessarily work in the cases where the HE ER SU PPDU is beneficial: an RTS frame in a non-HT PPDU would
have 6 dB less margin than the HE ER SU PPDU, meaning that while the intended recipient of the HE ER SU PPDU could receive the HE ER SU PPDU it might not receive (and thus not respond) to an RTS. The commenter brought up an alternate proposal to protect using
CTS-to-self. There was some discussion on the benefit of doing this over relying on the deferral protection offered by L-SIG. The question was asked why the HE ER SU PPDU would require such protection while a 1024 QAM HE SU PPDU would not -- both would not
necessarily be received by all HE devices. The argument in favor was not using protection.
|
|
20850
|
248.43
|
10.9
|
J
|
"An HE STA shall not send a Control Wrapper frame
to another HE STA." -- there is no justification for this restriction
|
Delete the cited text at the referenced location
|
REJECTED (EDITOR: 2019-03-28 17:58:53Z) - Justification for the restriction is supported by a complexity vs benefit analysis: supporting the Control Wrapper requires parsing
support on the receive side: all Control frames would need support as two variants: wrapped and plain as well as parsing support for extracting the HT Control field form the Wrapper frame itself. It also introduces less predictability on the size of the Control
frames making resource allocation and NAV setting more difficult. For the currently defined A-Control mechanisms there is insufficient benefit to supporting these in frames other than the QoS Null and QoS Data fames.
|