bsc: add TC_ms_rel_ind_does_not_cause_bssmap_reset
bsc: add TC_bssmap_clear_does_not_cause_bssmap_reset(), but the same triggered by an MS Rel Ind and a BSSMAP Clear Request sent to the MSC first. This test will only succeed once TC_chan_rel_rll_rel_ind() succeeds, i.e. with below osmo-bsc fix. Related: OS#3041 Depends: I0f8c9c4e6b6850b15c70250fd3f88bdf75f9accf (osmo-bsc) Change-Id: Ie4aa2f01c83b40303fa40ed64dbfce372b7cd96c
This commit is contained in:
parent
27f643639e
commit
fd445c34fe
|
@ -1820,6 +1820,68 @@ testcase TC_bssmap_clear_does_not_cause_bssmap_reset() runs on test_CT {
|
|||
f_shutdown_helper();
|
||||
}
|
||||
|
||||
/* OS#3041: Open and close N connections in a normal fashion, and expect no
|
||||
* BSSMAP Reset just because of that. Close connections from the MS side with a
|
||||
* Release Ind on RSL. */
|
||||
testcase TC_ms_rel_ind_does_not_cause_bssmap_reset() runs on test_CT {
|
||||
var default d;
|
||||
var integer i;
|
||||
var DchanTuple dt;
|
||||
var BSSAP_N_DATA_ind rx_di;
|
||||
var RSL_Message rx_rsl;
|
||||
var integer j;
|
||||
|
||||
f_init();
|
||||
|
||||
/* Wait for initial BSSMAP Reset to pass */
|
||||
f_sleep(4.0);
|
||||
|
||||
d := activate(no_bssmap_reset());
|
||||
|
||||
/* Setup up a number of connections and RLSD them again from the MSC
|
||||
* side. In the buggy behavior, the fourth one triggers BSSMAP Reset.
|
||||
* Let's do it some more times for good measure. */
|
||||
for (i := 0; i < 8; i := i+1) {
|
||||
/* Since we're doing a lot of runs, give each one a fresh
|
||||
* T_guard from the top. */
|
||||
T_guard.start;
|
||||
|
||||
/* Setup a BSSAP connection and clear it right away. This is
|
||||
* the MSC telling the BSC about a planned release, it's not an
|
||||
* erratic loss of a connection. */
|
||||
dt := f_est_dchan('23'O, 23, '00010203040506'O);
|
||||
|
||||
/* simulate RLL REL IND */
|
||||
f_ipa_tx(0, ts_RSL_REL_IND(dt.rsl_chan_nr, valueof(ts_RslLinkID_DCCH(0))));
|
||||
|
||||
/* expect Clear Request on MSC side */
|
||||
BSSAP.receive(tr_BSSAP_DATA_ind(dt.sccp_conn_id, tr_BSSMAP_ClearRequest)) -> value rx_di;
|
||||
|
||||
/* Instruct BSC to clear channel */
|
||||
var BssmapCause cause := bit2int(rx_di.userData.pdu.bssmap.clearRequest.cause.causeValue);
|
||||
BSSAP.send(ts_BSSAP_DATA_req(dt.sccp_conn_id, ts_BSSMAP_ClearCommand(cause)));
|
||||
|
||||
/* expect BSC to disable the channel */
|
||||
rx_rsl := f_exp_ipa_rx(0, tr_RSL_MsgTypeD(RSL_MT_RF_CHAN_REL), T3101_MAX);
|
||||
/* respond with CHAN REL ACK */
|
||||
f_ipa_tx(0, ts_RSL_RF_CHAN_REL_ACK(dt.rsl_chan_nr));
|
||||
|
||||
/* expect Clear Complete from BSC */
|
||||
BSSAP.receive(tr_BSSAP_DATA_ind(dt.sccp_conn_id, tr_BSSMAP_ClearComplete));
|
||||
|
||||
/* MSC disconnects as instructed. */
|
||||
BSSAP.send(ts_BSSAP_DISC_req(dt.sccp_conn_id, 0));
|
||||
}
|
||||
|
||||
/* In the buggy behavior, a timeout of 2 seconds happens between above
|
||||
* trigger (logs "SIGTRAN connection down, reconnecting...") and the
|
||||
* actual BSSMAP Reset. Wait a bit longer just to make sure. */
|
||||
f_sleep(4.0);
|
||||
|
||||
deactivate(d);
|
||||
f_shutdown_helper();
|
||||
}
|
||||
|
||||
control {
|
||||
/* CTRL interface testing */
|
||||
execute( TC_ctrl_msc_connection_status() );
|
||||
|
@ -1896,6 +1958,7 @@ control {
|
|||
|
||||
execute( TC_bssap_rlsd_does_not_cause_bssmap_reset() );
|
||||
execute( TC_bssmap_clear_does_not_cause_bssmap_reset() );
|
||||
execute( TC_ms_rel_ind_does_not_cause_bssmap_reset() );
|
||||
}
|
||||
|
||||
}
|
||||
|
|
Loading…
Reference in New Issue