Hi Johannes, Wireless,
One of the last remaining pieces within cfg80211/mac80211 to enable
complete S1G functionality is primary channel support. We've identified
a couple of potential implementation specific issues and would like
maintainer input prior to developing the patchset as it may be
mildly contentious.
Background
----------
The channelisation of an S1G PHY consists of two components, a center
frequency and a primary center frequency as per IEEE80211-2024 23.3.14.
The center frequency is equivalent to other PHY types, being the center
operating frequency for the operating channel and the primary center
frequency being the center frequency for the primary channel.
When an S1G PHY changes channel, it requires both the operating channel
and the primary channel parameters. The implementation of this will be
briefly mentioned at the end of this email.
S1G Channel Structure
---------------------
S1G has a hierarchical channel structure. Below is a snippet from the
IEEE80211-2020 Australian/US S1G band. The righthand side |*|
represents the FCC band edge. Above the == line are the designated
channel numbers and on the left column their respective bandwidths.
|------|---------------------------------------------|*|
c | 8MHz | | 44 | |*|
h |------|---------------------------------------------|*|
a | 4MHz | | 40 | 48 | |*|
n |------|---------------------------------------------|*|
n | 2MHz | | 38 | 42 | 46 | 50 | |*|
e |------|---------------------------------------------|*|
l | 1MHz | | 37 | 39 | 41 | 43 | 45 | 47 | 49 | 51 | |*|
|======|=============================================|*|
|******| 920 921 922 923 924 925 926 927 928 |*|
|******|---------------------------------------------|*|
frequency (MHz)
S1G Channel Selection Example
-----------------------------
An example channel configuration would be an operating channel of 44 and
a primary channel of 37. The primary channel must be a 1MHz or 2MHz channel
and must exist as a primary subchannel within the operating channels band.
Using the sample above, operating channel 44 can have a 1MHz primary of
37, 39, 41, 43, 45, 47, 49 or 51 and same goes for the 2MHz channels. Whereas
an operating channel of 40 may only have primary 1MHz channels of 37, 39,
41 and 43.
Regulatory Emission Challenges
------------------------------
To control RF emissions during FCC compliance testing, hardware vendors
disable edge-band primary channels to meet emission requirements. [1], [2]
and [3] show 1MHz and 2MHz primary channels on band edges disabled. This,
however, does not prevent the operating channel from being used. This is due
to the OFDM envelope peaking near band centre, providing enough spectrum
roll-off to satisfy emission limits.
Using [3] as an example, primary channels 51, 50 and 49 are disabled during
testing, but operating channels 48 and 44 are still tested (both of which contain
the disabled primary channels). These configurations all passed FCC requirements.
Proposed Solution
-----------------
We propose a new flag within struct ieee80211_channel_flags called
IEEE80211_CHAN_S1G_NO_PRIMARY or something similar that tells the
wireless subsystem that this channel cannot be used as a primary channel,
but is not disabled. This is an important distinction as during subchannel
validation, if a single subchannel is disabled that operating channel cannot
be used (similar to VHT and other PHY types) but an operating channel can
be used if an edgeband 1MHz channel has the NO_PRIMARY flag but is _not_
disabled.
NB: While the existing for_each_subchan macro doesn't work for S1G channels
given its fixed step size of 20MHz, this will be updated during
the implementation.
It's also important to note that this can only apply to edgeband primary
channels for the current regdom. This validation will be performed upon
advertisement by the driver of the available channels for the S1G band.
Additionally, puncturing is not supported for S1G.
This will be an implementation detail, as this is not explicitly described
by the standard, but rather used by vendors to ensure FCC compliance.
Primary Channel Representation
------------------------------
One potential challenge with actually implementing primary channel support
is how and where the primary channel is described. Initially it was thought
that a channel definition could contain a separate struct ieee80211_channel
like such:
struct cfg80211_chan_def {
struct ieee80211_channel *chan;
[...]
struct ieee80211_channel *s1g_pri_chan;
};
The obvious problem with this is that now a channel definition describes two
channels, though you could argue that to correctly describe an S1G channel
you require both components - which in some regards makes sense to put them
both in the channel definition. It does, however, require various API changes,
with the biggest one being cfg80211_chandef_create() to accept the new primary
channel parameter. An alternative is to create an S1G specific chandef creation
function which can then call the generic form.
Additionally, we can reuse cfg80211_chandef_valid() to perform validation as
both the operating channel and primary channel exist within the same
channel definition. By extension, many of the function that operate on a
chandef have access to both the primary channel and operating channel.
Definitely something to consider.
The second option is to treat them as two separate channel definitions. This
is probably more "correct" as after all a primary channel is a separate channel.
While this approach doesn't require many major API changes like the previous
method, it still has some negatives. Firstly, the need to carry a separate
channel definition in various places. Taking struct ieee80211_chanctx_conf as
an example:
struct ieee80211_chanctx_conf {
struct cfg80211_chan_def def;
[...]
struct cfg80211_chan_def s1g_pri_def;
};
When building this new channel definition, we probably don't want to be using
_nl80211_parse_chandef() as it relies on the NL80211_ATTR_WIPHY_FREQ to find
the channel, where the primary channel center frequency will rely on a separate
attribute. Now we could, of course, add in another branch to handle this case,
but the function seems fairly overloaded as is and would be good to keep the
S1G specific case separate.
With all that said, we will obviously send up an initial patchset (probably
as an RFC and only once the TIM patchset has been accepted) but since we are
inquiring with regards to the new flag thought it couldn't hurt to get some
preliminary thoughts.
References
----------
[1] AsiaRF MM610X-001 FCC Radio Test Report
Section 1.1.1
https://fccid.io/TKZMM610X-001/Test-Report/TKZMM610X-001-Test-Rpt-6686112.pdf
[2] Silex Technology SX-NEWAH FCC Radio Test Report
Section 2.2
https://fccid.io/N6C-SXNEWAH/Test-Report/03-FCC-Test-Report-DTS-4734386.pdf
[3] Morse Micro MM6108-MF08651-US Electromagnetic Emissions Compliance Report
Page 35
https://fccid.io/2A74O-DB3F2B/Test-Report/TR-TERF2406001545E2-902-928MHz-s03-part-1-7640840
lachlan
