Bug #3170: Plenty of BTS_Tests fail since build 62 - OsmoBTS - Open Source Mobile Communications

Actions

Copy link

Bug #3170

closed

Plenty of BTS_Tests fail since build 62

Added by laforge about 6 years ago. Updated about 6 years ago.

Status:

Resolved

Priority:

Urgent

Assignee:

laforge

Category:

Target version:

Start date:

04/14/2018

Due date:

% Done:

100%

Spec Reference:

Description

https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/test_results_analyzer/ shows that since build 62 on april 10, the following tests all fail:

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

BTS_Tests.TC_meas_res_sign_sdcch4.pcap	BTS_Tests.TC_meas_res_sign_sdcch4.pcap	86.4 KB	example pcap file	laforge, 04/14/2018 08:54 PM
BTS_Tests.TC_meas_res_sign_sdcch4.merged	BTS_Tests.TC_meas_res_sign_sdcch4.merged	6.54 MB	example TITAN log file	laforge, 04/14/2018 08:55 PM

Actions

Copy link

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:

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:

https://gerrit.osmocom.org/7470/

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 ;)

Actions

Copy link

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.

Actions

Copy link

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.

Actions

Copy link