Presentation is loading. Please wait.

Presentation is loading. Please wait.

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.

Similar presentations


Presentation on theme: "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."— Presentation transcript:

1 doc.: IEEE /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

2 doc.: IEEE /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 in Table G.14 to

3 doc.: IEEE /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 /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 –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 /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) { e cd … da cd} CRC32 Data (The first 72 characters of the original data converted to ASCII code) MAC header 100 octets

6 doc.: IEEE /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 /1198r0 Submission November 2004 Y.Inoue, Y.Asai, T.Onizawa, NTT Annex G.5 (cont) Table G.15 – Scrambling sequence for seed –This is the output sequence of the scrambler when the initial value of the shift register is –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 /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 /1198r0 Submission November 2004 Y.Inoue, Y.Asai, T.Onizawa, NTT Table G.17 ##Bit##Bit##Bit##Bit##Bit##Bit Correspond to the PAD bits Correspond to the PPDU TAIL bits

10 doc.: IEEE /1198r0 Submission November 2004 Y.Inoue, Y.Asai, T.Onizawa, NTT Table G.17 ##Bit##Bit##Bit##Bit##Bit##Bit

11 doc.: IEEE /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 /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.


Download ppt "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."

Similar presentations


Ads by Google