OpenBSC

openbsc@lists.osmocom.org

5 participants
4170 discussions

by Sipos Csaba

Hi Neels, Sorry for the late response. As there is still a slight chance that the issue on my side is HW related, I digged out my old MetroSite with 4 TRX as that is a little bit smaller and easier to move compared to the Ultra cabinet :-) So I will conduct some tests with it in the next couple days. Lets say the issue is the same: what exactly do you need from me to maybe look into it? I assume E1 pcap and logs. If you have a specific log mask, or you need something else, please let me know. Regards, Csaba

2 years, 2 months

OsmoDevCall on Jun 21, 2023: FR/HR/EFR voice codecs in Osmocom RAN

by Harald Welte

Dear Osmocom community, we're happy to announce the next incarnation of OsmoDevCall. when: June 21, 2023 at 20:00 CEST where: https://osmocom.org/OsmoDevCall (Big Blue Button) This time, @falconia will be leading a discussion on FR/HR/EFR voice codecs in Osmocom RAN This meeting will have the following schedule: 20:00 meet + greet 20:10 topic as outlined above 21:00 unstructured supplementary social event [*] Attendance is free of charge and open to anyone with an interest in Osmocom or open source cellular technologies. More information about OsmoDevCall, including the schedule for further upcoming events can be found at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall Looking forward to meeting you soon! Best regards, Harald [*] this is how we started to call the "unstructured" part of osmocom developer conferences in the past, basically where anyone can talk about anything, no formal schedule or structure. -- - 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)

2 years, 2 months

Nokia UltraSite

by Sipos Csaba

Hi Harald, I made some progress with the Nokia UltraSite and managed to fix its backplane, so at least I was able to continue with reintroducing hopping control with the first 2 TRX slots of the cabinet. During this process I realized that apparently even multi-TRX support is broken, which was working on the old OpenBSC codebase in 2016. If only the first TRX is configured the BTS bootstraps fine, but when a second TRX is configured, the unit goes into this weird state: the first TRX loops through configurng and waiting for LAPD states and stays in configuring state, while the second TRX is stuck ad supervisory state where TRX test is possible (it does pass the test). I used my old multi-TRX config file that actually worked with UltraSite (and MetroSite) where the second TRX only has TCH/F so nothing fancy, no hopping or anything like that. I wonder if my modification of moving the RSL bootsrap to after CONF_COMPLETE somehow changed something, maybe the BTS requires the RSL LAPD links to be up during the CONF state? Or the new FSM lchan refactoring might have introduced this in 2018... So apparently we have some more basic issues here then hopping :-) Regards, Csaba

2 years, 2 months

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

2 years, 2 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

2 years, 2 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

2 years, 3 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

2 years, 3 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

2 years, 3 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~

2 years, 3 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.

2 years, 3 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC