Some stuff was wrong and some was missing after new features being
implemented in tests over time.
Change-Id: I7a279592a68ffc76408a8e728e76151534265cc0
This type of scenario is used in several tests and will be used in more
tests in the future, so let's move there for easiness.
Change-Id: Ic65ff2ff9dc3cc82ae3fefcf3caf406279cd6b97
Infrastructure in STP_Tests_IPA changed to be more similar to what is
done in STP_Tests_M3UA, which already contain more advanced tests.
Array of AS names mp_ipa_as_names is added in order to let TTCN3 port
which AS is configured in STP for each src port.
Change-Id: Iae213c58598cc0207503fd10f09d2d57aab941fe
This way traffic modes set dynamically by peers are cleared and can be
reset by next tests easily.
Change-Id: I177441b2d43298b3836ccf78fe11267333e80665
In the past, we were automatically running [large parts of] the nplab
M3UA and SUA test suites, but those implement only a fraction of the
functionality. Particularly, they don't cover the non-standard IPA
behavior, and they don't cover RKM (routing key management).
Let's introduce an initial set of STP tests with this patch. We try
to not duplicate nplab here, and implement bits not covered there.
Change-Id: I628a87385cac0dfe708a0d74a5088fbd5a4790cd
We have a module parameter 'mp_l1_supports_gprs' that indicates
whether the L1 back-end (trxcon, virt_phy, or Calypso) does
support PDCH and TBF management.
The TC_pcu_ptcch does not require support of TBF management, only
PDCH (namely PTCCH) needs to be supported. This is already
implemented in trxcon, and can be easily implemented for Calypso.
Change-Id: Id2e751e825a7a5128bc3f2e4677d8ef31174b501
Otherwise most tests in bsc-latest fail because in latest release BSC
never sends that IE.
Related: OS#4244
Change-Id: I725836784a7900d2ea51eae188c2c279e8639dbf
It will allow changing ms max power in osmo-bsc.cfg as well as TTCN3
expactancies in BSC_Tests.cfg easily in docker-playground.git without
needing to recompile or change code in TTCN3.
Change-Id: Ib00c96902377582bc32778c5b947a6b4274041aa
Split f_mgcp_find_param_entry() out of f_mgcp_find_param() to be able to act on
an MgcpParameterList without an enclosing MgcpMessage.
Will be used by upcoming I8b82476f55a98f7a94d5c4f1cd80eac427b2d20f
Change-Id: I90f213d2a1be979afa024e0faa25d532f9858636
- Fix error log for a missing final DTMF.
- Instead of code dup to establish a call, use f_mo_call_establish(). This
will make the test benefit from changes to f_mo_call_establish() (which will
soon come up to accomodate changes in osmo-msc's codec negotiation).
- Instead of hardcoding the expected N_SD counter values to detect DTAP
duplicates, use f_bssmap_last_n_sd() and f_next_n_sd(), so that the N_SD
counter is correct regardless of how many DTAP were sent in
f_mo_call_establish().
- Instead of hardcoding a correct N_SD in the end, use skip_seq_patching ==
false, so that the ttcn DTAP correctly tracks N_SD for subsequent call
release messages.
- Release the call.
Change-Id: Ibfa8b906764f2d5ed75fe74125be42af4546e864
Before this, if an Assignment Request contains an unexpected Transport Layer
Address, the test completely rejects the Assignment Request.
Instead, accept any tla in the Assignment, and compare the expected tla in the
Assignment's interleave action. Thus we directly get logging hinting at the tla
instead of a T_guard timeout.
Change-Id: I04847c10d6c3bf9e04cfda6e343dfd4a65be71a5
This test case is aimed to verify handling of both PTCCH/U and
PTCCH/D logical channels, recently implemented in [1]. This is
done by sending 16 Access Bursts on PTCCH/U, and then by
sending a random data block on PTCCH/D.
The existing TC_pcu_data_req_ptcch does not cover PTCCH/U, and
moreover involves TBF handling which has nothing to do with
PTCCH. Let's keep it anyway.
[1] I232e5f514fbad2c51daaa59ff516004aba97c8a3
Change-Id: I011ffdfa63b698ce6085968d15ffb4ff4bd23ee5
Related: OS#4102
As it turns out, it was a bad idea to use a counter in altstep
as_ta_ptcch(), because its value is getting lost. Let's instead
introduce a new type PTCCH_TAI_ToA_MAP, which is basically a
list of ToA values for each PTCCH/U sub-slot (TA Index), and
pass it to the altstep.
Change-Id: I74252dfb929fcb32d07e8728d692674931fae727
Both TDMA_EV_PTCCH_DL_BLOCK and TDMA_EV_PTCCH_UL_BURST events may
happen together during the same TDMA frame (fn % 104 == 90). We
shall not skip TDMA_EV_PTCCH_UL_BURST. Let's fix this.
Change-Id: Ifc66d5d1c5f9eaa7bed6882105298c45257ebef0
Packets sent by f_gmm_attach() might take too long via layers to reach
the SGSN. The GMM_ATTACH_COMPL in f_gmm_attach() took soo long,
that it arrived after packets, which has been sent after calling f_gmm_attach().
This behaviour was found in TC hlr_location_cancel_request_update().
Change-Id: I0209c86e16fe616284d753e9e003f2e4d9ec9ea5
Test BTS_Tests.TC_dyn_osmo_pdch_act_deact was sporadically failing due
to receiving IND_INFO on the PCU port with pdch_mask related TS bit set
to 0 after sending a PDCH ACT. That happened due to a race condition
because PCU send IND_INFO periodically. As a result, it can happen that
BTS sends an IND_INFO after PCU.clear was called and before the PDCH ACT
is handled.
Commit 446e07bc77 already did same fix for
f_dyn_ipa_pdch_(de)act() family, but didn't change this one.
Change-Id: I323852632341c19837bebfcf2f00d404151367a7
The testcase TC_ts101318_rfc5993_rtp_conversion tests the RTP packet
format conversion of ts101318 to rfc5993 and vice versa. At the moment
the testcase sends RTP packets in both directions at the same time. In
order to simplify the test and to make race conditions less likely, lets
test both directions separately and add some guard time.
Change-Id: Id9b69587f7fb5f6b0da072ac5f4863fd4111e597
The testcase TC_one_crcx_receive_only_rtp performs a short RTP
transmission that lasts about 1 second. Then it conuts out the number of
packets that are transmitted and checks against a fixed value. The
compare values are determined using experimentation and reflect the
number of bytes/packets that one could expect under normal conditions on
an average machine.
However, there may be load sitations on the test host that may cause that
a too little number of packets is transmitted and the test will fail. Lets
reduce the number a bit as the only thing we want to make sure with this
is that there are at least some (more than one or two) packets transmitted
Change-Id: Ie63445d61268d178940ce8d9cfa984519c42041a
The following testcases are carried out using two bidirectional
connections on one MGW endpoint.
MGCP_Test.TC_amr_oa_bwe_rtp_conversion
MGCP_Test.TC_amr_oa_oa_rtp_conversion
MGCP_Test.TC_amr_bwe_bwe_rtp_conversion
The test is programmed in a way that the TTCN3 side of the RTP emulation
also works in bidirectional mode. This is prone to run into a race
condition when the RX side is activated but the TX side is already
transmitting.
However, in order to test if the RTP format conversion works we do not
need to test both directions at the same time. Its perfectly fine to do
the one direction first and then do the other afterwards. Lets also add
some guard time while switching the RTP flows.
Change-Id: Idf257cfc1ab45a7f0fb6e1a2f6426f1b3145879b
Sometimes in TC_proc_ss_paging_fail we hit a race condition. The
problem is that the paging expiration timer in OsmoMSC is set to
10 seconds by default (see MSC_PAGING_RESPONSE_TIMER_DEFAULT),
and in f_tc_proc_ss_paging_fail() we also wait 10.0 seconds.
Let's increase our timer value to 20.0 seconds,
so there will be more 10 seconds of leeway.
Change-Id: I6983e8c0cc8e1d7d1619f127e80063d71a4759d2
Related: Jenkins ttcn3-msc-test build #677
otherwise ICMP messages appear in pcap files and some messages are lost
since they seem to be dropped by the kernel.
Change-Id: Id69d98db63f8260067ad6bc1525fb05c936912f2
Unlike the circuit-switched domain, Uplink transmissions on PDCH time-slots
are not continuous and there can be long time gaps between them. This happens
due to a bursty nature of packet data. The actual Timing Advance of a MS may
significantly change between such rare Uplink transmissions, so GPRS introduces
additional mechanisms to control Timing Advance, and thus reduce interference
between neighboring TDMA time-slots.
At the moment of Uplink TBF establishment, initial Timing Advance is measured
from ToA (Timing of Arrival) of an Access Burst. This is covered by another
test case - TC_ta_rach_imm_ass. In response to that Access Burst the network
sends Immediate Assignment on AGCH, which _may_ contain Timing Advance Index
among with the initial Timing Advance value. And here PTCCH comes to play.
PTCCH is a unidirectional channel on which the network can instruct a sub-set
of 16 MS (whether TBFs are active or not) to adjust their Timing Advance
continuously. To ensure continuous measurements of the signal propagation
delay, the MSs shall transmit Access Bursts on Uplink (PTCCH/U) on sub-slots
defined by an assigned Timing Advance Index (see 3GPP TS 45.002).
The purpose of this test case is to verify the assignment of Timing Advance
Index, and the process of Timing Advance notification on PTCCH/D. The MTC
first establishes several Uplink TBFs, but does not transmit any Uplink
blocks on them. During 4 TDMA multi-frame periods the MTC is sending RACH
indications to the PCU, checking the correctness of two received PTCCH/D
messages (period of PTCCH/D is two multi-frames).
At the moment of writing, PTCCH handling is not implemented in OsmoPCU
(neither PTCCH/D messages are correct, nor PTCCH/U bursts are handled).
Additionally, this change introduces a new message type, which is used
for sending commands to the RAW components - RAW_PCU_Command. Commands
can be used to (re)configure components at run-time.
Change-Id: I868f78e3e95a95f8f2e55e237eea700d7d4726a3
Related: SYS#4606
Do not hard-code PCU_IF_SAPI_RACH for RACH.ind templates. We need
to be able to specify other SAPIs (PCU_IF_SAPI_PTCCH) in the
upcoming test cases for Timing Advance control.
Change-Id: I7e2ebcbba5e47cf44f064e429c0517ef3acb15af
This message is sent on PACCH by the network to the mobile station
in order to update the mobile station timing advance or power
control parameters. See 3GPP TS 44.060, section 11.2.13.
Change-Id: Ie07000b08918501a99962ad760932a27eacae678
According to 3GPP TS 44.018, section 10.5.2.16 "IA Rest Octets",
the first bit of Packet Uplink Assignment defines whether it is
a dynamic (1) or single block (0) allocation.
Change-Id: If2bee9b1b065fcfedd0e57a6487040cefe2e50c5
According to 3GPP TS 44.018, section 10.5.2.16 "IA Rest Octets",
Packet Uplink Assignment can be either of the following types:
- single block allocation,
- dynamic allocation.
The current version of TC_cs_lqual_ul_tbf does not handle single
block allocation, so we need to make sure we got a TBF with
dynamic allocation.
Change-Id: I05cf0c62d21094fb53a9e5e54b404f3cf972a182
This change is a step towards getting rid of the old test case
infrastructure. Note that a call to f_bssgp_establish() is moved
out of f_init_bssgp() to the test case's body.
Change-Id: If15339f02c5188e60fcb47ae6dc0ac289efa2896
Pau Espin
Harald Welte
Vadim Yanitskiy
Oliver Smith
Philipp Maier