https://osmocom.org/https://osmocom.org/favicon.ico?16647414092019-05-19T20:50:22ZOpen Source Mobile CommunicationsOsmoBTS - Bug #4009: Channel Activation starts SACCH too early in Synchronous Handoverhttps://osmocom.org/issues/4009?journal_id=145112019-05-19T20:50:22Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-3 priority-2 priority-default closed" href="/issues/3750">Feature #3750</a>: Extension of BTS_Tests.ttcn test coverage</i> added</li></ul> OsmoBTS - Bug #4009: Channel Activation starts SACCH too early in Synchronous Handoverhttps://osmocom.org/issues/4009?journal_id=145152019-05-19T20:58:50Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-1 priority-1 priority-lowest" href="/issues/4010">Feature #4010</a>: Test RSL CHAN ACT related details for different scenarios</i> added</li></ul> OsmoBTS - Bug #4009: Channel Activation starts SACCH too early in Synchronous Handoverhttps://osmocom.org/issues/4009?journal_id=145592019-05-22T07:18:55Zlaforge
<ul></ul><p>There's good news and bad news.</p>
<p>The actual behavior of the BTS is very dependent on the specific PHY used. I've analyzed osmo-bts-trx and osmo-bts-sysmo as two representatives, where lc15 and oc2g are mostly like -sysmo.</p>
<a name="osmo-bts-sysmo"></a>
<h1 >osmo-bts-sysmo<a href="#osmo-bts-sysmo" class="wiki-anchor">¶</a></h1>
osmo-bts-sysmo gets it half-way right. It
<ul>
<li>checks if the activation is HO related, and only activates uplink RACH detection until a RACH is received</li>
<li>then activates all other logical channels / SAPIs after the RACH was received</li>
</ul>
What it gets wrong:
<ul>
<li>it doesn't activate DL main channel (FACCH/SDCCH) while waiting for the RACH</li>
<li>it unconditionally delays activation of DL+UL SACCH, even if the MS Power IE and/or TA IE were present in RSL CHAN ACT</li>
</ul>
<a name="osmo-bts-trx"></a>
<h1 >osmo-bts-trx<a href="#osmo-bts-trx" class="wiki-anchor">¶</a></h1>
osmo-bts-trx gets it wrong in all cases:
<ul>
<li>it always activates both main channel and SACCH in UL and DL from the very beginning, even before any RACH is received in UL</li>
</ul>
<p>In fact, osmo-bts-trx and its scheduler don't even know the concept of L1 SAPI and hence don't have the infrastructure to enable/disable individual logical channels within one dedicated channel.</p>
<a name="Summary"></a>
<h1 >Summary<a href="#Summary" class="wiki-anchor">¶</a></h1>
What does this all mean in practice for osmo-bts-trx? There is a significant risk of poor hand-over performance, as
<ul>
<li>some phones could receive a massively wrong timing advance before we even know the TA</li>
<li>some phones could simply refuse to send the RACH if there is no downlink FACCH/SDCCH visible</li>
</ul> OsmoBTS - Bug #4009: Channel Activation starts SACCH too early in Synchronous Handoverhttps://osmocom.org/issues/4009?journal_id=148712019-06-19T08:34:50Zlaforge
<ul><li><strong>Priority</strong> changed from <i>Urgent</i> to <i>High</i></li></ul> OsmoBTS - Bug #4009: Channel Activation starts SACCH too early in Synchronous Handoverhttps://osmocom.org/issues/4009?journal_id=152082019-07-18T05:10:40Zlaforge
<ul><li><strong>Assignee</strong> deleted (<del><i>laforge</i></del>)</li></ul> OsmoBTS - Bug #4009: Channel Activation starts SACCH too early in Synchronous Handoverhttps://osmocom.org/issues/4009?journal_id=152212019-07-18T05:15:56Zlaforge
<ul><li><strong>Priority</strong> changed from <i>High</i> to <i>Normal</i></li></ul> OsmoBTS - Bug #4009: Channel Activation starts SACCH too early in Synchronous Handoverhttps://osmocom.org/issues/4009?journal_id=237742022-03-11T12:02:11Zfixeria
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-4 priority-3 priority-high3" href="/issues/4008">Bug #4008</a>: Channel Activation starts SACCH too early in Asynchronous Handover</i> added</li></ul> OsmoBTS - Bug #4009: Channel Activation starts SACCH too early in Synchronous Handoverhttps://osmocom.org/issues/4009?journal_id=237752022-03-11T12:44:51Zfixeria
<ul><li><strong>% Done</strong> changed from <i>0</i> to <i>50</i></li></ul><p>I am trying to investigate a handover related bug report from one of our customers, so I noticed that <code>TC_sacch_chan_act_ho_sync</code> is failing and stumbled upon this ticket. The scope of my investigation is limited to osmo-bts-trx, so whatever you see below is related to this BTS model only.</p>
<p>First of all, it should be noted that the current osmo-bts master behaves more or less correctly, except one bug in <code>rsl_rx_chan_activ()</code> that I just found and fixed:</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/27486">https://gerrit.osmocom.org/c/osmo-bts/+/27486</a> rsl: fix wrong IE being checked in rsl_rx_chan_activ() [NEW]</p>
<p>Test case <code>TC_sacch_chan_act_ho_sync</code> fails because after sending a <em>CHANnel ACTIVation</em> message with only the <em>MS Power</em> IE it does expect Downlink SACCH to be activated immediately, before the first handover RACH is received. The specs. state that "if only the MS power element is present the BTS <strong>may</strong> start transmission also on the SACCH". May does not mean shall, so osmo-bts-trx does not activate it. I corrected the test case expectations, and it started to pass in my local test setup.</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/27487">https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/27487</a> BTS_Tests: remove misleading comments in f_sacch_{present,missing}() [NEW]<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/27488">https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/27488</a> BTS_Tests: cosmetic: use setverdict() in f_sacch_{present,missing}() [NEW]<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/27489">https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/27489</a> BTS_Tests: fix expectations in TC_sacch_chan_act_ho_{sync,async} [NEW]<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/27490">https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/27490</a> BTS_Tests: exec TC_sacch_chan_act_ho_{sync,async} on g_AllChanTypes[] [NEW]</p>