The current BSC_Tests are using osmo-bts-omldummy to keep OML out of the test context.
Add a new test file and component for OML tests.
Change-Id: I0934ea26db359b0a6649c613f01de134a3a372ee
A recent commit introduced a regression which made
TC_assignment_emerg_setup_deny_bts fail.
The problematic commit (see hash below) set "pars.ra :=
f_rnd_ra_emerg()" in the helper function, which made the BSC early
reject the CHAN RQD with ImmAssRej in the case the BTS policy forbids
emergency calls.
In that scenario, rejection can be done early because there's no need to
wait to find out which MSC it is aimed at.
This scenario, however, is already being validated by test TC_chan_rqd_emerg_deny.
The scenario TC_assignment_emerg_setup_deny_bts was testing is actually
one where CHAN RQD doesn't contain reason="emergency call", which means
BTS doesn't early reject it, but only knows about it being an emergency
call when a CC Emergency Setup is sent to it, time at which it releases
the call.
Hence, this commit sets back pars.ra = f_rnd_ra_emerg() only on the ..._deny_msc
testcase, since it's the only test really needing it.
Fixes: 14076d3b72
Related: OS#5849
Change-Id: I8d342e5938f6293ae45ee399796417651768af5d
As stated in the comment near the t_def_TestHdlrPars definition,
valueof() shall not be used for getting a value of this template.
The f_gen_test_hdlr_pars() function should be used instead.
All LCLS testcases violated this, and started to fail since
recently after patch [1] has been merged:
"MSC_ConnectionHandler.ttcn:820 : Either imsi or imei must be set!"
BSC_Tests_LCLS.ttcn:743 BSC_Tests_LCLS control part
BSC_Tests_LCLS.ttcn:262 TC_lcls_gcr_only testcase
Use f_gen_test_hdlr_pars() as suggested.
Change-Id: I69ab8699b0be80b12e2df590d9170a743a00d035
Fixes: [1] b27653c6b6
OsmoBSC does some minimal parsing of l3 content to select MSC target,
match paging response to paging request, etc.
Since tests right now use potentially invalid data, osmo-bsc is not
rejecting conns providing invalid l3 content.
This commit makes sure TTCN3 tests pass valid l3 payloads to osmo-bsc,
so that they keep working once osmo-bsc starts rejecting invalid IEs it
parses.
Related: SYS#6280
Change-Id: I6e99ac39f32c9a981420b73f8d7d1568d2fa1c54
OsmoBSC does some minimal parsing of l3 content to select MSC target,
match paging response to paging request, etc.
Since tests right now use potentially invalid data, osmo-bsc is not
rejecting conns providing invalid l3 content.
This commit is another step towards passing proper l3 data to osmo-bsc
in TTCN3 tests.
Related: SYS#6280
Change-Id: I012dbdc673ff98a6647280ce3d0245abff86cfa4
Adjust the test to also check the special case ARFCN=0, which is at the
end of each sub list.
Related: OS#5717
Related: osmo-bsc Ic5e4f0531e08685460948b102367825588d839ba
Change-Id: Ia8f94d72651061427afc9e34f678544f89d0149b
For the purpose of testing MGW pooling, test cases TC_mgwpool_*
configure an additional MGW instance by calling f_vty_mgw_enable()
and then remove it by calling f_vty_mgw_disable().
Unlike the other two TC_mgwpool_* test cases, TC_mgwpool_pin_bts
does not call f_vty_mgw_disable() - this breaks LCLS testcases
executed after it. Add the missing call.
Change-Id: I3157203888d704b25aabd2569035cd95d48c48b2
Fixes: 3f41e321c7
Fixes: OS#5727
Add a couple tests to validate some MGW pool features, like load
balancing and skip selection blocked MGWs from the pool.
Related: SYS#5987
Change-Id: I6a8c30309be406e37190dc67b6ee5af13e1b9e68
OsmoBSC has supported this VTY interface since more than a year ago.
Let's update the config files to use the new "mgw" node.
The recently submitted VTY commands without the redundant "mgw" prefix
are still not used here in order to have the config file work with
latest release which still doesn't support those.
Related: SYS#5987
Change-Id: I9b869e6bf4a3910f38014d570dce27e67af6e0d6
The RSL_IE_MultirateCfg was implemented and added to union RSL_IE_Body
in [1]. Before this change, this IE was decoded as RSL_LV (basically
an octetstring). Now this IE is decoded as RSL_IE_MultirateCfg, while
some AMR tests still expect RSL_LV. Let them use RSL_IE_MultirateCfg.
Change-Id: I40dab41d5dc5d14e358ba5a070ce174e7d8d4a4b
Fixes: [1] I0a5ddce570c0fd70f096d897b0b609d20b552ff7
Currently this testcase fails:
RSL MR CONFIG IE does not match expectation.
Expected: { other := { len := 2, payload := '2804'O } }
Change-Id: Icc5381eccb924803b1117b46d2b4c47cee6dabd7
This way it's easier to see that the only difference from other
tests using c_mr_conf_5_90 is the ICMI field set to false.
Change-Id: If7b491fa55a9366520c2d665a700c5badb187fae
* This is a global constant, so prefix with 'c_' for consistency.
* The RSL_IE_MultirateCfg is all about AMR, remove redundant 'amr'.
Change-Id: I72405b7139fcfd0dbe90afc469ed4db71b43a87c
The per-BTS VTY command 'osmux (on|off|only)' was added to osmo-bsc.git
recently, and is not available in -latest yet. Use it conditionally.
Change-Id: Id501d3f4b5eb18b096d8baffcb5f38e583f7a3d8
Fixes: I6e82eb9d995de988b812001e1c4cf6923509de66
New TC_assignment_osmux_bts is added which tests Osmux used only
BTS<->BSC.
Existing TC_assignment_osmux is renamed to TC_assignment_osmux_cn,
and a new TC_assignment_osmux is added which tests using Osmux on both
sides (towards BTS and CN).
Related: SYS#5987
Change-Id: I6e82eb9d995de988b812001e1c4cf6923509de66
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
We want to add more options later on, and we don't want to be passing
all of them as params. Let's simply set the global fields directly in
the test and let f_init() use the confgured values.
Change-Id: I27b685c2c22cf876b5eba79cf8ad151a2643ecb1
That config is used to control the use of osmux between BSC<->MSC. Since
we'll add support for Osmux in BTS<->BSC, we want to test that in a
separate way. Let's rename it so that we can add a "use_osmux_bts" later
on.
Change-Id: I3bde4e6772c18043dd763d7747b5dbe40e0da3b8
BSC_Tests_CBSP was sending an ETWS message but using non-ETWS templates
to match the response, which may differ from an ETWS one (for instance,
ETWS related messages have no channel_ind).
Change-Id: I42941655081af6d5b04b1e061e6259d8dee94665
This test case verifies the new channel allocation mode, which
is expected to switch between ascending and descending modes
dynamically based on the following two configurable parameters:
* Uplink RxLev threshold (and min number of samples),
* C0 (BCCH carrier) channel load threshold.
The test case scenario includes:
Case a) Unknown Uplink RxLev => fall-back to ascending.
Case b) Not enough RxLev samples => use ascending.
Case c) Uplink RxLev below the threshold => use ascending.
Case d) Uplink RxLev above the threshold => use descending.
Case e) Uplink RxLev above the threshold, but C0 load is not.
Change-Id: Ia522f37c1c001b3a36f5145b8875fbb88311c2e5
Related: SYS#5460
The aim of these new test cases is to verify both ascending and
descending modes of the BSC's channel allocator. Both tests are
using BTS2, which has 4 TRX instances.
The common test scenario can be described as follows:
1. Establish an SDCCH channel, send some dummy payload on it.
2. Send a BSSMAP Assignment Request for a TCH/F channel.
3. Expect RSL CHANnel ACTIVation for a TCH/F channel.
4. Respond with RSL CHANnel ACTIVation NACK (*).
5. Expect a BSSMAP Assignment Failure.
These steps are repeated several times. Note (*) that for the
sake of simplicity, I am aborting the assignment procedure by
sending a NACK, so that the requested logical channel becomes
BORKEN and behaves like an occupied one until the A-bis/OML
link is re-established. This reduces the overall complexity.
Change-Id: Ic74a9cd264320a9a17648f9331b67fb2c2404122
Related: SYS#5460
As described in 3GPP TS 48.049:
7.8.2: "The RESTART message is sent once per broadcast message type as
indicated by the Broadcast Message Type IE."
7.9.2: "The FAILURE message is sent once per broadcast message type as
indicated by the Broadcast Message Type IE."
Related: osmo-bsc.git Change-Id I6668b55868cf534a3b59da5e11542abb8131d604
Related: SYS#5910
Change-Id: I05da2f61d26a1124d30793184d81aabf212cddda
New versions of osmo-bsc send CGI instead of LAC+CI, which provides more
information (PLMN).
Related: SYS#5910
Change-Id: I48e86150f499f0f458f75f132087319d80f86448
Recently I noticed sporadic CBSP test case failures on Jenkins:
Timeout waiting for RSL_OSMO_ETWS_CMD (disable)
BSC_Tests_CBSP.ttcn:1209 BSC_Tests_CBSP control part
BSC_Tests_CBSP.ttcn:1056 TC_cbsp_emerg_write_bts_cgi_cchan_disable
The related timeout is set to 5.0 seconds in f_exp_rsl_etws(), what
matches the Warning Period IE sent in CBSP WRITE-REPLACE message.
Adding a debug log printing T.read on receipt of RSL_OSMO_ETWS_CMD
reveals that we're cutting it too close: the message arrives just
a few milliseconds before the timeout expires.
f_exp_rsl_etws(): T := 4.999196s, remaining 0.000804s
f_exp_rsl_etws(): T := 4.998683s, remaining 0.001317s
f_exp_rsl_etws(): T := 4.999344s, remaining 0.000656s
Let's increase the timeout value (+0.5s) to avoid sporadic failures.
Change-Id: Ia40a268f9780ffbcfa2bb962d7c1ac25d16193de
A follow-up patch is adding BSC_Tests.f_shutdown_helper() calls to all
CBSP testcases, what makes TC_cbsp_emerg_write_bts_cgi_dchan fail due
to talloc count mismatch. All dchans need to be released to avoid this.
Change-Id: I8b707c821693f930ab10bd8feea08ba5007da967
This allows BSC_Tests_CBSP to import friendly API from BSC_Tests.
The line importing stuff from BSC_Tests BSC_Tests_CBSP.ttcn is moved
on top for consistency with an existing friend - BSC_Tests_VAMOS.
Change-Id: Ie0bb5c2e33aadd4858f0f6d001468985c40ab152
The TC_imm_ass_pre_chan_ack_dyn_ts sporadically fails on Jenkins.
Similar to [1], this is happening because the VTY command setting
the 'immediate-assignment' strategy back to 'post-chan-ack' is
being sent/processed earlier than the CHANnel REQ message.
TC_imm_ass_pre_ts_ack_dyn_ts is likely affected too, also fix it.
Change-Id: I1e38142d29d0fa2946a858eac13319aa05b42aa3
Related: [1] I38cd31041741b69eb15098a089b4d4b6b918ffd4
Alexander Couzens
Pau Espin
Vadim Yanitskiy
Oliver Smith
Neels Hofmeyr