We already have MS Power Control, which according to 3GPP 45.008
shall be implemented in the MS to minimize the transmit power in
the Uplink direction. The BS Power Control may optionally be
implemented by the network side for the same purpose.
Using Downlink signal measurements reported by the MS, the BSS
(either BSC, or BTS) may control Downlink attenuation in a way
that the transmit power remains as low as possible, or remains
in a specific range corresponding to good RxLev values on the
MS side. This change implements autonomous BS Power Control,
that can optionally be enabled by the BSC.
BS Power Control re-uses parts of the MS Power Control code,
so all parameters can be configured in the same way - via the
VTY interface or a configuration file. This basically means
that features like hysteresis and EWMA based filtering are
also available for BS Power Control.
The only difference is that RxQual values higher than 0 would
trigger the logic to reduce the current attenuation twice.
Note that one of the unit tests ('TC_rxlev_max_min') fails,
as the power step limitations for raising and lowering look
wrong to me, and the related discussion is still ongoing.
Change-Id: I5b509e71d5f668b6b8b2abf8053c27f2a7c78451
Related: SYS#4918
Similar to I3c07cb6e14acd5a988761bbc51a9c3b60fb22d87, this change
is another step towards separating the common delta calculation
logic from lchan_ms_pwr_ctrl(), since this function will loose
access to the averaged values.
On the one hand, the affected logging statements are getting
less precise; on the other, logging the averaged value as the
actual value ('rx-current') may be even more confusing.
Change-Id: I07007e45c859b4080fbbe520ffb5ccc0bb9c4244
Related: SYS#4918
This change would allow to separate the common logic from
lchan_ms_pwr_ctrl() and re-use it for Downlink power control.
The logging statement was quite useful during early stages
of development and testing of hysteresis and filtering,
but now we can sacrifice it.
Change-Id: I3c07cb6e14acd5a988761bbc51a9c3b60fb22d87
Related: SYS#4918
This way EWMA based filtering logic can be used not only for
MS Power Control, but also for BS Power Control.
Change-Id: I16c2e1b997f2b8af44d47809420293f072335bbd
Related: SYS#4918
This would allow to pass only two pointers:
- 'struct bts_power_ctrl_params', and
- 'struct lchan_power_ctrl_state',
and get rid of 'struct gsm_lchan' dependency. The later is
exactly where all state variables are supposed to be kept.
Change-Id: Idfefca30f4944bc722b4e9d8f1685eb77670a9db
Related: SYS#4918
Recently we've introduced EWMA based uplink power filtering, that
should reduce Uplink power oscillations. However, the power loop
is still quite sensitive to small deviations from the target power
level: even such an insignificant deviation like 2-5 dBm triggers
the loop to increase or decrease the MS power level. Even if the
EWMA based filtering is enabled with 80% smoothing (alpha = 0.2).
This change introduces a new configuration parameter - 'hysteresis':
uplink-power-target <-110-0> hysteresis <1-25>
that together with the 'uplink-power-target' defines a range:
[target - hysteresis .. target + hysteresis]
in which the MS power loop would not trigger any power changes.
This feature is now *enabled* by default, so given that:
- default 'uplink-power-target' is -75 dBm, and
- default 'hysteresis' is 3 dBm,
the default target Uplink power range is: -78 dBm ... -72 dBm.
Change-Id: Iacedbd4d69d3d74e2499af5622a07a8af0423da0
Related: SYS#4916
It makes no sense to do further calculations if the actual Uplink
signal strength equals the target value configured in the VTY.
Change-Id: Id99c7013a722403e773df8367b1a9d7a856e639b
Related: SYS#4916
So far the Uplink power control loop did not filter the Uplink RSSI
measurements (reported by the BTS) at all. The lack of filtering
makes our implementation too quick on the trigger, so in the real
deployments there will be unneeded Tx power oscillations.
In order to reduce this effect, let's implement a very simple EWMA
(also known as Single Pole IIR) filtering that is defined as follows:
Avg[n] = a * Pwr[n] + (1 - a) * Avg[n - 1]
where parameter 'a' determines how much weight of the latest UL RSSI
measurement result 'Pwr[n]' carries vs the weight of the average
'Avg[n - 1]'. The value of 'a' is usually a float in range 0 .. 1, so:
- value 0.5 gives equal weight to both 'Pwr[n]' and 'Avg[n - 1]';
- value 1.0 means no filtering at all (pass through);
- value 0.0 makes no sense.
This formula was further optimized with the use of '+=' operator.
The floating point math was also eliminated by scaling everything
up (by 100). For more details, see:
https://en.wikipedia.org/wiki/Moving_averagehttps://en.wikipedia.org/wiki/Low-pass_filter#Simple_infinite_impulse_response_filterhttps://tomroelandts.com/articles/low-pass-single-pole-iir-filter
The EWMA filtering is now *enabled by default*, but can be disabled
or (re-)configured over the VTY at any time:
! Completely disable filtering
no uplink-power-filtering
! Enable EWMA smoothing with the given parameters
uplink-power-filtering algo ewma beta <1-99>
Note that the VTY command expects 'beta' instead of 'alpha':
alpha = (100 - beta)
and the value must be in %. This is done for simplicity:
1% means lowest smoothing,
99% means highest smoothing.
Let's say we have EWMA filtering enabled with alpha = 0.4, and get
-98 dBm on the input, while the last output value was -60 dBm.
The new output would be:
Avg[n] = 0.4 * Pwr[n] + 0.6 * Avg[n - 1]
Avg[n] = (0.4 * -98) + (0.6 * -60)
Avg[n] = -75.2 => around -75
Of course, this is not a silver bullet, but better than nothing.
Change-Id: Ib6dcadbf14ef59696c6a546bd323bda92d399f17
Related: SYS#4916
Rename some variables so that:
* Variables containing power control levels end up with "_lvl".
* Variables containing power levels end up with _dbm.
* Move old current_dbm var to be ms_dbm, to match its power control
level counterpart ms_power_lvl, and add current_dbm to match its
counterpart ns_power_ctrl.current.
Now that variables are more clear, it also becomes clear that old "diff >
0" condition, apart from difficult, was currently wrong, since in order
to print the raise/low verb we want to compare between old and new
values, not between received and new values. Let's fix that in this same
commit.
Change-Id: I4e279a6b93fbcc5da25bf8c9213310939fd493ce
It's not a good idea to request big changes in MS Power based on
sporadic bad signal received, let's instead change announced MS power
levels more smoothly to avoid possible big signal strength fluctations,
similar to what is already done in osmo-bts-trx specific loop (loops.c).
Related: OS#1851
Change-Id: Iecc4ec7e21471ec853ad2d5659af4052aba5444c
Use instead the received MS Power currently in use by the MS matching
the measured signal. This way there's no need to wait for the MS to
reach the announced MS power level or add checks in case the MS doesn't
support that specific power level. Furthermore, more fine grained
announced power level value can be obtained faster due to more input
iterations not being dropped while waiting.
osmo-bts-trx specific algo was not following this approach and using
announced MS power instead because it's wowrking at a lower level and
henche was not using the transmitted MS Power level value by the MS as
input for the calculation.
The "if (diff < 2 && diff > -2))" condition is dropped since equal
signal strength may still result in a different MS power level announced
(the one currently used by the MS during tx of last SACCH block).
Related: OS#1851
Change-Id: I4494dc27a295a3dca1d3331d4ff712d486643e13
Several improvements have been made lately to MS Power Control loop from
osmo-bts-trx in loops.c. Let's port these to the common algorithm.
Related: OS#1851
Change-Id: I579967cc8bb69dc76a315c6c9d3a351f5961d92f
Make it clear that it contains the maximum MS power level (TS 05.05) and
not the one to be used. The one aimed at is in ms_power_ctrl.current.
Since it's used in related code, move it inside the ms_power_ctrl struct
too.
Related: OS#1851
Change-Id: Ib264ec7dac87355cef6415461ed74bd8e9c8ca52
This is similar commit to Ifda92155bd9c277ac150a327a7ab63c854087788,
which previously fixed same issue for osmo-bts-trx specific power
control loop code.
TS 48.058 sec 4.8 MS power control:
"""
TRX then attempts to keep the power control parameters within the limits
set by the MS POWER CONTROL message (or by the CHANNEL ACTIVATION message)
by changing the MS Power Level field of the L1 header sent to MS in each
SACCH block.
"""
Should fix TTCN3 BTS_Tests.TC_rsl_ms_pwr_dyn_max for non-bts-trx BTS
models.
Related: OS#1622
Change-Id: I376b52d7bee44132993a69cf532bd418171d0ca2
gsm_bts_role_bts was introduced at a time when we still shared
gsm_data_shared.[ch] between BSC and BTS, and where we then subsequently
needed a BTS-private structure. Since that sharing was abandoned quite
some time ago, we can merge gsm_bts_role_bts into gsm_bts and do away
with the bts/btsb dualism in a lot of the code.
Change-Id: I4fdd601ea873d9697f89a748cc77bcf7c978fa3e
It seems like rx previously had 'float' type. Remove the comments and
checks which are not relevant since rx is 'int'.
Change-Id: Idb4aad53667f88f9656c5bb1c52e7e75b385f446
Fixes: OS#2223
MS uplink power control is required in pretty much any BTS, and we
cannot assume that they PHY / L1 will always take care of it by
itself. So the correspondign code is moved to common/power_control.c
and called from the generic part of L1SAP.
The corresponding VTY paramter has been moved from the sysmobts-specific
trx VTY node to the common BTS VTY node.
Vadim Yanitskiy
Pau Espin
Harald Welte
Max