Cellular Network Infrastructure » Radio Access Network » OsmoBTS

see also: Timing_Advance

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;
}

• 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

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.

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

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.

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

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

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

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

dexter once comments for https://gerrit.osmocom.org/c/osmo-bts/+/16233 are applied and it gets merged we can close this ticket.

Merged, closing.