OpenBSC September 2025

openbsc@lists.osmocom.org

7 participants
15 discussions

New MGW for E1 Abis, future ThemWi sw plans
by Mychaela Falconia 24 Nov '25

24 Nov '25

Dear Osmocom community, I am pleased to announce the first usable version of my new MGW for use with OsmoBSC and E1-based BTS: https://gitea.osmocom.org/themwi/tw-e1abis-mgw This new sw component works as a drop-in replacement for osmo-mgw in the role of BSC-associated MGW for E1 Abis. Principal new features compared to OsmoMGW-E1 are: * The path from RTP input to fixed-timing TRAU-DL output passes through ThemWi jitter buffer (twjit), instead of blindly converting every received RTP packet to a TRAU-DL frame, queueing those frames to I.460 MUX Tx and hoping for the best. * For FR codec in the present implementation and for EFR coming later, a proper UL-to-DL transform (aka TFO transform) is applied to this RTP-to-DL path. This way if the stream of UL frames from the other call leg includes gaps due to radio errors, FACCH stealing or DTXu pauses, or if gaps are caused by packet loss, the stateful transform will produce proper error concealment or comfort noise insertion per TS 28.062 section C.3.2.1.1. * CSD is supported! This development may be the first time in Osmocom history of CSD working on an E1-based BTS. I tested this new MGW with Nokia InSite BTS and confirmed it working with all 3 classic GSM voice codecs (FR, HR and EFR) and with CSD up to 9600 bps. CSD at 14400 bps (D145_SYNC and EDATA frames) is supported too, but remains untested due to lack of needed support in OsmoMSC. My eventual goal is to use OsmoBSC and this new MGW with Ericsson RBS6k BTS, consisting of DUG20 and RUS or RRUS. I already have DUG20 and RUS01 hardware, but given all other work I still have to do on ThemWi CN software, I haven't got around to playing with Ericsson gear yet. My plans going forward are: * Get back to twrtp patches in Gerrit: implement the next round of changes per last round of review, and hopefully get twrtp into libosmo-netif so we can make it an option in OsmoBTS, in addition to E1 BTS. * Finish long-deferred work on libgsmhr1 in gsm-codec-lib. HRv1 codec is of course of no practical interest, can be regarded as a "just for fun" retronetworking feature, but I need to finish it so certain ThemWi components can rely on having encoders and decoders for all GSM codecs always available, and my TFO transform for HRv1 will serve as a stepping stone toward much more important TFO transform for EFR. * After the above, the big work item for me will be ThemWi-MSC. I won't get into details as I don't like writing about vaporware, but many of you know that currently I am still stuck on 2023-02 version of OsmoMSC while running newer versions of all other components. ThemWi-MSC will be my proper solution, but I'll write about it in detail only when it becomes a reality. Never stopping work toward restoration of top-quality GSM/2G networks, Mother Mychaela

2 1

Splitting out M3UA and MTP3 out of Open BSC into a separate library
by Arran Cudbard-Bell 20 Nov '25

20 Nov '25

Hi, Developing a module for FreeRADIUS to support EAP-SIM and EAP-AKA authentication against a HLR. The HLR we were targeting only supported a SCTP/M3UA/SCCP/TCAP/MAP stack, so we couldn't use SUA. Ripping the M3UA/MTP3 code out of OpenBSC worked surprisingly well. We ended up running the event loop in a separate thread to work around the threading issues. Unfortunately the HLR implements the ANSI variant of everything, whereas OpenBSC and supporting libraries seem to have been written to be compatible with the ITU standards. ...but the differences are fairly minor at MTP3 and SCCP layers, and i've started work on a patchset for libosmo-sccp. https://gerrit.osmocom.org/#/c/73/ Anyway, trying to gauge interest in splitting those layers out of Open BSC into a separate library, would be happy to take on M2UA as well for consistency. It would almost certainly get more projects using the code. There's very little out there even in Perl land for working with SS7. Thanks, -Arran Arran Cudbard-Bell <a.cudbardb(a)freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

6 6

Managing Complicated Laws in BSC Implementations
by Fennellmarian018＠gmail.com 20 Nov '25

20 Nov '25

The complexities of Base Station Controller (BSC) integration in open-source mobile networks have presented me with a number of overlapping areas pertaining to telecommunications legislation and regulatory compliance. In order to better comprehend how international legal standards affect open BSC installations in various jurisdictions, this intersection has unanticipatedly prompted me to seek [url=https://dissertationwritinghelp.uk/law-dissertation-help/]law dissertation help[/url]. I would love to hear from anyone else who has studied legal issues in their OpenBSC-related academic or practical work, as well as suggest some books.

2 1

Struggling to Find the Right Assignment Writing Help? Let’s Talk!
by teves20525＠binafex.com 19 Nov '25

19 Nov '25

I’ve been exploring different options for assignment writing help lately, but the process feels more confusing than I expected. There are so many services out there—some promise quick delivery, others focus on quality but it’s hard to know which ones actually deliver on their claims. For those who’ve gone through this search before, how did you decide which service to trust? Did you rely on reviews, personal recommendations, or trial and error? I’ve also seen people recommend specific options when they needed to buy dissertation work, which made me wonder if the same tips apply to regular assignments. What red flags should I watch out for? And are there any hidden factors like customer support or revision policies that made a big difference in your experience? Visit Here: https://www.helpwithdissertation.co.uk/write-my-dissertation-proposal/

2 1

ip.access nano 3G S8 Configuration
by John Thewlis - Meath Broadband 18 Nov '25

18 Nov '25

We are trying to setup this AP as part of the 3.5G Osmocom project. We have the software stack operational and are now preparing the nano for testing. When we try to login via telnet at port 8090 we are getting a constant refusal to connect:- root@osm/openbsc/openbsc/src/ipaccess# telnet 192.168.192.30 8090 Trying 192.168.192.30... telnet: Unable to connect to remote host: Connection refused The device seems to be locked as indicated by the leds on the front panel. We have tried resetting the nano to see if this would help but to no avail. Any ideas as to how to access the device for initial configuration?. Thanks John

4 4

cmd2 update causing pySim-shell to fail
by bryan coxwell 18 Nov '25

18 Nov '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

6 6

GPRS - local and foreign TLLIs
by Luca Melette 18 Nov '25

18 Nov '25

Hello everybody, after setting up a nanoBTS with OpenBSC/SGSN/GGSN, I had some troubles trying to connect my smartphone to the GPRS cell. Investigating the BTS-to-SGSN traffic, I saw that the frames sent by the SGSN were all marked with the same N(U) value (at LLC layer), the value was 0. With some debug, I found that the there was a mismatch in the TLLI storage, used to keep the status of attached terminals. The mentioned code is contained in gprs_llc.c, involving LL Entity functions and gprs_llc_tx_ui(). /* look-up or create the LL Entity for this (TLLI, SAPI) tuple */ lle = lle_by_tlli_sapi(msgb_tlli(msg), sapi); if (!lle) { struct gprs_llc_llme *llme; LOGP(DLLC, LOGL_ERROR, "LLC TX: unknown TLLI 0x%08x, " "creating LLME on the fly\n", msgb_tlli(msg)); llme = llme_alloc(msgb_tlli(msg)); lle = &llme->lle[sapi]; } The TX function uses the previously received TLLI to lookup for the LLE. The lle_by_tlli_sapi() performs the search, but preliminary it applies a foreign2local TLLI conversion to ensure to have a local one. Since no valid entry for the searched TLLI is found, a new one is created. And the problem is here. The new entry has the foreign TLLI. Next time the lookup fails again, and a new entry is created. This way, the counter N(U) is always reset, and the mobile do not recognize the message sequence and no attach is possible. My question is about foreign and local TLLIs. I patched the lookup, avoiding the conversion, so that the LLE is found and everything works fine... but... What is the sense of the conversion? Should the TLLI be always stored as a local one? Can this problem be solved with another foreign2local while allocating new entries? Actually, my problem has been solved with that workaround. But I'm curious to know what is the right way. Hope somebody can answer :) Thanks. Cheers, LM

4 5

Need nano3G (S8 - Model 237A)
by Akib Sayyed 18 Nov '25

18 Nov '25

Dear List I am extremely sorry for off the topic question. I am willing to buy nano3G Nodeb. Is anyone in list have spare which can be sold. Please let me know. -- Akib Sayyed Matrix-Shell akibsayyed(a)gmail.com akibsayyed(a)matrixshell.com Mob:- +91-966-514-2243 <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

4 3

Best Review Platforms UK for Small Businesses in 2025?
by olivianaylor322＠gmail.com 14 Nov '25

14 Nov '25

Hey everyone! I'm looking to boost my online presence and would love some suggestions. What are the best review platforms UK https://truereviews.uk/ businesses are using right now? I'm mainly targeting local customers, so trustworthy and widely-used platforms are key. Any tips or experiences with Trustpilot, Google Reviews, or others? Thanks in advance!

2 1

More efficient RTP transport for CSD
by Mychaela Falconia 25 Sep '25

25 Sep '25

Dear Osmocom community, Those of you who had occasion to work with CSD probably noticed that the standard RTP payload format prescribed for AoIP by 3GPP Rel8+ (64 kbit/s CLEARMODE) is extremely wasteful: 160 bytes of payload every 20 ms (compared to a maximum of 33 bytes every 20 ms for voice calls), and most of that 160-byte CLEARMODE payload is constant filler. The actual information content for CSD channels traveling across A interface (data bits plus all metadata preserved, strictly lossless conversion) fits into 16 bytes for CSD modes up to 4.8 kbit/s, 32 bytes for 9.6 kbit/s or 37 bytes for 14.4 kbit/s - much more compact than the 160-byte standard! Because my non-profit org in USA (American 2G Cooperative) will soon be operating a public GSM/2G network as a membership co-op, we have a legal and ethical obligation to provide all services strictly at cost. Radio resource usage is exactly the same between voice and data calls, while CPU load on tw-border-mgw machines in the CN will often be even less with CSD than with EFR or AMR speech transcoding - hence there is no legitimate reason for CSD calls to be more expensive than voice. Yet the bloated RTP format prescribed by 3GPP Rel8+ artificially increases the cost of IP transport within the network. My solution to the problem: yet another TW-TS, specifying a modified version of AoIP interface with compressed CSD. Here is the spec: https://www.freecalypso.org/specs/tw-ts-007-v010001.txt An updated version of TW-TS-003 (BSSMAP extension spec) spells out how the MSC requests the use of compressed CSD instead of standard TS 48.103 on AoIP by adding RTPext IE to ASSIGNMENT REQUEST or HANDOVER REQUEST, with the right bit set to request TW-TS-007 RTP format. In terms of implementation of this newly defined feature in Osmocom, my plan is as follows: * Within the past couple of years I extended osmo_trau2rtp() and osmo_rtp2trau() to support CSD on E1 BTS, using standard CLEARMODE format on RTP side. I plan to extend these functions to support TW-TS-007 as well. * Combination of mainline OsmoBSC plus tw-e1abis-mgw has fully working CSD with E1 BTS, already tested with Nokia InSite. If my idea for representing TW-TS-007 compressed CSD format in MGCP/SDP is acceptable (please see chapter 9 and Annex A in the spec linked above), I would like to extend OsmoBSC to be able to command tw-e1abis-mgw via MGCP/SDP to emit either standard CLEARMODE or TW-TS-007 per request from MSC. The above points are for E1 BTS. With IP-native OsmoBTS, we have two options: 1) We could add more logic to OsmoBTS to emit either standard CLEARMODE or TW-TS-007, just like we already do for TW-TS-001/002 carrying TRAU-UL metadata bits for FR/HR/EFR. 2) We could leave OsmoBTS completely unchanged, speaking only standard CLEARMODE format for CSD, and have OsmoBSC-associated OsmoMGW convert on the fly (we are dealing with strictly lossless conversion here, not bringing back extra metadata as with other TW-TS) if the MSC asked for TW-TS-007 compressed RTP format. Option 2 seems easier to implement, and I am leaning toward this option. Of course this option only makes sense when osmo-bsc, osmo-mgw and osmo-bts-trx run on the same SBC next to or inside SDR-based BTS, or when the link between the BSC and the BTS is a local Ethernet cable, while A interface travels across public Internet or other networks where bandwidth matters. What does the community think? For my own operation E1 BTS is a higher priority (I still plan on using surplus Ericsson RBS6k gear), hence there is plenty of time for Osmocom community to provide feedback on how y'all would like to see this mechanism working with IP-native OsmoBTS. In terms of upcoming Gerrit patches related to TW-TS-007, I plan to work on libosmo-abis next, implementing lossless conversion functions and extending osmo_trau2rtp() and osmo_rtp2trau() for efficient, native support of compressed CSD. GSM/2G Forever, Mother Mychaela P.S. If anyone has constructive criticism regarding chapter 9 or Annex A in the TW-TS-007 spec linked above (AoIP and SDP aspects), it is not too late to revise those parts.

2 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC September 2025