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:
signature.asc
Description: This is a digitally signed message part
