OpenBSC September 2024

openbsc@lists.osmocom.org

5 participants
15 discussions

pycrate repo update
by benoit michau 22 Jul '25

22 Jul '25

Dear osmocom developpers, This is just to let you know that the Python library pycrate has a new home : https://github.com/pycrate-org/pycrate. The packages on Pypi are now feeded from there. This library can be used in many cases dealing with mobile signalling. I wanted to let you know, as even if I am not aware of any osmocom projects depending on it, some of you may use the library from time to time, or could have local applications depending on it. Best Regards Benoit

2 1

Re: Help with sccp library
by mosbah abdelkader 07 Jul '25

07 Jul '25

> I don't understand. This callback will be called with data you need to write > to the network. In case of MTP Level3 you will need to wrap that around the > msgb you got. I means: is the interaction with mtp3 layer implemented (is sending sccp data by mtp3 implemented by the library?)? Also, what about the reception of data from mtp3 layer. is that implemented in the sccp lib. I am asking these questions because I see the code of mtp3 in the lib but no significant call is present in the sccp part of the lib. Thank you for your help.

4 3

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

Ericsson RBS6000 surplus situation
by Mychaela Falconia 17 Sep '24

17 Sep '24

Hello fellow Osmocomers, I just recently came across and watched Harald's ODC 2018 presentation about Ericsson RBS 6000. The part that intrigued me: Harald said in that year that this hardware was available quite inexpensively and plentifully; he said that a DUG10+RUG pair could be had for around 300 EUR in that year. My question to the community: what is the current situation 6 y later? Is there still any above-zero supply of either DUG10+RUG or DUG20+RUS surplus hardware? If a nonzero supply does exist, what is the typical price these days? In that 2018 presentation Harald also mentioned that the successor to DUG20 was DUS31/DUS41, and that those DUS units (which support GSM, WCDMA and LTE all in one box) have integrated SIU02 equivalent instead of native E1 interfaces. Hence question: has anyone in Osmocom cracked the E1-over-IP protocol spoken by SIU02 and its later incarnations, allowing Osmocom CNI to drive the GSM part of DUS31 etc, or is such operation beyond our current community capabilities? There are rumors going around that T-Mobile USA may be shutting down some Ericsson 2G equipment (though I still never got any clear answers as to what equipment it might be, if any), hence I am trying to brush up on my knowledge of this platform. M~

4 5

USRP1 not wanting to transmit (osmo-trx-usrp1)
by laptop fm 05 Sep '24

05 Sep '24

Hello, I tried using the osmocom stack with the usrp1 and I encountered this error : DMAIN NOTICE Starting the transceiver (Transceiver.cpp:287) DDEV NOTICE Setting TX gain to 0 dB. (USRPDevice.cpp:265) DDEV NOTICE Setting RX gain to 20 dB. (USRPDevice.cpp:292) DDEV NOTICE Setting TX gain to 0 dB. (USRPDevice.cpp:265) DDEV NOTICE Setting TX gain to 0 dB. (USRPDevice.cpp:265) DDEV NOTICE Setting TX gain to 0 dB. (USRPDevice.cpp:265) DMAIN NOTICE Stopping the transceiver (Transceiver.cpp:345) after that the osmo-trx-usrp1 seems to crash. I know it is not supported anymore but any possible fix would be appreciated. here is my system and log files together with a pcap : System : Debian 12 amd64 using osmocom-nightly repo (the stable repo still gives the same error)

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC September 2024