OpenBSC September 2026

openbsc@lists.osmocom.org

3 participants
2 discussions

Nokia AirScale GSM Packet Abis/IUA support in OsmoBSC ? working lab hardware available
by Ciccio Franco 21 Sep '26

21 Sep '26

Hello, we are trying to bring up a Nokia AirScale GSM BTS in an isolated laboratory using OsmoBSC 1.15.0. Hardware: Nokia AirScale ASIB + ABIA + FXDA GSM900 radio (472083A). BTS software: SBTS25R2, GSM RAT 25R2. The BTS is configured for Nokia Packet Abis over IP. BTS GSM IP: 172.19.107.97 BSC IP: 172.17.208.121 SCTP/IUA port: 49152 We developed a small IUA ↔ libosmo-abis bridge and currently achieve: SCTP association OK ASPUP / ASPUP_ACK OK ASPAC / ASPAC_ACK OK IUA AS ACTIVE OK Nokia uses one SCTP stream and PPID 1. The Routing Context / Interface Identifier observed is 0x00028e00 (BCF ID 654). OsmoBSC establishes its local LAPD link using SAPI 62 / TEI 1 and starts Nokia OML bootstrap. However the AirScale never establishes OMUSIG at application level. WebEM reports: Fault 2412: OMU signaling connection failure in Abis interface. We tested both sending the Nokia RESET_REQ after AS ACTIVE and an IUA TEI-first procedure. SCTP acknowledges the packets, but no Nokia OML response is received. The same behavior has been reproduced with two SBTS25R2 software builds, and an unrelated software-fallback alarm has now been eliminated. We understand that current OsmoBSC Nokia support is nokia-e1, including recent Flexi Multiradio support, while Nokia Packet Abis/IP support is not yet implemented. We have a complete Nokia AirScale GSM laboratory setup available and can provide remote access, packet captures, WebEM logs and test patches if somebody is interested in implementing/debugging nokia-ip support. Our immediate objective is to bring at least one GSM TRX/BCCH on air in the isolated RF laboratory. We can provide: PCAP of the SCTP/IUA association complete iua bridge source code OsmoBSC logs AirScale configuration and runtime exports Nokia alarm information interactive access to the physical AirScale BTS Is anyone interested in helping us identify the missing Packet Abis/IUA bootstrap procedure or in working on Nokia IP Abis support in OsmoBSC? Thank you.

1 0

[RFC] libosmocore port to macOS Apple Silicon (ARM64)
by Andrei Gosman 14 Sep '26

14 Sep '26

Hello, I have put together a working port of libosmocore for macOS on Apple Silicon (M1/M2/M3/M4), and I would like guidance on whether the Osmocom project would consider accepting it upstream, and if so, in what form. Current state, published as a standalone fork: https://github.com/AndreiGosman/libosmocore-macos-arm64 The port enables native compilation and runtime of libosmocore and its submodules (libosmovty, libosmocodec, libosmogsm, libosmocoding, libosmoisdn) on Darwin/ARM64. On top of it I have gr-gsm building and running natively, with grgsm_decode functional on IQ captures from a LibreSDR B220 Mini via UHD. The rest of the stack (grgsm_scanner, grgsm_livemon, gr-osmosdr) is not yet addressed. The current patchset is pragmatic rather than idiomatic. Approach: - Six files that include Linux-only headers or use Linux-only APIs (linux/if.h, linux/tcp.h, cpu_set_t + sched_setaffinity, linux/if_tun.h) are wrapped whole in #ifdef __linux__: cpu_sched_vty, netdev, serial, stats_tcp, tun, gprs_ns2_fr. - A new src/core/darwin_stubs.c exports no-op public symbols for the wrapped files (osmo_tcp_stats_config, osmo_stats_tcp_*, osmo_timerfd_*, osmo_tundev_*), so consumers link cleanly on Darwin. - A darwin_compat.h is included via CFLAGS -include and provides dummy values for SO_PRIORITY, CLOCK_REALTIME_COARSE, CLOCK_MONOTONIC_COARSE, CLOCK_BOOTTIME, plus a gettid() alias to getpid(). - src/core/exec.c sed-patched to substitute setresgid/setresuid (Linux) with setregid/setreuid (Darwin) for the specific 3-arg-equal use case. - configure invoked with --disable-uring --disable-libmnl --disable-libsctp. - LDFLAGS "-Wl,-undefined,dynamic_lookup" applied at make only, not at configure (to avoid false-positive detection of gettid/setns/unshare). I am aware this shape is unlikely to be acceptable as-is: whole-file wrapping is coarse, the compat header injection through CFLAGS bypasses your feature-detection model, and stubs that unconditionally return NULL/-1 have degraded semantics for real callers. My question: would upstream accept a refactored version of this? And if yes, in what shape: (1) Inline per-function or per-block #ifdef __linux__ conditionals within the existing files (no wraps, no separate stubs file). (2) Autoconf feature detection (AC_CHECK_HEADERS / AC_CHECK_FUNCS) with HAVE_* macros driving conditional compilation in .c files, and a proper compat header included from public headers rather than via -include. (3) A combination: (2) for portable features, (1) with clear comments for the rest, and darwin_stubs.c kept as a small explicit file referenced from Makefile.am rather than added implicitly. If any of the above is acceptable, I am willing to invest the time to refactor, submit via Gerrit, and iterate on review. If macOS support is out of scope for the project by policy, I will keep the fork as a standalone resource for the Mac community and close this thread. Testing environment for the current patchset: - macOS Tahoe (Darwin 25.5.0), Apple Silicon M4 - Homebrew 6.0.21, GNU Radio 3.10.12, Python 3.14 - libosmocore tag 1.14.2.4-2a26b Full patch details and rationale are in the fork README: https://github.com/AndreiGosman/libosmocore-macos-arm64/blob/master/README.… Thanks for your time, and for the project. Andrei Gosman

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC September 2026