This way it's consistent with ts_RSL_ChanMode, and there is
no need to pass dtx_downlink := false as the first param.
Change-Id: I0b87ef87f8cfff1c96b0beead29d549d5fe0b7c6
The testcase TC_meas_res_sign_tchX activates a traffic channel in
signalling mode and checks the RSL resulting measurement reports.
The CHANnel ACTIVation message sets "SDCCH" as "Channel rate and Type"
value. This is invalid, the "Channel Rate and Type" sould be set to "Half /
Full rate TCH Channel Lm / Bm" (while the speech or data indicator is
still set to "Signalling")
Change-Id: I51887b0d0379fcc1f4483d08dfdd6869e7a9f963
Related: OS#4799
This test case is very similar to TC_ms_pwr_ctrl_constant(), but the
key difference that we simulate sharp UL RSSI changes between -50 dBm
and -100 dBm on each iteration.
The 'uplink-power-target' (-75 dBm) is right in the middle of the
change range, so with EWMA filtering and 80% smoothing it's expected
that all averaged UL RSSI values would be around -75 dBm.
It's expected that the Uplink power level remains constant, however
this test case fails at the moment. The problem is that the IUT is
still quite sensitive to small deviations from 'uplink-power-target',
so ideally we should introduce a 'hysteresis' defining a range:
['target' - 'hysteresis' ... 'target' + 'hysteresis']
in which the MS power loop should not trigger any power changes.
For example, let's say:
'uplink-power-target' is -75 dBm (default), and
'hysteresis' is 8 dBm,
so then the range would be: -83 dBm ... -67 dBm.
Change-Id: I3be1a4a4a0ab7eebb9a930eee7039295c045a791
Depends: Iacedbd4d69d3d74e2499af5622a07a8af0423da0
Related: SYS#4916
The new test cases are similar to TC_meas_res_sign_tch{f,h}, with
the only difference that TCH channels are activated in speech mode.
Change-Id: I8455e3749ab72a463c00dd0ed28b69ef6f389aa1
Related: OS#4799
Otherwise the L1 (trxcon or Calypso PHY) would 'think' that we're
in signalling mode, and would not send us Bad Frame Indications.
Change-Id: I0ade3bd63f604c7f0665124b182a023d50030d0b
Depends: I6f403ed0506b4b1872361d9976d3186bfe514b52
Related: OS#4799
This test case is aimed to verify that the MS power level remains
constant when 'rx-current' does not change and equals 'rx-target'.
Change-Id: Ifdafa03506102ff15f4d6dc304fff7d7e8f48170
Related: SYS#4916
BTS_Tests.ttcn:3647.9-3703.1: In function definition `f_TC_imm_ass':
BTS_Tests.ttcn:3661.37-99: In the operand of operation `valueof()':
BTS_Tests.ttcn:3661.58-98: In actual parameter list of template
`@GSM_RR_Types.ts_ChanDescH0':
GSM_Types.ttcn:125.48-55: warning: Inadequate restriction on
the referenced template parameter
`sub_slot', this may cause a dynamic
test case error at runtime
GSM_Types.ttcn:126.8-9: warning: Inadequate restriction on
the referenced template parameter
`tn', this may cause a dynamic test
case error at runtime
Change-Id: I7d36d25e5f8d3bb1040c737eeaeddd15f98ec4c2
When several TRX are set up, it can be that in between a RSLEM_EV_TRX_UP
event and the related tr_RSL_RF_RES_IND for that TRX, we receive a
RSLEM_EV_TRX_UP from another TRX which got just connected in parallel.
Change-Id: I1296c76c1d97e6704340484994ff3921975146b9
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
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
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
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
The testcase failed becaues of an unexpected RSL Error Indication from
the LAPDm system which was in the RSL emulation queue when tearing down
the test environment.
By calling f_rsl_chan_deact() the queue gets flushed until the RSL
deactivate channel is received. It's also more clean to release the
channel.
Fixes: OS#4051
Change-Id: I55827626803ca81b68f905fd0df3126367951f39
A large number of our tests is currently failing with
BTS_Tests.ttcn:341 Dynamic test case error: IPL4 Test Port not mapped
which was introduced by Change-Id Ie7d311bf8f03bf9b1d29b5bb28ffad793f215fd1
Change-Id: Ia1ef4ac7dcfec137a8613bc49a7f312d81a86153
Before this patch, sending special TRXC commands to FakeTRX, such as
FAKE_TOA and FAKE_RSSI, from ConnHdlr resulted in a receive timeout
waiting for the response.
As it turned out, both the test_CT and the ConnHdlr have a TRXC port,
as depending on the test one would want to globally control it
from test_CT or from within a ConnHdlr.
However, only one of the two should be active (connected) at any given
point in time. Otherwise we'll have two UDP sockets on the same bind
port, and it's more or less random on which of them it ends up.
Let's add an optional parameter 'trxc_comp', which would indicate
whether we need to control TRXC from ConnHdlr or not.
Let's get rid of both f_trxc_connect() and f_main_trxc_connect(),
which basically do the same, but run on different components.
Change-Id: Ie7d311bf8f03bf9b1d29b5bb28ffad793f215fd1
Closes: OS#4039
This adds the following test cases to BTS_Tests_LAPDm.ttcn:
* TC_sabm_retransmit_bts()
* TC_sabm_invalid_resp()
* TC_sabm_dm()
* TC_establish_ign_first_sabm()
* TC_iframe_seq_and_ack()
* TC_iframe_timer_recovery()
Change-Id: I4e1136c0c0f10d5bc8d01e826ae5d92f17a0b2aa
The f_init() function itself can very well derive the identity using
the built-in testcasename() function. There's no need asking users
to do that - many of them don't do it in the first place :/
Change-Id: I17a61a84fba4df31b8baab1f631c8aa55d894dbd
The idea of this test case (as can bee seen from its name) is to
verify handover RACH detection. What we basically do is:
1. Activate a logical channel on the BTS side (HO_SYNC for now);
2. Switch the MS (e.g. trxcon) to that channel without waiting
for Immediate Assignment and sending Access Burst;
3. Send an Access Burst on that channel using RA = HO_REF;
4. Wait for RSL HANDOver DETected from the BTS;
5. Release a dedicated connection.
There is no way to verify if the Handover Reference received
from the MS matches the one that was sent to the BTS. We can
introduce a separate test case that would just send an Access
Burst with RA != HO_REF.
Change-Id: If2e8d9c9947823df62f4bcc9a7fcd20734ff7858
Depends on: (trxcon) Ia967820a536c99966ba2c60b63d2ea9edb093f46
In BTS_Tests.ttcn we used to compose L1ctlDataReq manually. This
can be done by ts_L1CTL_DATA_REQ_SACCH() template itself, so
let's abstract BTS_Tests.ttcn from doing that.
Change-Id: I1ae948bd0314cdf15c21ce4b6346d5e32f1fcf95
When no PCU is connected to the BTS, the BTS should mask the GPRS
indicator from the SI3 rest octets to indicate "no GPRS support"
in the cell. This will cause phones not even trying to send us
RACH requests for GPRS ATTACH, RAU, etc.
Change-Id: I37efb712ee0c513aea230beeb35e7dabce698a34
Related: OS#4023
Related: OS#3075
This test will currently fail due to a MODE MODIFY NACK, even though the
channel mode is not modified.
Related: OS##3750
Change-Id: I4cbea499bb6a331d314e6573548a4540945208b5
When executing the test on our build slaves, we ran into the following:
> Number of TDMA Frames (1100) not matching (1073 .. 1093)
> Number of TDMA Frames (1096) not matching (1073 .. 1093)
So it seems the tolerance was a bit too tight. If the timer runs
for a bit more than the requested amount of seconds (e.g. due to
high system load), the number of TDMA frames is likely a bit higher
and hence we need to permit a larger tolerance.
Change-Id: Ib00bb7e7f223fb0329d00e3835127b8c31299e27
This adds TC_pcu_socket_connect_multi, which verifies that a second
connection to the PCU Intrerface socket is denied while the first
connection is still established.
Change-Id: Ib484a0a39e719cb2ce00a9464fc1207357ec9e93
Related: OS#4023
In OsmocomBB/trxcon Change-Id Ia94ebf22a2ec439dfe1f31d703b832ae57b48ef2
we introduced a new mode CCCH_MODE_COMBINED_CBCH to indicate that the
channel combination is a CCCH+SDCCH/4 with one SDCCH stolen for CBCH.
Let's make sure we actually use that mode in our CBCH related tests
Change-Id: I27ee2c81bec7175c1ea09d4f3f6037f2866fe242
Some of our files didn't have a copyright notice at all, let's add
it. Also, update the notices in other files and ensure a SPDX
identifier is present in all but the most trivial files.
Change-Id: If7fa19ce484b415bc645e39b3d0d666b44b5f0fd
This test opens a SDCCH and sends a RR SUSPEND message from the
simulated MS. It then expects the BTS to pick that up and forward
it to the PCU socket rather than via RSL to the BSC.
Change-Id: I4da6e9d7c5dfbd0e017d2a63c6474da700c38e52
Related: OS#2249
Related: OS#4023
The four existing test in BTS_Tests.ttcn so far didn't have any chance
to verify if the invalid messages actually ended up on the air interface
or not. By using virtphy instead of trxcon, we can finally add that missing part.
Change-Id: Ie05d6b1530bd4d4cf4eaa574b068870682439ee4
Related: OS#4023
As trxcon+fake_trx don't have GPRS (TBF) support yet, we cannot do
any PCU related tests involving the Um interface yet. Instead, let's
use virtphy to fill that gap. Using virtphy, we can actually
receive/transmit GPRS blocks on the simulated Um interface.
TC_pcu_data_req_{pdtch,ptcch} are moved to a new test suite
"BTS_Tests_virtphy.ttcn" which should symbolize that the related tests
are to be executed with osmo-bts-virtual + virtphy instead of
osmo-bts-trx + fake_trx + trxcon.
You also have to set the following module parameter to make this work:
BTS_Tests.mp_bts_trxc_port := -1
Related: OS#4023
Change-Id: I677f660b1076148b3317b08b06eb3d6551d9b577
This new test verifies that the expected amount of PCUIF_RTS_REQ are
observed on the PCU Interface for both PTCCH and PDTCH.
Change-Id: Ic27cdd4f4adf11f871b84bd72692a03280274fe2
Related: OS#4023
As we don't yet speak OML directly from the TTCN3 test suite,
this requires a currently "RFC/WIP" state patch turning OML
Failure Event Reports into CTRL TRAP on the BSC, see
https://gerrit.osmocom.org/#/c/osmo-bsc/+/14177
Change-Id: I6c7641b37b6ee2177d43127140cc0b625409379c
Depends: osmo-bsc I4f8a9737c6ef1b951ea8e742cdbd3689371a99d5
Related: OS#4023
Add three BTS_Tests.ttcn test cases for verifying the BTS behavior
regarding CCCH LOAD IND (RACH).
Related: OS#3750
Change-Id: I6c9dee1d7d3eaa218fdce7ebb8e334858aedb736
This introduces a set of CBCH related tests for osmo-bts.
Warning: Those tests currently require a patched trxcon to work.
Related: OS#4011
Change-Id: I955b4000c12180a39b0205b69b7b2c8cee8c9da3
Those two new tests test the subtle rules related to how the presence
of certain IEs in the RSL CHAN ACT influence when exactly DL SACCH
transmission should start during hand-over related channel activation.
Change-Id: Ia88f3ab160891cdbbb8fa6e765f137edd04c6e81
Related: OS#3570
Related: OS#4008
Related: OS#4009
According to 3GPP Ts 48.058, every logical channel can receive some
specific SACCH filling at the time of RSL channel activation. This
overrides the global SACCH FILLING.
Related: OS#3750
Change-Id: I8adb371a7e0b80792dd2fa35e5204802068df5ba
Section 7 of the RSL specification (3GPP TS 48.058) describes how the
BTS shall respond in various error situations, including wrong message
type, wrong message discriminator and invalid message sequences.
Let's add three test cases for the above three scenarios.
Change-Id: If507a14bbed9cdcc62cd966468222186590fc965
Related: OS##3750
The module parameter mp_ipa_up_delay ads a delay after the ipa bring up.
This is relevant for the tests with real BTS hardware, but it is not
relavent for the regular TTCN3 tests.
Lets set the default to 0.0, since the delay caused problems with
TC_rsl_ms_pwr_ctrl and TC_si_sched_13_2bis_2ter_2quater.
Change-Id: I7663cad5df1ee5a8bcdbbf522881999f1be9f4fe
Related: OS#3960
When running tests with real hardware it is important to wait for some
time (3 sec. should be enough) before exiting f_init(). This is to
ensure that the BTS supplies a stable carrier before the test proceeds.
Change-Id: Ib78633a33a15cd40514e15b6ebf9a0a8fb7b9c68
Related: OS#3863
The default value for the module parameter mp_ipa_up_timeout is set to
10 sec. Given that the sysmobts needs around 10-11 sec. to perform one
restart cycle this is to low and causes tests to fail occasionally. Lets
increase the default value to 15 sec to get reliable.
Change-Id: I5bb290d00a02a25672305688352a03f3bf484ff3
Related: OS#3863
According to 3GPP TS 04.60, section 11.2.5a, the extended (11-bit)
Access Burst on RACH/PRACH is used by the MS to indicate its EGPRS
capability. One of the alternative synch. sequences (see 3GPP TS
05.02, TS1 and TS2) shall be used.
Add a test case to verify extended (11-bit) RACH decoding.
Depends: (OsmocomBB) I36fd20cd5502ce33c52f644ee4c22abb83350df8
Change-Id: I8fe156aeac9de3dc1e71a4950821d4942ba9a253
Related: OS#1854
When running PCU-related tests against BTS use name of the test as a PCU
version string sent from TTCN-3 code. This makes it easier to separate
OsmoBTS log output related to different test cases.
Change-Id: I9ef9e46061ef116529bdea196050f914804615b3
By default Misc_Helpers.f_shutdown() will set test verdict to
'none'. Let's fail test explicitly if we had any timeouts.
Related: OS#1854
Change-Id: Ifff8b3b83eeedea0d308f7ab0bfe347e2dc278c8
Previously the first timeout in TC_rach_content() caused test to
fail. Related TC_rach_count() test shows that there're some (13-16 out
of 1000) RA values which are problematic. Let's log all such values in
TC_rach_content() before failing the test to, hopefully, spot the
pattern which sets such RA values apart.
Change-Id: Ibfeb377101f406608c0193f08729c0e6d084281e
Related: OS#1854
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.
Change-Id: If11ef05d97aa5f6caaa731f3817c1fecfc3edf7c
It was observed that 'BTS_Tests.TC_rach_max_ta' started to fail
with the following reason: "BTS_Tests.ttcn:1091 : RACH passed
but was expected to be dropped: -2560".
My initial assumption was that the test case basically sends
FAKE_TOA command on a wrong TRXC interface, and it was
confirmed using trx_sniff.py:
# TRXD of the BB side
$ ./trx_sniff.py -p 6700
[DEBUG] trx_sniff.py:110 L1 -> TRX burst: fn=616 tn=0 pwr=0
[DEBUG] trx_sniff.py:110 TRX -> L1 burst: fn=597 tn=0 rssi=-60 toa256=-2560
[DEBUG] trx_sniff.py:110 TRX -> L1 burst: fn=598 tn=0 rssi=-60 toa256=-2560
...
# TRXD of the BTS side (Uplink bursts only)
$ ./trx_sniff.py -p 5700 --direction L1
[DEBUG] trx_sniff.py:110 TRX -> L1 burst: fn=719 tn=0 rssi=-60 toa256=0
and additionally be enriching logging messages of fake_trx.py:
[DEBUG] fake_trx.py:186 (trx@0.0.0.0:6700) Recv FAKE_TOA cmd
Sending FAKE_* commands on TRXC interface of the BB side affects
the bursts being forwarded to this side, so we should use the
TRXC interface of the BTS side to simulate Uplink delay.
The reason why the test case has been passing some time ago is
that there was a bug in fake_trx.py, that has been fixed recently.
This patch makes 'BTS_Tests.TC_rach_max_ta' green again ;)
Change-Id: I7736abd85407c186856be9f1a22613a1fa6e0c32
Usually the MS power is controlled by the BTS and there is no continous
supervison by the BSC needed. However, a scheme where the BSC takes care
of the power control loop exists. The power is then set via RSL using an
RSL MS POWER CONTROL message.
This tests establishes a dchan and then sends MS POWER CONTROL messages
with differen power levels and then checks the presence of the power
level set in the MS POWER LEVEL field of the SACCH L1 header.
Change-Id: I82b04a3bf94d355175f7f6ff3fdc43672e8080a2
Related: OS#1622
With some real HW setups, there's no PCU (osmo-pcu) available locally,
for instance when using a sysmobts, or when using a nanoBTS. There's no
need to waste time and generate extra output by running this tests in
this case.
Furthermore, some tests seem to crash sometimes in that setup, probably
due to using invalid fd (-1):
MTC@801a0da9866a: Setting RSL_SYSTEM_INFO_4 (4): '31061C62F224002A4740E50400'O
/osmo-ttcn3-hacks/bts/BTS_Tests: Segmentation fault occurred
/usr/lib/titan/libttcn3-parallel-dynamic.so(_Z14signal_handleri+0xa3)[0x7f0c33b48073]
/lib/x86_64-linux-gnu/libc.so.6(+0x33060)[0x7f0c321aa060]
/osmo-ttcn3-hacks/bts/UD_PT.so(_ZN12UD__PortType15UD__PT_PROVIDER13outgoing_sendERKN9UD__Types14UD__send__dataE+0xf0)[0x7f0c349e42f8]
/osmo-ttcn3-hacks/bts/PCUIF_CodecPort.so(_ZN16PCUIF__CodecPort16PCUIF__CODEC__PT4sendERKNS_17PCUIF__send__dataERK9COMPONENT+0x19e)[0x7f0c37e1731a]
/osmo-ttcn3-hacks/bts/PCUIF_CodecPort.so(_ZN16PCUIF__CodecPort16PCUIF__CODEC__PT4sendERKNS_26PCUIF__send__data_templateE+0x5f)[0x7f0c37e174f7]
/osmo-ttcn3-hacks/bts/BTS_Tests.so(_ZN10BTS__Tests20f__TC__pcu__act__reqERK7INTEGERS2_S2_RK7BOOLEAN+0x411)[0x7f0c3eec3210]
/osmo-ttcn3-hacks/bts/BTS_Tests.so(_ZN10BTS__Tests28testcase_TC__pcu__deact__reqEbd+0x15d)[0x7f0c3eec4f27]
/osmo-ttcn3-hacks/bts/BTS_Tests.so(+0xfb65d)[0x7f0c3eeef65d]
/usr/lib/titan/libttcn3-parallel-dynamic.so(_ZN11Module_List15execute_controlEPKc+0x1c)[0x7f0c33af3fbc]
Change-Id: I773c7ec52dd8532bf160e92ffefc8d936ca55de2
Some test env may take more than 10 seconds to (re-)start a BTS, so
let's make it variable through this parameter.
For instance it was observed that running osmo-bts-sysmo through ssh
inside a sysmobts can sometimes take a good number of seconds (specially
because ssh connection can take a while to be established successfully).
Change-Id: Ieb046358d8266ac94bd7b9e916e85f84de3ad319
We cannot notify RSL Emulation layer about expecting a specific FN
(during ts_RSLDC_ChanRqd) because we only know the FN after sending the
RACH request, and since notification to RSL Emulation happens async, it
can happen (verified) that ChanRqd message from BTS arrives and is
handled before we register the RACH req into the ConnectionTable.
Change-Id: I438fd3ee82d88498d928dbcc89ce9bd80d37ab64
Replace all calls to setverdict(fail) with f_shutdown() since I'd rather
fail and stop early in case we encounter an error.
Only replace setverdict(pass) with f_shutdown() if it is followed by
mtc.stop
Remove internal function f_shutdown and use the one from Misc_Helpers
Change-Id: Ia8b01a1876e969d6f0760ea625e4df83af4f54ca
Temporary disable testing on FACCH/H because Calypso PHY is not stable.
Otherwise some tests fail half of the time due to this unstability.
Related: OS#3653
Change-Id: I078cdfbf8d27e543a723eab90f66b2fcda016b5d
Since OS#2988 was fixed, we should not overwrite nor ignore the
measurement results in f_build_meas_res_tmpl().
Change-Id: Ie902bfc7619181b528eafbce367c87e0b062243a
Add another IPA test to the BTS and BSC test suites.
This new test sends the header in one burst, followed by the
payload which is transmitted byte-per-byte.
The test uses an ID REQ message. If acting as a server, the test
can expect an ID RESP message. However, if acting as a client, the
server will close the connection when it receives the ID REQ.
The CTRL interface port on the BSC does not close the connection in
this case, so that particular port is skipped by the test for now.
Change-Id: If75cb90841bb25619b414f0cabe008a2428a9fdf
Related: OS#2010
Depends: I4804ccabd342b82d44e69dbc6eaaae220ec7d4e4
Run the chopped IPA ping test from the IPA_Testing module
as part of the BTS test suite. Contrary to the BSC version
of this test, this test listens for an IPA connection rather
than connecting to an IPA server. Make code in the IPA_Testing
module for accepting connections actually work.
Change-Id: I4804ccabd342b82d44e69dbc6eaaae220ec7d4e4
Related: OS#2010
Since both Calypso PHY and trxcon (since OS#2988 is fixed) are
always sending the Measurement Reports in dedicated mode, the
test cases should expect to 'see' the RSL_MEAS_RES messages,
and ignore them if they are out of the testing scope.
This change makes the following test cases pass:
- TC_rll_est_ind,
- TC_rll_rel_ind_DCCH_0,
- TC_rll_rel_ind_DCCH_3,
- TC_rll_rel_ind_ACCH_0,
- TC_rll_rel_ind_ACCH_3,
by adding the 'lazy' version of as_meas_res() alt-step.
Change-Id: I34227b981f76377c338fad4ff9560ba2042abce4
The altstep for detecting Measurement Results, that was introduced
in I15782ec93d68a0dc54b2ed7a84cb70d780ba0ce1, was implemented in a
wrong way. Basically, the DL Measurement Reports (coming from the
MS) are being combined with the UL measurements, and then being
send as a RSL_MEAS_RES message, not RSL_INITDATA_IND.
Let's use the existing as_meas_res() in 'lazy' mode for that.
Change-Id: Iea5ee868ede8bfe1e2b1cbf5abcbf2844d3fe9a4
Vadim Yanitskiy
Philipp Maier
Pau Espin
Harald Welte
Alexander Couzens
Oliver Smith
Eric Wild
Daniel Willmann