| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
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:
-
Say STA operating on link 1 supports 1 SS and STA operating on link 2 supports 4 SS in non-EMLMR mode. When switched to EMLMR mode, out of the 4 SS on link 2 only 2 SS are capable of being shared with link 1.
Then the EMLMR mode supported NSS will be 3 (since link 1 creates the limitation) which is lower than 4.
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 |