Bug #5517
openttcn3-bts-test: new sporadic test case failures
30%
Description
Since recently, the following testcases sporadically fail:
- BTS_Tests.TC_tx_power_ramp_adm_state_change,
- BTS_Tests.TC_rsl_ms_pwr_dyn_ass_updown,
- BTS_Tests.TC_rsl_ms_pwr_dyn_up.
We should investigate why and try to fix them.
Checklist
- BTS_Tests.TC_tx_power_ramp_adm_state_change
- BTS_Tests.TC_rsl_ms_pwr_dyn_ass_updown
- BTS_Tests.TC_rsl_ms_pwr_dyn_up
Updated by fixeria about 2 years ago
- Checklist item BTS_Tests.TC_tx_power_ramp_adm_state_change added
- Checklist item BTS_Tests.TC_rsl_ms_pwr_dyn_ass_updown added
- Checklist item BTS_Tests.TC_rsl_ms_pwr_dyn_up added
- % Done changed from 0 to 30
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/27697 BTS_Tests: tune waiting timeout in TC_rsl_ms_pwr_dyn_up [NEW]
Updated by fixeria about 2 years ago
fixeria wrote in #note-1:
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/27697 BTS_Tests: tune waiting timeout in TC_rsl_ms_pwr_dyn_up [NEW]
Interestingly enough, while running this testcase locally to test the fix I saw this:
DLOOP INFO (bts=0,trx=0,ts=1,ss=0) Raising MS power control level 15 (0 dBm) => 3 (24 dBm): ms-pwr-lvl[curr 5, max 0], RSSI[curr -100, avg -100, th resh -47..-47] dBm, C/I[curr 6, avg 6, thresh 13..17] dB (power_control.c:296)
Note that osmo-bts is increasing the power by 24 dBm at once! This violates the maximum increase step limitation, which is 4 dB by default. This happened just once and I could not reproduce this again. pespin any ideas why would this happen and how? This must be a bug somewhere in the logic.
Updated by fixeria about 2 years ago
fixeria wrote in #note-2:
Note that osmo-bts is increasing the power by 24 dBm at once! This violates the maximum increase step limitation, which is 4 dB by default. This happened just once and I could not reproduce this again. pespin any ideas why would this happen and how? This must be a bug somewhere in the logic.
I managed to reproduce this again by running the test many times, and it looks like a race condition to me:
- trxcon indicates (btw, why?) ms-pwr-lvl=5 (20 dBm) in the Uplink L1 SACCH Header;
- osmo-bts thinks that the current ms-pwr-lvl is 15 (0 dBm), but gets 5 (20 dBm);
- the increase step is calculated in relation to the current ms-pwr-lvl=5 (20 dBm).
So it's not as critical as I thought, but the logging is a bit confusing.
Updated by pespin about 2 years ago
fixeria yes, the calculations are done based on the MS power level reorted by the MS itself ("ms-pwr-lvl[curr 5"). So in that case we ask the MS to go from ms-pwr-lvl 5 to 3.
Why is the MS using ms-pwr-lvl 5 despite the BTS seems asked for 0? No idea.In general, though, it's normal that the MS reports using a different MS Power Level than the one the BTS asked for, due to several reasons:
- It may take some time to ramp to the target required ms pwoer level
- A MS may not support that specific MS Power Level, so it can freely take one (I think is the first supported below/above) different than the one requested.
Please attach a full pcap next time you run into this.
Updated by fixeria about 1 year ago
- Checklist item BTS_Tests.TC_rsl_ms_pwr_dyn_ass_updown set to Done
Updated by fixeria about 1 year ago
TC_rsl_ms_pwr_dyn_ass_updown
has become stable green, no sporadic failures seen during the last 30 consecutive runs.
Updated by fixeria about 1 year ago
TC_tx_power_ramp_adm_state_change
is also stable now, but red:
"BTS_Tests.ttcn:721 : Tguard timeout" BTS_Tests.ttcn:8921 BTS_Tests control part BTS_Tests.ttcn:3045 TC_tx_power_ramp_adm_state_change testcase