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

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

Ohayou gozaimasu, Mark-san,

Good morning, Ming and Robert. I have questions to Ming and comments to Robert, too. I would appreciate if you two could read the following and respond.

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.

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?

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.

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

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:

Best regards,

tomo

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:

* 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

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?

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.

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:

* 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:

* 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

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:

* 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