Hi Yong,
Thanks for the confirmation. If we introduce a new type of control frame, but still cannot support full flexibility to indicate each 20MHz, or need
to aid by scrambler sequence, I am still not so comfort with that.
The main purpose to do so is to preserve the NAV reset rule, but it can only applied to 11ax STA, not all legacy STAs, we also need to evaluate the
value of it.
Regards,
Yunbo
发件人: Yong Liu [mailto:yliu007@xxxxxxxxx]
发送时间: 2020年7月2日
0:39
收件人: Liyunbo <liyunbo@xxxxxxxxxx>
抄送: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx; yongliu <yongliu@xxxxxxxxx>; lochan_verma@xxxxxxxxx
主题: Re: [STDS-802-11-TGBE] 11-20-0747-00-00be-rts-cts-in-11be
Hi Yunbo,
Good catch!
How could I forget this ... probably getting old :-)
So I guess only one byte can be added, unless people really hate odd number of bytes in the MAC payload.
It should still be possible to encode the allowed puncture modes in one byte.
Indicating BW in scrambler sequence should help also.
Thanks,
Yong
On Wed, Jul 1, 2020 at 12:54 AM Liyunbo <liyunbo@xxxxxxxxxx> wrote:
Hi Yong,
Got your point. But you may forget that there are 6 tail bits following PSDU, so when 2 more bytes are added in ehtCTS, it needs one extra OFDM symbol. Please double check it.
Regards,
Yunbo
发件人: Yong Liu [mailto:yliu007@xxxxxxxxx]
发送时间: 2020年7月1日 8:18
收件人: Liyunbo <liyunbo@xxxxxxxxxx>
抄送: STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx; yongliu <yongliu@xxxxxxxxx>; lochan_verma@xxxxxxxxx
主题: Re: [STDS-802-11-TGBE] 11-20-0747-00-00be-rts-cts-in-11be
Hi Yunbo,
Our intention is to make ehtCTS the same PPDU duration (# of symbols) as the CTS frame.
Here is the calculation:
Non-HT 6Mbps => 3 bytes / symbol
CTS frame: 2 bytes (Service) + 14 bytes (MAC payload) = 16 bytes (+2 byte PHY padding) => 6 symbols
For ehtCTS frame, we add 2 byte to the MAC payload (w/o PHY padding), which results in the same 6 symbol duration.
Therefore, the ehtCTS frame does preserve the NAV reset rule for 11ax devices.
I believe a QoS Null with BQR has a duration much longer than CTS / ehtCTS.
Also, we intend to define ehtCTS as a control frame very similar to CTS, which can be processed very fast to meet the SIFT turnaround time.
QoS Null with BQR is typically not processed by the same control frame logic, and probably needs much longer time to process.
Let me know if you have any further comment/concern.
Thanks,
Yong
On Sun, Jun 28, 2020 at 3:16 AM Liyunbo <liyunbo@xxxxxxxxxx> wrote:
Hi Yong,
Thanks for your response. I got your points for the first two questions, let’s further discuss when some SP touch the detail designs.
In Question(3), I mean use the procedure MU-RTS/BQR. It means using BQR carried in QoS Null frame to response MU-RTS frame. The benefit is we don’t need to introduce a new ehtCTS frame. Base on my understanding, ehtCTS frame is also longer than current CTS frame, because it need to carry BW bitmap. So if you want to preserve the NAV reset rule for 11ax devices, it will meet the same problem for both ehtCTS and BQR frame, am I understanding right?
Regards,
Yunbo
发件人: Yong Liu [mailto:yliu007@xxxxxxxxx]
发送时间: 2020年6月25日 9:38
收件人: Liyunbo <liyunbo@xxxxxxxxxx>; STDS-802-11-TGBE@xxxxxxxxxxxxxxxxx
抄送: yongliu <yongliu@xxxxxxxxx>; lochan_verma@xxxxxxxxx
主题: Re: [STDS-802-11-TGBE] 11-20-0747-00-00be-rts-cts-in-11be
Hello Yunbo,
Thanks for your questions, and sorry for my late reply.
Please see my responses inline below.
Please feel free to ping us for any further questions.
Cheers,
Yong
On Mon, Jun 22, 2020 at 2:46 AM Liyunbo <liyunbo@xxxxxxxxxx> wrote:
Hi Yong and Lochan,
Because of time limit, I didn’t get a chance to ask questions during teleconference. Would you please clarify below questions? Thanks.
1) Slide 7: There are both BW and puncture patent subfields in the special user info field of MU-RTS in your presentation. Since puncture pattern will provide detailed information for each 20MHz subchannels, why we still need BW subfield here?
<Yong> We just want to make it explicitly clear about the MU-RTS transmission BW, since the UL BW field is not able to indicate > 160MHz.
We are open to other options as far as they can cover all the BW and puncture cases and not lead to complicated parsing logics.
2) Slide 8: In the last bullet, one bit is used to distinguish which CTS frame format will be used in response of MU-RTS. Since ehtCTS is used for single STA, while CTS is used for more than one STAs. This information can be obtained by STA itself by counting the number of User info field. Why a bit indication is needed here?
<Yong> We thought about that option, but worried that more “special User Info fields” may be added for other purposes.
Repurposing a bit is probably more future-proof than counting the number of User Info fields.
3) Slide 9: an new ehtCTS is introduced in this page. Its function is almost the same as BQR in current standard. Do we still need to introduce this new frame? Isn’t a better idea to reuse BQR frame here?
<Yong> When you say BQR frame, do you mean a QoS Null frame that carries the BQR Control subfield?
Not sure how to reuse it as a response to a MU-RTS? Or you mean replacing MU-RTS with BQRP Trigger also?
One of the major reasons for us to choose MU-RTS / ehtCTS was to preserve the NAV reset rule for 11ax devices.
If ehsCTS is replaced with a frame longer than CTS_Time, the NAV reset rule may not work correctly.
Also, BQR does not seem to be very popular?
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