Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092024-03-26T14:00:15ZOpen Source Mobile Communications
Redmine OsmoMGW - Bug #6424 (In Progress): TC_one_crcx_loopback_rtp_implicit consistently failing in mast...https://osmocom.org/issues/64242024-03-26T14:00:15Zlaforge
<p>`TC_one_crcx_loopback_rtp_implicit` appears to be failing consistently in master for 30+ consecutive builds. Meanwhile, the same test is passing just fine in latest. So there seems to be some (long-standing) regression in master?</p> Osmo-CC - Feature #6319 (New): protocol version should have a defined end markerhttps://osmocom.org/issues/63192023-12-25T00:38:03Zneelsnhofmeyr@sysmocom.de
<p>in osmo-cc-v0.91.pdf I read:</p>
<pre>When a connection is established, both ends send a version string of eight bytes:
“OSMOCCv1” first. (no \0 termination, no line feed, case sensitive) The Version number is
defined by the eighth byte. In this case the protocol version is ‘1’.</pre>
<p>I think it would be better to make this more flexible than a single version char.</p>
<p>I was thinking, what happens when we reach "OSMOCCv10"? It cannot be distinguished from "OSMOCCv1" followed by an unrelated "0".</p>
<p>So I guess it should actually be \0 terminated, or it should be in a TLV, or it should be defined that the version string is sent in a single TCP packet where the entire payload is just the version string? Something that allows extending the string in the future.</p>
<p>What do you think?</p> OsmoBSC - Bug #6318 (Feedback): Show lchan shows wrong number of channels for TCHhttps://osmocom.org/issues/63182023-12-23T15:14:50Zmatanp
<p>When configuring a channel is configured as TCH, `show lchan` show 3 lchans for that channel.</p>
<p>tested on commit 9baa065c8da5ecd96e9a2f2c6d5d1c57ece754b2, I will test it on the master soon</p> OsmoMSC - Bug #6217 (Feedback): Bearer Capability mismatch in MT SETUPhttps://osmocom.org/issues/62172023-10-10T13:13:58Zfixeria
<p>While investigating <a class="issue tracker-1 status-3 priority-2 priority-default closed" title="Bug: mobile: MT calls not working anymore (Resolved)" href="https://osmocom.org/issues/6216">#6216</a>, I noticed that the Bearer Capability in MT SETUP looks weird and does not match such in the MO SETUP.</p>
<p>[frame 9] MO Setup (from SE K800):</p>
<pre>
Bearer Capability 1 - (MS supports at least full rate speech version 1 and half rate speech version 1. MS has a greater preference for full rate speech version 1 than for half rate speech version 1)
Element ID: 0x04
Length: 6
Octet 3
0... .... = Extension: Extended
.11. .... = Radio channel requirement: MS supports at least full rate speech version 1 and half rate speech version 1. MS has a greater preference for full rate speech version 1 than for half rate speech version 1
...0 .... = Coding standard: GSM standardized coding
.... 0... = Transfer mode: circuit
.... .000 = Information transfer capability: Speech (0x0)
Octets 3a - Speech Versions
0... .... = Extension: Extended
.0.. .... = Coding: octet used for extension of information transfer capability
..00 .... = Spare bit(s): 0
.... 0100 = Speech version indication: GSM full rate speech version 3(FR AMR) (0x4)
0... .... = Extension: Extended
.0.. .... = Coding: octet used for extension of information transfer capability
..00 .... = Spare bit(s): 0
.... 0010 = Speech version indication: GSM full rate speech version 2(GSM EFR) (0x2)
0... .... = Extension: Extended
.0.. .... = Coding: octet used for extension of information transfer capability
..00 .... = Spare bit(s): 0
.... 0000 = Speech version indication: GSM full rate speech version 1(GSM FR) (0x0)
0... .... = Extension: Extended
.0.. .... = Coding: octet used for extension of information transfer capability
..00 .... = Spare bit(s): 0
.... 0101 = Speech version indication: GSM half rate speech version 3(HR AMR) (0x5)
1... .... = Extension: No Extension
.0.. .... = Coding: octet used for extension of information transfer capability
..00 .... = Spare bit(s): 0
.... 0001 = Speech version indication: GSM half rate speech version 1(GSM HR) (0x1)
</pre>
<p>[frame 22] MT Setup (from osmo-msc):</p>
<pre>
Bearer Capability 1 - (MS supports at least full rate speech version 1 and half rate speech version 1. MS has a greater preference for full rate speech version 1 than for half rate speech version 1)
Element ID: 0x04
Length: 5
Octet 3
0... .... = Extension: Extended
.11. .... = Radio channel requirement: MS supports at least full rate speech version 1 and half rate speech version 1. MS has a greater preference for full rate speech version 1 than for half rate speech version 1
...0 .... = Coding standard: GSM standardized coding
.... 0... = Transfer mode: circuit
.... .000 = Information transfer capability: Speech (0x0)
Octets 3a - Speech Versions
0... .... = Extension: Extended
.0.. .... = Coding: octet used for extension of information transfer capability
..00 .... = Spare bit(s): 0
.... 0100 = Speech version indication: GSM full rate speech version 3(FR AMR) (0x4)
0... .... = Extension: Extended
.0.. .... = Coding: octet used for extension of information transfer capability
..00 .... = Spare bit(s): 0
.... 0101 = Speech version indication: GSM half rate speech version 3(HR AMR) (0x5)
0... .... = Extension: Extended
.0.. .... = Coding: octet used for extension of information transfer capability
..00 .... = Spare bit(s): 0
.... 1011 = Speech version indication: GSM half rate speech version 6(OHR AMR) (0xb)
1... .... = Extension: No Extension
.0.. .... = Coding: octet used for extension of information transfer capability
..00 .... = Spare bit(s): 0
.... 0000 = Speech version indication: GSM full rate speech version 1(GSM FR) (0x0)
</pre>
<p>osmo-msc.git 1792ba92c1f939fb232e25ae1124eda7bb11983f (1.11.1)<br />libosmocore.git 435856be518c9d3531ae5b8cbadac1474d521f3a</p> Core testing infrastructure - Bug #6185 (New): Submit titan.ProtocolEmulations.SCCP patch upstreamhttps://osmocom.org/issues/61852023-09-20T11:38:25Zpespin
<p>It was noticed that we currently hold & use in osmo-ttcn3-hacks our own fork of titan.ProtocolEmulations.SCCP.git [1].</p>
<p>We use our own fork because we are using an extra patch on top of master [2]. AFAICT, that patch has never been submitted upstream, but at first glance it looks like it should?</p>
<p>The upstream to submit to is in gitlab [3].</p>
<p>[1] <a class="external" href="https://github.com/osmocom/titan.ProtocolEmulations.SCCP">https://github.com/osmocom/titan.ProtocolEmulations.SCCP</a><br />[2] <a class="external" href="https://github.com/osmocom/titan.ProtocolEmulations.SCCP/commit/17a894fc6620a0df11d0d98c897fb66168276b16">https://github.com/osmocom/titan.ProtocolEmulations.SCCP/commit/17a894fc6620a0df11d0d98c897fb66168276b16</a><br />[3] <a class="external" href="https://gitlab.eclipse.org/eclipse/titan/titan.ProtocolEmulations.SCCP">https://gitlab.eclipse.org/eclipse/titan/titan.ProtocolEmulations.SCCP</a></p> OsmoMSC - Feature #6151 (Feedback): osmo-msc: Ability to configure (VTY) the AMR(-WB) formats use...https://osmocom.org/issues/61512023-08-25T16:04:43Zpespin
<p>Right now, RAB-ASsignment-Req message is built in osmo-iuh.git and it is hardcoded to built an RFCI list basically containing AMR 12k2.</p>
<p>The interesting related code path is:<br /><pre>
ran_iu_encode(RAN_MSG_ASSIGNMENT_COMMAND)
ran_iu_make_rab_assignment
ranap_new_msg_rab_assign_voice [osmo-iuh]
new_rab_par_voice
new_sdu_par_item
</pre></p>
<p>If you check new_sdu_par_item() in osmo-iuh.git (<a class="external" href="https://gitea.osmocom.org/cellular-infrastructure/osmo-iuh/src/branch/master/src/ranap_msg_factory.c#L556">https://gitea.osmocom.org/cellular-infrastructure/osmo-iuh/src/branch/master/src/ranap_msg_factory.c#L556</a>), you can see how the SDUs are added there, hardcoded.</p>
<p>Ideally, the RFCI list would be passed to ranap_new_msg_rab_assign_voice() from osmo-msc.</p>
<p>Then, from osmo-msc, an RFCI would be built based on:<br />- Whether the UE supports AMR or AMR-WB (CC Setup message, "Supported Codec List" IE)<br />- Whether osmo-msc is configured to serve AMR or/and AMR-WB on the VTY<br />- Whatever other restrictions on the other call leg</p>
<p>This would allow, for instance testing IuUP/AMR-WB calls.</p>
<p>If AMR-WB is selected, we probably need to update the SDP related paths to add "16000" after IUFP:<br /><pre>
a=rtpmap:97 VND.3GPP.IUFP/16000
</pre></p>
Some related specs:
<ul>
<li>3GPP TS 25.413 (RANAP)</li>
<li>3GPP TS 25.415 (IuUP)</li>
<li>3GPP TS 26.103 (Speech codec List for GERAN anf UMTS)</li>
<li>3GPP TS 26.171, 3GPP TS 26.201, 3GPP TS 26.202 (AMR-WB)</li>
<li>RFC 4867 (RTP for AMR, AMR-WB)</li>
</ul> libosmo-sccp + libosmo-sigtran - Feature #5917 (Feedback): immediately detect SCTP SHUTDOWN in SC...https://osmocom.org/issues/59172023-02-21T03:39:24Zneelsnhofmeyr@sysmocom.de
<p>This is a question about SCCP concepts for link loss detection.</p>
<p>I'm trying to trigger an SCCP link loss to examine the cleanup / leak behavior of osmo-hnbgw.<br />I'd like to find out how an SCTP link loss would propagate to osmo-hnbgw code and signal an SCCP link loss.<br />(IOW looking for a place that would trigger an FSM event like MY_SCCP_EV_LINK_LOST)</p>
<p>I have two scenarios, one that osmo-stp is killed, the other that the remote entity behind osmo-stp is disconnected.</p>
<hr />
<p>(1) kill osmo-stp</p>
I tried this:
<ul>
<li>in HNBGW_Tests.ttcn, cranked up T_guard to 10000.0 s</li>
<li>in a RAB Assignment test, just after the RAB is established, insert f_sleep(5000.0)</li>
<li>run the test to establish a context mapping with SCCP connection in osmo-hnbgw</li>
<li>kill osmo-stp</li>
</ul>
<p>I immediately see lots of low level DLINP, DLSS7 and some DLSCCP logging showing that an SCTP SHUTDOWN event was processed, and that the XUA AS restarts and tries to reconnect. But none of this makes its way up into osmo-hnbgw.</p>
<p>After about 15 minutes(!), I receive sccp_sap_up(N-DISCONNECT.indication) on the SCCP connection.<br />So, we do have a cleanup trigger, but</p>
<ul>
<li>Is it expected to take this long, given that an SCTP SHUTDOWN is detected in libosmo-sigtran immediately?</li>
<li>Do we only get an N-DISCONNECT on individual SCCP conns? My idea was to trigger a LINK_LOST event on the SCCP link to the CN, i.e. a signal that the entire SCCP layer is gone. Does that exist, conceptually?</li>
</ul>
<p>(log attached)</p>
<p>In contrast, when the RUA side of osmo-hnbgw sees an SCTP SHUTDOWN, osmo-hnbgw immediately registers that all HNB are disconnected, by means of the read cb() passed to osmo_stream_srv_create().</p>
<hr />
<p>(2) disconnect remote SCCP peer, STP still up<br />i.e. in ttcn, after the conn is established, call f_ran_adapter_cleanup(g_msc); f_ran_adapter_cleanup(g_sgsn);<br />and continue to f_sleep(5000.0) keeping the HNB connected.</p>
<p>Here I immediately see an N-PCSTATE.indication containing a DUNA (Destination Unavailable) coming up the SCCP user SAP, one each for the MSC and the SGSN point-code. osmo-hnbgw ignores N-PCSTATE so far, I guess it might be a good idea to implement acting on the DUNA messages. I see now that we can simply read out prim->u.pcstate.</p>
<p>Since the DUNA is so far ignored, the same as above happens. After about 15 minutes, sccp_scoc.c sends up an N-DISCONNECT for the individual SCCP connection and we do clean up, eventually.</p>
<hr />
So in summary:
<ul>
<li>when a remote entity behind STP goes bust, i can already now trigger my LINK_LOST event when osmo-hnbgw sees a PCSTATE indicating that the remote point-code for CS / PS CN becomes unavailable.</li>
<li>when the first SCTP hop goes bust (kill osmo-stp), maybe we can implement some prim going up the SCCP user SAP? Would that also be a DUNA, based on active SCCP conns' remote point-code, or is that a hacky layer violation?</li>
</ul> OsmoHNBGW - Feature #5904 (New): HNBAP Register Request handling does checks that seem to make no...https://osmocom.org/issues/59042023-02-11T02:28:42Zneelsnhofmeyr@sysmocom.de
<p>Looking at this code, a couple of things seem to make no sense:</p>
<p><a class="external" href="https://gitea.osmocom.org/cellular-infrastructure/osmo-hnbgw/src/commit/a3c7f750a2f77c0c0e0ade1800f5b3a97a2f0b6e/src/osmo-hnbgw/hnbgw_hnbap.c#L431">https://gitea.osmocom.org/cellular-infrastructure/osmo-hnbgw/src/commit/a3c7f750a2f77c0c0e0ade1800f5b3a97a2f0b6e/src/osmo-hnbgw/hnbgw_hnbap.c#L431</a></p>
<ul>
<li>we are using getpeername() to compare the remote address of the current ctx to all other hnb. But we are handling a PDU in an accept()ed connection, and the hnb_context *ctx has already been looked up according to the remote address the PDU was received from.</li>
</ul>
<ul>
<li>assuming there are two connections from the same remote address, what do we care about the IP address? if there are two HNB entities connecting via two distinct conns, so be it, from the same address or not. We should only care about the HNB id (LAC,SAC,RAC,CID,MCC,MNC identity)</li>
</ul>
<ul>
<li>assuming we want to check the remote address: in the error checking path of failed getpeername(), we are still going on to compare as if the result from getpeername() was valid.</li>
</ul>
<ul>
<li>the loop is guarding against two HNB registering with identical HNB id.
<ul>
<li>When this occurs from the same remote address, we discard the <strong>old</strong> hnb_context. However, in practice it seems that instead of allocating another hnb_context on the same remote address, instead the HNB-Register-Req is dispatched to the same hnb_context in osmo-hnbgw, and this loop is essentially skipped (the log often shows the "(duplicated)" at the bottom of the function).</li>
<li>When this occurs from a different remote address, we reject the <strong>new</strong> hnb_context (bottom of the loop body). Now, in recent efforts to hunt down UE state leaks in osmo-hnbgw, it became clear that a HNB disconnecting may go unnoticed. Imagine a HNB's conn being disrupted, its state still present in osmo-hnbgw. If a new conn is established for this HNB from another remote address, we refuse this new connection, favoring the disrupted connection. It may be frustrating for a user trying to reconnect a HNB via a different link. The comment names two reasons:
<ul>
<li>misconfiguration: it is the user's responsibility to configure distinct HNBs with distinct identities. Is it helpful to refuse a new connection when a previous connection became stale and lingers? It may avoid oscillation of two HNBs with same id competing, but it is also hard to recover from a failed link when refusing new connections.</li>
<li>impersonation: we have no authentication of HNB, we are utterly incapable of avoiding impersonation anyway.</li>
</ul></li>
</ul></li>
</ul>
<p>3GPP TS 25.469 8.2.4 Abnormal Conditions:<br />""" <br />If the HNB-GW receives a duplicate HNB REGISTER REQUEST (i.e. for an already registered HNB identified by the<br />unique HNB identity), then the new HNB REGISTER REQUEST shall override the existing registration and the<br />handling of the new HNB REGISTER REQUEST is according to section 8.2.<br />"""</p>
Context:
<ul>
<li>this patch introduced the reject on duplicate HNB REGISTER REQ: <a class="external" href="https://gitea.osmocom.org/cellular-infrastructure/osmo-iuh/commit/c964a2cfa1b08e5bbda5d721a7a0095d26b53791">https://gitea.osmocom.org/cellular-infrastructure/osmo-iuh/commit/c964a2cfa1b08e5bbda5d721a7a0095d26b53791</a></li>
<li>this patch introduced accepting the new HNB REGISTER REQ when from the same address: <a class="external" href="https://gitea.osmocom.org/cellular-infrastructure/osmo-hnbgw/commit/12bc4afab3096c60554cd6d43fa11840bd76228c">https://gitea.osmocom.org/cellular-infrastructure/osmo-hnbgw/commit/12bc4afab3096c60554cd6d43fa11840bd76228c</a></li>
</ul>
<p>It seems the initial motion to reject a duplicate HNB REGISTER was wrong, and the newer patch tried to alleviate this, but still kept the rejection based on the remote address for reasons not named.</p>
My idea for this is:
<ul>
<li>do not check remote addresses at all.</li>
<li>compare only HNB IDs. If they match, always discard the <strong>old</strong> hnb_context, allow the new HNB register.</li>
</ul>
<p>To test this, I implemented this behavior, and HNBGW_Tests.ttcn3 still succeed<br />(with only the expected failure of TC_hnb_register_duplicate() that no longer gets the HNB Register Reject it wants to see)<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-hnbgw/+/31289">https://gerrit.osmocom.org/c/osmo-hnbgw/+/31289</a></p>
<p>feedback welcome</p> OsmoHNBGW - Bug #5876 (New): on HNBAP HNB Register, clear previous UE state if anyhttps://osmocom.org/issues/58762023-01-25T14:03:01Zneelsnhofmeyr@sysmocom.de
<p>when a HNB registers with osmo-hnbgw, and the same HNB is already registered, osmo-hnbgw keeps the HNB state and simply logs "(duplicated)" with the HNB Register Request log.</p>
<p>A HNB should only register when it has restarted, and no UE state should stay around when that happens.<br />So, upon HNB Register Request, if we find that HNB already connected, clear out any previous state on that HNB.</p>
<p>Otherwise we likely keep stale UE state and stale SCCP conns indefinitely, by ignoring a restart of a HNB.</p> Cellular Network Infrastructure - Feature #5771 (New): series of presentations about the invididu...https://osmocom.org/issues/57712022-11-14T19:25:57Zlaforge
<p>Most of the talks we ever gave on setting up and running the Osmocom CNI are ages old and hence relatively outdated.</p>
<p>Given the number of network elements and the relate complexity, I think we should consider doing a talk on each of them. The talk doesn't have to be of a particular length, so some network elements might have shorter or longer presentations.</p>
<p>Looking at the checklist below, we already have 14 items. Covering this in OsmoDevCall is not an option, it would take too long (14 months if no other topic would be covered in between). So it is going to be on a separate schedule.</p>
<p>I would consider each presentation should then be prominently linked from the redmine project page of each network element, next to the user manual.</p>
<p>We may of course still be publishing those via the OsmoDevCall "event" on media.ccc.de, so all videos are in one location.</p>
<p>I think every presentation should start with a quick picture at the overal diagram of netwokr elements, describe the surrounding elements and their interfaces to then look in detail at the specific element that ist he subject of the talk.</p>
It should cover
<ul>
<li>basic configuration to get it started / connected</li>
<li>VTY for state introspection ("ar alle connections up?", ...)</li>
<li>looking at logs / protocol traces</li>
<li>practical demo; looking at what happens in pcaps + logs for some basic transaction like LU, SMS, voice call.</li>
</ul> libosmo-sccp + libosmo-sigtran - Feature #5679 (In Progress): unsupported SCCP user primitive N-P...https://osmocom.org/issues/56792022-09-12T18:25:30Zpespin
<p>As seen in osmo-hnbgw when receiving an M3UA NTFY:<br /><pre>
20220912180716266 DLINP <0007> stream.c:445 [CONNECTED] osmo_stream_cli_fd_cb(): connected read
20220912180716266 DLINP <0007> stream.c:324 [CONNECTED] osmo_stream_cli_read(): message received
20220912180716267 DLSS7 <0011> osmo_ss7.c:1906 0: asp-asp-clnt-msc-0: xua_cli_read_cb(): sctp_recvmsg() returned 24 (flags=0x80)
20220912180716267 DLM3UA <0014> m3ua.c:714 0: asp-asp-clnt-msc-0: Received M3UA Message (SNM:DAVA)
20220912180716267 DLM3UA <0014> xua_snm.c:403 0: asp-asp-clnt-msc-0: Rx DAVA() for 0.23.4/0,
20220912180716267 DLSCCP <0012> sccp_user.c:175 Delivering N-PCSTATE.indication to SCCP User 'SCCP Management'
20220912180716267 DLSCCP <0012> sccp_scmg.c:298 unsupported SCCP user primitive N-PCSTATE.indication <======= libosmo-sccp.git scmg_prim_cb()
20220912180716267 DLSCCP <0012> sccp_user.c:175 Delivering N-PCSTATE.indication to SCCP User 'OsmoHNBGW' <===== IT IS FURTHER DELIVERED UPWARDS DESPITE NOT BEING SUPPORTED?
20220912180716267 DMAIN <0000> hnbgw_cn.c:473 sccp_sap_up(N-PCSTATE.indication)
20220912180716267 DMAIN <0000> hnbgw_cn.c:504 Received unknown prim 2562 from SCCP USER SAP <===== OSMO_HNBGW DOESN'T KNOW WHAT TO DO WITH IT
</pre></p>
<p><a class="user active" href="https://osmocom.org/users/7">laforge</a> would you mind providing feedback on what you think would need to be done here?</p> OsmoMSC - Bug #5197 (New): msc_i Unimplemented msg type: HANDOVER PERFORMEDhttps://osmocom.org/issues/51972021-07-12T14:18:36Zpespin
<p>As seen on a running osmo-msc:<br /><pre>
<0010> ran_msg_a.c:848 msc_i(IMSI-...:MSISDN-...:TMSI-0x...:GERAN-A-65:PAGING_RESP)[0x...]{READY}: RAN decode: BSSMAP: Unimplemented msg type: HANDOVER PERFORMED
</pre></p>
<p>Seems the message type is missing in ran_a_decode_bssmap. Is this expected? what's missing?</p> OsmoMSC - Bug #5196 (New): Verify several "event not permitted" log lines in unit testshttps://osmocom.org/issues/51962021-07-12T11:48:53Zpespin
<pre>
pespin ~/dev/sysmocom/git/osmo-msc $ ag "not permitted" tests/msc_vlr/ | grep Event
tests/msc_vlr/msc_vlr_test_gsm_authen.err:60:DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A:LU){VLR_ULA_S_WAIT_AUTH}: Event VLR_ULA_E_HLR_LU_RES not permitted
tests/msc_vlr/msc_vlr_test_gsm_authen.err:649:DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A:LU){VLR_ULA_S_WAIT_AUTH}: Event VLR_ULA_E_HLR_LU_RES not permitted
tests/msc_vlr/msc_vlr_test_gsm_authen.err:1480:DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A:LU){VLR_ULA_S_WAIT_AUTH}: Event VLR_ULA_E_HLR_LU_RES not permitted
tests/msc_vlr/msc_vlr_test_gsm_authen.err:1793:DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A:LU){VLR_ULA_S_WAIT_AUTH}: Event VLR_ULA_E_HLR_LU_RES not permitted
tests/msc_vlr/msc_vlr_test_gsm_authen.err:2058:DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A:LU){VLR_ULA_S_WAIT_AUTH}: Event VLR_ULA_E_HLR_LU_RES not permitted
tests/msc_vlr/msc_vlr_test_gsm_authen.err:2324:DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A:LU){VLR_ULA_S_WAIT_AUTH}: Event VLR_ULA_E_HLR_LU_RES not permitted
tests/msc_vlr/msc_vlr_test_gsm_authen.err:3242:DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A:LU){VLR_ULA_S_WAIT_AUTH}: Event VLR_ULA_E_HLR_LU_RES not permitted
tests/msc_vlr/msc_vlr_test_ms_timeout.err:814:DMSC msc_a(IMSI-901700000004620:GERAN-A:LU){MSC_A_ST_WAIT_CLASSMARK_UPDATE}: Event MSC_A_EV_UNUSED not permitted
</pre>
<p>We should check whether those events are indeed not expected and only triggered by tests, or whether they can happen and hence we should allow them and handle them properly in the FSM.</p>
<p>Similar to:<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-msc/+/24916">https://gerrit.osmocom.org/c/osmo-msc/+/24916</a> msc_a.c: Allow MSC_A_EV_CN_CLOSE in state MSC_A_ST_RELEASING</p> Cellular Network Infrastructure - Bug #5188 (New): BSSMAP Cell Identifier IE vs. Cell Identifier ...https://osmocom.org/issues/51882021-06-23T00:43:19Zneelsnhofmeyr@sysmocom.de
<p>In libosmocore, we have enum CELL_IDENT, which gets used in both of<br /> Cell Identifier IE (3GPP TS 48.008 3.2.2.17)<br />and<br /> Cell Identifier List IE (3GPP TS 48.008 3.2.2.27)</p>
<p>The similar meaning and structuring of these two IEs suggests that the List IE<br />is simply a bunch of the plain Cell Identifier. However, if you read in 3GPP TS<br />48.008, comparing 3.2.2.17 and 3.2.2.27, there is this odd difference:</p>
<p>3.2.2.17, Cell Identifier IE:</p>
<pre><code>0000 CGI<br /> 0001 LAC+CI<br /> 0010 CI<br /> 0011 No cell</code></pre>
<pre><code>1000 PLMN+LAC+RNC (<del>> E-UTRAN)<br /> 1001 RNC (</del>> E-UTRAN)<br /> 1010 LAC+RNC (-> E-UTRAN)<br /> 1011 SAI<br /> 1100 LAC+RNC+CI</code></pre>
<p>3.2.2.27a, Cell Identifier List Segment:</p>
<pre><code>0000 CGI<br /> 0001 LAC+CI<br /> 0010 CI<br /> 0011 No cell</code></pre>
<pre><code>0100 LAI<br /> 0101 LAC<br /> 0110 entire BSS<br /> 0111 MCC+MNC</code></pre>
<p>I noticed this because I was trying to check for the correct target cell <br />identifier in the BSSMAP Handover Request message; we send a LAI cell <br />identification in the Cell Identifier IE. wireshark shows the LAI cell<br />identifer the same way that osmo-msc intends to encode it, but the TTCN3 <br />BSSAP_Templates fail to parse this LAI cell identifier.</p>
<p>So I added this cell id type to BSSMAP_IE_CellIdentifier in<br />./deps/titan.ProtocolModules.BSSMAP/src/BSSAP_Types.ttcn. and just to confirm<br />that I'm right i took a quick look in the spec, and then found that the ttcn <br />definition is in fact on par with the spec: the LAI cell id is not<br />present in 3.2.2.17 at all!</p>
<p>Now, our libosmocore gsm/protocol/gsm_08_08.h and gsm0808_utils.h are based on<br />the assumption that the same cell identifiers are used in both of these IEs.</p>
<p>The osmo-bsc and osmo-msc neighbor config for inter-BSC handover is built<br />assuming that we can send the 3.2.2.27a cell identifiers in the Handover<br />Request's 'Cell Identifier (Target)' IE.</p>
<p>Apparently the spec intends otherwise.</p>
<p>The effect of this goes across several osmo cn components:</p>
<ul>
<li>We define enum CELL_IDENT in libosmocore.</li>
<li>osmo-bsc sends the Handover Request using the 'Cell Identifier (Serving)' and 'Cell Identifier (Target)' IEs.</li>
<li>osmo-msc parses these, possibly forwards in inter-MSC handover procedure.</li>
</ul>
<p>I'm not sure how to resolve this.</p>
<ul>
<li>We could just accept that we're using the 3.2.2.27a identifiers also in 3.2.2.17. It makes an awful lot of sense in fact.<br /> The wireshark implementation seems to agree with this point, though of course that's not the benchmark.<br /> It might pose an incompatibility with strictly spec conforming cn implementations.<br /> And we would need to extend the TTCN BSSAP_Types.ttcn with values that aren't strictly present in 3.2.2.17,<br /> if we want to test these cell identifier types in our test suite.</li>
</ul>
<ul>
<li>or we could endeavour to fix the identifiers that we use in the BSSMAP protocol according to spec, in osmo-bsc and osmo-msc
<ul>
<li>either we introduce two distinct enums -- that could ripple through a lot of the cell identifier API, ugly.</li>
<li>or we still use the same enum for both, but making distinctions in the implementations which values are used for which.</li>
</ul></li>
</ul>
<p>To enforce that, we may have to adjust which cell identifier types can be used in the neighbor configuration of osmo-bsc and osmo-msc,<br />or we find ways to, for example, convert all cell identifier types to a supported one.<br />I guess easiest would be to enforce full CGI everywhere.</p>
<p>Yet easier would be to highlight in the documentation that osmocom is capable of nonstandard cell identifiers,<br />and to conform to specs users should simply use the full CGI everywhere in the neighbor config.</p>
<p>Any insights or opinions on this?</p> osmo-sip-connector - Bug #5177 (New): respect dynamic RTP payload types of external SIPhttps://osmocom.org/issues/51772021-06-12T07:24:17Zlaforge
<p>As <a class="user active" href="https://osmocom.org/users/4282">keith</a> reported in OsmoDevCall on June 11, when an external SIP entity sends a SIP INVITE with SDP for AMR using a dynamic PT, osmo-sip-connector still sends AMR audio using a different (actually unassigned for this call/session) PT.</p>
<p>I guess this relates to the fact that 3GPP uses "pseudo static" PTs for the different codecs, i.e. it has defined that certain PT numbers from the dynamic PT range actually statically represent 3GPP codec types. Within Osmocom, we are sticking to the latter and may not have considered "Real" SIP/SDP compatibilty on the external interface.</p> OsmoHNBGW - Feature #5153 (In Progress): support hnbgw co-located GTP-U proxy (UPF)https://osmocom.org/issues/51532021-05-13T12:13:07Zlaforge
<p>In the current osmo-hnbgw implementation, we simply configure the hNB GTP-U data to go directly to the GGSN. This requires IP-level routing between the RAN and the CN, which is possible in most lab situations, but not possible in real operator networks.</p>
<p>So we'd need to add support for a GTP-U proxy to control a co-located osmo-mgw. That proxy would translate GTP flows on the RAN side to GTP flows on the CN side (each with their own IPs/TEIDs).</p>
<p>The problem faced here is a 1:1 identical situation to what we're facing in OsmoSGSN in <a class="issue tracker-1 status-1 priority-2 priority-default" title="Bug: OsmoSGSN doesn't trigger 3G paging if downlink GTP traffic arrives after long break (New)" href="https://osmocom.org/issues/5154">#5154</a>. So both should then be able to use that same GTP-U proxy component.</p>
<p>Further brainstorming about this problem revealed that we're actualy talking about the same as the "SGW-U" network element described in 3GPP TS 23.214, which is what 3GPP invented when they introduced the control/user plane separation into the 4G EPC.</p>
<p>The SGW-U is exactly a GTP-U proxy between the RAN and the CN side, and it even includes functions for buffering GTP-U packets during mobility related GTP-U tunnel modification. It also includes functions for notifying the control plane entity of the first downlink packet received (so it can trigger paging). The SGW-U is controlled by the PFCP protocol. Only very few features of PFCP are required (PFCP is also used for he PGW-U which is much more complex).</p>
So in fact, what we'd have to implement is
<ul>
<li>a minimalistic SGW-U with PFCP suport</li>
<li>functionality in osmo-hnbgw to control that SGW-U via PFCP</li>
</ul> OsmoBSC - Feature #4940 (Stalled): VAMOS support in OsmoBSChttps://osmocom.org/issues/49402021-01-12T13:52:23Zlaforge
<p>This ticket should document what needs to be done in terms of supporting <a class="wiki-page" href="https://osmocom.org/projects/cellular-infrastructure/wiki/VAMOS">VAMOS</a> from <a class="wiki-page" href="https://osmocom.org/projects/osmobsc/wiki">OsmoBSC</a>, and to track its status via check-lists and possibly sub-issues.</p>
<p>3GPP unfortuantely doesn't provide any specifications for VAMOS beyond the radio interface. Neither A-bis OML nor RSL specs did receive any related updates.</p>
On an abstract level, we (IMHO) have the following problem domains:
<ol>
<li>how to represent the second user for each lchan</li>
<li>how to configure VAMOS via OML</li>
<li>how to represent the VAMOS channels on RSL</li>
<li>how to include VAMOS decisions in the channel allocator for assignment and hand-over</li>
</ol>
<p>as for the "representation" and "RSL" side, my idea would be to use the concept of "shadow TRX", i.e. introduce a second, logical TRX for each real TRX. Then one subscriber is on the "real" TRX and the other subscriber on the "shadow" TRX. Our data structures and RSL currently have at leaset uint8_t for the TRX number, and in reality no more than 12 TRX are ever expected in one BTS. This means we could e.g. use one of the higher-order bits to decide between real / shadow. So e.g.</p>
<ul>
<li>TRX number (and IPA stream ID) 0x00: TRX 0 (real)</li>
<li>TRX number (and IPA stream ID) 0x01: TRX 1 (real)</li>
<li>TRX number (and IPA stream ID) 0x80: TRX 0 (shadow)</li>
<li>TRX number (and IPA stream ID) 0x81: TRX 1 (shadow)</li>
<li>...</li>
</ul> Cellular Network Infrastructure - Bug #4883 (New): update OsmoNITB migration guidehttps://osmocom.org/issues/48832020-12-01T08:32:05Zlaforge
<p><a class="wiki-page" href="https://osmocom.org/projects/cellular-infrastructure/wiki/OsmoNITB_Migration_Guide">OsmoNITB_Migration_Guide</a> is showing its age. I've fixed the two most obvious outdated bits (no subscriber-create-on-demand and references to bsc_mgcp), but I'm sure there are plenty more, particularly in the config file snippets.</p>
<p>As there may still be people migrating from OsmoNITB, let's update it to reflect the current situation.</p> libosmocore - Bug #4842 (In Progress): gsm0408 test fails on several architectureshttps://osmocom.org/issues/48422020-11-03T13:06:31Zbunkbunk@stusta.de
<p><a class="external" href="https://buildd.debian.org/status/logs.php?pkg=libosmocore&ver=1.4.0-1">https://buildd.debian.org/status/logs.php?pkg=libosmocore&ver=1.4.0-1</a><br /> 25: gsm0408 FAILED (testsuite.at:156)</p>
<p>The pattern of the failures is<br />-LU with truncated IMSI MI: rc = -74 ok<br />-LU with too short IMSI MI (12345): rc = -74 ok<br />+LU with truncated IMSI MI: rc = -77 ok<br />+LU with too short IMSI MI (12345): rc = -77 ok</p>
<p>The root cause is likely related to<br />/usr/include/asm-generic/errno.h:#define EBADMSG 74 /* Not a data message <strong>/<br />/usr/include/mips64el-linux-gnuabi64/asm/errno.h:#define EBADMSG 77 /</strong> Not a data message */</p> OsmoMSC - Bug #4830 (In Progress): LU reject when no authentication data in HLR but "authenticati...https://osmocom.org/issues/48302020-10-25T18:39:40ZlaforgeOsmoMSC - Bug #4721 (In Progress): osmo-msc creates evil-twin entries in the VLR when an already ...https://osmocom.org/issues/47212020-08-19T06:24:05Zlaforge
<p>When running this test locally against a (sanitize-enabled) osmo-msc, I get sporadic failures.</p>
<p>The differnence in the log files seems to start:</p>
<p>successful case:<br /><pre>
Wed Aug 19 08:10:24 2020 DVLR <000e> gsm_04_08.c:1394 SUBSCR(IMSI-262420000000013:MSISDN-491230000013:TMSI-0x01020304) VLR: update for IMSI=262420000000013 (MSISDN=491230000013)
</pre></p>
<p>failing case:<br /><pre>
Wed Aug 19 08:10:29 2020 DVLR <000e> gsm_04_08.c:1394 SUBSCR(IMSI-262420000000013:MSISDN-491230000013:TMSI-0x3BEDCD7C) VLR: update for IMSI=262420000000013 (MSISDN=491230000013) (NO CONN!)
</pre></p>
<p>The pcap file containing both cases is attached. They seem exactly identical, it's just that in the first (successful) case, there is a LU ACCEPT immediately, while in the second (failing) case, there is a LU REJECT after timeout of 5s.</p>
<p>I've seen the failure both when running a single test case, as well as when running the entire MSC_Tests.control in one batch.</p> OsmoBSC - Feature #4716 (Stalled): support handover between different codec types, like TCH/F FR1...https://osmocom.org/issues/47162020-08-18T12:00:43Zneelsnhofmeyr@sysmocom.de
<p>The handover algorithm 2 supports congestion resolution by re-assigning within the same cell (like move from TCH/F to TCH/H) and across cells.<br />So far, the lchan type may change between TCH/F <--> TCH/H, when the AMR codec is in use, because that can automatically adapt its bandwitdh to continue a call.<br />The aim of this issue is to also support TCH/F <--> TCH/H handovers where the codec is not AMR, i.e. {FR1,EFR} <--> HR1.</p>
<p>First, take stock of what osmo-bsc currently does right, and what parts are missing.</p> libosmocore - Bug #4700 (Feedback): 'socket' C test fails when there is no IPv6https://osmocom.org/issues/47002020-08-09T18:06:40Zneelsnhofmeyr@sysmocom.de
<p>When building libosmocore (I did inside the ttcn3-tests docker container 'nonjenkins-bsc'), make check may fail the socket.c test;<br />when I revert this patch, the error no longer happens:</p>
<pre>
osmo_sock_init2: improve support for AF_UNSPEC
2c962f5de1eeea119cfac7d9d92db31c570353b9
I397c633931fd00d4f083955a3c49a40fb002d766
</pre>
<p>This is the test failure output:</p>
<pre><code>49: socket FAILED (testsuite.at:313)</code></pre>
<pre>
# -*- compilation -*-
49. testsuite.at:308: testing socket ...
../../../src/libosmocore/tests/testsuite.at:313: $abs_top_builddir/tests/socket/socket_test
--- experr 2020-08-09 17:51:39.081588010 +0000
+++ /src/make/libosmocore/tests/testsuite.dir/at-groups/49/stderr 2020-08-09 17:51:39.093588179 +0000
@@ -2,3 +2,7 @@
invalid: you have to specify either BIND or CONNECT flags
Unable to find a common protocol (IPv4 or IPv6) for local host: 127.0.0.1 and remote host: ::1.
Unable to find a common protocol (IPv4 or IPv6) for local host: ::1 and remote host: 127.0.0.1.
+unable to bind socket: ::1:0: Cannot assign requested address
+no suitable local addr found for: ::1:0
+Assert failed fd >= 0 ../../../src/libosmocore/tests/socket/socket_test.c:142
+/src/make/libosmocore/tests/testsuite.dir/at-groups/49/test-source: line 27: 20251 Aborted $abs_top_builddir/tests/socket/socket_test
--- expout 2020-08-09 17:51:39.081588010 +0000
+++ /src/make/libosmocore/tests/testsuite.dir/at-groups/49/stdout 2020-08-09 17:51:39.089588123 +0000
@@ -9,3 +9,9 @@
Checking osmo_sock_init2(AF_UNSPEC) must fail on mixed IPv6 & IPv4
Checking osmo_sock_init2(AF_UNSPEC) BIND + CONNECT on IPv4
Checking osmo_sock_init2(AF_UNSPEC) BIND + CONNECT on IPv6
+backtrace() returned 6 addresses
+/src/make/libosmocore/src/.libs/libosmocore.so.12(+0xdda0b) [0x7f89ded74a0b]
+/src/make/libosmocore/src/.libs/libosmocore.so.12(osmo_panic+0x14b) [0x7f89ded7491b]
+/src/make/libosmocore/tests/socket/socket_test(+0x1cc8) [0x558ed77eccc8]
+/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0x7f89dd7d02e1]
+/src/make/libosmocore/tests/socket/socket_test(+0x1eda) [0x558ed77eceda]
../../../src/libosmocore/tests/testsuite.at:313: exit code was 134, expected 0
49. testsuite.at:308: 49. socket (testsuite.at:308): FAILED (testsuite.at:313)
</pre> OsmoBSC - Support #4621 (New): feedback: osmo-bsc modifies the LAI in LU Accept messages, and the...https://osmocom.org/issues/46212020-06-18T16:36:53Zneelsnhofmeyr@sysmocom.de
<p>looking at osmo_bsc_filter.c, I notice that we probably don't want any of this to remain in osmo-bsc:<br /><a class="external" href="http://git.osmocom.org/osmo-bsc/tree/src/osmo-bsc/osmo_bsc_filter.c#n110">http://git.osmocom.org/osmo-bsc/tree/src/osmo-bsc/osmo_bsc_filter.c#n110</a></p>
<ul>
<li>we are modifying the LAI in a Location Updating Accept message. I'm pretty sure we don't want to do this in osmo-bsc ever.<br /> <a class="external" href="http://git.osmocom.org/osmo-bsc/tree/src/osmo-bsc/osmo_bsc_filter.c#n135">http://git.osmocom.org/osmo-bsc/tree/src/osmo-bsc/osmo_bsc_filter.c#n135</a></li>
</ul>
<ul>
<li>we are modifying the MM info, see bsc_patch_mm_info()<br /> <a class="external" href="http://git.osmocom.org/osmo-bsc/tree/src/osmo-bsc/osmo_bsc_filter.c#n32">http://git.osmocom.org/osmo-bsc/tree/src/osmo-bsc/osmo_bsc_filter.c#n32</a><br /> I'm least sure about the timezone information that osmo-bsc overwrites in the MM info,<br /> I dimly remember an explicit request to be able to run BSCs in different time zones...</li>
</ul>
<p>Which parts of this can be dropped?</p> Core testing infrastructure - Bug #4576 (Stalled): ttcn3-hlr-tests need to route multicast traffi...https://osmocom.org/issues/45762020-06-02T22:29:38Zneelsnhofmeyr@sysmocom.de
<p>The MSLookup tests in the ttcn3-hlr-test send out multicast-DNS queries,<br />and these should be answered by osmo-hlr running in the osmo-hlr-master container.</p>
<p>Running wireshark on the docker-hosting machine on 'any', the DNS queries are visible:</p>
<pre>
No. Time Arrival Time Source Source Port Destination Destination Port Info
102721 4919.259341 Jun 3, 2020 00:16:05.287612000 CEST 172.18.10.103 4266 239.192.23.42 4266 Standard query 0x5ca3 ANY sip.voice.491618327224.msisdn.mdns.osmocom.org
102722 4919.259341 Jun 3, 2020 00:16:05.287612000 CEST 172.18.10.103 4266 239.192.23.42 4266 Standard query 0x5ca3 ANY sip.voice.491618327224.msisdn.mdns.osmocom.org
</pre>
<p>Running tcpdump in the osmo-hlr-master container shows no such activity.</p>
<p>When running the osmo-mslookup-client commandline tool with the same query, osmo-hlr does receive it and responds in the way that the test expects it:</p>
<pre>
# osmo-mslookup-client sip.voice.262422543586245.imsi
query result last age v4_ip v4_port v6_ip v6_port
sip.voice.262422543586245.imsi result last 257 66.66.66.66 5060
</pre>
<p>But also, the tester does not receive that response<br />(as I found out by "infinitely" looping the MSLookup send and receive in HLR_Tests.ttcn).</p>
<p>I am not sure how <a class="user active" href="https://osmocom.org/users/301771">osmith</a> managed to test the MSLookup tests successfully,<br />there must be some way to get the multicast traffic to pass through the containers.</p> OsmoMSC - Bug #3294 (Stalled): transaction: refactor callref allocationhttps://osmocom.org/issues/32942018-05-26T17:51:04Zfixeria
<p>Each transaction has a field called 'callref', that should contain an unique identifier. This identifier is being assigned either by OsmoMSC itself, either by an external application (e.g. LCR), and is used to distinguish between multiple allocated transactions.</p>
<p>In case of a new callref generation on the MSC side, there are the following sources for that:</p>
<pre>
$ git grep "static uint32_t new_callref"
src/libmsc/gsm_04_08.c:static uint32_t new_callref = 0x80000001;
src/libmsc/gsm_04_11.c:static uint32_t new_callref = 0x40000001;
src/libmsc/mncc_builtin.c:static uint32_t new_callref = 0x00000001;
</pre>
<p>So, we have a few ranges for different types of communication:</p>
<pre><code>- from 0x00000001 to 0x40000000 - Call Control, internal MNCC;<br /> - from 0x40000001 to 0x80000000 - SMS messages;<br /> - from 0x80000001 to 0xffffffff - Call Control, external MNCC;</code></pre>
<p>And this is how a new 'callref' value is generated:</p>
<pre>
new_callref++
</pre>
<p>I see the following problems:</p>
<p>1) Imagine that we have a network, which is running for some long time. What if the amount of calls ever made would reach 0x40000000? The next values will be 0x40000001, 0x40000002, 0x40000003, etc. At some point, this may result into collisions, e.g. two transactions with same 'callref' value.</p>
<p>Possible solution: instead of doing `new_callref++` manually, create a function (e.g. trans_gen_ref), which would prevent overlaps between ranges, and flush the source to initial value.</p>
<p>2) The trans_alloc(), which is used to allocate a new transactions, doesn't check if passed 'callref' value is not used. In other words, it is possible to allocate a few transactions with not unique 'callref'. In this case the trans_find_by_callref() would work incorrectly.</p>
<p>Possible solution: before allocation, check if given 'callref' is already used.</p>
<p>3) The 'callref' as a field name itself looks/sounds like something call related, while this feature will be also used as soon as we implement SMS and SS/USSD over GSUP. It would be better to rename it to something more generic, e.g. just 'ref'.</p>
<p>4) Both sides, i.e. MSC and an external application, are involved in 'callref' generation. There is no master-slave relation... This may result in a situation, when an external application asks to allocate a new transaction with 'callref', which is already used.</p>
<p>Possible solution: inspire by GSM TS 04.07, section 11.2.3 "Transaction identifier" and introduce the direction bit. Probably, this can be a bit simplified, e.g. '0' means allocated by the MSC itself, '1' - by an external application.</p> OsmoMSC - Feature #3069 (New): investigate multiple CM Service Request on the same connhttps://osmocom.org/issues/30692018-03-16T12:28:10Zneelsnhofmeyr@sysmocom.de
<p>TS 24.008 Section 4.5.2:</p>
<blockquote>
<p>According to the protocol architecture described in 3GPP TS 24.007<br />[20], each CM entity will have its own MM connection. These different<br />MM connections are identified by the protocol discriminator PD and,<br />additionally, by the transaction identifier TI.</p>
</blockquote>
<p>So for example, one could have multiple calls (same pdisc, but different TI),<br />or one could have SMS ongoing while a call (different pdisc+TI).</p>
<p>Testing an SMS sent during an ongoing call indeed shows a secondary CM Service Request.</p>
In attached pcap it seems that we are already handling the situation rather well.<br />Nevertheless, take a close look:
<ul>
<li>are we handling the TI properly?</li>
<li>make sure that the tear down of one service handling doesn't cut short any other pending CM Service Requests,<br /> especially if one CM Service Request concludes while the another has just sent the CM Service Request and we are still waiting for the actual CC/RR/... service request following.</li>
</ul>
<p>(I also notice in attached PCAP that DTMF requests are rejected, and that a call Hold command is rejected; that may have to become separate issues.)</p> OsmoBSC - Bug #3002 (New): HO2: handover decision for dynamic timeslotshttps://osmocom.org/issues/30022018-02-26T00:05:32Zneelsnhofmeyr@sysmocom.de
<p>The recent handover_decision_2.c hasn't been duly tested in the presence of dynamic timeslots.<br />Particularly TCH/F_TCH/H_PDCH timeslots are potentially both TCH/F or TCH/H, which might require another spin on the handover_decision_2.c code.</p> OsmoBSC - Feature #2781 (Feedback): Extend OsmBSC TTCN-3 test coverage regarding resource leakshttps://osmocom.org/issues/27812017-12-22T21:19:21Zlaforge
<p>let's collect ideas about what we need to test here</p> Cellular Network Infrastructure - Feature #2623 (New): SCCP/M3UA: detect restart of osmo-msc and ...https://osmocom.org/issues/26232017-11-07T23:25:36Zneelsnhofmeyr@sysmocom.de
<p>Connecting osmo-bsc and osmo-hnbgw to the MSC and SGSN via an OsmoSTP instance, it is currently not possible to detect that the MSC or SGSN has restarted.</p>
<p>Scenario: using a sysmoBTS as a NITB, change MSC config, restart MSC -- now osmo-bsc happily continues to run and does not even notice that it is an entirely new MSC instance running in the core net now.</p>
<p>In the old days, the SCCPlite link would go down, but since now OsmoSTP is in-between and has no concept of who depends on who, no-one is notifying BSC or HNBGW that MSC or SGSN have gone down. Find out how this is intended to be solved if at all, and devise a way how osmo-bsc will restart and/or reconnect to a new MSC instance, and so forth.</p>