Harald Welte has submitted this change and it was merged.

Change subject: bsc: add TC_ms_rel_ind_does_not_cause_bssmap_reset
......................................................................


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
---
M bsc/BSC_Tests.ttcn
1 file changed, 63 insertions(+), 0 deletions(-)

Approvals:
  Harald Welte: Looks good to me, approved
  Jenkins Builder: Verified



diff --git a/bsc/BSC_Tests.ttcn b/bsc/BSC_Tests.ttcn
index 3b5c860..972d912 100644
--- a/bsc/BSC_Tests.ttcn
+++ b/bsc/BSC_Tests.ttcn
@@ -1820,6 +1820,68 @@
        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 @@
 
        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() );
 }
 
 }

-- 
To view, visit https://gerrit.osmocom.org/7219
To unsubscribe, visit https://gerrit.osmocom.org/settings

Gerrit-MessageType: merged
Gerrit-Change-Id: Ie4aa2f01c83b40303fa40ed64dbfce372b7cd96c
Gerrit-PatchSet: 2
Gerrit-Project: osmo-ttcn3-hacks
Gerrit-Branch: master
Gerrit-Owner: Neels Hofmeyr <nhofm...@sysmocom.de>
Gerrit-Reviewer: Harald Welte <lafo...@gnumonks.org>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: Neels Hofmeyr <nhofm...@sysmocom.de>

Reply via email to