OpenBSC October 2013

openbsc@lists.osmocom.org

21 participants
45 discussions

by mosbah abdelkader

> I don't understand. This callback will be called with data you need to write > to the network. In case of MTP Level3 you will need to wrap that around the > msgb you got. I means: is the interaction with mtp3 layer implemented (is sending sccp data by mtp3 implemented by the library?)? Also, what about the reception of data from mtp3 layer. is that implemented in the sccp lib. I am asking these questions because I see the code of mtp3 in the lib but no significant call is present in the sccp part of the lib. Thank you for your help.

1 month

[PATCH] sms_queue, smpp: Refactor MO SUBMIT code to make further changes easier.

by Alexander Chemeris

This is required to implement normal prefix/regexp routing in addition to the current "if unroutable" model. --- openbsc/src/libmsc/gsm_04_11.c | 63 +++++++++++++++++++++++----------------- 1 file changed, 37 insertions(+), 26 deletions(-) diff --git a/openbsc/src/libmsc/gsm_04_11.c b/openbsc/src/libmsc/gsm_04_11.c index e554b74..7e8ede8 100644 --- a/openbsc/src/libmsc/gsm_04_11.c +++ b/openbsc/src/libmsc/gsm_04_11.c @@ -279,6 +279,39 @@ static int gsm340_gen_tpdu(struct msgb *msg, struct gsm_sms *sms) return msg->len - old_msg_len; } +static int sms_queue_try_deliver(struct gsm_subscriber_connection *conn, + struct msgb *msg, struct gsm_sms *gsms) +{ + /* determine gsms->receiver based on dialled number */ + gsms->receiver = subscr_get_by_extension(conn->bts->network, gsms->dst.addr); + if (!gsms->receiver) { + rc = GSM411_RP_CAUSE_MO_NUM_UNASSIGNED; + goto out; + } + + switch (sms_mti) { + case GSM340_SMS_SUBMIT_MS2SC: + /* MS is submitting a SMS */ + rc = gsm340_rx_sms_submit(msg, gsms); + break; + case GSM340_SMS_COMMAND_MS2SC: + case GSM340_SMS_DELIVER_REP_MS2SC: + LOGP(DLSMS, LOGL_NOTICE, "Unimplemented MTI 0x%02x\n", sms_mti); + rc = GSM411_RP_CAUSE_IE_NOTEXIST; + break; + default: + LOGP(DLSMS, LOGL_NOTICE, "Undefined MTI 0x%02x\n", sms_mti); + rc = GSM411_RP_CAUSE_IE_NOTEXIST; + break; + } + + if (!rc && !gsms->receiver) + rc = GSM411_RP_CAUSE_MO_NUM_UNASSIGNED; + +out: + return rc; +} + /* process an incoming TPDU (called from RP-DATA) * return value > 0: RP CAUSE for ERROR; < 0: silent error; 0 = success */ static int gsm340_rx_tpdu(struct gsm_subscriber_connection *conn, struct msgb *msg) @@ -393,44 +426,22 @@ static int gsm340_rx_tpdu(struct gsm_subscriber_connection *conn, struct msgb *m /* FIXME: This looks very wrong */ send_signal(0, NULL, gsms, 0); - /* determine gsms->receiver based on dialled number */ - gsms->receiver = subscr_get_by_extension(conn->bts->network, gsms->dst.addr); - if (!gsms->receiver) { + rc = sms_queue_try_deliver(conn, msg, gsms); + if (rc == GSM411_RP_CAUSE_MO_NUM_UNASSIGNED) { #ifdef BUILD_SMPP rc = smpp_try_deliver(gsms, conn); - if (rc == 1) { - rc = 1; /* cause 1: unknown subscriber */ + if (rc == GSM411_RP_CAUSE_MO_NUM_UNASSIGNED) { osmo_counter_inc(conn->bts->network->stats.sms.no_receiver); } else if (rc < 0) { - rc = 21; /* cause 21: short message transfer rejected */ + rc = GSM411_RP_CAUSE_MO_NUM_UNASSIGNED; /* FIXME: handle the error somehow? */ } #else - rc = 1; /* cause 1: unknown subscriber */ osmo_counter_inc(conn->bts->network->stats.sms.no_receiver); #endif goto out; } - switch (sms_mti) { - case GSM340_SMS_SUBMIT_MS2SC: - /* MS is submitting a SMS */ - rc = gsm340_rx_sms_submit(msg, gsms); - break; - case GSM340_SMS_COMMAND_MS2SC: - case GSM340_SMS_DELIVER_REP_MS2SC: - LOGP(DLSMS, LOGL_NOTICE, "Unimplemented MTI 0x%02x\n", sms_mti); - rc = GSM411_RP_CAUSE_IE_NOTEXIST; - break; - default: - LOGP(DLSMS, LOGL_NOTICE, "Undefined MTI 0x%02x\n", sms_mti); - rc = GSM411_RP_CAUSE_IE_NOTEXIST; - break; - } - - if (!rc && !gsms->receiver) - rc = GSM411_RP_CAUSE_MO_NUM_UNASSIGNED; - out: sms_free(gsms); -- 1.7.9.5

11 years, 3 months

Unbounded AGCH queue in OsmoBTS

by Alexander Chemeris

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

11 years, 4 months

Hard reset NanoBTS after forgetting static IP

by Luca Bongiorni

-----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-----

11 years, 7 months

Openbsc support for new BTS

by Jason DSouza

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

11 years, 7 months

New handover algorithm with Nokia BTS

by Sipos Csaba

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

11 years, 7 months

OpenBSC + LCR + Asterisk = half sided calls in one direction

by Sipos 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

11 years, 7 months

[PATCH] bsc/ussd: Send faked CM Service Accept before sending USSD

by Jacob Erlbeck

The MS do not show the USSD messages yet. This patch modifies the implementation to insert a CM Service Accept before the ussdNotify to finish the establishment of the MM connection according to 3GPP TS 04.10/3.2.1. This fix has been tested with a Blackberry phone that has shown an ussd_grace_txt after rf_locked has been set to '1'. Without this patch, that message wasn't shown. The phone has sent a CC Setup and other messages before processing the channel release message sent by the BSC, but these messages have not been forwarded to the MSC (as expected). Ticket: OW#957 Sponsored-by: On-Waves ehf --- openbsc/include/openbsc/gsm_04_08.h | 3 +++ openbsc/src/libmsc/gsm_04_08.c | 4 ++-- openbsc/src/osmo-bsc/Makefile.am | 6 ++++-- openbsc/src/osmo-bsc/osmo_bsc_api.c | 17 +++++++++++------ 4 files changed, 20 insertions(+), 10 deletions(-) diff --git a/openbsc/include/openbsc/gsm_04_08.h b/openbsc/include/openbsc/gsm_04_08.h index 2f5aaa9..8df7b73 100644 --- a/openbsc/include/openbsc/gsm_04_08.h +++ b/openbsc/include/openbsc/gsm_04_08.h @@ -39,6 +39,9 @@ void gsm_net_update_ctype(struct gsm_network *net); int gsm48_tx_mm_info(struct gsm_subscriber_connection *conn); int gsm48_tx_mm_auth_req(struct gsm_subscriber_connection *conn, uint8_t *rand, int key_seq); int gsm48_tx_mm_auth_rej(struct gsm_subscriber_connection *conn); +int gsm48_tx_mm_serv_ack(struct gsm_subscriber_connection *conn); +int gsm48_tx_mm_serv_rej(struct gsm_subscriber_connection *conn, + enum gsm48_reject_value value); int gsm48_send_rr_release(struct gsm_lchan *lchan); int gsm48_send_rr_ciph_mode(struct gsm_lchan *lchan, int want_imeisv); int gsm48_send_rr_app_info(struct gsm_subscriber_connection *conn, uint8_t apdu_id, diff --git a/openbsc/src/libmsc/gsm_04_08.c b/openbsc/src/libmsc/gsm_04_08.c index c41443e..df985ca 100644 --- a/openbsc/src/libmsc/gsm_04_08.c +++ b/openbsc/src/libmsc/gsm_04_08.c @@ -804,14 +804,14 @@ int gsm48_tx_mm_auth_rej(struct gsm_subscriber_connection *conn) return gsm48_tx_simple(conn, GSM48_PDISC_MM, GSM48_MT_MM_AUTH_REJ); } -static int gsm48_tx_mm_serv_ack(struct gsm_subscriber_connection *conn) +int gsm48_tx_mm_serv_ack(struct gsm_subscriber_connection *conn) { DEBUGP(DMM, "-> CM SERVICE ACK\n"); return gsm48_tx_simple(conn, GSM48_PDISC_MM, GSM48_MT_MM_CM_SERV_ACC); } /* 9.2.6 CM service reject */ -static int gsm48_tx_mm_serv_rej(struct gsm_subscriber_connection *conn, +int gsm48_tx_mm_serv_rej(struct gsm_subscriber_connection *conn, enum gsm48_reject_value value) { struct msgb *msg; diff --git a/openbsc/src/osmo-bsc/Makefile.am b/openbsc/src/osmo-bsc/Makefile.am index 63972c8..9c091af 100644 --- a/openbsc/src/osmo-bsc/Makefile.am +++ b/openbsc/src/osmo-bsc/Makefile.am @@ -16,5 +16,7 @@ osmo_bsc_LDADD = $(top_builddir)/src/libbsc/libbsc.a \ $(top_builddir)/src/libcommon/libcommon.a \ $(top_builddir)/src/libctrl/libctrl.a \ $(top_builddir)/src/libcommon/libcommon.a \ - $(LIBOSMOSCCP_LIBS) $(LIBOSMOCORE_LIBS) \ - $(LIBOSMOGSM_LIBS) $(LIBOSMOVTY_LIBS) $(COVERAGE_LDFLAGS) $(LIBOSMOABIS_LIBS) + -ldbi -ldl $(LIBOSMOSCCP_LIBS) \ + $(LIBSMPP34_LIBS) $(LIBOSMOCORE_LIBS) \ + $(LIBOSMOGSM_LIBS) $(LIBOSMOVTY_LIBS) $(COVERAGE_LDFLAGS) \ + $(LIBOSMOABIS_LIBS) diff --git a/openbsc/src/osmo-bsc/osmo_bsc_api.c b/openbsc/src/osmo-bsc/osmo_bsc_api.c index 675bbb2..8288d3b 100644 --- a/openbsc/src/osmo-bsc/osmo_bsc_api.c +++ b/openbsc/src/osmo-bsc/osmo_bsc_api.c @@ -87,8 +87,8 @@ static void bsc_cipher_mode_compl(struct gsm_subscriber_connection *conn, queue_msg_or_return(resp); } -static void bsc_send_ussd_notification(struct gsm_subscriber_connection *conn, - struct msgb *msg, const char *text) +static void bsc_send_ussd_no_srv(struct gsm_subscriber_connection *conn, + struct msgb *msg, const char *text) { struct gsm48_hdr *gh; int8_t pdisc; @@ -119,10 +119,14 @@ static void bsc_send_ussd_notification(struct gsm_subscriber_connection *conn, } if (drop_message) { - LOGP(DMSC, LOGL_DEBUG, "Skipping (not sending) USSD message: '%s'\n", text); + LOGP(DMSC, LOGL_DEBUG, "Skipping (not sending) USSD message: '%s'\n", + text); return; } + LOGP(DMSC, LOGL_INFO, "Sending CM Service Accept\n"); + gsm48_tx_mm_serv_ack(conn); + LOGP(DMSC, LOGL_INFO, "Sending USSD message: '%s'\n", text); gsm0480_send_ussdNotify(conn, 1, text); gsm0480_send_releaseComplete(conn); @@ -143,7 +147,8 @@ static int bsc_compl_l3(struct gsm_subscriber_connection *conn, struct msgb *msg msc = bsc_find_msc(conn, msg); if (!msc) { LOGP(DMSC, LOGL_ERROR, "Failed to find a MSC for a connection.\n"); - bsc_send_ussd_notification(conn, msg, conn->bts->network->bsc_data->ussd_no_msc_txt); + bsc_send_ussd_no_srv(conn, msg, + conn->bts->network->bsc_data->ussd_no_msc_txt); return -1; } @@ -164,9 +169,9 @@ static int complete_layer3(struct gsm_subscriber_connection *conn, if (ret != BSC_CON_SUCCESS) { /* allocation has failed */ if (ret == BSC_CON_REJECT_NO_LINK) - bsc_send_ussd_notification(conn, msg, msc->ussd_msc_lost_txt); + bsc_send_ussd_no_srv(conn, msg, msc->ussd_msc_lost_txt); else if (ret == BSC_CON_REJECT_RF_GRACE) - bsc_send_ussd_notification(conn, msg, msc->ussd_grace_txt); + bsc_send_ussd_no_srv(conn, msg, msc->ussd_grace_txt); return BSC_API_CONN_POL_REJECT; } -- 1.7.9.5

11 years, 7 months

Abis RSL and channel allocation issue

by Sipos 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

11 years, 7 months

Re: Abis RSL and channel allocation issue

by Sipos Csaba

For my previous post in the subject: show lchan clearly indicates that the logical connections were never got disconnected. When the above output as made, there were no activity on the BTS for more than 20 minutes, yet these channels are not released: OpenBSC# show lchan BTS 0, TRX 0, Timeslot 0, Lchan 0: Type SDCCH Connection: 0, State: RELEASE REQUESTED BS Power: 22 dBm, MS Power: 26 dBm No Subscriber Measurement Report: Flags: DLinval RXL-FULL-ul: -110 dBm, RXL-SUB-ul: -110 dBm RXQ-FULL-ul: 0, RXQ-SUB-ul: 0 BTS 0, TRX 0, Timeslot 0, Lchan 1: Type SDCCH Connection: 0, State: RELEASE REQUESTED BS Power: 22 dBm, MS Power: 26 dBm No Subscriber Measurement Report: Flags: DLinval RXL-FULL-ul: -110 dBm, RXL-SUB-ul: -110 dBm RXQ-FULL-ul: 0, RXQ-SUB-ul: 0 BTS 0, TRX 0, Timeslot 0, Lchan 2: Type SDCCH Connection: 0, State: RELEASE REQUESTED BS Power: 22 dBm, MS Power: 26 dBm No Subscriber Measurement Report: Flags: DLinval RXL-FULL-ul: -110 dBm, RXL-SUB-ul: -110 dBm RXQ-FULL-ul: 0, RXQ-SUB-ul: 0 BTS 0, TRX 0, Timeslot 0, Lchan 3: Type SDCCH Connection: 0, State: RELEASE REQUESTED BS Power: 22 dBm, MS Power: 26 dBm No Subscriber Measurement Report: Flags: L1 MS Power: 26 dBm, Timing Advance: 0 RXL-FULL-dl: -47 dBm, RXL-SUB-dl: -47 dBm RXQ-FULL-dl: 0, RXQ-SUB-dl: 0 RXL-FULL-ul: -47 dBm, RXL-SUB-ul: -47 dBm RXQ-FULL-ul: 0, RXQ-SUB-ul: 0 BTS 0, TRX 0, Timeslot 1, Lchan 0: Type SDCCH Connection: 0, State: RELEASE REQUESTED BS Power: 22 dBm, MS Power: 26 dBm No Subscriber Measurement Report: Flags: DLinval RXL-FULL-ul: -110 dBm, RXL-SUB-ul: -110 dBm RXQ-FULL-ul: 0, RXQ-SUB-ul: 0 OpenBSC# With this method I can fill the whole signalling capacity of the BTS without any actual call or SMS being sent. Csaba

11 years, 7 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC October 2013