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
Hey Peter,
> I'd suggest to make LCR use SIP for communcation with Asterisk. See
> http://stuge.se/lcr.txt for a minimal example of LCR configuration.
Do you have some more example configuration files for the Asterisk end
of the SIP trunk?
> Since you're using bridging you might also want to try rtp-bridge
> between GSM and SIP, which could allow GSM phones and SIP phones to
> negotiate codec directly, avoiding any transcoding. (But maybe it
> only works with Abis over IP and not over ISDN? I'm not sure.)
I am almost sure that RTP bridge can only be used with IP based BTSes
which I don't have. My units are connecting via E1 dahdi.
> You can of course continue to debug the LCR-Asterisk module but I
> would suggest moving to SIP since I think working with SIP on both
> legs makes debugging a bit easier.
My problem is that I made test calls an analyzed the logs at both LCR
and Asterisk end, and there is no difference between a good and a half
sided call. First, I forced the GSM phones to use TCH/F FR only, then
I forced LCR and Asterisk SIP clients to use Alaw only (SIP clients
are not supporting any GSM codec). Transcoding obviously happens
between TCH/F FR and Alaw, but how on earth is possible that the
direction of the call can affect that this transcoding is going to
be a success or not? If its a transcoding failure it shouldn't work in
any direction. If its a call routing problem, then the call shouldn't
make its way to the called party. But none of this is what happens.
So I really don't know where to look, or how to debug this problem.
BR,
Csaba
Hi,
When sending sms via openbsc commandline the sms gets extra data added
to its tail.
The coversion from text to PDU results in the converted data + garbage,
this data is posted to the 'sms' database 'user-data' field, and then sent.
in the 'sms' database you can verify that a short sms text results in
long user-data
phone to phone sms works without problems.
Henry
Hi,
I am trying to modify osmocomBB to work without the phone as layer 1.
My goal is that application will using socket to communicate with BTS
(modified BTS which can send and receive message throught sockets).
I analyzed the osmocomBB code and I found that I'll have to modify
osmocon.c (host/osmocon/osmocon.c) file. This file is interface between
serial communication and layer2. If I am right, I have to do this changes:
1. Delete functions handle the serial interface
2. Add new tool server to dnload structure
3. Creating new tool server for L1 interface (UNIX socket or IP socket
with GSMTAP)
4. Add callback function for reading from layer2 socket and forward
this messages to L1 socket interface.
Simplified I have to listen and forward packets from BTS to layer2
socket and from L2 to L1.
Do I think in right direction or I am wrong and it will need more
modifications?
Best regards,
Miroslav Babjak
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.
Based on observation, constant blinking orange seems to indicate the layer
2 link isn't up (eg it's powered but Ethernet isn't connected). Solid
orange is good. Once it's fully booted it seems to be solid orange with a
very quick flash off once a second seems to indicate it's trying to find
the BSC
> 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.
>
> ipaccess-find / btsinstaller only ever seem to find my BSCs when the
machine they're running on is on the same subnet.
The easiest way to track down a rogue bts is to connect it directly to a
spare network port in the pc and then run wireshark on it. On boot my BTS
sends a number of dhcp inform requests broadcasting it's IP and then starts
blasting packets at the BSC address.
Hope this helps,
Hi all,
I know this problem has been dealt previously in a minor variation but
please help me out here.
I'm trying to configure OpenBSC using the USRP N210 device and followed the
same network from scratch installation.
I got up to the part where sysmobts gives the error and corrected it by
editing the makefile.
But unlike others my 'make' command is giving me an error in the rsl.c
file.
make[2]: Entering directory
`/home/prabu/OpenBSC-OpenBTS/osmo-bts/src/common'
CC rsl.o
rsl.c:140:2: warning: #warning merge lchan_lookup with OpenBSC [-Wcpp]
rsl.c: In function ‘rsl_rx_chan_activ’:
rsl.c:779:53: error: ‘struct gsm_lchan’ has no member named ‘mr_bts_lv’
rsl.c:783:15: error: ‘struct gsm_lchan’ has no member named ‘mr_bts_lv’
rsl.c: In function ‘rsl_rx_mode_modif’:
rsl.c:1028:53: error: ‘struct gsm_lchan’ has no member named ‘mr_bts_lv’
rsl.c:1032:15: error: ‘struct gsm_lchan’ has no member named ‘mr_bts_lv’
make[2]: *** [rsl.o] Error 1
make[2]: Leaving directory `/home/prabu/OpenBSC-OpenBTS/osmo-bts/src/common'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/prabu/OpenBSC-OpenBTS/osmo-bts/src'
make: *** [all-recursive] Error 1
Can someone please help me out in what this error deals with. Or people who
successfully completed the installation could tell me what they did
differently
Regards,
Jijo
Before the assigned value (0xFF) was truncated, reg->text[0] is of
type char. A corresponding test for the same value in openbsc could
only fail.
---
src/gsm/gsm0480.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gsm/gsm0480.c b/src/gsm/gsm0480.c
index 92a62dc..dbacefc 100644
--- a/src/gsm/gsm0480.c
+++ b/src/gsm/gsm0480.c
@@ -234,7 +234,7 @@ static int parse_ussd(const struct gsm48_hdr *hdr, uint16_t len, struct ussd_req
case GSM0480_MTYPE_RELEASE_COMPLETE:
LOGP(0, LOGL_DEBUG, "USS Release Complete\n");
/* could also parse out the optional Cause/Facility data */
- req->text[0] = 0xFF;
+ req->text[0] = '\0';
break;
case GSM0480_MTYPE_REGISTER:
case GSM0480_MTYPE_FACILITY:
--
1.8.3.2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi everyone,
we (Rhizomatica.org) are currently setting up a OpenBSC-based network
in Oaxaca, Mexico. I've been looking into the code and found the
token-based authentication which was used at the HAR2009 (I still
remember receiving that SMS) :)
I understand that each phone will get an SMS and then disconnect from
the network. What is the API to confirm the token and activate the
account? I vaguely remember a web interface at the time, but I could
be wrong...
Thanks a lot!
Ciaby
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iF4EAREKAAYFAlJXerwACgkQC30ZhxNccpFbuAEAjJN+DEjz5rlYBbYJeBw2884e
SuSvNHud+XfcDJL0IaYBAJFFIJbEG6XtdTADCt4lyvdaRcbTDn0B2f9NZEod8kJU
=KqiR
-----END PGP SIGNATURE-----
This patchset solves the issue with the wrong sender address for inbound SMPP
SMS messages. It then further cleans up DB structure to remove 'receiver_id'
field from the sms table.
The only issue with this code is that it somehow breaks channel_test test,
because it depended on some fragile linker behavior. The last patch in the
series fixes compilation of the test, but the test asserts. I hope the test
author will find a more proper way to implement it, but at this moment I
propose to disable it.
Alexander Chemeris (4):
bsc: Allow subscr_put() to be called with subscr->net=NULL.
sms: Add a function to update DB scheme v3 to v4.
msc: Do not store received id in the SMS database.
This is a hack to fix channel_test.c compilation.
Holger Hans Peter Freyther (1):
sms: Kill the sms->sender and use addr/ton/npi throughout the code
openbsc/include/openbsc/gsm_data.h | 1 -
openbsc/src/libbsc/gsm_subscriber_base.c | 2 +-
openbsc/src/libmsc/db.c | 257 ++++++++++++++++++++++++------
openbsc/src/libmsc/gsm_04_11.c | 9 +-
openbsc/src/libmsc/smpp_openbsc.c | 5 +-
openbsc/tests/channel/Makefile.am | 4 +-
openbsc/tests/channel/channel_test.c | 12 --
7 files changed, 215 insertions(+), 75 deletions(-)
--
1.7.9.5
In case of a headroom in a message, the 'head' pointer will not point to
the actual data.
---
src/osmo-bts-sysmo/l1_transp_fwd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/osmo-bts-sysmo/l1_transp_fwd.c b/src/osmo-bts-sysmo/l1_transp_fwd.c
index 5050705..87c230b 100644
--- a/src/osmo-bts-sysmo/l1_transp_fwd.c
+++ b/src/osmo-bts-sysmo/l1_transp_fwd.c
@@ -95,7 +95,7 @@ static int fwd_read_cb(struct osmo_fd *ofd)
static int prim_write_cb(struct osmo_fd *ofd, struct msgb *msg)
{
/* write to the fd */
- return write(ofd->fd, msg->head, msg->len);
+ return write(ofd->fd, msg->l1h, msgb_l1len(msg));
}
int l1if_transport_open(int q, struct femtol1_hdl *fl1h)
--
1.8.1.5
Hi Guys,
I am working with Nokia InSite and MetroSite units and now it is
obvious, that I have a timing accuracy problem with my E1 dahdi card.
According to "dahdi_test" I have a magnitude worse accuracy compared
to the GSM specs. I can measure 99.995% accuracy compared to the
required 99.99975%.
MY question is what can I do about it? My first idea was to replace
the oscillator on the card, which by default has a 20ppm oscillator on
it. I was able to find some 10ppm oscillators but they are not
matching the required frequency (8.192MHz).
It would be nice to hear some ideas about how can I solve this issue.
Thanks!
BR,
Csaba
This patch set is mostly minor fixes and clean ups, with the exception of
the last two patches ("subscriber create" VTY command and a standard way for
printing a subscriber's info).
I would appreciate merging this patches to master, as I'm working onmore code
which depends on them.
Alexander Chemeris (6):
Fix copy-paste error in console output in db_test.
Fix typo ',' -> ';' at the end of a line.
Fix typo in console output: "PEROIDOC" -> "PERIODIC".
Slight clean up of the code in gsm340_rx_tpdu() and a fix for an
unlikely, but possible memory leak there.
Add "subscriber create" VTY command.
Introduce a standard way for printing a subscriber's info.
openbsc/include/openbsc/gsm_subscriber.h | 4 ++++
openbsc/src/libmsc/db.c | 2 +-
openbsc/src/libmsc/gsm_04_08.c | 2 +-
openbsc/src/libmsc/gsm_04_11.c | 7 ++++---
openbsc/src/libmsc/vty_interface_layer3.c | 27 +++++++++++++++++++++++++++
openbsc/tests/db/db_test.c | 2 +-
6 files changed, 38 insertions(+), 6 deletions(-)
--
1.7.9.5
Hi list,
I want to integrate the OpenBSC with the Mobicents gateway. However, OpenBSC encapsulates the GSM MAP protocol in a DTAP header, while Mobicents expects a TCAP.
The question is: Is possible to use the TCAP protocol in OpenBSC ?
PS: Currently I am working with the USSD in OpenBSC. I performed some changes in the code and now we implemented the USSD request,facility and release-complete messages. In other words, now we are able to implement menus in USSD operations.
Best Regards