Age | Commit message (Collapse) | Author | Files | Lines |
|
intervals
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
|
|
If TRX is administratively locked during startup, for TS conigured as
TCH/F_PDCH the BSC will send a ACT PDCH message, but osmo-bts-trx won't
apply it by signalling it as available to the PCU, since the TRX is
locked.
That means the ts->flags contains the pending action to activate
it until it is unlocked. As a result, calling trx_set_ts() on it was
hitting the assert inside which expects not to apply the TS until it has
been confirmed by the PCU.
Let's still skip setting the TS and let pcu_tx_info_ind() trigger the
activation confirmation from PCU, since the TRX has just been unlocked.
Fixes following assert:
Assert failed (ts->flags & TS_F_PDCH_PENDING_MASK) == 0 /osmo-bts/src/osmo-bts-trx/l1_if.c:34
Change-Id: Ie3cad15d31870346d03a6e2f6dd32a9d2dd3067e
|
|
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
|
|
Fix power ramping if administrative state changes while previous
opposite change was already ACKED but power ramping was still ongoing.
With previous code, osmo-bts-trx would have sent a NACK and BSc would
drop the BTs link as a result.
Change-Id: I6c5240710ef6d223651dfb4a8db939b5d2f974ca
|
|
Let's handle it in common code to simplify and avoid duplication in
model specific code.
Change-Id: Icea3ea1108d360193cac478f366be97ff38246d4
|
|
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
|
|
They were both half implemented but named differently, due to myself
adding them during the initial FSM implementation. This prevents
osmo-bts-trx sending a POWEROFF when OML link is dropped.
Related: SYS#4864
Change-Id: Ic2dab864b6d4075dfb9a1e4acfd9af013c9c46fe
|
|
How to reproduce:
* Configure a TS to be TCH/F_TCH/H_PDCH in osmo-bsc.cfg
* Run the network with osmo-bts-trx, then use osmo-bsc's "rf_locked 1"
* Then, unlock it: "rf_locked 0"
* The following assert will be hit:
Assert failed ts->dyn.pchan_is == ts->dyn.pchan_want /osmo-bts/src/osmo-bts-trx/l1_if.c:349
"""
(gdb) bt
#0 0x00007ffff5bb9355 in raise () from /usr/lib/libc.so.6
#1 0x00007ffff5ba2853 in abort () from /usr/lib/libc.so.6
#2 0x00007ffff6832361 in osmo_panic_default (
fmt=0x555555814e60 "Assert failed %s %s:%d\n", args=0x7fffffffc6e0)
at /libosmocore/src/panic.c:49
#3 0x00007ffff683249d in osmo_panic (
fmt=0x555555814e60 "Assert failed %s %s:%d\n")
at /libosmocore/src/panic.c:84
#4 0x000055555570fdf7 in trx_set_ts (ts=0x7ffff1e6bce8)
at /osmo-bts/src/osmo-bts-trx/l1_if.c:349
#5 0x00005555557133c1 in bts_model_chg_adm_state (bts=0x627000000160,
mo=0x7ffff1e0f8a0, obj=0x7ffff1e0f860, adm_state=2 '\002')
at /osmo-bts/src/osmo-bts-trx/l1_if.c:681
#6 0x0000555555769978 in oml_rx_chg_adm_state (bts=0x627000000160,
msg=0x633000003e00)
at /osmo-bts/src/common/oml.c:1044
#7 0x000055555576a8d3 in down_fom (bts=0x627000000160, msg=0x633000003e00)
at /osmo-bts/src/common/oml.c:1129
#8 0x0000555555770aed in down_oml (bts=0x627000000160, msg=0x633000003e00)
at /osmo-bts/src/common/oml.c:1476
#9 0x00005555557f8174 in sign_link_cb (msg=0x633000003e00)
at /osmo-bts/src/common/abis.c:188
#10 0x00007ffff73b5935 in ipaccess_bts_read_cb (link=0x6120000030a0,
--Type <RET> for more, q to quit, c to continue without paging--
msg=0x633000003e00)
at /libosmo-abis/src/input/ipaccess.c:980
#11 0x00007ffff73a1060 in ipa_client_read (link=0x6120000030a0)
at /libosmo-abis/src/input/ipa.c:72
#12 0x00007ffff73a2458 in ipa_client_fd_cb (ofd=0x62f000038a50, what=1)
at /libosmo-abis/src/input/ipa.c:136
#13 0x00007ffff67ebfa7 in osmo_fd_disp_fds (_rset=0x7fffffffdda0,
_wset=0x7fffffffde40, _eset=0x7fffffffdee0)
at /libosmocore/src/select.c:227
#14 0x00007ffff67ec38c in _osmo_select_main (polling=0)
at /libosmocore/src/select.c:265
#15 0x00007ffff67ec46b in osmo_select_main (polling=0)
at /libosmocore/src/select.c:274
#16 0x00005555557ef089 in bts_main (argc=7, argv=0x7fffffffe208)
at /osmo-bts/src/common/main.c:354
#17 0x00005555556fe621 in main (argc=7, argv=0x7fffffffe208)
at /osmo-bts/src/osmo-bts-trx/main.c:176
"""
Related: OS#4920
Change-Id: Ia3210e24b921fd0c67f77068b7ef4a65f270cd11
|
|
Change-Id: I42b7a79b85e8750a12166dbfc66ad06f7cb713a6
|
|
Waiting until all other TRX are provisioned before really sending
POWERON helps avoiding race conditions where TRX!=0 are not yet fully
configured at the TRX side before POWERON is called.
This solves for instance the situation where after POWERON RSP the BTS
started ramping up on all TRX while on some NOMTXPOWER RSP was yet not
received...
Related: SYS#4920
Change-Id: I906be4714807c7a2793971cb6062120e24337d7b
|
|
The state of each config required is now tracked through the "acked"
variables, this way the FSM can know when all configs are confirmed by
the TRX and can proceed to submit POWERON command.
With this version each TRX is still totally independent (there's an FSM
per TRX), which means POWERON can be sent on TRX0 before TRX!=0 are
fully configured. As a result, powe ramping may start before we know the
NOMTXPOWER of a TRX. This kind of issue will be fixed in next commit.
Related: SYS#4920
Change-Id: I1b736a4be5ce52a854f5767d8609153e1f4c08d9
|
|
Change-Id: Icb1b7bd8852417ab7b9a7dbc205aa6f6db97d64d
|
|
With prior code state managing the TRXC side of osmo-bts-trx, there are
plenty o cases (race conditions) where things can go wrong/unexpected,
because there's really no infrastructure to wait and synchronize between
different TRXs (eg wait until all are configured to POWERON), or to
simply keep well known per-trx state regarding lower layers.
In order to fix in the future all of those issues and to sanitize
current code, a new per-trx FSM is introduced, which takes care of
submitting TRXC commands and waiting for response when needed to manage
the state of the TRX.
Related: OS#4364
Change-Id: I2a00c23df15840e33fbb232c9e1dd6db128f63f6
|
|
Change-Id: I509fdbc7883f227cef4b7e46cb68fa2418c63f97
|
|
the RSL link has nothing to do regarding the state of the Radio Carrier,
as in it being up is not enough to have a working (enabled) Radio
Carrier.
Change-Id: Iefb5c4e1097233b5c31e4d621c544d51516af678
|
|
At that time we schedule a POWERON command towards osmo-trx, so let the
callback of RSP POWERON set the OPSTATE in l1if_poweronoff_cb rather
than setting it without waiting for confirmation from osmo-trx.
Change-Id: Ib36a073cae5e1522821a04d8806648562f4e0f5b
|
|
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
|
|
Be consistent and use everywhere uint64_t.
Change-Id: Id6b5df7f5045901109fe1007a5ad54e2f95b95f8
|
|
GSMTAP_CHANNEL_UNKNOWN
commit d211c490cad38f2009943121d57bdb7df8eee9b0 avoided sending
GSMTAP packets on the virtual Um interface with type
GSMTAP_CHANNEL_UNKNOWN by relying on gsmtap_makemsg returning NULL.
But that's not the corect approach since it's totally fine to be sending
GSMTAP_CHANNEL_UNKNOWN on some GSMTAP cases (for instance when the
program fails to infer the type when decoding a message), since then
this way one can study pcap files and find the offending encoded
messages which failed to be decoded.
This patch goes togehter with revert patch introduced in libosmocore as
explained in the commit referred above.
Change-Id: I233afd930d3e43f7b120d40192c7c192102e38d9
|
|
LOGPLCHAN() prepends the BTS/TRX/TS numbers itself.
Change-Id: I8a1dd7da7098fe8c8a015459608d9134821fb322
|
|
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
|
|
Change-Id: I57ea9c4ddbe5443b9b6afe3f8e6b38170d0e5a0e
|
|
Change-Id: I21fa1688a0c8a3788a5ecedd5912f596a69a1beb
|
|
Ramp down when BTS is administratevly locked, and ramp up when it
becomes unlocked again.
Af ramping down, bts_model_trx_deact_rf is called to make sure all
channels are released.
power_ramp_start() is dropped from inside bts_model_trx_deact_rf since
it's not the proper place. In there we simply want to instantaneously
drop RF.
Related: SYS#4920
Change-Id: Ib7a7b0a0c24779349f142215f0bb32b72c86ce70
|
|
Change-Id: I4b24faf3a8fe5846b9394fea8faf9d37cc0ac9ff
|
|
This change avoids waiting for full ramp down if TRXs are already non
operational.
Change-Id: Ie1c7c3a969e7968075b89edcd1ab2227b178a869
|
|
This should provide a quick way to check if the system is frequently
overloaded over time and hence downlink FNs are scheduled later than
expected.
Change-Id: I0051b9ab18ebc9f92db11374d856de94f155efa4
|
|
I believe the modern compilers are smart enough to optimize the
outer (per-timeslot) loop of trx_sched_fn() in a way that TDMA
frame number is advanced after making sure that a transceiver
is powered on. However, it's still more perspicuous to check
availability of a given transceiver first.
Change-Id: I6a97000c1c84e36096e9ba378a489c82caa4cc5b
|
|
Change-Id: Ieac26c7aca118c16889cdde2565a514681dc137b
Related: OS#4546
|
|
Related: OS#4583
Change-Id: I88d59d47837105d52e2b4dfb819511cd360c50a1
|
|
According to 3GPP 45.002, section 5.2.4, a frequency correction
burst is basically a sequence of zeros. Since br->burst is already
zero-initialized, there is no need to maintain and memcpy() another
sequence of zeros into it. Just set the length.
Change-Id: Ic4f6d550010da5caf4bc471ff1e184c9fab30c6d
|
|
Change-Id: Id83fa562ba8496be8915573d2222dd64c7ca5eb9
|
|
This function never returns anything else than 0.
Change-Id: I119535fc09d611ef9f903f5d44aa21cecdce19a2
|
|
In trx_sched_fn() we schedule Downlink bursts in advance, in order
to give the transceiver some time to process them. This function
handles all timeslots of all transceivers in a loop. The problem
is that the given frame number is overwritten on each iteration.
Let's say we have 4 transceivers, each with default fn-advance 20.
The given frame number N will be advanced 4 times, so the resulting
frame number for 4-th transceiver would be (N + 4 * 20) instead of
(N + 20) as expected. Therefore, all additional transceivers would
be served more and more in the future (depending on their position).
Change-Id: Ie3ab544eac81a675266df09cd2b7740e4183188e
|
|
Depends: (libosmocore) Ic291fd3644f34964374227a191c7045d79d77e0d
Change-Id: I61c97a62bd5dbbb4a984921ebdfc10ad6ed00f2a
|
|
Change-Id: I4d4e7a5bfb899787605b3b25dcdc9e9470c438d9
|
|
Change-Id: I13221e5dffe3290fc791f8866f25141fcc0821ff
|
|
Change-Id: Idadb62ec25181b140d9061dc7470da00d47d8336
|
|
There's a standarized way through OML's Administrate State to control
the status of TRX, so let's use and maintain that one rather than this
ad-hoc hack.
Related: SYS#4920
Change-Id: Ia7f190063c35e0ed8e2e734047b3aff608cd3ce3
|
|
Change-Id: Id37562652b1ebc27d808d83342e4961b936dbcad
|
|
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
|
|
bts_model_trx_close is only called during bts_shutdown immediately after
bts_model_deact_rf, so its logic keeps being essentially the same after
this code movement.
On the other hand, bts_model_deact_rf is also called during RSL link
establishment if it failed for whatever reason in
bts.c:trx_link_estab(). In that case, we want to make sure the TRX is
not used so we need to implement bts_model_deact_rf.
Change-Id: Id4eae743da81773a04b82e7b454071b0cc66677a
|
|
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
|
|
Change-Id: Icedd533046853f67da5da84aae28b895a8cdb0bf
|
|
Change-Id: I44d079893d01946da703c4338a686795ced3cb00
|
|
Change-Id: I72559a50570cf447b5930f8995b1f345baeb1ee5
|
|
supported
Using the VTY command will force that value and prevent osmo-bts-trx to
use/send NOMTXPOWER cmd over TRXC.
Change-Id: I496753bc74767a7e18b831768d9d422a738192b7
|