| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi Gaurang,
There have been discussions online on CID 10053 and based on the points raised in the TGbe online meeting, in a smaller group consisting of delegates who had expressed their opinion on the matter. There was also CID 10155 on a related topic on which you too had expressed your opinion and there was a similar discussion. I think it is necessary, also from the perspective of the comment resolution procedure, to resolve the issue of NSTR mobile AP supporting EMLSR clients in the context of the CIDs related to it, rather than make a change as part of an unrelated CID.
I am copying below some salient points on how NSTR mobile AP MLD can and should be allowed to work with any kind of client.
Supporting EMLSR/EMLMR clients by a mobile AP should be optional and should not be disallowed.
Importantly, the decision on whether or not to implement an optional feature for a mobile AP should be left to the vendor. Someone who wants to implement it should not be prevented from doing so. That is why we prefer the spec as it is now, which leaves all choices open
Technically, all that is needed is alignment of DL with DL and UL with UL on the 2 links even when using different clients. I am referring to triggered UL here since that is how any coordinated operation among different clients is possible on the UL. For example, UL MU-MIMO or UL OFDMA has also been possible only when triggered by the AP. The level of complexity is similar to when an NSTR non-AP has to start align its UL transmissions over different links.
Should the specification constrain NSTR mobile AP to have DL and triggered UL only with the same client on both the links?
For example, if the NSTR mobile AP has legacy clients on the primary link and has won access to both the links, should it transmit only on the primary link and only to the legacy clients, giving up its access to the nonprimary link? The above would be very suboptimal and using the same generality, EMLSR/EMLSR clients can also be supported.
For UL, the non-primary link is available to only an 11be ML client. This is because all single link clients will be restricted only to the primary link. For such a client, as a part of the NSTR mobile AP protocol, we require that untriggered UL transmissions can happen either only on the primary link or both primary and non-primary link in an aligned manner. So, there is no issue of untriggered UL transmissions occurring only on the non-primary link
End alignment of BAs transmitted on the UL by the clients to the NSTR mobile AP on the 2 links: Even when the NSTR mobile AP transmits in 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 mixture 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 (although the AP is recommended to do so).
Can you please elaborate on your observation: “Allowing EMLSR operation with NSTR mobile AP MLD will create additional rules and exceptions for EMLSR, which already has many rules and exceptions.In the interest of stabilizing the spec, in my opinion disallowing EMLSR operation with NSTR mobile AP MLD is the right way forward.”
According to me, the current NSTR mobile AP spec already allows supporting EMLSR clients. So, a NSTR mobile AP implementation that wishes to support EMLSR clients can already do so without any additional support from the spec. So, I am not asking for any additional text in the 11be spec. On the contrary, the proposed change is adding text to the 11be spec to rule out support for EMLSR clients. Therefore, what is the motivation to introduce additional text only to explicitly prevent an implementation from supporting this feature, if it can already do so without requesting for any spec support?
Further, even with your proposed restriction to rule out EMLSR clients, the NSTR mobile AP is not prevented from scheduling (DL or triggered UL) a single link client on the primary link and an NSTR/STR client on the nonprimary link. This possibility is no different from supporting EMLSR clients.
Regards,
Shubho
Hi Shubho,
I used CID 13476 to make all changes (and bugfixes) related to NSTR mobile AP MLD. This was based on offline feedback that I had received.
I am not aware of or involved in any discussions related to CID 10053. Could you please provide details on how EMLSR operation would work on both sides for DL and UL? The NSTR Mobile AP MLD feature requires that any transmission on the nonprimary link must be accompanied by simultaneous transmission on the primary link. How would a non-AP MLD that supports EMLSR operation transmit on two links? Furthermore, simultaneous DL transmissions to different non-AP MLDs is complex (and provides little gains) given the start and end-alignment considerations on NSTR links.
Allowing EMLSR operation with NSTR mobile AP MLD will create additional rules and exceptions for EMLSR, which already has many rules and exceptions. In the interest of stabilizing the spec, in my opinion disallowing EMLSR operation with NSTR mobile AP MLD is the right way forward.
Thanks,
Gaurang
From: Shubhodeep Adhikari <00000c144a46bcee-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Monday, January 2, 2023 7:21 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] Announcement: Motions for TGbe on Wednesday 04th of January 2023
Hi Alfred,
Can you please remove CID 13476 (in doc 1480r1) from Motion 488 (MAC). I have a concern regarding the following resolution (highlighted in yellow):
The condition for the presence of the EML Capabilities subfield in the Common Info field is defined in 35.3.17 (Enhanced multi-link single radio operation) and 35.3.18 (Enhanced multi-link multi-radio operation). The subfield is not included in frames transmitted by an AP affiliated with an NSTR mobile AP MLD (#13476).
There is ongoing discussion in CID 10053 on whether an NSTR mobile AP should support EMLSR non-APs. So the above resolution seems premature. Also, this resolution seems unrelated to the comment in CID 13476.
Regards,
Shubho
On Sun, 25 Dec 2022 at 02:31, Alfred Asterjadhi <asterjadhi@xxxxxxxxx> wrote:
Hello all,
This is an advanced notification that TGbe will run motions during the Joint teleconference scheduled on 4th of January 2023.
Please refer to the document linked below for a preliminary list of all the motions (starting from slide 112) that will be run during the conference call:
Please review the documents included in Motions 487-496, and reply to this e-mail if you would like to identify any of these documents or any particular CID as items that need further discussion. The deadline for sending these e-mails is January 3rd 2023 @10:00am ET.
A list of these requested items will be queued for discussion and run as a separate motion (Motions >497) during the same Joint conference call.
Contributions that have not received a request for further discussions will be part of their respective cumulative motion and will be run at the same Joint conference call.
If you have any comments and/or questions please let me know.
Best Regards and Happy Holidays!
Alfred
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
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature