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
The testcase will ensure paging is repeated by the MSC.
Repeating will improve the reachability of MS when a Paging is lost
or not received because the MS is moving between states.
Change-Id: Ib5bf0b62e0639436cdcba03acbaedf1458e18873
This change introduces a new test case TC_cs_lqual_ul_tbf, which
is aimed to test the feedback of OsmoPCU on changing link quality
measurements in Uplink Data blocks during an active TBF.
Change-Id: Ia78d93e43a3c41b0b30e70df20a2da31077fd05f
Related: SYS#4607
The aim of this test case is to test the correctness of Timing Advance
at the time of TBF establishment. In particular, the test case sends
several Access Bursts (RACH.ind) with increasing 'qta' value, what
causes OsmoPCU to allocate a TBF (Temporary Block Flow) for each
RACH.ind and send DATA.req with Immediate Assignment on AGCH,
containing the expected Timing Advance value.
Change-Id: I21f76ae723519c0eb54515922a05ca8045b00ade
Related: SYS#4606
In Ieefa61232eb215a19a02e490255332e28e23b8f8, I had to revert
I5808954b5c67c3239e795e43ae77035152d359ef, because that change
broke encoding of messages on the PCU interface.
Since we cannot use 'PADDING' attribute until its implementation
is fixed in TITAN, let's work this around by stripping padding
bytes manually in UD_to_PCUIF().
Change-Id: Ibd698094c897d395208e80189457444a91018beb
This change implements UL Packet Resource Request message as per
3GPP TS 44.060, section 11.2.16 (only mandatory fields), and a
send template 'ts_RlcMacUlCtrl_PKT_RES_REQ' for it.
Change-Id: I0d688beb4112d6db10ac89e2966b555e74887a6e
The problem of existing test cases is that they mix IUT (i.e. OsmoPCU)
with OsmoBTS (osmo-bts-virtual) and OsmocomBB (virt_phy). This approach
allows to avoid dealing with TDMA clock indications and RTS requests on
the PCU interface - this is done by OsmoBTS. On the other hand, our test
scenarios may be potentially affected by undiscovered bugs in OsmoBTS
and the virt_phy.
In order to solve that problem, this change introduces a set of new
components and the corresponding handler functions:
- RAW_PCUIF_CT / f_PCUIF_CT_handler() - PCU interface (UNIX domain socket)
handler. Creates a server listening for incoming connections on a given
'pcu_sock_path', handles connection establishment and message forwarding
between connected BTS components (see below) and OsmoPCU.
- RAW_PCU_BTS_CT / f_BTS_CT_handler() - represents a single BTS entity,
connected to OsmoPCU through the RAW_PCUIF_CT. Takes care about sending
System Information 13 to OsmoPCU, forwarding TDMA clock indications from
a dedicated ClckGen component (see below), and filtering the received
messages by the BTS number. Implements minimalistic scheduler for both
DATA.ind and RTS.req messages, so they are send in accordance with the
current TDMA frame number.
- RAW_PCU_ClckGen_CT / f_ClckGen_CT_handler() - TDMA frame clock counter
built on top of a timer. Sends clock indications to the BTS component.
All components communicate using TTCN-3 ports and explicitly defined sets
of messages (see RAW_PCU_MSG_PT). One noticeable kind of such messages is
events (see RAW_PCU_Event and RAW_PCU_EventType). That's how e.g. the PCUIF
component can notify the BTS component that OsmoPCU has just connected, or
the BTS component can notify the MTC that SI13 negotiation is completed.
Events may optionally have parameters (e.g. frame-number for TDMA_EV_*).
Furthermore, the proposed set of components allows to have more than one
BTS entity, so we can also test multi-BTS operation in the future.
+-----+ +----------+ +---------+
| MTC +---------------+ PCUIF_CT +------+ OsmoPCU |
+--+--+ +----+-----+ +---------+
| |
| |
| |
| +-----------+ | +---------------+
+----+ BTS_CT #1 +------+ | ClckGen_CT #1 |
| +-----+-----+ | +-------+-------+
| | | |
| +---------------------------+
| |
| +-----------+ | +---------------+
+----+ BTS_CT #2 +------+ | ClckGen_CT #2 |
| +-----+-----+ | +-------+-------+
| | | |
| +---------------------------+
| |
| +-----------+ | +---------------+
+----+ BTS_CT #N +------+ | ClckGen_CT #N |
+-----+-----+ +-------+-------+
| |
+---------------------------+
Change-Id: I63a23abebab88fd5318eb4d907d6028e7c38e9a3
When a paging for a CS-Call times out the MSC/VLR is expected to send an
SGsAP-SERVICE-ABORT-REQUEST to the MME to indicate that the paging has
timed out. This is not taken into accound yet by TTCN3 test
TC_sgsap_paging_and_nothing
Related: OS#3614
Depends: osmo-msc I3f8f153afe24cf2efa245713509bdc8488902877
Change-Id: I99950a17ccf26aaa0eebded5480f33be4c57586a
For me this change causes MGCP parsing errors:
setverdict(fail): pass -> fail reason: "Could not extract parameters for code "C""
Apparently the \r is after all necessary to parse MGCP. Maybe the '\r' is
implicit when an '\n' occurs, but the non-SDP part of MGCP has *only* '\r' line
breaks.
This reverts commit a9a52fff15.
Change-Id: I81d105b951590310c67f14f0b5d0c2777e206c5e
Remove implied \r to fix following warnings:
"Duplicate character `\r' in the character set. Please note the \n
includes the \r implicitly. Use \q{0,0,0,10} if you would like to match
the LF only."
Change-Id: I99948e4b82b5b4bd5b8f7c1a4c60a97fcab3c0eb
The SGSN will send a CommonId after it has sent SecurityModeComplete
to support paging coordination in the RNC.
Change-Id: I82a05cab2aeea25eec699f726b2f5c4b3eef7560
Since bssgp also been used for Iu connection,
rename the variable to ran_index.
Be consistent and use the same variable name everywhere.
Change-Id: Ib278410bc49f07387873740ed8b411a815d940a8
Since gb_idx also been used for Iu connection,
rename the variable to ran_index.
Be consistent and use the same variable name everywhere.
Change-Id: Ia119feee6a442c76dc337e75c07f4a385cd5e1df
Since gb_index also been used for Iu connection,
rename the variable to ran_index.
Be consistent and use the same variable name everywhere.
Change-Id: I06b0c6184daeb886e8bd28d50bf18909d9244dc6
Get rid of template t_IMM_ASS, which is a part of L1CTL_Types.ttcn.
Prepare generic (for both CS and PS) template on top of tr_IMM_ASS,
and use it in f_L1CTL_WAIT_IMM_ASS().
Change-Id: I3a410ec3c41e3eefd23071bfb0d80feda82177a5
This is a TITAN specific attribute that allows to indicate that
a field of type 'charstring' is '\0'-terminated. Without that
attribute, 'PCUIF_Text' is mixed with the padding characters:
"0.7.0.5-df0f" & char(0, 0, 0, 0) & char(0, 0, 0, 0) & ...
Change-Id: Ic81fff4c82871bb29a2385b9ee7a2dd98f67dfb0
Vadim Yanitskiy
Pau Espin
Oliver Smith
Philipp Maier
Harald Welte