Whenever the BSC is updating SI1, SI3 or SI13 via RSL, the PCU should be
informed about the change via PCUIF as well. For SI13 this is already
the case and a testcase exists. The PCUIF protocol is
now capable to update SI1 and SI3 as well.
- Update BTS_Tests.TC_pcu_ver_si13 so that it works with the current
protocol version
- Add BTS_Tests.TC_pcu_ver_si3 and BTS_Tests.TC_pcu_ver_si1 that test
SI1 and SI3 as well.
Depends: osmo-bts Ib7aeb41e634ad6fcab3766a4667b0267c749436a
Change-Id: I5138ab183793e7eee4dc494318d984e9f1f56932
Related: SYS#5103
Currently osmo-bts seems to be sending IPA RSL Connect ACK
unconditionally, even if the remote peer is not reachable.
Change-Id: Ibfa58f670401907801f610578dd9b4ebf155a83a
According to 3GPP TS 48.058 4.1.4, SACCH may be transmitted also for only MS
Power present, and no Access Delay.
Change-Id: I2e1c0ecc9de65a019aaa9f08bb051bf051156172
In some cases GsmArfcn itself is not enough. It case of L1CTL
and GSMTAP, it needs to be equipped with a band discriminator:
- DCS / PCS (as the numbers may overlap),
- Downlink / Uplink (not yet there).
Let's rename this record and move it to GSM_Types. Also, add
send / receive tamplates, so we can add new fields later.
Change-Id: I7a63f03bbd15a06caafb786122dc12991d115771
It will be easier to use this list / array in non-L1CTL specific
records and templates, e.g. in (RR) Immediate Assignment.
Change-Id: I392299eea9a82168f893a72d06872c280b6fbdce
The new altstep reduces code duplication and simplifies access
to the L1 SACCH Header. It uses dec_SacchL1Header() to decode
the header, and would apply the received TA / MS Power level
values by default (see 'do_apply' parameter).
Change-Id: Ie593d9b06aea694fb0903a6d26ee387d8da4c82d
Related: SYS#4918
The test sets random bits for SI5 and expects to see those in dl SACCH. That
can only possibly work when that SI5 was actually sent to the BTS.
Change-Id: I0d3a96f5ae932734e986637ca2cb23805eba6829
We never launch this test case in DTX mode on anything else than
TCH/F, so it does not make sense to check this all the time.
Change-Id: I6e971d87f26253f4283c47b7f8826d14a2567a9b
Related: OS#4801
There is no such thing like a fill frame on SACCH:
- on Downlink, it's always System Information messages;
- on Uplink, it's always the Measurement Reports.
Yes, osmo-bts-trx does send dummy LAPDm func=UI frames on SACCH,
but this happens because the test suite never feds it with the
associated System Information messages (i.e. Type 5, 5ter, 6).
In the 'alt' statement, restrict matching of L1CTL DATA.ind, so
only DCCH/FACCH blocks are counted. Ignore DL SACCH blocks.
This change reveals that TC_tch_sign_l2_fill_frame_dtxd actually
fails because no fill frames are received at all from the IUT.
Change-Id: I6c68dd0a7dfa18ae4573a037399b6650feb22f11
Related: OS#4801
TTCN-3 offers templates and pattern matching, so no need to match
against all possible variants of the RSL channel number.
Change-Id: I104595c4a96617f8000f803d19a890cff0b02744
Related: OS#4801
The current definition of the SI2quater Rest Octets is incomplete.
In particular, the missing part is Repeated UTRAN FDD/TDD Neighbour
Cells structure, for which 3GPP came up with a very tricky encoding.
Given that both test cases checking scheduling of the SI messages
and not their content, let's simply use different SI2quater samples
containing E-UTRAN Parameters Description instead.
Change-Id: I3556be33eda17dd6fce347b390a3662d43064897
Fixes: OS#4662, OS#4800
The current TC_meas_res_speech_tchX tests only test a pure voice
transmission. A voice transmission can be occasionally interrupted by
FACCH transmissions. This should also be tested. Lets ad a _facch
variant for the two speech test variants we already that injects a FACCH
from time to time.
Related: OS#4799
Change-Id: Ie9cd39739d4b972f4e533a7bc90f79e914888aab
The purpose of these new test cases is to demonstrate a problem
described in OS#4823: the IUT sends *dummy bursts* in absence of
MT RTP frames, so on the MS side it looks like RF failures.
It's not yet clear what needs to be sent by the BTS in this kind
of situation, but at least we can verify that whatever is sent
can be decoded on the MS side without CRC errors.
Change-Id: I620ea84ae92c976a62c1f8334ec14a2a7685aa21
Related: OS#4823
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
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
Vadim Yanitskiy
Philipp Maier
Alexander Couzens
Pau Espin
Harald Welte