| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
As discussed on this morning’s telecon, I have prepared the following resolutions.
The resolution for 20637 is straight from Mark’s email.
On the call we discussed a reject resolution for 20758, but after reviewing the requirements I could not find something equivalent to “A non-AP STA shall not transmit an HE MU PPDU to more than one STA”, so I have a proposed statement to cover that.
I have uploaded a revision of the comment spreadsheet with these resolutions under the comment group “2019-03-28 telecon”: https://mentor.ieee.org/802.11/dcn/19/11-19-0292-06-00ax-comments-on-tgax-d4-0.xlsx
-Robert
|
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 ". |
|
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.
I think it needs to be more specific. I think it cannot include more than one in the range 1 to 2007 (not 0 to 2007) and cannot include any outside this range except 2046 |
|
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.
The question is who is being protected (non-ER from ER, or ER from non-ER) and how this is achieved. The CID 16255 resolution said that "RTS frame or MU-RTS frame is used to protect the TXOP from the non-ER STAs." |
|
20850 |
248.43 |
10.9 |
J |
"An HE STA shall not send a Control Wrapper frame |
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.
But the wording does not just exclude the currently defined A-Control mechanisms, it covers all mechanisms that use +HTC, including HT-variant and VHT-variant HT Controls. A device has to be able to receive a Control Wrapper anyway, because it might receive one from a non-HE STA. As far as predictability of NAV setting, that ship sailed a long time ago (see e.g. NOTE 1 in 9.2.5.2 -- in fact this explicitly mentions HT Control). So the arguments above do not hold |
--
Mark RISON, Standards Architect, WLAN English/Esperanto/Français
Samsung Cambridge Solution Centre Tel: +44 1223 434600
Innovation Park, Cambridge CB4 0DS Fax: +44 1223 434601
ROYAUME UNI WWW: http://www.samsung.com/uk
To unsubscribe from the STDS-802-11-TGAX list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAX&A=1