This fixes sporadic failures in testcases using those altsteps.
Change-Id: I3538d40ff1a585ccbe37f3a90f3c374c5f0b5767
Related: osmocom-bb.git I0046f9c103bcb9207f0c2643c6a806bd56553d77
The BTS rejects establishment without contention resolution on DCCH SAPI
0. This only applies if channel activation type is for immediate
assignment. The Test expects the establishment on DCCH SAPI 0 to fail,
if channel activation type is for immediate assignment and to pass, if
the channel activation type is for normal assignment.
Related: OS#6309
Change-Id: I8143c6e9448a663fee2111a91415cc58fbcb2133
This patch demonstrates the problem with handling of the Early IA:
* the first part remains unchanged: assign a channel on C0 (arfcn=871);
* the second (new) part tests channel assignment on C1 (arfcn=873).
As of now, osmo-bts does not meet our expectations for the second part.
Change-Id: I7517574a8095ddfa05c34c4c3d4accf2bd07894b
Related: SYS#6655
At some point (see related commit) we changed the ordering of default
interference boundaries from descending to ascending in osmo-bsc.
However the testsuite was not updated. Fix this.
Change-Id: I4f0d0814c343c626f6f7e5bafb7ac46cd7f362f6
Related: osmo-bsc.git Ie9bf4bf0c89418685b8ea5096332d22cfba7c521
Related: SYS#5313, OS#5956
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
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 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
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
Vadim Yanitskiy
Andreas Eversberg
Philipp Maier
Harald Welte