Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
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>
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. 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>
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>
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):
I remember you had some text for start time before. Any reason it was removed?
Regards, Vishnu From: Gaurang Naik <gnaik@xxxxxxxxxxxxxxxx>
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>
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]
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. 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 |