path: root/doc/manuals/chapters/power_control.adoc

== Power control

The objective of power control is to regulate the transmit power of the MS (Uplink)
as well as the BTS (Downlink) in order to achieve the optimal reception conditions,
i.e. a desired signal strength and a desired signal quality.

There are two advantages of power control:

- reduction of the average power consumption (especially in the MS), and
- reduction of the co-channel interference for adjacent channel users.

Power control can be performed either by the BSC, or by the BTS autonomously.
OsmoBSC currently lacks the power control logic, so it cannot act as the regulating
entity, however it's capable to instruct a BTS that supports autonomous power
control to perform the power regulation.  This is achieved by including vendor-
specific IEs with power control parameters in the channel activation messages
on the A-bis/RSL interface.

=== Power control parameters

Unfortunately, 3GPP specifications do not specify the exact list of power control
parameters and their encoding on the A-bis/RSL interface, so it's up to a BTS/BSC
vendor what to send and in which format.  Furthermore, there is no public
documentation on which parameters are accepted by particular BTS models.

3GPP TS 44.008 nonetheless defines a minimal set of parameters for a general power
control algorithm.  OsmoBSC allows to configure these parameters via the VTY
interface, this is further described in the next sections.

So far only the ip.access specific format is implemented, so it should be possible
to enable power control for nanoBTS.  OsmoBTS also accepts this format, but may
ignore some of the received parameters due to incomplete implementation.

==== When the parameters come into effect?

It depends on how the power control parameters are signaled to the BTS.  If a given
BTS vendor/model requires _each_ RSL CHANnel ACTIVation message to contain the full
set of parameters, then changing them in the BSC at run-time would affect all newly
established logical channels immediately.  The existing connections would continue
to use parameters which were in use during the time of channel activation.

For both ip.access nanoBTS and OsmoBTS, the configured parameters are being sent
only once when the A-bis/RSL link is established.  In all subsequent RSL messages,
the MS/BS Power Parameters IE will be sent empty.  Therefore, changing most of
dynamic power control parameters at run-time would affect neither the existing
nor newly established logical channels.

It's still possible to "push" a modified set of MS/BS power control parameters to a
BTS that accepts the default parameters at startup without triggering the A-bis/RSL
link re-establishment and thus interrupting the service.  The following command
triggers resending of both MS/BS power control parameters:

----
# Resending from the 'enable' node:
OsmoBSC# bts 0 resend-power-control-defaults

# Resending from any configuration node (note prefix 'do'):
OsmoBSC(config-ms-power-ctrl)# do bts 0 resend-power-control-defaults
----

NOTE: The above statement mostly applies to parameters for dynamic power control
mode (see below).  Switching between power control modes, as well as changing
static/maximum power values, does not necessarily require resending of parameters.

=== Power control configuration

Two identical groups of parameters are available for both MS (Uplink) and BS
(Downlink) power control.  This chapter is aimed to put some light on them.

All parameters can be set via the VTY interface, currently within the scope of
a BTS node.  This means that all transceivers will "inherit" the same configuration.

----
OsmoBSC(config)# network
OsmoBSC(config-net)# bts 0
OsmoBSC(config-net-bts)# ?
...
  bs-power-control              BS (Downlink) power control parameters
  ms-power-control              MS (Uplink) power control parameters
...
----

Either of these commands would lead to a separate node:

----
OsmoBSC(config-net-bts)# ms-power-control
OsmoBSC(config-ms-power-ctrl)# list with-flags
...
  . l.  mode (static|dyn-bts) [reset]
  . l.  bs-power (static|dyn-max) <0-30>
  . lv  ctrl-interval <0-31>
  . lv  step-size inc <2-6> red <2-4>
  . lv  rxlev-thresh lower <0-63> upper <0-63>
  . lv  rxqual-thresh lower <0-7> upper <0-7>
  . lv  rxlev-thresh-comp lower <0-31> <0-31> upper <0-31> <0-31>
  . lv  rxqual-thresh-comp lower <0-31> <0-31> upper <0-31> <0-31>
  . lv  no (rxlev-avg|rxqual-avg)
  . lv  (rxlev-avg|rxqual-avg) params hreqave <1-31> hreqt <1-31>
  . lv  (rxlev-avg|rxqual-avg) algo (unweighted|weighted|mod-median)
  . lv  (rxlev-avg|rxqual-avg) algo osmo-ewma beta <1-99>
----

NOTE: Flag `v` indicates that a given parameter is vendor specific, so different
BTS vendors/models may ignore or even reject it.  Flag `l` indicates that changing
a given parameter at run-time would affect only the new connections.

==== Power control mode

Three power control modes exist:

----
OsmoBSC(config-ms-power-ctrl)# mode ?
  static   Instruct the MS/BTS to use a static power level <1>
  dyn-bts  Power control to be performed dynamically by the BTS itself <2>
OsmoBSC(config-net-bts)# no (bs-power-control|ms-power-control) <3>
----
<1> Send RSL MS/BS Power IE alone indicating a static power level to the BTS.
<2> Send both RSL MS/BS Power IE and vendor-specific MS/BS Power Parameters IE.
<3> Do not send any power control IEs in RSL CHANnel ACTIVation messages.

By default, `static` mode is used for BS power control, while `dyn-bts` mode is
automatically enabled for MS power control if vendor-specific format of the power
control parameters (see above) is implemented for particular BTS model.  Otherwise
`static` mode is used too.  Changing the mode at run-time would not affect already
established connections, only the new ones (check flag `l`).

For BS power control, there is an additional parameter:

----
OsmoBSC(config-bs-power-ctrl)# bs-power ?
  static   Fixed BS Power reduction value (for static mode)
  dyn-max  Maximum BS Power reduction value (for dynamic mode)
----

that allows to configure the maximum BS power reduction value in `dyn-bts` mode,
and a fixed power reduction value in `static` mode.  In the later case, no
attenuation (0 dB) is applied by default (full power).

==== Power control interval

Having requested a transmit power level, the MS/BS power control loop may optionally
by suspended for a certain number of SACCH multiframes defined by VTY parameter
`ctrl-interval`.  Given that SACCH is relatively slow and transmission of a data block
takes 480 ms, suspension allows an observation of the effect of one power control
decision before initiating the next one.

----
OsmoBSC(config-bs-power-ctrl)# ctrl-interval ?
  <0-31>  P_CON_INTERVAL, in units of 2 SACCH periods (0.96 seconds)
----

By default, the suspension interval is set to 0 for both MS/BS power control loops,
therefore the power control decision is taken every 480 ms (one SACCH block period).
Setting `ctrl-interval` to 1 increases the interval to 960 ms, so basically every
second Uplink SACCH block is skipped;  value 2 corresponds to the interval of
1920 ms, so 3/4 received SACCH blocks are skipped.

3GPP TS 45.008 briefly mentiones this parameter in table A.1 (P_Con_INTERVAL).

==== Power change step size

In order to slow down the reactivity of the power control loop and thus make it more
robust against sporadic fluctuations of the input values (RxLev and RxQual), the
transmit power on both Uplink and Downlink is changed gradually, step by step.

OsmoBSC allows to configure the step sizes for both increasing and reducing directions
separately.  The corresponding power control loop would apply different delta values
to the current transmit power level in order to raise or lower it.

.Example: Power change step size
----
network
 bts 0
  bs-power-control
   mode dyn-bts <1>
   bs-power dyn-max 12 <2>
   step-size inc 6 red 4 <3>
  ms-power-control
   mode dyn-bts <1>
   step-size inc 4 red 2 <4>
----
<1> Both MS and BS power control is to be performed by the BTS autonomously.
<2> The BTS is allowed to reduce the power on Downlink up to 12 dB.
<3> On Downlink, BS power can be increased by 6 dB or reduced by 4 dB at once.
<4> On Uplink, MS power can be increased by 4 dB or reduced by 2 dB at once.

NOTE: In the context of BS power control, terms 'increase' and 'decrease' have the
same meaning as in the context of MS power control: to make the output power stronger
or weaker respectively.  Even despite the BS power loop in fact controls the attenuation.

TIP: It's recommended to pick the values in a way that the increase step is greater than
the reduce step.  This way the system would be able to react on signal degradation
quickly, while a good signal would not trigger radical power reduction.

Both parameters are mentioned in 3GPP TS 45.008, table A.1:

- Pow_Incr_Step_Size (range 2, 4 or 6 dB),
- Pow_Red_Step_Size (range 2 or 4 dB).

==== RxLev and RxQual thresholds

The general idea of power control is to maintain the signal level (RxLev) and quality
(RxQual) within the target ranges.  Each of these ranges can be defined as a pair of
the lowest and the highest acceptable values called thresholds.

The process of RxLev / RxQual threshold comparison is described in 3GPP TS 45.008,
section A.3.2.1.  All parameters involved in the process can be found in table
A.1 with the recommended default values.

.Example: RxLev and RxQual threshold configuration
----
network
 bts 0
  bs-power-control
   mode dyn-bts <1>
   rxlev-thresh lower 32 upper 38 <2>
   rxqual-thresh lower 3 upper 0 <3>
----
<1> BS power control is to be performed by the BTS autonomously.
<2> RxLev is to be maintained in range 32 .. 38 (-78 .. -72 dBm).
<3> RxQual is to be maintained in range 3 .. 0 (less is better).

NOTE: For both RxLev and RxQual thresholds, the lower and upper values are included
in the tolerance window.  In the example above, RxQual=3 would not trigger the
control loop to increase BS power, as well as RxLev=38 (-72 dBm) would not trigger
power reduction.

TIP: It's recommended to harmonize the increase step size with the RxLev threshold
window in a way that the former is less or equal than/to the later.  For example,
if the RxLev threshold is 32 .. 36 (-78 .. -74 dBm), then the window size is 4 dB,
and thus the increase step should be less or equal (e.g. 2 or 4 dB).

In 3GPP TS 45.008, lower and upper RxLev thresholds are referred as `L_RXLEV_XX_P`
and `U_RXLEV_XX_P`, while the RxQual thresholds are referred as `L_RXQUAL_XX_P` and
`U_RXQUAL_XX_P`, where the `XX` is either `DL` (Downlink) or `UL` (Uplink).

The process of threshold comparison actually involves more than just upper and lower
values for RxLev and RxQual.  The received "raw" measurements are being averaged and
stored in a circular buffer, so the power change is triggered only if Pn averages out
of Nn averages exceed the corresponding thresholds.

.Example: RxLev and RxQual threshold comparators
----
network
 bts 0
  bs-power-control
   mode dyn-bts <1>
   rxlev-thresh lower 32 upper 38
   rxlev-thresh-comp lower 10 12 <2> upper 19 20 <3>
   rxqual-thresh lower 3 upper 0
   rxqual-thresh-comp lower 5 7 <4> upper 15 18 <5>
----
<1> BS power control is to be performed by the BTS autonomously.
<2> P1=10 out of N1=12 averages < L_RXLEV_XX_P => increase power.
<3> P2=19 out of N2=20 averages > U_RXLEV_XX_P => decrease power.
<4>  P3=5 out of  N3=7 averages > L_RXQUAL_XX_P => increase power.
<5> P4=15 out of N4=18 averages < U_RXQUAL_XX_P => decrease power.

==== Measurement averaging process

3GPP 45.008, section A.3.1 requires that the measurement values reported by both
an MS and the BTS are being pre-processed before appearing on the input of the
corresponding power control loops in any of the following ways:

- Unweighted average;
- Weighted average, with the weightings determined by O\&M;
- Modified median calculation, with exceptionally high and low values
  (outliers) removed before the median calculation.

The pre-processing is expected to be performed by both MS and BS power control
loops independently, for every input parameter (i.e. RxLev and RxQual).

----
OsmoBSC(config-bs-power-ctrl)# rxlev-avg algo ?
  unweighted  Un-weighted average
  weighted    Weighted average
  mod-median  Modified median calculation
  osmo-ewma   Exponentially Weighted Moving Average (EWMA)
OsmoBSC(config-bs-power-ctrl)# rxqual-avg algo ?
  unweighted  Un-weighted average
  weighted    Weighted average
  mod-median  Modified median calculation
  osmo-ewma   Exponentially Weighted Moving Average (EWMA)
----

OsmoBTS features a non-standard Osmocom specific EWMA (Exponentially Weighted Moving
Average) based pre-processing.  Other BTS models may support additional non-standard
methods too, the corresponding VTY options can be added on request.

Among with the averaging methods, 3GPP 45.008 also defines two pre-processing
parameters in section A.3.1:

- Hreqave - defines the period over which an average is produced, in terms of the
  number of SACCH blocks containing measurement results, i.e. the number of
  measurements contributing to each averaged measurement;

- Hreqt - is the number of averaged results that are maintained.

By default, OsmoBSC would not send any pre-processing parameters, so the BTS may
apply its default pre-processing algorithm with default parameters, or may not
apply any pre-processing at all - this is up to the vendor.  The pre-processing
parameters need to be configured explicitly as shown in the example below.

.Example: Explicit pre-processing configuration
----
network
 bts 0
  bs-power-control
   mode dyn-bts <1>
   rxlev-avg algo unweighted <2>
   rxlev-avg params hreqave 4 hreqt 6 <3>
   rxqual-avg algo osmo-ewma beta 50 <4>
   rxqual-avg params hreqave 2 hreqt 3 <5>
  ms-power-control
   mode dyn-bts <1>
   rxlev-avg algo unweighted <2>
   rxlev-avg params hreqave 4 hreqt 6 <3>
   rxqual-avg algo osmo-ewma beta 50 <4>
   rxqual-avg params hreqave 2 hreqt 3 <5>
----
<1> Both MS and BS power control is to be performed by the BTS autonomously.
<2> Unweighted average is applied to RxLev values.
<3> RxLev: Hreqave and Hreqt values: 4 out of 6 SACCH blocks produce an averaged measurement.
<4> Osmocom specific EWMA is applied to RxQual values with smoothing factor = 50% (beta=0.5).
<5> RxQual: Hreqave and Hreqt values: 2 out of 3 SACCH blocks produce an averaged measurement.

// TODO: Document other power control parameters:
//		OsmoBSC(config-net-bts)# ms max power <0-40>
//		OsmoBSC(config-net-bts-trx)# max_power_red <0-100>

=== BCCH carrier power reduction operation

According to 3GPP TS 45.008, section 7.1, the BCCH carrier (sometimes called C0) of
a BTS shall maintain continuous Downlink transmission at full power in order to
stay "visible" to the mobile stations.  Because of that, early versions of this 3GPP
document prohibited BS power reduction on C0.  However, a new feature was introduced
in version 13.0.0 (2015-11) - "BCCH carrier power reduction operation".

This is a special mode of operation, in which the variation of RF power level for
some timeslots is relaxed for the purpose of energy saving.  In other words, the
output power on some timeslots, except the timeslot(s) carrying BCCH/CCCH, can be
lower than the full power.  In this case the maximum allowed difference is 6 dB.

Of course, energy saving comes at a price and has impacts to the network KPI.  In
particular, it does negatively affect cell reselection performance and does increase
handover failure and call drop rates.  This is why BCCH carrier power reduction
operation mode is not enabled by default.  More information on potential impact
and the simulation results can be found in 3GPP TR 45.926.

==== Supported BTS models

At the time of writing this manual, the only BTS model that can be instructed to
enter or leave the BCCH power reduction mode is osmo-bts-trx.  Support for other
BTS vendors/models may be added in the future.

TIP: If you're using OsmoBTS, make sure that it reports feature #021 "BCCH carrier
power reduction mode" in the feature vector.  This can be checked by issuing
`show bts` command in OsmoBSC's VTY interface.

==== Managing BCCH carrier power reduction

The BCCH carrier power reduction can be controlled via the CTRL and VTY interfaces.
There is currently no logic in OsmoBSC for automatic activation and deactivation
of this mode, so it's up to the network operator (or an external monitoring suite)
when and depending on which factors to toggle it.  Setting a value greater than
zero enables the BCCH power reduction mode;  setting zero disables it completely.

.Example: Activating BCCH carrier power reduction via the VTY
----
OsmoBSC> enable
OsmoBSC# bts 0 <1> c0-power-reduction ?
  <0-6>  Power reduction value (in dB, even numbers only)
OsmoBSC# bts 0 <1> c0-power-reduction 4 <2>
----
<1> BTS number for which to activate BCCH carrier power reduction
<2> Maximum BCCH carrier power reduction (in 2 dB steps, 4 dB in this example)

.Example: Activating BCCH carrier power reduction via the CTRL
----
$ osmo_ctrl.py \
	--host 127.0.0.1 <1> -p 4249 \
	--set "bts.0.c0-power-reduction" 4 <2>
----
<1> Remote address of the host running osmo-bsc (localhost in this example)
<2> Maximum BCCH carrier power reduction (in 2 dB steps, 4 dB in this example)

Once activated, it's possible to introspect the current maximum reduction value:

.Example: Checking BCCH carrier power reduction state via the VTY
----
OsmoBSC> enable
OsmoBSC# show bts 0 <1>
BTS 0 is of osmo-bts type in band DCS1800, has CI 0 LAC 1, BSIC 63 (NCC=7, BCC=7) and 2 TRX
  Description: (null)
  ARFCNs: 751 753
  BCCH carrier power reduction (maximum): 4 dB <2>
  ...
----
<1> BTS number for which to show BCCH carrier power reduction state
<2> Maximum BCCH carrier power reduction currently applied

.Example: Checking BCCH carrier power reduction state via the CTRL
----
$ osmo_ctrl.py \
	--host 127.0.0.1 <1> -p 4249 \
	--get "bts.0.c0-power-reduction"
Got message: b'GET_REPLY 3652121201381481804 bts.0.c0-power-reduction 4 <2>'
----
<1> Remote address of the host running osmo-bsc (localhost in this example)
<2> Maximum BCCH carrier power reduction currently applied