Running a test on my sysmoBTS just now (for completely unrelated reasons) gave me a similar log like below. But it only happened once and I am unable to reproduce it:
osmo-nitb tried to allocate an SDCCH on various lchan of TS 0, each says Activating ARFCN(868) SS(0) lctype SDCCH r=LOCATION_UPDATE but each ended up in "RELEASE DUE ERROR", then "back in operation".
This happened probably more than a dozen times over in close succession. Seconds after it seemed to have settled and I could do Location Updating again.
I've never seen this before on any BTS and am actually unable to reproduce it now. Could it be due to some recent software change? (running all the master branches of right now.)
Complete logs are here: http://kleinekatze.de/Roht9Sei/release_due_error (note: logs contain ANSI coloring, so best view with 'less -r' or 'cat') The dance starts e.g. in the nitb log at 20170203014131863 . The bts.log timestamps are one hour earlier plus nine seconds, so the dance starts in the bts.log below 20170203004140 . It is over at nitb: 20170203014245298 , bts: 20170203004254 .
Hossein, is this what your logs look like? How long have you retried connecting? It is known that USRPs without a high quality external timing source are somewhat unreliable (but they still work mostly).
Has anyone else seen this or knows what the reason could be?
BTW, Hossein, this happened now completely by chance and was not related to your mailing me privately ;)
~N
On Tue, Jan 31, 2017 at 01:36:08AM +0330, Hossein Amini wrote:
hi dear I install openbsc, osmosgsn, ggsn, osmo-trx, osmo-bts-trx, osmo-pcu and dependency from master branch step by step from this link. https://osmocom.org/projects/cellular-infrastructure/wiki/OpenBSC_GPRS
but when run osmo-nitb, osmo-trx and osmo-bts-trx, mobile connect to network but no access to network. (I used USRP N210/B210, ubuntu 15.10/16.10 64x)
osmo-nitb log:
20170130041914525 DRLL <0000> chan_alloc.c:352 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Allocating lchan=0 as SDCCH 20170130041914525 DRSL <0004> abis_rsl.c:1819 (bts=0,trx=0,ts=0,ss=0) Activating ARFCN(0) SS(0) lctype SDCCH r=LOCATION_UPDATE ra=0x05 ta=0 20170130041914525 DRSL <0004> abis_rsl.c:580 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Tx RSL Channel Activate with act_type=INITIAL 20170130041914525 DRSL <0004> abis_rsl.c:1189 (bts=0,trx=0,ts=0,ss=0) state NONE -> ACTIVATION REQUESTED 20170130041914525 DRSL <0004> abis_rsl.c:1546 (bts=0,trx=0,ts=0,ss=0) CHANNEL ACTIVATE ACK 20170130041914525 DRSL <0004> abis_rsl.c:1189 (bts=0,trx=0,ts=0,ss=0) state ACTIVATION REQUESTED -> ACTIVE 20170130041924529 DRSL <0004> abis_rsl.c:852 (bts=0,trx=0,ts=0,ss=0) RF Channel Release due to error: 1 20170130041924529 DRSL <0004> abis_rsl.c:762 (bts=0,trx=0,ts=0,ss=0) DEACTivate SACCH CMD 20170130041924529 DRSL <0004> abis_rsl.c:1189 (bts=0,trx=0,ts=0,ss=0) state ACTIVE -> RELEASE DUE ERROR 20170130041924530 DRSL <0004> abis_rsl.c:925 (bts=0,trx=0,ts=0,ss=0) RF CHANNEL RELEASE ACK 20170130041926530 DRSL <0004> abis_rsl.c:811 (bts=0,trx=0,ts=0,ss=0) is back in operation. 20170130041926531 DRSL <0004> abis_rsl.c:1189 (bts=0,trx=0,ts=0,ss=0) state RELEASE DUE ERROR -> NONE
[...]