We need to call f_shutdown() to properly terminate all components.
All (at least speech related) testcases do this function call.
Change-Id: Ib706fe3d9901f9cd1a0efa7d9ffd3b5b8a4472d7
Otherwise we're getting a DTE when trying to run this function more
than once in a single testcase (e.g. when testing different channel
modes). This is already done properly in f_TC_speech_rtp().
Change-Id: I290789153bea4b128af29dcf7c52da16b64c4108
Related: SYS#5919, OS#4823
This testcase is currently passing for both -master and -latest
versions of osmo-bts, despite their behavior is different:
* the -latest is sending FACCH frames with dummy LAPDm func=UI,
* the -master is sending invalid speech frames with inverted CRC3.
There is a bug in the 'tr_bad_frame' template definition: we expect
the payload to be present, while in real BFIs it's omitted. So these
two testcases would always pass, even if the IUT would be sending dummy
bursts or sending nothing at all, because they were designed to fail on
receipt of a never-matching TRAFFIC.ind template.
Let's fix this and align our expectations with the current behavior
of the -master version of osmo-bts. Note that sending invalid speech
frames with inverted CRC3 is not osmo-bts-trx specific behavior;
it's actually a replicated behavior of DSP based osmo-bts-sysmo.
Change-Id: Ic680002f60e598cfeeb448c517581b3506355e5b
Related: osmo-bts.git I78106802a0aa4af39859c75d29fe0e77037899fe
Related: SYS#5919, OS#4823
I forgot to update this function in [1]. Let's make it consistent with
the f_TC_speech_rtp(). More details can be found in the linked patch.
Change-Id: I8c2f8bb4cc4b44378af5536893bc73fde368b3fe
Related: [1] Ifb69669b75df5b390d7056cefaf0ef1df69d9bd4
The PCUIF protocol version 11 uses a more distinct (direct TLLI) way
to signal PAGING COMMAND and IMMEDIATE ASSIGNMENT messages towards the PCU.
Since OsmoBTS will soon fully support v.11 of the PCUIF protocol we need
to add compatibility in the OsmoBTS TTCN3 testsuite early. We also have
to stay compatible with older versions of OsmoBTS. The BTS_Tests.default
config still sets up mp_pcuif_version to version 10, so this will be the
default until we have full version 11 support in current master and
latest.
Related: OS#5927
Change-Id: I08de02e951e10bc8b4381cc2ad32e63f2747e3c4
With recent osmocom-bb.git patches [1][2][3] this testcase needs
slightly more time to execute all 8 TopTestCase steps.
Change-Id: Ia693e91b2bcf71cac0bcda07124ab99e97d27dcd
Related: [1] Ia42550d5c2d8b49efbdf8ef0ce46b26afd1c464e
Related: [2] Ic8a5b6277c6b16392026e0557376257d71c9d230
Related: [3] I838b1ebc54e4c5d116f8af2155d97215a6133ba4
In change I8b8264d28b1b1deb08774cdba58dd4c6dafe115d we modify osmo-bts
so that it will only confirm IMMEDIATE ASSIGNMENT messages. In order to
detect whether the message is an IMMEDIATE ASSIGNMENT, it has to look
into the message.
In testcase TC_pcu_data_req_imm_ass_pch we use f_rnd_octstring(23) to
generate the IMMEDIATE ASSIGNMENT message. Since osmo-bts now looks into
that message this is no longer enough. so let's generate a more realistic
IMMEDIATE ASSIGNMENT message where only the request reference and the TLLI
is randomized.
Related: OS#5927
Change-Id: Ic597154df01bdd04515edf882a567656f2a54d8c
Since recently [1], osmo-bts does submit all PCUIF DATA.ind regardless
of the Uplink link quality (C/I ratio in case of osmo-bts-trx).
Change-Id: If801e9112c1207ccdc40f9e675c52fadccdd1411
Related: [1] osmo-bts.git I8f1856dd9061c1bfca8b15be30df7a51760231b0
We must be using a valid TDMA Fn when scheduling UL BLOCK.req,
so wait for a DL BLOCK.ind, take the current Fn from there and
calculate a proper TDMA Fn for the next UL block.
Change-Id: If0fb615a4136a76a939588af0131ddcfb7acd877
Related: OS#5954
This altstep eliminates the need to wrap the actual PCUIF message
template into another (port specific) template t_SD_PCUIF.
Change-Id: Iabefddd54a4a2e2183feea04fdb8526e74efc7ac
Currently the TC_acch_overpower_* testcases are all passing without
any sporadic failures. However, most of them start failing due to
a DTE (some RSLEM related race condition) if I apply a patch [1] to
trxcon removing its internal TDMA clock module.
I don't know why this happens, but releasing the DCCH after executing
all testcase steps in f_TC_acch_overpower() makes that DTE go away.
Change-Id: I658e78ad8d4dc86403d22b5380ddd9a140f8c71c
Related: [1] osmocom-bb.git Ic8a5b6277c6b16392026e0557376257d71c9d230
Related: OS#5500
All testcases based on f_TC_speech_rtp() consist of two parts:
* In the first part we expect to receive a Downlink frame at the MS,
and, once received, we echo the received frame back to the BTS.
* In the second part we expect to receive an Uplink frame, the one
that was echoed back during the first part.
Let's keep echoing Downlink TCH frames while executing the second
part in order to reduce possibility of race conditions and keep
filling-up the Tx queue in the virtual MS (trxcon). Also keep
sending dummy Measurement Reports on SACCH.
Change-Id: Ifb69669b75df5b390d7056cefaf0ef1df69d9bd4
Related: OS#1572, OS#4396
Since recently [1], osmo-bts started to preen incoming FR and EFR RTP
frames for SID errors. In other words, if an incoming frame is a SID
frame, osmo-bts may modify some bits causing a mismatch on our side.
Use 'FF'O as padding pattern for TCH/FS to prevent pseudo-random frames
being treated as SID and modified by osmo-bts. Keep using '00'O for
other modes, because only TCH/FS specific SID frames must have specific
bit positions set to '0'B; for TCH/EFS and TCH/HS it's '1'B.
Change-Id: Ib42b783574caf5cbaf64b2eb5dd1d2b2a6637c2f
Related: [1] osmo-bts.git I89df2f12c49dd5378667cf149d19bde654f80134
Related: OS#6039
At the moment The RTP emulation and MGCP_Test only allow to specify one
codec and one set of RX/TX fixed payload octet strings to verify against.
This is quite limiting since it might be necessary to test against
different types and formats of payloads simultaneously in order to see
if osmo-mgw converts or forwards them correctly.
Let's extend this to support multiple codecs on MGCP/SDP level plus
support for multiple RTP payloads on RTP emulation level.
Related: OS#5461
Change-Id: I8422313fccad1bfcee52c933f643068bebdaf2d5
Change [1] fixes support of dynamic timeslots in osmo-bts-virtual,
so we don't need to change the pchan configuration anymore.
Change-Id: I98397ac0fc17ece8f0e41b1ef1c158b47c9de026
Related: [1] osmo-bts.git I5db5b7dd6a8e84cf9a0d84f04a650c2ed8a4e368
When calling f_pcu_to_l1(), the L1CTL port still contains many BCCH
related L1CTL DATA.ind messages in the queue. It's not a really a
problem since they all get discarded, but still they're producing
lots of useless TTCN_MATCHING log messages.
Change-Id: I57b745bcfc48dc621359658cd43d2ee622fde49b
The old GPRS related messages are no longer valid. Use the new message
definitions supported by both trxcon and virtphy since recently.
Comment out lines referencing the old definitions in LAPDm_RAW_PT.ttcn.
This module contains an implementation of the RLC/MAC abstraction
layer, which is currently not used anywhere.
Change-Id: Ib8f4459480bbe12584a6fa71882f745f03c5055d
Related: osmocom-bb.git I9567d64f9d00262e36147e8d7e541e5e246bda5f
Related: OS#5500
Currently we have two variants of the L1CTL PDU:
* L1ctlUlMessage: L23 -> L1 requests (*_REQ),
* L1ctlDlMessage: L1 -> L23 responses (*_IND, *_CONF).
The L1CTL_PT port is defined in a way that one can:
* Tx L1ctl{Ul,Dl}Message PDUs,
* Rx L1ctlDlMessage PDUs.
This means that the testsuite can act as the L23 talking to the L1
(e.g. trxcon or virtphy), but not vice-versa. Adding an additional
Rx `UD_send_data -> L1ctlUlMessage` mapping is not an option,
because such a mapping would be ambiguous and would cause errors.
By merging the two L1CTL PDU variants into the one, we can achieve
the testsuite acting as the L1. This will be useful for testing
the L23 applications in osmocom-bb.git, like the modem app.
Take a chance to reorder fields to match the order in L1ctlMsgType.
Change-Id: I1313068c5f02b65d3dbb05a1341a9d7286225f0c
Related: OS#5500
Prepare to test CSD in BSC_Tests.ttcn. After sending a BSSAP assignment
request to the BSC with channel type data, the BSC will send a channel
activation via RSL to the BTS (which is emulated by the testsuite).
Without CSD support in the RSL template, the testsuite is unable to
decode the message, prints "Data remained at the end of the stream
after successful decoding" and the test fails.
Related: OS#4393
Change-Id: Ief2d95c7e9d71afb26fa74da755294226c8e158d
Ramping down power if the oml link is lost was removed in osmo-bts.
Instead TC_tx_power_down_bcch checks that the rx power received is not
> 0 after dropping the oml link.
Change-Id: I463679d9678b95b7d3a5ace711c6ce17b3b24689
Depends: Ida1d7bbf094958b9142af306dbf84206729a609e (osmo-bts.git)
Related: SYS#6237
Since [1] was merged, sending the L1CTL_DM_REL_REQ message alone
is not enough to be able to tune back to BCCH. We also need to
send L1CTL_RESET_REQ, so the trxcon's state is reset properly.
This patch fixes the following testcases:
* TC_sacch_chan_act_ho_async,
* TC_sacch_chan_act_ho_sync,
* TC_conn_fail_crit.
Change-Id: I07192e8a3127f8d9557a4b8aac3ca002f511a1d5
Related: [1] I5bbe6ca4cc6299f9faf343822c992a6872a45081 (osmocom-bb.git)
osmo-bts-trx declares a connection failure when the radio link counter
S reaches 0. This counter is decreased every time the Viterbi decoder
yields a decoding error on the Uplink SACCH. For more details, see
3GPP TS 45.008, section 5.2.
The scheduler in osmo-bts-trx expects NOPE indications to be sent by
the transceiver in the absence of valid Uplink bursts. However, due
to the asynchronous nature of TRXD link, our virtual Um interface
implementation, fake_trx.py, does not generate NOPE indications on
it's own. Instead, trxcon is sending empty TRXDv0 PDUs (BURST.req),
which are then translated to proper TRXDv1 NOPE.ind by fake_trx.py.
The TC_conn_fail_crit currently sends L1CTL_DM_REL_REQ in order to
simulate connection loss, what makes trxcon disable all active
timeslots and thus stop sending NOPE.req to fake_trx.py.
Let's tune trxcon back to BCCH, in order to ensure that NOPE.req
messages are still being sent, so that osmo-bts-trx will be able
to declare a connection failure over the RSL as expected.
Change-Id: I34aee95111eafea90eeeea861682f1b4547d7b03
Related: Ic292d180ba64206fb4d88adb284f9f9d058b4587
The RSL MultiRate configuration IE is all about AMR (Adaptive Multi
Rate) codec, so there is no need for 'amr_' prefix in field names.
Change-Id: If63ee50e8681ad4e0a202f142f2fca2268d55079
There is no real need to pass the multi-rate parameters explicitly
in each invocation of ts_RSL_MultirateCfg. The exact multi-rate
configuration does not matter in scope of BTS specific tests.
Change-Id: I24117af8c5b7b11fe4b8f24fca5279ad97b46fab
Both testcases were introduced in 2021 [1], however they're not
executed on Jenkins because they're not present in control section.
Fixes: [1] I38e8a1cf15eb41a621b457b39024283a767c94be
Change-Id: Iebf6d14321b54e7ef261443aece03296540ebe92
As was explained in [1], until recently we relied on trxcon sendig
dummy RR Measurement Reports with patched L1 SACCH Header values.
Now trxcon does not patch it for us, so we need to send Uplink
SACCH blocks with the correct L1H ourselves.
Revision 2 of [1] was successfully tested and proved to fix the
above-mentioned testcases. However during code review I was asked
to make the statements sending Uplink SACCH blocks self-explanatory.
In revision 3 of [1] I modified the code to call f_send_meas_rep(),
which was introduced in [2], which as stated in the commit message
is using g_pars.l1_pars.{ms_power_level,ms_actual_ta} instead of
the values from received L1H. Of course this does not work.
Add and use f_send_meas_rep_l1h(), which allows to send the given L1H.
Take a chance to add a log() statement, so that we can see what we Tx.
Change-Id: Ia79a0a7b06394bd34d0f40226cf40e6e8bd2ba35
Fixes: [1] I31dd6b9026d04403092256176f67785a0a6486ad
Related: [2] Ia5d0315e053702df5fa8dad8c6c66c11c9f3edcb
Related: OS#5635
There is a time window between activation of a dedicated channel and
receipt of a L1CTL_DATA_REQ with the first RR Measurement Report, in
which the L1 may need to start transmission on Uplink SACCH.
In this case the L1 is using a dummy SACCH block with hard-coded L1
SACCH header values and hard-coded Measurement Results.
Until recently we relied on implementation specific behavior of trxcon
patching the L1 SACCH header in hard-coded dummy SACCH block. This
behavior was changed, so TC_ms_pwr_ctrl_{constant,pf_ewma} started to
fail. Let's properly populate the SACCH cache to fix these TCs.
Change-Id: I89eb90815e86db466ea626f4c25f2634c1d942d5
Depends: osmocom-bb.git I0f467fc07cf844cc73465f235b36ba7d00788c9f
Related: OS#5635
We used to rely on trxcon sendig dummy RR Measurement Reports and
patching the L1 SACCH Header with the configured MS Power Level
and Timing Advance values. Since recently, the following testcases
started to fail because trxcon does not patch dummy MRs anymore:
* TC_rsl_ms_pwr_dyn_ass_updown,
* TC_rsl_ms_pwr_dyn_max, and
* TC_rsl_ms_pwr_dyn_up.
Do not rely on dummy MRs, send SACCH blocks with the expected
MS Power Level and Timing Advance values from the testsuites.
f_send_meas_rep() internally uses:
* g_pars.l1_pars.ms_power_level, and
* g_pars.l1_pars.ms_actual_ta.
Change-Id: I31dd6b9026d04403092256176f67785a0a6486ad
Related: OS#5635
The key difference is that f_send_meas_rep() simply sends an RR
Measurement Report and does not wait until it's received on the RSL.
Change-Id: Ia5d0315e053702df5fa8dad8c6c66c11c9f3edcb
A comment in f_TC_rsl_ms_pwr_dyn_up() states:
> By default, the MS power loop gets triggered every 4th SACCH block (1.92s).
> We need 9 * 4 dB steps to get from 0 dBm to 33 dBm, so 9 * 1.92s total.
> Add an extra offset to avoid race conditions: +1.92s.
so the alt statement is expected to block for 19.2s, while the guard
timer is set to 20.0s by default. This is not enough, given that
f_TC_rsl_ms_pwr_dyn_up() also needs to wait for the first SACCH block
before entering the alt statement.
Let's give it more time to run in order to avoid sporadic failures.
Change-Id: Ib7de8383c95ac9e00560f786ec4c56f79f7d81bc
Related: OS#5635
Sending L1CTL_DM_REL_REQ does not make the L1 tune back to CCCH/BCCH.
We need to send a L1CTL_FBSB_REQ after releasing a dedicated channel
if we want to establish another one. This is essential when running
tests using Calypso PHY, and will be required once we have proper
trxcon_fsm implementation [1] merged.
Related: [1] osmocom-bb.git Ifaf63ead9dd180181358e771367b2a686ba159ca
Change-Id: I65fb243a62fc7670b43f467d6b79268cdfb98f36
Move parameter 'fpc' at the end and assign false by default, so that
there is not need to pass false. We never set it to true anyway.
Change-Id: I8a0ef562c2426a637fbb9fe3d50711ee7738d04f
If a CRXC message contains optional remote IP and port IEs, the
CRCX ACK received from the BTS is expected to contain its listen
address and port. In some cases osmo-bts may indicate nonsense
addr='0.0.0.0', and indeed the RTP_Emulation component is not gonna
like this. This makes both BTS_Tests.TC_speech_rtp_tch[fh] test
cases fail whenever executed in Docker:
Connection refused (unexpected)
Let's work this around by sending the remote IP and port IEs in
additional MDCX message and omitting them in CRCX. This mimics
osmo-bsc's behavior and makes both test cases pass.
Change-Id: I03453e72f62819989dfe6aa12d8bd889fced1046
Related: OS#5242
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
Vadim Yanitskiy
Philipp Maier
Oliver Smith
Daniel Willmann
Pau Espin