Project

General

Profile

Feature #1851

generalize power control and TA loop code

Added by laforge about 3 years ago. Updated 15 days ago.

Status:
In Progress
Priority:
Normal
Assignee:
Category:
osmo-bts-trx
Target version:
Start date:
11/18/2016
Due date:
% Done:

20%

Spec Reference:

Description

omso-bts-trx contains code for a power control and a TA loop. This code is not and should not be osmo-bts-trx specific but should be common code available to all BTS models.


Related issues

Related to OsmoBTS - Bug #2989: OsmoBTS reports ever-growing TA valueClosed02/23/2018

Related to OsmoBTS - Bug #3055: osmo-bts-trx: slow TA loop feedbackClosed03/10/2018

Related to OsmoBTS - Bug #1622: OsmoBTS power control incompliant to TS 05.08 and TS 08.58Resolved02/23/2016

Related to OsmoBTS - Support #4213: ms-power-controlFeedback09/23/2019

Related to OsmoBSC - Bug #4244: Take MS power class into account to calculate appropiate MS Power levelResolved10/30/2019

History

#1 Updated by laforge almost 3 years ago

#2 Updated by laforge over 2 years ago

#3 Updated by laforge over 2 years ago

  • Assignee set to sysmocom

#4 Updated by laforge almost 2 years ago

  • Related to Bug #2989: OsmoBTS reports ever-growing TA value added

#5 Updated by laforge over 1 year ago

  • Related to Bug #3055: osmo-bts-trx: slow TA loop feedback added

#6 Updated by laforge over 1 year ago

see also: Timing_Advance

#7 Updated by laforge about 1 year ago

  • Assignee changed from sysmocom to tnt

#8 Updated by laforge 12 months ago

  • Related to Bug #1622: OsmoBTS power control incompliant to TS 05.08 and TS 08.58 added

#9 Updated by laforge about 1 month ago

  • Assignee changed from tnt to pespin

#10 Updated by laforge about 1 month ago

#11 Updated by pespin about 1 month ago

There's seems to be some kind of support in "common" dir with some overlapping with loops.c/.h in osmo-bts-trx.

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.

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().

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:

int trx_ms_pwr_ctrl_is_osmo(struct gsm_bts_trx *trx)
{
    return trx->ms_power_control == 1;
}

So probably what's needed here:
  • 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?)
  • 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?)
  • l1sap.c's l1sap_ph_rts_ind() probably needs to call trx_loop_sacch_clock() before using lchan->ms_power_ctrl.current.
  • lchan_ms_pwr_ctrl() may need a similar patch to this one done for loops.c: https://gerrit.osmocom.org/c/osmo-bts/+/15877

#12 Updated by laforge about 1 month ago

On Fri, Oct 25, 2019 at 04:08:34PM +0000, pespin [REDMINE] wrote:

So probably what's needed here:
  • 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?)

ACK.

  • 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?)

The question is what kind of model-specific APIs are needed? There's
nothing really PHY/model specific in power control loops - assuming that
we don't use an automatic mechanism in the DSP of sysmo/oc2g/...

Conceptually we receive uplink measurement values (which are processed
above l1sap anyway) and also receive indication of the acutal L1
transmit power by the MS (in uplink SACCH L1 header), and we send
instructions for the new transmit power level of the MS in the downlink
SACCH L1 header. Nothing bts/phy/backend specific here, AFAICT.

In any case, it seems like currently it's broken for osmo-bts-trx and
our users deserve a very fast fix of the existing code, before we spent
time on the generalization part.

#13 Updated by pespin about 1 month ago

laforge wrote:

On Fri, Oct 25, 2019 at 04:08:34PM +0000, pespin [REDMINE] wrote:

So probably what's needed here:
  • 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?)

ACK.

  • 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?)

The question is what kind of model-specific APIs are needed? There's
nothing really PHY/model specific in power control loops - assuming that
we don't use an automatic mechanism in the DSP of sysmo/oc2g/...

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:
phy_link->u.osmotrx.trx_target_rssi (VTY "osmotrx ms-power-loop <-127-127>")
phy_link->u.osmotrx.trx_ms_power_loop (VTY "osmotrx ms-power-loop <-127-127>")
phy_link->u.osmotrx.trx_ta_loop (VTY "osmotrx timing-advance-loop")

So not sure how these parameters apply to bts-trx but not to other BTS?

In any case, it seems like currently it's broken for osmo-bts-trx and
our users deserve a very fast fix of the existing code, before we spent
time on the generalization part.

I'm looking now at what is broken exactly after my patch fixing TC_rsl_ms_pwr_dyn_max, any pointer welcome.

#14 Updated by pespin about 1 month ago

Some more similarities/differences with what we already have in common and in bts-trx:
  • 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).

#15 Updated by pespin about 1 month ago

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.

#16 Updated by laforge about 1 month ago

On Mon, Oct 28, 2019 at 04:02:12PM +0000, pespin [REDMINE] wrote:

  • common has VTY command "uplink-power-target <-110-0>" vs bts-trx has command "osmotrx ms-power-loop <-127-127>".

ACK, this is definitely duplication.

AFAIU the first is in dBm while the second is in dB.

This difference due to the fact that the PHY on non-TRX BTSs is
calibrated and we get absolute dBm values from the PHY.

The unit of osmo-bts-trx specific command must be dBFS, AFAICT. "dB"
always only defines a relative amount of power, think of it as a
"logarithmic percentage". Without giving an indication of what
corresponds to "100%", you cannot convert it to an absolute value.

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).

The generic part with dBm is fine. Indeed, some kind of calibration
data is needed for the osmo-bts-trx setup. In the SC5 scenario, the TRX
reports calibrated absolute values in the TRXD protocol, so the dBm value
equals the dBFS value.

We could now either define that as "normal" and implement support for
calibration values/table in osmo-trx (and hence make it also report dBm
in TRXD). Or we could add that code to osmo-bts-trx and make it
optional, i.e. assume dBm == dBFS in the absence of calibration data.

In fact, reading trx_if.adoc, the TRXD protocol actually states that the
RSSI values are in dBm, so we can simply make that assumption in
osmo-bts-trx.

#17 Updated by laforge about 1 month ago

Please note that a lot of processing happens already in the computation of uplink measurement
results. I always assumed that we could simply use those values as input, rather than
computing another set of values?

[...] like having an array of 32 last values, while the common power_control.c code only uses last value to calculate new power level.

Using only the last value is AFAIK what some of the proprietary PHYs we support do, and
it is known to generate oscillations due to the delays involved. At least some kind of simple
filter is required to avoid those oscillations, AFAICT.

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.

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.

#18 Updated by pespin 23 days ago

  • Related to Bug #4244: Take MS power class into account to calculate appropiate MS Power level added

#19 Updated by pespin 23 days ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 20

First bunch of commits cleaning up some variables and locations and unifying the VTY parameters used by both current algorithms (common and bts-trx).

#20 Updated by pespin 23 days ago

remote: https://gerrit.osmocom.org/c/osmo-bts/+/16058 Unify common and bts-trx power control loop VTY command
remote: https://gerrit.osmocom.org/c/osmo-bts/+/16059 Change gsm_bts_trx field to bool and rename it
remote: https://gerrit.osmocom.org/c/osmo-bts/+/16060 Change gsm_lchan field fixed to bool
remote: https://gerrit.osmocom.org/c/osmo-bts/+/16061 rsl: Remove unneeded duplicate reset on some lchan fields
remote: https://gerrit.osmocom.org/c/osmo-bts/+/16062 Move and rename gsm_lchan.ms_power field

#21 Updated by pespin 21 days ago

More related work:

remote: New Changes:
remote: https://gerrit.osmocom.org/c/osmo-bts/+/16068 cosmetic: Fix trailing whitespace
remote: https://gerrit.osmocom.org/c/osmo-bts/+/16069 bts-trx: loops.c: Avoid always clamping MS power to MS power class 1
remote: https://gerrit.osmocom.org/c/osmo-bts/+/16070 Apply latests improvements from loops.c to power_control.c
remote: https://gerrit.osmocom.org/c/osmo-bts/+/16071 Introduce BTS feature BTS_FEAT_MS_PWR_CTRL_DSP
remote: https://gerrit.osmocom.org/c/osmo-bts/+/16072 bts-trx: Drop low layer MS Power Control Loop algo
remote: https://gerrit.osmocom.org/c/osmo-bts/+/16073 power_control.c: Log rx current and target signal levels
remote:
remote: Updated Changes:
remote: https://gerrit.osmocom.org/c/osmo-bts/+/16059 Change gsm_bts_trx field to bool and rename it
remote: https://gerrit.osmocom.org/c/osmo-bts/+/16060 Change gsm_lchan field fixed to bool
remote: https://gerrit.osmocom.org/c/osmo-bts/+/16061 rsl: Remove unneeded duplicate reset on some lchan fields
remote: https://gerrit.osmocom.org/c/osmo-bts/+/16062 Move and rename gsm_lchan.ms_power field

#22 Updated by pespin 15 days ago

New changes for osmo-bts:
https://gerrit.osmocom.org/c/osmo-bts/+/16141 power_control.c: Don't use announced MS Power level as input for loop ...
https://gerrit.osmocom.org/c/osmo-bts/+/16142 power_control.c: Limit speed of announced MS Power Level value changes

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)