- OpenBSC - lists.osmocom.org

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

On the use of 'decmatch' in TTCN-3
by Harald Welte 31 Aug '26

31 Aug '26

Hi, I know that TTCN-3 is still new to a lot of you, but we are writing tons of integration testing against the various osmocom programs in it. It is quite amazing technology, and I would like to ask you to bear with me reading this mail :) Pau was stating the question earlier today on not finding an example on how to use decmatch. Indeed, it took me some months to find that gem in the TTCN-3 world. It solves the problem that you often have during test of layered protocol stacks: you have separate encoders/decoders for each protocol layer, and now you want to match on some of the *inner* payload. So normally, you have some kind of header definition + a binary (octetstring) payload. This happens in RSL with the L3_INFO IE, and just the same on BSSAP/DTAP where again the L3 message (for example call control) is encapsulated inside one information element. Now you have multiple options of addressing the problem: a) hand-written calls to the decoder function b) write na 'emulation' for the entire protocol layer c) use decmatch. a) would look like this (pseudo-code): var octetstring l3oct; var RSL_Message rsl RSL.receive(tr_RSL_DATA_REQ(g_chan_nr, ?, ?)) -> value rsl { var PDU_ML3_MS_NW l3 := dec_PDU_ML3_MS_NW(rsl.payload); if (match(l3, some_template)) { ... do something } ... } Which uses the built-in pattern-matching on the RSL port to match any message that matches the tr_RSL_DATA_REQ template, and stores the resulting RSL message in a variable. It then uses an explicit call to the decoder function of the L3 message, and then uses regular conditional expressions for further matching on that inner L3 payload. This is more or less how you would write in C, python or any other quite imperative programming languages. It's very verbose, time consuming and un-abstract/elegant. TTCN-3 has many declarative aspects to it. Code like the above is a waste of your time :) b) would mean that you implement some test component that handles the RSL messages on its bottom side test port, and the L3 messages on its top side test port. That is a possible way, and if you need a lot of state/logic of RSL, it maeks sense. But what if you really simply want to have a match? Then it would be a lot of effort and a large detour. c) decmatch to the rescue! You can write RSL.receive(tr_RSL_DATA_REQ(g_chan_nr, ?, decmatch tr_RRM_RR_STATUS)) which means: * do a receive on the RSL test port, and match on an incoming RSL message that matches the tr_RSL_DATA_REQ template, with channel number specified, link_id any (?), *and* if the octetstring payload, if decoded, matches the template tr_RRM_RR_STATUS ! This is *extremely* powerful and expressive. It allows you to condense complex, parametric template matching over multiple proocol layers. It would in the end match RSL DATA REQUEST, only if they contained a [valid] encoded RR STATUS. See https://gerrit.osmocom.org/6229 for the actual test case I used for the above examples. Please also note that I never had to even write the function name of the decoder (dec_PDU_ML3_MS_NW), but TTCN-3 *automatically* figures out which decoder function it must call in order to decode from the binary octetstring. Happy (TTCN-3) hacking + Osmocom bugfixing, 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 4

Splitting out M3UA and MTP3 out of Open BSC
by max1987martin＠outlook.com 18 Aug '26

18 Aug '26

The HLR we were targeting only supported a SCTP/M3UA/SCCP/TCAP/MAP stack, so we couldn't use SUA. Ripping the M3UA/MTP3 code out of OpenBSC worked surprisingly well. We ended up running the event loop in a separate thread to work around the threading issues. Unfortunately the HLR implements the ANSI variant of everything, whereas OpenBSC and supporting libraries seem to have been written to be compatible with the ITU standards.

1 0

OsmoBSC - lchan allocation failed in state WAIT_RLL_RTP_ESTABLISH
by cristi.live＠yahoo.com 17 Jun '26

17 Jun '26

Hello guys, I found an interesting issue. After I place a call to a number which is not existent in HLR DB I am not able to make a call to an existing one anymore. Seems the timeslot is not released properly. If I am doing a BSC config adjustment like channel allocator mode assignment to descending (assuming it was ascending before) I am able to make a call again (until i call a wrong number and the lchan gets stucked). Im using an ipaccess nanoBTS (fw version 168d502_v206b17d0) as hardware and latest versions of Osmocom packages (BSC, MSC, HLR, MGW and STP) with minimal changes of example configuration (from /etc/osmocom). Do you have any idea if could be an issue related to nanoBTS firmware? Regards, Cristian

1 0

OsmoBSC - lchan allocation failed in state WAIT_RLL_RTP_ESTABLISH
by Ionut Cristian CIOC 14 Jun '26

14 Jun '26

Hello guys, I found an interesting issue. After I place a call to a number which is not existent in HLR DB I am not able to make a call to an existing one anymore. Seems the timeslot is not released properly. If I am doing a BSC config adjustment like channel allocator mode assignment to descending (assuming it was ascending before) I am able to make a call again (until i call a wrong number and the lchan gets stucked). The error looks like: <000f> lchan_select.c:454 lchan(0-0-1-TCH_F-0)[0x55babd2a89c0]{UNUSED}: (type=TCH_F) Selected <0011> assignment_fsm.c:709 assignment(msc0-conn79_subscr-IMSI- xxxxxxxxxxxxxxxx-TMSI-0x63d29a26_0-0-1-TCH_F- 0)[0x55babd2a69a0]{WAIT_LCHAN_ACTIVE}: (bts=0,trx=0,ts=1,ss=0) Starting Assignment: chan_mode=SPEECH_V1, chan_type=FR, aoip=yes MSC- rtp=127.0.0.1:4382 (osmux=no) <000f> lchan_fsm.c:838 lchan(0-0-1-TCH_F- 0)[0x55babd2a89c0]{WAIT_TS_READY}: (type=TCH_F) Activation requested: ACTIVATE_FOR_ASSIGNMENT rtp=yes MGW-ci=new type=TCH_F tch- mode=SPEECH_V1 encr-alg=A5/0 ck=none <000f> lchan_fsm.c:1027 lchan(0-0-1-TCH_F- 0)[0x55babd2a89c0]{WAIT_ACTIV_ACK}: (type=TCH_F) Rx Activ ACK SPEECH_V1 <000f> lchan_rtp_fsm.c:369 lchan(0-0-1-TCH_F- 0)[0x55babd2a89c0]{WAIT_RLL_RTP_ESTABLISH}: (type=TCH_F) lchan-rtp failure in state WAIT_IPACC_CRCX_ACK: Received NACK on IPACC CRCX <000f> lchan_fsm.c:1147 lchan(0-0-1-TCH_F- 0)[0x55babd2a89c0]{WAIT_RLL_RTP_ESTABLISH}: (type=TCH_F) lchan allocation failed in state WAIT_RLL_RTP_ESTABLISH: Failed to setup RTP stream: LCHAN_EV_RTP_ERROR in state WAIT_RLL_RTP_ESTABLISH <000f> lchan_fsm.c:160 lchan(0-0-1-TCH_F- 0)[0x55babd2a89c0]{WAIT_RLL_RTP_ESTABLISH}: (type=TCH_F) Signalling Assignment FSM of error (lchan allocation failed in state WAIT_RLL_RTP_ESTABLISH: Failed to setup RTP stream: LCHAN_EV_RTP_ERROR in state WAIT_RLL_RTP_ESTABLISH) <0011> assignment_fsm.c:1043 assignment(msc0-conn79_subscr-IMSI- xxxxxxxxxxxxxxxx-TMSI-0x63d29a26_0-0-1-TCH_F- 0)[0x55babd2a69a0]{WAIT_RR_ASS_COMPLETE}: (bts=0,trx=0,ts=1,ss=0) Assignment failed in state WAIT_RR_ASS_COMPLETE, cause RADIO INTERFACE MESSAGE FAILURE: Failed to activate lchan (bts=0,trx=0,ts=1,ss=0) <0007> osmo_bsc_sigtran.c:624 (msc=0) Tx MSC: BSSMAP: ASSIGNMENT FAIL Im using an ipaccess nanoBTS (fw version 168d502_v206b17d0) as hardware and latest versions of Osmocom packages (BSC, MSC, HLR, MGW and STP) with minimal changes of example configuration (from /etc/osmocom). Do you have any idea if could be an issue related to nanoBTS firmware? Regards, Cristian

1 0

E1 to IP with iCE40 E1 USB interface
by Alina Androne 28 May '26

28 May '26

Hello, How can I utilize the iCE40 E1 USB adapter to transition from E1 to IP in a GSM network, connecting a physical Siemens BSC (which has a BTS connected) to OsmoMSC? Only the BTS and BSC are physical. I already have osmo-e1d installed. Should I use osmo-e1d or dahdi version for this transition? What would be the best approach to begin the process? Regards, Alina

6 12

GSM Silent call
by samir 04 May '26

04 May '26

Hi, I have read that silent-calls in GSM can be used to make a call to a target MS and listen to it without having the target knowing it. Is this theoretically possible ? If yes, can it be done in OpenBSC ?

4 3

Cinema apk
by jw8920621＠gmail.com 03 May '26

03 May '26

Cinema APK (Cinema HD APK) is a popular streaming app offering free access to movies and TV shows in HD quality, with subtitles, offline downloads, and an easy-to-use interface for Android users worldwide. Cinema apk | streameast

1 0

Reliable Economics Assignment Help Online Service for Students
by Lori Porter 02 May '26

02 May '26

Finding a Reliable Economics Assignment Help Online Service for Students at https://economicsassignmentshelp.com ensures that every academic task is built from scratch. This platform avoids recycled templates, focusing on a fresh architectural design to guarantee 100% originality. Experts develop unique logic for each economic theory, providing a distinct narrative that stays authentic. By prioritizing high-quality, custom research, the service delivers sharp and professional results that are never repeated, helping students achieve their goals with complete confidence.

1 0