https://osmocom.org/https://osmocom.org/favicon.ico?16647414092016-12-23T09:53:39ZOpen Source Mobile CommunicationsOsmoBTS - Feature #1851: generalize power control and TA loop codehttps://osmocom.org/issues/1851?journal_id=26962016-12-23T09:53:39Zlaforge
<ul></ul> OsmoBTS - Feature #1851: generalize power control and TA loop codehttps://osmocom.org/issues/1851?journal_id=41762017-05-30T15:32:40Zlaforge
<ul></ul> OsmoBTS - Feature #1851: generalize power control and TA loop codehttps://osmocom.org/issues/1851?journal_id=41772017-05-30T15:32:49Zlaforge
<ul><li><strong>Assignee</strong> set to <i>4368</i></li></ul> OsmoBTS - Feature #1851: generalize power control and TA loop codehttps://osmocom.org/issues/1851?journal_id=77872018-02-23T18:55:30Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-5 priority-2 priority-default closed" href="/issues/2989">Bug #2989</a>: OsmoBTS reports ever-growing TA value</i> added</li></ul> OsmoBTS - Feature #1851: generalize power control and TA loop codehttps://osmocom.org/issues/1851?journal_id=82272018-03-14T13:09:09Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-5 priority-1 priority-lowest closed" href="/issues/3055">Bug #3055</a>: osmo-bts-trx: slow TA loop feedback</i> added</li></ul> OsmoBTS - Feature #1851: generalize power control and TA loop codehttps://osmocom.org/issues/1851?journal_id=97762018-06-06T21:54:27Zlaforge
<ul></ul><p>see also: <a class="wiki-page" href="https://osmocom.org/projects/osmobts/wiki/Timing_Advance">Timing_Advance</a></p> OsmoBTS - Feature #1851: generalize power control and TA loop codehttps://osmocom.org/issues/1851?journal_id=122992018-10-20T19:37:24Zlaforge
<ul><li><strong>Assignee</strong> changed from <i>4368</i> to <i>tnt</i></li></ul> OsmoBTS - Feature #1851: generalize power control and TA loop codehttps://osmocom.org/issues/1851?journal_id=129312018-12-12T22:04:20Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-3 priority-2 priority-default closed" href="/issues/1622">Bug #1622</a>: OsmoBTS power control incompliant to TS 05.08 and TS 08.58</i> added</li></ul> OsmoBTS - Feature #1851: generalize power control and TA loop codehttps://osmocom.org/issues/1851?journal_id=163002019-10-24T18:36:39Zlaforge
<ul><li><strong>Assignee</strong> changed from <i>tnt</i> to <i>pespin</i></li></ul> OsmoBTS - Feature #1851: generalize power control and TA loop codehttps://osmocom.org/issues/1851?journal_id=163022019-10-24T18:37:35Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-3 status-6 priority-3 priority-high3 closed" href="/issues/4213">Support #4213</a>: ms-power-control</i> added</li></ul> OsmoBTS - Feature #1851: generalize power control and TA loop codehttps://osmocom.org/issues/1851?journal_id=163062019-10-25T16:08:34Zpespin
<ul></ul><p>There's seems to be some kind of support in "common" dir with some overlapping with loops.c/.h in osmo-bts-trx.</p>
<p>There's src/common/power_ctrl.c implementing lchan_ms_pwr_ctrl(), which looks pretty similar to loops.c trx_loop_sacch_input() + ms_power_diff(). Function lchan_ms_pwr_ctrl() is used in l1sap.c upon receival of a SACCH block, similar to what's done in trx-scheduler.c for the bts-trx API counterparts.</p>
<p>There's no similar API to bts-trx trx_loop_sacch_clock (Called once every downlink SACCH block needs to be sent.) in common; l1sap.c sends directly lchan->ms_power_ctrl.current in l1sap_ph_rts_ind().</p>
<p>There's a common vty cmd "ms-power-control (dsp|osmo)" used by non bts-trx models, with values "dsp -> 0, osmo -> 1". By default it's not set, meaning DSP is in used (and power_ctrl.c does nothing). This function is used around to access whether to use it or not:<br /><pre>
int trx_ms_pwr_ctrl_is_osmo(struct gsm_bts_trx *trx)
{
return trx->ms_power_control == 1;
}
</pre></p>
So probably what's needed here:
<ul>
<li>Move loops.c different APIs to common/power_ctrl.c, and call them through l1sap. Check how to glue that though trx_scheduler.c (data should be passed in the primitives?)</li>
<li>loops.c APIs need to be cleaned of references to phy_link/instance from osmo-bts-trx, not sure how yet (adding APIs from different models?)</li>
<li>l1sap.c's l1sap_ph_rts_ind() probably needs to call trx_loop_sacch_clock() before using lchan->ms_power_ctrl.current.</li>
<li>lchan_ms_pwr_ctrl() may need a similar patch to this one done for loops.c: <a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/15877">https://gerrit.osmocom.org/c/osmo-bts/+/15877</a></li>
</ul> OsmoBTS - Feature #1851: generalize power control and TA loop codehttps://osmocom.org/issues/1851?journal_id=163092019-10-25T18:24:11Zlaforge
<ul></ul><p>On Fri, Oct 25, 2019 at 04:08:34PM +0000, pespin [REDMINE] wrote:</p>
<blockquote>
So probably what's needed here:
<ul>
<li>Move loops.c different APIs to common/power_ctrl.c, and call them through l1sap. Check how to glue that though trx_scheduler.c (data should be passed in the primitives?)</li>
</ul>
</blockquote>
<p>ACK.</p>
<blockquote>
<ul>
<li>loops.c APIs need to be cleaned of references to phy_link/instance from osmo-bts-trx, not sure how yet (adding APIs from different models?)</li>
</ul>
</blockquote>
<p>The question is what kind of model-specific APIs are needed? There's<br />nothing really PHY/model specific in power control loops - assuming that<br />we don't use an automatic mechanism in the DSP of sysmo/oc2g/...</p>
<p>Conceptually we receive uplink measurement values (which are processed<br />above l1sap anyway) and also receive indication of the acutal L1<br />transmit power by the MS (in uplink SACCH L1 header), and we send<br />instructions for the new transmit power level of the MS in the downlink<br />SACCH L1 header. Nothing bts/phy/backend specific here, AFAICT.</p>
<p>In any case, it seems like currently it's broken for osmo-bts-trx and<br />our users deserve a very fast fix of the existing code, before we spent<br />time on the generalization part.</p> OsmoBTS - Feature #1851: generalize power control and TA loop codehttps://osmocom.org/issues/1851?journal_id=163112019-10-28T10:53:53Zpespin
<ul></ul><p>laforge wrote:</p>
<blockquote>
<p>On Fri, Oct 25, 2019 at 04:08:34PM +0000, pespin [REDMINE] wrote:</p>
<blockquote>
So probably what's needed here:
<ul>
<li>Move loops.c different APIs to common/power_ctrl.c, and call them through l1sap. Check how to glue that though trx_scheduler.c (data should be passed in the primitives?)</li>
</ul>
</blockquote>
<p>ACK.</p>
<blockquote>
<ul>
<li>loops.c APIs need to be cleaned of references to phy_link/instance from osmo-bts-trx, not sure how yet (adding APIs from different models?)</li>
</ul>
</blockquote>
<p>The question is what kind of model-specific APIs are needed? There's<br />nothing really PHY/model specific in power control loops - assuming that<br />we don't use an automatic mechanism in the DSP of sysmo/oc2g/...</p>
</blockquote>
<p>The only bts-trx specific things I see in loops.c are parameters from the phy_link structure which are in bts-trx specific parts:<br />phy_link->u.osmotrx.trx_target_rssi (VTY "osmotrx ms-power-loop <-127-127>")<br />phy_link->u.osmotrx.trx_ms_power_loop (VTY "osmotrx ms-power-loop <-127-127>")<br />phy_link->u.osmotrx.trx_ta_loop (VTY "osmotrx timing-advance-loop")</p>
<p>So not sure how these parameters apply to bts-trx but not to other BTS?</p>
<blockquote>
<p>In any case, it seems like currently it's broken for osmo-bts-trx and<br />our users deserve a very fast fix of the existing code, before we spent<br />time on the generalization part.</p>
</blockquote>
<p>I'm looking now at what is broken exactly after my patch fixing TC_rsl_ms_pwr_dyn_max, any pointer welcome.</p> OsmoBTS - Feature #1851: generalize power control and TA loop codehttps://osmocom.org/issues/1851?journal_id=163162019-10-28T16:02:12Zpespin
<ul></ul>Some more similarities/differences with what we already have in common and in bts-trx:
<ul>
<li>common has VTY command "uplink-power-target <-110-0>" vs bts-trx has command "osmotrx ms-power-loop <-127-127>". AFAIU the first is in dBm while the second is in dB. So I guess we should have some kind of VTY cmd to set up some kind of calibration data used to convert from dB<->dBm and then use either dB or dBm in a generic algo? (I'm not sure if I'm saying nonsense here, please instruct me if that's the case).</li>
</ul> OsmoBTS - Feature #1851: generalize power control and TA loop codehttps://osmocom.org/issues/1851?journal_id=163172019-10-28T16:10:50Zpespin
<ul></ul><p>loops.c seems to be (roughly, partially) implementing some of the ideas from the algo explained in TS 05.08 Annex A.3 "BSS pre-processing and threshold comparisons", like having an array of 32 last values, while the common power_control.c code only uses last value to calculate new power level. Still I'm not sure why the bts-trx specific code gets the lowest value from the array instead of an average or a median from it... that probably makes MS to increase its transmission power over time if there are sporadic bad receivals.</p> OsmoBTS - Feature #1851: generalize power control and TA loop codehttps://osmocom.org/issues/1851?journal_id=163192019-10-28T20:52:11Zlaforge
<ul></ul><p>On Mon, Oct 28, 2019 at 04:02:12PM +0000, pespin [REDMINE] wrote:</p>
<blockquote>
<ul>
<li>common has VTY command "uplink-power-target <-110-0>" vs bts-trx has command "osmotrx ms-power-loop <-127-127>".</li>
</ul>
</blockquote>
<p>ACK, this is definitely duplication.</p>
<blockquote>
<p>AFAIU the first is in dBm while the second is in dB.</p>
</blockquote>
<p>This difference due to the fact that the PHY on non-TRX BTSs is<br />calibrated and we get absolute dBm values from the PHY.</p>
<p>The unit of osmo-bts-trx specific command must be dBFS, AFAICT. "dB" <br />always only defines a relative amount of power, think of it as a<br />"logarithmic percentage". Without giving an indication of what<br />corresponds to "100%", you cannot convert it to an absolute value.</p>
<blockquote>
<p>So I guess we should have some kind of VTY cmd to set up some kind of calibration data used to convert from dB<->dBm and then use either dB or dBm in a generic algo? (I'm not sure if I'm saying nonsense here, please instruct me if that's the case).</p>
</blockquote>
<p>The generic part with dBm is fine. Indeed, some kind of calibration<br />data is needed for the osmo-bts-trx setup. In the SC5 scenario, the TRX<br />reports calibrated absolute values in the TRXD protocol, so the dBm value<br />equals the dBFS value.</p>
<p>We could now either define that as "normal" and implement support for<br />calibration values/table in osmo-trx (and hence make it also report dBm<br />in TRXD). Or we could add that code to osmo-bts-trx and make it<br />optional, i.e. assume dBm == dBFS in the absence of calibration data.</p>
<p>In fact, reading trx_if.adoc, the TRXD protocol actually states that the<br />RSSI values <strong>are</strong> in dBm, so we can simply make that assumption in<br />osmo-bts-trx.</p> OsmoBTS - Feature #1851: generalize power control and TA loop codehttps://osmocom.org/issues/1851?journal_id=163212019-10-28T21:04:12Zlaforge
<ul></ul><p>Please note that a lot of processing happens already in the computation of uplink measurement<br />results. I always assumed that we could simply use those values as input, rather than<br />computing another set of values?</p>
<blockquote>
<p>[...] like having an array of 32 last values, while the common power_control.c code only uses last value to calculate new power level.</p>
</blockquote>
<p>Using only the last value is AFAIK what some of the proprietary PHYs we support do, and<br />it is known to generate oscillations due to the delays involved. At least some kind of simple<br />filter is required to avoid those oscillations, AFAICT.</p>
<blockquote>
<p>Still I'm not sure why the bts-trx specific code gets the lowest value from the array instead of an average or a median from it... that probably makes MS to increase its transmission power over time if there are sporadic bad receivals.</p>
</blockquote>
<p>I don't know the details of the algorithm, but you could try to reach out to jolly, the original author. Maybe he remembers his thoughts.</p> OsmoBTS - Feature #1851: generalize power control and TA loop codehttps://osmocom.org/issues/1851?journal_id=164262019-11-12T16:58:39Zpespin
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-3 priority-2 priority-default closed" href="/issues/4244">Bug #4244</a>: Take MS power class into account to calculate appropiate MS Power level</i> added</li></ul> OsmoBTS - Feature #1851: generalize power control and TA loop codehttps://osmocom.org/issues/1851?journal_id=164402019-11-13T12:28:38Zpespin
<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>20</i></li></ul><p>First bunch of commits cleaning up some variables and locations and unifying the VTY parameters used by both current algorithms (common and bts-trx).</p> OsmoBTS - Feature #1851: generalize power control and TA loop codehttps://osmocom.org/issues/1851?journal_id=164412019-11-13T12:31:29Zpespin
<ul></ul><p>remote: <a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/16058">https://gerrit.osmocom.org/c/osmo-bts/+/16058</a> Unify common and bts-trx power control loop VTY command<br />remote: <a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/16059">https://gerrit.osmocom.org/c/osmo-bts/+/16059</a> Change gsm_bts_trx field to bool and rename it<br />remote: <a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/16060">https://gerrit.osmocom.org/c/osmo-bts/+/16060</a> Change gsm_lchan field fixed to bool<br />remote: <a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/16061">https://gerrit.osmocom.org/c/osmo-bts/+/16061</a> rsl: Remove unneeded duplicate reset on some lchan fields<br />remote: <a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/16062">https://gerrit.osmocom.org/c/osmo-bts/+/16062</a> Move and rename gsm_lchan.ms_power field</p> OsmoBTS - Feature #1851: generalize power control and TA loop codehttps://osmocom.org/issues/1851?journal_id=164582019-11-14T16:55:32Zpespin
<ul></ul><p>More related work:</p>
<p>remote: New Changes:<br />remote: <a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/16068">https://gerrit.osmocom.org/c/osmo-bts/+/16068</a> cosmetic: Fix trailing whitespace<br />remote: <a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/16069">https://gerrit.osmocom.org/c/osmo-bts/+/16069</a> bts-trx: loops.c: Avoid always clamping MS power to MS power class 1<br />remote: <a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/16070">https://gerrit.osmocom.org/c/osmo-bts/+/16070</a> Apply latests improvements from loops.c to power_control.c<br />remote: <a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/16071">https://gerrit.osmocom.org/c/osmo-bts/+/16071</a> Introduce BTS feature BTS_FEAT_MS_PWR_CTRL_DSP<br />remote: <a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/16072">https://gerrit.osmocom.org/c/osmo-bts/+/16072</a> bts-trx: Drop low layer MS Power Control Loop algo<br />remote: <a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/16073">https://gerrit.osmocom.org/c/osmo-bts/+/16073</a> power_control.c: Log rx current and target signal levels<br />remote:<br />remote: Updated Changes:<br />remote: <a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/16059">https://gerrit.osmocom.org/c/osmo-bts/+/16059</a> Change gsm_bts_trx field to bool and rename it<br />remote: <a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/16060">https://gerrit.osmocom.org/c/osmo-bts/+/16060</a> Change gsm_lchan field fixed to bool<br />remote: <a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/16061">https://gerrit.osmocom.org/c/osmo-bts/+/16061</a> rsl: Remove unneeded duplicate reset on some lchan fields<br />remote: <a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/16062">https://gerrit.osmocom.org/c/osmo-bts/+/16062</a> Move and rename gsm_lchan.ms_power field</p> OsmoBTS - Feature #1851: generalize power control and TA loop codehttps://osmocom.org/issues/1851?journal_id=164902019-11-20T19:26:45Zpespin
<ul></ul><p>New changes for osmo-bts:<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/16141">https://gerrit.osmocom.org/c/osmo-bts/+/16141</a> power_control.c: Don't use announced MS Power level as input for loop ...<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/16142">https://gerrit.osmocom.org/c/osmo-bts/+/16142</a> power_control.c: Limit speed of announced MS Power Level value changes</p> OsmoBTS - Feature #1851: generalize power control and TA loop codehttps://osmocom.org/issues/1851?journal_id=169542019-12-23T16:00:07Zpespin
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Feedback</i></li><li><strong>% Done</strong> changed from <i>20</i> to <i>90</i></li></ul><p><a class="user active" href="https://osmocom.org/users/15">dexter</a> once comments for <a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/16233">https://gerrit.osmocom.org/c/osmo-bts/+/16233</a> are applied and it gets merged we can close this ticket.</p> OsmoBTS - Feature #1851: generalize power control and TA loop codehttps://osmocom.org/issues/1851?journal_id=171342020-01-09T16:06:00Zpespin
<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>