[STDS-802-11-TGAX] 答复: TGax CRC Teleconference 2020-10-20

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

Thanks Mark for your comments. Please see my response inline. Thanks

Please refer to the new version in the server.

Best wishes

Ming Gan

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

Thanks for these resolutions. Some comments:

Mu Cascading: https://mentor.ieee.org/802.11/dcn/20/11-20-1646-00-00ax-mac-cr-on-mu-cascading-for-draft-7-0.doc

25058: I'm not sure about the change w.r.t. the proposed change.

The receivers of an MU PPDU are the same as the transmitters of

the immediately following TB PPDUs, except for the corner cases

of no-ack MPDUs, corruption and CS Required denial, etc., but

this is not a special feature of cascading, it's always the case.

[Ming]but the original text cover the exception you mentioned. So this rephrasing is better

Also, you don't need "within the same TXOP" since the whole para is

about "In an MU cascading sequence", though if you wanted to say

"Within an MU cascading sequence" I'd be OK.

[Ming] I am not sure MU cascading sequence could cross one TXOP, but we do not disallow it. So “within the same TXOP” is reasonable

25075: I'm not sure about the proposed additional requirement for

a non-AP STA to check the AP's MU Cascading Support subfield

before responding to an MU PPDU from the AP. If the AP can't

cope with MU cascading, it should not trigger a STA for a

cascading transmission.

[Ming] but you know this is optional for AP, so I use similar language for the nonAp STA.

(Also editorially "it transmit" -> "it transmits" (2x))

[Ming] I forgot to change it. Before it was “they transmit”. Thanks

In the first para below Discussion… Word is showing a change bar,

but I can't work out what is being changed. What is being changed here?

[Ming] No change there. Maybe I used previous CR document as template and removed the corresponding discussion

Fragment: https://mentor.ieee.org/802.11/dcn/20/11-20-1647-00-00ax-mac-cr-on-fragmentation-for-draft-7-0.doc

25109: the proposed change is better; you cannot have "shall"

in a NOTE.

[Ming]I strike out “shall” and do not inlcude “will”

25110/25111: these are the same comment with different proposed

changes, one for each of the possible interpretations. In the

resolution it would be better to say which is the correct

interpretation. (Seems it's "1) for a dynamic fragment containing a Management

frame, you can only have one in the A-MPDU"?)

[Ming] the first interpretation is correct, I added it to the resolution and have one more explaination

25112: the problem with saying "shall also support level 1 dynamic

fragmentation" is that it's not clear: do you support level 1

dynamic fragments at the same time as level 2/3 dynamic fragments,

or is it just that you have L1 support if the peer doesn't support

L2/L3? I think the proposed change is better.

[Ming] I am not sure I get your question. The proposed change is “An HE STA that is operating in level 2 or level 3 shall also support level 1 dynamic fragments”, my resolution is “An HE STA that is operating in level 2 or level 3 can still transmit and receive the dynamic fragments under Level 1 shall support level 1 dynamic fragmentation”. Why do you say the proposed change is better?

Or reject this comment because we have the corresponding descriptions in 26.3.2 and 26.3.3. or we could change it to “An HE STA that is operating in level 2 or level 3 shall also support to transmit and receive the dynamic fragments under level 1”

25115: I am not 100% sure "so that the PN never repeats for the same temporal key"

is correct. I agree that's what md/D5.0/12.5.3.3.1/a)1) suggests,

but on the other hand 12.5.3.1 indicates only reuse of a TK

with the same nonce is an issue, and as 12.5.3.3.4 shows the

nonce includes the UP, so maybe the PN can repeat for the same

TK as long as it's for a different UP? +Jouni here; the proposed

wording is:

[Ming]PV0 MPDU, PN is not related to UP, but if that is PV1 MPDU, it is related to UP, please refer to 12.5.3.3.1/b)1)

The frame body length and contents of the retransmitted fragment shall be the same as the initially transmitted fragment and shall remain fixed for the lifetime of the MSDU, A-MSDU or MMPDU at that STA except when all the fragments preceding the initial transmitted fragment were received and all the fragments following the initial transmitted fragment have either explicitly failed or have not been transmitted, in which case the frame body length and contents of the retransmitted fragment may be different from the initially transmitted fragment and the PN assignment for the retransmitted fragment shall follow the rules defined in 12.5.3.3.2 (PN processing) and 12.5.5.3.2 (PN processing) except that the PN shall be incremented for the retransmitted fragment so that the PN never repeats for the same temporal key (#CID 25115) if it has a different body length from the previously transmitted fragment and is encrypted.

Thanks,

Mark

P.S.: As regards "could you add the tile for 26.6, like 26.6 (A-MPDU operation in an HE PPDU)?"

I think it appears automatically in drafts and disappears automatically

in the final published document.

[Ming] thanks for your info

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: Monday, 19 October 2020 03:05
To: STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGAX] 答复: TGax CRC Teleconference 2020-10-20

Hello all,

I uploaded two CR documents to the server, please refer to the following link, comments are welcome

Fragment: https://mentor.ieee.org/802.11/dcn/20/11-20-1647-00-00ax-mac-cr-on-fragmentation-for-draft-7-0.doc

Mu Cascading: https://mentor.ieee.org/802.11/dcn/20/11-20-1646-00-00ax-mac-cr-on-mu-cascading-for-draft-7-0.doc

Best wishes

Ming Gan

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

Hello Osama,

Is the meeting time Tuesday October 20 @ 10:00 ET based on the calendar of 802.11?

Best wishes

Ming Gan

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

Hello All,

TGax CRC has a conference call scheduled for Tuesday October 20 @ 17:00 ET; for 2 hours.

Please let me know if you plan a submission. A draft agenda is available at: https://mentor.ieee.org/802.11/dcn/20/11-20-1552-10-00ax-tgax-crc-teleconference-agendas-october-november-december-2020.pptx

Webex Info: https://ieeesa.webex.com/ieeesa/j.php?MTID=mfb526d03f3e9ec7b8b28fe7a78faf086

Meeting number: 173 002 9529

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: 173 002 9529

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