Bug #1622

OsmoBTS power control incompliant to TS 05.08 and TS 08.58

Added by laforge about 3 years ago. Updated 5 months ago.

Target version:
Start date:
Due date:
% Done:


Spec Reference:


The way how OsmoBTS interprets the A-bis RSL information elements regarding MS and BS power control is wrong.

For a description of the current behavior, see

Furthermore, even the actual power control loop is completely simplistic, results in oscillations and doesn't implement any of the configurable averaging as specified in TS 05.08.

What needs to be done is:
correctly parse and interpret the various MS / BS power related IEs on RSL
implement Annex A of TS 05.08 (measurement averaging, MS power control)

Related issues

Related to OsmoBTS - Feature #1851: generalize power control and TA loop codeNew2016-11-18


#2 Updated by laforge almost 2 years ago

#3 Updated by laforge 5 months ago

  • Assignee set to sysmocom
  • Priority changed from Normal to High

#4 Updated by laforge 5 months ago

  • Assignee changed from sysmocom to dexter

assigning to dexter

#5 Updated by laforge 5 months ago

  • Related to Feature #1851: generalize power control and TA loop code added

#6 Updated by laforge 5 months ago

See src/osmo-bts-trx/loops.c, where 'ms_power_diff()' computes
the difference between the MS receive power target value and store it in

Admittedly, loops.c is one of the parts of the osmo-bts code bases that are rather hard to read and of bad structure. See #1851 for another related issue to generalize and refactor those loops, particularly also across BTS models.

The code in src/common/l1sap.c:l1sap_ph_rts_ind() then patches this value
into the L1 header of every downlink SACCH block:
p0 = lchan->ms_power_ctrl.current

Since the function that sets the MS power level bts_model_adjst_ms_pwr() is
a stub. This function is called by power_control.c and by rsl.c when the
BSC wants to set the MS power level via an MS POWER CONTROL message.

Yes, but the very same function also changes lchan->ms_power_ctrl.current
before. As osmo-bts-trx automatically uses that value during every DL SACCH
transmission, I would actually expect it to work.

The explicit bts_model_adjst_ms_pwr() function is just required for proprietary
PHYs that have their own TDMA scheduler and maintain that state in the PHY,
where hence we have to actively tell the PHY that the MS power level has changed.

So the first step from my point of view is to implement tests for this in BTS_Tests.ttcn,
considering cases like:

  • MS POWER IE present in RSL CHAN ACT
  • MS POWER IE being sent using a "RSL MS POWER CONTROL" message for an already-active
    logicel channel

and then running those tests with OsmocomBB against osmo-bts-trx, osmo-bts-sysmo, etc.

From my reading of the code, the feature "static MS power control" is looking for should already work if the level is communicated via the RSL MS POWER CONTROL message, and not via the RSL CHANNEL ACTIVATE, as the former is setting lchan->ms_power_ctrl.fixed = 1 where the latter is setting it to 0. Having TTCN3 tests for this would allow us to ascertain this for sure and ensure it keeps working.

#7 Updated by dexter 5 months ago

There is now a TTCN3 test that sends RSL MS POWER CONTROL and simultaneously checks that the L1 header of the SACCH channel contains the expected power level. From what I can see so far in the tests the external power control should work fine.

See also:

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)