1. doc.: IEEE 802.11-04/1198r0 Submission November 2004 Y.Inoue, Y.Asai, T.Onizawa, NTT 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

2. doc.: IEEE 802.11-04/1198r0 Submission November 2004 Y.Inoue, Y.Asai, T.Onizawa, NTT Interpretation Request Received 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.

3. doc.: IEEE 802.11-04/1198r0 Submission November 2004 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.

4. doc.: IEEE 802.11-04/1198r0 Submission November 2004 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.

5. doc.: IEEE 802.11-04/1198r0 Submission November 2004 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} CRC32 Data (The first 72 characters of the original data converted to ASCII code) MAC header 100 octets

6. doc.: IEEE 802.11-04/1198r0 Submission November 2004 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. tailPad BitsSERVICE PSDU PLCP PreambleSIGNALDATA tailParityLENGTHrsvRATE

7. doc.: IEEE 802.11-04/1198r0 Submission November 2004 Y.Inoue, Y.Asai, T.Onizawa, NTT 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. X7X7 X6X6 X5X5 X4X4 X3X3 X2X2 X1X1 Data In Scrambled Data Out S(x) = x 7 + x 4 + 1

8. doc.: IEEE 802.11-04/1198r0 Submission November 2004 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.

9. doc.: IEEE 802.11-04/1198r0 Submission November 2004 Y.Inoue, Y.Asai, T.Onizawa, NTT Table G.17 ##Bit##Bit##Bit##Bit##Bit##Bit 720074407681792081608400 721174507690793081708410 722174607701794181818420 723174717710795181908430 724174807720796082018441 725174917730797082108451 726075017740798082208461 727175117750799082308470 728175207761800182418481 729075307771801082518491 730075417781802082608501 731075517790803082718511 Correspond to the PAD bits Correspond to the PPDU TAIL bits

10. doc.: IEEE 802.11-04/1198r0 Submission November 2004 Y.Inoue, Y.Asai, T.Onizawa, NTT Table G.17 ##Bit##Bit##Bit##Bit##Bit##Bit 732175617801804182818520 733075707811805182918530 734175807820806083008541 735075917830807083108550 736076007840808183208561 737076107850809183318571 738176207861810083418580 739076317870811083518590 740076407881812183618601 741176517890813083718610 742176607900814183818620 743176717910815083918631

11. doc.: IEEE 802.11-04/1198r0 Submission November 2004 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.

12. doc.: IEEE 802.11-04/1198r0 Submission November 2004 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.