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
Avoid re-connecting to a new BSC while BTS is in shutting down. All the
FSMs are complex enough to even try to re-start when stopping has not
yet finished...
Change-Id: I1727828a16f4ec8043b00cc6b2e02a4c35f71377
This feature is not yet used by any bts_shutdown_fsm caller, but will be
used in the future when Abis link goes down.
Change-Id: I5dc282fdbcf862067be326e72b6183dd544222ae
Ramping down was set up with a target of -10 dBm, but then the code only
waited for all TRXs to be at least 0dBm, meaning that if operating more
than 1 TRX, the FSM could transit to state ST_WAIT_TRX_CLOSED when one
TRX reached -10 and other were already equal or below 0 (but not yet
-10). As a result, later on, when other TRXs reached -10 dBm they would
trigger EV_TRX_RAMP_COMPL which was not expected (no use) in
ST_WAIT_TRX_CLOSED.
Related: SYS#4864
Change-Id: If7af0b138efe78ec591c199a19fc22b304416a13
bts.h refers to struct gsm_bts object, but we still had a bunch of stuff
in bulky gsm_data.* from old days. Let's move stuff where it belongs to
start clean up of gsm_data.
Change-Id: I0a4219e3f64f625ee8b364bf408b8d2bcc8085c5
Setting the phy link of a trx to SHUTDOWN sets operative state to
DISABLED, so we use operative state as a condition to know whether all
TRX are already powered off properly and we can exit.
Change-Id: I2bcd211d7edcc8486461a555d6c470a94b166ed7
Some backends like osmo-bts-trx require exchanging messages like
POWEROFF to close the TRX, and hence need some time. Switch the function
to expect result asynchronously by calling a callback.
This will be used later to wait until all TRX are really powered off
before exiting the process.
Change-Id: I7d76b600fc06e1114b35bf0c2d08eff5bbd1b69a
It makes more sense to first deactive RF on all TRX and finally close
them totally. This way we keep consistency between all TRXs and it's
easier for lower layers which may need to close them all at once. Also
in the event that we want to turn bts_model_trx_deact_rf to return
asynchronously.
Change-Id: Ib62358384e37a5cef692926439462042fab0138c
Upon BTS shutdown (for instance because the Abis link against BSC was
lost), stop the operation in an ordered manner (cell soft lock). This
means slowly decrease tx power so that MS have time to handover to other
neighbour cells.
Related: SYS#4920
Change-Id: I70e34dda8974ebd94aea33bd9fb1d99f9063cc55
Using an FSM here will allow for more complex ordered shutdown
procedures, like power ramp down, waiting for TRX deact asyncrhonously,
etc.
Current commit leaves everything in place already prepared to implement
ramp down, which will be implemented in next commit in the series.
Related: SYS#4920
Change-Id: I8f48f17e61c3b9b86342eaf5b8a2b1ac9758bde5
Pau Espin