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