OpenBSC

openbsc@lists.osmocom.org

12 participants
4278 discussions

The future of c-open-smpp-34 ?
by Harald Welte 14 Nov '16

14 Nov '16

Dear Raul, In 2012 the Osmocom OpenBSC project started to use your libsmpp34 in order to add SMPP capabilities to our GSM Netwrok In The Box (NITB). As there was no source code repository (svn, git. ...) of your library around at the time, we imported the latest version you had released (1.10) into a git repository at http://git.osmocom.org/libsmpp34/ Ever since we have been chcecking your sourceforge project occasionally to see if you had made any further releases, in order to re-synchronize them. Ther hasn't been any release ever since. Meanwhile, various (small) improvements have been happening in our git repository, but those changes are of course not visible to the new user who is ending up on your sourceforge.net project page. In order to avoid further confusion to the user, I would like to ask your input on how we should proceed. * do you still have plans for this library? * do you want to run a git repo on sf.net and merge our contributions? * would you consider designating the git.osmocom.org server as the official source code repository, maybe even moving other content from sf.net to https://osmocom.org/projects/libsmpp34 I would appreciate if you could at least put a notice on sf.net indicating that there is a more actively maintained fork of your library available at the above URLS. Let me know if there is something we can do to help, or if you have any other comments. Thanks, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

complete merge of IuCS using --enable-iu switch
by Neels Hofmeyr 14 Nov '16

14 Nov '16

So far the state of IuCS aka 3G voice is such that we will not merge the branch to master unless we have a proper A-interface. But come to think of it, it would technically be possible to split the code not by git branches, but rather by the --enable-iu configure switch. In that case openbsc master would contain all IuCS code, and if compiled with --enable-iu, compile time switches would disable osmo-nitb, enable osmo-cscn and (currently) destroy 2G due to lack of an A-interface implementation. The benefit would be simply to not have a separate branch, making for easier 3G build instructions and possibly reducing rebase merge conflicts; developers could adjust the 3G code paths along with their 2G patches. It's just an idea that came to mind... In the end it's just a kind of "fake" merge, so not sure whether it's worth the effort. Any thoughts? ~N -- - Neels Hofmeyr <nhofmeyr(a)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 * Geschäftsführer / Managing Directors: Harald Welte

1 0

naming contest: gsm_network, gsm_subscriber_connection
by Neels Hofmeyr 13 Nov '16

13 Nov '16

Hi all, for a bit of bikeshed fun on the side, I'd like to ask your opinions on a good name. The background: we're in the process of separating libmsc from libbsc. Both use the structs gsm_network and gsm_subscriber_connection, and both of these structs contain elements that are used only by libbsc or only by libmsc, besides the elements that are used by both. So at some point I will "split" both of these in two, to have a BSC and an MSC version thereof. How should we name them? struct gsm_network (note, if there is a common part, that could still be named 'gsm_network') --> bsc_network / msc_network looks familiar but the meaning of the name is lost --> gsm_bsc / gsm_msc --> osmo_bsc / osmo_msc To me these would be the best and the names are still available, but there are header files named like this and the osmo-bsc binary also has a very similar name. I think I would go for these anyway. +1 --> osmo_gsm_bsc / osmo_gsm_msc As alternative, but the gsm is a bit out of place (particularly in the light of a UMTS MSC). struct gsm_subscriber_connection --> bsc_subscriber_connection / msc_subscriber_connection but we could use the opportunity to shorten the name --> bsc_subscr_conn / msc_subscr_conn I like these best; but add osmo? +1 --> osmo_bsc_subscr_conn / osmo_msc_subscr_conn almost the old length. Happy shedding, "+1" comments and/or opinions welcome ~Neels -- - Neels Hofmeyr <nhofmeyr(a)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 * Geschäftsführer / Managing Directors: Harald Welte

3 4

Migration of GSUP HLR code
by Harald Welte 11 Nov '16

11 Nov '16

Dear all, I have just moved the Osmocom GSUP HLR code from the really unrelated ancient osmo-auc.git repository into its own osmo-hlr.git repository. The GSUP HLR is a stand-alone HLR for SIM and USIM based subscribers which exposes the GSUP protocol towards its users. Currently in openbsc master, there is OsmoSGSN which supports this protocol. There is ongoing work to remove the HLR from OsmoNITB and make it access the GSUP HLR asynchronously. I originally intended to complete this in summer this year,but was constantly delayed due to various other tasks :/ Neels is now coming to the rescue and is in charge of moving this ahead to get it ready to merge. The osmo-gsup-hlr is still very simplistic. It's a single-threaded architecture and uses only sqlite3 tables as back-end. It is suitable for installations of the scale that OsmoNITB was able to handle. It also lacks various features like fine-grained control of subscribed services (like supplementary services). The most important goal for osmo-gsup-hlr is to be a replacement for the HLR code we'r removing from good old OsmoNITB. It is *not* supposed to be a fully-featured GSM HLR. One of the advantages of having the GSUP protocol for both CS and PS side is that there could be other, more scalable/powerful implementations of the HLR that can just be swapped in. Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

MS cannot connect; Location Update Request not received by BTS?
by Bruce Smith 11 Nov '16

11 Nov '16

5 7

osmo-nitb + osmo-sip-connector: background noise on peer to peer calls
by Anonim Stefan 09 Nov '16

09 Nov '16

Hi, I am using osmo-nitb + osmo-sip-connector and nanoBTS to establish a per to peer call. I am using: osmocom-nitb 0.15.1.20161024 osmo-sip-connector 1.20161024 While in call, I hear an annoying background noise while not talking. The noise disappears when someone speaks. Any idea what might be causing this and how this can be fixed? Thanks, Stefan

2 2

Osmo BTS Multi Carrier activation with 1 TRX
by Dhananjay kumar 08 Nov '16

08 Nov '16

Hi All, We are trying to configure Multi carrier [ 2 or more ARFCN working in parallel with 1 TRX] with B200 board. If anyone has done it ,please share working config file and executing command for BTS and TRX. Thanks in advance ! -- Thanks & Regards Dhananjay

2 1

estimate distance
by sami 04 Nov '16

04 Nov '16

Hi, Is there a function in OpenBSC that can help in estimating the diastase of the connected phone ? For example, something that gives the value of the power received by the phone from the BTS and the power received by the BTS from the phone (during paging or active call). best regards,

4 6

P*CH activation
by Max 03 Nov '16

03 Nov '16

HI. Pardon the cross-posting, I'm not sure where this question really belongs. I've been trying to wrap my head around how PDTCH/PACCH/PTCCH activation works. In osmo-bts-sysmo/oml.c there is pdtch_sapis[] which defines what got to be activated both in DL and UL directions. Right now it's PDTCH (UL & DL), PTCCH (DL) and PRACH. Note that PACCH (DL) and PTCCH (UL) are commented out. Yet I see code dealing with PACCH in osmo-pcu and corresponding log messages. So the question is - how does this works? The PACCH seems to be used so it's somehow activated but apparently not the same way as PDTCH. -- Max Suraev <msuraev(a)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

2 1

Re: [MERGED] openbsc[master]: gsm0408: Adding log output for 3g specific RR messages
by Neels Hofmeyr 03 Nov '16

03 Nov '16

Possible error in this merged patch, see inline: On Tue, Nov 01, 2016 at 09:56:24PM +0000, Harald Welte wrote: > Harald Welte has submitted this change and it was merged. > > Change subject: gsm0408: Adding log output for 3g specific RR messages > ...................................................................... > > > gsm0408: Adding log output for 3g specific RR messages > > GSM 04.18, which is the successor of GSM 04.08, describes > additional RR 3g specific message types. This commit adds > log output for those messages. The behaviour is not changed > all affected message types are still forwared to the MSC > as they were before. > > See also 3GPP TS 04.18, section 10.4, table 10.4.1 > > The change requires to update libosmocore as well, see > also commit f48fdb3a108da0dc23d7af4ac021e98e11f07152 in > libosmocore.git for details. > > Change-Id: I41f2242fdf59c3eb4b3f8f7f003c17f7e0df01aa > --- > M openbsc/src/libbsc/bsc_api.c > M openbsc/src/libmsc/gsm_04_08.c > 2 files changed, 11 insertions(+), 7 deletions(-) > > Approvals: > Harald Welte: Looks good to me, approved > Jenkins Builder: Verified > > > > diff --git a/openbsc/src/libbsc/bsc_api.c b/openbsc/src/libbsc/bsc_api.c > index cc12e9f..207e12a 100644 > --- a/openbsc/src/libbsc/bsc_api.c > +++ b/openbsc/src/libbsc/bsc_api.c > @@ -34,6 +34,7 @@ > #include <openbsc/trau_mux.h> > > #include <osmocom/gsm/protocol/gsm_08_08.h> > +#include <osmocom/gsm/gsm48.h> > > #include <osmocom/core/talloc.h> > > @@ -587,11 +588,13 @@ > case GSM48_PDISC_RR: > switch (msg_type) { > case GSM48_MT_RR_GPRS_SUSP_REQ: > - DEBUGP(DRR, "GRPS SUSPEND REQUEST\n"); > + DEBUGP(DRR, "%s\n", > + gsm48_rr_msg_name(GSM48_MT_RR_GPRS_SUSP_REQ)); > break; > case GSM48_MT_RR_STATUS: > - LOGP(DRR, LOGL_NOTICE, "RR STATUS (cause: %s)\n", > - rr_cause_name(gh->data[0])); > + LOGP(DRR, LOGL_NOTICE, "%s (cause: %s)\n", > + gsm48_rr_msg_name(GSM48_MT_RR_GPRS_SUSP_REQ), Although this is in case GSM48_MT_RR_STATUS, it logs GSM48_MT_RR_GPRS_SUSP_REQ. I'd prefer it it logs gsm48_rr_msg_name(msg_type), also in the call above, and like the patch does below. > + rr_cause_name(gh->data[0])); > break; > case GSM48_MT_RR_MEAS_REP: > /* This shouldn't actually end up here, as RSL treats > @@ -643,8 +646,9 @@ > /* Normally, a MSC should never receive RR > * messages, but we'd rather forward what we > * don't know than drop it... */ > - LOGP(DRR, LOGL_NOTICE, "BSC: Passing unknown 04.08 " > - "RR message type 0x%02x to MSC\n", msg_type); > + LOGP(DRR, LOGL_NOTICE, > + "BSC: Passing %s 04.08 RR message to MSC\n", > + gsm48_rr_msg_name(msg_type)); > if (api->dtap) > api->dtap(conn, link_id, msg); > } > diff --git a/openbsc/src/libmsc/gsm_04_08.c b/openbsc/src/libmsc/gsm_04_08.c > index a22e3c2..3e362fa 100644 > --- a/openbsc/src/libmsc/gsm_04_08.c > +++ b/openbsc/src/libmsc/gsm_04_08.c > @@ -1270,8 +1270,8 @@ > rc = gsm48_rx_rr_app_info(conn, msg); > break; > default: > - LOGP(DRR, LOGL_NOTICE, "MSC: Unimplemented " > - "GSM 04.08 RR msg type 0x%02x\n", gh->msg_type); > + LOGP(DRR, LOGL_NOTICE, "MSC: Unimplemented %s GSM 04.08 RR " > + "message\n", gsm48_rr_msg_name(gh->msg_type)); > break; > } > > > -- > To view, visit https://gerrit.osmocom.org/1037 > To unsubscribe, visit https://gerrit.osmocom.org/settings > > Gerrit-MessageType: merged > Gerrit-Change-Id: I41f2242fdf59c3eb4b3f8f7f003c17f7e0df01aa > Gerrit-PatchSet: 9 > Gerrit-Project: openbsc > Gerrit-Branch: master > Gerrit-Owner: dexter <pmaier(a)sysmocom.de> > Gerrit-Reviewer: Harald Welte <laforge(a)gnumonks.org> > Gerrit-Reviewer: Jenkins Builder > Gerrit-Reviewer: Max <msuraev(a)sysmocom.de> > Gerrit-Reviewer: Neels Hofmeyr <nhofmeyr(a)sysmocom.de> -- - Neels Hofmeyr <nhofmeyr(a)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 * Geschäftsführer / Managing Directors: Harald Welte

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC