Project

General

Profile

Actions

Feature #4701

closed

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

Added by neels over 3 years ago. Updated about 3 years 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-sgsnNewneels11/07/2017

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

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

Actions
Actions #1

Updated by neels over 3 years ago

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

Updated by neels over 3 years ago

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

Updated by neels over 3 years ago

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

Updated by laforge about 3 years 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.

Actions #5

Updated by laforge about 3 years 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.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)