Closed
Bug 970154
Opened 11 years ago
Closed 11 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•11 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•11 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•11 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•11 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: 11 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•