1. Decoding Latency for STBC and LDPC
Month Year
doc.: IEEE yy/xxxxr0
July 2006
Decoding Latency for STBC and LDPC
Date:
Authors:
Notice: This document has been prepared to assist IEEE 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
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures < 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 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 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at
Gunnar Nitsche, Philips
John Doe, Some Company

2. Abstract This presentation concerns the resolution of
Month Year
doc.: IEEE 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 g.
Gunnar Nitsche, Philips
John Doe, Some Company

3. July 2006
Our Background
We are mainly interested in handheld applications of n
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

4. Historical Background
July 2006
Historical Background
When convolutional channel coding was introduced for OFDM in a, SIFS was increased from 10 to 16 µs to accomodate the additional decoding latency of the Viterbi decoder.
For g, 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

5. July 2006
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 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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