This function is going to be used by the upcoming testcases for CSD
specific channel modes. Generating the Rx/Tx payload(s) now becomes
the duty of the calling function. So far the only user of this API
is f_TC_speech_rtp(), so move the speech payload generation there.
Change-Id: I9e823c33b1dbbadd57bc63df25b8ddf368d76232
Related: OS#1572
In PCUIF v.11 we support getting confirmations for IMMEDIATE ASSIGNMENT
messages that are sent through the AGCH.
Related: OS#5927
Change-Id: Iec00d8144dfb2cd8bcee9093c96a3cc98aea6458
The testcase TC_pcu_data_req_agch uses SAPI PCU_IF_SAPI_AGCH. Since we
now have a function f_PCUIF_tx_mac_block_agch() to send MAC blocks over
the AGCH using the recently introduced SAPI PCU_IF_SAPI_AGCH_2, lets use
this function instead.
Related: OS#5927
Change-Id: I341bbd01e8132fab913d307bfb4b2fb873cdde3c
In the recent PCUIF change of osmo-pcu (see Depends) a confirm flag
is added to struct gsm_pcu_if_pch. This flag tells the receiving end
(OsmoBSC or OsmoBTS) that the sending of the received MAC block has
to be confirmed towards the PCU. OsmoBTS and OsmoPCU now rely on the
conformation flag.
Let's update the BTS_and PCU testsuites accordingly.
Related: OS#5927
Depends: osmo-pcu.git Ia202862aafc1f0cb6601574ef61eb9155de11f04
Change-Id: I7017ca20ca7e0b77d0f363121e4f17280e39e8ac
We are no longer "appending" imsi digits. This is now done properly
using a struct but let's still mention what we use the IMSI for.
Related: OS#5927
Change-Id: I3d943cd96e1d9627ad68e3439b2a649baa5785f1
Since we now no longer refer to TLLI when we mean "message ID" (msg_id),
we should also remove the "_DT" / "_dt" suffix from structs and define
constants and replace it with "_2" if required.
Depends: osmo-pcu.git If641b507dcb6b176109c99dce7cff2a7561364b0
Related: OS#5927
Change-Id: I15e754ce3ceed92a517586a073d3e3ed008b5eef
The function f_PCUIF_tx_imm_ass_pch() retuns the frame number, that is
sent back from osmo-bts via PCUIF / gsm_pcu_if_data_cnf_dt. Since we are
about to remove this field from gsm_pcu_if_data_cnf_dt, lets no longer
access it here as well. Also the return code is never used anywhere in
the tests. (In osmo-pcu the fn parameter was used for logging only, in
osmo-bts it was set to constant 0)
Related: OS#5927
Change-Id: I0e5bad7a0d74e5032f2818f6fdf5b9b2ecb531cc
To confirm downlink IMMEDIATE ASSIGNMENT messages, we use the TLLI as an
identifier and the related record member is also called "tlli".
Unfortunately this is misleading since the message identifier does not
necessarly have to be a TLLI. It is just an implementation detail that
osmo-pcu uses the TLLI as a message identifier.
To make that clear, lets rename the tlli member (and variable and
parameter names where it is passed on) to "msg_id".
(Since this change only renames variables and struct members it will not
break compatibility with other programs that use the PCUIF)
Related: OS#5927
Depends: osmo-pcu.git I4a25039dfe329e68879bc68936e49c4b190625e6
Change-Id: I1db29d5b1920e351c452b798c3260654c2cbe0cb
The testcase TC_pcu_data_req_imm_ass_pch uses the PCH to transmit the
IMMEDIATE ASSIGNMENT message but the log line mentions the AGCH.
Related: OS#5927
Change-Id: I7cb8d91f2c3f92009d33134167eab856ee02fdab
We are calling f_pcu_data_req() with SAPI PCU_IF_SAPI_AGCH or SAPI
PCU_IF_SAPI_PCH and use ts_nr 7.
In this particular case, the parameter ts_nr has no effect (see pcu_sock.c in
osmo-bts.git). However, to prevent confusion, lets use ts_nr 0 since AGCH and
PCH are actually is on TS 0 (on TRX 0).
Related: OS#5927
Change-Id: I20566de992809d6c857c9062bf0fb799efa43e45
The MS sends UPLINK ACCESS. The BTS send RSL Listener DET message.
Another MS send UPLINK ACCESS. The BTS does not send another RSL
Listener DET message.
Change-Id: I544f492a32751d17f998a2143081c3763ba1dd29
Related: OS#4851
A VGCS channel is activated. The BSC sends UPLINK FREE message. The MS
sends RACH on VGCS channel. The MS receives VGCS UPLINK GRAND and
establishes layer 2. Then the BSC forces to releases the uplink. The MS
receives UPLINK FREE again.
Change-Id: Ic86bc34890c7d1e6e0b255c3d40eda3dfaa59285
Related: OS#4851
A VGCS channel is activated. The BSC sends UPLINK FREE message. The MS
sends RACH on VGCS channel. The MS receives VGCS UPLINK GRAND, but does
not respond to it. It is expeced that the BSC receivce RSL CONN FAIL.
Change-Id: I3b292f6a5f47298195bd942a5ca73d9d63f921b5
Related: OS#4851
A VGCS channel is activated. The BSC sends UPLINK FREE message and
UPLINK BUSY message. When the UPLINK FREE message is sent, the MS is
expected to receive several UPLINK FREE messages. Then the UPLINK BUSY
message is sent, the MS is expected to receive one UPLINK BUSY message.
Change-Id: I2f70adb4a6f71eb8972feccf9dda0f77e7a942b9
Related: OS#4851
Send Notification command to start and stop notifying an ASCI call.
When it starts, it is expected that NCH is received. Also it is expected
that NCH is received again. When it stops, it is expected that NCH is
not received anymore.
Change-Id: I3727c471663b731117a264f60d2f1ba5fd16928e
Related: OS#4851
The new type LapdmFrameBter and its send and receive template is used to
send and receive Bter frames, which has a short L2 header and uses all
23 octets for payload.
Bter frames are DCCH UI frames with SAPI 0 and 23 octets sent on
downlink only.
Change-Id: I07a4fd9879dfd9de441c0348a84b7dd5c9864eb4
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
Without this change I cannot run BTS_Tests manually anymore:
Local verdict of MTC: fail reason:
"BTS_Tests.ttcn:480 : Invalid PCU Version/BTS Number received"
Change-Id: If0046b44adb93fba7dced1ce06d5ddb9d7c75269
Fixes: 3b4abb86 "BTS_Tests: Add support for PCUIF protocol version 11"
This testcase has been fixed in [1] and is currently passing.
Change-Id: I9bc81629a9baaf922a87ac95c8f69af343aacdf1
Related: [1] I2c328219b1a37d0f4623c5728143cd91976000a0
Related: OS#5972
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
The test failed, because testing retransmit timeout on DCCH would take
longer than guard timer. Instead of changing that timer, I decided to
use ACCH instead. Additional changes were required to make ACCH test
work properly.
https://osmocom.org/issues/5972
Change-Id: I2c328219b1a37d0f4623c5728143cd91976000a0
Until recently, the asp-clnt-* ASPs, which have specific handling in osmo_sccp_simple_client_on_ss7_id(),
were being always forcedly set to sctp-role CLIENT by code in that
function.
This prevented user of that API from explicitly configuring the ASP as
"sctp-role server" through the VTY as the option would be overwritten silently.
Now, the sctp-role from config is followed if the ASP is
defined/configured through the VTY (not dynamically created at the time
osmo_sccp_simple_client_on_ss7_id() is called).
Since the default for a VTY-specified ASP is to be in "sctp-role
server", the config files need to be updated to properly configure the
ASP to be in "sctp-role client", which is the desired mode here.
Same applies for "role", where the default is SG but it is actually used
as "ASP" here.
Change-Id: I4eb5b5f6b4b24df079b4c74e2a2e2ebb8769b0bd
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
The old test was not really correct, since it is fine for the BTS to ACK
the RSL CONNECT despite later on failing to connect the RSL link.
RSL_CONNECT is really just setting the attributes (it could even be
replaced by SETATTR in the future), and connect happens later on.
This can still be found out by the BSC because the BBTRANSC will never
transition to a Enabled state until the RSL link becomes up.
This patch repurposes the existent test to do some more meaningful check
in a case the RSL CONNECT can be answered with a NACK. This scenario was
actually failing to be properly checked in osmo-bts until recently, so
it is expected that it will fail (and even crash) older versions of
osmo-bts.
Depends: osmo-bts.git Change-Id If27639ae1727fc5232e1a964a1b29f50c8805d80
Related: OS#5964
Change-Id: I10df611f0086d34a5482f7c8a79703938313ab3d
Some components directly report being activated. Let's allow it.
This fixes TC_initial_state_reports.
Change-Id: I054dc74f60edee027923f03f8e73e56b1dc11a83
Vadim Yanitskiy
Philipp Maier
Andreas Eversberg
Harald Welte
Pau Espin