This template is not (yet) used anywhere, but let's fix it
anyway to avoid possible confusion.
Change-Id: Ic819f2b0eb292170de73abc7e200d79fcf02a76c
Signed-off-by: Vadim Yanitskiy <axilirator@gmail.com>
The resulting frame number shall be within the period of TDMA hyperframe.
Change-Id: I794a14f69293cbbc937d62d09dd5794956b882db
Signed-off-by: Vadim Yanitskiy <axilirator@gmail.com>
Most of existing test cases are built on top of the PCU interface
abstraction components (see PCUIF_Components.ttcn). This means
that during the test case execution, additional components are
running in parallel, among with the MTC (Main Test Component).
When a test case terminates, either normally or due to an error,
it may happen that the virtual BTS component is stopped before
the associated TDMA clock generator. In this situation, sending
a clock indication towards the stopped BTS component would
lead to a dynamic test case error.
Let's take the process of tear down under control, and ensure that
the clock generator is stopped first. To achieve that, every test
case needs to call f_shutdown() in case of an error, as well as
in case of the normal termination.
Note we cannot use the existing f_shutdown() from Misc_Helpers,
because doing 'all component.stop' does not gurantee that the
clock generator is stopped first, and I experienced at least
one DTE while trying to integrate it.
Change-Id: I6a859687d9605cc08c51ff44d946c279b79bedfa
Signed-off-by: Vadim Yanitskiy <axilirator@gmail.com>
This test case would not fail even in case of Timing Advance mismatch.
Change-Id: Ife86e5e0e39f0112b854ed9a13e9c6f3c49531c9
Signed-off-by: Vadim Yanitskiy <axilirator@gmail.com>
We don't need a copy of the whole RR Immediate Assignment message.
Change-Id: I44417460126e507a0a47a5aee8c4a995085023fa
Signed-off-by: Vadim Yanitskiy <axilirator@gmail.com>
In response to a CHANNEL REQUEST received on BCCH, the network
would never allocate a Downlink TBF, so we should always expect
an Uplink TBF assignment.
Change-Id: I6b4c108bed39ba9ac9b6144827bc1e20b04333b4
Signed-off-by: Vadim Yanitskiy <axilirator@gmail.com>
Back in September 2019, while writing the first lines of the new
test infrastructure for OsmoPCU, I picked a random value as the
default RA (CHANNEL REQUEST message) for Uplink TBF establishment.
It has been accepted by the IUT so far, and still works, but
according to 3GPP TS 44.018, table 9.1.8.1, value '3A'O has
nothing to do with GPRS - it actually means 'Answer to paging'.
The new value belongs to range '011110xx' - one phase packet
access with request for single timeslot uplink transmission.
Change-Id: Ic036d380af3667d54a3a0a011a9d56a87e0f949b
Signed-off-by: Vadim Yanitskiy <axilirator@gmail.com>
The PCU interface has nothing to do with UDP...
Change-Id: I8d919e686c6ef311517eb53496d008987f984794
Signed-off-by: Vadim Yanitskiy <axilirator@gmail.com>
So far we only checked presence of GPRS Indicator in the Rest
Octets of System Information Type 3, but this indicator is
also included in the Rest Octets of System Information Type 4.
Let's add additional test cases to check this indicator in the
Rest Octets of both message types. In order to achieve this:
a) refactor f_si3_has_gprs_indicator(), so it can handle
System Information Type 4 and its Rest Octets too;
b) separate common part from the existing test cases into
functions and (re)use them from the new ones;
c) in f_TC_pcu_socket_noconnect(), make sure to send
BCCH INFO with System Information Type 4.
Change-Id: Ifc589c35a52a62331b0ad4fbe2eec3fba55b5ff9
Signed-off-by: Vadim Yanitskiy <axilirator@gmail.com>
Related: OS#3075
This is needed for the follow up change(s) verifying the GPRS
indicator in the Rest Octets of RR System Information Type 4.
Change-Id: I540b43bbe886f8ca3e9a7eb49a4d30d391d45f49
Signed-off-by: Vadim Yanitskiy <axilirator@gmail.com>
Related: OS#3075
We do have GPRS Indicator in SI3 Rest Octets, but for some reason
it was absent in SI4 Rest Octets. Let's finally enable it, so we
can extend the existing test cases to check GPRS Indicator in the
Rest Octets of both System Information Type 3 and 4.
Change-Id: Ib55c2673b53b5981e57372f4f8cfb0af32e04132
Signed-off-by: Vadim Yanitskiy <axilirator@gmail.com>
Related: OS#3075
Finally, we can get rid of hard-coded octetstrings and control
every field of the Rest Octets we're sending to the IUT.
Note that template 'ts_SI4_default' did not contain any Rest
Octets at all, thus the GPRS indicator was (and still is)
absent. This will be fixed in a follow up change.
Change-Id: I0a95b34b495267edf1f48692e24fcd5ede8ccdd1
Signed-off-by: Vadim Yanitskiy <axilirator@gmail.com>
Due to a buggy nature of TITAN's padding attributes [1], we cannot
apply them to individual fields of the records that are embedded
into other structured types, like records and unions.
Ensure that encoded System Information messages are padded to
either 23 or 19 octets, depending on their type. In order to
achieve this, rename and wrap the external encoding function.
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=562849
Change-Id: I3368df52985e576ad180c9a74d4925dd9c952b55
Signed-off-by: Vadim Yanitskiy <axilirator@gmail.com>
As it turned out, the length constraints introduced in [1] were
too strict. In particular, the use of FIELDLENGTH attribute made
it impossible to assign an octetstring of a smaller size and then
pad the remaining octets with '2B'O. TITAN would just use '00'O
instead, ignoring all my attempts to talk some sense into it.
[1] I183d3ba9000e3ced8ecce74a4390b80075ddf25d
Change-Id: Ie1b6d4100c064b6ae08ed55cd797b9416c6faf14
Signed-off-by: Vadim Yanitskiy <axilirator@gmail.com>
The 'RestOctets' is a sub-type of the 'octetstring' with additional
padding attributes. Let's use it for SI2bis, SI2ter, and SI6 too.
Change-Id: I183d3ba9000e3ced8ecce74a4390b80075ddf25d
Signed-off-by: Vadim Yanitskiy <axilirator@gmail.com>
Both are basically sub-types of GSM_RR_Types.RestOctets with length
constraints. We don't really need to have them as separate symbols,
especially since we have SI3RestOctets and SI4RestOctets now, so
let's apply these constraints within the corresponding records.
Change-Id: I2b126348ae5c5425fea4267ab2b77ea0192795ac
Signed-off-by: Vadim Yanitskiy <axilirator@gmail.com>
Optional "Rest Octets S" part is left for later.
Change-Id: Ib0814e79f8627f3e2b4746b7e521e06ff82bf2d7
Signed-off-by: Vadim Yanitskiy <axilirator@gmail.com>
Commit [1] introduced multiple regressions, because it basically
changed the byte order in all fields of the whole module from
'first' (implicit default) to 'last'. This is not what we need.
Instead, let's apply BYTEORDER(last) to 5 bit 'ext_ra' fields
unless the bug [2] in TITAN's RAW codec is fixed.
[1] I481a40daef3eed4a3daa687ad87c4128a13181b4
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=562488
Change-Id: If998ef72c13787f04fee79e1e646cd9a6787028a
Signed-off-by: Vadim Yanitskiy <axilirator@gmail.com>
They will be used by tests, templates and RLCMAC_EncDec.cc itself.
MCS HEader Type 1 and 2 to CPS conversion lefts as a TODO with
placeholder functions to easily implement when needed.
Change-Id: I18ff55a8067165bf081bf21473b4f88af955bf5b
RLCMAC blocks have a lot of fields and we will potentially require lots
of different templates, as well as functions to handle related structs.
Change-Id: I9c6597178168aa3848b21930f33be698dd2ce545
Delete PCU_Tests.ttcn along with the configs, since they are broken and
we are only adding new tests to PCU_Tests_RAW.ttcn. They are broken
because it's not possible to run multiple tests after another.
Some components which used to be in PCU_Tests.ttcn and which were used
by other PCU_Tests*.ttcn files have been moved to SGSN_Components.ttcn
Selftests have been moved to PCU_selftest.ttcn.
Small placeholder for module PCU_Tests is left in PCU_Tests.ttcn to
still be able to compile the binary as "PCU_Tests" and avoid changing
that part of docker setup. We'll eventually rename RAW tests soon
anyway.
Change-Id: Ie862a1525e9f4f9a3f2427ac3898810e3d044d2f
function helpers are slightly modified or added to accomodate for fields
in egprs data blocks being in different places.
Change-Id: I570fb7346519b2a161515e0ec40bd1870a89d673
* RlcmacUlBlock and RlcmacDlBlock gain a new union field "egprs_data",
which is chosen when msg contains an egprs data block. Hence one can
use same structure for both gprs/egprs data and simply check
"ischosen(block.data_egprs)" to know whether it contains egprs or gprs
data block.
* C++ code in RLCMAC_EncDec.cc takes care of encoding and decoding of
each data header type and exposes a generic ttcn3 struct
"UlMacDataHeader" and "DlMacDataHeader". Decoded header type can be
found in mac_hdr.header_type. This can be used t5ogether with CPS to
get the MCS of the message received. Similarly, the encoder will use the
same field to know how to encode the ttcn3 structure.
* In RLCMAC_EncDec.cc order of functions has been ordered to split
between encoding and decoding, and inside these split between Ul and
Dl messages.
* Only encoding of UL HeaderType3 and decoding of Dl HeaderType3 is
implemented so far in RLCMAC_EncDec.cc. However, all code is already
arranged and functions prepared (with FIXME fprintf) to easily add the
missing header types once needed.
* Actually only the decoding of DL HeaderType3 has been tested to work so far.
Encoding may still be missing to octet-align the data block after the header.
All these wil lbe fixed once a test using them exists.
Change-Id: I2bc4f877a5e17c57ffa8cf05565dc8593b45aae8
On top there's a lot of types related to data blocks. Having more
stylish section header helps orientating one self while looking through
the data blocks.
Change-Id: I87d4694031ea6874b233626818824cdc4f3505c6
Change [1] introduced a regression: PCU_Tests_RAW.TC_pcuif_suspend
fails since build #443. I have no idea why the BYTEORDER should be
set to 'first' (and not 'last'), but this is the only way I could
make TITAN's RAW encoder generate a valid MCC/MNC pair again.
[1] I481a40daef3eed4a3daa687ad87c4128a13181b4
Change-Id: I70a5b2eed3788be10d62fa421e3ba7444d66c655
Test sending MS RA capabilities through Packet Resource Request to
update GPRS multislot class.
EGPRS multislot will come in a later commit.
Change-Id: I5026d8b78a3fb82093956b65989d18fa6f6d5424
This test case initiates the packet Downlink assignment procedure
by sending a DL-UNITDATA PDU containing a random TLLI and checks
Timing Advance value indicated in the Immediate Assignment.
Currently fails due to a bug in the IUT (TA=220).
Change-Id: I410abedcc549495f30b5355d399a85648408a946
This change introduces three similar test cases:
- TC_egprs_pkt_chan_req_signalling,
- TC_egprs_pkt_chan_req_one_phase,
- TC_egprs_pkt_chan_req_two_phase,
which basically send several 11 bit RACH.ind messages to the IUT
containing different variations of EGPRS Packet Channel Request.
Depending on the establisment cause, for each RACH.ind we expect
to receive an Immediate Assignment containing an EGPRS Packet
Uplink Assignment in its Rest Octets.
All test cases make sure that Request Reference in the received
Immediate Assignment messages is set to 127 as required by 3GPP
TS 44.018 (see table 9.1.8.1, note 2b), and the Extended RA IE in
the Rest Octets matches 5 LSBs of the RA value that was sent.
Change-Id: Ib5732956ea160f93d82f06bf82bea45501f439d2
Related: OS#1548