BSC_Tests_VAMOS.ttcn is separate from BSC_Tests.ttcn in order to
instruct osmo-bts-omldummy to pass BTS_FEAT_VAMOS == true in the OML BTS
attributes.
Add tests:
TC_chan_act_to_vamos()
TC_mode_modify_to_vamos_fr()
TC_mode_modify_to_vamos_hr()
TC_assign_to_secondary_lchan_fr()
TC_assign_to_secondary_lchan_hr()
TC_vamos_multiplex_tch_f_tch_f()
TC_vamos_multiplex_tch_h_tch_h_tch_h_tch_h()
Change-Id: I2c504099163a30ea102cbd26d3615ca2e5ce1e64
In a recent osmo-bsc patch:
"allow explixit TSC Set and TSC on chan activ / modif / assignment"
c33eb8d56943b8981523754b081967e6ff5f245d
Ic665125255d7354f5499d10dda1dd866ab243d24
I accidentally changed the default behavior of the Training Sequence
Code sent to BTS and MS. So now, make sure that we verify the expected
Training Sequence Code in BSC_Tests, in:
RSL Channel Activate
RR Immediate Assignment
RR Assignment Command
RR Channel Mode Modify
RSL Mode Modify
Related: OS#5172 SYS#5315
Change-Id: Id67a949e0f61ec8123976eb8d336f04510c55c01
osmo-bsc does now support intra-cell re-Assignment of lchans with active
voice. Test re-Assignment of TCH/F, triggered by VTY command.
Change-Id: I05fecefb9d6f9f23a0362f133170bca4da92e308
Test the lchan mode modification code path of OsmoBSC, in preparation of
adding VAMOS bits to the mode modification procedure.
Related: SYS#4895
Change-Id: Idf4efaed986de0bbd2b663313e837352cc139f0f
Update TC_si2quater_*_earfcns test to trigger Tx of SI2quater eutran
neigh list properly, by sending a CommonID with "Last Used E-UTRAN PLMN
ID" IE. This should have been updated in a recent commit (see
below).
Fixes: 841b90daf2
Related: SYS#5337
Change-Id: I3073152475a338b29214393a9b550891d52e1f24
CSFB indicator shouldn't be used as stated in the specs. Rather, BSC
should act based on "Last Used E-UTRAN PLMN Id" found in messages such
as Common Id, or Handover Request/Required.
Related: SYS#5337
Related: osmo-bsc.git Change-Id I5d290ac55eca5adde1c33396422f4c10b83c03d5
Change-Id: I7b2e5a3ad24c10e279a7f1c447804100168203ba
The IE contains a cell list for the MS to register after the channel
is released. The IE is used in CSFB, but not only in that case: it's
also used in SRVCC.
Hence let's remove the CSFB references since the scope is more wide.
Related: SYS#5337
Change-Id: Ia1eeda98fc21aa92bb2e41b5e4761c5cf6516a7e
This param is not needed anymore sincenew releases used in -latest don't
need to disable it.
Let's keep the possibility to change behavior from within test and leave
v6 enabled by default as it used to be.
Related: OS#5042
Change-Id: Ic693885dd3d4259dc6ce80643d25c7d432148d3d
Since Idb453fc894584ccf4f5f8b45a24421db958e9478, osmo-bsc does send
ip.access specific Measurement Pre-Processing Defaults. This message
currently blocks the 'alt' statement in f_recv_next_si1(), so all
test cases calling it fail due to the guard timeout.
What's even worse, both TC_si_acc_rotate() and TC_si_acc_ramp_rotate()
dynamically configure the IUT in order to re-generate and send System
Information messages periodically. If any of them fails prematurely,
the related configuration parameters would remain active, so the IUT
would continue sending System Information messages, causing failures
in subsequent test cases.
Let's simply ignore all unmatched messages in the 'alt' statement.
Change-Id: I1a85a046e1a8ebcd494354dddcbcc9707fdf5ee9
There is a global boolean flag that would make f_init() return
early if it's called twice. This is exactly the case here.
Change-Id: Ic33786c4851d2682deec7c22fafb99043c1c1cf6
Calling f_shutdown_helper() in f_tc_chan_rel_rr_cause() leads to
premature test case termination, so only one out of 6 cause values
gets checked. Move it to TC_chan_rel_rr_cause().
Change-Id: Ic7df15b496fc0750e4f694b1ae79398216f498a7
This test shows that in current osmo-bsc, the start-mode fails to
propagate to the MultiRate Config IE, the only start-mode so far has
always been zero.
Change-Id: I75515baf8cda04567cad8a93c5aa88361c2d259f
Make sure that when a 'start-mode auto' is set, that the previous start
mode setting does not linger in the unused bits.
- after I577ff590d7588fd7e3ee4846c7955ab8f84cf2b1, osmo-bsc sets its
ICMI bit properly, but passes this test only because it *always* sends
smod (start-mode) bits as zero.
- in I49691df01745a7c485bf165e897872c35fc4b147, the smod bits are
properly sent on RSL, but this test shows that when ICMI becomes zero
for 'start-mode auto', the smod bits will remain whatever start-mode
was set in the previous osmo-bsc config. Instead, osmo-bsc should
clear the smod bits for 'start-mode auto' so that its MultiRate Config
does not vary depending on what was previously configured.
- in I1ec5bad0bce01cc425ee05ecf70c83ec662a226a, clearing smod is
implemented and this test is expected to pass.
Change-Id: I151678f64e680f30f35b6bb2b0036d63efde9f2c
osmo-bsc currently has a bug that fails to reflect the correct
start-mode in the AMR MultiRate config IE.
And it went unnoticed that the ttcn tests expect a MultiRate config of
ICMI = 1, even though the used configuration should yield ICMI = 0.
See mr_conf = '2804'O, where the '8' indicates ICMI = 1.
As a first fix of the ttcn3-bsc-tests, configure the BSC according to
the expected ICMI value and Start Mode, i.e. ICMI = 1 and StartMode = 0,
which is configured by 'amr tch-[fh] start-mode 1'. This should make
these tests pass as-is for both the current osmo-bsc as well as an
osmo-bsc where the bug is fixed, with minimal changes to the current
tests. See also OS#4868.
An upcoming patch will add tests for 'start-mode auto'.
Related: OS#4868
Change-Id: I4cff01c37d5c7e301e9a01f773b7e009a789519b
These allow passing N vty configurations on the bts / msc node without
requiring subsequent 'exit'.
As an example, use f_vty_cfg_msc() in BSC_Tests.ttcn AMR config.
Change-Id: I9f3e485f692acb3d2a7620e9b454b372651be78e
When a RESET-ACK times out, the logs currently are indistinguishable between
BSSMAP and BSSMAP-LE. Add protocol naming for each RESET / RESET-ACK logging to
make sure the information does not need guesswork.
Example of a test failure shown in jenkins:
BSC_Tests.TC_unsol_ass_compl
Stacktrace
Timeout waiting for RESET-ACK after sending RESET
BSC_Tests.ttcn:8295 BSC_Tests control part
BSC_Tests.ttcn:4274 TC_unsol_ass_compl testcase
Nothing conveys that it is (presumably) the background *BSSMAP-LE* timeout
halting the test 5 seconds in, and not an A-interface failure.
Change-Id: I874567e68b8279bf2460b9474241f0a9fe5ff0ff
Adding LCS to OsmoBSC creates the possibility of a Paging for LCS, where the
Paging Response should not emit a Complete Layer 3 on the A-interface.
Change-Id: Icb402b7436d844d939790f3cfb3725ffcf1136d2
This introduces the Lb interface stack, which allows BSC_Tests.ttcn
to emulate a SMLC towards the BSC.
In accordance with https://osmocom.org/projects/cellular-infrastructure/wiki/Point_Codes
we use 0.23.6 as point code for emulating the SMLC.
Change-Id: Id41246f0dd812f7ddee9d920bfd07a4e3aac3504
Without this, subsequent vty commands become "% Unknown command".
(Triggered by the test start vty "logp" in f_start_handler() that is going to
be added by subsequent patch.)
Change-Id: I51ace11883256ee0725caae46ea22adb2ea5eb39
We cannot use a random 8bit value as RACH request, as some of that
space actually maps to emergency call RACH, which is rejected unless
we enable it in the config.
Change-Id: Ie073fe721022c392278e8632ab52122b4b89cbe1
Since If4d479a54cad467f53b49065c1c435a4471ac7d2, osmo-bsc started
to send more concrete DLCI values on the A/BSSAP interface. In
particular, the control channel identification bits now indicate
whether it's SDCCH/FACCH or SACCH channel.
Let's use '?' as the default DLCI template that we expect to get
from the IUT, so those test cases, for which DLCI is not a part
of the testing scenario, would not fail.
Change-Id: Ida659d53e0d31f9aa0ea2ccccefc94d8c659eb76
The aim of this test case is to verify DLCI / RSL Link ID conversion
for MO/MT L3 messages on SAPI0/SAPI3. In particular, the test suite
verifies the following scenarios:
- RSL -> BSSAP:
- 16 MO messages on FACCH/F with SAPI0,
- 16 MO messages on SACCH/F with SAPI3;
- BSSAP -> RSL:
- 16 MT messages on FACCH/F with SAPI0,
- 16 MT messages on SACCH/F with SAPI3.
Change-Id: Ica69ae95b47a67ba99ba9cc36629b6bd210d11e4
Related: OS#3716
The new name is more concrete and better reflects what the
function does: transmit a MO L3 payload to the IUT over the
A-bis/RSL and receive it back on the A/BSSAP.
Change-Id: Ic2b60b60c49ae7788ce03503b8b867bb9e55244b
Related: OS#3716
When the BSC sends a CRCX without an IP address in it, the testcase will
automatically assign an IPV6 address in the response. However, this
breaks compatibility with older versions of osmo-bsc that do not have
IPV6 support. Lets add a module parameter in order to be able to use
IPV4 as default if required.
Change-Id: I30c77abef63636bb02db12d2f2b2d79ea244b96c
Neels Hofmeyr
Pau Espin
Harald Welte
Vadim Yanitskiy
Philipp Maier