Extension of BTS_Tests.ttcn test coverage
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
- 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)
lapdm_rslms_recvmsg: Fix memory leak in error path
The caller of lapdm_rslms_recvmsg() (e.g. osmo-bts/src/common/rsl.c)
assumes the message ownership is transferred. However, in one of the
two error paths, msgb_free() was not called and hence we had a memory
Also clarify the msgb ownership transfer in a comment.
rsl: Send RSL Error Report in case of unknown/unsupported msg_type
Send an RSL Error Report in case of unknown/unsupported msg_type,
as describedi in section 7.3 of 3GPP TS 48.058.
rsl: Include Channel Nr and Link ID in Error reports whenever possible
While the CHAN_NR and LINK_ID IEs in ERROR REPORRT are optional, we
still should include it whenever possible to help error analysis.
RSL: Reject RLL messages for lchans that are not active yet
The Radio Link Layer (RLL) messages only make sense when a given
logical channel is active. If it isn't active, let's reject the
messages with an RSL ERROR REPORT with cause "Message sequence error",
wich according to spec means:
"A message with an existing message type which is not possible according
to the specification and to the state of the BTS is erroneous."
RSL: Fix off-by-one error when parsing SACCH INFO IE in RSL CHAN ACT
This off-by-one error in length verification caused all SACCH INFO IE
to be deemed invalid and hence any RSL CHAN ACT with that IE to be
load_indication: Fix missing re-set of RACH parameters
While we re-set the PCH load counters after every report, we never
actually re-set the RACH load counters. This meant that the
period/window for RACH load averaging would always grow, rather than
being reset every load indication period.
l1sap: Correctly count RACH slots in calc_exprd_rach_frames()
We used a bogus multiplication factor of four when computing the number
of expired RACH slots. While there are four RACH slots per block (i.e.
4 times more RACH received than normal MAC blocks), that multiplier
doesn't apply here: We are calling this function per frame and not
per block. So the maximum number of RACH slots per frame is (in
most suual cases with a single CCCH) at maximum 1. Only some obscure
configurations with multiple CCCHs in a single cell would render higher
values. In any case, blocks never even enter this equation.
This wrong multiplier resulted in rather weird RACH load reports to the
l1sap: Fix calculation of expired RACH slots in case of missing frame numbers
In case of a Combined CCCH (with SDCCH/4), the number of RACH slots
depends on the frame number. So in case of lost/skipped frame numbers,
we cannot simply compute the value for the current fn and then multiply
it by the number of frame numbers expired. Rather, we have to 'replay'
all missed frame numbers and individually determine how many RACH
slots happened in that frame.
#3 Updated by laforge over 2 years 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 over 2 years 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 over 2 years 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 over 2 years 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 over 2 years 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 over 2 years 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.
#26 Updated by fixeria almost 2 years 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.
- Checklist item RF RESOURCE INDICATION set to Done
- % Done changed from 90 to 100
For the sake of completeness:
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/24567 BTS: add a test case for RF RESource INDication [WIP]
The progress can be tracked in #1569.