https://projects.osmocom.org/https://projects.osmocom.org/favicon.ico?16647414092018-09-30T11:40:23ZOpen Source Mobile CommunicationsOsmoSGSN - Bug #3403: osmo-sgsn doesn not connect properly with via SCCP when restartedhttps://projects.osmocom.org/issues/3403?journal_id=117792018-09-30T11:40:23Zlaforge
<ul><li><strong>Assignee</strong> set to <i>laforge</i></li></ul> OsmoSGSN - Bug #3403: osmo-sgsn doesn not connect properly with via SCCP when restartedhttps://projects.osmocom.org/issues/3403?journal_id=117912018-09-30T11:55:13Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-1 priority-3 priority-high3" href="/issues/2623">Feature #2623</a>: SCCP/M3UA: detect restart of osmo-msc and osmo-sgsn</i> added</li></ul> OsmoSGSN - Bug #3403: osmo-sgsn doesn not connect properly with via SCCP when restartedhttps://projects.osmocom.org/issues/3403?journal_id=122672018-10-17T10:20:23Zlaforge
<ul><li><strong>Assignee</strong> changed from <i>laforge</i> to <i>msuraev</i></li></ul> OsmoSGSN - Bug #3403: osmo-sgsn doesn not connect properly with via SCCP when restartedhttps://projects.osmocom.org/issues/3403?journal_id=138502019-04-09T11:22:44Zlaforge
<ul><li><strong>Assignee</strong> changed from <i>msuraev</i> to <i>lynxis</i></li></ul> OsmoSGSN - Bug #3403: osmo-sgsn doesn not connect properly with via SCCP when restartedhttps://projects.osmocom.org/issues/3403?journal_id=139112019-04-14T04:21:08Zlynxis
<ul><li><strong>Assignee</strong> changed from <i>lynxis</i> to <i>laforge</i></li></ul><p><a class="user active" href="https://projects.osmocom.org/users/7">laforge</a> can you take a look? I don't know the SCCP stack. IMHO: we should send out a RESET to the connections within libsccp. But how does the other end (HNBGW) notices, that the SGSN has been restarted? In <a class="issue tracker-2 status-1 priority-3 priority-high3" title="Feature: SCCP/M3UA: detect restart of osmo-msc and osmo-sgsn (New)" href="https://projects.osmocom.org/issues/2623">#2623</a> you wrote</p>
<blockquote>
<p>One could implement the classic SCCP messsages / primitives for infomring the BSC that the MSC is no longer reachable at the old point code. On the MTP-level, this is MTP-STATUS.ind from the MTP up into the SCCP stack. The SCCP stack then would use N-PCSTATE.ind (Q.711 6.3.2.3.3)</p>
</blockquote>
<p>And we don't know how many HNBGW will connect to the SGSNs and what's their address in advance.</p> OsmoSGSN - Bug #3403: osmo-sgsn doesn not connect properly with via SCCP when restartedhttps://projects.osmocom.org/issues/3403?journal_id=139232019-04-15T07:28:56Zlaforge
<ul><li><strong>Assignee</strong> changed from <i>laforge</i> to <i>lynxis</i></li></ul><p>This is nothing that is handled at the SCCP level. SCCP just provides transport of RANAP messages. The logical "reset" state between a given RNC/HNBGW and the SGSN must be done on RANAP level. The fact that a given peer is no longer reachable is detected mainly if no responses to [normal] messages are received, and the RANAP RESET procedure is used to re-initialize the logical relation between two peers.</p>
<p>SCCP may in the future provide us hints to detect outages more reliably/directly, but that doesn't prevent us from implementing this properly.</p> OsmoSGSN - Bug #3403: osmo-sgsn doesn not connect properly with via SCCP when restartedhttps://projects.osmocom.org/issues/3403?journal_id=139242019-04-15T07:29:15Zlaforge
<ul><li><strong>Category</strong> set to <i>Iu interface</i></li></ul> OsmoSGSN - Bug #3403: osmo-sgsn doesn not connect properly with via SCCP when restartedhttps://projects.osmocom.org/issues/3403?journal_id=170872020-01-08T22:48:44Zlaforge
<ul><li><strong>Assignee</strong> deleted (<del><i>lynxis</i></del>)</li></ul> OsmoSGSN - Bug #3403: osmo-sgsn doesn not connect properly with via SCCP when restartedhttps://projects.osmocom.org/issues/3403?journal_id=212092021-02-07T12:57:14Zlaforge
<ul><li><strong>Assignee</strong> set to <i>lynxis</i></li></ul><p>I've implemented notification of SCCP users via the SCCP-User SAP in <a class="external" href="https://gerrit.osmocom.org/c/libosmo-sccp/+/22778">https://gerrit.osmocom.org/c/libosmo-sccp/+/22778</a></p>
<p>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 <br />sp_status OSMO_SCCP_SP_S_INACCESSIBLE or OSMO_SCCP_SP_S_ACCESSIBLE.</p>
<p>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 <a class="user active" href="https://projects.osmocom.org/users/1741">lynxis</a>. I'll just implement some tests to ensure we get those notifications as expected now.</p>