OpenBSC May 2023

openbsc@lists.osmocom.org

12 participants
14 discussions

by bryan coxwell

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

11 months, 2 weeks

libosmocore/BSC/MSC: MO voice calls rejected from Siemens S11E (patch included)

by Lennart Müller

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

1 year

Problem while running NIB on Open Cellular Base sation

by Brackley Casinga

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

1 year

Request for Assistance with GPRS Configuration

by Ahnaf Tahmid

Dear Osmocom Community, I have noticed that the wiki page for OpenBSC GPRS at https://osmocom.org/projects/cellular-infrastructure/wiki/OpenBSC_GPRS has not been updated for four years, and since then, there have been significant updates to the software. As a result, the information on the GPRS/EDGE Setup page may be outdated, and I am struggling to configure GPRS on my system. I have attached my configuration files below for your review. ip address 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp0s31f6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000 link/ether ec:8e:b5:41:cb:90 brd ff:ff:ff:ff:ff:ff 3: wlp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether b8:8a:60:4f:59:02 brd ff:ff:ff:ff:ff:ff inet 192.168.1.109/24 brd 192.168.1.255 scope global dynamic noprefixroute wlp1s0 valid_lft 7152sec preferred_lft 7152sec inet6 fe80::649b:2ab5:6dd3:8779/64 scope link noprefixroute valid_lft forever preferred_lft forever

1 year, 8 months

Enhanced RTP transport of FR & EFR in IP-based GSM RAN

by Mychaela Falconia

Hello Osmocom, I have written a new specification, in the style of 3GPP specs, for enhanced RTP transport of FR and EFR codec frames in an IP-based GSM RAN, addressing problem areas where the general standard RTP format for these codecs creates functional regressions relative to the original T1/E1 Abis architecture with TRAU frames. The new spec has its official home here: https://www.freecalypso.org/specs/tw-ts-001-v010001.txt and here is a pair of patches adding OsmoBTS support for accepting this TW-TS-001 format in RTP input and optionally (per vty config) emitting it in RTP output: https://cgit.osmocom.org/osmo-bts/log/?h=falconia/rtp_traulike The code patches are just for better context - they will go to Gerrit for review later - but right now I am soliciting a review of the specification, rather than code implementation. I am not aware of any established process in Osmocom for reviewing new specifications (different from code review), as writing new 3GPP-style specs is not something this community does often. But in the present case I am genuinely convinced that the Internet standard RTP format for GSM-FR and GSM-EFR (written with VoIP rather than GSM RAN in mind) is truly deficient for GSM RAN purposes, especially for those who wish to deploy their GSM networks in a retronetworking fashion, and the only way to bring back the full set of E1 Abis bells and whistles over IP is to invent our own (completely optional) pseudostandard format that will likely only be used within {Osmocom+Themyscira} community. With this context in mind, I cordially invite all of you, esteemed GSM FOSS developers, to review the new specification linked above. Sincerely, Mother Mychaela

1 year, 8 months

Nokia UltraSite

by Sipos Csaba

Hi Harald, I tested and can confirm that the Nokia code cannot handle a situation when the first TRX is not the first physical TRX in the cabinet. This affects MetroSite and UltraSite and all other variants that can handle more than one TRX. Given the fact these units are getting 20+ years old, backplane or other HW issues can force a user to not start with the first physical TRX and in that case the RSL bootstrap fails as the BTS receives a config starting with trx1 while the unit may has trx2 or trx3 etc. Question is how to handle this? One option is that on Nokia, each TRX has its own RSL TEI, and that is a 1:1 match as much as I know. Physical TRX1 has TEI1, TRX2 has TEI2 etc. So we can make a check during fu_config to first determine the first physical TRX based on the RSL TEI, and then check at each iteration which is the next one. For example you can have trx2 and trx4 as well, so we cannot expect that the TRX-es are in a continuous order nor that they always start with trx1. Another option is to introduce a new Nokia specific TRX variable that describes the physical location of the TRX inside the cabinet and do the above mentioned checks with that. Or there is a 3rd option I am not thinking about :-) Any and all opinions are welcome. Regards, Csaba

1 year, 8 months

Nokia UltraSite

by Sipos Csaba

Dear Harald, Sorry for the delay, the UltraSite cabinet has some massive backplane/interconnect issues, I tried to sort those out in the last couple days (with not much success). I had some time to further investigate the Nokia UltraSite situation, and here are the outstanding issues I faced: 1. 2-3 seconds after BTS_RESET the OML LAPD link is reestablished (coming from the BTS itself), and the signalling logic tries to bootstrap OML (sometimes RSL as well) during the BTS performing the reset. This tries do fail of course. Not sure if this causes any practical error, although it does not look nice. Maybe adding some logic state checks can help? 2. Sometimes on the OML LAPD link (and only on that one) I can see these error messages: DLLAPD lapd_core.c:1315 (0:1-T1-S62) S frame response with F=1 error DLLAPD lapd_core.c:421 (0:1-T1-S62) sending MDL-ERROR-IND cause 6 from state LAPD_STATE_MF_EST Sometimes they arrive in batches, sometimes only a few. FYI the BTS and the TRE both runs the latest SW ever released for UltraSite (CX8.2). 3. Moving the RSL bootstrap to after "NOKIA_BTS_CONF_COMPL" received seems to be working fine, this way we don't need to add another timer, and Osmo-BSC can wait long enough to make sure all the TRXes loaded the SW, configured and waiting for LAPD. In case more than one TRX is used, the TRXes reach the "waiting LAPD" state in different order. Did you had time to maybe try with InSite? I dont think my patch can brake it, but I remember InSite was an odd ball within the Site family. I also started to re-introduce RF/BB hopping control for Nokia, if you - or anyone - can review it that would be lovely: https://github.com/dchard/osmo-bsc/commit/41f6cd4723961700c5e5eceab4c92e7ce… I was not able to try it out yet, as due to my backplane issues with the cabinet, only TRX1 and TRX3 and TRX4 slots are working. And for some reason if I try to use TRX3 and 4, the RSL bootstrap fails. I wonder if the Nokia code has some limitation if the first TRX is not actually the first? I tried to configure Osmo-BSC to start with "trx 2" but it does not want to start anything other than "trx 0". Of course the question is what OsmoBSC sends during OML bootstrap. As much as I can see, the Nokia code does not take into account if the first TRX is not the first physically in the unit, but I am not a 100% sure yet. Some help or hint here would be very welcome. This is where I am now. The HW issues with the unit makes it pretty time consuming to focus on the SW side, for now. If you or anyone has any ideas or comments, please let me know. Regards, Csaba

1 year, 9 months

How is support for the Ericsson DUS 31/ Ericsson packetAbis/IP

by Enzo D'Amato

Hi! I just purchased a used Ericsson RBS 6000 chassis with a DUS 31 module in it. From what I have read, this module should be compatible with Open5GS for the LTE side, but I wanted to inquire about the status of support for it on the GSM side under OsmoBSC. As far as I know, it should work the same as the DUG series which is supported, with the only difference being it's use of Ericsson packetAbis/IP rather than hardware T1 lines for the voice backhaul connectivity. Will these units work with osmocom for GSM, or will I have to purchase a DUG unit for my enclosure? Is there anything else I should be aware of? Thank you, Enzo D'Amato

1 year, 9 months

Jenkins Builder spurious failure

by Mychaela Falconia

It looks like there is something wrong with the Jenkins Builder invoked by Gerrit: https://jenkins.osmocom.org/jenkins/job/gerrit-binpkgs-rpm/5274/consoleFull The errors in that log seem like something to do with the build environment (couldn't download RPM for libtalloc-devel?) and nothing to do with the patch which I submitted to Gerrit. Which is: https://gerrit.osmocom.org/c/osmo-bts/+/32788 M~

1 year, 9 months

OsmoDevCall presentation proposal: FR/HR/EFR speech handling

by Mychaela Falconia

Dear Osmocom community, Over the past several months I've been working almost exclusively on improving FR1 and EFR speech handling in the Osmocom GSM network implementation. All of my Gerrit patches since March have been in this area, and my two Themyscira-branded public domain libraries for GSM codecs are also primarily intended for use together with Osmocom, specifically for implementation of transcoding media gateways that interconnect an Osmocom GSM network with a non-GSM outside world such as G.711 PSTN. Given the knowledge I've gained over months of working in this area, and seeing that many other Osmocom developers aren't particularly familiar with these aspects of the specs (understandable: GSM is huge, can't keep everything in one's head), I would like to do an OsmoDevCall presentation on the topic of GSM speech handling with traditional non-AMR codecs. I would like to cover the following subtopics: * What metadata bits (BFI, UFI, SID, TAF) are defined in the specs for transport of encoded speech between network elements, beyond the familiar speech codec bits themselves. * What exactly are regular speech frames, SID frames, silence frames (a "silence frame" for FR1 codec is NOT the same thing as a SID frame!) and bad frame gaps, and which of these categories are allowed or not allowed to exist at each of the interfaces in the spec-defined GSM architecture. * Which transformations are supposed to happen where: which network elements are responsible for bad frame handling, error concealment, comfort noise insertion or SID propagation. * How these architectural principles, originally defined for the T1/E1 environment with TRAUs, can be carried over to an RTP environment. * Relevant Osmocom components: OsmoBTS and the aspect of OsmoMGW that interfaces from RTP to T1/E1 Abis. * What behavior changes have been effected by my patches to OsmoBTS and supporting libraries that have already been merged, and which behavior changes are still on my wish list or to-do list to implement and hopefully get merged. Looking at the OsmoDevCall wiki page, I see absolutely nothing scheduled past May, and there was no OsmoDevCall in April - are we out of presenters? But we have just one problem: it seems that some people in the senior leadership of Osmocom organization don't want me presenting on OsmoDevCall, and recently even asked specifically for presentation ideas from "anyone other than Mychaela". I see two possible solutions to this problem: Option 1: If the leaders in question could set aside their personal dislike of me and allow me to present on highly Osmocom-relevant topics (such as the FR/HR/EFR codec presentation proposal above) no different from other Osmocom developers, that would be the best solution. Option 2: If those who control the scheduling of presentations on the official OsmoDevCall platform (the official BigBlueButton instance for ODC) are not willing to budge, the alternative will be for me and Das Signal (my dear friend and FreeCalypso sysadmin) to set up our own BBB instance on our own server, configure it to look and feel exactly like the official one used for ODC, hold presentations there during those months when no official ODC presentation takes place due to lack of non-excluded willing presenters, and invite everyone from Osmocom to join those unofficial ODC-like presentations. So - which of the two is it going to be? Sincerely, Mother Mychaela, operator of a non-profit GSM network based on Osmocom, contributing to Osmocom CNI development in conjuction with that network operation.

1 year, 9 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC May 2023