On Sun, Mar 22, 2009 at 2:02 AM, Johannes Berg
<johannes@xxxxxxxxxxxxxxxx> 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:
> (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]
I rather be more exact. Can you elaborate a little more on this?
> 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,
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
> 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?
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.
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.
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-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
