https://projects.osmocom.org/https://projects.osmocom.org/favicon.ico?16647414092020-11-04T05:04:09ZOpen Source Mobile CommunicationsOsmoPCU - Bug #4844: do not resent DL assignment on RACHhttps://projects.osmocom.org/issues/4844?journal_id=202492020-11-04T05:04:09Zfixeria
<ul></ul><p>This is a very confusing ticket description:</p>
<blockquote>
<p>do not resent DL assignment on RACH</p>
</blockquote>
<p>RACH is an Uplink-only unidirectional channel, so how can a Downlink assignment be sent on Uplink?</p>
<blockquote>
<p>When a MS wants to send data without a TBF present,<br />it sends a RACH, get's an immediate assign, moves over to the PDCH and receives a UL assignment.</p>
</blockquote>
<p>It actually receives an Uplink resource assignment in the Rest Octets of (RR) Immediate Assignment.</p>
<blockquote>
<p>However if the MS misses either the immediate assign or the UL assignment, the PCU tries to assign using the TLLI 0x0, which seems to be wrong.<br />The PCU uses TLLI 0x0, even it can't know the TLLI of the MS. It only knows it by the first UL data.</p>
</blockquote>
<p>Yep, more specifically a new TBF is always allocated with TLLI=0x00000000. I am not sure if 0x00000000 or 0xffffffff is a valid TLLI; the specs. do not mention any reserved values. On the other hand, in osmo-ttcn-hack we do have TLLI_UNUSED := 'FFFFFFFF'...</p> OsmoPCU - Bug #4844: do not resent DL assignment on RACHhttps://projects.osmocom.org/issues/4844?journal_id=202632020-11-05T14:30:12Zlaforge
<ul></ul><p>On Wed, Nov 04, 2020 at 05:04:09AM +0000, fixeria [REDMINE] wrote:</p>
<blockquote>
<p>Yep, more specifically a new TBF is always allocated with TLLI=0x00000000. I am not sure if 0x00000000 or 0xffffffff is a valid TLLI; the specs. do not mention any reserved values. On the other hand, in osmo-ttcn-hack we do have TLLI_UNUSED := 'FFFFFFFF'...</p>
</blockquote>
<p>TLLI is derived from TMSI, and TMSI 0xffffffff is reserved for "not valid TLLI". the reason for that<br />is that EF.TMSI - like all files on smart cards - are 0xffffffff in erased state.</p> OsmoPCU - Bug #4844: do not resent DL assignment on RACHhttps://projects.osmocom.org/issues/4844?journal_id=202842020-11-08T06:39:06Zfixeria
<ul></ul><p>I have not (yet) tested this change, and didn't run ttcn3-pcu-test against it:</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/osmo-pcu/+/21073">https://gerrit.osmocom.org/c/osmo-pcu/+/21073</a> TLLI 0x00000000 is a valid TLLI, use 0xffffffff instead</p>
<p>so let's keep it WIP for now.</p> OsmoPCU - Bug #4844: do not resent DL assignment on RACHhttps://projects.osmocom.org/issues/4844?journal_id=202852020-11-08T06:47:38Zfixeria
<ul></ul><p>P.S. BEWARE! Opening huge diffs in Gerrit may lead to OOM!</p> OsmoPCU - Bug #4844: do not resent DL assignment on RACHhttps://projects.osmocom.org/issues/4844?journal_id=206122020-12-17T01:04:04Zlynxis
<ul><li><strong>Assignee</strong> set to <i>fixeria</i></li></ul> OsmoPCU - Bug #4844: do not resent DL assignment on RACHhttps://projects.osmocom.org/issues/4844?journal_id=213262021-02-17T14:16:12Zfixeria
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Feedback</i></li><li><strong>Assignee</strong> changed from <i>fixeria</i> to <i>lynxis</i></li></ul><p>I still do not understand what's the problem here, please clarify ticket description.</p>
<blockquote>
<p>However if the MS misses either the immediate assign or the UL assignment, the PCU tries to assign using the TLLI 0x0, which seems to be wrong. The PCU uses TLLI 0x0, even it can't know the TLLI of the MS. It only knows it by the first UL data.</p>
</blockquote>
<p>What do you expect to happen if the MS does not respond to the assignment?</p> OsmoPCU - Bug #4844: do not resent DL assignment on RACHhttps://projects.osmocom.org/issues/4844?journal_id=213542021-02-19T12:57:02Zlynxis
<ul><li><strong>Description</strong> updated (<a title="View differences" href="/journals/21354/diff?detail_id=35584">diff</a>)</li></ul> OsmoPCU - Bug #4844: do not resent DL assignment on RACHhttps://projects.osmocom.org/issues/4844?journal_id=213552021-02-19T12:57:21Zlynxis
<ul><li><strong>Assignee</strong> changed from <i>lynxis</i> to <i>fixeria</i></li><li><strong>% Done</strong> changed from <i>0</i> to <i>60</i></li></ul> OsmoPCU - Bug #4844: do not resent DL assignment on RACHhttps://projects.osmocom.org/issues/4844?journal_id=213682021-02-20T17:37:14Zfixeria
<ul></ul><p>I am sorry, but it's still not clear what's wrong and what do you expect. I am inclined to reject it.</p>
<pre>
RACH ->
X- IMM assign (MS never receive IMM assign)
---- PCU have a UL timeout and doesn't know the TLLI
<- UL TBF Assignment TLLI for 0x0000000.
</pre>
<p>Why would there be another assignment (last packet in your diagram)? Yes, osmo-pcu would create an Uplink TBF with a special TLLI (0xffffffff in the recent versions), which would simply expire after a timeout. Other than the first assignment in Immediate Assignment, nothing else will be sent.</p>
<p>I created a very simple test case that confirms my understanding:</p>
<p><a class="external" href="https://git.osmocom.org/osmo-ttcn3-hacks/commit/?h=fixeria/OS4844&id=46cf8242d2be9f49f035bd4970cb33cdcf6e9dd2">https://git.osmocom.org/osmo-ttcn3-hacks/commit/?h=fixeria/OS4844&id=46cf8242d2be9f49f035bd4970cb33cdcf6e9dd2</a></p>
<p>Feel free to change this test case in order to demonstrate the problem, or at least provide a proper explanation.</p> OsmoPCU - Bug #4844: do not resent DL assignment on RACHhttps://projects.osmocom.org/issues/4844?journal_id=213692021-02-20T17:37:38Zfixeria
<ul><li><strong>Assignee</strong> changed from <i>fixeria</i> to <i>lynxis</i></li><li><strong>% Done</strong> changed from <i>60</i> to <i>0</i></li></ul> OsmoPCU - Bug #4844: do not resent DL assignment on RACHhttps://projects.osmocom.org/issues/4844?journal_id=230072021-11-12T20:12:00Zpespin
<ul></ul><p>I am not aware of such an issue in nowdays PCU after all the fixes and refactorings, so I'd be inclinded to close the ticket too. Leting lynxis comment on it.</p> OsmoPCU - Bug #4844: do not resent DL assignment on RACHhttps://projects.osmocom.org/issues/4844?journal_id=274892023-07-28T14:44:46Zpespin
<ul></ul><p>More than 1 year without feedback here, so I'm inclined to close this ticket in the following weeks/months if no new feedback or ttcn3 test / manual run is provided showing the problem.</p>