19 Feb
2018
19 Feb
'18
8:57 a.m.
Hello again,
Thanks for the reply. Here is my nitb configuration:
e1_input
e1_line 0 driver ipa
e1_line 0 port 0
network
network country code 1
mobile network code 1
short name LimeSDR
long name LimeSDR
auth policy accept-all
location updating reject cause 13
encryption a5 0
neci 1
paging any use tch 0
rrlp mode none
mm info 1
handover 0
handover window rxlev averaging 10
handover window rxqual averaging 1
handover window rxlev neighbor averaging 10
handover power budget interval 6
handover power budget hysteresis 3
handover maximum distance 9999
timer t3101 10
! timer t3103 0
! timer t3105 0
! timer t3107 0
timer t3109 4
! timer t3111 0
timer t3113 60
! timer t3115 0
! timer t3117 0
! timer t3119 0
timer t3122 10
! timer t3141 0
dtx-used 0
subscriber-keep-in-ram 0
bts 0
type sysmobts
band DCS1800
cell_identity 0
location_area_code 2
training_sequence_code 7
! base_station_id_code 63
ms max power 23
cell reselection hysteresis 4
rxlev access min 0
periodic location update 30
! radio-link-timeout 32
channel allocator ascending
rach tx integer 9
rach max transmission 7
channel-descrption attach 1
channel-descrption bs-pa-mfrms 5
channel-descrption bs-ag-blks-res 1
ip.access unit_id 1801 0
oml ip.access stream_id 255 line 0
neighbor-list mode automatic
! codec-support fr efr afs
! amr tch-f modes 2
! amr tch-f start-mode 1
! amr tch-h modes 2
! amr tch-h start-mode 1
gprs mode none
trx 0
rf_locked 0
arfcn 525
nominal power 23
max_power_red 0
rsl e1 tei 0
timeslot 0
phys_chan_config CCCH+SDCCH4
hopping enabled 0
timeslot 1
phys_chan_config TCH/F
hopping enabled 0
timeslot 2
phys_chan_config TCH/F
hopping enabled 0
timeslot 3
phys_chan_config TCH/F
hopping enabled 0
timeslot 4
phys_chan_config TCH/F
hopping enabled 0
timeslot 5
phys_chan_config TCH/F
hopping enabled 0
timeslot 6
phys_chan_config TCH/F
hopping enabled 0
timeslot 7
phys_chan_config TCH/F
hopping enabled 0
mncc-int
default-codec tch-f amr
default-codec tch-h amr
And here is my osmo-bts-trx configuration:
phy 0
instance 0
osmotrx rx-gain 1
osmotrx ip local 127.0.0.1
osmotrx ip remote 127.0.0.1
bts 0
band DCS1800
ipa unit-id 1801 0
oml remote-ip 127.0.0.1
gsmtap-sapi ccch
gsmtap-sapi pdtch
trx 0
phy 0 instance 0
I do however doubt that the LimeSDR is at fault for the voice calls failing, as on an
older osmo-bts-trx ver. 0.6.0.21-9982b, I get the same RTP errors (<0007> l1sap.c:96
RTP clock out of sync with lower layer: 0 vs 160 (456369->456369)) but voice calls do
work (at least somewhat)
On 2018.02.16 22:07, Osmocom Mailing List wrote:
Hi,
Can I see your configuration files? Particularly the OsmoNITB (OpenBSC) one.
Here's mine: https://gist.github.com/FFY00/ea5fa36435bc31d3d3a02ff3e46abb50
Thanks,
Filipe Laíns <https://github.com/FFY00>
On sex, fev 16, 2018 at 1:14 PM, Pau Espin Pedrol
<pespin@sysmocom.de><mailto:pespin@sysmocom.de> wrote:
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@sysmocom.de<mailto:pespin@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
Sent via Migadu.com, world's easiest email
hosting<https://migadu.com?s=sent_via>