Re: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] TGbe Teleconferences [01/0

Thread Links	Date Links
Thread Prev	Thread Next	Thread Index	Date Prev	Date Next	Date Index

Hi Gaurang,

I am not sure I follow you argument here for point 1. The response to PS-polls, IFS + backoff is applicable for the link which just finished the beacon frame transmission, but my argument also valid for the other links. To elaborate, consider a scenario where an AP MLD operates on two links (link1 and link2) and there is a nonAP MLD operating in EMLSR mode on these two links. Say AP1 of AP MLD is sending a beacon frame on link1 and the STA of EMLSR nonAP MLD associated on link1 is decoding this beacon. After the end of the beacon frame, the EMLSR nonAP MLD requires the EMLSR transition delay to switch to listen mode on all links. During this transition delay, AP2 of the AP MLD should not be sending an initial control frame on link 2 since it will be missed by the nonAP MLD. This is the case that is not covered by your text. In my opinion, same condition should also be applied to link1 (which transmitted the beacon), although the chance of violation can be low, as you mentioned in your response.

Regards,

Vishnu

From: Gaurang Naik <gnaik@xxxxxxxxxxxxxxxx>
Sent: Wednesday, January 19, 2022 8:47 PM
To: Vishnu Vardhan Ratnam <vishnu.r@xxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] TGbe Teleconferences [01/05/2022, and 01/06/2022]: Agendas Posted

Hi Vishnu,

Thank you for your response.

I believe the transition delay right after the transmission of the group addressed frames is not essential. From a non-AP side, it is not guaranteed that it is receiving the group addressed frames, since it can elect to do so on any link. From the AP side, it is anyway likely to be responding to the PS-Polls received from STAs that wake up after seeing BUs in the TIM element. Furthermore, there is IFS + backoff for the AP which would likely take similar order of time as the transition delay.

About the definition of the primary link, the way I see it, if there is a primary link that the STA selects, it must stick to receiving Beacons and group addr frames on that link. Otherwise, the purpose of defining the primary link is defeated. If the primary link is static, it curtails the flexibility of the non-AP MLD. If the primary link is to be changed, we would need to define an update mechanism, which would add unnecessary complexity and would not be in the scope of this CR document. The proposed resolution in doc 1706 keeps things simpler.

Thanks,

Gaurang

From: Vishnu Ratnam <vishnu.r@xxxxxxxxxxx>
Sent: Monday, January 17, 2022 2:44 PM
To: Gaurang Naik <gnaik@xxxxxxxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] TGbe Teleconferences [01/05/2022, and 01/06/2022]: Agendas Posted

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

Hi Guarang,

Thanks for the response.

For your first point, I guess your current text covers the case of when a first frame exchange has already started on an EMLSR link before the start of a group addressed frame reception period on another link. In that case the text suggests termination of the first frame exchange sequence. But it probably doesn’t cover the case when the frame exchange starts after the end of a group addressed frame transmission on another link. The point is that the AP must wait for at least an EMLSR transition delay after the end of a group addressed frame exchange sequence on another link, before transmitting an initial control frame. This part isn’t covered in current set of rules.

Regarding your second point, I am not prescribing to enforce that the EMLSR client only listen to beacons and other group addressed frames on one link, it can indeed be a client implementation decision. Rather, I am saying the spec should enable an EMLSR client to choose to receive beacons primarily on one link, if it desires to do so. If an EMLSR client does choose such a “primary link” for group addressed frame reception, the AP MLD should accordingly prevent overlap of individually addressed frames on any link with the group addressed frame transmissions on only this primary link. As per the current text, the overlap of a frame exchange sequence with group-addressed frames on any link is prevented, which is unnecessary in such cases. The proposed spec rules should at least be generalized to accommodate such optimization.

Regards,

Vishnu

From: Gaurang Naik <gnaik@xxxxxxxxxxxxxxxx>
Sent: Wednesday, January 12, 2022 1:40 PM
To: Vishnu Vardhan Ratnam <vishnu.r@xxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] TGbe Teleconferences [01/05/2022, and 01/06/2022]: Agendas Posted

Hi Vishnu,

Thank you for reviewing the document and for the offline discussions.

I will incorporate the editorial change in the next revision. Thank you for pointing it out.

Regarding initiation of the frame exchange sequence, I think the current statement does imply that AP should not initiate frame exchanges either (in addition to ending it). However, if you think that it needs to be explicitly called out, I can revise the statement.

About the second point, as I mentioned in our offline discussions, a non-AP MLD must have the flexibility to decide which link to receive the Beacons on. Moreover, it cannot be assumed that the non-AP MLD listens to the Beacons on the same EMLSR link each time. The proposed text in document 1706r1 provides a recommendation to the AP to avoid overlaps b/w frame exchanges and group addressed frames on two EMLSR links. If the AP MLD does initiate frame exchanges, then it also provides flexibility to the non-AP MLD to not respond to the initial Control frame. Therefore, the problem you mentioned in your example will not occur.

Thanks,

Gaurang

From: Vishnu Ratnam <vishnu.r@xxxxxxxxxxx>
Sent: Tuesday, January 11, 2022 3:49 PM
To: Gaurang Naik <gnaik@xxxxxxxxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] TGbe Teleconferences [01/05/2022, and 01/06/2022]: Agendas Posted

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

Thanks Gaurang for the draft, discussions and for incorporating some of my offline comments. I still have few more comments (some of which we discussed about before but I want to include here for others’ consideration as well):

Minor grammatical correction: “An AP affiliated with the AP MLD should end frame exchanges initiated with a STA affiliated with the non-AP MLD in one of the EMLSR links at least an EMLSR transition delay, indicated in the EMLSR Transition Delay subfield, before another AP …”
Your text seems to have rules on termination of frame exchanges by AP but not on the start of a frame exchange. Why not also have additional text of the form: “An AP affiliated with an AP MLD shall not initiate a frame exchange with an STA of a non-AP MLD in one of the EMLSR links if:

Either the frame exchange duration is expected to overlap with group-addressed frame transmissions on another EMLSR enabled link or the frame exchange duration is separated from group-addressed frame transmission on another EMLSR enabled link by less than an EMLSR transition delay
and the STA affiliated with the non-AP MLD in the other EMLSR link is expected to receive those group addressed frames”.

I remember you had some text for start time before. Any reason it was removed?

According to your current text, a frame exchange between an AP and a nonAP EMLSR STA will not be feasible if it overlaps with a TBTT on any of the other EMLSR enabled links of the nonAP MLD. Considering a 100ms beacon rate and 3 EMLSR links, this can be very inefficient since many potential TXOPs can be lost, as illustrated in red in the figure below. In particular, a nonAP MLD may decode just one beacon every listen interval (shown in green in the Figure) so preventing TXOP overlap with all TBTTs on all links can be an overkill. Some better mechanism may be required to improve channel access opportunities of EMLSR, especially considering a nonAP MLD doesn’t decode all beacons. One possible option can be that an EMLSR nonAP MLD elects a primary link to receive group-addressed frames on. There needs to be defined a mechanism for the EMLSR client to inform the AP about the same and correspondingly the AP operation would be to avoid TXOP overlap with only group addressed frames on this primary link. I bring this up because this is inherently tied to the resolution of this comment CC6946.

Regards,

Vishnu

From: Gaurang Naik <gnaik@xxxxxxxxxxxxxxxx>
Sent: Monday, January 10, 2022 3:07 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] TGbe Teleconferences [01/05/2022, and 01/06/2022]: Agendas Posted

Hi Alfred,

Could you please queue document 1706r1 to the MAC queue?

All,

Kindly let me know if you have any feedback.

Thanks,

Gaurang

From: huangguogang <000017b1384624cd-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Sunday, January 9, 2022 11:13 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] TGbe Teleconferences [01/05/2022, and 01/06/2022]: Agendas Posted

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

Hi Alfred,

Please add the following contribution to the MAC queue:

11-22-0041-00-00be-Some-issues-on-SCS-operation.pptx

Regards,

Guogang Huang

发件人: Alfred Asterjadhi [mailto:asterjadhi@xxxxxxxxx]
发送时间: 2022年1月5日 5:36
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: [STDS-802-11-TGBE] TGbe Teleconferences [01/05/2022, and 01/06/2022]: Agendas Posted

Hello all,

First of all I would like to wish everybody a Happy New Year!

I uploaded an updated version of the agendas, which contains the agenda for the next conference calls, scheduled on Wednesday January 05 (JOINT), 10:00-12:00 ET and Thursday January 06 (MAC), 10:00-12:00 ET.

The agendas can be found here:

https://mentor.ieee.org/802.11/dcn/21/11-21-1775-18-00be-nov-jan-tgbe-teleconference-agenda.docx

Note for CR documents: Please update the baseline to TGbe D1.31 for the CR documents.

DIAL IN DETAILS FOR WEDNESDAY:

Join the JOINT meeting here: https://ieeesa.webex.com/ieeesa/j.php?MTID=m47e46089d108a8ef448b7a3a11976593

Meeting number: 233 886 75218 Meeting password: wireless (94735377 from phones and video systems)

DIAL IN DETAILS FOR THURSDAY:

Join the MAC meeting here: https://ieeesa.webex.com/ieeesa/j.php?MTID=mff9e3bd94518bedcc608845d389fdd3e

Meeting number: 234 227 52561 Meeting password: wireless (94735377 from phones and video systems)

Let me know if you have any questions and/or suggestions.

Best Regards,

Alfred

Alfred Asterjadhi, PhD

IEEE802.11 TGbe Chair,

Qualcomm Technologies Inc.

asterjadhi@xxxxxxxxx

aasterja@xxxxxxxxxxxxxxxx

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