Date: Fri, 4 Feb 2005 21:27:44 -0800
From: Jouni Malinen <jkmaline@cc.hut.fi>
To: Dan Williams <dcbw@redhat.com>
Cc: jt@hpl.hp.com, netdev@oss.sgi.com
Subject: Re: WEXT quality specification
Message-ID: <20050205052744.GD9685@jm.kir.nu>
References: <Pine.LNX.4.58.0502042136060.1614@devserv.devel.redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.58.0502042136060.1614@devserv.devel.redhat.com>
User-Agent: Mutt/1.5.6i
Sender: netdev-bounce@oss.sgi.com
Errors-to: netdev-bounce@oss.sgi.com
Precedence: bulk
Content-Length: 4794
Lines: 94

On Fri, Feb 04, 2005 at 09:45:55PM -0500, Dan Williams wrote:

> I've taken the liberty of whipping up a long-winded patch to wireless.17.h in an 
> attempt to concretely specify what drivers need to do for quality.

Nice to see more documentation on this area. I would consider moving
this to somewhere else or adding a separate document
(Documentation/networking/wireless/... ?) though, since I would hope to
eventually see detailed (and in practice, quite long) explanation for
all areas of the wireless extensions, not just signal quality. Comments
in C header files may not be the nicest format for editing such
specification..

> + * Explanation of WIRELESS QUALITY

Maybe change that to wireless signal quality?

> + * Wireless quality is may be measured in two methods, drivers must PICK ONE
> + * and use it consistently throughout the driver->userspace API:

Unfortunately, this may not be possible with some (well, maybe even
most) hardware models. It is quite common to configure TX power in dBm
and report signal strength for received frames in RSSI. Even if this
part is left out and this is only about signal strength/quality of
received frames, some cards have different mechanism for reporting
quality for 1) received packets, 2) current BSS (average), 3) scan
results. Another common example is in reporting received signal strength
in RSSI and noise level in dBm.

> + * 2) The second measure is decibel millivolts, or dBm.  This is calculated from

milliwatts (i.e., power, not potential)

> + * the RSSI of each packet based on lookup tables or conversion constants
> + * specified by each manufacturer.  dBm is an absolute measurement of electrical
> + * power generated by the radio signals in the receive circuitry of the card.
> + * It is expressed in _negative_ numbers, where 0dBm = 1mV.  The upper bound

1 mW

> + * is _always_ 0, and the lower bound is determined by the receiver sensitivity

When setting TX power, these numbers are (in most cases) positive, e.g.,
16 dBm. Again, this could be considered to be outside the scope of this
description, but should be kept in mind for other parts of wireless
extensions. Another example would be non-802.11 wireless device that
could potentially receive signals with higher power than 0 dBm..

> + * The 'qual' fields are method independent, and are specified as follows:
> + *
> + * max_qual.qual:   (range is 0 -> 255) upper bound of subjective quality
> + *                  levels.  Other .qual fields MUST be less than this number.
> + *
> + * qual.qual:       (range is 0 -> max_qual.qual) Quality of the received packet
> + *                  as determined by the driver.  The only restriction is that
> + *                  user applications MUST be able to derive a percentage value
> + *                  by doing the following calculation:
> + *                          percent =  100 * (qual.qual / max_qual.qual)
> + *                  Drivers may factor other statistics, such as receive packet
> + *                  errors, # collisions, noise levels, etc, into the value.

Is this restriction to linear value ok? Many other values are in
logarithmic scale. What does this "percentage" really mean and what is
it used for? The current wireless.h defines quality as percentage of
retries or missed beacons, or SNR..

> + * Once a driver has PICKED ONE method of measurement, the quality fields must
> + * be filled as follows.  Remember, all fields are 8-bits wide and are treated
> + * as signed or unsigned based on the method of quality measurement above.
> + *
> + *
> + * RSSI METHOD (set max_qual.level > 0 as explained below)
> + *--------------------------------------------------------
> + * max_qual.level:  (range is 1 -> 255) upper bound of the RSSI of any received
> + *                  packet, determined by the card's hardware.  Usually
> + *                  specified in technical literature from manufacturer, or
> + *                  provided by registers on the card.
> + *                    NOTE: to specify that values are in RSSI, max_qual.level
> + *                          MUST be larger than 0.

So, if the hardware reports RSSI in 0..70, both values 0 and 1 should be
stored as 1? Actually, I've seen one hardware where reported RSSI values
are dropping below zero every now and then..

> + * max_qual.noise:  (range is 0 -> 255) lower bound of noise, ie the received

Why is there a different range for noise? Is only max_qual.level used to
select the RSSI/dBm method and this max_qual.noise would be, e.g., the
current noise floor (which, btw, is often presented in dBm, not RSSI).
Is this a new mechanism for reporting noise floor? I don't remember
seeing this kind of definition before.

-- 
Jouni Malinen                                            PGP id EFC895FA