tree 0af890436bf1823ef12fd9eb1092c5ffd94c4c20
parent 8b4e046b5d7094d7182e8052c3d5b1228a809caa
author Vadim Yanitskiy <vyanitskiy@sysmocom.de> 1661285312 +0700
committer fixeria <vyanitskiy@sysmocom.de> 1661787546 +0000

BSC_Tests: fix race conditions in TC_chan_alloc_algo_ass_dynamic

In cases a), b), c), d), and e) we're sending one or more Measurement
Reports via the A-bis/RSL, and then immediately triggering a traffic
channel assignment by calling f_TC_chan_alloc_algo(), which sends an
Assignment Request via the A interface.

The above-mentioned messages are sent immediately all together, so it
may happen that the BSC handles the Assignment Request earlier than
the Measurement Report(s).  In this case there will be no RxLev
samples, so the BSC would fall-back to ascending allocation order.

Recently we saw this race condition actually happening on Jenkins:

https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test-sccplite/1583/

Let's introduce an artificial delay before sending the Assignment
Request, so that the BSC has enough time to process received MRs.

Change-Id: I2fd6508488e935d208a7aba8e2f215b1cc14ad32