path: root/bsc
AgeCommit message (Collapse)AuthorFilesLines
6 daysbsc: clarify RESET logging: BSSMAP vs RANAP vs BSSMAP-LENeels Hofmeyr1-3/+3
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
7 daysbsc: mark test start in OsmoBSC's logging outputNeels Hofmeyr1-0/+2
Change-Id: I896a02403c9933323a9d7807a66be0afc4028d0f
7 daysbsc: implement initial LCS tests for OsmoBSCNeels Hofmeyr2-0/+549
Change-Id: Id3df9439752c088cff5618d21254af42365690ca
7 daysbsc: LCS: add mp_enable_lcs_testsNeels Hofmeyr1-8/+13
We want to switch off Lb iface for 'latest', etc Change-Id: Idf463c3c2169cad953b4ebc5b5845b31d5efb848
9 daysas_handover: fix for signalling channel, without MGCPNeels Hofmeyr1-3/+5
Change-Id: I276f82841c07f8a885ee0659002d4a41e5b180e4
9 daysf_perform_compl_l3: make receiving bssmap optionalNeels Hofmeyr1-26/+28
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
9 daysadd rsl arg to f_mo_l3_transceive, f_mt_l3_transceiveNeels Hofmeyr1-6/+8
Change-Id: I6c42418cc4dcc98573a78c3fd5d905ddf6dc3a87
9 daysbsc: connect PROC for BSSAP-LENeels Hofmeyr1-0/+1
Change-Id: Id787ed6e36f6f6e96658cd74b8aaa17cc57ec1e0
9 daysbsc: fix SMLC point codeNeels Hofmeyr1-1/+1
Change-Id: Icfd1d564f20d9229c5b17c94dda3b7177787079a
9 daysbsc: Add Lb interface supportHarald Welte3-2/+55
This introduces the Lb interface stack, which allows BSC_Tests.ttcn to emulate a SMLC towards the BSC. In accordance with we use 0.23.6 as point code for emulating the SMLC. Change-Id: Id41246f0dd812f7ddee9d920bfd07a4e3aac3504
9 daysbsc: fix missing vty exit in f_vty_allow_emerg_bts()Neels Hofmeyr1-0/+1
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
11 daysbsc: Fix random failures in BSC_Tests.TC_early_conn_failHarald Welte1-1/+1
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
14 daysBSC_Tests: fix f_mo_l3_transceive(): relax DLCI matchingVadim Yanitskiy1-1/+1
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
2020-10-03BSC_Tests: introduce TC_tch_dlci_link_id_sapi for OS#3716Vadim Yanitskiy2-0/+60
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
2020-10-03BSC_Tests: introduce f_mt_l3_transceive() sending BSSAP -> RSLVadim Yanitskiy1-0/+17
Change-Id: I5f1685815a4477b4d50351d3518ae21dd7d20139 Related: OS#3716
2020-10-03BSC_Tests: parametrize f_mo_l3_transceive()Vadim Yanitskiy1-6/+7
Change-Id: I617a103e9dae8f16e3f3996c89e53ace49f7bfa8 Related: OS#3716
2020-10-03BSC_Tests: s/f_verify_active_layer3/f_mo_l3_transceive/gVadim Yanitskiy1-3/+3
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
2020-10-01update expected resultsNeels Hofmeyr1-70/+61
Change-Id: Icb534a2b00fc48c3ead009a620e6061e595cb581
2020-10-01bsc: undup f_verify_active_layer3()Neels Hofmeyr1-30/+21
Change-Id: Ia4433618787b58f8789c9e97cdfbb8b320a09395
2020-10-01bsc: f_logp(): add VTY pt so it works on various componentsNeels Hofmeyr1-11/+11
So far only worked on test_CT, now also on MSC_ConnHdlr by passing the respective BSCVTY. Change-Id: I85ad0a59af72aa72e26a1252f946ada43388dc17
2020-09-29MSC_ConnectionHandler: allow to use IPV4 as defaultPhilipp Maier2-3/+15
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
2020-09-25bsc: Call f_shutdown_helper() on all tests missing itPau Espin Pedrol1-53/+145
This should hopefully avoid sporadic errors during tear down of tests such as TC_si_acc_rotate. Change-Id: I8c8a1061b546576b7a5c4b11f20dfc887aaab6e0
2020-09-25cosmetic: bsc: Fix indentation alignmentPau Espin Pedrol1-28/+28
Change-Id: I5484784fca254044055a9f131e1ebb19de8ceba5
2020-09-23bsc: Check attempted/successful channel requestsDaniel Willmann1-0/+2
Change-Id: I5b5c7c72eea28314da2ee7725d94d85917aa3ad3 Related: SYS#4877
2020-09-20MSC_ConnectionHandler: do not allow as_Media_mgw to exitPhilipp Maier1-1/+1
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
2020-09-18bsc: Rework CBSP tests to support testing IPv6Pau Espin Pedrol1-43/+143
Change-Id: I859edebd24634ec9b448cd114f5541c93e552b0b
2020-09-14BSC_Tests/hopping: also verify handling of ARFCN 0 in MAVadim Yanitskiy1-3/+13
According to 3GPP TS 44.018, table "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
2020-09-14BSC_Tests/hopping: fix: consider ARFCN of the transceiver itselfVadim Yanitskiy1-2/+13
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
2020-09-14BSC_Tests/hopping: turn FHParamsTrx into a record, add ARFCN fieldVadim Yanitskiy1-26/+29
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
2020-09-14BSC_Tests/hopping: fix ArfcnList: use GsmArfcn instead of integerVadim Yanitskiy1-1/+1
Change-Id: I63adf2ffaaf789a97d29ec5c1b7b7a551e56769c Related: SYS#4868, OS#4545
2020-09-13BSC_Tests: set verdict to pass when TC_emerg_premption is donePhilipp Maier1-0/+2
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
2020-09-11BSC_Tests: check for the same measurement bandwidth as in SI2quater on ↵Alexander Couzens1-1/+2
Channel Release 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
2020-09-11BSC_Tests: fix whitespace typoAlexander Couzens1-1/+1
Change-Id: I68d7b6ef1d35b798f66a04bce4de29fdd75ff7f1
2020-09-09bsc: Fix race condition waiting for RESET-ACKPau Espin Pedrol1-1/+12
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
2020-09-09bsc: Introduce test TC_assignment_aoip_tla_v6 and TC_ho_into_this_bsc_tla_v6Pau Espin Pedrol2-12/+63
Change-Id: Iba24fae66c80b64bf81bbfd616294af757e5dca3
2020-09-07BSC_Tests/hopping: add TC_fh_params_handover_cmdVadim Yanitskiy1-0/+101
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
2020-09-07BSC_Tests/hopping: call f_shutdown_helper() in all TC_fh_params_*Vadim Yanitskiy1-4/+4
Change-Id: I84d35bc6c50fb7404918b43022819713f3e86d37
2020-09-07BSC_Tests/hopping: fix: do not reduce Mobile Allocation bit-maskVadim Yanitskiy1-4/+1
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 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
2020-09-07BSC_Tests/hopping: fixup TC_fh_params_si4_cbch: bring CBCH backVadim Yanitskiy1-2/+2
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
2020-09-02BSC_Tests/hopping: make f_vty_{handover,ss_action}() more flexibleVadim Yanitskiy1-8/+10
Make it possible to call them from a testcase / function running on any kind of component, not only on MSC_ConnHdlr. Change-Id: Ifbcc24c5a0299ba43a998ccbdd0f77bc109c6935
2020-09-02BSC_Tests/hopping: fix bit-mask reduction in f_TC_fh_params_gen_tr_ma()Vadim Yanitskiy1-1/+1
Change-Id: Id8b1e9fb62f9deaa5517d7366271437af0fc6eef Related: SYS#4868, OS#4545
2020-09-02BSC_Tests/hopping: fix error message in TC_fh_params_assignment_cmdVadim Yanitskiy1-1/+1
Change-Id: I6ccee0296e3f5ae13086b8e68c1709e386f59e97
2020-09-01BSC_Tests/hopping: add TC_fh_params_si4_cbchVadim Yanitskiy1-0/+80
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, if CBCH is active in the cell, the CBCH Channel Description IE indicates where to find it (physical channel description). According to section, 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
2020-09-01BSC_Tests/hopping: add TC_fh_params_assignment_cmdVadim Yanitskiy1-0/+80
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
2020-09-01BSC_Tests/hopping: add TC_fh_params_{chan_activ,imm_ass}Vadim Yanitskiy1-0/+274
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
2020-08-31bsc: verify handover rate countersNeels Hofmeyr1-43/+406
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
2020-08-31Revert "bsc: Add Lb interface support"Harald Welte3-55/+2
This reverts commit c47fdb2e52c98f81a3b708dcaeaf131096fe912c - as osmo-bsc currently doesn't yet have a Lb interface, we shouldn't try to test it yet. Change-Id: I7898dd336cbef27553d97857ac22f1a539da1380
2020-08-30bsc: Add Lb interface supportHarald Welte3-2/+55
This introduces the Lb interface stack, which allows BSC_Tests.ttcn to emulate a SMLC towards the BSC. In accordance with we use 0.23.6 as point code for emulating the SMLC. Change-Id: I854618cc08de1a716784f52542a4df3c7f7ad900
2020-08-29BSC CBSP: apply changes to 'cbc' vty section, switch server<->client modesNeels Hofmeyr2-5/+23
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
2020-08-29BSC_Tests: add TC_rll_{rel_ind,err_ind,timeout}_sapi_n_rejectVadim Yanitskiy1-0/+116
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