| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi Minyoung,
Thanks.
For the 1st point, a 'should' which is indicative of a recommendation may still lead to interop issues for APs that choose some other PPDU format for longer range. Also, the current spec does not preclude an AP from choosing only EHT/HE MU PPDUs if it wants to avoid the situation that you have pointed out. However, if you prefer to draw attention to the potential problem and also point out a possible solution, it suffices to mention the problem and that the AP ‘may’ restrict DL transmissions to EHT/HE MU PPDUs in order to avoid it.
On the 2nd point, I mentioned the Downlink case in my email. Without any explicit ruling out, it is not clear that DL transmission by an NSTR mobile AP MLD to 2 different clients on the 2 links is not permitted.
Regards,
Sindhu
On Fri, Sep 9, 2022 at 10:03 PM Minyoung Park <mpark.ieee@xxxxxxxxx> wrote:Hi Sindhu,Thanks for the responses.For the 1st point, since you agree on the problem but I also see your point on the range argument, would making this 'should' behavior work for you as a recommendation? Basically replacing 'shall' to 'should'.On the 2nd point, NSTR mobile AP MLD, for two different clients case, what happens if one client transmits on the secondary link only while the other link is not accessing the primary link? Doesn't this violate the current NSTR mobile AP rules since the primary link has to be always included for the secondary link transmission?Regards,MinyoungOn Fri, Sep 9, 2022 at 3:16 AM Sindhu Verma <sindhu.verma@xxxxxxxxxxxx> wrote:Hi Minyoung,
Thanks for your email.
I couldn’t attend your presentation yesterday as it was very late India time.
I have copied your comments and inserted responses.
[MP] The problem is that in such a case it is not clear when the non-AP MLD switches back to the listen operation. There could be following three cases depending on different implementations:
- after PHY preamble if the received PPDU is EHT PPDU or HE MU PPDU
- after MAC header if it doesn't see it's address
- after checking FCS at the end of the received frame
If the received frame is a long Data/Management frame (1-2 msec), in the worst case and for different implementation, the non-AP MLD might have to wait until the end of the frame to check the FCS. Since the AP MLD doesn't know when the non-AP MLDs that are not included as a destination in the PPDU will switch back to the listening operation (due to the ambiguity above), the AP MLD will assume the worst case and cannot use the other link to schedule transmission to the non-AP MLD until the end of the long Data/Management frame.
>>I agree this is a valid issue. But this issue was known when the current proposal to return to listen mode was agreed as a compromise. That is also why before this compromise, the duration based approach was discussed for a long time and had almost got agreed. There are significant downsides of restricting AP transmissions to EHT MU or HE MU only. For example, this will have a direct impact on the link adaptation algorithm at the AP and will restrict the range of transmissions by the AP to an EMLSR non-AP.
[MP] The statement in the resolution seems to be correct. In the current spec, there is no definition for EMLSR operation for NSTR mobile AP. Also an NSTR mobile AP and an associated non-AP MLD can transmit a frame on the secondary channel only together with the primary channel so this constraint doesn't go well with the EMLSR where it transmits a frame on any available link.
>> The NSTR mobile AP MLD is also an AP MLD, but with some explicitly specified restrictions. So, it is expected to support capabilities unless it is ruled out in the specification. If transmitting on the nonprimary link, the NSTR mobile-AP must transmit on both the links together. But currently, there is no constraint that both links cannot be transmitted to 2 different clients.
Regards,
Sindhu
On Thu, Sep 8, 2022 at 11:02 PM Minyoung Park <mpark.ieee@xxxxxxxxx> wrote:Hi Sindhu,Thanks for the comments.Please see inline below.Regards,MinyoungOn Thu, Sep 8, 2022 at 8:22 AM Sindhu Verma <000011381223f2e2-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:Hi Minyoung,
Thanks for preparing the submission 1434r0
I have some comments on the following proposed changes.
“(#12814)During the frame exchanges, the PPDU format of a Data frame or a Management frame that is transmitted by the AP affiliated with the AP MLD that initiated the frame exchanges shall be the EHT MU PPDU format or the HE MU PPDU format.”
The justification provided is that the switch back to listen operation for an EMLSR non-AP is based on determining PPDUs not addressed to itself and it may be difficult to decode these PPDUs (say the PPDU addressed to another non-AP can be at a higher MCS than what can be decoded by the given EMLSR non-AP due to differences in the SINR). However, the spec does not say that an EMLSR non-AP has to decode a frame not addressed to itself in order to switch back to listen operation. (If you remember, this was arrived at after a lot of discussion) It rather says that if it does not detect any of the following class of frames it shall switch back to listen. So, if the AP transmits a PPDU to another non-AP and the given EMLSR non-AP does not decode it, the EMLSR non-AP shall switch back to listen.
"...the STA affiliated with the non-AP MLD does not detect, within the PPDU corresponding to the PHY-RXSTART.indication any of the following frames:
-an individually addressed frame with the RA equal to the MAC address of the STA affili-ated with the non-AP MLD
-a Trigger frame that has one of the User Info fields addressed to the STA affiliated with the non-AP MLD
-a CTS-to-self frame with the RA equal to the MAC address of the AP affiliated with the AP MLD
-a Multi-STA BlockAck frame that has one of the Per AID TID Info fields addressed to the STA affiliated with the non-AP MLD
-a NDP Announcement frame that has one of the STA Info fields addressed to the STA affil-iated with the non-AP MLD"
So, the premise of the proposal and the corresponding change are not needed.
[MP] The problem is that in such a case it is not clear when the non-AP MLD switches back to the listen operation. There could be following three cases depending on different implementations:- after PHY preamble if the received PPDU is EHT PPDU or HE MU PPDU- after MAC header if it doesn't see it's address- after checking FCS at the end of the received frameIf the received frame is a long Data/Management frame (1-2 msec), in the worst case and for different implementation, the non-AP MLD might have to wait until the end of the frame to check the FCS. Since the AP MLD doesn't know when the non-AP MLDs that are not included as a destination in the PPDU will switch back to the listening operation (due to the ambiguity above), the AP MLD will assume the worst case and cannot use the other link to schedule transmission to the non-AP MLD until the end of the long Data/Management frame.
The resolution to CID 10155 states that “the EMLSR operation in TGbe D2.1.1 is defined between an AP MLD and a non-AP MLD and is not defined for a NSTR mobile AP” I have a concern with this resolution. What kind of non-APs does an NSTR mobile AP support? Only single-link or STR? Because even NSTR is only defined between an AP MLD and a non-AP MLD. As per my interpretation, since an NSTR mobile AP MLD is a kind of AP MLD (as mentioned in its definition), it can support all the AP MLD features other than the ones that are explicitly ruled out in the specification.
[MP] The statement in the resolution seems to be correct. In the current spec, there is no definition for EMLSR operation for NSTR mobile AP. Also an NSTR mobile AP and an associated non-AP MLD can transmit a frame on the secondary channel only together with the primary channel so this constraint doesn't go well with the EMLSR where it transmits a frame on any available link.Some editorial comments: Page 5 “One of the otherA STAs operating on the corresponding one of the other links of the EMLSR links” should be “Any of the other…”. Same comment for a similar change in page 6.
[MP] Will make the change.
Regards,
Sindhu
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