The idea of this test case (as can bee seen from its name) is to
verify handover RACH detection. What we basically do is:
1. Activate a logical channel on the BTS side (HO_SYNC for now);
2. Switch the MS (e.g. trxcon) to that channel without waiting
for Immediate Assignment and sending Access Burst;
3. Send an Access Burst on that channel using RA = HO_REF;
4. Wait for RSL HANDOver DETected from the BTS;
5. Release a dedicated connection.
There is no way to verify if the Handover Reference received
from the MS matches the one that was sent to the BTS. We can
introduce a separate test case that would just send an Access
Burst with RA != HO_REF.
Change-Id: If2e8d9c9947823df62f4bcc9a7fcd20734ff7858
Depends on: (trxcon) Ia967820a536c99966ba2c60b63d2ea9edb093f46
In BTS_Tests.ttcn we used to compose L1ctlDataReq manually. This
can be done by ts_L1CTL_DATA_REQ_SACCH() template itself, so
let's abstract BTS_Tests.ttcn from doing that.
Change-Id: I1ae948bd0314cdf15c21ce4b6346d5e32f1fcf95
ttcn3-bsc-test-latest currently fails on most tests because it tries to
use "osmux off" VTY param and only current osmo-msc master supports
it.
Change-Id: I53d58b2d905905ebf1df322d0389b3715a48212f
Initially it was thought safe to only enable it since the osmux test was
at the end, but actually IU tests run after it, and those don't expect
osmux to be enabled.
This way we also always match osmo-msc osmux state with whatever the
test expects (and sets through f_init()).
Change-Id: I8fb48af7d37f1a2391a39c19f5ec5064cd5869d2
If a LAPDm message is shorter than the MAC block size, we must pad
it before seding it to L1. trxcon e.g. would ignore any frames with
the wrong length since Change-Id I258ee9f6d0124b183b1db23a73f1e523fcea89a8
Change-Id: I30bcce27f95974eaca4168a156d1548586c924d6
Related: OS#3415
When no PCU is connected to the BTS, the BTS should mask the GPRS
indicator from the SI3 rest octets to indicate "no GPRS support"
in the cell. This will cause phones not even trying to send us
RACH requests for GPRS ATTACH, RAU, etc.
Change-Id: I37efb712ee0c513aea230beeb35e7dabce698a34
Related: OS#4023
Related: OS#3075
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
In the existing TC_pcu_* test cases we use L1CTL_DATA_* messages
to send / receive (E)GPRS related MAC-blocks. The length of such
blocks can be greater than 23 octets (i.e. fixed MAC-block
length in GSM), up to 162 octets to be precise.
Change-Id: Iced78796882b757016d02a266d55bc2a98b62a3d
This test will currently fail due to a MODE MODIFY NACK, even though the
channel mode is not modified.
Related: OS##3750
Change-Id: I4cbea499bb6a331d314e6573548a4540945208b5
When executing the test on our build slaves, we ran into the following:
> Number of TDMA Frames (1100) not matching (1073 .. 1093)
> Number of TDMA Frames (1096) not matching (1073 .. 1093)
So it seems the tolerance was a bit too tight. If the timer runs
for a bit more than the requested amount of seconds (e.g. due to
high system load), the number of TDMA frames is likely a bit higher
and hence we need to permit a larger tolerance.
Change-Id: Ib00bb7e7f223fb0329d00e3835127b8c31299e27
This adds TC_pcu_socket_connect_multi, which verifies that a second
connection to the PCU Intrerface socket is denied while the first
connection is still established.
Change-Id: Ib484a0a39e719cb2ce00a9464fc1207357ec9e93
Related: OS#4023
Bring our TTCN-3 view of how RSL channel numbers are defined in sync
with that of our other implementations (BTS, libosmocore, trxcon, ...)
Change-Id: I48908058ac2501a3b5ae7c74e4e8527cbaee1b01
Related: OS#4027
In OsmocomBB/trxcon Change-Id Ia94ebf22a2ec439dfe1f31d703b832ae57b48ef2
we introduced a new mode CCCH_MODE_COMBINED_CBCH to indicate that the
channel combination is a CCCH+SDCCH/4 with one SDCCH stolen for CBCH.
Let's make sure we actually use that mode in our CBCH related tests
Change-Id: I27ee2c81bec7175c1ea09d4f3f6037f2866fe242
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
This test opens a SDCCH and sends a RR SUSPEND message from the
simulated MS. It then expects the BTS to pick that up and forward
it to the PCU socket rather than via RSL to the BSC.
Change-Id: I4da6e9d7c5dfbd0e017d2a63c6474da700c38e52
Related: OS#2249
Related: OS#4023
The four existing test in BTS_Tests.ttcn so far didn't have any chance
to verify if the invalid messages actually ended up on the air interface
or not. By using virtphy instead of trxcon, we can finally add that missing part.
Change-Id: Ie05d6b1530bd4d4cf4eaa574b068870682439ee4
Related: OS#4023
As trxcon+fake_trx don't have GPRS (TBF) support yet, we cannot do
any PCU related tests involving the Um interface yet. Instead, let's
use virtphy to fill that gap. Using virtphy, we can actually
receive/transmit GPRS blocks on the simulated Um interface.
TC_pcu_data_req_{pdtch,ptcch} are moved to a new test suite
"BTS_Tests_virtphy.ttcn" which should symbolize that the related tests
are to be executed with osmo-bts-virtual + virtphy instead of
osmo-bts-trx + fake_trx + trxcon.
You also have to set the following module parameter to make this work:
BTS_Tests.mp_bts_trxc_port := -1
Related: OS#4023
Change-Id: I677f660b1076148b3317b08b06eb3d6551d9b577
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
This new test verifies that the expected amount of PCUIF_RTS_REQ are
observed on the PCU Interface for both PTCCH and PDTCH.
Change-Id: Ic27cdd4f4adf11f871b84bd72692a03280274fe2
Related: OS#4023
As we don't yet speak OML directly from the TTCN3 test suite,
this requires a currently "RFC/WIP" state patch turning OML
Failure Event Reports into CTRL TRAP on the BSC, see
https://gerrit.osmocom.org/#/c/osmo-bsc/+/14177
Change-Id: I6c7641b37b6ee2177d43127140cc0b625409379c
Depends: osmo-bsc I4f8a9737c6ef1b951ea8e742cdbd3689371a99d5
Related: OS#4023
Add three BTS_Tests.ttcn test cases for verifying the BTS behavior
regarding CCCH LOAD IND (RACH).
Related: OS#3750
Change-Id: I6c9dee1d7d3eaa218fdce7ebb8e334858aedb736
After new fields (osmux osmocom extensions) were added to BSSMAP Reset
and BSSMAP AssignReq/AssignCompl in titan.ProtocolModules.BSSMAP, we
need to set them in ts_* templates, otherwise TTCN3 runtimes fails with:
"""
BSC_Tests.ttcn:143 Dynamic test case error: Performing a valueof or send
operation on a non-specific template of type @BSSAP_Types.BSSMAP_IE_Osmo_OsmuxSupport.
"""
Fixes: fe0c6083bd
Depends: titan.ProtocolModules.BSSMAP Iaf1e137269c0da20b2c96fd104b57edf336693af
Change-Id: I568100376cf8a47c01a33bada97bf8eaa7c07fcd
This adds TC_sms_cb_cmd_sdcch{4,8]_default_and_normal() which test
the correct behavior in case of a DEFAULT SMSCB and normal one-shot
SMSCBs.
Change-Id: I0782b121cd69158903b09f935b298ddbf5a9ffb5
Related: OS#4011
The existing code structure could only test for normal messages with a
NULL default, but didn't handle situations where normal and/or schedule
messages were superimposed on top of DEFAULT messages.
Also, prepare the infrastructure for testing both CBCH BASIC and CBCH
EXTENDED.
No new tests are introduced, the code should behave identical before
and after this patch.
Change-Id: I144c7d833b79c648b1ac69a6155f3603025ede5c
Related: OS#4011
Add a new testcase TC_sms_cb_cmd_sdcch4_default_then_null() which first
installes a DEFAULT message, verifies that, then removes the default
message and verifies only NULL CBCH blocks are sent anymore.
Change-Id: I9608d42a164a6210f100d10cb3ccfb7735975011
Related: OS#4011