| 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 ---
Thank you for your response, Mark. Please see inlined. Regards, Youhan From: Mark Rison [mailto:m.rison@xxxxxxxxxxx] Hello Youhan, Thanks for your careful review. 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’. Yes, we already agreed last night that it should be "should" not "shall", and this is reflected in 15/0762r1 on Mentor. [YK] Thank you for reverting the ‘shall’ back to ‘should’. Yes, we discussed much of the above argument yesterday, but at the time, it was regarding the ‘should’ or ‘shall’. But I re-read your comment afterwards,
and felt that the same argument applies to the general issue you are raising (“… requirement for an AP to notify …”). Hence, I repeated the argument to say that I do not agree with the issue (“requirement”) you are raising in the comment. 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. I think these two are different. 1847.40 is about when you should tx OMN. 1849.5 is about when you shall not tx OMN. They are not in conflict. [YK] I think there is a conflict because 1847.40 would say with your proposed change “… STA should send OMN if there is change in operating mode…”, while 1849.5 would say “… AP shall not send OMN if RX Nss
did not change”. AP is a subset of STA, and RX Nss is a subset of operating mode. So, 1847.40 would be saying one should send OMN, while 1849.5 would be saying one shall not send OMN. ·
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. I think this is a valid observation. I will have to consider whether there's a way to reorder things to make this (i.e. that the specific case of AP->STA is dealt with separately)
clearer. ·
As for the proposed change for the paragraph starting on P1849L4, 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. I don't think the proposed changes tie things to VHT. Remember that a VHT STA is an HT STA. [YK] Yes, a VHT STA is an HT STA. My point here is that the current draft is agnostic to which PPDU format you support (e.g. HT-only or HT-and-VHT). 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 we should not have to try to second-guess future amendments, especially if this is at the cost of precision. A future amendment will have to review all this stuff anyway (see e.g. the existing references
to "the Supported Channel Width Set subfield in the HT Capability Information field"). [YK] While I don’t see something ‘wrong’ with your change here, I don’t see anything broken in the draft, nor see the need to make a change to the draft. And if we leave it as-is, it has higher chance that
we don’t have to worry about this again in the future. ·
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” Because e.g. an 11g STA does not transmit a Supported MCS Set field at all. Also, again remember that a VHT STA is an HT STA. [YK] Yes, a VHT STA is an HT STA. But not all HT STA are VHT STA. And your proposed text reads “… HT STA is reported in … VHT Capabilities Info field”. and delete the word “recipient”. Because it's there already (first line, near the middle). [YK] Situation is that STA1 (the ‘recipient STA’) transmits the HT/VHT Capabilities element to STA2, and STA2 transmits OMN to STA1. So, it could be confusing to some people on which STA is being referred to
in the “transmitted by the STA” (the wording you are proposing) – both STA are transmitting something (STA1 transmits HT/VHT Capabilities, and STA2 transmits OMN). So, I believe the intention was to clarify that the “STA” here is STA1 (‘recipient STA’).
You are probably right that what you are proposing may make sense in terms of English grammar, but I think the current draft (“transmitted … by the recipient STA”) is also correct and is more explicit – my preference. ·
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. 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 From: Kim, Youhan [mailto:youhank@xxxxxxxxxxxxxxxx]
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 _______________________________________________________________________________ |