OpenBSC June 2026

openbsc@lists.osmocom.org

1 participants
3 discussions

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

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

17 Jun '26

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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC June 2026