It's better if we run ttcn3-bts-test with the default values, given
that they were significantly reduced some time ago.
Change-Id: Id97e848e5dfd0b6c504d06f62642511cfd5a0f66
Related: I7da3d0948f38e12342fb714b29f8edc5e9d0933d (osmo-bts)
Related: OS#4487
The first interference report may contain unreliable values, so we
ignore it and start the actual matching only after receiving it.
Change-Id: I44b0db6675ecf740fba7ad2a6882f86da018febf
Related: SYS#5313
Starting from [1] osmo-bts does average the interference levels as
defined by the Intave parameter before reporting over the PCUIF.
In TC_pcu_interf_ind we expect to receive an interference report
every 480ms (one SACCH period), so let's the Intave to 1.
[1] osmo-bts.git I3fbaad5dbc3bbd305b3ad4cb4bfb431a42cfbffc
Change-Id: I070b195af8c62454edd8de961cce6be2c120ae48
Related: SYS#5313
Otherwise they fail, because BS power control is normally not
permitted on the BCCH carrier (unless it's in power saving mode).
Change-Id: Ied3e38986690850f0323d4db072cf59b6975587e
Related: SYS#4918
Given that the test suite acts as the BSC, it's known in advance
which exact logical channel is going to be activated. Therefore,
it's not necessary to send an Immediate Assignment with the known
Channel Description IE over the Um interface (via L1CTL).
On the other hand, we may still want to validate the process of
dedicated channel establishment, involving the use of Immediate
Assignment procedure. So instead of doing this every time when
a ConnHdlr component needs to activate a logical channel, let's
split the existing logic into a separate test case - TC_est_dchan.
This change facilitates the goal of running test cases against
additional transceivers (not only against C0). Currently this
is not possible, because a ConnHdlr component has no access to
C0/AGCH when executed on Cx > 0.
Change-Id: I8df3db36f35190241735629a961f09d73bd0e5f5
The idea behind these test cases is to make sure that osmo-bts
does send RSL MEASurement RESult messages regardless of what
was received on SACCH: RR Measurement Report or SAPI=3 data.
Change-Id: I7d17d6e5f413f2de78db944f23ad731b81ad24cf
Set the executable name in each regen_makefile.sh explicitly with -e,
instead of having it set indirectly from the first .ttcn file. Make it
consistent by placing the name on top of each of these files.
Fix for warning:
ttcn3_makefilegen: warning: File `BSC_Tests.ttcn' was given more than once for the Makefile.
Related: OS#5252
Change-Id: I5ed03f8f3ed905483620dc7bae33b617bbb8507f
Make all regen_makefile.sh more readable and diff friendly by moving
each entry in FILES and CPPFLAGS_TTCN3 into separate lines. Order
entries alphabetically.
Related: OS#5252
Change-Id: I6b6866eb9f6ec6232e4ae434517457a4c8c1c050
Since recently, osmo-bts may not be restarting after each test. Which
means the supp-meas-info is not reset when test starts. Hence, some of
these tests started failing because a previous test set a value
different than the default one.
Change-Id: Iaa16b33781a8f490fc1cdbafda407755371dbe7f
These test cases can potentially break the IUT or cause weird/unexpected
behavior. Ensure that they are executed last, not affecting the others.
Change-Id: I167a9e6eb2e3fe1d9c73994c428d8419074d96c3
Fixes: I3b602ac9dbe0ab3e80eb30de573c9b48a79872d8
Related: OS#5245
New versions of osmo-pcu support Neighbor Address Resolution over this
interface, and deprecated the old CTRL interface.
Let's use it by default while still keeping support for the old one for
a while to avoid breakage of existing deployments.
Tests run to validate:
* Old osmo-pcu still passes tests using CTRL interface
* New osmo-pcu (with new iface support) still passes tests using CTRL
interface
* New osmo-pcu (with new iface support) passes tests using new iface
Related: SYS#4971
Change-Id: I05f1aabc64fc5bc4740b0d8afd8990b485eacd50
This way functions like f_inet_addr() and f_inet6_addr() can be
used directly without converting between bytes and integers.
Change-Id: I389a8cb95c025c9dddc751789223621c15d9b48f
The current paging load tests only test what happens when the paging
load is introduced from the PS side. However there are no tests that
tests what happens when PS pagings are introduced from the PCU side
into an already overloaded system.
osmo-bts was equipped recently with a mechanism that detects congestive
situations. Once a congestion is detcted osmo-bts will drop pagings from
the BTS side. The rationale of the new testcase is that the behavior
must not change when the PS pagings start since osmo-bts is dropping
them.
Change-Id: Ie72e788d9ebff6ca4e50314746127a9689948062
Depends: osmo-bts I30f97672d7a0c369c4a656e878ab8cbbd83e31ea
Related: SYS#5306
Sometimes, VAMOS related test cases fail due to a DTE:
Dynamic test case error: Sending data on the connection of port
CCHAN_PT to 1:RSL_CCHAN failed. (Broken pipe)
Call f_shutdown() to ensure that all components are properly
terminated, so there will be no race conditions like this.
Change-Id: I690412a29b24571109415d32b09543de459076d1
Related: SYS#4895
Since recently, we do have NOPE indications in the virtual Um
environment. Somehow this broke test cases for the MS power
control. Releasing the channel makes everything work again.
Change-Id: I6a204bbecfe116aa302eae28ff24d6bb899fa8b7
Related: SYS#5313, OS#1569, OS#1866
Recent changes [1] to osmo-bts make it periodically send the
RF RESource INDication messages for each transceiver over the
A-bis/RSL. These messages block the queue of 'RSL_CCHAN' port
and make the paging related test cases fail. Ignore them.
Change-Id: I18b879235c6eefb2dd89a3f4502b0830efeac6bb
Related: [1] Id80fdbef087de625149755165c025c0a9563dc85
Related: SYS#5313, OS#1569
Unfortunately, trxcon does not support handling more than one
connection in parallel. If there is already one connection
established, it would reject all other connection attempts.
This causes an error in f_handler_init(). As a quick hack,
let's allow running BTS_Tests.ConnHdlr components without
establishing L1CTL connections at all.
Change-Id: I72bcaed6c3803a0e18c9b787036a441e30c220cc
Related: SYS#4895, OS#4941
The expectations of this test case were wrong. The IUT would first
accept() an additional connection and then close() it immediately.
Since there may be other messages, like TIME.ind and DATA.ind, the
'alt' statement would not match successful connection result, and
instead would unblock the flow due to timeout.
The titan.TestPorts.UNIX_DOMAIN_SOCKETasp had to be changed [1] to
send UD_connect_result with ERROR if recv() returns zero or a negative.
[1] https://github.com/eclipse/titan.TestPorts.UNIX_DOMAIN_SOCKETasp/pull/4
Change-Id: I898b8b14515d79766b12d652ebb1ddf834e2863c
This commit fixes a regression introduced in [1]
Change-Id: I107039f1ff44ae8c41d690f5f293ed136c17586b
Fixes: [1] Ia9f366ca1fdad700a90ca3367e43523f7bac39a1
The PCUIF connection involves a lot of frequent messages, such as
the TIME.ind and since recently DATA.ind with len=0. As a result,
the test suite logs are getting unreadable due to lots of coding
warnings and port queueing notifications.
This change is aimed to improve the situation a bit, by establishing
the PCUIF connection only for those test cases which actually use it.
Side effects:
* TC_pcu_socket_verify_info_ind becomes reliable, because the
PCUIF establishment is done after the RSL bootstrapping;
* TC_pcu_socket_connect_multi starts to fail, because it used
to pass due to timeout, since not all messages are handled
in the 'alt' statement.
Change-Id: I09ccb65ce94a41ffdad4e93da650c3f32d422af4
Related: OS#5083
Vadim Yanitskiy
Oliver Smith
Pau Espin
Neels Hofmeyr
Philipp Maier
Eric Wild