[RFC] regulatory information interpretation rules

[RFC] regulatory information interpretation rules

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 6844 bytes --]

Ok, so I'm thinking about the interpretation rules for the regulatory
information. I even dreamt about this tonight, unfortunately...

Long mail ahead, sorry, but I felt it was best to include some
background information and examples.

To recap, our information for each country currently consists of
multiple sub-band rules as follows:
	(MIN - MAX @ MAXBW), (MAXAG, TXPWR), FLAGS

Where:
	MIN	lower band edge
	MAX	upper band edge
	MAXBW	maximum usable bandwidth
	MAXAG	maximum permitted antenna gain
	TXPWR	maximum transmit power
	FLAGS	special restriction flags:
		- NO_OFDM	no OFDM use permitted
		- NO_CCK	no CCK use permitted
		- INDOOR	indoor use only
		- OUTDOOR	outdoor use only
		- DFS		DFS required
		- PTP_ONLY	PTP only
		- PTMP_ONLY	PTMP only
		- PASSIVE_SCAN	passive scan
		- NO_IBSS	no IBSS (should be applied to mesh also)

The flags should be fairly self-explanatory.

The maximum antenna gain is a little useless because there's no way to
enforce this by changing antennas, nor are antenna gain values always
known to the host software -- and in any case it seems a little
restrictive to disable the wireless entirely if the AG is higher. Needs
thought on what to do with this -- maybe keep for informational purposes
only.

The maximum usable bandwidth specifies how much of the (sub)band you are
allowed to use at once, at least that was my current interpretation -- I
now think we should document the interpretation rules and slightly
change it from what I've been thinking. This is relevant for example for
HT40, apparently not all countries permit using 40 MHz of the ISM
spectrum by a single transmitter.

For a simple interpretation case, let me give an example:
country ZW:
        (2402.000 - 2482.000 @ 40.000), (N/A, 20.00)

This means that you can use channels 1 through 13 with 20 MHz bandwidth,
or HT40+ on channels 1 through 11, or HT40- on channels 3 through 13, or
anything with a lower bandwidth, of course. Theoretically you would be
allowed to use a 10 MHz channel on 2407 MHz, but that isn't possible in
802.11 implementations. [1]


More complex rules exist for 5 GHz, though. Take this example:
country DK:
        (2402.000 - 2482.000 @ 40.000), (N/A, 20.00)
        (5170.000 - 5250.000 @ 40.000), (N/A, 20.00)
        (5250.000 - 5330.000 @ 40.000), (N/A, 20.00), DFS
        (5490.000 - 5710.000 @ 40.000), (N/A, 27.00), DFS

Here, we have a DFS requirement on anything above 5250 MHz. This does
not, however, preclude using HT40- on channel 52 (5260 MHz) [2], but
would require DFS for that combination. Similar things can happen for
transmit power.

Interesting things happen where you have overlaps, like Japan's 2.4 GHz
band:
        (2402.000 - 2472.000 @ 40.000), (N/A, 20.00)
        (2457.000 - 2482.000 @ 20.000), (N/A, 20.00)
        (2474.000 - 2494.000 @ 20.000), (N/A, 20.00), NO-OFDM

Luis says this is meant to specify:

        Channels 1-11 allow 40 width channels, so HT40 is allowed.
        
        Channels 12, 13 only allow 20 MHz width channels, so HT40 is
        disallowed.
        
        Channel 14 only allows non-OFDM.

But how can we arrive at that interpretation? I would argue that we need
to change the interpretation rules in a way that lets us remove overlap
and specify what is really required. This means more dynamic flags
calculations, but we can live with that. To this end, let me propose
that the rules for 2.4 GHz Japan be rewritten to (where I have marked
changes with *):

        ( 2402.000 - *2452.000 @ 40.000), (N/A, 20.00)
        (*2452.000 -  2482.000 @ 20.000), (N/A, 20.00)
        (*2482.000 -  2494.000 @ 20.000), (N/A, 20.00), NO-OFDM

Now how should you interpret this? I'll propose the following
interpretation rules (and show how you arrive at the required
interpretation from above):

 1) MIN values are really something like MIN+, i.e. approaching the MIN
    from above, that means that the value "2452 MHz" falls into the
    first of the ranges, not the second [3]

 2) The entire band a channel occupies needs to be covered by (any
    number of) contiguous rules.

 3) The MAXBW value specifies what maximum bandwidth a channel can use
    which has its center frequency (!) falling into the given range.

 4) The FLAGS specify restrictions that any channel _overlapping_ the
    given range has to operate under.

That is all. Now let me show how to interpret this.

"Channels 1-11 allow 40 width channels, so HT40 is allowed."

        Channel 11 has center frequency 2462, but when used with HT40
        the center of the used bandwidth falls to 2452 or 2472. 2452
        falls into the first range, so can use 40 MHz, 2472 falls into
        the second range so cannot use 40 MHz, so only HT40- is
        permitted.

"Channels 12, 13 only allow 20 MHz width channels, so HT40 is disallowed."

        Channels 12/13 have center frequencies 2467/2472 respectively,
        with HT40 falling to center frequencies 2457, 2477, 2462, 2482.
        None of those fall into a range where 40 MHz bandwidth is
        allowed, but 2467/2472 fall into the second range so can be used
        with 20 MHz (e.g. HT20), the 20 MHz channel 13 covers 2462-2482
        MHz so it is not subject to the NO_OFDM restriction.

"Channel 14 only allows non-OFDM."

        Channel 14's center frequency is 2484, so it clearly falls into
        the third range, its HT40 use would be 2474 or 2494 MHz none of
        which are permitted to use 40 MHz, and anything with 2494 center
        frequency would not be covered by a permitted range anyway.
        Channel 14 (as a regular 20 MHz channel) covers 2474-2494 so
        overlaps with the third range and as such is subject to the
        NO_OFDM restriction.


Note that currently, due to our regulatory rules, this interpretation
doesn't actually require changes in any regulatory domain but Japan (JP)
and North Korea (KP) because no other domain has overlaps, and all the
other examples are like Denmark -- which doesn't apply to us (cf. [2]).

Comments?

johannes


[1] mind you, we are simplifying a little here, HT40 really seems to
affect about 45-50 MHz of the spectrum, but that seems not very relevant

[2] which is not valid, and due to the way the regulatory information
was derived we currently only have invalid examples, but this is likely
to change as the rules are adapted to match the real legislation rather
than how they apply to 802.11 -- after all we want this database to be
usable for other things too

[3] this is arbitrary, but needs to be specified. If you need the other
way, you need to use 2451.999 MHz for both values of 2452 above, which
should be good enough in the granularity we require.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [RFC] regulatory information interpretation rules

[Luis R. Rodriguez]

On Sun, Mar 22, 2009 at 2:02 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> Ok, so I'm thinking about the interpretation rules for the regulatory
> information. I even dreamt about this tonight, unfortunately...
>
> Long mail ahead, sorry, but I felt it was best to include some
> background information and examples.
>
> To recap, our information for each country currently consists of
> multiple sub-band rules as follows:
> =C2=A0 =C2=A0 =C2=A0 =C2=A0(MIN - MAX @ MAXBW), (MAXAG, TXPWR), FLAGS
>
> Where:
> =C2=A0 =C2=A0 =C2=A0 =C2=A0MIN =C2=A0 =C2=A0 lower band edge
> =C2=A0 =C2=A0 =C2=A0 =C2=A0MAX =C2=A0 =C2=A0 upper band edge
> =C2=A0 =C2=A0 =C2=A0 =C2=A0MAXBW =C2=A0 maximum usable bandwidth
> =C2=A0 =C2=A0 =C2=A0 =C2=A0MAXAG =C2=A0 maximum permitted antenna gai=
n
> =C2=A0 =C2=A0 =C2=A0 =C2=A0TXPWR =C2=A0 maximum transmit power
> =C2=A0 =C2=A0 =C2=A0 =C2=A0FLAGS =C2=A0 special restriction flags:
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- NO_OFDM =C2=A0=
 =C2=A0 =C2=A0 no OFDM use permitted
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- NO_CCK =C2=A0=
 =C2=A0 =C2=A0 =C2=A0no CCK use permitted
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- INDOOR =C2=A0=
 =C2=A0 =C2=A0 =C2=A0indoor use only
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- OUTDOOR =C2=A0=
 =C2=A0 =C2=A0 outdoor use only
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- DFS =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 DFS required
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- PTP_ONLY =C2=
=A0 =C2=A0 =C2=A0PTP only
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- PTMP_ONLY =C2=
=A0 =C2=A0 PTMP only
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- PASSIVE_SCAN=
 =C2=A0passive scan
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- NO_IBSS =C2=A0=
 =C2=A0 =C2=A0 no IBSS (should be applied to mesh also)
>
> The flags should be fairly self-explanatory.
>
> The maximum antenna gain is a little useless because there's no way t=
o
> enforce this by changing antennas, nor are antenna gain values always
> known to the host software -- and in any case it seems a little
> restrictive to disable the wireless entirely if the AG is higher. Nee=
ds
> thought on what to do with this -- maybe keep for informational purpo=
ses
> only.
>
> The maximum usable bandwidth specifies how much of the (sub)band you =
are
> allowed to use at once, at least that was my current interpretation -=
- I
> now think we should document the interpretation rules and slightly
> change it from what I've been thinking. This is relevant for example =
for
> HT40, apparently not all countries permit using 40 MHz of the ISM
> spectrum by a single transmitter.
>
> For a simple interpretation case, let me give an example:
> country ZW:
> =C2=A0 =C2=A0 =C2=A0 =C2=A0(2402.000 - 2482.000 @ 40.000), (N/A, 20.0=
0)
>
> This means that you can use channels 1 through 13 with 20 MHz bandwid=
th,
> or HT40+ on channels 1 through 11, or HT40- on channels 3 through 13,=
 or
> anything with a lower bandwidth, of course. Theoretically you would b=
e
> allowed to use a 10 MHz channel on 2407 MHz, but that isn't possible =
in
> 802.11 implementations. [1]
>
>
> More complex rules exist for 5 GHz, though. Take this example:
> country DK:
> =C2=A0 =C2=A0 =C2=A0 =C2=A0(2402.000 - 2482.000 @ 40.000), (N/A, 20.0=
0)
> =C2=A0 =C2=A0 =C2=A0 =C2=A0(5170.000 - 5250.000 @ 40.000), (N/A, 20.0=
0)
> =C2=A0 =C2=A0 =C2=A0 =C2=A0(5250.000 - 5330.000 @ 40.000), (N/A, 20.0=
0), DFS
> =C2=A0 =C2=A0 =C2=A0 =C2=A0(5490.000 - 5710.000 @ 40.000), (N/A, 27.0=
0), DFS
>
> Here, we have a DFS requirement on anything above 5250 MHz. This does
> not, however, preclude using HT40- on channel 52 (5260 MHz) [2], but
> would require DFS for that combination. Similar things can happen for
> transmit power.
>
> Interesting things happen where you have overlaps, like Japan's 2.4 G=
Hz
> band:
> =C2=A0 =C2=A0 =C2=A0 =C2=A0(2402.000 - 2472.000 @ 40.000), (N/A, 20.0=
0)
> =C2=A0 =C2=A0 =C2=A0 =C2=A0(2457.000 - 2482.000 @ 20.000), (N/A, 20.0=
0)
> =C2=A0 =C2=A0 =C2=A0 =C2=A0(2474.000 - 2494.000 @ 20.000), (N/A, 20.0=
0), NO-OFDM
>
> Luis says this is meant to specify:
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0Channels 1-11 allow 40 width channels, so =
HT40 is allowed.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0Channels 12, 13 only allow 20 MHz width ch=
annels, so HT40 is
> =C2=A0 =C2=A0 =C2=A0 =C2=A0disallowed.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0Channel 14 only allows non-OFDM.
>
> But how can we arrive at that interpretation? I would argue that we n=
eed
> to change the interpretation rules in a way that lets us remove overl=
ap
> and specify what is really required. This means more dynamic flags
> calculations, but we can live with that. To this end, let me propose
> that the rules for 2.4 GHz Japan be rewritten to (where I have marked
> changes with *):
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0( 2402.000 - *2452.000 @ 40.000), (N/A, 20=
=2E00)
> =C2=A0 =C2=A0 =C2=A0 =C2=A0(*2452.000 - =C2=A02482.000 @ 20.000), (N/=
A, 20.00)
> =C2=A0 =C2=A0 =C2=A0 =C2=A0(*2482.000 - =C2=A02494.000 @ 20.000), (N/=
A, 20.00), NO-OFDM
>
> Now how should you interpret this? I'll propose the following
> interpretation rules (and show how you arrive at the required
> interpretation from above):
>
> =C2=A01) MIN values are really something like MIN+, i.e. approaching =
the MIN
> =C2=A0 =C2=A0from above, that means that the value "2452 MHz" falls i=
nto the
> =C2=A0 =C2=A0first of the ranges, not the second [3]

I rather be more exact. Can you elaborate a little more on this?

> =C2=A02) The entire band a channel occupies needs to be covered by (a=
ny
> =C2=A0 =C2=A0number of) contiguous rules.
>
> =C2=A03) The MAXBW value specifies what maximum bandwidth a channel c=
an use
> =C2=A0 =C2=A0which has its center frequency (!) falling into the give=
n range.
>
> =C2=A04) The FLAGS specify restrictions that any channel _overlapping=
_ the
> =C2=A0 =C2=A0given range has to operate under.
>
> That is all. Now let me show how to interpret this.
>
> "Channels 1-11 allow 40 width channels, so HT40 is allowed."
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0Channel 11 has center frequency 2462, but =
when used with HT40
> =C2=A0 =C2=A0 =C2=A0 =C2=A0the center of the used bandwidth falls to =
2452 or 2472.

> =C2=A0 =C2=A0 =C2=A0 =C2=A02452 falls into the first range, so can us=
e 40 MHz,

Hm, so the two modified rules that we should look at for a channel
who's center freq is 2452 MHz are:

        ( 2402.000 - *2452.000 @ 40.000), (N/A, 20.00)
        (*2452.000 -  2482.000 @ 20.000), (N/A, 20.00)

I cannot clearly see how a 40 MHz width channel would be allowed here
if its center of freq is 2452 MHz given the interpretation rules
above. It would seem to me the two regulatory rules would be required
to make that determination since the start freq and end freq of the
HT40 channel would only fit when considering both rules. Why would we
determine we can use 40 MHz on this HT40 channel? What if the allowed
bandwidth for the second rule was 10 MHz instead of 20 MHz?

>        2472 falls into
> =C2=A0 =C2=A0 =C2=A0 =C2=A0the second range so cannot use 40 MHz, so =
only HT40- is
> =C2=A0 =C2=A0 =C2=A0 =C2=A0permitted.
>
> "Channels 12, 13 only allow 20 MHz width channels, so HT40 is disallo=
wed."
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0Channels 12/13 have center frequencies 246=
7/2472 respectively,
> =C2=A0 =C2=A0 =C2=A0 =C2=A0with HT40 falling to center frequencies 24=
57, 2477, 2462, 2482.
> =C2=A0 =C2=A0 =C2=A0 =C2=A0None of those fall into a range where 40 M=
Hz bandwidth is
> =C2=A0 =C2=A0 =C2=A0 =C2=A0allowed, but 2467/2472 fall into the secon=
d range so can be used
> =C2=A0 =C2=A0 =C2=A0 =C2=A0with 20 MHz (e.g. HT20), the 20 MHz channe=
l 13 covers 2462-2482
> =C2=A0 =C2=A0 =C2=A0 =C2=A0MHz so it is not subject to the NO_OFDM re=
striction.
>
> "Channel 14 only allows non-OFDM."
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0Channel 14's center frequency is 2484, so =
it clearly falls into
> =C2=A0 =C2=A0 =C2=A0 =C2=A0the third range, its HT40 use would be 247=
4 or 2494 MHz none of
> =C2=A0 =C2=A0 =C2=A0 =C2=A0which are permitted to use 40 MHz, and any=
thing with 2494 center
> =C2=A0 =C2=A0 =C2=A0 =C2=A0frequency would not be covered by a permit=
ted range anyway.
> =C2=A0 =C2=A0 =C2=A0 =C2=A0Channel 14 (as a regular 20 MHz channel) c=
overs 2474-2494 so
> =C2=A0 =C2=A0 =C2=A0 =C2=A0overlaps with the third range and as such =
is subject to the
> =C2=A0 =C2=A0 =C2=A0 =C2=A0NO_OFDM restriction.
>
>
> Note that currently, due to our regulatory rules, this interpretation
> doesn't actually require changes in any regulatory domain but Japan (=
JP)
> and North Korea (KP) because no other domain has overlaps, and all th=
e
> other examples are like Denmark -- which doesn't apply to us (cf. [2]=
).
>
> Comments?

The overlapping suggestions make sense.

Apart from creating a clarification on how we would deal with
overlapping regulatory rules this also clarifies the way we should
logically think of channels in terms of regulatory for our
infrastructure. 802.11 HT40 channels are now viewed as a singular
channel with its own center of frequency and the question that is
asked is:

"is this HT40 channel allowed?"

The notion of the two channels involved required to make use of HT40
work is ignored and while this works it should be considered for
implementation. For example we want to allow a channel change to occur
as quickly as possible so if the above regulatory questions can be
saved into flag form to avoid a direct regulatory rule lookup during
channel change I think it would be great. How would we cache the
answer to the HT40 question on the channel?

The same HT40 question could be made but instead of looking at the
HT40 channel as an individual channel we'd be trying to answer this by
looking at the two channels involved to make the HT40 channel happen.
We'd know if HT40 is allowed by the allowed bandwidth in the given
regulatory domain, we'd still have to find out whether or not HT40- or
HT40+ is allowed but to answer this we first need to know on which
channels HT40 is allowed and which channels are disabled. The
assumption is if a channel is allowed then the channel can use 20 MHz.
=46or example to find out whether or not HT40- is allowed we'd first
check if the control channel (aka primary channel):

  o exists
  o allowed
  o allows HT40

We'd then check if the same for the extension channel (aka secondary
channel) exists. If both of these channel checks check out OK then
HT40- can be marked as allowed on the primary channel. The answer then
becomes cached for later lookups upon channel change.

How would we go about this with the proposed changes on considering
HT40- upon a channel change?

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] regulatory information interpretation rules

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 5467 bytes --]

On Sun, 2009-03-22 at 13:48 -0700, Luis R. Rodriguez wrote:

> >  1) MIN values are really something like MIN+, i.e. approaching the MIN
> >    from above, that means that the value "2452 MHz" falls into the
> >    first of the ranges, not the second [3]
> 
> I rather be more exact. Can you elaborate a little more on this?

Hmm, ok, well, let me put it this way:

Given

	MIN - MAX @ ...

and centre = MIN, we do not say that centre falls into that range.

Basically we do "MIN < freq <= MAX" rather than "MIN <= freq <= MAX" to
avoid problems with
	A - B @ ...
	B - C @ ...
and then determining which range "B" falls into. My interpretation says
that it belongs into the _first_ rather than the second range.

> > "Channels 1-11 allow 40 width channels, so HT40 is allowed."
> >
> >        Channel 11 has center frequency 2462, but when used with HT40
> >        the center of the used bandwidth falls to 2452 or 2472.
> 
> >        2452 falls into the first range, so can use 40 MHz,
> 
> Hm, so the two modified rules that we should look at for a channel
> who's center freq is 2452 MHz are:
> 
>         ( 2402.000 - *2452.000 @ 40.000), (N/A, 20.00)
>         (*2452.000 -  2482.000 @ 20.000), (N/A, 20.00)
> 
> I cannot clearly see how a 40 MHz width channel would be allowed here
> if its center of freq is 2452 MHz given the interpretation rules
> above.

This is why I needed the rule 1), to specify that 2452 falls into the
first range which specifies @40.

> It would seem to me the two regulatory rules would be required
> to make that determination since the start freq and end freq of the
> HT40 channel would only fit when considering both rules. Why would we
> determine we can use 40 MHz on this HT40 channel? What if the allowed
> bandwidth for the second rule was 10 MHz instead of 20 MHz?

That seems irrelevant -- I said that the maximum usable bandwidth
depends on the range the centre frequency falls into, and all the ranges
we've defined.

Maybe I should clarify some things more -- it was obvious to me after
thinking about it, but I suppose I formulated it more as a mathematician
than a recipe for an engineer ;)

> The overlapping suggestions make sense.
> 
> Apart from creating a clarification on how we would deal with
> overlapping regulatory rules this also clarifies the way we should
> logically think of channels in terms of regulatory for our
> infrastructure. 802.11 HT40 channels are now viewed as a singular
> channel with its own center of frequency and the question that is
> asked is:
> 
> "is this HT40 channel allowed?"

Right. It's also a clarification that overlapping ranges should not be
allowed (and we should thus check for that somewhere), and how to handle
all the possible cases without overlapping ranges, mostly due to 2).

> The notion of the two channels involved required to make use of HT40
> work is ignored and while this works it should be considered for
> implementation.

Indeed, this is first and foremost a definition of how to interpret the
database that we have, and not how to implement it.

> For example we want to allow a channel change to occur
> as quickly as possible so if the above regulatory questions can be
> saved into flag form to avoid a direct regulatory rule lookup during
> channel change I think it would be great. How would we cache the
> answer to the HT40 question on the channel?

Yeah, I need to think about this. We also need to think about 5/10 MHz
channels. I'm thinking that maybe the best way to do that is to add a
"supported channel types" bitmap to each channel, which we could then
modify to include HT40+/- as appropriate as well. Something like we have
with orig_flags and flags already.

> The same HT40 question could be made but instead of looking at the
> HT40 channel as an individual channel we'd be trying to answer this by
> looking at the two channels involved to make the HT40 channel happen.

I kinda disagree here. How should we know whether 20+20 is allowed or
not if we don't treat it as 40?

> We'd know if HT40 is allowed by the allowed bandwidth in the given
> regulatory domain, we'd still have to find out whether or not HT40- or
> HT40+ is allowed but to answer this we first need to know on which
> channels HT40 is allowed and which channels are disabled. The
> assumption is if a channel is allowed then the channel can use 20 MHz.

Not exactly -- we could have pure 10 MHz bands in the regdb in the
future.

> For example to find out whether or not HT40- is allowed we'd first
> check if the control channel (aka primary channel):
> 
>   o exists
>   o allowed
>   o allows HT40
> 
> We'd then check if the same for the extension channel (aka secondary
> channel) exists. If both of these channel checks check out OK then
> HT40- can be marked as allowed on the primary channel. The answer then
> becomes cached for later lookups upon channel change.

Ok, yes, we could do that, but it would be disregarding the MAXBW, no?
Or rather, how do you define "allows HT40"?

> How would we go about this with the proposed changes on considering
> HT40- upon a channel change?

?

Anyhow, yes, there are different ways to implement this, but then it
seems we'd need more regulatory flags, and I don't see a reason for that
given the information we have -- which is only a little quirky for JP
and KP.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [RFC] regulatory information interpretation rules

[Luis R. Rodriguez]

On Sun, Mar 22, 2009 at 2:33 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Sun, 2009-03-22 at 13:48 -0700, Luis R. Rodriguez wrote:
>
>> > =C2=A01) MIN values are really something like MIN+, i.e. approachi=
ng the MIN
>> > =C2=A0 =C2=A0from above, that means that the value "2452 MHz" fall=
s into the
>> > =C2=A0 =C2=A0first of the ranges, not the second [3]
>>
>> I rather be more exact. Can you elaborate a little more on this?
>
> Hmm, ok, well, let me put it this way:
>
> Given
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0MIN - MAX @ ...
>
> and centre =3D MIN, we do not say that centre falls into that range.
>
> Basically we do "MIN < freq <=3D MAX" rather than "MIN <=3D freq <=3D=
 MAX" to
> avoid problems with
> =C2=A0 =C2=A0 =C2=A0 =C2=A0A - B @ ...
> =C2=A0 =C2=A0 =C2=A0 =C2=A0B - C @ ...
> and then determining which range "B" falls into. My interpretation sa=
ys
> that it belongs into the _first_ rather than the second range.

Hm, it changes the way we think about the regulatory rules
considerably. For example, if a regulatory domain is defined with only
one rule as:

2412 - 2462 @ 40

It would imply that a regular (20 MHz wide) channel 1 with a center of
freq 2412 MHz would not be allowed while a regular (20 MHz wide)
channel 11 with a center of freq 2462 MHz would be allowed. It means
that to the regulatory rule patcher/contributor they would have to
think of the first value used as the center of freq -1 at least, while
the end freq can be equal to the max center of freq allowed.

Would this also mean a channel who's center of freq is 2413 (although
bogus) is allowed?

>> > "Channels 1-11 allow 40 width channels, so HT40 is allowed."
>> >
>> > =C2=A0 =C2=A0 =C2=A0 =C2=A0Channel 11 has center frequency 2462, b=
ut when used with HT40
>> > =C2=A0 =C2=A0 =C2=A0 =C2=A0the center of the used bandwidth falls =
to 2452 or 2472.
>>
>> > =C2=A0 =C2=A0 =C2=A0 =C2=A02452 falls into the first range, so can=
 use 40 MHz,
>>
>> Hm, so the two modified rules that we should look at for a channel
>> who's center freq is 2452 MHz are:
>>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 ( 2402.000 - *2452.000 @ 40.000), (N/A, =
20.00)
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 (*2452.000 - =C2=A02482.000 @ 20.000), (=
N/A, 20.00)
>>
>> I cannot clearly see how a 40 MHz width channel would be allowed her=
e
>> if its center of freq is 2452 MHz given the interpretation rules
>> above.
>
> This is why I needed the rule 1), to specify that 2452 falls into the
> first range which specifies @40.

I see, thanks for the clarification.

>> It would seem to me the two regulatory rules would be required
>> to make that determination since the start freq and end freq of the
>> HT40 channel would only fit when considering both rules. Why would w=
e
>> determine we can use 40 MHz on this HT40 channel? What if the allowe=
d
>> bandwidth for the second rule was 10 MHz instead of 20 MHz?
>
> That seems irrelevant -- I said that the maximum usable bandwidth
> depends on the range the centre frequency falls into, and all the ran=
ges
> we've defined.

I understand the proposal better now.

> Maybe I should clarify some things more -- it was obvious to me after
> thinking about it, but I suppose I formulated it more as a mathematic=
ian
> than a recipe for an engineer ;)

Heh, thanks yeah the above helps a lot.

>> The overlapping suggestions make sense.
>>
>> Apart from creating a clarification on how we would deal with
>> overlapping regulatory rules this also clarifies the way we should
>> logically think of channels in terms of regulatory for our
>> infrastructure. 802.11 HT40 channels are now viewed as a singular
>> channel with its own center of frequency and the question that is
>> asked is:
>>
>> "is this HT40 channel allowed?"
>
> Right. It's also a clarification that overlapping ranges should not b=
e
> allowed (and we should thus check for that somewhere), and how to han=
dle
> all the possible cases without overlapping ranges, mostly due to 2).
>
>> The notion of the two channels involved required to make use of HT40
>> work is ignored and while this works it should be considered for
>> implementation.
>
> Indeed, this is first and foremost a definition of how to interpret t=
he
> database that we have, and not how to implement it.

Right so reason I mentioned this is because ultimately I'm in favor
for choosing the interpretation and implementation which is easiest,
fastest and will also cause less pain for users of the old style reg
rules.

>> For example we want to allow a channel change to occur
>> as quickly as possible so if the above regulatory questions can be
>> saved into flag form to avoid a direct regulatory rule lookup during
>> channel change I think it would be great. How would we cache the
>> answer to the HT40 question on the channel?
>
> Yeah, I need to think about this. We also need to think about 5/10 MH=
z
> channels. I'm thinking that maybe the best way to do that is to add a
> "supported channel types" bitmap to each channel, which we could then
> modify to include HT40+/- as appropriate as well. Something like we h=
ave
> with orig_flags and flags already.

Yeah I think that would make sense. BTW so one way to deal with this
is to keep the channel.bandwidth and to simply think about it as the
max allowed bandwidth _per_channel_. Technically if this is =3D=3D 20 t=
hen
it is implied channels with custom bandwidths smaller than this would
be allowed. Of course then its a matter of what the device and its
device driver actually supports. As for HT40 the bandwidth required
would be 20 per channel but you'd also need to ensure the channel doe
snot have the NO_HT40 flag set which would have been propagated down
from the regulatory rule.

>> The same HT40 question could be made but instead of looking at the
>> HT40 channel as an individual channel we'd be trying to answer this =
by
>> looking at the two channels involved to make the HT40 channel happen=
=2E
>
> I kinda disagree here. How should we know whether 20+20 is allowed or
> not if we don't treat it as 40?

As of right now the assumption in our code is to disable a channel if
we cannot use at least 20 MHz on it. Therefore if the channel is not
disabled we _know_ we can use 20 MHz on it. If the primary and
secondary channel exists on the device and are enabled then we can
potentially use HT40. The only other question missing is whether or
not the regulatory domain allows for it. We would know whether both
channels' regulatory rule supports HT40 by looking at their respective
freq_range->max_bandiwdth, this would have to be >=3D 40 MHz. Otherwise
we can set a NO_HT40 flag on the channel. We'd then only allow HT40 if
both channels' rules enable it.

>> We'd know if HT40 is allowed by the allowed bandwidth in the given
>> regulatory domain, we'd still have to find out whether or not HT40- =
or
>> HT40+ is allowed but to answer this we first need to know on which
>> channels HT40 is allowed and which channels are disabled. The
>> assumption is if a channel is allowed then the channel can use 20 MH=
z.
>
> Not exactly -- we could have pure 10 MHz bands in the regdb in the
> future.

Agreed, the above was describing how we currently implement this. If
10 Mhz channels are enabled later then the channel's max_bandwidth
would be set to 10 MHz and we'd then add a check to ensure for HT40
both channels support at least 20 MHz.

>> For example to find out whether or not HT40- is allowed we'd first
>> check if the control channel (aka primary channel):
>>
>> =C2=A0 o exists
>> =C2=A0 o allowed
>> =C2=A0 o allows HT40
>>
>> We'd then check if the same for the extension channel (aka secondary
>> channel) exists. If both of these channel checks check out OK then
>> HT40- can be marked as allowed on the primary channel. The answer th=
en
>> becomes cached for later lookups upon channel change.
>
> Ok, yes, we could do that, but it would be disregarding the MAXBW, no=
?
> Or rather, how do you define "allows HT40"?

Nope, the trick is to also rely on the regulatory rule's max bandwidth
to determine whether or not HT40 is allowed or not. For example if you
look at the wireless-regdb and find regulatory rules with a frequency
range marked with a max bandwidth of 20 MHz you'd know the channels
that are being queried that fit into those rules would not allow HT40,
so you set a NO_HT40 flag on the channel.

>> How would we go about this with the proposed changes on considering
>> HT40- upon a channel change?
>
> ?

I was asking specifically how this would be implemented. I was curious
for example if you'd cache or not whether HT40- would be allowed
somehow and if so where.

> Anyhow, yes, there are different ways to implement this, but then it
> seems we'd need more regulatory flags, and I don't see a reason for t=
hat
> given the information we have -- which is only a little quirky for JP
> and KP.

Depends on what you mean by needing more regulatory flags. We would
certainly not require more regulatory flags in the wireless-regdb or
crda, nor to interpret them in the kernel. We would however need them
for the 802.11 code to help cache the answer to these questions. We'd
need the NO_HT40 flag to cache whether or not a regulatory rule's max
bandwidth allows HT40 or not, then we could end up re-using the FAT
above and FAT below flags to indicate NO_HT40MINUS and NO_HT40PLUS. So
technically we wouldn't be adding any other flag other than a NO_HT40
flag just to indicate the regulatory domain's HT40 preferences.

Something we should also take into consideration is the changes
required to the wireless-regdb and what this would imply for users of
kernel code which interpret it differently. This could potentially
mean we'd then have to release two different wireless-regdb files per
release but I think it'd be nice to avoid that if possible

An alternative to this proposal is to clarify how overlapping
regulatory rules should be considered (which is how it works anyway).
Here's my take on it:

If you have overlapping rules you simply apply the first rule which
fits your desired bandwidth and modulation type. Right now we only pay
attention to the desired bandwidth, but we could add things like "OFMD
required" and only return the first rule that allows OFDM for example
for the given bandwidth.

This allows you to be very specific about your requirements.
Technically we wouldn't have to re-run these checks unless the user
changes the target bandwidth to something smaller than the default of
20 MHz.

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] regulatory information interpretation rules

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 9643 bytes --]

On Sun, 2009-03-22 at 15:52 -0700, Luis R. Rodriguez wrote:

> > Basically we do "MIN < freq <= MAX" rather than "MIN <= freq <= MAX" to
> > avoid problems with
> >        A - B @ ...
> >        B - C @ ...
> > and then determining which range "B" falls into. My interpretation says
> > that it belongs into the _first_ rather than the second range.
> 
> Hm, it changes the way we think about the regulatory rules
> considerably. For example, if a regulatory domain is defined with only
> one rule as:
> 
> 2412 - 2462 @ 40
> 
> It would imply that a regular (20 MHz wide) channel 1 with a center of
> freq 2412 MHz would not be allowed while a regular (20 MHz wide)
> channel 11 with a center of freq 2462 MHz would be allowed. It means
> that to the regulatory rule patcher/contributor they would have to
> think of the first value used as the center of freq -1 at least, while
> the end freq can be equal to the max center of freq allowed.

No, of course we still require (rule 2) that the entire channel
bandwidth falls into the permitted range, so this would never allow
anything with centre 2412 or 2462 since those would span more than the
range.

> Would this also mean a channel who's center of freq is 2413 (although
> bogus) is allowed?

Only if it has a 2 MHz bandwidth :P

However, yes, I'm disregarding IEEE rules about allowed channels --
that's something we are handling by the channel array.

> > Indeed, this is first and foremost a definition of how to interpret the
> > database that we have, and not how to implement it.
> 
> Right so reason I mentioned this is because ultimately I'm in favor
> for choosing the interpretation and implementation which is easiest,
> fastest and will also cause less pain for users of the old style reg
> rules.

Mind you -- unless the reg rules for a country contain overlap there's
nothing that really changes with these interpretation rules (some more
things would be allowed, technically, like HT40+ on channel 48, but
those are not valid according to the IEEE -- this is unrelated to
regulatory code though). If they do contain overlap I'm saying that we
should remove the overlap and specify how to use the rules w/o the
overlap to achieve the correct goal.

> >> For example we want to allow a channel change to occur
> >> as quickly as possible so if the above regulatory questions can be
> >> saved into flag form to avoid a direct regulatory rule lookup during
> >> channel change I think it would be great. How would we cache the
> >> answer to the HT40 question on the channel?
> >
> > Yeah, I need to think about this. We also need to think about 5/10 MHz
> > channels. I'm thinking that maybe the best way to do that is to add a
> > "supported channel types" bitmap to each channel, which we could then
> > modify to include HT40+/- as appropriate as well. Something like we have
> > with orig_flags and flags already.
> 
> Yeah I think that would make sense. BTW so one way to deal with this
> is to keep the channel.bandwidth and to simply think about it as the
> max allowed bandwidth _per_channel_. Technically if this is == 20 then
> it is implied channels with custom bandwidths smaller than this would
> be allowed. Of course then its a matter of what the device and its
> device driver actually supports. 

Yeah that's not going to work -- most devices will support 20 MHz but
not 10 MHz channels.

> As for HT40 the bandwidth required
> would be 20 per channel but you'd also need to ensure the channel doe
> snot have the NO_HT40 flag set which would have been propagated down
> from the regulatory rule.

But I don't want a NO_HT40 flag :P

> >> The same HT40 question could be made but instead of looking at the
> >> HT40 channel as an individual channel we'd be trying to answer this by
> >> looking at the two channels involved to make the HT40 channel happen.
> >
> > I kinda disagree here. How should we know whether 20+20 is allowed or
> > not if we don't treat it as 40?
> 
> As of right now the assumption in our code is to disable a channel if
> we cannot use at least 20 MHz on it. Therefore if the channel is not
> disabled we _know_ we can use 20 MHz on it. If the primary and
> secondary channel exists on the device and are enabled then we can
> potentially use HT40. The only other question missing is whether or
> not the regulatory domain allows for it. We would know whether both
> channels' regulatory rule supports HT40 by looking at their respective
> freq_range->max_bandiwdth, this would have to be >= 40 MHz. Otherwise
> we can set a NO_HT40 flag on the channel. We'd then only allow HT40 if
> both channels' rules enable it.

Yeah but that's rather confusing. And it requires looking at even more
information?

> >> We'd know if HT40 is allowed by the allowed bandwidth in the given
> >> regulatory domain, we'd still have to find out whether or not HT40- or
> >> HT40+ is allowed but to answer this we first need to know on which
> >> channels HT40 is allowed and which channels are disabled. The
> >> assumption is if a channel is allowed then the channel can use 20 MHz.
> >
> > Not exactly -- we could have pure 10 MHz bands in the regdb in the
> > future.
> 
> Agreed, the above was describing how we currently implement this. If
> 10 Mhz channels are enabled later then the channel's max_bandwidth
> would be set to 10 MHz and we'd then add a check to ensure for HT40
> both channels support at least 20 MHz.

s/20 MHz/40 MHz/ and that's where it gets too complicated IMHO
regulatory wise to treat HT40 as two channels. I'd rather view that as
an implementation detail and say we are nuking 40 MHz of the bandwidth
-- check if we are allowed to do _that_.

> > Ok, yes, we could do that, but it would be disregarding the MAXBW, no?
> > Or rather, how do you define "allows HT40"?
> 
> Nope, the trick is to also rely on the regulatory rule's max bandwidth
> to determine whether or not HT40 is allowed or not. For example if you
> look at the wireless-regdb and find regulatory rules with a frequency
> range marked with a max bandwidth of 20 MHz you'd know the channels
> that are being queried that fit into those rules would not allow HT40,
> so you set a NO_HT40 flag on the channel.

Yeah, that works, but still seems like a rather complex thing to do, and
doesn't really address the problem of overlap in other areas. It's not
just HT40 that makes trouble there -- it is mostly HT40 _now_ because of
the way most rules were derived originally though.

> > Anyhow, yes, there are different ways to implement this, but then it
> > seems we'd need more regulatory flags, and I don't see a reason for that
> > given the information we have -- which is only a little quirky for JP
> > and KP.
> 
> Depends on what you mean by needing more regulatory flags. We would
> certainly not require more regulatory flags in the wireless-regdb or
> crda, nor to interpret them in the kernel. We would however need them
> for the 802.11 code to help cache the answer to these questions. We'd
> need the NO_HT40 flag to cache whether or not a regulatory rule's max
> bandwidth allows HT40 or not, then we could end up re-using the FAT
> above and FAT below flags to indicate NO_HT40MINUS and NO_HT40PLUS. So
> technically we wouldn't be adding any other flag other than a NO_HT40
> flag just to indicate the regulatory domain's HT40 preferences.

Yes, but I think that we should not put this into the flags but rather
into a new bitmask of "supported channel types" so we're in a way
future-proofing ourselves for 5/10/40 MHz channels at the same time. And
then we can also use these bits to disallow Ht40 operation on channels
48/52 -- but we need to take care to not do that bit in the regulatory
code.

In fact, it seems like we will eventually need per-channel-type flags;
imagine a Ht40+ channel where the secondary channel is above the
boundary for DFS requirement and the control channel is below -- in that
case we have different DFS requirements for that channel for 20 and 40
MHz operation.

> Something we should also take into consideration is the changes
> required to the wireless-regdb and what this would imply for users of
> kernel code which interpret it differently. This could potentially
> mean we'd then have to release two different wireless-regdb files per
> release but I think it'd be nice to avoid that if possible

Yeah -- but I just realised that we can actually detect this in the
kernel, if there is overlap then the user is using an old database, if
there isn't then it's ok to use the new interpretation rules.

> An alternative to this proposal is to clarify how overlapping
> regulatory rules should be considered (which is how it works anyway).

Indeed, that is possible too, but I fear that will just come back to
haunt us in the future as new possibilities for using various parts of
the system come up.

> Here's my take on it:
> 
> If you have overlapping rules you simply apply the first rule which
> fits your desired bandwidth and modulation type. Right now we only pay
> attention to the desired bandwidth, but we could add things like "OFMD
> required" and only return the first rule that allows OFDM for example
> for the given bandwidth.

That works too, but it seems that it would make rule matching a lot more
complicated, no? It also restricts the database use to 802.11 because it
requires the 802.11 channelisation for proper interpretation of the
database, which I think is undesirable.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [RFC] regulatory information interpretation rules

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 2496 bytes --]

On Sun, 2009-03-22 at 10:02 +0100, Johannes Berg wrote:
> Ok, so I'm thinking about the interpretation rules for the regulatory
> information. I even dreamt about this tonight, unfortunately...

[...]

> Now how should you interpret this? I'll propose the following
> interpretation rules (and show how you arrive at the required
> interpretation from above):
> 
>  1) MIN values are really something like MIN+, i.e. approaching the MIN
>     from above, that means that the value "2452 MHz" falls into the
>     first of the ranges, not the second [3]
> 
>  2) The entire band a channel occupies needs to be covered by (any
>     number of) contiguous rules.
> 
>  3) The MAXBW value specifies what maximum bandwidth a channel can use
>     which has its center frequency (!) falling into the given range.
> 
>  4) The FLAGS specify restrictions that any channel _overlapping_ the
>     given range has to operate under.
> 
> That is all. Now let me show how to interpret this.

Let me rewrite those rules, more formally.

Let's take an example regdomain with "n" rules:

country EX:
	(MIN_1 - MAX_1 @ BW_1), (MAXAG_1, TXPWR_1), FLAGS_1
	...
	(MIN_n - MAX_n @ BW_n), (MAXAG_n, TXPWR_n), FLAGS_n

And let's say we need to determine whether a channel, which
(disregarding modulation for a moment) is determined by its center
frequency and bandwidth:
	CHANNEL = (CENTER, BW)

Then the rules are as follows, now using the notation outlined here:
http://en.wikipedia.org/wiki/Interval_(mathematics)#Notations_for_intervals (I'd use latex notation if I knew everybody was familiar with it, you have to do with some words instead)

 0) (stated outside rules before) for all 1 <= k < n : MAX_k <= MIN_{k+1}
    [1]

 1) each rule in the regdomain covers the frequency range (MIN_1, MAX_1]
    [2]

 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   [3]

 4) This is easier to formulate algorithmically:
    USE_FLAGS = 0
    for k = 1 .. n
        if CENTER in (MIN_k, MAX_k]:
            USE_FLAGS |= FLAGS_k

johannes

[1] this says "no overlap" but also "must be sorted" which can be
    beneficial
[2] this is a useless rule given the way I formulated rules 3 and 4, but
    it helps think about how it works
[3] given rule 0) the if only matches (at most) once


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [RFC] regulatory information interpretation rules

[Luis R. Rodriguez]

On Thu, Mar 26, 2009 at 3:57 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Sun, 2009-03-22 at 10:02 +0100, Johannes Berg wrote:
>> Ok, so I'm thinking about the interpretation rules for the regulator=
y
>> information. I even dreamt about this tonight, unfortunately...
>
> [...]
>
>> Now how should you interpret this? I'll propose the following
>> interpretation rules (and show how you arrive at the required
>> interpretation from above):
>>
>> =C2=A01) MIN values are really something like MIN+, i.e. approaching=
 the MIN
>> =C2=A0 =C2=A0 from above, that means that the value "2452 MHz" falls=
 into the
>> =C2=A0 =C2=A0 first of the ranges, not the second [3]
>>
>> =C2=A02) The entire band a channel occupies needs to be covered by (=
any
>> =C2=A0 =C2=A0 number of) contiguous rules.
>>
>> =C2=A03) The MAXBW value specifies what maximum bandwidth a channel =
can use
>> =C2=A0 =C2=A0 which has its center frequency (!) falling into the gi=
ven range.
>>
>> =C2=A04) The FLAGS specify restrictions that any channel _overlappin=
g_ the
>> =C2=A0 =C2=A0 given range has to operate under.
>>
>> That is all. Now let me show how to interpret this.
>
> Let me rewrite those rules, more formally.
>
> Let's take an example regdomain with "n" rules:
>
> country EX:
> =C2=A0 =C2=A0 =C2=A0 =C2=A0(MIN_1 - MAX_1 @ BW_1), (MAXAG_1, TXPWR_1)=
, FLAGS_1
> =C2=A0 =C2=A0 =C2=A0 =C2=A0...
> =C2=A0 =C2=A0 =C2=A0 =C2=A0(MIN_n - MAX_n @ BW_n), (MAXAG_n, TXPWR_n)=
, FLAGS_n
>
> And let's say we need to determine whether a channel, which
> (disregarding modulation for a moment) is determined by its center
> frequency and bandwidth:
> =C2=A0 =C2=A0 =C2=A0 =C2=A0CHANNEL =3D (CENTER, BW)
>
> Then the rules are as follows, now using the notation outlined here:
> http://en.wikipedia.org/wiki/Interval_(mathematics)#Notations_for_int=
ervals (I'd use latex notation if I knew everybody was familiar with it=
, you have to do with some words instead)
>
> =C2=A00) (stated outside rules before) for all 1 <=3D k < n : MAX_k <=
=3D MIN_{k+1}
> =C2=A0 =C2=A0[1]
>
> =C2=A01) each rule in the regdomain covers the frequency range (MIN_1=
, MAX_1]
> =C2=A0 =C2=A0[2]
>
> =C2=A02) given C =3D union (over all k =3D 1 .. n) of (MIN_k, MAX_k] =
it must be
> =C2=A0 =C2=A0true that (CENTER - BW/2, CENTER + BW/2) is a subset of =
C
>
> =C2=A03) it must be true for all 1 <=3D k <=3D n:
> =C2=A0 =C2=A0 =C2=A0 =C2=A0if CENTER in (MIN_k, MAX_k] : BW <=3D BW_k=
 =C2=A0 [3]
>
> =C2=A04) This is easier to formulate algorithmically:
> =C2=A0 =C2=A0USE_FLAGS =3D 0
> =C2=A0 =C2=A0for k =3D 1 .. n
> =C2=A0 =C2=A0 =C2=A0 =C2=A0if CENTER in (MIN_k, MAX_k]:
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0USE_FLAGS |=3D FLAGS_k
>
> johannes
>
> [1] this says "no overlap" but also "must be sorted" which can be
> =C2=A0 =C2=A0beneficial
> [2] this is a useless rule given the way I formulated rules 3 and 4, =
but
> =C2=A0 =C2=A0it helps think about how it works
> [3] given rule 0) the if only matches (at most) once

This helps a lot :), looks good to me! If anyone has a case where
overlapping regulatory rules _should_ exist now would be a great time
to give an example. Otherwise they go away.

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] regulatory information interpretation rules

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1177 bytes --]

On Sun, 2009-03-22 at 10:02 +0100, Johannes Berg wrote:
> Ok, so I'm thinking about the interpretation rules for the regulatory
> information. I even dreamt about this tonight, unfortunately...

The posting about the German rules made me look at them again and I
realised that there's no way (with either interpretation of the rules)
we can currently handle the German requirement of using only
0.25mW/25kHz, 10mW/MHz or 50mW/MHz.

Previously we had only thought about 20 MHz (or above) channels so that
wasn't a restriction (since you then reach the max EIRP permitted), but
with smaller bandwidths that does become a limit, a 5 MHz channel can
only have a max EIRP of 50mW, 50mW or 250mW respectively.

Should we incorporate that into regdb while we're changing things there
anyway? I'd add an optional field into the database like this:
	(5150 - 5250 @ 40), (N/A, 200mW, 0.25 mW / 25 kHz), ...
                                       ^^^^^^^^^^^^^^^^^^ optional

and extend netlink with it as well -- this requires a regdb version
change but not a netlink protocol change (except for the addition of the
new limit).

Does that make sense?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [RFC] regulatory information interpretation rules

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 553 bytes --]

On Thu, 2009-03-26 at 11:57 +0100, Johannes Berg wrote:

>  4) This is easier to formulate algorithmically:
>     USE_FLAGS = 0
>     for k = 1 .. n
>         if CENTER in (MIN_k, MAX_k]:
>             USE_FLAGS |= FLAGS_k

That wasn't what I intended... What I did intend to say is this:

USE_FLAGS = 0
for k = 1 .. n
    if (CENTER - BW/2, CENTER + BW/2) intersects (MIN_k, MAX_k]
        USE_FLAGS |= FLAGS_k

since we want to take into account all flags even if the channel just
overlaps a little with a specific range.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]