In change [1] together with the actual implementation I introduced
a serious bug to trx_sched_fn(): if a timeslot is configured to use
frequency hopping, both 'pinst' and 'l1h' pointers are *overwriten*
in the inner loop, so the Downlink burst is re-directed to the
approproate PHY instance. However, if a subsequent timeslot is not
hopping, the Downlink burst would be re-directed to the wrong PHY
instance because both pointers were overwriten during a previous
iteration.
Let's add another 'struct phy_instance' pointer to the inner loop,
so it's properly re-initialized for each timeslot iteration.
Change-Id: I9afbbef8dc5d885763356470c27d4392dce8e815
Fixes: [1] I68f4ae09fd0789ad0d8f1c1e17e17dfc4de8e462
Related: SYS#4868, OS#4546
In change [1] the new power control structures and default params
were introduced. In change [2], the existing VTY commands for MS
power control in the BTS were deprecated and changed to use the
new structures as storage. Finally, in change [3], handling of
the power control parameters on the A-bis/RSL was implemented.
This change is the final logical step in the mentioned chain: it
makes both MS/BS power control loops use the new parameters, and
removes the old structures. The actual implementation of both
power control loops remains the same, however the expected output
of some unit tests for the Downlink loop needs to be changed:
- TC_fixed_mode: disabling dynamic power control becomes a separate
step of the test script since the field 'fixed' is removed;
- TC_rxlev_target: RxLev thresholds are printed 'as-is'.
Not all of the new parameters are used by the power control loops
yet. Further improvements to be done in the follow up commits.
[1] I6d41eb238aa6d4f5b77596c5477c2ecbe86de2a8
[2] Icbd9a7d31ce6723294130a31a179a002fccb4612
[3] I5a901eca5a78a0335a6954064e602e65cda85390
Change-Id: Ib18f84c40227841d95a36063a6789bf63054fc2e
Related: SYS#4918
When [baseband] frequency hopping is in use, Downlink bursts from
additional transceivers may end up being transmitted on TRX0/C0.
In this case, we must not apply per-lchan attenuation, because
the BTS shall maintain constant power level on that TRX.
Change-Id: Id171df70447283b00da965e1f81dfac20e35495c
Related: SYS#4918
3GPP TS 44.006, section 11 describes a method how the uplink
SACCH transmission can be repeated to increase transmission
reliability.
Change-Id: I7e4cc33cc010866e41e3b594351a7f7bf93e08ac
Related: OS#4795, SYS#5114
3GPP TS 44.006, section 10 describes a method how the downlink
FACCH transmission can be repeated to increase transmission
reliability.
Change-Id: I72f0cf7eaaef9f80fc35e752c90ae0e2d24d0c75
Depends: libosmocore I6dda239e9cd7033297bed1deb5eb1d9f87b8433f
Related: OS#4796 SYS#5114
Now bts_model_vty_init() must be called only once, otherwise the
process would crash when bts_model_init() is called from main().
Change-Id: I262c39896b5db86c54ad9aa7042c7ca6657815d9
Related: SYS#4937, OS#3036
Similar to bts_vty_init(), BTS specific bts_model_vty_init()
requires a pointer to 'struct gsm_bts'. Not only it's used
as a parent talloc context, but also stored locally, so then
it can be used by some VTY commands.
Let's expose the global 'struct gsm_bts' from main, and pass
the application's talloc context like was done in [1].
This finally makes the BTS model specific options appear in
the automatically generated VTY reference (--vty-ref-xml).
[1] Ic356a950da85de02c82e9882a5fbadaaa6929680
Change-Id: Iee7fee6747dd1e7c0af36f9b27326f651ae37aaf
Related: SYS#4937, OS#3036
When the FACCH is generated (while in SPEECH mode), there is also a
fake speech indication handed up to l1sap.c. We must make sure that only
one of the two indications carry a measurement value, so lets invalidate
the measurement values (RSSI in particular) for the generated TCH
indication.
Change-Id: Ie3f2e620ba2a2ab2fecdbae627ef01c6128fce0b
Related: OS#4799
All the Operative State logic to manage a RadioCarrier//BBTransc NM objects is
centralized in these FSM, where other parts of the code simply send
events to it.
This allows keeping state consistent and offloading logic from each bts
backend, since they are only required to submit events now.
The idea in the long run is to also replace other NM objects with
similar FSMs.
This improved logic fixes bug where PHY + RSL link became available before
OPSTART and hence op state changed to Enabled before receiving any OPSTART message.
Change-Id: Ifb249a821c4270918699b6375a72b3a618e8cfbe
This fixes old behavior mimicing broken behavior in nanoBTS (according to TS 12.21)
where BTS Site Mgr NM object was announced as Enabled despite no OPSTART
was sent by the BSC.
With this new FSM, BTS SiteManager will be announced as Disabled Offline
during OML startup conversation, instead of Enabled.
The new osmo-bsc OML management FSMs use this change in behavior to find
out whether it should use the old broken management states (without
Offline state, as per nanoBTS) or use the new state transitions (which
allow fixing several race conditions).
Change-Id: Iab2d17c45c9642860cd2d5d523c1baae24502243
This fix allows osmo-bts to play fine with newer osmo-bsc NM OML FSMs,
which expectes for non-nanoBTS types to follow TS 12.21 guidelines.
Until now, BSC simply waited to received State Event Change Dependency
for each TS and then sent all required commands (Set Chan Attr, Adm
Unlock and Opstart). In newer osmo-bsc FSMs, Opstart is only sent when
in Offline state, so we need to transit to that state. For the above
mentioned reason, since we pass through the Dependency state anyway
after this patch, older osmo-bscs will work correctly too.
Change-Id: Id9e61f8d773e6e6170c68b5b836d276c747d8d69
in function rx_tchh_fn() the variable meas_avg is not initalized. This
is not always a problem, since most of the time trx_sched_meas_avg() is
populating the variable properly. In cases where a FACCH is transmitted
(chan_state->ul_ongoing_facch = true) the variable is left unpopulated.
In order to have at least stable values for those cases, initalize the
variable with zeros for the ongoing facch phase.
Change-Id: I5c3c1c41d22f9edaaf6bd4478dd04f090dca12a9
Fixes: CID#214480
Make sure that we pick the correct UL measurements from the
history when we deal with AMR SID frames (SUB frames).
Change-Id: I902bb47d68742d2589156f61099b67a0edbaf40b
Related: OS#2978
Currently the UL measurements (RSSI, ToA256, C/I) of the burst that
concludes a block are passed up to the higher layers. This means
that the measurement values of the other bursts are skipped.
Let's keep record of all UL measurements and average the values
before we pass them up to the higher layers. Use a simple ring
buffer to store the measurement history (up to 8 unique entries
for now). Remove *_num/*_sum variables from l1sched_chan_state.
Change-Id: I2b02b51fea5664f161382a4ddc63dbf14ffc9ac5
Related: OS#3032, OS#2978
MA (Mobile Allocation) is actually a bit-mask indicating those ARFCNs
of the Cell Allocation, which must be used as the hopping sequence.
What we store in struct gsm_bts_trx_ts is the actual list of hopping
channels, so let's name it properly and eliminate possible confusion.
Change-Id: I677d66e428fa0fe119ebc37bc2a4e6cc05c251c4
In general, it is always set to 1 (Locked) in
st_open_poweroff_on_enter() right after initial POWEROFF, and once the
BSC unlocks it (based on VTY cfg "rf_locked (0|1)") by sending an OML
message, the bts_model_chg_adm_state() call will update it sending
RFMUTE.
This basically fixes the case where osmo-bsc.cfg is configured with
"rf_locked 1" to start with a TRX locked until manually unlocked.
Related: SYS#4920
Change-Id: I96b64cdc901d6f216df628d7be57a67af4a21e25
Since commit 221ee92551,
bts_model_trx_deact_rf() was being called when RF locking the TRX, which
was implemented by resetting the scheduler. This proved to be a messy
and wrong way to emulate disabling RF, since it modifies tate on lots of
structures from which it is later difficult to recover from, causing
bugs and issues like:
82a35a1dbfbe15a12c87eef420d1cahttps://osmocom.org/issues/4694https://osmocom.org/issues/4695https://osmocom.org/issues/4696https://osmocom.org/issues/4697
So for all these reasons, it is believed a good solution to avoid
resetting the scheduler and simply ask lower layers (osmo-trx) to take
care of disabling RF TX/RX on a given TRX. For TRX implementations not
supporting the newly added RFMUTE command, ramping down to -10dBm still
provides for a way to emulate RF locking. In any case, none of this was
supported until recently so it's not like we are breaking some feature
here.
Related: SYS#4920
Change-Id: I1423ddb390ef327ec7d4a27de2ac5dca663773a5
It was reported that both osmo-bsc and osmo-bts-trx may end up
running in a half-broken state, when everything looks good and
the UEs can see the network, but all channel requests get
rejected due to "trx not usable" error:
lchan_select.c:173 (bts=0) lchan_select_by_type(SDCCH)
lchan_select.c:48 looking for lchan CCCH+SDCCH4: (bts=0,trx=0) trx not usable
lchan_select.c:48 looking for lchan SDCCH8: (bts=0,trx=0) trx not usable
lchan_select.c:239 (bts=0) Failed to select SDCCH channel
lchan_select.c:173 (bts=0) lchan_select_by_type(TCH_H)
lchan_select.c:48 looking for lchan TCH/H: (bts=0,trx=0) trx not usable
lchan_select.c:239 (bts=0) Failed to select TCH_H channel
lchan_select.c:173 (bts=0) lchan_select_by_type(TCH_F)
lchan_select.c:48 looking for lchan TCH/F: (bts=0,trx=0) trx not usable
lchan_select.c:239 (bts=0) Failed to select TCH_F channel
As was then figured out, this happens because the Radio Carrier
MO (Managed Object) remains Disabled even after the BSC has
sent OPSTART and the BTS ACKed it:
oml.c:986 OC=RADIO-CARRIER(02) INST=(00,00,ff): Rx OPSTART
l1_if.c:614 Rx OPSTART for RADIO-CARRIER MO
l1_if.c:201 TRX_PROV(phy0-0)[0x1238c0]{OPEN_POWERON}:
Event TRX_PROV_EV_CFG_ENABLE not permitted
oml.c:144 OC=RADIO-CARRIER(02) INST=(00,00,ff): Tx Opstart Ack
It remains a mistery why the TRX_PROV FSM is already in state
OPEN_POWERON, while it's expected to be in state OPEN_POWEROFF,
but we definitely should not ACKnowledge the OPSTART if this
happens. Send a NACK instead with cause NM_NACK_CANT_PERFORM.
Change-Id: I8727460acbf850b84df67a9cbdc25b47dee1fadd
Related: SYS#5063
We already get quite informative message originated from oml.c:
OC=RADIO-CARRIER(02) INST=(00,00,ff): Rx OPSTART
Change-Id: I3d4a4473541327488d3393b1fa7c6391afb3728a
osmotrx fn-advance (which is the clock_advance variable here) and
osmotrx rts-advance together make up the minimum delay the BTS can react
to a channel request, etc.
The default of 20 are around 92ms which is clearly too much. With
modern hardware and using SCHED_RR a lower value should not be an issue.
See OS#4487 for some related measurements on more CPU-limited devices like a
LimeNet-micro3.
Fixes: OS#4487
Fixes: SYS#4885
Related: SYS#4881
Change-Id: I7da3d0948f38e12342fb714b29f8edc5e9d0933d
The idea behind the baseband frequency hopping is quite simple: we
have several RF carriers (transceivers) transmitting and receiving
on fixed frequencies (just like in a regular multi-trx setup), and
an additional burst routing layer between the schedulear and the
transceiver interface (TRXD over UDP).
Speaking in terms of the proposed implementation:
- on Downlink, dlfh_route_br() calculates the ARFCN corresponding
to the current TDMA frame number according to the hopping sequence
parametets, and picks the transceiver with matching ARFCN;
- on Uplink, ulfh_route_bi() iterates over the transceiver list of
of the BTS, calculating hopping ARFCNs for equivalent timeslots,
and picks the one with ARFCN matching the received burst.
In order to avoid frequent transceiver lookups on the Downlink path,
dlfh_route_br() maintains a "cache" in the timeslot state structure.
Unfortunately, this "cache" seems to be useless on the Uplink path,
so ulfh_route_bi() always needs to lookup the matching transceiver
for each burst received over the TRXD interface.
It may also happen that the scheduler will be unable to route an
Uplink or Downlink burst, e.g. due to inconsistent / incorrect
hopping sequence parameters received from the BSC, or in case
if a transceiver gets RF-locked by the BTS operator.
Such events are logged as "FATAL" and aditionally signalled by the
following osmo-bts-trx specific rate counters:
- trx_sched:dl_fh_no_carrier (Downlink), and
- trx_sched:ul_fh_no_carrier (Uplink).
Change-Id: I68f4ae09fd0789ad0d8f1c1e17e17dfc4de8e462
Related: SYS#4868, OS#4546
This change facilitates the upcoming freq. hopping implementation,
in particular scheduling of dummy bursts on C0 with hopping time-
slots. One problem is that we cannot know in advance, whether to
send a dummy burst on a given timeslot unless all transceivers are
processed. For example, trx#3 may want to send a normal burst on
ARFCN of trx#0 (C0), while we have already sent a dummy burst...
Another important aspect is that we shall not be sending dummy
bursts on transceivers other than C0. Scheduling dummy bursts
from _sched_dl_burst() in the context of a single hopping timeslot
of a single transceiver leaves trx_sched_fn() no way to know
whether it's a dummy burst or something else.
Let's solve both problems by moving dummy burst scheduling logic
from _sched_dl_burst() to trx_sched_fn(). Maintain C0 slot-mask
in the inner (per-trx) loop, so that we can fill missing bursts
with dummy bursts afterwards.
Change-Id: I8c3651c27d2991079e83b8abdb7e2c3f95b97a43
Related: SYS#4868, OS#4546
On receipt of either SIGTERM or SIGINT the shutdown FSM initiates
ramping down of the transmit power on Downlink. I noticed that
for some reason osmo-bts-trx stops sending Downlink bursts during
the process of ramping down.
I also noticed the following imporatant message:
DL1C NOTICE scheduler_trx.c:287 No more clock from transceiver
despite the transceiver is still powered on and keeps sending
the clock indications over the TRXC interface.
As it turned out, the problem is that on receipt of either SIGTERM
or SIGINT, we also raise the global 'quit' flag, so in the scheduler
trx_sched_clock() stealthy stops handling the clock indications.
Let's ensure that clock indications are handled regardless of the
state of 'quit' flag, so the ramping down would work as expected.
Change-Id: Ia71133d6f0b900e5e103595c83303a7cc5c06edf
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
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
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
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
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
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
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
Vadim Yanitskiy
Philipp Maier
Pau Espin
Daniel Willmann