Remove the 'runs on' clause, add a VTY port argument.
That allows using this function also on the test_CT.
Will be used by upcoming System Information tests.
Change-Id: Ib059d9690f92f5f76025bca2b84496716a2a4cf0
For SI tests, it is necessary to first startup the VTY, then issue some config
commands, and only then start up the BTSes. By this separation that can be done
by:
f_init(nr_bts := 0);
f_vty_transceive(...);
f_init_bts(bts_idx := 0);
Will be used by upcoming System Information tests.
Change-Id: I24afb07735c3827f52760214fcb7a239190c3402
So far the naming is so that the EUTRAN_NeighborCell sounds like it reflects a
single E-ARFCN, while in fact it contains a list of E-ARFCNs. In 3GPP TS 48.018
it is more accurately named "Neighbor Cells", in plural.
There is another "list layer" that allows repeating these lists of E-ARFCNs,
which the spec names Repeated Neighbor Cells, i.e. have a list of (=repeat) the
lists of E-ARFCNs.
Repeated Neighbor Cells = {
// first cells list
Neighbor Cells = {
cell descriptions = {
{ e_arfcn = 1, meas_bw = 3 },
{ e_arfcn = 2, meas_bw = 3 },
{ e_arfcn = 3, meas_bw = 3 },
},
prio, thresh, ...
},
// second cells list
Neighbor Cells = {
cell descriptions = {
{ e_arfcn = 4, meas_bw = 3 },
{ e_arfcn = 5, meas_bw = 3 },
{ e_arfcn = 6, meas_bw = 3 },
},
prio, thresh, ...
},
...
}
Adjust the naming of the SI2quaterRestOctets members to more closely resemble
this structure, adopting the naming in 3GPP TS 48.018:
EUTRAN_NeighborCell -> EUTRAN_NeighborCells
because it is really a collection of multiple E-ARFCNs
EUTRAN_NeighborCells -> EUTRAN_RepeatedNeighborCells
because it is a list of E-ARFCN lists, and 3GPP TS 48.018 names it
"Repeated Neighbor Cells".
Also rename the EUTRAN_NotAllowedCells accordingly.
Change-Id: Ib11d72c04cdb8997ec97321257fb58b2c113e790
osmo-msc failed to record the Complete Layer 3 Information LAC and CI in the
MSC-A as well as the VLR record. Since osmo-msc
Iee1781985fb25b21ce27526c6a3768bf70d4dc9a and
I194271af2acb37b4f8cc2d106ab2fd2b0d443589, osmo-msc properly records these for
successful Complete Layer 3 procedures.
Incorporate verification of the LAC and CI in all tests calling f_perform_lu()
and f_expect_clear(). Implement by scraping the output of vty
'show subscriber imsi 1234 conn'
Some tests model a failure to attach, or expire the VLR record: for those, add
parameter verify_cell_id to g_pars, and pass it as false, to skip checking the
LAC and CI.
Disable CI checking for all Iu tests globally in f_verify_vty_lac_ci(), see
OS#4634.
For the latest build, which does not yet record LAC and CI properly, provide
mp_enable_cell_id_test, which skips all cell id verification if set to false.
Put to effect by docker-playground I052fea208021509e12826c50474b96474e7a58c2.
Related: OS#4627
Depends: Iee1781985fb25b21ce27526c6a3768bf70d4dc9a (osmo-msc)
Change-Id: Ie410714a96353f74a52a104c56fa0a08683e0004
This is a very minimalistic (incomplete) implementation of SI2quater
Rest Octets as per 3GPP TS 44.018, table 10.5.2.33b.1. Should be
enough to decode some of the E-UTRAN specific parameters though.
Some BITn fields might need to be replaced with more specific
enumerated or integer types. Beware [1], the bit ordering rules
are different for integer and bitstring (sub-)types if a field
ends up on boundary of the two octets!
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=562488
Change-Id: I6a12c9ee12f8df8b4fc0976dd593152dc1195718
Related: SYS#4870
At the time of writing Ief0d9b096feeee7d37b5f2429dd3e80de0161806 I wasn't aware
of the 'inout' keyword, which allows to pass the counter list by reference.
Rather modify the counter lists in-place. Instead of requiring
list := f_counter_name_vals_add(list, ...)
rather implement by directly modifying list:
f_counter_name_vals_add(list, ...)
Change-Id: I85ac56b042fe4bb1db392c1f451c8e900582cc2a
Use new f_counter_* functions to verify osmo-bsc MSC pooling counters.
This nicely also verifies the intended effect of each test in detail.
Depends: I2ded757958dfa62b502efbab765203bcadf899e2 (osmo-bsc)
Change-Id: I2006f1def5352b4b73d0159bfcaa2da9c64bfe3f
First user will be new MSC pooling tests in ttcn3-bsc-test, see
I2006f1def5352b4b73d0159bfcaa2da9c64bfe3f.
Change-Id: Ief0d9b096feeee7d37b5f2429dd3e80de0161806
Not all osmo-bts backends do support multiple transceivers, while
we still want to run test cases against them. Let's make the
number of transceivers configurable (mp_transceiver_num), so it
can be adjusted depending on osmo-bts backend to be used.
Change-Id: Ic9dd49a2fc856de593b52b3ec0c559e0e15ca173
Related: OS#3155
Since change [1] has been merged, we see multiple regressions in
ttcn3-bsc-test (all LCLS test cases) and ttcn3-bsc-test-sccplite
(sporadic failures). In all failed cases, the reason is similar:
RSL for unknown Dchan
BSC_Tests.ttcn:4501 BSC_Tests control part
BSC_Tests.ttcn:2176 TC_assignment_codec_fr testcase
The mentioned change enables TCP_NODELAY option for all IPA based
connections, including both OML and RSL. This option disables
Nagle's algorithm [2], so we get less delays on IPA based links.
It took me a lot of time to investigate, and finally, I figured
out what is actually causing those regressions. The TCP_NODELAY
itself is not a problem, of course. As it turned out, the
problem is here, in our TTCN-3 test case framework.
Each test case involves several components (actors) running in parallel.
One of them is RSL_Emulation_CT, which is responsible for handling and
routing of RSL messages between the connected components.
A test case may register dedicated channel handlers by calling
f_rslem_register(), so DCHAN/RLL/IPACCESS messages will be matched
by RslChannelNr/TrxNr and routed to the corresponding one.
If no handler is found for a given RSL message, the RSL_Emulation_CT
would abort the test case execution. And that's where the problem is.
Given that all components are running in parallel, it may happen
that a received RSL message would be processed by the RSL emulation
component faster than the test case would call f_rslem_register().
The test case would be aborted due to "RSL for unknown Dchan".
Speaking in context of the failing BSC test cases, a test case
calls f_rslem_register() on receipt of an Assignment Command as
it contains all the assignment parameters. After that we expect
to receive an RSL ip.access CRCX for that channel.
The problem is that both Assignment Command and ip.access CRCX
messages are sent by the BSC simultaneously, so the later may
be handled faster than the first one. Race condition!
Let's work this around by maintaining a waiting queue, where the
messages, for which no handler was found, will be kept until the
corresponding dedicated channel is registered.
This is an optional feature that needs to be enabled explicitly
by calling f_rslem_dchan_queue_enable(), and then explicitly
disabled by calling f_rslem_dchan_queue_disable().
If at the moment of calling f_rslem_dchan_queue_disable() the
waiting queue is not empty, e.g. because the IUT sent us more
messages than we expected, test execution will be terminated.
The actial fix for the LCLS test cases will be submitted next.
[1] Ia3d4c41bf0659e682f0b7ae5f3d58ed0f28edb58
[2] https://en.wikipedia.org/wiki/Nagle%27s_algorithm
Change-Id: I25e10e28de174337233e6a3bb32cc16f2d7d614e
Related: OS#4619
It appears some changes were made only to the files in
docker-playground.git, but not here. This means that running
tests locally produced unexpected results.
We must always ensure that the tests run both without and with
docker, which means making sure the configs are all maintained!
Change-Id: I3a3f4c572b8a390882fb8f12807018ca19e4827c
This was removed when libfilter was removed from osmo-bsc.
For some strange reason apparently the config files were not used/tested
while testing the removal of libfilter.
Also, irrespective of breaking TTCN3 test execution, we must introduce
a dummy 'access-list' VTY command to osmo-bsc to ensure we don't break
virtually every config file out there.
Change-Id: I5d703b9f2f1066654daa43519999585cf9ec7e78
The TC_ho_neighbor_config_* tests sometimes take longer than 30 seconds,
because they run multiple handovers. Since they don't have access to the
Test_CT, they cannot restart the T_guard. The simplest solution is to choose a
longer T_guard timeout for those tests specifically, by adding an argument to
f_init(). (A longer timeout for those tests is following in another patch.)
Why f_init()? Assigning a different default value to T_guard seems to not be
possible, but a different timeout value can be passed to T_guard.start(), which
happens in f_init().
Change-Id: I14918f6a44d6fa1bd5c3e133757ebdbe32813b33
Handover testing required passing MSC and BSC addresses to f_tc_* functions and
added pars.handover.sccp_addr_msc and .handover.sccp_addr_bsc.
MSC pool tests added a separate sub-record pars.mscpool which also contains
these two fields.
Move them both up one level, to form a single pair of pars.sccp_addr_msc and
pars.sccp_addr_bsc.
This eliminates the pars.handover sub-record.
Change-Id: Iae81ca58001455099218ce769a97dc6402832490
The MSC pooling feature is implemented in osmo-bsc
Ifbdea197b26e88751a391c8a80c41f04e7d5e047.
A VTY command ('mscpool roundrobin next') that allows deterministic testing is
added in I2155d906505a26744966f442ffb1e87a6a9b494c.
osmo-bsc.cfg changes needed for these tests to succeed are in docker-playground
I1986e4ef43beee161c82193694421b56136c1afe
The new tests will fail until the above have been merged.
Change-Id: I21cbab193cd0de2e5692665442eae113d5f61904
Let's test whether paging is triggered after T3314 expiration, as well
as suspend and explicit and implicit resume work as expected
Change-Id: I83b7a453958e30dfc727ba3140168217c209833f
Related: OS#4616
In some scenarios we do not expect a PDU from GTP to show up on
the Gb side. Let's add support for this.
Change-Id: Ia9fde1d433657c920ee1ec4d41004f4544ceb346
Related: OS#4616
So far, the ConnHdlr components were only able to exchange BSSGP PDUs
on the PTP BVC, but not on the SIGNALING BVC. For this, we need to
actually connect to the BSSGP_SP_SIG that BSSGP_Emulation provides.
Change-Id: I4482a24e4808ac2fe04401224f628606d8207416
Related: OS#4616
Add BSSAP_N_UNITDATA_req to RAN_Conn_PT, so that we are able to send a Paging
from a test function that runs on MSC_ConnHdlr.
This will be needed by upcoming MSC pool tests, see
I21cbab193cd0de2e5692665442eae113d5f61904.
Change-Id: I36d486db05169b0fc3f19112b5a9008248d62930
For tr_RSL_PAGING_CMD, also check comp_ref against null.
Upon receiving a tr_RSL_PAGING_CMD, the code tries to dispatch the Paging
Command to all valid clients. However, the ConnectionTable[*].comp_ref is
*always* present, and actually null for unconnected clients.
So, before this patch, a Paging Command from osmo-bsc gets sent to a null
client, which disconnects the RSL emulation and aborts the test.
There is currently no test using this, but the upcoming MSC pool tests will:
see I21cbab193cd0de2e5692665442eae113d5f61904.
Change-Id: Iaf7730153a3a19e448a33298c3e12212a55929d5
Unlike the RSL_IE_MS_Power, where power_level is 5 bit long, in
the RSL_IE_BS_Power it's 4 bit long. Fix this.
Change-Id: Ic0cb2275ef585754b9ae5e3d8077ca652afd9365
Similar to the MSC tests, have several g_bssap and mp_bssap_cfg.
Prepare for MSC pool tests.
Replace g_bssap with a g_bssap[NUM_MSC] array.
Replace mp_bssap_cfg with an mp_bssap_cfg[NUM_MSC] array.
Requires patch I1986e4ef43beee161c82193694421b56136c1afe in docker-playground
to match the new required BSC_Tests.cfg format.
Related: OS#3682
Change-Id: Ibb36695b7c31f7b04eec6c5d59522fc0779b3c2f
Neels Hofmeyr
Vadim Yanitskiy
Pau Espin
Harald Welte