Re: [RFC] RCPI support in radiotap and in our wireless subsystems

Re: [RFC] RCPI support in radiotap and in our wireless subsystems

[Ivo van Doorn]

Hi.

> ---
> 
> For ipw2200:
> 
> s8 antsignal = frame->rssi_dbm - IPW_RSSI_TO_DBM;
> 
> and IPW_RSSI_TO_DBM is set to 112.
> 
> Is antsignal above the "measure by the PHY sublayer of the received RF
> power in the channel measured over the entire received frame"?

For completeness, the rt2x00 & RSSI:

rt2400pci, rt2500pci, rt2500usb:
Same as ipw2200 only the IPW_RSSI_TO_DBM varies from 100 to 120 (as
hardcoded value in the register) to a unsigned char value read from
the EEPROM. The legacy drivers _suggest_ this is the rssi...

rt61pci, rt73usb:
The device reports an agc value, this is used as basis for a vague calculation
to determine the RSSI_TO_DBM offset based on LNA and current operating band.
Here too, the legacy driver suggests this is the rssi...

Ivo

Re: [RFC] RCPI support in radiotap and in our wireless subsystems

[bruno randolf]

On Friday 07 March 2008 05:38:45 Luis R. Rodriguez wrote:
> I've been reviewing use or RSSI value, signal strength and noise on
> several Linux drivers, namely MadWifi, ath5k, ipw2200 and b43, and how
> these are populated using radiotap headers. It quickly became clear we
> should probably abandon RSSI's use in radiotap and slowly move to
> using RCPI [1] for both radiotap and for later use on our wireless
> subsystems. Reasons for doing so is:

i think it's worth the effort to try to clean up this mess and get some 
standardisation between the devices as far as possible but i'm afraid we are 
at the mercy of the values the hardware gives us and the information we get 
from hardware vendors about the meaning of these values.

> a. Currently Radiotap's definition and use of
> IEEE80211_RADIOTAP_DB_ANTSIGNAL and IEEE80211_RADIOTAP_DBM_ANTSIGNAL
> is not so clear

i think it's quite clear, except that it does not state when this signal is 
supposed to be measured.

if all devices could use this in the same way that would already be great!

> For Atheros hardware:
>
> RSSI is defined to be equivalent to the Signal To Noise (SNR) [3] and
>
> SNR = Signal - Noise
>
> Now, this is great, however the next question is what Signal is and
> what Noise is. Is Signal or SNR here the "measure by the PHY sublayer
> of the received RF power in the channel measured over the entire
> received frame"?

no, according to the information we have from madwifi it is not:

/*
 * rx_rssi is in units of dbm above the noise floor.  This value
 * is measured during the preamble and PLCP; i.e. with the initial
 * 4us of detection.
 */
(this is copied from a comment in hal/ah_desc.h)

> So I propose IEEE80211_RADIOTAP_RCPI, defined as above, and hopefully
> we can start figuring out what exactly RSSI values are in the
> different cards we support to compute this. Comments?

it's good to extend radiotap to include this possibility, but at least for 
atheros hardware we know we can't supply this value (unless newer devices 
allow us to get a RCPI value somehow, but we probably would need atheros 
support to know that).

it would already be an important step to better define the variables inside 
mac80211, so drivers can report what they support (and mac80211 can make the 
translations to the weird values iwconfig uses).

right now the variable names inside mac80211 are really ambigous and not very 
well defined. in struct ieee80211_rx_status we have:

 * @ssi: signal strength when receiving this frame
 * @signal: used as 'qual' in statistics reporting
 * @noise: PHY noise when receiving this frame

it could be changed to something like:

 * @signal: signal strength in dBm above noise or RCPI according to flag
 * @noise: PHY noise in dBm when receiving this frame
 (remove ssi)

bruno

Re: [RFC] RCPI support in radiotap and in our wireless subsystems

[Luis R. Rodriguez]

On Thu, Mar 6, 2008 at 7:32 PM, bruno randolf <bruno-L9ZBdB2wSWtl57MIdRCFDg@public.gmane.org> wrote:
> On Friday 07 March 2008 05:38:45 Luis R. Rodriguez wrote:
>  > I've been reviewing use or RSSI value, signal strength and noise on
>  > several Linux drivers, namely MadWifi, ath5k, ipw2200 and b43, and how
>  > these are populated using radiotap headers. It quickly became clear we
>  > should probably abandon RSSI's use in radiotap and slowly move to
>  > using RCPI [1] for both radiotap and for later use on our wireless
>  > subsystems. Reasons for doing so is:
>
>  i think it's worth the effort to try to clean up this mess and get some
>  standardisation between the devices as far as possible but i'm afraid we are
>  at the mercy of the values the hardware gives us and the information we get
>  from hardware vendors about the meaning of these values.

Unfortunately, yeap.

>  > a. Currently Radiotap's definition and use of
>  > IEEE80211_RADIOTAP_DB_ANTSIGNAL and IEEE80211_RADIOTAP_DBM_ANTSIGNAL
>  > is not so clear
>
>  i think it's quite clear, except that it does not state when this signal is
>  supposed to be measured.

Precisely --  the lack of clarity on time of measurement is what I
don't think makes it clear. Without that being clear I'm afraid every
driver for each Operating System may have interpreted that to their
own meaning. Because we only have so much data available from wireless
hardware though and RSSI is usually exposed because its part of the
802.11 Service Parameter Lists my guess is that DB_ANTISIGNAL is
usually set to the hardware's RSSI (whatever that value may mean) and
DBM_ANTSIGNAL is usually set to the a converted factor *when
understood* to get a "dBm" value.

To better define IEEE80211_RADIOTAP_DB_ANTSIGNAL and
IEEE80211_RADIOTAP_DBM_ANTSIGNAL what I think we need is a better
understanding of what vendors tend to use for RSSI value and when they
compute it. We can then clarify the definition to match practice.

>  if all devices could use this in the same way that would already be great!
>
>
>  > For Atheros hardware:
>  >
>  > RSSI is defined to be equivalent to the Signal To Noise (SNR) [3] and
>  >
>  > SNR = Signal - Noise
>  >
>  > Now, this is great, however the next question is what Signal is and
>  > what Noise is. Is Signal or SNR here the "measure by the PHY sublayer
>  > of the received RF power in the channel measured over the entire
>  > received frame"?
>
>  no, according to the information we have from madwifi it is not:
>
>  /*
>   * rx_rssi is in units of dbm above the noise floor.  This value
>   * is measured during the preamble and PLCP; i.e. with the initial
>   * 4us of detection.
>   */
>  (this is copied from a comment in hal/ah_desc.h)

Nice, thanks for pointing that out! I wonder if this can be tweaked :)

>  > So I propose IEEE80211_RADIOTAP_RCPI, defined as above, and hopefully
>  > we can start figuring out what exactly RSSI values are in the
>  > different cards we support to compute this. Comments?
>
>  it's good to extend radiotap to include this possibility, but at least for
>  atheros hardware we know we can't supply this value (unless newer devices
>  allow us to get a RCPI value somehow, but we probably would need atheros
>  support to know that).

You're right.

>  it would already be an important step to better define the variables inside
>  mac80211, so drivers can report what they support (and mac80211 can make the
>  translations to the weird values iwconfig uses).

Agreed.

>  right now the variable names inside mac80211 are really ambigous and not very
>  well defined. in struct ieee80211_rx_status we have:
>
>   * @ssi: signal strength when receiving this frame

Right, ath5k sets this to RSSI + noise:

                /* signal level in dBm */
                rxs.ssi = rxs.noise + ds->ds_rxstat.rs_rssi;

b43 sets this to:

       status.ssi = b43_rssi_postprocess(dev, jssi,
                                         (phystat0 & B43_RX_PHYST0_OFDM),
                                         (phystat0 & B43_RX_PHYST0_GAINCTL),
                                         (phystat3 & B43_RX_PHYST3_TRSTATE));

>   * @signal: used as 'qual' in statistics reporting

ath5k sets this to:

                /*
                 * "signal" is actually displayed as Link Quality by iwconfig
                 * we provide a percentage based on rssi (assuming max rssi 64)
                 */
                rxs.signal = ds->ds_rxstat.rs_rssi * 100 / 64;


>   * @noise: PHY noise when receiving this frame

ath5k sets this to the noise floor we get through noise floor
calibration. There's a patent behind how this is computed but I think
it may be during SIFS. Not too sure though.

>  it could be changed to something like:
>
>   * @signal: signal strength in dBm above noise or RCPI according to flag

As it stands I don't think all drivers could populate this field under
that description. For example, ssi in b43 is set to some magical value
we have no clue what it means.

We *could* test this stuff and see if it matches RCPI for each device,
or just try to figure out at least what RSSI is wrt to the observed
signal through a spectrum analyser (and even jssi is for b43) but I
wonder how this will change upon hw revisions.

>   * @noise: PHY noise in dBm when receiving this frame
>   (remove ssi)

Again, the problem in clarifying this also puts a restriction on what
driver developers may know about their hardware.

Ah!

  Luis

Re: [RFC] RCPI support in radiotap and in our wireless subsystems

[bruno randolf]

On Friday 07 March 2008 12:04:24 Luis R. Rodriguez wrote:
> >  it could be changed to something like:
> >
> >   * @signal: signal strength in dBm above noise or RCPI according to flag
>
> As it stands I don't think all drivers could populate this field under
> that description. For example, ssi in b43 is set to some magical value
> we have no clue what it means.
>
> We *could* test this stuff and see if it matches RCPI for each device,
> or just try to figure out at least what RSSI is wrt to the observed
> signal through a spectrum analyser (and even jssi is for b43) but I
> wonder how this will change upon hw revisions.
>
> >   * @noise: PHY noise in dBm when receiving this frame
> >   (remove ssi)
>
> Again, the problem in clarifying this also puts a restriction on what
> driver developers may know about their hardware.

yes, but you suggested RCPI which is even more difficult to deliver. well - i 
don't know *any* device which could...

ok. what about 3 hw flags then?

something like:
_SIGNAL_RSSI_UNITLESS
_SIGNAL_RSSI_DBM
_SIGNAL_RCPI

so mac80211 can fill in the right radiotap headers, and drivers can make it 
clear what they support. it's clear that drivers should strive to deliver the 
most exact when they can.

we have the same problem with the rx timestamp. we made a definition and ath5k 
for example can't deliver. but i think a clear definition and a clear note 
where it cannot be delivered is better than no definition at all :)

bruno

Re: [RFC] RCPI support in radiotap and in our wireless subsystems

[Luis R. Rodriguez]

On Fri, Mar 7, 2008 at 3:57 AM, bruno randolf <bruno-L9ZBdB2wSWtl57MIdRCFDg@public.gmane.org> wrote:
> On Friday 07 March 2008 12:04:24 Luis R. Rodriguez wrote:
>  > >  it could be changed to something like:
>  > >
>  > >   * @signal: signal strength in dBm above noise or RCPI according to flag
>  >
>  > As it stands I don't think all drivers could populate this field under
>  > that description. For example, ssi in b43 is set to some magical value
>  > we have no clue what it means.
>  >
>  > We *could* test this stuff and see if it matches RCPI for each device,
>  > or just try to figure out at least what RSSI is wrt to the observed
>  > signal through a spectrum analyser (and even jssi is for b43) but I
>  > wonder how this will change upon hw revisions.
>  >
>  > >   * @noise: PHY noise in dBm when receiving this frame
>  > >   (remove ssi)
>  >
>  > Again, the problem in clarifying this also puts a restriction on what
>  > driver developers may know about their hardware.
>
>  yes, but you suggested RCPI which is even more difficult to deliver. well - i
>  don't know *any* device which could...

Well I was hoping we could see if we *could* deliver it, at least
within Atheros hardware but from what you tell me we can't. And from
what I gather from a few other wireless cards we can't either. The
idea was to propose it for radiotap but I do think its pointless if we
don't have hardware yet which we can produce those results.

>  ok. what about 3 hw flags then?
>
>  something like:
>  _SIGNAL_RSSI_UNITLESS
>  _SIGNAL_RSSI_DBM
>  _SIGNAL_RCPI

Seems reasonable.

>  so mac80211 can fill in the right radiotap headers, and drivers can make it
>  clear what they support. it's clear that drivers should strive to deliver the
>  most exact when they can.

Sounds good!

So having IEEE80211_RADIOTAP_DBM_ANTSIGNAL is preferable than
IEEE80211_RADIOTAP_DB_ANTSIGNAL in drivers, for obvious reasons. I'll
deal with another question with respect to mac80211 in another e-mail.

>  we have the same problem with the rx timestamp. we made a definition and ath5k
>  for example can't deliver. but i think a clear definition and a clear note
>  where it cannot be delivered is better than no definition at all :)

Sure, we have to take into consideration what other drivers can deliver as well.

  Luis

[RFC] RCPI support in radiotap and in our wireless subsystems

[Luis R. Rodriguez]

I've been reviewing use or RSSI value, signal strength and noise on
several Linux drivers, namely MadWifi, ath5k, ipw2200 and b43, and how
these are populated using radiotap headers. It quickly became clear we
should probably abandon RSSI's use in radiotap and slowly move to
using RCPI [1] for both radiotap and for later use on our wireless
subsystems. Reasons for doing so is:

a. Currently Radiotap's definition and use of
IEEE80211_RADIOTAP_DB_ANTSIGNAL and IEEE80211_RADIOTAP_DBM_ANTSIGNAL
is not so clear and it seems different drivers set it to different
values. MadWifi uses DB_ANTSIGNAL for RSSI, ath5k uses DB_ANTSIGNAL as
RSSI + noise, ipw2200 doesn't set it despite it having a value which
can be used for it. The b43 driver, although like ath5k is a mac80211
driver, uses DB_ANTSIGNAL as:

        status.ssi = b43_rssi_postprocess(dev, jssi,
                                          (phystat0 & B43_RX_PHYST0_OFDM),
                                          (phystat0 & B43_RX_PHYST0_GAINCTL),
                                          (phystat3 & B43_RX_PHYST3_TRSTATE));

We have no clue what jssi is, nor what this yields, yet we use it.

b. For roaming purposes we need to standardize on a value so that the
upper layers can reliably count on for signal strength and I believe
RCPI was defined for just that purpose

c. For strong subsystem rate control algorithms we need to count on
reliable signal strength values. Right now mac80211's PID rate control
algorithm [2] doesn't make use of signal strength, it just uses
non-acked frames and re-transmission counters. I would think using
signal strength here might help somehow.

However, to support RCPI it seems you need to rely on a way to
accurately compute signal strength, but more accurately "received RF
power in the selected channel for a received frame. This parameter
shall be a measure by the PHY sublayer of the received RF power in the
channel measured over the entire received frame or by other equivalent
means which meet the specified accuracy". I've tried reviewing RSSI
value for a few hardware out there to see if we can easily start
adding support for this in our drivers but I am not confident in the
exact value that RSSI represents as it varies on hardware and there is
an obvious the lack of documentation in that area.

---

For Atheros hardware:

RSSI is defined to be equivalent to the Signal To Noise (SNR) [3] and

SNR = Signal - Noise

Now, this is great, however the next question is what Signal is and
what Noise is. Is Signal or SNR here the "measure by the PHY sublayer
of the received RF power in the channel measured over the entire
received frame"? Noise is computed upon noise calibration time, and I
think its computed during SIFS time, but I haven't yet finished
reading the patent that describes this stuff yet [4] so not too sure.
I guess its not important as long as we can rely on the value.

---

For ipw2200:

s8 antsignal = frame->rssi_dbm - IPW_RSSI_TO_DBM;

and IPW_RSSI_TO_DBM is set to 112.

Is antsignal above the "measure by the PHY sublayer of the received RF
power in the channel measured over the entire received frame"?

----

For Broadcom:

We have something called jssi and then get what we think is an RSSI
value. We don't know what either of them are.

        status.ssi = b43_rssi_postprocess(dev, jssi,
                                          (phystat0 & B43_RX_PHYST0_OFDM),
                                          (phystat0 & B43_RX_PHYST0_GAINCTL),
                                          (phystat3 & B43_RX_PHYST3_TRSTATE));

---

At least RCPI seems to be well defined, and I think we can add it to
radiotap for those drivers that can reliably compute this value.

Quoting from Simon's post:

"The allowed values for the Received Channel Power Indicator (RCPI) parameter
shall be an 8 bit value in the range from 0 through 220, with indicated
values rounded to the nearest 0.5 dB as follows:

0: Power < -110 dBm
1: Power = -109.5 dBm
2: Power = -109.0 dBm

and so on where

RCPI = int{(Power in dBm +110)*2} for 0dbm > Power > -110dBm

220: Power > -0 dBm
221-254: reserved
255: Measurement not available

RCPI shall equal the received RF power within an accuracy of +/-5 dB
(95% confidence interval) within the specified dynamic range of the
receiver. The received RF power shall be determined assuming a receiver
noise equivalent bandwidth equal to the channel bandwidth multiplied by
1.1."

So I propose IEEE80211_RADIOTAP_RCPI, defined as above, and hopefully
we can start figuring out what exactly RSSI values are in the
different cards we support to compute this. Comments?

  Luis

[1] http://www.mail-archive.com/netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org/msg19487.html
[2] http://linuxwireless.org/en/developers/Documentation/mac80211/RateControl/PID
[3] http://madwifi.org/wiki/UserDocs/RSSI
[4] http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.htm&r=1&f=G&l=50&s1=7245893.PN.&OS=PN/7