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
We have added an additional bts_model field to the PCUIF_info_ind. This
also means that we have to increment the PCUIF version number since
adding fields is a major change to the protocol. This patch updates the
related TTCN3 record and also increments the PCUIF version number.
Related: OS#6191
Depends: osmo-pcu.git I48eb75f65ab54fdec41ef913e24c1f18cd4a4047
Change-Id: Ib1516e66c70f021adee49f41bd707803fc06f9cf
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
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