diff options
author | Neels Hofmeyr <neels@hofmeyr.de> | 2018-03-09 15:39:31 +0100 |
---|---|---|
committer | Neels Hofmeyr <neels@hofmeyr.de> | 2018-03-12 04:43:16 +0100 |
commit | fd445c34fe47349f9576b6a8e4c53372e2ca8a59 (patch) | |
tree | 3492f99147e445cb232e5cb49497e69a803244dd /bsc | |
parent | 27f643639e43a146eab090d723692f47efa452a6 (diff) |
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
Diffstat (limited to 'bsc')
-rw-r--r-- | bsc/BSC_Tests.ttcn | 63 |
1 files changed, 63 insertions, 0 deletions
diff --git a/bsc/BSC_Tests.ttcn b/bsc/BSC_Tests.ttcn index 3b5c8600..972d912a 100644 --- a/bsc/BSC_Tests.ttcn +++ b/bsc/BSC_Tests.ttcn @@ -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() ); } } |