Feature #3102

Updated by neels over 1 year ago

After issue #3041 was fixed by the new gscon FSM, it became apparent that the a_reset.c FSM is actually no longer used at all: a_reset_conn_fail() is never invoked.

I also noticed in osmo_bsc_reset.c, we have an evil twin of a_reset.c still in the code base.
Its events also seem to never be invoked.
(BTW, in osmo-msc, we also never invoke a_reset_conn_fail())

In summary, the Reset FSMs are in desperate need of some tender loving care, they are currently abandoned and useless, apparently.

The proper trigger to invoke a_reset_conn_fail(): it was mentioned that specific N-Disconnect causes indicate a failure versus a normal disconnect.
a_reset_conn_fail() should only be invoked upon receiving such failure cause.

If possible, some ttcn3 test should simulate such a failure disconnect.

Also debatable is the conn_loss_count: if there are only two SCCP connections, and both of them go up in flames, the reset FSM should probably not wait for a third erratic disconnect; it should fire a BSSMAP BSSAP Reset as well?


Add picture from clipboard (Maximum size: 48.8 MB)