https://projects.osmocom.org/https://projects.osmocom.org/favicon.ico?16647414092021-02-17T19:01:11ZOpen Source Mobile CommunicationsOsmoPCU - Bug #5033: N3101 potentially being updated only during RBBP poll but not during USF pollhttps://projects.osmocom.org/issues/5033?journal_id=213322021-02-17T19:01:11Zpespin
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-3 priority-2 priority-default closed" href="/issues/5020">Bug #5020</a>: osmo-pcu: Poll and SBA allocation improvements and fixes</i> added</li></ul> OsmoPCU - Bug #5033: N3101 potentially being updated only during RBBP poll but not during USF pollhttps://projects.osmocom.org/issues/5033?journal_id=214552021-03-03T17:54:55Zpespin
<ul></ul>Related issue:<br />According to specs, T3169 is only to be armed when:
<ul>
<li>N3101_MAX is reached, by incrementing N3101 (unanswered USF transmitted blocks).</li>
<li>N3103_MAX is reached, by incrementing N3103 (unanswered last UL ACK by means of CTRL ACK by MS, incremented on each retransmition of UL ACK).</li>
</ul>
<p>Furthermore, when T3169 is enabled, the tbf should be in state RELEASING so that its USF is not used (see below some uses of it don't fullfil this).</p>
However, I see T3169 being armed in up to 5 places:
<ul>
<li>tbf.cpp gprs_rlcmac_tbf::poll_timeout(): This is at first sight the only proper place where it should happen, that is, after increasing N3101. It has to yet bee seen whether this whole block is correctly placed here in this function (see rant at the description of the ticket).</li>
<li>tbf.cpp gprs_rlcmac_tbf::poll_timeout(): Check for the "N3103_MAX" condition. This one looks good to me.</li>
<li>bts.cpp bts_rcv_rach(): T3169 is IMHO abused here and wrongly used, since the TBF is not set to RELEASE state (for obvious reasons). It needs to be checked with a TTCN3 what happens exactly under the scenario where MS never transmits UL data after requesting the UL ASS, specially for single block allocations. If a TBF exists, AFAIU we should simply rely on N3101 and drop the T_START for this case.</li>
<li>tbf_ul.cpp tbf_alloc_ul(): Same here, we should rely on N3101 to eventually start T3169.</li>
<li>tbf_ul.cpp gprs_rlcmac_ul_tbf::rcv_data_block_acknowledged(): This seems like a complete abuse of T3169 in order to make sure to drop eventually the TBF.</li>
</ul>
<p>So all in all, my feeling is that N3101 counting may be broken and hence we rely on abusing T3169 by setting it directly in different places.</p> OsmoPCU - Bug #5033: N3101 potentially being updated only during RBBP poll but not during USF pollhttps://projects.osmocom.org/issues/5033?journal_id=214682021-03-04T12:59:54Zpespin
<ul></ul><p>pespin wrote:</p>
<blockquote>
<ul>
<li>bts.cpp bts_rcv_rach(): T3169 is IMHO abused here and wrongly used, since the TBF is not set to RELEASE state (for obvious reasons). It needs to be checked with a TTCN3 what happens exactly under the scenario where MS never transmits UL data after requesting the UL ASS, specially for single block allocations. If a TBF exists, AFAIU we should simply rely on N3101 and drop the T_START for this case.</li>
</ul>
</blockquote>
<p><a class="external" href="https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/23232">https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/23232</a> pcu: Introduce test TC_n3101_max_t3169</p>
<p>So my concerns seems to be true. AFAICT there's no system in place for osmo-pcu now (PCUIF issue?) to detect USF assigned UL blocks for which no data was received, hence N3101 doesn't seem to be incremented, only by lost RRBP polls (gprs_rlcmac_tbf::poll_timeout() only called in that case, and N3101 being incremented there).</p>
<p>I still need to investigate further what goes on in BTS and PCUIF when the BTS is unable to decode a PDCH block (FN). A potentially good improvement would be to send some sort of NOPE-ind as we do in TRXDv1 nowadays.</p> OsmoPCU - Bug #5033: N3101 potentially being updated only during RBBP poll but not during USF pollhttps://projects.osmocom.org/issues/5033?journal_id=217362021-03-24T18:19:12Zpespin
<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>60</i></li></ul><p>remote: <a class="external" href="https://gerrit.osmocom.org/c/osmo-pcu/+/23486">https://gerrit.osmocom.org/c/osmo-pcu/+/23486</a> Fix: left shift cannot be repesented in type int [NEW]<br />remote: <a class="external" href="https://gerrit.osmocom.org/c/osmo-pcu/+/23487">https://gerrit.osmocom.org/c/osmo-pcu/+/23487</a> sched: Fix scheduling UL TBF not matching conditions [NEW]<br />remote: <a class="external" href="https://gerrit.osmocom.org/c/osmo-pcu/+/23488">https://gerrit.osmocom.org/c/osmo-pcu/+/23488</a> sched: Simplify usf selection code [NEW]<br />remote: <a class="external" href="https://gerrit.osmocom.org/c/osmo-pcu/+/23489">https://gerrit.osmocom.org/c/osmo-pcu/+/23489</a> Set matching USF if available when polling a UL TBF [NEW]<br />remote: <a class="external" href="https://gerrit.osmocom.org/c/osmo-pcu/+/23490">https://gerrit.osmocom.org/c/osmo-pcu/+/23490</a> pdch: Add mising pdch_ulc_release_node in Rx Cell Change Notif [NEW]<br />remote: <a class="external" href="https://gerrit.osmocom.org/c/osmo-pcu/+/23491">https://gerrit.osmocom.org/c/osmo-pcu/+/23491</a> pdch_ulc: Create helper API pdch_ulc_release_node [NEW]<br />remote: <a class="external" href="https://gerrit.osmocom.org/c/osmo-pcu/+/23492">https://gerrit.osmocom.org/c/osmo-pcu/+/23492</a> Track scheduled UL blocks through USF [NEW]<br />remote: <a class="external" href="https://gerrit.osmocom.org/c/osmo-pcu/+/23493">https://gerrit.osmocom.org/c/osmo-pcu/+/23493</a> Properly implement N3101 [NEW]</p>
After this bunch of patches become merged, we already track all sort of UL blocks in a unified way. What's missing regarding this ticket:
<ul>
<li>Make sure TTCN3 tests for T3169, N3101, N3103 and N3105 are passing fine. That means, investigating whether those counters are being incremented/reset in a correct way.</li>
<li>Rework T3169 to only be armed as a result of N3101_MAX, N3103_MAX, etc. (when TBF goes into RELEASE state iirc), instead of having it always armed and re-arm it every itme something is received.</li>
</ul> OsmoPCU - Bug #5033: N3101 potentially being updated only during RBBP poll but not during USF pollhttps://projects.osmocom.org/issues/5033?journal_id=219382021-04-20T12:11:57Zpespin
<ul></ul><blockquote>
What's missing regarding this ticket:
<ul>
<li>Make sure TTCN3 tests for T3169, N3101, N3103 and N3105 are passing fine. That means, investigating whether those counters are being incremented/reset in a correct way.</li>
</ul>
</blockquote>
<p>This is done in several tests, all of them behaving fine:<br /><pre>
execute( TC_n3101_max_t3169() );
execute( TC_n3103_max_t3169() );
execute( TC_n3105_max_t3195() );
</pre></p>
<p>I just submitted the missing one for N3103 here:<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/23811">https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/23811</a> pcu: Introduce test TC_n3103_max_t3169</p>
<blockquote>
<ul>
<li>Rework T3169 to only be armed as a result of N3101_MAX, N3103_MAX, etc. (when TBF goes into RELEASE state iirc), instead of having it always armed and re-arm it every itme something is received.</li>
</ul>
</blockquote>
<p>^ This is still TODO.</p> OsmoPCU - Bug #5033: N3101 potentially being updated only during RBBP poll but not during USF pollhttps://projects.osmocom.org/issues/5033?journal_id=219972021-04-26T10:32:36Zpespin
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Feedback</i></li><li><strong>% Done</strong> changed from <i>60</i> to <i>90</i></li></ul><p>pespin wrote:</p>
<blockquote><blockquote>
<ul>
<li>Rework T3169 to only be armed as a result of N3101_MAX, N3103_MAX, etc. (when TBF goes into RELEASE state iirc), instead of having it always armed and re-arm it every itme something is received.</li>
</ul>
</blockquote>
<p>^ This is still TODO.</p>
</blockquote>
<p>Done here, once merged the ticket can be closed:<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-pcu/+/23872">https://gerrit.osmocom.org/c/osmo-pcu/+/23872</a> Stop abusing T3169</p> OsmoPCU - Bug #5033: N3101 potentially being updated only during RBBP poll but not during USF pollhttps://projects.osmocom.org/issues/5033?journal_id=219992021-04-26T10:39:06Zpespin
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-7 priority-3 priority-high3" href="/issues/3928">Bug #3928</a>: Missing PCU_Tests.ttcn for various timers / time-outs</i> added</li></ul> OsmoPCU - Bug #5033: N3101 potentially being updated only during RBBP poll but not during USF pollhttps://projects.osmocom.org/issues/5033?journal_id=220762021-05-13T12:08:35Zpespin
<ul><li><strong>Status</strong> changed from <i>Feedback</i> to <i>Resolved</i></li><li><strong>% Done</strong> changed from <i>90</i> to <i>100</i></li></ul><p>Merged, closing.</p>