RFC: more finegrained configuration of 11b/11g rates and modulations
Wed Jul 28 15:52:09 PDT 2004
On Thu, Jul 29, 2004 at 01:23:22AM +0300, Denis Vlasenko wrote:
> Hi all,
> I am going to do some unification work on rate support for
> 11b/11g, immediately targeting acx111, prism54 and possibly
> The proposal is to use ASCII formatted private ioctl:
> iwpriv <iface> set_rate "1,2,5,11 11p,24d"
> Syntax is: two space delimited lists.
> First one defines basic rate set, second one
> lists additional usable rates and is optional.
> I'll call 6,9,12,18,24,36,48,54Mbit/s data rates
> defined in 11g and 11a standards 'g-rates'
> Syntax of lists: either comma separated list of
> rates in Mbit/s, rounded down to integer value
> (translation: 5 == 5.5Mbit/s), a single entry 'a'
> (means 'all rates'), or 'g' == g-rates only
> (rationale: too many of them to list individually).
> All variants can be optionally suffixed by modulation.
> Currently valid suffixes are:
> c: cck
> d: cckofdm
> o: ofdm
> p: pbcc
> more will be added as new standards emerge.
> When suffix is omitted, defaults to "natural" modulation
> for given rate. Here are default and currently
> allowed alternative modulations, default is listed first:
> 1,2:(no suffixes allowed)
> 5:cck pbcc
> 11:cck pbcc
> g-rates:ofdm cckofdm
> Driver must refuse ioctl if it cannot satisfy it precisely.
> iwpriv wlan0 set_rate 11
> fixed rate, 11Mbit/s (cck) basic rate
> iwpriv wlan0 set_rate 22
> fixed rate, 22Mbit/s (pbcc) basic rate
> iwpriv wlan0 set_rate 5,11
> auto rate, both 5.5 and 11Mbit/s (cck) are basic rates
> iwpriv wlan0 set_rate "5 11,22"
> auto rate, 5.5 is basic rate, 11 (cck) and 22(pbcc) extended rates
> iwpriv wlan0 set_rate "5 11p,22"
> auto rate, 5.5 is basic rate, 11 (pbcc) and 22(pbcc) extended rates
> iwpriv wlan0 set_rate "1,2,5,11 ao"
> auto rate, 1,2,5.5,11 are basic, everything else
> are extended rates, using ofdm
> iwpriv wlan0 set_rate "6 g"
> 6 (ofdm) basic rate, g-rates (ofdm) extended
> it is an '11g-only' setup: use only g-rates with ofdm,
> will interfere with 11b equipment
> iwpriv wlan0 set_rate "6d gd"
> 6 (cckofdm) basic rate, g-rates (cckofdm) extended
> '11g 11b-compatible' setup: use only g-rates with cckofdm,
> 11b stations in the area can detect signal and avoid collisions
> (am I right here?)
> That's it.
> I have test code for parser. It contains common code and
> example prism54 and acx111 implementations (#ifdef'ed out).
> You can compile attached file, run it, type in test string
> and see resulting translation into prism54-compatible
> basic/extended rates oid data.
> acx111 testing is not done yet.
> I solicit comments on:
> * use space or a semicolon as basic/extended rates separator?
> * do we need suffixes for 1 and 2 Mbit?
> * will one-letter suffixes suffice?
> * are 11g/11a defaults ok?
> * are 'a' and 'g' pseudo-rates ok?
> * is last example's comment right?
> * other comments?
> P.S. if you happen to have 11g documents, can you
> mail them to me? I need to look closer on 11g/11b
> rates and modulations compatibility...
My first comment is that I would prefer to protect the dumb
users to have to mess up with all this complex stuff. Of course, it's
desirable to have that in an Access Point, but I believe a client card
should be smart enough to figure out what to use.
My personal goal is to keep the main API simple. Of course,
you are free to do whatever you want in iwpriv.
Second comment is that not all hardware will allow this much
flexibility and won't support all rate. I don't know how you will deal
with that. You may need a command to export "capabilities" so that the
user/app know how to create a string that can work.
Third comment is that I believe it's better to keep text
parsers out of the kernel for various reasons, especially that this
one is not totaly trivial. If you want, we could include the text
parser in iwpriv.c (similar to roam/port).
But, don't let my comment influence too much your work ;-)
More information about the Hostap