Why is the cell radio strength API a mess?

[Leith Bade]

I have been exploring how to get better signal quality measurements on my phone using the android.telephony.* APIs.

Last time I looked at it 3 years ago the only APIs available were:

PhoneStateListener.onSignalStrength(int asu) for old phones pre-2.1 which returned a generic "asu" value which is taken from the AT+CSQ command (see 3GPP TS 27.007 8.5). The function was poorly documented too.

The much improved SignalStrength class was added in 2.1. This class supports CDMA and GSM phones. Also the GSM signal strengths were expanded to now use the slightly better  getGsmSignalStrength() and getGsmBitErrorRate(). These correspond to <rssi> and <ber> from 3GPP TS 27.007 8.5.

But the GSM functions were useless on 3G phones running over UMTS. This is because UMTS measures signal quality in terms of RSCP and EcIo which are far more important in a WCDMA system. You can see that the CDMA and ECIO functions report these, but not for GSM phones.

Part of the problem was that the only standard 3GPP AT command at that time was AT+CSQ which is a GSM era function thus only supports RSSI and BER. This command is rather strange is that it's <rssi> with a range of -113 to -51 dBm in 2 dBm steps does not quite correspond to the RXLEV value it is based on which covers -110 to -48 dBm in 1 dBm steps (see 3GPP TS 45.008 8.1.4). At least <ber> exactly corresponds to RXQUAL from 3GPP TS 45.008 8.2.4

However in 3GPP Release 10 a new AT+CESQ command was added. This command is an important update as it supports all the measurements from GSM, UMTS and LTE. You can see it at 3GPP TS 27.007 8.69. Basically it has these measurements in it:

for GSM network:

<rxlev> = -110 to -48 dBm in 1 dBm steps (now aligns with 3GPP TS 45.008 8.1.4)

<ber> = RXQUAL levels 0 to 7 (from 3GPP TS 45.008 8.2.4)

for UMTS:

<rsrp> = -120 to -25 dBm in 1 dBm steps (from 3GPP TS 25.133 9.1.1.3)

<ecno> = -24 to 0 dBm in 0.5 dBm steps (from 3GPP TS 25.133 9.1.2.3)

for LTE:

<rsrq> = -19.5 to -3 dBm in 0.5 dBm steps (from 3GPP TS 36.133 9.1.7)

<rsrp> = -140 to -44 dBm in 1 dBm steps (from 3GPP TS 36.133 9.1.4)

It would seem to be a perfect opportunity to tidy up the API and and add the missing measurements.

It seems that the Android developers were thinking the same thing and made some big changes in 4.2. Not only did they move a bunch of the classes to a new git module, they added CellInfo, CellIdentity, and CellSignalStrength in GSM, CDMA and LTE flavours.

Unfortunately they did not take time to think it through and the new interfaces provide basically the same limited set of measurements as the old API, except for LTE where they screwed up the RSRQ values.

The mistakes:

They brought back getAsuLevel(). What is "asu"? Why is it used across GSM, CDMA, and LTE when it only applies to GSM? Why is the JavaDoc for this function across the base class, and the three sub classes, inconsistent (is it GSM <rssi> or LTE RSRP, what about for CDMA phones?!?)

They should have left out getAsuLevel()!

The getDbm function is far more suitable and applies to all three sub-classes in a consistent way.

They left out EcIo for UMTS and RSRQ for LTE... but then added the useful (but not from the AT command) getTimingAdvance().

However the description for getTimingAdvance() is incomplete and does not refer to whether it is RSTD (from 3GPP TS 36.133 9.1.10) or UE Rx - Tx (from 3GPP TS 36.133 9.1.9) or what units it is in.

What's even more baffling is when you look at the new RIL driver interface from ril.h.

A new LTE measurement packet has been added: RIL_LTE_SignalStrength

It includes the old GSM signal strength measurement, RSRP, RSRQ, SNR and CQI measurements.

However they screwed up RSRQ by defining it as -20 to -3 dB with 1 dB increments instead of 0.5 dB (losing half the precision). They should have multiplied by 10 like they did with SNR to keep the precision.

So the API should be updated again to fix all these problems. I would like to see all the stuff from 3GPP TS 27.007 8.69 in the exact same range and accuracies (with 0.5dBm RSRQ).  Also adding the frequency id to the cell identity stuff would be good too.

[Grgur Damic]

Very good point!

We are in April 2014 and nothing has changed...

Did you manage to get correct values in some alternative way (reflection, playing with ril, etc...)?