Cellular Network Infrastructure » Radio Access Network » OsmoBSC

The file osmo_bsc_reset.c turned out to be dead code (was not not even compiled). I have removed the file now: https://gerrit.osmocom.org/7476

I have checked the problem back. The most convenient way to call a_reset_conn_fail() is when we notice that an SCCP connection indeed failes (CR is not answered). From the logical perspective and when I understand the things right, I should get an OSMO_SCU_PRIM_N_DISCONNECT in osmo_bsc_sigtran.c:sccp_sap_up(). Unfortunately I do not see any OSMO_SCU_PRIM_N_DISCONNECT indication at all. Shouldn't the SCCP stack make sure that there actually is a connection made and inform in case the connection attempt failes?

Apart from this it is also debatable if we need the error detection at all. The reason why osmo-msc and osmo-bsc work fine even with a dysfunctional error detection is because both parties are sending an BSSMAP reset when they start up. So if one side goes down, the opposite side is informed when the side that was down is up again. However, we could run into problems when we use a third party MSC that does not do a bssmap RESET when it is starting up (I do not know how strict the spec is in this case and how common the MSC sideded reset is)

I think I found the reason why we do not get the N_DISCONNECT.ind. Its simply because the timer 993210 (20sek) is set expiring earlier than the CONNECTION_TIMER (60sek) in libosmo-sccp. When I increase 993210 to more than 60sek, then I get the N-DISCONNECT.ind with cause code 0.

Fri Apr 13 15:30:16 2018 DRLL <0000> chan_alloc.c:665 (bts=0) channel load average is 10.24%
Fri Apr 13 15:30:16 2018 DRLL <0000> chan_alloc.c:678 (bts=0) T3122 wait indicator set to 14 seconds
Fri Apr 13 15:30:17 2018 DMSC <0008> osmo_bsc_sigtran.c:217 N-DISCONNECT.ind(2, , cause=0)
Fri Apr 13 15:30:17 2018 DMSC <0008> osmo_bsc_sigtran.c:224 SUBSCR_CONN[0x561cf2183dc0]{WAIT_CC}: Received Event DISCONNET.ind
Fri Apr 13 15:30:17 2018 DMSC <0008> bsc_subscr_conn_fsm.c:979 SUBSCR_CONN[0x561cf2183dc0]{WAIT_CC}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
Fri Apr 13 15:30:17 2018 DMSC <0008> bsc_subscr_conn_fsm.c:297 SUBSCR_CONN[0x561cf2183dc0]{WAIT_CC}: tossing all MGCP connections...
Fri Apr 13 15:30:17 2018 DMSC <0008> bsc_subscr_conn_fsm.c:1017 SUBSCR_CONN[0x561cf2183dc0]{WAIT_CC}: Releasing lchan
Fri Apr 13 15:30:17 2018 DRLL <0000> chan_alloc.c:540 (bts=0,trx=0,ts=0,ss=1) starting release sequence

So, libosmo-sccp seems to work fine here.

Here is a fix that uses the expiration of 993210 to inform the A-RESET FSM about a connection problem. When a certain number of connection errors occurred consecutively, then the BSC starts sending out BSSMAP RESET messages again.
https://gerrit.osmocom.org/7794

We might have the following error situation:

Problem: The MSC restarts, but since it lost all its state it does not know about any BSC, eventually the MSC can not inform about the reset.

There are two possible approaches I see here:

1) We drop all input from an unknown (not yet known) BSC. The BSC will notice that the connection is bad and fall back into the disconnected state, sending continues BSSMAP resets until an answer is received.

2) When the MSC receives a message from an unknown BSC, it responds with a BSSMAP reset immediately.

Approach No. 1 is currently implemented. I wonder if No. 2 is cleaner, but maybe we should keep it as it is.

I share the impression that we might not need the FSM, given the Reset sent to a BSC on first seeing it, and the BSC sending Reset on restarting.
It would be good if you shared your test results. Have you played out various scenarios?
Like, what currently happens when we do:

• restart MSC
  • during "silence"
  • during ongoing communication.
• same for BSC.
• pull some ethernet cable between MSC and BSC
  • "left" of the STP
  • "right" of the STP
• re-connect ethernet cable after a while
• kill the STP, restart after a while

Does any lock-up or too long timeouts occur before the system becomes operational?
Would the a_reset FSM help with that?

Did some test, when restarting the MSC in total silence everything seems to be ok, but when I restart it in the middle of some communication things go problematic. I think this mostly has something to do with the phones which are not registered anymore but still think that they are registered.

Like with the MSC I also cleaned up the code that handles the BSSMAP reset. See also: https://gerrit.osmocom.org/#/c/8055/

The following two patches (already merged) finish up the cleanups to a_reset.c:

https://gerrit.osmocom.org/#/c/osmo-msc/+/8054/
https://gerrit.osmocom.org/#/c/osmo-bsc/+/8055/

The problem I noticed ("communication things") was caused by the usage of wrong cause codes. The wrong cause codes prevented the MS to try an LU when the network rejects the CM-Service request. This is now also fixed:

https://gerrit.osmocom.org/#/c/osmo-msc/+/9169/