OpenBSC

openbsc@lists.osmocom.org

8 participants
4276 discussions

Fwd: OpenAirInterface releases 5G core network code
by Neels Hofmeyr 26 Sep '20

26 Sep '20

Possibly interesting to note this OAI announcement. Unfortunately none of the links are direct, but all of them are ugly tracking links. Also ads for facetwoogle. So I had to blank out a lot. Also interesting to note how they don't self-host, but rather spread their code across *both* hosted-gitlab and github. Also interesting how the From: address is a gmail one vs. the contact(a)openairinterface.org further below. In a massive herd effort, folks are fudging up the internet, no news there at least. ~N ----- Forwarded message from OpenAirInterface Software Alliance <osalliance5g(a)gmail.com> ----- Date: Fri, 25 Sep 2020 05:40:17 +0000 From: OpenAirInterface Software Alliance <osalliance5g(a)gmail.com> To: nhofmeyr(a)sysmocom.de Subject: OpenAirInterface releases 5G core network code X-Mailer: MailChimp Mailer - **CIDbb030ed5232925faf6b6** ** OpenAirInterface releases 5G core network code ------------------------------------------------------------ Dear Community, The OpenAirInterface Software Alliance is pleased to announce the release of the OAI 5G Core Network code. An initial set of features is already available and developments with a solid team are underway to build the rest of the 3GPP 5G SBA core. The project home page is here (<blanked-tracking-link>) and gives a good overview of the development phases and the roadmap. The AMF (<blanked-tracking-link>) and the SMF (<blanked-tracking-link>) code is available on GITLAB. While working to release the UPF code, we are working with the SPGW-U (<blanked-tracking-link>) on the GITHUB. A CI bench is already operational and in place. Any new features or developments introduced by community developers will automatically launch the CI pipeline and changes will only merge after having thoroughly been tested against third party testers and the OAI 5G RAN test benches. We cordially invite the community to contribute to the developments of the OAI 5G core network and reach out to contact(a)openairinterface.org for any questions and contribution proposals. The OpenAirInterface Software Alliance Team* [removing a ton of tracking links] ----- End forwarded message -----

2 1

Structure alignment problems in PCUIFv9 and PCUIFv10
by Vadim Yanitskiy 21 Sep '20

21 Sep '20

Hi all, we seem to have problems with structure alignment in the new version of the PCUIF protocol: PCUIFv9: sizeof(struct gsm_pcu_if) -> 212; 212 % 4 == 0 PCUIFv10: sizeof(struct gsm_pcu_if) -> 1006; 1006 % 4 != 0 I think we would need to add/remove some padding. The question is whether we should make sure that all structures are aligned, or having the top level struct gsm_pcu_if aligned would be enough? Even in PCUIFv9 not all structures are properly aligned: sizeof(struct gsm_pcu_if_data_cnf_dt) -> 21; 21 % 4 -> 1, sizeof(struct gsm_pcu_if_rts_req) -> 13; 13 % 4 -> 1, sizeof(struct gsm_pcu_if_rach_ind) -> 15; 15 % 4 -> 3, sizeof(struct gsm_pcu_if_pag_req) -> 11; 11 % 4 -> 3, sizeof(struct gsm_pcu_if_susp_req) -> 11; 11 % 4 -> 3. I devise by 4 because the widest member is uint32_t in all cases. Kind regards, Vadim. -- - Vadim Yanitskiy <vyanitskiy at sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte

2 2

working dahdi config for Ericsson RBS 2000
by Ivan Babanov 19 Sep '20

19 Sep '20

Hello! Can anybody share a working /etc/dahdi/system.conf file? I'm trying to bring up RBS 2000 with osmo-bsc and I'm not sure that I have correct configuration. 1. Which signaling should be used? CAS? CCS? RBS? 2. There is the same thing with framing. hdb3? 3. parameter "dslot=1,4" pointed in RBS2000 wiki looks wrong. dahdi_cnf does not work with it at least now. Thank you Ivan

2 1

Re: Support for new SDR devices
by Harald Welte 17 Sep '20

17 Sep '20

Hi Xaver, [posting this on the mailing list, as it may be of interest to others] On Fri, Sep 11, 2020 at 04:55:35PM +0200, Xaver Zu wrote: > This is a dynamic linking. this is true, but the nature of the linking does not matter in terms of what creates the derivative work. > Is this a problem even if I do not distribute the resulting binary? The AGPL (contrary to the GPL) conditions start when users remotely interact with your software (See Section 13 of AGPLv3). This means even operating a network with remote users already means you need to provide the complete and corresponding source code to the entire work under AGPLv3, which is impossible if you have a proprietary dependency. So if you build the software, and you make sure that nobody but yourself every uses the resulting GSM network, you are fine. But as soon as any third party uses it, you would be putting yourself in the impossible position to providing the source code to a proprietary library. > I can simply add a warning to the file that the compiled program cannot be distributed. One might consider this a "further restriction" which by itself is a violation of AGPLv3: All other non-permissive additional terms are considered "further restrictions" within the meaning of section 10. [...] You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License. But even beyond that: How many users do you think willread that warning in the source code vs. how many will simply run it (and possibly allow others to register). Even if you added a message to start-up, and to the user manual, I still would think many people don't look at that. I don't think we should distribute something that "tricks" people into committing license violations or putting them in an impossible position, legally speaking. > Is it a violation that someone assembles and uses it on their own machine? It is not a violation as long as they are they only person using the resulting GSM network (or using its VTY or its TRXC/TRXD interface). I would compare distributing source code like that to shipping a product that is almost impossible to use safely, but very easy to use in a [legally] unsafe way. > Is it a violation to even have sources and build instructions for it? Maybe not, but see above, I don't want to make it too easy for people to shoot themselves into their foot. > Can we agree to leave it as a starting point until someone will have the > time to do it using IPC? I'm very sorry (really), but we will not merge this code to the mainline osmo-trx code base on osmocom.org. Kind regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

4 13

Alternatives to CalypsoBTS?
by Mychaela Falconia 12 Sep '20

12 Sep '20

Hello GSM network side folks, I assume that most of you are probably aware of the existence of a certain hack called CalypsoBTS: it's a rather unbelievable hack that takes a piece of hw meant to be a GSM MS and turns it into a poor man's GSM BTS, all inherent asymmetry in the GSM air interface be damned. As a manufacturer of Calypso-based GSM MS devices I occasionally get approached by people who seek to acquire a Calypso device seemingly for the sole purpose of running that CalypsoBTS hack, and every time I get approached by someone of that sort, I always shake my head in bewilderment - isn't there a better way to get your own little toy BTS running than to misuse GSM MS hardware? The purpose of the present post is to solicit advice from the community as to what I should tell those poor souls who are seeking to set up their own toy BTS and are looking to do it via the CalypsoBTS route - is there some better way that we as a community can steer them toward instead? It is my understanding - please correct me if I'm wrong - that the least expensive way to set up your own GSM BTS for toy purposes (as opposed to running a real operational GSM network which people will depend on for real communication) is to use a generic SDR device of one of several types that are supported by osmo-bts-trx/osmo-trx - but this is where my knowledge in this area ends, as this particular mode of GSM toying has never been an area of interest for me. But for those people who (unlike me) *are* interested in setting up their own toy BTS in the least expensive way, what SDR hardware should we as the community recommend for them? What is the cheapest option that will be good enough - especially if the criteria for "good enough" are compared to CalypsoBTS? What would be the least expensive option that is just good enough to be advocated as a better alternative to the CalypsoBTS hack? In the case of my current FCDEV3B hardware the price tag seems to be an effective deterrent against people misusing it as CalypsoBTS: FCDEV3B is expensive, and someone whose actual need is to run their own BTS rather than MS can easily buy a suitable SDR device for the same price or less, it seems. But the issue is beginning to rear its ugly head again because I have another development board in the works (not here yet, probably won't have the hw until December), and there is a possibility (nothing is certain yet) that it might be a bit less expensive than FCDEV3B. Is there an SDR-based option (or any other non-CalypsoBTS option) for running a toy BTS with osmo-bts-trx and the Osmocom CNI stack behind it that would cost $250 or less in hardware? The $250 number comes from my anticipated-around-December new FreeCalypso development board - there is a chance that it might be that cheap (but again, absolutely nothing is certain at the present moment) - and if there is no SDR or other option for running your own toy BTS for the same or lower hw price, then I fear that I am going to be flooded with support requests from people asking for help with using my new board as CalypsoBTS, which I absolutely dread. Hence my present attempt to pre-emptively seek some better solution for those people. (It would be nice if that stream of support requests from people seeking to run the CalypsoBTS hack could be redirected to Sysmocom or some other commercial entity who could make some money helping those people, but my experience is that these people are not the kind who would ever pay for commercial support, so no hope there...) It may also be worth mentioning that the filter replacement hack (removing or replacing Rx SAW filters that are meant to limit the GSM MS device's Rx capability to only specific GSM downlink bands) will not be possible on the new FreeCalypso GSM MS board that will be coming around December - that design uses an integrated RF FEM (front end module) instead of discrete antenna switch and SAW filter components. But I've also heard that plenty of people run the CalypsoBTS hack without doing any filter rework, just letting the strong signal from a nearby GSM MS force its way through wrong SAW filters and not caring about the 40 dB or so of attenuation being incurred - I cringe at the thought, but that's what people do... M~

3 4

Question on osmo-trx mcbts
by Harald Welte 12 Sep '20

12 Sep '20

Hi Thomas, it's been some time, hope you're doing fine! Today on IRC we were collectively wondering about one detail in the osmo-trx mcbts implementation that has been there from day one: Your're creating the Channelizer and Synthesis class for four channels of 800kHz within the 3.2Mbps wideband-channel. So far so good. But why does the code ever only use up to three of them? And why is there a specific re-ordering, see radioInterfaceMulti.cpp in getLogicalChan() ? It would be great if you could share your thoughts on that. To me, it looks like the constraint to 3 channels is arbitrary and we should just as well be able to use all four? Thanks, Harald -- - 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 2

Fwd: Support for new SDR devices
by Xaver Zu 12 Sep '20

12 Sep '20

That library does a lot of work. Configures HW, sends samples to FPGA via DMA, does calibration, normalization, format conversions ... Highly optimized for Intel CPU. If everything were to be done in an equivalently closed version, it would take several years of work for me. I would like to start with a simple proof-of concept. Implementing only the functions used in osmo-trx-pciesdr. In the first phase, these can be only dummy functions writing or reading zeros. I assume that the GPL violation problem will be solved from the moment I will be able to build the library and link it with osmo-trx and run it. The next step is just a matter of effort from anyone in the community. Xaver

1 0

Re: Support for new SDR devices
by Harald Welte 11 Sep '20

11 Sep '20

Hi Xaver, On Fri, Sep 11, 2020 at 07:51:50AM +0200, Xaver Zu wrote: > I created a short Wiki page. Please see if it's enough as a link to a > commit message. > https://osmocom.org/projects/sdr/wiki/PCIeSDR Thanks. For sure it is sufficient in terms of content. I did some minor reformatting while reading. However, I found a major problem. You state: > The higher-level driver (in userspace) includes a DSP, a calibration stage, and the gateware update. It is in the form of a closed source dynamic library named libsdr.so. The C API for Linux / x86 is in the form of a header file libsdr.h which also serves as brief documentation. This is incompatible with the strong copyleft licensing (AGPLv3) of osmo-trx! You cannot directly link with a proprietary library. The only way I can see a PCIeSDR backend for osmo-trx would be via osmo-trx-ipc, which provides a general-purpose sharde memory interface to another process. The other process can then use the non-free library, if you want that. -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

OsmoDevCon / COVID-19
by Harald Welte 07 Sep '20

07 Sep '20

Dear fellow Osmocom developers, as you all know, we've sadly had to postpone OsmoDevCon 2020 back in April this year. At the time, we discussed to re-visit the situation in October 2020. While legally it is no problem at all to host an event with ~ 20 participants in Berlin/Germany (specific regulations really only start from 50+ participants) - I'm not entirely convinced it would be the smartest move. Legality and public health regulations are only one part of the equation - common sense and profound care for the key members of our community for sure are more relevant considerations to me. I'm not 100% in favour and not 100% against. Hence, I would like to get your input. Should we a) try to get an event organized on-site in Berlin? We'd have to move to a larger venue than IN-Berlin with proper ventilation and sufficient space so we can keep physical distance, but I think that's manageable for sysmocom as organizer. b) simply postpone to 2021? I'm convinced the situation will not change significantly (in a positive way) until late April 2021, so it's not really a "solution" as it will likely mean we have to think of late 2021 or 2022. c) plan some kind of online conference? To be honest, I think this model works fine for events where a single speaker wants to give lectures to hundreds or thousands of participants. But OsmoDevCon is much more interactive. We could record or live-stream some talks or screencasts from home, sure. But that only captures one part of the event. We could also try to set a date for a collaborative mumble, or the like - for the "hallway track". What are your thoughts? Let's avoid cross-posting the discussion to all of the mailing lists and simply have it on openbsc(a)lists.osmocom.org. Regards, Harald -- - 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)

3 2

Re: New Defects reported by Coverity Scan for Osmocom
by nhofmeyr＠sysmocom.de 27 Aug '20

27 Aug '20

On Tue, Aug 25, 2020 at 02:49:39AM +0000, scan-admin(a)coverity.com wrote: > *** CID 212862: Error handling issues (CHECKED_RETURN) > /source-Osmocom/osmo-pcu/src/pdch.cpp: 211 in gprs_rlcmac_pdch::packet_paging_request()() > 205 > 206 /* loop until message is full */ > 207 while (pag) { > 208 if (log_check_level(DRLCMAC, LOGL_DEBUG)) { > 209 struct osmo_mobile_identity omi = {}; > 210 char str[64]; > >>> CID 212862: Error handling issues (CHECKED_RETURN) > >>> Calling "osmo_mobile_identity_decode" without checking return value (as is done elsewhere 20 out of 22 times). > 211 osmo_mobile_identity_decode(&omi, pag->identity_lv + 1, pag->identity_lv[0], true); > 212 osmo_mobile_identity_to_str_buf(str, sizeof(str), &omi); > 213 LOGP(DRLCMAC, LOGL_DEBUG, "Paging MI - %s\n", str); > 214 } I'd like to let you guys know that I intentionally don't check the return value here. This is only for logging the mobile identity, and if decoding fails, the logging should just show "NONE". ~N

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC