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
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
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
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
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
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
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
* 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
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
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
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 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
Pau Espin
Daniel Willmann
Vadim Yanitskiy
Philipp Maier
Alexander Couzens
Harald Welte
Oliver Smith