Feature #3483
handover decision: if rxlev is ok but rxqual is bad, move from TCH/H to TCH/F
0%
Description
Bad quality scenario: rxlev is ok, but rxqual drops below the min_rxqual threshold.
Handover decision 2 contains a switch from TCH/H to TCH/F to improve rxqual. See on_measurement_report() in handover_decision_2.c, by the comment "Bad Quality".
However, that condition seems buggy: "if (... av_rxqual > ho_get_hodec2_min_rxqual(bts->ho))" should probably be the flipped?
To test for this with real equipment, we could manipulate the min_rxqual threshold during a call.
In ttcn3, we could use measurement reports.
Related issues
History
#1 Updated by neels over 1 year ago
- Related to Feature #1608: various handover improvements, meta-issue added
#2 Updated by laforge about 1 year ago
- Assignee set to neels
#3 Updated by neels about 1 year ago
I expect this to already work, just need to make sure by explicit tests.
#4 Updated by neels about 1 year ago
- Category set to Handover
#5 Updated by neels about 1 year ago
Another problem: this magic number in on_measurement_report() should rather be ho_get_hodec2_min_rxlev():
if (rxlev2dbm(av_rxlev) > -85)
#6 Updated by neels about 1 year ago
to be clarified is the issue of moving between codecs without transcoding support. Some comments are at https://osmocom.org/issues/3503#note-5
#7 Updated by neels about 1 year ago
neels wrote:
However, that condition seems buggy: "if (... av_rxqual > ho_get_hodec2_min_rxqual(bts->ho))" should probably be the flipped?
3GPP TS 45.008 8.2.4 Range of parameter RXQUAL:
The BER values used to define a quality band are the estimated error probabilities before channel decoding
and RXQUAL_0 means BER < 0.2%, ... RXQUAL_7 means BER > 12.8%.
i.e. a higher RXQUAL value should indicate a worse signal, and the condition is not flipped.
