Project

General

Profile

Actions

Bug #3353

closed

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

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

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
06/18/2018
Due date:
% Done:

0%

Spec Reference:

Description

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:
https://git.osmocom.org/osmo-ttcn3-hacks/tree/bts/BTS_Tests.ttcn?id=92d4842022307b60cd215318596b68b40e708e57#n3273

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

Actions
Actions #1

Updated by pespin over 5 years ago

  • Related to Feature #3155: execute BTS_Tests.ttcn with real (C123) phone hardware in LTHW setup added
Actions #2

Updated by laforge over 5 years ago

  • Assignee set to pespin
Actions #3

Updated by laforge over 5 years ago

pespin wrote:

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):

I think the test is correct. We expect a RLL EST IND, and no RLL ERR 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.

The important question is why you come to that conclusion. Without any argument, I beg to differ :)

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):

So what Error 14 seems to be about is that the L3 INFO payload immediately inside the SABM message is not allowed in some cases. This is correct. L3 payload in the SABM is only allowed for contention resolution, and that in turn is only used on SAPI0 of the main DCCH.

The following two lines you quoted from the test are doing a normal establishment, and not a contention resolution establishment.

    /* 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))

The ''O part is passing a zero-length L3 PDU, and hence no L3 INFO is expected.

Actions #4

Updated by pespin almost 5 years ago

  • Status changed from New to Closed

Clarified quite long time ago.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)