Cellular Network Infrastructure » Radio Access Network » OsmoBTS

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:

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

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.

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.

Most tests are passing after merging the above patch, however TC_sacch_filling still fails

TC_sacch_filling now also passes again