Bug #3170
closedPlenty of BTS_Tests fail since build 62
100%
Description
- TC_deact_sacch
- TC_meas_res_* for all channel types!
- TC_sacch_filling
- TC_sacch_info_mod
- TC_sacch_multi
After looking into the TTCN3 logs, I see:
07:11:33.438221 159 BTS_Tests.ttcn:1310 setverdict(fail): pass -> fail reason: "No MEAS RES received at all", new component reason: "No MEAS RES received at all"
however, there are plenty of MEAS_RES visible on RSL in the pcap as well as the log.
The reason seems to be that OsmoBTS is sending a "RLL ERROR IND" with cause "Frame Type not implemented", which is apparently in response to OsmocomBB mobile or trxcon sending a frame like this on the uplink SACCH:
01 03 01 2b 8d ed fd 79 16 ....
where "01 03" is the SACCH header with MS power level 1 and TA 3. The following LAPDm frame is rather short, as it consists only of a single octet "01" followed by random padding
fixeria: I suspect this was introduced when some recent patches about randomized padding were merged in trxcon. Any idea?
Files
Updated by fixeria about 6 years ago
Hi Harald,
cause "Frame Type not implemented"
...
I suspect this was introduced when some recent patches
about randomized padding were merged in trxcon. Any idea?
Correct, the frame you've mentioned is a fill frame with randomized padding.
The problem partially described there:
- https://osmocom.org/issues/2988#note-14
- https://lists.osmocom.org/pipermail/baseband-devel/2018-March/005513.html
In short, according to the GSM TS 04.08, section 3.4.1.1 "SACCH
procedures", Measurement Report messages are sent at each possible
occasion when nothing else has to be sent. In other words, a dummy
LAPDm fill frame (0x01, 0x03, 0x01, 0x2b, ...) is not applicable here.
I even made an unsuccessful attempt to resolve this issue:
This work is currently stalled because I've switched to USSD,
but I'll resume ASAP. If you have any recommendations,
feel free to write ;)
Updated by laforge about 6 years ago
I think the main problem here is that you're missing the L1 header in this message. A SACCH message doesn't have a 23byte LAPDm message, but only a 21 byte LAPDm message prefixed by a 2-byte Layer1 header. So now the first two bytes of your frame are misinterpreted as L1 header.
If the fill frame was properly prefixed with a L1 SACCH header, I don't think the BTS would send ERROR IND. From a higher-level protocol point of view, it could still be a bug not to send measurement reports, surt. But at least L1/L2 would be fine. I also assume that the interpretation of "01 03" as uplink SACCH header will confuse the TA loop handling.
Updated by laforge about 6 years ago
- Status changed from New to In Progress
- % Done changed from 0 to 80
I'm going to merge https://gerrit.osmocom.org/#/c/7807/ as an interim work-around. At least this way, the BTS no longe sends RLL ERROR IND to the BSC, which is what breaks a lot of test cases.
Updated by laforge about 6 years ago
Most tests are passing after merging the above patch, however TC_sacch_filling
still fails
Updated by laforge about 6 years ago
- Status changed from In Progress to Resolved
- % Done changed from 80 to 100
TC_sacch_filling now also passes again