So, which IEEE<->Frequency mappings should we be all using?

So, which IEEE<->Frequency mappings should we be all using?

[Adrian Chadd]

Hi all,

I've been increasingly asked to bring up FreeBSD on "other" bands.

* 420MHz
* 700MHz
* 900MHz (which we already have, due to history);
* 3.6GHz
* 4.9GHz

I'd also like to support half and quarter width channels on these
frequencies. If I use the 2GHz channel mapping method, I end up with a
very restricted channel set and it definitely has no "gaps" for
5/10MHz increments.

Now, what I'd like to do is figure out some sane, shared method of
translating channel frequencies to IEEE numbers and back. That way the
BSDs and Linux (and maybe commercial stacks; I dunno what they do) can
have some sane chance of interoperating.

So: Is there some standardised or semi-standardised channel mapping
method? Or should we invent one?


-adrian

RE: So, which IEEE<->Frequency mappings should we be all using?

[Wright, Brett]

> -----Original Message-----
> From: owner-freebsd-wireless@freebsd.org [mailto:owner-freebsd-
> wireless@freebsd.org] On Behalf Of Adrian Chadd
> Sent: Thursday, 18 July 2013 3:42 AM
> To: freebsd-wireless@freebsd.org; linux-wireless@vger.kernel.org
> Subject: So, which IEEE<->Frequency mappings should we be all using?
> 
> Hi all,
> 
> I've been increasingly asked to bring up FreeBSD on "other" bands.
> 
> * 420MHz
> * 700MHz
> * 900MHz (which we already have, due to history);
> * 3.6GHz
> * 4.9GHz
> 
> I'd also like to support half and quarter width channels on these
frequencies.
> If I use the 2GHz channel mapping method, I end up with a very
restricted
> channel set and it definitely has no "gaps" for 5/10MHz increments.
> 
> Now, what I'd like to do is figure out some sane, shared method of
> translating channel frequencies to IEEE numbers and back. That way the
BSDs
> and Linux (and maybe commercial stacks; I dunno what they do) can have
> some sane chance of interoperating.
> 
> So: Is there some standardised or semi-standardised channel mapping
> method? Or should we invent one?
> 
> 
> -adrian

Hi Adrian,

I wanted to make similar changes to madwifi some years ago, and as there
was no standard I invented one.
This likely won't align with your requirements, but share some details
below in case it may help.

The approach I took was that the ieee channel numbers should overlap for
the different frequency bands, as there are a huge number of different
channels once you include all bands + 5, 10, 20, (and maybe 40) channel
widths (not such a big deal since no manufacturers seem to offer a radio
that supports more than one of the lower frequency bands on one board).
This way the 20MHz channel numbers were unchanged for all bands (as they
report as 2.4GHz band anyway), and the 5 and 10 MHz widths I mapped
above channel 14 using mapgsm() and ath_hal_mhz2ieee(), plus other
additions like unmapgsm, etc.
To cut a long story short I ended up with channels 1-14 for 20MHz, 21-34
for 5MHz, and 41-54 for 10MHz.

Re: So, which IEEE<->Frequency mappings should we be all using?

[Johannes Berg]

On Wed, 2013-07-17 at 10:42 -0700, Adrian Chadd wrote:

> * 420MHz
> * 700MHz
> * 900MHz (which we already have, due to history);
> * 3.6GHz
> * 4.9GHz

3.6 should have been defined in the spec recently, 4.9 surely is defined
already (though the whole stack will have to support the
dot11ChannelStartingFactor)

The others are kinda non-standard extensions, and you probably won't
even be able to properly support them since they're kinda
pretend-handled like 2.4 GHz.

johannes

Re: So, which IEEE<->Frequency mappings should we be all using?

[Adrian Chadd]

Well, the UHF stuff is available now and vendors are making cards for
them. I'm happy just mapping them to 2.4GHz channels for now but it
severely restricts the channels (ie, spacing/width) we can use in that
range.



adrian

On 22 July 2013 07:40, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Wed, 2013-07-17 at 10:42 -0700, Adrian Chadd wrote:
>
>> * 420MHz
>> * 700MHz
>> * 900MHz (which we already have, due to history);
>> * 3.6GHz
>> * 4.9GHz
>
> 3.6 should have been defined in the spec recently, 4.9 surely is defined
> already (though the whole stack will have to support the
> dot11ChannelStartingFactor)
>
> The others are kinda non-standard extensions, and you probably won't
> even be able to properly support them since they're kinda
> pretend-handled like 2.4 GHz.
>
> johannes
>