OpenBSC November 2016

openbsc@lists.osmocom.org

21 participants
33 discussions

B210 - 2 chain Configuration issue
by Dhananjay kumar 21 Nov '16

21 Nov '16

Hi, We are configuring B210 with OSMO-NITB ,OSMO-BTS and OSMO-TRX for 2 chain configuartion. BSC Configuation : bts 0 trx 0 rf_locked 0 arfcn 51 nominal power 0 max_power_red 0 rsl e1 tei 0 timeslot 0 phys_chan_config CCCH+SDCCH4 hopping enabled 0 timeslot 1 phys_chan_config PDCH timeslot 2 phys_chan_config PDCH timeslot 3 phys_chan_config PDCH timeslot 4 phys_chan_config PDCH timeslot 5 phys_chan_config PDCH timeslot 6 phys_chan_config TCH/F timeslot 7 phys_chan_config TCH/F trx 1 rf_locked 0 arfcn 55 nominal power 0 max_power_red 0 rsl e1 tei 0 timeslot 0 phys_chan_config CCCH+SDCCH4 timeslot 1 phys_chan_config PDCH timeslot 2 phys_chan_config PDCH timeslot 3 phys_chan_config PDCH timeslot 4 phys_chan_config PDCH timeslot 5 phys_chan_config PDCH timeslot 6 phys_chan_config TCH/F timeslot 7 phys_chan_config TCH/F BTS config : trx 0 phy 0 instance 0 trx 1 phy 0 instance 1 *Issue description :* On TRX 0 all 8 eight brust is seen on simulator , but on TRX1 only 1 brust is coming up. when channel is swiped with " - s" [osmo-trx -fc 2 -s ] issue reversed to TRX0. Please refer attached screen shot for frame brust. we need to both TRX working with identical power level. let me know if anyone has faced this issue and have solution for this. BR Dhananjay

1 0

Dynamic TCH/F_PDCH does not work for CS call
by Mrinal Mishra 16 Nov '16

16 Nov '16

Hello All, We are testing Dynamic TCH allocation. In the latest BSC ( commit version 87ef68eb33d463d8aad1511a272cbdb779f1ba19) it is observed that CS call is not working with TCH/F_PDCH channel configuration. Please note that if PS call is attempted in TCH/F_PDCH channel then it works fine. When Dynamic TCH tested with the old BSC commit version (7bc6986f6babdaf5f2436dae2f603ae5823aa7b4) then CS call worked fine with TCH/F_PDCH channel. Please let us know if it is known issue. Thanks and Regards, Mrinal

4 9

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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC November 2016