However, I (Adrian) am willing to accept that most folks in TGac don’t care about the architecture. Therefore I will limit any proposed changes in this document to those easily made. Actioning this particular comment would result in new primitives and interaction with the PLCP rx state machine text and diagrams; these changes are too extensive to be considered made”. Therefore I’m OK with “easily rejecting the comment as shown. 5227 Sigurd 268.01 22.3.21 PHY-RXEND takes two PHY_RXEND has been J Rejected. parameters redefined to take two parameters (see 7.3.5.13.2 in 7.3.5.13.2 in mb). This states should be reflected is an “RXVECTOR here. included parameter only when is true.” We have assumed in the PLCP receive state machine that is false. 4754 There are Align and complete the several two figures:- Say "Bit inconsistencies padding (if needed)" and between "Tail bits (if BCC)" in rx- Figure 22-25 Pass an A-MPDU up to (PLCP tx) and the MAC in rx- Put in the Figure 22-27 appropriate PMD data (PLCP rx):- In signals in rx- Include tx, the PSDU handling in the gets "Bit PLCP in rx and remove Padding if the second sentence of needed" and the NOTE- Show how the "Tail Bits (if PARTIAL_AID/GROUP_ID BCC)" before it are passed down for tx- is scrambled Rename "VHT-Training" in and encoded rx and "VHT Training to a C-PSDU. Symbols" in tx to In rx, they're or "VHT-STF" apparently and "VHT-LTF"- Rename always Non-VHT Training present- In tx, Symbols from the PLCP the MAC and rename it to passes an or "L-STF" and while in in tx- Remove the rx the MAC is line of dots at the top of tx passed an MPDU- There is no PMD data indication or data end
However, I (Adrian) am willing to accept that most folks in TGac don’t care about the architecture. Therefore I will limit any proposed changes in this document to those easily made. Actioning this particular comment would result in new primitives and interaction with the PLCP rx state machine text and diagrams; these changes are too extensive to be considered “easily made”. Therefore I’m OK with rejecting the comment as shown. 5227 Sigurd 268.01 22.3.21 PHY-RXEND takes two parameters PHY_RXEND has been redefined to take two parameters (see 7.3.5.13.2 in mb). This should be reflected here. J Rejected. 7.3.5.13.2 in states “RXVECTOR is an included parameter only when is true.” We have assumed in the PLCP receive state machine that is false. 4754 There are several inconsistencies between Figure 22-25 (PLCP tx) and Figure 22-27 (PLCP rx):- In tx, the PSDU gets "Bit Padding if needed" and "Tail Bits (if BCC)" before it is scrambled and encoded to a C-PSDU. In rx, they're apparently always present- In tx, the MAC passes an while in rx the MAC is passed an MPDU- There is no PMD data indication or data end Align and complete the two figures:- Say "Bit padding (if needed)" and "Tail bits (if BCC)" in rx- Pass an A-MPDU up to the MAC in rx- Put in the appropriate PMD data signals in rx- Include handling in the PLCP in rx and remove the second sentence of the NOTE- Show how the PARTIAL_AID/GROUP_ID are passed down for tx- Rename "VHT-Training" in rx and "VHT Training Symbols" in tx to or "VHT-STF" and "VHT-LTF"- Rename Non-VHT Training Symbols from the PLCP and rename it to or "L-STF" and in tx- Remove the line of dots at the top of tx
11-12-0503-01-00ac-lb187-clause-22-3-21-pmd-comment-resolutions.docx