It can happen when using several TRX that all of them go alreadyunder
shutdown target tx power level, but that due to configuration the BTS
still may want to keep pushing the tx power level even lower. Hence, we
end up in a situation where the FSM is trying to close all the TRX while the
power ramp procedure is ongoing for some of them. As a result, race
conditions can happen where for instance the power ramping procedure for
one TRX ends and calls the cb to send SETPOWER after the TRX PHY has
been closed (and hence TRXC link is unavaialble).
If that happens, the trx_if lower layers store the SETPOWER and attempt
a later retransmit, which may take up to 2 seconds after TRX becomes
active if BTS reconnects immediatelly.
Hence, we end up in some test cases where BTS reconnects and configures
some TRX while others are kep unconfigured for a while due to the
mentioned delay, hence the test attempting to use the TS while it hasn't
been yet configured.
The solution is to avoid this kind of unexpected events with ongoing
powe ramp once we have decided tx power is lower enough to shutdown the
TRX completely. Hence we abort the pending power ramp procedure.
Change-Id: Ibca581131eb142d7c38c917a0d6990efec03123c
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
See previous commit adding the unit test about the error description and
expected behavior.
The wrong behavior appeared due to step_size_mdB being unsigned and the
whole addition at the left side of the comparison being turned too as
unsigned, hence a small negative value turning into a big positive
value, and tpp->p_total_cur_mdBm not being updated to speed up the power
ramping.
Change-Id: I36a34362ebc90226fd8e1e190f898c3718fd923a
Until now, power-ramp max-initial was only taken into account in order
to skip ramping if the desired target level was below it, in order to
forbid growin too quickly or applying directly to much power given power
amplifier requirements.
However, in the event that a higher tx power level is desired,
max-initial was not taking into account and ramping simply started from
current tx power level, which could be a lot lower than max-initial.
Allow shortcutting the ramping in that case so that max-initial is
applied directly, and ramping continues from there, in order to have a
more expected behavior (max-initial applied the same).
Since max-initial can since a few commits before handle a negative
value, this means One can for instance set max-initial to -10 and still
keep the old behavior of ramping step by step from -10 (rf-locked in
osmo-bts-trx) to 0 or 7 or whatever is the nominal power
(max_power_red).
Change-Id: I4e5742ecdbf66d77ff9445999f6fff43bbf4856a
This allows for instance ramping up from -10 dBm -> -4 dBm if NOMTXPOWER
of SDR is really low (below 0dBm) or because the max_power_red is >=
NOMTXPOWER.
Related: SYS#4920
Change-Id: I0f27fb7b86b58c5a80f5342b66ff4f5d1b775498
Move all struct gsm_bts_trx references from bulky gsm_data to its own
file containing all related definitions and implementations. Also move a
few functions clearly related to that object which were placed in bts.*
Change-Id: Iebaf5b221c48b571f45408af867ce6f9c0cd9f4a
According to 3GPP TS 08.58, section 9.3.4, BS Power IE indicates
the transmission power attenuation on a particular channel:
+--------------+---------+-----------------+
| Reserved (3) | FPC (1) | Power level (4) |
+--------------+---------+-----------------+
so let's change handling of this IE as follows:
- s/bs_power/bs_power_red/g, so it reflects 'reduction';
- store power attenuation value in dB, not in 2 db steps;
- get rid of ms_power_ctrl.bts_tx_pwr, it's always 0 anyway;
- fix rsl_tx_meas_res(): use lchan->bs_power_red;
- always check if FPC (Fast Power Control) flag is set;
- we don't support it, so reject messages containing it;
- fix rsl_rx_chan_activ(): properly apply the bitmask.
Change-Id: I16cc50dfca102030380a06e16c234d5f6698f38f
In case a system has a high-gain external PA (like a 40dB PA) connected
externally, we cannot simply switch the transceiver to 0 dBm in
trx_init() only to then start the ramping at much lower levels once the
PHJ completes in trx_init_compl_cb(). The result would be a short
0 + 40 dBm spike followed by later ramping. We want to avoid that
spike, particularly its associated inrush current, so let's bring up the
board with smething very conservative like -50 dBm, and then ramp from
there.
Change-Id: I0ad91fce64f65e0213c9fcfde3390ace519055db
Fixes: SYS#3259
It seems more user friendly to look at a calibration table in terms of
the delta (positive or negative) compared to the nominal gain value,
rather than a collection of absolute gain values. It has the added
benefit that the (API/data model) user doesn't have to specify a gain
value for each ARFCN, but rather can rely on the default nominal gain in
absence of a calibration table for this specific unit.
Change-Id: I7311815902a88d2fc9d211cf4c62fa6fdc5e86ad
We use the completion call-back from L1 to compare the instructed
TRX board output power with the actual value as reported back from
L1.
Right now we only print an error message in case the values disagree.
In the future we might want to either use that value as part of our
calculation or send an OML alarm report to the BSC.
In order to support transmit power reduction by thermal management
as well as the variety of new internal / external PA configurations
of BTSs, we need a slightly more complex system.
Also, as at high power a single dB can be quite a big difference,
we are now doing all computations in milli-dB(m), i.e. 1/10000 bel.
Ramping is now used both for up and down ramping, as that is useful in
cases where you want to gracefully shut down a cell by shrinking its
radius, gradually handing over subscribers to neighboring cells.
Furthermore, this code is becoming part of the 'common' codebase, as it
is not really specific to how sysmobts is working.
The user can specify a single aggregate value for external system
gain/attenuation. Let's say you have 1dB loss of antenna cable, so you
can put that as 'user-gain -1' into the config, which means that a
'transmit power of 20dBm' will be compensatet for that and the TRX is
instructed to output 21dBm to compensate the cable loss. Similarly,
external PAs can be described by a positive user-gain.
One of the next steps will be to communicate those values and the
nominal power capability of the specific BTS to the BSC, so the BSC will
automatically show correct signal levels in the VTY and log files.
The code includes provisions for future extensions regarding
* an external and an internal PA with calibration tables
* a thermal attenuation setting to be controlled by the site manager
Pau Espin
Vadim Yanitskiy
Stefan Sperling
Harald Welte