Hi Alice,
Thanks for your reply.
The descriptions in Table 9-46a and the EHT variant Common field are a bit confusing to me.
According to Note 1 under Table 9-46a, the text only refers to the EHT/UHR TB PPDU case involving a 4×996-tone RU, i.e., 320 MHz.
The HE/EHT P160 bit (B54) in the EHT variant Common field is used to indicate that the solicited TB PPDU in P160 is an HE TB PPDU when this bit
is set to 1. As I understand it, this applies to the last row of Table 9-46a, where the User Info field sets B39 to 0, meaning it's an HE variant addressed to an EHT non-UHR STA.
Based on this, it seems that the spec allows the Trigger frame to also carry another EHT variant User Info field—corresponding to the second-last
row of Table 9-46a. In this case, the Trigger frame would carry:
l
an EHT variant Common Info field with B54 = 1 and B55 = 0,
l
an HE variant User Info field with B39 = 0, and
l
an EHT variant User Info field with B39 = 1,
so as to solicit an HE TB PPDU in P160 and an EHT TB PPDU in S160 simultaneously.
However, Note 2 under Table 9-46a states that the last two rows are not used by an EHT AP. This seems contradictory—if these rows are not to be
used, then why was the HE/EHT P160 field (B54) introduced in the spec?
Could you please clarify this point?
Best Regards
-----------------------------------------------------------
Yaoshen Cui
崔耀燊
Tel: (+86)
0755-66869698-12478
Email: cuiyaoshen@xxxxxxxxxxxxxx
From: Alice Jialing Li Chen [mailto:jialing.li.phd2@xxxxxxxxx]
Sent: Thursday, May 29, 2025 10:07 PM
To: 崔耀燊 <cuiyaoshen@xxxxxxxxxxxxxx>
Cc: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] CC50 PDT-CR on Trigger frame
In NOTE1 under Table 9-46a, an EHT AP (including a UHR AP) shall not send a trigger frame with both HE and EHT variant.
It is correct that a UHR AP can't send a TF with both EHT and UHR variant.
Hi Alice,
Thanks for sharing your CR documents. I have a comment/question about your previous discussion.
It appears that the UHR AP send a trigger frame with both the HE variant and the EHT
variant, or both the HE variant and the UHR variant at the same time.
However, the UHR AP can’t send a trigger frame with both the EHT variant and the UHR
variant at the same time, as the differentiation is based on the PHY Version Identifier subfield in the Special User Info field, not in the User Info field.
Is this understanding correct?
Best Regards
-----------------------------------------------------------
Yaoshen Cui
崔耀燊
Tel: (+86)
0755-66869698-12478
Email:
cuiyaoshen@xxxxxxxxxxxxxx
From: Alice
Jialing Li Chen [mailto:jialing.li.phd2@xxxxxxxxx]
Sent: Thursday, May 29, 2025 12:39 PM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] CC50 PDT-CR on Trigger frame
Hi Alfred,
Thanks for your response,
In my understanding, you mean that AP sends a trigger frame (i.e., ICF) to both non-UHR
STA and UHR STA by using the HE variant or EHT variant. In this case, non-UHR STA performs TB PPDU transmission by using the HE variant or EHT variant, treating the B60 as a reserved bit, but even though UHR STA received the Trigger frame of the HE variant
or EHT variant, this STA can understand whether I-FCS is used or not by using the bit information of B60 in the common field of the HE variant or EHT variant.
Is my understanding correct?
Best regards,
Dongguk
______________________________________________________________________________________________
Dongguk Lim
Chief Technology Officer IoT Connectivity Standard Task/Professional
LG Electronics Inc
19, Yangjae-daero 11-gil, Seocho-gu, Seoul, Korea
M.82-10-8996-4690
E.dongguk.lim@xxxxxxx
From: Alfred
Asterjadhi [mailto:asterjadhi@xxxxxxxxx]
Sent: Wednesday, May 28, 2025 9:20 AM
To: Dongguk Lim <dongguk.lim@xxxxxxx>
Cc: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] CC50 PDT-CR on Trigger frame
Hi Dongguk,
The intention here is to allow the AP to poll both non-UHR STAs (that see the ICF Trigger frame in a legacy way) and UHR STAs (that need I-FCS) with the same
ICF Trigger frame (which needs to be EHT variant or HE variant to be understood by EHT or HE STAs, along with UHR STAs).
Hi Alice,
Thank you for sharing your CR documents.
Regarding 633, I have one comment and one question.
In your proposed modification, you suggested the inclusion of IFCS in both HE and EHT
variant common info fields.
In my understanding, since IFCS is a feature defined for a UHR STA, it cannot be used
for HE STA and EHT STA.
In addition, those STAs also cannot identify this information.
For these reasons, I think that we don’t need to modify the common field of the HE
and EHT variants.
If you want to change the operation of both HE and EHT STA regarding the defined IFCS,
I think that it is better to discuss this issue in the 11revmx.
Best regards,
Dongguk.
______________________________________________________________________________________________
Dongguk Lim
Chief Technology Officer IoT Connectivity Standard Task/Professional
LG Electronics Inc
19, Yangjae-daero 11-gil, Seocho-gu, Seoul, Korea
M.82-10-8996-4690
E.dongguk.lim@xxxxxxx
From: Alice
Jialing Li Chen [mailto:jialing.li.phd2@xxxxxxxxx]
Sent: Friday, May 23, 2025 8:55 AM
To: STDS-802-11-TGBN@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBN] CC50 PDT-CR on Trigger frame
The latest PDT-CR documents on Trigger frame for unresolved CIDs are the following. Could you please review? Your timely feedback is much appreciated!
·
11-25/633r0 Part 2 to resolve CIDs in
9.3.1.22.2, not presented yet
·
11-25/636r4 Part 5 to resolve CIDs in 9.3.1.22.7
– 9.3.1.22.9, presented/discussed in 5/12/2025 & 5/15/2025 TGbn Joint calls
The following PDT/CR documents have been uploaded.
-
9, 10, 61, 84, 193, 404, 405, 1065, 1203, 1567, 1568, 1985, 2084, 2340, 2523, 2875, 2876, 2877, 2878, 2879, 2880, 3161, 3270, 3271, 3474, 3631, 3722 in 11-25/442r5 [27
CIDs]
-
16, 113, 283, 557, 558, 1609, 2091, 2344, 2345, 2470, 2905, 2906, 3273, 3643, 3644, 3725 in 11-25/634r3 [16
CIDs]
Could you please add them to a motion in PM2?
The latest PDT-CR documents on Trigger frame are the following. Part 2 is new. Parts 1, 3, 4, 5, 6 were revised based on dicussion in the Monday TGbn Joint call.
·
11-25/442r4 Part 1 to resolve CIDs in 9.3.1.22 and 9.3.1.22.1
·
11-25/633r0 Part 2 to resolve CIDs in 9.3.1.22.2
·
11-25/634r2 Part 3 to resolve CIDs in 9.3.1.22.3
·
11-25/635r0 Part 4 to resolve CIDs in 9.3.1.22.6
·
11-25/636r4 Part 5 to resolve CIDs in 9.3.1.22.7
– 9.3.1.22.9
·
11-25/637r4 Part 6 to resolve CIDs in 9.3.1.22.10
– 9.3.1.33.16
PS: The following comments in the chat window have been addressed.
-
Mark: In "B39 is set to 0 for an HE variant User Info field by an EHT or UHR AP", "or UHR AP" has been deleted, but only "or UHR" should be deleted, otherwise the sentence doesn't work
-
Dibakar/Juan's comment
-
Mark: Isn't an UHR AP an EHT AP?
-
Mark: "MURTS" should be "MU-RTS". "MU RTS" should be "MU-RTS"
-
Mark: Field name should not include "/Reserved"
-
Mark: "Not-applicable" should be "Not applicable"
-
Yongho Seok Apple: "The UL Bandwidth Extension subfield, together with the UL BW subfield in the Common Info field, indicates the bandwidth of the solicited TB PPDU (i.e., the bandwidth in the U-SIG
field of the EHT TB PPDU or UHR TB PPDU) if the Trigger frame is not an MU-RTS Trigger frame (see 9.3.1.22.11 (MU RTS Trigger frame format))[#3643]" If it is BSRP GI3, the solicited PPDU is not TB PPDU.
-
Laurent: For NPCA Primary Channel indication, a more accurate description would be: The NPCA Primary Channel Indication is set to 1 if the Trigger frame is transmitted by an NPCA STA that has switched
to the NPCA primary channel (see 37.11 (Non-primary channel access (NPCA))) and is set to 0 otherwise.
-
Mark: "a EHT" should be "an EHT" (Alice: not found)
-
Mark: "of PS160" should be "of the PS160"
-
Mark: "DRU Size" should be "DRU size" (assuming not a field name)
-
(Alice: Rename fields. They're not the same field.) Mark: I don't think we can have a field with two names
-
Liwen: should Location Indication User Info field follow the style of I-FCS USer Info field (B12 to B15 being reserved)?
-
Change I-FCS to IFCS per editor’s input
-
Mark: “up to … and excluding …” is enough. Remove “any other …”
-
Mark: "is defined as a BSRP non-trigger based (NTB) Trigger frame" should be "is called a BRSP NTB Trigger frame", no?
-
Mark: missing comma in "UL Spatial Reuse field the UHR P160 field"
-
Mark: delete "always" in "is always set to 0"
One more PDT-CR document on the Trigger frame has been uploaded. Your timely feedback is much appreciated!
The following PDT-CR documents on the Trigger frame will be presented in a TGbn Joint call in the IEEE May meeting. Could you please review and let me know if
you have any comments and questions? Your timely feedback is much appreciated!
-
11-25/442r2 Part 1 to resolve CIDs in 9.3.1.22 and 9.3.1.22.1
-
11-25/634r0 Part 3 to resolve CIDs in 9.3.1.22.3
-
11-25/636r2 Part 5 to resolve CIDs in 9.3.1.22.7
– 9.3.1.22.9
-
11-25/637r2 Part 6 to resolve CIDs in 9.3.1.22.10
– 9.3.1.33.16
Two more PDT-CR documents on the Trigger frame are under preparation. Will let you know when they are ready.
-
11-25/633r0 Part 2 to resolve CIDs in 9.3.1.22.2
-
11-25/635r0 Part 4 to resolve CIDs in 9.3.1.22.6
To unsubscribe from the STDS-802-11-TGBN list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1
To unsubscribe from the STDS-802-11-TGBN list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1
To unsubscribe from the STDS-802-11-TGBN list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1
To unsubscribe from the STDS-802-11-TGBN list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1
To unsubscribe from the STDS-802-11-TGBN list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBN&A=1
