Proposed Response to the Interpretation Request for Annex G

Proposed Response to the Interpretation Request for Annex G Yasuhiko Inoue, Yusuke Asai and Takeshi Onizawa NTT Access Network Service Systems Laboratories mailto:yinoue@ansl.ntt.co.jp Y.Inoue, Y.Asai, T.Onizawa, NTT

The CRC field in Table G.14 – Last 144 DATA bits, appears to be wrong for the example frame Table G.1 shows the frame, including CRC, in transmit octet order but with each octet in [7..0] bit order. Table G.13 shows the first 144 bits in transmit order, i.e. each octet in [0..7] order. Table G.14 shows the last 144 bits in transmit order, i.e. each octet in [0..7] order. If the frame is converted to bit transmit order, as per G.13 and G.14, and passed through a CRC32 engine the resulting CRC will be '0C9DCF21'H in transmit order [msb..lsb]. However, Table G.14 shows the CRC as '5BEA99B7'H which appears to be incorrect. The CRC field in Table G.14 – Last 144 DATA bits, appears to be wrong for the example frame This seems to be a result of processing octets through the CRC engine in [7..0] bit order instead of [0..7] bit order and then reversing the bit order of each octet of the resulting CRC. In other words if the frame is processed through the CRC engine as it appears in Table G.1 instead of in the correct order, as shown in Tables G.13 and G.14, the resulting CRC will be incorrectly calculated as 'DA5799ED'H, which is what appears in Table G.1. If each of the octets of this CRC is then reversed in place the result is '5BEA99B7'H which is what appears as the last four octets of Table G.14. To correct the error and produce a CRC of '0C9DCF21'H in transmit order [msb..lsb], the last four octets of Table G.1 should be changed to 30 B9 F3 84, and bits 784..815 in Table G.14 to 0000 1100 1001 1101 1100 1111 0010 0001. Interpretation Request Received Y.Inoue, Y.Asai, T.Onizawa, NTT

Proposed Response • The requester is right. • The two bits (bit#818 and bit#820) in the Table G.17 should be corrected. • Both of bit #818 and bit #820 in the Table G.17 are “0” in current STD. • We have examined the scenario written in the STD and confirmed that requester is right. • Both bit #818 and bit #820 should be modified to be “1”. Y.Inoue, Y.Asai, T.Onizawa, NTT

What we did • Reviewed Annex G.1 and G.2 (Table G.1). • Checked the Table G.13 and the Table G.14. • Correspond to the first and last 144 bits of DATA field in PPDU frame. • We confirmed that both of the tables were correct. • Checked the Table G.15. • The scrambling sequence for seed 1011101. • We also confirmed that this table was correct. • Checked the Table G.16 and the Table G.17. • We confirmed that the bits #818 and #820 in Table G.17 is NOT correct. Y.Inoue, Y.Asai, T.Onizawa, NTT

Annex G.1 and G.2 • Table G.1: • Table G.1 consists of following items. • The MAC header (24 octets) • The first 72 characters of the original message converted to ASCII code • The CRC32 (4 octets) • A PSDU of length 100 octets (= 800 bits) • {04 02 00 2e 00 60 08 cd … 74 72 65 61 da 57 99 cd} 100 octets MAC header Data (The first 72 characters of the original data converted to ASCII code) CRC32 Y.Inoue, Y.Asai, T.Onizawa, NTT

Annex G.5 • Generation of DATA field in PPDU frame: • The DATA field in a PPDU frame consists of SERVICE field, PSDU, tail (PPDU TAIL) and Pad bits. • Table G.13 shows the first 144 bits of the DATA field. • The SERVICE field (sixteen “0” bits) are added before PSDU. • Table G.14 shows the last 144 bits of the DATA field. • Assuming the modulation mode of 36M bps (16QAM, r=3/4), 42 Pad bits are appended in this case. RATE rsv LENGTH Parity tail SERVICE PSDU tail Pad Bits PLCP Preamble SIGNAL DATA Y.Inoue, Y.Asai, T.Onizawa, NTT

Data In X7 X4 X6 X5 X3 X2 X1 Scrambled Data Out S(x) = x7 + x4 + 1 Annex G.5 (cont) • Table G.15 – Scrambling sequence for seed 1011101 • This is the output sequence of the scrambler when the initial value of the shift register is 1011101. • We have confirmed that the Table G.15 was correct. Y.Inoue, Y.Asai, T.Onizawa, NTT

Annex G.5 (cont) • We have confirmed that: • Table G.16 (First 144 bits after scrambling) was correct. • Table G.17 (Last 144 bits after scrambling) was NOT correct as the requester pointed out. • The Table G.17 we obtained is shown in the next two slides. Y.Inoue, Y.Asai, T.Onizawa, NTT

Table G.17 Correspond to the PPDU TAIL bits Correspond to the PAD bits Y.Inoue, Y.Asai, T.Onizawa, NTT

Table G.17 Y.Inoue, Y.Asai, T.Onizawa, NTT

Another Confirmation • The bit #818 and bit #820 in the Table G.17 correspond to the PPDU TAIL bits. • The PPDU TAIL bits and PAD bits are all “0” • There will be exact sequence of the scrambler output after bit #816 in the Table G.17. • The bits #818 and #820 in the Table G.17 correspond the bits #56 and #58 in the Table G.15 which have value of “1”. Y.Inoue, Y.Asai, T.Onizawa, NTT

Conclusions • We have confirmed that the requester is right. • The values of the bit #818 and bit #820 in the Table G.17 should be modified to “1”. Y.Inoue, Y.Asai, T.Onizawa, NTT

Proposed Response to the Interpretation Request for Annex G