OpenBSC January 2025

openbsc@lists.osmocom.org

8 participants
23 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

Separate RSL bootstrap to LAPD and BCCH+SACCH
by Sipos Csaba 20 Jan '25

20 Jan '25

Dear list, At the moment setting up the RSL lapd link and start its bootstrap (BCCH info and SACCH filling) is done in one go (as much as I can see). The issue with this is for the Nokia Site family: per spec. we should let the RSL lapd link to be initiated by the BTS and once that lapd link is up, the BTS sends a BTS_STATE_CHANGED message with "TRX, enabled" object id and object current state, and only after this we should start sending the BCCH info and SACCH filling (the "actual" bootstrap of the RSL). For this to work, we need the Object Identity and Object Current State attributes (which is a WIP atm), but somehow it should be possible to separate the RSL bootstrap to RSL lapd only and RSL bcch info + sacch filling. I am unaware if the above separation is possible with the current codebase, but if someone can shed some light on this, that would be appreciated. Adding the Object Identity and Object Current State will also allow us to detect the actual state changes of various BTS objects (mostly the TRX), and we can also use the BTS_CHA_ADM_STATE to actually lock/unlock TRXes, so we dont need to fake the 12.21 state anymore. Regards, Csaba

3 4

Looking for BS11 mounting plates
by Alexander Huemer 05 Jan '25

05 Jan '25

Hi! I am in possession of a pair of Siemens BS11 mounting plates and am looking for a second pair. A photo of the plates is attached. Since - I believe - most people who play with such basestations do not mount them to a wall or pole, my hope is that some unused ones are floating around somewhere. Thanks, -Alex^Wblackbit

2 4

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC January 2025