Hi all,
Members who have more questions on the proposal or voted “No” on this SP today: can you please let us know of your concerns so we can try to resolve them soon ?
Regards,
Dibakar
From: Ganming (Ming) <ming.gan@xxxxxxxxxx>
Sent: Wednesday, December 16, 2020 11:26 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] NSTR blindness issue
Hello Matt.
Thanks for your comments, it seems you agree with concept. The remaining issue is whether we need to describe something. This is the
same as “sync frame operation” in the spec which is also used to address this unknown status of channel. Please refer to the baseline in the SPEC
For a STA that requested for a sync frame transmission,
the UL-Sync capable AP shall schedule a sync frame at the slot boundary of the STA in the RAW if the Time Slot Protection Request field is equal to 1 or the Cross Slot Boundary field is equal to 1,
or at the TWT of the STA, or at the expiration of the wakeup timer, as the next frame for transmission according to the medium access rules specified in Clause 10.
Please see my response inline below.
Best wishes
Ming Gan
发件人:
Matthew Fischer [mailto:00000959766b2ff5-dmarc-request@xxxxxxxxxxxxxxxxx]
发送时间: 2020年12月17日 11:36
收件人:
STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] NSTR blindness issue
1 then another AP (AP 2) of the same AP MLD should
send a Trigger frame to STA-2 soliciting UL PPDU or a modified MU-RTS trigger that allocates time for STA-2
I suggest, at a minimum, changing the SHOULD to a MAY
I would not support SHOULD in this case.
In fact, in either case, should or may, this language does not seem to be needed at all.
The mechanism in 613 only requires that a STA have some sort of ability to:
Within a PPDU TX by STA1, include an indication that STA2 desires to TX
What happens after that is up to the recipient AP and the 613 proposed action of the AP is nothing new - it is behavior that already exists.
I.e. any AP can transmit a trigger or MU RTS to any STA at any time that that AP has gained access to a link.
[Ming] the behavior does not already exist. For example, the AP does not have any schedule for any
STA, so in this case only the request is received, then AP can do this kind of assistance. If AP already has some schedule for that STA, in this case nothing is needed, including that STA contends the channel by using low ED level.
So I request that the entire yellow text be changed to:
A PPDU transmitted by STA 1 may carry a signal (Signaling is TBD) which indicates that STA 2 has at least one MPDU in any of its transmission queues.
Hi Dibakar, Ming and all,
I am generally fine with the motivation of the added text to SP. I have a couple of clarification questions:
1 then another AP (AP 2) of the same AP MLD should
send a Trigger frame to STA-2 soliciting UL PPDU or a modified MU-RTS trigger that allocates time for STA-2
Should send a Trigger sounds vague to me, is the intention to immediately schedule a Trigger?
if the channel is idle, MediumSyncDelay timer is
not 0 and if the AP2 does not have frame exchange already scheduled with another STA
AP MLD is supposed to track the MediumSyncDelay timer of different non-STR MLDs on each link??
Thanks,
Sharan
Hi Pooya,
The highlighted text is from 613r2. That contribution was presented and discussed few months ago.
Regards,
Dibakar
Would you kindly point me to the discussion on the yellow highlighted part? I think this text is discussing
a very different topic and needs more discussion.
Hi all,
We worked offline and tried to converge on a SP text for blindness. The new version
below captures the main aspects of both 1009r4 and 613r2. The highlighted text are the changes relative to r4. Please review and let us know of any comments.
Do you agree to add the following to 11be SFD R1: if during a transmission
of a STA (STA-1) of a non-STR non-AP MLD longer than a TBD duration,
another STA (STA-2) of the same MLD cannot detect its medium state when required (due to STA-1’s UL transmission interference), STA-2 shall start a MediumSyncDelay timer at the end of STA-1's transmission, unless the STA-2 ended a transmission at the same
time:
·
the MediumSyncDelay timer expires after a duration value that is either assigned by AP or specified in spec or if at least either of the following
events happens:
·
any received PPDU with a valid MPDU
·
a received PPDU with a valid TxOP_duration
whichever happens first
·
while the MediumSyncDelay timer is running the STA is only allowed to attempt to initiate up to number of TxOPs assigned by the AP (at least 1) and
shall attempt to initiate that TxOP with the transmission of an RTS frame using regular EDCA backoff using baseline CCA but a TBD ED threshold value
·
The TBD ED threshold value has a default value specified in the spec (e.g., -62dBm) but can also be assigned by the AP MLD within a limited range
such as between -82dBm and -62dBm
·
If the channel was busy immediately after the blind period, additional TBD rules to use RTS may apply.
·
If the PPDU transmitted by STA 1 carries a signal (Signaling is TBD) which indicates that STA 2 intends to send UL frame
after transmission from STA-1 then another AP (AP 2) of the same AP MLD should send a Trigger frame to STA-2 soliciting UL PPDU or a modified MU-RTS trigger that allocates time for STA-2 if the channel is idle, MediumSyncDelay timer is not 0 and if the AP2
does not have frame exchange already scheduled with another STA
Note:
·
If either the intra-BSS NAV or the inter-BSS NAV is non-zero in STA-2 at the end of transmission of STA-1, STA-2 does not transmit any PPDU using
EDCA until the NAV expires.
·
If either the intra-BSS NAV or the inter-BSS NAV is non-zero in STA-2 at the end of transmission of STA-1, there could be further TBD conditions
and requirements to expire the MediumSyncDelay timer.
Regards,
Dibakar
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
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
|