This change introduces new version 10 specific extensions, in
particular: the frequency hopping parameters of each timeslot.
These parameters are used to compose Channel Description IE
in the packet resource assignment messages.
In order to maintain backwards compatibility with version 9 of
the PCUIF, and thus to still be able to run test cases against
the latest release of osmo-pcu, I kept the old parts of the
INFO.ind and gruoped them together with the new records
into union 'PCUIF_InfoTrxs'.
During decoding, the content of this union is resolved by the
TITAN's RAW codec itself, depending on value of the 'version'
field. During the encoding, it's the responsibility of the
API user to set a proper field of the union. I implemented
both f_PCUIF_ver_INFO_{Trxs,PDCHMask} helpers for that.
Version 9 is kept as default, so this change can be merged
independently of the actual implementation. We can bump
it and remove the compatibility glue once the new versions
of both osmo-bts and osmo-pcu are released.
Change-Id: Idf11bc4ba3ff0b00b32f2beab8fd020c67119d05
Related: SYS#4868, OS#4547
This is required for the upcoming test cases running on hopping
channels. Dealing with module / hopping parameters in every
test case is definitely not a good idea, so let's add a function.
Change-Id: Ia4f078ebbb278246ee117f580ff93f301dc60f7c
Related: SYS#4868, OS#4546
They're going to be used in other modules too, not only in BTS_Tests.
Also, take a chance to rearrange the list of arguments, so the ones
with default values are placed after mandatory ones.
Change-Id: Ia33ebf2e680f16f774a981fc33422dfe5036637f
Some types of System Information (mostly the Rest Octets) are not
fully implemented, so calling the generic dec_SystemInformation()
may result in a DTE. Let's add dec_SystemInformationSafeBT() with
"prototype(backtrack)", so it would return a non-zero integer if
decoding fails. Let's add a wrapper dec_SystemInformationSafe()
that would additionally check the RR Protocol Discriminator.
Change-Id: Id4d73e0f3347e1d4c4c77aec75b767311d662292
Related: OS#4662
The testcase tests if a CHANNEL REQUEST on the RACH leads to the correct
CHANNEL REQUIRED message on RSL level. When a MS is sending a CHANNEL
REQUEST to establish an emergency call, it uses a slightly different
layout for the request reference (RA). Lets add another similar testcase
(TC_rach_content_emerg) to cover the emergency call situation as well.
Change-Id: Ie5b7af3e93efaa6d0b412d3b1c77bc9514424f52
Related: OS#4549
Not all osmo-bts backends do support multiple transceivers, while
we still want to run test cases against them. Let's make the
number of transceivers configurable (mp_transceiver_num), so it
can be adjusted depending on osmo-bts backend to be used.
Change-Id: Ic9dd49a2fc856de593b52b3ec0c559e0e15ca173
Related: OS#3155
This was removed when libfilter was removed from osmo-bsc.
For some strange reason apparently the config files were not used/tested
while testing the removal of libfilter.
Also, irrespective of breaking TTCN3 test execution, we must introduce
a dummy 'access-list' VTY command to osmo-bsc to ensure we don't break
virtually every config file out there.
Change-Id: I5d703b9f2f1066654daa43519999585cf9ec7e78
Unlike the RSL_IE_MS_Power, where power_level is 5 bit long, in
the RSL_IE_BS_Power it's 4 bit long. Fix this.
Change-Id: Ic0cb2275ef585754b9ae5e3d8077ca652afd9365
Another surprise from the latest osmo-bts release: it may send us
CCCH LOAD INDication message during the RSL bring up. Ignore it.
Change-Id: Iab22b620a5f7b07fe03c1b13bebef2931d14879d
This test verifies power ramping (up) is working fine during BTS
startup.
config files are updated to make sense:
* "nominal power" in osmo-bsc.cfg reflects correct default nominal tx
power of fake_trx.
* "osmotrx tx-attenuation" in osmo-bts.cfg is removed to let osmo-bts
use the value received through OML (max_power_red 20).
* "power-ramp step-size" in osmo-bts.cfg is increased to speed up the
test. There's no good reason to keep it lower.
Change-Id: Ieb7444c6312bbeab64da2732393b3facf3e1f003
- Get rid of f_L1CTL_DM_EST_REQ, it's not really needed.
- Derive ts_L1CTL_DM_EST_REQ_H0 from ts_L1CTL_DM_EST_REQ.
- Turn all its params into (value) templates.
- Turn it into a (value) template itself.
- Pass GsmArfcn directly to ts_L1CTL_DM_EST_REQ_H0.
Change-Id: I4f275e22d4309a23b4ed301a0779c4ecb92023a8
Related: OS#4546
Since change [1], the IPA emulation component allows us to handle
multiple IPA connections, thus multiple RSL connections. The idea
is to attach a TCP/IP connection identifier to each message.
On top of that, this change implements mapping between TCP/IP
connection identifiers and RSL stream identifiers, so we can
finally talk to any of connected transceivers (up to 4 for now),
not only the last connected one (as it was before). The actual
mapping is done during the IPA identification procedure.
Instead of forwarding ASP_IPA_EVENT_UP to a test case, the RSL
emulation component now sends a new event - RSLEM_EV_TRX_UP,
with transceiver number (actually, IPA stream-id) attached.
[1] I93c58c08cf296e5cea81d811650caa1a09b8a579
Change-Id: I86afb55ecc6703ce7a229aaa626223f9331a4778
Related: OS#4546
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>