Closed Bug 970154 Opened 10 years ago Closed 10 years ago

LTE signal strength range.

Categories

(Firefox OS Graveyard :: RIL, defect)

x86_64
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: sku, Unassigned)

Details

Attachments

(1 file)

By following AOSP, LTE signal strength should contain signalStrength/rsrp/rsrq/rssnr/cqi/[timingAdvance]. (see [1])

Regarding rsrp, AOSP define the range between 44 to 140 dBm.
However, we can see partner report it's value as 100 for invalid one (see [2]), Partner might follow rsrp value via [3] to let valid range locates between 0 and 97 dbm.

This report conflict with AOSP design (see [4]), and it will make us do the wrong judgment for LTE signal strength mapping by following AOSP's algorithm.



[1] - https://github.com/android/platform_hardware_ril/blob/master/include/telephony/ril.h#L714

[2] - 02-07 17:36:55.808   108   242 I Gecko   : RIL Worker[0]: signal strength: {"gsmSignalStrength":99,"gsmBitErrorRate":255,"cdmaDBM":-1,"cdmaECIO":-1,"evdoDBM":-1,"evdoECIO":-1,"evdoSNR":-1,"lteSignalStrength":99,"lteRSRP":100,"lteRSRQ":-32767,"lteRSSNR":-32767,"lteCQI":-32767}

[3]- 3GPP TS 27.007 clause 8.69 Extended signal quality +CESQ

[4] - https://github.com/android/platform_frameworks_base/blob/master/telephony/java/android/telephony/SignalStrength.java#L370
Hi Michael:
 Could you please help check why QCT solution report 100 dbm for invalid rsrp on FxOS?
By following AOSP, 44 ~ 140 dBm are all valid value for rsrp.
The result will make us treat LTE signal is valid, and do the wrong judgment for signal mapping.

    int rsrp; /* The current Reference Signal Receive Power in dBm multipled by -1.
               * Range: 44 to 140 dBm
               * INT_MAX: 0x7FFFFFFF denotes invalid value.
               * Reference: 3GPP TS 36.133 9.1.4 */

Thanks!!
Shawn
Flags: needinfo?(mschwart)
Hi Shawn, is this issue with commercial ril or reference ril?  I see from your [2] above shows RIL Worker from the reference RIL.

Can you provide radio and main logs of this situation?  I think it might make things clearer.
Flags: needinfo?(mschwart) → needinfo?(sku)
Attached file signal.log
Hi Michael:
 It's my bad to provide incorrect information before.

I used reference RIL. and RILD did set lteSignalStrength to 99 (INVALID one).

Sorry for my careless, and, thanks for your time again!!
Shawn


02-14 16:23:25.062   116   184 D RILC    : Signal strength: gwl_rssi: 29, gw_bit_error: 255, cdma_dbm: -1, cdma_ecio: -1, hdr_dbm: -1, hdr_ecio: -1, hdr_sinr: -1, lte_rsrp -32767, lte_rsrq -32767
02-14 16:23:25.082   108   243 I Gecko   : RIL Worker[0]: signal strength: {"gsmSignalStrength":29,"gsmBitErrorRate":255,"cdmaDBM":-1,"cdmaECIO":-1,"evdoDBM":-1,"evdoECIO":-1,"evdoSNR":-1,"lteSignalStrength":99,"lteRSRP":-32767,"lteRSRQ":-32767,"lteRSSNR":-32767,"lteCQI":-32767}
Flags: needinfo?(sku)
Wrong info was provided. There is no issue regarding LTE signal strength.

"lteSignalStrength":99,  <- Invalid  (Valid Range: 0 to 63)
"lteRSRP":-32767,        <- Invalid, (Valid Range: 44 to 140 dBm)
"lteRSRQ":-32767         <- Invalid, (Valid Range: 20 to 3 dB.)
"lteRSSNR":-32767,       <- Invalid, (Valid Range: -200 to +300 (-200 = -20.0 dB, +300 = 30dB).)
"lteCQI":-32767          <- Invalid  (Valid Range: 0 to 15.)
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: