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

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.

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