Bug #3353


osmo-bts: TTCN3 BTS_Tests.TC_rll_est_ind fail behavior not clear

Added by pespin over 3 years ago. Updated almost 3 years ago.

Target version:
Start date:
Due date:
% Done:


Spec Reference:


The test TC_rll_est_ind attempts to create a link MS<->BTS and makes sure that an Establish Indication is sent to the BSC once the link is established:

When running the test with osmo-bts-trx (same when checking the pcap file from the virtphy one), I saw that the BTS is sending ERROR INDICATION to the BSC, but those messages don't seem to be expected at all by reading the test code. The test only expected either a normal Establish Indiciation (with or without L3 payload) to be received, or otherwise doesn't care what's received.

It should be clarified whether it is a good behavior to receive an Error indication or not. In case it's not expected, I added this code in TTCN3 but I don't know why, it never triggers (despite seeing Error Indications in pcap file):

diff --git a/bts/BTS_Tests.ttcn b/bts/BTS_Tests.ttcn
index 1044747..5f7ddab 100644
--- a/bts/BTS_Tests.ttcn
+++ b/bts/BTS_Tests.ttcn
@@ -3258,6 +3258,9 @@ private function f_TC_rll_est_ind(charstring id) runs on ConnHdlr {
                        setverdict(fail, "Unexpected EST IND without L3 in ", tc);
+       [] RSL.receive(tr_RSL_ERROR_IND(g_chan_nr, tc.link_id)) {
+               setverdict(fail, "Unexpected ERROR IND in", tc);
+               }
        [tc.exp] T.timeout {
                setverdict(fail, "Timeout waiting for EST IND");

After looking around for a while, though, I think the Error indication messages are expected and they should be checked in the test code.

Looking at BTS log, I can see the Error indications being logged:

20180618190445771 DLLAPD <0011> lapdm.c:712 received message not permitted
20180618190445771 DLLAPD <0011> lapdm.c:419 sending MDL-ERROR-IND 14
20180618190449581 DLLAPD <0011> lapdm.c:712 received message not permitted
20180618190449581 DLLAPD <0011> lapdm.c:419 sending MDL-ERROR-IND 14

Error 14 is "RLL_CAUSE_SABM_INFO_NOTALL", and it's triggered in lapdm_rx_not_permitted() on code paths with following comments:
  • /* no contention resolution on SACCH */
  • /* SAPI3 doesn't support contention resolution */

So, according to those comments or code paths, the ttcn3 test expectations are afaiu, because these two lines expect an Establish indication for SAPI3 (and SACCH on one of them):

        /* normal SAPI3 establishment on main DCCH */
        valueof(t_EITC(3, valueof(ts_RslLinkID_DCCH(3)), ''O, true)),
        /* normal SAPI3 establishment on SACCH */
        valueof(t_EITC(3, valueof(ts_RslLinkID_SACCH(3)), ''O, true))

Related issues

Related to OsmoBTS - Feature #3155: execute BTS_Tests.ttcn with real (C123) phone hardware in LTHW setupStalledpespin04/10/2018


Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)