Cause GSM0808_CAUSE_MS_NOT_EQUIPPED is to be transmitted only in the case
BSC receives a RelInd from the MS/BTS. In this test, an ErrorInd is
sent, as in TC_rll_err_ind_sapi_n_reject, so it is expected that the
BSC will send the N_Reject message with cause
GSM0808_CAUSE_BSS_NOT_EQUIPPED.
Related: OS#4728
Related: SYS#5047
Fixes: 999ceb6637
Change-Id: Ieebe3465b31d98fcae0e2c1993477c5021c99b3b
IPA_Emulation component was marked with the "alive" type recently, in
order to avoid race conditions leading to errors during tear down of the
test.
It turns out, the way "alive" keeps the component alive is by means of
not closing the sockets when the component is stopped. As a result,
TC_rsl_drop_counter test stopped working properly because it was
specting a TCP FIN to be sent to osmo-bsc when the component was
stopped.
In order to fix it, add a new CFG port to the IPA_Emulation component on
which one can operate. Add a a new method to tell the component to close
the socket.
Then, put that in BSC_Tests into a function which was actually unsued
until now, and use it in the test in order to have the specific logic
enclosed in a function helper.
Fixes: 7138913d66
Change-Id: I68163b053313d9907ba8e40954a5933d14cb7db6
In the out-of-this-BSC handover tests, a neighbor config of LAC 99 left
behind from a previous test obstructed the test from working:
% BTS 0 already had neighbor LAC:99 ARFCN-BSIC:123-45
% ERROR: duplicate Cell ID in neighbor config, with differing ARFCN+BSIC: LAC:99 ARFCN-BSIC:123-any
Add a 'no neighbor lac 99' before configuring the neighbor via VTY.
Also add the missing neighbor config to
f_tc_srvcc_eutran_to_geran_ho_out_main().
Affects tests:
BSC_Tests.TC_ho_out_of_this_bsc
BSC_Tests.TC_srvcc_eutran_to_geran_ho_out
BSC_Tests.TC_srvcc_eutran_to_geran_ho_out_forbid_fast_return
Change-Id: I7a7c97a47a06abb59c0d89638c6b503ab66eb359
* t_RSL_IE_ActType_PDCH is actually a constant, not a template.
* tr_RSL_CHAN_ACT_PDCH makes no use of parameter 'mode'.
* Accomplish tr_RSL_CHAN_ACT_PDCH with a send template.
* Use 'present' qualifier for receive template parameters.
Change-Id: Ie62a92daaacf4de5f05dd1f3f5b4a2a5e4ee6dd6
According to feedback received from TITAN developers in
https://www.eclipse.org/forums/index.php?t=msg&th=1106652&goto=1848616&#msg_1848616
the use of alive-type components has the following advantage:
> Also the DTE during the shutdown can be avoided to use alive type
> components. The test ports of the alive components are not
> disconnected/unmapped when the component finished only when killed or
> the MTC terminated.
So the idea of this patch is to use alive-type components for all the
underlying infrastructure, such as the *_Emulation_CT starting from M3UA
to SCCP and further up the stack. This way, only the MTC and the
highest level of components (such as ConnHdlr) remain as normal
components.
The hope is that using more alive-type components in the lower protocol
layer emulations will reduce the probability of DTE during shutdown if
some message is received during the component shutdown after the MTC
has completed.
Change-Id: I61d791d6d1bfe9226aabbe223baafc5f8f6d4f04
Using the same IMSI in each test case makes it harder to correlate
subscriber connections in the SUT with particular test cases. A
good example is a problem described in OS#5337: some test cases
create dangling subscriber entries that never got released:
OsmoBSC# show subscriber all
IMSI TMSI Use
001019876543210 ffffffff 3 (3*paging-start)
001010000100001 ffffffff 1 (conn)
With this patch I am getting the following output:
OsmoBSC# show subscriber all
IMSI TMSI Use
001016017428234 ffffffff 1 (paging-start)
001014631230680 ffffffff 1 (paging-start)
001011161500382 ffffffff 1 (paging-start)
001010000100001 ffffffff 1 (conn)
so I was able to correlate the following test cases:
* (001016017428234) TC_lcs_loc_req_for_active_ms_ta_req,
* (001014631230680) TC_lcs_loc_req_for_active_ms_le_timeout2,
* (001011161500382) TC_cm_service_during_lcs_loc_req,
* (001010000100001) TC_no_msc.
Change-Id: Ie008b5566b207b13cd562c55625bad38c09b3927
Related: OS#5337
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
Make sure that when a 'start-mode auto' is set, that the previous start
mode setting does not linger in the unused bits.
- after I577ff590d7588fd7e3ee4846c7955ab8f84cf2b1, osmo-bsc sets its
ICMI bit properly, but passes this test only because it *always* sends
smod (start-mode) bits as zero.
- in I49691df01745a7c485bf165e897872c35fc4b147, the smod bits are
properly sent on RSL, but this test shows that when ICMI becomes zero
for 'start-mode auto', the smod bits will remain whatever start-mode
was set in the previous osmo-bsc config. Instead, osmo-bsc should
clear the smod bits for 'start-mode auto' so that its MultiRate Config
does not vary depending on what was previously configured.
- in I1ec5bad0bce01cc425ee05ecf70c83ec662a226a, clearing smod is
implemented and this test is expected to pass.
Change-Id: I151678f64e680f30f35b6bb2b0036d63efde9f2c
osmo-bsc currently has a bug that fails to reflect the correct
start-mode in the AMR MultiRate config IE.
And it went unnoticed that the ttcn tests expect a MultiRate config of
ICMI = 1, even though the used configuration should yield ICMI = 0.
See mr_conf = '2804'O, where the '8' indicates ICMI = 1.
As a first fix of the ttcn3-bsc-tests, configure the BSC according to
the expected ICMI value and Start Mode, i.e. ICMI = 1 and StartMode = 0,
which is configured by 'amr tch-[fh] start-mode 1'. This should make
these tests pass as-is for both the current osmo-bsc as well as an
osmo-bsc where the bug is fixed, with minimal changes to the current
tests. See also OS#4868.
An upcoming patch will add tests for 'start-mode auto'.
Related: OS#4868
Change-Id: I4cff01c37d5c7e301e9a01f773b7e009a789519b
These allow passing N vty configurations on the bts / msc node without
requiring subsequent 'exit'.
As an example, use f_vty_cfg_msc() in BSC_Tests.ttcn AMR config.
Change-Id: I9f3e485f692acb3d2a7620e9b454b372651be78e
When a RESET-ACK times out, the logs currently are indistinguishable between
BSSMAP and BSSMAP-LE. Add protocol naming for each RESET / RESET-ACK logging to
make sure the information does not need guesswork.
Example of a test failure shown in jenkins:
BSC_Tests.TC_unsol_ass_compl
Stacktrace
Timeout waiting for RESET-ACK after sending RESET
BSC_Tests.ttcn:8295 BSC_Tests control part
BSC_Tests.ttcn:4274 TC_unsol_ass_compl testcase
Nothing conveys that it is (presumably) the background *BSSMAP-LE* timeout
halting the test 5 seconds in, and not an A-interface failure.
Change-Id: I874567e68b8279bf2460b9474241f0a9fe5ff0ff
Adding LCS to OsmoBSC creates the possibility of a Paging for LCS, where the
Paging Response should not emit a Complete Layer 3 on the A-interface.
Change-Id: Icb402b7436d844d939790f3cfb3725ffcf1136d2
This introduces the Lb interface stack, which allows BSC_Tests.ttcn
to emulate a SMLC towards the BSC.
In accordance with https://osmocom.org/projects/cellular-infrastructure/wiki/Point_Codes
we use 0.23.6 as point code for emulating the SMLC.
Change-Id: Id41246f0dd812f7ddee9d920bfd07a4e3aac3504
Without this, subsequent vty commands become "% Unknown command".
(Triggered by the test start vty "logp" in f_start_handler() that is going to
be added by subsequent patch.)
Change-Id: I51ace11883256ee0725caae46ea22adb2ea5eb39
We cannot use a random 8bit value as RACH request, as some of that
space actually maps to emergency call RACH, which is rejected unless
we enable it in the config.
Change-Id: Ie073fe721022c392278e8632ab52122b4b89cbe1
Since If4d479a54cad467f53b49065c1c435a4471ac7d2, osmo-bsc started
to send more concrete DLCI values on the A/BSSAP interface. In
particular, the control channel identification bits now indicate
whether it's SDCCH/FACCH or SACCH channel.
Let's use '?' as the default DLCI template that we expect to get
from the IUT, so those test cases, for which DLCI is not a part
of the testing scenario, would not fail.
Change-Id: Ida659d53e0d31f9aa0ea2ccccefc94d8c659eb76
The aim of this test case is to verify DLCI / RSL Link ID conversion
for MO/MT L3 messages on SAPI0/SAPI3. In particular, the test suite
verifies the following scenarios:
- RSL -> BSSAP:
- 16 MO messages on FACCH/F with SAPI0,
- 16 MO messages on SACCH/F with SAPI3;
- BSSAP -> RSL:
- 16 MT messages on FACCH/F with SAPI0,
- 16 MT messages on SACCH/F with SAPI3.
Change-Id: Ica69ae95b47a67ba99ba9cc36629b6bd210d11e4
Related: OS#3716
The new name is more concrete and better reflects what the
function does: transmit a MO L3 payload to the IUT over the
A-bis/RSL and receive it back on the A/BSSAP.
Change-Id: Ic2b60b60c49ae7788ce03503b8b867bb9e55244b
Related: OS#3716
When the BSC sends a CRCX without an IP address in it, the testcase will
automatically assign an IPV6 address in the response. However, this
breaks compatibility with older versions of osmo-bsc that do not have
IPV6 support. Lets add a module parameter in order to be able to use
IPV4 as default if required.
Change-Id: I30c77abef63636bb02db12d2f2b2d79ea244b96c
According to 3GPP TS 44.018, table 10.5.2.21.1 "Mobile Allocation
information element", in the cell allocation frequency list the
absolute RF channel numbers are placed in increasing order of ARFCN,
except that ARFCN 0, if included in the set, is put in the last
position in the list.
Let's verify that the IUT handles this corner case correctly.
Change-Id: I3afadfde03f6ea766c0756a181ef129e4b05c383
Related: SYS#4868, OS#4545
The Mobile Allocation IE generated by the IUT includes not only
the list of hopping ARFCNs, but also ARFCN of the transceiver
itself. This is the correct behaviour, and that's why we see
sporadic test case failures like this one:
Mobile Allocation IE does not match (tn := 1):
{ len := 3, ma := '001010101011111100000000'B }
vs expected
{ len := 2, ma := '0010101010111111'B }
The last '0'B bits may look like redundant padding, but actually
only 7 of them are. The MSB '0'B bit in the last (third) octet
corresponds to pre-configured ARFCN 871.
Since f_TC_fh_params_gen() generates all ARFCNs in GSM-900:
- in f_TC_fh_params_gen(), pick an ARFCN value from GSM-900;
- in f_TC_fh_params_set(), change ARFCN of a given transceiver;
- in f_TC_fh_params_gen_tr_ma(), consider that ARFCN;
- in f_TC_fh_params_unset(), bring it back to 871.
Change-Id: Id11be94087c18d8159af4b7988826023832f9944
Related: SYS#4868, OS#4545
This record must contain not only the hopping parameters, but
also ARFCN of the transceiver they belong to. Since ARFCN of
the transceiver also becomes part of the Mobile Allocation,
we need to take it into account in the matching functions.
Change-Id: I4722dc3f758a097806811cb0b59aa4093374c74c
Related: SYS#4868, OS#4545
The testcase TC_emerg_premption does not set a verdict when done. Make
sure that the verdict is set to pass when the test is done.
Change-Id: Ie612b32cfa9cedd1e0f1d51e48911da94ec325cf
Related: OS#4549
osmo-bsc is using the same LTE neighbors of the SI2quater in the Channel Release -
Cell selection indicator after release of all TCH and SDCCH IE. Ensure the same measurement bandwidth
is present to not overwrite the measurements bandwidth from the SI2quater.
Change-Id: I9aa30dfd1e2c1b80e037bd71ebc4cdd3752638b4
This scenario appeared in jenkins runs of BSC_Tests making
TC_ctrl_msc_connection_status fail (the first test in the suite). I
could however not reproduce it on my local docker setup because it
really seems like a timing race condition.
The scenario is:
TTCN3 -> BSC: RESET
TTCN3 <- BSC: RESET
TTCN3 -> BSC: RESET-ACK
In there, TTCN3's f_legacy_bssap_reset() expected a RESET-ACK to be
received, but it may well be that the other end never saw the RESET and
hence it will never sent the RESET-ACK, since it indicated it became
available afterwards. In that case (RESET received), let's not fail if a
RESET-ACK is never received, since the connection is actually in the
desired state and this scenario can happen and it's all fine.
Change-Id: Ic92e0fb7033e5134b66e485a11371394adaba78a
Similar to TC_fh_params_assignment_cmd, this test case verifies
presence and correctness of the hopping parameters in the following
messages and their IEs:
1. (RR) Handover Command
1.1. Description of the First Channel, after time IE
1.2. Cell Channel Description IE (presence)
1.3. Mobile Allocation, after time IE
The hopping parameters are randomly generated and configured
via the VTY interface in the beginning, and unset in the end.
Since the C0/TS0 (BCCH+SDCCH4+CBCH) shall not be hopping, let's
temporarily re-configure TS0 as BCCH, and TS1 as SDCCH8 on TRX0
of BTS1 (handover tagret).
Change-Id: I0ddea535dce7e5558793be5cddaad0ab46e978ec
Related: SYS#4868, OS#4545
My initial assumption was that we can skip redundant '0'B bits or
even '00'O octets in the Mobile Allocation IE, and thus reduce
the overall size of this element. Unfortunately, this is wrong.
3GPP TS 44.018, section 10.5.2.21 clearly states that the Mobile
Allocation IE contains a bit-string of size NF, where NF is the
number of frequencies in the cell allocation. If NF % 8 != 0,
then '0'B padding bits must be appended to make it octet-aligned.
In other words, if the cell allocation contains let's say 13
frequencies, but a hopping timeslot makes use of only a small
fraction of it (e.g. 4 first channels), we would still need to
transmit at least 13 bits (+padding), including all redundant
bits and octets.
Change-Id: Ia79efc9aa07b5088913d6679715f351d30f48d13
Related: SYS#4868, OS#4545
Change [1] introduced a regression that caused some TC_cbsp_*
test cases to fail. The problem is that TC_fh_params_si4_cbch
re-configures TS0 as CCCH+SDCCH4 instead of CCCH+SDCCH4+CBCH,
so the CBCH channel vanishes after this test case is executed.
[1] Ibc3b73697a1d2c8dbb27274e48f5e5ba21fdd540
Change-Id: Ia249f10c1b768a5af2b6c92ecba5d2941528f876
Related: SYS#4868, OS#4545
Make it possible to call them from a testcase / function
running on any kind of component, not only on MSC_ConnHdlr.
Change-Id: Ifbcc24c5a0299ba43a998ccbdd0f77bc109c6935