Hello Mark and Alfred,
Agree to keep capability for the AP. I am fine to remove the description at non-AP side.
Meanwhile, please check the two attached documents.
Best wishes,
Ming Gan
发件人: *** 802.11 TGax - HEW - High Efficiency WLAN *** [mailto:STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx]
代表
Alfred Asterjadhi
发送时间: 2020年10月22日
0:35
收件人: STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGAX] TGax CRC Teleconference 2020-10-20
Thanks Mark. Please find inline.
Regards,
Alfred
On Wed, Oct 21, 2020 at 6:42 AM Mark Rison <m.rison@xxxxxxxxxxx> wrote:
> I would like to keep capability for the AP
Well, why -- what is the purpose of signalling the AP's capability here?
[AA] Useful for the non-AP STA to know if the AP implements this feature or not is my guess.
If the AP supports MU cascading, it sends the kinds of MU PPDUs that
are only used if MU cascading is supported (of course it first has to
check whether the non-AP STA supports MU cascading too). The non-AP
STA doesn't have to check anything before sending the TB PPDU, since
the AP will not send those kinds of MU PPDUs if the AP doesn't support
MU cascading.
[AA] That is correct. And i dont think there is something as of now which asks the STA to check something. I believe Ming was adding something to that extent if i recall correctly but i dont think we need to.
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 Ganming (Ming)
Sent: Tuesday, 20 October 2020 17:05
To: STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGAX] 答复: TGax CRC Teleconference 2020-10-20
Alfred and Mark
Could you help check the following comment? I would like to keep capability for the AP. Any comments
25075
195.06
9.4.2.248.2
There is no normative behaviour associated with the MU Cascading Support subfield at the AP, i.e. a non-AP STA does not have to look at it to do or not do anything in particular
In Table 9-323a—Subfields of the HE MAC Capabilities Information field change "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." to "Reserved for an AP."
Best wishes,
Ming Gan
发件人: *** 802.11 TGax - HEW - High Efficiency WLAN *** [mailto:STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx] 代表 Mark Rison
发送时间: 2020年10月20日 21:34
收件人: STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGAX] TGax CRC Teleconference 2020-10-20
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
I assert the original text is poor too.
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
I think an MU cascading sequence has to be a single TXOP, because
the point of cascading is to have an MU PPDU that both acks some stuff just
received, and triggers some stuff immediately next. Figure 26-5—An example
of an MU cascading sequence supports this.
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.
No, the point is that a STA should not be required to do additional
checks when it receives a Trigger frame from the AP.
[Also I don't know what "a response frame to a received triggering frame" is in the
new proposed text.]
Fragment: https://mentor.ieee.org/802.11/dcn/20/11-20-1647-00-00ax-mac-cr-on-fragmentation-for-draft-7-0.doc
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?
Your r0 resolution was:
An HE STA that is operating in level 2 or level 3 shall support level 1 dynamic fragmentation
which as I said was 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?
In r1 you now have:
An HE STA that is operating in level 2 or level 3 shall support to transmit and receive the dynamic fragments under level 1
but that basically has the same problem: is "under level 1" saying that
if the peer doesn't support L2/L3 you have to support L1, or is it
saying that in addition to supporting the types of dynamic fragments
described for L2/L3 you also support the L1 dynamic fragments
(when operating with an L2/L3 peer)?
I think
An HE STA that is operating in level 2 or level 3 shall also support level 1 dynamic fragments
is better because it clearly distinguishes the operating level from
the types of dynamic fragments that need to be supported.
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”
No, I think we need it in 26.3.1 for the description to be complete.
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)
We don't need to worry about PV1 MPDUs because HE does not use them.
12.5.3.1 says:
CCM also requires a unique nonce value for each frame
protected by a given temporal key(#4086). Reuse of a nonce value(#4086) with the same temporal key voids
all security guarantees.
12.5.3.3.4 shows that the nonce includes the priority (UP):
So I have two concerns with:
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.
1) I am not sure it's a problem if the PN repeats, as long as it's
for different UPs
2) But even if we play it safe an say the PN must never repeat full
stop, the specification shall be incremented so that the PN never repeats is not clear.
We need to be more explicit on how this is to be achieved, e.g.
does the sender have to remember all the PNs it has ever used and
pick one it hasn't used before, even if it's less than one it has
used before? Or can/shall it just remember the biggest it has ever used
and use one more than 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: *** 802.11 TGax - HEW - High Efficiency WLAN *** <STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx> On Behalf Of Ganming (Ming)
Sent: Tuesday, 20 October 2020 10:04
To: STDS-802-11-TGAX@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGAX] 答复: TGax CRC Teleconference 2020-10-20
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
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
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