[STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] 11-22-0230-02-00be-cc36-cr-of-

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

Dear all,

Thanks a lot for your good discussion. Since Xiaogang is open for the 20MHz operating STA, if no more concern is received, I will not distinguish the supported BW of the receiver STA in next revision to make the text simple.

About whether 320MHz BW signaling applied to an EHT AP that doesn’t support 320MHz, I more aligned with Wook Bong’s opinion. Besides what Wook Bong mentioned, one more reason is that in Co-OFDMA, AP1 with 160MHz support may cooperate with AP2 that support 320MHz BW, it may need AP 1 to understanding 320MHz signaling (the group haven’t discuss the details, but it may happens). Now, if we decide that 160MHz AP doesn’t understand 320MHz signaling, we can not change the decision later. But I don’t have a strong opinion on this point.

Let’s hear more opinions from others. I will update a new version tomorrow base on the group’s input.

Regards,

Yunbo

发件人: Wook Bong Lee [mailto:wookbong.lee@xxxxxxxxxxx]
发送时间: 2022年3月3日 4:39
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] 11-22-0230-02-00be-cc36-cr-of-cid-4147-and-5311

Hi Yongho,

I understood.

But if we want to limit this only to non-AP STA, then we need to have lots of spec text. Need to split case by case.

In my opinion, this is same as below case.

160 MHz signaling TA support for 80 MHz AP.

Do we have a different requirement for this 80 MHz AP?

Furthermore, if AP is not 320 MHz capable, then regardless of the spec, there is no case the AP will receive 320 MHz PPDU from the non-AP STA associated with the AP. Then, do we need to handle this issue?

Best regards,

Wook Bong Lee

From: Yongho Seok [mailto:yongho.seok@xxxxxxxxx]
Sent: Wednesday, March 2, 2022 10:32 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 11-22-0230-02-00be-cc36-cr-of-cid-4147-and-5311

An EHT AP that does not support 320MHz does not need to support this 320 MHz signaling TA, since the issue only happens at the non-AP.
If mandating 320 MHz signaling TA, it should be limited to an EHT non-AP 6G STA only in the spec.

Thanks,

Yongho

2022년 3월 2일 (수) 오전 10:09, Chen, Xiaogang C <xiaogang.c.chen@xxxxxxxxx>님이 작성:

Thanks Wook Bong.

Sounds like a good argument. I am open to make it simple :). Let’s hear others opinion.

From: Wook Bong Lee <wookbong.lee@xxxxxxxxxxx>
Sent: Wednesday, March 2, 2022 8:42 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 11-22-0230-02-00be-cc36-cr-of-cid-4147-and-5311

Hi all,

As I mentioned during the call, if we just mandate 320 MHz signaling TA for all STA 6G, the spec will be much simpler. And all these discussion can be resolved.

As far as I know, we don’t distinguish different bandwidth supporting device supporting signaling TA differently.

I don’t know why we should take a different direction this time.

Best regards,

Wook Bong Lee

From: Liyunbo [mailto:00001846a2e5e0c1-dmarc-request@xxxxxxxxxxxxxxxxx]
Sent: Wednesday, March 2, 2022 7:22 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] 答复: 11-22-0230-02-00be-cc36-cr-of-cid-4147-and-5311

Hi Xiaogang,

I agree that when the RX STA validate the BW parameter, it already knows the frame type. But it doesn’t good to generate the value of BW after frame type is parsed in MAC. The procedure is the value is first generated in PHY layer, but before it transfer to MAC the STA not sure whether the BW parameter is valid. In MAC layer only check the validity of BW parameter. If the BW parameter is not valid, then this parameter will be ignored.

If it is still not clear for you, we can further discuss in the meeting when I run the SP.

Regards,

Yunbo

发件人: Chen, Xiaogang C [mailto:xiaogang.c.chen@xxxxxxxxx]
发送时间: 2022年3月2日 23:13
收件人: Liyunbo <liyunbo@xxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: RE: 11-22-0230-02-00be-cc36-cr-of-cid-4147-and-5311

Hi Yunbo

The BW info is only “usable” after “validation” like other frames. As long as the validation is done in MAC, my understanding is receiver already know the frame type which is also parsed in MAC.

From: Liyunbo <liyunbo@xxxxxxxxxx>
Sent: Tuesday, March 1, 2022 11:50 PM
To: Chen, Xiaogang C <xiaogang.c.chen@xxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: 答复: 11-22-0230-02-00be-cc36-cr-of-cid-4147-and-5311

Hi Xiaogang,

Thanks for your good question. The sentence you marked is to say that the “validity” instead of the “value” of BW parameter is determined in MAC. The reason is that whether a non-HT duplicated frame carries BW info in scrambling sequence is indicated through signaling TA which is in MAC. So the decoding of BW of non-HT duplicated frame is still in PHY layer, then PHY layer will transfer the BW info through RXVECTOR to MAC to confirm the “validity”. We can not change the procedure to let the receiver first go to MAC layer to get indication information and then back to PHY layer to do BW decoding and then transfer the decoding result to MAC again.

If my understanding is wrong, PHY experts can correct me, thanks.

Regards,

Yunbo

发件人: Chen, Xiaogang C [mailto:xiaogang.c.chen@xxxxxxxxx]
发送时间: 2022年3月2日 11:43
收件人: Liyunbo <liyunbo@xxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: RE: 11-22-0230-02-00be-cc36-cr-of-cid-4147-and-5311

Thanks Yunbo to clarify.

From the note below, isn’t it mean the decision of BW is made in MAC instead of PHY?

From: Liyunbo <liyunbo@xxxxxxxxxx>
Sent: Tuesday, March 1, 2022 4:41 PM
To: Chen, Xiaogang C <xiaogang.c.chen@xxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: 答复: 11-22-0230-02-00be-cc36-cr-of-cid-4147-and-5311

Hi Xiaogang,

Thanks for your questions. Below are my responses, let me know whether it is clear for you.

For the MAC frame, you only made changes to RTS and CFEnd frame? PS poll, NDPA, BAreq frame are listed but no change has been made?

[Yunbo] In the paragraphs of RTS and CF-End, there were description about “to an EHT STA with 320MHz bandwidth support”, it conflict with our intention that a STA with narrower band also need to decode the BW from scrambling sequence and SERVICE field. That’s the reason we change this part.

In the paragraphs of PS-Poll, NDPA, BAR, there were no limitation about receiver side, it aligned with our intension, so no change is needed.

The intension of changes to RTS/CFend is to allow 80/160MHz STA understand 320MHz RTS or CFend? Why these narrow BW operating STA need to understand 320Mhz RTS or CFEnd?

[Yunbo] Good question. Because the BW decoding is in PHY layer, a receiving STA hasn’t know the frame type when a STA get BW information. The intension of change is not just for RTS/CF-END, but for any type of frame transmitted in non-HT duplicated format. From the receiver STA’s point of view, it follows the same procedure of decoding BW no matter it is an individual addressed or broadcast addressed frame.

Regards,

Yunbo

发件人: Chen, Xiaogang C [mailto:xiaogang.c.chen@xxxxxxxxx]
发送时间: 2022年3月2日 4:25
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] 11-22-0230-02-00be-cc36-cr-of-cid-4147-and-5311

Thanks Yunbo.

Can you clarify/confirm

For the MAC frame, you only made changes to RTS and CFEnd frame? PS poll, NDPA, BAreq frame are listed but no change has been made?
The intension of changes to RTS/CFend is to allow 80/160MHz STA understand 320MHz RTS or CFend? Why these narrow BW operating STA need to understand 320Mhz RTS or CFEnd?

From: Hanqing Lou <Hanqing.Lou@xxxxxxxxxxxxxxxx>
Sent: Tuesday, March 1, 2022 9:08 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBE] 11-22-0230-02-00be-cc36-cr-of-cid-4147-and-5311

Yunbo and all,

Thanks for the discussions and clarifications. I didn’t see the definition of STA 6G with 20MHz operating bandwidth anywhere. I suggest to use the terminology defined in spec. Below is my suggestion:

During reception by a VHT STA, HE STA, EHT STA in 2.4 GHz band, EHT STA in 5 GHz band, ~~that is not a STA 6G~~, and 20 MHz operating EHT STA in 6 GHz band ~~or EHT STA that is a STA 6G with 20MHz operating bandwidth~~(#4147), RXVECTOR parameter CH_BANDWIDTH_IN_NON_HT shall be determined from selected bits in the scrambling sequence as shown in Table 17-7 (Contents of the first 7 bits of the scrambling sequence) and Table 17-9 (RXVECTOR parameter CH_BANDWIDTH_IN_NON_HT values for a VHT or HE STA).

During reception by an EHT STA 6G that is not a 20MHz operating EHT STA ~~that is~~ ~~a STA 6G with operating bandwidth greater than 20 MHz~~(#4147), the RXVECTOR parameter CH_BANDWIDTH_IN_NON_HT shall be determined from selected bits in the scrambling sequence as shown in Figure 17-6 (SERVICE field bit assignment), Table 17-7 (Contents of the first 7 bits of the scrambling sequence), and Table 17-9a (RXVECTOR parameter CH_BANDWIDTH_IN_NON_HT values for an EHT STA).

Best regards,

Hanqing

From: Liyunbo <00001846a2e5e0c1-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Tuesday, March 1, 2022 1:47 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] 答复: 11-22-0230-02-00be-cc36-cr-of-cid-4147-and-5311

Hi Xiaogang,

Thanks. I modified the text based on your suggestions (highlighted in green). Please double check.

Dear all,

Please let me know whether the modifications are fine for you, thanks.

Regards,

Yunbo

发件人: Chen, Xiaogang C [mailto:xiaogang.c.chen@xxxxxxxxx]
发送时间: 2022年3月1日 9:59
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] 11-22-0230-02-00be-cc36-cr-of-cid-4147-and-5311

Hi Ross

Yes. That’s the cases I talked about.

IMO, the changes are also future proof in case 20MHz only is introduced.

From: Yujian (Ross Yu) <ross.yujian@xxxxxxxxxx>
Sent: Monday, February 28, 2022 4:19 PM
To: Chen, Xiaogang C <xiaogang.c.chen@xxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: 答复: 11-22-0230-02-00be-cc36-cr-of-cid-4147-and-5311

Hi Xiaogang,

6GHz only supports 80MHz or above only STA currently. You are talking about 20MHz operating STA which reduced its operating bandwidth from 80MHz or above to 20MHz. Do I understand correctly? The STA shall have the capability to understand 320MHz NDPA bandwidth. Whilst if the STA chooses to reduce its bandwidth to 20MHz, during that period, the STA can choose to not understand the 320Mhz NDPA. Is it the case?

Ross Jian Yu 于健

Huawei Technologies

发件人: Chen, Xiaogang C [mailto:xiaogang.c.chen@xxxxxxxxx]
发送时间: 2022年3月1日 8:06
收件人: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: Re: [STDS-802-11-TGBE] 11-22-0230-02-00be-cc36-cr-of-cid-4147-and-5311

Hi Yunbo

Here are my thoughts:

20MHz operating STA is not supposed to be addressed by 320MHz NDPA. We don’t need to mandate these STAs to interpret 320Mhz NDPA. I asked if there are other 320MHz frames need to be parsed by 20MHz STA 6G and you said no others? Seems you also changed RTS and CFEnd (there are also several other MAC frame in your doc but I don’t see changes?).
If it’s only about sounding, I suggest the following edits. If there are other 320MHz MAC frames, except NDPA, need to be interpreted by 20MHz STA, then I don’t have strong opinion to keep original text.

If dot11EHTOptionImplemented is equal to true and the STA is not a STA 6G(#4147) or a 20MHz operating STA 6G, then the allowed values are CBW20, CBW40, CBW80, or CBW160.

If dot11EHTOptionImplemented is equal to true and the STA is a STA 6G(#4147) with operating bandwidth greater than 20MHz, then the allowed values are CBW20, CBW40, CBW80, CBW160, or CBW320.

From: Liyunbo <00001846a2e5e0c1-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Sunday, February 27, 2022 4:25 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] 答复: 11-22-0230-02-00be-cc36-cr-of-cid-4147-and-5311

Hi Wook Bong,

Thanks for your question. Current text is clear for me, 20MHz only STA is not related for now. Let’s see whether Xiaogang has concern or suggestions.

Regards,

Yunbo

发件人: Wook Bong Lee [mailto:wookbong.lee@xxxxxxxxxxx]
发送时间: 2022年2月26日 1:00
收件人: Liyunbo <liyunbo@xxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: RE: 11-22-0230-02-00be-cc36-cr-of-cid-4147-and-5311

Hi Yunbo and Xiaogang,

Thanks for discussion.

Do we need to worry about 20 MHz only STA?

It is clear that this is only for STA 6G.

The TA field is the address of the STA transmitting the RTS frame or the bandwidth signaling TA of the STA transmitting the RTS frame. In an RTS frame transmitted by an EHT STA that is a STA 6G with 320 MHz bandwidth support in a non-HT or non-HT duplicate format to another EHT STA that is a STA 6G

Best regards,

Wook Bong Lee

From: Liyunbo [mailto:00001846a2e5e0c1-dmarc-request@xxxxxxxxxxxxxxxxx]
Sent: Thursday, February 24, 2022 10:44 PM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] 答复: 11-22-0230-02-00be-cc36-cr-of-cid-4147-and-5311

Hi Xiaogang,

Thanks for your feedback.

As you said, since 20MHz only STA is not allowed in 6GHz yet. So current text doesn’t related to 20MHz only STA. How about we clarify the rule for 20MHz only STA based on the decision from the group when it is allowed?

From my knowledge, there is no other frame with 320MHz non-HT duplicated format need to be understand by 20MHz only STA.

Regards,

Yunbo

发件人: Chen, Xiaogang C [mailto:xiaogang.c.chen@xxxxxxxxx]
发送时间: 2022年2月25日 4:38
收件人: Liyunbo <liyunbo@xxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
主题: RE: 11-22-0230-02-00be-cc36-cr-of-cid-4147-and-5311

Thanks Yunbo.

CID 4147 is about 320Mhz NDPA, so I add my understanding below:

80/160MHz STA already mandatory support Full BW MU feedback for 320MHz NDPA, so these STA need to understand 320MHz indication in service field for sure.
20MHz only STA is not allow in 6GHz yet. Even it is allowed, BFer is not supposed to address to 20MHz STA with 320MHz NDPA. So no matter 20MHz STA support 320MHz NDPA or not, there is no interop issue.

Btw, I cannot find any change directly related to NDPA in your document except RXVECTOR below. If the highlighted is used to cover NDPA, my question is if 20MHz only device is allowed in 6GHz, they also need to support 320MHz BW signaling even they will never be able to participate 320MHz sounding? Is there other frames with 320MHz non-HT dup format need to be understood by 20Mhz only STA?

Parameter

Associated primitive

Value

CH_BANDWIDTH

_IN_NON_HT

PHY-RXSTART.request(RXVECTOR)

Not present if neither dot11VHTOptionImplemented nor dot11HEOptionImplemented is present or equal to true.

Present if at least one of dot11VHTOptionImplemented and dot11HEOptionImplemented is present and equal to true.

If dot11EHTOptionImplemented is not present or equal to false, then the allowed values areIf present, CBW20, CBW40, CBW80, CBW160, or CBW80+80.

If dot11EHTOptionImplemented is equal to true and the STA is not a STA 6G(#4147), then the allowed values are CBW20, CBW40, CBW80, or CBW160.

If dot11EHTOptionImplemented is equal to true and the STA is a STA 6G(#4147), then the allowed values are CBW20, CBW40, CBW80, CBW160, or CBW320.

From: Liyunbo <00001846a2e5e0c1-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Wednesday, February 23, 2022 8:54 AM
To: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBE] 11-22-0230-02-00be-cc36-cr-of-cid-4147-and-5311

Dear all,

I initial this e-mail thread to discuss the issue of BW signaling of NPDA which mentioned in CID 4147. Please let me know your comments and suggestions, thanks.

I uploaded 230r2 to the server to incorporate Po-Kai’s comments during the presentation.

https://mentor.ieee.org/802.11/dcn/22/11-22-0230-02-00be-cc36-cr-of-cid-4147-and-5311.docx

Regards,

Yunbo

To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1

To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1

To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1

To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1

To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1

To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1

To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1

To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1

To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1

To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1

To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1

To unsubscribe from the STDS-802-11-TGBE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBE&A=1

[STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] 11-22-0230-02-00be-cc36-cr-of-cid-4147-and-5311