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
Whenever the BSC is updating SI1, SI3 or SI13 via RSL, the PCU should be
informed about the change via PCUIF as well. For SI13 this is already
the case and a testcase exists. The PCUIF protocol is
now capable to update SI1 and SI3 as well.
- Update BTS_Tests.TC_pcu_ver_si13 so that it works with the current
protocol version
- Add BTS_Tests.TC_pcu_ver_si3 and BTS_Tests.TC_pcu_ver_si1 that test
SI1 and SI3 as well.
Depends: osmo-bts Ib7aeb41e634ad6fcab3766a4667b0267c749436a
Change-Id: I5138ab183793e7eee4dc494318d984e9f1f56932
Related: SYS#5103
Currently osmo-bts seems to be sending IPA RSL Connect ACK
unconditionally, even if the remote peer is not reachable.
Change-Id: Ibfa58f670401907801f610578dd9b4ebf155a83a
According to 3GPP TS 48.058 4.1.4, SACCH may be transmitted also for only MS
Power present, and no Access Delay.
Change-Id: I2e1c0ecc9de65a019aaa9f08bb051bf051156172
In some cases GsmArfcn itself is not enough. It case of L1CTL
and GSMTAP, it needs to be equipped with a band discriminator:
- DCS / PCS (as the numbers may overlap),
- Downlink / Uplink (not yet there).
Let's rename this record and move it to GSM_Types. Also, add
send / receive tamplates, so we can add new fields later.
Change-Id: I7a63f03bbd15a06caafb786122dc12991d115771
It will be easier to use this list / array in non-L1CTL specific
records and templates, e.g. in (RR) Immediate Assignment.
Change-Id: I392299eea9a82168f893a72d06872c280b6fbdce
Pau Espin
Vadim Yanitskiy
Philipp Maier
Eric Wild
Alexander Couzens