Hi Yong,
You pasted my SP to challenge my argue points
J
Thanks for the very good discussion with you.
I would like to clarify that when CTS frame is used to indicate more BW information, scrambler sequence seems the only way that can work, so I support
that. But when new frame is introduced, indicate in the MAC frame body is more natural way. So I have concern of using scramble sequence in new frame.
Base on the discussion, I summary my understanding below to further sync our understanding. My personal opinion is either we reuse existing frame
(CTS or BQR) or introduce a new ehtCTS frame with full flexibility, glad to hear your further opinions.
Type 1: Reuse legacy CTS frame through scrambler sequence
Pros: can preserve NAV setting rule for all legacy STA; doesn’t need add new frame type
Cons: may only can support less puncture modes, lack of future extension (e.g. larger bandwidth, more puncture pattern, or other potential
future MAC function).
Type 2: introduce a new ehtCTS frame that encode only SU preamble punctured PPDU in 1 extra Byte
Pros: can only preserve NAV setting rule for ax STA
Cons: lack of future extension (e.g. larger bandwidth, more puncture pattern, or other potential future MAC function).
Type 3: introduce a new ehtCTS frame with 2 more Bytes to support full flexibility of each 20MHz
Pros: Can indicate full flexibility for each 20MHz
Cons: cannot preserve NAV setting rule for legacy STA (include ax STA)
Type 4: reuse current BQR frame
Pros: Can indicate full flexibility for each 20MHz; doesn’t need add new frame type
Cons: cannot preserve NAV setting rule for legacy STA (include ax STA); longer signaling overhead
Regards,
Yunbo
发件人: Yong Liu [mailto:yliu007@xxxxxxxxx]
发送时间: 2020年7月2日
9:55
收件人: 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,
Thanks for your comments.
I don't think scrambler sequence is really a concern here, according to the following strawpoll :-)
Straw poll #102
802.11be supports indicating BW larger than 160 MHz through scrambler sequence in non-HT or non-HT duplicated frames. [#SP102]
[20/0616r0 (Bandwidth indication of 320MHz for non-HT and non-HT duplicate frames, Yunbo Li, Huawei), SP#1, Y/N/A: 46/15/32]
As for puncture information, I believe 8-bit is more than enough to indicate all allowed large-RU puncture cases, plus some additional corner cases (if any).
Even if the scrambler sequence is not used to indicate BW, 8-bit should be enough to indicate both BW and allowed large-RU puncture cases.
Note that ehtCTS is only used for SU protection.
Also, it might be OK to reuse the CTS frame type for ehtCTS.
Not sure any implementation would drop ehtCTS due to one byte longer?
Regarding to the NAV reset rule, we are open to any solution that can apply to both 11ax STAs and legacy STAs.
There does not seem to be an obvious one though.
Thanks,
Yong
On Wed, Jul 1, 2020 at 6:10 PM Liyunbo <liyunbo@xxxxxxxxxx> wrote:
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