We originally wanted to intrdouce an OML router which would permit
external proceses to implement certain OML MOs. However, that code
was never completed, and all the existing implementation (in three
copies) does is to create a unix domain socket and discard what
is received there.
Change-Id: I7fcbbd5d6b64ddc666ca836dc49abb430be0d5cb
Sometimes the following messages appear in the logging output:
TCH/F: Prim has wrong chan_nr=0xc5 link_id=00, expecting chan_nr=0x0d link_id=00
TCH/F: Prim has wrong chan_nr=0xc2 link_id=00, expecting chan_nr=0x0a link_id=00
when a dynamic timeslot is switched from PDCH to TCH/F (or to TCH/H).
This means that the transmit queue of a timeslot still contains
PDCH frames, that were not properly cleaned on PDCH deactivation.
Let's finally do this in trx_sched_set_lchan().
Change-Id: Ic6560c660c658f36b84e7efa2f1d93e3a870962b
Related: SYS#5108, OS#4804
Trying to (de)activate logical channels that are already (de)activated
is not something that we normally expect. Treat this as error.
Change-Id: I6256280cae35b2b4d7a8ba4b3913ca69cde22611
In this function we already do check that a given timeslot is not
a PDCH slot, so checking if TRX_CHAN_FLAG_PDCH is redundant.
Change-Id: Ie73bdaf0f6bc76ed8d2e95d1fb995333bf617e7e
Both TRXC_PDTCH or TRXC_PTCCH are described in 'trx_chan_desc'
(defined as 'const'), and both have TRX_CHAN_FLAG_PDCH set. So
indeed, this condition can never be true.
Change-Id: Ie185a939b48eb859ac1c8ffa0a4f667fda0cb82b
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
It makes no sense to do further calculations if the actual Uplink
signal strength equals the target value configured in the VTY.
Change-Id: Id99c7013a722403e773df8367b1a9d7a856e639b
Related: SYS#4916
Sending INFO.ind unconditionally in pcu_if_signal_cb() provokes
a lot of warnings during OML bootstrapping / termination:
DPCU INFO pcu_sock.c:247 Sending info
DPCU INFO pcu_sock.c:262 BTS is up
DPCU INFO pcu_sock.c:205 (bts=0,trx=0) unavailable for PCU (op=Disabled adm=Unlocked)
DPCU INFO pcu_sock.c:205 (bts=0,trx=1) unavailable for PCU (op=Disabled adm=Unlocked)
Do not call pcu_tx_info_ind() if the PCU is not connected.
Change-Id: If8bc8bec5ad808be8d40e91278a4a4fde84920b0
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
If no PCU is connected, we cannot be providing GPRS services,
and hence should not transmit SI13.
Change-Id: I54320cf8073a33ed9e35b365921df178005e8967
Closes: OS#3075
The commandline option --vty-ref-xml is needed to enable automatic
generation of the VTY reference manual.
Change-Id: I895db6086748a5916874e779963caed589050109
Related: SYS#4937, OS#1601
The PCUIF is a 'brilliant' protocol: some fields are expected to
be in the network byte order, some in the host order. The NSVC
remote address and local/remote ports is a good example:
- byte order of the address must be the network order, and
- byte order of the ports must be the host order.
Change-Id: I383cab0b58b62734090023298da8c5a341c670d5
Fixes: I310699fabbfec4255f0474f31717f215c1201eca
Related: SYS#4915
This is another regresion introduced by [1]. Both local and remote
port numbers recived in the network order, and must be stored as-is.
Change-Id: I3c21a2c27dcbf6de728ce2c7ccbae9e2f517c450
Fixes: I310699fabbfec4255f0474f31717f215c1201eca
Related: SYS#4915
Using gsm_bts_trx_num() involves redundant iterations over the
list of transceivers - we definitely don't want them.
Change-Id: I4bd40ffcc1e925412a21b0a934bbfdeddbc6ad1f
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
The address_family is 8 bit and have a padding byte afterwards.
By using osmo_load16be it's encoding it wrong and result in an
empty/invalid NSVC configuration.
Change-Id: Ie070b5745124d48e74a6dedd8903b74bfb3ce9d2
Since I310699fabbfec4255f0474f31717f215c1201eca the BTS
can decode NM_ATT_OSMO_NS_LINK_CFG. This OML attribute will be
only used if the OML feature IPV6_NSVC is present.
Change-Id: I9910f2afb3ab94167938b0fd356f2f0a8c382130
With PCU interface version 10 it supports IPv6 NSVC. The new OML IE
NM_ATT_OSMO_NS_LINK_CFG allows to configure IPv6 NSVC.
Change-Id: I310699fabbfec4255f0474f31717f215c1201eca
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
This regression was introduced in 2ff4592ffc.
There is simply no PHY in case of osmo-bts-omldummy.
Change-Id: I864ac3f15e06462d6ce808b3f2188c5c39a5aad2
Fixes: Ic00df9e7278d42bc10c1e1a1c0edde7e13199299
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
Harald Welte
Vadim Yanitskiy
Pau Espin
Philipp Maier
Alexander Couzens