osmo-nitb and osmo-bts-trx problems with voice, no connection (using LimeSDR)

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Pau Espin Pedrol pespin at sysmocom.de
Fri Feb 16 13:14:04 UTC 2018


Hi,

I'm also experincing this issue while using limesdr, also using latest 
dependencies (soapysdr, limesuite, etc.) and latest osmo-trx.

The call is established correctly, but after a few seconds (or almost 
immediately) it is cancelled.

This explains that the call was closed:

 > <0000> rsl.c:689 (bts=0,trx=0,ts=3,ss=0) Sending Connection Failure:
 > cause = 0x01
 > <0011> lapdm.c:1144 ((nil)) RLL Message 'REL_REQ' received without LAPDm
 > context. (sapi 0)
 > <0000> rsl.c:1433 (bts=0,trx=0,ts=3,ss=0) Sending RTP delete indication:
 > cause = Normal event, unspecified

The RTP becoming out of sync most probably also explains too that a lot 
of packets are not being received correctly at l1sap layer:

> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 1600 vs 160 
> (2295960->2296003)
> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 82594400 vs 
> 160 (2296003->2295973)
> <000e> l1sap.c:96 RTP clock out of sync with lower layer: 1440 vs 160 


Reproducing a conversation relarted to this topic that I had with 
Harald, but unfortunately didn't have time to continue on it yet:

* Pau:
It seems it comes from osmo-bts l1sap_ph_data_ind with len(msgb)==0, 
indicating a bad frame. I can reproduce this every time I place a call 
between 2 MS with a limesdr.

* Harald:
well, it's not "a bad frame", but it's a lot of ongoing bad/lost
signaling blocks.

So first of all, this entire code path is not traversed for voice (TCH)
block, only for signalling (FACCH/SACCH) blocks. And then, there's the
's' counter implementing the radio link criterion. It is not formally
specified for the BTS side (see TS 45.008 Section 5.3), but we simply
implement what's specified for the MS side in TS 45.008 Section 5.2.

"S" is incremented for every good block by two, and decremented for
every bad block. And once it reaches a negative value, the
above-mentioned LINK FAILURE message is sent via RSL. See

So you must be loosing more than 66.6% of your total number of signaling
blocks to ever reach this point.

How do the measurement reports look like? Those are the most valuable
resource when debugging anything related to RF link issues.


-- 
- Pau Espin Pedrol <pespin at sysmocom.de>         http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte



More information about the OpenBSC mailing list