https://projects.osmocom.org/https://projects.osmocom.org/favicon.ico?16647414092019-05-19T20:50:14ZOpen Source Mobile CommunicationsOsmoBTS - Bug #4008: Channel Activation starts SACCH too early in Asynchronous Handoverhttps://projects.osmocom.org/issues/4008?journal_id=145092019-05-19T20:50:14Zlaforge
<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 #4008: Channel Activation starts SACCH too early in Asynchronous Handoverhttps://projects.osmocom.org/issues/4008?journal_id=145132019-05-19T20:58:46Zlaforge
<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 #4008: Channel Activation starts SACCH too early in Asynchronous Handoverhttps://projects.osmocom.org/issues/4008?journal_id=145582019-05-22T07:18:04Zlaforge
<ul><li><b>Checklist item</b> <input type='checkbox' class='checklist-checkbox' disabled> <i>osmo-bts-sysmo</i> added</li><li><b>Checklist item</b> <input type='checkbox' class='checklist-checkbox' disabled> <i>osmo-bts-oc2g</i> added</li><li><b>Checklist item</b> <input type='checkbox' class='checklist-checkbox' disabled> <i>osmo-bts-lc15</i> added</li><li><b>Checklist item</b> <input type='checkbox' class='checklist-checkbox' disabled> <i>osmo-bts-trx</i> added</li></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 practise 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 #4008: Channel Activation starts SACCH too early in Asynchronous Handoverhttps://projects.osmocom.org/issues/4008?journal_id=148702019-06-19T08:34:47Zlaforge
<ul><li><strong>Priority</strong> changed from <i>Urgent</i> to <i>High</i></li></ul> OsmoBTS - Bug #4008: Channel Activation starts SACCH too early in Asynchronous Handoverhttps://projects.osmocom.org/issues/4008?journal_id=152072019-07-18T05:10:15Zlaforge
<ul><li><strong>Assignee</strong> deleted (<del><i>laforge</i></del>)</li></ul> OsmoBTS - Bug #4008: Channel Activation starts SACCH too early in Asynchronous Handoverhttps://projects.osmocom.org/issues/4008?journal_id=152202019-07-18T05:15:54Zlaforge
<ul><li><strong>Priority</strong> changed from <i>High</i> to <i>Normal</i></li></ul> OsmoBTS - Bug #4008: Channel Activation starts SACCH too early in Asynchronous Handoverhttps://projects.osmocom.org/issues/4008?journal_id=202462020-11-03T16:17:39Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Priority</strong> changed from <i>Normal</i> to <i>High</i></li></ul> OsmoBTS - Bug #4008: Channel Activation starts SACCH too early in Asynchronous Handoverhttps://projects.osmocom.org/issues/4008?journal_id=209812021-01-27T15:19:29Zneelsnhofmeyr@sysmocom.de
<ul><li><b>Checklist item</b> <input type='checkbox' class='checklist-checkbox' checked disabled> <i>osmo-bts-sysmo</i> set to Done</li></ul> OsmoBTS - Bug #4008: Channel Activation starts SACCH too early in Asynchronous Handoverhttps://projects.osmocom.org/issues/4008?journal_id=209822021-01-27T15:19:29Zneelsnhofmeyr@sysmocom.de
<ul><li><b>Checklist item</b> <input type='checkbox' class='checklist-checkbox' checked disabled> <i>osmo-bts-sysmo</i> set to Done</li><li><b>Checklist item</b> <input type='checkbox' class='checklist-checkbox' checked disabled> <i>osmo-bts-oc2g</i> set to Done</li><li><b>Checklist item</b> <input type='checkbox' class='checklist-checkbox' checked disabled> <i>osmo-bts-lc15</i> set to Done</li><li><b>Checklist item</b> <input type='checkbox' class='checklist-checkbox' checked disabled> <i>osmo-bts-trx</i> set to Done</li></ul> OsmoBTS - Bug #4008: Channel Activation starts SACCH too early in Asynchronous Handoverhttps://projects.osmocom.org/issues/4008?journal_id=209832021-01-27T15:38:48Zneelsnhofmeyr@sysmocom.de
<ul><li><b>Checklist item</b> <input type='checkbox' class='checklist-checkbox' disabled> <i>osmo-bts-sysmo</i> set to Not done</li><li><b>Checklist item</b> <input type='checkbox' class='checklist-checkbox' disabled> <i>osmo-bts-oc2g</i> set to Not done</li><li><b>Checklist item</b> <input type='checkbox' class='checklist-checkbox' disabled> <i>osmo-bts-lc15</i> set to Not done</li><li><b>Checklist item</b> <input type='checkbox' class='checklist-checkbox' disabled> <i>osmo-bts-trx</i> set to Not done</li><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>70</i></li></ul><p>Patches have been merged to keep SACCH deactivated in certain situations<br />(depending on what IEs the BSC sent during Channel Activation).</p>
<p>Still, OsmoBSC always sends the MS Power IE, so those patches will never have an effect when using OsmoBSC.<br />The rather non-trivial question is: what IEs should the BSC send in which situations?</p>
<p>The aim of this ticket is to keep SACCH deactivated as long as the TA is not known.<br />3GPP TS 48.058 4.1.3 and 4.1.4 define which SAPIs should be enabled for a handover target lchan.<br />Summary of that spec:</p>
<pre>
| | Access || transmit | activate
| MS Power | Delay || on main channel | dl SACCH
----------------------------------------------------------------------
async ho no * --> yes no
async ho yes * --> yes may be started
sync ho no no --> yes no
sync ho yes no --> yes may be started
sync ho yes yes --> yes shall be started
</pre>
<p>So for this ticket we are mostly interested in the MS Power IE being present or not.</p>
<p>Looking at 3GPP TS 48.058 we get this information from the footnotes:</p>
<ul>
<li>MS Power IE has two different meanings:
<ul>
<li>when MS Power Parameters IE is <strong>not</strong> present: MS Power IE indicates the initial power the MS should use.</li>
<li>when MS Power Parameters IE <strong>is</strong> present: MS Power IE indicates the maximum permitted MS power value.</li>
</ul></li>
</ul>
<p>OsmoBSC transmits the MS Power Parameters IE only when in dynamic power control mode.<br />See <a class="external" href="https://git.osmocom.org/osmo-bsc/tree/src/osmo-bsc/abis_rsl.c?id=80184ae1714f52cbeed8d94472975f07122e806f#n205">https://git.osmocom.org/osmo-bsc/tree/src/osmo-bsc/abis_rsl.c?id=80184ae1714f52cbeed8d94472975f07122e806f#n205</a></p>
<p>For a new lchan assignment or handover to another cell, OsmoBSC sends the bts->ms_max_power in the MS Power IE.<br />For a handover within the same cell, OsmoBSC sends the previous lchan's MS power in the MS Power IE.<br />(see <a class="external" href="https://git.osmocom.org/osmo-bsc/tree/src/osmo-bsc/lchan_fsm.c?id=80184ae1714f52cbeed8d94472975f07122e806f#n577">https://git.osmocom.org/osmo-bsc/tree/src/osmo-bsc/lchan_fsm.c?id=80184ae1714f52cbeed8d94472975f07122e806f#n577</a>)</p>
<p>So, first of all, it seems that we have a bug in OsmoBSC:<br />If a channel activation for handover sends both MS Power IE as well as MS Power Parameters IE (in dynamic power control mode),<br />then the BTS should interpret the MS Power IE as the maximum permitted MS power. But we send the previous lchan's power.</p>
<p>The other question is whether we can or ever should omit the MS Power IE from a channel activation,<br />to get the effect that we wanted to achieve with this issue in the first place,<br />being to omit the DL SACCH from a handover channel activation until the TA is known.<br />I would have assumed that the lchan should omit DL SACCH when the Timing Advance is omitted from the Channel Activation,<br />but at least for async HO, the TA presence (the Access Delay IE) apparently does not make any difference in the decision<br />to activate DL SACCH or not on initial channel activation, according to the spec.</p>
<p>At this moment I am a bit confused / undecided on what IEs the BSC should send in what situations...<br />any help is welcome.</p> OsmoBTS - Bug #4008: Channel Activation starts SACCH too early in Asynchronous Handoverhttps://projects.osmocom.org/issues/4008?journal_id=209842021-01-27T15:41:11Zneelsnhofmeyr@sysmocom.de
<ul><li><b>Checklist item</b> <input type='checkbox' class='checklist-checkbox' checked disabled> <i>osmo-bts-sysmo</i> set to Done</li><li><b>Checklist item</b> <input type='checkbox' class='checklist-checkbox' checked disabled> <i>osmo-bts-oc2g</i> set to Done</li><li><b>Checklist item</b> <input type='checkbox' class='checklist-checkbox' checked disabled> <i>osmo-bts-lc15</i> set to Done</li><li><b>Checklist item</b> <input type='checkbox' class='checklist-checkbox' checked disabled> <i>osmo-bts-trx</i> set to Done</li></ul><p>the merged patches are<br /><a class="external" href="https://git.osmocom.org/osmo-bts/commit/?id=f733cf826375a3f348b6195b286af872beef0ff7">https://git.osmocom.org/osmo-bts/commit/?id=f733cf826375a3f348b6195b286af872beef0ff7</a><br /><a class="external" href="https://git.osmocom.org/osmo-bts/commit/?id=1c05ef15ecb1a9053112b2c11bb5c062cee06478">https://git.osmocom.org/osmo-bts/commit/?id=1c05ef15ecb1a9053112b2c11bb5c062cee06478</a><br /><a class="external" href="https://git.osmocom.org/osmo-bts/commit/?id=61585254338d16bb359987ad1f4537900e6288db">https://git.osmocom.org/osmo-bts/commit/?id=61585254338d16bb359987ad1f4537900e6288db</a><br /><a class="external" href="https://git.osmocom.org/osmo-bts/commit/?id=4ee4d6be2a66a151de0fc0ef258d89fad4135a91">https://git.osmocom.org/osmo-bts/commit/?id=4ee4d6be2a66a151de0fc0ef258d89fad4135a91</a><br /><a class="external" href="https://git.osmocom.org/osmo-bts/commit/?id=def24f0d9af2463a5ef557d35f23abd5b4d07120">https://git.osmocom.org/osmo-bts/commit/?id=def24f0d9af2463a5ef557d35f23abd5b4d07120</a></p> OsmoBTS - Bug #4008: Channel Activation starts SACCH too early in Asynchronous Handoverhttps://projects.osmocom.org/issues/4008?journal_id=209852021-01-27T15:51:52Zneelsnhofmeyr@sysmocom.de
<ul></ul><blockquote>
<pre> async ho yes * --> yes may be started</pre>
</blockquote>
<p>I just realize that OsmoBTS could <strong>always</strong> deactivate DL SACCH for async HO,<br />regardless of the MS Power IE presence, because the spec says the DL SACCH <strong>may</strong> be started, not <strong>shall</strong> be started.</p>
<p>For sync HO it's a bit different, but this ticket here is about async HO.</p> OsmoBTS - Bug #4008: Channel Activation starts SACCH too early in Asynchronous Handoverhttps://projects.osmocom.org/issues/4008?journal_id=209862021-01-27T16:07:49Zneelsnhofmeyr@sysmocom.de
<ul></ul><pre>
| | Access || transmit | activate
| MS Power | Delay || on main channel | dl SACCH
----------------------------------------------------------------------
async ho no * --> yes no
async ho yes * --> yes may be started
sync ho no no --> yes no
sync ho yes no --> yes may be started
sync ho yes yes --> yes shall be started
</pre>
<p>A possible overall solution for both async and sync handover:</p>
<ul>
<li>when both MS Power and Access Delay IEs are present, then activate SACCH.</li>
<li>otherwise, do not activate SACCH.</li>
</ul>
<p>This would adhere to all the "no" rows, would opt for not sending SACCH for all "may be started" rows,<br />and also adheres to the last "shall be started" row.</p>
<p>Hence OsmoBSC would in practice trigger DL SACCH activation or not by sending Access Delay or not.<br />Then we can implement in OsmoBSC that we mostly omit an Access Delay IE in HO channel activation.<br />Send Access Delay only when it is an intra-cell HO with an already known TA.</p> OsmoBTS - Bug #4008: Channel Activation starts SACCH too early in Asynchronous Handoverhttps://projects.osmocom.org/issues/4008?journal_id=209872021-01-27T19:40:11Zlaforge
<ul></ul><p>Neels, I currently cannot dive into the last 'depty' of the topic, but one thing<br />to always keep in mind: OsmoBSC supports a vareity of BTS products out there, OsmoBTS<br />is only one of them.</p>
<p>So no matter what kind of changes we introduce, we should result in a spec-compliant<br />behavior. Relying on some special logic in OsmoBTS can only be considered as a last<br />resort, if the specs don't permit any generic solution.</p> OsmoBTS - Bug #4008: Channel Activation starts SACCH too early in Asynchronous Handoverhttps://projects.osmocom.org/issues/4008?journal_id=237732022-03-11T12:02:11Zfixeria
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-1 priority-2 priority-default" href="/issues/4009">Bug #4009</a>: Channel Activation starts SACCH too early in Synchronous Handover</i> added</li></ul> OsmoBTS - Bug #4008: Channel Activation starts SACCH too early in Asynchronous Handoverhttps://projects.osmocom.org/issues/4008?journal_id=237762022-03-11T12:47:37Zfixeria
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Feedback</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_async</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.</p>
<p>Test case <code>TC_sacch_chan_act_ho_async</code> fails because after sending a <em>CHANnel ACTIVation</em> message with 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 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>