Since recenly, osmo-bts is using P_CON_INTERVAL=2 by default. This
means that the MS power loop gets triggered every 4th SACCH block
(1.92s), so we need more time to reach the maximim Tx power.
Change-Id: I9266f7284fcdb0afa3473f575640689e334e89a8
Related: osmo-bts.git I91c505447f68714239a4f033d4f06e91893df201
Related: OS#5517
The test case scenario can be summarized as follows:
1. Activate a logical channel for async handover.
1.a. Tune the MS side to that channel.
1.b. Make sure that no Downlink DCCH is received.
2. Send a handover Access Burst to the BTS.
2.a. Expect RR Physical Information to be received Ny1 times.
2.b. Expect no other data to be received on Downlink DCCH.
Currently the new test case fails for several reasons:
* osmo-bts-trx starts transmitting on DCCH before the handover
Access Burst is received, this is wong;
* trxcon immediately starts sending dummy frames on Uplink
DCCH, causing osmo-bts to stop sendig RR Physical Info.
Change-Id: I9469027ce88fb2750f1eceef2d8a56d4b8ee4d03
Related: SYS#5838
In TTCN-3 it's possible to call one altstep from another. This
allows us to build complex hierarchies of simple altsteps, where
one is built on top of the others. I call this altstep-oriented
programming. This change adds the following hierarchy:
* as_l1ctl_dl_msg() - triggers on receipt of a L1CTL DATA.ind
matching the given RSL chan_nr/link_id and data templates;
* as_dl_lapdm_dummy() - triggers on receipt of dummy LAPDm
func=UI frames with empty payload (repeats by default);
* as_dl_dcch_lapdm_ab() - triggers on receipt of a Downlink DCCH
containing a L2 payload that matches the given LAPDm frame;
* as_dl_dcch_pdu() - triggers on receipt of a LAPDm AB frame
with a L3 payload matching the given template.
All of these altsteps (except as_dl_lapdm_dummy()) expect an 'out'
parameter, which will hold the matched (and possibly decoded) data.
Example:
var PDU_ML3_NW_MS pdu;
alt {
[] as_dl_lapdm_dummy(); /* Ignore empty LAPDm func=UI frames */
[] as_dl_dcch_pdu(pdu, tr_CM_SERV_ACC) { setverdict(pass); }
[] as_dl_dcch_pdu(pdu, tr_CM_SERV_REJ) { setverdict(fail); }
[] as_dl_dcch_pdu(pdu, ?) { setverdict(inconc, "Unexpected PDU"); }
}
Change-Id: Ia4d502488cbb6bccc4d2656206ae6649bfa71007
Related: SYS#5838
Currently we execute both test cases on *all* available dedicated
channels from g_AllChannels[]. Given that SACCH is slow, and in
some cases we intentionally wait for a timeout of 3.0 seconds to
expire, the overall execution time is quite long. We have a risk
of the test execution being aborted due to the guard timeout.
I agree that using g_AllChannels[] makes sense for TC_ho_rach, which
tests handover RACH detection. There we want to be sure that detection
works on all slots of all DCCH types (especially when running a setup
with real MS/BTS hardware).
But for both TC_sacch_chan_act_ho_{sync,async} it's enough to run
on different channel types (see g_AllChanTypes[]), because what
we actually want to test is the Downlink SACCH operation.
Change-Id: Ic1937edd72ff842cb619e153d0f6a624ceb95281
Related: SYS#5838, OS#4008, OS#4009
According to 3GPP TS 48.058:
* 4.1.3 async handover: "If the MS Power IE is present the BTS
*may* start transmission also on the SACCH".
* 4.1.4 sync handover: "If only the MS Power IE is present the BTS
*may* start transmission also on the SACCH".
"May" does not mean "shall", so osmo-bts does not.
Change-Id: I5e97944e56b7860f2d912cd8d3c978a0f1e08645
Related: SYS#5838, OS#4008, OS#4009
TTCN-3 offers a very convinient way of matching an octetstring
against a record template (decoding target) on the fly, so that
there is no need to attempt decoding it manually beforehand.
This can be done by using the 'decmatch' keyword (see B.1.2.9).
Unfortunately, decmatch fails if an octetstring is longer than
the encoded variant of the decoding target (e.g. has padding).
Let's work this around by adding a 'padding' field, so during
decoding all remaining octets will be stored in it.
Change-Id: I0151adf7790127617f7cb57c9a9ec6c28721e95a
Related: SYS#5838
This eliminates the need for using log2str() and improves readability.
Change-Id: Iaf9b03fb81ec4fa2ca4f0a0b2f0b50491c6a9d80
Related: SYS#5838, OS#4008, OS#4009
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
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
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
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
Vadim Yanitskiy
Pau Espin
Neels Hofmeyr
Philipp Maier
Eric Wild