| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
If there needs to be a “full bandwidth …
PPDU”, there logically must be a need for a “partial bandwidth … PPDU”. What’s
that? Note that one could also argue for an “empty bandwidth … PPDU”, “empty”
being the element that completes the set of adjectives [full, partial, empty]!
:^))) Cheers, RR From: Wook Bong Lee
[mailto:wookbong.lee@xxxxxxxxxxx] Hi Bin, I am fine with “a
full bandwidth non-OFDMA EHT PPDU” What I am trying to
say was that we can define what is exactly mean by it as we defined each
terminology somewhere. Best regards, Wook Bong Lee From: Bin Tian
[mailto:btian@xxxxxxxxxxxxxxxx] Hi Wook Bong Thanks for your review. Please find my inline
comments below. Bin From: Wook Bong Lee
<wookbong.lee@xxxxxxxxxxx> CAUTION: This email originated from outside of the
organization. Hi Bin, I reviewed
11-20/1153r2. Thanks for your
effort. I have few comments
(including editorial). 1.
PPDU
name: currently you used “a full bandwidth non-OFDMA EHT PPDU”, “a punctured
non-OFDMA EHT PPDU”, and “and OFDMA EHT PPDU”. In my opinion, either we define
those PPDU or use defined PPDU. For example, a full bandwidth non-OFDMA EHT
PPDU: an EHT MU PPDU, compressed mode (non-OFDMA) without puncturing. Bin> Generally speaking, EHT PPDU potentially
refers to all EHT PPDU types. Also, I think “a full bandwidth non-OFDMA EHT
PPDU" is more clear than “ an EHT MU PPDU, compressed mode
(non-OFDMA) without puncturing". But I am open for the group
discussion. To avoid making repeated changes, how about I keeping these
terms for now and making these changes in the future once the TG agrees on
terminology? 2.
Type
in table 2. CBW160 with 40Mhz puncturing à CBW160 with 40 MHz
puncturing Bin> Done. Thanks, 3.
Sometimes
there is no space between “number” and “unit”. Need a space. E.g. “40 MHz” Bin> Done. Thanks Best regards, Wook Bong Lee From: Bin Tian [mailto:btian@xxxxxxxxxxxxxxxx] Good
point. Depending on discussion outcome, I can update it in the next revision. Thanks
for the review. Bin From: Yujian (Ross Yu) <ross.yujian@xxxxxxxxxx> CAUTION: This email originated from outside of the
organization. Hi Bin, Thanks for the work. Very efficient. One general comment is in table 2 for
example, CBW160+160 is missing according to the current SFD. Whilst I know Rui
is going to discuss this soon. regards 于健 Ross Yu Huawei
Technologies 发件人: Bin Tian [mailto:btian@xxxxxxxxxxxxxxxx]
Hi
TTT members and all As
you know, Timing related parameter is a single section in PHY that
defines the most commonly used variable and parameters which are needed for the
drafting of other PHY sections. Traditionally this section has to be drafted
first. To save time and be consistent in content, my colleague Lin Yang
and I have taken a stab by porting this section from 11ax D6.0 to the EHT draft
and make some necessary changes to reflect the new bandwidth and RU/MRU size
introduced in EHT. There are some TBDs which we have highlighted in yellow and
can be updated in the future depending on the PHY discussion outcome. I
have uploaded the initial version to the mentor as 11-20/1153r0. Please
take a look and let me know if you have any comments and suggestions. Thanks, Bin
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 |