OpenBSC September 2020

openbsc@lists.osmocom.org

14 participants
24 discussions

Re: Help with sccp library
by mosbah abdelkader 08 Jul '25

08 Jul '25

> I don't understand. This callback will be called with data you need to write > to the network. In case of MTP Level3 you will need to wrap that around the > msgb you got. I means: is the interaction with mtp3 layer implemented (is sending sccp data by mtp3 implemented by the library?)? Also, what about the reception of data from mtp3 layer. is that implemented in the sccp lib. I am asking these questions because I see the code of mtp3 in the lib but no significant call is present in the sccp part of the lib. Thank you for your help.

4 3

dynamic traffic channels
by Neels Hofmeyr 20 May '25

20 May '25

On Tue, Jun 28, 2016 at 10:05:28AM +0200, Harald Welte wrote: > [translated from german] > is it certain that we switch a channel to PDCH only when > gprs mode != none? A TS can be GSM_PCHAN_TCH_F_PDCH; those are the only ones for which we send a PDCH ACT message. We send a PDCH ACT message - during init (CHANNEL OML's state changed to enabled -> send PDCH ACT), - and upon channel release ack when pchan == GSM_PCHAN_TCH_F_PDCH. So the question is, when we receive a channel release ack, could that be the PDCH release and we switch PDCH right back on by accident? No, because we only receive a chan rel ack when the *TCH/F* is being released. That is because the PDCH release is initiated "internally" from the PDCH DEACT, and thus this condition in common/rsl.c rsl_tx_rf_rel_ack() catches on, which existed before dyn PDCH: if (lchan->rel_act_kind != LCHAN_REL_ACT_RSL) { LOGP(DRSL, LOGL_NOTICE, "%s not sending REL ACK\n", gsm_lchan_name(lchan)); return 0; } In rsl_rx_rf_chan_rel() the rel_act_kind is set to LCHAN_REL_ACT_RSL, but not in the rsl_rx_dyn_pdch(). This is analogous to the ip.access way -- the ip.access nanobts replies to a PDCH DEACT with a PDCH DEACT ACK and doesn't send a separate channel release ack. Maybe we could set rel_act_kind to some new LCHAN_REL_ACT_IPAC_DYN_PDCH for clarity? (But we shouldn't actually send a release ack, to stay compatible.) Even though it works as-is, we should indeed add another flag check: - We do check the flags that no ACT/DEACT is already pending; - And we do send a PDCH DEACT only if ts->flags & TS_F_PDCH_ACTIVE; - But we would send a PDCH ACT despite ts->flags & TS_F_PDCH_ACTIVE. This should never happen, but it would make sense to ensure that. ~Neels

3 5

Problem while running NIB on Open Cellular Base sation
by Brackley Casinga 31 Jan '24

31 Jan '24

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

2 1

Application specific VTY attributes
by Vadim Yanitskiy 06 Oct '20

06 Oct '20

Hi Philipp, while reading your comments to: https://gerrit.osmocom.org/c/osmo-bsc/+/19670 https://gerrit.osmocom.org/c/osmo-mgw/+/20250 I realized that it would be better to discuss here. My initial idea was that the absence of attributes (in the command definition and thus in the VTY reference) implicitly indicates that a given VTY command in the 'config' node comes into effect immediately. This way we would only need to add attributes to commands requiring program restart or reestablishment of some link(s) / connection(s). However, in some applications *most* of the commands may require full program restart. Or the opposite: most commands may apply immediately. Adding same attributes to every command is annoying, so I came up with a concept of default 'applies when' policy: what if we add a new field to 'struct cmd_node' indicating default attributes of all commands belonging to it? struct cmd_node foo_node = { .node = FOO_NODE, .prompt = "%s(config-net)# ", .vtysh = 1, .usrattr = (1 << FOO_VTY_ATTR_RESTART_FULL), // (!) }; This way a DEFUN() command definition would inherit foo_node.usrattr, and a DEFUN_USRATTR() command definition would override it. dexter wrote: > I just wonder if there could be a VTY_ATTR_RESTART_FULL predefined in > libosmore. Almost any of the osmo program will need it. Maybe also an > VTY_ATTR_RESTART_IMMEDIATE? ACK. I think they could be even moved to generic attributes: /*! Attributes (flags) for \ref cmd_element */ enum { CMD_ATTR_DEPRECATED = (1 << 0), CMD_ATTR_HIDDEN = (1 << 1), CMD_ATTR_APPLY_IMMEDIATE = (1 << 2), CMD_ATTR_APPLY_FULL_RESTART = (1 << 3), }; dexter wrote: > Maybe we could have some standard letters defined in libosmocore > for standard situations: > F = Full restart required > I = Applied Immediately ACK. We can also agree that generic (pre-defined) attributes use upper case letters, while the application specific ones use lower case? What do you think about these ideas? If you agree, and nobody has any objections, I can quickly implement them in libosmocore. Would be also nice to know what other developers think. Neels, Harald, Pau, Daniel? Best 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

4 10

libosmocore stderr log performance / blocking
by Harald Welte 30 Sep '20

30 Sep '20

Hi! >From time to time we've been discussing logging related stalling of osmocom programs, particularly in the context of the stderr log target. In general, when we log to stderr, we perform a blocking, buffered write. So any slow output on stderr will slow down the entire osmocom program. I've taken some time to play with this using bpftrace and usdt (static userspace probes) in order to determine the latency of log statements in osmocom programs. My test program doesn't do anything else but an endless LOGP() of verying length (from 1..512 characters). It was executed on a Lenovo Thinkpad X260 (i7-6600U, 16GB RAM, SATA SSD with btrfs on top of dm-crypt). I've compared * launching the program in uxterm * launching the program in gnome-terminal * launching the program in screen (detached) * launching the program in screen (attached; printing via uxterm) * launching the program with 2>/dev/null * launching the program with 2>/file/on/btrfs/on/ssd * launching the program from systemd (with journald) * replacing stderr logging with gsmtap log target (without wqueue) The resulting histograms of the time spent for writing the logs are below. The git repo containing the test program, the libosmocore usdt patch and the bpftrace program can be found at git://git.osmocom.org/laforge/osmo-logbench.git == launching the program in uxterm @usecs: [2, 4) 30 | | [4, 8) 199963 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@| [8, 16) 82294 |@@@@@@@@@@@@@@@@@@@@@ | [16, 32) 6897 |@ | [32, 64) 1649 | | [64, 128) 57 | | [128, 256) 221 | | [256, 512) 8588 |@@ | [512, 1K) 13062 |@@@ | [1K, 2K) 144 | | [2K, 4K) 14 | | [4K, 8K) 3 | | [8K, 16K) 0 | | [16K, 32K) 0 | | [32K, 64K) 0 | | [64K, 128K) 0 | | [128K, 256K) 0 | | [256K, 512K) 0 | | [512K, 1M) 0 | | [1M, 2M) 0 | | [2M, 4M) 0 | | [4M, 8M) 0 | | [8M, 16M) 0 | | [16M, 32M) 0 | | [32M, 64M) 0 | | [64M, 128M) 0 | | [128M, 256M) 0 | | [256M, 512M) 0 | | [512M, 1G) 28 | | == launching the program in gnome-terminal @usecs: [2, 4) 32387 |@@@ | [4, 8) 457668 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@| [8, 16) 44408 |@@@@@ | [16, 32) 466 | | [32, 64) 63 | | [64, 128) 9 | | [128, 256) 3 | | [256, 512) 53 | | [512, 1K) 0 | | [1K, 2K) 0 | | [2K, 4K) 0 | | [4K, 8K) 1 | | [8K, 16K) 0 | | [16K, 32K) 0 | | [32K, 64K) 39 | | [64K, 128K) 125 | | [128K, 256K) 0 | | [256K, 512K) 0 | | [512K, 1M) 0 | | [1M, 2M) 0 | | [2M, 4M) 0 | | [4M, 8M) 0 | | [8M, 16M) 0 | | [16M, 32M) 0 | | [32M, 64M) 0 | | [64M, 128M) 0 | | [128M, 256M) 0 | | [256M, 512M) 0 | | [512M, 1G) 0 | | [1G, 2G) 1 | | So we can see that gnome-terminal tends to be faster on most stderr-writes, but at the expens of introducing a few long-delays in the 32..128ms bucket. == launching the program in screen (detached) @usecs: [2, 4) 107649 |@@@@@@@@ | [4, 8) 699672 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@| [8, 16) 15262 |@ | [16, 32) 622 | | [32, 64) 5840 | | [64, 128) 42728 |@@@ | [128, 256) 14000 |@ | [256, 512) 68 | | [512, 1K) 3 | | [1K, 2K) 0 | | [2K, 4K) 1 | | [4K, 8K) 0 | | [8K, 16K) 0 | | [16K, 32K) 0 | | [32K, 64K) 0 | | [64K, 128K) 0 | | [128K, 256K) 0 | | [256K, 512K) 0 | | [512K, 1M) 0 | | [1M, 2M) 0 | | [2M, 4M) 0 | | [4M, 8M) 0 | | [8M, 16M) 0 | | [16M, 32M) 0 | | [32M, 64M) 0 | | [64M, 128M) 0 | | [128M, 256M) 0 | | [256M, 512M) 0 | | [512M, 1G) 0 | | [1G, 2G) 50 | | * launching the program in screen (attached; printing via uxterm) @usecs: [2, 4) 2 | | [4, 8) 67887 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@| [8, 16) 30378 |@@@@@@@@@@@@@@@@@@@@@@@ | [16, 32) 58881 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ | [32, 64) 5188 |@@@ | [64, 128) 301 | | [128, 256) 61 | | [256, 512) 3963 |@@@ | [512, 1K) 7603 |@@@@@ | [1K, 2K) 407 | | [2K, 4K) 42 | | [4K, 8K) 20 | | [8K, 16K) 0 | | [16K, 32K) 0 | | [32K, 64K) 0 | | [64K, 128K) 0 | | [128K, 256K) 0 | | [256K, 512K) 0 | | [512K, 1M) 0 | | [1M, 2M) 0 | | [2M, 4M) 0 | | [4M, 8M) 0 | | [8M, 16M) 0 | | [16M, 32M) 0 | | [32M, 64M) 0 | | [64M, 128M) 0 | | [128M, 256M) 0 | | [256M, 512M) 0 | | [512M, 1G) 0 | | [1G, 2G) 1 | | so intrestingly, attaching the screen will significantly slow down stderr. It seems screen doesn't do sufficient buffering internally, or it blocks the osmocom program until not only it has updated its internal buffer, but also written to the output of the attached uxterm? == launching the program with 2>/dev/null @usecs: [1] 2202080 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@| [2, 4) 26966 | | [4, 8) 1107 | | [8, 16) 305 | | [16, 32) 10 | | [32, 64) 6 | | [64, 128) 0 | | [128, 256) 0 | | [256, 512) 1 | | [512, 1K) 0 | | [1K, 2K) 0 | | [2K, 4K) 0 | | [4K, 8K) 0 | | [8K, 16K) 0 | | [16K, 32K) 0 | | [32K, 64K) 0 | | [64K, 128K) 0 | | [128K, 256K) 0 | | [256K, 512K) 0 | | [512K, 1M) 0 | | [1M, 2M) 0 | | [2M, 4M) 0 | | [4M, 8M) 0 | | [8M, 16M) 0 | | [16M, 32M) 0 | | [32M, 64M) 0 | | [64M, 128M) 0 | | [128M, 256M) 0 | | [256M, 512M) 0 | | [512M, 1G) 0 | | [1G, 2G) 153 | | unsurprisingly, this turns out to be rather fast == launching the program with 2>/file/on/btrfs/on/ssd @usecs: [2, 4) 2275464 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@| [4, 8) 265612 |@@@@@@ | [8, 16) 9384 | | [16, 32) 368 | | [32, 64) 4 | | [64, 128) 24 | | [128, 256) 3 | | [256, 512) 1 | | [512, 1K) 0 | | [1K, 2K) 0 | | [2K, 4K) 0 | | [4K, 8K) 0 | | [8K, 16K) 0 | | [16K, 32K) 0 | | [32K, 64K) 0 | | [64K, 128K) 0 | | [128K, 256K) 0 | | [256K, 512K) 0 | | [512K, 1M) 0 | | [1M, 2M) 0 | | [2M, 4M) 0 | | [4M, 8M) 0 | | [8M, 16M) 0 | | [16M, 32M) 0 | | [32M, 64M) 0 | | [64M, 128M) 0 | | [128M, 256M) 0 | | [256M, 512M) 0 | | [512M, 1G) 0 | | [1G, 2G) 95 | | I've tried creating some load using a cocnrrent dd of the underlying block device, but couldn't make out any difference. I guess this shows how good the I/O subsystem is. Yes, some writes are slower than writing to /dev/null, but == launching the program from systemd (with journald) [2, 4) 1060607 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@| [4, 8) 75133 |@@@ | [8, 16) 724 | | [16, 32) 107 | | [32, 64) 8 | | [64, 128) 8 | | [128, 256) 0 | | [256, 512) 0 | | [512, 1K) 0 | | [1K, 2K) 0 | | [2K, 4K) 0 | | [4K, 8K) 0 | | [8K, 16K) 0 | | [16K, 32K) 0 | | [32K, 64K) 0 | | [64K, 128K) 38 | | [128K, 256K) 0 | | [256K, 512K) 0 | | [512K, 1M) 0 | | [1M, 2M) 0 | | [2M, 4M) 0 | | [4M, 8M) 0 | | [8M, 16M) 0 | | [16M, 32M) 0 | | [32M, 64M) 0 | | [64M, 128M) 0 | | [128M, 256M) 0 | | [256M, 512M) 0 | | [512M, 1G) 0 | | [1G, 2G) 1 | | This is also pretty fast. There are some writes in the 64..128ms range, though. Those are likely going to cause problems in timing critical programs like osmo-bts, osmo-trx or osmo-mgw. * replacing stderr logging with gsmtap log target (without wqueue) @usecs: [4, 8) 776978 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@| [8, 16) 1771 | | [16, 32) 60 | | [32, 64) 0 | | [64, 128) 1 | | [128, 256) 0 | | [256, 512) 0 | | [512, 1K) 0 | | [1K, 2K) 0 | | [2K, 4K) 0 | | [4K, 8K) 0 | | [8K, 16K) 0 | | [16K, 32K) 0 | | [32K, 64K) 0 | | [64K, 128K) 0 | | [128K, 256K) 0 | | [256K, 512K) 0 | | [512K, 1M) 0 | | [1M, 2M) 0 | | [2M, 4M) 0 | | [4M, 8M) 0 | | [8M, 16M) 0 | | [16M, 32M) 0 | | [32M, 64M) 0 | | [64M, 128M) 0 | | [128M, 256M) 0 | | [256M, 512M) 0 | | [512M, 1G) 0 | | [1G, 2G) 0 | | [2G, 4G) 82 | | Ignoring the strange (and certainly bogus) artefacts in the 2..4s bin at the bottom, writes to the GSMTAP UDP socket tend to be quite fast, much faster than anything via stderr. Even faster than stderr-to-dev-null. == conclusion all-in-all, it looks not too bad at least on a relatively unloaded couple-of-years-old laptop. I would have expected worse. We can definitely see that there are non-neglectable delays created by both systemd/journald as well as gnome-terminal. One idea would be to play with setvbuf(3) to increase stderr buffering inside libc. The other idea would be to do our own buffering using osmo_wqueue() on the raw, unbuffered stderr-fd, which would then be in non-blocking mode and handled vis osmocom select. We'd have to add some kind of limit for that buffer in order to avoid OOM situations. -- - 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)

4 10

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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC September 2020