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/.
Norbertas Kremeris n.kremeris at live.comHello 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 at sysmocom.de><mailto:pespin at 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 at sysmocom.de<mailto: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
Sent via Migadu.com, world's easiest email hosting<https://migadu.com?s=sent_via>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180219/5733564f/attachment.htm>