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

Re: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] TGbe Teleconferences [01/05/2022, and 01/06/2022]: Agendas Posted

Hi Yongho, Ming,

Since Ming has concerns about the addition of the power state, I removed it from 1484r5 and uploaded r6. Let's discuss this part later.

Thanks,
Minyoung

On Wed, Feb 23, 2022 at 11:35 PM Yongho Seok <yongho.seok@xxxxxxxxx> wrote:
HI Ming, 
Well, I think that this is just clarification of the medium access recovery procedure. I know you want to list very specific conditions that the medium access recovery procedure is applied to, instead of a general rule. In such a case, since the baseline spec also has the following very specific texts, I like to remind that we have to follow the NAVSyncDeley rule, for power saving and HE SST operation, unless we don't have a new sentence that can explicitly override the existing NAVSyncDeley rule. That is also the feedback that I heard offline. 

A non-S1G STA that is changing from doze to awake state in order to transmit shall perform CCA until a frame
is detected by which it can set its NAV, or until a period of time indicated by the NAVSyncDelay from the
MLME-JOIN.request primitive has transpired.

Thanks, 
Yongho 

2022년 2월 23일 (수) 오후 10:08, Ganming(Ming Gan) <000017d5b1a95115-dmarc-request@xxxxxxxxxxxxxxxxx>님이 작성:

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.

 

Regards,

Minyoung

 

On Wed, Feb 23, 2022 at 12:50 PM Yongho Seok <yongho.seok@xxxxxxxxx> wrote:

Hi Minyoung, 

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 ... 

 

Thanks, 

Yongho 

 

2022년 2월 23일 (수) 오전 9:35, Minyoung Park <mpark.ieee@xxxxxxxxx>님이 작성:

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.

 

Regards,

Minyoung 

 

 

 

On Wed, Feb 23, 2022 at 5:15 AM Shubhodeep Adhikari <00000c144a46bcee-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:

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

 

 

On Wed, Feb 23, 2022 at 7:01 AM Minyoung Park <mpark.ieee@xxxxxxxxx> wrote:

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,

Minyoung

 

 

On 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, 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


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

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