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
MS <-> SGSN: Successful Attach over Geran
MS <-> SGSN: Routing Area Update over Iu
The test case will crash the SGSN and is not included
in the default run.
Change-Id: Id23244aa6ca329579300b66b73ce238bd4d01eef
This reverts commit dd6d5d1baa.
The PADDING seems to be a very experimental feature of TITAN. It works
very well for decoding of messages, so the padding bytes are getting
recognized as expected, but encoding is broken. Not only the data
buffer and its length are encoded in a wrong way, but other fields too.
Change-Id: Ieefa61232eb215a19a02e490255332e28e23b8f8
MS <-> SGSN: Attach over Iu
MS <-> SGSN: Routing Area Update over Geran
The tess case will crash the SGSN and is not included
in the default run.
Change-Id: Ie043639638a640a2041324fc910964385a41c77d
f_send_l3() replaces f_send_l3_gmm_llc() to have one function
which sends L3 messages for Iu and Gb at the same time.
This allows to share most of the tests between Iu & Gb.
Change-Id: If47ad2be459ca7b87d9071d9ff020a51821e4433
Get rid of t_IMM_ASS_TBF_UL_DYN, use tr_IMM_TBF_ASS instead. Also,
use both tr_PacketUlDynAssign and tr_PacketUlSglAssign for matching
UL TBF assignment.
Change-Id: Icb7dab04a1e2a833c14754d872bd4b85af3d58a5
Both 't_IMM_ASS_TBF_DL' and 't_RR_IMM_ASS_TBF_DL' templates were
introduced for a specific task - matching Packet Immediate
Assignment (Downlink TBF) by TLLI.
In the upcoming changes we will also need to match Uplink TBF
assignment, and more generic fields such as Timing Advance.
Let's add a generic template for Packet Immediate Assignment
and allow passing IaRestOctets as a parameter.
Change-Id: I492cf990820ba153ea71469b8b623e56e031e549
According to 3GPP TS 44.018, section 10.5.2.16, IA Rest Octets IE
starting with 'HH' bits may contain one of the following CSN.1
encoded components:
7 6 5 4 3 2 1 0 Bit Numbers
H H 0 0 . . . . Packet Uplink Assignment
H H 0 1 . . . . Packet Downlink Assignment
H H 1 . . . . . Second Part Packet Assignment
We already have (partial) support for the first two, while the
last type has not been supported so far. Let's add it.
Also, this change introduces several templates for IA Rest Octets
IE and some of its components mentioned above. This would allow
us to abstract the API users from dealing with further changes,
e.g. adding a coding attribute 'CSN.1 L/H' and missing fields.
Change-Id: Ib3a21e7c5fa1cad4466e3a09fa70540de7f6ecc5
For some reason TITAN starts padding not from the beginning of
record ImmediateAssignment, but from it's wrapper GsmRrMessage.
As a result, dec_GsmRrMessage() warns about undecoded octets:
Data remained at the end of the stream after successful decoding '2B2B2B'O
Similarly enc_GsmRrMessage() generates a shorter payload. Let's
work this around by applying PADDING attribute to GsmRrMessage.
Change-Id: I5fe327383402956213c20a68b18b8a48381156b5
Since I403d2141536303a966be7ff51b06c3de202412e6, IA Rest Octets is
a mandatory IE. When changing the definition of ts_IMM_ASS, I forgot
to mark its optional 'lh', 'hl', and 'hh' as omitted explicitly.
As a result, many of our TTCN-3 test cases were broken:
Dynamic test case error: Using an unbound optional field.
Also, in Ifdcdcf50709fcc03195cb8ef6092977e26f910ec I added an
optional field 'pad' to record 'IaRestOctets'. That was not the
best solution, because padding should be handled transparently.
Let's get rid of that dummy field and equip both 'ImmediateAssignment'
and 'IaRestOctets' records with proper padding attributes. The later
one needs to be marked with 'CSN.1 L/H' attribute in the future, but
for now we should keep it octet-aligned.
Change-Id: I69d5fbd8e3388e287bfa54f02454d207e62ee640
The BSC must not only pass the ETWS Primary Notification from CBSP
down every dedicated channel, but it must also send it via an
Osmocom-specific RSL message to enable the BTS to brodcast it via
the PCH (P1 Rest Octets) and pass it to the PCU for PACCH.
Change-Id: Ia418095844aaa418a4e2ff6fd75d8a4b3c8bb9c0
Related: #4046
When the BSC receives an ETWS PN via CBSP, it must send it through all
established dedicated channels of the matching BTSs.
Related: OS#4046
Change-Id: Ib057bd251604e9bae968e71de245b3bbf737a356