Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
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]
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]
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>
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]
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>
Hi Xiaogang, Thanks for your questions. Below are my responses, let me know whether it is clear for you.
[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.
[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]
Thanks Yunbo. Can you clarify/confirm
From: Hanqing Lou <Hanqing.Lou@xxxxxxxxxxxxxxxx>
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, During reception by an EHT STA 6G
that is not a 20MHz operating EHT STA Best regards, Hanqing From: Liyunbo <00001846a2e5e0c1-dmarc-request@xxxxxxxxxxxxxxxxx>
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]
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>
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]
Hi Yunbo Here are my thoughts:
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>
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]
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]
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]
Thanks Yunbo. CID 4147 is about 320Mhz NDPA, so I add my understanding below:
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?
From: Liyunbo <00001846a2e5e0c1-dmarc-request@xxxxxxxxxxxxxxxxx>
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 |