Decoding Latency for STBC and LDPC Month Year doc.: IEEE 802.11-yy/xxxxr0 July 2006 Decoding Latency for STBC and LDPC Date: 2006-07-19 Authors: Notice: This document has been prepared to assist IEEE 802.11. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.11. Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures <http:// ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair <stuart.kerry@philips.com> as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at <patcom@ieee.org>. Gunnar Nitsche, Philips John Doe, Some Company

Abstract This presentation concerns the resolution of Month Year doc.: IEEE 802.11-yy/xxxxr0 July 2006 Abstract This presentation concerns the resolution of CID 1634/4038: decoding latency for STBC CID 4037: decoding latency for LDPC Both coding options introduce additional decoding latency compared to standard Viterbi decoding, but the receiver still has to ACK after the regular SIFS. This implies a significant implementation burden. It is therefore proposed to virtually increase the SIFS time for these coding options similar to what has been done in 802.11g. Gunnar Nitsche, Philips John Doe, Some Company

July 2006 Our Background We are mainly interested in handheld applications of 802.11n Thus, increasing range is more important for us than inreasing throughput Both STBC and LDPC are valuable options for increasing range Since handheld applications imply severe restrictions in terms of power and cost, we are concerned about any constraints that make STBC or LDPC harder to implement than necessary Gunnar Nitsche, Philips

Historical Background July 2006 Historical Background When convolutional channel coding was introduced for OFDM in 802.11a, SIFS was increased from 10 to 16 µs to accomodate the additional decoding latency of the Viterbi decoder. For 802.11g, a single SIFS of 10 µs was necessary for both DSSS/CCK and OFDM modes. To fullfil the requirements for both modes, OFDM frames end 6 µs before NAV ends, so SIFS is virtually increased for OFDM but DSSS/CCK still see their regular SIFS. Gunnar Nitsche, Philips

July 2006 19.3.2.3 ERP-OFDM PPDU format For ERP-OFDM modes, an ERP packet is followed by a period of no transmission with a length of 6 μs called the signal extension. The purpose of this extension is to make the TXTIME calculation in 19.8.3 result in a transmission duration interval that includes an additional 6 μs. The SIFS time for Clause 17 packets is 16 μs, and the SIFS time for Clause 18 packets is 10 μs. The longer SIFS time in Clause 17 is to allow extra time for the convolutional decode process to finish. As Clause 19 packets will use a SIFS time of 10 μs, this extra 6 μs length extension is used to ensure that the transmitter computes the Duration field in the MAC header incorporating the 6 μs of “idle time” following each ERP-OFDM transmission. This ensures that the NAV value of Clause 18 STAs is set correctly. Gunnar Nitsche, Philips

Decoding latency for STBC July 2006 Decoding latency for STBC In all STBC modes, the coded information is spread over 2 consecutive OFDM symbols Channel decoding can only start if both OFDM symbols have been received, although FFT can be done immediately for each symbol individually After the last symbol has been received, the Viterbi decoder has to process the information from the last 2 symbols (with STBC) instead of the last one alone (without STBC at same rate) So, if the same Viterbi decoder is used in both cases, the end of channel decoding is delayed for STBC, by an amount that depends on the implementation Assuming a Viterbi that is just fast enough to handle the throughput, the additional delay caused by STBC is about 1 OFDM symbol, i.e. 4 µs So, either SIFS is virtually increased for STBC frames by 4 µs, or a much faster Viterbi is necessary. Gunnar Nitsche, Philips

LDPC designed to meet 6 µs latency July 2006 LDPC designed to meet 6 µs latency LDPC is a block based channel coding algorithm. Thus, the decoder cannot do much before the last information bit of a block has been received. The advanced coding team that has designed the LDPC took the 6 µs decoding latency available for the Viterbi as a given constraint So, it is assumed that the LDPC can decode all block sizes in 6 µs. Considering the maximum block size (1944 bits) and code rate (5/6 -> 1620 info bits), this implies that such a decoder can handle a sustained throughput of 270 Mbit/s! Typical handheld applications require just 1 SS up to 65 Mb/s, meaning that the expensive LDPC block is used only 25% of the time Even for 2 SS up to 130 Mb/s, the LDPC is used only 50% of the time Gunnar Nitsche, Philips

LDPC designed to meet throughput July 2006 LDPC designed to meet throughput Now let's take the opposite approach, designing the LDPC to meet throughput constraints and looking what latency we get For 1 SS, processing maximum size blocks using code rate 5/6 at 65 Mbit/s correspond to 1620 / 65 = 24.9 µs per block, which would be a clearly excessive latency For 2 SSs, processing these blocks at 130 Mbit/s correspond to 12.5 µs per block, still a somewhat large latency Gunnar Nitsche, Philips

July 2006 Balanced LDPC design If we would choose 10 µs decoding time, i.e. 4 µs additional SIFS time as for STBC, the latency would correspond to 162 Mbit/s, thus a reasonably balanced compromise for the highest mandatory rate MCS 15 at short GI (144 Mbit/s) Under the above assumption, an LDPC decoder could potentially be implemented with 2/3 of the logic compared to draft 1.0 Reducing the block size would also help to better balance latency vs. throughput, but at the severe drawback of less coding gain Yet another possibility would be to reduce the number of iterations for the last block, but again at the drawback of less coding gain So, the 4 µs SIFS time increase is proposed as best solution, costing just a very marginal throughput degradation Gunnar Nitsche, Philips

Combination of STBC and LDPC July 2006 Combination of STBC and LDPC Things get worse if both options are applied simultaneously, but the latencies do not add up To keep things simple, let's still assume just 4 µs additional SIFS time Gunnar Nitsche, Philips

July 2006 Straw Polls Before preparing normative text, I would like to get some feedback from the group via the following straw polls: 1. SIFS time for STBC mode shall be increased yes no abstain 2. SIFS time for LDPC mode shall be increased If above polls are positive: 3. SIFS time for STBC and LDPC mode shall be increased by 4 µs Gunnar Nitsche, Philips