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
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
Vadim Yanitskiy
Oliver Smith
Pau Espin
Neels Hofmeyr
Philipp Maier