[STDS-802-11-TGBR] AW: [STDS-802-11-TGBR] Clarification on "around DC" during presentation/discussion on 1648/r0
Dear Aravindh,
thank you for making everyone aware of these mutual discussions between some members, this is highly appreciated. In my opinion, mixing frequencies up and down is quite complex based on 802.11bb assumptions. 802.11bb does a block up-/downconversion of parts of the 5 and 6 GHz bands what keeps frequency mapping fixed and the external design simple. In my opinion, up-down conversion was a questionable approach since the beginning.
802.11bb is limited by the fact that chipset vendors could not do anything in their chip design to support LC, as the scope of 11bb was limited to previous generations up to Wi-Fi 6 (11ax) and chips were already designed when TGbb started. No more changes to Wi-Fi 6 chips were possible. Even for Wi-Fi 7, suggested changes came little late.
That's why up/down conversion remained the only approach to develop a first minimum viable product. We are all aware that it has numerous disadvantages. Moreover, up-down conversion is a backwards-looking philosophy. I personally believe it hinders moving forward. TGbr should be more forward-looking than TGbb and not be limited by previous chipsets. I am happy to support extending LC with up/down to 320 MHz to support 11be as it is currently defined, but would not spend more consideration on this legacy approach.
Rather, we should demonstrate chipset vendors, how a well-designed ELC DSP looks like and minimize necessary changes, as long as the LiFi market is emerging and rather small. Vendors maybe willing to implement ELC if it has competitive advantages.
In my opinion, this needs three steps:
1. Demonstrate the benefits of using ELC. This is ongoing and shared as soon as ready.
2. Specify how implementation of LiFi is intended, assuming that chipset changes are possible. This can be accomplished in TGbr.
3. Work with chipset vendors to get ELC implemented on their next-gen. chipset.
For intuition: Wi-Fi chipsets can only be changed looking forward. The Wi-Fi 8 mainstream project (P802.11bn) is running, D1.0 of TGbn is already available, and we can see that the PHY spec is rather stable. I assume that vendors are already working on their chip designs, internally. ELC missed the chance to make it into Wi-Fi 8 already when UHR SG decided not to include LC into the scope of TGbn, similar to mm-wave. For chipset changes, one should focus on Wi-Fi 9. The mainstream project will be kicked-off soon. By co-defining Wi-Fi 9 and including LiFi from day one with corresponding submissions to the next-gen. Wi-Fi study group, there is a chance to get accepted finally and chipset changes being adapted for LiFi.
My suggestion is to join our limited forces in TGbr, limit backwards-looking discussions to the extend necessary to facilitate evolution of existing products and focus on a new design for Wi-Fi 9 which allows direct baseband and IF outputs with programmable IF. In this way, I believe, the required complexity and flexibility of flexible IF can be managed with reasonable effort.
Best regards - Volker
-----Ursprüngliche Nachricht-----
Von: Aravindh Krishnamoorthy <00004c930240d8fe-dmarc-request@xxxxxxxxxxxxxxxxx>
Gesendet: Freitag, 19. September 2025 15:48
An: STDS-802-11-TGBR@xxxxxxxxxxxxxxxxx
Betreff: [STDS-802-11-TGBR] Clarification on "around DC" during presentation/discussion on 1648/r0
Dear TGbr members,
Firstly, I'm happy to inform you that I've updated the MLD contribution to 1648/r1 [1] reflecting the outcome of the straw poll.
Next, I've received a few requests for clarification on the "around DC" statement, esp. for non-MLO use cases. I'll try to clarify below; hope that you find it satisfactory.
I'd like to emphasise that the examples below are mainly for illustrative purposes (e.g., 6 GHz-only AP) and may not necessarily map to a commercial use case.
My Assumptions:
1. E/LC works best if the mapped IF band is close to the DC frequency. This is inherently due to the low-pass characteristics of the end-to-end channel.
2. E/LC with "RF LC Converter", Figure 33-2 in Draft P802.11REVmf_D1.0, is the most practical case.
There are two current ways to map an RF channel to IF:
1. 802.11bb method: For every new RF channel, the corresponding IF channel is pushed upwards in frequency.
a. As seen from Table 33-1 in Draft P802.11REVmf_D1.0, a purely 6 GHz 802.11 chipset (notwithstanding other implications) can *not* use the 16 MHz to 176 MHz LC IF band. It is mapped to 176 MHz to 326 MHz band.
b. This is in contradiction to Assumption 1 above, where operations starting 16 MHz would be optimal.
c. Effects gets worse in case we want to bring in support for 2.4 GHz RF channel, e.g., for next generation RF + ELC APs, or high 6 GHz band.
d. Using an 802.11bb-like mapping on all supported (future) ELC bands creates additional system design issues: APs cannot straightforwardly support two or more ELC bands, i.e., they cannot enable future usecases where two ELC bands for two different operating scenarios or STAs are used. MIMO ops 1677/r0 [3] requires all STAs to be MIMO capable.
2. 1076/r0 [2] (Slide 5) method: For every new ELC band, the corresponding RF channel is pushed upwards in frequency.
a. Each ELC band has LC IF starting at 16 MHz, which is in accordance with Assumption 1.
b. However, a purely 5 GHz 802.11 chipset cannot be used for operating in the 400 to 600 nm ELC band, severely limiting system design choices.
Hence, both known ways have positives and negatives. Perhaps using MLE, as suggested in 1648/r1 [1], can provide novel solutions that are acceptable to all, even if the proposed flexibility will have to be severely restricted.
I'll be happy to receive any comments or questions from the members.
Best regards,
Aravindh Krishnamoorthy
[1]: https://mentor.ieee.org/802.11/dcn/25/11-25-1648-01-00br-elc-mld-mapping-proposal.pptx
[2]: https://mentor.ieee.org/802.11/dcn/25/11-25-1076-00-00br-a-proposal-for-channelization-mapping.pptx
[3]: https://mentor.ieee.org/802.11/dcn/25/11-25-1677-00-00br-multi-optical-bands-and-mlo.pptx
________________________________________________________________________
To unsubscribe from the STDS-802-11-TGBR list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBR&A=1
________________________________________________________________________
To unsubscribe from the STDS-802-11-TGBR list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBR&A=1