Project

General

Profile

Bug #3353

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

Added by pespin 29 days ago. Updated 24 days ago.

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

0%

Estimated time:
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 setupIn Progress2018-04-10

History

#1 Updated by pespin 29 days ago

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

#2 Updated by laforge 24 days ago

  • Assignee set to pespin

#3 Updated by laforge 24 days 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.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)