Project

General

Profile

Feature #4701

implement OsmoSTP notification of peers disconnecting, e.g. for OsmoBSC to detect that a specific MSC in the pool is disconnected

Added by neels 7 months ago. Updated 18 days ago.

Status:
Resolved
Priority:
Normal
Assignee:
Target version:
-
Start date:
08/11/2020
Due date:
% Done:

100%

Spec Reference:

Description

This is a spin-off from the discussion in #4619 (where the MSC-pooling tests leave osmo-bsc in a state of assuming presence of MSCs that have disconnected)
and also related to #2623 (which is actually more about sending RESET upon re-connect)

The aim is to be able to immediately notify of disconnected peers across the STP (e.g. BSC <-> MSC).

laforge wrote:

On Fri, Aug 07, 2020 at 01:44:00PM +0000, neels [REDMINE] wrote:

Now I need to pinpoint what exactly the right mechanism would be for osmo-bsc to realize that an MSC is no longer connected.

Without any active calls (SCCP connections) you don't really know.

The only situations are:
  • SCCP connection timers timing out (if there are any active SCCP connections)
  • SCCP network informing the user about unavailability of a given point code
    • we don't imlpement this in Osmocom so far, but there are messages like
      M3UA DUNA/DAVA that can be used by an STP to notify M3UA ASPs like the BSC about
      availability/unavailability of a given point code.
    • libosmo-sigtan would have to parse such messages and send N-NOTICE.indication
      from the SCCP provider to the SCCP user (local SCCP user like MSC, BSC, ...),
      as well as N-INFO.indication for active SCCP connections

Related issues

Related to Cellular Network Infrastructure - Feature #2623: SCCP/M3UA: detect restart of osmo-msc and osmo-sgsnNew11/07/2017

Related to Cellular Network Infrastructure - Bug #4619: ttcn3-bsc-test: all LCLS test cases broken since build #987Resolved06/17/2020

Related to OsmoBSC - Bug #4832: osmo-bsc hard-releases lchan if no MSC is foundStalled10/25/2020

Associated revisions

Revision bfc85e43 (diff)
Added by pespin 6 months ago

ctrl: Fix CTRL TRAP for {msc.X,msc_)connection_status not sent

The tx TRAP callback is triggered through a signal which is never sent in
osmo-bsc code, and never was as far as I can tell going quite far in the
logs.
In the meanwhile, the msc_connection_status was left in favour of
multi-msc msc.X.connection_status CTRL variable, so let's prepre the cb
function to work for that onei too, dropping global variables which may lead
to wrong output in multi-msc environments, and simply use msc->nr==0 for
the old variable "msc_connection_status".

The signal is now triggered in a_reset when the A conn becomes connected
or disconnected. As a result, a user waiting for the disconnect event
may notice that the status may be changed with a noticeable delay, since
the A conn may be reset only due to high layer timeouts after several
repeated failures (T4, BAD_CONNECTION_THRESOLD).

Related: OS#2623
Related: OS#4701
Related: SYS#5046
Change-Id: I645d198e8e1acd0aba09d05cb3ae90443946acf8

History

#1 Updated by neels 7 months ago

  • Related to Feature #2623: SCCP/M3UA: detect restart of osmo-msc and osmo-sgsn added

#2 Updated by neels 7 months ago

  • Related to Bug #4619: ttcn3-bsc-test: all LCLS test cases broken since build #987 added

#3 Updated by neels 4 months ago

  • Related to Bug #4832: osmo-bsc hard-releases lchan if no MSC is found added

#4 Updated by laforge 22 days ago

  • Assignee set to neels

I've implemented notification of SCCP users via the SCCP-User SAP in https://gerrit.osmocom.org/c/libosmo-sccp/+/22778

This means that every time a [remote] point code becomes available or unavailable, the SCCP user application (MSC, BSC, SGSN, SMLC, ...) should now receive a N-PCSTATE.ind stating the "affected point code". and either
sp_status OSMO_SCCP_SP_S_INACCESSIBLE or OSMO_SCCP_SP_S_ACCESSIBLE.

This indication should then be used by the applications to trigger whatever internal logic that needs to happen if a remote point-code disappears or re-appears. I'll leave that part to @neels. I'll just implement some tests to ensure we get those notifications as expected now.

#5 Updated by laforge 18 days ago

  • Status changed from New to Resolved
  • % Done changed from 0 to 100
  • We have MTP-level notifications by means of M3UA DUNA/DAVA in place now, as shown by the below three test cases
    • TC_ssnm_aspac_dava_aspia_duna
    • TC_ssnm_distribution_dava_duna
    • TC_ssnm_distribution_dava_duna_multipc
  • those are now reported via N-PCSTATE primitives on the SCCP user SAP

There's some additional work in the pipeline to also provide separate notifications of SSN availability, etc. but none of that would strictly fall within the scope of this specific issue. Marking it resolved.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)