Project

General

Profile

Actions

Bug #1622

closed

OsmoBTS power control incompliant to TS 05.08 and TS 08.58

Added by laforge about 8 years ago. Updated over 4 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
02/23/2016
Due date:
% Done:

100%

Spec Reference:

Description

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 http://openbsc.osmocom.org/trac/wiki/GsmPowerControl

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)


Checklist

  • fix behavior on BSC side (always send MS power parameters in RSL CHAN ACT)
  • fix behavior on BTS side: autonomous UL power control ony if MS power parametrs IE was sent
  • TTCN3 tests for static MS power level in RSL CHAN ACT
  • TTCN3 tests for static MS power level in MS POWER CONTROL
  • TTCN3 test for autonomous MS power control after RSL CHAN ACT
  • TTCN3 test for autonomous MS power control after MS POWER CONTROL
  • Ensure the ms power level is actually interpreted as the maximum allowable power level if a ms power parameters IE is present

Related issues

Related to OsmoBTS - Feature #1851: generalize power control and TA loop codeResolvedpespin11/18/2016

Actions
Related to OsmoBTS - Feature #3750: Extension of BTS_Tests.ttcn test coverageResolved01/08/2019

Actions
Actions #2

Updated by laforge over 6 years ago

Actions #3

Updated by laforge over 5 years ago

  • Assignee set to 4368
  • Priority changed from Normal to High
Actions #4

Updated by laforge over 5 years ago

  • Assignee changed from 4368 to dexter

assigning to dexter

Actions #5

Updated by laforge over 5 years ago

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

Updated by laforge over 5 years 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
lchan->ms_power_ctrl.current.

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.

Actions #7

Updated by dexter about 5 years 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: https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/12391/

Actions #8

Updated by laforge almost 5 years ago

  • Related to Feature #3750: Extension of BTS_Tests.ttcn test coverage added
Actions #9

Updated by laforge almost 5 years ago

  • Assignee changed from dexter to laforge
Actions #10

Updated by laforge almost 5 years ago

  • Checklist item fix behavior on BSC side (always send MS power parameters in RSL CHAN ACT) added
  • Checklist item fix behavior on BTS side: autonomous UL power control ony if MS power parametrs IE was sent added
  • Checklist item TTCN3 tests for static MS power level in RSL CHAN ACT added
  • Checklist item TTCN3 tests for static MS power level in MS POWER CONTROL added
  • Checklist item TTCN3 test for autonomous MS power control after RSL CHAN ACT added
  • Checklist item TTCN3 test for autonomous MS power control after MS POWER CONTROL added
  • % Done changed from 0 to 20
In https://gerrit.osmocom.org/#/c/osmo-bts/+/14155/ I'm fixing teh logic/handling when the BSC sends an explicit "MS POWER CONTROL" message:
  • if the optional MS power parameters IE is present (we don't care about contents), the BTS performs MS power control autonomously
  • if the optional MS power parameters IE is absent, we switch to static MS power according to the MS Power IE.
Actions #11

Updated by Hoernchen almost 5 years ago

  • Checklist item TTCN3 tests for static MS power level in MS POWER CONTROL set to Done
Actions #12

Updated by Hoernchen almost 5 years ago

currently tested by TC_rsl_ms_pwr_ctrl

Actions #13

Updated by Hoernchen almost 5 years ago

  • Checklist item TTCN3 tests for static MS power level in RSL CHAN ACT set to Done
Actions #14

Updated by Hoernchen almost 5 years ago

Actions #15

Updated by Hoernchen almost 5 years ago

  • Checklist item Ensure the ms power level is actually interpreted as the maximum allowable power level if a ms power parameters IE is present added

As the spec states "If the MS Power Parameters element is present it indicates that the MS power control is to be performed by TRX. The MS Power element then indicates the maximum MS power to be used. "
This is currently not working at all, the loop will just ignore this maximum ms power.

Actions #16

Updated by Hoernchen almost 5 years ago

  • Checklist item TTCN3 test for autonomous MS power control after RSL CHAN ACT set to Done
  • Checklist item TTCN3 test for autonomous MS power control after MS POWER CONTROL set to Done
Actions #17

Updated by laforge over 4 years ago

  • Priority changed from High to Normal
Actions #18

Updated by pespin over 4 years ago

  • Checklist item Ensure the ms power level is actually interpreted as the maximum allowable power level if a ms power parameters IE is present set to Done

"Ensure the ms power level is actually interpreted as the maximum allowable power level if a ms power parameters IE is present added"
Fixed by:
https://gerrit.osmocom.org/c/osmo-bts/+/15877 bts-trx: loops.c: Take into account RSL CHAN ACT ms power level limits
https://gerrit.osmocom.org/c/osmo-bts/+/15884 power_control.c: Take into account RSL CHAN ACT ms power level limits

Actions #19

Updated by pespin over 4 years ago

If I understand correctly, current code already does this correctly:
"fix behavior on BTS side: autonomous UL power control ony if MS power parametrs IE was sent added"
It was fixed in https://gerrit.osmocom.org/#/c/osmo-bts/+/14155/
And same fix is also done during RSL CHAN ACT recevied in rsl_rx_chan_activ().

Actions #20

Updated by pespin over 4 years ago

Regarding "fix behavior on BSC side (always send MS power parameters in RSL CHAN ACT) added", it should be done here:
https://gerrit.osmocom.org/c/osmo-bsc/+/15882 rsl: Send IE MS Power Param during CHAN ACT and MS PWR CTRL messages

and tested here:
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/15881 bsc: Verify RSL IE MS Power Parameters is send upon CHAN ACT

so I think all boxes in the task should be marked as DONE and ticket closed.

Actions #21

Updated by laforge over 4 years ago

  • Assignee changed from laforge to pespin
Actions #22

Updated by pespin over 4 years ago

  • Checklist item fix behavior on BSC side (always send MS power parameters in RSL CHAN ACT) set to Done
  • Checklist item fix behavior on BTS side: autonomous UL power control ony if MS power parametrs IE was sent set to Done
  • Status changed from New to Resolved
  • % Done changed from 20 to 100
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)