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
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>
Since build #842, both TC_paging_{i|t}msi_80percent started to fail:
"BTS_Tests.ttcn:3051 : Expected 271 pagings but have 284"
BTS_Tests.ttcn:6414 BTS_Tests control part
BTS_Tests.ttcn:3051 TC_paging_imsi_80percent testcase
"BTS_Tests.ttcn:3075 : Expected 543 pagings but have 553"
BTS_Tests.ttcn:6415 BTS_Tests control part
BTS_Tests.ttcn:3075 TC_paging_tmsi_80percent testcase
As it turns out, since If5339c7a91b4e0188194f1cd935798f153974e01
TITAN can decode PCH filling messages with no Mobile Identity.
We should not count them in as_l1_count_paging(), as they're
sent by osmo-bts itself.
Change-Id: I420f36ed000b1c2488fbe500c33a8161e27d20e3
Fixes: OS#4475
We actually need to check if a MI is present, i.e. not omit.
ispresent(omit) => false
isvalue(omit) => true
Change-Id: I0e24e2aaa1f0da7ffdbc93ea4a19491e5dfb39b4
All the records related to Mobile Identity IE (see 3GPP TS 24.008,
section 10.5.1.4) are defined in [1], so there is no real need to
dumplicate them. Moreover, most of the related templates in
library/L3_Templates.ttcn are based on these records.
[1] titan.ProtocolModules.MobileL3_v13.4.0/src/MobileL3_CommonIE_Types.ttcn
Change-Id: I27c2743c59db770d6f7e9447dc8c1f539b228ced
A new module is created since its tests are aimed at running against
real HW set ups to check performance of the system under high loads.
As a result, tests in here will usually require a specific config file.
One first test is introduced to activate all TCH/H channels and see if
the BTS (+BTS-TRX) can keep on going fine for a while.
Related: OS#4365
Change-Id: I2d5f0043bdee1f8f5edcf46acce79ce547d1333d
Some tests need direct access to the pcu socket, however, when working
with hardware bts this socket is not always available. The tests that
depend on the pcu socket are then skipped by the testsuite.
The following tests are not automatically excluded, but require direct
PCU access. Lets exclude them as well:
- TC_dyn_osmo_pdch_act_deact
- TC_dyn_osmo_pdch_double_act
- TC_dyn_ipa_pdch_act_deact
- TC_dyn_ipa_pdch_act_tchf_act_nack
Change-Id: I735b85d2ff3f541ebf0a558735d6172d69e7c29f
Related: OS#3863
On channel establishment the first measurement result may lack the
measurement reports from the MS. This is normal behavior, so lets
tolerate that.
Change-Id: Ib2f511991349ab15e02db9c5e45f0df3645835a4
Related: OS#2975
New generic ms power loop algo takes into account the MS Power sent by
MS over L1 SACCH Header. As a result, the test infra must now update its
transmitted value according to what is requested by the BTS as if it was
a real MS in order for algo to output expected results.
Requires osmocom-bb I975cfc5f5d63eb32a7f8932a7f6a544c9a12233c to have
transmitted MS power values for dummy Meas Results updated as requested
over L1CTL.
Change-Id: I287761202093fbc1064f9868efe6f7f6155253ca
Since there can be multiple PDCH channels configured on different
timeslots, different TRXes, and BTSes, the PTCCH/U handling code
in OsmoPCU needs to know the exact origin of a given RACH.ind.
Otherwise, it is not known which subscriber originated a given
PTCCH/U indication, and hence it is impossible to send PTCCH/D
Timing Advance notification properly.
Fortunately, we can extend the RACH.ind message without even
bumping the protocol version, because every single PDU has a
fixed size defined by the largest message - INFO.ind. In case
if the actual message payload is smaller, the rest is filled
with a constant padding byte (0x00).
Older versions of OsmoPCU will consider the new fields as padding,
while the messages from older OsmoBTS versions will always have
both fields set to 0x00. Since C0/TS0 cannot be configured to
PDCH, this can be easily detected on the other end.
Change-Id: Ia5c4e504a21dc5508920553d3856027455dba1b1
Related: OS#4102, OS#1545
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
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
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
This reverts commit c089b415f5. The
additional sleep caused other tests to break, probably because it
triggered race conditions:
* TC_pcu_socket_connect_multi
* TC_pcu_socket_connect_si3gprs
* TC_si_sched_13_2bis_2ter_2quater
Adjust TC_pcu_socket_verify_info_ind test case error message to mention
OS#4179. This test is flapping now, most of the time the BTS sends a
CellID 0 because it did not receive the real CellID from the BSC yet.
Related: OS#4179
Change-Id: I2115c337f4601a4614b140715323c42803b003ee
Verify that the CellID of SI3 (TS 04.08 9.1.35) and other values are
passed properly to the PCU socket. A bug in OsmoBTS is currently causing
it to send a byte-swapped CellID, related fix is in [1].
[1] I68faf4558f0686fb2a3db24077dceaae05bf0262 (osmo-bts)
Related: OS#3854
Change-Id: I6516808f4b9e9a2301f9ccc1e55ded14e7334c33
Give the emulated BSC side some time to send the various SI via RSL.
This workaround makes OsmoBTS send the correct CellID and other
information instead of empty values to the PCU socket. The next commit
tests these values.
Related: OS#4179
Change-Id: I547f2b8e0796b6976506c28b1b493b1f5bce28f8
Vadim Yanitskiy
Philipp Maier
Neels Hofmeyr
Pau Espin
Oliver Smith