https://osmocom.org/https://osmocom.org/favicon.ico?16647414092019-11-26T15:26:34ZOpen Source Mobile CommunicationsOsmoBTS - Bug #4281: MS power control loop is interrupted when bad frames are receivedhttps://osmocom.org/issues/4281?journal_id=165262019-11-26T15:26:34Zdexter
<ul></ul><p>I had a look at int lchan_ms_pwr_ctrl(struct gsm_lchan *lchan, const uint8_t ms_power, const int rxLevel). We could simply call the function with lchan->ms_power_ctrl.current for ms_power (data<sup><a href="#fn0">0</a></sup>) and a made up rssi value. That should work.</p> OsmoBTS - Bug #4281: MS power control loop is interrupted when bad frames are receivedhttps://osmocom.org/issues/4281?journal_id=165272019-11-26T15:35:38Zpespin
<ul></ul><p>If I understand correctly we still have the correct RSSI value in that case, what we lack is only the MS Power.</p>
<p>I don't know the details about how to decode the data, but it may make sense to separate between 2 cases if possible: 1 byte is available (but not entire block) or not available. In first case we can still feed correct parameters to the function, in the second we cannot.</p>
<p>In the case were no MS power is available we can indeed simply pass lchan->ms_power_ctrl.current.</p> OsmoBTS - Bug #4281: MS power control loop is interrupted when bad frames are receivedhttps://osmocom.org/issues/4281?journal_id=165282019-11-26T15:51:42Zdexter
<ul><li><strong>% Done</strong> changed from <i>0</i> to <i>80</i></li></ul><p>I think so, the rssi can be taken from data_ind->rssi. The lchan->ms_power_ctrl.current should be still correct. I do not think that the MS changes its power by itsself.</p>
<p>See also: <a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/16233">https://gerrit.osmocom.org/c/osmo-bts/+/16233</a> l1sap.c: ensure ms power control loop is running</p> OsmoBTS - Bug #4281: MS power control loop is interrupted when bad frames are receivedhttps://osmocom.org/issues/4281?journal_id=165292019-11-26T15:59:01Zpespin
<ul></ul>well lchan->ms_power_ctrl.current is the value we are requesting, but it doesn't necessarily mean it's the one using at that moment:
<ul>
<li>The MS may not support the requested ms power level, so it may be transmitting with the nearest supported one (for instance I have an MS which doesn't support power level 29, and in that case transmits with 0, the nearest one below in signal strength).</li>
<li>We may have just changed lchan->ms_power_ctrl.current from value A to B and MS may still be transmitting with value A or some value between A and B.</li>
</ul>
So we could discuss about which of the 2 approaches is better:
<ul>
<li>Pass lchan->ms_power_ctrl.current and let the regular power control loop algo run assuming the tx ms power level is same as lchan->ms_power_ctrl.current, meaning output calculated new ms power level is not accurate or wrong.</li>
<li>Pass special value to tell the algo to simply increase the requested MS power level. However, I'm not sure if that's actually always the correct expected way to solve it, since error to decode could be due to other factors. I'd welcome somebody with more RF knowledge to provide some advise here.</li>
</ul> OsmoBTS - Bug #4281: MS power control loop is interrupted when bad frames are receivedhttps://osmocom.org/issues/4281?journal_id=165862019-11-30T12:10:12Zlaforge
<ul></ul><p>On Tue, Nov 26, 2019 at 03:35:39PM +0000, pespin [REDMINE] wrote:</p>
<blockquote>
<p>If I understand correctly we still have the correct RSSI value in that case, what we lack is only the MS Power.</p>
</blockquote>
<p>ACK.</p>
<blockquote>
<p>I don't know the details about how to decode the data, but it may make sense to separate between 2 cases if possible: 1 byte is available (but not entire block) or not available. In first case we can still feed correct parameters to the function, in the second we cannot.</p>
</blockquote>
<p>You receive a MAC block and either can fix all bugs and hence the CRC passes, or you have som bit errors, and the CRC fails. If that happens, you have no idea where those bits are.</p>
<blockquote>
<p>In the case were no MS power is available we can indeed simply pass lchan->ms_power_ctrl.current.</p>
</blockquote>
<p>ACK.</p> OsmoBTS - Bug #4281: MS power control loop is interrupted when bad frames are receivedhttps://osmocom.org/issues/4281?journal_id=169962020-01-06T10:43:26Zdexter
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Resolved</i></li><li><strong>% Done</strong> changed from <i>80</i> to <i>100</i></li></ul>