OpenBSC

openbsc@lists.osmocom.org

5 participants
4178 discussions

Merging tw-e1abis-mgw into mainline Osmocom

by Mychaela Falconia

Dear Osmocom community, A little over a month ago I announced availability of this new MGW: https://osmocom.org/projects/retro-gsm/wiki/ThemWi_E1_Abis_MGW So far only two people responded to this news: Csaba has been testing this new MGW on his Nokia MetroSite (he and I are working toward adding AMR support), while Keith took only a passing notice - if I understood him correctly (please forgive me if I misunderstood!), it looks like Rhizomatica/TIC no longer operate GSM networks with Ericsson RBS gear, hence no more need for improved E1 MGW from their side. However, I am getting a sense that the larger Osmocom community may be disappointed regarding my choice to develop this improved E1 Abis MGW as a "rogue" project external to Osmocom, rather than in the form of patches to osmo-mgw. Therefore, I have given some thought to how it might be possible to merge this new E1 MGW into mainline Osmocom. Here are my current thoughts: 1) Integrating improved functionality of tw-e1abis-mgw into osmo-mgw in a fully unified manner, full coexistence of all existing osmo-mgw functionality plus all tw-e1abis-mgw functionality within a single program/process, running on one MGCP port and providing both rtpbridge and E1 endpoints, is beyond my ability, or at least beyond what I can do using only my own volunteer time. osmo-mgw code base is extremely complex, and as much as I dread to say it, insanely and needlessly so - it is a Gordian knot, and I tend to approach those the way Alexander did... 2) As an intermediate compromise between the too-difficult goal of point 1 above and the current status quo of tw-e1abis-mgw existing externally to Osmocom, how would Osmocom community feel about a hypothetical osmo-e1-mgw program? Suppose I were to produce patches that add osmo-e1-mgw as a new program to osmo-mgw git source tree, such that osmo-mgw and osmo-e1-mgw binaries would be built side by side in the same source tree - any interest? The actual code bases compiling into these two binaries would still be mostly separate, just the autotools infra of osmo-mgw git tree would be shared, but the new osmo-e1-mgw program would carry Osmocom branding, and it would live in a mainline Osmocom repository where people other than me can shape its future direction. Please note that I don't need this integration for myself: for our own use on our to-be-built network, we (A2GC) are quite happy running the hybrid software stack where some components are built from Osmocom source repositories while other components are built from ThemWi repos. Instead I am making this offer to Osmocom community for social reasons: I wish to continue as an active member of this community, if possible, and fork-like activities are certainly _not_ the way to go, socially. I am also making this integration offer to the community as food for thought, without any urgency. If the greater Osmocom community does wish to see tw-e1abis-mgw turned into something like osmo-e1-mgw, integrated into mainline Osmocom, it will probably be another few months before I can start submitting patches in this direction. The reason for the delay is that tw-e1abis-mgw is not quite finished at the present moment: two big missing features are AMR support and UL-to-DL transform (aka TFO transform) for EFR. I would like to fill these two functional gaps in the new MGW while staying in my own tw-e1abis-mgw source tree, before beginning the process of merging into Osmocom mainline - hence the time delay prognosis. If Osmocom community does wish to see the improved E1 MGW as part of mainline Osmocom code base, I would need an explicit "green light" go-ahead before I start preparing any patches. The patch process would need to proceed as follows: 1) I will need to prepare a patch for libosmocore, adding a header file with definitions from 3GPP TS 48.103 Table 5.4.2.2.1. Right now ThemWi software, including tw-e1abis-mgw, uses <themwi/common/aoip_rtp_pt.h> header file - but of course the latter won't be available in pure Osmocom environment without ThemWi dependencies. 2) There will need to be a whole bunch of patches to libosmo-abis.git (libosmotrau portion thereof), adding various functions which I currently collect in libtwtrau and which will be used by the upcoming AMR-capable version of tw-e1abis-mgw. 3) Only after 1 and 2 above are merged, then I'll able to produce a big patch for osmo-mgw.git, adding osmo-e1-mgw (or whatever other name the community comes up with) as a new program. In any case, in the immediate short term I am going to continue improving tw-e1abis-mgw where it lives currently, in ThemWi area of Osmocom Gitea. Once AMR support and UL-to-DL transform for EFR are there, I will make another post here. At that point if the greater community would like to see this work merged, I will need feedback in this ML thread. GSM/2G Forever, Mother Mychaela

21 hours, 33 minutes

Artvigil Australia: A Trusted Solution for Enhanced Focus and Wakefulness

by csheldon756＠gmail.com

Artvigil in Australia is a popular nootropic medication known for promoting wakefulness and mental alertness. Containing Armodafinil, it is often prescribed to manage sleep disorders such as narcolepsy, shift work sleep disorder, and obstructive sleep apnea. Many professionals and students also use Artvigil to improve focus, productivity, and cognitive performance. Available through reputable online pharmacies, Artvigil offers a reliable alternative to Modafinil with longer-lasting effects. Australians seeking a safe and effective way to stay alert can buy Artvigil online after consulting a healthcare professional to ensure proper dosage and safe usage- https://www.healthmatter.co/product/artvigil-150/

2 days, 4 hours

Re: Merging tw-e1abis-mgw into mainline Osmocom

by Sipos Csaba

Hi Mychaela, My two cents on the subject is that any solution seems better than a fork. This is a small community, what we are doing is even more niche. Visibility is as important as the features themselves, therefor whatever the community thinks is appropriate to somehow integrate/merge these into existing Osmocom projects (MSC/MGW and libraries), seems like a better approach. In this sense probably option 2. seems an easy way out of this for now. I am also planning to add more Nokia BTSes to the supported list, namely Flexi EDGE, Multiradio and Multiradio 10. If anyone has access to a minimal viable setup (BTS+1 RF unit at least), or has equipment and can provide remote access, and/or want to donate it, please let me know. Of course older Nokia units (Talk family and even older units) are also welcome. Regards, Csaba

2 days, 20 hours

More efficient RTP transport for CSD

by Mychaela Falconia

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 weeks, 4 days

Financial Accounting Assignment Help

by Katherine Salvator

When it comes to managing complex coursework, finance and accounting students face significant challenges. Topics like balance sheets, income statements, ratio analysis, and tax accounting require accuracy, strong analytical skills, and deep subject knowledge. This is where Financial Accounting Assignment Help becomes a game-changer. With expert guidance, students not only receive well-researched and error-free assignments but also gain conceptual clarity that helps them perform better in exams and real-world applications. Beyond finance, students across multiple disciplines struggle with time constraints, formatting issues, and academic pressures. This makes Online Assignment Help a reliable resource for UK learners. From essays and dissertations to case studies and research projects, experts provide tailored solutions that meet academic standards and strict deadlines. The service ensures plagiarism-free content, proper referencing, and professional presentation—qualities that professors value highly. By combining subject expertise with timely support, services like Rapid Assignment Help make a real difference in students’ academic journeys. Whether it’s accounting or any other subject, learners can rely on professional assistance to balance their studies, improve grades, and gain confidence. With the right support, academic stress turns into academic success.

2 weeks, 6 days

Mobile disassociates from sysmobts 1002 after call

by Christoph Quirin Lauter

Hello, I am sorry, this might not be the right place to ask. I am kind of a newbie to the osmocom stack as well, so please be gentle with me. I recently got an FCC license in the 900MHz range and I am running sysmobts 1002 at home. I have updated it from NITB to the modern world of course. Everything seems to work as it should but there is one issue: A Pixel 9 Pro Android phone with a sysmocom SIM card (999/70) connected to the sysmobts disassociates -in certain cases- with the BTS/BSC after a call and displays "No network". It will never reassociate again, unless I put the phone in airplane mode and back on. Then it reassociates immediately again. I cannot see anything particular in the osmo-bsc/osmo-bts-sysmo logs but as I said, I am a newbie. I will be happy to post the logs if this is helpful. The issue does not arise for each call, only certain calls. I use osmo-sip-connector to an asterisk. Is this a known issue? Is it an issue with the phone? Did I configure something in a wrong way? I will do some experiments with another GSM phone. Thank you! Christoph Lauter

1 month

Move vlr code from osmo-msc into a own library

by Alexander 'lynxis' Couzens

Hi, a couple month ago I proposed to make the VLR code of the osmo-msc independent of the osmo-msc and create a new library called libosmo-vlr. Later use the libosmo-vlr code to integrate it into osmo-sgsn. But after take more time of this approach, I'm not sure if it is a very good idea to guarantee high stability of libosmo-vlr as we do for other osmocom libraries. Because the code is heavily integrated with both daemon and some code path are quite complex and partly not fully understood. I would rather guarantee runtime stability within a library version, but not at build time. The strategy would be increasing the library major version more often. Any thoughts? Best, lynxis PS. The current concept (because of time pressure) is to keep 2 copies of libosmo-vlr in the code base of osmo-msc and osmo-sgsn and to move it later out of it into an own library.

1 month

Having trouble balancing GSM projects and coursework?

by fennellmarian018＠gmail.com

As someone knee-deep in OpenBSC settings and attempting to gain a firm understanding of BTS to BSC handovers, I've struck a stumbling block in balancing my technical deep dives with academic duties. Between tracing Abis interface logs and diagnosing paging issues, I barely have time to concentrate on my finance studies. To be honest, I've pondered finding someone to take my accounting class for me so that I can continue with my telco experiments here. I'm not sure whether anyone else is dealing with the same workload, but if you've discovered a solid workflow or technique, I'd love to hear about it because OpenBSC is currently capturing my full attention. visit: https://takemycourseforme.us.com/pay-someone-to-take-my-online-accounting-c…

1 month

Struggling with Assignments? Let’s Talk About It!

by teves20525＠binafex.com

Hey everyone, I’ve been seriously overwhelmed lately trying to manage all my coursework, deadlines, and part-time job. It’s got me thinking how do others handle the pressure? I’ve been considering looking into an online university assignment help UK service but I’m not sure where to begin. Are these services reliable? Have you used one that actually delivered quality work without breaking the bank? I’m really looking for honest recommendations or red flags to avoid. What should I keep in mind before choosing one? Let’s share experiences maybe we can help each other out! Visit here: https://assignmenthelpinuk.co.uk/university-assignment-help/

1 month, 1 week

New MGW for E1 Abis, future ThemWi sw plans

by Mychaela Falconia

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

1 month, 1 week

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC