Hi Matt,
Thanks for lengthy response.
Please see my response inline.
Best regards,
Wook Bong Lee
From: Matthew Fischer [mailto:matthew.fischer@xxxxxxxxxxxx]
Sent: Monday, September 28, 2020 1:01 PM
To: Wook Bong Lee <wookbong.lee@xxxxxxxxxxx>
Cc: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx; Srinivas Kandala <srini.k1@xxxxxxxxxxx>; Sharan Naribole <n.sharan@xxxxxxxxxxx>
Subject: Re: [STDS-802-11-TGBE] 答复:
[STDS-802-11-TGBE] 答复: [Suspected Marketing
Mail] Re: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE]
Comments on 11-20-1395-00-00be-pdt-mac-mlo-multi-link-channel-access-general-non-str
There are several elements in several frames that are used by several features/functions in the MAC to provide for:
1) an indication from one STA to another STA of maximum TX power
2) an indication from one STA to another STA of various limits on TX power, e.g. regulatory and maybe AP/BSS imposed
3) there are some exchanges that allow a STA to say "I just used TX power value X in a frame that I just sent to you or in this very frame"
There are no statements that I can think of to say that a STA shall use a specific value of TX power, other than, a STA shall NOT use a TX power that is beyond some TX power limit, e.g. regulatory limits that the
STA is aware of, plus limits indicated to the STA through usually, AP signaling.
An exception to that statement is that when an 11ax AP sends a trigger to an 11ax STA, it can specify a "Target RSSI" value for each STA.
This is a means for the AP to sort of suggest a TX power to the STA, but it is not a SHALL.
So I agree that in general, it is well within the allowance of the standard for a STA to use any power it chooses that obeys the few rules regarding maximums.
[WB] Thanks for confirmation. No signaling a STA to use a certain (absolute) transmit power level. For TB PPDU, it is relative power level and it is within an STA’s maximum power level it internally determined.
So let's compare NSTR with TX EVM.
For TX EVM, you place an upper bound on a measurable parameter and then you can say:
For constellation A, the maximum measurable parameter value is Z
For constellation B, the max param value is Y
This allows the STA to fiddle with a dozen TX parameters to ensure that Y is met at each MCS.
For each constellation, the TX power parameter might be different, and it is up to the STA to choose values as it pleases, so long as the objective TX EVM is met.
For other PHY parameters and requirements, the situation is similar.
I.e. there is some measurable outcome with a limit value and one or more free variables which may be altered so long as the limit is not exceeded.
[WB] OK. For transmission in one link, PHY is changing its power level to meet those requirements. In case of multiple links, it should be the case for each link perspective, right?
No one wants to lose its range. This is why we try to maximize its transmit power level as long as it meets requirements. This is why we uses different power level for different modulation and bandwidth.
So what do we have for NSTR?
NSTR means: "while transmitting on linkA, reception fails on linkB"
To start, we must define "failure on linkB."
Once receive failure is defined, then we can attempt to define relationships between those failures and transmissions on other links
So what does it mean to have a receive failure on linkB?
Well, we could say that we would like to receive the following:
Of course, that is one choice of many - we could vary any of those RX parameters!
And then we need to choose a transmission on linkA where we have exactly the same problem of choosing among several parameters:
TX power min of (max permitted, max capable)
So, for this situation, we do not have a singular parameter with a single limit or even a single table of values corresponding to a set of values for a single parameter.
For this situation, you would need to have a multi-dimensional table for each of the input and output
That is the dynamic specification that some people have advocated, but as you can see, depending on how many parameters are included, the dimensions of the matrix could yield a large table.
And, that's just for one link pair
If a STA has several links that have relationships, then there is another multi-dimensional matrix for each pair
Note also that for the "other STA" to make use of this advertised information, that STA would have to determine which particular TX parameters were in use on linkA.
Some of those are easily obtainable, e.g. MCS
Others might or might not be simple to obtain, e.g. which STA is transmitting on linkA
And some are not easy, e.g. TX power of the signal on linkA
So, for the moment, the group consensus seems to be:
1) include a single point of the multitude of possible reception parameters and a single point from the matrix of possible transmission parameters to provide for a singular indication of NSTR or not for a given
pair of links
2) spend more time later to figure out how much additional information to provide, if any
An argument against any specification that goes beyond the singular point in the matrix (or at least, an argument for keeping that as optional):
One thing to note is that if there is any TX interference on a neighbor link, it is quite possible that altering the available parameters on TX and RX does not move "the interference needle" very much anyway.
E.g. if at full TX power a TX on linkA causes the noisefloor on the NSTR link to rise by 50 dB, then would it be possible for the other STA to lower the MCS enough for an RX to be correctly received?
For example, if an NSTR non-AP STA transmitted full power to an AP on linkA and the AP wanted to TX DL to the same NSTR non-AP on linkB, then would it be possible for the AP to lower the MCS enough to have the DL
be decoded correctly?
That would require that the AP signal at the non-AP STA would have to be around -40 dBm
That can happen, but it is not likely.
And even if it did happen, if you were the AP, that's probably not the choice that you would make
I.e. as an AP, if you saw the UL TX from NSTR STAx on linkA, and you had a chance to TX on linkB
then as the AP, if your choice is:
a) TX MCS0 to NSTR STAx on linkB
b) TX MCS9 to STAy on linkB
You'd be smart to choose b)
And there are other choices to be made:
on the NSTR STAx side - would that STAx reduce the UL TX power on the linkA transmission in order to reduce the impact on the NSTR affected linkB?
e.g. if TX on linkA causes a noisefloor of -45 on linkB, then maybe NSTR STAx instead uses TX power 15 dB lower so that the noisefloor on linkB is -60
Again, I would suggest that reducing the TX power is a bad choice
a) moving from noisefloor of -45 to -60 is still not going to leave much SINR for the AP DL RX for most locations of most non-AP mobile STAs
b) the NSTR STAx would, with a TX power reduction of 15 dB, drop MCS by many steps so that TPUT would be dramatically reduced, and this reduction would be made in hopes that there would be some DL RX to make up
for the loss - but there's no guarantee that the AP would send a DL to NSTR STAx during that time - the AP has his own choice to make and again, he'd much rather send an MCS9 to some other STA than an MCS1 to STAx - and that's if the AP happens to have won
medium access on linkB at that time - so it's a low probability choice to make - a bad tradeoff
So the best thing to do is to have a simple binary signal that says, effectively - really, don't bother trying to TX to me on linkB when I am TX to you on linkA
[WB] Agreed. I don’t think we want to simply reduce Tx power to meet STR requirement. It will reduce its range on one link. Bad choice.
Again. I am not arguing about whether we want to go for binary signaling or not. I am arguing about the maximum transmit power level on P20 to be used in all other bandwidth.
Will write one more time. What is maximum power level here? Why we are not allowing smaller power level for higher bandwidth as we normally do it now for single link transmission?
But I am happy to write up text later, during comment resolution to add optional signaling of as much matrix of TX and RX conditions as the group would like.
[WB] Then, can we at least the below text TBD?
An MLD which has a pair of links for which the transmission by the STA of the MLD on one of the links of a PPDU
using the maximum allowed transmission power
on the primary 20 MHz channel of the BSS using
any PPDU bandwidth permitted within the BSS that the STA is capable of transmitting causes the inability of the STA of the MLD on the other link to meet the minimum receive sensitivity requirement defined
in 34.w.x.y (Receiver minimum input sensitivity) shall indicate the pair of links as NSTR by setting the TBD field in the TBD elements that it transmits.
Hi Matt,
Thanks for the discussion.
I have no strong opinion on whether NSTR or STR being dynamic or not.
I am actually fine with static when an STA joins the network (or BSS) for R1 at least.
One problem, again for me, is how to determine whether it is NSTR or STR by using max power.
As far as I know, we never say an STA shall use a certain level of absolute power to do something.
In PHY, we define all requirements based on whatever TX power an STA chooses.
E.g. TX EVM, unused tone EVM, spectral mask, you can name it.
In most implementation, we adjust the transmit power level to meet a certain requirement.
I am not a MAC guy, so not familiar with all of the frames/information you mentioned below as maximum
power level.
So, please educate me if there is a maximum transmit power level an STA shall use for transmission.
(Not the maximum transmit power level an STA shall not exceed.)
If there is such a maximum transmit power level, then we can use it as a requirement for the NSTR/STR
test.
Best regards,
Wook Bong Lee
From: Matthew Fischer [mailto:00000959766b2ff5-dmarc-request@xxxxxxxxxxxxxxxxx]
Sent: Friday, September 25, 2020 6:46 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 答复:
[STDS-802-11-TGBE] 答复:
[Suspected Marketing Mail] Re: [STDS-802-11-TGBE] 答复:
[STDS-802-11-TGBE] Comments on 11-20-1395-00-00be-pdt-mac-mlo-multi-link-channel-access-general-non-str
I believe that many people are pointing out the same issue and I believe that the group has suggested a resolution to that issue, but perhaps not yet agreed
to it.
Specifically, many people are commenting on the problematic nature of having a single specific set of parametric values for which to establish whether or
not a pair of links is NSTR, as the group has agreed that NSTR-ness will be communicated/signaled to other STAs.
I believe that nearly everyone agrees that if the parameters are modified in either direction from those values that appear in the current revision, it
could mean that the NSTR-ness of the link pair disappears or arises where it had not been before, i.e. that the NSTR-ness of a pair of links is dynamic v some set of parameters.
I believe that we have all known this to be true from the beginning, and it is not and never has been, a point of disagreement.
The question is: How, in the signaling and/or definition of when a link is NSTR, do you accommodate the dynamic/variable nature of the NSTR-ness of a link
pair?
While there has been some suggestion of something more sophisticated to convey the dynamic nature of NSTR, it appears that the consensus for now is to have
capability signaling of only a binary indication of NSTR-ness of a pair of links.
For that indication to be useful to the recipient of the information, there has to be some specific, parametric meaning to the information and that is why
a specific set of information has been provided, e.g. 20 MHz, max TX power, etc. And given that the signaling is binary (NSTR or NOT NSTR), then there can only be a singular parametric inflection point for determination of NSTR-ness.
That's how we ended up where we are now.
At this point, we can all either agree that:
we need to add, in the capability signaling PDT, at least a placeholder for more sophisticated variable NSTR-ness information, e.g. perhaps an indication
of the amount of signal coupling between the transmitter and the receiver chains
-Some have remarked that they do not want to give away such secret implementation information, but this information would be optional, don't TX if you don't
want to
-I don't think that anyone has settled on any specifics here yet
we do not need to add anything now because any necessary modifications to account for the dynamic nature of NSTR will probably be complex and it will take
time to agree to something and therefore such possible additions are best left to be resolved in the future, which is quickly approaching
As for maximum TX power, that might be modified to the value from the "Max Transmit Power field" of an RRM frame
But there are many TX power fields to consider, but in spite of that, I offer a quick attempt:
replace "maximum transmit power" with:
the maximum transmit power as determined by examining the values in the following elements and frames, if transmitted or received by the STA, as applicable:
9.4.2.8 Country element (Maximum Transmit Power Level field)
9.4.2.13 Power Constraint element
9.4.2.161 Transmit Power Envelope element
9.6.7.10 DSE Power Constraint frame format
9.6.7.30 Network Channel Control frame format
(There are probably more.)
Here's an example of one of them to show how quickly it becomes very complicated:
9.6.6 Radio Measurement action details
9.4.1.19 Max Transmit Power field
The Max Transmit Power field is a 2s complement signed integer(#4696). It provides an upper limit,
in units of dBm, on the transmit power as measured (#4448)at the antenna connector
to be used by the
transmitting STA on the current channel. The Max Transmit Power value has a tolerance of ±5 dB. See
11.10.13 (Operation of the Max Transmit Power field). The Max Transmit Power field is shown(#243) in
Figure 9-103 (Max Transmit Power field format(#2607)).
Using this field would require the use of RRM - what if a STA does not support RRM?
What if it supports RRM and TPC and DSE?
Will all of those values mate up properly? Will they contradict each other? How does one resolve the complete set of information?
And what if it is a non-AP that advertises a max TX power but then is limited by the AP?
The text that is needed to specify the value would depend on the status of the implementation's implementation of many different protocols.
So again, I believe that we all agree on all of this (maybe we do not)
The open questions in my opinion are:
What additional signaling will be provided (e.g. how many additional parameters or values, e.g. power
per MCS, dB of coupling at BW X)?
What signaling is required v optional?
How does one choose from among the various TX power indications and limits that are signaled by both
ends of the link?
Does anyone think that it is possible to get all of this right in just a few days?
Can we instead move all of this to the "clean up the 0.1 draft" phase of the TGbe program?
Someone might respond by saying that we should also then throw out the singular parametric point that
exists today in the document.
That's also a possibility.
But the more that we do that, the less material that we have in 0.1 and pretty soon, it's just a bunch
of statements like:
A STA shall indicate within TBD elements that it transmits, if a pair of links is NSTR by setting the TBD fields to the value TBD when TBD conditions are
true.
And actually, that's sort of what was in a previous revision, but the majority seemed to be begging for something more, hence the latest revision.
I'm happy either way.
I agree with Dibakar. The principle of definition is if under at least one case a pair of link is NSTR,
then this pair of link is NSTR. But the definition doesn’t disallow NSTR link pair perform STR operation to increase the efficiency under TBD condition. Additional information could be provide to identify the conditions.
Regards,
Yunbo
发件人:
Das, Dibakar [mailto:dibakar.das@xxxxxxxxx]
发送时间:
2020年9月25日
7:59
收件人:
STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题:
Re: [STDS-802-11-TGBE] 答复: [Suspected Marketing Mail] Re:
[STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] Comments on 11-20-1395-00-00be-pdt-mac-mlo-multi-link-channel-access-general-non-str
The STA is part of NSTR link pair if at least in one config of BW, Txpower,.. it is NSTR. So, naturally it makes
sense to use the max tx power (normalized over 20 MHz BW) or otherwise.
If that STA is now willing to inform the AP that helps the AP identify some configs in which it can be STR, then
it can operate as STR for those configs.
Hi Dibakar,
As I mentioned in my e-mail, the biggest problem for me is max allowed tx power.
If a STA can’t transmit maximum allowed tx power, then the STA can only be NSTR no matter what?
Best regards,
Wook Bong Lee
From: Das, Dibakar [mailto:dibakar.das@xxxxxxxxx]
Sent: Thursday, September 24, 2020 4:12 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 答复:
[Suspected Marketing Mail] Re: [STDS-802-11-TGBE] 答复:
[STDS-802-11-TGBE] Comments on 11-20-1395-00-00be-pdt-mac-mlo-multi-link-channel-access-general-non-str
The requirement text should be the opposite way. When using max TX power on one link, if no problem
in receiving on other link, MLD can declare STR. All other cases should be considered NSTR if we are going to have such requirements in spec.
è
I believe that’s what Matt is proposing.
Hi Dibakar, Wook Bong, Payam and all,
I agree with Wook Bong and Payam about the declaration instead of explicit requirement.
@Dibakar: Reviewing the current “requirement” text, it is not aligned with what you are stating.
Current text is indicating only when using Max TX power on one link, if there is an issue on receiving
on other link, then declare NSTR. What if when using lower TX Power, you still have issue. Is it OK to declare as STR?
The requirement text should be the opposite way. When using max TX power on one link, if no problem
in receiving on other link, MLD can declare STR. All other cases should be considered NSTR if we are going to have such requirements in spec.
Thanks,
Sharan
From: Das, Dibakar [mailto:dibakar.das@xxxxxxxxx]
Sent: Thursday, September 24, 2020 3:41 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 答复:
[Suspected Marketing Mail] Re: [STDS-802-11-TGBE] 答复:
[STDS-802-11-TGBE] Comments on 11-20-1395-00-00be-pdt-mac-mlo-multi-link-channel-access-general-non-str
Hi Wook Bong,
According to this definition, if the STA pair becomes STR in some tx/rx configs (BW, Tx power, ..) but not in all,
it is considered a NSTR link pair.
Such STAs shall be expected to be treated as NSTR by the AP unless it provides additional optional information informing
the AP of the configs in which it can still be STR. That’s not precluded by the definition.
Regards,
Dibakar
From: Wook Bong Lee <wookbong.lee@xxxxxxxxxxx>
Sent: Thursday, September 24, 2020 3:30 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 答复: [Suspected Marketing Mail] Re: [STDS-802-11-TGBE]
答复: [STDS-802-11-TGBE] Comments on 11-20-1395-00-00be-pdt-mac-mlo-multi-link-channel-access-general-non-str
Hi Payam and Matt,
I agree with Payam. For me, declaration sounds better.
Later, if we want to ensure performance, then we can define requirement in PHY.
But if members want to define requirement as in below, then I would like to clarify the meaning of
maximum allowed transmit power.
An MLD which has a pair of links for which the transmission by the STA of the MLD on one of the links of a PPDU
using the maximum allowed transmission power
on the primary 20 MHz channel of the BSS using
any PPDU bandwidth permitted within the BSS that the STA is capable of transmitting causes the inability of the STA of the MLD on the other link to meet the minimum receive sensitivity requirement defined
in 34.w.x.y (Receiver minimum input sensitivity) shall indicate the pair of links as NSTR by setting the TBD field in the TBD elements that it transmits.
Let’s say maximum allowed transmission power level is 23dBm. But for some reason a STA can transmit
only 18dBm.
With 18dBm on one link, the STA meets the minimum receive sensitivity on the other link.
In this case, the STA can indicate it is STR link or not?
Moreover, for some cases, a STA is transmitting smaller power for 40/80 MHz PPDU than it can use for
20 MHz PPDU.
Best regards,
Wook Bong Lee
Question is whether NSTR relationship is by declaration. I doubt if implementations could (or should) change the
relationship based on dynamic (txop level) bandwidth and power adjustments. I think declaring the relationship could work (and it doesn’t mean it cannot change during the links lifetime, it’s just declared differently again somehow), and a simple definition
such as following could be sufficient. The “decided/declared by MLD” part can be part of the text/behavior.
Non-simultaneous transmit and receive (NSTR) link pair:
A pair of links of a multi link device (MLD) for which ability to receive a PPDU on one link can be degraded during any transmission in the other link
Hi Matt,
Thanks for your effort.
An MLD which has a pair of links for which the transmission by the STA of the MLD on one of the links of a PPDU using the maximum allowed transmission power on the primary 20 MHz channel of the BSS using any PPDU bandwidth permitted
within the BSS that the STA is capable of transmitting causes the inability of the STA of the MLD on the other link to meet the minimum receive sensitivity requirement defined in 34.w.x.y (Receiver minimum input sensitivity) shall indicate the pair of links
as NSTR by setting the TBD field in the TBD elements that it transmits.
First of all, I think below sentence is touching PHY requirement, and thus need to discuss in PHY or Joint.
Second, what is the maximum allowed transmission power? Is it determined by an AP or regulatory domain?
Third, what if a STA is not transmitting in that much power for some reason? What if the STA determined to use smaller power in order not to disturb
the other link performance?
Best regards,
Wook Bong Lee
From: Matthew Fischer [mailto:00000959766b2ff5-dmarc-request@xxxxxxxxxxxxxxxxx]
Sent: Monday, September 21, 2020 12:29 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 答复:
[Suspected Marketing Mail] Re: [STDS-802-11-TGBE] 答复:
[STDS-802-11-TGBE] Comments on 11-20-1395-00-00be-pdt-mac-mlo-multi-link-channel-access-general-non-str
Thanks to all who have commented.
It's a complicated topic.
Here is a consolidated set of replies:
Feel free to read any or all or none, each of which is identified by the commenter:
See R12 for any referenced changes:
The question of MU-RTS, as you noted, is not addressed by the motion, and therefore, remains unaddressed by the PDT
The questions regarding the last two paragraphs were resolved by SP during the SEP 21 CC
Definition: presence of "requirements" therein - this point was discussed during the SEP 21 CC and is addressed in a new revision by modifying the definition
Definition wording/inclusion of too many details - the specific requirements have been moved to the 33.x.y.3 subclause and remain intact
The reason for the complete set of details is due to some discussion that occurred after the previous CC presentation
Basically, all of the items mentioned can have in influence on the NSTR-ness of a pair of links
I.e. a pair of links might be NSTR given:
a) one value of TX power, but not at another
b) one PPDU width vs another PPDU width
use of the term "RTS link" - agreed that there is no formal definition for this term - I have reluctantly changed it to "the link on which the RTS was received"
which uses many more words and makes the bullet item harder to read due to its length, but is more correct
10.3.2.9 CTS - proposal to remove the first bullet "the STA is affiliated with an MLD that has at least one NSTR link pair"
Previous discussion had not only suggested keeping the first bullet, but adding the phrase "that has NSTR link pairs"
I.e. I agree with you that it is implied that if the second bullet says that the RTS has to be received on one or more of the MLD's NSTR link pairs, then
there must be at least one NSTR link pair in order to satisfy this bullet, and that only an MLD can have even one link pair, but others disagreed - so it is not me that you have to convince, but everyone else
Your comment on the second paragraph of 33.x.y.3 suggests that the behavior is described for an STR, not NSTR device.
You have assumed that NSTR means "It is impossible for an NSTR device to transmit on linkA while receiving on linkB." but this is not correct.
An NSTR device may transmit on LinkA while receiving on linkB, the difference between STR and NSTR is that for STR, there are NO consequences to TX while
RX, but for NSTR, there are potential consequences.
The group has never suggested that an NSTR device SHALL NOT TX while RX on the other link
So, TX during RX for an NSTR device is allowed, possible and addressable
Regarding the wording of: An AP of an MLD should not transmit to an NSTR STA if that NSTR MLD is transmitting on the other link of an NSTR link pair
Your comment is that it is much easier for a device to take a directed action based on reception at its own antennas rather than based on transmission at
the antennas some other device
I understand the general nature of the comment but there are many cases for which the reception at the AP might yield either no information or fuzzy information
a) there might be a transmission by the non-AP which is undetected by the AP due to overlapping signal
b) there might be reception activity at the AP which is not correctly decoded, even at the PHY header, due to interference or overlapping reception
c) there might be a valid PHY header which provides COLOR and AID information that might indicate that STAx is the transmitter, but that information can
be incorrect because of color collision or incomplete AID information, etc.
d) there might be a valid phy header, but invalid MPDU header information
e) MPDU header information might not be available until near the end of a PPDU, meaning that the AP would have to wait until there is no activity whatsoever
on the other link
f) The AP might not want to wait to determine which STA is the transmitting source
I.e. the AP is provided with a choice, due to the use of "should" instead of "shall" and therefore, the conditions do not need to be exact
NSTR definition complexity:
The complexity is reduced by reverting to a reference, but the elements of that definition remain in the new paragraph in the behavior subclause for the
reasons stated earlier in this email
If you feel that some aspect of TX RX alignment is needed in the definition (which is now specified in the behavioral subclause), then please provide some
text suggestion.
As suggested during the CC, there is no single "CCA sensitivity", there are at least three components to CCA:
b) RX minimum sensitivity
We could add something about ED, but the RX min sens item is a stricter requirement, so I believe that ED is not needed, unless you want to make the definition
looser
i.e. right now, a link pair is NSTR if you cannot RX MCS0 at -82, i.e. your link-link interference must be about -85
It is my assumption that if you CAN RX MCS0 at -82, then you certainly can also do ED at -62, confirmed by the idea that the interference is -85, implying
that a random signal at -63 or even down to -80 would trigger ED
If you want to mention the ED part, then you would say:
a link pair is NSTR only when you are NOT able to perform ED at -62, which means that your link-link interference must be about -62 which is clearly demanding
a lot less of a device
I.e. that's a looser requirement for NSTR - i.e. an MLD remains able to call itself STR for an additional 20 dB of cross link interference
i.e. a worse-performing MLD could still be called STR
Hi Matt and all,
I have below comments for Matt’s updated definition about NSRT link pair.
1)
The last version in R9 only mentioned
“causes an impaired ability to receive a PPDU”,
it is not clear what does impaired ability exactly means. In the latest version in R10, it is much clear what the inability means. So the STA MLD will know what’s
the exact rule to follow when it report the STR capability. So I more prefer the updated version.
2)
Response to Jay’s question.
I think the main factors already mentioned in Matt’s definition. Power (the
maximum allowed transmission power), bandwidth (any PPDU bandwidth)
and MCS (Receiver minimum input sensitivity is MCS related).
3)
Besides minimum receive sensitivity level, I think the CCA sensitivity level should also be considered in the definition. The reason is receive sensitivity level is considered from the angle that the STA MLD
receive a packet. But CCA sensitivity is considered from the angle that the STA MLD do channel contention. I think when either one is affected by the transmission on another link, it should be defined as NSTR link.
Matt, do you think the 3rd comment is reasonable to considered?
Regards,
Yunbo
发件人:
Yang, Zhijie (NSB - CN/Shanghai) [mailto:zhijie.yang@xxxxxxxxxxxxxxx]
发送时间: 2020年9月19日
6:44
收件人:
STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE]
[Suspected Marketing Mail] Re: [STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] Comments on 11-20-1395-00-00be-pdt-mac-mlo-multi-link-channel-access-general-non-str
Hi Dibakar,
A general question, why we thought TX power & RX sensitivity is the mainly factor to cause the NSTR issue? I think there are other factors to cause such issue as well, such as TX
&RX synchronization mechanism due to the PHY design. And I doubt whether it’s correct or not if we thought the TX power & RX sensitivity is the only one factor in the new definition.
Thanks
Best Regards
Jay Yang
Hi Jay and Yonggang,
The previous text was unclear about whether STR/NSTR link pair is defined per PPDU or for the entire operation. The new text clarifies that this definition does not change from
PPDU to PPDU. As such it is a step in the right direction.
Regards,
Dibakar
From: Yang, Zhijie (NSB - CN/Shanghai) <zhijie.yang@xxxxxxxxxxxxxxx>
Sent: Friday, September 18, 2020 7:20 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] [Suspected Marketing Mail] Re: [STDS-802-11-TGBE]
答复: [STDS-802-11-TGBE] Comments on 11-20-1395-00-00be-pdt-mac-mlo-multi-link-channel-access-general-non-str
Hi Matt,
Agree with Yonggang, the NSTR definition is too complicated compared with the previous version. I think we could use some general sentence to define it in initial version, and then
enhance it in the further if necessary. For the factors like Max TX power and min RX sensitivity, we could use a note to cover them temporarily.
Thanks
Best Regards
Jay Yang
From: Yonggang Fang <yfang@xxxxxxxxx>
Sent: 2020年9月18日
12:08
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [Suspected Marketing Mail] Re: [STDS-802-11-TGBE]
答复: [STDS-802-11-TGBE] Comments on 11-20-1395-00-00be-pdt-mac-mlo-multi-link-channel-access-general-non-str
Hi Matt,
Thanks a lot for your effort on preparing the PDT. I have some comments on the 1395r10.
1) "Non-simultaneous transmit and receive (NSTR ) link pair:
A pair of links of a multi link device (MLD ) for which the transmission by a STA of the MLD on one of the links of a PPDU using the maximum allowed transmission power on the primary 20 MHz channel of the BSS using any PPDU bandwidth permitted within the BSS
that the STA is capable of transmitting causes the inability of the STA of the MLD on the other link to meet the minimum receive sensitivity requirement defined in 34.w.x..y (Receiver minimum input sensitivity). Each link of such a pair is a member of the
NSTR link pair."
a) Does the spec allow to refer to the requirement in the definition?
b) This definition of NSTR is too complicated. Your previous definition of NSTR before R8 is much simple and clear. Why is it necessary to add such condition in the NSTR definition? It would
be better to describe those conditions in the NSTR ML setup and operation.
2) RTS link
There is no definition for RTS link. Suggest to change to the link that carries the RTS frame or other words.
3) "In this subclause
, a STA is NSTR limited if all of the following conditions are true:
-
the STA is affiliated with an MLD
that has NSTR link pairs
-
the STA
has received the RTS on a link that is a member of one or more
of the MLD
’sNSTR
link pairs
-
a
STA of the MLD is a TXOP holder or TXOP responder
on one of the other links
that is a member of
at least
one of the NSTR link pairs
of which the RTS link is a member"
The first bullet is not necessary as it has been covered by the the second and third one.
4) "A STA that is affiliated with a non-AP MLD and that transmits a frame on a link of
one of its NSTR link pairs at the same time that another STA affiliated with the same non-AP MLD
is receiving a frame on the other link of the NSTR link pair should ensure that the transmitted PPDU ends at the same time or earlier than the PPDU that is being recevied ."
a) It seems this sentence describes the case of STR not for NSTR . Could you please clarify this sentence ?
Best Regards
Original Mail
Subject: Re: [STDS-802-11-TGBE]
答复:
[STDS-802-11-TGBE] Comments on 11-20-1395-00-00be-pdt-mac-mlo-multi-link-channel-access-general-non-str
Based on discussion during and after presentation during a recent TGbe session, additional changes have been made to 1395 N-STR operation.
Details of what changed in R10 (and previous revisions) can be found at the top of the document
In particular, despite my assertion that no good would come of any attempt to make the definition of NSTR "inability to receive" specific to some set of
parameters, I was convinced by various commenters to believe that it was better to establish a specific set of parameters to define NSTR receive impairment including a relationship to the RX minimum sensitivity specification and those things are now included
in the definition of NSTR . I.e. if the decision about whether to label a pair of links as NSTR is implementation dependent, then the information is less useful as the recipient of that information cannot be certain of exactly what it means.
Note that these changes were made with the assumption that additional parameter values could be provided within capability signaling, e.g. the NSTR -ness
of any two links could be dynamic based on the values of those parameters, e.g. TX power, TX BW and PPDU location within the operating channel.
I am blaming my computer for having lost track of your email - my machine had rebooted a couple of times in the last couple of days.
As for your comments - I believe that you were able to bring each of your points up during the presentation Monday PDT, and I responded.
I've included a summary here:
As discussed, I believe that there can never be a specific definition - the best that it can say is "transmission on one link causes receive impairment
on the other link of the pair"
2) "transmit and receive" v "transmission and reception"
Agree to settle on one phrase - currently chose "transmit and receive" - see r9
3) phrasing, "not respond with CTS " v "may respond with CTS "
The convention is "may respond" - this implies that it is ok to NOT respond, this is how the standard is always written
I.e. we never say "a STA may not do something"
4) NSTR non-AP MLD should align PPDU
your comment is that this is not in the motion
I agreed on the call that we should SP this text after the body has had some time to think about whether the recommendation "should" is acceptable here,
and noting that the motion was very broad in simply stating that the behavior of the NSTR MLD needs to be specified
Hi Matt,
Sorry for my network problem during the teleconference. Please find my comments attached.
Regards,
Yunbo
发件人:
Matthew Fischer [mailto:00000959766b2ff5-dmarc-request@xxxxxxxxxxxxxxxxx]
发送时间:
2020年9月5日
9:45
收件人:
STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题:
Re: [STDS-802-11-TGBE] Comments on 11-20-1395-00-00be-pdt-mac-mlo-multi-link-channel-access-general-non-str
On 1) - I understand the reason for your different interpretation.
Maybe it would be better as:
If all of the conditions of the previous paragraph are met, except for "the STA is not NSTR limited"
Would that make it more clear?
If all of the conditions of the previous paragraph are met, except for the condition "the STA is not NSTR limited"
link set should be describable as a set of links rather than a pair - there is no reason to limit it to only 2 links
and yes, the assumption is that all links in the set are NSTR to each other - I thought about whether any asymmetry could exist and it seemed pretty implausible to
me
on the CTS response extra condition - you're not reading it correctly
if says, if all of the conditions of the preceding paragraph are met EXCEPT - so you have to reread it as - the only condition that failed in the paragraph
was that the STA was NSTR limited
if that is true, then it cannot be the case that an STR STA reaches this point
Hi Matt,
Please find my comments attached
From: Matthew Fischer <00000959766b2ff5-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Friday, September 04, 2020 4:54 PM
To :
STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] Comments on 11-20-1395-00-00be-pdt-mac-mlo-multi-link-channel-access-general-non-str
I've made a small addition.
I've added another AP should not transmit to an NSTR MLD in the case of when the AP might be able to determine that some STA of the NSTR MLD is actively
transmitting to anybody else (i.e. currently, it only mentions transmitting to the AP, because that's easy for the AP to figure out) but it is possible that maybe the AP can see the non-AP transmitting for example, a P2P on a link and the AP might be able
to decode the EHT PPDU header AID and Color or something in the MAC header that tells it that this is a TX by the non-AP MLD and if it can do that, then again, the AP should not TX to that NSTR non-AP MLD - so this new should not applies only when the AP is
able to make that determination.
Dear Matthew and Kaiying ,
I saw R2, and it seems to reflect SFD well.
Thank you for your hard work.
Best Regard,
Sanghyun Kim
Sanghyun Kim, Ph.D
WILUS Inc.
5th Fl., 216 Hwangsaeul-ro Bundang-gu,
Seongnam-si Gyeonggi-do 13595, Korea
T +82 31 712 0523
www.wilusgroup.com
-----Original Message-----
From: "Kaiying Lu"<Kaiying .Lu@MEDIATEK .COM>
To: <STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx>;
Cc:
Sent: 2020-09-04 (금)
03:41:52 (GMT+09:00)
Subject: Re: [STDS-802-11-TGBE] Comments on 11-20-1395-00-00be-pdt-mac-mlo-multi-link-channel-access-general-non-str
Hi Matt and Sanghyun ,
I agree with Sanghyun ’s comment. The SFD gave the condition on which the responder is allowed to make a choice. But the condition is that
the another STA affiliated with the NSTR MLD is participating an TXOP on that link. Without this condition, the NSTR responder shall respond CTS if NAV is idle on this link.
I think the draft text should reflect this condition.
Thanks,
Kaiying
From: Matthew Fischer [mailto:00000959766b2ff5-dmarc-request@xxxxxxxxxxxxxxxxx]
Sent: Thursday, September 3, 2020 11:00 AM
To :
STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] Comments on 11-20-1395-00-00be-pdt-mac-mlo-multi-link-channel-access-general-non-str
text does not cover “the STA may not respond with a CTS frame."
of the SFD . (We need some “may” for a STA with NSTR contrained )
a. I agree that the SFD says "may" not respond, which appears to allow for the responder to make a choice
b. I agree that doc 1395r0 does not provide a choice to the responder , but instead, always dictates, depending on conditions, that there either shall or shall not be a CTS
When reading the SFD , I assumed that the language was imprecise.
I will create a version which provides the choice as an alternative, assuming that the SFD expresses exactly what the body desired, i.e. that the responder has a choice.
Dear Matthew,
Thanks for preparing the text.
Please find attached comments.
Best Regards,
Sanghyun Kim
Sanghyun Kim, Ph.D
WILUS Inc.
5th Fl., 216 Hwangsaeul-ro Bundang-gu,
Seongnam-si Gyeonggi-do 13595, Korea
T +82 31 712 0523
www.wilusgroup.com
-----Original Message-----
From: "Liuming Lu"<lu.liuming@ZTE .COM.CN>
To: <STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx>;
Cc:
Sent: 2020-09-03 (목)
11:26:26 (GMT+09:00)
Subject: [STDS-802-11-TGBE] Comments on 11-20-1395-00-00be-pdt-mac-mlo-multi-link-channel-access-general-non-str
Hi Matthew,
Thanks for the preparation for the pdt-mac-mlo-multi-link-channel-access-general-non-str.
I have some comments. Please see the attached file.
Best Regards,
Liuming Lu
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
*********** MEDIATEK Confidentiality Notice ***********
The information contained in this e-mail message (including any
attachments) may be confidential, proprietary, privileged, or
otherwise exempt from disclosure under applicable laws. It is
intended to be conveyed only to the designated recipient(s). Any
use, dissemination, distribution, printing, retaining or copying
of this e-mail (including its attachments) by unintended recipient(s)
is strictly prohibited and may be unlawful. If you are not an
intended recipient of this e-mail, or believe that you have received
this e-mail in error, please notify the sender immediately
(by replying to this e-mail), delete any and all copies of this
e-mail (including any attachments) from your system, and do not
disclose the content of this e-mail to any other person. Thank you!
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
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
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
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
|