OpenBSC

openbsc@lists.osmocom.org

4315 discussions

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 10 Nov '16

10 Nov '16

5 7

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

08 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 02 Nov '16

02 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 02 Nov '16

02 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

osmo-bts-trx channel activation
by Max 02 Nov '16

02 Nov '16

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

2 2

Re: Profiling data of decoding EPDAN compressed bitmap
by Holger Freyther 29 Oct '16

29 Oct '16

> On 13 Jul 2016, at 12:21, Max <msuraev(a)sysmocom.de> wrote: > Hi all, > After looking at the code, I don't think reusing table implementation > would be easy - the approaches are too different as well as underlying > data structures. okay. then we will need to use the tree based version and from my point of view we should do it the following way: * Remove osmo_t4_decode (and related routines) from libosmocore (last step) * Make the tree based decoder ready in terms of the surrounding style * Adopt/Clone the osmo_t4_decode tests and move them to the PCU (as part of the commit that adds the decoder to the PCU) @Me: After the infrastructure is in the PCU I will remove osmo_t4_decode (and tests) from libosmocore @Radisys: I am afraid the tree based decoding is not ready yet and as it impacts the upcoming encoder (and other RLE code as far as I understand) let me put it here. In osmo-pcu (and all other projects) we use libtalloc for memory allocations. This means the tree should use talloc with proper parent/child allocations. This way the destructor of the decoder will also free all nodes of the tree. There should be no call to malloc/free in the PCU. Please take the tests from libosmocore and make sure they work with the new decoder. Tests are the lifeline and we need more and not less of them. The decoder needs to be robust against invalid input. search_runlen can fail but the caller doesn't check for that. Please test with invalid/truncated or broken inputs to see we don't end in a never terminating while loop. Test using unit tests. Similar the current osmo_t4_decode can return an error that is propagated back to the compressed bitmap decoding and we should have the same. Reduce code duplication. With the decoder the only difference between the if/else is if the data is filled with 0x00 or 0xFF and which table/root to use. Instead of having code clones please parameterize either by having local variables in the beginning or by calling different (inline) functions. kind regards holger

1 1

open-sip-connector error logs
by Anonim Stefan 27 Oct '16

27 Oct '16

Hi, I am using osmo-sip-connector 1.20161024 with osmocom-nitb 0.15.1.20161024 on debian jessie. I keep getting the below error[1] causing my syslog to fill up. Also I can see sometimes the sip connector replies with 0.0.0.0 RTP IP address. Anyone had this issues before ? Any idea what might be causing this? Regards, Stefan [1] Oct 25 11:58:28 openbsc1 osmo-sip-connector[283]: length packettport(0x1064c30): zero length packettport(0x1064c30): zero length packettport(0x1064c30): zero length packettport(0x1064c30): zero length packettport(0x1064c30): zero length packettport(0x1064c30): zero length packettport(0x1064c30): zero length packettport(0x1064c30): zero length packettport(0x1064c30): zero length packettport(0x1064c30): zero length packettport(0x1064c30): zero length packettport(0x1064c30): zero length packettport(0x1064c30): zero length packettport(0x1064c30): zero length packettport(0x1064c30): zero length packettport(0x1064c30): zero length packettport(0x1064c30): zero length packettport(0x1064c30): zero length packettport(0x1064c30): zero length packettport(0x1064c30): zero length packettport(0x1064c30): zero length packettport(0x1064c30): zero length packettport(0x1064c30): zero length packettport(0x1064c30): zero length packettport(0x1064c30): zero length packettport(0x1064c30): zero length packettport(0x1064c30): zero length packettport(0x1064c30): zero length packettport(0x1064c30): zero length packettport(0x1064c30): zero length packettport(0x1064c30): zero length packettport(0x1064c30): zero length packettport(0x1064c30): zero length packettport(0x1064c30): zero length packettport(0x1064c30): zero length packettport(0x1064c30): zero length packettport(0x1064c30): zero length packettport(0x1064c30): zero length packettport(0x1064c30): zero length packettport(0x1064c30): zero length packettpor

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC