When the test is executed outside of docker, having to manage all
those different IP addresses while manually starting programs can be
quite cumbersome. Let's just run everything over localhost, like
we always do with other tests.
Now the only cumbersome command to start is trxcon, as it defaults to
only one TRX and adding additional TRX is rather complicated:
./fake_trx.py --trx TRX1@127.0.0.1:5700/1 --trx TRX2@127.0.0.1:5700/2 --trx TRX3@127.0.0.1:5700/3
Change-Id: Iea8519685da7d73696ce9cc2541e93c45c099828
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
Somebody seems to have forgotten to update the osmo-bsc.cfg file here,
as osmo-bsc wouldn't even start using the file here.
Change-Id: I8453da3bda36912ee42fb0c8d862f75b2065965f
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
Harald Welte
Vadim Yanitskiy
Philipp Maier
Pau Espin
Alexander Couzens