Bug #5953
openttcn3-bts-test: TC_ms_pwr_ctrl_{constant,pf_ewma} are failing
0%
Description
These two testcases were added by me back in 2020 and have been passing until recently:
commit c7ef03057fe6644372b8bf08c165afef29fc600f
Author: Vadim Yanitskiy <vyanitskiy@sysmocom.de>
Date: Sun Oct 18 19:24:18 2020 +0700
BTS_Tests: introduce TC_ms_pwr_ctrl_constant()
Unexpected MS Power level change: 7 -> 13
BTS_Tests.ttcn:9052 BTS_Tests control part
BTS_Tests.ttcn:8111 TC_ms_pwr_ctrl_constant testcase
commit 652e60eb83f928036a649fa45f7a4a4eb8207eac
Author: Vadim Yanitskiy <vyanitskiy@sysmocom.de>
Date: Sun Oct 18 19:43:27 2020 +0700
BTS_Tests: add TC_ms_pwr_ctrl_pf_ewma: test EWMA based power filtering
Unexpected MS Power level change: 7 -> 13
BTS_Tests.ttcn:9053 BTS_Tests control part
BTS_Tests.ttcn:8178 TC_ms_pwr_ctrl_pf_ewma testcase
The "red age" of both TCs is 102 days ago for both -master and -latest.
I guess this might be related to the recent changes in osmocom-bb.git/trxcon.
Updated by fixeria about 1 month ago
- Assignee changed from fixeria to pespin
I tried to debug this, but the MS power loop in osmo-bts behaves in a way that I cannot find logical explanation for. This is most likely related to the C/I based RxQual input criteria, which was implemented after these testcases. There has also been some refactoring of the MS power loop code, so I was having hard time to understand why it behaves differently. I even tried simulating a good C/I level (within the default thresholds) in the testsuite, but it didn't help. pespin re-assigning this ticket to you, since you were the last one touching the MS power loop after me.
Updated by fixeria about 1 month ago
I recommend focusing on TC_ms_pwr_ctrl_constant first, because the testcase scenario is relatively easy: it's emulating the RxLev/RxQual within the default target thresholds of osmo-bts and expecting the MS power level to remain constant.
Updated by pespin about 1 month ago
- Status changed from New to Feedback
- Assignee changed from pespin to fixeria
After some initial investigation, we found there's several problems:
1- The test was written before C/I was taken into account in the ms power loop, hence the C/I we are sending is below threshold and making the MS power loop increase the requested power, which makes it fail the test
2- Some Tx MS Power provided by TTCN3/trxcon is wrongly reported with Ms Power level 15 despite never been requested. The MS would be expected to use the maximum MS power reported by the BTS when it starts using the channel.
fixeria will look into fixing this in trxcon/l1ctl/ttcn3.
