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
Otherwise only those commands that are registered by libosmocore
appear in the generated XML VTY reference - change the order.
Instead of a pointer to 'struct gsm_bts', pass the application's
talloc context, as it's only used for dynamic command allocation.
Change-Id: Ic356a950da85de02c82e9882a5fbadaaa6929680
Related: SYS#4937, OS#3036
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
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
There are some situations where it is useful to be able to change the
Radio Link Timeout at runtime, without restarting the BTS.
This adds a new (hidden) command for this:
"bts <0-255> radio-link-timeout (oml|infinite|<4-64>)"
Change-Id: I64674a432cf7751b16d5d0b52f66766fa6e37028
It's more convenient to use one command to enable/disable sending
of all kinds of UL/DL messages at once, rather than specifying
all of them individually.
Adjust config_write_bts_single(), so it would not print unknown
GSMTAP SAPI entries if gsmtap_sapi_mask is set to UINT32_MAX.
Change-Id: Icd7fce860ecdcf8ffa107bdfee7ec94ea9ea6cb2
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
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
It was a very bad idea to mix "public" BTS features, that are
reported to the BSC via OML, and those features, that are used
locally (and exclusively) in osmo-bts.
Why? At least because we already have the BTS feature manipulation
API in libosmocore, that is used by osmo-bsc, but for some reason
not by osmo-bts. New features added to libosmocore would clash
with the existing "internal" ones like BTS_FEAT_MS_PWR_CTRL_DSP.
So what this change does can be described as follows:
- remove duplicate definition of the "public" features,
- use libosmocore's API for the "public" features,
- separate both "internal" and "public" features:
- the "public" features continue to live in bitvec,
- the "internal" features become flags,
- s/BTS_FEAT/BTS_INTERNAL_FLAG/g.
Change-Id: Icf792d02323bb73e3b8d46384c7890cb1eb4731e
Send test failure event report OML message to the BSC. I found this
useful while manually testing related handling code in OsmoBSC.
Related: OS#1605
Change-Id: I0c4eba1636d8faf5012db26643bdf1d9fb6bfa1e
osmo-bts-trx used to have its own (low-level) MS Power Control loop,
but recently it has been ripped out. Since [1], the process fails to
start if the configuration file still contains 'ms-power-control dsp'.
Let's be more tolerant: override 'dsp' by 'osmo' and print a warning.
[1] I49706926b1e962b18791174627bc3cc0cd0cd9d5
Change-Id: I4facd21bca3d8cb80d21e83ea267bc013e474533
It indicates whether BTS model supports managing an MS Power Control
Loop over HW/DSP instead of using the software based osmocom algorithm
present in osmo-bts.
osmo-bts-trx own loop implementation is considered to be a "DSP/HW" one
since it acts on lower layers and interferes with osmocom algorithm
since it controls the same end variable "lchan->ms_power_ctrl.current",
this way we make sure both aren't enabled at the same time.
Old behavior in kept: if common upper-layer algo is not enabled
explicitly in VTY (ms-power-control osmo) and bts-trx specific lower
layer algo is neither enabled (osmotrx ms-power-loop <xyz>), then no
power control is done at all.
Related: OS#1851
Change-Id: I49706926b1e962b18791174627bc3cc0cd0cd9d5
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
Thies field is used to store and retrieve whether MS power needs to be
calculated and updated by osmo-bts software or autonomously by lower
layers. Previous name was not clear
and may have been understood as indicating whether MS Power Control loop
is done or not in general, and the responsible for that is located under
lchan's ms_power_ctrl.fixed.
Related: OS#1851
Change-Id: Ic690ab69866a7377f1597e24aa7b0214831c1cbe
Make it obvious for compilers and for coverity, that the sapi value used
to shift a bit for the sapi_mask is always <= 31. The sapi value is an
index of the value string l1sap_common_sapi_names, which has 24 entries.
Fixes: CID#205067, CID#205068
Change-Id: Id8be0ab67479b1f76a4f624bd3a5242e4fe59f4b
Change uint8_t sapi to int, so we can properly assert on errors from
get_string_value().
Fixes: CID#205066, CID#205069
Change-Id: I4d30afacfab93051868ae8f462cee9ad3dbc7fd0
Since March 15th 2017, libosmocore API logging_vty_add_cmds() had its
parameter removed (c65c5b4ea075ef6cef11fff9442ae0b15c1d6af7). However,
definition in C file doesn't contain "(void)", which means number of
parameters is undefined and thus compiler doesn't complain. Let's remove
parameters from all callers before enforcing "(void)" on it.
API osmo_stats_vty_add_cmds never had a param list but has seem problem
(no "void"), so some users decided to pass a parameter to it.
Change-Id: Ia4d1a7914308d1481fe31fe0986265ead339e61e
Related: OS#4138
The radio link quality is defined by C/I (Carrier-to-Interference
ratio), which is computed from the training sequence of each
received burst, by comparing the "ideal" training sequence with
the actual (received) one.
Link quality measurements are used by L1SAP to filter out "ghost"
Access Bursts, and by the link quality adaptation algorithms. One
can define minimum link quality values using the VTY interface.
On the VTY interface we expect integer C/I values in centiBels
(cB, 10e-2 B), while the internal structures are using float
values in deciBels (dB, 10e-1 B). Some PHYs (sysmo, octphy,
oc2g, and litecell15) expose C/I measurements in deciBels,
while on the L1SAP interface we finally send then in centiBels.
Let's avoid this confusion and stick to a single format, that
will be used by the internal logic of OsmoBTS - integer values
(int16_t) in centiBels. This will give us the range of:
-32768 .. 32767 centiBels, or
-3276.8 .. 3276.7 deciBels,
which is certainly sufficient.
Change-Id: If624d6fdc0270e6813af8700d95f1345903c8a01
Let's keep some statistics about the min/max/average frame number
advance that we're observing above L1SAP when comparing the time in the
PH-RTS.ind and the frame number we observe in PH-DATA.ind of data
that was received on the uplink.
The statistics are currently only shown in the VTY, but this is a
precursor to using them to correctly advance the LAPDm timers in a
follow-up patch.
Change-Id: I8f739fdb808a614f080afbc4654641ec3df19eb2
Related: OS#2294
Related: OS#3906
This adds the final missing part to full CBCH support:
* keep a tab on the current queue length for basic + extended CBCH
* keep rate counters about the number of sent / transmitted SMSCB
* send CBCH LOAD information via RSL to the BSC
Change-Id: I7068c7937a60a900c40439115bb84dc3ee0d061f
The logic for Extended CBCH are the same as for the Basic CBCH, we just
need to
* duplicate our related state
* parse the optional RSL_IE_SMSCB_CHAN_INDICATOR IE
* start to send data on the Extended CBCH (TB=4..7)
Change-Id: If2c6dc7da1e2185ab75fc957f8d305ad8db22429
Closes: OS#3535
A comma is needed to separate a command definition from its
description, not the parts of description. Let's fix this.
Before this patch:
OsmoBTS# configure terminal
OsmoBTS(config)# phy 0
OsmoBTS(phy)# no?
no PHY Instance number
OsmoBTS(phy)# no ?
instance
osmotrx OsmoTRX Transceiver configuration
After this patch:
OsmoBTS# configure terminal
OsmoBTS(config)# phy 0
OsmoBTS(phy)# no?
no Negate a command or set its defaults
OsmoBTS(phy)# no ?
instance Select a PHY instance to remove
osmotrx OsmoTRX Transceiver configuration
Change-Id: If10d85abc6506118ba08c37e8101f423d6f838ea
TRX0 is allocated in a different place than other TRX.
Commit that introduced the bug added an initialization step
(bts_trx_init) applied in VTY cmd "trx <0-254>", where TRX are allocated
since same commit, but doesn't initialize TRX0 for reasons explained in
first paragraph.
As a result, some parameters were not applied to TRX0, like
power ramping increment step, which prevented MS from finding the network in
osmo-gsm-tester tests.
Fixes: eebb6a4216 ("bts: Allocate TRX for BTS dynamically, deprecate -t")
Change-Id: I5afd66548634ff53e2af24dc7055d408ca8ca4e3
No need to pass -t num_trx anymore to specify number of TRX to use. It
is calculated based on dynamic allocation from VTY config.
Using parameter -t is flagged as deprecated and is transformed into a
NOOP por backward compatibility.
As a result, TRX now are allocated after the BTS is allocated and
initial config (pre-VTY) is applied.
A new function bts_trx_init() is added, to set default config on each
TRX during allocation and before setting VTY config on it.
A new per BTS model function bts_model_trx_init() is added, to allow
per model specific default configuration of each TRX.
Change-Id: Iab1a754ab12a626759f9f90aa66f87bdce65ac9c
The command implementation says "deprecated", so then the vty command attribute
should also be DEPRECATED. It will be hidden from online docs and vty
reference.
Change-Id: I23e620f1b947e129989fe69c6380c91b9abf7021