| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi Gaurang,
I have copied points from your email and embedded responses.
Gaurang>> Supporting EMLSR operation requires additional complexity at a NSTR mobile AP MLD or EMLSR non-AP MLD, or both.
Gaurang>> Instead, it is better to stabilize the spec and disallow it.
If this was the case, it would mean that the current NSTR mobile AP spec does not support EMLSR clients. So, why do you still want to put an additional clause that explicitly states that EMLSR clients cannot be supported? Just leave the specification as is without any change. This is what I have been insisting on.
On the contrary, I think the current NSTR mobile AP spec already allows EMLSR clients and architectures are free to support it if they choose to. Why do you want the 11be spec to block such an architecture from supporting EMLSR clients?
Gaurang>> For EMLSR, contention on multiple links is the main benefit, which is lost if EMLSR operation is enabled with NSTR mobile AP MLD.
Since EMLSR clients would listen on both links, it would allow an NSTR mobile AP to contend on both links and transmit on either one or both links depending on the outcome of channel access. This is possible for DL and triggered UL. So, there is no loss of benefit arising from the multiple listen feature offered by EMLSR clients.
Gaurang>> If the NSTR mobile AP MLD decides to wait on the primary link for the nonprimary link to count down, the odds of an OBSS transmission stepping increase substantially.
From the perspective of ML performance, the situation is no different between NSTR clients or EMLSR clients. If the NSTR mobile AP wins TXOPs on both links that are fully overlapping in time, it can transmit to a single or multiple NSTR clients on the two links or to multiple EMLSR clients on the two links. A mix of legacy and NSTR/EMLSR clients is also possible.
If your claim is that the NSTR mobile AP MLD would seldom transmit on both links, that operation would be like a single-link mobile AP. In this case too, NSTR or EMLSR clients would lead to the same ML performance
Gaurang>>Simultaneous exchanges (UL or DL) on primary + nonprimary to different MLDs does not provide any meaningful gains.
This is counterintuitive. The ML gain when an AP transmits to the same client on multiple links is not higher than when an AP transmits to different clients on different links. In fact, having different clients helps in all practical scenarios as one client alone may not have enough traffic to exhaust a full TXOP on both the links.
Gaurang>> Supporting EMLSR operation requires additional complexity at a NSTR mobile AP MLD or EMLSR non-AP MLD, or both.
My proposal is to leave the current spec unchanged. So there is no additional complexity.
Gaurang>> For example, to transmit to two different non-AP MLDs and achieve end-alignment, either both STAs must support receiving SRS Control, which makes support for SRS Control a must for EMLSR non-AP MLDs to meaningfully operate with NSTR mobile AP MLD
UL: SRS control is relevant only for untriggered UL to end-align the responses from the AP. There is no need for any special behavior to enforce end-alignment of untriggered UL, as untriggered UL transmission on the nonprimary can only occur if the primary link is also being transmitted on by the same client. For triggered UL, the AP enforces end alignment using the duration of the allocation whether to the same client or to different clients.
DL: Even when the NSTR mobile AP transmits on the DL to the same NSTR client and if the mobile AP intends to continue the TXOP after the given DL-BA exchange, the NSTR client has to end align the BAs on the 2-links. If the BAs are not end aligned, the mobile AP will just have to initiate a new TXOP. The situation is similar in case of 2 EMLSR clients or a mix of legacy and EMLSR/NSTR clients. It is also similar to an NSTR non-AP transmitting on UL to an STR AP and the DL BAs not being end-aligned.
As I have said, there is a viable NSTR mobile AP architecture that can support EMLSR clients and without any additional support from the spec. That is why I oppose putting any forcible restriction to rule out such an architecture.
Regards,
Shubho
Hi Shubho,
I see two main issues in allowing EMLSR operation with NSTR mobile AP MLD:
- For EMLSR, contention on multiple links is the main benefit, which is lost if EMLSR operation is enabled with NSTR mobile AP MLD. Simultaneous exchanges (UL or DL) on primary + nonprimary to different MLDs does not provide any meaningful gains. If the NSTR mobile AP MLD decides to wait on the primary link for the nonprimary link to count down, the odds of an OBSS transmission stepping increase substantially. NSTR mobile AP MLD channel access rules are best suited to provide throughput benefits when it exchanges frames with an MLMR non-AP MLD (STR or NSTR).
- Supporting EMLSR operation requires additional complexity at a NSTR mobile AP MLD or EMLSR non-AP MLD, or both. For example, to transmit to two different non-AP MLDs and achieve end-alignment, either both STAs must support receiving SRS Control, which makes support for SRS Control a must for EMLSR non-AP MLDs to meaningfully operate with NSTR mobile AP MLD. Or, additional behavior at the NSTR mobile AP MLDs would be required - the NSTR mobile AP MLD will have to terminate the TXOP if the duration of Ctrl response durations on two links are different. This, again, would contribute to poor performance and add to its implementation complexity.
Considering the performance issues, allowing EMLSR mode with NSTR mobile AP MLD would achieve limited to no benefit and we would be allowing it only for the sake of it. Instead, it is better to stabilize the spec and disallow it.
Thanks,
Gaurang
-----Original Message-----
From: Shubhodeep Adhikari <shubhodeep.adhikari@xxxxxxxxxxxx>
Sent: Tuesday, January 3, 2023 5:40 AM
To: Gaurang Naik <gnaik@xxxxxxxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] Announcement: Motions for TGbe on Wednesday 04th of January 2023
WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
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
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature