Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi Minyoung, Ming,
The proposed change would mean that a device operating in EMLSR mode is considered to have become blind on one link whenever it has any kind of frame exchange on the other link.
A device in EMLSR mode is capable of doing CCA and listening for certain low data rate messages in parallel on both links. For example, it can (and it must) receive initial control messages in parallel even with partial overlap in time. This same capability can allow such a device to perform CCA on one link even when it receives certain messages (for example messages up to a certain MCS or NSS) on the other link. So, as long as such a device is capable of doing CCA on one link while receiving messages on the other link, why should it be considered to have become blind on the link? Blindness should be governed only by inability to perform CCA.
The only restriction in the current EMLSR specification is that there cannot be full fledged transmission and/or reception in parallel on both links. It doesn’t preclude any other case: for example, the case where a device can do CCA on one link while receiving certain messages on the other link. However, the proposed change seems to be adding this restriction.
So, I am unable to understand the motivation of introducing this change.
Regards,
Shubho
Hi Alfred,Please add the following deferred SP to the MAC call on Thursday(Feb.24):- 11-21/1484r3 CC36 CR EMLSR Medium Sync, Minyoung Park (Intel)I had offline discussion with Ming and resolved his comments and updated to r3:Thanks,MinyoungOn Tue, Jan 4, 2022 at 1:30 PM Alfred Asterjadhi <asterjadhi@xxxxxxxxx> wrote: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, PhDIEEE802.11 TGbe Chair,Qualcomm Technologies Inc.Cell #: +1 858 263 9445Office #: +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
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature