https://projects.osmocom.org/https://projects.osmocom.org/favicon.ico?16647414092020-10-25T20:52:19ZOpen Source Mobile CommunicationsOsmoBSC - Bug #4832: osmo-bsc hard-releases lchan if no MSC is foundhttps://projects.osmocom.org/issues/4832?journal_id=201182020-10-25T20:52:19Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-7 priority-3 priority-high3" href="/issues/4829">Bug #4829</a>: OsmocomBB Rx bit errors in dedicated mode</i> added</li></ul> OsmoBSC - Bug #4832: osmo-bsc hard-releases lchan if no MSC is foundhttps://projects.osmocom.org/issues/4832?journal_id=201492020-10-27T17:11:10Zlaforge
<ul><li><strong>Priority</strong> changed from <i>Normal</i> to <i>High</i></li></ul> OsmoBSC - Bug #4832: osmo-bsc hard-releases lchan if no MSC is foundhttps://projects.osmocom.org/issues/4832?journal_id=201912020-10-28T22:55:21Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>In Progress</i></li><li><strong>% Done</strong> changed from <i>0</i> to <i>90</i></li></ul><p><a class="external" href="https://gerrit.osmocom.org/c/osmo-bsc/+/20949">https://gerrit.osmocom.org/c/osmo-bsc/+/20949</a><br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/20948">https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/20948</a></p> OsmoBSC - Bug #4832: osmo-bsc hard-releases lchan if no MSC is foundhttps://projects.osmocom.org/issues/4832?journal_id=201922020-10-28T22:59:27Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>% Done</strong> changed from <i>90</i> to <i>50</i></li></ul><p>above patches add an RR Release on the lchan, still need to address the remaining aspects</p> OsmoBSC - Bug #4832: osmo-bsc hard-releases lchan if no MSC is foundhttps://projects.osmocom.org/issues/4832?journal_id=201932020-10-28T23:02:39Zneelsnhofmeyr@sysmocom.de
<ul></ul><blockquote>
<p>Another oddity about this problem is that it only shows if the MSC is absent when the BSC starts up. If the BSC has once seen the MSC, then it considers it 'eligible'. Even if the MSC then is gone at a later point, it will not go back to this hard-fast-clear behavior (at least not quickly?).</p>
</blockquote>
<p>This is not exactly related to this specific case, rather refer to <a class="issue tracker-2 status-3 priority-2 priority-default closed" title="Feature: implement OsmoSTP notification of peers disconnecting, e.g. for OsmoBSC to detect that a specific... (Resolved)" href="https://projects.osmocom.org/issues/4701">#4701</a></p> OsmoBSC - Bug #4832: osmo-bsc hard-releases lchan if no MSC is foundhttps://projects.osmocom.org/issues/4832?journal_id=201952020-10-28T23:02:54Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-3 priority-2 priority-default closed" href="/issues/4701">Feature #4701</a>: implement OsmoSTP notification of peers disconnecting, e.g. for OsmoBSC to detect that a specific MSC in the pool is disconnected</i> added</li></ul> OsmoBSC - Bug #4832: osmo-bsc hard-releases lchan if no MSC is foundhttps://projects.osmocom.org/issues/4832?journal_id=201962020-10-29T01:01:34Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>File</strong> <a href="/attachments/4341">0001-spoof-LU-reject-when-there-is-no-MSC.patch</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/4341/0001-spoof-LU-reject-when-there-is-no-MSC.patch">0001-spoof-LU-reject-when-there-is-no-MSC.patch</a> added</li><li><strong>File</strong> <a href="/attachments/4342">spoof-LU-reject-when-there-is-no-MSC.pcapng</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/4342/spoof-LU-reject-when-there-is-no-MSC.pcapng">spoof-LU-reject-when-there-is-no-MSC.pcapng</a> added</li><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Feedback</i></li><li><strong>Assignee</strong> changed from <i>neels</i> to <i>laforge</i></li><li><strong>% Done</strong> changed from <i>50</i> to <i>90</i></li></ul><p>tested just now the behavior of a Samsung Galaxy S4m:</p>
<ul>
<li>letting the LU Request time out:
<ul>
<li>The lchan stays open for close to 20 seconds.</li>
<li>The MS launches the next LU attempt about 15 seconds later.</li>
</ul></li>
</ul>
<ul>
<li>releasing immediately (including RR Release with above fix <a class="external" href="https://gerrit.osmocom.org/c/osmo-bsc/+/20949">https://gerrit.osmocom.org/c/osmo-bsc/+/20949</a> )
<ul>
<li>lchan stays open for 0.33 seconds</li>
<li>The MS launches the next LU attempt about 15 seconds later.</li>
</ul></li>
</ul>
<ul>
<li>when spoofing a Location Updating Reject
<ul>
<li>lchan stays open for 0.33 seconds</li>
<li>The MS launches the next LU attempt about 15 seconds later.</li>
</ul></li>
</ul>
<p>No matter whether we spoof a reject, plain release or let the LU time out, the Galaxy S4m always retries after roughly 15 seconds.<br />Letting the LU time out is bad because it occupies the lchan for a long time.<br />Spoofing a reject doesn't affect RF load by the MS retrying (at least not for the Galaxy S4m).</p>
<p>Conclusion from these tests would be to just properly release the lchan and not care about spoofing a reject.<br />So above patch to simply add an RR Release should do it.</p>
<p>For later reference, attaching the patch that I used to test the spoofing behavior, and a pcap showing it in operation.</p> OsmoBSC - Bug #4832: osmo-bsc hard-releases lchan if no MSC is foundhttps://projects.osmocom.org/issues/4832?journal_id=201972020-10-29T01:05:14Zneelsnhofmeyr@sysmocom.de
<ul></ul>out of curiosity, also tried just sending a LU Reject without releasing the lchan:
<ul>
<li>lchan stays open for about 10 seconds.</li>
<li>MS launches next LU attempt about 15 seconds later.</li>
</ul> OsmoBSC - Bug #4832: osmo-bsc hard-releases lchan if no MSC is foundhttps://projects.osmocom.org/issues/4832?journal_id=201982020-10-29T01:22:44Zfixeria
<ul></ul><p>While looking at the capture you attached, I stumbled upon packet number 13 "(RR) Channel Release" with cause "Unknown (32)". I checked in 3GPP TS 44.018, section 10.5.2.31 "RR Cause", and yes, Wireshark is right - there is no such cause value. Where this value is coming from?</p> OsmoBSC - Bug #4832: osmo-bsc hard-releases lchan if no MSC is foundhttps://projects.osmocom.org/issues/4832?journal_id=202022020-10-29T10:46:14Zlaforge
<ul></ul><p>For a LU REJECT with cause "network failure" (which likely is the right<br />cause here), T3211 applies and that is a 15s timer, indeed. We could<br />send a "permanent" cause, but that would be wrong.</p>
<blockquote>
<p>No matter whether we spoof a reject, plain release or let the LU time out, the Galaxy S4m always retries after roughly 15 seconds.</p>
<p>Spoofing a reject doesn't affect RF load by the MS retrying (at least not for the Galaxy S4m).</p>
</blockquote>
<p>If we wanted to make the MS back off for a longer time, the LU reject would need to<br />include the optional T3246 ("Extended wait time") IE.</p> OsmoBSC - Bug #4832: osmo-bsc hard-releases lchan if no MSC is foundhttps://projects.osmocom.org/issues/4832?journal_id=211152021-02-06T09:28:39Zlaforge
<ul><li><strong>Status</strong> changed from <i>Feedback</i> to <i>Stalled</i></li><li><strong>Assignee</strong> changed from <i>laforge</i> to <i>neels</i></li><li><strong>Priority</strong> changed from <i>High</i> to <i>Low</i></li></ul><p>I think in order to avoid signaling overload (every single MS retrying every 15s), we should spoof a LU REJECT with the T3246 "extended wait time" IE. The value we send probably should scale with either the amount of time the MSC is already unreachable, or the rate of LU REQ we get, so we have some kind of back-off.</p>
This could also be done in two steps:
<ol>
<li>start with spoofing LU with a fixed back-off</li>
<li>adjusting that back-off automatically.</li>
</ol>
<p>re-prioritizing as low.</p> OsmoBSC - Bug #4832: osmo-bsc hard-releases lchan if no MSC is foundhttps://projects.osmocom.org/issues/4832?journal_id=220312021-04-29T02:20:02Zfixeria
<ul><li><strong>% Done</strong> changed from <i>90</i> to <i>20</i></li></ul><p>Today I also faced this problem while testing some TRXDv2 related changes (fortunately, I immediately remembered this ticket). I thought we're at least sending the <em>RR Channel Release</em> to the MS if the MSC is not available, but in fact <strong>we do not</strong>. The problem is that osmo-bsc sends <em>RSL RF Channel Release</em> immediately after sending <em>RSL DATA REQuest</em> with the <em>RR Channel Release</em>, so osmo-bts simply has no time to transmit this message. I guess we should wait until T3109 expires before deactivating the channel?</p> OsmoBSC - Bug #4832: osmo-bsc hard-releases lchan if no MSC is foundhttps://projects.osmocom.org/issues/4832?journal_id=231652021-12-07T20:50:48Zfixeria
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-3 priority-2 priority-default closed" href="/issues/5337">Bug #5337</a>: ttcn3-bsc-test: leaked struct bsc_subscr in BSC_Tests.TC_no_msc</i> added</li></ul> OsmoBSC - Bug #4832: osmo-bsc hard-releases lchan if no MSC is foundhttps://projects.osmocom.org/issues/4832?journal_id=251672022-10-18T21:41:50ZHoernchen
<ul></ul><p>I just stumbled upon this because there was - allegedly - no msc available, which led to a lot of weird downlink errors on the ms side due to a disappearing channel...</p>