Feature #3750
Extension of BTS_Tests.ttcn test coverage
60%
Description
Extension of the BTS Tests.ttcn test suite as well as its dependencies to extend the test coverage to cover the following scenarios, for which currently no automatic test coverage exists
Checklist
- RSL channel activation with timing advance from initial activation onwards.
- RSL MODE MODIFY with encryption parameter IE and/or multirate configuration IE.
- RSL DEACTIVATE slow associated control channel (“SACCH”)
- Handover Detection
- Mobile station (“MS”) Power Control
- Base station (“BS”) Power Control
- Common control channel (“CCCH”) LOAD INDICATION for random access channel (“RACH”)
- Cell broadcast channel (“CBCH”) LOAD INDICATION
- RF RESOURCE INDICATION
- Error handling, such as discriminator error, type error, sequence error, duplicated IE
- Packet control unit (“PCU”) interface
- SACCH INFO as part of RSL CHAN ACT
- SACCH transmission rules in the context of special CHAN ACT (HO)
Related issues
History
#3 Updated by laforge 7 months ago
- Checklist item Error handling, such as discriminator error, type error, sequence error, duplicated IE set to Done
Tests related to error handling have been submitted in https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/14086/
which triggered osmo-bts bug-fixes in https://gerrit.osmocom.org/#/c/osmo-bts/+/14083/, https://gerrit.osmocom.org/#/c/osmo-bts/+/14084/ and https://gerrit.osmocom.org/#/c/osmo-bts/+/14085/
Meanwhile, a related wireshark dissector bug has been discovered: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15789
#5 Updated by laforge 7 months ago
- Checklist item SACCH INFO as part of RSL CHAN ACT added
https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/14089/ for SACH INFO as part of RSL CHAN ACT. Testcase immediately found an error in osmo-bts which is fixed in https://gerrit.osmocom.org/#/c/osmo-bts/+/14087/
#10 Updated by laforge 7 months ago
- Checklist item SACCH transmission rules in the context of special CHAN ACT (HO) set to Done
- % Done changed from 10 to 20
tests for SACCH related transmission rules on hand-over related channel activation in https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/14094
#14 Updated by laforge 7 months ago
- Checklist item Common control channel (“CCCH”) LOAD INDICATION for random access channel (“RACH”) set to Done
- % Done changed from 20 to 50
https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/14169 contains tests for RACH load indications. There were several fixes required in osmo-bts in order to make it pass: https://gerrit.osmocom.org/14158, https://gerrit.osmocom.org/#/c/osmo-bts/+/14159/ and https://gerrit.osmocom.org/#/c/osmo-bts/+/14160/
The initial TA from RSL CHAN ACT has been implemented by @Hoernchen in https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/14151/
#20 Updated by laforge 6 months ago
- Checklist item Handover Detection set to Done
- % Done changed from 50 to 70
handover detection has been implemented in http://git.osmocom.org/osmo-ttcn3-hacks/commit/bts?id=7c2c10cbf0c837082040f80c463be97b729a7dda
#24 Updated by Hoernchen 6 months ago
There is currently no reasonable way to test the RF RESOURCE INDICATION, osmo-bts does currently not use the parameters from TS 100 623 (9.4.24 Intave 9.4.25 Interference level Boundaries), and while osmo-trx can be polled for noise measurements those measurements are currently done by averaging 20 idle bursts, while intave is specified as average of # sacch frames (480ms), and even if all that was not the case it would still not be possible to test all of that without creating artificial noise to trigger a interference level change which in turn would trigger the sending of a RF RESOURCE INDICATION message.
#25 Updated by Hoernchen 6 months ago
- Related to Feature #1569: Report RF interference levels as part of RF RESOURCE INDICATION added
#26 Updated by fixeria 25 days ago
There is currently no reasonable way to test the RF RESOURCE INDICATION [...]
Please see https://gerrit.osmocom.org/c/osmo-bts/+/15989. I believe this change would facilitate getting the actual (not averaged) interference levels. Since TRXDv1, OsmoTRX sends us IDLE indications (basically measurements during IDLE frames) and NOPE indications (when a burst was expected, but has not been received / detected).
[...] and even if all that was not the case it would still not be possible to test all of that without creating artificial noise to trigger a interference level change [...]
We can simulate pretty much everything with a virtual Um-interface - FakeTRX. The problem is that sending of IDLE / NOPE indications is still missing there :/ If I had time, I would implement this in a few days.
