1. March 2002 Jie Liang, et al, Texas Instruments Slide 1 doc.: IEEE 802.11-02/0207r0 Submission Simplifying MAC FEC Implementation and Related Issues Jie Liang, Matthew Shoemake, Lior Ophir Texas Instruments Incorporated 12500 TI Blvd. Dallas, Texas 75243 Liang@ti.com, shoemake@ti.com, Lior.Ophir@ti.com

2. March 2002 Jie Liang, et al, Texas Instruments Slide 2 doc.: IEEE 802.11-02/0207r0 Submission Motivations (1) Implementation Options for MAC Level FEC: –Select FEC option according to FEC bit in the header: not taking advantage of error protection of the header –Parallel decoding option: pass through both paths and use FCS to determine the correct outcome double buffer size higher power consumption –Header directed one-path sequential decoding option Lower power consumption Lower memory requirement Preferred Option: One-path sequential decoding option FEC MAC Processing Regular MAC Processing Header Decoding PHY data stream

3. March 2002 Jie Liang, et al, Texas Instruments Slide 3 doc.: IEEE 802.11-02/0207r0 Submission Motivations (2) Performance Degradation of Simply Using FEC bit to determine decoding options for packets [1][1] FECed Header (32+16) + One FECed MPEG (188+4+16) [2][2] FECed Header (32+16) + One FECed max size TCP/IP (1460+8*16+4) Packet TypePacket Length Uncoded BER Parallel Dec. (PER pd ) FEC Bit (PER 1 ) Comments Data Short2561.5e -3 1.0e -2 1.1e -2 Negligible difference Data Long16401.0e -3 1.0e -2 1.1e -2 Negligible difference Video Short2564e -4 2e -5 4e -4 Significant Degradation Video Long16404e -4 1.3e -4 5.3e -4 Significant Degradation

4. March 2002 Jie Liang, et al, Texas Instruments Slide 4 doc.: IEEE 802.11-02/0207r0 Submission We use the outcome of the header RS decoding to decide the decoding path for the rest of the packet: –Decoding failure -> packet is not RS coded –Decoding success -> packet is RS coded What is the probability that the above approach gives wrong decision: For (n,k,t) RS code over GF(q), let Q be the decoding error probability, and Vn(t) be the Hamming Sphere of radius t of a given codeword, then the decoding error probability is given by: Probability of RS Decoding Error (1) where

5. March 2002 Jie Liang, et al, Texas Instruments Slide 5 doc.: IEEE 802.11-02/0207r0 Submission The RS decoding error probability is given by: Probability of RS Decoding Error (2) For the (48,32,8) RS code for the MAC header, the decoding error is: 8.1x10 -14 Therefore, the header directed one-path method for MAC FEC decoding gives good decisions almost all the time. However, there are fixed data patterns that would induce the receiver to make wrong decisions.

6. March 2002 Jie Liang, et al, Texas Instruments Slide 6 doc.: IEEE 802.11-02/0207r0 Submission Space of Catastrophic Packets (1) The problem is that for some data patterns, even when they are not RS encoded, the afore-mentioned decoder implementation would classify them as RS encoded, causing lost packets. Even the retransmission of these packets may not change the above outcome. Essentially these packets may never be correctly received. Construction of a catastrophic packet: Let C0 be a non-RS coded MAC header pattern. Let C1 be another MAC header pattern, and P1 be the RS parity symbols. Since C0 is not RS encoded, payload would follow it and could be any random patterns D0. C0 C1 P1 xxxxxxxx The MAC header RS decoder would “correct” the non-coded C0/D0 to C1/P1 if the following condition is met: d(C0,C1)+d(D0,P1)  t Where d() is the Hamming distance.

7. March 2002 Jie Liang, et al, Texas Instruments Slide 7 doc.: IEEE 802.11-02/0207r0 Submission Space of Catastrophic Packets (2) From the previous construction, we could calculate the total number T of payload patterns for d0 that will cause decoding errors. It can be given as follows: For the (48,32,8) RS code for the MAC header, the catastrophic payload patterns for each MAC header T: T  8x10 26 (out of 3.4x10 38 ) The catastrophic patterns are a diminishingly small portion of the total packet patterns. However, they still constituent a large number of packets in total number. These packets can NEVER pass through.

8. March 2002 Jie Liang, et al, Texas Instruments Slide 8 doc.: IEEE 802.11-02/0207r0 Submission Would MAC Header CRC Help? C0 C1 CRC xxxxxxxx P1 The answer is No. Adding CRC bytes would help reducing decoding errors probability, which is already low, further. However, it won’t reduce the total number of problematic error patterns (follow the construction from previous slides).

9. March 2002 Jie Liang, et al, Texas Instruments Slide 9 doc.: IEEE 802.11-02/0207r0 Submission Handling Catastrophic Packets Catastrophic packets are a diminishingly small portion of the total possible packets. When a non-RS coded packet with a catastrophic pattern is transmitted, the first packet will not be received correctly. MAC header CRC can not fix this problem. The key here is to directly use FEC bits for deciding packet decoding option, but we need to match the decision error probability from using FEC bits directly to the desirable overall packet error rate.

10. March 2002 Jie Liang, et al, Texas Instruments Slide 10 doc.: IEEE 802.11-02/0207r0 Submission Fixing the Problems We will next propose a variety of options to fix this problems Two options involve changing PLCP headers, but they are cleaner solutions and give better results Third option will need only to change MAC header (adding one FEC bit), not optimal but sufficient for most applications We will leave the group the choose the option it prefers.

11. March 2002 Jie Liang, et al, Texas Instruments Slide 11 doc.: IEEE 802.11-02/0207r0 Submission FEC Field: Option 1 (PLCP SIGNAL Field) 802.11b PLCP 802.11a PLCP Signal (8) Service (8) Length (16) CRC (16) bit 0 7 FEC Rate (4)Reserved (1) LENGTH (12) Parity (1)Tail (6)

12. March 2002 Jie Liang, et al, Texas Instruments Slide 12 doc.: IEEE 802.11-02/0207r0 Submission FEC Field: Option 2 (PLCP SERVICE Field) 802.11b 802.11a B0B1B2B3B4B5B6B7 reserved Locked clock Mode selection reservedFECreservedLength extension Scrambler Initialization (7)RESERVED (9) FEC 0-2 repetition code of length 3, correct 1 errors provide SNR gain (not coding gain) of 4.8db (for PSDU with RS, the SNR gain is smaller)

13. March 2002 Jie Liang, et al, Texas Instruments Slide 13 doc.: IEEE 802.11-02/0207r0 Submission FEC Field: Option 3 (MAC Header) octets: 226662620-23124 Frame Control Duration / ID Address 1 Address 2 Address 3 Sequenc e Control Address 4 QoS Control Frame Body FCS MAC Header bit 0 15 9 FEC 0 FEC 1 Bit 15 of Frame Control is currently reserved Bit 9 of QoS Control is allocated for FEC bit already FEC field (only two values allowed, distance=2): 00: no RS coding 11: RS coded Separate FEC0 and FEC1 to achieve diversity to burst errors

14. March 2002 Jie Liang, et al, Texas Instruments Slide 14 doc.: IEEE 802.11-02/0207r0 Submission Results: 2 FEC Bits Packet TypePacket Length Uncoded BER Parallel Dec. (PER pd ) 2 FEC Bit (PER 2 ) Comments Data Short2561.5e -3 1.0e -2 Negligible difference Data Long16401.0e -3 1.0e -2 Negligible difference Video Short2564e -4 2e -5 Negligible difference Video Long16404e -4 1.3e -4 Negligible difference

15. March 2002 Jie Liang, et al, Texas Instruments Slide 15 doc.: IEEE 802.11-02/0207r0 Submission Summary We presented an implementation architecture to support MAC FEC decoding without double decoding or double buffer. We analyzed the performance of this architecture in terms of decision error probability and number of problematic error patterns. We provided solutions to fix the above problem through carefully designing the FEC field to match the desirable packet error rate. The proposed method offer simple implementation architecture while having little degradation in performance.