Cellular Network Infrastructure » Radio Access Network » OsmoBTS

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.

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.

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.

• 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.

TC_rsl_ms_pwr_dyn_ass_updown has become stable green, no sporadic failures seen during the last 30 consecutive runs.

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