OpenBSC November 2019

openbsc@lists.osmocom.org

4 participants
17 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

request: osomocom git repo branch cleanup
by Harald Welte 30 Nov '19

30 Nov '19

Dear Osmocom developers, the number of branches in many repositories (most notably libosmocore) is growing to a rather large number, and I would like to encourage everyone to have a quick look about which branches can be deleted by now (and delete them, if no longer needed). Thanks! 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

36c3: GSM base stations wanted
by Vadim Yanitskiy 28 Nov '19

28 Nov '19

Dear all, 36c3 is going to happen soon, and as usually we're planing to setup our own GSM/UMTS network (LTE is to be discussed). While we do have enough UMTS NodeB units, we're looking for heroes who could sacrifice their GSM base stations (preferably sysmoBTS or nanoBTS) for the duration of the congress. Note that we're not considering SDRs (unless somebody with a strong aspiration wants to ensure proper clock distribution, filtering, power amplification, etc). Please let us know 1) how many (and what kind of) units we could borrow from you, 2) can you bring them to Leipzig before the first day, or can you drop them somewhere in Berlin (Sysmocom? AfRa?). Thanks! On behalf of the GSM team, Vadim Yanitskiy.

1 0

Build failures of network:osmocom:nightly/osmo-hlr
by Harald Welte 12 Nov '19

12 Nov '19

Somehow osmo-hlr is no longer building in OBS for a variety of targets -- - 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)

4 3

osmo-msc: repeatpaging?
by Neels Hofmeyr 04 Nov '19

04 Nov '19

I noticed the MSC test that wants osmo-msc to repeat a Paging to the BSC and hNodeB. After fixing the Iu tests, I wanted to get this last ttcn3-msc-test working, so I was about to implement repeated Paging from osmo-msc, but the more I think about it, the less it makes sense to me. The commit log in osmo-ttcn3-hacks says: Repeating will improve the reachability of MS when a Paging is lost or not received because the MS is moving between states. This reasoning seems flawed to me, because the BSC / hNodeB is between the MSC and the MS, and the BSC *does* repeat Paging. That should cover MS moving between states. The link between MSC and {BSC,hNodeB} is considered reliable, and AFAICT nothing really gets better when repeating a Paging request to the BSS. It could make sense to maybe repeat Paging with a larger/more general Cell Identifier List? But why not send the full list in the first place? Also 3GPP TS 48.008 3.1.10 Paging says: A single PAGING message across the MSC to BSS interface contains information on the cells in which the page shall be broadcast. I interpret the "A single" as: there is no repetition of Paging requests toward the BSS, and that's also what makes most sense to me infrastructurally. Is there any spec indicating repeated Paging from the MSC? I would actually remove the test TC_lu_and_mt_sms_paging_repeated. If that's the wrong call, we should specify how osmo-msc should repeat Paging. Before that, having the test makes little sense... What do you guys think? ~N

3 3

contrib: alternative ladder diagram format
by Neels Hofmeyr 01 Nov '19

01 Nov '19

Hi all, I wrote a script and am wondering whether it makes sense to publish it in libosmocore/contrib/. For codec negotiation patches, I was writing ladder diagrams manually in the mscgen format, and it was so annoying to type "[label=]" all the time, that I decided to write a script that parses a leaner ladder diagram format and converts it to mscgen format. I was going to use this format in osmo-msc.git, but actually, after I wrote the first osmo-msc codec ladder diagram, I went a step further and automated the process by transcribing an osmo-msc log output directly to a ladder diagram. That script can output to mscgen format, so in the end there is no dependency on that simpler ladder format from my osmo-msc patches. When writing ladder diagrams manually in the future, I'll probably choose my simpler ladder format. I could always submit the converted format instead of that, i.e. keep the simpler format to myself entirely. I could publish the script privately... Any opinions? Does it make sense to put this in libosmocore/contrib/ before any Osmocom git trees actually depend on it? See branch neels/contrib http://git.osmocom.org/libosmocore/commit/?h=neels/contrib&id=f1ec9483de0f9… ~N

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC November 2019