New versions of osmo-pcu support Neighbor Address Resolution over this
interface, and deprecated the old CTRL interface.
Let's use it by default while still keeping support for the old one for
a while to avoid breakage of existing deployments.
Tests run to validate:
* Old osmo-pcu still passes tests using CTRL interface
* New osmo-pcu (with new iface support) still passes tests using CTRL
interface
* New osmo-pcu (with new iface support) passes tests using new iface
Related: SYS#4971
Change-Id: I05f1aabc64fc5bc4740b0d8afd8990b485eacd50
This way functions like f_inet_addr() and f_inet6_addr() can be
used directly without converting between bytes and integers.
Change-Id: I389a8cb95c025c9dddc751789223621c15d9b48f
The current paging load tests only test what happens when the paging
load is introduced from the PS side. However there are no tests that
tests what happens when PS pagings are introduced from the PCU side
into an already overloaded system.
osmo-bts was equipped recently with a mechanism that detects congestive
situations. Once a congestion is detcted osmo-bts will drop pagings from
the BTS side. The rationale of the new testcase is that the behavior
must not change when the PS pagings start since osmo-bts is dropping
them.
Change-Id: Ie72e788d9ebff6ca4e50314746127a9689948062
Depends: osmo-bts I30f97672d7a0c369c4a656e878ab8cbbd83e31ea
Related: SYS#5306
Sometimes, VAMOS related test cases fail due to a DTE:
Dynamic test case error: Sending data on the connection of port
CCHAN_PT to 1:RSL_CCHAN failed. (Broken pipe)
Call f_shutdown() to ensure that all components are properly
terminated, so there will be no race conditions like this.
Change-Id: I690412a29b24571109415d32b09543de459076d1
Related: SYS#4895
Since recently, we do have NOPE indications in the virtual Um
environment. Somehow this broke test cases for the MS power
control. Releasing the channel makes everything work again.
Change-Id: I6a204bbecfe116aa302eae28ff24d6bb899fa8b7
Related: SYS#5313, OS#1569, OS#1866
Recent changes [1] to osmo-bts make it periodically send the
RF RESource INDication messages for each transceiver over the
A-bis/RSL. These messages block the queue of 'RSL_CCHAN' port
and make the paging related test cases fail. Ignore them.
Change-Id: I18b879235c6eefb2dd89a3f4502b0830efeac6bb
Related: [1] Id80fdbef087de625149755165c025c0a9563dc85
Related: SYS#5313, OS#1569
Unfortunately, trxcon does not support handling more than one
connection in parallel. If there is already one connection
established, it would reject all other connection attempts.
This causes an error in f_handler_init(). As a quick hack,
let's allow running BTS_Tests.ConnHdlr components without
establishing L1CTL connections at all.
Change-Id: I72bcaed6c3803a0e18c9b787036a441e30c220cc
Related: SYS#4895, OS#4941
The expectations of this test case were wrong. The IUT would first
accept() an additional connection and then close() it immediately.
Since there may be other messages, like TIME.ind and DATA.ind, the
'alt' statement would not match successful connection result, and
instead would unblock the flow due to timeout.
The titan.TestPorts.UNIX_DOMAIN_SOCKETasp had to be changed [1] to
send UD_connect_result with ERROR if recv() returns zero or a negative.
[1] https://github.com/eclipse/titan.TestPorts.UNIX_DOMAIN_SOCKETasp/pull/4
Change-Id: I898b8b14515d79766b12d652ebb1ddf834e2863c
This commit fixes a regression introduced in [1]
Change-Id: I107039f1ff44ae8c41d690f5f293ed136c17586b
Fixes: [1] Ia9f366ca1fdad700a90ca3367e43523f7bac39a1
The PCUIF connection involves a lot of frequent messages, such as
the TIME.ind and since recently DATA.ind with len=0. As a result,
the test suite logs are getting unreadable due to lots of coding
warnings and port queueing notifications.
This change is aimed to improve the situation a bit, by establishing
the PCUIF connection only for those test cases which actually use it.
Side effects:
* TC_pcu_socket_verify_info_ind becomes reliable, because the
PCUIF establishment is done after the RSL bootstrapping;
* TC_pcu_socket_connect_multi starts to fail, because it used
to pass due to timeout, since not all messages are handled
in the 'alt' statement.
Change-Id: I09ccb65ce94a41ffdad4e93da650c3f32d422af4
Related: OS#5083
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