On 4/12/2024 5:30 PM, James Dutton wrote:
On Fri, 12 Apr 2024 at 09:02, Vasanthakumar Thiagarajan
<quic_vthiagar@xxxxxxxxxxx> wrote:
On 4/12/2024 1:08 PM, Nicolas Escande wrote:
On Fri Apr 12, 2024 at 5:50 AM CEST, Vasanthakumar Thiagarajan wrote:
On 4/11/2024 10:09 PM, Maxime Bizon wrote:
On Thu, 2024-04-11 at 21:56 +0530, Vasanthakumar Thiagarajan wrote:
Hello,
Thanks for making it clear,
For example, starting a 5Ghz AP in ax-only mode, and at the same
time
creating a STA interface on 2.4GHz ?
Yes, such use cases continue to be supported in single wiphy mode.
Understood, but I see some corner cases.
For example, assume two bands AP hardware, 2.4GHz and 5GHz.
Previously:
- phy0 is 2.4Ghz
- phy1 is 5Ghz
- iw phy phy0 interface create wlan0 type managed
- iw dev wlan0 scan
=> will only scan 2.4Ghz
With single phy approach:
- phy0 is 2.4Ghz + 5Ghz concurrent
- # iw phy phy0 interface create wlan0 type managed
- # iw dev wlan0 scan
.> >>> => will scan both bands ?
Yes, both the bands will be scanned if freq list is not given
- <starting from previous state>
- # iw phy phy0 interface create wlan1 type __ap
- # hostapd -i wlan1 <config>
- # iw dev wlan0 scan
=> what will happen then ?
Scan will be carried out on all the radios including the one on which AP interface is
running. Scan with freq list can be used not to disturb the radio of AP interface.
Same goes for hostapd ACS, I assume specifying freqlist becomes
mandatory or we can't predict which band the AP will be on ?
If no freq list is given, ACS will run through all the bands and select a channel from any
of the bands. But this can be optimized to do ACS and channels selection on a particular
band using channellist/freqlist hostapd configurations.
Hello,
And in a (very unlikely) case that there are two underlying radios that can
operate on the same frequencies, how would freqlist enable us to really select
the underlying radio ?
This can not be supported in this approach. As only the radios participating in MLO are
supposed to be combined under one wiphy, not sure if we have real use case to combine
radios of same frequencies.
Vasanth
Looking at this discussion, I think it would really be helped with
some architectural diagrams describing the various combinations of
components in an RF chain.
Let us take a single example.
We have antennas, analogue front end, and ADCs (Analogue to digital converters)
The features of those two are:
1) Antennas can be optimised for particular frequencies.
2) The analogue front end has many different parameters, but for this
discussion, the important one is:
a) frequencies it can tune to.
b) instantaneous bandwidth. I.e. When tuned to a particular frequency,
what is the bandwidth around that frequency that one can receive.
3) ADC
a) The Sample rate
Once the RF sample are in the digital domain one has the ADC ->
DIgital Processing -> Output data
If we assume that the ADC is set to receive the full instantaneous
bandwidth, the digital processing can do a number of things.
1) process the full instantaneous bandwidth into a single channel of data.
2) process the instantaneous bandwidth into multiple sub bands, or
multiple channels of data.
There is also the control endpoint that controls all these components.
There can be multiple front ends for each ADC. multiple ADCs per
Digital Processing.
A higher level process (maybe hostapd) can then speak to multiple
Digital Processing and ADC, RF Front end components and then somehow
has to manage and coordinate them all.
All these capabilities and varying arrangement of the various
components need to be reported up to a higher level, in a common way,
that can handle all possible arrangements.
Once the higher level process has all this information, it can then
manage to do everything necessary for Multi-Link operation (MLO).
Exactly, that is what this patch series is trying to do. Advertising
per-underlying radio's capabilities to upper layer.
So, to answer some of the questions in this thread.
Scanning: The high level process should know what capabilities are
available and what can be done in parallel or not. So it should be
able to convert a request from a user, into a more detailed request
down towards the hardware.
I.e. User asks for scan. High level process tells which bits of the
hardware should do the scanning and across which frequencies.
While it might sound complicated, when implemented correctly, it is
just a matter of iterating over a tree with a search match criteria.
Current implementation does not change anything in scan function
wrt a wiphy. So there will be only one scan at anytime for a wiphy.
Possible enhancements can be discussed and added in future.
Vasanth
