In this testsuite, we simulate BTS and CBC by attaching to RSL and CBSP
protocol interfaces of the BSC. We then issue a variety of CBSP
commands to the BSC and check for corresponding action on both the BTS-
facing RSL as well as responses on the CBSP side.
Change-Id: Ia6ffac181f50586d06d2f29bca1c57285179e861
osmo-bts does currently not use the signaled lchan BS power level, nor
does it update the BS power IE returned in the measurement results.
Change-Id: If91fb57b4070c60bb277d0b55d69ee3dde47ee48
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
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
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
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
According to 3GPP Ts 48.058, every logical channel can receive some
specific SACCH filling at the time of RSL channel activation. This
overrides the global SACCH FILLING.
Related: OS#3750
Change-Id: I8adb371a7e0b80792dd2fa35e5204802068df5ba
Usually the MS power is controlled by the BTS and there is no continous
supervison by the BSC needed. However, a scheme where the BSC takes care
of the power control loop exists. The power is then set via RSL using an
RSL MS POWER CONTROL message.
This tests establishes a dchan and then sends MS POWER CONTROL messages
with differen power levels and then checks the presence of the power
level set in the MS POWER LEVEL field of the SACCH L1 header.
Change-Id: I82b04a3bf94d355175f7f6ff3fdc43672e8080a2
Related: OS#1622
This is quite useful when one needs to expect an RSL UNITDATA
message with any payload. Let's set 'l3_info' to '?' by default,
like it's already done for 'ts_RSL_DATA_*'.
Change-Id: I45260343b34d8d054e7efa72de11dd4cb510a8cc
The 'tr_RSL_UNITDATA_IND' is a 'response' template, so there
is no reason to restrict 'link_id' to any obvious value.
Change-Id: I29ac0a2828b565baa1d2f3ac0a922bc441378f94
Add tests TC_tch_sign_l2_fill_frame and TC_tch_sign_l2_fill_frame_dtxd.
TC_tch_sign_l2_fill_frame is already passing and verifies that fill
frames are sent if there is nothing else to transmit on a SDCCH4/SDCCH8,
TCH/H, or TCH/F signalling channel where DTX is disabled for downlink.
TC_tch_sign_l2_fill_frame_dtxd is currently failing. It verifies that
only specific fill frames are sent, as required by GSM 05.08 for TCHF
signalling channels with DTX enabled for downlink. At present, our
implementation generates no fill frames in this case, which is one
piece of the problem described in issue OS#1950.
Change-Id: Id4e0de6e78b62cd408f600a57a28617d91da64af
Related: OS#1950
In osmo-bts Change-Id Iea4a4781481f77c6163d82dcd71a844a5be87bf2
we introduce an Osmocom specific "supplementary measurement info IE"
into the RSL MEAS REP message. This commit adds the related type
definitions and extends the related matching in BTS_Tests.ttcn.
Change-Id: I5d1114c73508c67ad7cd9864d7370367612b1241
Until now, the test went from RR Handover Command directly to RR Handover
Complete, and osmo-bsc didn't mind it. However, the normal handover procedure
requires an RSL Handover Detect to be sent in-between those. Send that.
Change-Id: I6e54edcc3a99e116d852eca8e48c7a5bc685e832
The existing test simply sent 1000 messages via RSL without checking
what actually arrived on the radio interface, or without
expecting/counting any RSL DELETE IND.
Let's fix this by introducing test sending IMM.ASS at three different
rates, with related expectations in terms of nubmer of IMM.ASS arriving
on Um vs. RSL DELETE IND arriving at BSC.
Change-Id: Ib6043b76ba1d7aaff107bb612f63b5a747d8720c
Related: OS#2990
Related: SYS#2695
This adds a series of test cases to BTS_Tests.ttcn implementing testing
of the RLL sub-layr of RSL, i.e. the translation between LAPDm frames
on the Um interface and the RLL frames on the Abis side (and vice vrsa).
Related: OS#3174
Change-Id: I336378de6106e5369600cbb49e0c47cc59864630
This adds a set of four new testcases relted to dynamic PDCH switching:
One successful and one unsuccessful for each Osmo + IPA style dynamic
PDCH.
Closes: OS#3099
Change-Id: I7a7a937548a35461d86e93ead79c39a37a59563e
The MDISC_IPACCESS is only used for the media (CRCX/MDCX/DLCX) related
commands, not for the PDCH activation/deactivation. The latter uses
normal MDISC_DCHAN.
Also, add the inverse templates for PDCH actiation/deactivation, so we
now have both receive and transmit template for each of the 6 related
messages (activation, deactivation, plus each their ACK + NACK).
Change-Id: I170a90391859d71e1f96a72205487cccba5b6ae7
The way how TTCN-3 templates work it's not possible for us to have
a parametric template for both generating DLCX with conn_id and without :(
Change-Id: Icb772ca5b9661ab39b1c161fa4ebc70544275d8f
The way how TTCN-3 templates work we cannot use a template parameter
to decide if we want to match only on messages that contain a matching
RTP_PT2, or (alternatively) on any messages whether or not they have
a RTP_PT2 IE at all :(
Change-Id: I7a4f5d7e1d44994316717da5b769e278ea188b12
We're testing at 80% and 200% of PCH capacity, both for either IMSI-only
or TMSI-only paging requests. The way how we test ensures:
* the expected number of paged mobile identities end up on the Um interface
* we implicitly check the queuing limit of 200 paging records by
overflowing it in the 20-seconds-of-200%-load cases
* we implicitly check the batching of mobile identities into different
paging types
* we test the PCH load reporting over RSL
As a side note, in case you were ever wondering what's the expected
paging throughput / capacity, there are now helper functions to compute
it. For our combined CCCH/SDCCH4, it's about 16 IMSIs per second or
about 32 TMSIs per second.
Change-Id: I0b80b72bdab3d80d915296d70e1174623fbd8610
This is a template that goes beyond the 3GPP specs, as it expects
presence of certain optional IEs which we know are always present
in the OsmoBTS case.
Change-Id: Ibf37565ab4fe70515b598a2757953628aa780241
So far, the RSL templates have been used for BSC testing, i.e.
TTCN3 behaving like a BTS. Now we want to test the BTS, so we
have to "invert" the receive/send direction and hence also need
the inverse templates.
This doesn't add *all* of them, but a sufficiently large number for our
first testcases against OsmoBTS.
Change-Id: Ica9cfae5a691e4d967d046b04e5bb16a71a89adf
There are quite a number of non-transparent RLL messages, such as
RLL_RELEASE_REQ. Make sure we match those as intended.
Change-Id: I30260a57fc01613450e6ac66e0af97c29041b4fa
Let's verify the operation of the CIPHERING MODE COMMAND as issued
by MSC, performed by BSC and implemented by simulated BTS/MS.
Change-Id: Ibc06bd2177c63837a794a0ca1f54ebef17499e78
They all are related to a dedicated channel and carry a channel number
as first information element.
Change-Id: Ic3fdc029a96c34a9d2d9ec669b789526c8325637