Project

General

Profile

Actions

Bug #5517

open

ttcn3-bts-test: new sporadic test case failures

Added by fixeria almost 2 years ago. Updated about 1 year ago.

Status:
New
Priority:
Normal
Assignee:
Category:
osmo-bts-trx
Target version:
-
Start date:
04/08/2022
Due date:
% Done:

30%

Spec Reference:

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
Actions #1

Updated by fixeria almost 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]

Actions #2

Updated by fixeria almost 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.

Actions #3

Updated by fixeria almost 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.

Actions #4

Updated by pespin almost 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.

Actions #5

Updated by fixeria about 1 year ago

  • Checklist item BTS_Tests.TC_rsl_ms_pwr_dyn_ass_updown set to Done
Actions #6

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.

Actions #7

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
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)