Idea: TCM extension to wifi

[ryao]

I happened to be looking at the history of dial-up modems a while ago and noticed something interesting at wikipedia:

https://en.wikipedia.org/wiki/Trellis_coded_modulation
https://en.wikipedia.org/wiki/List_of_ITU-T_V-series_recommendations#V.29

In short, at the time that TCM was introduced, the best dial-up modem had achieved was 9.6Kbps (V.29) via QAM and people did not think going much higher was possible. If wikipedia's citation is correct, the shannon limit for the POTS line (pre-digital trunk lines I assume) was ~35Kbps. Adopting TCM enabled speeds of 33.6Kbps (V.34, although V.32 had initially used TCM to reach 14.4Kbps). 33.6Kbps is very close to the claimed shannon limit of ~35Kbps.

I thought to myself, "Wifi uses QAM; could an extension to wifi use TCM to improve wifi throughput?"

After digging into this, I suspect the answer is yes. We can see link rates for wifi at the following MCS table:

https://www.gnswireless.com/info/signal-to-noise-ratio-snr/

We can see that 20Mhz channels are currently limited to 86.7Mbps. If I have done my research correctly, this is because Wifi uses OFDM with 64 sub carriers of which 52 are data subcarriers. When 256-QAM is used with a 3/4 coding rate, we have 52 * log2(256) * 3/4 = 312 bits per a OFDM symbol. At a short guard interval of 400 nanoseconds, we have a 3.6 microsecond symbol duration, which is approximately OFDM 277778 symbols per second. 312 bits per a OFDM symbol * OFDM 277778 symbols per second is ~86.7Mbps. The symbol duration is mentioned here:

https://courses.grainger.illinois.edu/cs598wsi/fa2023/Notes/Lecture5_scribe.pdf

The following site gives a description of how TCM interacts with various modulation schemes:

https://www.complextoreal.com/wp-content/uploads/2013/01/tcm.pdf

In particular, it doubles the constellation points to encode the additional error correction bit. That should allow us to increase the OFDM symbol rate by eliminating the FEC overhead. That would give us a link rate of appoximately ~116Mbps on a 20Mhz channel.

There is a disadvantage of going to a higher constellation, but as per complextoreal, TCM is supposed to overcome that by giving a coding gain. Going by the description there, we would want to implement a 8/9 convolutional encoding scheme and encode a 256-QAM signal in a 512-QAM signal.

It seems that V.34 is an open standard, with the ITU publishing it in its entirety:

https://www.itu.int/rec/T-REC-V.34/en

They describe the trellis encoder and various convolutional encoders used by V.34's TCM there. In particular, V.34 supports 3 different convolutional encoding schemes:

• 16-state rate-2/3
• 32-state rate-3/4
• 64-state rate-4/5

If this pattern follows, we would want to implement a 1024 state 8/9 convolutional encoder to use TCM in wifi. I don't know what the coding gain would be, but the following claims the coding gain to be 4.5dB for the 32-state scheme and 4.7dB for the 64-state scheme:

https://www.audentia-gestion.fr/research.microsoft/v34.pdf

If I understand things correctly, a proof of concept with the 64-state rate-4/5 convolutional encoder described in V.34 where would put a 16-QAM signal into 32-QAM could be done. That would only achieve 57.8Mbps, although perhaps it would have improvements in range.

I am fully open to the possibility that I am wrong. I admit that I need to do much more background reading before I can be certain of what I am thinking. However, I suspect that others here are much better prepared to do that than I am, so if my preliminary thoughts pique anyone's interest, please feel free to look into it. :)

Edit: After thinking about it, I think the 35Kbps shannon limit cited by wikipedia for POTS (which I assumed was prior to digital trunk lines) is nonsense. In specific, the convolutional coding means that when getting the peak of 33.8Kbps, you are actually pushing though more than 35Kbps. My original rationale for considering this is wrong, but surprisingly, the napkin math suggests that TCM could be an improvement and it is probably not wrong to think that V.34 has some good signal processing ideas in it that might be relevant to modern things.

[ryao]

My current guess is that the required SNR will increase by at least 2dB, so the additional bandwidth from implementing TCM like this is actually not free, although the required increase in SNR seems rather cheap given that it should give 33% more bandwidth.