Closed
Bug 970154
Opened 10 years ago
Closed 10 years ago
LTE signal strength range.
Categories
(Firefox OS Graveyard :: RIL, defect)
Tracking
(Not tracked)
RESOLVED
INVALID
People
(Reporter: sku, Unassigned)
Details
Attachments
(1 file)
696.83 KB,
text/x-log
|
Details |
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
Reporter | ||
Comment 1•10 years ago
|
||
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)
Comment 2•10 years ago
|
||
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)
Reporter | ||
Comment 3•10 years ago
|
||
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)
Reporter | ||
Comment 4•10 years ago
|
||
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.
Description
•