existing test suite doesn't catch wrong measurement processing
Despite us having TTCN-3 tests in BTS_Tests.ttcn that also cover measurement processing, those bugs have not been caught so far. This means there are significant (unexpected) gaps in our test coverage which should be fixed. Preferably we should have test coverage that fails before fixing any related issues.
#2 Updated by dexter almost 2 years ago
- File TC_meas_res_sign_sdcch4_meas_expected.txt TC_meas_res_sign_sdcch4_meas_expected.txt added
- File TC_meas_res_sign_sdcch4_meas_got.txt TC_meas_res_sign_sdcch4_meas_got.txt added
- File TC_meas_res_sign_sdcch8.meas_expected.txt TC_meas_res_sign_sdcch8.meas_expected.txt added
- File TC_meas_res_sign_sdcch8.meas_got.txt TC_meas_res_sign_sdcch8.meas_got.txt added
- File TC_meas_res_sign_sdcch8.pcapng TC_meas_res_sign_sdcch8.pcapng added
- File TC_meas_res_sign_tchh_meas_expected.txt TC_meas_res_sign_tchh_meas_expected.txt added
- File TC_meas_res_sign_tchh_meas_got.txt TC_meas_res_sign_tchh_meas_got.txt added
- File TC_meas_res_sign_tchh_toa256_meas_expected.txt TC_meas_res_sign_tchh_toa256_meas_expected.txt added
- File TC_meas_res_sign_tchh_toa256_meas_got.txt TC_meas_res_sign_tchh_toa256_meas_got.txt added
I am currently looking at what we already have. To check the measurement reporting we currently have the following tests in place:
Unfortunately BTS_Tests.TC_meas_res_sign_tchf is the only one that is currently passing. I think we need to fix this first. The main reason why the tests are failing is because the measurement indications that comes back has unexpected values for rxq_f_u and rxq_s_u (see attached _expected.txt _got.txt files). The testsuite defines the tolerance range for both values as (0 .. 1), but the actual value that we get when the tests are running is 7. Technically this value may be even in the valid range but the testsuite narrows the valid range. The tests were passing before, probably the testsuite defines a correct test expectation here. We now should check how those values are computed and if this is correct.
When mp_tolerance_rxqual is set to 7, then the tests are more likely to pass, I could make them all pass instead of BTS_Tests.TC_meas_res_sign_sdcch8. However, there still seems to be a problem with other parts of the testsuite or of the iut itsself. Sometimes there is no new channel opened and the tests times out because it sees no measurement reports within a certain amount of time. From what I can see, it is not the case that there are just no measurement reports sent, there is not even a channel estabilshed. All whats there are CCCH LOAD INDications. For this see attacted trace: TC_meas_res_sign_sdcch8.pcapng.
#4 Updated by Hoernchen over 1 year ago
The issue is caused by an unexpected number of measurements (should be 3 for sddch/4) which in turn are apparently caused by lost frames, scheduler_trx.c:tx_data_fn will add a measurement with 100% BER for lost frames, and since the measurement processing code processes the newest 3 results the measurement results are impacted by one dummy report with 100% BER and fixed rx level, so the test fails.
#5 Updated by Hoernchen over 1 year ago
I've removed the superfluous measurement report generation upon sdcch frame loss in https://gerrit.osmocom.org/c/osmo-bts/+/14762 - this fixes the sdcch tests, but does not explain why adding a lost report ends up with more reports, since one should be lost...
TCH/H is also broken due to 21/25 UL measurements right for the first measurement report, and only 13/25 for all following reports.