OpenBSC

openbsc@lists.osmocom.org

4315 discussions

Request for Assistance with GPRS Configuration
by Ahnaf Tahmid 29 May '23

29 May '23

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

3 6

Enhanced RTP transport of FR & EFR in IP-based GSM RAN
by Mychaela Falconia 29 May '23

29 May '23

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 0

Nokia UltraSite
by Sipos Csaba 25 May '23

25 May '23

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 0

Nokia UltraSite
by Sipos Csaba 23 May '23

23 May '23

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 0

How is support for the Ericsson DUS 31/ Ericsson packetAbis/IP
by Enzo D'Amato 20 May '23

20 May '23

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 2

Jenkins Builder spurious failure
by Mychaela Falconia 19 May '23

19 May '23

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~

3 2

OsmoDevCall presentation proposal: FR/HR/EFR speech handling
by Mychaela Falconia 15 May '23

15 May '23

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.

3 3

gsm-codec-lib-r2 new release
by Mychaela Falconia 12 May '23

12 May '23

Hello GSM community, I just put a new release of Themyscira GSM codec libraries and utilities package: ftp://ftp.freecalypso.org/pub/GSM/codecs/gsm-codec-lib-r2.tar.bz2 ftp://ftp.freecalypso.org/pub/GSM/codecs/gsm-codec-lib-latest.tar.bz2 (symlink) The two libraries in this package (libgsmefr and libgsmfrp) are intended for people who develop gateway software interconnecting Osmocom-based GSM networks to PSTN or other networks, gateways which include a speech transcoding function that terminates the GSM codec leg. If anyone is currently interconnecting an Osmocom GSM voice network to the outside world using software which you did not write yourself (Asterisk, FreeSwitch, Kamailio, whatever) and you care about the plain old FR codec, and/or care about EFR, beyond just AMR, I encourage you to investigate your current non-Osmocom gateway software to see exactly how it implements FR and EFR. Because there were NO pre-existing FOSS libraries that correctly implement FR and EFR decoding prior to my Themyscira gsm-codec-lib development, most pre-existing gateway software probably implements these codecs in a flawed manner: FR codec: Everyone to my knowledge implements this codec using classic libgsm, a library that dates back to 1990s. It's a good library, it's a fully correct implementation of GSM 06.10 spec, and I use it too. However, it implements _only_ a bare 06.10 encoder and a bare 06.10 decoder, without any DTX functions of GSM 06.31 and related specs. In the encoder direction having no DTX isn't really a problem (you won't be able to do DTXd anyway unless you got lots of spectrum and are running multi-ARFCN cells), but the lack of an Rx DTX handler per GSM 06.31 *is* a real problem: if you feed the uplink from a GSM call (RTP stream from a BTS) to a bare GSM 06.10 decoder such as gsm_decode() function in libgsm, you won't get correct handling of SID frames, which every standard GSM MS will transmit, and you won't get correct handling of BFI frame gaps, which will always occur. The correct solution is to insert a call to a GSM 06.31 Rx DTX handler (it is more than an ECU) just before the call to gsm_decode(), and my libgsmfrp offering is that GSM 06.31 Rx DTX handler. EFR codec: Everyone other than me implements EFR (if they support it at all) using an AMR library such as libopencore-amrnb. I have seen totally broken implementations that schlep 244-bit payloads directly between supposed-to-be-EFR RTP and the AMR library, without reordering those bits per gsm690_12_2_bitorder[] - those implementation have exactly zero chance of ever actually working with a real GSM-EFR MS on the other end - and I've also seen implementations that do perform this bit reordering and are thus closer to correct. But even the latter implementations are still wrong when it comes to SID handling: EFR is equivalent to the highest MR122 mode of AMR only for regular speech frames, but not for SID. There does exist a special encoding format for representing GSM-EFR SID in AMR frame interfaces, but libopencore-amrnb does not support GSM-EFR SID in any way at all. If you take the uplink from a GSM-EFR call and feed it to libopencore-amrnb decoder, any time the GSM MS emits a SID frame, strange noise sounds will appear at the output of that decoder, instead of the correct comfort noise. Themyscira libgsmefr is a proper encoder and decoder library for EFR, based on the EFR reference code from ETSI, in exactly the same way how libopencore-amrnb is based on the AMR reference code from ETSI/3GPP. It still has some performance problems which I will be working on later (the goal of getting it to perform no worse than libopencore-amrnb has not been achieved yet), but at least it is correct. Hasta la Victoria, Siempre, Mychaela aka The Mother

1 0

Osmo-BSC with Nokia UltraSite
by Sipos Csaba 12 May '23

12 May '23

Dear Harald, A long time passed since I worked with the Nokia Site family and OpenBSC. I managed to save an UltraSite cabinet from scrap, so I try to revive it for a museum. On the old NITB versions I managed to make this work once, now I am trying with the new (at least to me) Osmo-BSC implementation. To keep it simple, only one TRX is configured: OML <--> E1 TS 1 (64kbit) RSL <--> E1 TS 2 (64kbit) TRXSIG <--> E1 TS 3 and 4 DAHDI is used with a Digium Wildcard TE110P T1/E1 Board. Osmo-BSC is able to do the OML bootstrap, but the RSL waits for LAPD endlessly. My first question is: should Osmo-BSC be able to bootstrap the BTS fully (all the way to "on air" mode) if it is not (yet) connected to any other core element (MGW, MSC, STP) ? This is the Osmo-BSC log (after the NOKIA_BTS_RESET command + the reset_wait_time passed): DLLAPD input/lapd.c:245 (0:1-T1-S62): LAPD Allocating SAP for SAPI=62 / TEI=1 (d l=0x56284cfbd220, sap=0x56284cfbd200) DLLAPD input/lapd.c:255 (0:1-T1-S62): k=1 N200=3 N201=260 T200=1.0 T203=10.0 DLLAPD input/lapd.c:519 (0:1-T1-S62): LAPD DL-ESTABLISH request TEI=1 SAPI=62 DLLAPD input/lapd.c:654 (0:1-T1-S62) LAPD DL-ESTABLISH confirm TEI=1 SAPI=62 DNM bts_nokia_site.c:63 (bts=0) bootstrapping OML DNM bts_nokia_site.c:1729 (bts=0) Rx ABIS_OM_MDISC_FOM DNM bts_nokia_site.c:1573 (bts=0) Rx (0x82) NOKIA_BTS_OMU_STARTED DNM bts_nokia_site.c:1583 (bts=0) Rx BTS type = 17 (UltraSite GSM 900) DNM bts_nokia_site.c:1098 (bts=0) Sending NOKIA_BTS_START_DOWNLOAD_REQ DNM bts_nokia_site.c:1729 (bts=0) Rx ABIS_OM_MDISC_FOM DNM bts_nokia_site.c:1573 (bts=0) Rx (0x84) NOKIA_BTS_MF_REQ DNM bts_nokia_site.c:1729 (bts=0) Rx ABIS_OM_MDISC_FOM DNM bts_nokia_site.c:1573 (bts=0) Rx (0x88) NOKIA_BTS_CONF_REQ DNM bts_nokia_site.c:1098 (bts=0) Sending NOKIA_BTS_ACK DNM bts_nokia_site.c:1260 (bts=0) Sending multi-segment 0 DNM bts_nokia_site.c:1260 (bts=0) Sending multi-segment 1 DNM bts_nokia_site.c:1729 (bts=0) Rx ABIS_OM_MDISC_FOM DNM bts_nokia_site.c:1573 (bts=0) Rx (0x81) NOKIA_BTS_ACK DNM bts_nokia_site.c:1604 (bts=0) Rx ACK = 1 DLLAPD input/lapd.c:245 (0:2-T1-S0): LAPD Allocating SAP for SAPI=0 / TEI=1 (dl= 0x56284d252a20, sap=0x56284d252a00) DLLAPD input/lapd.c:255 (0:2-T1-S0): k=2 N200=3 N201=260 T200=1.0 T203=10.0 DLLAPD input/lapd.c:519 (0:2-T1-S0): LAPD DL-ESTABLISH request TEI=1 SAPI=0 DLLAPD lapd_core.c:421 (0:2-T1-S0) sending MDL-ERROR-IND cause 1 from state LAPD _STATE_IDLE DLLAPD input/lapd.c:658 (0:2-T1-S0) LAPD DL-RELEASE indication TEI=1 SAPI=0 DLLAPD input/lapd.c:282 (0:2-T1-S0): LAPD Freeing SAP for SAPI=0 / TEI=1 (dl=0x5 6284d252a20, sap=0x56284d252a00) DCHAN lchan_fsm.c:1779 lchan(0-0-0-CCCH_SDCCH4-0)[0x56284d251770]{UNUSED}: (type =NONE) lchan allocation failed in state UNUSED: LCHAN_EV_TS_ERROR DCHAN lchan_fsm.c:197 lchan(0-0-0-CCCH_SDCCH4-0)[0x56284d251770]{UNUSED}: (type= NONE) lchan activation failed (lchan allocation failed in state UNUSED: LCHAN_EV _TS_ERROR) DCHAN lchan_fsm.c:1779 lchan(0-0-0-CCCH_SDCCH4-1)[0x56284d2519b0]{UNUSED}: (type =NONE) lchan allocation failed in state UNUSED: LCHAN_EV_TS_ERROR DCHAN lchan_fsm.c:197 lchan(0-0-0-CCCH_SDCCH4-1)[0x56284d2519b0]{UNUSED}: (type= NONE) lchan activation failed (lchan allocation failed in state UNUSED: LCHAN_EV _TS_ERROR) DCHAN lchan_fsm.c:1779 lchan(0-0-0-CCCH_SDCCH4-2)[0x56284d251bf0]{UNUSED}: (type =NONE) lchan allocation failed in state UNUSED: LCHAN_EV_TS_ERROR DCHAN lchan_fsm.c:197 lchan(0-0-0-CCCH_SDCCH4-2)[0x56284d251bf0]{UNUSED}: (type= NONE) lchan activation failed (lchan allocation failed in state UNUSED: LCHAN_EV _TS_ERROR) DCHAN lchan_fsm.c:1779 lchan(0-0-0-CCCH_SDCCH4-3)[0x56284d251e30]{UNUSED}: (type =NONE) lchan allocation failed in state UNUSED: LCHAN_EV_TS_ERROR DCHAN lchan_fsm.c:197 lchan(0-0-0-CCCH_SDCCH4-3)[0x56284d251e30]{UNUSED}: (type= NONE) lchan activation failed (lchan allocation failed in state UNUSED: LCHAN_EV _TS_ERROR) Would be nice to make this old beast running again. Much appreciate any and all help. Regards, Csaba

2 5

T1/E1 beyond the BTS - how about BSC and TRAU?
by Mychaela Falconia 12 May '23

12 May '23

Hello Osmocom, I know a lot of people here have salvaged T1/E1 BTS equipment from Nokia, Ericsson etc. But what about the next level up - has anyone been able to salvage a classic T1/E1 BSC that goes with those BTSes? And given the hardware, does anyone in our community know how to get one of those beasts working? I am interested in the TRAU component of the classic GSM BSS architecture, and I would really love to lay my hands (remotely, via OCTOI, would be just fine) on one of those beauties. Specifically, I seek to feed custom-crafted bits to the TRAU's Abis input and capture what it puts out on the A interface G.711 side, and vice-versa. What can be learned from such experiments? Several things: * I would love to play with TFO: see the TFO_REQ in-band signaling messages the TRAU should put out on its own during the first 5 s or so, then send our own TFO_REQ and TFO_ACK to the TRAU, do the whole protocol, and get the TRAU to actually enter TFO mode. Reading the spec is one thing, but seeing it in action would be so much more fun! I've also been wanting to write my own FOSS implementation of in-band TFO within G.711 RTP, but it would be an impractical task without having some other existing implementation to test against. * If we can get TFO to work, we'll be able to see exactly how real TRAUs handled the onerous requirements of TS 28.062 section C.3.2.1.1. Implementing those rules for FR1 would be quite easy, but try doing the same for EFR or HR1 - *very* daunting! It would be lovely to see exactly what actual historical implementations did here. * Outside of TFO, we should be able to get the TRAU into a known state by feeding it spec-defined encoder and decoder homing frames, and then craft our own test sequences (beyond the standard ones it was surely tested with by its designers) to exercise those parts of the codec implementation where the specs allow implementors to innovate, particularly everything to do with error concealment. But doing all of the above requires access to some old-style T1/E1 BSC that contains such a TRAU. Does anyone in our community have access to such hw? M~

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC