pespin submitted this change.
sccp: Introduce rate counter CNLINK_CTR_SCCP_RLSD_CN_ORIGIN
In the general usual case we expect the CN to orderly tear down the conn
by sending a SCCP-DT[RANAP-Iu-ReleaseCommand], which HNB will answer
with RUA-Disconnect[RANAP-Iu-ReleaseComplete], which will trigger a RLC
HNBGW->CN and finally (in state WAIT_RLSD in context_map_sccp) we will
receive a RLSD.
The fact that the CN is unilaterally and directly tearing down the conn
at SCCP level may be useful to spot malfunctions at the CN (eg. SCCP
conn at CN timing out because it never answered the RANAP/DTAP on top,
etc), so it's a good thing to count.
Related: SYS#7454
Change-Id: Icc6d29192574536d3c954a06645f178fa66bff50
---
M include/osmocom/hnbgw/hnbgw_cn.h
M src/osmo-hnbgw/context_map_sccp.c
M src/osmo-hnbgw/hnbgw_cn.c
3 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/include/osmocom/hnbgw/hnbgw_cn.h b/include/osmocom/hnbgw/hnbgw_cn.h
index 6299cde..917cc07 100644
--- a/include/osmocom/hnbgw/hnbgw_cn.h
+++ b/include/osmocom/hnbgw/hnbgw_cn.h
@@ -62,6 +62,7 @@
CNLINK_CTR_SCCP_N_DATA_IND,
CNLINK_CTR_SCCP_N_DISCONNECT_IND,
CNLINK_CTR_SCCP_N_PCSTATE_IND,
+ CNLINK_CTR_SCCP_RLSD_CN_ORIGIN,
/* Counters related to link selection from a CN pool. */
CNLINK_CTR_CNPOOL_SUBSCR_NEW,
diff --git a/src/osmo-hnbgw/context_map_sccp.c b/src/osmo-hnbgw/context_map_sccp.c
index 987e410..f0bbe1b 100644
--- a/src/osmo-hnbgw/context_map_sccp.c
+++ b/src/osmo-hnbgw/context_map_sccp.c
@@ -211,6 +211,7 @@
static void map_sccp_init_action(struct osmo_fsm_inst *fi, uint32_t event, void *data)
{
struct msgb *ranap_msg = NULL;
+ struct hnbgw_context_map *map = fi->priv;
switch (event) {
@@ -238,6 +239,7 @@
case MAP_SCCP_EV_RX_RELEASED:
/* SCCP RLSD received from CN. This will never happen since we haven't even asked for a connection, but
* for completeness: */
+ CNLINK_CTR_INC(map->cnlink, CNLINK_CTR_SCCP_RLSD_CN_ORIGIN);
map_sccp_fsm_state_chg(MAP_SCCP_ST_DISCONNECTED);
return;
@@ -283,6 +285,7 @@
ranap_msg = data;
/* SCCP RLSD received from CN. This will never happen since we haven't even received a Connection
* Confirmed, but for completeness: */
+ CNLINK_CTR_INC(map->cnlink, CNLINK_CTR_SCCP_RLSD_CN_ORIGIN);
handle_rx_sccp(fi, ranap_msg);
map_sccp_fsm_state_chg(MAP_SCCP_ST_DISCONNECTED);
return;
@@ -311,6 +314,7 @@
static void map_sccp_connected_action(struct osmo_fsm_inst *fi, uint32_t event, void *data)
{
+ struct hnbgw_context_map *map = fi->priv;
struct msgb *ranap_msg = NULL;
bool rua_disconnect_err_condition;
@@ -361,6 +365,7 @@
case MAP_SCCP_EV_RX_RELEASED:
ranap_msg = data;
/* The CN sends an N-Disconnect (SCCP Released). */
+ CNLINK_CTR_INC(map->cnlink, CNLINK_CTR_SCCP_RLSD_CN_ORIGIN);
handle_rx_sccp(fi, ranap_msg);
map_sccp_fsm_state_chg(MAP_SCCP_ST_DISCONNECTED);
return;
diff --git a/src/osmo-hnbgw/hnbgw_cn.c b/src/osmo-hnbgw/hnbgw_cn.c
index dd560e3..8a7f88e 100644
--- a/src/osmo-hnbgw/hnbgw_cn.c
+++ b/src/osmo-hnbgw/hnbgw_cn.c
@@ -482,6 +482,10 @@
"sccp:n_pcstate:ind",
"Received SCCP N-PCSTATE.ind"
},
+ [CNLINK_CTR_SCCP_RLSD_CN_ORIGIN] = {
+ "sccp:rlsd_cn_origin",
+ "Received unexpected SCCP RSLD originated unilaterally by CN"
+ },
/* Indicators for CN pool usage */
[CNLINK_CTR_CNPOOL_SUBSCR_NEW] = {
To view, visit change 40248. To unsubscribe, or for help writing mail filters, visit settings.