Re: [STDS-802-11-TGAX] 20-0981

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

Hello Ming,

Re 20/980 discussion. (Not 20/0981 as in title.)

Could you further explain why the following proposed text is correct?

An AP shall not transmit an A-MPDU to a non-AP STA that includes an Ack or BlockAck frame together with a triggering frame unless both the AP and the non-AP STA have indicated support by setting the MU Cascading Support subfield to 1 in the MAC Capabilities Information field in the HE Capabilities element they transmit.

This is saying that only when both AP and non-AP STA supports MU Cascading sequence, the AP can transmit ack(Ack or BA) + TF, and prohibited in other cases.

But can’t the AP transmit such an A-MPDU also in an ordinary UL MU sequence?

For instance, the AP is triggering two non-AP STAs, STA 1 and STA2.

1. The AP triggers STA 1 and STA 2.

2. STA 1 and STA 2 transmit Data that solicits ack to the AP.

3. AP transmits ack + TF to STA 1 and STA 2 again. The ack is for the Data that STA 1 and STA 2 transmitted. The TF is to let STA 1 and STA 2 continue UL MU transmission.

4. STA 1 and STA 2 transmit Data that solicits ack to the AP.

…

I think the above is not an MU Cascading sequence but just an ordinary UL MU sequence being continued, because the AP is not transmitting Data/Management.

My understanding is that the AP can transmit TF + Data/Management only when it is MU Cascading sequence. It will match with the first sentence, “An MU cascading sequence is a frame exchange sequence between an AP and one or more non-AP STAs that allows Data and/or Management frames to be carried in both directions.”

The proposed text in 20/0980r2 is fine for me.

Best regards,

tomo

From: *** 802.11 TGax - HEW - High Efficiency WLAN *** <STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx> On Behalf Of Ganming (Ming)
Sent: Tuesday, August 18, 2020 3:29 PM
To: STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGAX] 答复: [STDS-802-11-TGAX] 20-0981

Hello Osama

Got it. One week passes, but I still do not get any response. Let me wait for a while. And I will try to present it on Thursday.

Best wishes,

Ming Gan

发件人: Osama AboulMagd
发送时间: 2020年8月17日 20:12
收件人: Ganming (Ming) <ming.gan@xxxxxxxxxx>; STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
主题: RE: [STDS-802-11-TGAX] 20-0981

Hello Ming,

The TG is trying to finish the resolution of all CIDs this week. Please plan to discuss your resolutions during the TG teleconference on Tuesday or Thursday.

Thanks for your help.

Regards;

Osama.

From: *** 802.11 TGax - HEW - High Efficiency WLAN *** [mailto:STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx] On Behalf Of Ganming (Ming)
Sent: Tuesday, August 11, 2020 12:10 PM
To: STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGAX] 答复: [STDS-802-11-TGAX] 20-0981

Hello guys

I correct the CIDs for this CR document, and they have the same meaning. Please check the attached file and tell me if you have feedback as soon as possible.

Best wishes,

Ming Gan

发件人: *** 802.11 TGax - HEW - High Efficiency WLAN *** [mailto:STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx] 代表 Ganming (Ming)
发送时间: 2020年8月11日 21:52
收件人: STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
主题: [STDS-802-11-TGAX] 答复: [STDS-802-11-TGAX] 20-0980 and 20-0981

Hello Mark

Actually “Ack or BlockAck frame together a triggering frame” is also ok because we agree that TB PPDU needs to contain a Data/Management frame which solicits an immediate acknowledgement frame. Since we do not have forbidden behavior at the STA side, so we should disallow “Ack or BlockAck frame together a triggering frame” behavior at the AP side in the third PPDD of the figure.

Best wishes
Ming Gan

发件人: *** 802.11 TGax - HEW - High Efficiency WLAN *** [mailto:STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx] 代表 Mark Rison
发送时间: 2020年8月11日 21:22
收件人: STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGAX] 20-0980 and 20-0981

I don't think this is correct. The key thing about MU cascading is that

the STA needs to send a TB PPDU with both an ack and some data. If

you look at the first MU PPDU, that PPDU cannot (for an A-MPDU to a given user)

contain both a triggering frame that triggers data/management that solicits

ack and a data/management (that solicits ack). The rule below would allow

such an MU PPDU.

+Tomo-san, because we seem to be revisiting our earlier consensus.

Thanks,

Mark

Mark RISON, Standards Architect, WLAN English/Esperanto/Français

Samsung Cambridge Solution Centre Tel: +44 1223 434600

Innovation Park, Cambridge CB4 0DS Fax: +44 1223 434601

ROYAUME UNI WWW: http://www.samsung.com/uk

From: Alfred Asterjadhi <asterjadhi@xxxxxxxxx>
Sent: Tuesday, 11 August 2020 13:10
To: Ganming (Ming) <ming.gan@xxxxxxxxxx>
Cc: Mark Rison <m.rison@xxxxxxxxxxx>; STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGAX] 20-0980 and 20-0981

Hi Ming,

Thanks.

I don't have a strong opinion on the first query (slight preference on option 1 to keep things simple perhaps. But for the second query I would say neither of the options because they are changing the contents of what makes an A-MPDU the initializer of an MU Cascading sequence. I would say option 3 in this case, which is the current rule specified in the draft:

An AP shall not transmit an A-MPDU to a non-AP STA that includes an Ack or BlockAck frame together with a triggering frame unless both the AP and the non-AP STA have indicated support by setting the MU
Cascading Support subfield to 1 in the MAC Capabilities Information field in the HE Capabilities elementthey transmit.

Regards,

Alfred

On Tue, Aug 11, 2020 at 12:40 AM Ganming (Ming) <ming.gan@xxxxxxxxxx> wrote:

Hello Alfred and Mark

Based on both of your comments, I provide two options for each modification. Please refer to the attached file

Hope this could be finalized.

Best wishes

Ming Gan

发件人: Alfred Asterjadhi [mailto:asterjadhi@xxxxxxxxx]
发送时间: 2020年8月11日 6:30
收件人: Mark Rison <m.rison@xxxxxxxxxxx>
抄送: STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx; Ganming (Ming) <ming.gan@xxxxxxxxxx>
主题: Re: [STDS-802-11-TGAX] 20-0980 and 20-0981

Thanks Mark for your prompt response.

Please find my thoughts inline.

Regards,

Alfred

On Mon, Aug 10, 2020 at 3:04 PM Mark Rison <m.rison@xxxxxxxxxxx> wrote:

Hello Alfred,

Thanks. Some comments on your feedback:

1)

An MU cascading sequence is a frame exchange sequence between an AP and one or more non-AP STAs that allows Data and/or Management frames to be carried in both directions

is a description of what MU cascading allows, it is not a statement

that anything with Data/Management frames in both directions is

an MU cascading sequence. Note "that allows" rather than "that

has".

[AA] I agree with your interpretation. However it seemed to me that one of the comments was specifying that this statement conflicts with others below. I am fine if we harmonize the statement to be inline with the normative behavior below.

So

> According to this statement it would mean that a DL MU PPDU followed by an HE TB PPDU is an MU Cascading sequence.

is not correct. Having said that, I'm OK to try to express it another

way (which?) or even to delete it completely, though it would feel a bit

strange to me to not have some general words to describe what MU cascading

is about (which is, as the statement above says, about having data(/mgmt)

going both ways -- everything else is just protocol).

[AA] I think it is fine to have a generic statement. The only thing i was trying to avoid is changing what an MU cascading sequence actually is.

2) Well,

Please see above and below. You are missing the ack/ba in the HE MU PPDU

is only true for the second/middle PPDU. So maybe

[AA] That is correct. In fact there was some discussions in the past on this aspect but then at the end it was decided to leave the figure as is nevertheless.

in this figure the HE MU PPDUs contain a triggering frame and a Data frame or Management frame, the second HE MU PPDU also contains an Ack or BlockAck frame and the HE TB PPDUs contain an Ack or BlockAck frame and a Data frame or Management frame. (#CID 20732, 20733 and 21450)

[when would an Ack frame be used, incidentally?]

[AA] Not certain I understand the question. An Ack frame would be used when the soliciting frame is a MGMT frame or a QOs Data frame send in S-MPDU within the HE TB PPDU and has Ack Policy set to Normal Ack.

Of course, you are assuming that the Data/Management frame in the TB

requires an ack, which might not be the case, right?

[AA] If there is no Ack frame as a result the HE MU PPDU would be part of a generic sequence (e.g., HE MU PPDU || HE TB PPDU) rather than an MU cascading sequence.

Really, it would be better to show the key MPDUs in the figure, but

it would get a bit messy for the MU PPDUs, since there would be two

sets for each MU PPDU.

[AA] Agree, but at the same time I cant think of a way of further clarifying it.

Thanks,

Mark

--

Mark RISON, Standards Architect, WLAN   English/Esperanto/Français

Samsung Cambridge Solution Centre       Tel: +44 1223 434600

Innovation Park, Cambridge CB4 0DS      Fax: +44 1223 434601

ROYAUME UNI                             WWW: http://www.samsung.com/uk

From: Alfred Asterjadhi <asterjadhi@xxxxxxxxx>
Sent: Monday, 10 August 2020 22:33
To: Mark Rison <m.rison@xxxxxxxxxxx>
Cc: STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGAX] 20-0980 and 20-0981

Hello Mark, and Ming,

Thanks for the interactions regarding the proposed resolutions in this document.

I could not follow all the detailed discussions in the thread so I took the freedom in providing my feedback in the document itself, which can be found attached here.

Best Regards,

Alfred

On Mon, Aug 10, 2020 at 10:04 AM Mark Rison <m.rison@xxxxxxxxxxx> wrote:

Hello Ming,

Thanks for the update, and the attached file. A few editorials:

- a Data frame or Management frame -> a Data or Management frame (2x)

- "The A-MPDU may additionally contain one or more MPDUs and is constructed following the rules defined in 26.11 (Setting TXVECTOR parameters for an HE PPDU)."

is a bit confusing, because the new text already mentions some MPDUs. I suggest

-> "The A-MPDU may additionally contain other MPDUs, following the rules defined in 26.11 (Setting TXVECTOR parameters for an HE PPDU)."

- Incidentally, that xref is clearly wrong, since TXVECTOR params are

not relevant to rules for constructing A-MPDUs. What is the intended subclause?

Also, "The MU cascading sequence may have a different set of transmitters in HE TB PPDUs as compared to the receivers of the HE MU PPDU that immediately follows the HE TB PPDUs within the same TXOP. The MU cascading sequence may have a different set of receivers in the HE MU PPDU as compared to the set of transmitters of HE TB PPDUs that immediately follow the HE MU PPDU within the same TXOP."

is really quite hard to follow. How about

"In an MU cascading sequence, the receivers of an HE MU PPDU may differ from the transmitters of preceding HE TB PPDUs

and of following HE TB PPDUs."

?

> But I know you point about “or in the last HE MU PPDU, an Ack or BlockAck frame”. The last HE MU PPDU could not be an exception because no any pending DL Data or Management frame at the AP side. Right?

The AP could in theory choose an HE MU PPDU to send the ack/block acks at the end

(where the example shows a Multi-STA BA), no?

[Is that correct? A cascading sequence always has to be started by the AP, so even

if cascading is supported you can't have say UL SU Data, then D/M w/ immack + TF for D/M,

right? Or even UL SU Data then ack/BA + TF for D/M, right?]

> [Ming] right

OK, then should it be:

Unless both the AP and the non-AP STA have indicated support by setting the MU Cascading Support subfield to 1 in the MAC Capabilities Information field in the HE Capabilities element they transmit, and the AP is the TXOP holder, an AP shall not transmit to the non-AP STA an A-MPDU that […]

?

Thanks,

Mark

--

Mark RISON, Standards Architect, WLAN   English/Esperanto/Français

Samsung Cambridge Solution Centre       Tel: +44 1223 434600

Innovation Park, Cambridge CB4 0DS      Fax: +44 1223 434601

ROYAUME UNI                             WWW: http://www.samsung.com/uk

From: Ganming (Ming) <ming.gan@xxxxxxxxxx>
Sent: Monday, 10 August 2020 12:54
To: Mark Rison <m.rison@xxxxxxxxxxx>; STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
Subject: 答复: [STDS-802-11-TGAX] 20-0980 and 20-0981

Thanks Mark, Please see my response in line.

Meanwhile please check the attached file for the clean version.

发件人: *** 802.11 TGax - HEW - High Efficiency WLAN *** [mailto:STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx] 代表 Mark Rison
发送时间: 2020年8月10日 19:18
收件人: STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGAX] 20-0980 and 20-0981

Hello Ming,

An MU cascading sequence is a frame exchange sequence between an AP and one or more non-AP STAs carried in an HE MU PPDU in the downlink and HE TB PPDU in the uplink where both the HE MU PPDU and the HE TB PPDU contain at least one Data frame or Management frame ~~in the uplink and characterized by the~~

~~exchange of Control, Data and/or Management frames in both directions~~.

This seems to be an imprecise paraphrasing of the "shall not" below

(imprecise e.g. because it does not say the Data/Management frame

has to solicit an immediate ack). What's the point? What do you

lose if you delete it completely?

[Ming] Agree, it needs “which solicit the immediate acknowledgement” after “one Data frame or Management frame”

OK, so then what's the point of this sentence? It just duplicates the

"shall not" just after.

[Ming]right. I do not have an idea to make it better.

OK, so why not delete it, or make it more general, e.g. "An MU cascading sequence is a frame exchange sequence between an AP and one or more non-AP STAs that allows Data and/or Management frames to be carried in both directions."?

[Ming] I am fine with the general description. Isn’t the change too much? I am afraid that other people do not buy it.

An example of an MU cascading sequence is shown in Figure 26-5 (An example of an MU cascading sequence) where the HE MU PPDU contains a Data frame and a triggering frame and the HE TB PPDU contains an Ack or BlockAck frame and a Data frame. (#CID 20732, 20733 and 21450)

The example doesn't say it's a Data frame in the MU PPDU, does it? It could be a

Management frame. Ditto the TB PPDU, in fact. Maybe it would be better to

show Data, ack and triggering frames in the figure?

[Ming]It could be a Management frame. However, this is an example. I am not sure it is good way to change the figure.

OK, then if you don't want to change the figure then the text needs to describe

the contents, maybe with a semicolon:

An example of an MU cascading sequence is shown in Figure 26-5 (An example of an MU cascading sequence); in this figure the HE MU PPDUs contain a Data or Management frame and a triggering frame and the HE TB PPDUs contain an Ack or BlockAck frame and a Data or Management frame. (#CID 20732, 20733 and 21450)

[Ming]Good, I adopt this suggestion. Other option is to remove the new added text.

OK. Maybe swap the order around to make it consistent, especially because TFs have to come first: in this figure the HE MU PPDUs contain a triggering frame and a Data or Management frame, and the HE TB PPDUs contain an Ack or BlockAck frame and a Data or Management frame. (#CID 20732, 20733 and 21450)

[Ming]Accepted

~~An AP shall not transmit an A-MPDU to a non-AP STA that includes an Ack or BlockAck frame together with a triggering frame~~ Unless both the AP and the non-AP STA have indicated support by setting the MU Cascading Support subfield to 1 in the MAC Capabilities Information field in the HE Capabilities element they transmit, an AP shall not transmit to the non-AP STA an A-MPDU that includes both

-a Data or Management frame that solicits the immediate acknowledgment, an Ack or BlockAck frame

-a triggering frame that solicits a Data or Management frame.

The A-MPDU may additionally contain one or more MPDUs and is constructed following the rules defined in 26.11 (Setting TXVECTOR parameters for an HE PPDU).

Note that “a Data or Management frame that solicits the immediate acknowledgment” is for the frame before the TB PPDU , and “an Ack or BlockAck frame” is for the frame after the TB PPDU

I don't understand this, and I find "a Data or Management frame that solicits the immediate acknowledgment, an Ack or BlockAck frame"

confusing. Is this trying to say that the acknowledgement takes the form of an Ack or BA frame?

If so, then that's obvious, isn't it? Also the "the" is grammatically wrong (which immediate

ack is this?). If you really want this then compress it to "a Data or Management frame that solicits an Ack or BlockAck frame"

but I think "a Data or Management frame that solicits an immediate acknowledgment" is better.

[Ming] “a Data or Management frame that solicits the immediate acknowledgment, an Ack or BlockAck frame” has two parts, one is “a Data or Management frame that solicits the immediate acknowledgment”,

[This should be "an immediate acknowledgment". You cannot use "the" before using something

like "a(n)" to define what is being referred to ("A STA sends a frame. The frame is big").]

[Ming]Right, it is “an”

the other is “an Ack or BlockAck frame”. The relationship is “or”. The latter part plus the second bullet “a triggering frame that solicits a Data or Management frame” equal the original first sentence of the second paragraph in the D6.0

So you mean that you're trying to say:

Unless both the AP and the non-AP STA have indicated support by setting the MU Cascading Support subfield to 1 in the MAC Capabilities Information field in the HE Capabilities element they transmit, an AP shall not transmit to the non-AP STA an A-MPDU that includes both

1) one or both of:

a) a Data or Management frame that solicits an immediate acknowledgment

b) an Ack or BlockAck frame

2) a triggering frame that solicits a Data or Management frame.

?

[Ming]Yes

the original first sentence of the second paragraph is “An AP shall not transmit an A-MPDU to a non-AP STA that includes an Ack or BlockAck frame together with a triggering frame unless…”, the sentence describes the third frame in Figure 26-5—An example of an MU cascading sequence

But that third PPDU (the HE MU PPDU in the middle) is required to contain both

"a Data or Management frame that solicits an immediate acknowledgment" and

"a triggering frame that solicits a Data or Management frame", like the first PPDU.

But although it contains "an Ack or BlockAck frame" this is not the case for the first

PPDU. Similarly things like Action No Ack frames could be present in the

MU PPDUs, but don't have to be.

[Ming]the third PPDU does not need to carry "a Data or Management frame that solicits an immediate acknowledgment". It could be only "an Ack or BlockAck frame" plus "a triggering frame that solicits a Data or Management frame". That is reason why “one or both of ” is more reasonable.<-my original thought.

Now we already mention “a Data or Management frame that solicits an immediate acknowledgment”, of course, there is an Ack or BlockAck frame in the third PPDU. But my question is that if third PPDU (the HE MU PPDU in the middle) does not contain any Data or Management frame, just has acknowledgement and triggering frame, could we regarding it as MU Cascading sequence? (I am not sure)

I see. Then you mean:

Unless both the AP and the non-AP STA have indicated support by setting the MU Cascading Support subfield to 1 in the MAC Capabilities Information field in the HE Capabilities element they transmit, an AP shall not transmit to the non-AP STA an A-MPDU that includes both

1) a Data or Management frame that solicits an immediate acknowledgment, or in the last HE MU PPDU, an Ack or BlockAck frame

2) a triggering frame that solicits a Data or Management frame.

? Is that correct?

[Ming] not last one. I mean the HE MU PPDU except for the first one. But if some certain HE MU PPDU does not have Data or Management frame, can we call it MU cascading sequence (Please confirm this question)? If not, we could remove “or in the last HE MU PPDU, an Ack or BlockAck frame”

But I know you point about “or in the last HE MU PPDU, an Ack or BlockAck frame”. The last HE MU PPDU could not be an exception because no any pending DL Data or Management frame at the AP side. Right?

But I'm not sure we need this. What we need to is to list what is forbidden unless

MU cascading is supported, and that's just D/M w/ immack + TF for D/M. The fact

that towards the end of the cascade you could have ack + TF for D/M is not important,

because you couldn't get there without first doing D/M w/ immack + TF for D/M.

[Ming] oh, this is about forbidden behavior. Agree with you at this point.

[Is that correct? A cascading sequence always has to be started by the AP, so even

if cascading is supported you can't have say UL SU Data, then D/M w/ immack + TF for D/M,

right? Or even UL SU Data then ack/BA + TF for D/M, right?]

[Ming] right

So the cascading requirement for the MU PPDUs is "a Data or Management frame

that solicits an immediate acknowledgment" and "a triggering frame that solicits a Data or

Management frame", but not necessarily "an Ack or BlockAck frame", I think.

Based on the discussion between Tomo and Mark. I have the following response.

1.       Regarding AP’s capability, it is still needed. The capability is for the AP itself, no additional requirement for the non-AP

I still don't understand. The AP knows its own capability, it does not need to look

into its HE Capabilities element to find out. So if the non-AP STA doesn't need to

know whether the AP is capable (which indeed it doesn't), who needs the bit in the

HE Capabilities element from the AP, exactly?

[Ming] I have same confusing as what you said. But we have the similar capability bit, like BQR support, For a non-AP STA, indicates support for generating a frame with a BQR Control subfield. Now MU cascading support, indicates that the AP is capable of transmitting an A-MPDU that is constructed following the MU cascade sequence rules

Maybe there's a bug there too! But maybe another comment.

[Ming]I do not want to touch this bug here. It seems the group members like to limit some behavior for the transmitter itself.

OK, let's not worry about this for now!

Thanks,

Mark

--

Mark RISON, Standards Architect, WLAN   English/Esperanto/Français

Samsung Cambridge Solution Centre       Tel: +44 1223 434600

Innovation Park, Cambridge CB4 0DS      Fax: +44 1223 434601

ROYAUME UNI                             WWW: http://www.samsung.com/uk

发件人: *** 802.11 TGax - HEW - High Efficiency WLAN *** [mailto:STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx] 代表 Mark Rison
发送时间: 2020年8月10日 14:07
收件人: STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGAX] 20-0980 and 20-0981

Hello Ming,

An MU cascading sequence is a frame exchange sequence between an AP and one or more non-AP STAs carried in an HE MU PPDU in the downlink and HE TB PPDU in the uplink where both the HE MU PPDU and the HE TB PPDU contain at least one Data frame or Management frame ~~in the uplink and characterized by the~~

~~exchange of Control, Data and/or Management frames in both directions~~.

This seems to be an imprecise paraphrasing of the "shall not" below

(imprecise e.g. because it does not say the Data/Management frame

has to solicit an immediate ack). What's the point? What do you

lose if you delete it completely?

[Ming] Agree, it needs “which solicit the immediate acknowledgement” after “one Data frame or Management frame”

OK, so then what's the point of this sentence? It just duplicates the

"shall not" just after.

An example of an MU cascading sequence is shown in Figure 26-5 (An example of an MU cascading sequence) where the HE MU PPDU contains a Data frame and a triggering frame and the HE TB PPDU contains an Ack or BlockAck frame and a Data frame. (#CID 20732, 20733 and 21450)

The example doesn't say it's a Data frame in the MU PPDU, does it? It could be a

Management frame. Ditto the TB PPDU, in fact. Maybe it would be better to

show Data, ack and triggering frames in the figure?

[Ming]It could be a Management frame. However, this is an example. I am not sure it is good way to change the figure.

OK, then if you don't want to change the figure then the text needs to describe

the contents, maybe with a semicolon:

An example of an MU cascading sequence is shown in Figure 26-5 (An example of an MU cascading sequence); in this figure the HE MU PPDUs contain a Data or Management frame and a triggering frame and the HE TB PPDUs contain an Ack or BlockAck frame and a Data or Management frame. (#CID 20732, 20733 and 21450)

--

~~An AP shall not transmit an A-MPDU to a non-AP STA that includes an Ack or BlockAck frame together with a triggering frame~~ Unless both the AP and the non-AP STA have indicated support by setting the MU Cascading Support subfield to 1 in the MAC Capabilities Information field in the HE Capabilities element they transmit, an AP shall not transmit to the non-AP STA an A-MPDU that includes both

-a Data or Management frame that solicits the immediate acknowledgment, an Ack or BlockAck frame

-a triggering frame that solicits a Data or Management frame.

The A-MPDU may additionally contain one or more MPDUs and is constructed following the rules defined in 26.11 (Setting TXVECTOR parameters for an HE PPDU).

Note that “a Data or Management frame that solicits the immediate acknowledgment” is for the frame before the TB PPDU , and “an Ack or BlockAck frame” is for the frame after the TB PPDU

I don't understand this, and I find "a Data or Management frame that solicits the immediate acknowledgment, an Ack or BlockAck frame"

confusing. Is this trying to say that the acknowledgement takes the form of an Ack or BA frame?

If so, then that's obvious, isn't it? Also the "the" is grammatically wrong (which immediate

ack is this?). If you really want this then compress it to "a Data or Management frame that solicits an Ack or BlockAck frame"

but I think "a Data or Management frame that solicits an immediate acknowledgment" is better.

[Ming] “a Data or Management frame that solicits the immediate acknowledgment, an Ack or BlockAck frame” has two parts, one is “a Data or Management frame that solicits the immediate acknowledgment”,

[This should be "an immediate acknowledgment". You cannot use "the" before using something

like "a(n)" to define what is being referred to ("A STA sends a frame. The frame is big").]

the other is “an Ack or BlockAck frame”. The relationship is “or”. The latter part plus the second bullet “a triggering frame that solicits a Data or Management frame” equal the original first sentence of the second paragraph in the D6.0

So you mean that you're trying to say:

Unless both the AP and the non-AP STA have indicated support by setting the MU Cascading Support subfield to 1 in the MAC Capabilities Information field in the HE Capabilities element they transmit, an AP shall not transmit to the non-AP STA an A-MPDU that includes both

1) one or both of:

a) a Data or Management frame that solicits an immediate acknowledgment

b) an Ack or BlockAck frame

2) a triggering frame that solicits a Data or Management frame.

?

the original first sentence of the second paragraph is “An AP shall not transmit an A-MPDU to a non-AP STA that includes an Ack or BlockAck frame together with a triggering frame unless…”, the sentence describes the third frame in Figure 26-5—An example of an MU cascading sequence

But that third PPDU (the HE MU PPDU in the middle) is required to contain both

"a Data or Management frame that solicits an immediate acknowledgment" and

"a triggering frame that solicits a Data or Management frame", like the first PPDU.

But although it contains "an Ack or BlockAck frame" this is not the case for the first

PPDU. Similarly things like Action No Ack frames could be present in the

MU PPDUs, but don't have to be.

So the cascading requirement for the MU PPDUs is "a Data or Management frame

that solicits an immediate acknowledgment" and "a triggering frame that solicits a Data or

Management frame", but not necessarily "an Ack or BlockAck frame", I think.

Based on the discussion between Tomo and Mark. I have the following response.

1.       Regarding AP’s capability, it is still needed. The capability is for the AP itself, no additional requirement for the non-AP

I still don't understand. The AP knows its own capability, it does not need to look

into its HE Capabilities element to find out. So if the non-AP STA doesn't need to

know whether the AP is capable (which indeed it doesn't), who needs the bit in the

HE Capabilities element from the AP, exactly?

[Ming] I have same confusing as what you said. But we have the similar capability bit, like BQR support, For a non-AP STA, indicates support for generating a frame with a BQR Control subfield. Now MU cascading support, indicates that the AP is capable of transmitting an A-MPDU that is constructed following the MU cascade sequence rules

Maybe there's a bug there too! But maybe another comment.

Thanks,

Mark

--

Mark RISON, Standards Architect, WLAN   English/Esperanto/Français

Samsung Cambridge Solution Centre       Tel: +44 1223 434600

Innovation Park, Cambridge CB4 0DS      Fax: +44 1223 434601

ROYAUME UNI                             WWW: http://www.samsung.com/uk

From: Ganming (Ming) <ming.gan@xxxxxxxxxx>
Sent: Sunday, 9 August 2020 03:43
To: tomo.adachi@xxxxxxxxxxxxx; Mark Rison <m.rison@xxxxxxxxxxx>; STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
Subject: 答复: [STDS-802-11-TGAX] 20-0980 and 20-0981

Hello Tomo and Mark

Thank you for the below valuable discussion. What do you think about the following text?

Alfred and Liwen, please check the following text meanwhile. In the call, it seems you guys want to keep the first sentence of the second paragraph.

An MU cascading sequence is a frame exchange sequence between an AP and one or more non-AP STAs carried in an HE MU PPDU in the downlink and HE TB PPDU in the uplink where both the HE MU PPDU and the HE TB PPDU contain at least one Data frame or Management frame ~~in the uplink and characterized by the~~

~~exchange of Control, Data and/or Management frames in both directions~~. An example of an MU cascading sequence is shown in Figure 26-5 (An example of an MU cascading sequence) where the HE MU PPDU contains a Data frame and a triggering frame and the HE TB PPDU contains an Ack or BlockAck frame and a Data frame. (#CID 20732, 20733 and 21450)

~~An AP shall not transmit an A-MPDU to a non-AP STA that includes an Ack or BlockAck frame together with a triggering frame~~ Unless both the AP and the non-AP STA have indicated support by setting the MU Cascading Support subfield to 1 in the MAC Capabilities Information field in the HE Capabilities element they transmit, an AP shall not transmit to the non-AP STA an A-MPDU that includes both

-a Data or Management frame that solicits the immediate acknowledgment, an Ack or BlockAck frame

-a triggering frame that solicits a Data or Management frame.

The A-MPDU may additionally contain one or more MPDUs and is constructed following the rules defined in 26.11 (Setting TXVECTOR parameters for an HE PPDU).

Note that “a Data or Management frame that solicits the immediate acknowledgment” is for the frame before the TB PPDU , and “an Ack or BlockAck frame” is for the frame after the TB PPDU

Based on the discussion between Tomo and Mark. I have the following response.

1.       Regarding AP’s capability, it is still needed. The capability is for the AP itself, no additional requirement for the non-AP

2.       Regarding TRS control, as Tomo menetioned, TRS control still can solicit the Action no Ack frame or QoS Null frame with No Ack ack policy. You know, the STA still needs to prepare both acknowledgement frames and some specific Data frame or Management frame within SIFS time in this case. This is additional requirement for the STA.

Best wishes

Ming Gan

发件人: tomo.adachi@xxxxxxxxxxxxx [mailto:tomo.adachi@xxxxxxxxxxxxx]
发送时间: 2020年7月31日 14:05
收件人: m.rison@xxxxxxxxxxx; Ganming (Ming) <ming.gan@xxxxxxxxxx>; STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
主题: RE: [STDS-802-11-TGAX] 20-0980 and 20-0981

Konnichiwa, Mark-san,

And hello, Ming,

Yes, Mark-san, I think we are almost there.

BTW, I will take days off for the next two weeks (not a sabbatical but something similar to that) and won’t probably respond.

If so, I'm not sure I agree, because as discussed, a TRS Control that solicits

an Action No Ack frame or a QoS Null with No Ack ack policy can be used even

if the two devices don't support cascading, no? If you mean that a TRS Control

does not explicitly solicit a Data/Management frame, just allows special flavours

of such frames, then I think that's too subtle without more words.

Mark-san, I see what you say.

As I wrote before, what is special is that both side needs to be able to acknowledge and send Data/Management.

I’m now fine with

Unless both the AP and the non-AP STA have set the MU Cascading Support subfield to 1 in the MAC Capabilities Information field in the HE Capabilities element they transmit, an AP shall not send to the non-AP STA an A-MPDU that contains both:

* a Data or Management frame, that requires acknowledgment

* a Trigger frame that solicits a Data or Management frame .

Ming, are you OK with replacing

An MU cascading sequence shall not be used between an AP and a non-AP STA (#CID 20732 and 20733) unless both the AP and the non-AP STA have indicated support by setting the MU Cascading Support subfield to 1 in the MAC Capabilities Information field in the HE Capabilities element they transmit.

in 20/980r1 with the above? Note that the subclause is 26.5.3, not 26.5.4.

And what is the purpose of the AP side to set the MU Cascading Support bit (9.4.2.247.2 HE MAC Capabilities Information field)?

Is there anything that the non-AP STA needs to do when the AP sets this bit? If not, can’t it make it reserved on the AP side? If yes, the above proposed text can be updated to

Unless ~~both the AP and~~ the non-AP STA ~~have~~has set the MU Cascading Support subfield to 1 in the MAC Capabilities Information field in the HE Capabilities element ~~they transmit~~, an AP shall not send to the non-AP STA an A-MPDU that contains both:

* a Data or Management frame, that requires acknowledgment

* a Trigger frame that solicits a Data or Management frame .

Best regards,

tomo

From: Mark Rison <m.rison@xxxxxxxxxxx>
Sent: Wednesday, July 29, 2020 5:01 PM
To: adachi tomoko(足立朋子 ○ＲＤＣ□ＩＴ研○ＷＳＬ) <tomo.adachi@xxxxxxxxxxxxx>; STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGAX] 20-0980 and 20-0981

Ohayou gozaimasu Tomo-san,

I think we're nearly there!

Or, for the cascading case, is it strictly limited to a Trigger frame?

That's my question. Maybe it can be a TRS Control for the very

end of the cascade, if the end of the cascade is DL data, UL ack

(i.e. opposite to Figure 26-5—An example of an MU cascading sequence)?

Ming, could you answer to this? The question is whether a TRC Control is allowed at the AP not only at the end but also during the cascading sequence.

I thought that the non-AP STA needs to be able to act as both the recipient and the originator, in other words, to respond with an A-MPDU including an acknowledgement and a Data or Management frame (if the basic conditions such as CS, duration, etc. are met).

OK, so how about:

- support bit in Clause 9:

For an HE AP:

Set to 1 to indicate that the AP is capable of trans-

mitting an A-MPDU that is constructed following

the MU cascade sequence rules (see 26.5.3 (MU

cascading sequence)) under MU cascade operation.

Set to 0 otherwise.

or

Reserved [since "is capable of" doesn't really mean anything and what's a non-AP STA supposed to do with this information?]

For a non-AP HE STA:

Set to 1 to indicate that the non-AP STA is capable

of receiving an A-MPDU that is constructed follow-

ing the MU cascade sequence rules (see 26.5.3 (MU

cascading sequence)).

Set to 0 otherwise.

Mark-san, I see your point where it is highlighted in yellow.

Maybe the intention was to have the non-AP STA that is capable only sets the bit to 1 when the associated AP is capable?

No, capabilities are supposed to be static; they do not depend on what other people's capabilities are.

Ming, could you give us your opinion?

Robert, while I scanned for “cascad" in clause 9, D6.1, I found the following:

9.2.4.6a.4 BSR Control

The Control Information subfield in a BSR Control subfield contains buffer status information used for UL

MU operation (see 26.5.3 (MU cascading sequence)). The format of the subfield is shown in Figure 9-22e

(Control Information subfield format in a BSR Control subfield).

I think the reference should be corrected to 26.5.2 (UL MU Operation).

Please also check “BSRs (see 26.5.3 (MU cascading sequence))” that appears twice in Table 9-297a—Broadcast TWT Recommendation field for a broadcast TWT element.

Good catch! I'm now worried there are other broken references. E.g. I quickly found:

— "BQRs (see 26.5.2 (UL MU operation))" 2x in Table 9-297a—Broadcast TWT Recommendation field for a broadcast TWT element

- "The transmitting STA follows the corresponding buffer status report procedure, as described in 26.5.3 (MU cascading sequence)" in Table 10-11a—Conditions for including Control subfield variants

- "The TWT responding STA should solicit buffer status reports from the TWT requesting

STA at the start of the TWT SP following the procedure described in 26.5.3 (MU cascading sequence) or as

described in 26.5.7 (NDP feedback report procedure)." in 26.8.2 Individual TWT agreements

so I fear many references are broken.

- behaviour in Clause 26:

Unless both the AP and the non-AP STA have set the MU Cascading Support subfield to 1 in the MAC Capabilities Information field in the HE Capabilities element they transmit, an AP shall not send to the non-AP STA an A-MPDU that contains both:

* a Data or Management frame, that requires acknowledgment

* a Trigger frame that solicits a Data or Management frame

I am almost OK with this.

Again, in my opinion, a Trigger frame can be substituted to a triggering frame that includes the TRS Control case.

I am not sure what you mean. Do you mean that you think the text should be:

Unless both the AP and the non-AP STA have set the MU Cascading Support subfield to 1 in the MAC Capabilities Information field in the HE Capabilities element they transmit, an AP shall not send to the non-AP STA an A-MPDU that contains both:

* a Data or Management frame, that requires acknowledgment

* a triggering frame that solicits a Data or Management frame

If so, I'm not sure I agree, because as discussed, a TRS Control that solicits

an Action No Ack frame or a QoS Null with No Ack ack policy can be used even

if the two devices don't support cascading, no? If you mean that a TRS Control

does not explicitly solicit a Data/Management frame, just allows special flavours

of such frames, then I think that's too subtle without more words.

Ming, are you OK with adding the above text in 26.5.3? I think the following sentence proposed in 20/980r1 can be replaced with the above text:

An MU cascading sequence shall not be used between an AP and a non-AP STA (#CID 20732 and 20733) unless both the AP and the non-AP STA have indicated support by setting the MU Cascading Support subfield to 1 in the MAC Capabilities Information field in the HE Capabilities element they transmit.

Isn't this just duplication of the above text?

Yoroshiku onegaishimasu,

Mark

--

Mark RISON, Standards Architect, WLAN   English/Esperanto/Français

Samsung Cambridge Solution Centre       Tel: +44 1223 434600

Innovation Park, Cambridge CB4 0DS      Fax: +44 1223 434601

ROYAUME UNI                             WWW: http://www.samsung.com/uk

From: Mark Rison <m.rison@xxxxxxxxxxx>
Sent: Tuesday, July 28, 2020 2:25 AM
To: adachi tomoko(足立朋子 ○ＲＤＣ□ＩＴ研○ＷＳＬ) <tomo.adachi@xxxxxxxxxxxxx>; STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGAX] 20-0980 and 20-0981

Ohayou gozaimasu Tomo-san,

Thanks for your response.

> The AP requirement is true (to be more precise, it can be a TRS Control subfield instead of a Trigger frame).

Can it? A TRS Control only solicits acks, not Data/Management frames.

So it's not clear to me that this forms part of a cascading sequence.
I suppose it could be at the very end of the sequence? But we can't

say that you must support cascading if you want to send an A-MPDU containing

Data frames that have a TRS Control, because I don't think that's true:

even if you don't support cascading you can send such an A-MPDU, no?

I see from 26.5.2.4 and Tables 9-532 and 9-531 referred therein that we can transmit Action No Ack and QoS Null frames. Am I wrong?

Ah, yes, you're right. I should have said "only solicits things that

don't solicit acks". (I assume you meant 9-530, not 9-531.)

Or, for the cascading case, is it strictly limited to a Trigger frame?

That's my question. Maybe it can be a TRS Control for the very

end of the cascade, if the end of the cascade is DL data, UL ack

(i.e. opposite to Figure 26-5—An example of an MU cascading sequence)?

I agree that the AP doesn’t need to send a TRS Control even if it supports cascading and can send it even if it doesn’t support cascading. I tried to express that in “can”.

> But the non-AP STA requirement is not accurate. The HE TB PPDU can be transmitted only when the AP transmitted a triggering frame.

The requirement was just "if you send a TB PPDU in response to the MU PPDU

it cannot contain a Data or Management frame". But as I said I don't think

this is a real requirement on the non-AP STA, it's a requirement on the AP.

I think we are aligned for this. J

> If the AP sets the MU Cascading Support subfield to 1, the AP may send to a non-AP STA that sets the MU Cascading Support subfield to 1 an A-MPDU that contains a Data/Management frame and a Trigger frame or a Data/Management frame carrying a TRC Control subfield.

If all of the following conditions is met, the non-AP STA shall respond with an HE TB PPDU including an Ack or BlockAck frame:

-      the non-AP STA sets the MU Cascading Support subfield to 1

-      the non-AP STA receives an A-MPDU that contains a Data/Management frame and a Trigger frame or a Data/Management frame carrying a TRC Control subfield from the AP and the Data/Management solicits immediate response

But there are other conditions, e.g. CS Required, power pre-correction,

TB PPDU duration, so it's not always the case that you shall respond.

I think expressing things as "you cannot do X unless both sides support

cascading" is safer.

OK. So the basic conditions in 26.5.2.3 comes first. Then, can’t we add that as one of the items?

But it's always true. What's the *new* requirement on non-AP STAs?

What is wrong or missing (incomplete) in saying that the requirement

for cascading is:

Unless both the AP and the non-AP STA have set the MU Cascading Support subfield to 1 in the MAC Capabilities Information field in the HE Capabilities element they transmit, an AP shall not send to the non-AP STA a PPDU that contains both:

* a Data or Management frame

* a Trigger frame that solicits a Data or Management frame

? As I said, (a) I think the AP can send a PPDU that contains a

Data/Management frame with a TRS Control even if cascading is not

supported, and (b) I think there is no specific requirement on the

non-AP STA, as long as the AP obeys the requirement above. Also

(c) it matches the description of the support bit in Clause 9.

If (b) above is true, why does the non-AP STA need to set the MU Cascading Support subfield?

Well, the non-AP STA needs to set this so that the AP knows that it can

send an A-MPDU with both a Data/Management frame and {a Trigger frame

that solicits {a Data/Management frame that solicits ack}}. I think the

real question is why the AP needs to set it -- what is the STA going to

do with this information?

I thought that the non-AP STA needs to be able to act as both the recipient and the originator, in other words, to respond with an A-MPDU including an acknowledgement and a Data or Management frame (if the basic conditions such as CS, duration, etc. are met).

OK, so how about:

- support bit in Clause 9:

For an HE AP:

Set to 1 to indicate that the AP is capable of trans-

mitting an A-MPDU that is constructed following

the MU cascade sequence rules (see 26.5.3 (MU

cascading sequence)) under MU cascade operation.

Set to 0 otherwise.

or

Reserved [since "is capable of" doesn't really mean anything and what's a non-AP STA supposed to do with this information?]

For a non-AP HE STA:

Set to 1 to indicate that the non-AP STA is capable

of receiving an A-MPDU that is constructed follow-

ing the MU cascade sequence rules (see 26.5.3 (MU

cascading sequence)).

Set to 0 otherwise.

- behaviour in Clause 26:

Unless both the AP and the non-AP STA have set the MU Cascading Support subfield to 1 in the MAC Capabilities Information field in the HE Capabilities element they transmit, an AP shall not send to the non-AP STA an A-MPDU that contains both:

* a Data or Management frame, that requires acknowledgment

* a Trigger frame that solicits a Data or Management frame

Yoroshiku onegaishimasu,

Mark

--

Mark RISON, Standards Architect, WLAN   English/Esperanto/Français

Samsung Cambridge Solution Centre       Tel: +44 1223 434600

Innovation Park, Cambridge CB4 0DS      Fax: +44 1223 434601

ROYAUME UNI                             WWW: http://www.samsung.com/uk

From: tomo.adachi@xxxxxxxxxxxxx <tomo.adachi@xxxxxxxxxxxxx>
Sent: Thursday, 23 July 2020 16:45
To: Mark Rison <m.rison@xxxxxxxxxxx>; STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGAX] 20-0980 and 20-0981

Hi Mark,

? Strawman:

Unless both the AP and the non-AP STA have set the MU Cascading Support subfield to 1 in the MAC Capabilities Information field in the HE Capabilities element they transmit:

* An AP shall not send to the non-AP STA a PPDU that contains a (Basic?) Trigger frame and a Data or Management frame

* A non-AP STA shall not include a Data or Management frame in the HE TB PPDU sent in response to an HE MU PPDU that contains a Data or Management frame

But I'm not sure this is right, and if this strawman AP requirement

is correct then I'm not sure this non-AP STA requirement is needed;

it's entirely an AP constraint (as the support bit description suggests).

The AP requirement is true (to be more precise, it can be a TRS Control subfield instead of a Trigger frame).

But the non-AP STA requirement is not accurate. The HE TB PPDU can be transmitted only when the AP transmitted a triggering frame.

So second strawman:

Unless both the AP and the non-AP STA have set the MU Cascading Support subfield to 1 in the MAC Capabilities Information field in the HE Capabilities element they transmit, an AP shall not send to the non-AP STA a PPDU that contains both:

* a Data or Management frame

* a Trigger frame that solicits a Data or Management frame

?

Again, the Trigger frame can be a TRS Control subfield instead.

In other way, I think we can say as follows to avoid negative _expression_:

If the AP sets the MU Cascading Support subfield to 1, the AP may send to a non-AP STA that sets the MU Cascading Support subfield to 1 an A-MPDU that contains a Data/Management frame and a Trigger frame or a Data/Management frame carrying a TRC Control subfield.

If all of the following conditions is met, the non-AP STA shall respond with an HE TB PPDU including an Ack or BlockAck frame:

-      the non-AP STA sets the MU Cascading Support subfield to 1

-      the non-AP STA receives an A-MPDU that contains a Data/Management frame and a Trigger frame or a Data/Management frame carrying a TRC Control subfield from the AP and the Data/Management solicits immediate response

Could you polish it, Mark?

Best regards,

tomo

From: adachi tomoko(足立朋子 ○ＲＤＣ□ＩＴ研○ＷＳＬ)
Sent: Wednesday, July 22, 2020 5:43 PM
To: Mark Rison <m.rison@xxxxxxxxxxx>; STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGAX] 20-0980 and 20-0981

Hi Mark,

The 1^st sentence in the 2^nd para is explaining the condition that both sides need to have the capability support.

From my understanding, the AP shall not transmit data to a STA while triggering the STA that does not have the capability.

The STA shall indicate its capability to the AP and may transmit UL data if it supports the sequence and if it has buffered data.

My apologies to rough response. I am about to stop working today.

Let me think about the description further how to explain without saying “shall not”…

Best regards,

tomo

From: Mark Rison <m.rison@xxxxxxxxxxx>
Sent: Wednesday, July 22, 2020 5:25 PM
To: adachi tomoko(足立朋子 ○ＲＤＣ□ＩＴ研○ＷＳＬ) <tomo.adachi@xxxxxxxxxxxxx>; STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-11-TGAX] 20-0980 and 20-0981

Thanks for the reminder. I'm not 100% sure where we are with this.

20/0980r1 says:

An MU cascading sequence is a frame exchange sequence between an AP and one or more non-AP STAs carried in an HE MU PPDU in the downlink and HE TB PPDU in the uplink where both the HE MU PPDU and the HE TB PPDU contain at least one Data frame or Management frame. An example of an MU cascading sequence is shown in Figure 26-5 (An example of an MU cascading sequence) where the HE MU PPDU contains a Data frame and a triggering frame and the HE TB PPDU contains an Ack or BlockAck frame and a Data frame. (#CID 20732, 20733 and 21450)

An MU cascading sequence shall not be used between an AP and a non-AP STA (#CID 20732 and 20733) unless both the AP and the non-AP STA have indicated support by setting the MU Cascading Support subfield to 1 in the MAC Capabilities Information field in the HE Capabilities element they transmit. The A-MPDU may additionally contain one or more MPDUs and is constructed following the rules defined in 26.11 (Setting TXVECTOR parameters for an HE PPDU).

So what is the intent of the second para (the one with the only normative

requirement ("shall not"))? The AP has no direct control over what the non-AP STA

includes it its TB PPDU, so is this actually a requirement on the non-AP STA?

"A STA shall not transmit an HE TB PPDU that contains a Data or Management frame

in response to an HE MU PPDU that contains a Data or Management frame

unless both the AP and the non-AP STA have set the support bit."?

But that's not compatible with the description of the support bit, which

is entirely in terms of the downlink rules:

For an HE AP:

Set to 1 to indicate that the AP is capable of trans-

mitting an A-MPDU that is constructed following

the MU cascade sequence rules (see 26.5.3 (MU

cascading sequence)) under MU cascade operation.

Set to 0 otherwise.

For a non-AP HE STA:

Set to 1 to indicate that the non-AP STA is capable

of receiving an A-MPDU that is constructed follow-

ing the MU cascade sequence rules (see 26.5.3 (MU

cascading sequence)).

Set to 0 otherwise.

To make progress, I suggest that the "shall" should be expressed as the actual

requirement, not a vague "shall not do cascading". Can someone fill in the blanks in:

Unless both the AP and the non-AP STA have set the MU Cascading Support subfield to 1 in the MAC Capabilities Information field in the HE Capabilities element they transmit:

* An AP shall not <what?>

* A non-AP STA shall not <what?>

? Strawman:

Unless both the AP and the non-AP STA have set the MU Cascading Support subfield to 1 in the MAC Capabilities Information field in the HE Capabilities element they transmit:

* An AP shall not send to the non-AP STA a PPDU that contains a (Basic?) Trigger frame and a Data or Management frame

* A non-AP STA shall not include a Data or Management frame in the HE TB PPDU sent in response to an HE MU PPDU that contains a Data or Management frame

But I'm not sure this is right, and if this strawman AP requirement

is correct then I'm not sure this non-AP STA requirement is needed;

it's entirely an AP constraint (as the support bit description suggests).

So second strawman:

Unless both the AP and the non-AP STA have set the MU Cascading Support subfield to 1 in the MAC Capabilities Information field in the HE Capabilities element they transmit, an AP shall not send to the non-AP STA a PPDU that contains both:

* a Data or Management frame

* a Trigger frame that solicits a Data or Management frame

?

Thanks,

Mark

--

Mark RISON, Standards Architect, WLAN   English/Esperanto/Français

Samsung Cambridge Solution Centre       Tel: +44 1223 434600

Innovation Park, Cambridge CB4 0DS      Fax: +44 1223 434601

ROYAUME UNI                             WWW: http://www.samsung.com/uk

From: *** 802.11 TGax - HEW - High Efficiency WLAN *** <STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx> On Behalf Of Tomo Adachi
Sent: Wednesday, 22 July 2020 02:07
To: STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGAX] 20-0980 and 20-0981

Hi Mark, Ming,

Sorry for my late reply…

I wasn’t attending the call when 20/0980 was discussed and thought that it will be converged.

But, is this topic still with no conclusion?

My position is that I’m happy with the change made in 20/0980r1. I do think that there are cases when an AP sends ack/BA+Data in DL.

For more extreme case, when the data frames been exchanged have No Ack policy, only those data frames can appear in both UL and DL.

So the essential for the MU cascading is the first sentence in the first para, i.e., “a frame exchange sequence between an AP and one or more non-AP STAs carried in an HE MU PPDU in the downlink and HE TB PPDU in the uplink where both the HE MU PPDU and the HE TB PPDU contain at least one Data frame or Management frame”.

And I’m OK if the capability condition, which is the first sentence in the second para, is merged with the first para.

(You may need to clarify what “the A-MPDU” is for the current second sentence in the second para. My suggestion will be to say like “The A-MPDU *within the MU cascading sequence* may additionally contain one or more MPDUs and is constructed following the rules defined in 26.11 (Setting TXVECTOR parameters for an HE PPDU).”)

Mark may want to clarify what is required when the STA declares the support. And I agree that is missing.

My understanding is that, the STA is required to be capable of generating both ack/BA and data/management frames and transmit them in an A-MPDU.

You may think that it conflicts with what I said above, but this is because the Ack policy of the MPDUs within the MU cascading sequence is not limited to No Ack. So, in case of the (implicit) BAR carried in the A-MPDU, the STA has to respond to it.

Mark, do you agree if the requirement on the non-AP STA side is clarified?

Best regards,

tomo

From: Mark Rison <m.rison@xxxxxxxxxxx>
Sent: Wednesday, July 8, 2020 8:36 PM
To: Ganming (Ming) <ming.gan@xxxxxxxxxx>; STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
Cc: adachi tomoko(足立朋子 ○ＲＤＣ□ＩＴ研○ＷＳＬ) <tomo.adachi@xxxxxxxxxxxxx>; Asterjadhi, Alfred (aasterja@xxxxxxxxxxxxxxxx) <aasterja@xxxxxxxxxxxxxxxx>
Subject: RE: [STDS-802-11-TGAX] 20-0980 and 20-0981

> Regarding MU cascading

Look, we just need to agree what MU cascading is, i.e. the thing you

can only do if both sides declare support for the feature. If we

cannot agree, then the feature is clearly underspecified and broken.

Is it

a frame exchange sequence between an AP and one or more non-AP STAs

carried in an HE MU PPDU in the downlink and HE TB PPDU in the uplink and characterized by the

exchange of Control, Data and/or Management frames in both directions

or is it that you

transmit an A-MPDU to a non-AP STA that includes an Ack or BlockAck frame together

with a triggering frame

? And is the requirement only on tx for the AP and only on rx

for the non-AP STA, per Clause 9's

For an HE AP:

Set to 1 to indicate that the AP is capable of trans-

mitting an A-MPDU that is constructed following

the MU cascade sequence rules (see 26.5.3 (MU

cascading sequence)) under MU cascade operation.

Set to 0 otherwise.

For a non-AP HE STA:

Set to 1 to indicate that the non-AP STA is capable

of receiving an A-MPDU that is constructed follow-

ing the MU cascade sequence rules (see 26.5.3 (MU

cascading sequence)).

Set to 0 otherwise.

?

> Regarding 20-0981

This was my email to Alfred:

So, is this what 26.3.1 is trying to say?

— Level 1: dynamic fragments shall be in non-A-MPDUs (no support for dynamic fragments in A-MPDUs that do not contain an S-MPDU)

— Level 2: dynamic fragments may be in an A-MPDU that does not contain an S-MPDU, subject to the following conditions:

- There shall be no more than one dynamic fragment of any given MSDU or A-MSDU in the A-MPDU, and the MSDU or A-MSDU shall be under a block ack agreement [i.e. you can have dynfrags for multiple MSDUs/A-MSDUs, as long as they’re all for different MSDUs/A-MSDUs, i.e. different SN+UP?]

- They shall be no more than one dynamic fragment of any given MMPDU [or maybe the intent is “no more than one dynamic fragment in a Management frame? Can you have multiple dynfrags of MMPDUs as long as the SNs are different?] [can you have this together with dynfrags of MSDUs/A-MSDUs?]

[I’m guessing what the existing text is trying to say, because it’s not clear to me what “each” means and how an MMPDU can be sent under a BA agreement in “support for up to one dynamic fragment for each MSDU, each A-MSDU (if supported by the recipient) and one MMPDU (see 26.6.3 (Multi-TID A-MPDU and ack-enabled single-TID A-MPDU)) in an A-MPDU that does not contain an S-MPDU, where the A-MPDU contains at least one dynamic fragment and is sent under an HT-immediate block ack agreement.”]

— Level 3: dynamic fragments may be in an A-MPDU that does not contain an S-MPDU, subject to the following conditions:

- There shall be no more than 4 dynamic fragments of any given MSDU or A-MSDU in the A-MPDU, and the MSDU or A-MSDU shall be under a block ack agreement

- They shall be no more than one dynamic fragment of any given MMPDU

[Ditto. Seems it’s same as level 2 except you can have 4 dynfrags for each MSDU/A-MSDU?]

Thanks,

Mark

P.S.: The xrefs in

The TWT responding STA should solicit buffer status reports from the TWT requesting

STA at the start of the TWT SP following the procedure described in 26.5.3 (MU cascading sequence) or as

described in 26.5.7 (NDP feedback report procedure).

look wrong to me.

--

Mark RISON, Standards Architect, WLAN   English/Esperanto/Français

Samsung Cambridge Solution Centre       Tel: +44 1223 434600

Innovation Park, Cambridge CB4 0DS      Fax: +44 1223 434601

ROYAUME UNI                             WWW: http://www.samsung.com/uk

From: *** 802.11 TGax - HEW - High Efficiency WLAN *** <STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx> On Behalf Of Ganming (Ming)
Sent: Wednesday, 8 July 2020 09:17
To: STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGAX] 答复: [STDS-802-11-TGAX] 20-0980 and 20-0981

Hello Alfred

Regarding MU cascading, I provided several solutions to address this vague issue in previous CR phases. But It seems most of people want to keep the existing text and do not want to do any change. Finally, I chose to reject this comment. However, it did not satisfy the commenter Mark Rison such that he raised this comment again and again. In the last call, I was aware there was discussion and converged it to ack+trigger is the essential of MU cascading. However, I still did not know the story behind it. In my opinion, it may not be exact. For example, ack+data also could be the essential of MU cascading.

Regarding 20-0981, which email is making the general description clear? Mark , Alfred, could you provide your thought here?

Best wishes,

Ming Gan

发件人: Alfred Asterjadhi [mailto:asterjadhi@xxxxxxxxx]
发送时间: 2020年7月8日 4:31
收件人: Ganming (Ming) <ming.gan@xxxxxxxxxx>
抄送: STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGAX] 20-0980 and 20-0981

Hello Ming,

Thanks for initiating this thread.

Please find my thoughts inline.

Regards,

Alfred

On Thu, Jul 2, 2020 at 8:16 AM Ganming (Ming) <ming.gan@xxxxxxxxxx> wrote:

Hello all,

In CR document 20-0980, it seems there is divergence in the definition of MU cascading sequence, especially for inconsistency between the first sentence of the first paragraph and the first sentence of second paragraph. Please tell me if you have any suggestion.

[AA] It seems that after the presentation there is no divergence but rather we need to fix the inconsistency between the two locations. I think the safest is to make the declarative statement to be inline with the normative behavior.

In CR document 20-0981, Mark mentioned it is not clear for the general description of three fragmentation levels. And Alfred, please check PN setting for retransmitted fragment.

[AA] I think I saw an e-mail circulating on the first item, which i believe is being solved. On the second item will try to find some time in the next days to take a look. Thanks for the reminder.

Best wishes,

Ming Gan

发件人: *** 802.11 TGax - HEW - High Efficiency WLAN *** [mailto:STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx] 代表 Ganming (Ming)
发送时间: 2020年7月2日 20:49
收件人: STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
主题: [STDS-802-11-TGAX] 答复: [STDS-802-11-TGAX] 答复: TGax CRC Teleconference 2020-07-02

Thanks Mark for your feedback, please see my response inline.

发件人: *** 802.11 TGax - HEW - High Efficiency WLAN *** [mailto:STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx] 代表 Mark Rison
发送时间: 2020年7月2日 20:03
收件人: STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGAX] 答复: TGax CRC Teleconference 2020-07-02

Thanks for these contributions, Ming.

I have the following comments:

11-20-0979-00-00ax-mac-cr-on-BSS-Load-for-draft 6.0

- "the percentage of time, linearly scaled with 255 representing 100%" -- if 100% is 255

then it's not a percentage. I suggest changing "percentage" to

"fraction" (3x)

[Ming]Agree, we should did the same change for BSS load and extended BSS load in REvmd

- "This percentage is computed" should similarly be "The field value is computed" (3x)

[Ming]Agree, same as before

- The resolutions refer to document xxxx (3x)

[Ming] Fixed

11-20-0980-00-00ax-mac-cr-on-MU-Cascading-for-draft 6.0

- "and also may enable the exchange of Control frames in both directions" is a bit weird,

because the Control frames might only go in one direction, right? Why

not delete "in both directions"? Or even this whole phrase?

[Ming] delete it

- "An MU cascading sequence shall not be exchanged between an AP and a non-AP STA (#CID 20732 and 20733) unless"

is a bit weird. Maybe "shall not occur" or "shall not be used"?

[Ming]Adopt

11-20-0981-00-00ax-mac-cr-on-Fragmentation-for-draft 6.0

I don't think CID 24364 has really been addressed.

Let's look at Level 1, which should be the easiest:

— Level 1: support for one dynamic fragment that is a non-A-MPDU [in a PSDU (#24364)], no support for dynamic fragments in an A-MPDU that is does not contain an S-MPDU.

So what does that mean?

It's clear I can only put my dynamic fragments in an S-MPDU, but beyond

that it's not clear.

Can I have multiple MSDUs fragmented at the same time (on different TIDs)?

[Ming] No if it is that A-MPDU

Can I have multiple MSDUs fragmented at the same time (to different STAs)?

[Ming] Maybe, one fragment in PSDU

If the receiver sees dynamic fragments for different MSDUs from the same STA,

does it need to assume that the earlier one was abandoned?

[Ming] abandon it in this case

Etc. Levels 2 and 3 are even more unclear.

It's possible that the intent is that all this "support for one" is intended

to be within the scope of a PSDU, i.e. just to prevent you, for level 1,

from having an A-MPDU with multiple dynamic fragments, but if so that's

not clear at all.

[Ming] your understanding is correct, do you have any suggestion if you think that is not clear

Also, it's not clear whether dynamic fragmentation is only for tx in an

HE TB PPDU. The original point was to make more efficient use of the

fixed HE TB PPDU durations, right? I can't immediately find such a restriction,

however.

[Ming] not only for TB PPDU, but also for HE MU PPDU, the initial stating point to reusing the wasted resource due to the ending time alignment in OFDMA PPDU.

Thanks,

Mark

--

Mark RISON, Standards Architect, WLAN   English/Esperanto/Français

Samsung Cambridge Solution Centre       Tel: +44 1223 434600

Innovation Park, Cambridge CB4 0DS      Fax: +44 1223 434601

ROYAUME UNI                             WWW: http://www.samsung.com/uk

From: *** 802.11 TGax - HEW - High Efficiency WLAN *** <STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx> On Behalf Of Osama Aboul-Magd
Sent: Wednesday, 1 July 2020 11:51
To: STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGAX] 答复: TGax CRC Teleconference 2020-07-02

Thanks Ming. I’ll add to the agenda.

Regards;

Osama.

On Wed, Jul 1, 2020 at 5:34 AM Ganming (Ming) <ming.gan@xxxxxxxxxx> wrote:

Hello Osama,

Could you help add the following contributions to the agenda

1.       11-20-0979-00-00ax-mac-cr-on-BSS-Load-for-draft 6.0

2.       11-20-0980-00-00ax-mac-cr-on-MU-Cascading-for-draft 6.0

3.       11-20-0981-00-00ax-mac-cr-on-Fragmentation-for-draft 6.0

Best wishes,

Ming Gan

发件人: *** 802.11 TGax - HEW - High Efficiency WLAN *** [mailto:STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx] 代表 Osama AboulMagd
发送时间: 2020年7月1日 17:22
收件人: STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
主题: [STDS-802-11-TGAX] TGax CRC Teleconference 2020-07-02

Hello All,

TGax CRC has a conference call scheduled for Thursday July 2nd @ 10:00 ET; for 3 hours.

Please let me know if you have a submission. I’ll send an agenda later.

Webex info https://ieeesa.webex.com/ieeesa/j.php?MTID=md80a26eb27009f9eaa014f3fab6c4da2

Meeting number: 719 726 400

Meeting password: wireless (94735377 from phones and video systems)

Join by phone: Tap to call in from a mobile device (attendees only) +1-408-418-9388 USA Toll
Global call-in numbers

Access code: 719 726 400

Teleconferences are bound by the conditions stipulated by the documentation below. Please review them and bring up any questions/concerns you may have before proceeding with the teleconference

•       IEEE Code of Ethics

–       https://www.ieee.org/about/corporate/governance/p7-8.html

•       IEEE Standards Association (IEEE-SA) Affiliation FAQ

–       https://standards.ieee.org/faqs/affiliation.html

•       Antitrust and Competition Policy

–       https://standards.ieee.org/content/dam/ieee-standards/standards/web/documents/other/antitrust.pdf

•       IEEE-SA Patent Policy

–       http://standards.ieee.org/develop/policies/bylaws/sect6-7.html

–       https://standards.ieee.org/about/sasb/patcom/

•       IEEE 802 Working Group Policies &Procedures (29 Jul 2016)

–       http://www.ieee802.org/PNP/approved/IEEE_802_WG_PandP_v19.pdf

•       IEEE 802 LMSC Chair's Guidelines (Approved 13 Jul 2018)

–       https://mentor.ieee.org/802-ec/dcn/17/ec-17-0120-27-0PNP-ieee-802-lmsc-chairs-guidelines.pdf

•       Participation in IEEE 802 Meetings

–       https://mentor.ieee.org/802-ec/dcn/16/ec-16-0180-05-00EC-ieee-802-participation-slide.pptx

•       IEEE 802.11 WG OM: (Approved 10 Nov 2017)

–       https://mentor.ieee.org/802.11/dcn/14/11-14-0629-22-0000-802-11-operations-manual.docx

Regards;

Osama.

TGax CRC has a conference call scheduled for Thursday June 25 @ 20:00 ET; for 3 hours.

A draft agenda is available at: https://mentor.ieee.org/802.11/dcn/20/11-20-0538-35-00ax-tgax-crc-teleconference-march-july-2020-teleconference-agendas.pptx

Webex info: https://ieeesa.webex.com/ieeesa/j.php?MTID=mbda27a87f1a2aed6ebc8ff66bca58a6a

Meeting number: 715 674 299

Meeting password: wireless (94735377 from phones and video systems)

Join by phone: Tap to call in from a mobile device (attendees only) +1-408-418-9388 USA Toll
Global call-in numbers

Access code: 715 674 299

Teleconferences are bound by the conditions stipulated by the documentation below. Please review them and bring up any questions/concerns you may have before proceeding with the teleconference

•       IEEE Code of Ethics

–       https://www.ieee.org/about/corporate/governance/p7-8.html

•       IEEE Standards Association (IEEE-SA) Affiliation FAQ

–       https://standards.ieee.org/faqs/affiliation.html

•       Antitrust and Competition Policy

–       https://standards.ieee.org/content/dam/ieee-standards/standards/web/documents/other/antitrust.pdf

•       IEEE-SA Patent Policy

–       http://standards.ieee.org/develop/policies/bylaws/sect6-7.html

–       https://standards.ieee.org/about/sasb/patcom/

•       IEEE 802 Working Group Policies &Procedures (29 Jul 2016)

–       http://www.ieee802.org/PNP/approved/IEEE_802_WG_PandP_v19.pdf

•       IEEE 802 LMSC Chair's Guidelines (Approved 13 Jul 2018)

–       https://mentor.ieee.org/802-ec/dcn/17/ec-17-0120-27-0PNP-ieee-802-lmsc-chairs-guidelines.pdf

•       Participation in IEEE 802 Meetings

–       https://mentor.ieee.org/802-ec/dcn/16/ec-16-0180-05-00EC-ieee-802-participation-slide.pptx

•       IEEE 802.11 WG OM: (Approved 10 Nov 2017)

–       https://mentor.ieee.org/802.11/dcn/14/11-14-0629-22-0000-802-11-operations-manual.docx

Regards;

Osama.

To unsubscribe from the STDS-802-11-TGAX list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAX&A=1

To unsubscribe from the STDS-802-11-TGAX list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAX&A=1

To unsubscribe from the STDS-802-11-TGAX list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAX&A=1

To unsubscribe from the STDS-802-11-TGAX list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAX&A=1

To unsubscribe from the STDS-802-11-TGAX list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAX&A=1

To unsubscribe from the STDS-802-11-TGAX list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAX&A=1

--

Alfred Asterjadhi, PhD

IEEE802.11 TGbe Chair,

Qualcomm Technologies Inc.

asterjadhi@xxxxxxxxx

aasterja@xxxxxxxxxxxxxxxx

Cell #: +1 858 263 9445

Office #: +1 858 658 5302

To unsubscribe from the STDS-802-11-TGAX list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAX&A=1

To unsubscribe from the STDS-802-11-TGAX list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAX&A=1

To unsubscribe from the STDS-802-11-TGAX list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAX&A=1

To unsubscribe from the STDS-802-11-TGAX list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAX&A=1

To unsubscribe from the STDS-802-11-TGAX list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAX&A=1

To unsubscribe from the STDS-802-11-TGAX list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAX&A=1

To unsubscribe from the STDS-802-11-TGAX list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAX&A=1

--

Alfred Asterjadhi, PhD

IEEE802.11 TGbe Chair,

Qualcomm Technologies Inc.

asterjadhi@xxxxxxxxx

aasterja@xxxxxxxxxxxxxxxx

Cell #: +1 858 263 9445

Office #: +1 858 658 5302

--

Alfred Asterjadhi, PhD

IEEE802.11 TGbe Chair,

Qualcomm Technologies Inc.

asterjadhi@xxxxxxxxx

aasterja@xxxxxxxxxxxxxxxx

Cell #: +1 858 263 9445

Office #: +1 858 658 5302

Alfred Asterjadhi, PhD

IEEE802.11 TGbe Chair,

Qualcomm Technologies Inc.

asterjadhi@xxxxxxxxx

aasterja@xxxxxxxxxxxxxxxx

Cell #: +1 858 263 9445

Office #: +1 858 658 5302

To unsubscribe from the STDS-802-11-TGAX list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAX&A=1