| 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 ---
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. 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. ·
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 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. I don't think the proposed changes tie things to VHT. Remember that a VHT STA is an HT STA. 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"). ·
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. and delete the word “recipient”. Because it's there already (first line, near the middle). ·
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 _______________________________________________________________________________ |