Hi all,
We're moving this discussion to the mailing list, as it seems it is
more generic and complex than we've thought initially.
The issue arose when I started doing load testing of the OsmoTRX
transceiver and disabled all gating in it. As a result, all incoming
noise was processed as valid Normal Bursts and Access Bursts and sent
up to OsmoBTS. This leads to a situation, similar to a RACH flood,
when there are more RACH requests coming, than a BTS could reasonably
process. And this leads to an unbounded increase of the AGCH queue in
the BTS - it consumes a few Mb per minute.
I think that this is the root cause of the issue we've seen at a
Netherlands festival installation, when 20K phones suddenly started
connecting to our station after official networks went down. When the
amount of RACH requests exceeded available CCCH capacity (took <5
seconds), mobile phones stopped answering out IMM.ASS messages.
Hypothesis is that the AGCH queue became so long, requests were sent
too late for a phone to receive it. And thus no phones answered to our
IMM.ASS messages. Unfortunately, I wasn't able to collect enough data
to check this hypothesis during that time and we don't have another
big festival on hands atm.
An attached is a quick fix for the unbounded queue growth. It uses a
hardcoded value for the maximum queue length, which is fine for our
load testing, but not flexible enough for the real life usage. We
should make the AGCH queue long enough to keep high performance. At
the same time, it must not exceed MS timeout or _all_ IMM.ASS messages
will miss their target MS's.
We could make this parameter user-configurable on a BTS side, but it
seems more reasonable to automatically calculate it, depending on the
channel combination and timeout values. But this should be done on the
BSC side. So the questions are:
1) what is a good way to calculate it?
2) should we configure this queue length over OML, or move the queue
from BTS to BSC?
--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ООО УмРадио
http://fairwaves.ru
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hey there,
I have come across a nanoBTS 165AU but since is used and not tested from the previous owner, I guess it has set a static IP.
After turned on is booting (RED light) and then remains (ORANGE not flashing) even if the eth is connected to the router.
At the moment I am trying with ipaccess-find and BtsInstaller to find in on my LAN .
Unfortunately it is not answering and is not even getting an IP from the router by the DHCP daemon.
Two possibilities, I have thought:
- - an hw/sw issue;
- - a Static IP is set.
Supposing that is the 2nd possibility, I was thinking:
- - to change private class of my LAN, to see if it changes something;
- - to make an hard reset of the bts.
Do you know if it possible to reset in someway?
Ever happened this issue to you guys?
Suggestions or insults are welcome.
Thanks in advance.
Cheers,
Luca
P.S.: I don't recall exactly, but one time I heard that is possible to reset by short-circuiting some pins of the LAN/48VDC eth connector. Is it right?!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
iQIcBAEBAgAGBQJSE682AAoJEPLE1Qsi6ZiTuKkQAJaYGFTgMF5XlWuZuCI1eSvU
lVCvpdB+fDRY7o6iut3y0fGlS1ZOIS8X93c7/T0XKUvSJaZ2ARIGjqi81A4XlkAK
pdFvBNPKixYATYZYhP3nIggC1QGK9fuWQSUKVEGgnswsXt0VaJKdEwgn0CX7ttku
uoh6FM3vtp30drB4t9oe0bW9M9qzGz6yyw+8asaqQBs8bafOHm4+S4kJsN6lYmPU
wY/s8ctzqZerNI0MwBVASZCFldsyWe0NuduquYZlwg4god996srFNkVQL+o9nrmF
vmPb896DTsCdivwqs+UyaZOgp1mKxjtfco275pVATG4qSAgz/JYQBxWK6fWQr+Zv
PIzQvFLME1kh/29nUihxw93mzju5Rz1naTosx5+Fs7jPjCFocqD5Var3hkU4iu78
kNALJNx6UGOdfbqcInO30ltSm21HH1QBJnIoZf6MblELvHcvHbBNyPB8zM13suoS
y3/oD/wcXefQaMaSa5HFc30ydJHBWS+adNlVp3fdYYArZaVkFxaVjJx8fW1juPVx
54aco5j7/tZD5tfg9FCOTHqmAiOVDqjs7nZrOpsRdkdPJHq2uHbGmHGqyhZlVWNv
B+9/eiOdQyKZ5R+3vvRrmhBe9g2a28xtRI7N8KxwCov0wbA6R0h8l2UtGza6NTcn
EUdW3ptIWP216tSFdVTs
=9Ctc
-----END PGP SIGNATURE-----
Hello Harald and everyone out there!
I have been going through your Osmocom projects especially Openbsc (osmo-nitb) and Osmobts projects and I must say it's a real great work!
I'm a lead engineer at Octasic and after looking at your work on OpenBSC and OsmoBTS, we decided to use your OpenBSC stack for internal testing of our Octasic PHY.
I know currently openbsc supports few BTS models like ip.access, sysmocom etc. I have gone through the wiki and some of the openbsc archives. I could find an archive regarding Octasic SDR, but I guess it has not gone any further.
http://lists.osmocom.org/pipermail/openbsc/2010-November/002196.html
I will be interested in osmo-nitb which I can use for network part of GSM and use osmo-bts for BTS L2/L3 stuff, which already has abis-over-ip interface to openBSC(osmo-nitb). I have Octasic SDR hardware that has the layer1 (DSP image), so all I need to implement is the interfaces between Octasic Layer1 and osmobts L2/L3 to communicate between them, which I'm working on.
I have already installed openbsc (osmo-nitb) and also osmobts on my Debian 7.1.0. I'm currently in a process of writing interfaces between Octasic L1 and osmobts.
I'm using the default config file openbsc.cfg for osmo-nitb & using ip.access config file for osmobts (with changes in the OML ip & band GSM900)
At present I'm trying to get TRX config request from osmo-nitb. However though I'm receiving few OML messages like NM_MT_SET_BTS_ATTR (pcap attached), I guess they are specific to ip.access BTS, I'm not able to see any TRX config request coming from osmo-nitb (Or by any chance is that what I'm receiving is the TRX config one?)
I'm simply sending ack for those OML messages and eventually expecting a TRX config request from osmo-nitb. I'm not sure if osmo-nitb expects something to se sent from BTS side, looks like it is simply waiting for something(see below).
I have tried to run osmo-nitb program and it look like:
./osmo-nitb -c openbsc.cfg
<0019> input/ipaccess.c:934 enabling ipaccess BSC mode
DB: Database initialized.
DB: Database prepared.
<001d> sms_queue.c:220 Attempting to send 20 SMS
<0019> input/ipa.c:323 accept()ed new link from 127.0.0.1 to port 3002
(I do not see RSL link becoming up here)
I tried turn on debug:
./osmo-nitb -c openbsc.cfg -C --debug=DRLL:DCC:DMM:DRR:DRSL:DNM
DB: Database initialized.
DB: Database prepared.
<0005> abis_nm.c:315 OC=SITE-MANAGER(00) INST=(ff,ff,ff) STATE CHG: OP_STATE=NULL AVAIL=Power off(02)
<0005> abis_nm.c:315 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=NULL AVAIL=Dependency(05)
<0005> abis_nm.c:1442 Set BTS Attr (bts=0) <0005> abis_nm.c:1763 OC=BTS(01) INST=(00,ff,ff) Sending OPSTART
<0005> abis_nm.c:315 OC=GPRS-NSE(f0) INST=(00,ff,ff) STATE CHG: OP_STATE=NULL AVAIL=Dependency(05)
<0005> abis_nm.c:315 OC=GPRS-CELL(f1) INST=(00,ff,ff) STATE CHG: OP_STATE=NULL AVAIL=Dependency(05)
<0005> abis_nm.c:315 OC=GPRS-NSVC(f2) INST=(00,00,ff) STATE CHG: OP_STATE=NULL AVAIL=Dependency(05)
<0005> abis_nm.c:315 OC=GPRS-NSVC(f2) INST=(00,01,ff) STATE CHG: OP_STATE=NULL AVAIL=Dependency(05)
<0005> abis_nm.c:315 OC=RADIO-CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=NULL AVAIL=Power off(02)
<0005> abis_nm.c:315 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=NULL AVAIL=Power off(02)
<0005> abis_nm.c:315 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=NULL AVAIL=Power off(02)
<0005> abis_nm.c:315 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=NULL AVAIL=Power off(02)
<0005> abis_nm.c:315 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=NULL AVAIL=Power off(02)
<0005> abis_nm.c:315 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=NULL AVAIL=Power off(02)
<0005> abis_nm.c:315 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=NULL AVAIL=Power off(02)
<0005> abis_nm.c:315 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=NULL AVAIL=Power off(02)
<0005> abis_nm.c:315 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=NULL AVAIL=Power off(02)
<0005> abis_nm.c:315 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=NULL AVAIL=Power off(02)
<0005> abis_nm.c:315 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=Enabled AVAIL=Dependency(05)
<0005> abis_nm.c:1442 Set BTS Attr (bts=0) <0005> abis_nm.c:1763 OC=BTS(01) INST=(00,ff,ff) Sending OPSTART
And then BSC keeps waiting here though at osmobts - osmo-nitb interface IPACCESS ping-pong goes on for keep-alive of the abis OML link and after some time,
Osmobts reports link down(see attached osmo-bts debug).
At present, I have just created socket interface from osmo-bts to octasic L1 and I'm in the process of writing interfaces for the messages.
I'm expecting 1st message, TRX config request from osmo-nitb and do not see it. I was thinking, once the abis interface is up (OML link), osmo-nitb will trigger TRX configuration and then based on the response from BTS, other configurations. Does osmo-nitb require some kind of handshake from the BTS side to send the TRX configuration?
I shall be really grateful to hear advices from the experts out there. I can give you more information if required.
Thanks,
Jason D'Souza
I just wanted to ask before I spend a lot of time with it. Does the
new HO algorithm also works with non-IP based BTSes like Nokia metro
or insite? Or at least in theory it should work?
Because the handover is not working with the current algo for Nokia, I
want to give the new one a try.
Csaba
Hi,
I am setting up openbsc with LCR and Asterisk to provide external
connectivity for the GSM clients, and I encountered and interesting
problem.
If the GSM phone initiates a voice call towards a SIP phone it works
perfectly, the voice goes both ways, the quality is OK, everything is
fine.
But when the SIP phones initiates a voice call towards the GSM phone,
only the SIP phone can hear the voice of the GSM phone, and not the
other way around (half sided call). The connection setup works both
ways just fine.
The GSM and the SIP phone can also call the asterisk test numbers, and even can do
echo test just fine. The two GSM phones can call each other too
without any problem.
Does somebody has any idea what could go wrong?
Config:
E1 based Nokia BTS with DAHDI card and TCH/F FR codec.
The SIP phone uses Alaw, LCR also set to use Alaw.
The LCR is bridged to Asterisk, interface.conf:
[GSM]
gsm-bs
tones yes
earlyb no
bridge ast
[ast]
remote asterisk
context from-lcr
earlyb no
tones yes
bridge GSM
routing.conf is completely empty.
Astrisk SIP.conf:
[general]
context=incoming
disallow=all
allow=alaw
allow=ulaw
allow=gsm
transport=udp
udpbindaddr=0.0.0.0
tcpenable=no
tcpbindaddr=0.0.0.0
tlsenable=no
tlsbindaddr=0.0.0.0
[5010]
type=friend
username=5010
secret=123456
dtmfmode=rfc2833
callerid="5010" <5010>
host=dynamic
canreinvite=no
context=myphones
Asterisk extensions.conf
[general]
static=yes
writeprotect=no
clearglobalvars=no
[globals]
; Global variables goes here
[incoming]
; Nothing should land here yet, but every context should end in
; a Hangup(), so we do that.
exten => s,1,Hangup()
[myphones]
; When we dial something from the phones we just added in
; sip.conf, Asterisk will look for a matching extension here,
; in this context.
; SIP phone
exten => 5010,1,Dial(SIP/5010)
exten => 5010,n,Hangup()
; Another SIp phone
;exten => 1001,1,Dial(SIP/1001)
;exten => 1001,n,Hangup()
; GSM phone 1
exten => 12346,1,Dial(LCR/ast/${EXTEN:0},60)
exten => 12346,n,Hangup()
; GSM phone 2
exten => 12345,1,Dial(LCR/ast/${EXTEN:0},60)
exten => 12345,n,Hangup()
; Testing extension
exten => 201,1,Answer()
exten => 201,n,Playback(levan_polka.mp3)
exten => 201,n,Hangup()
; Echo-test, it is good to test if we have sound in both directions.
; The call is answered
exten => 202,1,Answer()
; Welcome message is played
exten => 202,n,Playback(dir-welcome)
; Play information about the echo test
exten => 202,n,Playback(demo-echotest)
; Do the echo test, end with the # key
exten => 202,n,Echo()
; Plays information that the echo test is done
exten => 202,n,Playback(demo-echodone)
; Goodbye message is played
exten => 202,n,Playback(vm-goodbye)
; Hangup() ends the call, hangs up the line
exten => 202,n,Hangup()
[from-lcr]
include => myphones
exten => _X.,1,Dial(LCR/ast/${EXTEN:0},60)
exten => 5010,1,Dial(SIP/5010)
exten => 5010,n,Hangup()
BR,
Csaba
I am more and more sure that the my failing handover situation has a
deeper root cause and it is not actually the handover which is
failing, but there should be a channel allocation problem. And there
it is.
The following log is made during the send of an SMS to the mobile from
the BSC CLI:
Tue Oct 29 15:06:15 2013 <001e> sms_queue.c:220 Attempting to send 20 SMS
Tue Oct 29 15:06:15 2013 <0000> chan_alloc.c:457 (bts=0,trx=0,ts=0,ss=1) starting release sequence
Tue Oct 29 15:06:15 2013 <0000> abis_rsl.c:892 (bts=0,trx=0,ts=0,ss=1) RSL RLL RELEASE REQ (link_id=0x03, reason=1)
Tue Oct 29 15:06:15 2013 <0003> gsm_04_08_utils.c:231 Sending Channel Release: Chan: Number: 1 Type: 1
Tue Oct 29 15:06:15 2013 <0004> abis_rsl.c:634 (bts=0,trx=0,ts=0,ss=1) DEACTivate SACCH CMD
Tue Oct 29 15:06:15 2013 <0004> abis_rsl.c:1070 (bts=0,trx=0,ts=0,ss=1): MEAS RES for inactive channel
Tue Oct 29 15:06:15 2013 <001a> input/dahdi.c:320 send returns -1 instead of 160
Tue Oct 29 15:06:15 2013 <001a> input/dahdi.c:320 send returns -1 instead of 160
Tue Oct 29 15:06:15 2013 <0000> abis_rsl.c:1657 (bts=0,trx=0,ts=0,ss=1) SAPI=0 RELEASE INDICATION
Tue Oct 29 15:06:15 2013 <0004> abis_rsl.c:1628 (bts=0,trx=0,ts=0,ss=1) waiting for SAPI=3 to be released.
Tue Oct 29 15:06:21 2013 <0000> abis_rsl.c:1657 (bts=0,trx=0,ts=0,ss=1) SAPI=3 Tue Oct 29 15:06:21 2013 <0000> abis_rsl.c:1599 (bts=0,trx=0,ts=0,ss=1) ERROR INDICATION cause=Timer T200 expired (N200+1) times
Tue Oct 29 15:06:21 2013 <0004> abis_rsl.c:680 (bts=0,trx=0,ts=0,ss=1) RF Channel Release CMD due error 1
Tue Oct 29 15:06:21 2013 <0004> abis_rsl.c:634 (bts=0,trx=0,ts=0,ss=1) DEACTivate SACCH CMD
Tue Oct 29 15:06:21 2013 <0000> abis_rsl.c:892 (bts=0,trx=0,ts=0,ss=1) RSL RLL RELEASE REQ (link_id=0x03, reason=1)
Tue Oct 29 15:06:21 2013 <0004> abis_rsl.c:732 (bts=0,trx=0,ts=0,ss=1) RF CHANNEL RELEASE ACK
Tue Oct 29 15:06:23 2013 <0004> abis_rsl.c:649 (bts=0,trx=0,ts=0,ss=1) is back in operation.
As you can see, although SAPI=3 was requested to be release, we never
got any RELEASE INDICATION for that. And after some time, the radio
link will be disconnected with T200 timeout.
I tried to send another SMS the same way like above, and get a more
interesting log:
Tue Oct 29 15:54:45 2013 <001e> sms_queue.c:220 Attempting to send 20 SMS
Tue Oct 29 15:54:46 2013 <0000> chan_alloc.c:457 (bts=0,trx=0,ts=0,ss=1) starting release sequence
Tue Oct 29 15:54:46 2013 <0000> abis_rsl.c:892 (bts=0,trx=0,ts=0,ss=1) RSL RLL RELEASE REQ (link_id=0x03, reason=1)
Tue Oct 29 15:54:46 2013 <0003> gsm_04_08_utils.c:231 Sending Channel Release: Chan: Number: 1 Type: 1
Tue Oct 29 15:54:46 2013 <0004> abis_rsl.c:634 (bts=0,trx=0,ts=0,ss=1) DEACTivate SACCH CMD
Tue Oct 29 15:54:46 2013 <001a> input/dahdi.c:320 send returns -1 instead of 160
Tue Oct 29 15:54:46 2013 <001a> input/dahdi.c:320 send returns -1 instead of 160
Tue Oct 29 15:54:46 2013 <0004> abis_rsl.c:1070 (bts=0,trx=0,ts=0,ss=1): MEAS RES for inactive channel
Tue Oct 29 15:54:46 2013 <0000> abis_rsl.c:1657 (bts=0,trx=0,ts=0,ss=1) SAPI=0 RELEASE INDICATION
Tue Oct 29 15:54:46 2013 <0004> abis_rsl.c:1628 (bts=0,trx=0,ts=0,ss=1) waiting for SAPI=3 to be released.
...
Tue Oct 29 16:00:46 2013 <0004> abis_rsl.c:1467 (bts=0,trx=0,ts=0,ss=2) Activating ARFCN(885) SS(2) lctype SDCCH r=LOCATION_UPDATE ra=0x08 ta=0
Tue Oct 29 16:00:46 2013 <0004> abis_rsl.c:1169 (bts=0,trx=0,ts=0,ss=2) CHANNEL ACTIVATE ACK
As you can see, SAPI=3 again not getting released properly, but this
time there is not even a T200 timeout and the SACCH channel got stuck,
never released. The last two line is the periodic LA update, and you can see
that it uses ss=2, because the BSC thinks that ss=1 is still in use.
This is the very same issue I noticed with the handover:
[0;mFri Jul 26 12:45:29 2013 <000c> handover_decision.c:203 (bts=0,trx=0,ts=2): Cell on ARFCN 123 is better: [0;mFri Jul 26 12:45:29 2013 <000c> handover_logic.c:96 (old_lchan on BTS 0, new BTS 1)
[0;mStarting handover
[0;m[1;35mFri Jul 26 12:45:29 2013 <0004> abis_rsl.c:1165 (bts=1,trx=0,ts=2,ss=0) CHANNEL ACTIVATE ACK
[0;mFri Jul 26 12:45:29 2013 <000c> handover_logic.c:204 handover activate ack, send HO Command
[0;m[1;35mFri Jul 26 12:45:29 2013 <0004> abis_rsl.c:1138 (bts=1,trx=0,ts=2,ss=0) HANDOVER DETECT [0;m[1;35maccess delay = 0
[0;m[1;31mFri Jul 26 12:45:29 2013 <0000> abis_rsl.c:1621 (bts=1,trx=0,ts=2,ss=0) SAPI=0 [0;m[1;31mESTABLISH INDICATION
[0;m[1;31mFri Jul 26 12:45:29 2013 <0000> abis_rsl.c:1621 (bts=1,trx=0,ts=2,ss=0) SAPI=0 [0;m[1;31mDATA INDICATION
[0;m[1;34mFri Jul 26 12:45:29 2013 <0003> bsc_api.c:515 HANDOVER COMPLETE cause = Normal event
[0;mFri Jul 26 12:45:29 2013 <000c> handover_logic.c:261 Subscriber 244153333330126 HO from BTS 0->1 on ARFCN 885->123
[0;m[1;31mFri Jul 26 12:45:29 2013 <0000> chan_alloc.c:405 (bts=0,trx=0,ts=2,ss=0) starting release sequence
[0;m[1;31mFri Jul 26 12:45:29 2013 <0000> abis_rsl.c:891 (bts=0,trx=0,ts=2,ss=0) RSL RLL RELEASE REQ (link_id=0x00, reason=1)
[0;m[1;35mFri Jul 26 12:45:29 2013 <0004> abis_rsl.c:1069 (bts=0,trx=0,ts=2,ss=0): MEAS RES for inactive channel
[0;m[1;35mFri Jul 26 12:45:30 2013 <0004> abis_rsl.c:1069 (bts=0,trx=0,ts=2,ss=0): MEAS RES for inactive channel
[0;m[1;35mFri Jul 26 12:45:30 2013 <0004> abis_rsl.c:1069 (bts=0,trx=0,ts=2,ss=0): MEAS RES for inactive channel
......
[0;m[1;35mFri Jul 26 12:45:40 2013 <0004> abis_rsl.c:1069 (bts=0,trx=0,ts=2,ss=0): MEAS RES for inactive channel
[0;m[1;35mFri Jul 26 12:45:42 2013 <0004> abis_rsl.c:1069 (bts=0,trx=0,ts=2,ss=0): MEAS RES for inactive channel
[0;m[1;35mFri Jul 26 12:45:43 2013 <0004> abis_rsl.c:1069 (bts=0,trx=0,ts=2,ss=0): MEAS RES for inactive channel
[0;m[1;35mFri Jul 26 12:45:44 2013 <0004> abis_rsl.c:1069 (bts=0,trx=0,ts=2,ss=0): MEAS RES for inactive channel
[0;m[1;35mFri Jul 26 12:45:44 2013 <0004> abis_rsl.c:988 (bts=0,trx=0,ts=2,ss=0) CONNECTION FAIL: RELEASING [0;m[1;35mCAUSE=0x01(Radio Link Failure) [0;m[1;35m
[0;m[1;35mFri Jul 26 12:45:44 2013 <0004> abis_rsl.c:679 (bts=0,trx=0,ts=2,ss=0) RF Channel Release CMD due error 1
[0;m[1;35mFri Jul 26 12:45:44 2013 <0004> abis_rsl.c:633 (bts=0,trx=0,ts=2,ss=0) DEACTivate SACCH CMD
[0;m[1;31mFri Jul 26 12:45:44 2013 <0000> abis_rsl.c:891 (bts=0,trx=0,ts=2,ss=0) RSL RLL RELEASE REQ (link_id=0x40, reason=1)
[0;m[1;35mFri Jul 26 12:45:44 2013 <0004> abis_rsl.c:1069 (bts=0,trx=0,ts=2,ss=0): MEAS RES for inactive channel
[0;m[1;35mFri Jul 26 12:45:44 2013 <0004> abis_rsl.c:731 (bts=0,trx=0,ts=2,ss=0) RF CHANNEL RELEASE ACK
[0;m[1;35mFri Jul 26 12:45:46 2013 <0004> abis_rsl.c:648 (bts=0,trx=0,ts=2,ss=0) is back in operation.
As you can see, from the BSC point of view the handover was
successful, but it was not able to release the old channel, we never
got any RELEASE INDICATION. This is why we get the Radio Link Failure
eventually, because the phone is not there anymore, but the channel
yet not closed. Because the release of the old channel is not
successful, OpenBSC never tries to remap the TRAU to the new channel,
therefore both phones got disconnected (properly).
This is as far as I can get with this problem. Maybe now that I
narrowed down the root cause, someone can help me with it.
I still think this problem is not Nokia specific, maybe other BTSes
are affected (BS11 or other E1 based units).
Csaba
Hi Caleb,
The segfault is introduced with this patch:
http://cgit.osmocom.org/libosmocore/commit/?id=f5a079f739c57d8be7c59149fd45…
Is is not really a bugfix, but if you just comment out the following
part from lapd_core.c added by the above patch and recompile openbsc, it will help:
dl->tx_hist = NULL;
The problem is probably related to the RESET function, because Nokia
units are being reset during the initialization phase, and
bootstrapped after that. The reason for this is if this reset is not
concluded, then the BTS will not apply certain configuration parameters
(e.g. change in ARFCN, transmit power, timeslot configuration).
I strongly suggest you anyway, to start with TCF/F FR configuration,
and if you see major alarm "BCF operation degraded: difference between
PCM and BTS clock", it means that your E1 card is not able to provide
accurate enough timing for the BTS. According to Nokia, you need +-5Hz
accuracy on the E1 to meet the timing requirements, but even then at
least 20-25 minutes of operation is needed for the BTS clock to be
synced and the alarm goes away. Usually DAHDI or other E1 cards clock
are not precise enough but don't worry: even with the alarm you can
make pretty good quality phone calls, but remember: if you experience
severe call quality degradation, or the phones cannot camp, or they
loosing the network all the time, it is going to be a timing related
problem. Anyway, do you have the Nokia InSite manager software? If not
just write me a mail and I can help with that. You definitely going to
need that and an LMP cable to do the initial setup, before you can get
started with OpenBSC.
BR,
Csaba