https://www.osmocom.org/https://www.osmocom.org/favicon.ico?16647414092017-12-03T10:23:33ZOpen Source Mobile CommunicationsOsmoBTS - Bug #1854: 11-bit RACH support breaks default 8-bit RACH: collisions are possiblehttps://www.osmocom.org/issues/1854?journal_id=64882017-12-03T10:23:33Zlaforge
<ul><li><strong>Assignee</strong> set to <i>msuraev</i></li></ul> OsmoBTS - Bug #1854: 11-bit RACH support breaks default 8-bit RACH: collisions are possiblehttps://www.osmocom.org/issues/1854?journal_id=65282017-12-04T11:02:05Zmsuraev
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-3 priority-2 priority-default closed" href="/issues/1548">Bug #1548</a>: 11bit RACH support</i> added</li></ul> OsmoBTS - Bug #1854: 11-bit RACH support breaks default 8-bit RACH: collisions are possiblehttps://www.osmocom.org/issues/1854?journal_id=65372017-12-04T12:04:27Zmsuraev
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>In Progress</i></li></ul><p>Encoding/decoding support for 11-bit RACH for libosmocoding is available in gerrit 5062.</p> OsmoBTS - Bug #1854: 11-bit RACH support breaks default 8-bit RACH: collisions are possiblehttps://www.osmocom.org/issues/1854?journal_id=71762018-01-17T16:34:24Zmsuraev
<ul><li><strong>% Done</strong> changed from <i>0</i> to <i>10</i></li></ul><p>Support was merged to libosmocoding. README update is in gerrit 5833. The next step is to implement it in osmo-bts-trx and test.</p> OsmoBTS - Bug #1854: 11-bit RACH support breaks default 8-bit RACH: collisions are possiblehttps://www.osmocom.org/issues/1854?journal_id=73582018-01-30T09:17:38Zmsuraev
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Stalled</i></li></ul> OsmoBTS - Bug #1854: 11-bit RACH support breaks default 8-bit RACH: collisions are possiblehttps://www.osmocom.org/issues/1854?journal_id=77332018-02-21T23:34:28Zmsuraev
<ul></ul><p>The tests with gerrit 6315 is not working with current master of omopcu. We should re-test with sysmobts andimplement missing pieces.</p> OsmoBTS - Bug #1854: 11-bit RACH support breaks default 8-bit RACH: collisions are possiblehttps://www.osmocom.org/issues/1854?journal_id=79572018-03-01T23:14:05Zlaforge
<ul><li><strong>Assignee</strong> changed from <i>msuraev</i> to <i>4368</i></li></ul> OsmoBTS - Bug #1854: 11-bit RACH support breaks default 8-bit RACH: collisions are possiblehttps://www.osmocom.org/issues/1854?journal_id=81232018-03-10T07:22:48Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-7 priority-2 priority-default" href="/issues/3054">Feature #3054</a>: Extended (11-bit) RACH support in OsmoTRX</i> added</li></ul> OsmoBTS - Bug #1854: 11-bit RACH support breaks default 8-bit RACH: collisions are possiblehttps://www.osmocom.org/issues/1854?journal_id=81242018-03-10T07:23:35Zlaforge
<ul></ul><p>Please note not even OsmoTRX currently has support for this, see <a class="issue tracker-2 status-7 priority-2 priority-default" title="Feature: Extended (11-bit) RACH support in OsmoTRX (Stalled)" href="https://www.osmocom.org/issues/3054">#3054</a></p> OsmoBTS - Bug #1854: 11-bit RACH support breaks default 8-bit RACH: collisions are possiblehttps://www.osmocom.org/issues/1854?journal_id=122532018-10-17T09:44:02Zlaforge
<ul><li><strong>Assignee</strong> changed from <i>4368</i> to <i>msuraev</i></li></ul> OsmoBTS - Bug #1854: 11-bit RACH support breaks default 8-bit RACH: collisions are possiblehttps://www.osmocom.org/issues/1854?journal_id=127912018-11-29T12:41:37Zlaforge
<ul></ul><p>see also <a class="external" href="https://gerrit.osmocom.org/#/c/osmo-bts/+/5833/">https://gerrit.osmocom.org/#/c/osmo-bts/+/5833/</a></p> OsmoBTS - Bug #1854: 11-bit RACH support breaks default 8-bit RACH: collisions are possiblehttps://www.osmocom.org/issues/1854?journal_id=134292019-02-21T16:39:42Zmsuraev
<ul><li><strong>Status</strong> changed from <i>Stalled</i> to <i>In Progress</i></li><li><strong>% Done</strong> changed from <i>10</i> to <i>40</i></li></ul><p>After merging <a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/6315">https://gerrit.osmocom.org/c/osmo-bts/+/6315</a> and corresponding <a class="external" href="https://gerrit.osmocom.org/c/osmo-trx/+/11423">https://gerrit.osmocom.org/c/osmo-trx/+/11423</a> and related OsmoTRX patches there's TTCN-3 failure in TC_rach_content() and TC_rach_count() due to some (about 16 out of 1000) RACH being "lost". So far I'm unable to reproduce this using real phone. I'm not sure yet what's so special about the lost RACH (e. g. '0xCF') which makes a difference or whether rach content itself has anything to do with it at all. Investigation is ongoing.</p>
<p>The error constantly appears only with '0xCF', '0xBE' and '0x00' RA values for different FN.</p> OsmoBTS - Bug #1854: 11-bit RACH support breaks default 8-bit RACH: collisions are possiblehttps://www.osmocom.org/issues/1854?journal_id=136542019-03-26T15:29:02Zmsuraev
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Stalled</i></li><li><strong>% Done</strong> changed from <i>40</i> to <i>50</i></li></ul><p>Related <a class="external" href="https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/13128">https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/13128</a> might be useful for local testing.<br />Once the issue is fixed, <a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/5833">https://gerrit.osmocom.org/c/osmo-bts/+/5833</a> should be merged as well.</p> OsmoBTS - Bug #1854: 11-bit RACH support breaks default 8-bit RACH: collisions are possiblehttps://www.osmocom.org/issues/1854?journal_id=140722019-04-20T23:04:31Zfixeria
<ul><li><strong>Tracker</strong> changed from <i>Feature</i> to <i>Bug</i></li><li><strong>Status</strong> changed from <i>Stalled</i> to <i>In Progress</i></li><li><strong>Assignee</strong> changed from <i>msuraev</i> to <i>fixeria</i></li><li><strong>% Done</strong> changed from <i>50</i> to <i>80</i></li><li><strong>Spec Reference</strong> set to <i>3GPP TS 05.02, section 5.2.7</i></li></ul><blockquote>
<p>The error constantly appears only with '0xCF', '0xBE' and '0x00' RA values for different FN.</p>
</blockquote>
<p>Please see: <a class="external" href="https://gerrit.osmocom.org/#/c/osmo-bts/+/13723/">https://gerrit.osmocom.org/#/c/osmo-bts/+/13723/</a></p>
<p>Changing to 'Bug' since merging this feature (without proper testing) introduced a regression.</p> OsmoBTS - Bug #1854: 11-bit RACH support breaks default 8-bit RACH: collisions are possiblehttps://www.osmocom.org/issues/1854?journal_id=140742019-04-21T20:33:19Zfixeria
<ul><li><strong>Subject</strong> changed from <i>11bit RACH support in osmo-bts-trx</i> to <i>11-bit RACH support breaks default 8-bit RACH: collisions are possible</i></li><li><strong>Priority</strong> changed from <i>Normal</i> to <i>Urgent</i></li></ul><blockquote>
<p>Please see: <a class="external" href="https://gerrit.osmocom.org/#/c/osmo-bts/+/13723/">https://gerrit.osmocom.org/#/c/osmo-bts/+/13723/</a></p>
</blockquote>
<p>I've got an idea: what if I overcomplicated the task with the synch. sequence detection? What if changing the order of both gsm0503_rach_ext_decode_ber() and gsm0503_rach_decode_ber() would be enough? I did a quick test, and yes! Changing the order vice versa makes both TC_rach_content() and TC_rach_count() TTCN-3 test cases happy. However...</p>
<p>To be 100% sure, I decided to write a simple collision test. The key idea is to encode all possible 8-bit RA values for all possible BSIC values, and attempt to decode them as 11-bit RACH. This replicates the current behaviour. Additionally, this test encodes all possible 11-bit RA values for all possible BSIC values, and attempts to decode them as 8-bit RACH. Please see an attached file.</p>
<pre>
=== Looking for possible collisions: decoding 8-bit RACH as 11-bit
Successfully decoded 8-bit (0xc0) RACH as 11-bit (0x0500): bsic=0x00
Successfully decoded 8-bit (0x06) RACH as 11-bit (0x0184): bsic=0x01
Successfully decoded 8-bit (0x7e) RACH as 11-bit (0x04cf): bsic=0x01
Successfully decoded 8-bit (0x80) RACH as 11-bit (0x0700): bsic=0x01
Successfully decoded 8-bit (0x82) RACH as 11-bit (0x04fc): bsic=0x01
Successfully decoded 8-bit (0xa5) RACH as 11-bit (0x02f3): bsic=0x01
Successfully decoded 8-bit (0xfa) RACH as 11-bit (0x0737): bsic=0x01
Successfully decoded 8-bit (0x3a) RACH as 11-bit (0x0237): bsic=0x02
Successfully decoded 8-bit (0x6a) RACH as 11-bit (0x001c): bsic=0x02
Successfully decoded 8-bit (0x77) RACH as 11-bit (0x057d): bsic=0x02
Successfully decoded 8-bit (0xf6) RACH as 11-bit (0x0764): bsic=0x02
Successfully decoded 8-bit (0x0a) RACH as 11-bit (0x030c): bsic=0x03
Successfully decoded 8-bit (0x19) RACH as 11-bit (0x0435): bsic=0x03
Successfully decoded 8-bit (0x3a) RACH as 11-bit (0x0237): bsic=0x03
Successfully decoded 8-bit (0x8e) RACH as 11-bit (0x011e): bsic=0x03
Successfully decoded 8-bit (0xa5) RACH as 11-bit (0x02f3): bsic=0x03
Successfully decoded 8-bit (0x0f) RACH as 11-bit (0x03ed): bsic=0x04
Successfully decoded 8-bit (0x37) RACH as 11-bit (0x027d): bsic=0x04
Successfully decoded 8-bit (0x42) RACH as 11-bit (0x0317): bsic=0x04
...
=== Looking for possible collisions: decoding 11-bit RACH as 8-bit
Successfully decoded 11-bit (0x0067) RACH as 8-bit (0x86): bsic=0x00
Successfully decoded 11-bit (0x0100) RACH as 8-bit (0xc0): bsic=0x00
Successfully decoded 11-bit (0x0146) RACH as 8-bit (0x87): bsic=0x00
Successfully decoded 11-bit (0x0197) RACH as 8-bit (0xda): bsic=0x00
Successfully decoded 11-bit (0x0354) RACH as 8-bit (0x03): bsic=0x00
Successfully decoded 11-bit (0x03a5) RACH as 8-bit (0x2b): bsic=0x00
Successfully decoded 11-bit (0x061a) RACH as 8-bit (0xbe): bsic=0x00
Successfully decoded 11-bit (0x0628) RACH as 8-bit (0xe6): bsic=0x00
Successfully decoded 11-bit (0x062a) RACH as 8-bit (0x4c): bsic=0x00
Successfully decoded 11-bit (0x0657) RACH as 8-bit (0x6a): bsic=0x00
Successfully decoded 11-bit (0x068c) RACH as 8-bit (0x2a): bsic=0x00
Successfully decoded 11-bit (0x06c0) RACH as 8-bit (0xe0): bsic=0x00
Successfully decoded 11-bit (0x0714) RACH as 8-bit (0xcc): bsic=0x00
Successfully decoded 11-bit (0x0734) RACH as 8-bit (0x4c): bsic=0x00
Successfully decoded 11-bit (0x0748) RACH as 8-bit (0xde): bsic=0x00
Successfully decoded 11-bit (0x078a) RACH as 8-bit (0x5d): bsic=0x00
Successfully decoded 11-bit (0x07bc) RACH as 8-bit (0xc2): bsic=0x00
Successfully decoded 11-bit (0x07f0) RACH as 8-bit (0x08): bsic=0x00
Successfully decoded 11-bit (0x07f1) RACH as 8-bit (0x5d): bsic=0x00
Successfully decoded 11-bit (0x0006) RACH as 8-bit (0x3e): bsic=0x01
Successfully decoded 11-bit (0x0164) RACH as 8-bit (0x36): bsic=0x01
Successfully decoded 11-bit (0x0173) RACH as 8-bit (0xe5): bsic=0x01
Successfully decoded 11-bit (0x0184) RACH as 8-bit (0x06): bsic=0x01
Successfully decoded 11-bit (0x0185) RACH as 8-bit (0x53): bsic=0x01
Successfully decoded 11-bit (0x0212) RACH as 8-bit (0xc0): bsic=0x01
Successfully decoded 11-bit (0x026f) RACH as 8-bit (0x33): bsic=0x01
Successfully decoded 11-bit (0x0276) RACH as 8-bit (0x1f): bsic=0x01
...
</pre>
<p>The results show that collisions are possible in both cases, regardless of the ordering. Changing the order would make the situation even worse:</p>
<pre>
=== Results:
- decoding 8-bit RACH as 11-bit: 260
- decoding 11-bit RACH as 8-bit: 1961
</pre>
<p>This analysis should have been done before merging extended (11-bit) RACH support.</p>
<p>I think the proposed solution (i.e. distinguishing by the synch. sequence: <a class="external" href="https://gerrit.osmocom.org/#/c/osmo-bts/+/13723/">https://gerrit.osmocom.org/#/c/osmo-bts/+/13723/</a>) is probably the only valid way, and we need to merge it as soon as possible. With default BSIC=63, the following 8-bit RA values are misinterpreted as 11-bit RACH bursts:</p>
<pre>
Successfully decoded 8-bit (0x00) RACH as 11-bit (0x0000): bsic=0x3f
Successfully decoded 8-bit (0xbe) RACH as 11-bit (0x0388): bsic=0x3f
Successfully decoded 8-bit (0xcf) RACH as 11-bit (0x0036): bsic=0x3f
</pre>
<p>Recently I introduced the extended (11-bit) RACH support in OsmocomBB/trxcon:</p>
<p><a class="external" href="https://gerrit.osmocom.org/#/c/osmocom-bb/+/13731/">https://gerrit.osmocom.org/#/c/osmocom-bb/+/13731/</a><br /><a class="external" href="https://gerrit.osmocom.org/#/c/osmocom-bb/+/13732/">https://gerrit.osmocom.org/#/c/osmocom-bb/+/13732/</a></p>
<p>so the missing part is a couple of TTCN-3 test cases.</p>
<p>The last (but quite important) question for me: may 11-bit RACH bursts use the default TS0 synch. sequence, as regular 8-bit RACH does? And may a regular 8-bit RACH use the additional TS1 / TS2 synch. sequences? I couldn't find the answer in specifications, but if yes, then I don't really know, how else can we distinguish 8-bit and 11-bit RACH?</p> OsmoBTS - Bug #1854: 11-bit RACH support breaks default 8-bit RACH: collisions are possiblehttps://www.osmocom.org/issues/1854?journal_id=140762019-04-21T20:51:43Zfixeria
<ul><li><strong>File</strong> <a href="/attachments/3660">rach_test.c</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/3660/rach_test.c">rach_test.c</a> added</li></ul><p>Adding the forgotten attachment.</p> OsmoBTS - Bug #1854: 11-bit RACH support breaks default 8-bit RACH: collisions are possiblehttps://www.osmocom.org/issues/1854?journal_id=140782019-04-21T22:09:45Zfixeria
<ul></ul><blockquote>
<p>The last (but quite important) question for me [...]</p>
</blockquote>
<p>Ok, I've finally found the answer in 3GPP TS 04.60, section 11.2.5a. The EGPRS capability can be indicated by the MS using the alternative training sequences (i.e. TS1 or TS2) and the 11-bit RACH coding scheme. Therefore, the if we detect TS0 - it's a generic 8-bit Access Burst, otherwise it's an extended 11-bit Access Burst. The proposed solution is correct.</p> OsmoBTS - Bug #1854: 11-bit RACH support breaks default 8-bit RACH: collisions are possiblehttps://www.osmocom.org/issues/1854?journal_id=140792019-04-22T00:06:44Zfixeria
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Feedback</i></li><li><strong>% Done</strong> changed from <i>80</i> to <i>100</i></li></ul><blockquote>
<p>so the missing part is a couple of TTCN-3 test cases.</p>
</blockquote>
<p>Please see:</p>
<p><a class="external" href="https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/13734/">https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/13734/</a><br /><a class="external" href="https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/13735/">https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/13735/</a></p>
<p>Everything seems to work just fine. The last thing I need to do is to write a proper commit message for:</p>
<p><a class="external" href="https://gerrit.osmocom.org/#/c/osmo-bts/+/13723/">https://gerrit.osmocom.org/#/c/osmo-bts/+/13723/</a></p>
<p>so we can merge it then and close this issue.</p> OsmoBTS - Bug #1854: 11-bit RACH support breaks default 8-bit RACH: collisions are possiblehttps://www.osmocom.org/issues/1854?journal_id=143872019-05-09T18:44:00Zfixeria
<ul><li><strong>Status</strong> changed from <i>Feedback</i> to <i>Resolved</i></li></ul><p>The fix for osmo-bts-trx has been merged.</p> OsmoBTS - Bug #1854: 11-bit RACH support breaks default 8-bit RACH: collisions are possiblehttps://www.osmocom.org/issues/1854?journal_id=264422023-03-21T13:11:34Zfixeria
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-3 priority-2 priority-default closed" href="/issues/5955">Bug #5955</a>: ttcn3-bts-test: TC_pcu_[ext_]rach_content is failing</i> added</li></ul>