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
Without the SMLC routing in place, virtually all BSC_Tests fail with:
VirtSMLC-BSSAP_LE(8)@x42: setverdict(fail): none -> fail reason: "BSSMAP-LE: Timeout waiting for RESET-ACK after sending RESET"
Copy the SMLC part of osmo-stp.cfg from
docker-playground/ttcn3-bsc-test/osmo-stp.cfg and localhost-ize it.
Change-Id: I274515e7e9205c895cd250abed7361aef5a33f56
During f_create_chan_and_exp() (part of f_establish_fully()), announce
the BSSAP L3 expectation before activating the lchan.
In RSL_Emulation f_chan_est(), we go through Chan Request, Channel Act
and Immediate Assignment followed by EST IND. Right after that, osmo-bsc
sends a Complete Layer 3 on BSSAP. But in f_create_chan_and_exp(), we
only create the expectation of the BSSAP right after the call to
f_chan_est(), i.e. only after sending the EST IND. So far it was always
juuust in time to work, but when I added a little check to the end of
f_chan_est(), or alternatively an f_sleep(0.2), then BSC tests always
fail with:
Test case TC_reassignment_fr finished. Verdict: fail reason: Couldn't find Expect for incoming connection { [...] pdu := { bssmap := { completeLayer3Information... }
With the BSSAP expectation done first, this error is avoided.
Change-Id: I1d4af737dcc0f9c9fa6cdaff3a92813d532e730c
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
I am introducing a BSC test case that runs through a assigning a TCH
channel for signalling, and then using Channel Mode Modify to change its
mode from signalling to speech. For this to work,
f_channel_needs_modify() needs to actually look up the channel mode of
the TCH and not assume that a TCH is always in speech mode.
Related: SYS#4895
Change-Id: If30e2cec65da91cb5899ee29e2afb6696437a4c9
it has been deprecated in libosmocore.git 2.5 years ago:
commit 7e0686c6b4b456ec4e6e15689694b1bcf96c301f
Author: Neels Hofmeyr <neels@hofmeyr.de>
Date: Mon Sep 10 20:58:52 2018 +0200
Change-Id: Ieb9e958278e7bb9d5e798f83b70dcb873a25d06d
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
It was previously disabled by default in order to avoid test breakage
with older versions of osmocom projects not supporting them. Since we
just did a new release, all -latest contian now master which should work
fine.
Don't remove the moduleparam yet in order to avoid breakage with some
cfg files in docker-playground.git still setting it to true.
Related: OS#5042
Change-Id: I4e2049c109986906d3c985ca2282174b1abff581
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
The altstep as_handover needs to repeat until the IPACC and the MGCP rtp
negotiation is done (MDCX). By setting the norepeat flag of the sub
altsteap as_Media_mgw to true, we allow as_handover to exit early, even
when the handover is not done yet, which eventually causes the testcase
to fail.
Change-Id: I303879a9153d25a02743dc1d4713ae74918b9be7
fixes: OS#4752
According to 3GPP TS 44.018, table 10.5.2.21.1 "Mobile Allocation
information element", in the cell allocation frequency list the
absolute RF channel numbers are placed in increasing order of ARFCN,
except that ARFCN 0, if included in the set, is put in the last
position in the list.
Let's verify that the IUT handles this corner case correctly.
Change-Id: I3afadfde03f6ea766c0756a181ef129e4b05c383
Related: SYS#4868, OS#4545
The Mobile Allocation IE generated by the IUT includes not only
the list of hopping ARFCNs, but also ARFCN of the transceiver
itself. This is the correct behaviour, and that's why we see
sporadic test case failures like this one:
Mobile Allocation IE does not match (tn := 1):
{ len := 3, ma := '001010101011111100000000'B }
vs expected
{ len := 2, ma := '0010101010111111'B }
The last '0'B bits may look like redundant padding, but actually
only 7 of them are. The MSB '0'B bit in the last (third) octet
corresponds to pre-configured ARFCN 871.
Since f_TC_fh_params_gen() generates all ARFCNs in GSM-900:
- in f_TC_fh_params_gen(), pick an ARFCN value from GSM-900;
- in f_TC_fh_params_set(), change ARFCN of a given transceiver;
- in f_TC_fh_params_gen_tr_ma(), consider that ARFCN;
- in f_TC_fh_params_unset(), bring it back to 871.
Change-Id: Id11be94087c18d8159af4b7988826023832f9944
Related: SYS#4868, OS#4545
This record must contain not only the hopping parameters, but
also ARFCN of the transceiver they belong to. Since ARFCN of
the transceiver also becomes part of the Mobile Allocation,
we need to take it into account in the matching functions.
Change-Id: I4722dc3f758a097806811cb0b59aa4093374c74c
Related: SYS#4868, OS#4545
The testcase TC_emerg_premption does not set a verdict when done. Make
sure that the verdict is set to pass when the test is done.
Change-Id: Ie612b32cfa9cedd1e0f1d51e48911da94ec325cf
Related: OS#4549
osmo-bsc is using the same LTE neighbors of the SI2quater in the Channel Release -
Cell selection indicator after release of all TCH and SDCCH IE. Ensure the same measurement bandwidth
is present to not overwrite the measurements bandwidth from the SI2quater.
Change-Id: I9aa30dfd1e2c1b80e037bd71ebc4cdd3752638b4
This scenario appeared in jenkins runs of BSC_Tests making
TC_ctrl_msc_connection_status fail (the first test in the suite). I
could however not reproduce it on my local docker setup because it
really seems like a timing race condition.
The scenario is:
TTCN3 -> BSC: RESET
TTCN3 <- BSC: RESET
TTCN3 -> BSC: RESET-ACK
In there, TTCN3's f_legacy_bssap_reset() expected a RESET-ACK to be
received, but it may well be that the other end never saw the RESET and
hence it will never sent the RESET-ACK, since it indicated it became
available afterwards. In that case (RESET received), let's not fail if a
RESET-ACK is never received, since the connection is actually in the
desired state and this scenario can happen and it's all fine.
Change-Id: Ic92e0fb7033e5134b66e485a11371394adaba78a
Similar to TC_fh_params_assignment_cmd, this test case verifies
presence and correctness of the hopping parameters in the following
messages and their IEs:
1. (RR) Handover Command
1.1. Description of the First Channel, after time IE
1.2. Cell Channel Description IE (presence)
1.3. Mobile Allocation, after time IE
The hopping parameters are randomly generated and configured
via the VTY interface in the beginning, and unset in the end.
Since the C0/TS0 (BCCH+SDCCH4+CBCH) shall not be hopping, let's
temporarily re-configure TS0 as BCCH, and TS1 as SDCCH8 on TRX0
of BTS1 (handover tagret).
Change-Id: I0ddea535dce7e5558793be5cddaad0ab46e978ec
Related: SYS#4868, OS#4545
My initial assumption was that we can skip redundant '0'B bits or
even '00'O octets in the Mobile Allocation IE, and thus reduce
the overall size of this element. Unfortunately, this is wrong.
3GPP TS 44.018, section 10.5.2.21 clearly states that the Mobile
Allocation IE contains a bit-string of size NF, where NF is the
number of frequencies in the cell allocation. If NF % 8 != 0,
then '0'B padding bits must be appended to make it octet-aligned.
In other words, if the cell allocation contains let's say 13
frequencies, but a hopping timeslot makes use of only a small
fraction of it (e.g. 4 first channels), we would still need to
transmit at least 13 bits (+padding), including all redundant
bits and octets.
Change-Id: Ia79efc9aa07b5088913d6679715f351d30f48d13
Related: SYS#4868, OS#4545
Change [1] introduced a regression that caused some TC_cbsp_*
test cases to fail. The problem is that TC_fh_params_si4_cbch
re-configures TS0 as CCCH+SDCCH4 instead of CCCH+SDCCH4+CBCH,
so the CBCH channel vanishes after this test case is executed.
[1] Ibc3b73697a1d2c8dbb27274e48f5e5ba21fdd540
Change-Id: Ia249f10c1b768a5af2b6c92ecba5d2941528f876
Related: SYS#4868, OS#4545
Make it possible to call them from a testcase / function
running on any kind of component, not only on MSC_ConnHdlr.
Change-Id: Ifbcc24c5a0299ba43a998ccbdd0f77bc109c6935
This test case verifies presence and correctness of the hopping
parameters in (RR) System Information Type 4 (CBCH description).
Since the C0/TS0 (BCCH+SDCCH4+CBCH) shall not be hopping, let's
temporarily re-configure TS0 as BCCH, and TS1 as SDCCH8+CBCH.
According to 3GPP TS 44.018, section 9.1.36.1, if CBCH is active
in the cell, the CBCH Channel Description IE indicates where to
find it (physical channel description).
According to section 9.1.36.2, the CBCH Mobile Allocation IE shall
be included if CBCH Channel Description IE indicates that frequency
hopping is in use.
Change-Id: Ibc3b73697a1d2c8dbb27274e48f5e5ba21fdd540
Related: SYS#4868, OS#4545
This test case verifies presence and correctness of the hopping
parameters in the following messages and their IEs:
1. (RR) Assignment Command
1.1. Description of the First Channel, after time IE
1.2. Mobile Allocation, after time IE
Change-Id: Id12509385b444c426f4af7a0cf0d46efe2cb0eda
Related: SYS#4868, OS#4545
This test case verifies presence and correctness of the hopping
parameters in the following messages and their IEs:
1. RSL CHANnel ACTIVation
1.1. Channel Identification IE
2. RSL IMMEDIATE ASSIGN COMMAND
2.1. Channel Description IE
2.2. Mobile Allocation IE
The hopping parameters are randomly generated and configured
via the VTY interface in the beginning, and unset in the end.
Change-Id: Ib9218b61a2b0c0467340656e4b65a36b7b0ba302
Related: SYS#4868, OS#4545
This will break the 'latest' builds for most handover tests until
Ib0087b6566ae4d82f8c3ef272c1256bcd1d08bf1 is released.
Move the TC_ho_neighbor_config_* closer to the f_tc_ho_neighbor_config_*
functions, so that it is easier to read the added counters, relating to the
expected handovers.
Depends: Ib0087b6566ae4d82f8c3ef272c1256bcd1d08bf1 (osmo-bsc)
Change-Id: I10bc0b67ca8dcf41dbb02332ed18017e819c2b32
This reverts commit c47fdb2e52 - as
osmo-bsc currently doesn't yet have a Lb interface, we shouldn't try
to test it yet.
Change-Id: I7898dd336cbef27553d97857ac22f1a539da1380
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: I854618cc08de1a716784f52542a4df3c7f7ad900
With Icaa2775cc20a99227dabe38a775ff808b374cf98, osmo-bsc no longer allows
configuring CBSP as both server and client at the same time, and the 'cbc' VTY
section has a different structure.
Adjust the 'cbc' section in osmo-bsc.cfg.
For each CBSP test init, switch osmo-bsc's CBSP link to server or client mode
by new vty command 'cbc' / 'mode (server|client|disabled)'.
Related: Icaa2775cc20a99227dabe38a775ff808b374cf98 (osmo-bsc)
Related: I9e9760121265b3661f1c179610e975cf7a0873f1 (docker-playground)
Related: OS#4702
Change-Id: I7eea0dd39de50ed80af79e0f10c836b8685d8644
The idea of these new test cases is to verify that the IUT does
send BSSMAP SAPI N Reject in the following cases respectively:
- on receipt of an unexpected RLL RELease INDication message
in response to RLL ESTablish REQuest (for SAPI=3 link);
- on receipt of an unexpected RLL ERROR INDication message
in response to RLL ESTablish REQuest (for SAPI=3 link);
- due to SAPI=3 link establishment timeout.
Change-Id: I00489e2af3befe5780380f64b09fb01e726c8df5
Related: SYS#5047, OS#4728
When receiving the instruction to CBSP RESET, osmo-bsc should stop CBSP
broadcasting on all affected BTSes. Expect the according zero-payload ETWS CMDs
on all CBSP relevant RSL ports.
This behavior is implemented by osmo-bsc
I925a041936c6163483d70fe6d158af368ec8c444
This is expected to break all CBSP tests until above bsc patch is merged,
particularly the 'latest' tests will see this breakage until the next release
is tagged.
Depends: I925a041936c6163483d70fe6d158af368ec8c444 (osmo-bsc)
Change-Id: Ifee313369a433a6a638c5fffdedee5363b8e47c2
Fill all channels of the BTS and then try to do a channel request for an
emergency call. Osmo-bsc should pick one of the TCH channels and release
it so that there is room for the emergency call.
Change-Id: I7d544680f492cb825d909b86b2e1131ab652df13
Related: OS#4549
the argument given to tr_ASP_RSL_UD() needs a 'present' qualifier, as it
cannot be 'omit'
BSC_Tests_CBSP.ttcn:524.1-537.1: In testcase definition `TC_cbsp_write_lac':
BSC_Tests_CBSP.ttcn:532.2-535.2: In interleave statement:
BSC_Tests_CBSP.ttcn:533.5-41: In guard operation:
BSC_Tests_CBSP.ttcn:533.5-41: In receive statement:
BSC_Tests_CBSP.ttcn:533.37-40: In actual parameter list of template `@IPA_Emulation.tr_ASP_RSL_UD':
BSC_Tests_CBSP.ttcn:533.38-39: In parameter #1 for `rsl':
BSC_Tests_CBSP.ttcn:533.38-39: warning: Inadequate restriction on the referenced template variable `tr', this may cause a dynamic test case error at runtime
BSC_Tests_CBSP.ttcn:531.27-82: note: Referenced template variable is here
BSC_Tests_CBSP.ttcn:534.5-41: In guard operation:
BSC_Tests_CBSP.ttcn:534.5-41: In receive statement:
BSC_Tests_CBSP.ttcn:534.37-40: In actual parameter list of template `@IPA_Emulation.tr_ASP_RSL_UD':
BSC_Tests_CBSP.ttcn:534.38-39: In parameter #1 for `rsl':
BSC_Tests_CBSP.ttcn:534.38-39: warning: Inadequate restriction on the referenced template variable `tr', this may cause a dynamic test case error at runtime
BSC_Tests_CBSP.ttcn:531.27-82: note: Referenced template variable is here
Change-Id: Id64e8e135b690c34293487304d7a175b5b56265b
Some tests may stop without cleaning up the CBSP state. Avoid affecting
subsequent tests by clearing the state for each f_cbsp_init_server().
Some ETWS CMD may still be left in the RSL queue (from the time period passing
between a stopped test and the next test starting up), so clear all RSL ports.
To be able to do so, move f_cbsp_reset_bss() to the cbsp_test_CT, from where it
can access both CBSP and IPA_RSL[] ports. All current callers are on
cbsp_test_CT anyway.
This patch should fix TC_cbsp_emerg_write_bts_cgi_cchan and
TC_cbsp_emerg_write_bts_cgi_cchan_disable, which so far break because of
leftover ETWS CMDs in the RSL queue from the preceding test run.
Change-Id: If7400a6624bb6dd9cacbcc733bdeba102d19e29c
For each CBSP test, define one global set of CBSP msg id and serno for use by
that test.
Each CBSP test should use a distinct message id and serial nr, to not get mixed
up with previous state. But keeping those numbers manually is a confusing pain,
and as a reader it is hard to follow how these numbers change (if they do).
In f_cbsp_init_server(), require a preset of msg id and serno to be used in
that test, and from then on only use g_cbsp_msg_id and g_cbsp_ser_no instead of
magic numbers. If they change, write it out explicitly, making it easy to
follow what is expected to happen, and also making it easy to copy-paste code
snippets without having to manually adjust magic numbers.
Choice of numbers: pick a simpler scheme where both msg_id and ser_no share a
common "prefix" in the 1000s range, and for a ser_no add 500 to keep distinct
numbers (that avoid confusion when reading the logs):
test prefix msg_id ser_no next-ser_no
1 1000 1001 1501 1502
2 2000 2001 2501 2502
3 3000 3001 3501 3502
...
E.g. the first test has the prefix of 1000.
msg_id: 1001, ser_no: 1101.
Change-Id: I43ba196974614d1aea2b6055be2fe82059b38974
It might be part of initialization, but what this function does is expect to
receive a CBSP RESTART, period.
Change-Id: Ieffe70cf43eb79b798d93717bbce294ee809f0e2
Recently fixed errors in the last_block counting as well as encoding ask for a
proper test coverage of various lengths, which also verifies the expected
blocks count explicitly.
Implement this in TC_cbsp_write_bss():
Run f_tc_cbsp_write_bss() multiple times with differing fixed payload lengths,
at all block count transitions, plus some arbitrary lengths in-between.
Before this patch, TC_cbsp_write_bss() would pick a different random payload
length for every test run, which, until recently, then sporadically hit
last_block value errors. That's not good for reproducability.
Change-Id: I3cace19f9e5adc8ebab13ef2328a36dc150b2b31
Subsequent patch I3cace19f9e5adc8ebab13ef2328a36dc150b2b31 adds a test with
specific payload lengths. To verify the correctness of the number-of-blocks
calculation (recently fixed), allow pinpointing the expected blocks count.
Change-Id: Ie58a6175e55ab2679dc69f9e191d0efc0e84cde0
Keep the default of using a random payload length, but also allow picking one
specifically. TC_cbsp_write_bss() will use this in a subsequent patch.
Change-Id: I259da42cbcbfdfe930aabb45c9de8a2b67c69629
Fix the length calculation to provide a range of [1..82].
f_rnd_int() generates [0..max[ (i.e., < max), so f_gen_page() so far has a
payload len range of [0..81]. We want no zero payload, and we want a maximum of
82 bytes (page max of 88 minus 6 header bytes).
Change-Id: Id521b6038a23dc8e71ea25475bcdef7bc8917531
When dividing the payload by 22, the initial 6 header octets must also be taken
into account.
And, the last_block value indicates 4 as 0, which is not encoded correctly
before this patch. Add a separate f_cbsp_block_count_enc() to fix the
calculation.
Change-Id: I06cc144bd92e94d461dac3f56a738da8e055b73a
Expecting a CBSP RESTART when connecting as CBSP client does not work, osmo-bsc
doesn't send any. Let's ignore this to get the CBSP tests running at all first.
We should clarify expected behavior and apply that, later (OS#4702).
Related: OS#4702
Change-Id: Ib93530691344c6dc4c0a8318bee2edf87e309a42
The bsc/BSC_Tests_CBSP.ttcn rely on a configuration where the first three BTS
carry out SMSCB messaging, and the fourth BTS does not. That requires a CBCH
channel config on bts 0, 1, 2.
Side effects:
- adjust the number of available SDCCH (for TC_chan_exhaustion).
- there now is a CBCH channel description in SI4, add this to
SystemInformationConfig_default.
Related: Idbcc703ace7012fb395f0eef3e445df28b368d74 (docker-playground)
Change-Id: Iac46ee2cc5bc0978d5f5baa550baf493a7c56b1b
In the ttcn3-bsc-latest tests, there are no 'msc 1' and 'msc 2' configured, so
stepping into 'msc 1' and '2' creates two new, empty MSC configurations.
osmo-bsc latest actually still tries to use them and fails 2/3 Compl L3.
So do not step into 'msc' config scopes if no such MSC is mentioned in the
running config yet.
This should finally fix the bsc latest tests after I broke them in
I02ad58ed7d0d0aac61e393b415e09c6c5c8a70ca and
Ibd5adb359b3fb302e2c70700d911878aef605ff3 and
I75295d638072df9f5213a7e74e4a960c009c2865.
Yes, I know :/
Change-Id: Ibfeeea98c2a962dec58ad03beb35bb7f83cad228
Invoke Clear Command with various Cause codes and verify that the RR Channel
Release reflects them.
Depends: I734cc55c501d61bbdadee81a223b26f9df57f959 (osmo-bsc)
Change-Id: Ie6c99f28b610a67f2d59ec00b3541940e882251b
Add a DCHAN and release to recently added SI2quater tests (because these tests
already configure various amounts of EARFCNs in osmo-bsc).
Verify that the RR Channel Release for CSFB contains all configured EARFCNs.
In GSM_RR_Types.ttcn, add coding for "Cell selection indicator after release of
all TCH and SDCCH IE".
In f_expect_chan_rel(), add optional arg csfb_expect_cells, and, if present,
decode the RR Channel Release message's L3 part, and in turn the Cell Selection
Indicator Value contained. Match against csfb_expect_cells.
In f_tc_si2quater_n_earfcns(), also compose a list of EARFCNs as found in the
RR Channel Release, and pass to f_expect_chan_rel().
Depends: I59e427e4ebb1c6af99b27a15c40fed82457ac8ab (osmo-bsc)
Change-Id: I882c5e1f70bcc4833fc837a95c900ce291919cc5
Test that a CHAN RQD that indicates an emergency call is rejected if
emergency calls are disabled.
Change-Id: I9084df86e8f808e3c1d948ab88e07e7458761a71
Related: OS#4548
The testcase TC_chan_act_ack_noest_emerg tests if an emergency causes a
channel assignment. This can only work if emergency calls are allowed,
but the testcase does not make sure that this actually is the case.
Related: OS#4548
Change-Id: I0ddac0ba8ed4afe993d566dcbea87cdc62ed9fe4
The EMERGENCY SETUP is an L3 message that normally gets passed through
transparently to the A interface. Nomrally the BSC will not look into L3
messages. However if EMERGENCY CALLS are allowed on a BTS or not is set
in the system information. Also osmo-bsc has the option to deny
EMERGENCY CALLS globally for all BTSs.
Since EMERGENCY CALLS are a crucial application, the BSC should not only
send the appropiate sysinfo messages that forbid emergency calling. It
should also make sure that any attempt to make an emergency call is
rejected early if emergency calls are denied.
Lets add some checks to verify that the allow/deny mechanisms for
EMERGENCY CALLS are working as expected.
Depends: osmo-bsc Ia6eb38370ce4165d221d2ffbe1cd105c0628313c
Change-Id: I486d99953529a1ce9f0a3950c9a97900922eee92
Related: OS#4548
The function f_establish_fully may be called with template ass_tpl set
to "omit". In this case we must make sure that we do not pass ass_tpl on
to isvalue().
Change-Id: Ie094e5b56a851351671327b475d5e597a5a94bf6
TC_chan_act_ack_noest requests a channel and then releases it again.
However, this does not test yet what happens if the requestor (BTS) uses
a request reference that indicates an emergancy call. Depending on the
configuration the BSC should reject or allow the channel to be
established.
Change-Id: If828c0f5786d89efa7608f38d648e2a2b8f6f675
Related: OS#4549
osmo-bsc takes a while to notice that a connected MSC is no longer connected.
Once the mscpool tests have run, the additional msc 1 and msc 2 still linger
around even though the BSSMAP link is no longer served by the bsc-tester.
The easiest way to ensure that only expected MSCs are contacted is to set
'no allow-attach' for each MSC that should not be in use.
So, the default setup is 'allow-attach' on msc 0, and 'no allow-attach' on mscs
1 and 2. In f_init(), allow attach on those MSCs indicated by the nr_msc
amount. The entire vty transaction to configure attach/no attach for all three
MSCs takes about 4 micro seconds in my test setup, so it is fine to do this
during f_init() for each BSC test.
After this, tests running after the MSC pooling tests (the LCLS tests) no
longer round-robin their subscribers across disconnected MSCs.
NOTE: it would be good to somehow detect more reliably in osmo-bsc that an MSC
is gone and not use it anymore. That is however not so trivial. To get the LCLS
tests back online, this is a workaround to avoid that complexity for now.
Change-Id: I02ad58ed7d0d0aac61e393b415e09c6c5c8a70ca
An upcoming patch adds a test series (of various payload lengths) to
TC_cbsp_write_bss(), which then needs a bit longer than 30 seconds to run
through those. That test will pass a longer guard_timeout.
Change-Id: I54e1b3994074f4d0caf5b201588fce0ec41dda89
Add more EUTRAN ARFCNs, reaching the maximum allowed amount.
Add tests with 12, 23, 42 EARFCNs, just for the sake of testing some arbitrary
numbers.
Add tests with 32 and 33 EARFCNs because before osmo-bsc
Iabeed10053ee5899b4def3509aedd25abb2410a9, only 32 EARFCNs could be stored by
osmo-bsc.
Add a test with 48 EARFCNs to verify the maximum amount of EARFCNs and maximum
amount of SI2quater multiplexes works as expected.
Add a test with 49 EARFCNs to verify the VTY error response when adding too
many EARFCNs, and showing that osmo-bsc still sends 16 SI2quater with 48
EARFCNs.
Depends: Iabeed10053ee5899b4def3509aedd25abb2410a9 (osmo-bsc)
Change-Id: I99bf9b3381812d1db6fd0757f65995bae48da776
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
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
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
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
osmo-bsc does not use an rtp-base for years, ever since we're using an MGW.
Related: Id14fa3066ca5d472a817593074a6222f159168a8
Change-Id: Ia4866fc603877b2ab8ce16683e9f6145764117c7
In f_probe_for_handover disable the RSL emulation before the vty handover
command. Otherwise, osmo-bsc may be too fast to issue the handoverCommand, so
that RSLem still handles it and says: "RSL for unknown Dchan".
(f_probe_for_handover() receives the handoverCommand directly, just to detect
whether a handover would be initiated, and then quickly aborts the handover
procedure.)
Related: OS#4264
Change-Id: I7f73ef8cbdf46e31a46c9e1b7ad0fa2bd41c0a12
RLCMAC blocks have a lot of fields and we will potentially require lots
of different templates, as well as functions to handle related structs.
Change-Id: I9c6597178168aa3848b21930f33be698dd2ce545
All the records related to Mobile Identity IE (see 3GPP TS 24.008,
section 10.5.1.4) are defined in [1], so there is no real need to
dumplicate them. Moreover, most of the related templates in
library/L3_Templates.ttcn are based on these records.
[1] titan.ProtocolModules.MobileL3_v13.4.0/src/MobileL3_CommonIE_Types.ttcn
Change-Id: I27c2743c59db770d6f7e9447dc8c1f539b228ced
Some stuff was wrong and some was missing after new features being
implemented in tests over time.
Change-Id: I7a279592a68ffc76408a8e728e76151534265cc0
Otherwise most tests in bsc-latest fail because in latest release BSC
never sends that IE.
Related: OS#4244
Change-Id: I725836784a7900d2ea51eae188c2c279e8639dbf
It will allow changing ms max power in osmo-bsc.cfg as well as TTCN3
expactancies in BSC_Tests.cfg easily in docker-playground.git without
needing to recompile or change code in TTCN3.
Change-Id: Ib00c96902377582bc32778c5b947a6b4274041aa
The BSC must not only pass the ETWS Primary Notification from CBSP
down every dedicated channel, but it must also send it via an
Osmocom-specific RSL message to enable the BTS to brodcast it via
the PCH (P1 Rest Octets) and pass it to the PCU for PACCH.
Change-Id: Ia418095844aaa418a4e2ff6fd75d8a4b3c8bb9c0
Related: #4046
When the BSC receives an ETWS PN via CBSP, it must send it through all
established dedicated channels of the matching BTSs.
Related: OS#4046
Change-Id: Ib057bd251604e9bae968e71de245b3bbf737a356
In this testsuite, we simulate BTS and CBC by attaching to RSL and CBSP
protocol interfaces of the BSC. We then issue a variety of CBSP
commands to the BSC and check for corresponding action on both the BTS-
facing RSL as well as responses on the CBSP side.
Change-Id: Ia6ffac181f50586d06d2f29bca1c57285179e861
Change the unit_id value, that is supposed to be unknown at BTS, from
0/0/0 to 99/0/0 to make TC_oml_unknown_unit_id pass again. The test was
failing, because a new bts that matches 0/0/0 was added to osmo-bsc.cfg
in [1], [2] and [3].
[1] Ia4ba0e75abd3d45a3422b2525e5f938cdc5a04cc
[2] I1c57a04747f5ec004ccf4657954dcb0b003c24fc (docker-playground)
[3] I00547dccf8908d46df4730cb513fe577956d7683 (docker-playground)
Related: OS#4156
Change-Id: I585ff825c7b6bca17e5c6fb6d670a649965a1653
Fix failing TC_ctrl test for ttcn3-bsc-test and -latest.
Depends: I00547dccf8908d46df4730cb513fe577956d7683 (docker-playground)
Related: OS#4156
Change-Id: Ie2c664ba0f845da644e20e2c919c12d8fc2af6ba
The testcase TC_paging_resp_unsol expects the BSC to close the channel
when an unsolicit paging response is received. This expectation is due
to the fact that osmo-bsc supports multiple MSC, which is not specified
in 3gpp specs. Therefore the BSC needs to know which MSC is in charge.
However, with MT-CSFB calls it is a normal situation that the BSC
receives a paging response on abis without sending a paging first since
the MSC has paged the UE via the SGs interface. In those cases we expect
the BSC to forward the paging response to the first configured MSC.
Related: SYS#4624
Change-Id: I5562cbf61a2aa42e6950860bc0f9c6c20c61a9fe
Since osmo-bsc commit "neighbor config: allow re-using ARFCN+BSIC pairs"
(I29bca59ab232eddc74e0d4698efb9c9992443983), osmo-bsc considers only those
cells as neighbors that are explicitly listed, or all local cells if none are
listed. This lead to breaking TC_ho_int, because the osmo-bsc.cfg has only one
remote-cell neighbor for bts 0, and hence a handover to local cell bts 1 is now
regarded as invalid.
The remote-cell neighbor is needed for inter-BSC handover tests; also consider
that the TC_ho_neighbor_config_* tests each place individual neighbor
configuration by live VTY interaction.
Hence make all of these tests more robust: remove the neighbor config from the
osmo-bsc.cfg file, and instead include VTY interaction for each test case that
sets the particularly needed neighbor configuration at runtime.
An analogous osmo-bsc.cfg change in docker-playground is in change
If44dd6b578cdc55076c8180707d1c2d69fe5f2a8.
(It is not actually harmful to leave the neighbor config in osmo-bsc.cfg, but
remove that since it is also not needed anymore.)
Change-Id: If44dd6b578cdc55076c8180707d1c2d69fe5f2a8
Add tests to play through various neighbor configurations.
Tests will pass as soon as osmo-bsc I29bca59ab232eddc74e0d4698efb9c9992443983
is merged.
Add RSL2 to allow triggering handover to BTS 2.
Adjust osmo-bsc.cfg to match the new tests. Also applied in docker-playground
I1c57a04747f5ec004ccf4657954dcb0b003c24fc.
- Actually enable handover.
- Add bts 3
Depends: osmo-bsc I8623ab581639e9f8af6a9ff1eca990518d1b1211 ('no neighbors')
Related: OS#4056
Change-Id: Ia4ba0e75abd3d45a3422b2525e5f938cdc5a04cc
Make sure that the RR is released only after the MSC has sent the Clear Command:
- first expect a Clear Request from osmo-bsc and return a Clear Command,
- only then accept RR release messages.
See 3GPP TS 48.008 3.1.5.3.3 "Abnormal Conditions": "The terrestrial resource
in the old BSS shall remain assigned until a CLEAR COMMAND message is received
from the MSC"
osmo-bsc already complies, the test should continue to pass.
Change-Id: Iba05336d3c4af8a1c57cdc828dae464eae3510b9
BSC waits to receive a ClearCommand in response to its ClearRequest
before it starts tearing down the MGCP conn on the MSC-side of the MGW
endpoint.
As a result, expected DLCX was not being sent which made test fail.
However, currently test still fails because current osmo-bsc master
sends a repeated ClearRequest message in this scenario.
Related: OS#4078
Change-Id: Ic398896147a0b6b04ffeae56a23d25783b2b17fe
* MGCP-over-IPA handling in MSC_ConnectionHandler means we need to use
the new MGCP_CLIENT_MULTI port since we'll be managing MGCP messages
from 2 different UDP connections, and we need to be able to route
answers correctly. As a result, parameter multi_conn_mode is enabled for
SCCPlite and all code adapted to use that port in that type of scenario.
* iDuring calls when on SCCPlite, send a full (all-required-params-in)
CRCX through the MGCP-over-IPA connection towards the BSC in order to
emulate the MSC, and expect the correct answer back. This way we test
BSC funcionality to forward MGCP messages coming from MSC works as
expected.
Related: OS#2536
Depends: osmo-bsc.git I38ad8fa645c08900e0e1f1b4b96136bc6d96b3ab
Change-Id: I31fed700772dd0b063f913b1e1639fd428c46e7d
* Some scenarios like MGW BSC-attached in SCCPlite require handling of
2 MGCP-over-UDP sockets in MGCP Emulation: 1 for regular
libosmomgcp-client from osmo-bsc and another one from the forward socket
from osmo-bsc (of MGCP-over-IPA messages communicated with MSC).
* Old port is kept for backward compatibility with other tests and
enabled by default. It's also interesting to keep it because it makes
tests without special needs (2 sockets) to use the old port/API which
produces simpler code to read and mantain.
* Users of the new port have to enable multi_conn_mode parameter and
expect to interact with port MGCP_CLIENT_MULTI instead of MGCP_CLIENT,
which will offer messages containing information about the UDP
connection being used by that message.
Change-Id: Ic0ba8c5cde068c07671512a83095d83e28b86746
Move logic handling CRCX and MDCX to function, so they can be reused for
other ports in forthcoming commits.
Change-Id: I07344657c5d1465a8e0c278adb76150ca7f449ba
* TTCN3 code was not ACKing the DLCXs, and as a result retransmitted
DLCX BSC->MGW were being counted as 2nd DLCX.
* In SCCPLite, only 1 DLCX is expected BSC->MGW, because the BSC only
takes care of the BTS-side conn in the endpoint, while MSC takes care of
the MSC-side conn (which is not sent in this case because doesn't really
involved the BSC other than forwarding the message, which will already
be tested in other places in forthcoming commits).
* Getting rid of retransmissions by ACKing the DLCX, it unconvers a bug
in TC_ho_out_fail_no_ho_detect when on AoIP, where BSC only deletes one
of the 2 previously created connections.
* Code is refactored into the function because its logic is made more
complex, and may be even more complex in forthcoming commits when we add
MGCP-over-IPA forwarding verification support.
Change-Id: Ia1d0db9af073760105cc8509e228e317dbea2268
Previous to this commit, BSSAP Reset (Ack) messages contained Osmux
Support IE even if transport was SCCPLite, where those IEs are actually
meaningless.
Change-Id: If6cc0f65a0f273297a4523e5d6a7564d966f0aa6
This will allow RAN_Emulation to have better knowledge on the protocol
stack in use, and behave differently based on that information.
For intance, forthcoming commit will append OsmuxSupport IE only if
transport is BSSAP AoIP.
Change-Id: Ife62e328af2d3f2475ff93249f2138820c7ddabb
ttcn3-bsc-test-latest currently fails on most tests because it tries to
use "osmux off" VTY param and only current osmo-bsc master supports it.
Change-Id: I61e4c59b2926f3f70cb6d0190a8683861e54179a
Some of our files didn't have a copyright notice at all, let's add
it. Also, update the notices in other files and ensure a SPDX
identifier is present in all but the most trivial files.
Change-Id: If7fa19ce484b415bc645e39b3d0d666b44b5f0fd
Test verifies once osmux is enabled in osmo-bsc, BSSMAP RESET (ACK)
contains Osmux Support IE and that it correctly handles BSSMAP ASsign
Req with Osmux CID.
Related: OS#2551
Depends: osmo-bsc 6de754cdde5319af3059d8fc6abf85037ec7eacc
Depends: titan.ProtocolModules.BSSMAP Iaf1e137269c0da20b2c96fd104b57edf336693af
Change-Id: If69c716dc06d61d810c32d1720a237c7535baca8
Since we use some BSSMAP extensions to signal Osmux, we need to maintain
our own fork of BSSMAP_Types in order to supports those IEs in BSSMAP
RESET and BSSMAP Assin Req/Compl. Hence, switch all build componenets to
fetch and use our fork.
Depends: titan.ProtocolModules.BSSMAP Iaf1e137269c0da20b2c96fd104b57edf336693af
Change-Id: Ic8debe5f3ffe8e1d4258fa6b4632a3871b99af40
Randomly, this test issues the Clear Command so fast that the MGW has not yet
been set up, and hence the test cannot possibly see DLCX for endpoint conns
that haven't been set up at all. So, simply wait a bit before clearing.
Change-Id: Idd0b3810916efd02a499e0ac060a6a275265b8c3
The RAN_Emulation currently unconditionally provides BSSAP and MGCP support.
Let's re-structure the code so that support for those protocols is now
possible to enable/disable at compile time.
This patch is in preparation of introducing RANAP support in RAN_Emulation.
Change-Id: Id53ba3ff05f9946230e0e4a759245de14a0f9fbd
Related: OS#2856
So far, BSSMAP_Emulation supported only a transport over BSSMAP.
However, we soon intend to merge support for RANAP in order to
simulate RANAP/Iu connections as well as BSSMAP. Let's start
by renaming some of the existing types/functions/ports/modules
without introducing any functional changes just yet.
Related: OS#2857, OS#2856
Change-Id: Iecbcb0c6c136baad9460eca40606bb4010d8882d
Make sure that the S15-S0 related testcases are only executed when AoIP
is used as transport.
Change-Id: I62d51bbe4b1f089ded6c271b68414a4a37d509d8
Related: OS#3864
The S15-S0 related testscases are missing from the expected-results.xml
file. Lets add them.
Change-Id: I28a853ec25feb723b2d333061e1ae4d2e0b34d86
Related: SYS#4470
The handling of the AMR rate configuration bits S15-S0 is currently only
superficially checked. Lets add more some more elaborated testcases to
check through varios different situations. Also make sure that the
resulting mr configuration IE is verified
Change-Id: Ica323deb9836deea72982e093c9cb31deb5a216b
Related: SYS#4470
The testcase TC_assignment_codec_amr_f uses a combination of S-Bits that
has S1 which configures a set of four rates at once. This is quite a
complex situation and since the BSC was upgraded with new features
affecting the behavior in this special case lets simplify this testcase
for now.
depends: osmo-bsc Ie52376b51fe07ed07056e8df2e9557293ff67a78
Change-Id: Ibf730f76947cdeed23eb3119167450e3b7a9b314
Related: SYS#4470
When a MSC releases a connection using the BSSMAP CLEAR CMD, it can
specify that this call was part of CSFB.
The BSC is then supposed to add a special IE to the RR RELEASE
message which will help the phone to switch back to LTE as soon
as possible.
This commit adds a new test case testing for exactly that behavior.
The test does *not* verify if the EARFCN information contained is
actually correct, only that the IE is present in the RR RELEASE.
Change-Id: I7501fb25578412c882ff92da5d388f3079bbce7f
Requires: osmo-bsc Ibfbb87e2e16b05032ad1cb91c11fad1b2f76d755
Related: OS#3777
The 'decmatch' keyword allows us to match the decoded version of some
octetstring, which is very useful in the situations where we have
the L3 message only as octetstring but want to check if it matches
some L3 template.
Change-Id: I0a91e067f7e8062bf991fef8b0d4d8da740bfafc
The RR RELEASE message does not always have to be '060D00'O,
which constrains it to:
* not having any optional IEs
* not having a cause value != 00
Let's relax the matching to accept any RR RELEASE message, whatever
the cause may be, and whether or not there are any optional IEs at the
end.
At the same time, also remove some copy+pasting but rather have one
template that gets used everywhere.
Change-Id: I4b9d078c9b66f040fe673b5d957cf8e2c6d5892c
The tests presented in Change I109d986dd7ece1a56422a669ca64353ed46f7ed6,
are using a slightly outdated vty syntax and fail because of that. Lets
update the VTY syntax.
Change-Id: I302e8872dbdc8e65d51902a881f777863de22915
Related: OS#3503
When a channel is assigned via the assignment request throught the A
interface, the MSC may offer either FR, HR or both. When FR and HR are
permitted, a preference is set on one of the two.
At the moment we do not check how the bsc is reacting to those
preferences and its also not checked how the behavior is when the
preferred rate is not available because all lchan of that type are
already in use. Lets add a set of tests to verify this.
Change-Id: I109d986dd7ece1a56422a669ca64353ed46f7ed6
Depends: osmo-bsc I397e68e26d6a1727890353fa34f4897b54795866
Related: OS#3503
Previous RA value (23, Establishment cause = 0010XXXX) meant MS was dual
rate capable but was asking speciifically for only TCH/F channel. As a
result, TCH/H was not being allocated and an immediate assignment reject
was sent.
Change-Id: I3e58592c661fc004e648dbe46b67a3b3f5a20bc8
When an internal handover is performed, the BSC is expected to inform
the MSC about the event by sending a BSSMAP HANDOVER PERFORMED message.
This feature was missing in the BSC and has now been added. The tests
need to be upgraded in order to handle the additional message.
- Upgrade f_tc_ho_int so that it expects a HANDOVER PERFORMED message
Change-Id: I10f4e578c96a90317939ba49b61b14a3c7e488a7
Depends: osmo-bsc If26e5807280e0f75a423b3b04f8e3c698c82a351
Related: OS#3645
TC_paging_resp_unsol spent some time in gerrit before being merged. As a
result, other commits were merged in between the test was submitted (tested)
and merged. As a result, commit a5302c8151
was merged while this test was still in gerrit and thus was not updated
accordingly.
Similar stuff happened with the osmo-bsc commit fixing the scenario this
test was showcasing: The osmo-bsc patch (77cd1129931928d2a6e7667d0374feeeed71b0ce)
had merge conflict with other osmo-bsc commits merged in-between,
and was merged even later than the commit introducing this TTCN3 test, so
failures were expected for this test for a while.
Change-Id: I933cba41912640eb7e15be4a27bda5b4dd489962
The idea of this test case is to verify channel deactivation
procedure due to no response to Immediate Assignment.
Change-Id: I00b0838c9f919303aef72280248b0d1317f42b3b
Related: OS#3709
With this test we want to verify that channels are released if BSC fails
to complete an L3 request, for instance because no pending Paging
CMD is found for a received Paging Response.
Related: OS#3680
Change-Id: Iabe8a51aa13d2fcfec4500cf7aab47d60cc138ce
It's useful to see which BTS exactly has failed the test in
configuration with multiple BTS on single BSC.
Change-Id: Ib813635862c04d51a30e7bbcca4ec05ce664f7e9
Previously the expectations for number of CRCX and MDCX messages from
MGW was adjusted unconditionally for LCLS tests. However this is only
necessary for MGW-loop type of LCLS. Use explicit variable (with default
value preserving current behavior) to decide whether to apply this
adjustment or not. This simplifies support for other kinds of LCLS
loops.
Change-Id: I07b2c56991977b5e80c372a5b8338f348f14c076
Related: OS#3659
Move duplicated code into separate functions to simplify adding test
cases which do not use MGW MDCX methods for closing the loop.
Change-Id: Idf9fc8e639b0ece662ab26c481899ef39fb7edfe
Related: OS#3659
Add two helper functions which retry a VTY command until the
result matches a regular expression or a configurable timeout
expires.
Use these functions in BSC test's f_ts_dyn_mode_get, which has
seen sporadic failures due to a race condition during channel
reconfiguration, in order to hopefully close this race.
Change-Id: I308ddb06e440c165fe1e73fe2c1fb78be2e1d510
Related: OS#3690
Instead of vaguely allowing any release messages to be present or not, exactly
pinpoint for each test case the exact release messages expected during lchan
release.
Related: an osmo-bsc change broke sending of RR Release messages, which was
utterly ignored and hence not caught by ttcn tests. That must not happen again.
I am not actually sure that these expectations are 100% correct; if errors
become apparent, we shall change the expectations in ttcn3 and then fix
osmo-bsc according to that.
Adjust f_expect_chan_rel() and callers,
and the Assignment procedures (as_assignment and f_establish_fully).
The current state of the bsc tests should all pass with osmo-bsc
Id3301df059582da2377ef82feae554e94fa42035
Related: OS#3413
Change-Id: Ibc64058f1e214bea585f4e8dcb66f3df8ead3845
Allow osmo-bsc sending a Deact SACCH messages in most cases. Prepare the
ttcn3-bsc-tests to not break just because of those messages that will soon be
sent.
When releasing an lchan, it makes sense to Deactivate SACCH on it, if it was
ever active. So far osmo-bsc was fairly reluctant to send Deactivate SACCH, but
osmo-bsc Id3301df059582da2377ef82feae554e94fa42035 is about to change that.
In most test cases, Deact SACCH are still optional, but in one case, the
current missing Deact SACCH will introduce a test failure: in the 'interleave'
of BSC_Tests.TC_ho_out_fail_no_ho_detect.
As soon as abovementioned osmo-bsc patch is merged, the test will pass again.
Also, as soon as Ibc64058f1e214bea585f4e8dcb66f3df8ead3845 is merged here, the
bsc tests will properly ensure whether Deact SACCH is sent or not in all tests.
Change-Id: I27da24dbe3184fa7a076a35f6fa6af457c1db8d2
Receive RR Release messages if they happen during lchan release. Add RR Release
to the alt{}s in both f_expect_chan_rel() to cover a whole bunch of test cases,
and in f_tc_ho_out_fail_no_ho_detect() which has its own release expectations.
Before this, RR Release messages would typically be lost in the RSL.clear
recently removed by Ie1be30c3f109dda8c58c523df508211f8e20aad3.
However, I still expect tests to pass after this, since the current osmo-bsc
master has a bug that omits RR Release messages (since [1]).
By applying this patch, both the buggy osmo-bsc (omitting RR Release) and the
fix of that [2] should pass the BSC tests. So far by accepting whatever comes
along, and not complaining if it doesn't come along.
A subsequent patch will more precisely ensure that exactly the expected
messages will be sent by osmo-bsc (Ibc64058f1e214bea585f4e8dcb66f3df8ead3845).
[1] osmo-bsc I4fd582b41ba4599af704d670af83651d2450b1db
commit 8b818a01b00ea3daad4ad58c162ac52b4f08a5cb
"subscr conn: properly forget lchan before release"
[2] osmo-bsc I666b3b4f45706d898d664d380bd0fd2b018be358
"fix: send RR Release (e.g. after BSSMAP Clear Cmd"
Related: OS#3413
Change-Id: I4e6d266d091b140f56b28312cb3c5d67ffcc3a59
Instead of placing an own set of channel release expectations, just use the
common f_expect_chan_rel() that exists for exactly this purpose.
This will also be in line with upcoming changes to tighten checking of the
lchan release messages.
Related: OS#3413
Change-Id: Ib7dd886472337e2deb968e6f9de6cecdb7855319
When we're expecting release, it can be non-deterministic / timing dependent to
flush the RSL queue. Particularly the RR Release message is typically already
in the queue when f_expect_chan_rel() is called and would be lost.
It turns out that none of the current callers need the flush feature.
If a test needs it, we can add a separate f_rsl_flush() function and call that,
no need to clutter up the f_expect_chan_rel() argument list. I had such
function but found that no caller needs it, so dropped it.
Related: OS#3413
Change-Id: Ie1be30c3f109dda8c58c523df508211f8e20aad3
Check that channel number IE is present in the received message. This
fixes following warning:
The value returned by function `@RSL_Types.f_rsl_find_ie' is not used
Change-Id: Icc6824d7acef809d76c70b5ff060a8261a82e2be
Related: OS#3659
The osmo-bsc.cfg should work on localhost. Having arbitrary IP address
in it seems confusing and might lead to hard-to-debug errors.
Change-Id: Ideb8a78348af435f9992c42bce0bb197d1e73e04
Unfortunately all component.stop can not be called from the non-mtc
component. f_shutdown is a wrapper that will try to shutdown a test in
the best way calling all component.stop if it is called from the mtc and
just stopping the mtc if called from any other component.
Change-Id: I9b71f7f7bd70d2da21fbad60c340d5bf8b3b9536
Some TC_no_out_fail_* testcases still used valueof() to get g_pars which
always set aoip to true.
Use f_gen_test_hdlr_pars() now so these tests can properly detect if
they are run with sccplite of aoip and can adjust their expectations
accordingly.
Change-Id: Ic164827d63c9f5452888951bba4c197c3fe6f57b
This function can now be called from anywhere to try and safely shutdown
a testcase. It is not optimal as we can't call "all component.stop" from
outside the mtc, but without any proper and orderly shutdown handling of
all our emulation components I believe this is the best we can do.
To use it:
import from Misc_Helpers all;
in your module and then call
Misc_Helpers.f_shutdown(__BFILE__, __LINE__);
You can also pass the function a verdict and a message and it will take care
of calling setverdict, but beware of the following:
While setverdict would accept any number of arguments as log message
and convert them to a log string f_shutdown expects one charstring.
It's possible to use the log2str function to use the log arguments in
setverdict for f_shutdown, for example
setverdict(fail, "Template didn't match: ", tmpl_foo);
would become
Misc_Helpers.f_shutdown(__BFILE__, __LINE__, fail, log2str("Template didn't match: ", tmpl_foo));
Change-Id: I84d1aa6732f6b748d2bfdeac8f6309023717f267
Add another IPA test to the BTS and BSC test suites.
This new test sends the header in one burst, followed by the
payload which is transmitted byte-per-byte.
The test uses an ID REQ message. If acting as a server, the test
can expect an ID RESP message. However, if acting as a client, the
server will close the connection when it receives the ID REQ.
The CTRL interface port on the BSC does not close the connection in
this case, so that particular port is skipped by the test for now.
Change-Id: If75cb90841bb25619b414f0cabe008a2428a9fdf
Related: OS#2010
Depends: I4804ccabd342b82d44e69dbc6eaaae220ec7d4e4
With a related patch to libosmocore, this test will pass on
osmo-bsc's ctrl interface.
Change-Id: I20a4f251dbe3e75a5c53a0ff167998bbd1266f62
Depends: I9d7137c830981ccad03806b30b776e2b1f1b4699
Related: OS#2010
Most differences between sccplite and AoIP are visible during the
assignment. The current implementation checks for the presence of a CIC
in the ASSIGNMENT REQUEST in order to detect if the communication should
be modeled by AoIP or sccplite. This method is error prone and does not
work very well in situations where only signalling is used, because
there in sccplite and AoIP no CIC or AoIP trasp. identifier is present,
so there is nothing to check on. To resolve this we need an explicit way
to tell the MSC_ConnectionHandler that it has to behave like an AoIP MSC
or like an sccplite MSC.
- Add an aoip flag to TestHdlrParams
- Make sure BSC_Tests.ttcn sets the AoIP depending on mp_bssap_cfg.transport
Change-Id: I800249e783deb018d99e81d814843e0574a5c69b
Related: OS#3639
We cannot test the control interface with an IPA ping message.
The control interface only supports osmocom-specific extensions,
and the IPA ping message is not part of those extensions.
Other tests will have to be devised for the control interface.
Change-Id: Iae0f16394c78196de621c14b34d1b1905c0cb7c8
Related: OS#2010
This new module allows us to test IPA code in libosmocore
and libosmo-netif. Currently only one test is implemented,
which sends a chopped IPA ping message and expects to receive
an IPA pong.
The system under test is any IPA speaker on any TCP port.
Any test suite may call parametrized functions to create
an IPA testing component and run a particular test.
So far, one such test has been added to the BSC_Tests suite.
Change-Id: I246a405414e36a44dc1e308692faab8bf04da0e6
Related: OS#2010
Since our BSC implementation supports AoIP, the COMPLETE LAYER 3
INFORMATION message must contan a Codec List (BSS Supported) information
element. The test currently just receive a L3 compl Template and then
continue. This is implemented without an altstep. So lets have an altstep
with timeout here and make sure that the codecList information element is
always included.
However, since AoIP was specified after sccp-lite, we need to make sure
that for sccp-lite configurations, the Codec List is not included.
- Check L3 compl message using an alt-step
- Make sure codecList is always included (for AoIP)
Change-Id: Ia16a454e78421430ec32cc37939d429970cb06ec
Related: OS#3548
At the moment we use the default S0-S15 bits for the AMR config,
regardless what RSL_IE_Body mr_conf or osmo-bsc.cfg sets.
- Make sure consistant S0-S15 bits are used for AMR related tests.
This is a re-submit of change I794e6d4fe8abc67337428cbe0bcc8802fae37a6e,
which had to be reverted because the depending patch in osmo-bsc is not
yet merged into master. This caused TC_assignment_codec_amr_f and
TC_assignment_codec_amr_h to fail.
Change-Id: Ia98f18ba2c17c85ed01488734dc6df67f5b60d41
Depends: osmo-bsc: I2d8ded51b3eb4c003fe2da6f2d6f48d001b73737
Related: OS#3529
The change depends on another change in osmo-bsc, which
is not in master yet. Because of this TC_assignment_codec_amr_f
and TC_assignment_codec_amr_h are currently failing. So lets
revert this patch and re-submit it later.
See also: osmo-bsc change I2d8ded51b3eb4c003fe2da6f2d6f48d001b73737
This reverts commit 7f5609ad3e.
Change-Id: Ib16d14c723773ce67508c7e6028e594c15779506
Add f_gen_handover_req() like f_gen_ass_req(), to match AoIP or SCCPlite
requirements.
For incoming HO, MSC_ConnHdlr needs to know the SCCP addresses to expect the
incoming SCCP Connection from MSC to BSC. Add 'handover' section to
TestHdlrParams, and pass in the addresses from test_CT via that.
In osmo-bsc.cfg, add a remote neighbor config, so that the VTY command
'handover any to arfcn 123 bsic any' can trigger an outgoing inter-BSC HO.
Add various BSSMAP handover templates to BSSMAP_Templates.ttcn.
Add RR Ho Command template to L3_Templates.ttcn.
Move ts_BSSAP_Conn_Req() from msc/BSC_ConnectionHandler.ttcn to
library/BSSMAP_Emulation.ttcn, so we can also model an SCCP Connection Request
in BSC_Tests.ttcn (this time from MSC to BSC).
Add the two new tests to bsc/expected-results.xml.
Related: OS#2283
Change-Id: Id22852d4be7f127d827e7a8beeec55db27c07f03
At the moment we use the default S0-S15 bits for the AMR config,
regardless what RSL_IE_Body mr_conf or osmo-bsc.cfg sets.
- Make sure consistant S0-S15 bits are used for AMR related tests.
Change-Id: I794e6d4fe8abc67337428cbe0bcc8802fae37a6e
Enhance TC_classmark to also include the BSSMAP Classmark Request -> RR
Classmark Enquiry part. So far it was only testing the return path of RR
Classmark Change -> BSSMAP Classmark Update.
This test will thus fail with current osmo-bsc master, and will succeed as soon
as osmo-bsc If5db638fd6e8d9c2ef9e139e99f0fabe1ef16ddf is merged.
Add:
* ts_BSSMAP_ClassmarkRequest in BSSMAP_Templates.ttcn
* tr_RRM_CM_ENQUIRY in L3_Templates.ttcn
Change-Id: Idaab4d568cf986b4897ba008f6262c839d1592fb
When the altstep in f_establish_fully() gets an unexpected ASSIGNMENT
FAIL or COMPLETE it should stop completely like it is already
implemented in many other altsteps.
Change-Id: Ib4ac7bcbac35a4ae454d1806f3fbb727834d18b7
BSC_Tests: sprinkle logs to illustrate what the dyn PDCH tests expect.
BSC_Tests: tweak comment to mention that inter-BSC HO MT *does* allow N-CONNECT
from MSC.
f_tc_assignment_fr_a5_1_codec_missing: mark the missing IE beyond doubt.
Change-Id: I93c2914e766e200d89308cc81dd803e939b9b28c
Sometimes TC_chan_rel_hard_rlsd_ms_dead could fail because the Immediate
assignment command would arrive in the RSL queue after it was cleared in
f_expect_chan_rel. The alt statement would now never complete since the
Immediate Assignment was blocking/hogging the queue. Wait explicitly for
the IMM ASS in f_chreq_act_ack before continuing.
Change-Id: I2831d4caf7f045b3396d28a978328e8a1097d8d3
Sometimes (under heavy load and when the last paging cmd arrives near
the reset ack) some messages are not enqueued in the IPA_RSL port after
we have received the reset ack from BSSAP.
In the failures I have seen wireshark reports that no paging cmd arrived
after the reset ack, see jenkins job 285:
https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test/285/
Adding a sleep is always a bit crude, but since the paging cmd is
scheduled through TCP while the reset ack is sent through sctp I don't
see another way.
Running the test under load in a loop showed improvements where I was
not able to reproduce the failure with this patch.
Change-Id: Ib2d60e2c59baf98e437e078d844adcc6dbdbfcd8
Pass the CTRL_DETECT_CONNECTION_ESTABLISHMENT_RESULT parameter to
the TELNET port by default. This allows tests to make progress
into an error handling path if they are started while the osmo-*
program they want to connect on VTY is not running.
Observed with osmo-ggsn tests, where if the one test runs
into a VTY connection failure the subsequent test would get
stuck forever in a map() call on the VTY TELNET port.
Teach the function f_vty_wait_for_prompt() about connection
reports by the TELNET module. We may now receive an integer which
represents the socket file descriptor for the telnet connection.
This case was not handled by the previous change made in
commit cb111b21ab. As a result,
BSC tests started failing with "VTY Timeout for prompt" because
the alt-statement in f_vty_wait_for_prompt() would not progress
past the integer sitting on the VTY port's receive queue.
Change-Id: I56925f93af6c55e93f3f417099db135744da6a40
Related: OS#3149
With this patch, I see all ttcn3-bsc-tests failing with
"Verdict: fail reason: VTY Timeout for prompt"
This reverts commit cb111b21ab.
Change-Id: I215d7ab5eee75cf6d3afaac760af64356c943140
Pass the CTRL_DETECT_CONNECTION_ESTABLISHMENT_RESULT parameter to
the TELNET port by default. This allows tests to make progress
into an error handling path if they are started while the osmo-*
program they want to connect on VTY is not running.
Observed with osmo-ggsn tests, where if the one test runs
into a VTY connection failure the subsequent test would get
stuck forever in a map() call on the VTY TELNET port.
Change-Id: I9acf7793d5d68aec6d087cff254a10d8b673dab1
Related: OS#3149
It seems mtc.stop() alone does not really solve the race conditions when
shutting down components. The error happens when messages are sent on
ports which are no longer connected since the receiving component has
terminated.
Some web search
http://www.ttcn-3.org/TTCN3UCAsia2007/Presentations/TTCN3%20UC%202007%20Concurrent%20TTCN.pdf
suggested that one should stop all components before
calling mtc.stop (slide 38). Slide 33 also mentions the difference
between .stop and .kill. Kill removes the port connections while stop
does not. And I think looking at the logs when the testcase teminates
(through mtc.stop or otherwise) it is internally calling kill on all the
components. So hopefully stopping all components and then stopping the mtc
will fix this nasty issue.
I verified locally that the situation improves between commits now when
running BSC_Tests.TC_paging_imsi_nochan_all 20 times in a loop and
otherwise generating load on the system. It reliably failed before this
patch and I wasn't able to get it to fail with it.
Change-Id: I398883492919ceabcf94b5cc2361c63ec772d9d5
This test suite acts as an SCCP server on top of M3UA.
SCCP tests are run against the sccp_demo_user program which
can be found in libosmo-sccp/examples. This program must be
started in client mode: sccp_demo_user -c
The SCCP test suite should then work out of the box with
the provided SCCP_Tests.cfg file and this additional change
to sccp_demo_user default point codes:
https://gerrit.osmocom.org/#/c/libosmo-sccp/+/9652/
There is currently only one test, for the libosmo-sccp crash
reported as issue OS#2666. The implementation of this test
is currently using an ugly workaround due to shortcomings of
the M3UA Emulation layer (see source code comments). Whether
a better solution is feasible is still to be determined.
The test requires a patch to the SCCP Protocol Emulation which
has been submitted upstream: https://git.eclipse.org/r/#/c/124552/
Change-Id: I03f5e8b282a7396b45417495c88d8fb81b26cda8
Related: OS#2666
Call mtc.stop after setverdict(fail), add reasons to most failures and
fail with verdict error for internal errors.
Change-Id: I9b618235939fa41160b9be6677b121963d3ec857
The IPACC and MDCX interaction happens nearly in parallel to the
normal RSL connection that handles the handover, in particular the
channel relase from the old BTS may arrive in between IPACC and MGCP
operations.
- When the channel release arrives, check if MGCP and IPACC
operations are done (we have seen one MDCX on MGCP and an CRCX
plus an MDCX on IPACC level)
Change-Id: I207e9ece48ec53f872f82d981435cee7c2d0b094
Related: OS#3396
The function f_check_mgcp_expectations() checks the counters that
count the occurrence of MDCX and CRCX messages against computed
expected values. At the moment it is not easy to spot where exactly
the deviation occurred. Lets add some log output so that we can see
which type of message on which connection was missing or too much.
Also add a string parameter that is set to the calling functions
name so that we know from where the check has been triggered.
- Add more verbose log output for counters
- Add parameter to prepend to the log line
Change-Id: Ida0eba4ef3c1db977d392267ef76ec37b87133b3
Related: OS#3292
The function f_establish_f_establish_fully does not yet handle the
case where calls get switched locally. In those cases we expect to
see one additional MDCX before the BSSMAP ASSIGNMENT COMPLETE is
sent.
- Check exp_ass_cpl if the call is expected to be LCLS and expect
another MDCX for those cases.
Change-Id: I55fae5ab03980cd810ed7dc38208550686b1659e
Related: OS#3292
as_media handles the MGCP interaction for most of the tests. However,
it does not make sure if transactions are missing or if too many
transactions are performed (e.g. if an SCCP-Lite tests still creates
the connections pointing to the core network, even if they must not
created by the BSC in this case). So lets make sure that the MGCP
transactions are performed as expected by counting them.
- Add counters to count CRCX and MDCX transactions
- Check those counters after call establishment and handover
Change-Id: Ib073b097a840ca3a8ee99c4ed41f59f574191d98
Related: OS#3292
as_media() tests both, IPACC/RSL media handling and MGCP media
handling. These two domains are technically quite separate, which
means we can split them up into two separate altsteps in order
to increase readability of the code.
- Split as_media() into as_Media_ipacc() and as_Media_mgw()
Change-Id: I539e8ffdb9f99d5a8e730dd918df502614b9e84d
Related: OS#3292
since the local MGW may not support transcoding, osmo-bsc should
avoid to LCLS call legs that use different codec/rate. This test
attemts to set up a call with different codec rate and checks if
those legs do not get LCLSed
Change-Id: I91b132306e530ad9ca03fb4a34012381be6b0b52
Depends: osmo-bsc I157549129a40c64364dc126f67195759e5f1d60f
Related: OS#1602
At the moment LCLS is only tested using GSM-FR. There are not LCLS
tests that test with GSM-HR yet. Lets make GSM-HR available and see
what happens when we run BSC_Tests_LCLS.TC_lcls_gcr_bway_connect
on HR instead of FR.
- set channelType depending on g_pars.ass_codec_list.codecElements[0]
- add testcase TC_lcls_gcr_bway_connect_hr
Related OS#1602
Change-Id: I2421519a642bdb7453ae4a9058e177845690a489
The current osmo-bsc refactoring causes an erratic MR Config IE. This patch
ensures that the ttcn3-bsc-tests catch this error.
Add MR Config IE expectations to g_pars, set these in the two tests that expect
an MR Config IE in the Chan Activ message:
BSC_Tests.TC_assignment_codec_amr_{f,h}
All other tests now verify that there is *no* MR Config IE in RSL Chan Activ
messages -- all other tests request no voice or a non-AMR codec for Chan Activ.
Change-Id: Ie841feed9d5e478bab1fea2bb86f300e84799013
When leaving TS 6 in Osmocom style dyn TS mode, the initialization of the BTS
will cause a RSL Chan Activ, which the tests BSC_Tests.TC_early_conn_fail and
BSC_Tests.TC_late_conn_fail will interpret as the channel activation that they
expect to come from the Channel Request. They will hence issue the Conn Fail
message before the lchan is established, and are getting confused on what they
expect to happen.
Change-Id: I2bde987eefe7129c9f7c3b81b624d55cb66a75d0
The test currently use a hardcoded payload type and encoding name.
This does mean in practice that even when an assignment with EFR
is happeining. The MGCP responses to the BSC tell that the codec
is AMR. This is not correct. The testcases should always pick a
suitable payload type / encoding name in the MGCP response
- Add constants for IANA/3GPP assigned payload types
- Add function to lookup the right encoding name for a payload type
- Initalize the encoding name and payload type in g_media according
to the BSSAP PDU.
Change-Id: I2735267091059e2f2169da80bdcd30abc2b1554b
Realted: OS#2728
Until now, the test went from RR Handover Command directly to RR Handover
Complete, and osmo-bsc didn't mind it. However, the normal handover procedure
requires an RSL Handover Detect to be sent in-between those. Send that.
Change-Id: I6e54edcc3a99e116d852eca8e48c7a5bc685e832
The intention is to ignore RLL REL requests, and not to actually block the alt
statement in f_expect_chan_rel() if any RLL REL messages show up.
Change-Id: I3bbcdc41d186a3464cd4adb5c5b770bdec056993
Those test cases simulate a BTS-originated RLL CONN FAIL IND at
"unusual" time:
a) before we actually establish any RLL
b) after / while we're tearing down the RLL
This is triggering an osmo-bsc segfault, see OS#3182.
Change-Id: I324c410d7565c189dbc91df577d92b87c036732c
Related: OS#3182
There's a sequence of commands which was repeated over at least
four test cases. Let's factor this out into the new
f_exp_chan_rel_and_clear() function, and use that function from
all the former copy+pasted sections.
Change-Id: Ic6791fce4e8787e38b818a12ed526d3e47f313ef
PARALLEL | VERDICTOP will log when the port is dying or when other
components will change to fail. This helped to find a timeout in the
SGSN tests where a function call message timed out.
Change-Id: I770ac964dc37e2752e7d35e493f707b091c739b0
In this test case, the MSC performs a hard SCCP release of the
SCCP connection. This makes the BSC send a RLL REL REQ on the lchan,
but we simulate a broken/lost MS which doesn't respond to that.
Current OsmoBSC master will fail this test, and that's exactly why we
need it.
Change-Id: I800168499c2ab30af72625aba6fc740bc16e5653
Related: OS#3333
This test establishes an SDCCH for each iteration. However,
* due to OS#3333, osmo-bsc is currently not properly releasing those
lchan's,
* due to OS#3222, we furthermore don't allocate "larger" channels like TCH
and as a result on a combined CCCH system we only have 4 SDCCH, which
is less than the 8 that we try to use here.
Change-Id: I0f7fff54248a505387bdfe105259e8ad10ce6c77
Related: OS#3333
Related: OS#3332
For each of the SCCP/BSSMAP connections we create, let's make sure we
use a different RA and frame number, to make sure the test is more
realistic, and to aid any debugging.
Change-Id: I35540979c38d46f03702812e93742d7db772c533
While osmo-bsc was still affected of OS#3331, it would release the SCCP
connection from the BSC side. This is illegal as per 3GPP spec and
has meanwhile been fixed in osmo-bsc master. However, the testcase
BSC_Tests_LCLS.TC_lcls_connect_clear() relied on the broken behavior,
let's fix that.
The testcase now releases the SCCP connection from the simulated MSC
side in response to the BSSMAP Clear Complete from the BSC.
Change-Id: Ic3e1f8729a093b04941ec7ca72664d53adb21229
When f_ass_patch_lcls() was recently introduced during LCLS support
patches, we broke any testcases that *expected* an ASSIGNMENT FAIL
by overwriting the ASSIGNMENT FAIL with an ASSIGNMENT COMPL.
This patch fixes f_ass_patch_lcls() to only patch 'assignmentComplete'
members, if this assignmentComplete is actually chosen.
This fixes BSC_Tests.TC_assignment_fr_a5_1_codec_missing
Change-Id: I64fbf4cc3178a91913143960475a0d3758779ced
This is an early WIP, we actually will need to establish two calls/legs
before the BSC is able to locally correlate them.
Related: OS#1602
Change-Id: Ie6d0b9c38027abf65c7c564fc79b889d013fa6a7
In case we want to derive other component types by extending
MSC_ConnectionHandler, we will want to connect additional ports
before starting the component.
Hence, split the connect part into f_create_handler(), while keeping
the create + start part in f_start_handler().
Change-Id: If272816b7e720e8b8f000f7ab8baa20619b35fb7
Two paging tests were failing in Jenkins due to a configuration problem.
This has now been fixed so we can expect these two tests to pass:
TC_paging_imsi_nochan_lac
TC_paging_imsi_nochan_lai
Related: g#9361
Related: docker-playground 4147adabb9917fd852cc49c93603f379ec810c6b
Change-Id: I1a3dc5fb13385549bb9ec523271a5da5dc6aaa8c
The osmo-bsc.cfg file in docker-playground/ttcn3-bsc-test contains
codec, encryption, and ipaccess settings which were missing from
the corresponding configuration file in this repository. This caused
spurious test failures when running BSC_Tests outside of Jenkins.
Change-Id: If392dcd42fb741c7ab8ae204bbefde89f05f0afe
The helper function f_tc_ciph_mode_a5(), thich performs all of the
three tests currently disables the ASSIGNMENT COMMAND since due to
a bug in OsmoBSC a MODE MODIFY would be attempted by the BSC,
causing the testcase to fail.
The problem in OsmoBSC is now fixed and the ASSIGNMENT COMMAND can
be re-enabled again for this test. However, the test function
includes and expects an AoIP transport layer address, which is
not included for signalling assignments.
- Make sure no AoIP transport identifier is included in ths
ASSIGNMENT COMMAND
- Do not expect an AoIP transport identifier in the
ASSIGNMENT COMPLETE from the BSC
- Re-Enable the generation of the ASSIGNMENT COMMAND
Change-Id: Ib39d7dd2d1b3665570d7b287e431d10111316437
Closes: OS#2936
The helper function f_establish_fully() checks the channel type
for compatibility. If the channel type is compatible with the
desired mode a channel mode modification could be necessary if
the current channel mode is different from the desired channel
mode. However, this is not checked at the momemend. We just
blindly expect a MODE MODIFY message from the BSC and ignore
the cases where the current channel mode and the desired channel
mode already matches up. This is the case if only a signalling
channel is requested with f_establish_fully for example.
- Check if the channel mode of the current channel and the
desired channel mode match up.
- Make sure that the MODE MODIFY from the BSC is only
expected when the channel modes are different.
Note: The function f_channel_needs_modify() that is used
to determine if a channel modification is needed or not
does not cover all cases yet. (see fixme note)
Change-Id: I9004f299220b01ecea6b2316ba3f913c316947dc
Closes: OS#2762
Related: OS#2936
In non-handler mode, the SCCP emulation is currently started before
there's a user registered to SCCP_SP_PORT. If the first BSSMAP
package arrives from the network, then the SCCP_Emulation will crash
as it cannot deliver the resulting SCCP user primitive to the user.
Let's split start from initialization, so user code can still register
something to SCCP_SP_PORT before starting SCCP_Emulation.
Change-Id: I55c94f18531bb7e5369500dc90f4b0ff3a420774
In SCCPlite, the codec list is always missing, and that's the
successful situation, not a failure case. Let's run this test
only in AoIP scenarios.
Related: OS#2544
Change-Id: I01db7628c2b1c58419d544fc6fa311b9d9b59fb9
Of course a "CIC only" assignment will succeed in AoIP, so let's
invert the logic: Test "AoIP only" assignment in that case, and expect
it to fail.
Related: OS#2544
Change-Id: I3b8e5e6ec001f3cab6a00072ef0a7b97c13c278d
In classic non-AoIP-cases, OsmoBSC should simply return the
chosen speech version, but not any codec list in the BSSMAP ASSIGNMENT
COMPLETE message. Let's adjust the expectations accordingly.
Related: OS#2544
Change-Id: Id8e2a749bce91cfadd316bc2d56d1289412b9026
When sending BSSMAP Assignment Request, we need to decide if we want
to fill in the AoIP TransportIdentifier or the CIC. The former
is needed in AoIP, the latter is needed for SCCPlite and classic SCCP.
Related: OS#2544
Change-Id: I8aa0cf2189101de49a6da81625226bdcbbaff027
The existing encryption related test cases are all testing a case
involving the assignment procedure.
This patch adds some new testcases that test encryption without
any assignment, like e.g. in a typical LU.
Change-Id: I443cd8127e76f70fcaa7bf1638c2219524fa9381
Closes: OS#3183
If it's a pure signalling procedure (like LU), the MSC will never
even send a BSSMAP ASSIGNMENT CMD. Our test suite should be able
to produce this kind of behavior by passing "omit" as assignment
comamnd to the f_establish_fully() function.
Change-Id: I9bb5c8c19518905cf1ce121aa0b433886ec594d5
In addition to the existing 3GPP AoIP stacking, allow BSSAP to
run on top of a SCCPlite stacking. Implement both the server and the
client role for IPA.
Related: OS#2544
Change-Id: Ie844c4de62e0ef5d5c4c366185968211a7f6d676
Neels Hofmeyr
Harald Welte
Pau Espin
Vadim Yanitskiy
Philipp Maier
Daniel Willmann
Oliver Smith
Neels Hofmeyr