Re: [STDS-802-11-TGAX] TGax CRC Teleconference 2020-08-20

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

Konnichiwa Tomo-san,

add the following at the beginning of the paragraph that starts with “The MU cascading sequence may have a different set of transmitters in HE TB PPDUs” in 20/980r4:

“The MU cascading sequence may also allow Data and/or Management frames to be carried in the uplink.”

I find this sentence a bit confusing. MU cascading sequences

do allow Data/Management frames in the uplink, though whether it's

allowed in any particular HE TB PPDU depends on what triggering

frame was used. I think it would be clearer as something like:

NOTE—An HE TB PPDU might contain Data and/or Management frames, subject to the variant of triggering frame in the HE MU PPDU.

after the para you refer to. I'm suggesting a NOTE because this

is not a new normative requirement/option, it's just a restatement

of existing fact about UL MU. Similarly, I'm happy to change the

sentence we added in the previous para to a NOTE:

NOTE— The A-MPDU can contain other MPDUs, subject to the rules in 26.6 (A-MPDU operation in an HE PPDU).

since it too is not adding a new normative requirement.

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: *** 802.11 TGax - HEW - High Efficiency WLAN *** <STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx> On Behalf Of Tomo Adachi
Sent: Wednesday, 26 August 2020 01:11
To: STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGAX] TGax CRC Teleconference 2020-08-20

Hello all,

By understanding that

AP[TF(basic) + Data] – STAs[BA + Data(no ack)] – AP[TF(basic) + Data] – STAs[BA + Data(no ack)] – …

is not a MU cascading sequence, as there is no difference at the STA side to handle TF+Data at the beginning or in the middle,

I am fine if we can change the 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.”

in 20/980r4 to

“An MU cascading sequence is a frame exchange sequence between an AP and one or more non-AP STAs in which the AP simultaneously acknowledges an UL transmission from a STA, and triggers the STA for a further UL transmission.”

and

add the following at the beginning of the paragraph that starts with “The MU cascading sequence may have a different set of transmitters in HE TB PPDUs” in 20/980r4:

“The MU cascading sequence may also allow Data and/or Management frames to be carried in the uplink.”

A direct motion to modify 20/980r4 as above can be taken.

Does someone have any objection/concern?

Best regards,

tomo

From: *** 802.11 TGax - HEW - High Efficiency WLAN *** <STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx> On Behalf Of Tomo Adachi
Sent: Monday, August 24, 2020 4:22 PM
To: STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGAX] TGax CRC Teleconference 2020-08-20

Hello Robert,

Thank you very much for your response.

Please see my comments in-line.

From: Stacey, Robert <robert.stacey@xxxxxxxxx>
Sent: Saturday, August 22, 2020 1:36 AM
To: adachi tomoko(足立朋子 ○ＲＤＣ□ＩＴ研○ＷＳＬ) <tomo.adachi@xxxxxxxxxxxxx>; STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
Subject: RE: TGax CRC Teleconference 2020-08-20

Hello Tomo, All,

Some additional comments embedded.

-Robert

From: *** 802.11 TGax - HEW - High Efficiency WLAN *** <STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx> On Behalf Of Tomo Adachi
Sent: Thursday, August 20, 2020 11:03 PM
To: STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGAX] TGax CRC Teleconference 2020-08-20

Ming, Alfred, Liwen, and Mark

Based on the discussion that we had in today’s call, I am OK to allow the AP to only transmit ack+TF in the MU cascading sequence. (A bit disappointed that UL MU is limited to one exchange per STA in TXOP, though.)

But I’m still not convinced on two points. Please convince me to avoid submitting further comments.

1. I still think the following sentence is not correct.

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

This is not a general description. It is only cutting out one example when Data/Management frames are sent in both directions and is misleading.

How about changing it like the following?

“An MU cascading sequence is a frame exchange sequence between an AP and one or more non-AP STAs where Data and/or Management frames are transmitted sequentially either in uplink or in both directions.”

[RS] The frame exchange sequence {TF – UL data} is not a cascading sequence, but would be with your suggested edit. But I think what you might be asking is if the sequence {TF – data– TF + ack – data} is a cascading sequence. Based on the current definition, No. The AP can only send a TF + ack if the non-AP STA supports cascading, but the sequence itself is not a cascading sequence.

So I think what your question is: If the sequence { TF – data – TF + ack – data} is valid and requires cascading support, why don’t we include it in the definition of a cascading sequence? We should probably try.

[TA] Yes, indeed! J

Your explanation deepened my understanding.

From your comment below in 2, a sequence such as

AP[TF(basic) + Data] – STAs [BA + Data] – AP[BA]

is not an MU cascading sequence. So, just saying “both directions” is not correct.

Does “transmitted sequentially” make sense? Mark suggested to change the text as “transmitted in more than one UL PPDU”.

So my suggested sentence now will be

An MU cascading sequence is a frame exchange sequence between an AP and one or more non-AP STAs where Data and/or Management frames are transmitted in more than one UL PPDU or in consecutive UL and DL PPDUs after the initial triggering frame from the AP.

This will cover the sequences like

- AP[TF(basic)] – STAs[Data] – AP[BA + TF(basic)] – STAs[Data] …

- AP[TF(basic) + Data] – STAs[BA + Data] – AP[BA + TF(basic) + Data] – STAs[BA + Data] …

I don’t think the following sequence where the AP is always the initiator side and the non-AP STAs are always the responder side is MU Cascading.

- AP[Data + TF(MU-BAR)] – STAs[BA] – AP[Data + TF(MU-BA)] – STAs[BA] …

So “downlink” is intentionally excluded in the above proposed text.

2. While the following sentence disallows ack+TF outside the MU Cascading sequence, the current text does not touch on TF(basic) + Data.

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.

Then, TF(basic) + Data can be transmitted outside the MU Cascading sequence. But is this really true?

[RS] Yes.

An A-MPDU that includes TF(TID Aggregation Limit = 0) + Data will result in an A-MPDU response with ack but no Data/Management soliciting an ack

An A-MPDU that includes TF(TID Aggregation Limit > 0) + Data will result in an A-MPDU response with ack and possibly Data/Management soliciting an ack, but the AP response to that could be an ack by itself (no TF)

[TA] Thanks for pointing out the use of TID Aggregation Limit.

But how about after receiving a TB PPDU? Can an AP still transmit TF+Data outside the MU Cascading sequence?

The sequence what I am thinking is for example

AP[TF(basic) + Data] – STAs[BA + Data(no ack)] – AP[TF(basic) + Data] – STAs[BA + Data(no ack)] – …

This an MU cascading sequence, isn’t it?

Why does TF(basic) + Data in the middle of the sequence not limited to the MU Cascading even though it’s a core factor to enable bi-directional transfer?

Is it because the STA side has no difference with handling the TF+Data at the beginning?

Receiving such A-MPDU, the STA side may transmit BA+Data, where the Data may solicit acknowledgement.

Other than in the MU Cascading sequence, as the AP cannot transmit BA+TF after receiving such A-MPDU from the above restriction, there should be a rule also on the STA side not to transmit Data that solicits acknowledgment when it receives TF(basic) + Data. But there is no such rule.

To go straight forward, I think TF(basic) + Data should be also disallowed outside the MU Cascading sequence (i.e., option 2).

Best regards,

tomo

From: *** 802.11 TGax - HEW - High Efficiency WLAN *** <STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx> On Behalf Of Mark Rison
Sent: Thursday, August 20, 2020 10:22 PM
To: STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGAX] TGax CRC Teleconference 2020-08-20

Just kind remind, I send a request to the Chair.

If you have suggestion, please tell me.

Regarding 20/0980r3:

- I attach my comments again.

- I am probably OK with option 3 as long as Alfred (or anyone else) can

explain why ack+TRS needs to be forbidden unless MU cascading is supported.

- However, Tomo-san's point about whether

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.

is cascading or not needs to be agreed on

[Ming] I have no idea for this.

OK, well let's hope Alfred and Tomo-san do!

- The changes actually shown in 20/0980r3 are not correct:

* They don't effect option 3

in this figure the HE MU PPDUs contain a triggering frame and a Data or Management frame which solicits an immediate acknowledgement, and the HE TB PPDUs contain an Ack or BlockAck frame and a Data or Management frame which solicits an immediate acknowledgement. (#CID 20732, 20733 and 21450)

should be:

in this figure the second HE MU PPDU contains an Ack or BlockAck frame and a triggering [or Trigger, depending on the Tomo-san point outcome] frame.

[Ming] Does the second HE MU PPDU contain Data frame? This is just an example, I do not see any issue for the original sentence. Please point it out if any.

The A-MPDU may additionally contain one or more MPDUs and is constructed following the rules in 26.6 (A-MPDU operation in an HE PPDU).

should be:

The A-MPDU may contain other MPDUs, subject to the rules in 26.6 (A-MPDU operation in an HE PPDU).

[Ming] any difference between “additionally ” and “other”? if they are the same, I would like to keep it.

Yes.

"The A-MPDU may additionally contain one or more MPDUs and is constructed following the rules in 26.6 (A-MPDU operation in an HE PPDU)." means "In addition to the rules above, the A-MPDU may contain some MPDUs, per 26.6". But this is confusing, because the rules above already refer the inclusion of certain MPDUs in the A-MPDU (specifically the Ack/BA frames and the triggering frames -- these are all MPDUs).

Regarding CID 24557 in 20/0981r4:

- I attach my comments again.

- I'm not persuaded by

the PN assignment for the retransmitted fragment shall follow the rules defined in 12.5.3.3.2 (PN processing) except that the PN shall be incremented in steps of 1 for the retransmitted fragment if it has a different body length from the previously transmitted fragment

* I'm not sure we can guarantee that another frame hasn't been transmitted

(to the given receiver) with the PN specified here (incremented by 1), i.e.

that PN might already have been used. Can we guarantee this?

[Ming] It can be guaranteed because it has the following description in 12.5.3.3.2 (PN processing)

The PN shall never repeat for a series of encrypted MPDUs using the same temporal key.

The problem is the following sequence:

- Send dynfrag with PN 1234, but this dynfrag is not acked

- Send something else (maybe on a different AC) with PN 1235

- Can't retx the dynfrag with "PN shall be incremented in steps of 1", because that would cause a transmission with PN 1235, which is forbidden

* 12.5.3.3.2 is for CCMP, but we also need to support GCMP.

[Ming] Good catch. Actually there are two sub clause of PN processing. One is 12.5.3.3.2 (PN processing) in CCMP and the other is 12.5.5.3.2 PN processing in GCMP.

So I would like to change it to “the PN assignment for the retransmitted fragment shall follow the rules defined in 12.5.3 (CTR with CBC-MAC protocol (CCMP)) and 12.5.5 (GCM protocol (GCMP)) except that the PN shall be incremented in steps of 1 for the retransmitted fragment if it has a different body length from the previously transmitted fragment and is encrypted”

See above. I am not confident we can be sure PN+1 is available.

* the DU might not be encrypted

[Ming] What is the DU? Is this related

I meant this as a shorthand for MSDU, A-MSDU or MMPDU.

If there is no better proposal from e.g. Jouni then how about something

generic and safe like:

If the MSDU, A-MSDU or MMPDU is encrypted, and the retransmitted fragment has a different length from the previous fragment, the PN shall be greater than any PN previously used for transmissions to the receiver.

NOTE—This is to ensure that requirements on non-reuse of a PN with the same temporal key are met (see 12.5.3.3.2 and 12.5.5.3.2).

[Ming] “Greater” is not good since the baseline says “The PN is incremented by a positive number for each MPDU. The PN shall be incremented in steps of 1 for

constituent MPDUs of fragmented MSDUs and MMPDUs.”

See above. I am not convinced we can guarantee that incrementing the PN by 1 will be possible. And in any case the last sentence is not true for dynfrag when we start incrementing the PN on retx, since then the constituent MPDUs will not have PNs going up by 1 every time. Also that sentence does not cover A-MSDUs (since A-MSDUs cannot be statically fragmented). Maybe we need to change 12.5.x to say " The PN shall be incremented in steps of 1 for

constituent MPDUs of fragmented MSDUs and MMPDUs that do not use dynamic fragmentation."

NOT “the MSDU, A-MSDU or MMPDU is encrypted”, it is MPDU (or fragment) is encrypted

Ah, interesting point. I thought you could say that MSDUs/A-MSDUs/MMPDUs

are encrypted. But OK, then:

If the fragments of the MSDU, A-MSDU or MMPDU are encrypted, and the retransmitted fragment has a different length from the previous fragment, the PN shall be greater than any PN previously used for transmissions to the receiver.

NOTE—This is to ensure that requirements on non-reuse of a PN with the same temporal key are met (see 12.5.3.3.2 and 12.5.5.3.2).

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: Thursday, 20 August 2020 12:02
To: Mark Rison <m.rison@xxxxxxxxxxx>; tomo.adachi@xxxxxxxxxxxxx; Alfred Asterjadhi <aasterja@xxxxxxxxxxxxxxxx>
Subject: 转发: TGax CRC Teleconference 2020-08-20

Just kind remind, I send a request to the Chair.

If you have suggestion, please tell me. We need to finalize it this week as Osama mentioned before that all the CIDs for D6.0 should be resolved . Once it is decided, hope no similar comment again.

Best wishes,

Ming Gan

发件人: Ganming (Ming)
发送时间: 2020年8月20日 18:58
收件人: Osama AboulMagd <Osama.AboulMagd@xxxxxxxxxx>; STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
主题: 答复: TGax CRC Teleconference 2020-08-20

Hello Osama

Could you add the 981/r4 (1 CID) and 980/r3 to the agenda? Thank you.

Best wishes,

Ming Gan

发件人: *** 802.11 TGax - HEW - High Efficiency WLAN *** [mailto:STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx] 代表 Osama AboulMagd
发送时间: 2020年8月19日 21:23
收件人: STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
主题: [STDS-802-11-TGAX] TGax CRC Teleconference 2020-08-20

Hello All,

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

I’ve uploaded a tentative agenda. It is available at: https://mentor.ieee.org/802.11/dcn/20/11-20-1169-09-00ax-tgax-crc-teleconference-agendas-august-september-2020.pptx

I believe submissions are available covering all (or most) the remaining 34 comments.

• Call the meeting to order

• IEEE-SA IPR policy and procedure

• Attendance. Please record your attendance on IMAT (imat.ieee.org).

• Please add [V} and [NV] beside your name on Webex

• Motions (Candidate CIDs are listed in the next page)

• https://mentor.ieee.org/802.11/dcn/20/11-20-0665-08-00ax-comment-resolution-on-mibs-and-pics.docx - Edward Au - CID 24209

• https://mentor.ieee.org/802.11/dcn/20/11-20-0981-03-00ax-mac-cr-on-fragmentation-for-draft-6-0.doc - Ming Gan - CID 24557

• https://mentor.ieee.org/802.11/dcn/20/11-20-1218-02-00ax-d6-0-misc-cr.docx - Robert Stacey

• Discussion on CID 24102 – Lili Hervieu

• https://mentor.ieee.org/802.11/dcn/20/11-20-0980-02-00ax-mac-cr-on-mu-cascading-for-draft-6-0.doc - Ming Gan

• https://mentor.ieee.org/802.11/dcn/20/11-20-1233-00-00ax-the-last-of-the-cids-plan-b.docx - Alfred Asterjadhi

• https://mentor.ieee.org/802.11/dcn/20/11-20-1235-00-00ax-11ax-d6-0-comment-resolution-of-cid-24043.docx - Liwen Chu

• AoB

• Adjourn

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

Meeting number: 129 383 1701

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: 129 383 1701

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