OpenBSC January 2020

openbsc@lists.osmocom.org

7 participants
16 discussions

dynamic traffic channels
by Neels Hofmeyr 20 May '25

20 May '25

On Tue, Jun 28, 2016 at 10:05:28AM +0200, Harald Welte wrote: > [translated from german] > is it certain that we switch a channel to PDCH only when > gprs mode != none? A TS can be GSM_PCHAN_TCH_F_PDCH; those are the only ones for which we send a PDCH ACT message. We send a PDCH ACT message - during init (CHANNEL OML's state changed to enabled -> send PDCH ACT), - and upon channel release ack when pchan == GSM_PCHAN_TCH_F_PDCH. So the question is, when we receive a channel release ack, could that be the PDCH release and we switch PDCH right back on by accident? No, because we only receive a chan rel ack when the *TCH/F* is being released. That is because the PDCH release is initiated "internally" from the PDCH DEACT, and thus this condition in common/rsl.c rsl_tx_rf_rel_ack() catches on, which existed before dyn PDCH: if (lchan->rel_act_kind != LCHAN_REL_ACT_RSL) { LOGP(DRSL, LOGL_NOTICE, "%s not sending REL ACK\n", gsm_lchan_name(lchan)); return 0; } In rsl_rx_rf_chan_rel() the rel_act_kind is set to LCHAN_REL_ACT_RSL, but not in the rsl_rx_dyn_pdch(). This is analogous to the ip.access way -- the ip.access nanobts replies to a PDCH DEACT with a PDCH DEACT ACK and doesn't send a separate channel release ack. Maybe we could set rel_act_kind to some new LCHAN_REL_ACT_IPAC_DYN_PDCH for clarity? (But we shouldn't actually send a release ack, to stay compatible.) Even though it works as-is, we should indeed add another flag check: - We do check the flags that no ACT/DEACT is already pending; - And we do send a PDCH DEACT only if ts->flags & TS_F_PDCH_ACTIVE; - But we would send a PDCH ACT despite ts->flags & TS_F_PDCH_ACTIVE. This should never happen, but it would make sense to ensure that. ~Neels

3 5

Problem while running NIB on Open Cellular Base sation
by Brackley Casinga 31 Jan '24

31 Jan '24

Hi, My name is Brackley Cassinga Form DRC, we run a community network called pamoja net where we offer gsm services using osmocom open source software and OC Base station. Recently I have tried to install another base station as the same installed but I could not find any resource guiding through all the steps to take to run NIB on a base station. I'm currently running Ubuntu and I will appreciate if you could guide me on the installation of BSC,hlr,MSC , in order to run a basic gsm network. Thank you. Regards -- *Ir Brackley heshima Casinga **Pacifique* *CEO and Founder of kwanzatechnologie* KwanzaTechnologies ,GlobalElectronics +243977265291 | +243977265291 | Pcassinga(a)gmail.com/ brackley(a)ensemblepourladifference.org www.kwantechnologies.jimdosite.com <http://www.kwantechnologies.com/> | Skype: Brackley cassinga <https://webapp.wisestamp.com/#> Av Semliki N 43

2 1

Feedback to GSUP Proxy Cache concept
by Oliver Smith 24 Jan '20

24 Jan '20

Hi Neels, > D-GSM proxy cache -- if you have the time, feedback on this design document would be appreciated: http://git.osmocom.org/osmo-hlr/commit/?h=neels/dgsm&id=8071c561405a031f204… > (when that commit is checked out, building osmo-hlr with manuals enabled should render the ladder diagrams in proxy_cache.adoc, which illustrate what I'm planning to implement) > (and disregard "(7) Skip the Insert Subscriber Data", as explained in the prose) I like that the key of the home HLR is not shared with the proxy HLRs. All in all, it sounds like a very smart solution! Some notes: * In the ladder diagrams, it shows that the AKAs are cached in both the MSC and the HLR. Why not just cache them in the HLR? * It might be a good idea to make AKA reuse optional with a VTY config option? * Potential use case: phone is home in village A, gets turned off, owner travels to village B with the phone, the link to village A is down. Phone gets turned on, then there will be no AKAs cached in village B's (proxy) HLR and the LU will fail. But there does not seem a way around this without sharing the keys (or without spaming other HLRs with AKAs for all subscribers in the HLR that they might use in the future, but that would just waste traffic). Regards, Oliver -- - Oliver Smith <osmith(a)sysmocom.de> https://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

build2.osmocom.org hardware replacement
by Harald Welte 22 Jan '20

22 Jan '20

Dear Osmocom community, in recent weeks (at least since mid-december) we've had some stability issues with build2.osmocom.org, the physical machine that runs the build2-deb8build-ansible and build2-deb9build-ansible LXCs used heavily by our jenkins. I've had to reset the machine, and now we finally have asked the hosting company to perform a hardware replacement. This has happened about 3 hours ago, and I hope the stability problems are gone now. Let me know if you still see anything odd related to build2. Regards, Harald -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

Osmocom CNI release 202001
by Pau Espin Pedrol 09 Jan '20

09 Jan '20

Dear all, I'm pleased to announce new tagged releases for Osmocom Cellular Network Infrastructure components. libosmocore 1.3.0 osmo-gsm-manuals 0.3.0 osmo-pcap 0.1.2 osmo-ggsn 1.5.0 libosmo-abis 0.8.0 libosmo-netif 0.7.0 libosmo-sccp 1.2.0 osmo-sip-connector 1.4.0 osmo-hlr 1.2.0 osmo-trx 1.2.0 osmo-bts 1.2.0 osmo-pcu 0.8.0 osmo-mgw 1.7.0 osmo-iuh 0.6.0 osmo-bsc 1.6.0 osmo-msc 1.6.0 osmo-sgsn 1.6.0 openbsc 1.3.2 Tags for related Openembedded meta layers have also been updated and are waiting to be merged, hopefully today, and will be available in branch 201705. Other related components such as libgtpnl or libsmpp34 had no development at all since last release cycle so they don't show up here. As a reminder, last release cycle was done around August 2019. Have fun, -- - Pau Espin Pedrol <pespin(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

Osmo Bsc (Seperate CNI) with Asterisk network busy!!
by Garrett Allen 02 Jan '20

02 Jan '20

Hi All I've used osmo-bsc in non standalone mode ie seperate components and all works fine voice and sms work as should. However when introducing. sip connector with asterisk the handsets will not make voice calls they just constantly respond network busy. I'm using osmo bts-trx with osmo-trx-lms on raspbian 10 below is Asterisk config. Any help would be appreciated. Gar [GSM] type=friend host=127.0.0.1 dtmfmode=rfc2833 canreinvite=no disallow=all allow=gsm context=gsmsubscriber port=5062

3 7

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC January 2020