| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Ming, The original text is “for each EMLMR link”. Per Vishnu’s comment the text is changed to “at least one EMLMR link”. Best Regards, Liwen From: Ganming(Ming Gan) <000017d5b1a95115-dmarc-request@xxxxxxxxxxxxxxxxx>
Caution:
EXT Email
Then what is the benefit to link 2? Downgrade? 发件人: Vishnu Ratnam [mailto:vishnu.r@xxxxxxxxxxx]
Hi Ming, In your very example, say there are two links, link 1 supports 2 ss, and link 2 supports 8 ss. EMLMR Supported NSS Set can be 6 ss. It can be shown that in congested networks, this EMLMR mode with 6 SS can
provide throughput gains over operating in non-EMLMR mode with 2 SS and 8 SS respectively. More importantly, this offers flexibility by allowing implementations of EMLMR where not all RF chains can be switched from one link to another link and when there can
be asymmetry in NSS across links. Firstly, I don’t see the need for the spec to impose restrictions on how many NSS to use in EMLMR mode, it can be left to implementation. If at all we want to say something, I prefer Liwen’s current version
with “at least one EMLMR link”. Regards, Vishnu From: Ganming(Ming Gan) <ming.gan@xxxxxxxxxx>
Hello Liwen I don’t think “at least” in the following sentence is correct. It should be “each”. For example, there are two links, link 1 supports 2 ss, and link 2 supports 8 ss. Are you saying the value
indicated by EMLMR Supported MCS And NSS Set subfield could be 3 or 4? What EMLMR operation on link 2 in this case? An non-AP MLD may announce the different Tx Nss and Rx Nss in the EMLMR Supported MCS And NSS Set subfield in the different EML operating mode negotiation where the Tx Nss and Rx Nss in the EMLMR Supported
MCS And NSS Set subfield shall be more than the Tx Nss and Rx Nss of
at least one EMLMR link as defined in 35.15(PPDU format, BW, MCS, NSS, and DCM selection rules),
35.9 (Operating mode indication), and 26.9 (Operating mode indication). Best wishes Ming Gan 发件人: Vishnu Ratnam [mailto:vishnu.r@xxxxxxxxxxx]
Thanks Liwen, I am fine with this text. Although I am still a bit curious what benefit specifying this provides. Maybe we can discuss during your presentation.
Regards, Vishnu From: Liwen Chu <liwen.chu@xxxxxxx>
Hi Vishnu, How about the following text: An non-AP MLD may announce the different Tx Nss and Rx Nss in the EMLMR Supported MCS And NSS Set subfield in the different EML operating mode negotiation where the Tx Nss and Rx Nss in the EMLMR Supported
MCS And NSS Set subfield shall be more than the Tx Nss and Rx Nss of
at least one EMLMR link as defined in 35.15(PPDU format, BW, MCS, NSS, and DCM selection rules),
35.9 (Operating mode indication), and 26.9 (Operating mode indication). I assume the red text address your concern and is still in line with the EMLMR’s radio switch operation. Best Regards, Liwen From: Vishnu Ratnam <vishnu.r@xxxxxxxxxxx>
Thanks Liwen. My point is that it is possible that the max MCS and NSS supported by EMLMR mode is lower than the MCS and NSS supported on some of the EMLMR links (even after applying 26.9 or 35.9). One example is the one I provided. I agree that the
example is unorthodox, but my point is such implementations should not be precluded.
More generally, I don’t see the value in adding the restriction that “maximal Tx Nss and maximal Rx Nss in the EMLMR Supported MCS And NSS Set subfield shall be no less than the Tx Nss and Rx Nss of each EMLMR
link”. Can you explain why this restriction is required? Regards, Vishnu From: Liwen Chu <liwen.chu@xxxxxxx>
Hi Vishnu, With the added text, the Tx/Rx Nss of the EMLMR mode can be smaller than the maximal Tx/Rx Nss of a link, e.g. when the operating Tx/Rx Nss of each link through the operation of 26.9 or 35.9 is smaller than the maximal Tx/Rx Nss of the
related link. Your example is trick since the Nss of link 2 in EMLMR mode is less than the Nss of link2 in non-EMLMR mode. Best Regards, Liwen From: Vishnu Ratnam <vishnu.r@xxxxxxxxxxx>
Hi Liwen, I have a concern regarding the following sentence: “where the maximal Tx Nss and maximal Rx Nss in the EMLMR Supported MCS And NSS Set subfield shall be no less than the Tx Nss and Rx Nss of each EMLMR link
as defined in 35.15(PPDU format, BW, MCS, NSS, and DCM selection rules), 35.9 (Operating mode indication), and 26.9 (Operating mode indication).(#10043)” It is possible that the EMLMR Supported MCS and NSS Set is lower than the largest of the MCS and NSS supported on each of the EMLMR links. Consider below example:
More generally, this kind of restriction is unnecessary and it should be up to implementation to determine what MCS and NSS to support in EMLMR mode. The spec shouldn’t be dictating this. Regards, Vishnu From: Liwen Chu <liwen.chu@xxxxxxx>
Hi Alfred, Please add the following contribution to the agenda Best Regards, Liwen From: Alfred Asterjadhi <asterjadhi@xxxxxxxxx>
With Corrected Link: Regards, AA On Mon, Nov 28, 2022 at 1:15 PM Alfred Asterjadhi <asterjadhi@xxxxxxxxx> wrote:
-- Alfred Asterjadhi, PhD IEEE802.11 TGbe Chair, Qualcomm Technologies Inc. Cell #: +1 858 263 9445 Office #: +1 858 658 5302 To unsubscribe from the STDS-802-11-TGBE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1 To unsubscribe from the STDS-802-11-TGBE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1 To unsubscribe from the STDS-802-11-TGBE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1 To unsubscribe from the STDS-802-11-TGBE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1 To unsubscribe from the STDS-802-11-TGBE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1 To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1 |