This fixes failure of test TC_rim_ran_info_req_single_rep
It probably broke during some infra refactoring of the PCUIF_Components.
Change-Id: Idf9a38280abd6243cc9ef09fc7d033e515c5be15
In recent osmo-pcu commits, initial fn was changed to invalid value -1,
in order to be able to detect FN jumps. previously, the initial value
was set randomly to 0, which was wrong anyway because first FN received
from the BTS could be any other FN counted by the BTS at that time.
This makes some tests fail because they send RACH.ind + RTS.ind to
receive the Imm Assignment, and the Request reference in the Imm Assign
was calculated on the invalid unset FN "-1", hence it won't match test
expectancies.
In order to fix it, simply make sure the TDMA clock is initiated by
sending a DATA.ind to the PCU before tests start doing stuff
(f_init_raw() is blocked waiting for BTS_EV_SI13_NEGO).
Related: osmo-pcu.git Change-Id I29fb27981597edc69abb976049ba41aa840488cb
Related: OS#5020
Change-Id: I00c4dd9133ec9a236bf28fb8cb0afd0615791012
PCUIF will be updated to always send DATA.ind for each expected block FN
on any activated PDCH slot, irrespective of whether valid data was
received or not, similarly to what's done already for TRXDv1 NOPE.ind in
TRXD and TCH channels in OsmoBTS. The aim at this change is to be able to
track TDMA clock in an accurate way without hops, and hence be able to
detect on time whether expected UL blocks (SF, RRBP poll) didn't arrive.
Older osmo-pcu versions can cope well with this change, they will simply
print an error upon ach data_len=0 messages received and submit a GSMTAP
block, then discard it, so tests still pass.
Nevertheless, a new module parameter is added to disable this new
behavior in order to avoid logs and pcap files ending up clogged with
uneeded information until a new osmo-pcu release appears.
Related: OS#5020
Change-Id: Ib4f97a9bcfa68230945effeb6412218faa64ec78
This way tests can match directly on specific RLCMAC blocks, giving the
opportunity to handle different types using altsteps.
Before this, a user of the port could only receive a pcu_msg DATA_REQ
with a octetstring containing the rlcmac block, then decode it in a
second step when already in the alt step.
Related: OS#4927
Change-Id: Id8628e327d16c3a57e680e5a1ba0a2a8874f3a23
Most of existing test cases are built on top of the PCU interface
abstraction components (see PCUIF_Components.ttcn). This means
that during the test case execution, additional components are
running in parallel, among with the MTC (Main Test Component).
When a test case terminates, either normally or due to an error,
it may happen that the virtual BTS component is stopped before
the associated TDMA clock generator. In this situation, sending
a clock indication towards the stopped BTS component would
lead to a dynamic test case error.
Let's take the process of tear down under control, and ensure that
the clock generator is stopped first. To achieve that, every test
case needs to call f_shutdown() in case of an error, as well as
in case of the normal termination.
Note we cannot use the existing f_shutdown() from Misc_Helpers,
because doing 'all component.stop' does not gurantee that the
clock generator is stopped first, and I experienced at least
one DTE while trying to integrate it.
Change-Id: I6a859687d9605cc08c51ff44d946c279b79bedfa
Signed-off-by: Vadim Yanitskiy <axilirator@gmail.com>
Pau Espin
Vadim Yanitskiy
Vadim Yanitskiy