| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
| --- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
Hi, Mark. Thank you very much for the proposed resolutions. We had to stop in the middle of discussing CID 6389 today, and I will not be able to attend Thu PM1 session when I presume this will be picked up again. So
please allow me to provide my feedback on CID 6389 via email instead. A STA is not “required” to transmit an OMN frame/element. Please note that all the ‘shall’s in 10.42 is used to clarify how NOT to use the OMN (as opposed to mandating a STA to transmit OMN). It is at the discretion
of each STA to decide whether it wishes to announce the change of its operating mode (RX Nss and/or BW). As discussed during the meeting today, it occurs frequently that not all the modes a STA announced to be capable of to be ‘usable’ at a given time – for
example, even though a STA declares 2SS RX capable, channel conditions may prevent successfully receiving 2SS packets. And yet, 802.11 systems successfully operate in those situations even though there is no explicit indication from the STA that it cannot
receive 2SS packets in the current channel condition, for example. Hence, it is not necessary nor the intent that a STA “has to” indicate a change in operating mode every single time. In that sense, I do not agree with your comment that “the requirement
for an AP to notify (re)associating STAs that it is operating with reduced max NSS is not clearly expressed” – there is no such requirement. Of course, an AP may notify such information to (re)associating STAs as deemed necessary, which is allowed as shown
in Table 8-30 (Association Response frame body), Tables 8-33 (Reassociation Response frame body), etc. – and yes, it is probably a good thing for the AP to indicate the operating mode change (for its own benefit), but not a ‘requirement’. Specific to your text proposal, ·
I think it is correct for the paragraph starting at P1847L40 NOT to include the additional frame format you are proposing to add (e.g. Beacon, Probe Response, etc.) This is because there are more specific
rules on using OMN in such frames – for example, see the paragraph starting on P1849L5. If we include Beacon, Probe Response, etc. to P1847L40, then it would cause conflict with P1849L5. Hence, I do not feel there is need to make changes to the paragraph
starting on P1847L40. ·
Regarding changing P1847L50 from “An association with an AP” to “An association in an infrastructure BSS”, I understand your motivation is to include the case where the ‘first STA’ is an AP and the
‘second STA’ is the associated non-AP STA. However, that case is covered in P1848L12 and P1848L27. Hence, I do not think the proposed change for P1847L50 is necessary. ·
As for the proposed change for the paragraph starting on P1848L4, I think the current text is more forward compatible. Please note that the intent of the OMN is not to be tied only to VHT. For example,
even non-VHT HT STAs are allowed to support OMN. And it is desirable that future 802.11 amendments also make use of OMN as much as possible (instead of defining a ‘new’ OMN). Now, if we accept your proposed text, then we would have to update the text when
the next amendment comes up because your proposed text works only for HT and VHT modes. While I can see that you are trying to be more precise, I don’t see the current text to be broken, and seems quite ‘forward compatible’. ·
I think your proposed text change for P1849L10 (“A STA shall not transmit
in an individually addressed frame an Operating Mode field”) is ok. ·
Regarding the creation of “NOTE 2” and the text changes within it, I am fine with making it a NOTE. However, I think your text change within NOTE2 is not accurate. For example, it reads “… number
of spatial streams supported by the recipient HT STA is reported in … the Supported VHT-MCS and NSS Set field”. Note the “HT STA” and “VHT-MCS”. I did not spend time to fix this part, but I didn’t understand why you wanted to insert the word “HT” and delete
the word “recipient”. ·
Change to P1849L17 (“A STA shall not transmit
in an individually addressed frame an Operating Mode field … recipient STA”) seems ok. ·
As for NOTE3, similar comment as on NOTE2 in above. ·
Agree with removing “received” from P1849L29. Regards, Youhan From: ***** IEEE stds-802-11-tgm List ***** [mailto:STDS-802-11-TGM@xxxxxxxx]
On Behalf Of Mark Rison --- This message came from the IEEE 802.11 Task Group M Technical Reflector ---
I have just uploaded 15/0762r0. This contains discussion, open issues and some proposed resolutions for CIDs 6075, 6214, 6215, 6216, 6305, 6306, 6308, 6375, 6376, 6377, 6389, 6390, 6404, 6482, 6496, 6506, 6562, 6563, 6583. These CIDs cover PS, Duration setting classes, OMN, CS/CCA/NAV/ED/PD/"CCA-ED", aAirPropagationTime corner cases, aSlotTime error, "reserved", SA Query and other assoc/reassoc horrors, and various editorials. I am available to present these in: - AM1 and PM1 on Wed 17 - AM1 and PM1 on Thu 18 - PM1 on Fri 19 Mark -- 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 _______________________________________________________________________________
IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send your request to this CLOSED reflector. We use this valuable tool to communicate on the issues at hand.
SELF SERVICE OPTION: Point your Browser to -
http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM and then amend your subscription on the form provided. If you require removal from the reflector press the LEAVE button.
Further information can be found at:
http://www.ieee802.org/11/Email_Subscribe.html _______________________________________________________________________________
IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send your request to this CLOSED reflector. We use this valuable tool to communicate on the issues at hand. SELF SERVICE OPTION: Point your Browser to - http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM and then amend your subscription on the form provided. If you require removal from the reflector press the LEAVE button. Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html _______________________________________________________________________________ |