[Prism54-devel] Re: RFC: more finegrained configuration of 11b/11g rates and modulations
Thu Jul 29 01:08:58 PDT 2004
On Thursday 29 July 2004 06:22, Jouni Malinen wrote:
> On Thu, Jul 29, 2004 at 01:23:22AM +0300, Denis Vlasenko wrote:
> > The proposal is to use ASCII formatted private ioctl:
> > iwpriv <iface> set_rate "1,2,5,11 11p,24d"
> I sure hope the parser for this does not end up being implemented in
> each driver separately.. This should probably get at least some
> processing in user space (e.g., iwconfig), even though this would be
> somehwat difficult for the wildcard cases if they are "all supported (by
> hw) rates".
In my opinion that this string should be parsed in kernel.
Try to propose binary interface that will cover all existing
and near future wireless rates and all modulations.
> > 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).
> This may not be enough for all rates. It looks like it would give unique
> values for current standard and amendments, although 10 MHz rates in
> IEEE 802.11j were close to generating duplicates.. I would recommend
I don't know what is 11j. Something in 10 GHz band or
narrower channels for 11a? I'll google for it.
Anyway, private set_rate ioctl is not meant to be able to
specify 11g and 11a rates at the same time, since AFAIK
you cannot operate a STA<->AP link which works *simultaneously*
in 11g and 11a.
It is expected that one selects 11b/g, 11a or that
mysterious (to me) 11j mode with some other method.
After that, "24,48,54" rate spec will mean
"use _11g_ 24M,48M,54M with ofdm" or
"use _11a_ 24M,48M,54M with ofdm".
> using array of binary numbers in a way that is able to represent at
> least all rates described in IEEE 802.11 MIB (126 rates as an octet
> string with increments of 500 Kbps from 1 Mbs to 63.5 Mbps).
> However, if we want to keep prorietary extensions in mind, this should
> not be limited to 127 * 0.5 Mbps.. In addition, some other extensions
> use rate less than 1 Mbps, so this would not actually cover all
> currently available hardware if that is a goal here..
ASCII allows us to specify even 3456734569374865 Mbit/s without
> Calling 6..54 Mbps rates g-rates is somewhat odd taken into account that
> IEEE 802.11a introduced these four years before IEEE 802.11g.. 'a' for
> all rates is asking for trouble when we have 802.11a...
'a' and 'g' rate specifiers may be not worth the trouble in fact,
I am thinking about dropping them.
> > 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...
> IEEE 802.11g is over six months old, si it's available from
> Get IEEE 802..
Thanks for URL.
> In addition, you should add IEEE 802.11j to things to consider since it
> adds "half-rates" for 10 MHz channels..
More information about the Hostap