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
Neels Hofmeyr
Harald Welte
Vadim Yanitskiy
Philipp Maier
Pau Espin
Daniel Willmann