Bug #6029


Single TTCN3 BSC handover test fails

Added by jolly 10 months ago. Updated 4 months ago.

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


Spec Reference:


If I run a single handover test "BSC_Tests.TC_ho_into_this_bsc_a5_1_3" it fails most of the times.
If I run it multiple times (adding same line multiple times to BSC_Tests.cfg), subsequent tests do not fail.

This seems to happen with all other handover tests too.

My current work-around is to add the test twice to the BSC_Tests.cfg.

Actions #1

Updated by jolly 9 months ago

It tuned out that a single test fails, because running a single test will also start the BSC during that test. The BSC takes a while to start up until it is able to receive the (BSSMAP) Reset message.

Doing "f_sleep(2.0);" before calling "f_init(...);" in this test solves the problem. The Reset message is received and will be acked by the BSC.

Actions #2

Updated by laforge 4 months ago

This is sad and I wish I knew of a smart way to fix this.

Sadly there is no mechanism in TTCN3 to execute a given function once at startup of the testsuite (like a constructor), irrespective of the number of test cases which are then started later on. Every test case is 100% autonomous and all components are created from scratch...

I guess we could try to figure out why osmo-bsc needs time at start-up before it can accept the BSSMAP RESET?

The way how TITAN officially recommends to work in such situations AFAIR is to run some kind of "proxy daemon" that keeps the A interface connection (and all other external connections) alive, and talk from the test cases with that daemon. The daemon then keeps all the lower-layer protocols (like M3UA, ...) up and you really only execute the test case at the highest protocol level (BSSMAP here) without tearing down and bringing up the entire stack[s].


Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)