OpenBSC

openbsc@lists.osmocom.org

14 participants
4246 discussions

Nokia Site (Ultra, Metro)
by Sipos Csaba 01 Jul '23

01 Jul '23

Hi Harald, > Is that patch already in gerrit somewhere? https://github.com/dchard/osmo-bsc/tree/nokia_ultrasite I managed to get some InSite units so now I have the whole range. I tested all units, and this is the result: 1. InSite: it does not initiate the RSL LAPD even when the unit reports: "waiting for lapd", the BSC needs to start the RSL bootstrap. Non the less, multi BTS operation does work (tried it with HDSL cascade), although I have seen some weird behavior between bootstraps (just starting the BSC does not trigger the same behavior). 2. MetroSite: this unit does start the RSL bootstrap on its own when the TRXes reaches "waiting for lapd" state, it does not wait for the BSC to do it. Multi TRX, RF and BB hopping works as expected. 3. UltraSite: it runs exactly the same SW version as the MetroSite, yet this unit also does not start the RSL bootstrap on its own even when the unit reports: "waiting for lapd", the BSC needs to start the RSL bootstrap. Only single TRX works in this case. Also the MetroSite does not spits out garbage on the E1, the InSite and UltraSite does. In general one issue is that even after the BTS reset is ACKed, the BSC allows the RSL LAPDs to be bootstrapped while the unit is already resetting, and that fails obviously. But more importantly, it seems that the whole LAPD logic is not working exactly the same across the unit types. I wonder if we should wait more for the RSL to be triggered by the BTS itself and should not start the RSL bootstrap after CONF_COMPLETE received. I found no info about who should initiate the RSL bootstrap: the BTS or the BSC? Regards, Csaba <openbsc-request(a)lists.osmocom.org> ezt írta (időpont: 2023. jún. 30., P, 14:00): > > Send OpenBSC mailing list submissions to > openbsc(a)lists.osmocom.org > > To subscribe or unsubscribe via email, send a message with subject or > body 'help' to > openbsc-request(a)lists.osmocom.org > > You can reach the person managing the list at > openbsc-owner(a)lists.osmocom.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OpenBSC digest..." > > Today's Topics: > > 1. Re: Nokia Site (Ultra, Metro) (Harald Welte) > 2. Re: code review (Harald Welte) > 3. Re: Nokia Site (Ultra, Metro) (Harald Welte) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 30 Jun 2023 12:08:43 +0200 > From: Harald Welte <laforge(a)osmocom.org> > Subject: Re: Nokia Site (Ultra, Metro) > To: Sipos Csaba <dchardware(a)gmail.com> > Cc: "openbsc-request(a)lists.osmocom.org" <openbsc(a)lists.osmocom.org> > Message-ID: <ZJ6pq/2V9WfA3yDw@nataraja> > Content-Type: text/plain; charset=us-ascii > > Hi Sipos, > > On Fri, Jun 23, 2023 at 11:18:35AM +0200, Sipos Csaba wrote: > > I checked RF and BB hopping with my MetroSite with my patch added, and > > they both seem to work, multi-TRX was tested a couple days ago, that > > also works with 2 TRXes. Obviously I did not tested every possible > > hopping scenarios, but in both cases the node manager reported the > > correct hopping states and I also checked with a spectrum analyzer. > > This is good news. Is that patch already in gerrit somewhere? > > > Anyway, at this point in time I don't see any particular issues that > > indicates a BSC problem. One feature missing is the ability to > > configure sectors (Nokia calls a sector a "BTS" while the base station > > is called "BCF"). My question is, do we have any BTS type that has > > sector configuration support so I can take a look how this was done > > (if any) ? > > I think we never had support for this in OsmoBSC or even before in OpenBSC. > > In GSM/3GPP spec language, every sector is a BTS. The fact that many networks > use sectorized cells is nothing that reflects anywhere in the specification or > the terminology. It's an implementation detail. > > I think from the OsmoBSC point of view, a typical 3-sector site would still be > three logical BTSs (in the data model / structures). It's "just" the respective > manufacturer OML code would have to be adjusted to accomodate a situation where > there are managed objects that only exist once per site, while others > exist per BTS/TRX/... > > We have the same situation with Ericsson OM2000 support: Right now one > can only have a single BTS per RBS, as our OM2000 code doesn't > distinguish between MOs that exist once per site only (CF, TF, IS, ...) > and MOs that exist for each BTS. > > -- > - Harald Welte <laforge(a)osmocom.org> https://laforge.gnumonks.org/ > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) > > ------------------------------ > > Message: 2 > Date: Fri, 30 Jun 2023 12:02:11 +0200 > From: Harald Welte <laforge(a)osmocom.org> > Subject: Re: code review > To: Neels Hofmeyr <nhofmeyr(a)sysmocom.de> > Cc: openbsc(a)lists.osmocom.org > Message-ID: <ZJ6oI2u2l9wAJ2Eo@nataraja> > Content-Type: text/plain; charset=us-ascii > > Hi Neels, > > On Wed, Jun 21, 2023 at 05:37:55AM +0200, Neels Hofmeyr wrote: > > Let me compare two larger feature branches: > > There are weeks of review on 19 patches in osmo-hnbgw/cnpool, > > and <24h from submit to merge on 14 patches in osmo-msc. > > I'm not saying this is good, but I think the difference is likely in terms of > complexity of the related patches. Small patches doing simple to understand > things are easy to review and hence likely to be merged more quickly. > > > The cnpool patch series for osmo-hnbgw spawned huge discussions and long delays > > on account of minor issues: log lines, event names and comments. I said so, yet > > it droned on and even spawned offspring. > > It would be good to have pointers to specific gerrit patches here. I'm trying to > look at it now, but topic:cnpool has so many patches that it's hard to find which > ones you're referring-to exactly. > > https://gerrit.osmocom.org/c/osmo-hnbgw/+/33133 has a discussion about > parsing of routing area identities and using shared code rather than > open-coded implementations in various places. I consider that relevant > and not cosmetic/bikeshedding > > https://gerrit.osmocom.org/c/osmo-hnbgw/+/33173 contains a discussion > about naming. Naming *is* important, particularly if it uses terms > which already have well-established meaning, such as (here) what is a > RANAP RESET and what is a "lost link". Code in maintained software > development projects is written not merely to execute, but for other > developers to read and continue to develop/maintain. If terminology is > used in a wrong way, it is likely misunderstood by other developers, > causing problems down the road when investigating bugs or adding new > functionality. I am seeing quite a lot of questionable naming in > general when it comes to SS7/SIGTRAN. Also, event/state names of FSMs > may end up in log or VTY output, where it has the potential to confuse > not just other developers but users. > > https://gerrit.osmocom.org/c/osmo-hnbgw/+/33178 contains a "maybe add a > log line" spawning a discussion with relatively verbose messages in it. > That might be one of the cases you are referring to? To be fair it was > a "maybe" comment, so a simple one line response might have been > sufficient. > > > None of the important features was part of code review: > > larger design choices of the API, efficiency in handling the actual signalling, > > correctness of the signalling. > > tbh, if there's a series of (it feels like) 30+ patches doing lots of complex > stuff, it's hard to assume anyone is able to grasp those from reading > the diffs. For correctness of signalling the test cases and > associated pcaps are probably a better resource than gerrit patch > review. > > > And at the same time I was "just now" asked to review some patches for > > osmo-msc, which changes an API that I have recently added and had ideas and > > reasons for. > > again, please provide specific pointers. Without that you are expecting > every reader of this e-mail to re-read all osmo-msc patches of the last > few weeks just to find out which specific one[s] you are referring to. > > It might have been https://gerrit.osmocom.org/c/osmo-msc/+/33358/1 where > I overlooked a *resolved* comment "Not merging this one yet to give > Neels a chance to review as well since he wrote the codec filter stuff > that this is now modeled after." which I didn't see as the patch and > many following it had two positive reviews and built correctly and hence > I merged the entire series. > > My workflow is usually to perform code review, and then if I'm done and > there are series or parts of series with V+1/R+2 merge those entire > series/chunks, particularly if there are no unresolved comments. > I'm [obviously] not going through each and every resolved comment of > every patch in a series. Those are *resolved*. > > So while it was me who merged that series, and I'm of course sorry if > that created problems, I acted in good faith (see above). > > I think if anyone wants to hold back a merge for whatever reason, make > sure you put a -1 vote in so it becomes impossible to be merged by > accident. Or at the very least make sure there is an unresolved comment > which will produce a warning when attempting to merge. > > > Before I get a chance to even glance, I see that all the patches > > are already merged! It is now basically too late to bring in my feedback, > > because the patches are in, and why spend more time on it. Suck it up, bygones. > > It's not all lost: One can always send follow-up patches? Or revert the > original patch and replace it? No release has been made in between, so > no stable API has been set in stone that needs to continue to be > supported. > > > Also I have (in my own free time) tried to get an improved logging timestamp > > into libosmocore. This is tagging along for years and years now, because every > > time over it is being blocked by minor details that are matters of taste. For > > years I lose precious moments every time i have to read an 'extended-timestamp' > > in osmo logging and identify the boundary of hours, minutes and seconds. This I > > consider important. AFAIR the reasons for blocking the patches were, > > objectively, all not important. > > I always found it mildly fascinating how many options, choices and > formats (I think primarily you) introduce to the libosmocore logging. > Like file name in front or file at the end? I think osmo* is the only > software with which I've worked where the actual *format* of the log has > many user-configurable options. I'm not talking about sub-systems, > levels and targets! Now we even have multiple different formats for > timestamps, and we are growing more of them. In my opinion, most of > this is bloat. It just adds complexity to things happening at the > runtime of the osmo-* code for something that could just as well be > obtained with log post-processing (like converting from a unix epoch > timestamp to whatever human readable format the reader desires). We've > already merged a lot of this over the years. > > To me, the problem with all those many options is that it becomes > very difficult to have any software parsing/analyzing osmo* logs, as > every deployment might be chosing a different combination of "this is my > personal favorite of ordering the portions of a log line" or "this is my > personal favorite of formatting a timestamp". > > But now introducing *timezones* into the program > (https://gerrit.osmocom.org/c/libosmocore/+/32043) really goes over the > top for me. Timezones are handled at the operating system level / libc. > > > Let's still give all the code review we can, but let's keep in mind the actual > > impact the particular code change has. If it goes in the "fringe detail" > > bucket, let's mention it, but just let it pass if the author disagrees. > > To be honest, I don't really see much of this here. I see a lot of > optional / non-critical stuff like "typo here" or "maybe ..." but I > rarely see "I absolutely demand that you must ...". > > Regards, > Harald > > -- > - Harald Welte <laforge(a)osmocom.org> https://laforge.gnumonks.org/ > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) > > ------------------------------ > > Message: 3 > Date: Fri, 30 Jun 2023 12:09:27 +0200 > From: Harald Welte <laforge(a)osmocom.org> > Subject: Re: Nokia Site (Ultra, Metro) > To: Sipos Csaba <dchardware(a)gmail.com> > Cc: "openbsc-request(a)lists.osmocom.org" <openbsc(a)lists.osmocom.org> > Message-ID: <ZJ6p15URO27eoMei@nataraja> > Content-Type: text/plain; charset=us-ascii > > On Sun, Jun 25, 2023 at 03:08:51PM +0200, Sipos Csaba wrote: > > I tested up to four TRX with the Metro and that works as well. Once > > everything is tested and working I will provide example files, and try > > to updated the Nokia specific wiki as it is quite outdated (info is > > from the NITB era). > > Thanks in advance! > > > Will try to look at Ericsson and BS-11, maybe there are some clues > > about sectors there. > > See my other mail, unfortunately it's not something implemented. > -- > - Harald Welte <laforge(a)osmocom.org> https://laforge.gnumonks.org/ > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > OpenBSC mailing list -- openbsc(a)lists.osmocom.org > To unsubscribe send an email to openbsc-leave(a)lists.osmocom.org > > > ------------------------------ > > End of OpenBSC Digest, Vol 104, Issue 8 > ***************************************

1 0

Nokia Site (Ultra, Metro)
by Sipos Csaba 30 Jun '23

30 Jun '23

Hi Neels, I checked RF and BB hopping with my MetroSite with my patch added, and they both seem to work, multi-TRX was tested a couple days ago, that also works with 2 TRXes. Obviously I did not tested every possible hopping scenarios, but in both cases the node manager reported the correct hopping states and I also checked with a spectrum analyzer. This means that either my UltraSite still has some issues, or that the config logic for it needs a bit of tuning. The one difference I have noticed is that the MetroSite does starts the RSL LAPD when the TRXes reach a configured state, while the UltraSite needs the BSC to start the RSL LAPD links even after the TRXes reach the same configured state. FYI, I am running exactly the same BTS SW release on both units (latest LTS ever released by the vendor), so they should not behave differently from a pure SW point of view. Anyway, at this point in time I don't see any particular issues that indicates a BSC problem. One feature missing is the ability to configure sectors (Nokia calls a sector a "BTS" while the base station is called "BCF"). My question is, do we have any BTS type that has sector configuration support so I can take a look how this was done (if any) ? Regards, Csaba

3 4

BSC to multiple external MSCs
by Varoon Greedharry 22 Jun '23

22 Jun '23

Hello, I know it's quite a dummy question (Beginner) but I'm actually trying the BSC to two external MSCs but the attempt failed. As per the doc, I did configure the cs7 instance. Is there an example configuration file which I could go through. -- Best Regards, Varoon

2 2

Re: OpenBSC Digest, Vol 104, Issue 1
by Sipos Csaba 21 Jun '23

21 Jun '23

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 2

OsmoDevCall on Jun 21, 2023: FR/HR/EFR voice codecs in Osmocom RAN
by Harald Welte 21 Jun '23

21 Jun '23

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)

1 0

Nokia UltraSite
by Sipos Csaba 08 Jun '23

08 Jun '23

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 1

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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC