WWAN signal strength is reported lower than android in same location

[Pat McGowan]

The signal indicator seems to be pessimistic wrt actual signal strength.
Review the current thresholds to be closer to other OS settings

[Ricardo Salveti (rsalveti)]

The forma to calculate the signal strength depends on the technology, and our ofono-rilmodem driver basically converts the ASU values to percentage (0-31, 99).

Here's how android calculates the signal bars (for GSM):
"""
   int asu = getGsmSignalStrength();
   if (asu <= 2 || asu == 99) level = SIGNAL_STRENGTH_NONE_OR_UNKNOWN;
   else if (asu >= 12) level = SIGNAL_STRENGTH_GREAT;
   else if (asu >= 8) level = SIGNAL_STRENGTH_GOOD;
   else if (asu >= 5) level = SIGNAL_STRENGTH_MODERATE;
   else level = SIGNAL_STRENGTH_POOR;
   if (DBG) log("getGsmLevel=" + level);
   return level;
"""

So in order to have a similar result, here's the range and bars based on the output from ofono (0-100%):
>= 38% - GREAT (4 bars)
25% <= x < 38% - GOOD (3 bars)
16% <= x < 25% - MODERATE (2 bars)
6% <= x < 16% - POOR (1 bar)
0% <= 6% - NONE or UNKNOWN

[Ricardo Salveti (rsalveti)]

* 6% < x < 16% - POOR (1 bar)

[Matthew Paul Thomas (mpt)]

AnandTech has comparison charts of how Android (2.2, at least) and iOS (4.0) map signal strength to bars.
<http://www.anandtech.com/show/3821/iphone-4-redux-analyzing-apples-ios-41-signal-fix>

I had assumed that if the signal is strong enough to connect to a carrier at all, it's strong enough for a phone call. Is that not the case? And if it isn't, do we know where the cutoff is?

[Antti Kaijanmäki (kaijanmaki)]

This should really be handled on ofono side as it's specific to a single modem tech.

Ofono reports the signal strength through org.ofono.NetworkRegistration Strength property:

Service org.ofono
Interface org.ofono.NetworkRegistration
Object path [variable prefix]/{modem0,modem1,...}

Properties byte Strength [readonly, optional]

                        Contains the current signal strength as a percentage
                        between 0-100 percent.

[Ricardo Salveti (rsalveti)]

This shouldn't be handled by ofono, and the tech specifics should also be handled by the client side, not ofono.

Percentage is not ideal, and not linear, but it was what was used by ofono initially (see https://lists.ofono.org/pipermail/ofono/2011-January/007827.html).

We could just change it to report asu values (what we get from the modem), but then the same logic applied bellow would need be used, just with different values.

The only think ofono does is converting ASU (as defined by TS 27.007 8.5) to percentage (x-100/31)

[Ricardo Salveti (rsalveti)]

Also check how this is handled by Android:
http://androidxref.com/4.4.2_r2/xref/frameworks/base/telephony/java/android/telephony/SignalStrength.java

[Antti Kaijanmäki (kaijanmaki)]

IMHO indicator-network should not accommodate for a specific technology, but instead the abstraction should be done as close to the HW as possible and therefore the natural place for that would be inside ofono modem driver.

Ofono is the abstractor of different modem HW and that abstraction also has to take care of dealing with modems reporting their signal strengths in arbitrary ways. Right now the only way of getting the signal strength from ofono API is the Strength property and that has been specified to be a percentage from 0 to 100 and indeed it's up to the particular modem driver to provide mapping of that percentage.

We have 5 different signal strength icons available so from indicator-network POV we split the percentage to 5 even ranges independently of specific modem technology:

>= 80% -> 4 bars
>= 60% -> 3 bars
>= 40% -> 2 bars
>= 20% -> 1 bar
< 20% -> 0 bars

[Tony Espy (awe)]

I also agree with Ricardo, ofono standardizes on the percentage that's used across all technologies. This is one of the downsides of having two abstraction layers ( RIL & ofono ). So fixing this in the ofono layer requires us to either break the API ( ie. use different semantics for strength reporting ) or add our own technology specific strength properties.

[Antti Kaijanmäki (kaijanmaki)]

I don't see how fixing this on ofono layer requires any changes; we only have to modify the mapping.

Android code itself defines 5 discrete strengths:
 - SIGNAL_STRENGTH_GREAT
 - SIGNAL_STRENGTH_GOOD
 - SIGNAL_STRENGTH_MODERATE
 - SIGNAL_STRENGTH_POOR
 - SIGNAL_STRENGTH_NONE_OR_UNKNOWN

We can map those (how ever they are calculated) to the linear and evenly distributed range of [0..100].

As an example:

   int asu = getGsmSignalStrength();

  // 0-20% - SIGNAL_STRENGTH_NONE_OR_UNKNOWN
  if (asu == 99)
    level = 0;
  else if (asu == 0)
    level = 6;
  else if (asu == 1)
    level = 12;
  else if (asu == 2)
    level = 18;

  // 20-40% - SIGNAL_STRENGTH_POOR
  else if (asu == 3)
    level = 25;
  else if (asu = 4)
    level = 35;

  // 40-60% - SIGNAL_STRENGTH_MODERATE
  else if (asu = 5)
    level = 46;
  else if (asu = 6)
    level = 52;
  else if (asu = 7)
    level = 58;

  // 60-80% SIGNAL_STRENGTH_GOOD
  else if (asu = 8)
    level = 60;
  else if (asu = 9)
    level = 65;
  else if (asu = 10)
    level = 70;
  else if (asu = 11)
    level = 75;

  // 80-100% - SIGNAL_STRENGTH_GREAT
  else if (asu >= 12)
    level = 80 + 20*(1 - (31-asu)/19.0);

[Ricardo Salveti (rsalveti)]

But then we'd break the ofono API as rilmodem is doing exactly the same thing as we have for the other modems (check at modem and others).

People using the ofono API is expecting the percentage to be basically the asu values (in case of a gsm modem).

[Tony Espy (awe)]

Alright, after spending some more time looking at the code, rilmodem is doing the *exact* same thing as atmodem.

Both atmodem and rilmodem receive a signal strength ( rssi ) from the modem as defined in ETSI GSM 07.07 (3GPP TS 27.007) section 8.5:

http://www.etsi.org/deliver/etsi_ts/127000_127099/127007/08.05.00_60/ts_127007v080500p.pdf

<rssi>
:
0 -113 dBm or less
1 -111 dBm
2...30 -109... -53 dBm
31 -51 dBm or greater
99 not known or not detectable

They also receive a channel bit error rate which is ignored by both implementations.

Both drivers use the *exact* same logic to convert the received RSSI value into a percentage:

if (strength == 99)
    result = -1;
else
    result = (strength * 100) / 31;

So, I'll again re-iterate that I agree with Ricardo that we should *not* change rilmodem. If the suggested changes are made to the indicator-network code, it will just *work* with any ofono GSM modem implementation.

[Antti Kaijanmäki (kaijanmaki)]

OK. Let's do that in the indicator then.

[Launchpad Janitor (janitor)]

This bug was fixed in the package indicator-network - 0.5.1+14.10.20140623-0ubuntu1

---------------
indicator-network (0.5.1+14.10.20140623-0ubuntu1) utopic; urgency=low

  [ Ubuntu daily release ]
  * New rebuild forced

  [ Ricardo Salveti de Araujo ]
  * Changing signal strength thresholds to follow values use by Android
    (LP: #1329945) (LP: #1329945)
 -- Ubuntu daily release <email address hidden> Mon, 23 Jun 2014 18:55:23 +0000