This change fixes sporadic failures of TC_cm_serv_rej:
RAN Connection table not found by component TC_cm_serv_rej(2648)
BSC_Tests.ttcn:11106 BSC_Tests control part
BSC_Tests.ttcn:10550 TC_cm_serv_rej testcase
The reason is that sometimes a BSSAP/DTAP PDU (with CM Service Reject)
gets enqueued before the SUT has established an SCCP connection to the
virtual MSC. This causes a lookup error in the RAN connection table.
A simple solution would be to add a receive statement after calling
f_create_chan_and_exp(), like it's done everywhere else:
f_create_chan_and_exp();
BSSAP.receive(tr_BSSMAP_ComplL3); // <---
But a more general solution is to expect and receive this message in
f_create_chan_and_exp(), so we can reduce code duplication and make
the API more convinient. This is exactly what this change does.
Change-Id: Ic675168e29919e1234cb49440c4a630238ff5d70
Related: SYS#4878
Verify the BTS level assignment:attempted_speech / _sign as well as
assignment:completed_speech / _sign counters, in four selected
assignment tests (fr, hr, amr_f, amr_h).
Shows a bug where we counted a speech assignment as
assignment:completed_sign.
Related: SYS#4878
Depends: Ie9fcd1e86f27ecb2f11e2e8813faac365cb470b8 (osmo-bsc)
Change-Id: Icb1386ec2ccd70eb3c026301b9b08ad7177278f7
Test the new bsc.N.paging:expired stat in TC_paging_counter too.
Depends: osmo-bsc I9c118e7e3d61ed8c9f1951111255b196905eba4d
Related: SYS#4878
Change-Id: I8931bf1bc2f4e0d4b168168cdb83683bb350d961
So far all handover tests trigger handover via VTY command. This means
that any bugs introduced in measurement report handling and handover
target selection are by definition not caught.
Almost a year ago, fixing a handover oscillation bug for intra-BSC
handover introduced a segfault for inter-BSC handover targets, because
for those the target.bts is NULL. Show this bug.
Related: OS#5324 SYS#5259
Related: I5a3345ab0005a73597f5c27207480912a2f5aae6 (osmo-bsc)
Change-Id: Iba033c32015173f57dbb1c211aefab1a9094e29d
As can be seen from ttcn3-bsc-test run #1565 on Jenkins [1], it may
happen that the VTY command requesting handover reaches the IUT earlier
than the SCCP 'SACK CC' message. In this case, the 'SUBSCR_CONN' FSM
remains in state 'WAIT_CC', so we get an error:
(bts=0,trx=0,ts=0,ss=0) (ARFCN 871) --> BTS 1 Manually triggering Handover from VTY
SUBSCR_CONN(msc0-conn204)[0x5633b2877af0]{WAIT_CC}: Received Event HANDOVER_START
SUBSCR_CONN(msc0-conn204)[0x5633b2877af0]{WAIT_CC}: Event HANDOVER_START not permitted
The easiest way to avoid this is to introduce and artificial delay
after the connection establishment and before triggering the handover.
[1] https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test/1565/
Change-Id: I19f7ca942e22d7930a56d1a525414f137a9ef831
Make the test more stable by sleeping a bit before stopping all
components. Also reduce the f_sleep(3.0), an accidental leftover from
initial debugging.
Related: SYS#4878
Change-Id: I005af13baac4bca2a431b09b2a6bbfe7077342e0
This test case fails in ttcn3-bsc-test-sccplite due to:
BSC_Tests.ttcn:10212 Dynamic test case error:
Using the value of an optional field containing omit.
Change-Id: I235027c2b53b8f2ae975e25eb7c38b1959668d6f
Related: SYS#5627
The function f_TC_fh_params_set sets frequency hopping parameters. The
ARFCN is also part of those parameters. However, this function does not
set the respective band for the ARFCN that it configurs. This results in
an invalid setting at the BSC that might cause unexpected behavior.
Lets make sure we configure the band parameter correctly before setting
the ARFCN
Change-Id: I447e4145c68c62b11b818e28f0081c19e9107647
Related: SYS#5369
For intra-BSC handovers, also verify the correct Training Sequence Code
in the RR Handover Command (not only in the Channel Activation as added
in previous patch).
Related: SYS#4895 OS#5244
Related: Iae20df4387c3d75752301bd5daeeea7508966393 (osmo-bsc)
Change-Id: I32e3553581eb17812082f1f2ee96cc978e8db668
OS#5244 reports an error in the Training Sequence Code used in the
Channel Activation for a handover target channel. Verify the TSC to
uncover this bug.
Related: SYS#4895, OS#5244
Related: Iae20df4387c3d75752301bd5daeeea7508966393 (osmo-bsc)
Change-Id: I1ed6f068c85b01e5a2d7b5f2651498a1521f89af
Reduce code (comment) dup by having one const definition for default
TSCs instead of magic numbers.
Will add another use of this in upcoming patch testing correct TSC in
handover.
Related: SYS#4895
Change-Id: I3733ebbbfd74630e095a08b83023974aad177b34
Reproduce a segfault happening when the SDCCH (primary) lchan is lost
in-between a TCH Channel Activ and its Channel Activ Ack.
Related: SYS#5627
Related: I3b1cd88bea62ef0032f6c035bac95d3df9fdca7a (osmo-bsc)
Change-Id: I81cccdea450885d5241cab62000ad355d464dd49
In SCCPlite, there is only one DLCX. Turns out the DLCX doesn't have to
be part of the interlave, just call f_expect_dlcx_conns() which takes
care of AoIP vs SCCPlite expectations.
Related: SYS#4895
Change-Id: Id8931185dfa9f229ca7af033a97cabd040db0c2a
Fix SCCPlite run of TC_cm_reestablishment.
I'm not sure why it works for AoIP before this patch, but now it works
for both SCCPlite and AoIP.
Related: SYS#5130
Change-Id: I1c87272c5bb1ac452927054a9eef104d795e02f8
Avoid test breakage in ttcn3-bsc-test-sccplite, due to different
osmo-bsc configuration.
Related: SYS#5542
Change-Id: Iaf976ac12dbb2ee1930a7acfcf3cb452db34beed
I want to add tests that verify the stat items reflecting the MSC
connection status. To be able to run a test expecting fewer connected
MSC after a test that launched more MSCs requires the links to be reset.
Related: SYS#5542
Depends: I1975941b790d2b30d0904d41e456220cba26ecff (osmo-bsc)
Change-Id: Ice3056dc46c94f9399f8379db7aeb7193782f2f2
Add a delay between sending the RSL Conn Fail IND and checking the stats
values, so that osmo-bsc has a good chance of receiving the message and
promoting the failure into the stats values first.
Even though jenkins shows no failures, when testing locally, this test
fails a lot for me without that bit of delay.
Change-Id: Iaf0173239528337283b23f70840d36ad25f14950
Also test the early IA feature for non-dyn TS in 'pre-ts-ack' mode, for
completeness' sake.
Related: SYS#5559
Change-Id: I6ba84b4b618dd99ec2095aaf611209e525f2b5f4
Tests have shown that the Training Sequence Set was not correct in early
IMM ASS messages. Add validation of the TSC and ARFCN in IMM ASS
messages for all early IA related tests. This makes the tests fail.
Related osmo-bsc patch linked below makes the tests pass again.
Related: SYS#5559
Related: I9f26074154600d854a0b3baee2f38a6666f4cb56 (osmo-bsc)
Change-Id: I4479244b0c53648e62e84e1ebf986f51d659484f
The mentioned bug was fixed 3 years ago, and there are already lots of
tests below so remove the comment.
Related: OS#3182
Change-Id: I3df4dbd1647dae78eccd31c49c3aec3cf9e12a6f
Test the experimental 'immediate-assignment pre-ts-ack' implemented in
I19e6a3d614aa5ae24d64eed96caf53e6f0e8bb74
Related: SYS#5559
Change-Id: I2ae28cd92910d4bc341a88571599347a64a18fe5
Add tests for the new early IMM ASS feature in osmo-bsc:
'immediate-assignment (post-chan-ack|pre-chan-ack)'
Related: 0b44493d3de03d2750527e224df67b473fe39f93 (osmo-bsc)
Related: SYS#5559
Change-Id: If71f4562d532b6c5faf55f5fd073449a8a137ebf
So far the test ran both lchans on bts 0, which is not really a
realistic scenario for a CM Re-Establishment Request. Move the second
channel to bts 1, using various RSL port args added recently.
Change-Id: Ia930f7b8986ba27c5f507478dbff0a2942f207d8
So far we were often just expecting the message type. Instead expect a
release on the proper channel number.
While hunting a test error, this confused me for a while, because a
missing handler resulted in the release message handled in the wrong
place, even though the chan_nr mismatched.
Related: SYS#5130
Change-Id: I002c9273a387104bea062dec8879b4e19a72008d
To be able to run tests on a cell other than bts 0, there needs to be a
way to select the RSL_DCHAN_PT and RSLEM_PROC_PT in various places.
Upcoming BSC_Tests.TC_cm_reestablishment depends on this, to be able to
run through an Assignment on bts 1.
Related: SYS#5130
Change-Id: Ia14f46d4e5e8d4722224b97c346c0cb7973fff97
The function f_expect_dlcx_conns() is clearly related to MGCP, and
semantically should not interfere with BSSAP by also receiving the Clear
Complete.
For some tests, this incidentally makes sense, but an upcoming test
failed in a non-obvious way because of this.
Related: SYS#5130
Change-Id: I637414f4db8ea7c4b59aaee205d65926574b5ccd
After the RSL RF Release has happened, by definition the RSL_Emulation
should no longer direct RSL messages on that chan_nr to the test
component that used to own the chan_nr in the ConnectionTable.
Before this patch, re-using e.g. an already freed SDCCH would result in
non-obvious test failure. This is most relevant for generic functions
called from various tests, but fixing all occurences anyway.
Related: SYS#5130
Change-Id: I764ea2ed9af9358adeb42d7ed46b84f30f1e224c
This module parameter is not needed anymore, since latest already
supports this feature for a while.
Change-Id: I3a2a4f984443a40285440a7fc54b1797a943e4b0
With this we'll avoid running the test in latest. This way we'll not
fail after changing the TS for the test and hence other tests won't be
affected.
Related: SYS#5309
Change-Id: Ib956401030e6a97db218823c997c61c335fbd581
In the configuration file, that we use for ttcn3-bsc-test, TS5 is
configured to TCH/H. However, f_ts_reset_chcomb() would reset
it to TCH/F. This makes some other test cases fail.
Change-Id: I4c2c70381274949ed75d58723136e2f54eb3a7af
Fixes: [1] I6110fe0bf56f4dbf67265f0d4c97cdea0b410af4
Related: SYS#24876
After removing a5/4 from the default config, it also needs to be
explicitly enabled for these two tests.
Fixes: 26a3db ("bsc: change encryption a5 via VTY where needed")
Change-Id: Ibe00edb096f94b500869c46a39a694a73133c716
Verify that A5/1 is preferred over A5/2. Add encr_exp_enc_alg to
MSC_ConnectionHandler:TestHdlrEncrParams, so the expected encryption
algorithm can be different from what the MSC tells the BSC about the
capabilities of MS.
Related: OS#4975
Change-Id: I688d056bcfe73f7846f908a28f4621f944cf2178
Do not assume that osmo-bsc.cfg contains "0 1 3 4" for master and "0 1 3"
for latest anymore. An upcoming test will need to change the value as
the test runs and needs a defined value to reset to.
Assume that osmo-bsc.cfg contains "0 1 3" and change it to "0 1 3 4"
only for TC_ciph_mode_a5_4.
Related: OS#4975
Related: docker-playground I55135ca00ef51de5cf6eaec75cfc20c21beef665
Change-Id: I3cf36c6ef86a0db050507f3737f4b0c10dcd52ed
Only ho-into-this-bsc tests are required, since the out-of-this-bsc
message (Handover Required) does not involve any encryption information.
Related: SYS#5324
Change-Id: I8de65eb9a5bd9a58add55e821f2a559c9a81edc1
In f_tc_ho_int(), verify encryption information for the handover
target's chan act.
Add test cases calling f_tc_ho_int() with various A5/n encryption modes.
Related: SYS#5324
Change-Id: Iaab26c708c106a61b762234d42ed9a52cdc2998c
Allow only A5/4, but omit the Kc128 IE from MSC's msg. Expect Cipher
Mode Reject.
Related: SYS#5324
Change-Id: I7734a4a59797a9b21523c33f48815a8094f4e6ec
Implement tools for OsmoBSC a5/4 support testing:
- in f_cipher_mode() and f_check_chan_act(), expect Kc128 key as
appropriate, using recently added g_pars.encr.enc_kc128
- osmo-bsc.cfg: allow a5/4
Related: SYS#5324
Change-Id: Ifa48a8498dde7d04fb29f497013bdb5a1e5f3597
Instead of passing each part individually, simply pass the entire
TestHdlrEncrParams to f_cipher_mode().
Preparation for A5/4.
Add the kc128 to TestHdlrEncrParams instead of a function arg. kc128 is
so far unused, but will be used in an upcoming patch adding A5/4.
Related: SYS#5324
Change-Id: I2cb8282e55436da5ae64ab569df87d5d5a0dd2f0
reasons:
* TC_assignment_fr_a5_4() runs an unusual sequence of messages: it first
fully assigns an lchan, and after that sends a Cipher Mode Command.
Usually, the ciphering happens as part of attaching (Compl L3).
The new test TC_assignment_fr_a5_not_sup() does the ciphering in the
usual sequence, and properly expects a Cipher Mode Reject.
* TC_assignment_fr_a5_4 means to ask for an *unsupported* encryption
algo. Since we are going to introduce A5/4 support shortly, we'll need
to free up this name, for a successful A5/4 encryption test.
New test TC_assignment_fr_a5_not_sup() asks for A5/5 encryption, which
is not supported.
Related: SYS#5324
Change-Id: I83eca18d1b3d8d58177aa3750935ec5a3a985ca4
The function didn't wait to receive the 2 messages from the BSC. As a
result, they may have arrived while tearing down the test components
shortly after exiting the function and provoke a Dynamic Test Error
while pushing the messages up the stack since some of the stack layers
may already be unavailable.
Test TC_ho_out_of_this_bsc() workarounded this by using a f_sleep(1),
but TC_srvcc_eutran_to_geran_ho_out() didn't, making it fail sometimes.
Change-Id: I590b09353900dfe6c4f648812ab675fed1908589
BSC_Tests_VAMOS.ttcn is separate from BSC_Tests.ttcn in order to
instruct osmo-bts-omldummy to pass BTS_FEAT_VAMOS == true in the OML BTS
attributes.
Add tests:
TC_chan_act_to_vamos()
TC_mode_modify_to_vamos_fr()
TC_mode_modify_to_vamos_hr()
TC_assign_to_secondary_lchan_fr()
TC_assign_to_secondary_lchan_hr()
TC_vamos_multiplex_tch_f_tch_f()
TC_vamos_multiplex_tch_h_tch_h_tch_h_tch_h()
Change-Id: I2c504099163a30ea102cbd26d3615ca2e5ce1e64
In a recent osmo-bsc patch:
"allow explixit TSC Set and TSC on chan activ / modif / assignment"
c33eb8d56943b8981523754b081967e6ff5f245d
Ic665125255d7354f5499d10dda1dd866ab243d24
I accidentally changed the default behavior of the Training Sequence
Code sent to BTS and MS. So now, make sure that we verify the expected
Training Sequence Code in BSC_Tests, in:
RSL Channel Activate
RR Immediate Assignment
RR Assignment Command
RR Channel Mode Modify
RSL Mode Modify
Related: OS#5172 SYS#5315
Change-Id: Id67a949e0f61ec8123976eb8d336f04510c55c01
osmo-bsc does now support intra-cell re-Assignment of lchans with active
voice. Test re-Assignment of TCH/F, triggered by VTY command.
Change-Id: I05fecefb9d6f9f23a0362f133170bca4da92e308
Test the lchan mode modification code path of OsmoBSC, in preparation of
adding VAMOS bits to the mode modification procedure.
Related: SYS#4895
Change-Id: Idf4efaed986de0bbd2b663313e837352cc139f0f
Update TC_si2quater_*_earfcns test to trigger Tx of SI2quater eutran
neigh list properly, by sending a CommonID with "Last Used E-UTRAN PLMN
ID" IE. This should have been updated in a recent commit (see
below).
Fixes: 841b90daf2
Related: SYS#5337
Change-Id: I3073152475a338b29214393a9b550891d52e1f24
CSFB indicator shouldn't be used as stated in the specs. Rather, BSC
should act based on "Last Used E-UTRAN PLMN Id" found in messages such
as Common Id, or Handover Request/Required.
Related: SYS#5337
Related: osmo-bsc.git Change-Id I5d290ac55eca5adde1c33396422f4c10b83c03d5
Change-Id: I7b2e5a3ad24c10e279a7f1c447804100168203ba
The IE contains a cell list for the MS to register after the channel
is released. The IE is used in CSFB, but not only in that case: it's
also used in SRVCC.
Hence let's remove the CSFB references since the scope is more wide.
Related: SYS#5337
Change-Id: Ia1eeda98fc21aa92bb2e41b5e4761c5cf6516a7e
This param is not needed anymore sincenew releases used in -latest don't
need to disable it.
Let's keep the possibility to change behavior from within test and leave
v6 enabled by default as it used to be.
Related: OS#5042
Change-Id: Ic693885dd3d4259dc6ce80643d25c7d432148d3d
Since Idb453fc894584ccf4f5f8b45a24421db958e9478, osmo-bsc does send
ip.access specific Measurement Pre-Processing Defaults. This message
currently blocks the 'alt' statement in f_recv_next_si1(), so all
test cases calling it fail due to the guard timeout.
What's even worse, both TC_si_acc_rotate() and TC_si_acc_ramp_rotate()
dynamically configure the IUT in order to re-generate and send System
Information messages periodically. If any of them fails prematurely,
the related configuration parameters would remain active, so the IUT
would continue sending System Information messages, causing failures
in subsequent test cases.
Let's simply ignore all unmatched messages in the 'alt' statement.
Change-Id: I1a85a046e1a8ebcd494354dddcbcc9707fdf5ee9
There is a global boolean flag that would make f_init() return
early if it's called twice. This is exactly the case here.
Change-Id: Ic33786c4851d2682deec7c22fafb99043c1c1cf6
Calling f_shutdown_helper() in f_tc_chan_rel_rr_cause() leads to
premature test case termination, so only one out of 6 cause values
gets checked. Move it to TC_chan_rel_rr_cause().
Change-Id: Ic7df15b496fc0750e4f694b1ae79398216f498a7
This test shows that in current osmo-bsc, the start-mode fails to
propagate to the MultiRate Config IE, the only start-mode so far has
always been zero.
Change-Id: I75515baf8cda04567cad8a93c5aa88361c2d259f
Vadim Yanitskiy
Neels Hofmeyr
Oliver Smith
Pau Espin
Philipp Maier
Neels Hofmeyr
Harald Welte