OpenBSC April 2023

openbsc@lists.osmocom.org

4 participants
11 discussions

Pysim error: SW match failed
by Martin Nagy 16 Aug '25

16 Aug '25

Hi all, After buying a super Sim Kit (16 in 1) from China, I tried the reader (green PCB inside a blue transparent plastic case with a blue LED) and SIM (identified as a fakesupersim) with pysim tool. However i am getting the following error: /pySim-prog.py -n 26C3 -c 49 -x 262 -y 42 -z 1234 -j 1 -t auto Insert card now (or CTRL-C to cancel) Autodetected card type fakemagicsim Generated card parameters : > Name : 26C3 > SMSP : e1ffffffffffffffffffffffff058100945555ffffffffffff000000 > ICCID : 8949262427518313026 > MCC/MNC : 262/42 > IMSI : 262422461512085 > Ki : 7b74741a1ee14337ec23f9ab92a13648 > OPC : ccd867d60797d8d45354a51b3ef568ff Programming ... Traceback (most recent call last): File "./pySim-prog.py", line 530, in <module> card.program(cp) File "/home/nadicek/pysim/pysim/pySim/cards.py", line 231, in program self._scc.update_binary('6f30', hplmn + 'ff' * (tl-3)) File "/home/nadicek/pysim/pysim/pySim/commands.py", line 53, in update_binary return self._tp.send_apdu_checksw(pdu) File "/home/nadicek/pysim/pysim/pySim/transport/__init__.py", line 87, in send_apdu_checksw raise RuntimeError("SW match failed ! Expected %s and got %s." % (sw.lower(), rv[1])) RuntimeError: SW match failed ! Expected 9000 and got 9804. I checked mailing lists and haven’t found anybody who had similar problem with pysim. Also I have tried forcing different models of SIM, but nothing is working. Obviously I can remove this check from the script file (__init__.py in /pySim/transport), however somebody had a reason to put such condition there. I would like to ask if it is safe to remove that line of code and the purpose of that line of code. Thanks a lot and best regards Martin

3 3

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

cmd2 update causing pySim-shell to fail
by bryan coxwell 24 Jun '25

24 Jun '25

Hi all, Just wanted to share an issue and a quick workaround I found for it in case anyone else has the same problem. I believe a cmd2 update is causing pySim-shell to fail. After installing it on a fresh install of Ubuntu Server 20.04 and getting the following error when I run "python3 pySim-shell -p0": >Using PC/SC reader interface >Autodetected card type: sysmoUSIM-SJS1 >AIDs on card: > USIM: a0000000871002ffffffff8907090000 >Traceback (most recent call last): > File "pySim-shell.py", line 512, in <module> > app = PysimApp(card, rs, opts.script) > File "pySim-shell.py", line 59, in __init__ > super().__init__(persistent_history_file='~/.pysim_shell_history', allow_cli_args=False, use_ipython=True, auto_load_commands=False, command_sets=basic_commands, >startup_script=script) >TypeError: __init__() got an unexpected keyword argument 'use_ipython' If you run into this you can fix it by uninstalling cmd2 and reinstalling cmd2 with "pip3 install cmd2==1.5". Best, Bryan

5 5

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

libosmocore/BSC/MSC: MO voice calls rejected from Siemens S11E (patch included)
by Lennart Müller 31 Jan '24

31 Jan '24

Hi, I had a problem placing MO GSM calls from a Siemens S11E: The calls were dropped immediately; Osmo-MSC reports "Cannot compose Channel Type from bearer capabilities" After investigating the SETUP request from the S11E, the phone does not use octet 3a (no extension bit set in IE 3). Wireshark decodes the radio channel requirement as "Full rate support only MS/fullrate speech version 1 supported", so I added a condition to the gsm48_ie.c function of libosmocore to include at least GSM FR in the list of available speech_ver in case octet 3 has no extension. Attached to this message are the Abis-IP PCAP traces of MO calls, and the patch for gsm48_ie.c. Regards, Lennart

6 6

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

libosmocodec reference to ECU implementations from ETSI
by Mychaela Falconia 21 Apr '23

21 Apr '23

libosmocore/include/osmocom/codec/ecu.h lines 32-44: /* As the developer and copyright holder of the related code, I hereby * state that any ECU implementation using 'struct osmo_ecu_ops' and * registering with the 'osmo_ecu_register()' function shall not be * considered as a derivative work under any applicable copyright law; * the copyleft terms of GPLv2 shall hence not apply to any such ECU * implementation. * * The intent of the above exception is to allow anyone to combine third * party Error Concealment Unit implementations with libosmocodec. * including but not limited to such published by ETSI. * * -- Harald Welte <laforge(a)gnumonks.org> on August 1, 2019. */ Question about "ECU implementations ... published by ETSI": what exactly are they? To the best of my knowledge (I could be wrong, I am a late joiner to this party), ETSI/3GPP never published any ECU implementations - instead what they did publish are reference encoder and decoder implementations for HR1, EFR and AMR codecs. In each of those reference codec implementations, the error concealment function is deeply intertied with the guts of the decoder (the thing that puts out a block of 160 linear PCM samples, *not* a corrected codec frame) and does not exist as a separable piece - thus none of those reference codec implementations can be meaningfully called an ECU implementation, and there is no code in there that could be hooked up to libosmocodec ECU framework in a technically feasible way, no matter what license. So what I am missing? Are there some other code publications from ETSI or 3GPP which I am not aware of, ones that do implement a separate or at least separable ECU, as opposed to a complete decoder that takes potentially-errored codec frames as input and emits linear PCM as output? If any such "true" ECU implementations do exist, I would love to be pointed in the direction of one! M~

1 0

i pushed a commit for SCCP_Emulation.ttcn to github
by Neels Hofmeyr 16 Apr '23

16 Apr '23

I fixed something in SCCP_Emulation.ttcn (from Ericsson), and trying out what I'm allowed to do, it happened so that I just pushed the fix onto https://github.com/osmocom/titan.ProtocolEmulations.SCCP master See https://github.com/osmocom/titan.ProtocolEmulations.SCCP/commit/17a894fc662… The fix is trivial enough, but I'd like to note that I pushed something that no-one reviewed, and hope that's ok. my github user is part of that Osmocom group, I set the remote to a git@... URL, so that's why I could just push onto master. For the future, do we have a process to review fixes for Ericsson's ttcn code? Send it to this ML? ~N

3 2

falconia/rtp_traulike branch in osmo-bts
by Mychaela Falconia 08 Apr '23

08 Apr '23

Hello GSM community, I just pushed a private feature branch to osmo-bts, implementing a feature of much interest to me: https://cgit.osmocom.org/osmo-bts/log/?h=falconia/rtp_traulike What is it all about? This document, contained inside the branch, explains it all: https://cgit.osmocom.org/osmo-bts/tree/doc/rtp_traulike.txt?h=falconia/rtp_… Some day I would like to see this feature merged (it is enabled with a vty option, and if you don't set that option, nothing changes), but whether it will ever be merged or not, this feature is what I am going to run with in my ThemWi operation, and themwi-mgw (my Osmocom CN to G.711 PSTN transcoder) is going to depend on it. Enjoy! Hasta la Victoria, Siempre, Mychaela aka The Mother

2 3

3GPP TS 28.062 section C.3.2.1.1 for EFR: seeking help
by Mychaela Falconia 06 Apr '23

06 Apr '23

Hello GSM community, I realize that most of you over in Osmocom land would much rather see me submit Gerrit patches than write lengthy ML posts, but right now I really need some help with the algorithmic logic of a feature before I can develop patches implementing said feature - so please bear with me. The fundamental question is: what is the most correct way for a GSM network (let's ignore divisions between network elements for the moment) to construct the DL speech frame stream for call leg B if it is coming from the UL of call leg A? I am talking about call scenarios where call leg A and call leg B use the same codec, thus no transcoding is done (TrFO), and let me also further restrict this question to old-style FR/HR/EFR codecs, as opposed to AMR. At first the answer may seem so obvious that many people will probably wonder why I am asking such a silly question: just take the speech frame stream from call leg A UL, feed it to call leg B DL and be done with it, right? But the question is not so simple. What should the UL-to-DL mapper do when the UL stream hits a BFI instead of a valid speech frame? What should this mapper do if call leg A does DTXu but there is no DTXd on call leg B? The only place in 3GPP specs where I could find an answer to this question is TS 28.062 section C.3.2.1.1. Yes, I know that it's the spec for in-band TFO within G.711, a feature which I reason no one other than me probably cares about, but that particular section - I am talking about section C.3.2.1.1 specifically, you can ignore the rest of TFO for the purpose of this question - seems to me like it should apply to _any_ scenario where an FR/HR/EFR frame stream is directly passed from call leg A to call leg B without transcoding, including scenarios like a self-contained Osmocom network with OsmoMSC switching from one MS to another without any external MNCC. Let us first consider the case of FR1 codec, which is the simplest. Suppose call leg A has DTXu but call leg B has no DTXd - one can't do DTXd on C0, so if 200 kHz of spectrum is all you got, operating a BTS with just C0, then no one can do DTXd. When Alice on call leg A is silent, her MS will send a SID every 480 ms and have its Tx off the rest of the time, and the frame stream from the BTS serving her call leg will exhibit a SID frame in every 24th position and BFI placemarkers in all other positions. So what should the DL frame stream going to Bob look like in this scenario? My reading of section C.3.2.1.1 (second paragraph from the top is the one that covers this scenario) tells me that the *network* (set aside the question of which element) is supposed to turn that stream of BFIs with occasional interspersed SIDs into a stream of valid *speech* frames going to Bob, a stream of valid speech frames representing comfort noise as produced by a network-located CN generator. The spec says in that paragraph: "The Downlink TRAU Frames shall not contain the SID codeword, but parameters that allow a direct decoding." Needless to say, there is no code anywhere in Osmocom currently that does the above, thus current Osmocom is not able to produce the fancy TrFO behavior which the spec(s) seem to call for. (I said "spec(s)" vaguely because I only found a spec for TFO, not for TrFO, but I don't see any reason why this aspect of TFO spec shouldn't also apply to TrFO when the actual problem at hand is exactly the same.) But no no no guys, I am *not* bashing Osmocom here, I am seeking to improve it! As it happens, fully implementing the complete set of TS 28.062 section C.3.2.1.1 rules (I shall hereafter call them C3211 rules for short) for the original FR1 codec would be quite easy, and I already have a code implementation which I am eyeing to integrate into Osmocom. Themyscira libgsmfrp is a FLOSS library that implements a complete, spec-compliant Rx DTX handler for FR1, and it is 100% my own original work, not based on ETSI or TI or any other sources, thus no silly license issues - and I am eyeing the idea of integrating the same functions, appropriately renamed, repackaged and re-API-ed, into libosmocodec, and then invoking that functionality in OsmoBTS, in the code path that goes from RTP Rx to feeding TCH DL to PHY layers. But while FR1 is easy, doing the same for EFR is where the real difficulty lies, and this is the part where I come to the community for help. The key diff between FR1 and EFR that matters here is how their respective Rx DTX handlers are defined in the specs: for FR1 the Rx DTX handler is a separate piece, with the interface from this Rx DTX handler to the main body of the decoder being another 260-bit FR1 frame (this time without possibility of SID or BFI), and the specs for DTX (06.31 plus 06.11 and 06.12) define and describe the needed Rx DTX handler in terms of emitting that secondary 260-bit FR1 frame. Thus implementing this functionality in Themyscira libgsmfrp was a simple matter of taking the logic described in the specs and turning it into code. But for EFR the specs do not define the Rx DTX handler as a separate piece, instead it is integrated into the guts of the full decoder. There is a decoder, presented as published C source from ETSI, that takes a 244-bit EFR frame, which can be either speech or SID, *plus* a BFI flag as input, and emits a block of 160 PCM samples as output - all Rx DTX logic is buried inside, intertwined with the actual speech decoder operation, which is naturally quite complex. I've already spent a lot of time looking at the reference C implementation of EFR from ETSI - I kinda had to, as I did the rather substantial work of turning it into a usable function library, with state structures and a well-defined interface instead of global vars and namespace pollution - the result is Themyscira libgsmefr - but I am still nowhere closer to being able to implement C3211 functionality for this codec. The problem is this: starting with a EFR SID frame and previous history of a few speech frames (the hangover period), how would one produce output EFR speech frames (not SID) that represent comfort noise, as C3211 says is required? We can all easily look at ETSI's original code that generates CN as part of the standard decoder: but that code generates linear PCM output, not secondary EFR speech frames that represent CN. There is the main body of the speech decoder, and there are conditions throughout that slightly modify this decoder logic in subtle ways for CN generation and/or for ECU-style substitution/muting - but no guidance for how one could construct "valid speech" EFR frames that would produce a similar result when fed to the standard decoder in the MS after crossing radio leg B. This is where I could really use some input from more senior and more knowledgeable GSM-ers: does anyone know how mainstream commercial GSM infra vendors (particularly "ancient" ones of pure T1/E1 TDM kind) have solved this problem? What do _they_ do in the scenario of call leg A with DTXu turning into call leg B without DTXd? Given that those specs were written in the happy and glorious days when everyone used 2G, when GSM operators had lots of spectrum, and when most networks operated large multi-ARFCN BTSes with frequency hopping, I figure that almost everyone probably ran with DTXd enabled when that spec section was written - hence if I wonder if the authors of the TFO spec failed to appreciate the magnitude of what they were asking implementors to do when they stipulated that a UL-to-DL mapping from DTXu-on to DTXd-off "shall" emit no-SID speech frames that represent TFO-TRAU-generated CN. And if I wonder if the actual implementors ignored that stipulation even Back In The Day... Here is one way how we might be able to "cheat" - what if we implement a sort of fake DTXd in OsmoBTS for times when real DTXd is not possible because we only have C0? Here is what I mean: suppose the stream of TCH frames about to be sent to the PHY layer (perhaps the output of my proposed, to-be-implemented UL-to-DL mapper) is the kind that would be intended for DTXd-enabled DL in the original GSM architecture, with all speech pauses filled with repeated SIDs, every 20 ms without fail. A traditional DTXd BTS is supposed to transmit only those SIDs that either immediately follow a speech frame or fall in the SACCH-aligned always-Tx position, and turn the Tx off at other times. We can't actually turn off Tx at those "other" times when we are C0 - but what if we create a "fake DTXd" effect by transmitting a dummy FACCH containing an L2 fill frame at exactly the same times when we would do real DTXd if we could? The end effect will be that the spec-based Rx DTX handler in the MS will "see" the same "thing" as with real DTXd: receiving FACCH in all those "empty" 20 ms frame windows will cause that spec-based Rx DTX handler to get BFI=1, exactly the same as if radio Tx were truly off and the MS were listening to radio noise. Anyway, I would love to hear other people's thoughts on these ideas, especially if someone happens to know how traditional GSM infra vendors handled those pesky requirements of TS 28.062 section C.3.2.1.1 for UL-to-DL mapping. Sincerely, Your GSM-obsessed Mother Mychaela

2 5

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC April 2023