Project

General

Profile

Actions

Bug #3820

open

osmo-hnbgw does not properly do RANAP RESET and RESET ACK on the link towards MSC and SGSN

Added by neels about 5 years ago. Updated almost 3 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
03/04/2019
Due date:
% Done:

0%

Spec Reference:

Description

Currently there is no RESET at all happening on the "cnlink", on the RANAP links towards MSC and SGSN.

The legacy scenario was one distinct SUA connection for each of MSC and SGSN, and each probably did separate RESET handling.
The code looks like it was functional once (though I didn't check).

But now, since we use proper SS7 with an STP in the middle, there obviously is only a single SCCP connection towards both MSC and SGSN.
There is still a bunch of currently dead code that is supposed to do RESET handling, but since both IuCS and IuPS links are handled by a single cnlink instance, its states do not make sense:
for example, say the MSC responded with a RESET ACK, the single cnlink instance would go into CNLINK_S_EST_ACTIVE, even though the SGSN hasn't ACKed yet.

See:
  • hnbgw_cnlink_init() sets up the cnlink->T_RafC timer, which is never triggered.
  • a CNLINK_S_EST_CONF event should trigger T_RafC, but that state is never triggered anywhere (apparently that was a SUA specific legacy?)
  • as soon as the T_RafC timer expires, we would send RESET to both IuCS and IuPS.
  • cn_ranap_rx_reset_ack(), if called for any one domain, would then trigger CNLINK_S_EST_ACTIVE.
  • apparently no code path cares at all about the cnlink state that always stays in CNLINK_S_NULL AFAICT.
A workaround is that MSC / SGSN ignore the missing RESET handling, but it comes at a cost:
  • should MSC / SGSN restart, the connections on the Iuh remain valid and UEs are left in a lost state.
  • should the hnbgw restart, MSC and SGSN would stay with orphaned connections -- not guaranteed to be cleaned up in all cases.
  • I've seen UEs attempting IuRelease requests that get ignored due to unknown conn_id, for minutes and minutes on end,
    and only coming back to activity when switching to flight mode and back.
    Another workaround for this is to make osmo-msc send an IuRelease command for unknown conn_ids before disconnecting, but the RESET should have taken care of that.
Solution:
  • Even though we're using one SCCP instance and one SCCP User for both MSC and SGSN links, there must be two separate FSMs for IuCS and IuPS.
  • Both IuCS and IuPS should send separate RESET messages to MSC / SGSN, respectively, and handle the ACKs for that.
  • If the MSC/SGSN sends a RESET, all open connections must be discarded (best with a preceding IuRelease command to help UEs recover from the lost connection)

Related: in my current neels/ho branch refactoring for osmo-msc, I put in place a flag that ignores a missing RESET on a RAN link.
See ran_peer.c. Once osmo-hnbgw properly sends RESET as well as properly handles incoming RESET, that shim could
be discarded / changed to default to off for IuCS.


Related issues

Related to OsmoMSC - Bug #3944: OsmoMSC doesn't respond to Iu ResetResolvedlaforge04/20/2019

Actions
Actions #1

Updated by laforge almost 5 years ago

  • Related to Bug #3944: OsmoMSC doesn't respond to Iu Reset added
Actions #2

Updated by RobDany about 3 years ago

Actions #3

Updated by laforge almost 3 years ago

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)