Hello,
https://mentor.ieee.org/802.11/dcn/21/11-21-0727-01-000m-revme-phy-comments.xls
has been uploaded.
The following resolutions, from the PHY Motion A tab,
are due to be motioned during the session at 16:00 ET (20:00 UTC) today:
|
CID |
Commenter |
Comment |
Proposed Change |
Resolution |
|
349 |
Mark RISON |
"RCPI indications of 8 bits are supported." duplicates first sentence |
Delete the cited sentence |
ACCEPTED (PHY: 2021-06-14 20:21:34Z) |
|
89 |
Hitoshi Morioka |
T_L-SIG is also defined in Table 21-5, where "_" indicates
suscript. |
Add "T_L-SIG" to the list, where "_" indicates subscript. |
REVISED (PHY: 2021-06-14 20:20:52Z) |
|
88 |
Hitoshi Morioka |
T_L-SIG is also defined in Table 19-6, where "_" indicates
suscript. |
Add "T_L-SIG" to the list, where "_" indicates subscript. |
REVISED (PHY: 2021-06-14 20:20:15Z) |
|
87 |
Hitoshi Morioka |
HT_SIG should be HT-SIG. |
Replace "HT_SIG" with "HT-SIG". |
ACCEPTED (PHY: 2021-06-14 20:19:41Z) |
|
86 |
Hitoshi Morioka |
HT_SIG should be HT-SIG. |
Replace "HT_SIG" with "HT-SIG". |
ACCEPTED (PHY: 2021-06-14 20:18:39Z) |
|
85 |
Hitoshi Morioka |
L_SIG and HT_SIG should be L-SIG and HT-SIG respectively. |
Replace "L_SIG" with "L-SIG". Replace "HT_SIG" with "HT-SIG". |
ACCEPTED (PHY: 2021-06-14 20:18:21Z) |
|
84 |
Hitoshi Morioka |
L_SIG and HT_SIG should be L-SIG and HT-SIG respectively. |
Replace "L_SIG" with "L-SIG". Replace "HT_SIG" with "HT-SIG". |
ACCEPTED (PHY: 2021-06-14 20:17:56Z) |
|
83 |
Hitoshi Morioka |
N_HTDLTF should be N_HT-DLTF, where "_" indicates subscript. |
Replace "N_HTDLTF" with "N_HT-DLTF", where "_" indicates subscript. |
REVISED (PHY: 2021-06-14 20:17:13Z) |
|
569 |
Rui Cao |
The normalization factor of N_TX in the denominator is not correct for HT portion. Need to update according to VHT and HE equations. |
Separate normalization factor differently for preamble portion and data portion as in
Equation (21-13) and definition of N_Norm in P3151L24.. |
REVISED (PHY: 2021-06-14 20:23:31Z) |
|
568 |
Rui Cao |
non-HT dup data portion needs to be power normalized across
N_tx, the same as legacy preamble portion. Otherwise, there is a power bump of
sqrt(Ntx) from preamble to data portion. |
add N_TX in the denominator of the normalization factor. |
REVISED (PHY: 2021-06-14 20:22:42Z) |
|
567 |
Rui Cao |
non-HT dup data portion needs to be power normalized across
N_tx, the same as legacy preamble portion. |
add
N_tx in the denominator of the normalization factor. |
REVISED (PHY: 2021-06-14 20:21:59Z) |
|
19 |
Brian Hart |
VHT uses "Segment" in
assocation with two different concepts: for non-contiguous spectrum (e.g.
Equation (21-11)) and for per-80MHz processing (e.g. the Segment parser used to construct two 80 MHz streams for BCC interleaving
etc as part of creating a 160 MHz PPDU), although it is clear that the former usage is the intended usage (clause 3: "frequency segment: A contiguous block of spectrum used by a transmission."; and
Nseg=1 for 160MHz in Table 21-5). However, many members see "Segment parser" in the block diagrams and are more familiar with 160 MHz, so then associate "segment" with 80 MHz processing (or less for narrower PPDUs). This caused on-going
confusion in 11ax: e.g. as late as D7.0 of 11ax there was a fundamental error on this topic: the number of data tones per frequency segment,
Nsd, had two incompatible definitions
(Nsd in table 27-13 that differed for 80+80 vs 160 versus
Nsd in section 27.5.7 that had no differentiation between 80+80 vs 160). 11ax's ultimate fix was almost complete: it kept "frequency segment" for non-contiguous PPDUs, and used "frequency
subblock" for
80 MHz processing (or less for narrower PPDUs); but the confusing/ misleading term "Segment de/parser" remains. By its name, "segment parser" implies it takes one input stream and parses it into one or more segments. But for 160 MHz, the so-called Segment parser
takes one stream and parses into two frequency subblocks in *one* segment. |
"Segment parsed/parser/parsing" are terms used locally within the VHT, TVHT and S1G PHYs
PHYs today (and HE PHY) so making a name correction is relatively straightforward. However, "Segment de/parser" are embedded terms in the industry, and - despite the need to reduce confusion in 11ax and now 11be - it may be too confusing
to entirely replace the name. Meanwhile it is fair to point out that, for 80+80, if not for 160M, the "Segment parser" outputs both segments and frequency
subblocks. Then change "Segment [de]parser/parsing/parsed" to "Frequency-subblock/Segment [de]parser/parsed/parsing" throughput the draft. This change has the virtue that a) searching for "Segment pars"
is still successful, b) the more correct name appears first, c) the new name is not incorrect in that sometimes the Frequency-subblock/Segment parser does output segments. |
REVISED (PHY: 2021-06-14 19:54:41Z) - Incorporate the changes in https://mentor.ieee.org/802.11/dcn/21/11-21-0965-01-000m-cc35-phy-cids-19-18-14-15-527.docx,
for CID 19. |
|
17 |
Brian Hart |
This figure has got broken since the top line has 4 outputs but no input. Also the superscripts are hard to read. Finally it is unclear
where the output comes from. |
Copy across figure 16-3 since there the top line has an input and it says "X15 first" in two places (yet check for any other differences
that aren't corrections, but AFAIK there shouldn't be any). |
REVISED (PHY: 2021-06-14 20:15:59Z) |
Thanks,
Mark
--
Mark RISON, Standards Architect, WLAN English/Esperanto/Français
Samsung Cambridge Solution Centre Tel: +44 1223 434600
Innovation Park, Cambridge CB4 0DS Fax: +44 1223 434601
ROYAUME UNI WWW:
http://www.samsung.com/uk
To unsubscribe from the STDS-802-11-TGM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1