Note: this is a public e-mail
As I mentioned at the Linux wireless summit we want to revamp the
regulatory code on Linux to take into consideration some new features
and to make the code a bit easier to follow and manage, and most
importantly do unit tests outside of the kernel through a userspace
testbed which can prove validity of the data and all possible states
we can run into. This can also help other OSes which may want to
cherry pick the code into their own solutions and hopefully create
more traction on embracing and working together towards a more unified
regulatory database.
I've dumped some initial code here:
git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/regsim.git
The first goal is to start embracing the formal definition of a
regulatory domain and rules that a frequency should match to by
Johannes a while ago:
0) for all 1 <= k < n : MAX_k <= MIN_{k+1}
1) each rule in the regdomain covers the frequency range (MIN_1, MAX_1]
2) given C = union (over all k = 1 .. n) of (MIN_k, MAX_k] it must be
true that (CENTER - BW/2, CENTER + BW/2) is a subset of C
3) it must be true for all 1 <= k <= n:
if CENTER in (MIN_k, MAX_k] : BW <= BW_k
4) This is easier to formulate algorithmically:
USE_FLAGS = 0
for k = 1 .. n
if (CENTER - BW/2, CENTER + BW/2) intersects (MIN_k, MAX_k]:
USE_FLAGS |= FLAGS_k
This intends on addressing regulatory domains which may have
overlapping rules or TPC rules for different bandwidths -- all of
which do not exist today as far as I'm concerned but certainly do
limit our architecture as it is today. I intend on testing this by
creating a test regulator domain under main.c which has some
overlapping frequency rules and ensuring that the target rule picked
matches the above definition.
Next we should review 802.11mb stuff and the "operating class"
extensions, and see if we can throw some of that to the framework to
intersect the existing rules. This will take care of the operating
class requirements for 802.11ad. For this I will need some help on the
language used on 11mb operating classes. For 802.11ac I didn't get any
new concerns or architecture change requirements. For TV space.. its a
bit different and we will have the external regulatory database we
will need to talk to but -- not sure how that fits into this stuff. If
someone is working on that I'd appreciate review or feedback.
After that will be adding some form of state machine for each possible
regulatory state we can get into and then adding all possible events
and changes to the state machine. Then we start simulating devices and
them moving around all possible states, exposing allowed channels,
output power, etc, and comparing this against expected results.
If you'd like to help feel free to coordinate on #linux-wireless on
irc.freenode.net or on this list. Patches always welcomed.
Luis
On 09/30/2011 01:21 PM, Adrian Chadd wrote:
> On 29 September 2011 20:46, Zefir Kurtisi <[email protected]> wrote:
>
>> Really? Where would be 'there' countrycode-wise?
>>
>> That would definitely break today's CRDA capabilities :-\
>
> I -think- one or both of ETSI/FCC have different CAC/NOL requirements
> for the channels which overlap the weather radars.
> At least when someone took FreeBSD to get DFS certified a while ago,
> the weather radar ranges were checked against a 30 minute CAC. :)
>
> I think it's worth defining specific DFS parameters for each frequency
> range. That's what I'll be doing for FreeBSD when I revamp its
> net80211 regulatory database code.
>
>
> Adrian
I was assuming that weather radars will not be supported at all but the related channels be just disabled. It is practically impossible to assure a 99.99% detection probability (as required for ETSI 1.5.1), or? E.g. to detect ETSI radar pattern 1 (10 pulses), you basically need to treat any single detected pulse as radar event. Doable, but not very useful ;)
Zefir
Thanks for the update.
To me it looks not reasonable to mix in between the two approaches: either we assume countrycodes use the same DFS region for all channels, or each channel/band needs to have its own. Otherwise I feel that a DFS region bitmap would give a semi-flexible compromise that might end up being insufficient to represent some fancy countrycodes.
Zefir
----- Original Message -----
> From: "Luis R. Rodriguez" <[email protected]>
> To: "Zefir Kurtisi" <[email protected]>, "Michael Green" <[email protected]>, "David Quan"
> <[email protected]>, "Kevin Hayes" <[email protected]>, "Arun Venkataraman" <[email protected]>
> Cc: "linux-wireless" <[email protected]>, "Boris Presman" <[email protected]>, "Assaf Azulay"
> <[email protected]>
> Sent: Wednesday, 28 September, 2011 9:52:15 PM
> Subject: Re: Regulatory revamp status
> On Wed, Sep 28, 2011 at 8:45 AM, Zefir Kurtisi
> <[email protected]> wrote:
> > Hello Luis,
> >
> > I am referring to your announcement for a regulatory revamp at the
> > LinuxWireless
> > summit in Vancouver and the patches to add DFS information to CRDA
> > you
> > proposed quite some time ago in [1].
> >
> > For the integration of DFS that is currently being worked out by TI,
> > we will need to have
> > the DFS regulatory domain for the selected countrycode available --
> > that basically was
> > implemented with the named patch set.
>
> Yup, there was one pending item on that and it was to determine
> whether or not a country can have different DFS regions for different
> frequency bands. If this is true this also implies that a country can
> have multiple DFS regions. I have found one country in our internal
> regulatory updates which maps Bulgaria to different DFS regions and
> have asked our regulatory folks about this. This seems odd to me and
> I'd prefer to stick to one DFS region entirely for one country, but if
> in the future we forsee DFS regions to be band specific this may
> complicate things and we should address this now. Can you tell me if
> at TI you have no multiple DFS regions for one country ? Do you guys
> have Bulgaria mapping to one DFS region?
>
> > Could you please give some info on the status of the regulatory
> > revamp and particularly if
> > the proposed DFS information will be part of it?
>
> You should consider DFS integration into wireless-regdb as independent
> of the regulatory revamp given that we have 16 bits we can use to
> extend wireless-regdb for any future capabilities without having to
> restructure the format of the file to require a different version of
> crda. So DFS can be added as-is today. Updates below on the regulatory
> revamp though and DFS.
>
> I'm chugging along the regulatory revamp slowly given the questions
> that come up with it require consulting with several different people.
> The latest piece I reviewed was TPC and for that it seems we already
> take into account the 3 dB difference into account into
> wireless-regdb, however this can be further optimized if TPC is
> implemented -- but implementing TPC is device specific in that the TPC
> reports and how you use them can vary depending on the device. When
> you send TPC report requests will also vary. In short I've latest
> determined to stick to what we have today and assume we'll always be
> reducing the 3 dB in power built-in already into the wireless-regdb
> power for each country where needed. This assumes no proper TPC
> implementation. It would still be nice to know when a band requires
> TPC though to enable vendors to implement TPC and reduce power not by
> 3 dB but by whatever metrics they come up with. Given that 3 dB seems
> to be the only required change we likely could stick to that as the
> assumed max value and just require a TPC flag, and if the band has
> this flag allow the driver / stack / etc to add 3 dB more to power if
> it implements TPC. The only problem with this is we'd assume alway a
> static 3 dB. Another possibility is to use a u8 value here to
> represent the deducted tx power, instead of a bit value for a flag.
>
> Technically speaking we can support both DFS and TPC in the current
> file format for wireless-regdb, we have 16 bits left, we could leave
> u8 for DFS region as a bitmask (left to determine about the multiple
> DFS regions) and u8 for the tx power adaptation for TPC. Thoughts?
>
> > One detail that came up in the discussion to
> > your patches was whether DFS regulatory domains are constant for a
> > countrycode or might
> > differ between bands. Has this been clarified meanwhile?
>
> Not yet! I've asked for input a while ago and today as well. What do
> you guys think?
>
> Luis
Hello Luis,
I am referring to your announcement for a regulatory revamp at the LinuxWireless summit in Vancouver and the patches to add DFS information to CRDA you proposed quite some time ago in [1].
For the integration of DFS that is currently being worked out by TI, we will need to have the DFS regulatory domain for the selected countrycode available -- that basically was implemented with the named patch set.
Could you please give some info on the status of the regulatory revamp and particularly if the proposed DFS information will be part of it? One detail that came up in the discussion to your patches was whether DFS regulatory domains are constant for a countrycode or might differ between bands. Has this been clarified meanwhile?
Thanks
Zefir
[1] http://marc.info/?l=linux-wireless&m=129286456607063&w=2, referenced at http://linuxwireless.org/en/developers/DFS#Map_countries_to_a_DFS_region_bit
On 29 September 2011 20:46, Zefir Kurtisi <[email protected]> wrote:
> Really? Where would be 'there' countrycode-wise?
>
> That would definitely break today's CRDA capabilities :-\
I -think- one or both of ETSI/FCC have different CAC/NOL requirements
for the channels which overlap the weather radars.
At least when someone took FreeBSD to get DFS certified a while ago,
the weather radar ranges were checked against a 30 minute CAC. :)
I think it's worth defining specific DFS parameters for each frequency
range. That's what I'll be doing for FreeBSD when I revamp its
net80211 regulatory database code.
Adrian
On Thu, Sep 29, 2011 at 5:46 AM, Zefir Kurtisi
<[email protected]> wrote:
> On 09/29/2011 01:45 PM, Adrian Chadd wrote:
>> On 29 September 2011 16:37, Zefir Kurtisi <[email protected]> wrote:
>>> Thanks for the update.
>>>
>>> To me it looks not reasonable to mix in between the two approaches: either we assume countrycodes use the same DFS region for all channels, or each channel/band needs to have its own. Otherwise I feel that a DFS region bitmap would give a semi-flexible compromise that might end up being insufficient to represent some fancy countrycodes.
>>
>> There's some funny stuff in there.
>>
>> For example, some of the DFS bands have different CAC/NOL timing. :-)
>>
>>
>>
>> Adrian
>
> Really? Where would be 'there' countrycode-wise?
>
> That would definitely break today's CRDA capabilities :-\
Well, CRDA has no DFS support yet ;) and hence the regulatory revamp
work, to accommodate as much as possible for both future technologies
and capture all these gotchas on existing technologies. If DFS varies
so much then using one u8 for a country may not be enough, and we may
want to add a whole section for DFS with the u8 being an optional
minimum and with a DFS section for overrides on values. Thoughts?
That is -- if your country varies per band or CAC / NOL timings we can
address these countries only with the future revamp work. This would
allow us to move forward with DFS support only for those countries
where a unified DFS mapping applies.
Luis
On Wed, Sep 28, 2011 at 8:45 AM, Zefir Kurtisi
<[email protected]> wrote:
> Hello Luis,
>
> I am referring to your announcement for a regulatory revamp at the LinuxWireless
> summit in Vancouver and the patches to add DFS information to CRDA you
> proposed quite some time ago in [1].
>
> For the integration of DFS that is currently being worked out by TI, we will need to have
> the DFS regulatory domain for the selected countrycode available -- that basically was
> implemented with the named patch set.
Yup, there was one pending item on that and it was to determine
whether or not a country can have different DFS regions for different
frequency bands. If this is true this also implies that a country can
have multiple DFS regions. I have found one country in our internal
regulatory updates which maps Bulgaria to different DFS regions and
have asked our regulatory folks about this. This seems odd to me and
I'd prefer to stick to one DFS region entirely for one country, but if
in the future we forsee DFS regions to be band specific this may
complicate things and we should address this now. Can you tell me if
at TI you have no multiple DFS regions for one country ? Do you guys
have Bulgaria mapping to one DFS region?
> Could you please give some info on the status of the regulatory revamp and particularly if
> the proposed DFS information will be part of it?
You should consider DFS integration into wireless-regdb as independent
of the regulatory revamp given that we have 16 bits we can use to
extend wireless-regdb for any future capabilities without having to
restructure the format of the file to require a different version of
crda. So DFS can be added as-is today. Updates below on the regulatory
revamp though and DFS.
I'm chugging along the regulatory revamp slowly given the questions
that come up with it require consulting with several different people.
The latest piece I reviewed was TPC and for that it seems we already
take into account the 3 dB difference into account into
wireless-regdb, however this can be further optimized if TPC is
implemented -- but implementing TPC is device specific in that the TPC
reports and how you use them can vary depending on the device. When
you send TPC report requests will also vary. In short I've latest
determined to stick to what we have today and assume we'll always be
reducing the 3 dB in power built-in already into the wireless-regdb
power for each country where needed. This assumes no proper TPC
implementation. It would still be nice to know when a band requires
TPC though to enable vendors to implement TPC and reduce power not by
3 dB but by whatever metrics they come up with. Given that 3 dB seems
to be the only required change we likely could stick to that as the
assumed max value and just require a TPC flag, and if the band has
this flag allow the driver / stack / etc to add 3 dB more to power if
it implements TPC. The only problem with this is we'd assume alway a
static 3 dB. Another possibility is to use a u8 value here to
represent the deducted tx power, instead of a bit value for a flag.
Technically speaking we can support both DFS and TPC in the current
file format for wireless-regdb, we have 16 bits left, we could leave
u8 for DFS region as a bitmask (left to determine about the multiple
DFS regions) and u8 for the tx power adaptation for TPC. Thoughts?
> One detail that came up in the discussion to
> your patches was whether DFS regulatory domains are constant for a countrycode or might
> differ between bands. Has this been clarified meanwhile?
Not yet! I've asked for input a while ago and today as well. What do
you guys think?
Luis
On 09/29/2011 01:45 PM, Adrian Chadd wrote:
> On 29 September 2011 16:37, Zefir Kurtisi <[email protected]> wrote:
>> Thanks for the update.
>>
>> To me it looks not reasonable to mix in between the two approaches: either we assume countrycodes use the same DFS region for all channels, or each channel/band needs to have its own. Otherwise I feel that a DFS region bitmap would give a semi-flexible compromise that might end up being insufficient to represent some fancy countrycodes.
>
> There's some funny stuff in there.
>
> For example, some of the DFS bands have different CAC/NOL timing. :-)
>
>
>
> Adrian
Really? Where would be 'there' countrycode-wise?
That would definitely break today's CRDA capabilities :-\
Zefir
On 29 September 2011 16:37, Zefir Kurtisi <[email protected]> wrote:
> Thanks for the update.
>
> To me it looks not reasonable to mix in between the two approaches: either we assume countrycodes use the same DFS region for all channels, or each channel/band needs to have its own. Otherwise I feel that a DFS region bitmap would give a semi-flexible compromise that might end up being insufficient to represent some fancy countrycodes.
There's some funny stuff in there.
For example, some of the DFS bands have different CAC/NOL timing. :-)
Adrian
On 09/29/2011 07:47 PM, Luis R. Rodriguez wrote:
> On Thu, Sep 29, 2011 at 5:46 AM, Zefir Kurtisi
> <[email protected]> wrote:
>> On 09/29/2011 01:45 PM, Adrian Chadd wrote:
>>> On 29 September 2011 16:37, Zefir Kurtisi <[email protected]> wrote:
>>>> Thanks for the update.
>>>>
>>>> To me it looks not reasonable to mix in between the two approaches: either we assume countrycodes use the same DFS region for all channels, or each channel/band needs to have its own. Otherwise I feel that a DFS region bitmap would give a semi-flexible compromise that might end up being insufficient to represent some fancy countrycodes.
>>>
>>> There's some funny stuff in there.
>>>
>>> For example, some of the DFS bands have different CAC/NOL timing. :-)
>>>
>>>
>>>
>>> Adrian
>>
>> Really? Where would be 'there' countrycode-wise?
>>
>> That would definitely break today's CRDA capabilities :-\
>
> Well, CRDA has no DFS support yet ;) and hence the regulatory revamp
Yes, I meant the proposed approach with a regulaltory domain per countrycode won't work with those fancy ones.
> work, to accommodate as much as possible for both future technologies
> and capture all these gotchas on existing technologies. If DFS varies
> so much then using one u8 for a country may not be enough, and we may
> want to add a whole section for DFS with the u8 being an optional
> minimum and with a DFS section for overrides on values. Thoughts?
>
That sounds like a doable way to start with the per countrycode domain and traverse to the optional refinement values on demand.
BTW, would this render the countrycode to CTL mappings in regd_common.h redundant, or do DFS and CTL domains differ?
> That is -- if your country varies per band or CAC / NOL timings we can
> address these countries only with the future revamp work. This would
> allow us to move forward with DFS support only for those countries
> where a unified DFS mapping applies.
>
To start with support for unified DFS domain CCs, was there ever some v2 for the related patch set you posted?
> Luis
Zefir
On Thu, Sep 29, 2011 at 1:37 AM, Zefir Kurtisi
<[email protected]> wrote:
> Thanks for the update.
>
> To me it looks not reasonable to mix in between the two approaches: either we assume countrycodes use the same DFS region for all channels, or each channel/band needs to have its own. Otherwise I feel that a DFS region bitmap would give a semi-flexible compromise that might end up being insufficient to represent some fancy countrycodes.
I reviewed this with Michael. The answer is we only want one DFS
region per country, that's it. I'll respin my DFS patches.
Luis