OpenBSC July 2020

openbsc@lists.osmocom.org

5 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

Support for new SDR devices
by Xaver Zu 17 Aug '20

17 Aug '20

Hi all, What are the plans to expand support for new SDR devices? When I check the contents of osmo-trx/Transceiver52M/device/ on the git master I see the supported lms, uhd and usrp1 devices. For example the XTRX SDR was presented at OsmoDevCon 2018. I expected it to be included in the master soon. At this point I see its addition in the fairwaves / libxtrx-wip branch from 2018. That doesn't give me much encouragement for my next question. Would it be possible to add support for PCIe SDR from Amarisoft? Some information about SDR is here https://discourse.myriadrf.org/t/amarisoft-sdr-integration-with-oai/2288 Based on the https://media.ccc.de/v/osmocon2018-82-osmotrx-status-support-for-more-drive… I tried to create support by myself. I've gotten into a state that some MS with weak requirements for signal quality and timing can connect. My branch is here https://github.com/XK1ZU/osmo-trx/tree/PCIeSDR-LMSstyle gr-osmosdr support is here https://github.com/XK1ZU/gr-osmosdr/commits/PCIeSDR This osmo-trx is able to run for a few tens of seconds then it quits and I have to restart it, so I would need a deeper understanding of the timing and scheduling of processes within osmo-trx. Who should be a clock master SW stack or SDR device? I see a lot of log error messages as 0000> Transceiver.cpp:422 [tid=140137319651072][chan=0] dumping STALE burst in TRX->SDR interface (1:1408722 vs 7:1408723), retrans=0 <0000> Transceiver.cpp:1122 [tid=140137311258368] ClockInterface: sending IND CLOCK 1408899 or 0000> Transceiver.cpp:280 [tid=140137328043776] Starting the transceiver <0000> radioInterface.cpp:181 [tid=140137328043776] Starting radio device <0000> PCIESDRDevice.cpp:199 [tid=140137328043776] PCIESDRDevice::start <0000> PCIESDRDevice.cpp:205 [tid=140137328043776] starting PCIeSDR..., sample rate:1.08333e+06 <0000> PCIESDRDevice.cpp:234 [tid=140137328043776] PCIESDRDevice::flush <0000> PCIESDRDevice.cpp:219 [tid=140137328043776] msdr_start ok: <0000> PCIESDRDevice.cpp:532 [tid=140137328043776] Update Alignment <0000> PCIESDRDevice.cpp:532 [tid=140137328043776] Update Alignment <0000> radioInterface.cpp:202 [tid=140137328043776] Radio started <0000> Threads.cpp:119 [tid=140137294472960] Thread 140137294472960 (task 18522) set name: TxLower <0000> Threads.cpp:119 [tid=140137311258368] Thread 140137311258368 (task 18524) set name: RxUpper0 <0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP POWERON 0' <0000> Threads.cpp:119 [tid=140137302865664] Thread 140137302865664 (task 18523) set name: RxLower <0002> PCIESDRDevice.cpp:363 [tid=140137302865664] rc < 0 <0002> PCIESDRDevice.cpp:364 [tid=140137302865664] Sample buffer: Requested timestamp is not valid <0000> Threads.cpp:119 [tid=140137319651072] Thread 140137319651072 (task 18525) set name: TxUpper0 <0002> PCIESDRDevice.cpp:365 [tid=140137302865664] timestamp = 10960, length = 262144, time_start = 6765960, time_end = 6766960, data_start = 223320, data_end = 224320 <0002> PCIESDRDevice.cpp:482 [tid=140137294472960] tx_underflow_count:3 rx_overflow_count:0 <0002> PCIESDRDevice.cpp:491 [tid=140137294472960] PCIeSDR: tx underrun ts_tmp:10976 ts:10960 hwts:6762040 <0000> radioInterface.cpp:334 [tid=140137302865664] Receive error 0 <0000> Transceiver.cpp:1162 [tid=140137302865664] Something went wrong in thread RxLower, requesting stop <0002> PCIESDRDevice.cpp:482 [tid=140137294472960] tx_underflow_count:4 rx_overflow_count:0 <0002> PCIESDRDevice.cpp:491 [tid=140137294472960] PCIeSDR: tx underrun ts_tmp:13476 ts:13460 hwts:6762278 <0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is 'SETRXGAIN 40' <0000> PCIESDRDevice.cpp:318 [tid=140137328043776] Setting RX gain to 40 dB. <0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP SETRXGAIN 0 40' <0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is 'SETPOWER 0' <0000> PCIESDRDevice.cpp:297 [tid=140137328043776] Setting TX gain to 60 dB. device:0x1f6e0e0 chan:0 <0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP SETPOWER 0 0' <0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is 'SETSLOT 0 5' <0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP SETSLOT 0 0 5' <0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is 'SETSLOT 1 7' <0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP SETSLOT 0 1 7' <0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is 'SETSLOT 2 13' <0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP SETSLOT 0 2 13' <0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is 'SETSLOT 3 13' <0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP SETSLOT 0 3 13' <0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is 'SETSLOT 4 13' <0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP SETSLOT 0 4 13' <0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is 'SETSLOT 5 8' <0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP SETSLOT 0 5 8' <0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is 'SETSLOT 6 8' <0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP SETSLOT 0 6 8' <0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is 'SETSLOT 5 13' <0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP SETSLOT 0 5 13' <0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is 'SETSLOT 7 13' <0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP SETSLOT 0 7 13' <0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is 'SETSLOT 6 13' <0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP SETSLOT 0 6 13' <0000> osmo-trx.cpp:485 [tid=140137400406720] Shutting down transceiver... <0000> Transceiver.cpp:338 [tid=140137400406720] Stopping the transceiver <0000> Transceiver.cpp:351 [tid=140137400406720] Stopping the device <0000> PCIESDRDevice.cpp:254 [tid=140137400406720] PCIESDRDevice::stop <0000> PCIESDRDevice.cpp:261 [tid=140137400406720] PCIESDR stopped <0000> Transceiver.cpp:364 [tid=140137400406720] Transceiver stopped <0000> PCIESDRDevice.cpp:78 [tid=140137400406720] Closing PCIESDR Device Yours XK1Zu

5 7

libosmocore / osmo_fd / select() / performance
by Harald Welte 21 Jul '20

21 Jul '20

Hi all, it has been coming up in at least two contexts recently: Select is showing up a lot in system-level profiles particularly on osmo-bts. This is hardly surprising, as select() is not particularly known for efficiency. It was used back in 2008 for the *BSC*, in a context where we were talking about 1-10 BTS with each no more than 1-2 TRX. Now we are using the same osmo_fd abstraction on the BTS, where the number of messages per second is much higher, particularly in osmo-bts-trx with its TRXD protocol, and particularly with higher number of TRX per BTS. There is an older feature request to introduce epoll support in https://osmocom.org/issues/1579 but unfortunately nobody has been finding the resources and/or time to implement it. Meanwhile, 1.5 years ago, the Linux kernel received a new sub-system called io_uring, which I would personally love to support. Here are some pointers for those who are interested: https://lwn.net/Articles/776703/ https://kernel.dk/io_uring.pdf https://lwn.net/Kernel/Index/#io_uring As unfortunately not everyone is using half-way recent kernels, we will likely have to fall back to epoll or something like that. 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 scheduled outage on *2020-07-19 9am CEST*
by Harald Welte 19 Jul '20

19 Jul '20

There is an urgent need to migrate our most important public infrastructure to a new server, and I will be doing that on *Sunday, July 19 2020*, starting about 9am CEST. The migration involves redmine (main osmocom.org website), jenkins, gerrit, git, and cgit. In theory, the migration should be quick. I would expect (significantly) less than one hour of downtime. However, we all know Murphys law. Services not affected are mail (including mailman lists), ftp, dns. So in case of doubt, we can still use mailing lists to communicate. In case anyone urgently needs osmocom source code on Sunday morning during the downtime: There are public mirrors available on github. 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 1

OsmoCBC Status?
by Nick Jones 05 Jul '20

05 Jul '20

Hi all, Just wondering what the status of OsmoCBC is? I started compiling from source, but I couldn't find any docs on interfacing with it other than that it's via a HTTP REST API, If there aren't any docs are there packet captures or examples I can work from that'd be quicker than trying to reverse it from the source code, Happy to contribute some docs once I work it out, Cheers, Nick

2 2

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC July 2020