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
Stefan Sperling
Harald Welte