[STDS-802-11-TGBE] 答复: [STDS-802-11-TGBE] 11-20-0747-00-00be-rts-cts-in-11be

[Liyunbo <liyunbo@xxxxxxxxxx>]

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