In TTCN-3 it's not possible to store templates in records, so in
f_assignment_codec() we match received RSL_IE_MR_CONFIG against the
value (not template!) stored in g_pars.expect_mr_conf_ie.
Because of that, the length field is not being calculated by TITAN
for us, so we need to calculate it in ts_RSL_MultirateCfg ourselves.
Automatic length calculation only works during encoding/decoding
and when matching against a receive template.
Change-Id: I595be86d69913ba25e965a5a5c6977e00c342e60
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 RSL MultiRate configuration IE is all about AMR (Adaptive Multi
Rate) codec, so there is no need for 'amr_' prefix in field names.
Change-Id: If63ee50e8681ad4e0a202f142f2fca2268d55079
There is no real need to pass the multi-rate parameters explicitly
in each invocation of ts_RSL_MultirateCfg. The exact multi-rate
configuration does not matter in scope of BTS specific tests.
Change-Id: I24117af8c5b7b11fe4b8f24fca5279ad97b46fab
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
Similar to what's already present in RTPEM_Emulation, this allows tests
to retrieve the Osmux messages received.
Related: OS#5987
Change-Id: Id9aa3a0a02ef5a5e39b4df8a1c165f35255829ab
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
Both testcases were introduced in 2021 [1], however they're not
executed on Jenkins because they're not present in control section.
Fixes: [1] I38e8a1cf15eb41a621b457b39024283a767c94be
Change-Id: Iebf6d14321b54e7ef261443aece03296540ebe92
This change basically reverts [1]. Oliver's patch allowing to set
SO_REUSEADDR, which is needed for D-GSM mslookup mDNS testing, has
been merged upstream. No need to depend on our own fork anymore.
Change-Id: Idf96a64f3d5f7928ed0fb81f4a91e469df3a9adc
Related: [1] Ie7e1c3dbd67dba9079a5768e442faffc936fd7fa
Related: SYS#4618
Will soon be used by new subdir 'upf' (test osmo-upf),
and by 'hnbgw' (test GTP mapping via UPF).
Related: SYS#5599
Change-Id: I0723b931b3f755ea291bffa2f27c34ba446c2f2f
Helped me find a failure cause: instead of T_guard timeout, immediately
show an unexpected MNCC event.
Related: SYS#5066
Change-Id: I49a15142a4b6c51ca767a884c0574f96e01d7cb1
continued from Id0c98bc267daff352fc7db7712f967111970fd4d
Upcoming changes to osmo-msc move the CN side CRCX to an earlier point
in time, reversing that order. Introduce an 'interleave' to not care
about the ordering of MGCP and BSSAP messages.
Related: SYS#5066
Related: Ie433db1ba0c46d4b97538a969233c155cefac21c (osmo-msc)
Change-Id: I0ec348df08aa49ed58b3465de51b259fb74c0aea
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
As was explained in [1], until recently we relied on trxcon sendig
dummy RR Measurement Reports with patched L1 SACCH Header values.
Now trxcon does not patch it for us, so we need to send Uplink
SACCH blocks with the correct L1H ourselves.
Revision 2 of [1] was successfully tested and proved to fix the
above-mentioned testcases. However during code review I was asked
to make the statements sending Uplink SACCH blocks self-explanatory.
In revision 3 of [1] I modified the code to call f_send_meas_rep(),
which was introduced in [2], which as stated in the commit message
is using g_pars.l1_pars.{ms_power_level,ms_actual_ta} instead of
the values from received L1H. Of course this does not work.
Add and use f_send_meas_rep_l1h(), which allows to send the given L1H.
Take a chance to add a log() statement, so that we can see what we Tx.
Change-Id: Ia79a0a7b06394bd34d0f40226cf40e6e8bd2ba35
Fixes: [1] I31dd6b9026d04403092256176f67785a0a6486ad
Related: [2] Ia5d0315e053702df5fa8dad8c6c66c11c9f3edcb
Related: OS#5635
There is a time window between activation of a dedicated channel and
receipt of a L1CTL_DATA_REQ with the first RR Measurement Report, in
which the L1 may need to start transmission on Uplink SACCH.
In this case the L1 is using a dummy SACCH block with hard-coded L1
SACCH header values and hard-coded Measurement Results.
Until recently we relied on implementation specific behavior of trxcon
patching the L1 SACCH header in hard-coded dummy SACCH block. This
behavior was changed, so TC_ms_pwr_ctrl_{constant,pf_ewma} started to
fail. Let's properly populate the SACCH cache to fix these TCs.
Change-Id: I89eb90815e86db466ea626f4c25f2634c1d942d5
Depends: osmocom-bb.git I0f467fc07cf844cc73465f235b36ba7d00788c9f
Related: OS#5635
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
Also run the Iu tests for osmo-msc.
Same as we have in docker-playground.git/ttcn3-msc-test/MSC_Tests.cfg
Related: SYS#5066
Change-Id: Ied0449fd0328ee57b66e3cff9d34b0e1d27b9fb4
So far, the first CRCX dispatched by osmo-msc is used for the RAN side,
and the second one for the CN side. Upcoming changes to osmo-msc move
the CN side CRCX to an earlier point in time, reversing that order.
Allow both RTP addresses from the two MGCP CRCX OK to appear in the
Assignment Request message to RAN, so that the test succeeds for both
the current osmo-msc and the upcoming patch (see below).
Related: SYS#5066
Related: Ie433db1ba0c46d4b97538a969233c155cefac21c (osmo-msc)
Change-Id: Id0c98bc267daff352fc7db7712f967111970fd4d
These tests are currently failing since osmo-cbc doesn't support
reloading cells yet.
Related: OS#5641
Change-Id: I7b1c5275eff56888268601b481e8f8c1dd1bb1b0
Vadim Yanitskiy
Neels Hofmeyr
Pau Espin
Daniel Willmann