OpenBSC November 2016

openbsc@lists.osmocom.org

21 participants
30 discussions

complete merge of IuCS using --enable-iu switch

by Neels Hofmeyr

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

8 years, 7 months

naming contest: gsm_network, gsm_subscriber_connection

by Neels Hofmeyr

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

8 years, 7 months

Migration of GSUP HLR code

by Harald Welte

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)

8 years, 7 months

MS cannot connect; Location Update Request not received by BTS?

by Bruce Smith

8 years, 7 months

osmo-nitb + osmo-sip-connector: background noise on peer to peer calls

by Anonim Stefan

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

8 years, 7 months

Osmo BTS Multi Carrier activation with 1 TRX

by Dhananjay kumar

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

8 years, 7 months

estimate distance

by sami

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,

8 years, 7 months

P*CH activation

by Max

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

8 years, 7 months

Re: [MERGED] openbsc[master]: gsm0408: Adding log output for 3g specific RR messages

by Neels Hofmeyr

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

8 years, 7 months

osmo-bts-trx channel activation

by Max

Hi. In sysmobts we use ugly hack to auto-activate BCCH/CCCH on TS0 via opstart_compl(). How does channel activation looks like for osmo-bts-trx? On a related note: how do we decide on number of AGCH? In case of sysmobts it's communicated to L1 in agch.u8NbrOfAgch via lch_par. What would be equivalent for osmo-bts-trx? -- 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

8 years, 7 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC November 2016