Hello Yongho,
How about the case of doze state? Doesn’t it have blindness issue? Note that we do not have this for NSTR.
Best wishes
Ming Gan
发件人: Minyoung Park [mailto:mpark.ieee@xxxxxxxxx]
发送时间: 2022年2月24日
5:21
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] TGbe Teleconferences [01/05/2022, and 01/06/2022]: Agendas Posted
Hi Yongho,
Sure, we can clarify that.
If anybody has concerns with the change, please let me know.
Can you clarify that the medium access recovery procedure is not applied when the STA operating in the EMLSR link and the PSM mode is a doze state, as the below?
When a non-AP MLD is operating in the EMLSR mode, a STA affiliated with a non-AP MLD
that is operating on one of the EMLSR links
and is in an awake state is considered to have lost medium synchronization ...
Hi Shubhodeep,
Thanks for the comment. I revised the document to r4, keeping the original text 'if it is not able to perform CCA' to address your comment:
Also updated the document based on feedback from Liuming, Yongho, and Ming.
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:
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:
--
Qualcomm Technologies Inc.
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
This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom
it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail
to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete
it from your computer, and destroy any printed copy of it.
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
|