The existing sampling duration of 8s was insufficient to collect
sufficient samples to confirm the scheduling rules.
Change-Id: I2f631935c86fb840cdd733c28b2df503512341fa
When our emulated PCU sends a DEACT.req to the BTS, there is no way
of knowing when exactly that command will have been completed: There is
no confirmation sent in response.
Let's introduce a f_sleep(1.0) to give the BTS sufficient time for
deactivating the channel.
This will make TC_pcu_deact_req pass reliably. It currently fails
in about one third of all test executions on jenkins.
Change-Id: Id9a559b8b208a60f71c3eb9a23830e4d2dbc5df9
In osmo-bts Change-Id If53fb07ec38f6bbc368ce84d14e59fa8167691d3
unfortunately the wording / syntax of the VTY was changed. Let's
adjust to the new wording.
Change-Id: I4a6d37febde104e70ce03992b7e2e8fb793b5a00
The first RACH LOAD IND may only cover a fractional reporting
interval, and hence must be ignored.
Change-Id: I32a703847fbf2b95993e910e6510613902e2bb1a
The first RACH LOAD IND may only cover a fractional reporting
interval, and hence must be ignored.
Change-Id: I43ee8e846803e2ef6218a3e7ac385ed8af30c217
f_init / f_init_pcu simply save the first PCU_INFO_IND
in g_pcu_last_info. That first one might still be wrong as
the PCU might connect to the BTS before the BTS is configured
accordingly.
Let's wait for 2 seconds and actually use the last (most recent)
PCU_INFO_IND for the test.
Change-Id: I45717605fde66bf870bcb6e2560f0fc753d05d95
Both osmo-bts and osmo-pcu are switching to PCUIFv10 soon, so let's
use the new version by default. For older (latest) IUT versions
not supporting PCUIFv10, one would need to override this module
parameter in {BTS,PCU}_Tests.cfg.
Change-Id: I9350c4a54434c3d46ce9424f382ca0057e58d053
Related: SYS#4868, SYS#4915
Pass transceiver number to f_resolve_fh_params(), otherwise the
hopping parameters would always be generated for TRX#0, and thus
the expectations for TRX#N > 0 would be wrong.
Change-Id: If1a25f5ff1b1bca900d54cc56e2045df5a81f4e2
Fixes: I9bb164fd2c7c48b91e0d7bd1abaf3cfec155342c
Related: SYS#4868, OS#4547
The bit-mask in fhp.ma_map.ma is octet-aligned, so we cannot use
its length. Use the number of transceivers instead, since they
all belong to the same BTS.
Change-Id: I772d13841babd2856b6b2fcf126ba47fb20b055a
Fixes: Ibebbedecaed0a3f24a1bc7b520013fa563c4bbda
Related: SYS#4868, OS#4547
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>
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
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
Extra debugging is added because otherwise it's extremely difficul to
find at which state the test is when debugging sporadic failures.
In f_TC_rec_invalid_frame, timer T is reused because it was actually not
being used before, only defined in there.
Change-Id: If24a81bf20d293b87adf9f37111fc7d344f169f5
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
Some stuff was wrong and some was missing after new features being
implemented in tests over time.
Change-Id: I7a279592a68ffc76408a8e728e76151534265cc0
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
All MS/UE must be notified of ETWS Primary Notifiations.
Depending on their state, the notification goes different paths:
* CS dedicated mode: BSC sends it as L3 message over LAPDm / DCCH
* CS/PS idle mode: BTS sends paging messages on PCH
* PS TBF active: PCU send Packet Application Info
This tests the last of the three methods by checking that a ETWS Primary
Notification sent on RSL to the BTS is received by the PCU socket.
Change-Id: I2661df7f7d870a0ac1c89bb8a85df81644b00b0a
Related: OS#4047, OS#4048
Depends: osmo-bts Ic0b3f38b400a0ca7e4089061ceb6548b0695faa6
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
Base on docker-playground.git's ttcn3-bts-test/*.cfg files, change IPs
from 172.18.9.* to 127.0.0.* (last octet unchanged).
Change-Id: I9eb2bb4599a4e874424f73483d9658a4467b8b8c
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
Since [1] we additionally filter Access Bursts by the link quality
(defined by C/I) in L1SAP, and since [2] we do provide the actual
C/I values for osmo-bts-trx, as was received from the transceiver.
[1] https://gerrit.osmocom.org/r/I893ec9c6c2ebad71ea68b2dc5f9f5094dfc43b78
[2] https://gerrit.osmocom.org/r/I8d86dec7ebc039cbfd038c4342ff328b11281865
The default minimum C/I for Access Bursts in OsmoBTS is 50 cB,
while the TTCN-3 test cases configure fake_trx.py to send 0 cB,
so all Access Bursts are getting dropped, as expected.
Let's use 60 cB (or 6 dB) by default. This change makes Access
Bursts pass again, and thus fixes some broken test cases.
Change-Id: Ic345f7995c2553e346590cd851f8857d26e7beb2
The idea of this test case is to verify that the link quality
measurements, in particular C/I (Carrier-to-Interference ratio),
are delivered to the PCU (as a part of PCUIF_DATA.ind).
The C/I ratio needs to be calculated by the transceiver from the
training sequence of each burst, where we can compare the "ideal"
training sequence with the actual training sequence and then
express that in cB (centiBels).
This test case can only be executed with fake_trx.py and trxcon,
because this pair allows us to simulate C/I values. Also, the
new TRXD header format needs to be supported (see OS#4006).
Change-Id: I67d89b2f0e13a7a6f74f001b19d37add77ec06f5
Depends: (OsmocomBB) I7080effbbc1022d1884c6d6f0cb580eba8e514ff
Related: OS#1855
osmo-bts does currently not use the signaled lchan BS power level, nor
does it update the BS power IE returned in the measurement results.
Change-Id: If91fb57b4070c60bb277d0b55d69ee3dde47ee48
Harald Welte
Alexander Couzens
Vadim Yanitskiy
Philipp Maier
Pau Espin
Oliver Smith
Eric Wild